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]

Message-ID: <AANLkTikArWRWcJJRu-3rbJYanHxa4jKu2oovtLztUsk9@mail.gmail.com>
Date:	Tue, 22 Mar 2011 23:49:51 +0530
From:	Jaswinder Singh <jaswinder.singh@...aro.org>
To:	andy.green@...aro.org
Cc:	Andy Green <andy@...mcat.com>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	greg@...ah.com, benh@...nel.crashing.org,
	grant.likely@...retlab.ca, Nicolas Pitre <nicolas.pitre@...aro.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 22 March 2011 21:34, Andy Green <andy@...mcat.com> wrote:
> On 03/22/2011 03:05 PM, Somebody in the thread at some point said:
>
> Hi -
>
>>  Personally, I wouldn't have bothered thinking about some kernel-wide
>> solution to the Panda SMSC9514 issue. I think defining Panda specific
>>  udev rules to 'rename the SMSC9614 on USB1(?) to ETH0' is sufficient and
>> legal to do. Bus enumeration algos change neither often nor enough.
>> I believe there would be far riskier assumptions in filesystems already.
>
> Not sure you got all the points there.  The interface index is not targeted
> at all, it's the interface class.  That is why I only talk about usb%d vs
> eth%d.
>
> If you think about what userland has to do to correct that, it involves
> userland understanding that it is running on specifically a Panda board or
> other boards that need mangling, and it is looking at the device that is
> specifically the onboard one.  (You cannot do it from VID/PID because that
> same VID/PID can turn up in a second pluggable adapter case -- still an
> smsc95xx you see -- where you really would want it called usb%d.)  This is
> why elsewhere I refer to this as a "userland board quirk database" being
> needed to solve it in userland.  If it was simpler, sure, I wouldn't bother
> looking to guide the driver's choice in kernel because you can as pointed
> out meddle them from userland.  But if you look into what has to be done in
> Userland it's nothing like a normal udev handler based only on vid/pid.
>  Userland is actually super allergic to knowing directly what it is running
> on and making decisions based on that, for good reasons, and desperately
> wants to be generic leaving all board quirks for the kernel to hide.  And
> the machine definition file is designed to understand board-specific
> information.

I thought I understood. You want the RJ-45 port of _Panda_ be
called ethN(say eth0) rather than usbN, while other USB-Ethernet adaptors,
if any and SMSC9514, connected to the USB downstream ports of
LAN9514 be named usbN.

If yes, isn't that possible by specifying a _Panda_ specific udev rule
to find and rename a network interface based only on its type and
devpath without needing its MAC address?  Greg ?
The udev rule could be a part of some hwpack.


>>    Though it is illegal for a NIC to not have MAC address, no spec demands
>> the
>>  MAC be on some EEPROM or like. Theoretically, the NIC vendor could
>> hand me a NIC
>> and a note with it's unique MAC address scribbled :)
>>  As Mark already noted, savings pile if we could save eeproms when a
>> device is
>> expected to ship in tens of thousands.
>>  IIANM, Greg acknowledged passing MAC via board specific data
>> structure(albeit via DT)
>> It's a different matter that DT has many hearts to win(at least in ARM
>> Linux)
>> So, perhaps the answer to Q(a) is - Yes.
>>
>> (b) IMHO, though stable enough, the most obvious method of 'devpath
>> association'
>>  is indeed not future-proof.
>
> What're you thinking it's not future-proof against?

Even if the rootfilesystem remains the same, the devpath association will
fail if, say, Linux USB core decides to number usb busses in reverse order as
a part of some code restructuring.
After all the USB spec doesn't say about the bus/port ordering.

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