netdev - Re: [PATCH] dm9000: Support MAC address setting through platform data.

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:	Fri, 25 Jul 2008 11:23:01 +0200
From:	Laurent Pinchart <laurentp@...-semaphore.com>
To:	Ben Dooks <ben-linux@...ff.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] dm9000: Support MAC address setting through platform data.

On Friday 25 July 2008, Ben Dooks wrote:
> On Wed, Jul 23, 2008 at 05:41:52PM +0200, Laurent Pinchart wrote:
> > The dm9000 driver reads the chip's MAC address from the attached EEPROM.
> > When no EEPROM is present, or when the MAC address is invalid, it falls
> > back to reading the address from the chip.
> > 
> > This patch lets platform code set the desired MAC address through platform
> > data.
> 
> I belive we've had discussions about this before on the subject
> as this is generally down to broken boot-loader behaviour.
> 
> Would people have objections to passing the mac address in on the
> command line and having the driver initialise it from there? Are
> there any other ethernet drivers out there with the same problem?

That wouldn't really help here. I should have provided more background information, let's fix this.

The system I'm working on has an ISA-like bus on which users can plug extension boards. One of those board has a DM9000 chip connected directly to the bus. Having several DM9000-based extension boards in a system is a common situation.

The extension boards have a serial EEPROM connected to the bus, but no EEPROM connected to the DM9000. The EEPROM stores, among other information, the MAC address. The platform driver I wrote for the extension board reads the EEPROM content, and needs to pass the MAC address when it registers a DM9000 device.

I don't think the boot loader is the right place to fix the issue. It would involve scanning all boards on the extension bus and configuring the DM9000, which isn't really practical. Beside, the bus can be reset at runtime without involving a full system reset, in which case Linux will have to reprogram the DM9000 with a MAC address anyway.

> I've added some notes on the patch anyway.
>  
> > Signed-off-by: Laurent Pinchart <laurentp@...-semaphore.com>
> > ---
> >  drivers/net/dm9000.c   |    3 +++
> >  include/linux/dm9000.h |    1 +
> >  2 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
> > index 864295e..6bc8924 100644
> > --- a/drivers/net/dm9000.c
> > +++ b/drivers/net/dm9000.c
> > @@ -716,6 +716,11 @@ dm9000_probe(struct platform_device *pdev)
> >  	for (i = 0; i < 6; i += 2)
> >  		dm9000_read_eeprom(db, i / 2, ndev->dev_addr+i);
> >  
> > +	if (!is_valid_ether_addr(ndev->dev_addr) && pdata != NULL) {
> > +		mac_src = "platform data";
> > +		memcpy(ndev->dev_addr, pdata->dev_addr, 6);
> > +	}
> > +
> >  	if (!is_valid_ether_addr(ndev->dev_addr)) {
> >  		/* try reading from mac */
> >  		
> > diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
> > index a375046..4fb49a4 100644
> > --- a/include/linux/dm9000.h
> > +++ b/include/linux/dm9000.h
> > @@ -26,6 +26,7 @@
> >  
> >  struct dm9000_plat_data {
> >  	unsigned int	flags;
> > +	unsigned char	dev_addr[6];
> 
> how about unsigned char *mac_addr, so that you can detect
> if the address has not been passed in easily. dev_addr is
> not really descriptive enough as a name.

mac_addr is indeed a better name. Using an unsigned char * involves extra storage. What about a DM9000_PLATF_MAC_ADDR flag instead ?

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)