The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
Cc: stable@vger.kernel.org # 6.10.y Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com --- Hi,
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
soundwire sdw-master-0-1: Program transport params failed: -22 soundwire sdw-master-0-1: Program params failed: -22 SDW1-Playback: ASoC: error at snd_soc_link_prepare on SDW1-Playback: -22
Regards, Peter
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 00191b1d2260..4e9e7d2a942d 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1286,18 +1286,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, unsigned int port_num) { struct sdw_dpn_prop *dpn_prop; - unsigned long mask; + u8 num_ports; int i;
if (direction == SDW_DATA_DIR_TX) { - mask = slave->prop.source_ports; + num_ports = hweight32(slave->prop.source_ports); dpn_prop = slave->prop.src_dpn_prop; } else { - mask = slave->prop.sink_ports; + num_ports = hweight32(slave->prop.sink_ports); dpn_prop = slave->prop.sink_dpn_prop; }
- for_each_set_bit(i, &mask, 32) { + for (i = 0; i < num_ports; i++) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; }
Hi,
On 10/09/2024 15:40, Peter Ujfalusi wrote:
The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
I just noticed that Krzysztof already sent the revert patch but it is not picked up for stable-6.10.y
https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@lin...
Cc: stable@vger.kernel.org # 6.10.y Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
Hi,
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
soundwire sdw-master-0-1: Program transport params failed: -22 soundwire sdw-master-0-1: Program params failed: -22 SDW1-Playback: ASoC: error at snd_soc_link_prepare on SDW1-Playback: -22
Regards, Peter
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 00191b1d2260..4e9e7d2a942d 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1286,18 +1286,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, unsigned int port_num) { struct sdw_dpn_prop *dpn_prop;
- unsigned long mask;
- u8 num_ports; int i;
if (direction == SDW_DATA_DIR_TX) {
mask = slave->prop.source_ports;
dpn_prop = slave->prop.src_dpn_prop; } else {num_ports = hweight32(slave->prop.source_ports);
mask = slave->prop.sink_ports;
dpn_prop = slave->prop.sink_dpn_prop; }num_ports = hweight32(slave->prop.sink_ports);
- for_each_set_bit(i, &mask, 32) {
- for (i = 0; i < num_ports; i++) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; }
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
Hi,
On 10/09/2024 15:40, Peter Ujfalusi wrote:
The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
I just noticed that Krzysztof already sent the revert patch but it is not picked up for stable-6.10.y
https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@lin...
Is this in Linus's tree yet? That's what we are waiting for.
Cc: stable@vger.kernel.org # 6.10.y Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
Hi,
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
Really? Commit ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") is in Linus's tree, why isn't it being reverted there first?
confused,
greg k-h
On 11.09.24 14:31, Greg KH wrote:
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
Really? Commit ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") is in Linus's tree, why isn't it being reverted there first?
FWIW, the revert should land in mainline tomorrow afaics: https://lore.kernel.org/all/ZuFcBcJztAgicjNt@vaman/
BTW, in case anyone cares: I think this is another report about the problem, this time with 6.6.y: https://bugzilla.kernel.org/show_bug.cgi?id=219256
Ciao, Thorsten
On 11-09-24, 16:31, Linux regression tracking (Thorsten Leemhuis) wrote:
On 11.09.24 14:31, Greg KH wrote:
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
Really? Commit ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") is in Linus's tree, why isn't it being reverted there first?
FWIW, the revert should land in mainline tomorrow afaics: https://lore.kernel.org/all/ZuFcBcJztAgicjNt@vaman/
BTW, in case anyone cares: I think this is another report about the problem, this time with 6.6.y: https://bugzilla.kernel.org/show_bug.cgi?id=219256
Revert has been applied to 6.6 and other stable kernel so this should be fixed now
On 11-09-24, 14:31, Greg KH wrote:
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
Hi,
On 10/09/2024 15:40, Peter Ujfalusi wrote:
The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
I just noticed that Krzysztof already sent the revert patch but it is not picked up for stable-6.10.y
https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@lin...
Is this in Linus's tree yet? That's what we are waiting for.
Yes I was waiting for that as well, the pull request has been sent to Linus, this should be in his tree, hopefully tomorow..
Cc: stable@vger.kernel.org # 6.10.y Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
Hi,
The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next.
Really? Commit ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") is in Linus's tree, why isn't it being reverted there first?
I guess Peter jumped the gun, I was planning to ask you once this is picked up Linus
On 13-09-24, 17:21, Vinod Koul wrote:
On 11-09-24, 14:31, Greg KH wrote:
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
Hi,
On 10/09/2024 15:40, Peter Ujfalusi wrote:
The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
I just noticed that Krzysztof already sent the revert patch but it is not picked up for stable-6.10.y
https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@lin...
Is this in Linus's tree yet? That's what we are waiting for.
Yes I was waiting for that as well, the pull request has been sent to Linus, this should be in his tree, hopefully tomorow..
It is in Linus's tree now. Greg would you like to drop commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3 or carry it and the revert...?
What is the usual process for you to handle reverts?
On Sun, Sep 15, 2024 at 12:45:25AM +0530, Vinod Koul wrote:
On 13-09-24, 17:21, Vinod Koul wrote:
On 11-09-24, 14:31, Greg KH wrote:
On Tue, Sep 10, 2024 at 04:02:29PM +0300, Péter Ujfalusi wrote:
Hi,
On 10/09/2024 15:40, Peter Ujfalusi wrote:
The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based.
The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct.
For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory.
This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3.
I just noticed that Krzysztof already sent the revert patch but it is not picked up for stable-6.10.y
https://lore.kernel.org/lkml/20240909164746.136629-1-krzysztof.kozlowski@lin...
Is this in Linus's tree yet? That's what we are waiting for.
Yes I was waiting for that as well, the pull request has been sent to Linus, this should be in his tree, hopefully tomorow..
It is in Linus's tree now. Greg would you like to drop commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3 or carry it and the revert...?
I can not "drop" a commit that is already in a realease for obvious reasons :(
What is the usual process for you to handle reverts?
We just take them like normal. What is the git id of the revert in Linus's tree?
thanks,
greg k-h
On 15-09-24, 15:23, Greg KH wrote:
On Sun, Sep 15, 2024 at 12:45:25AM +0530, Vinod Koul wrote:
Is this in Linus's tree yet? That's what we are waiting for.
Yes I was waiting for that as well, the pull request has been sent to Linus, this should be in his tree, hopefully tomorow..
It is in Linus's tree now. Greg would you like to drop commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3 or carry it and the revert...?
I can not "drop" a commit that is already in a realease for obvious reasons :(
What is the usual process for you to handle reverts?
We just take them like normal. What is the git id of the revert in Linus's tree?
Sure, makes sense. It has been auto-picked so this is fine.
fwiw: ab8d66d132bc: soundwire: stream: fix programming slave ports for non-continous port maps
Thanks
linux-stable-mirror@lists.linaro.org