From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Vinod Koul <vkoul@kernel.org>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
Sanyog Kale <sanyog.r.kale@intel.com>,
Shreyas NC <shreyas.nc@intel.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] soundwire: stream: fix programming slave ports for non-continous port maps
Date: Mon, 29 Jul 2024 16:25:28 +0200 [thread overview]
Message-ID: <095d7119-8221-450a-9616-2df6a0df4c77@linux.intel.com> (raw)
In-Reply-To: <20240729140157.326450-1-krzysztof.kozlowski@linaro.org>
On 7/29/24 16:01, Krzysztof Kozlowski wrote:
> Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and
> 'sink_ports' - define which ports to program in
> sdw_program_slave_port_params(). The masks are used to get the
> appropriate data port properties ('struct sdw_get_slave_dpn_prop') from
> an array.
>
> Bitmasks can be non-continuous or can start from index different than 0,
> thus when looking for matching port property for given port, we must
> iterate over mask bits, not from 0 up to number of ports.
>
> This fixes allocation and programming slave ports, when a source or sink
> masks start from further index.
>
> Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
This is a valid change to optimize how the port are accessed.
But the commit message is not completely clear, the allocation in
mipi_disco.c is not modified and I don't think there's anything that
would crash. If there are non-contiguous ports, we will still allocate
space that will not be initialized/used.
/* Allocate memory for set bits in port lists */
nval = hweight32(prop->source_ports);
prop->src_dpn_prop = devm_kcalloc(&slave->dev, nval,
sizeof(*prop->src_dpn_prop),
GFP_KERNEL);
if (!prop->src_dpn_prop)
return -ENOMEM;
/* Read dpn properties for source port(s) */
sdw_slave_read_dpn(slave, prop->src_dpn_prop, nval,
prop->source_ports, "source");
IOW, this is a valid change, but it's an optimization, not a fix in the
usual sense of 'kernel oops otherwise'.
Am I missing something?
BTW, the notion of DPn is that n > 0. DP0 is a special case with
different properties, BIT(0) cannot be set for either of the sink/source
port bitmask.
> ---
> drivers/soundwire/stream.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
> index 7aa4900dcf31..f275143d7b18 100644
> --- a/drivers/soundwire/stream.c
> +++ b/drivers/soundwire/stream.c
> @@ -1291,18 +1291,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave,
> unsigned int port_num)
> {
> struct sdw_dpn_prop *dpn_prop;
> - u8 num_ports;
> + unsigned long mask;
> int i;
>
> if (direction == SDW_DATA_DIR_TX) {
> - num_ports = hweight32(slave->prop.source_ports);
> + mask = slave->prop.source_ports;
> dpn_prop = slave->prop.src_dpn_prop;
> } else {
> - num_ports = hweight32(slave->prop.sink_ports);
> + mask = slave->prop.sink_ports;
> dpn_prop = slave->prop.sink_dpn_prop;
> }
>
> - for (i = 0; i < num_ports; i++) {
> + for_each_set_bit(i, &mask, 32) {
> if (dpn_prop[i].num == port_num)
> return &dpn_prop[i];
> }
next prev parent reply other threads:[~2024-07-29 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 14:01 [PATCH] soundwire: stream: fix programming slave ports for non-continous port maps Krzysztof Kozlowski
2024-07-29 14:25 ` Pierre-Louis Bossart [this message]
2024-07-30 8:23 ` Krzysztof Kozlowski
2024-07-30 8:39 ` Krzysztof Kozlowski
2024-07-30 8:59 ` Pierre-Louis Bossart
2024-07-30 9:19 ` Krzysztof Kozlowski
2024-07-30 9:28 ` Pierre-Louis Bossart
2024-07-30 9:29 ` Krzysztof Kozlowski
2024-07-30 9:43 ` Pierre-Louis Bossart
2024-07-31 6:56 ` Vinod Koul
2024-09-03 7:34 ` Liao, Bard
2024-09-03 12:50 ` Krzysztof Kozlowski
2024-09-03 15:17 ` Liao, Bard
2024-09-04 11:43 ` Krzysztof Kozlowski
2024-09-09 14:34 ` Charles Keepax
2024-08-18 7:28 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=095d7119-8221-450a-9616-2df6a0df4c77@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sanyog.r.kale@intel.com \
--cc=shreyas.nc@intel.com \
--cc=stable@vger.kernel.org \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.