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: Wed, 4 Apr 2018 15:00:48 +0800 From: Chen-Yu Tsai <wens@...e.org> To: Icenowy Zheng <icenowy@...c.io> Cc: Maxime Ripard <maxime.ripard@...tlin.com>, Mark Rutland <mark.rutland@....com>, devicetree <devicetree@...r.kernel.org>, Stephen Boyd <sboyd@...nel.org>, netdev <netdev@...r.kernel.org>, Michael Turquette <mturquette@...libre.com>, Rob Herring <robh+dt@...nel.org>, Corentin Labbe <clabbe.montjoie@...il.com>, Mark Brown <broonie@...nel.org>, Giuseppe Cavallaro <peppe.cavallaro@...com>, linux-clk <linux-clk@...r.kernel.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH net-next 02/12] clk: sunxi-ng: r40: export a regmap to access the GMAC register On Wed, Apr 4, 2018 at 2:45 PM, Icenowy Zheng <icenowy@...c.io> wrote: > 在 2018-04-03二的 11:50 +0200,Maxime Ripard写道: >> On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote: >> > On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote: >> > > On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard >> > > <maxime.ripard@...tlin.com> wrote: >> > > > On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu Tsai wrote: >> > > > > From: Icenowy Zheng <icenowy@...c.io> >> > > > > >> > > > > There's a GMAC configuration register, which exists on >> > > > > A64/A83T/H3/H5 in >> > > > > the syscon part, in the CCU of R40 SoC. >> > > > > >> > > > > Export a regmap of the CCU. >> > > > > >> > > > > Read access is not restricted to all registers, but only the >> > > > > GMAC >> > > > > register is allowed to be written. >> > > > > >> > > > > Signed-off-by: Icenowy Zheng <icenowy@...c.io> >> > > > > Signed-off-by: Chen-Yu Tsai <wens@...e.org> >> > > > >> > > > Gah, this is crazy. I'm really starting to regret letting that >> > > > syscon >> > > > in in the first place... >> > > >> > > IMHO syscon is really a better fit. It's part of the glue layer >> > > and >> > > most other dwmac user platforms treat it as such and use a >> > > syscon. >> > > Plus the controls encompass delays (phase), inverters (polarity), >> > > and even signal routing. It's not really just a group of clock >> > > controls, >> > > like what we poorly modeled for A20/A31. I think that was really >> > > a >> > > mistake. >> > > >> > > As I mentioned in the cover letter, a slightly saner approach >> > > would >> > > be to let drivers add custom syscon entries, which would then >> > > require >> > > less custom plumbing. >> > >> > A syscon is convenient, sure, but it also bypasses any abstraction >> > layer we have everywhere else, which means that we'll have to >> > maintain >> > the register layout in each and every driver that uses it. >> > >> > So far, it's only be the GMAC, but it can also be others (the SRAM >> > controller comes to my mind), and then, if there's any difference >> > in >> > the design in a future SoC, we'll have to maintain that in the GMAC >> > driver as well. >> >> I guess I forgot to say something, I'm fine with using a syscon we >> already have. > > As we finally need the SRAM controller on these new SoCs (for VE on all > SoCs targeted by dwmac-sun8i, and for DE on A64), should we deprecate > the syscon and all switch to device regmap (and let sunxi-dram driver > to export a regmap)? (As in the A64 DE2 thread discussed, two device > nodes shouldn't cover the same MMIO region.) Sounds like a plan. > In addition, there might be multiple registers in the syscon/sram zone > that are needed (for example, if a version driver is written, it will > need the "0x24 Version Register"; and GMAC needs "0x30 EMAC Clock > Register"). How to deal with this if we export the syscon/sram zone as > a generic device regmap? You can have multiple regmaps for a device. And the API allows you to request them up by name. ChenYu >> >> I'm just questionning if merging any other driver using one is the >> right move. >> >> Maxime >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@...ts.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Powered by blists - more mailing lists