netdev - Re: [Pasemi-linux] I2C MDIO support for pasemi

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: <C3F69A6B-85D0-4FB4-834E-958A21C7577A@freescale.com>
Date:	Wed, 2 Apr 2008 17:45:38 -0500
From:	Andy Fleming <afleming@...escale.com>
To:	Nate Case <ncase@...-inc.com>
Cc:	Olof Johansson <olof@...om.net>, netdev@...r.kernel.org,
	pasemi-linux@...abs.org
Subject: Re: [Pasemi-linux] I2C MDIO support for pasemi_mac driver

On Mar 13, 2008, at 16:57, Nate Case wrote:

> On Fri, 2008-03-07 at 12:48 -0600, Olof Johansson wrote:
>> On second thought, it might be a better idea to change from BUS:ID to
>> BUSTYPE:BUS:ID in phylib, to separate the namespaces.
>>
>> That, plus a way to get to an i2c bus number from a device tree node,
>> and we should be all set. That might be tricker though.
>
> This turned out to not be as invasive of a change as I thought.   
> Here's
> my first attempt at it.  The changes to pasemi_mac are based on your
> first patch but modified accordingly for the new bus type field.
>
> Comments are welcome.  Patch is against 2.6.23 for now (though I
> wouldn't expect any of these areas to have changed much since then).
> After I get some feedback I can rebase against the latest netdev and  
> do
> a formal submission.

Sorry, I should have responded to this when it arrived.

My first instinct is that the current bus->id shouldn't be an int at  
all (well, obviously not my *first* instinct, since that's what I did  
the first time through).  So I like the idea of including a label in  
the bus, but I'm not sure if it's necessary to add a new field.   
Instead, I'd like to see bus->id converted to a char * or char [].  I  
played around with this a bit today, and it requires a little more  
work than it might at first seem, but is quite doable.

The question is whether that would solve your problem.  I think you  
would then be able to register buses with the id "pas_gpio:xxx" or  
"i2c:xxx", etc.

Anyway, I'm sending a patch which does that as an RFC in a follow-on  
email.  A part of me thinks adding bus->type might be good, whether  
it's the final solution or not.

Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html