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: <4D7A4BDE.7050206@linaro.org>
Date:	Fri, 11 Mar 2011 16:20:46 +0000
From:	Andy Green <andy@...mcat.com>
To:	Greg KH <greg@...ah.com>
CC:	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/11/2011 04:08 PM, Somebody in the thread at some point said:
> On Fri, Mar 11, 2011 at 09:50:32AM +0000, Andy Green wrote:
>> The particular use that suggested this is on Panda, it would be
>> ideal to be able to set a flag in the usb device's platform data
>> that forces it to be named eth%d since it's a hardwired asset on the
>> board with an RJ45 socket.
>
> If you _really_ need to name your network devices in a specific order,
> then use the userspace tools we already have to do this.  That is what
> they were created for, why ignore them?

I think maybe discussion of this use-case, its usbnet specificity, and 
the alternative options to achieve that have derailed discussion about 
what I was actually asking.

Is it true that for on-board devices, it can sometimes be legitimate and 
useful to be able to deliver platform_data from the board file through 
to stuff on a USB bus, same as you would for memory mapped, I2C, other 
busses?

Or is that it since it is USB, it can never be useful or legitimate, no 
matter what different kind of wired-up on-board USB device it is, to 
have the board definition file configure the driver for that instantiation?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ