netdev - Re: [PATCH] net: phy: Add support for SMSC/Microchip LAN9303 3-port switch

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: <531057A4.5020607@denx.de>
Date:	Fri, 28 Feb 2014 10:32:20 +0100
From:	Stefan Roese <sr@...x.de>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, r.meier@...mens.com,
	lukas.stockmann@...mens.com, f.fainelli@...il.com
Subject: Re: [PATCH] net: phy: Add support for SMSC/Microchip LAN9303 3-port
 switch

On 27.02.2014 23:02, David Miller wrote:
> From: Stefan Roese <sr@...x.de>
> Date: Thu, 27 Feb 2014 10:07:52 +0100
>
>> This driver exposes a sysfs interface to access the LAN9303 registers to
>> userspace. These sysfs files can be used to configure the switch.
>>
>> Signed-off-by: Stefan Roese <sr@...x.de>
>
> We have an abstraction for programming switch devices called DSA.
>
> Even if DSA doesn't fullfill your needs, doing adjustments using sysfs
> files in userland is going to be the worst user experience possible.

DSA would have been optimal for us, as we really want to expose the 
external switch ports to the host cpu as (virtual) ethernet ports. But 
as Florian already mentioned, this switch does not support DSA. Only 
VLAN tagging with some special configuration options to make this setup 
possible for us.

I'm not sure but perhaps its possible to use the kernel DSA 
infrastructure for this switch after all? Are some non-DSA compatible 
switches supported right now? I could not find any reference for such 
non-DSA devices. Perhaps I missed something here.

> Every driver will export different things to tweak, each device will
> have different semantics and limitations for these settings, etc.
>
> Better is to come up with a real, types, interface for programming
> such devices and providing an implementation of that.

Right. Such a thing would be better. But as Florian already pointed out, 
nothing like this is available in kernel.org right now. Thats the reason 
why I chose to implement this "simple" driver, btw as done in 
drivers/net/phy/spi_ks8995.c.

Thanks,
Stefan

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