linux-kernel - Re: [PATCH v1 2/2] pwm: Add the S32G support in the Freescale FTM 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] [day] [month] [year] [list]

Message-ID: <a2fec7ae-7f5e-4440-8623-41e89433b7a7@linaro.org>
Date: Mon, 11 Aug 2025 23:20:50 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 Frank.Li@....com, linux-pwm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Ghennadi.Procopciuc@....com, s32@....com
Subject: Re: [PATCH v1 2/2] pwm: Add the S32G support in the Freescale FTM
 driver

On 11/08/2025 23:11, Uwe Kleine-König wrote:
> Hello Daniel,
> 
> On Mon, Aug 11, 2025 at 11:44:32AM +0200, Daniel Lezcano wrote:
>> On 11/08/2025 07:18, Uwe Kleine-König wrote:
>>> All variants (up to now) have .has_fltctrl == .has_fltpol. Is there a
>>> good reason that justifies two bools for the register description?
>>
>> Yeah, I agree it can be folded into a single has_flt_reg boolean. I can only
>> guess that was done with the idea of sticking to the reference manual and
>> perhaps having more variant to come with, eg.,  fltctrl=false and
>> fltpol=true
>>
>> Do you want me to merge these boolean ?
> 
> That's the obvious thing to do if you want the new variant supported :-)
> 
> Unless you know that there is such a variant with .has_fltctrl !=
> .has_fltpol to appear soon, I prefer the simplified handling with only
> one bool.
> 
>>> Also I wonder about the fuss given that the two registers are not used
>>> in the PWM driver. So this is only to prevent reading these registers
>>> via regmap debug stuff? What happens if the memory locations are read
>>> where the other implementations have these registers?
>>
>> The problem arises at resume time.
>>
>> 	/* restore all registers from cache */
>>          clk_prepare(fpc->ipg_clk);
>> 	regcache_cache_only(fpc->regmap, false);
>>          regcache_sync(fpc->regmap);
>>
>> Without skipping these registers, the kernel crashes on s32g2/3
> 
> That's a useful information for the commit log.

Ok, thanks, I'll do the changes accordingly


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog