linux-kernel - Re: RFC: Platform data for onboard USB assets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D8BA548.6030702@linaro.org>
Date:	Thu, 24 Mar 2011 20:10:48 +0000
From:	Andy Green <andy@...mcat.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>, arnd@...db.de,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	greg@...ah.com
Subject: Re: RFC: Platform data for onboard USB assets

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/