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: <4D7A44E0.5080605@nokia.com>
Date:	Fri, 11 Mar 2011 17:50:56 +0200
From:	Roger Quadros <roger.quadros@...ia.com>
To:	ext Arnd Bergmann <arnd@...db.de>
CC:	<andy.green@...aro.org>, ext Andy Green <andy@...mcat.com>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

Hi,

On 03/11/2011 05:22 PM, ext Arnd Bergmann wrote:
> On Friday 11 March 2011, Roger Quadros wrote:
>>> There is no reason I can see that onboard USB assets should continue to
>>> be treated differently to miss out on the same capability because they
>>> are USB and not I2C, particularly as a permanently NULL platform_data
>>> pointer is already sitting there in the usb_device's .dev already
>>> exactly for this use.
>>
>> What do you want to set in platform data? the ethernet device name? 
>> Isn't that better done in user space using udev rules?
> 
> A udev rule would solve the problem at hand, but I'd consider that
> an ugly workaround as well. The naming in the kernel is really
> bogus -- any USB device that has a fixed address gets treated
> as eth0, while others become usb0, with the same driver,
> see the code fragment below.

but isn't that sensible? a real ethernet hardware will have a MAC
address. no?

> The most simple way to solve this particular problem is to
> remove the check for "net->dev_addr [0] & 0x02", which only
> has any effect on the smsc75xx and smsc95xx drivers, both of
> which are for real ethernet devices, not point-to-point
> USB links.
> 
> That would however still leave the problem of the missing
> mac address, which is not good if you want to work with the
> system using dhcp.

The USB ethernet peripheral does not have a globally unique MAC ??

-- 
regards,
-roger
--
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/