2012/12/26 Rafał Miłecki <zajec5@xxxxxxxxx>:
> 2012/12/26 Hauke Mehrtens <hauke@xxxxxxxxxx>:
>> On 12/26/2012 11:46 AM, Rafał Miłecki wrote:
>>> 2012/12/26 Hauke Mehrtens <hauke@xxxxxxxxxx>:
>>>> On 12/25/2012 07:23 PM, Rafał Miłecki wrote:
>>>>> +#ifdef CONFIG_SSB_SFLASH
>>>>> +struct ssb_sflash {
>>>>> + bool present;
>>>>> +};
>>>>> +#endif
>>>>
>>>> I assume you want to share some of the code for the serial flash driver
>>>> between bcma and ssb. You should create a file with the structure in
>>>> include/linux/platform_data/ and share that between bcma and ssb.
>>>
>>> It's a small struct having about 5 trivial fields. We don't share
>>> sturcts for any other drivers (chipcommon/mips/pcie) so I think they
>>> should stay separated here as well.
>>
>> When this structure is just used in ssb or bcma and in the nvram code of
>> arch/mips/bcm47x I would also prefer two structures one for bcma and one
>> for ssb.
>>
>>> Plus the mtd driver will have to implement bus abstraction anyway.
>>
>> If you have a structure describing the needs of the serial flash driver
>> in drivers/mtd/ you could write the flash driver without any ifdef
>> BCMA_* or SSB_* and if does not have to include linux/ssb/ssb.h or
>> linu/bcma/bcma.h, like I did this with the watchdog driver
>> include/linux/bcm47xx_wdt.h
>
> OK, I've analyzed your bcm47xx_wdt. I can see you abstract bus here
> and implement some simple ops.
>
> We could add similar extra layer for sflash, but I wonder what we
> could put in that. For full sflash support we need 2 things:
> 1) Hardware info (u32 window, u32 blocksize, u16 numblocks)
> 2) Chipcommon access (read32, write32)
>
> In total that are only ~5 fields in some struct. I wonder if it makes
> sense to move that abstracting code to an extra layer? Maybe we can
> just do that in bcm47xxsflash with few ifdefs?
Hm, the advantage is that we could fill that struct directly instead
copying values in bcm47xxsflash probe function. Still not sure which
path to follow.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
