Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-24T20:10:56Z

On 03/24/2011 07:17 PM, Somebody in the thread at some point said:

Hi -

>> The SDIO patches target wl12xx that is already in mainline and
>> already using literally platform_data. Because there's no neater
>> way on offer, it currently -- in mainline -- does it by having a
>> built-in stub with its own Kconfig, that copies platform_data from
>> the board definition file into a private malloc'd buffer, then uses
>> it by getting a pointer to the copy from another private api in the
>> driver. All this in a specific driver.
>
> I've spent some time looking at the wl12xx driver code, and while the
> data symbol it is using happens to be called 'platform_data', it isn't
> actually the same thing as we're debating in this thread.
>
> The platform_data in drivers/net/wireless/wl12xx_platform_data.c is a
> strongly typed pointer to a 'struct wl12xx_platform_data', which
> doesn't have the deficiencies associated with
> (struct device*)->platform_data. It isn't a void* travelling through
> the device model without guarantees that the right thing will get
> dereferenced on the other end.

I see you're left exactly as you were found by the earlier discussion of
how dangerous or not that void * is in this particular case.

> The fact that it has /other/ deficiencies is I imagine exactly why
> you want to be rid of it, and rightly so. Immediately obvious is that
> the way it currently is done means that there can never be more than
> one wl12xx in the system.

Actually what I wanted from the start is to fix some issues for TI /
Panda and provide a generic way for other people to do something similar
as a side-effect, because delivery of this configuration information,
one way or another, is a generic issue.

Arnd seems to have sold his "change everything to eth%d" fix so that one
is off my plate.

I have a solution just at Panda level thanks to Alan Cox's workaround
for MAC setting on ethernet and WLAN I'll issue shortly, that does not
address the real problems that could be addressed with another approach
at the right layer.

That leaves my async platform_data code just fixing wl12xx access to its
own platform_data because that's what I found to clean up so far. And
then -->

> I've got a proposal for a solution. I'll get it written up as
> quickly as possible and send it out soon.

I see. Isn't it a bit curious you got this sudden off-piste interest in
improving the platform_data situation of wl12xx after it turns up in
this RFC? I mean I like having my work done for me, if that's how it is
maybe we can work out a system ^^

-Andy