linux-kernel - Re: [RFC PATCH v1] Revert "pwm: Clear chip_data in pwm

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]

Date:   Tue, 7 Mar 2023 22:27:44 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     George Stark <gnstark@...rdevices.ru>
Cc:     thierry.reding@...il.com, krzysztof.kozlowski@...aro.org,
        alim.akhtar@...sung.com, linux-pwm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, kernel@...rdevices.ru
Subject: Re: [RFC PATCH v1] Revert "pwm: Clear chip_data in pwm_put()"

Hello George,

On Wed, Mar 08, 2023 at 12:00:14AM +0300, George Stark wrote:
> From: George Stark <GNStark@...rdevices.ru>
> 
> This reverts commit e926b12c611c2095c7976e2ed31753ad6eb5ff1a.
> 
> There're several issues with the original change:
> 
> - it breaks generic semantics of set_driver_data-like routines that
> only client code controls lifetime of it's own data.
> 
> - it breaks pwm-sti.c driver: pwm_set_chip_data is used only in probe stage
> then pwm_get_chip_data used in capture callback

pwm-sti is also broken in other regards. pwm_set_chip_data() is only
called after pwmchip_add(). But as soon as pwmchip_add() is called, the
callbacks (e.g. capture) might be called. Then the call to
pwm_set_chip_data() might be too late.

> Change-Id: I5787c6b4c520d4a0997567c416b26fa4e0806b94

Please don't add a Change-Id footer for Linux submissions.

If you ask me, better drop pwm_set_chip_data() completely. It adds no
useful value. It's just a variant of driver data and using both
complicates the driver and probably fragments memory allocations. Also
the sematic of driver data is better known as it's the same for all
subsystems.

Do you use the capture functionality? In my eyes the capture part of the
pwm subsystem is very alien. Only a small subset of the hardware
supports this and the counter framework should be better suited for such
tasks.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)