* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
@ 2023-12-11 21:15 ` Florian Fainelli
2023-12-12 0:26 ` Kelsey Steele
` (9 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2023-12-11 21:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor, allen.lkml
On 12/11/23 10:19, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
2023-12-11 21:15 ` Florian Fainelli
@ 2023-12-12 0:26 ` Kelsey Steele
2023-12-12 13:21 ` Naresh Kamboju
` (8 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Kelsey Steele @ 2023-12-12 0:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
On Mon, Dec 11, 2023 at 07:19:50PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
No regressions found on WSL (x86 and arm64).
Built, booted, and reviewed dmesg.
Thank you.
Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
2023-12-11 21:15 ` Florian Fainelli
2023-12-12 0:26 ` Kelsey Steele
@ 2023-12-12 13:21 ` Naresh Kamboju
2023-12-12 14:02 ` Conor Dooley
` (7 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Naresh Kamboju @ 2023-12-12 13:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
On Tue, 12 Dec 2023 at 00:15, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 6.1.68-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.1.y
* git commit: 807435a379b45e6eec975857b7daf5ac2b3fbf93
* git describe: v6.1.67-195-g807435a379b4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.67-195-g807435a379b4
## Test Regressions (compared to v6.1.66)
## Metric Regressions (compared to v6.1.66)
## Test Fixes (compared to v6.1.66)
## Metric Fixes (compared to v6.1.66)
## Test result summary
total: 136008, pass: 114767, fail: 2850, skip: 18250, xfail: 141
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 151 total, 150 passed, 1 failed
* arm64: 52 total, 52 passed, 0 failed
* i386: 38 total, 38 passed, 0 failed
* mips: 26 total, 26 passed, 0 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 35 total, 35 passed, 0 failed
* riscv: 15 total, 15 passed, 0 failed
* s390: 16 total, 16 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 46 total, 46 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* v4l2-complianciance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2023-12-12 13:21 ` Naresh Kamboju
@ 2023-12-12 14:02 ` Conor Dooley
2023-12-12 16:12 ` Shuah Khan
` (6 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Conor Dooley @ 2023-12-12 14:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
On Mon, Dec 11, 2023 at 07:19:50PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2023-12-12 14:02 ` Conor Dooley
@ 2023-12-12 16:12 ` Shuah Khan
2023-12-12 17:34 ` Guenter Roeck
` (5 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Shuah Khan @ 2023-12-12 16:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml, Shuah Khan
On 12/11/23 11:19, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2023-12-12 16:12 ` Shuah Khan
@ 2023-12-12 17:34 ` Guenter Roeck
2023-12-12 19:08 ` Pavel Machek
` (4 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Guenter Roeck @ 2023-12-12 17:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On Mon, Dec 11, 2023 at 07:19:50PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 545 pass: 545 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2023-12-12 17:34 ` Guenter Roeck
@ 2023-12-12 19:08 ` Pavel Machek
2023-12-12 20:08 ` RTL8152_INACCESSIBLE was " Pavel Machek
` (3 subsequent siblings)
10 siblings, 0 replies; 18+ messages in thread
From: Pavel Machek @ 2023-12-12 19:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Hi!
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2023-12-12 19:08 ` Pavel Machek
@ 2023-12-12 20:08 ` Pavel Machek
2023-12-12 20:48 ` Guenter Roeck
2023-12-12 21:57 ` Ron Economos
` (2 subsequent siblings)
10 siblings, 1 reply; 18+ messages in thread
From: Pavel Machek @ 2023-12-12 20:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, dianders, grundler, davem
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
Hi!
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
> Douglas Anderson <dianders@chromium.org>
> r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
>
> Douglas Anderson <dianders@chromium.org>
> r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
>
> Douglas Anderson <dianders@chromium.org>
> r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
>
> Douglas Anderson <dianders@chromium.org>
> r8152: Add RTL8152_INACCESSIBLE checks to more loops
>
> Douglas Anderson <dianders@chromium.org>
> r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
Central patch that actually fixes something is:
commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Oct 20 14:06:59 2023 -0700
r8152: Block future register access if register access fails
...but we don't have that in 6.1. So we should not need the rest,
either.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-12 20:08 ` RTL8152_INACCESSIBLE was " Pavel Machek
@ 2023-12-12 20:48 ` Guenter Roeck
2023-12-13 7:52 ` Pavel Machek
0 siblings, 1 reply; 18+ messages in thread
From: Guenter Roeck @ 2023-12-12 20:48 UTC (permalink / raw)
To: Pavel Machek, Greg Kroah-Hartman, dianders, grundler, davem
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On 12/12/23 12:08, Pavel Machek wrote:
> Hi!
>
>> This is the start of the stable review cycle for the 6.1.68 release.
>> There are 194 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>
>
>> Douglas Anderson <dianders@chromium.org>
>> r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
>>
>> Douglas Anderson <dianders@chromium.org>
>> r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
>>
>> Douglas Anderson <dianders@chromium.org>
>> r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
>>
>> Douglas Anderson <dianders@chromium.org>
>> r8152: Add RTL8152_INACCESSIBLE checks to more loops
>>
>> Douglas Anderson <dianders@chromium.org>
>> r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
>
> Central patch that actually fixes something is:
>
> commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> Author: Douglas Anderson <dianders@chromium.org>
> Date: Fri Oct 20 14:06:59 2023 -0700
>
> r8152: Block future register access if register access fails
>
> ...but we don't have that in 6.1. So we should not need the rest,
> either.
>
Also, the missing patch is fixed subsequently by another patch, so it can not
be added on its own.
Guenter
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-12 20:48 ` Guenter Roeck
@ 2023-12-13 7:52 ` Pavel Machek
2023-12-13 8:50 ` Greg Kroah-Hartman
0 siblings, 1 reply; 18+ messages in thread
From: Pavel Machek @ 2023-12-13 7:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Pavel Machek, Greg Kroah-Hartman, dianders, grundler, davem,
stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
Hi!
> > > This is the start of the stable review cycle for the 6.1.68 release.
> > > There are 194 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> >
> >
> > > Douglas Anderson <dianders@chromium.org>
> > > r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
> > >
> > > Douglas Anderson <dianders@chromium.org>
> > > r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
> > >
> > > Douglas Anderson <dianders@chromium.org>
> > > r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
> > >
> > > Douglas Anderson <dianders@chromium.org>
> > > r8152: Add RTL8152_INACCESSIBLE checks to more loops
> > >
> > > Douglas Anderson <dianders@chromium.org>
> > > r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
> >
> > Central patch that actually fixes something is:
> >
> > commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> > Author: Douglas Anderson <dianders@chromium.org>
> > Date: Fri Oct 20 14:06:59 2023 -0700
> >
> > r8152: Block future register access if register access fails
> >
> > ...but we don't have that in 6.1. So we should not need the rest,
> > either.
> >
>
> Also, the missing patch is fixed subsequently by another patch, so it can not
> be added on its own.
For the record I'm trying to advocate "drop all patches listed as they
don't fix the bug", not "add more", as this does not meet stable
criteria.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-13 7:52 ` Pavel Machek
@ 2023-12-13 8:50 ` Greg Kroah-Hartman
2023-12-13 15:16 ` Doug Anderson
0 siblings, 1 reply; 18+ messages in thread
From: Greg Kroah-Hartman @ 2023-12-13 8:50 UTC (permalink / raw)
To: Pavel Machek
Cc: Guenter Roeck, dianders, grundler, davem, stable, patches,
linux-kernel, torvalds, akpm, shuah, patches, lkft-triage,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
allen.lkml
On Wed, Dec 13, 2023 at 08:52:25AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > This is the start of the stable review cycle for the 6.1.68 release.
> > > > There are 194 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > >
> > >
> > > > Douglas Anderson <dianders@chromium.org>
> > > > r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
> > > >
> > > > Douglas Anderson <dianders@chromium.org>
> > > > r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
> > > >
> > > > Douglas Anderson <dianders@chromium.org>
> > > > r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
> > > >
> > > > Douglas Anderson <dianders@chromium.org>
> > > > r8152: Add RTL8152_INACCESSIBLE checks to more loops
> > > >
> > > > Douglas Anderson <dianders@chromium.org>
> > > > r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
> > >
> > > Central patch that actually fixes something is:
> > >
> > > commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> > > Author: Douglas Anderson <dianders@chromium.org>
> > > Date: Fri Oct 20 14:06:59 2023 -0700
> > >
> > > r8152: Block future register access if register access fails
> > >
> > > ...but we don't have that in 6.1. So we should not need the rest,
> > > either.
> > >
> >
> > Also, the missing patch is fixed subsequently by another patch, so it can not
> > be added on its own.
>
> For the record I'm trying to advocate "drop all patches listed as they
> don't fix the bug", not "add more", as this does not meet stable
> criteria.
But the original commit here does say it fixes a bug, see the text of
the commits listed above. So perhaps someone got this all wrong when
they wrote the original commits that got merged into 6.7-rc? Otherwise
this seems like they are sane to keep for now, unless the original
author says they should be dropped, or someone who can test this driver
says something went wrong.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-13 8:50 ` Greg Kroah-Hartman
@ 2023-12-13 15:16 ` Doug Anderson
2023-12-13 17:37 ` Greg Kroah-Hartman
0 siblings, 1 reply; 18+ messages in thread
From: Doug Anderson @ 2023-12-13 15:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pavel Machek, Guenter Roeck, grundler, davem, stable, patches,
linux-kernel, torvalds, akpm, shuah, patches, lkft-triage,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
allen.lkml
Hi,
On Wed, Dec 13, 2023 at 12:50 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Dec 13, 2023 at 08:52:25AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > This is the start of the stable review cycle for the 6.1.68 release.
> > > > > There are 194 patches in this series, all will be posted as a response
> > > > > to this one. If anyone has any issues with these being applied, please
> > > > > let me know.
> > > >
> > > >
> > > > > Douglas Anderson <dianders@chromium.org>
> > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
> > > > >
> > > > > Douglas Anderson <dianders@chromium.org>
> > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
> > > > >
> > > > > Douglas Anderson <dianders@chromium.org>
> > > > > r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
> > > > >
> > > > > Douglas Anderson <dianders@chromium.org>
> > > > > r8152: Add RTL8152_INACCESSIBLE checks to more loops
> > > > >
> > > > > Douglas Anderson <dianders@chromium.org>
> > > > > r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
> > > >
> > > > Central patch that actually fixes something is:
> > > >
> > > > commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> > > > Author: Douglas Anderson <dianders@chromium.org>
> > > > Date: Fri Oct 20 14:06:59 2023 -0700
> > > >
> > > > r8152: Block future register access if register access fails
> > > >
> > > > ...but we don't have that in 6.1. So we should not need the rest,
> > > > either.
> > > >
> > >
> > > Also, the missing patch is fixed subsequently by another patch, so it can not
> > > be added on its own.
> >
> > For the record I'm trying to advocate "drop all patches listed as they
> > don't fix the bug", not "add more", as this does not meet stable
> > criteria.
>
> But the original commit here does say it fixes a bug, see the text of
> the commits listed above. So perhaps someone got this all wrong when
> they wrote the original commits that got merged into 6.7-rc? Otherwise
> this seems like they are sane to keep for now, unless the original
> author says they should be dropped, or someone who can test this driver
> says something went wrong.
Right. The patches that "add RTL8152_INACCESSIBLE" to more loops are
bugfixes, but they're not terribly important ones to backport. While
they technically make sense even on older kernels and could
conceivably make the older kernels unload the r8152 driver a little
faster when a device is unplugged, it's not a big deal. On the first
version of the recent patches I didn't even add a "Fixes" tag for them
but I was asked to during the review process.
The "add RTL8152_INACCESSIBLE" patches become more important with
commit d9962b0d4202 ("r8152: Block future register access if register
access fails"). Once you have that it's possible to end up in the
"INACCESSIBLE" situation in response to normal (ish) error handling
and thus you want it to be faster.
Based on our experience in ChromeOS, commit d9962b0d4202 ("r8152:
Block future register access if register access fails") is a pretty
important fix and I would say it should be backported to stable.
Certainly we've backported it to our kernels in ChromeOS. In our case
we made things easier on ourselves by backporting pretty much all
patches to the r8152 driver.
-Doug
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-13 15:16 ` Doug Anderson
@ 2023-12-13 17:37 ` Greg Kroah-Hartman
2023-12-13 18:17 ` Doug Anderson
0 siblings, 1 reply; 18+ messages in thread
From: Greg Kroah-Hartman @ 2023-12-13 17:37 UTC (permalink / raw)
To: Doug Anderson
Cc: Pavel Machek, Guenter Roeck, grundler, davem, stable, patches,
linux-kernel, torvalds, akpm, shuah, patches, lkft-triage,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
allen.lkml
On Wed, Dec 13, 2023 at 07:16:52AM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Dec 13, 2023 at 12:50 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Dec 13, 2023 at 08:52:25AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > This is the start of the stable review cycle for the 6.1.68 release.
> > > > > > There are 194 patches in this series, all will be posted as a response
> > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > >
> > > > >
> > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
> > > > > >
> > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
> > > > > >
> > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
> > > > > >
> > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > r8152: Add RTL8152_INACCESSIBLE checks to more loops
> > > > > >
> > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
> > > > >
> > > > > Central patch that actually fixes something is:
> > > > >
> > > > > commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> > > > > Author: Douglas Anderson <dianders@chromium.org>
> > > > > Date: Fri Oct 20 14:06:59 2023 -0700
> > > > >
> > > > > r8152: Block future register access if register access fails
> > > > >
> > > > > ...but we don't have that in 6.1. So we should not need the rest,
> > > > > either.
> > > > >
> > > >
> > > > Also, the missing patch is fixed subsequently by another patch, so it can not
> > > > be added on its own.
> > >
> > > For the record I'm trying to advocate "drop all patches listed as they
> > > don't fix the bug", not "add more", as this does not meet stable
> > > criteria.
> >
> > But the original commit here does say it fixes a bug, see the text of
> > the commits listed above. So perhaps someone got this all wrong when
> > they wrote the original commits that got merged into 6.7-rc? Otherwise
> > this seems like they are sane to keep for now, unless the original
> > author says they should be dropped, or someone who can test this driver
> > says something went wrong.
>
> Right. The patches that "add RTL8152_INACCESSIBLE" to more loops are
> bugfixes, but they're not terribly important ones to backport. While
> they technically make sense even on older kernels and could
> conceivably make the older kernels unload the r8152 driver a little
> faster when a device is unplugged, it's not a big deal. On the first
> version of the recent patches I didn't even add a "Fixes" tag for them
> but I was asked to during the review process.
>
> The "add RTL8152_INACCESSIBLE" patches become more important with
> commit d9962b0d4202 ("r8152: Block future register access if register
> access fails"). Once you have that it's possible to end up in the
> "INACCESSIBLE" situation in response to normal (ish) error handling
> and thus you want it to be faster.
>
> Based on our experience in ChromeOS, commit d9962b0d4202 ("r8152:
> Block future register access if register access fails") is a pretty
> important fix and I would say it should be backported to stable.
> Certainly we've backported it to our kernels in ChromeOS. In our case
> we made things easier on ourselves by backporting pretty much all
> patches to the r8152 driver.
Ok, as lots of fixes seem to be needed here, do you have a list of the
git ids that we should backport to bring this up to a workable state
like you have in your tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: RTL8152_INACCESSIBLE was Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-13 17:37 ` Greg Kroah-Hartman
@ 2023-12-13 18:17 ` Doug Anderson
0 siblings, 0 replies; 18+ messages in thread
From: Doug Anderson @ 2023-12-13 18:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pavel Machek, Guenter Roeck, grundler, davem, stable, patches,
linux-kernel, torvalds, akpm, shuah, patches, lkft-triage,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
allen.lkml
Hi,
On Wed, Dec 13, 2023 at 9:38 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Dec 13, 2023 at 07:16:52AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Dec 13, 2023 at 12:50 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Dec 13, 2023 at 08:52:25AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > > This is the start of the stable review cycle for the 6.1.68 release.
> > > > > > > There are 194 patches in this series, all will be posted as a response
> > > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > > let me know.
> > > > > >
> > > > > >
> > > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
> > > > > > >
> > > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > > r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
> > > > > > >
> > > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > > r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
> > > > > > >
> > > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > > r8152: Add RTL8152_INACCESSIBLE checks to more loops
> > > > > > >
> > > > > > > Douglas Anderson <dianders@chromium.org>
> > > > > > > r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
> > > > > >
> > > > > > Central patch that actually fixes something is:
> > > > > >
> > > > > > commit d9962b0d42029bcb40fe3c38bce06d1870fa4df4
> > > > > > Author: Douglas Anderson <dianders@chromium.org>
> > > > > > Date: Fri Oct 20 14:06:59 2023 -0700
> > > > > >
> > > > > > r8152: Block future register access if register access fails
> > > > > >
> > > > > > ...but we don't have that in 6.1. So we should not need the rest,
> > > > > > either.
> > > > > >
> > > > >
> > > > > Also, the missing patch is fixed subsequently by another patch, so it can not
> > > > > be added on its own.
> > > >
> > > > For the record I'm trying to advocate "drop all patches listed as they
> > > > don't fix the bug", not "add more", as this does not meet stable
> > > > criteria.
> > >
> > > But the original commit here does say it fixes a bug, see the text of
> > > the commits listed above. So perhaps someone got this all wrong when
> > > they wrote the original commits that got merged into 6.7-rc? Otherwise
> > > this seems like they are sane to keep for now, unless the original
> > > author says they should be dropped, or someone who can test this driver
> > > says something went wrong.
> >
> > Right. The patches that "add RTL8152_INACCESSIBLE" to more loops are
> > bugfixes, but they're not terribly important ones to backport. While
> > they technically make sense even on older kernels and could
> > conceivably make the older kernels unload the r8152 driver a little
> > faster when a device is unplugged, it's not a big deal. On the first
> > version of the recent patches I didn't even add a "Fixes" tag for them
> > but I was asked to during the review process.
> >
> > The "add RTL8152_INACCESSIBLE" patches become more important with
> > commit d9962b0d4202 ("r8152: Block future register access if register
> > access fails"). Once you have that it's possible to end up in the
> > "INACCESSIBLE" situation in response to normal (ish) error handling
> > and thus you want it to be faster.
> >
> > Based on our experience in ChromeOS, commit d9962b0d4202 ("r8152:
> > Block future register access if register access fails") is a pretty
> > important fix and I would say it should be backported to stable.
> > Certainly we've backported it to our kernels in ChromeOS. In our case
> > we made things easier on ourselves by backporting pretty much all
> > patches to the r8152 driver.
>
> Ok, as lots of fixes seem to be needed here, do you have a list of the
> git ids that we should backport to bring this up to a workable state
> like you have in your tree?
The ones that were relevant to commit d9962b0d4202 ("r8152: Block
future register access if register access fails") were these, which is
basically the two series that I landed recently.:
79321a793945 r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()
8c53a7bd7065 r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()
8a67b47fced9 r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()
32a574c7e268 r8152: Add RTL8152_INACCESSIBLE checks to more loops
e62adaeecdc6 r8152: Hold the rtnl_lock for all of reset
d9962b0d4202 r8152: Block future register access if register access fails
715f67f33af4 r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
bc65cc42af73 r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()
dc90ba37a8c3 r8152: Check for unplug in rtl_phy_patch_request()
b8d35024d405 r8152: Release firmware if we have an error in probe
bb8adff9123e r8152: Cancel hw_phy_work if we have an error in probe
5dd176895269 r8152: Run the unload routine if we have errors during probe
a5feba71ec9c r8152: Increase USB control msg timeout to 5000ms as per spec
The problem, of course, is that picking commit d9962b0d4202 ("r8152:
Block future register access if register access fails") causes
conflicts with other changes that have happened to this driver. On
ChromeOS we generally resolve things like this by just picking the
extra patches. We already had quite a few backports to the ChromeOS
kernel trees, so I can't say it would be the same for stable branches.
On ChromeOS 5.15 you can see the picks that were needed at:
https://crrev.com/c/4857700
If you click "SHOW ALL (17)" then you can see the patches that I
uploaded together to get things resolved on our ChromeOS 5.15 branch.
There are also links to our 6.1, 5.10, and 5.4 branches.
One note is that as part of taking these extra patches we ended up
getting commit ec51fbd1b8a2 ("r8152: add USB device driver for config
selection") which caused a regression. That's where the following
recent changes that landed in your tree came from:
aa4f2b3e418e r8152: Choose our USB config with choose_configuration()
rather than probe()
a87b8e3be926 usb: core: Allow subclassed USB drivers to override
usb_choose_configuration()
c2d95fcff0f0 usb: core: Don't force USB generic_subclass drivers to
define probe()
...and where the (pending) extra patch came from:
https://lore.kernel.org/r/20231211073237.v3.1.If27eb3bf7812f91ab83810f232292f032f4203e0@changeid
("usb: core: Fix crash w/ usb_choose_configuration() if no driver")
-Doug
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2023-12-12 20:08 ` RTL8152_INACCESSIBLE was " Pavel Machek
@ 2023-12-12 21:57 ` Ron Economos
2023-12-12 22:21 ` Jon Hunter
2023-12-12 22:23 ` SeongJae Park
10 siblings, 0 replies; 18+ messages in thread
From: Ron Economos @ 2023-12-12 21:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On 12/11/23 10:19 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <re@w6rz.net>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2023-12-12 21:57 ` Ron Economos
@ 2023-12-12 22:21 ` Jon Hunter
2023-12-12 22:23 ` SeongJae Park
10 siblings, 0 replies; 18+ messages in thread
From: Jon Hunter @ 2023-12-12 22:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, linux-tegra,
stable
On Mon, 11 Dec 2023 19:19:50 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 fail
Linux version: 6.1.68-rc1-g807435a379b4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 6.1 000/194] 6.1.68-rc1 review
2023-12-11 18:19 [PATCH 6.1 000/194] 6.1.68-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2023-12-12 22:21 ` Jon Hunter
@ 2023-12-12 22:23 ` SeongJae Park
10 siblings, 0 replies; 18+ messages in thread
From: SeongJae Park @ 2023-12-12 22:23 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, damon,
SeongJae Park
Hello,
On 2023-12-11T19:19:50+01:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 6.1.68 release.
> There are 194 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 13 Dec 2023 18:19:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.68-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine.
Attaching the test results summary below. Please note that I retrieved the
kernel from linux-stable-rc tree[2].
Tested-by: SeongJae Park <sj@kernel.org>
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 807435a379b4 ("Linux 6.1.68-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: sysfs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh
ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_i386_idle_flag.sh
ok 13 selftests: damon-tests: build_i386_highpte.sh
ok 14 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
^ permalink raw reply [flat|nested] 18+ messages in thread