[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba9928dc-2701-4e6e-a8b2-73a5484f75b0@linux.dev>
Date: Mon, 12 Jan 2026 11:44:27 +0000
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org
Cc: Donald Hunter <donald.hunter@...il.com>, Jakub Kicinski
<kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
Jiri Pirko <jiri@...nulli.us>,
Prathosh Satish <Prathosh.Satish@...rochip.com>, Petr Oros
<poros@...hat.com>, linux-kernel@...r.kernel.org,
Michal Schmidt <mschmidt@...hat.com>
Subject: Re: [PATCH net-next 1/3] dpll: add dpll_device op to get supported
modes
On 12/01/2026 10:14, Ivan Vecera wrote:
> Currently, the DPLL subsystem assumes that the only supported mode is
> the one currently active on the device. When dpll_msg_add_mode_supported()
> is called, it relies on ops->mode_get() and reports that single mode
> to userspace. This prevents users from discovering other modes the device
> might be capable of.
>
> Add a new callback .supported_modes_get() to struct dpll_device_ops. This
> allows drivers to populate a bitmap indicating all modes supported by
> the hardware.
>
> Update dpll_msg_add_mode_supported() to utilize this new callback:
>
> * if ops->supported_modes_get is defined, use it to retrieve the full
> bitmap of supported modes.
> * if not defined, fall back to the existing behavior: retrieve
> the current mode via ops->mode_get and set the corresponding bit
> in the bitmap.
>
> Finally, iterate over the bitmap and add a DPLL_A_MODE_SUPPORTED netlink
> attribute for every set bit, accurately reporting the device's capabilities
> to userspace.
>
> Signed-off-by: Ivan Vecera <ivecera@...hat.com>
LGTM,
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Powered by blists - more mailing lists