linux-kernel - Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platform data to a dev path name

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:	Sun, 13 Mar 2011 17:58:47 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	andy.green@...aro.org
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, patches@...aro.org
Subject: Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platform data to a dev path name

On Sunday, March 13, 2011, Andy Green wrote:
> On 03/13/2011 12:51 PM, Somebody in the thread at some point said:
> 
> >> Okay.  This is not a PC we are talking about.
> >>
> >> If the platform / board definition file is registering the USB hosts
> >> synchronously at boot time, the driver is composed into the monolithic
> >> kernel, there are no PCI busses or whatever on the SoC, the bus indexing
> >> is totally deterministic.  This is extremely common in the platform /
> >> SoC case and is the case the patchset is targeted at.  Even further, the
> >> only time you'd use it is to reach a USB asset that is wired up the same
> >> board permanently as well.
> >>
> >> Anyway this seems moot by now.
> >
> > However, if you add a new infrastructure like this, it should be at least
> > usable on systems that you description doesn't apply to.
> 
> Sounds reasonable, except the platform data is coming from a 
> board-specific board definition file at boot-time to talk about assets 
> that are on fixed interfaces of a specific board.

I'm not sure how this contradicts what I said above.

> It's not really applicable to wider generic bus use, just like platform_data
> usually isn't and has to be targeted at "device at XYZ on I2C bus n" with 
> knowledge of what driver is bound to that device.  Despite that 
> "impedence mismatch", it covers the SoC onboard USB asset case just fine 
> as it is.

So, you want to have a mechanism telling the driver "if the device
happens to have this particular path, use that platform data", right?

And it works because the initialization code kind of knows what path the
device is going to be at, so it can predict that and provide the mathing data.

Unfortunately, this relies on how device paths are constructed at the moment,
so if this approach is adopted in general, it will prevent us from changing
that way in the future (or at least it will make that very difficult).

Perhaps you could use some other kind of device identification here?

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