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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Mar 2011 13:17:04 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	andy.green@...aro.org
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 Wed, Mar 23, 2011 at 10:06:16AM +0000, Andy Green wrote:
> On 03/23/2011 09:47 AM, Somebody in the thread at some point said:
> >>There is no udev solution for what is being done currently by the async
> >>platform_data patchset with SDIO WLAN.  The patches are out there and in
> >>use already.  The only reason I don't post them here as round 2 of the
> >>RFC yet is because Grant wanted a couple of days and politically it's
> >>expedient for me to agree to that.
> >
> >Kernel policy has always been that just because some vendor has deployed
> >an interface doesn't mean we care one iota about it or consider it an
> >argument for the solution. In some cases in fact it bcomes the working
> >demo of why it was a bad idea.
> 
> To be clear, this is not about any funny business at the interface
> on the hardware.
> 
> 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.

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.

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

g.

--
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/