netdev - Re: [PATCH net-next v1 17/21] amd-xgbe: Add I2C support for determining SFP media types

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] [day] [month] [year] [list]

Date:   Wed, 9 Nov 2016 09:35:01 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>, Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 17/21] amd-xgbe: Add I2C support for
 determining SFP media types

On 11/3/2016 10:18 AM, Andrew Lunn wrote:
>> There are a couple of things about this. Russel's work isn't part of
>> the kernel yet so I can't make use of it.
> 
> Well, you could guide it into the kernel. Part of it has already made
> the way in. And i know of other platforms which would benefit from it.
> 
>> Additionally, the I2C device is integrated into the IP of the
>> network device with register addresses being offsets of the network
>> device BAR so I'm not sure how I would go about getting it setup in
>> order to use the i2c infrastructure.
> 
> Have you looked at the core i2c stuff? All you need is an
> i2c_algorithim structure:
> 
> http://lxr.free-electrons.com/source/include/linux/i2c.h#L407
> 
> and an i2c_adaptor structure:
> 
> http://lxr.free-electrons.com/source/include/linux/i2c.h#L532
> 
> and then you can call i2c_add_adapter() to register your i2c bus with
> the i2c core. Embedded such an i2c driver inside another driver is not
> a problem.

I looked into this but I need to investigate this more. The I2C bus
for this device is dedicated to multiple instances of this device which
requires obtaining a hardware mutex before using it. I see how the
locking is done, but I might need additional mutexes to protect certain
scenarios and it could affect performance if I have to obtain and
release the hardware mutex more than is needed.

I'd like to stay with what I have for now in order to enable the driver
and then come back and look at what it would take to integrate this
support into the driver knowing that userspace could be accessing the
bus, also.

Thanks,
Tom

> 
>   Andrew
>