linux-kernel - Re: [PATCH] ethernet: atheros: Add nss-gmac driver

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: <1753817.oBE21Kj2o0@wuerfel>
Date:	Thu, 22 Jan 2015 11:18:50 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	wstephen@...eaurora.org
Cc:	jcliburn@...il.com, grant.likely@...aro.org, robh+dt@...nel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH] ethernet: atheros: Add nss-gmac driver

On Thursday 22 January 2015 00:20:59 wstephen@...eaurora.org wrote:
> > Right. For review purposes, I think it would be helpful to split this
> > huge patch into several steps then:
> >
> > - add a base driver
> > - add the overlay interface
> > - add the nss driver
> >
> > Ideally more of them.
> 
> The nss-drv driver is open sourced but we are currently not planning to
> upstream to linux kernel yet because we are still actively adding new
> features
> https://www.codeaurora.org/cgit/quic/qsdk/oss/lklm/nss-drv
> 
> > Thanks for the description, this sounds very interesting indeed. I do
> > have more questions though: how do you get the rules into the NSS driver?
> > Does this get handled transparently by the openvswitch driver or
> > did you have to add new user interfaces for it?
> >
> 
> No, we are not using openvswitch. We have a connection manager monitoring
> conntrack events and creates rules then send it through the interface
> built in nss-drv.
> 

I see. In this case, I think merging your new driver is not a good idea:

- We already have a driver (dwmac1000) for the ethernet hardware,
  which is known to work on a lot of hardware and has an established
  binding.

- The main difference in your new driver is the plug-in interface,
  but that has no upstream users

- The nss driver is not getting submitted, and has little chance of
  getting merged if you do, because it introduces a driver-specific
  API for something that should be hardware independent.

You can simplify your private nss code a lot if you remove the
abstraction layer and only implement ethernet features you need
in the same module, and then load either the upstream driver or
your nss driver. Make sure they use a compatible binding so the
device gets attached to just one of the two drivers. For the
built-in case, you can use the 'unbind' interface from user space
to remove the device from the dwmac1000 driver.

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