[PATCH 42/83] staging: brcm80211: remove dependency on pci core difinitions from aiutils.c

Arend van Spriel arend at broadcom.com
Thu Jun 2 08:38:55 UTC 2011


On 06/02/2011 01:18 AM, Julian Calaby wrote:
> On Wed, Jun 1, 2011 at 21:45, Roland Vossen<rvossen at broadcom.com>  wrote:
>> From: Arend van Spriel<arend at broadcom.com>
>>
>> The file aiutils.c included the register definition includes for the
>> PCI and PCIe core. This was for two functions which have been partly
>> moved to nicpci.c. This means that nicpci.h is the only include file
>> to provide interface to aiutils.c for PCI core related functions.
>>
>> Signed-off-by: Arend van Spriel<arend at broadcom.com>
>> Reviewed-by: Roland Vossen<rvossen at broadcom.com>
>> ---
>> diff --git a/drivers/staging/brcm80211/brcmsmac/aiutils.c b/drivers/staging/brcm80211/brcmsmac/aiutils.c
>> index bae40fe..43320b4 100644
>> --- a/drivers/staging/brcm80211/brcmsmac/aiutils.c
>> +++ b/drivers/staging/brcm80211/brcmsmac/aiutils.c
>> @@ -1915,7 +1913,7 @@ void ai_pci_down(si_t *sih)
>>   void ai_pci_setup(si_t *sih, uint coremask)
>>   {
>>         si_info_t *sii;
>> -       struct sbpciregs *pciregs = NULL;
>> +       void *regs = NULL;
>>         u32 siflag = 0, w;
>>         uint idx = 0;
>>
> Is changing this to void* necessarily a good idea? - the regs variable
> appears to only be used by PCI code, so having it declared as a struct
> sdpciregs* isn't going to make it any less generic - and having it
> declared as a structure would help to spot bugs in the code.
>
> Thanks,

Hi Julian,

The separation I tried to accomplish was to have the knowledge of the 
pci core register layout in one file, ie. nicpci.c. So this step is to 
make aiutils.c unaware of that layout. Another solution would be to move 
the function itself to nicpci.c. I will look into this as tend to agree 
with you.

Gr. AvS

-- 
Almost nobody dances sober, unless they happen to be insane.
-- H.P. Lovecraft --





More information about the devel mailing list