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: Mon, 7 Oct 2019 21:53:20 +0200 From: Martin Blumenstingl <martin.blumenstingl@...glemail.com> To: Philipp Zabel <pza@...gutronix.de> Cc: Dilip Kota <eswara.kota@...ux.intel.com>, "Chuan Hua, Lei" <chuanhua.lei@...ux.intel.com>, cheol.yong.kim@...el.com, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, qi-ming.wu@...el.com, robh@...nel.org, Hauke Mehrtens <hauke@...ke-m.de> Subject: Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC Hi Philipp, On Thu, Oct 3, 2019 at 4:19 PM Philipp Zabel <pza@...gutronix.de> wrote: [...] > > because the register layout was greatly simplified for the newer SoCs > > (for which there is reset-intel) compared to the older ones > > (reset-lantiq). > > Dilip's suggestion (in my own words) is that you take his new > > reset-intel driver, then we will work on porting reset-lantiq over to > > that so in the end we can drop the reset-lantiq driver. > > Just to be sure, you are suggesting to add support for the current > lantiq,reset binding to the reset-intel driver at a later point? I > see no reason not to do that, but I'm also not quite sure what the > benefit will be over just keeping reset-lantiq as is? according to Chuan and Dilip the current reset-lantiq implementation is wrong [0]. my understanding is that the Lantiq and Intel LGM reset controllers are identical except: - the Lantiq variant uses a weird register layout (reset and status registers not at consecutive offsets) - the bits of the reset and status registers sometimes don't match on the Lantiq variant - the Intel variant has a dedicated registers area for the reset controller registers, while the Lantiq variant mixes them with various other functionality (for example: USB2 PHYs) > > This approach means more work for me (as I am probably the one who > > then has to do the work to port reset-lantiq over to reset-intel). > > More work than what alternative? compared to "fixing" the existing reset-lantiq driver (reset callback) and then (instead of adding a new driver) integrating Intel LGM support into reset-lantiq > > I'm happy to do that work if you think that it's worth following this > > approach. So I want your opinion on this before I spend any effort on > > porting reset-lantiq over to reset-intel. > > Reset drivers are typically so simple, I'm not quite sure whether it is > worth to integrate multiple drivers if it complicates matters too much. > In this case though I expect it would just be adding support for a > custom .of_xlate and lantiq specific register property parsing? yes, that's how I understand the Lantiq and Intel reset controllers: - reset/status/assert/deassert callbacks would be shared across all variants - register parsing and of_xlate are SoC specific Martin [0] https://www.spinics.net/lists/devicetree/msg305951.html
Powered by blists - more mailing lists