linux-kernel - Re: [PATCH] Add COUNTER_FUNCTION

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: <538f5d83-1a16-4df5-8dbe-4c6d556e1058@lechnology.com>
Date: Wed, 27 Nov 2024 16:49:52 -0600
From: David Lechner <david@...hnology.com>
To: "Rafael V. Volkmer" <rafael.v.volkmer@...il.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, wbg@...nel.org
Subject: Re: [PATCH] Add COUNTER_FUNCTION_DISABLE to the counter API

On 11/27/24 3:54 PM, Rafael V. Volkmer wrote:
> On 11/25/24 11:36 AM, David Lechner wrote:
>> How does this work without an additional patch to modify the TI eQEP
>> counter driver to handle this new enum value? For example, I would
>> expect that this enum value would be added to ti_eqep_position_functions
>> and case statements added in ti_eqep_function_read(),
>> ti_eqep_function_write() and ti_eqep_action_read() to handle the new
>> option.
> 
> Hi, David!
> 
> Yes, the intention is to have a second path where the eQEP driver handles 
> this within these file operations functions.
> 
> Best regards

OK, so please send those patches too so that we can see the whole picture.

Based on your discussion with William, it sounds like there are 2 things
that need to be resolved.

1. Should a power saving mode actually be a counter function or should it
   be controlled by the counter enable attribute or something else, like
   more general Linux power management stuff?
2. If there are going to be in-kernel users calling these functions, then
   we will likely want to introduce some new APIs in the kernel for this.
   Using platform_get_drvdata() from one driver to another is a bit
   fragile. Likely we will want some devicetree bindings for counter
   consumers and providers and some kernel APIs like a counter_get() that
   takes an index or string ID to get the counter provider assigned to a
   counter consumer. Then we will probably want some wrappers around the
   counter ops pointers so that consumer drivers don't have to depend on
   the internal implementation of the counter subsystem.