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
| ||
|
Date: Tue, 7 Apr 2015 17:16:55 +0000 From: James Hartley <James.Hartley@...tec.com> To: Andrew Bresticker <abrestic@...omium.org>, Arnd Bergmann <arnd@...db.de> CC: "David S. Miller" <davem@...emloft.net>, Giuseppe Cavallaro <peppe.cavallaro@...com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Govindraj Raja <Govindraj.Raja@...tec.com>, Damien Horsley <Damien.Horsley@...tec.com> Subject: RE: [PATCH V2 2/2] stmmac: Add IMG Pistachio platform glue layer > -----Original Message----- > From: abrestic@...gle.com [mailto:abrestic@...gle.com] On Behalf Of > Andrew Bresticker > Sent: 06 April 2015 23:28 > To: Arnd Bergmann; James Hartley > Cc: David S. Miller; Giuseppe Cavallaro; devicetree@...r.kernel.org; > netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Govindraj Raja > Subject: Re: [PATCH V2 2/2] stmmac: Add IMG Pistachio platform glue layer > > On Mon, Apr 6, 2015 at 3:10 PM, Arnd Bergmann <arnd@...db.de> wrote: > > On Monday 06 April 2015 14:42:38 Andrew Bresticker wrote: > >> At the moment, the only additional setup required for the DWMAC on > >> the IMG Pistachio SoC is to request and enable a separate gate clock > >> for the register interface. > >> > >> Signed-off-by: Andrew Bresticker <abrestic@...omium.org> > >> Signed-off-by: Govindraj Raja <govindraj.raja@...tec.com> > >> Cc: James Hartley <james.hartley@...tec.com> > > > > Why do you need a special glue driver for that? > > > > Since you don't do anything special, I'd say it should be possible to > > handle this with just the default driver. > > Right, at the moment we only need to request and enable a second clock, > which could be added to the core driver. If we don't expect to have to > extend this driver to deal with other configurations (which IIRC there were > some concerns about when I wrote this), then I'm fine with folding this change > into the core driver - James? Weren't the concerns about USB not Ethernet? I don't remember anything that would stop us extending the driver for eth. > > Thanks, > Andrew James.
Powered by blists - more mailing lists