linux-mips
[Top] [All Lists]

Re: [PATCH 3/7] bcma: scan for extra address space

To: Hauke Mehrtens <hauke@hauke-m.de>
Subject: Re: [PATCH 3/7] bcma: scan for extra address space
From: Julian Calaby <julian.calaby@gmail.com>
Date: Mon, 12 Mar 2012 12:30:54 +1100
Cc: gregkh@linuxfoundation.org, stern@rowland.harvard.edu, linux-mips@linux-mips.org, ralf@linux-mips.org, m@bues.ch, linux-usb@vger.kernel.org, Rafał Miłecki <zajec5@gmail.com>, linux-wireless@vger.kernel.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=REfPJsNXoXD0Jyksyq1s+4vcw7uYZPzw96m36+CKYN8=; b=iskjAI0n2TM1QGYnnuhp6vjdqnZvV7Le+3hbBegIGUoFhRwHSFZVOdJPUD1O6qnZDC 5xg5ukZoOpEAtnJjTa7ArYPy9uQr0YgQDHFXvmuiFaB9w0oyS6Xa2mzvKh6sOvGVRtAg ZPcqoC5awhGfhNVYYD36a2IktPp2UkgfoxWZCyKIK2oTldc+cdUH6ujzaa+0xcE8jb95 IijnGPpC4GwStqNMDIqdylnrU48rmFNT/sYCBL0B1PGm4YeofBpa7x8wJkXDgHy+nPU5 zNAh8oNpPCY/ztkVeirB3AjwlGWuLwYzSL/yzorviS2VpT6achHvY/3MdR5cVy61do4Z Efig==
In-reply-to: <4F5D3679.3090900@hauke-m.de>
References: <1331496505-18697-1-git-send-email-hauke@hauke-m.de> <1331496505-18697-4-git-send-email-hauke@hauke-m.de> <CAGRGNgX116dRB03NTL_DFZ4b_PYcdY+Un_cVwt6ZUGR1bwZzHA@mail.gmail.com> <4F5D3679.3090900@hauke-m.de>
Sender: linux-mips-bounce@linux-mips.org
Hi Hauke,

On Mon, Mar 12, 2012 at 10:34, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> On 03/11/2012 10:59 PM, Julian Calaby wrote:
>> Hi Hauke,
>>
>> On Mon, Mar 12, 2012 at 07:08, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>> Some cores like the USB core have two address spaces. In the USB host
>>> controller one address space is used for the OHCI and the other for the
>>> EHCI controller interface. The USB controller is the only core I found
>>> with two address spaces. This code is based on the AI scan function
>>> ai_scan() in shared/aiutils.c i the Broadcom SDK.
>>>
>>> CC: Rafał Miłecki <zajec5@gmail.com>
>>> CC: linux-wireless@vger.kernel.org
>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>> ---
>>>  drivers/bcma/scan.c       |   18 +++++++++++++++++-
>>>  include/linux/bcma/bcma.h |    1 +
>>>  2 files changed, 18 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
>>> index 3a2f672..3c2eeed 100644
>>> --- a/drivers/bcma/scan.c
>>> +++ b/drivers/bcma/scan.c
>>> @@ -286,6 +286,22 @@ static int bcma_get_next_core(struct bcma_bus *bus, 
>>> u32 __iomem **eromptr,
>>>                        return -EILSEQ;
>>>        }
>>>
>>> +
>>> +       /* First Slave Address Descriptor should be port 0:
>>> +        * the main register space for the core
>>> +        */
>>> +       tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 
>>> 0);
>>> +       if (tmp <= 0) {
>>> +               /* Try again to see if it is a bridge */
>>> +               tmp = bcma_erom_get_addr_desc(bus, eromptr,
>>> +                                             SCAN_ADDR_TYPE_BRIDGE, 0);
>>> +               if (tmp > 0) {
>>> +                       pr_info("found bridge");
>>> +                       return -ENXIO;
>>> +               }
>>
>> Should this do something if the second bcma_erom_get_addr_desc() call
>> returns an error? We seem to be putting any errors from that call into
>> the addr member of the core structure below.
> Yes that's true, we should handle that error. If tmp <= 0 the
> description entry was malformed and something went wrong and we should
> handle it, a correctly found bridge should just be ignored.
>
> I will fix this, should I resend the hole series or just this patch?

I'm not sure the rest of the series made it to linux-wireless, so
maybe you should resend everything.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

<Prev in Thread] Current Thread [Next in Thread>