Re: [PATCH v3 3/5] remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
On 02.11.23 16:43, Mathieu Poirier wrote: > Hi Jan, > > On Thu, Nov 02, 2023 at 11:07:45AM +0100, Jan Kiszka wrote: >> On 13.02.22 21:12, Suman Anna wrote: >>> Add support to the K3 R5F remoteproc driver to configure all the R5F >>> cores to be either in IPC-only mode or the traditional remoteproc mode. >>> The IPC-only mode expects that the remote processors are already booted >>> by the bootloader, and only performs the minimum steps required to >>> initialize and deinitialize the virtio IPC transports. The remoteproc >>> mode allows the kernel remoteproc driver to do the regular load and >>> boot and other device management operations for a R5F core. >>> >>> The IPC-only mode for a R5F core is detected and configured at driver >>> probe time by querying the System Firmware for the R5F power and reset >>> state and/or status and making sure that the R5F core is indeed started >>> by the bootloaders, otherwise the device is configured for remoteproc >>> mode. >>> >>> Support for IPC-only mode is achieved through .attach(), .detach() and >>> .get_loaded_rsc_table() callback ops and zeroing out the regular rproc >>> ops .prepare(), .unprepare(), .start() and .stop(). The resource table >>> follows a design-by-contract approach and is expected to be at the base >>> of the DDR firmware region reserved for each remoteproc, it is mostly >>> expected to contain only the virtio device and trace resource entries. >>> >>> NOTE: >>> The driver cannot configure a R5F core for remoteproc mode by any >>> means without rebooting the kernel if that R5F core has been started >>> by a bootloader. This is the current desired behavior and can be >>> enhanced in the future if the feature is needed. >>> >> >> This change surfaced some complex issue in the K3 core: Turning on the >> RTI1 watchdog also powers up R5F core 1. And this could happen either in > > When writing "... also powers up...", other than R5F core 1, what else is > being > powered? Would be a question for the SoC vendor - I assumed that only mcu_rti1 [1] goes on when enabling it. But also mcu_r5fss0_core1 is enabled after that, at least according to the respective TI-SCI query that the is_on handler is performing. I've tested that under Linux and in U-Boot. > >> U-Boot or in the kernel. If the kernel finds the core running, it also >> expects a resource table in the reserved RAM. But as the core is >> supposed to start via remoteproc, there is none, rather often garbage. >> Sometimes, a consistency check catches that, but not always: >> > > If I understand correct and strictly addressing the Linux case, the R5F is > configured to operate in split mode and both cores are off. An RTI1 watchdog > happens, which has the side effect of turning on core 1. At some later time > core > 1 is turned on from the sysfs interface, the remoteproc driver recognizes that > it is already powered and as such enacts the "attach" scenario. That leads > to a > crash because the resource table hasn't been loaded into memory. > > Is this a proper description? Almost: The watchdog device (rti_wdt [2]) is probed before k3-r5-remoteproc. This comes with powering up rti1, and that turns on R5 core 1 as well. There is no watchdog fired. After that, the k3-r5 driver probes the available cores, finds the second one enabled, and goes down the IPC-only road for it. > >> [ 38.372844] remoteproc remoteproc18: 4100.r5f is available >> [ 38.380324] platform 4140.r5f: R5F core may have been powered on by a >> different host, programmed state (0) != actual state (1) >> [ 38.394910] platform 4140.r5f: configured R5F for IPC-only mode >> [ 38.401941] platform 4140.r5f: assigned reserved memory node >> r5f-dma-memory@a100 >> [ 38.476997] remoteproc remoteproc19: 4140.r5f is available >> [ 38.484661] remoteproc remoteproc19: attaching to 4140.r5f >> [ 38.491092] Unable to handle kernel paging request at virtual address >> 8dff >> [ 38.503704] Mem abort info: >> [ 38.509760] ESR = 0x9607 >> [ 38.514071] EC = 0x25: DABT (current EL), IL = 32 bits >> [ 38.519578] SET = 0, FnV = 0 >> [ 38.523095] EA = 0, S1PTW = 0 >> [ 38.526355] FSC = 0x07: level 3 translation fault >> [ 38.528974] cal 6f03000.cal: Neither port is configured, no point in >> staying up >> [ 38.531775] Data abort info: >> [ 38.541866] ISV = 0, ISS = 0x0007 >> [ 38.545765] CM = 0, WnR = 0 >> [ 38.548
Re: [PATCH v3 3/5] remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
On 13.02.22 21:12, Suman Anna wrote: > Add support to the K3 R5F remoteproc driver to configure all the R5F > cores to be either in IPC-only mode or the traditional remoteproc mode. > The IPC-only mode expects that the remote processors are already booted > by the bootloader, and only performs the minimum steps required to > initialize and deinitialize the virtio IPC transports. The remoteproc > mode allows the kernel remoteproc driver to do the regular load and > boot and other device management operations for a R5F core. > > The IPC-only mode for a R5F core is detected and configured at driver > probe time by querying the System Firmware for the R5F power and reset > state and/or status and making sure that the R5F core is indeed started > by the bootloaders, otherwise the device is configured for remoteproc > mode. > > Support for IPC-only mode is achieved through .attach(), .detach() and > .get_loaded_rsc_table() callback ops and zeroing out the regular rproc > ops .prepare(), .unprepare(), .start() and .stop(). The resource table > follows a design-by-contract approach and is expected to be at the base > of the DDR firmware region reserved for each remoteproc, it is mostly > expected to contain only the virtio device and trace resource entries. > > NOTE: > The driver cannot configure a R5F core for remoteproc mode by any > means without rebooting the kernel if that R5F core has been started > by a bootloader. This is the current desired behavior and can be > enhanced in the future if the feature is needed. > This change surfaced some complex issue in the K3 core: Turning on the RTI1 watchdog also powers up R5F core 1. And this could happen either in U-Boot or in the kernel. If the kernel finds the core running, it also expects a resource table in the reserved RAM. But as the core is supposed to start via remoteproc, there is none, rather often garbage. Sometimes, a consistency check catches that, but not always: [ 38.372844] remoteproc remoteproc18: 4100.r5f is available [ 38.380324] platform 4140.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1) [ 38.394910] platform 4140.r5f: configured R5F for IPC-only mode [ 38.401941] platform 4140.r5f: assigned reserved memory node r5f-dma-memory@a100 [ 38.476997] remoteproc remoteproc19: 4140.r5f is available [ 38.484661] remoteproc remoteproc19: attaching to 4140.r5f [ 38.491092] Unable to handle kernel paging request at virtual address 8dff [ 38.503704] Mem abort info: [ 38.509760] ESR = 0x9607 [ 38.514071] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.519578] SET = 0, FnV = 0 [ 38.523095] EA = 0, S1PTW = 0 [ 38.526355] FSC = 0x07: level 3 translation fault [ 38.528974] cal 6f03000.cal: Neither port is configured, no point in staying up [ 38.531775] Data abort info: [ 38.541866] ISV = 0, ISS = 0x0007 [ 38.545765] CM = 0, WnR = 0 [ 38.548814] swapper pgtable: 4k pages, 48-bit VAs, pgdp=82fdc000 [ 38.555831] [8dff] pgd=1008f003, p4d=1008f003, pud=1008e003, pmd=100886609003, pte= [ 38.568623] remoteproc remoteproc18: powering up 4100.r5f [ 38.569338] Internal error: Oops: 9607 [#1] PREEMPT SMP [ 38.574440] remoteproc remoteproc18: Booting fw image am65x-mcu-r5f0_0-fw, size 932 [ 38.580644] Modules linked in: usbserial ti_cal videobuf2_dma_contig ti_k3_r5_remoteproc(+) videobuf2_memops pci_endpoint_test videobuf2_v4l2 rti_wdt watchdog videobuf2_common at24 st_lsm6dsx_i2c(+) optee_rng st_lsm6dsx kfifo_buf pm16d17 rng_core tee_stmm_efi tpm_ftpm_tee fuse dm_mod ip_tables x_tables ipv6 [ 38.589862] remoteproc remoteproc18: remote processor 4100.r5f is now up [ 38.615533] CPU: 1 PID: 283 Comm: (udev-worker) Not tainted 6.1.54-cip6 #1 [ 38.615546] Hardware name: SIMATIC IOT2050 Advanced PG2 (DT) [ 38.615553] pstate: 0005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 38.641945] pc : rproc_handle_resources.constprop.0+0x8c/0x164 [ 38.647788] lr : rproc_boot+0x2fc/0x57c [ 38.651628] sp : 89d53740 [ 38.654934] x29: 89d53740 x28: 00087f7d77f8 x27: 0008048f4c10 [ 38.662068] x26: 0001 x25: x24: 8e00 [ 38.669199] x23: 00080227e038 x22: x21: 892bb1b0 [ 38.676333] x20: 00080227e000 x19: x18: 028e [ 38.683464] x17: x16: 6d958cac x15: [ 38.690597] x14: x13: x12: [ 38.697728] x11: x10: x9 : bfff [ 38.704862] x8 : x7 : fdff x6 : ffdf [ 38.711994] x5 : 000802be1f00 x4 : 8e000100 x3 : 00fd [ 38.719127] x2 : x1 : 8e03 x0 :
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 19.04.21 17:14, Michal Simek wrote:
>
>
> On 4/19/21 1:48 PM, Jan Kiszka wrote:
>> On 19.04.21 12:52, Michal Simek wrote:
>>> Hi Jan,
>>>
>>> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>>>> On 01.04.21 16:52, Jan Kiszka wrote:
>>>>> On 01.04.21 13:42, Michal Simek wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>>>
>>>>>>>> Signed-off-by: Rajan Vaja
>>>>>>>> ---
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>>>>>>> +
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>>>>>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>> new file mode 100644
>>>>>>>> index 000..9868ca1
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>> @@ -0,0 +1,222 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>> +/*
>>>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>>>> + *
>>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>> + *
>>>>>>>> + * Michal Simek
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#include
>>>>>>>> +/ {
>>>>>>>> + pss_ref_clk: pss_ref_clk {
>>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>>> + compatible = "fixed-clock";
>>>>>>>> + #clock-cells = <0>;
>>>>>>>> + clock-frequency = <>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + video_clk: video_clk {
>>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>>> + compatible = "fixed-clock";
>>>>>>>> + #clock-cells = <0>;
>>>>>>>> + clock-frequency = <2700>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>>> + compatible = "fixed-clock";
>>>>>>>> + #clock-cells = <0>;
>>>>>>>> + clock-frequency = <0>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>>
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 19.04.21 12:52, Michal Simek wrote:
> Hi Jan,
>
> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>> On 01.04.21 16:52, Jan Kiszka wrote:
>>> On 01.04.21 13:42, Michal Simek wrote:
>>>> Hi Jan,
>>>>
>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>
>>>>>> Signed-off-by: Rajan Vaja
>>>>>> ---
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>>>>> +
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>>>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>> new file mode 100644
>>>>>> index 000..9868ca1
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>> @@ -0,0 +1,222 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>> +/*
>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>> + *
>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>> + *
>>>>>> + * Michal Simek
>>>>>> + */
>>>>>> +
>>>>>> +#include
>>>>>> +/ {
>>>>>> +pss_ref_clk: pss_ref_clk {
>>>>>> +u-boot,dm-pre-reloc;
>>>>>> +compatible = "fixed-clock";
>>>>>> +#clock-cells = <0>;
>>>>>> +clock-frequency = <>;
>>>>>> +};
>>>>>> +
>>>>>> +video_clk: video_clk {
>>>>>> +u-boot,dm-pre-reloc;
>>>>>> +compatible = "fixed-clock";
>>>>>> +#clock-cells = <0>;
>>>>>> +clock-frequency = <2700>;
>>>>>> +};
>>>>>> +
>>>>>> +pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>> +u-boot,dm-pre-reloc;
>>>>>> +compatible = "fixed-clock";
>>>>>> +#clock-cells = <0>;
>>>>>> +clock-frequency = <0>;
>>>>>> +};
>>>>>> +
>>>>>> +gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>> +u-boot,dm-pre-reloc;
>>>>>> +compatible = "fixed-clock";
>>>>>> +#clock-cells = <0>;
>>>>>> +clock-frequency = <10800>;
>>>>>> +};
>>>>>> +
>>>>>> +aux_ref_clk: aux_ref_clk {
>>>>>> +u-boot,dm-pre-reloc;
>>>>>> +compatible = "fixed-clock";
>>>>>> +#clock-cells = <0>;
>>>>>> +clock-frequency = <2700>;
>>>>>> +};
>>>>>> +
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 01.04.21 16:52, Jan Kiszka wrote:
> On 01.04.21 13:42, Michal Simek wrote:
>> Hi Jan,
>>
>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>> Add clock nodes for zynqmp based on CCF.
>>>>
>>>> Signed-off-by: Rajan Vaja
>>>> ---
>>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>>> +
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>> new file mode 100644
>>>> index 000..9868ca1
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>> @@ -0,0 +1,222 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Clock specification for Xilinx ZynqMP
>>>> + *
>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>> + *
>>>> + * Michal Simek
>>>> + */
>>>> +
>>>> +#include
>>>> +/ {
>>>> + pss_ref_clk: pss_ref_clk {
>>>> + u-boot,dm-pre-reloc;
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <>;
>>>> + };
>>>> +
>>>> + video_clk: video_clk {
>>>> + u-boot,dm-pre-reloc;
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <2700>;
>>>> + };
>>>> +
>>>> + pss_alt_ref_clk: pss_alt_ref_clk {
>>>> + u-boot,dm-pre-reloc;
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <0>;
>>>> + };
>>>> +
>>>> + gt_crx_ref_clk: gt_crx_ref_clk {
>>>> + u-boot,dm-pre-reloc;
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <10800>;
>>>> + };
>>>> +
>>>> + aux_ref_clk: aux_ref_clk {
>>>> + u-boot,dm-pre-reloc;
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <2700>;
>>>> + };
>>>> +};
>>>> +
>>>> + {
>>>> + clocks = <_clk CAN0_REF>, <_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> + {
>>>> + clocks = <_clk CAN1_REF>, <_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> + {
>>>> + clocks = <_clk ACPU>;
>>>> +};
>>>> +
>>>> +_dma_chan1 {
>>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +_dma_chan2 {
>>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +_dma_chan3 {
>>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +_dma_chan4 {
>>>> + clocks = <_clk GDMA_REF>
[tip: x86/cleanups] x86/pat: Do not compile stubbed functions when X86_PAT is off
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 16854b567dff767e5ec5e6dc23021271136733a5
Gitweb:
https://git.kernel.org/tip/16854b567dff767e5ec5e6dc23021271136733a5
Author:Jan Kiszka
AuthorDate:Mon, 26 Oct 2020 18:39:06 +01:00
Committer: Borislav Petkov
CommitterDate: Wed, 14 Apr 2021 08:21:41 +02:00
x86/pat: Do not compile stubbed functions when X86_PAT is off
Those are already provided by linux/io.h as stubs.
The conflict remains invisible until someone would pull linux/io.h into
memtype.c. This fixes a build error when this file is used outside of
the kernel tree.
[ bp: Massage commit message. ]
Signed-off-by: Jan Kiszka
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/a9351615-7a0d-9d47-af65-d9e2fffe8...@siemens.com
---
arch/x86/mm/pat/memtype.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 6084d14..3112ca7 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -800,6 +800,7 @@ void memtype_free_io(resource_size_t start, resource_size_t
end)
memtype_free(start, end);
}
+#ifdef CONFIG_X86_PAT
int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
{
enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
@@ -813,6 +814,7 @@ void arch_io_free_memtype_wc(resource_size_t start,
resource_size_t size)
memtype_free_io(start, start + size);
}
EXPORT_SYMBOL(arch_io_free_memtype_wc);
+#endif
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
[tip: x86/cleanups] x86/asm: Ensure asm/proto.h can be included stand-alone
The following commit has been merged into the x86/cleanups branch of tip: Commit-ID: f7b21a0e41171d22296b897dac6e4c41d2a3643c Gitweb: https://git.kernel.org/tip/f7b21a0e41171d22296b897dac6e4c41d2a3643c Author:Jan Kiszka AuthorDate:Sun, 11 Apr 2021 10:12:16 +02:00 Committer: Borislav Petkov CommitterDate: Mon, 12 Apr 2021 13:12:46 +02:00 x86/asm: Ensure asm/proto.h can be included stand-alone Fix: ../arch/x86/include/asm/proto.h:14:30: warning: ‘struct task_struct’ declared \ inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2); ^~~ .../arch/x86/include/asm/proto.h:40:34: warning: ‘struct task_struct’ declared \ inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_common(struct task_struct *task, int option, ^~~ if linux/sched.h hasn't be included previously. This fixes a build error when this header is used outside of the kernel tree. [ bp: Massage commit message. ] Signed-off-by: Jan Kiszka Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/b76b4be3-cf66-f6b2-9a6c-3e7ef54f9...@web.de --- arch/x86/include/asm/proto.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h index b6a9d51..8c5d191 100644 --- a/arch/x86/include/asm/proto.h +++ b/arch/x86/include/asm/proto.h @@ -4,6 +4,8 @@ #include +struct task_struct; + /* misc architecture specific prototypes */ void syscall_init(void);
Re: [PATCH v2] x86: pat: Do not compile stubbed functions when X86_PAT is off
On 11.04.21 11:10, Borislav Petkov wrote:
> On Sun, Apr 11, 2021 at 10:22:19AM +0200, Jan Kiszka wrote:
>> On 26.10.20 18:39, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> Those are already provided by linux/io.h as stubs.
>>>
>>> The conflict remains invisible until someone would pull linux/io.h into
>>> memtype.c.
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
>>>
>>> Change in v2:
>>> - correct commit message
>>>
>>> arch/x86/mm/pat/memtype.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
>>> index 8f665c352bf0..41a4ac585af3 100644
>>> --- a/arch/x86/mm/pat/memtype.c
>>> +++ b/arch/x86/mm/pat/memtype.c
>>> @@ -800,6 +800,7 @@ void memtype_free_io(resource_size_t start,
>>> resource_size_t end)
>>> memtype_free(start, end);
>>> }
>>>
>>> +#ifdef CONFIG_X86_PAT
>>> int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
>>> {
>>> enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
>>> @@ -813,6 +814,7 @@ void arch_io_free_memtype_wc(resource_size_t start,
>>> resource_size_t size)
>>> memtype_free_io(start, start + size);
>>> }
>>> EXPORT_SYMBOL(arch_io_free_memtype_wc);
>>> +#endif
>>>
>>> pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>>> unsigned long size, pgprot_t vma_prot)
>>>
>>
>> What happened to this?
>
> What is this patch and your other asm/proto.h thing fixing?
>
> Looks like you're using kernel headers in something else and don't want
> to include the whole world thus those fixes... so that you can include
> upstream kernel headers without having to touch them...
>
> Or am I way off base here?
>
The patches are coming from downstream usage, yes, but I think the
solutions are relevant cleanups for upstream as well.
Jan
Re: [PATCH v2] x86: pat: Do not compile stubbed functions when X86_PAT is off
On 26.10.20 18:39, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Those are already provided by linux/io.h as stubs.
>
> The conflict remains invisible until someone would pull linux/io.h into
> memtype.c.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Change in v2:
> - correct commit message
>
> arch/x86/mm/pat/memtype.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> index 8f665c352bf0..41a4ac585af3 100644
> --- a/arch/x86/mm/pat/memtype.c
> +++ b/arch/x86/mm/pat/memtype.c
> @@ -800,6 +800,7 @@ void memtype_free_io(resource_size_t start,
> resource_size_t end)
> memtype_free(start, end);
> }
>
> +#ifdef CONFIG_X86_PAT
> int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
> {
> enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
> @@ -813,6 +814,7 @@ void arch_io_free_memtype_wc(resource_size_t start,
> resource_size_t size)
> memtype_free_io(start, start + size);
> }
> EXPORT_SYMBOL(arch_io_free_memtype_wc);
> +#endif
>
> pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> unsigned long size, pgprot_t vma_prot)
>
What happened to this?
Jan
[PATCH] x86: Ensure asm/proto.h can be included stand-alone
From: Jan Kiszka Avoids ../arch/x86/include/asm/proto.h:14:30: warning: ‘struct task_struct’ declared inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2); ^~~ ../arch/x86/include/asm/proto.h:40:34: warning: ‘struct task_struct’ declared inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_common(struct task_struct *task, int option, ^~~ if linux/sched.h hasn't be included previously. Signed-off-by: Jan Kiszka --- arch/x86/include/asm/proto.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h index b6a9d51d1d79..8c5d1910a848 100644 --- a/arch/x86/include/asm/proto.h +++ b/arch/x86/include/asm/proto.h @@ -4,6 +4,8 @@ #include +struct task_struct; + /* misc architecture specific prototypes */ void syscall_init(void); -- 2.26.2
Re: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem
On 07.04.21 16:59, Nishanth Menon wrote: > On 16:13-20210407, Aswath Govindraju wrote: >> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1]. >> >> Add support by removing the no-1-8-v tag and including the voltage >> regulator device tree nodes for power cycling. >> >> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1 >> >> Signed-off-by: Aswath Govindraju > >> --- >> >> test logs: >> https://pastebin.ubuntu.com/p/vpYbY9QWh8/ >> > Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already > out). but it does trigger an interesting discussion.. > >> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 - >> .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++ >> 2 files changed, 33 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> index cb340d1b401f..632f32fce4a1 100644 >> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >> @@ -301,7 +301,6 @@ >> ti,otap-del-sel = <0x2>; >> ti,trm-icp = <0x8>; >> dma-coherent; >> -no-1-8-v; >> }; >> > > Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0, > 2.0, 2.1 coming along, the plan for TI was to support older revs via > overlays hoping that older boards will eventually get replaced or die > out of lack of use.. but you do have production on 1.0 -> so would you > rather handle this in overlay OR IOT boards dts introduce no-1-8-v > property? I'm fine with pulling anything needed into our board-specific DTs. Those pending are for SR1.0 boards only. SR2 will come later and have their own DTs. Didn't follow the thread: Where is this patch located wrt my IOT2050 series? Does it come first first, and we would have to rebase? Or would this change rather have to move the flag to k3-am65-iot2050-common.dtsi? Thanks a lot for having an eye on these subtle dependencies! Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 01.04.21 13:42, Michal Simek wrote:
> Hi Jan,
>
> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>> On 07.11.19 10:44, Rajan Vaja wrote:
>>> Add clock nodes for zynqmp based on CCF.
>>>
>>> Signed-off-by: Rajan Vaja
>>> ---
>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>> +
>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>> new file mode 100644
>>> index 000..9868ca1
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>> @@ -0,0 +1,222 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Clock specification for Xilinx ZynqMP
>>> + *
>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>> + *
>>> + * Michal Simek
>>> + */
>>> +
>>> +#include
>>> +/ {
>>> + pss_ref_clk: pss_ref_clk {
>>> + u-boot,dm-pre-reloc;
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <>;
>>> + };
>>> +
>>> + video_clk: video_clk {
>>> + u-boot,dm-pre-reloc;
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <2700>;
>>> + };
>>> +
>>> + pss_alt_ref_clk: pss_alt_ref_clk {
>>> + u-boot,dm-pre-reloc;
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <0>;
>>> + };
>>> +
>>> + gt_crx_ref_clk: gt_crx_ref_clk {
>>> + u-boot,dm-pre-reloc;
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <10800>;
>>> + };
>>> +
>>> + aux_ref_clk: aux_ref_clk {
>>> + u-boot,dm-pre-reloc;
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <2700>;
>>> + };
>>> +};
>>> +
>>> + {
>>> + clocks = <_clk CAN0_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> + {
>>> + clocks = <_clk CAN1_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> + {
>>> + clocks = <_clk ACPU>;
>>> +};
>>> +
>>> +_dma_chan1 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan2 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan3 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan4 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan5 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan6 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +_dma_chan7 {
>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 07.11.19 10:44, Rajan Vaja wrote:
> Add clock nodes for zynqmp based on CCF.
>
> Signed-off-by: Rajan Vaja
> ---
> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
> +
> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
> 15 files changed, 270 insertions(+), 26 deletions(-)
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> new file mode 100644
> index 000..9868ca1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> @@ -0,0 +1,222 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Clock specification for Xilinx ZynqMP
> + *
> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
> + *
> + * Michal Simek
> + */
> +
> +#include
> +/ {
> + pss_ref_clk: pss_ref_clk {
> + u-boot,dm-pre-reloc;
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <>;
> + };
> +
> + video_clk: video_clk {
> + u-boot,dm-pre-reloc;
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2700>;
> + };
> +
> + pss_alt_ref_clk: pss_alt_ref_clk {
> + u-boot,dm-pre-reloc;
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + };
> +
> + gt_crx_ref_clk: gt_crx_ref_clk {
> + u-boot,dm-pre-reloc;
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <10800>;
> + };
> +
> + aux_ref_clk: aux_ref_clk {
> + u-boot,dm-pre-reloc;
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2700>;
> + };
> +};
> +
> + {
> + clocks = <_clk CAN0_REF>, <_clk LPD_LSBUS>;
> +};
> +
> + {
> + clocks = <_clk CAN1_REF>, <_clk LPD_LSBUS>;
> +};
> +
> + {
> + clocks = <_clk ACPU>;
> +};
> +
> +_dma_chan1 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan2 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan3 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan4 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan5 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan6 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan7 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan8 {
> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan1 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan2 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan3 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan4 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan5 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan6 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan7 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> +_dma_chan8 {
> + clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
> +};
> +
> + {
> + clocks = <_clk LPD_LSBUS>, <_clk GEM0_REF>,
> + <_clk GEM0_TX>, <_clk GEM0_RX>,
> + <_clk GEM_TSU>;
> + clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
> +};
> +
> + {
> + clocks = <_clk LPD_LSBUS>, <_clk GEM1_REF>,
> + <_clk GEM1_TX>, <_clk GEM1_RX>,
> + <_clk GEM_TSU>;
> + clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
> +};
> +
> + {
> + clocks = <_clk LPD_LSBUS>, <_clk GEM2_REF>,
> + <_clk GEM2_TX>, <_clk GEM2_RX>,
> + <_clk GEM_TSU>;
> + clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
> +};
> +
> + {
> + clocks = <_clk LPD_LSBUS>, <_clk GEM3_REF>,
> + <_clk GEM3_TX>, <_clk GEM3_RX>,
> + <_clk GEM_TSU>;
> + clock-names = "pclk",
Re: [PATCH] staging: gasket: remove it from the kernel
On 25.03.21 15:52, Greg KH wrote: > On Thu, Mar 25, 2021 at 03:46:10PM +0100, Jan Kiszka wrote: >> On 15.03.21 17:10, Rob Springer wrote: >>> Acked-by: Rob Springer >>> >>> >>> On Mon, Mar 15, 2021 at 8:44 AM wrote: >>>> >>>> From: Greg Kroah-Hartman >>>> >>>> As none of the proposed things that need to be changed in the gasket >>>> drivers have ever been done, and there has not been any forward progress >>>> to get this out of staging, it seems totally abandonded so remove the >>>> code entirely so that people do not spend their time doing tiny cleanups >>>> for code that will never get out of staging. >>>> >>>> If this code is actually being used, it can be reverted simply and then >>>> cleaned up properly, but as it is abandoned, let's just get rid of it. >>>> >>>> Cc: Rob Springer >>>> Cc: Todd Poynor >>>> Cc: Ben Chan >>>> Cc: Richard Yeh >>>> Signed-off-by: Greg Kroah-Hartman >> >> OK, so is there a plan of the HW vendor to improve the user experience >> for this hardware? Is there a different software architecture in sight >> which will not need a kernel driver? > > What hardware vendor makes this thing? What systems require it? And > why can't you use UIO instead? > >> Just wondering loudly while fiddling with dkms packages and starring at >> the code diffs between what was removed here and what I still have to >> install manually from remote sources. > > Where are the remote sources for this thing and why didn't they ever get > synced into the kernel tree? > Very good questions, and I'm curious to learn if someone in CC can answer them. I was just starting to play with this thing, using Google's binary Debian repo. But that is not... optimal. Even more when thinking beyond a try-out stage. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] staging: gasket: remove it from the kernel
On 15.03.21 17:10, Rob Springer wrote: > Acked-by: Rob Springer > > > On Mon, Mar 15, 2021 at 8:44 AM wrote: >> >> From: Greg Kroah-Hartman >> >> As none of the proposed things that need to be changed in the gasket >> drivers have ever been done, and there has not been any forward progress >> to get this out of staging, it seems totally abandonded so remove the >> code entirely so that people do not spend their time doing tiny cleanups >> for code that will never get out of staging. >> >> If this code is actually being used, it can be reverted simply and then >> cleaned up properly, but as it is abandoned, let's just get rid of it. >> >> Cc: Rob Springer >> Cc: Todd Poynor >> Cc: Ben Chan >> Cc: Richard Yeh >> Signed-off-by: Greg Kroah-Hartman OK, so is there a plan of the HW vendor to improve the user experience for this hardware? Is there a different software architecture in sight which will not need a kernel driver? Just wondering loudly while fiddling with dkms packages and starring at the code diffs between what was removed here and what I still have to install manually from remote sources. Thanks, Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
On 22.03.21 19:05, Jan Kiszka wrote:
> On 22.03.21 08:58, Jan Kiszka wrote:
>> On 03.07.19 07:08, Nicolas Boichat wrote:
>>> If the device tree is incorrectly configured, and attempts to
>>> define a "no-map" reserved memory that overlaps with the kernel
>>> data/code, the kernel would crash quickly after boot, with no
>>> obvious clue about the nature of the issue.
>>>
>>> For example, this would happen if we have the kernel mapped at
>>> these addresses (from /proc/iomem):
>>> 4000-41ff : System RAM
>>> 4008-40df : Kernel code
>>> 40e0-411f : reserved
>>> 4120-413e0fff : Kernel data
>>>
>>> And we declare a no-map shared-dma-pool region at a fixed address
>>> within that range:
>>> mem_reserved: mem_region {
>>> compatible = "shared-dma-pool";
>>> reg = <0 0x4000 0 0x01A0>;
>>> no-map;
>>> };
>>>
>>> To fix this, when removing memory regions at early boot (which is
>>> what "no-map" regions do), we need to make sure that the memory
>>> is not already reserved. If we do, __reserved_mem_reserve_reg
>>> will throw an error:
>>> [0.00] OF: fdt: Reserved memory: failed to reserve memory
>>>for node 'mem_region': base 0x4000, size 26 MiB
>>> and the code that will try to use the region should also fail,
>>> later on.
>>>
>>> We do not do anything for non-"no-map" regions, as memblock
>>> explicitly allows reserved regions to overlap, and the commit
>>> that this fixes removed the check for that precise reason.
>>>
>>> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in
>>> the case of partial overlap")
>>> Signed-off-by: Nicolas Boichat
>>> ---
>>> drivers/of/fdt.c | 10 +-
>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>> index cd17dc62a71980a..a1ded43fc332d0c 100644
>>> --- a/drivers/of/fdt.c
>>> +++ b/drivers/of/fdt.c
>>> @@ -1138,8 +1138,16 @@ int __init __weak
>>> early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
>>> int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
>>> phys_addr_t size, bool nomap)
>>> {
>>> - if (nomap)
>>> + if (nomap) {
>>> + /*
>>> +* If the memory is already reserved (by another region), we
>>> +* should not allow it to be removed altogether.
>>> +*/
>>> + if (memblock_is_region_reserved(base, size))
>>> + return -EBUSY;
>>> +
>>> return memblock_remove(base, size);
>>> + }
>>> return memblock_reserve(base, size);
>>> }
>>>
>>>
>>
>> Likely the wrong patch to blame but hopefully the right audience:
>>
>> I'm trying to migrate my RPi4 setup to mainline, and this commit breaks
>> booting with TF-A (current master) in the loop. Error:
>>
>> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
>>
>>
>>
>> [0.00] Linux version 5.10.24+ (jan@md1f2u6c) (aarch64-linux-gnu-gcc
>> (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1
>> 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12
>> (arm-9.10)1
>> [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1
>>
>>
>>
>> [0.00] efi: UEFI not found.
>>
>>
>>
>> [0.00] OF: fdt: Reserved memory: failed to reserve memory for node
>> 'atf@0': base 0x, size 0 MiB
>>
>>
>>
>> And then we hang later on when Linux does start to use that memor
Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
On 22.03.21 08:58, Jan Kiszka wrote:
> On 03.07.19 07:08, Nicolas Boichat wrote:
>> If the device tree is incorrectly configured, and attempts to
>> define a "no-map" reserved memory that overlaps with the kernel
>> data/code, the kernel would crash quickly after boot, with no
>> obvious clue about the nature of the issue.
>>
>> For example, this would happen if we have the kernel mapped at
>> these addresses (from /proc/iomem):
>> 4000-41ff : System RAM
>> 4008-40df : Kernel code
>> 40e0-411f : reserved
>> 4120-413e0fff : Kernel data
>>
>> And we declare a no-map shared-dma-pool region at a fixed address
>> within that range:
>> mem_reserved: mem_region {
>> compatible = "shared-dma-pool";
>> reg = <0 0x4000 0 0x01A0>;
>> no-map;
>> };
>>
>> To fix this, when removing memory regions at early boot (which is
>> what "no-map" regions do), we need to make sure that the memory
>> is not already reserved. If we do, __reserved_mem_reserve_reg
>> will throw an error:
>> [0.00] OF: fdt: Reserved memory: failed to reserve memory
>>for node 'mem_region': base 0x4000, size 26 MiB
>> and the code that will try to use the region should also fail,
>> later on.
>>
>> We do not do anything for non-"no-map" regions, as memblock
>> explicitly allows reserved regions to overlap, and the commit
>> that this fixes removed the check for that precise reason.
>>
>> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in
>> the case of partial overlap")
>> Signed-off-by: Nicolas Boichat
>> ---
>> drivers/of/fdt.c | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index cd17dc62a71980a..a1ded43fc332d0c 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -1138,8 +1138,16 @@ int __init __weak
>> early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
>> int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
>> phys_addr_t size, bool nomap)
>> {
>> -if (nomap)
>> +if (nomap) {
>> +/*
>> + * If the memory is already reserved (by another region), we
>> + * should not allow it to be removed altogether.
>> + */
>> +if (memblock_is_region_reserved(base, size))
>> +return -EBUSY;
>> +
>> return memblock_remove(base, size);
>> +}
>> return memblock_reserve(base, size);
>> }
>>
>>
>
> Likely the wrong patch to blame but hopefully the right audience:
>
> I'm trying to migrate my RPi4 setup to mainline, and this commit breaks
> booting with TF-A (current master) in the loop. Error:
>
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
>
>
>
> [0.00] Linux version 5.10.24+ (jan@md1f2u6c) (aarch64-linux-gnu-gcc
> (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1
> 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12
> (arm-9.10)1
> [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1
>
>
>
> [0.00] efi: UEFI not found.
>
>
>
> [0.00] OF: fdt: Reserved memory: failed to reserve memory for node
> 'atf@0': base 0x, size 0 MiB
>
>
>
> And then we hang later on when Linux does start to use that memory and
> seems to trigger an exception.
>
> Is there a bug in the upstream RPi4 DT?
>
FWIW, this is triggering the conflict:
(arch/arm/boot/dts/bcm283x.dtsi)
/* firmware-provided startup stubs live here, where the secondary CPUs are
* spinning.
*/
/memreserve/ 0x 0x1000;
I strongly suspect this is only needed in case of TF-A-free boot. With
TF-A we have standard PCSI (my motivation to use TF-A in the first
place) - and then this is in conflict with the firmware's reservation.
Do we need separate DTs for this use case? Or should TF-A account for
this?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
On 03.07.19 07:08, Nicolas Boichat wrote:
> If the device tree is incorrectly configured, and attempts to
> define a "no-map" reserved memory that overlaps with the kernel
> data/code, the kernel would crash quickly after boot, with no
> obvious clue about the nature of the issue.
>
> For example, this would happen if we have the kernel mapped at
> these addresses (from /proc/iomem):
> 4000-41ff : System RAM
> 4008-40df : Kernel code
> 40e0-411f : reserved
> 4120-413e0fff : Kernel data
>
> And we declare a no-map shared-dma-pool region at a fixed address
> within that range:
> mem_reserved: mem_region {
> compatible = "shared-dma-pool";
> reg = <0 0x4000 0 0x01A0>;
> no-map;
> };
>
> To fix this, when removing memory regions at early boot (which is
> what "no-map" regions do), we need to make sure that the memory
> is not already reserved. If we do, __reserved_mem_reserve_reg
> will throw an error:
> [0.00] OF: fdt: Reserved memory: failed to reserve memory
>for node 'mem_region': base 0x4000, size 26 MiB
> and the code that will try to use the region should also fail,
> later on.
>
> We do not do anything for non-"no-map" regions, as memblock
> explicitly allows reserved regions to overlap, and the commit
> that this fixes removed the check for that precise reason.
>
> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the
> case of partial overlap")
> Signed-off-by: Nicolas Boichat
> ---
> drivers/of/fdt.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index cd17dc62a71980a..a1ded43fc332d0c 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1138,8 +1138,16 @@ int __init __weak
> early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
> int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> phys_addr_t size, bool nomap)
> {
> - if (nomap)
> + if (nomap) {
> + /*
> + * If the memory is already reserved (by another region), we
> + * should not allow it to be removed altogether.
> + */
> + if (memblock_is_region_reserved(base, size))
> + return -EBUSY;
> +
> return memblock_remove(base, size);
> + }
> return memblock_reserve(base, size);
> }
>
>
Likely the wrong patch to blame but hopefully the right audience:
I'm trying to migrate my RPi4 setup to mainline, and this commit breaks
booting with TF-A (current master) in the loop. Error:
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.10.24+ (jan@md1f2u6c) (aarch64-linux-gnu-gcc
(GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1
20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12
(arm-9.10)1
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1
[0.00] efi: UEFI not found.
[0.00] OF: fdt: Reserved memory: failed to reserve memory for node
'atf@0': base 0x, size 0 MiB
And then we hang later on when Linux does start to use that memory and
seems to trigger an exception.
Is there a bug in the upstream RPi4 DT?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
[only saw this now, or delivery to me was delayed - anyway] On 16.03.21 19:02, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 18:01 +0100, Jan Kiszka wrote: >> On 16.03.21 17:50, Sean Christopherson wrote: >>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>> On Tue, 2021-03-16 at 16:31 +0100, Jan Kiszka wrote: >>>>> Back then, when I was hacking on the gdb-stub and KVM support, the >>>>> monitor trap flag was not yet broadly available, but the idea to once >>>>> use it was already there. Now it can be considered broadly available, >>>>> but it would still require some changes to get it in. >>>>> >>>>> Unfortunately, we don't have such thing with SVM, even recent versions, >>>>> right? So, a proper way of avoiding diverting event injections while we >>>>> are having the guest in an "incorrect" state should definitely be the >>>>> goal. >>>> Yes, I am not aware of anything like monitor trap on SVM. >>>> >>>>> Given that KVM knows whether TF originates solely from guest debugging >>>>> or was (also) injected by the guest, we should be able to identify the >>>>> cases where your approach is best to apply. And that without any extra >>>>> control knob that everyone will only forget to set. >>>> Well I think that the downside of this patch is that the user might >>>> actually >>>> want to single step into an interrupt handler, and this patch makes it a >>>> bit >>>> more complicated, and changes the default behavior. >>> >>> Yes. And, as is, this also blocks NMIs and SMIs. I suspect it also doesn't >>> prevent weirdness if the guest is running in L2, since IRQs for L1 will >>> cause >>> exits from L2 during nested_ops->check_events(). >>> >>>> I have no objections though to use this patch as is, or at least make this >>>> the new default with a new flag to override this. >>> >>> That's less bad, but IMO still violates the principle of least surprise, >>> e.g. >>> someone that is single-stepping a guest and is expecting an IRQ to fire >>> will be >>> all kinds of confused if they see all the proper IRR, ISR, EFLAGS.IF, etc... >>> settings, but no interrupt. >> >> From my practical experience with debugging guests via single step, >> seeing an interrupt in that case is everything but handy and generally >> also not expected (though logical, I agree). IOW: When there is a knob >> for it, it will remain off in 99% of the time. >> >> But I see the point of having some control, in an ideal world also an >> indication that there are pending events, permitting the user to decide >> what to do. But I suspect the gdb frontend and protocol does not easily >> permit that. > > Qemu gdbstub actually does have control over suppression of the interrupts > over a single step and it is even enabled by default: > > https://qemu.readthedocs.io/en/latest/system/gdb.html > (advanced debug options) > Ah, cool! Absolutely in line with what we need. > However it is currently only implemented in TCG (software emulator) mode > and not in KVM mode (I can argue that this is a qemu bug). Maybe the behavior of old KVM was not exposing the issue, thus no one cared. As I wrote in the other mail today, even some recent kernel do not seem to break single-stepping, for yet unknown reasons. > > So my plan was to add a new kvm guest debug flag KVM_GUESTDBG_BLOCKEVENTS, > and let qemu enable it when its 'NOIRQ' mode is enabled (it is by default). > > However due to the discussion in this thread about the leakage of the > RFLAGS.TF, > I wonder if kvm should by default suppress events and have something like > KVM_GUESTDBG_SSTEP_ALLOW_EVENTS to override this and wire > that to qemu's NOIRQ=false case. > > This will allow older qemu to work correctly and new qemu will be able to > choose > the old less ideal behavior. Sounds very reasonable to me. > >> >>>> Sean Christopherson, what do you think? >>> >>> Rather than block all events in KVM, what about having QEMU "pause" the >>> timer? >>> E.g. save MSR_TSC_DEADLINE and APIC_TMICT (or inspect the guest to find out >>> which flavor it's using), clear them to zero, then restore both when >>> single-stepping is disabled. I think that will work? >>> >> >> No one can stop the clock, and timers are only one source of interrupts. >> Plus they do not all come from QEMU, some also from KVM or in
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 13:34, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 12:27 +0100, Jan Kiszka wrote: >> On 16.03.21 11:59, Maxim Levitsky wrote: >>> On Tue, 2021-03-16 at 10:16 +0100, Jan Kiszka wrote: >>>> On 16.03.21 00:37, Sean Christopherson wrote: >>>>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>>>> This change greatly helps with two issues: >>>>>> >>>>>> * Resuming from a breakpoint is much more reliable. >>>>>> >>>>>> When resuming execution from a breakpoint, with interrupts enabled, >>>>>> more often >>>>>> than not, KVM would inject an interrupt and make the CPU jump >>>>>> immediately to >>>>>> the interrupt handler and eventually return to the breakpoint, to >>>>>> trigger it >>>>>> again. >>>>>> >>>>>> From the user point of view it looks like the CPU never executed a >>>>>> single instruction and in some cases that can even prevent forward >>>>>> progress, >>>>>> for example, when the breakpoint is placed by an automated script >>>>>> (e.g lx-symbols), which does something in response to the breakpoint >>>>>> and then >>>>>> continues the guest automatically. >>>>>> If the script execution takes enough time for another interrupt to >>>>>> arrive, >>>>>> the guest will be stuck on the same breakpoint RIP forever. >>>>>> >>>>>> * Normal single stepping is much more predictable, since it won't land >>>>>> the >>>>>> debugger into an interrupt handler, so it is much more usable. >>>>>> >>>>>> (If entry to an interrupt handler is desired, the user can still place >>>>>> a >>>>>> breakpoint at it and resume the guest, which won't activate this >>>>>> workaround >>>>>> and let the gdb still stop at the interrupt handler) >>>>>> >>>>>> Since this change is only active when guest is debugged, it won't affect >>>>>> KVM running normal 'production' VMs. >>>>>> >>>>>> >>>>>> Signed-off-by: Maxim Levitsky >>>>>> Tested-by: Stefano Garzarella >>>>>> --- >>>>>> arch/x86/kvm/x86.c | 6 ++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>>>>> index a9d95f90a0487..b75d990fcf12b 100644 >>>>>> --- a/arch/x86/kvm/x86.c >>>>>> +++ b/arch/x86/kvm/x86.c >>>>>> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct kvm_vcpu >>>>>> *vcpu, bool *req_immediate_exit >>>>>> can_inject = false; >>>>>> } >>>>>> >>>>>> +/* >>>>>> + * Don't inject interrupts while single stepping to make guest >>>>>> debug easier >>>>>> + */ >>>>>> +if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >>>>>> +return; >>>>> >>>>> Is this something userspace can deal with? E.g. disable IRQs and/or set >>>>> NMI >>>>> blocking at the start of single-stepping, unwind at the end? Deviating >>>>> this far >>>>> from architectural behavior will end in tears at some point. >>>>> >>>> >>>> Does this happen to address this suspicious workaround in the kernel? >>>> >>>> /* >>>> * The kernel doesn't use TF single-step outside of: >>>> * >>>> * - Kprobes, consumed through kprobe_debug_handler() >>>> * - KGDB, consumed through notify_debug() >>>> * >>>> * So if we get here with DR_STEP set, something is wonky. >>>> * >>>> * A known way to trigger this is through QEMU's GDB stub, >>>> * which leaks #DB into the guest and causes IST recursion. >>>> */ >>>> if (WARN_ON_ONCE(dr6 & DR_STEP)) >>>> regs->flags &= ~X86_EFLAGS_TF; >>>> >>>> (arch/x86
Re: [PATCH v4 2/2] gpio: sch: Hook into ACPI SCI handler to catch GPIO edge events
On 17.03.21 10:52, Andy Shevchenko wrote: > On Wed, Mar 17, 2021 at 07:57:44AM +0100, Jan Kiszka wrote: >> On 16.03.21 21:49, Andy Shevchenko wrote: >>> On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote: >>>> From: Jan Kiszka >>>> >>>> Neither the ACPI description on the Quark platform provides the required >>>> information is to do establish generic handling nor hardware capable of >>>> doing it. According to the datasheet the hardware can generate SCI events. >>>> Therefore, we need to hook from the driver directly into SCI handler of >>>> the ACPI subsystem in order to catch and report GPIO-related events. >>>> >>>> Validated on the Quark-based IOT2000 platform. >>> >>> This patch must be dropped completely. SCI handler is not correct way to do >>> this. The proper way (and we have already few examples in the kernel) is to >>> register GPE event. >> >> As explained above, this is not supported by the preexisting firmware, >> and there won't be any updates to it anymore. >> >> This platform is history, the SoC was discontinued by Intel long ago, >> and our devices reaching their support end as well. The race to upstream >> was lost in this case - backlog too long, we being too slow. > > So you have no device to test and there is actually no device which has this > capability in the wild. > > Am I reading this correct? No. We do have devices but we don't have the time to invest further into bringing missing features upstream - not to speak of changing the firmware in order to support cleaner upstream integration. For the remaining lifetime of the devices, we are stuck on 4.4.y-cip with a few additional patches, including this one. > > In any case, we have platforms in the wild that actually support GPEs and this > makes sense for them. Sure, I don't want to judge for them. Just our original target of this patch is no longer relevant for upstream. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 18:26, Sean Christopherson wrote: > On Tue, Mar 16, 2021, Jan Kiszka wrote: >> On 16.03.21 17:50, Sean Christopherson wrote: >>> Rather than block all events in KVM, what about having QEMU "pause" the >>> timer? >>> E.g. save MSR_TSC_DEADLINE and APIC_TMICT (or inspect the guest to find out >>> which flavor it's using), clear them to zero, then restore both when >>> single-stepping is disabled. I think that will work? >>> >> >> No one can stop the clock, and timers are only one source of interrupts. >> Plus they do not all come from QEMU, some also from KVM or in-kernel >> sources directly. > > But are any other sources of interrupts a chronic problem? I 100% agree that If you are debugging a problem, you are not interested in seening problems of the debugger, only real ones of your target. IOW: Yes, they are, even if less likely - for idle VMs. > this would not be a robust solution, but neither is blocking events in KVM. > At > least with this approach, the blast radius is somewhat contained. > >> Would quickly become a mess. > > Maybe, but it'd be Qemu's mess ;-) > Nope, it would spread to KVM as well, as indicated above. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v4 2/2] gpio: sch: Hook into ACPI SCI handler to catch GPIO edge events
On 16.03.21 21:49, Andy Shevchenko wrote: > On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote: >> From: Jan Kiszka >> >> Neither the ACPI description on the Quark platform provides the required >> information is to do establish generic handling nor hardware capable of >> doing it. According to the datasheet the hardware can generate SCI events. >> Therefore, we need to hook from the driver directly into SCI handler of >> the ACPI subsystem in order to catch and report GPIO-related events. >> >> Validated on the Quark-based IOT2000 platform. > > This patch must be dropped completely. SCI handler is not correct way to do > this. The proper way (and we have already few examples in the kernel) is to > register GPE event. As explained above, this is not supported by the preexisting firmware, and there won't be any updates to it anymore. This platform is history, the SoC was discontinued by Intel long ago, and our devices reaching their support end as well. The race to upstream was lost in this case - backlog too long, we being too slow. Jan > > It took me a while to gather all bits of this puzzle. > > At least now I get an event, but kernel oopses, I'll continue debugging > tomorrow. > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 17:50, Sean Christopherson wrote: > On Tue, Mar 16, 2021, Maxim Levitsky wrote: >> On Tue, 2021-03-16 at 16:31 +0100, Jan Kiszka wrote: >>> Back then, when I was hacking on the gdb-stub and KVM support, the >>> monitor trap flag was not yet broadly available, but the idea to once >>> use it was already there. Now it can be considered broadly available, >>> but it would still require some changes to get it in. >>> >>> Unfortunately, we don't have such thing with SVM, even recent versions, >>> right? So, a proper way of avoiding diverting event injections while we >>> are having the guest in an "incorrect" state should definitely be the goal. >> Yes, I am not aware of anything like monitor trap on SVM. >> >>> >>> Given that KVM knows whether TF originates solely from guest debugging >>> or was (also) injected by the guest, we should be able to identify the >>> cases where your approach is best to apply. And that without any extra >>> control knob that everyone will only forget to set. >> Well I think that the downside of this patch is that the user might actually >> want to single step into an interrupt handler, and this patch makes it a bit >> more complicated, and changes the default behavior. > > Yes. And, as is, this also blocks NMIs and SMIs. I suspect it also doesn't > prevent weirdness if the guest is running in L2, since IRQs for L1 will cause > exits from L2 during nested_ops->check_events(). > >> I have no objections though to use this patch as is, or at least make this >> the new default with a new flag to override this. > > That's less bad, but IMO still violates the principle of least surprise, e.g. > someone that is single-stepping a guest and is expecting an IRQ to fire will > be > all kinds of confused if they see all the proper IRR, ISR, EFLAGS.IF, etc... > settings, but no interrupt. >From my practical experience with debugging guests via single step, seeing an interrupt in that case is everything but handy and generally also not expected (though logical, I agree). IOW: When there is a knob for it, it will remain off in 99% of the time. But I see the point of having some control, in an ideal world also an indication that there are pending events, permitting the user to decide what to do. But I suspect the gdb frontend and protocol does not easily permit that. > >> Sean Christopherson, what do you think? > > Rather than block all events in KVM, what about having QEMU "pause" the timer? > E.g. save MSR_TSC_DEADLINE and APIC_TMICT (or inspect the guest to find out > which flavor it's using), clear them to zero, then restore both when > single-stepping is disabled. I think that will work? > No one can stop the clock, and timers are only one source of interrupts. Plus they do not all come from QEMU, some also from KVM or in-kernel sources directly. Would quickly become a mess. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 16:49, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 16:31 +0100, Jan Kiszka wrote: >> On 16.03.21 15:34, Maxim Levitsky wrote: >>> On Tue, 2021-03-16 at 14:46 +0100, Jan Kiszka wrote: >>>> On 16.03.21 13:34, Maxim Levitsky wrote: >>>>> On Tue, 2021-03-16 at 12:27 +0100, Jan Kiszka wrote: >>>>>> On 16.03.21 11:59, Maxim Levitsky wrote: >>>>>>> On Tue, 2021-03-16 at 10:16 +0100, Jan Kiszka wrote: >>>>>>>> On 16.03.21 00:37, Sean Christopherson wrote: >>>>>>>>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>>>>>>>> This change greatly helps with two issues: >>>>>>>>>> >>>>>>>>>> * Resuming from a breakpoint is much more reliable. >>>>>>>>>> >>>>>>>>>> When resuming execution from a breakpoint, with interrupts >>>>>>>>>> enabled, more often >>>>>>>>>> than not, KVM would inject an interrupt and make the CPU jump >>>>>>>>>> immediately to >>>>>>>>>> the interrupt handler and eventually return to the breakpoint, to >>>>>>>>>> trigger it >>>>>>>>>> again. >>>>>>>>>> >>>>>>>>>> From the user point of view it looks like the CPU never executed a >>>>>>>>>> single instruction and in some cases that can even prevent forward >>>>>>>>>> progress, >>>>>>>>>> for example, when the breakpoint is placed by an automated script >>>>>>>>>> (e.g lx-symbols), which does something in response to the >>>>>>>>>> breakpoint and then >>>>>>>>>> continues the guest automatically. >>>>>>>>>> If the script execution takes enough time for another interrupt to >>>>>>>>>> arrive, >>>>>>>>>> the guest will be stuck on the same breakpoint RIP forever. >>>>>>>>>> >>>>>>>>>> * Normal single stepping is much more predictable, since it won't >>>>>>>>>> land the >>>>>>>>>> debugger into an interrupt handler, so it is much more usable. >>>>>>>>>> >>>>>>>>>> (If entry to an interrupt handler is desired, the user can still >>>>>>>>>> place a >>>>>>>>>> breakpoint at it and resume the guest, which won't activate this >>>>>>>>>> workaround >>>>>>>>>> and let the gdb still stop at the interrupt handler) >>>>>>>>>> >>>>>>>>>> Since this change is only active when guest is debugged, it won't >>>>>>>>>> affect >>>>>>>>>> KVM running normal 'production' VMs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Signed-off-by: Maxim Levitsky >>>>>>>>>> Tested-by: Stefano Garzarella >>>>>>>>>> --- >>>>>>>>>> arch/x86/kvm/x86.c | 6 ++ >>>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>>>>>>>>> index a9d95f90a0487..b75d990fcf12b 100644 >>>>>>>>>> --- a/arch/x86/kvm/x86.c >>>>>>>>>> +++ b/arch/x86/kvm/x86.c >>>>>>>>>> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct >>>>>>>>>> kvm_vcpu *vcpu, bool *req_immediate_exit >>>>>>>>>> can_inject = false; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> +/* >>>>>>>>>> + * Don't inject interrupts while single stepping to make guest >>>>>>>>>> debug easier >>>>>>>>>> + */ >>>>>>>>>> +if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >>>>>>>>>> +return; >>>>>>>>
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 15:34, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 14:46 +0100, Jan Kiszka wrote: >> On 16.03.21 13:34, Maxim Levitsky wrote: >>> On Tue, 2021-03-16 at 12:27 +0100, Jan Kiszka wrote: >>>> On 16.03.21 11:59, Maxim Levitsky wrote: >>>>> On Tue, 2021-03-16 at 10:16 +0100, Jan Kiszka wrote: >>>>>> On 16.03.21 00:37, Sean Christopherson wrote: >>>>>>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>>>>>> This change greatly helps with two issues: >>>>>>>> >>>>>>>> * Resuming from a breakpoint is much more reliable. >>>>>>>> >>>>>>>> When resuming execution from a breakpoint, with interrupts enabled, >>>>>>>> more often >>>>>>>> than not, KVM would inject an interrupt and make the CPU jump >>>>>>>> immediately to >>>>>>>> the interrupt handler and eventually return to the breakpoint, to >>>>>>>> trigger it >>>>>>>> again. >>>>>>>> >>>>>>>> From the user point of view it looks like the CPU never executed a >>>>>>>> single instruction and in some cases that can even prevent forward >>>>>>>> progress, >>>>>>>> for example, when the breakpoint is placed by an automated script >>>>>>>> (e.g lx-symbols), which does something in response to the breakpoint >>>>>>>> and then >>>>>>>> continues the guest automatically. >>>>>>>> If the script execution takes enough time for another interrupt to >>>>>>>> arrive, >>>>>>>> the guest will be stuck on the same breakpoint RIP forever. >>>>>>>> >>>>>>>> * Normal single stepping is much more predictable, since it won't land >>>>>>>> the >>>>>>>> debugger into an interrupt handler, so it is much more usable. >>>>>>>> >>>>>>>> (If entry to an interrupt handler is desired, the user can still >>>>>>>> place a >>>>>>>> breakpoint at it and resume the guest, which won't activate this >>>>>>>> workaround >>>>>>>> and let the gdb still stop at the interrupt handler) >>>>>>>> >>>>>>>> Since this change is only active when guest is debugged, it won't >>>>>>>> affect >>>>>>>> KVM running normal 'production' VMs. >>>>>>>> >>>>>>>> >>>>>>>> Signed-off-by: Maxim Levitsky >>>>>>>> Tested-by: Stefano Garzarella >>>>>>>> --- >>>>>>>> arch/x86/kvm/x86.c | 6 ++ >>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>> >>>>>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>>>>>>> index a9d95f90a0487..b75d990fcf12b 100644 >>>>>>>> --- a/arch/x86/kvm/x86.c >>>>>>>> +++ b/arch/x86/kvm/x86.c >>>>>>>> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct >>>>>>>> kvm_vcpu *vcpu, bool *req_immediate_exit >>>>>>>>can_inject = false; >>>>>>>>} >>>>>>>> >>>>>>>> + /* >>>>>>>> + * Don't inject interrupts while single stepping to make guest >>>>>>>> debug easier >>>>>>>> + */ >>>>>>>> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >>>>>>>> + return; >>>>>>> >>>>>>> Is this something userspace can deal with? E.g. disable IRQs and/or >>>>>>> set NMI >>>>>>> blocking at the start of single-stepping, unwind at the end? Deviating >>>>>>> this far >>>>>>> from architectural behavior will end in tears at some point. >>>>>>> >>>>>> >>>>>> Does this happen to address this suspicious workaround in the kernel? >>>>>> >>>>>> /* >>>>>> * The k
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 13:34, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 12:27 +0100, Jan Kiszka wrote: >> On 16.03.21 11:59, Maxim Levitsky wrote: >>> On Tue, 2021-03-16 at 10:16 +0100, Jan Kiszka wrote: >>>> On 16.03.21 00:37, Sean Christopherson wrote: >>>>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>>>> This change greatly helps with two issues: >>>>>> >>>>>> * Resuming from a breakpoint is much more reliable. >>>>>> >>>>>> When resuming execution from a breakpoint, with interrupts enabled, >>>>>> more often >>>>>> than not, KVM would inject an interrupt and make the CPU jump >>>>>> immediately to >>>>>> the interrupt handler and eventually return to the breakpoint, to >>>>>> trigger it >>>>>> again. >>>>>> >>>>>> From the user point of view it looks like the CPU never executed a >>>>>> single instruction and in some cases that can even prevent forward >>>>>> progress, >>>>>> for example, when the breakpoint is placed by an automated script >>>>>> (e.g lx-symbols), which does something in response to the breakpoint >>>>>> and then >>>>>> continues the guest automatically. >>>>>> If the script execution takes enough time for another interrupt to >>>>>> arrive, >>>>>> the guest will be stuck on the same breakpoint RIP forever. >>>>>> >>>>>> * Normal single stepping is much more predictable, since it won't land >>>>>> the >>>>>> debugger into an interrupt handler, so it is much more usable. >>>>>> >>>>>> (If entry to an interrupt handler is desired, the user can still place >>>>>> a >>>>>> breakpoint at it and resume the guest, which won't activate this >>>>>> workaround >>>>>> and let the gdb still stop at the interrupt handler) >>>>>> >>>>>> Since this change is only active when guest is debugged, it won't affect >>>>>> KVM running normal 'production' VMs. >>>>>> >>>>>> >>>>>> Signed-off-by: Maxim Levitsky >>>>>> Tested-by: Stefano Garzarella >>>>>> --- >>>>>> arch/x86/kvm/x86.c | 6 ++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>>>>> index a9d95f90a0487..b75d990fcf12b 100644 >>>>>> --- a/arch/x86/kvm/x86.c >>>>>> +++ b/arch/x86/kvm/x86.c >>>>>> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct kvm_vcpu >>>>>> *vcpu, bool *req_immediate_exit >>>>>> can_inject = false; >>>>>> } >>>>>> >>>>>> +/* >>>>>> + * Don't inject interrupts while single stepping to make guest >>>>>> debug easier >>>>>> + */ >>>>>> +if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >>>>>> +return; >>>>> >>>>> Is this something userspace can deal with? E.g. disable IRQs and/or set >>>>> NMI >>>>> blocking at the start of single-stepping, unwind at the end? Deviating >>>>> this far >>>>> from architectural behavior will end in tears at some point. >>>>> >>>> >>>> Does this happen to address this suspicious workaround in the kernel? >>>> >>>> /* >>>> * The kernel doesn't use TF single-step outside of: >>>> * >>>> * - Kprobes, consumed through kprobe_debug_handler() >>>> * - KGDB, consumed through notify_debug() >>>> * >>>> * So if we get here with DR_STEP set, something is wonky. >>>> * >>>> * A known way to trigger this is through QEMU's GDB stub, >>>> * which leaks #DB into the guest and causes IST recursion. >>>> */ >>>> if (WARN_ON_ONCE(dr6 & DR_STEP)) >>>> regs->flags &= ~X86_EFLAGS_TF; >>>> >>>> (arch/x86
Re: [PATCH 1/3] scripts/gdb: rework lx-symbols gdb script
On 15.03.21 23:10, Maxim Levitsky wrote:
> Fix several issues that are present in lx-symbols script:
>
> * Track module unloads by placing another software breakpoint at 'free_module'
> (force uninline this symbol just in case), and use remove-symbol-file
> gdb command to unload the symobls of the module that is unloading.
>
> That gives the gdb a chance to mark all software breakpoints from
> this module as pending again.
> Also remove the module from the 'known' module list once it is unloaded.
>
> * Since we now track module unload, we don't need to reload all
> symbols anymore when 'known' module loaded again (that can't happen
> anymore).
> This allows reloading a module in the debugged kernel to finish much faster,
> while lx-symbols tracks module loads and unloads.
>
> * Disable/enable all gdb breakpoints on both module load and unload breakpoint
> hits, and not only in 'load_all_symbols' as was done before.
> (load_all_symbols is no longer called on breakpoint hit)
> That allows gdb to avoid getting confused about the state of the (now two)
> internal breakpoints we place.
>
> Otherwise it will leave them in the kernel code segment, when continuing
> which triggers a guest kernel panic as soon as it skips over the 'int3'
> instruction and executes the garbage tail of the optcode on which
> the breakpoint was placed.
>
> Signed-off-by: Maxim Levitsky
> ---
> kernel/module.c | 8 ++-
> scripts/gdb/linux/symbols.py | 106 +--
> 2 files changed, 83 insertions(+), 31 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 30479355ab850..ea81fc06ea1f5 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -901,8 +901,12 @@ int module_refcount(struct module *mod)
> }
> EXPORT_SYMBOL(module_refcount);
>
> -/* This exists whether we can unload or not */
> -static void free_module(struct module *mod);
> +/* This exists whether we can unload or not
> + * Keep it uninlined to provide a reliable breakpoint target,
> + * e.g. for the gdb helper command 'lx-symbols'.
> + */
> +
> +static noinline void free_module(struct module *mod);
>
> SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
> unsigned int, flags)
> diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
> index 1be9763cf8bb2..4ce879548a1ae 100644
> --- a/scripts/gdb/linux/symbols.py
> +++ b/scripts/gdb/linux/symbols.py
> @@ -17,6 +17,24 @@ import re
>
> from linux import modules, utils
>
> +def save_state():
Naming is a bit too generic. And it's not only saving the state, it's
also disabling things.
> +breakpoints = []
> +if hasattr(gdb, 'breakpoints') and not gdb.breakpoints() is None:
> +for bp in gdb.breakpoints():
> +breakpoints.append({'breakpoint': bp, 'enabled': bp.enabled})
> +bp.enabled = False
> +
> +show_pagination = gdb.execute("show pagination", to_string=True)
> +pagination = show_pagination.endswith("on.\n")
> +gdb.execute("set pagination off")
> +
> +return {"breakpoints":breakpoints, "show_pagination":
> show_pagination}
> +
> +def load_state(state):
Maybe rather something with "restore", to make naming balanced. Or is
there a use case where "state" is not coming from the function above?
> +for breakpoint in state["breakpoints"]:
> +breakpoint['breakpoint'].enabled = breakpoint['enabled']
> +gdb.execute("set pagination %s" % ("on" if state["show_pagination"] else
> "off"))
> +
>
> if hasattr(gdb, 'Breakpoint'):
> class LoadModuleBreakpoint(gdb.Breakpoint):
> @@ -30,26 +48,38 @@ if hasattr(gdb, 'Breakpoint'):
> module_name = module['name'].string()
> cmd = self.gdb_command
>
> +# module already loaded, false alarm
> +if module_name in cmd.loaded_modules:
> +return False
Possibly at all, now that we track unloading? Can our state tracking
become out-of-sync?
> +
> # enforce update if object file is not found
> cmd.module_files_updated = False
>
> # Disable pagination while reporting symbol (re-)loading.
> # The console input is blocked in this context so that we would
> # get stuck waiting for the user to acknowledge paged output.
> -show_pagination = gdb.execute("show pagination", to_string=True)
> -pagination = show_pagination.endswith("on.\n")
> -gdb.execute("set pagination off")
> +state = save_state()
> +cmd.load_module_symbols(module)
> +load_state(state)
> +return False
>
> -if module_name in cmd.loaded_modules:
> -gdb.write("refreshing all symbols to reload module "
> - "'{0}'\n".format(module_name))
> -cmd.load_all_symbols()
> -else:
> -
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 11:59, Maxim Levitsky wrote: > On Tue, 2021-03-16 at 10:16 +0100, Jan Kiszka wrote: >> On 16.03.21 00:37, Sean Christopherson wrote: >>> On Tue, Mar 16, 2021, Maxim Levitsky wrote: >>>> This change greatly helps with two issues: >>>> >>>> * Resuming from a breakpoint is much more reliable. >>>> >>>> When resuming execution from a breakpoint, with interrupts enabled, more >>>> often >>>> than not, KVM would inject an interrupt and make the CPU jump >>>> immediately to >>>> the interrupt handler and eventually return to the breakpoint, to >>>> trigger it >>>> again. >>>> >>>> From the user point of view it looks like the CPU never executed a >>>> single instruction and in some cases that can even prevent forward >>>> progress, >>>> for example, when the breakpoint is placed by an automated script >>>> (e.g lx-symbols), which does something in response to the breakpoint and >>>> then >>>> continues the guest automatically. >>>> If the script execution takes enough time for another interrupt to >>>> arrive, >>>> the guest will be stuck on the same breakpoint RIP forever. >>>> >>>> * Normal single stepping is much more predictable, since it won't land the >>>> debugger into an interrupt handler, so it is much more usable. >>>> >>>> (If entry to an interrupt handler is desired, the user can still place a >>>> breakpoint at it and resume the guest, which won't activate this >>>> workaround >>>> and let the gdb still stop at the interrupt handler) >>>> >>>> Since this change is only active when guest is debugged, it won't affect >>>> KVM running normal 'production' VMs. >>>> >>>> >>>> Signed-off-by: Maxim Levitsky >>>> Tested-by: Stefano Garzarella >>>> --- >>>> arch/x86/kvm/x86.c | 6 ++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>>> index a9d95f90a0487..b75d990fcf12b 100644 >>>> --- a/arch/x86/kvm/x86.c >>>> +++ b/arch/x86/kvm/x86.c >>>> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct kvm_vcpu >>>> *vcpu, bool *req_immediate_exit >>>>can_inject = false; >>>>} >>>> >>>> + /* >>>> + * Don't inject interrupts while single stepping to make guest debug >>>> easier >>>> + */ >>>> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >>>> + return; >>> >>> Is this something userspace can deal with? E.g. disable IRQs and/or set NMI >>> blocking at the start of single-stepping, unwind at the end? Deviating >>> this far >>> from architectural behavior will end in tears at some point. >>> >> >> Does this happen to address this suspicious workaround in the kernel? >> >> /* >> * The kernel doesn't use TF single-step outside of: >> * >> * - Kprobes, consumed through kprobe_debug_handler() >> * - KGDB, consumed through notify_debug() >> * >> * So if we get here with DR_STEP set, something is wonky. >> * >> * A known way to trigger this is through QEMU's GDB stub, >> * which leaks #DB into the guest and causes IST recursion. >> */ >> if (WARN_ON_ONCE(dr6 & DR_STEP)) >> regs->flags &= ~X86_EFLAGS_TF; >> >> (arch/x86/kernel/traps.c, exc_debug_kernel) >> >> I wonder why this got merged while no one fixed QEMU/KVM, for years? Oh, >> yeah, question to myself as well, dancing around broken guest debugging >> for a long time while trying to fix other issues... > > To be honest I didn't see that warning even once, but I can imagine KVM > leaking #DB due to bugs in that code. That area historically didn't receive > much attention since it can only be triggered by > KVM_GET/SET_GUEST_DEBUG which isn't used in production. I've triggered it recently while debugging a guest, that's why I got aware of the code path. Long ago, all this used to work (soft BPs, single-stepping etc.) > > The only issue that I on the other hand did > see which is mostly gdb fault is that it fails to remove a software breakpoint > when resuming over it, if that breakpoint's python handler messes up > with gdb's symbols, which is what lx-symbols does. > > And that despite the fact that lx-symbol doesn't mess with the object > (that is the kernel) where the breakpoint is defined. > > Just adding/removing one symbol file is enough to trigger this issue. > > Since lx-symbols already works this around when it reloads all symbols, > I extended that workaround to happen also when loading/unloading > only a single symbol file. You have no issue with interactive debugging when NOT using gdb scripts / lx-symbol? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
On 16.03.21 00:37, Sean Christopherson wrote: > On Tue, Mar 16, 2021, Maxim Levitsky wrote: >> This change greatly helps with two issues: >> >> * Resuming from a breakpoint is much more reliable. >> >> When resuming execution from a breakpoint, with interrupts enabled, more >> often >> than not, KVM would inject an interrupt and make the CPU jump immediately >> to >> the interrupt handler and eventually return to the breakpoint, to trigger >> it >> again. >> >> From the user point of view it looks like the CPU never executed a >> single instruction and in some cases that can even prevent forward >> progress, >> for example, when the breakpoint is placed by an automated script >> (e.g lx-symbols), which does something in response to the breakpoint and >> then >> continues the guest automatically. >> If the script execution takes enough time for another interrupt to arrive, >> the guest will be stuck on the same breakpoint RIP forever. >> >> * Normal single stepping is much more predictable, since it won't land the >> debugger into an interrupt handler, so it is much more usable. >> >> (If entry to an interrupt handler is desired, the user can still place a >> breakpoint at it and resume the guest, which won't activate this workaround >> and let the gdb still stop at the interrupt handler) >> >> Since this change is only active when guest is debugged, it won't affect >> KVM running normal 'production' VMs. >> >> >> Signed-off-by: Maxim Levitsky >> Tested-by: Stefano Garzarella >> --- >> arch/x86/kvm/x86.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index a9d95f90a0487..b75d990fcf12b 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -8458,6 +8458,12 @@ static void inject_pending_event(struct kvm_vcpu >> *vcpu, bool *req_immediate_exit >> can_inject = false; >> } >> >> +/* >> + * Don't inject interrupts while single stepping to make guest debug >> easier >> + */ >> +if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) >> +return; > > Is this something userspace can deal with? E.g. disable IRQs and/or set NMI > blocking at the start of single-stepping, unwind at the end? Deviating this > far > from architectural behavior will end in tears at some point. > Does this happen to address this suspicious workaround in the kernel? /* * The kernel doesn't use TF single-step outside of: * * - Kprobes, consumed through kprobe_debug_handler() * - KGDB, consumed through notify_debug() * * So if we get here with DR_STEP set, something is wonky. * * A known way to trigger this is through QEMU's GDB stub, * which leaks #DB into the guest and causes IST recursion. */ if (WARN_ON_ONCE(dr6 & DR_STEP)) regs->flags &= ~X86_EFLAGS_TF; (arch/x86/kernel/traps.c, exc_debug_kernel) I wonder why this got merged while no one fixed QEMU/KVM, for years? Oh, yeah, question to myself as well, dancing around broken guest debugging for a long time while trying to fix other issues... Jan >> + >> /* >> * Finally, inject interrupt events. If an event cannot be injected >> * due to architectural conditions (e.g. IF=0) a window-open exit >> -- >> 2.26.2 >> -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
"cache_from_obj: Wrong slab cache." on failing ACPI init
Hi, a wrong config surfaced a potential issue in the cleanup path of ACPI, at least according to my current understanding. Use x86_64_defconfig, add CONFIG_SLAB_FREELIST_HARDENED=y and disable CONFIG_PCI, then boot in QEMU (likely also real HW) to get this: ... [0.041398] ACPI: Added _OSI(Module Device) [0.041978] ACPI: Added _OSI(Processor Device) [0.042342] ACPI: Added _OSI(3.0 _SCP Extensions) [0.043060] ACPI: Added _OSI(Processor Aggregator Device) [0.043337] ACPI: Added _OSI(Linux-Dell-Video) [0.044095] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) [0.044341] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) [0.045020] ACPI Error: AE_BAD_PARAMETER, During Region initialization (20210105/tbxfload-53) [0.045340] ACPI: Unable to load the System Description Tables [0.046076] ACPI Error: Could not remove SCI handler (20210105/evmisc-251) [0.046367] [ cut here ] [0.047004] cache_from_obj: Wrong slab cache. ftrace_event_field but object is from kmalloc-64 [0.047340] WARNING: CPU: 0 PID: 1 at ../mm/slab.h:456 kmem_cache_free+0x1c8/0x280 [0.048319] Modules linked in: [0.048335] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc2+ #7 [0.049174] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [0.049336] RIP: 0010:kmem_cache_free+0x1c8/0x280 [0.050041] Code: 28 48 01 d8 48 85 db 0f 85 2d ff ff ff 0f 0b 48 8b 57 60 48 8b 4d 60 48 c7 c6 f0 5b c1 af 48 c7 c7 50 5c da af e8 c8 36 e8 ff <0f> 0b 48 89 de 48 89 ef e8 8b be ff ff 48 8b 0d 7c 9e e4 00 e9 a6 [0.050336] RSP: :b12e80017d90 EFLAGS: 00010282 [0.051135] RAX: RBX: 89570104f340 RCX: dfff [0.051335] RDX: b12e80017bb0 RSI: dfff RDI: 0003 [0.052304] RBP: 895701042500 R08: R09: 0001 [0.052335] R10: 0001 R11: b12e80017ba8 R12: afdcb739 [0.053201] R13: 89570104f380 R14: 89578104f340 R15: [0.053335] FS: () GS:89573ec0() knlGS: [0.054337] CS: 0010 DS: ES: CR0: 80050033 [0.055342] CR2: CR3: 1780c001 CR4: 00370ef0 [0.056345] DR0: DR1: DR2: [0.057291] DR3: DR6: fffe0ff0 DR7: 0400 [0.057337] Call Trace: [0.057743] ? rdinit_setup+0x26/0x26 [0.058268] acpi_os_release_object+0x5/0x10 [0.058335] acpi_ns_delete_children+0x4b/0x60 [0.059168] acpi_ns_delete_namespace_subtree+0x5c/0x79 [0.059336] ? acpi_sleep_proc_init+0x1f/0x1f [0.059987] acpi_ns_terminate+0xc/0x31 [0.060335] acpi_ut_subsystem_shutdown+0x45/0xa1 [0.061060] ? acpi_sleep_proc_init+0x1f/0x1f [0.061335] acpi_terminate+0x5/0xf [0.062160] acpi_init+0x3f7/0x482 [0.062337] ? video_setup+0x79/0x79 [0.062958] ? acpi_sleep_proc_init+0x1f/0x1f [0.063335] do_one_initcall+0x3f/0x1c0 [0.063876] kernel_init_freeable+0x1bb/0x1f9 [0.064335] ? rest_init+0xb0/0xb0 [0.064833] kernel_init+0x5/0x110 [0.065329] ret_from_fork+0x22/0x30 [0.065338] ---[ end trace 8bfe26bf6796f23c ]--- [0.066028] [ cut here ] and many more of those. This was with current Linus head and also v5.10.23. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH v5 2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
From: Jan Kiszka These boards are based on AM6528 GP and AM6548 HS SOCs. Signed-off-by: Jan Kiszka Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index a9e7f981631e..c5aa362e4026 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -23,6 +23,8 @@ properties: items: - enum: - ti,am654-evm + - siemens,iot2050-basic + - siemens,iot2050-advanced - const: ti,am654 - description: K3 J721E SoC -- 2.26.2
[PATCH v5 0/3] arm64: Add TI AM65x-based IOT2050 boards
Changes in v4: - dropped spidev node - rebased over ti-k3-dts-next Jan Jan Kiszka (3): dt-bindings: Add Siemens vendor prefix dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards arm64: dts: ti: Add support for Siemens IOT2050 boards .../devicetree/bindings/arm/ti/k3.yaml| 2 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm64/boot/dts/ti/Makefile | 2 + .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 655 ++ .../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++ .../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++ 6 files changed, 782 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts -- 2.26.2
[PATCH v5 1/3] dt-bindings: Add Siemens vendor prefix
From: Jan Kiszka Add prefix for Siemens AG. Signed-off-by: Jan Kiszka Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f6064d84a424..91f99130a933 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1024,6 +1024,8 @@ patternProperties: description: Silex Insight "^siliconmitus,.*": description: Silicon Mitus, Inc. + "^siemens,.*": +description: Siemens AG "^simtek,.*": description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": -- 2.26.2
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 11.03.21 15:21, Nishanth Menon wrote: > On 15:14-20210311, Jan Kiszka wrote: > > [...] > >>> >>> See [1] compare the compatibles against >>> Documentation/devicetree/bindings -> I think you should describe what >>> your hardware really is though. >> >> This SPI bus is routed to an Arduino connector. By default, userspace >> (e.g. mraa) takes ownership and adds the desired logic for what is being >> connected. We have no idea what shield or other extension the user adds, >> though. > > overlays look like the right approach for variable systems like these. > It is not exactly plug and play.. but it does provide a level of > flexibility that is helpful. Yes, that's for extensions which have kernel drivers. The default model here is userspace, though. Will add as a separate patch to our queue for now. > > [..] >> The problem here is not simple txt->yml conversion: There is no official >> binding for spidev yet, just existing users and the driver waiting for them. >> > > I think we should discuss in the spidev list to get it resolved. > >>> Thanks.. While it might help me personally to get some on my internal >>> farm, it might be good to get them on kernelci as well on the longer >>> run. >>> >> >> Will keep that on the radar. I definitely want to get it into the CIP >> LAVA lab which is testing LTS as well. > > Cool. > >> Are we talking about spidev here? Then let's drop that node, but I do >> need to know how to describe spidev properly > > yes - the spidev is my problem. can you drop the node and repost? i cant > locally modify and hope it works. > Done. >> >> Or is it about those other warnings coming from your dtsi files, now >> being surfaced? If you can tell me how to resolve them, I can write patches. > > I will look at the warnings later today.. I dont think they are > triggered by the board dts. > That was also my interpretation of the results. Some are even just copies from what you get for the EVM boards. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH v5 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
From: Jan Kiszka
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link:
https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka
Reviewed-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 655 ++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 778 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 386ef98ccf7d..d56c742f5a10 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index ..de763ca9251c
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,655 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include
+
+/ {
+ aliases {
+ spi0 = _spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x0281";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e80 {
+ reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa000 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a010 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa010 0 0xf0>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a100 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa100 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a110 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa110 0 0xf0>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a200 {
+ reg = <0x00 0xa200 0x00 0x0020>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ status-led-red {
+ gpios = <_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 11.03.21 15:00, Nishanth Menon wrote:
> On 14:44-20210311, Jan Kiszka wrote:
>> On 11.03.21 14:17, Nishanth Menon wrote:
>>> On 10:37-20210310, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>> + spidev@0 {
>>>> + compatible = "rohm,dh2228fv";
>>>> + spi-max-frequency = <2000>;
>>>> + reg = <0>;
>>>
>>> Jan,
>>>
>>> As part of my final sanity checks, I noticed that we missed this: is a
>>> checkpatch warning
>>>
>>> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented --
>>> check ./Documentation/devicetree/bindings/
>>> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
>>> compatible = "rohm,dh2228fv";
>>>
>>> I cannot pick up nodes that are'nt documented as yaml in
>>> Documentation/devicetree
>>>
>>> I know this is irritating to find such nodes that already have previous
>>> users and the person coming last gets to deal with "new rules".. but
>>> sorry for catching this so late.
>>>
>>> Here are the options that come to mind:
>>>
>>> option 1) - drop the node and resubmit.
>>>
>>> option 2) - get the documentation into linux master tree and then submit
>>> the patches.
>>>
>>
>> As you said, I'm not setting a precedence here:
>>
>> arch/arm/boot/dts/imx28-cfa10049.dts: compatible =
>> "rohm,dh2228fv";
>> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible =
>> "rohm,dh2228fv";
>> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>>
>> Was just just never documented as binding? Or why is no one allowed to
>> use this anymore? What is to be used instead for spidev?
>
> See [1] compare the compatibles against
> Documentation/devicetree/bindings -> I think you should describe what
> your hardware really is though.
This SPI bus is routed to an Arduino connector. By default, userspace
(e.g. mraa) takes ownership and adds the desired logic for what is being
connected. We have no idea what shield or other extension the user adds,
though.
>
> Unfortunately devicetree migration has been far from being smooth.. it
> was like chewing an elephant - linux community had to attack it in
> pieces..
>
> Yes - it was unfortunately one of those cases where the driver support
> was introduced long back and no binding was introduced at that time (it
> was'nt mandatory then).. then we added a mandatory requirement that it
> be documented in txt.. over years realized things are'nt great with
> unstructured txt description of binding, now moving on converting
> existing txt files to yaml and schemas to static check the dts...
> evolution over the years, I guess.
>
> I am on a fight internally as well to have all our legacy txt files
> converted over to yaml.. and am having to put up a stance - see [2]
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
> [2]
> https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
The problem here is not simple txt->yml conversion: There is no official
binding for spidev yet, just existing users and the driver waiting for them.
>>
>>>
>>> I think we should just drop the node and resubmit - since this is a more
>>> intrusive change and I don't have your platform handy, I am going to
>>> suggest you make a call :(
>>
>> This breaks userspace here, and we would need to carry that node on top.
>>
>
> Uggh... that sucks.. but I think that would be lower tradeoff to make
> than me (as it stands now) having to drop the patch series.
>
>> BTW, I already brought up the topic internally to get you some boards
>> for testing.
>
> Thanks.. While it might help me personally to get some on my internal
> farm, it might be good to get them on kernelci as well on the longer
> run.
>
Will keep that on the radar. I definitely want to get it into the CIP
LAVA lab which is testing LTS as well.
>>
>> I've done that and addressed all that I could (former patch 4). We
>> import those from k3, and I don't feel confident how to resolve them.
>> See also v1 of this patch.
>
> Yeah - i noticed that upstream dt-schema has gotten even more stricter
> even though the dts has remained the same.. I need to spend time in
> digging at it.
>
> At this point the only big kicker is the checkpatch stuff which I cant
> let through - if i do that arnd will probably kick everything from my
> PR out :( - which I cant do.
>
Are we talking about spidev here? Then let's drop that node, but I do
need to know how to describe spidev properly
Or is it about those other warnings coming from your dtsi files, now
being surfaced? If you can tell me how to resolve them, I can write patches.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 11.03.21 14:17, Nishanth Menon wrote:
> On 10:37-20210310, Jan Kiszka wrote:
>> From: Jan Kiszka
>> +spidev@0 {
>> +compatible = "rohm,dh2228fv";
>> +spi-max-frequency = <2000>;
>> +reg = <0>;
>
> Jan,
>
> As part of my final sanity checks, I noticed that we missed this: is a
> checkpatch warning
>
> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check
> ./Documentation/devicetree/bindings/
> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> compatible = "rohm,dh2228fv";
>
> I cannot pick up nodes that are'nt documented as yaml in
> Documentation/devicetree
>
> I know this is irritating to find such nodes that already have previous
> users and the person coming last gets to deal with "new rules".. but
> sorry for catching this so late.
>
> Here are the options that come to mind:
>
> option 1) - drop the node and resubmit.
>
> option 2) - get the documentation into linux master tree and then submit
> the patches.
>
As you said, I'm not setting a precedence here:
arch/arm/boot/dts/imx28-cfa10049.dts: compatible =
"rohm,dh2228fv";
arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible =
"rohm,dh2228fv";
drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
Was just just never documented as binding? Or why is no one allowed to
use this anymore? What is to be used instead for spidev?
>
> I think we should just drop the node and resubmit - since this is a more
> intrusive change and I don't have your platform handy, I am going to
> suggest you make a call :(
This breaks userspace here, and we would need to carry that node on top.
BTW, I already brought up the topic internally to get you some boards
for testing.
>
> Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
> see more than a few warnings there which may need some closer look.
>
I've done that and addressed all that I could (former patch 4). We
import those from k3, and I don't feel confident how to resolve them.
See also v1 of this patch.
Jan
>
> A full log against linux-next is here:
> https://pastebin.ubuntu.com/p/qR69h28c5f/
>
>
> PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
>
> I have been using my script to verify with kpv -C -V -n num_patches and
> then digging through the logs.
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
On 11.03.21 13:56, Nishanth Menon wrote:
> On 19:36-20210310, Bajjuri, Praneeth wrote:
>>
>>
>> On 2/20/2021 6:49 AM, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> Add the DT entry for a watchdog based on RTI1.
>>>
>>> On SR1.0 silicon, it requires additional firmware on the MCU R5F cores
>>> to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As
>>> this firmware will also lock the power domain to protect it against
>>> premature shutdown, mark it shared.
>>>
>>> Signed-off-by: Jan Kiszka
>>
>> Acked-by: Praneeth Bajjuri
>>
>>> ---
>>> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> index 7454c8cec0cc..903796bf7d64 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> @@ -308,4 +308,13 @@ mcu_r5fss0_core1: r5f@4140 {
>>> ti,loczrama = <1>;
>>> };
>>> };
>>> +
>>> + mcu_rti1: rti@4061 {
>
> Jan, I was about to pick up the patches and was running through
> my sanity checks and the following caught my eye with dtbs_check
> (dtschema is at 2021.2.1) test against next-20210311
>
> /workdir/arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: rti@4061:
> $nodename:0: 'rti@4061' does not match '^watchdog(@.*|-[0-9a-f])?$'
>
> Please use watchdog@4061 instead of rti@4061
>
> Since this is a minor change, I have done this change locally. let me
> know if you have an issue and I can drop it off my branch for a new
> version.
>
That's fine, thanks for fixing up - still learning such details.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
[PATCH v4 1/3] dt-bindings: Add Siemens vendor prefix
From: Jan Kiszka Add prefix for Siemens AG. Signed-off-by: Jan Kiszka Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f6064d84a424..91f99130a933 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1024,6 +1024,8 @@ patternProperties: description: Silex Insight "^siliconmitus,.*": description: Silicon Mitus, Inc. + "^siemens,.*": +description: Siemens AG "^simtek,.*": description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": -- 2.26.2
[PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
From: Jan Kiszka
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link:
https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka
Reviewed-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 784 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 386ef98ccf7d..d56c742f5a10 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index ..34bca374bb76
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include
+
+/ {
+ aliases {
+ spi0 = _spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x0281";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e80 {
+ reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa000 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a010 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa010 0 0xf0>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a100 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa100 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a110 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa110 0 0xf0>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a200 {
+ reg = <0x00 0xa200 0x00 0x0020>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ status-led-red {
+ gpios = <_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+
[PATCH v4 2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
From: Jan Kiszka These boards are based on AM6528 GP and AM6548 HS SOCs. Signed-off-by: Jan Kiszka Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index a9e7f981631e..c5aa362e4026 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -23,6 +23,8 @@ properties: items: - enum: - ti,am654-evm + - siemens,iot2050-basic + - siemens,iot2050-advanced - const: ti,am654 - description: K3 J721E SoC -- 2.26.2
[PATCH v4 0/3] arm64: Add TI AM65x-based IOT2050 boards
Changes in v4: - rebased over ti-k3-dts-next and resent completely (no changes) - added ack and review tags Jan Jan Kiszka (3): dt-bindings: Add Siemens vendor prefix dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards arm64: dts: ti: Add support for Siemens IOT2050 boards .../devicetree/bindings/arm/ti/k3.yaml| 2 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm64/boot/dts/ti/Makefile | 2 + .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++ .../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++ .../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++ 6 files changed, 788 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts -- 2.26.2
Re: [PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 09.03.21 16:10, Nishanth Menon wrote: > On 09:38-20210309, Jan Kiszka wrote: >> From: Jan Kiszka >> >> Add support for two Siemens SIMATIC IOT2050 variants, Basic and >> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus >> differ in their number of cores and availability of security features. >> Furthermore the Advanced version comes with more RAM, an eMMC and a few >> internal differences. >> >> Based on original version by Le Jin. >> >> Link: >> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html >> Link: https://github.com/siemens/meta-iot2050 >> Signed-off-by: Jan Kiszka >> Reviewed-by: Vignesh Raghavendra >> --- > > Jan, > > I am not sure if > https://lore.kernel.org/linux-arm-kernel/20210304160712.8452-2-s-a...@ti.com/ > is going to impact your platform. I am planning on picking that series up > today. > might be good to test against tomorrow's next - running through my basic > tests right now before committing to the ICSS-G nodes being picked up. > > If you could repost after testing against tomorrow's next, it will > probably be better. Thanks, I was already on CC. That series does not affect the board features as configured in this patch. However, we are eagerly awaiting ISCCG and then PRU Ethernet support in upstream as this is used on our boards, with both SR1.0 and (upcoming) SR2.0. However, I can update [1] with that series and retest our staging integration. But as you can see from the topmost commit, it is constantly shaking as upstreaming goes on. Jan [1] https://github.com/siemens/linux/commits/jan/iot2050 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 09.03.21 15:41, Nishanth Menon wrote: > On 09:38-20210309, Jan Kiszka wrote: >> From: Jan Kiszka >> >> Add support for two Siemens SIMATIC IOT2050 variants, Basic and >> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus >> differ in their number of cores and availability of security features. >> Furthermore the Advanced version comes with more RAM, an eMMC and a few >> internal differences. >> >> Based on original version by Le Jin. >> >> Link: >> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html >> Link: https://github.com/siemens/meta-iot2050 >> Signed-off-by: Jan Kiszka >> Reviewed-by: Vignesh Raghavendra > > Jan, > > Could you post the full series as V3 please? it works better > that way for b4 workflow for me. > Sure, give me a minute. All 4 patches then, I assume. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
From: Jan Kiszka
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link:
https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka
Reviewed-by: Vignesh Raghavendra
---
Changes in v3:
- address review comments of Vignesh regarding names and node enabling
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 784 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 65506f21ba30..22108491f16e 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index ..34bca374bb76
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include
+
+/ {
+ aliases {
+ spi0 = _spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x0281";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e80 {
+ reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa000 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a010 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa010 0 0xf0>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a100 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa100 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a110 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa110 0 0xf0>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a200 {
+ reg = <0x00 0xa200 0x00 0x0020>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ status-led-red {
+ gpios = <_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+
Re: [PATCH v2 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 04.03.21 07:58, Vignesh Raghavendra wrote:
> Hi,
>
> On 2/12/21 1:02 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Add support for two Siemens SIMATIC IOT2050 variants, Basic and
>> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
>> differ in their number of cores and availability of security features.
>> Furthermore the Advanced version comes with more RAM, an eMMC and a few
>> internal differences.
>>
>> Based on original version by Le Jin.
>>
>> Link:
>> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
>> Link: https://github.com/siemens/meta-iot2050
>> Signed-off-by: Jan Kiszka
>
> Reviewed-by: Vignesh Raghavendra
>
Thanks!
> Few minor comments below:
>
> [...]
>
>> +
>> +_i2c0 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_i2c0_pins_default>;
>> +clock-frequency = <40>;
>> +
>> +psu: tps62363@60 {
>
> Please use generic node names:
>
> psu: regulator@60 { ... };
>
Done.
>> +compatible = "ti,tps62363";
>> +reg = <0x60>;
>> +regulator-name = "tps62363-vout";
>> +regulator-min-microvolt = <50>;
>> +regulator-max-microvolt = <150>;
>> +regulator-boot-on;
>> +ti,vsel0-state-high;
>> +ti,vsel1-state-high;
>> +ti,enable-vout-discharge;
>> +};
>> +
>> +/* D4200 */
>> +pcal9535_1: gpio@20 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x20>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
>> +"A5-pull", "", "",
>> +"IO14-enable", "IO15-enable", "IO16-enable",
>> +"IO17-enable", "IO18-enable", "IO19-enable";
>> +};
>> +
>> +/* D4201 */
>> +pcal9535_2: gpio@21 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x21>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"IO0-direction", "IO1-direction", "IO2-direction",
>> +"IO3-direction", "IO4-direction", "IO5-direction",
>> +"IO6-direction", "IO7-direction",
>> +"IO8-direction", "IO9-direction", "IO10-direction",
>> +"IO11-direction", "IO12-direction", "IO13-direction",
>> +"IO19-direction";
>> +};
>> +
>> +/* D4202 */
>> +pcal9535_3: gpio@25 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x25>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
>> +"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
>> +"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
>> +"IO12-pull", "IO13-pull";
>> +};
>> +};
>
> [...]
>
>> +_0 {
>> +status = "okay";
>> +};
>> +
>> +_phy {
>> +status = "okay";
>> +};
>> +
>
> These nodes are enabled by default right? Above is redundant.
Seems like historic left-overs here - fixed.
>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins_default>;
>> +dr_mode = "host";
>> +};
>> +
>> +_1 {
>> +status = "okay";
>> +};
>> +
>> +_phy {
>> +status = "okay";
>> +};
>> +
>
> Same here...
Also fixed.
>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins_default>;
>> +dr_mode = "host";
>> +};
>> +
>
> [...
Re: [PATCH 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
On 03.03.21 15:21, Henning Schild wrote:
> Hi,
>
> thanks for the fast and thorough review!
>
> Am Tue, 2 Mar 2021 10:38:19 -0800
> schrieb Guenter Roeck :
>
>> On 3/2/21 8:33 AM, Henning Schild wrote:
>>> From: Henning Schild
>>>
>>> This driver adds initial support for several devices from Siemens.
>>> It is based on a platform driver introduced in an earlier commit.
>>>
>>> Signed-off-by: Gerd Haeussler
>>> Signed-off-by: Henning Schild
>>> ---
>>> drivers/watchdog/Kconfig | 11 ++
>>> drivers/watchdog/Makefile | 1 +
>>> drivers/watchdog/simatic-ipc-wdt.c | 305
>>> + 3 files changed, 317 insertions(+)
>>> create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>>> index 1fe0042a48d2..948497eb4bef 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>> @@ -1575,6 +1575,17 @@ config NIC7018_WDT
>>> To compile this driver as a module, choose M here: the
>>> module will be called nic7018_wdt.
>>>
>>> +config SIEMENS_SIMATIC_IPC_WDT
>>> + tristate "Siemens Simatic IPC Watchdog"
>>> + depends on SIEMENS_SIMATIC_IPC
>>> + select WATCHDOG_CORE
>>> + help
>>> + This driver adds support for several watchdogs found in
>>> Industrial
>>> + PCs from Siemens.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> module will be
>>> + called simatic-ipc-wdt.
>>> +
>>> # M68K Architecture
>>>
>>> config M54xx_WATCHDOG
>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>>> index f3a6540e725e..7f5c73ec058c 100644
>>> --- a/drivers/watchdog/Makefile
>>> +++ b/drivers/watchdog/Makefile
>>> @@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
>>> obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
>>> obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
>>> obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
>>> +obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
>>>
>>> # M68K Architecture
>>> obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
>>> diff --git a/drivers/watchdog/simatic-ipc-wdt.c
>>> b/drivers/watchdog/simatic-ipc-wdt.c new file mode 100644
>>> index ..b5c8b7ceb404
>>> --- /dev/null
>>> +++ b/drivers/watchdog/simatic-ipc-wdt.c
>>> @@ -0,0 +1,305 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Siemens SIMATIC IPC driver for Watchdogs
>>> + *
>>> + * Copyright (c) Siemens AG, 2020-2021
>>> + *
>>> + * Authors:
>>> + * Gerd Haeussler
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License version 2
>>> as
>>> + * published by the Free Software Foundation.
>>
>> Covered by SPDX-License-Identifier
>>
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include > +#include
>>> +#include
>>
>> Alphabetic order please
>>
>>> +
>>> +#define WD_ENABLE_IOADR0x62
>>> +#define WD_TRIGGER_IOADR 0x66
>>> +#define GPIO_COMMUNITY0_PORT_ID 0xaf
>>> +#define PAD_CFG_DW0_GPP_A_23 0x4b8
>>
>> Please increase indentation and spare another tab
>>
>>> +#define SAFE_EN_N_427E 0x01
>>> +#define SAFE_EN_N_227E 0x04
>>> +#define WD_ENABLED 0x01
>>> +
>>> +#define TIMEOUT_MIN2
>>> +#define TIMEOUT_DEF64
>>> +#define TIMEOUT_MAX64
>>> +
>>> +#define GP_STATUS_REG_227E 0x404D /* IO PORT for
>>> SAFE_EN_N on 227E */ +
>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>>> +module_param(nowayout, bool, );
>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
>>> started (default="
>>> +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>>> +
>>> +static DEFINE_SPINLOCK(io_lock); /* the lock for io
>>> operations */ +static struct watchdog_device wdd;
>>> +
>>
>> Having two variables named 'wdd' is confusing. Please chose another
>> name.
>>
>>> +static struct resource gp_status_reg_227e_res =
>>> + DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1,
>>> KBUILD_MODNAME); +
>>> +static struct resource io_resource =
>>> + DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
>>> + KBUILD_MODNAME " WD_ENABLE_IOADR");
>>> +
>>> +/* the actual start will be discovered with pci, 0 is a
>>> placeholder */ +static struct resource mem_resource =
>>> + DEFINE_RES_MEM_NAMED(0, SZ_4, "WD_RESET_BASE_ADR");
>>> +
>>> +static u32 wd_timeout_table[] = {2, 4, 6, 8, 16, 32, 48, 64 };
>>> +static void __iomem *wd_reset_base_addr;
>>> +
>>> +static int get_timeout_idx(u32 timeout)
>>> +{
>>> + int i;
>>> +
>>> + i = ARRAY_SIZE(wd_timeout_table) - 1;
>>> + for (; i >= 0; i--) {
>>> + if (timeout >= wd_timeout_table[i])
>>> + break;
>>> + }
>>> +
>>> + return i;
>>> +}
>>
>> Please add a comment explaining why you don't use find_closest().
>
> Will not be a comment but we will switch to using this,
Re: [PATCH] scripts/gdb: document lx_current is only supported by x86
On 22.02.21 22:18, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-
>> From: Kieran Bingham [mailto:kieran.bing...@ideasonboard.com]
>> Sent: Tuesday, February 23, 2021 12:06 AM
>> To: Song Bao Hua (Barry Song) ; cor...@lwn.net;
>> linux-...@vger.kernel.org; jan.kis...@siemens.com
>> Cc: linux-kernel@vger.kernel.org; linux...@openeuler.org
>> Subject: Re: [PATCH] scripts/gdb: document lx_current is only supported by
>> x86
>>
>> Hi Barry
>>
>> On 21/02/2021 21:35, Barry Song wrote:
>>> lx_current depends on the per_cpu current_task which exists on x86 only:
>>>
>>> arch$ git grep current_task | grep -i per_cpu
>>> x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *,
>> current_task);
>>> x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task)
>> cacheline_aligned =
>>> x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
>>> x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task)
>> = _task;
>>> x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
>>> x86/kernel/smpboot.c: per_cpu(current_task, cpu) = idle;
>>>
>>> On other architectures, lx_current() will lead to a python exception:
>>> (gdb) p $lx_current().pid
>>> Python Exception No symbol "current_task" in current
>> context.:
>>> Error occurred in Python: No symbol "current_task" in current context.
>>>
>>> To avoid more people struggling and wasting time in other architectures,
>>> document it.
>>>
>>> Cc: Jan Kiszka
>>> Signed-off-by: Barry Song
>>> ---
>>> Documentation/dev-tools/gdb-kernel-debugging.rst | 2 +-
>>> scripts/gdb/linux/cpus.py| 10 --
>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst
>> b/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> index 4756f6b3a04e..1586901b683c 100644
>>> --- a/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> +++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> @@ -114,7 +114,7 @@ Examples of using the Linux-provided gdb helpers
>>> [ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
>> reserved
>>>
>>>
>>> -- Examine fields of the current task struct::
>>> +- Examine fields of the current task struct(supported by x86 only)::
>>>
>>> (gdb) p $lx_current().pid
>>> $1 = 4998
>>> diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
>>> index 008e62f3190d..f382762509d3 100644
>>> --- a/scripts/gdb/linux/cpus.py
>>> +++ b/scripts/gdb/linux/cpus.py
>>> @@ -156,6 +156,13 @@ Note that VAR has to be quoted as string."""
>>>
>>> PerCpu()
>>>
>>> +def get_current_task(cpu):
>>> +if utils.is_target_arch("x86"):
>>> + var_ptr = gdb.parse_and_eval("_task")
>>> + return per_cpu(var_ptr, cpu).dereference()
>>> +else:
>>> +raise gdb.GdbError("Sorry, obtaining the current task is not yet "
>>> + "supported with this arch")
>>
>> I've wondered in the past how we should handle the architecture specific
>> layers.
>>
>> Perhaps we need to have an interface of functionality to implement on
>> each architecture so that we can create a per-arch set of helpers.
>>
>> or break it up into arch specific subdirs at least...
>>
>>
>>> class LxCurrentFunc(gdb.Function):
>>> """Return current task.
>>> @@ -167,8 +174,7 @@ number. If CPU is omitted, the CPU of the current
>>> context
>> is used."""
>>> super(LxCurrentFunc, self).__init__("lx_current")
>>>
>>> def invoke(self, cpu=-1):
>>> -var_ptr = gdb.parse_and_eval("_task")
>>> -return per_cpu(var_ptr, cpu).dereference()
>>> +return get_current_task(cpu)
>>>
>>
>> And then perhaps we simply shouldn't even expose commands which can not
>> be supported on those architectures?
>
> I feel it is better to tell users this function is not supported on its arch
> than simply hiding the function.
>
> If we hide it, users still have many chances to try it as they have got
> information of lx_current from go
[PATCH] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1.
On SR1.0 silicon, it requires additional firmware on the MCU R5F cores
to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As
this firmware will also lock the power domain to protect it against
premature shutdown, mark it shared.
Signed-off-by: Jan Kiszka
---
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 7454c8cec0cc..903796bf7d64 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -308,4 +308,13 @@ mcu_r5fss0_core1: r5f@4140 {
ti,loczrama = <1>;
};
};
+
+ mcu_rti1: rti@4061 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x0 0x4061 0x0 0x100>;
+ clocks = <_clks 135 0>;
+ power-domains = <_pds 135 TI_SCI_PD_SHARED>;
+ assigned-clocks = <_clks 135 0>;
+ assigned-clock-parents = <_clks 135 4>;
+ };
};
--
2.26.2
Re: [PATCH] spi: pca2xx-pci: Fix an issue about missing call to 'pci_free_irq_vectors()'
On 15.02.21 14:22, Andy Shevchenko wrote:
> On Sun, Feb 14, 2021 at 10:57:46PM +0800, Dejin Zheng wrote:
>> Call to 'pci_free_irq_vectors()' are missing both in the error handling
>> path of the probe function, and in the remove function. So add them.
>
> I'm wondering if you noticed that it's done by pcim_* API.
> Perhaps you can introduce pcim_alloc_irq_vectors() or so and do not add these
> calls at all?
You mean as plain wrapper for pci_alloc_irq_vectors, just to document
it's managed?
>
>> Fixes: 64e02cb0bdfc7c ("spi: pca2xx-pci: Allow MSI")
>
> No, it doesn't fix anything.
>
Ah, now I recall: imbalanced APIs.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] spi: pca2xx-pci: Fix an issue about missing call to 'pci_free_irq_vectors()'
On 14.02.21 15:57, Dejin Zheng wrote:
> Call to 'pci_free_irq_vectors()' are missing both in the error handling
> path of the probe function, and in the remove function. So add them.
>
> Fixes: 64e02cb0bdfc7c ("spi: pca2xx-pci: Allow MSI")
> Signed-off-by: Dejin Zheng
> ---
> drivers/spi/spi-pxa2xx-pci.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
> index 14fc41ed2361..1ec840e78ff4 100644
> --- a/drivers/spi/spi-pxa2xx-pci.c
> +++ b/drivers/spi/spi-pxa2xx-pci.c
> @@ -254,8 +254,10 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
> snprintf(buf, sizeof(buf), "pxa2xx-spi.%d", ssp->port_id);
> ssp->clk = clk_register_fixed_rate(>dev, buf , NULL, 0,
> c->max_clk_rate);
> - if (IS_ERR(ssp->clk))
> - return PTR_ERR(ssp->clk);
> + if (IS_ERR(ssp->clk)) {
> + ret = PTR_ERR(ssp->clk);
> + goto err_irq;
> + }
>
> memset(, 0, sizeof(pi));
> pi.fwnode = dev->dev.fwnode;
> @@ -268,12 +270,16 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
> pdev = platform_device_register_full();
> if (IS_ERR(pdev)) {
> clk_unregister(ssp->clk);
> - return PTR_ERR(pdev);
> + ret = PTR_ERR(pdev);
> + goto err_irq;
> }
>
> pci_set_drvdata(dev, pdev);
>
> return 0;
> +err_irq:
> + pci_free_irq_vectors(dev);
> + return ret;
> }
>
> static void pxa2xx_spi_pci_remove(struct pci_dev *dev)
> @@ -283,6 +289,7 @@ static void pxa2xx_spi_pci_remove(struct pci_dev *dev)
>
> spi_pdata = dev_get_platdata(>dev);
>
> + pci_free_irq_vectors(dev);
> platform_device_unregister(pdev);
> clk_unregister(spi_pdata->ssp.clk);
> }
>
Reviewed-by: Jan Kiszka
Thanks!
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v2 0/4] arm64: Add TI AM65x-based IOT2050 boards
On 11.02.21 20:32, Jan Kiszka wrote: > Changes in v2: > - address board-specific issues found by kernel_verify_patch > - remove dead l2-cache node from iot2050-basic DT > - add binding for Siemens vendor prefix > - factor out board bindings into separate patch > - add missing device_type to common ti,am654-pcie-rc nodes > > Jan > > Jan Kiszka (4): > dt-bindings: Add Siemens vendor prefix > dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards > arm64: dts: ti: Add support for Siemens IOT2050 boards > arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes > > .../devicetree/bindings/arm/ti/k3.yaml| 2 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/arm64/boot/dts/ti/Makefile | 2 + > .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 679 ++ > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 + > .../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++ > .../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++ > 7 files changed, 808 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts > create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts > Forgot to include the requested boot log. Here it comes for the basic variant: [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 5.11.0-rc7+ (jan@md1f2u6c) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #113 SMP PREEMPT Thu Feb 11 21:26:46 CET 2021 [0.00] Machine model: SIMATIC IOT2050 Basic [0.00] earlycon: ns16550a0 at MMIO32 0x0281 (options '') [0.00] printk: bootconsole [ns16550a0] enabled [0.00] Reserved memory: created DMA memory pool at 0xa000, size 1 MiB [0.00] OF: reserved mem: initialized node r5f-dma-memory@a000, compatible id shared-dma-pool [0.00] Reserved memory: created DMA memory pool at 0xa010, size 15 MiB [0.00] OF: reserved mem: initialized node r5f-memory@a010, compatible id shared-dma-pool [0.00] Reserved memory: created DMA memory pool at 0xa100, size 1 MiB [0.00] OF: reserved mem: initialized node r5f-dma-memory@a100, compatible id shared-dma-pool [0.00] Reserved memory: created DMA memory pool at 0xa110, size 15 MiB [0.00] OF: reserved mem: initialized node r5f-memory@a110, compatible id shared-dma-pool [0.00] Zone ranges: [0.00] DMA [mem 0x8000-0xbfff] [0.00] DMA32empty [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8000-0x9e7f] [0.00] node 0: [mem 0xa220-0xbfff] [0.00] Initmem setup node 0 [mem 0x8000-0xbfff] [0.00] On node 0 totalpages: 247296 [0.00] DMA zone: 4096 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 247296 pages, LIFO batch:63 [0.00] cma: Reserved 24 MiB at 0xbc40 [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: Trusted OS migration not required [0.00] psci: SMC Calling Convention v1.2 [0.00] percpu: Embedded 22 pages/cpu s49560 r8192 d32360 u90112 [0.00] pcpu-alloc: s49560 r8192 d32360 u90112 alloc=22*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Detected VIPT I-cache on CPU0 [0.00] CPU features: detected: ARM erratum 845719 [0.00] CPU features: detected: GIC system register CPU interface [0.00] Built 1 zonelists, mobility grouping on. Total pages: 243200 [0.00] Kernel command line: root=PARTUUID=e4abca5c-738d-48cd-ac11-7e578c11d495 console=ttyS3,115200n8 earlycon=ns16550a,mmio32,0x0281 mtdparts=4704.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),128k(ospi.env),128k(ospi.env.backup),1m(ospi.sysfw),64k(pru0-fw),64k(pru1-fw),64k(rtu0-fw),64k(rtu1-fw),-@8m(ospi.rootfs) rw rootwait [0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 926684K/989184K available (10560K kernel code, 1038K rwdata, 3976K rodata, 1600K init, 390K bss, 37924K reserved, 24576K cma-reserved) [0.
[PATCH v2 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
From: Jan Kiszka
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link:
https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 679 ++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 802 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 65506f21ba30..22108491f16e 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index ..28e31c219a33
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,679 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include
+
+/ {
+ aliases {
+ spi0 = _spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x0281";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e80 {
+ reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa000 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a010 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa010 0 0xf0>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a100 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa100 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a110 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa110 0 0xf0>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a200 {
+ reg = <0x00 0xa200 0x00 0x0020>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ status-led-red {
+ gpios = <_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1920>;
[PATCH v2 1/4] dt-bindings: Add Siemens vendor prefix
From: Jan Kiszka Add prefix for Siemens AG. Signed-off-by: Jan Kiszka --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 041ae90b0d8f..ff4e8f1b1557 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1014,6 +1014,8 @@ patternProperties: description: Silex Insight "^siliconmitus,.*": description: Silicon Mitus, Inc. + "^siemens,.*": +description: Siemens AG "^simtek,.*": description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": -- 2.26.2
[PATCH v2 2/4] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
From: Jan Kiszka These boards are based on AM6528 GP and AM6548 HS SOCs. Signed-off-by: Jan Kiszka --- Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index c6e1c1e63e43..b1ab0cf4a2d6 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -23,6 +23,8 @@ properties: items: - enum: - ti,am654-evm + - siemens,iot2050-basic + - siemens,iot2050-advanced - const: ti,am654 - description: K3 J721E SoC -- 2.26.2
[PATCH v2 0/4] arm64: Add TI AM65x-based IOT2050 boards
Changes in v2: - address board-specific issues found by kernel_verify_patch - remove dead l2-cache node from iot2050-basic DT - add binding for Siemens vendor prefix - factor out board bindings into separate patch - add missing device_type to common ti,am654-pcie-rc nodes Jan Jan Kiszka (4): dt-bindings: Add Siemens vendor prefix dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards arm64: dts: ti: Add support for Siemens IOT2050 boards arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes .../devicetree/bindings/arm/ti/k3.yaml| 2 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm64/boot/dts/ti/Makefile | 2 + .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 679 ++ arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 + .../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++ .../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++ 7 files changed, 808 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts -- 2.26.2
[PATCH v2 4/4] arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes
From: Jan Kiszka
This is demanded by the parent binding of ti,am654-pcie-rc, see
Documentation/devicetree/bindings/pci/designware-pcie.txt.
Signed-off-by: Jan Kiszka
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 12591a854020..787a49523c35 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -707,6 +707,7 @@ pcie0_rc: pcie@550 {
dma-coherent;
interrupts = ;
msi-map = <0x0 _its 0x0 0x1>;
+ device_type = "pci";
};
pcie0_ep: pcie-ep@550 {
@@ -739,6 +740,7 @@ pcie1_rc: pcie@560 {
dma-coherent;
interrupts = ;
msi-map = <0x0 _its 0x1 0x1>;
+ device_type = "pci";
};
pcie1_ep: pcie-ep@560 {
--
2.26.2
Re: [PATCH] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 09.02.21 15:44, Nishanth Menon wrote: > Jan, > > A few quick scan comments below, you might need to post based off > 5.12-rc1 once available.. > > Also, I see a bit of warnings with dtbs_check, which probably needs a > little more digging into (pcie insists to get a device_type property, > etc..) > > you could use kernel_patch_verify or > https://github.com/nmenon/kernel_patch_verify/blob/master/Dockerbuild.md > > it throws up a report like this https://pastebin.ubuntu.com/p/SdkZr432z3/ > Ok, will have a look - is that checkpatch on steroids? > So, many of my comments below are just first pass parse of that log -> I > usually do recommend building with W=2 and dtbs_check (with yamlint etc) > to make sure things are a bit sane. Will be good to have additional > eyes. > > On 11:21-20210209, Jan Kiszka wrote: >> From: Jan Kiszka >> >> Add support for two Siemens SIMATIC IOT2050 variants, Basic and >> Advanced. They are based on the TI AM6528 and AM6548 SOCs. >> >> Based on original version by Le Jin. > > Might be good to add links to the boards as well (if available), for > future reference. > Sure, though stability of links is not under my control. But I could additionally drop https://github.com/siemens/meta-iot2050 here. >> >> Signed-off-by: Jan Kiszka >> --- > > Will be nice to see at least a pastebin link for a bootlog on the boards > in the cover-letter / diffstat section with the v2 - for reference. > Sure. >> .../devicetree/bindings/arm/ti/k3.yaml| 2 + >> arch/arm64/boot/dts/ti/Makefile | 4 + >> .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 649 ++ >> .../boot/dts/ti/k3-am6528-iot2050-basic.dts | 56 ++ >> .../dts/ti/k3-am6548-iot2050-advanced.dts | 57 ++ >> 5 files changed, 768 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts >> >> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml >> b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> index c6e1c1e63e43..b1ab0cf4a2d6 100644 >> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml >> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml >> @@ -23,6 +23,8 @@ properties: >> items: >>- enum: >>- ti,am654-evm >> + - siemens,iot2050-basic >> + - siemens,iot2050-advanced > > - In a separate patch, > ./Documentation/devicetree/bindings/vendor-prefixes.yaml -> Could you > make sure we add 'siemens' there? > - and, lets move the bindings to it's own patch, since that is how Rob > prefers to review in > https://patchwork.ozlabs.org/project/devicetree-bindings/list/ > > Both of these patches will need Rob to ack. I think I should be able > to pick the first one up as well to reduce dependency, but we can > check with Rob in case there is a preference. > Ok. >>- const: ti,am654 >> >>- description: K3 J721E SoC >> diff --git a/arch/arm64/boot/dts/ti/Makefile >> b/arch/arm64/boot/dts/ti/Makefile >> index 65506f21ba30..928ea26ce250 100644 >> --- a/arch/arm64/boot/dts/ti/Makefile >> +++ b/arch/arm64/boot/dts/ti/Makefile >> @@ -8,6 +8,10 @@ >> >> dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb >> > > - drop the EOL to club am65 dtbs close to each other > >> +dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb >> + > > - Drop this EOL as well. Something like this: > > dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb > > dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb > >> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb >> + >> dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb >> >> dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi >> b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi >> new file mode 100644 >> index ..de05937dbb60 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi >> @@ -0,0 +1,649 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) Siemens AG, 2018-2021 >> + * > > Optional: might be nice to add a oneliner comment for reuse scope.. > You mean something like "Common
[PATCH] arm64: dts: ti: Add support for Siemens IOT2050 boards
From: Jan Kiszka
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 and AM6548 SOCs.
Based on original version by Le Jin.
Signed-off-by: Jan Kiszka
---
.../devicetree/bindings/arm/ti/k3.yaml| 2 +
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 649 ++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 56 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 57 ++
5 files changed, 768 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml
b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index c6e1c1e63e43..b1ab0cf4a2d6 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -23,6 +23,8 @@ properties:
items:
- enum:
- ti,am654-evm
+ - siemens,iot2050-basic
+ - siemens,iot2050-advanced
- const: ti,am654
- description: K3 J721E SoC
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 65506f21ba30..928ea26ce250 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -8,6 +8,10 @@
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
+
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index ..de05937dbb60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,649 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include
+
+/ {
+ aliases {
+ spi0 = _spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x0280";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure_ddr@9e80 {
+ reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa000 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a010 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa010 0 0xf0>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a100 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa100 0 0x10>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a110 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa110 0 0xf0>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a200 {
+ reg = <0x00 0xa200 0x00 0x0020>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ gpio_leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ status-led-red {
+ gpios = <_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ linux,default-trigger = "gpio";
+ };
+
+ status-led-green {
+ gpios = <_gpio0 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ };
+
+ user-led1-red {
+ gpios = <_3 14 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ };
+
+ user-led1-green {
+ gpios = <_2 15 GPIO_ACTIVE_HIGH>;
+
Re: [PATCH net-next 1/1] stmmac: intel: change all EHL/TGL to auto detect phy addr
On 06.11.20 10:43, Wong Vee Khee wrote:
> From: Voon Weifeng
>
> Set all EHL/TGL phy_addr to -1 so that the driver will automatically
> detect it at run-time by probing all the possible 32 addresses.
>
> Signed-off-by: Voon Weifeng
> Signed-off-by: Wong Vee Khee
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index b6e5e3e36b63..7c1353f37247 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -236,6 +236,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
> int ret;
> int i;
>
> + plat->phy_addr = -1;
> plat->clk_csr = 5;
> plat->has_gmac = 0;
> plat->has_gmac4 = 1;
> @@ -345,7 +346,6 @@ static int ehl_sgmii_data(struct pci_dev *pdev,
> struct plat_stmmacenet_data *plat)
> {
> plat->bus_id = 1;
> - plat->phy_addr = 0;
> plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
>
> plat->serdes_powerup = intel_serdes_powerup;
> @@ -362,7 +362,6 @@ static int ehl_rgmii_data(struct pci_dev *pdev,
> struct plat_stmmacenet_data *plat)
> {
> plat->bus_id = 1;
> - plat->phy_addr = 0;
> plat->phy_interface = PHY_INTERFACE_MODE_RGMII;
>
> return ehl_common_data(pdev, plat);
> @@ -376,7 +375,6 @@ static int ehl_pse0_common_data(struct pci_dev *pdev,
> struct plat_stmmacenet_data *plat)
> {
> plat->bus_id = 2;
> - plat->phy_addr = 1;
> return ehl_common_data(pdev, plat);
> }
>
> @@ -408,7 +406,6 @@ static int ehl_pse1_common_data(struct pci_dev *pdev,
> struct plat_stmmacenet_data *plat)
> {
> plat->bus_id = 3;
> - plat->phy_addr = 1;
> return ehl_common_data(pdev, plat);
> }
>
> @@ -450,7 +447,6 @@ static int tgl_sgmii_data(struct pci_dev *pdev,
> struct plat_stmmacenet_data *plat)
> {
> plat->bus_id = 1;
> - plat->phy_addr = 0;
> plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
> plat->serdes_powerup = intel_serdes_powerup;
> plat->serdes_powerdown = intel_serdes_powerdown;
>
This fixes PHY detection on one of our EHL-based boards. Can this also
be applied to stable 5.10?
Thanks,
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v8 1/1] ns: add binfmt_misc to the user namespace
On 16.12.19 10:12, Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace a new empty binfmt instance is created and
> used in this namespace.
>
> For instance, using "unshare" we can start a chroot of another
> architecture and configure the binfmt_misc interpreter without being root
> to run the binaries in this chroot.
>
> Signed-off-by: Laurent Vivier
> Acked-by: Andrei Vagin
> Tested-by: Henning Schild
> ---
> fs/binfmt_misc.c | 115 +
> include/linux/user_namespace.h | 15 +
> kernel/user.c | 14
> kernel/user_namespace.c| 3 +
> 4 files changed, 119 insertions(+), 28 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index cdb45829354d..17fa1f56ca2e 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -40,9 +40,6 @@ enum {
> VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
> };
>
> -static LIST_HEAD(entries);
> -static int enabled = 1;
> -
> enum {Enabled, Magic};
> #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
> #define MISC_FMT_OPEN_BINARY (1 << 30)
> @@ -62,10 +59,7 @@ typedef struct {
> struct file *interp_file;
> } Node;
>
> -static DEFINE_RWLOCK(entries_lock);
> static struct file_system_type bm_fs_type;
> -static struct vfsmount *bm_mnt;
> -static int entry_count;
>
> /*
> * Max length of the register string. Determined by:
> @@ -82,18 +76,37 @@ static int entry_count;
> */
> #define MAX_REGISTER_LENGTH 1920
>
> +static struct binfmt_namespace *binfmt_ns(struct user_namespace *ns)
> +{
> + struct binfmt_namespace *b_ns;
> +
> + while (ns) {
> + b_ns = READ_ONCE(ns->binfmt_ns);
> + if (b_ns)
> + return b_ns;
> + ns = ns->parent;
> + }
> + /* as the first user namespace is initialized with
> + * _binfmt_ns we should never come here
> + * but we try to stay safe by logging a warning
> + * and returning a sane value
> + */
> + WARN_ON_ONCE(1);
> + return _binfmt_ns;
> +}
> +
> /*
> * Check if we support the binfmt
> * if we do, return the node, else NULL
> * locking is done in load_misc_binary
> */
> -static Node *check_file(struct linux_binprm *bprm)
> +static Node *check_file(struct binfmt_namespace *ns, struct linux_binprm
> *bprm)
> {
> char *p = strrchr(bprm->interp, '.');
> struct list_head *l;
>
> /* Walk all the registered handlers. */
> - list_for_each(l, ) {
> + list_for_each(l, >entries) {
> Node *e = list_entry(l, Node, list);
> char *s;
> int j;
> @@ -135,17 +148,18 @@ static int load_misc_binary(struct linux_binprm *bprm)
> struct file *interp_file = NULL;
> int retval;
> int fd_binary = -1;
> + struct binfmt_namespace *ns = binfmt_ns(current_user_ns());
>
> retval = -ENOEXEC;
> - if (!enabled)
> + if (!ns->enabled)
> return retval;
>
> /* to keep locking time low, we copy the interpreter string */
> - read_lock(_lock);
> - fmt = check_file(bprm);
> + read_lock(>entries_lock);
> + fmt = check_file(ns, bprm);
> if (fmt)
> dget(fmt->dentry);
> - read_unlock(_lock);
> + read_unlock(>entries_lock);
> if (!fmt)
> return retval;
>
> @@ -611,19 +625,19 @@ static void bm_evict_inode(struct inode *inode)
> kfree(e);
> }
>
> -static void kill_node(Node *e)
> +static void kill_node(struct binfmt_namespace *ns, Node *e)
> {
> struct dentry *dentry;
>
> - write_lock(_lock);
> + write_lock(>entries_lock);
> list_del_init(>list);
> - write_unlock(_lock);
> + write_unlock(>entries_lock);
>
> dentry = e->dentry;
> drop_nlink(d_inode(dentry));
> d_drop(dentry);
> dput(dentry);
> - simple_release_fs(_mnt, _count);
> + simple_release_fs(>bm_mnt, >entry_count);
> }
>
> /* / */
> @@ -653,6 +667,9 @@ static ssize_t bm_entry_write(struct file *file, const
> char __user *buffer,
> struct dentry *root;
> Node *e = file_inode(file)->i_private;
> int res = parse_command(buffer, count);
> + struct binfmt_namespace *ns;
> +
> + ns = binfmt_ns(file_dentry(file)->d_sb->s_user_ns);
>
> switch (res) {
> case 1:
> @@ -669,7 +686,7 @@ static ssize_t bm_entry_write(struct file *file, const
> char __user *buffer,
> inode_lock(d_inode(root));
>
> if (!list_empty(>list))
> - kill_node(e);
> + kill_node(ns, e);
>
> inode_unlock(d_inode(root));
> break;
> @@ -695,6 +712,7 @@ static ssize_t bm_register_write(struct file *file, const
>
Re: [PATCH v2] scripts/gdb: fix list_for_each
On 05.01.21 17:51, George Prekas wrote:
> On 9/24/2020 9:20 AM, George Prekas wrote:
>> If the list is uninitialized (next pointer is NULL), list_for_each gets
>> stuck in an infinite loop. Print a message and treat list as empty.
>>
>> Signed-off-by: George Prekas
>> ---
>> scripts/gdb/linux/lists.py | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
>> index c487ddf09d38..bae4d70b7eae 100644
>> --- a/scripts/gdb/linux/lists.py
>> +++ b/scripts/gdb/linux/lists.py
>> @@ -27,6 +27,11 @@ def list_for_each(head):
>> raise TypeError("Must be struct list_head not {}"
>> .format(head.type))
>>
>> + if head['next'] == 0:
>> + gdb.write("list_for_each: Uninitialized list '{}' treated as
>> empty\n"
>> + .format(head.address))
>> + return
>> +
>> node = head['next'].dereference()
>> while node.address != head.address:
>> yield node.address
>
> Happy New Year!
Same to you!
>
> Any updates on this?
>
Sorry, slipped through.
Reviewed-by: Jan Kiszka
Andrew, please pick this up.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v2] gdb: lx-symbols: store the abspath()
On 17.12.20 09:17, Johannes Berg wrote: > From: Johannes Berg > > If we store the relative path, the user might later cd to a > different directory, and that would break the automatic symbol > resolving that happens when a module is loaded into the target > kernel. Fix this by storing the abspath() of each path given, > just like we already do for the cwd (os.getcwd() is absolute.) > > Signed-off-by: Johannes Berg > --- > v2: break the long line > --- > scripts/gdb/linux/symbols.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py > index 1be9763cf8bb..08d264ac328b 100644 > --- a/scripts/gdb/linux/symbols.py > +++ b/scripts/gdb/linux/symbols.py > @@ -164,7 +164,8 @@ lx-symbols command.""" > saved_state['breakpoint'].enabled = saved_state['enabled'] > > def invoke(self, arg, from_tty): > -self.module_paths = [os.path.expanduser(p) for p in arg.split()] > +self.module_paths = [os.path.abspath(os.path.expanduser(p)) > + for p in arg.split()] > self.module_paths.append(os.getcwd()) > > # enforce update > Reviewed-by: Jan Kiszka Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] gdb: correct sys.path insertion
On 16.12.20 14:36, Johannes Berg wrote:
> From: Johannes Berg
>
> Perhaps something got moved around at some point, but the
> current path that gets inserted has "/scripts/gdb" twice,
> since the script is located in scripts/gdb/ already. Fix
> the path.
>
> Signed-off-by: Johannes Berg
> ---
> scripts/gdb/vmlinux-gdb.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
> index 4136dc2c59df..476da5b6a7ca 100644
> --- a/scripts/gdb/vmlinux-gdb.py
> +++ b/scripts/gdb/vmlinux-gdb.py
> @@ -13,7 +13,7 @@
>
> import os
>
> -sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb")
> +sys.path.insert(0, os.path.dirname(__file__))
>
> try:
> gdb.parse_and_eval("0")
>
How did you test that, which setup? I just ran "gdb
/build/vmlinux", and "python print(sys.path)" didn't expose this
duplication. So your change would actually break that common case.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] gdb: lx-symbols: store the abspath()
On 16.12.20 14:56, Johannes Berg wrote: > From: Johannes Berg > > If we store the relative path, the user might later cd to a > different directory, and that would break the automatic symbol > resolving that happens when a module is loaded into the target > kernel. Fix this by storing the abspath() of each path given, > just like we already do for the cwd (os.getcwd() is absolute.) > > Signed-off-by: Johannes Berg > --- > scripts/gdb/linux/symbols.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py > index 1be9763cf8bb..e651c335deb6 100644 > --- a/scripts/gdb/linux/symbols.py > +++ b/scripts/gdb/linux/symbols.py > @@ -164,7 +164,7 @@ lx-symbols command.""" > saved_state['breakpoint'].enabled = saved_state['enabled'] > > def invoke(self, arg, from_tty): > -self.module_paths = [os.path.expanduser(p) for p in arg.split()] > +self.module_paths = [os.path.abspath(os.path.expanduser(p)) for p in > arg.split()] > self.module_paths.append(os.getcwd()) > > # enforce update > Looks good, we just tried to stay within 80 chars line length also with the python scripts. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v5 0/7] gpio: exar: refactor the driver
On 23.11.20 13:12, Bartosz Golaszewski wrote: > Thanks!On Mon, Nov 23, 2020 at 1:03 PM Jan Kiszka > wrote: >> >> On 23.11.20 12:38, Bartosz Golaszewski wrote: >>> On Mon, Nov 16, 2020 at 11:42 AM Bartosz Golaszewski wrote: >>>> >>>> From: Bartosz Golaszewski >>>> >>>> I just wanted to convert the driver to using simpler IDA API but ended up >>>> quickly converting it to using regmap. Unfortunately I don't have the HW >>>> to test it so marking the patches that introduce functional change as RFT >>>> and Cc'ing the original author. >>>> >>> >>> Hi Jan! >>> >>> Could you give this last version a final spin before I merge it? >>> >> >> [ 14.250117] exar_serial :02:00.0: enabling device ( -> 0002) >> [ 14.336622] :02:00.0: ttyS2 at MMIO 0x9000 (irq = 44, base_baud = >> 7812500) is a XR17V35X >> [ 14.391588] :02:00.0: ttyS3 at MMIO 0x9400 (irq = 44, base_baud = >> 7812500) is a XR17V35X >> [ 19.250510] gpio_exar: probe of gpio_exar.1.auto failed with error -22 >> >> That's "new"... >> > > And if you change reg_bits from 11 to 16? > 16 works. Didn't we have that already? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v5 0/7] gpio: exar: refactor the driver
On 23.11.20 12:58, Jan Kiszka wrote: > On 23.11.20 12:38, Bartosz Golaszewski wrote: >> On Mon, Nov 16, 2020 at 11:42 AM Bartosz Golaszewski wrote: >>> >>> From: Bartosz Golaszewski >>> >>> I just wanted to convert the driver to using simpler IDA API but ended up >>> quickly converting it to using regmap. Unfortunately I don't have the HW >>> to test it so marking the patches that introduce functional change as RFT >>> and Cc'ing the original author. >>> >> >> Hi Jan! >> >> Could you give this last version a final spin before I merge it? >> > > [ 14.250117] exar_serial :02:00.0: enabling device ( -> 0002) > [ 14.336622] :02:00.0: ttyS2 at MMIO 0x9000 (irq = 44, base_baud = > 7812500) is a XR17V35X > [ 14.391588] :02:00.0: ttyS3 at MMIO 0x9400 (irq = 44, base_baud = > 7812500) is a XR17V35X > [ 19.250510] gpio_exar: probe of gpio_exar.1.auto failed with error -22 > > That's "new"... > Bisected to "gpio: exar: switch to using regmap" again. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v5 0/7] gpio: exar: refactor the driver
On 23.11.20 12:38, Bartosz Golaszewski wrote: > On Mon, Nov 16, 2020 at 11:42 AM Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> I just wanted to convert the driver to using simpler IDA API but ended up >> quickly converting it to using regmap. Unfortunately I don't have the HW >> to test it so marking the patches that introduce functional change as RFT >> and Cc'ing the original author. >> > > Hi Jan! > > Could you give this last version a final spin before I merge it? > [ 14.250117] exar_serial :02:00.0: enabling device ( -> 0002) [ 14.336622] :02:00.0: ttyS2 at MMIO 0x9000 (irq = 44, base_baud = 7812500) is a XR17V35X [ 14.391588] :02:00.0: ttyS3 at MMIO 0x9400 (irq = 44, base_baud = 7812500) is a XR17V35X [ 19.250510] gpio_exar: probe of gpio_exar.1.auto failed with error -22 That's "new"... Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")
On 22.11.20 17:35, Michał Mirosław wrote:
> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
>> On 09.11.20 00:28, Qu Wenruo wrote:
>>> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>>>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
> [...]
>>>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>>>> creating regulator") seems to be the cause.
> [...]
>> We are still missing some magic fix for stable trees: On the STM32MP15x,
>> things are broken since 5.4.73 now. And 5.9.y is not booting as well on
>> that board. Reverting the original commit make it boot again.
>>
>> Linus master is fine, though, but I'm tired of bisecting. Any
>> suggestions? Or is there something queued up already?
>
> You might want to look at `git log --grep=aea6cb99703e` if you can't
> wait for a stable backport.
>
Good. Is that flagged and tested for 5.9/5.4 (and whatever is also
affected) already?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator")
On 09.11.20 00:28, Qu Wenruo wrote:
>
>
> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>>> Hi Michał,
>>>
>>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
>>> from NVME.
>>>
>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>> creating regulator") seems to be the cause.
>>>
>>> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
>>> provided by RK808 regulator.
>>> With that commit, now RK808 regulator fails to register:
>>>
>>> [1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
>>> [1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
>>> [1.419856] rk808 0-001b: failed to register 12 regulator
>>> [1.422801] rk808-regulator: probe of rk808-regulator failed with
>>> error -22
>>
>> Hi,
>>
>> This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer
>> probe when trying to get voltage from unresolved supply") recently accepted
>> to regulator tree [1]. Can you verify this?
>
> Thanks, tested with that commit cherry picked to v5.10-rc2 and it solves
> the problem.
>
We are still missing some magic fix for stable trees: On the STM32MP15x,
things are broken since 5.4.73 now. And 5.9.y is not booting as well on
that board. Reverting the original commit make it boot again.
Linus master is fine, though, but I'm tired of bisecting. Any
suggestions? Or is there something queued up already?
In any case: Is that board in no stable Q farm? It's a basic "boot
fails" regression.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v3 6/7] gpio: exar: switch to using regmap
On 10.11.20 15:30, Bartosz Golaszewski wrote:
> On Tue, Nov 10, 2020 at 3:26 PM Andy Shevchenko
> wrote:
>>
>> On Tue, Nov 10, 2020 at 04:26:24PM +0200, Andy Shevchenko wrote:
>>> On Tue, Nov 10, 2020 at 01:34:05PM +0100, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
We can simplify the code in gpio-exar by using regmap. This allows us to
drop the mutex (regmap provides its own locking) and we can also reuse
regmap's bit operations instead of implementing our own update function.
>>>
>>> ...
>>>
+ /*
+* We don't need to check the return values of mmio regmap operations
(unless
+* the regmap has a clock attached which is not the case here).
+*/
+ exar_gpio->regs = devm_regmap_init_mmio(dev, p, _regmap_config);
+ if (IS_ERR(exar_gpio->regs))
+ return PTR_ERR(exar_gpio->regs);
index = ida_alloc(_index, GFP_KERNEL);
- if (index < 0) {
- ret = index;
- goto err_mutex_destroy;
- }
+ if (index < 0)
+ return index;
>>>
>>> And below you effectively use p as regmap!
>>> That's what renaming of variable regs -> regmap or map can easily reveal.
>>>
>>> exar_gpio->regs = p;
>>
>> Jan, if you remove this line, does it help?
>>
>
> Ha! I guess you were right saying that keeping the name is asking for
> trouble then. :)
>
> I think that may be it but address width should still be changed to 16.
>
Removing the line that Andy found made things work here. And switching
to 16 for reg_bits didn't make things worse again.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v3 6/7] gpio: exar: switch to using regmap
On 10.11.20 14:29, Bartosz Golaszewski wrote: > On Tue, Nov 10, 2020 at 2:23 PM Jan Kiszka wrote: >> >> >> Unfortunately, this one still crashes: >> > > Just to confirm: does patch 5/7 alone work? > Yes, I've bisected. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v3 6/7] gpio: exar: switch to using regmap
On 10.11.20 13:34, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> We can simplify the code in gpio-exar by using regmap. This allows us to
> drop the mutex (regmap provides its own locking) and we can also reuse
> regmap's bit operations instead of implementing our own update function.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/gpio/Kconfig | 1 +
> drivers/gpio/gpio-exar.c | 90 +---
> 2 files changed, 38 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5d4de5cd6759..253a61ec9645 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -255,6 +255,7 @@ config GPIO_EP93XX
> config GPIO_EXAR
> tristate "Support for GPIO pins on XR17V352/354/358"
> depends on SERIAL_8250_EXAR
> + select REGMAP_MMIO
> help
> Selecting this option will enable handling of GPIO pins present
> on Exar XR17V352/354/358 chips.
> diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
> index 28b0b4b5fa35..a2d324c513f8 100644
> --- a/drivers/gpio/gpio-exar.c
> +++ b/drivers/gpio/gpio-exar.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #define EXAR_OFFSET_MPIOLVL_LO 0x90
> #define EXAR_OFFSET_MPIOSEL_LO 0x93
> @@ -26,9 +27,8 @@ static DEFINE_IDA(ida_index);
>
> struct exar_gpio_chip {
> struct gpio_chip gpio_chip;
> - struct mutex lock;
> + struct regmap *regs;
> int index;
> - void __iomem *regs;
> char name[20];
> unsigned int first_pin;
> };
> @@ -53,51 +53,13 @@ exar_offset_to_bit(struct exar_gpio_chip *exar_gpio,
> unsigned int offset)
> return (offset + exar_gpio->first_pin) % 8;
> }
>
> -static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
> - unsigned int offset)
> -{
> - struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> - int temp;
> -
> - mutex_lock(_gpio->lock);
> - temp = readb(exar_gpio->regs + reg);
> - temp &= ~BIT(offset);
> - if (val)
> - temp |= BIT(offset);
> - writeb(temp, exar_gpio->regs + reg);
> - mutex_unlock(_gpio->lock);
> -}
> -
> -static int exar_set_direction(struct gpio_chip *chip, int direction,
> - unsigned int offset)
> -{
> - struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> - unsigned int addr = exar_offset_to_sel_addr(exar_gpio, offset);
> - unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
> -
> - exar_update(chip, addr, direction, bit);
> - return 0;
> -}
> -
> -static int exar_get(struct gpio_chip *chip, unsigned int reg)
> -{
> - struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> - int value;
> -
> - mutex_lock(_gpio->lock);
> - value = readb(exar_gpio->regs + reg);
> - mutex_unlock(_gpio->lock);
> -
> - return value;
> -}
> -
> static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
> {
> struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> unsigned int addr = exar_offset_to_sel_addr(exar_gpio, offset);
> unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
>
> - if (exar_get(chip, addr) & BIT(bit))
> + if (regmap_test_bits(exar_gpio->regs, addr, BIT(bit)))
> return GPIO_LINE_DIRECTION_IN;
>
> return GPIO_LINE_DIRECTION_OUT;
> @@ -109,7 +71,7 @@ static int exar_get_value(struct gpio_chip *chip, unsigned
> int offset)
> unsigned int addr = exar_offset_to_lvl_addr(exar_gpio, offset);
> unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
>
> - return !!(exar_get(chip, addr) & BIT(bit));
> + return !!(regmap_test_bits(exar_gpio->regs, addr, BIT(bit)));
> }
>
> static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
> @@ -119,21 +81,42 @@ static void exar_set_value(struct gpio_chip *chip,
> unsigned int offset,
> unsigned int addr = exar_offset_to_lvl_addr(exar_gpio, offset);
> unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
>
> - exar_update(chip, addr, value, bit);
> + if (value)
> + regmap_set_bits(exar_gpio->regs, addr, BIT(bit));
> + else
> + regmap_clear_bits(exar_gpio->regs, addr, BIT(bit));
> }
>
> static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
>int value)
> {
> + struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> + unsigned int addr = exar_offset_to_sel_addr(exar_gpio, offset);
> + unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
> +
> exar_set_value(chip, offset, value);
> - return exar_set_direction(chip, 0, offset);
> + regmap_clear_bits(exar_gpio->regs, addr, BIT(bit));
> +
> + return 0;
> }
>
> static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
> {
> - return
Re: [PATCH 0/7] gpio: exar: refactor the driver
On 27.10.20 16:12, Jan Kiszka wrote: > On 26.10.20 15:46, Andy Shevchenko wrote: >> On Mon, Oct 26, 2020 at 4:22 PM Bartosz Golaszewski wrote: >>> >>> From: Bartosz Golaszewski >>> >>> I just wanted to convert the driver to using simpler IDA API but ended up >>> quickly converting it to using regmap. Unfortunately I don't have the HW >>> to test it so marking the patches that introduce functional change as RFT >>> and Cc'ing the original author. >> >> +Cc: Jan, AFAIR their devices are using Exar UART. >> > > Thanks for CC'ing. I cannot promise testing this soon, but I will try my > best. > Finally tested, unfortunately with bad news: ... at24 i2c-INT3499:00: 1024 byte INT3499:00 EEPROM, writable, 1 bytes/write pxa2xx_spi_pci :00:15.0: enabling device ( -> 0002) pxa2xx_spi_pci :00:15.1: enabling device ( -> 0002) exar_serial :02:00.0: enabling device ( -> 0002) :02:00.0: ttyS2 at MMIO 0x9000 (irq = 44, base_baud = 7812500) is a XR17V35X :02:00.0: ttyS3 at MMIO 0x9400 (irq = 44, base_baud = 7812500) is a XR17V35X BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0xc1150010) - not-present page *pde = Oops: 0010 [#1] PREEMPT CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.0-rc2+ #438 Hardware name: Intel Corp. QUARK/SIMATIC IOT2000, BIOS V24.02.01 10/30/2018 Workqueue: events deferred_probe_work_func EIP: 0x0 Code: Unable to access opcode bytes at RIP 0xffd6. EAX: EBX: f7c74000 ECX: 0004 EDX: 0099 ESI: EDI: EBP: c1157da8 ESP: c1157d90 DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00010282 CR0: 80050033 CR2: ffd6 CR3: 03771000 CR4: 00100010 Call Trace: regmap_update_bits_base+0x22/0x60 ? exar_set_value+0x70/0x70 [gpio_exar] ? exar_set_value+0x70/0x70 [gpio_exar] exar_direction_output+0x47/0x50 [gpio_exar] gpiod_direction_output_raw_commit+0x74/0x270 ? exar_direction_input+0x50/0x50 [gpio_exar] ? exar_set_value+0x70/0x70 [gpio_exar] gpiod_direction_output+0xf0/0x160 create_gpio_led+0xea/0x180 gpio_led_probe+0x22c/0x460 ? device_pm_check_callbacks+0x4c/0x100 platform_drv_probe+0x2d/0x80 really_probe+0xcb/0x330 driver_probe_device+0x49/0xa0 __device_attach_driver+0x61/0x80 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x4f/0x90 __device_attach+0xbb/0x120 ? driver_allows_async_probing+0x60/0x60 device_initial_probe+0x12/0x20 bus_probe_device+0x6f/0x80 deferred_probe_work_func+0x56/0x80 process_one_work+0x1ce/0x390 worker_thread+0x37/0x420 kthread+0x115/0x130 ? process_one_work+0x390/0x390 ? kthread_create_on_node+0x20/0x20 ret_from_fork+0x19/0x30 Modules linked in: gpio_exar(+) spi_pxa2xx_platform 8250_exar spi_pxa2xx_pci ti_adc108s102 industrialio_triggered_buffer kfifo_buf industrialio at24 CR2: ---[ end trace d982fb210f759304 ]--- EIP: 0x0 Code: Unable to access opcode bytes at RIP 0xffd6. EAX: EBX: f7c74000 ECX: 0004 EDX: 0099 ESI: EDI: EBP: c1157da8 ESP: c1157d90 DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00010282 CR0: 80050033 CR2: ffd6 CR3: 03771000 CR4: 00100010 Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 0/7] gpio: exar: refactor the driver
On 26.10.20 15:46, Andy Shevchenko wrote: > On Mon, Oct 26, 2020 at 4:22 PM Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> I just wanted to convert the driver to using simpler IDA API but ended up >> quickly converting it to using regmap. Unfortunately I don't have the HW >> to test it so marking the patches that introduce functional change as RFT >> and Cc'ing the original author. > > +Cc: Jan, AFAIR their devices are using Exar UART. > Thanks for CC'ing. I cannot promise testing this soon, but I will try my best. Jan >> Bartosz Golaszewski (7): >> gpio: exar: add a newline after the copyright notice >> gpio: exar: include idr.h >> gpio: exar: switch to a simpler IDA interface >> gpio: exar: use a helper variable for >dev >> gpio: exar: unduplicate address and offset computation >> gpio: exar: switch to using regmap >> gpio: exar: use devm action for freeing the IDA and drop remove() >> >> drivers/gpio/Kconfig | 1 + >> drivers/gpio/gpio-exar.c | 155 +++ >> 2 files changed, 77 insertions(+), 79 deletions(-) >> >> -- >> 2.29.1 >> > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH v2] x86: pat: Do not compile stubbed functions when X86_PAT is off
From: Jan Kiszka
Those are already provided by linux/io.h as stubs.
The conflict remains invisible until someone would pull linux/io.h into
memtype.c.
Signed-off-by: Jan Kiszka
---
Change in v2:
- correct commit message
arch/x86/mm/pat/memtype.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 8f665c352bf0..41a4ac585af3 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -800,6 +800,7 @@ void memtype_free_io(resource_size_t start, resource_size_t
end)
memtype_free(start, end);
}
+#ifdef CONFIG_X86_PAT
int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
{
enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
@@ -813,6 +814,7 @@ void arch_io_free_memtype_wc(resource_size_t start,
resource_size_t size)
memtype_free_io(start, start + size);
}
EXPORT_SYMBOL(arch_io_free_memtype_wc);
+#endif
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
--
2.26.2
Re: scripts/gdb: issues when loading modules after lx-symbols
On 05.10.20 13:05, Stefano Garzarella wrote: > On Mon, Oct 05, 2020 at 11:45:41AM +0200, Jan Kiszka wrote: >> On 05.10.20 11:29, Stefano Garzarella wrote: >>> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote: >>>> On 05.10.20 10:14, Stefano Garzarella wrote: >>>>> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote: >>>>>> On 01.10.20 16:31, Stefano Garzarella wrote: >>>>>>> Hi, >>>>>>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7. >>>>>>> >>>>>>> If the modules are already loaded, and I do 'lx-symbols', all work fine. >>>>>>> But, if I load a kernel module after 'lx-symbols', I had this issue: >>>>>>> >>>>>>> [ 5093.393940] invalid opcode: [#1] SMP PTI >>>>>>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted >>>>>>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2 >>>>>>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS >>>>>>> 1.13.0-2.fc32 04/01/2014 >>>>>>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270 >>>>>>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 >>>>>>> c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 >>>>>>> cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55 >>>>>>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246 >>>>>>> [ 5093.412056] RAX: RBX: c010a0c0 RCX: >>>>>>> 4ee3 >>>>>>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: >>>>>>> c010a0c0 >>>>>>> [ 5093.416349] RBP: c9563e50 R08: R09: >>>>>>> 0002 >>>>>>> [ 5093.418044] R10: 0096 R11: 08a4 R12: >>>>>>> 88807a0d1280 >>>>>>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: >>>>>>> c9563e70 >>>>>>> [ 5093.427138] FS: 7f018f632740() GS:88807dc0() >>>>>>> knlGS: >>>>>>> [ 5093.430037] CS: 0010 DS: ES: CR0: 80050033 >>>>>>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: >>>>>>> 00170ef0 >>>>>>> [ 5093.435096] DR0: DR1: DR2: >>>>>>> >>>>>>> [ 5093.436765] DR3: DR6: fffe0ff0 DR7: >>>>>>> 0400 >>>>>>> [ 5093.439689] Call Trace: >>>>>>> [ 5093.440954] ? load_module+0x24b6/0x27d0 >>>>>>> [ 5093.443212] ? __kernel_read+0xd6/0x150 >>>>>>> [ 5093.445140] __do_sys_finit_module+0xd3/0xf0 >>>>>>> [ 5093.446877] __x64_sys_finit_module+0x1a/0x20 >>>>>>> [ 5093.449098] do_syscall_64+0x38/0x50 >>>>>>> [ 5093.450877] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>>>>> [ 5093.456153] RIP: 0033:0x7f018f75c43d >>>>>>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa >>>>>>> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f >>>>>>> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48 >>>>>>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: >>>>>>> 0139 >>>>>>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: >>>>>>> 7f018f75c43d >>>>>>> [ 5093.474747] RDX: RSI: 557e5c964288 RDI: >>>>>>> 0003 >>>>>>> [ 5093.478049] RBP: 0004 R08: R09: >>>>>>> >>>>>>> [ 5093.481298] R10: 0003 R11: 0246 R12: >>>>>>> >>>>>>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: >>>>>>> 557e5c9775c0 >>>>>>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel >>>>>>> kvm irqbypass virtio_blk virtio_rng rng_core [last
Re: scripts/gdb: issues when loading modules after lx-symbols
On 05.10.20 11:29, Stefano Garzarella wrote: > On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote: >> On 05.10.20 10:14, Stefano Garzarella wrote: >>> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote: >>>> On 01.10.20 16:31, Stefano Garzarella wrote: >>>>> Hi, >>>>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7. >>>>> >>>>> If the modules are already loaded, and I do 'lx-symbols', all work fine. >>>>> But, if I load a kernel module after 'lx-symbols', I had this issue: >>>>> >>>>> [ 5093.393940] invalid opcode: [#1] SMP PTI >>>>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted >>>>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2 >>>>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS >>>>> 1.13.0-2.fc32 04/01/2014 >>>>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270 >>>>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 >>>>> c1 fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 >>>>> cc <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55 >>>>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246 >>>>> [ 5093.412056] RAX: RBX: c010a0c0 RCX: >>>>> 4ee3 >>>>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: >>>>> c010a0c0 >>>>> [ 5093.416349] RBP: c9563e50 R08: R09: >>>>> 0002 >>>>> [ 5093.418044] R10: 0096 R11: 08a4 R12: >>>>> 88807a0d1280 >>>>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: >>>>> c9563e70 >>>>> [ 5093.427138] FS: 7f018f632740() GS:88807dc0() >>>>> knlGS: >>>>> [ 5093.430037] CS: 0010 DS: ES: CR0: 80050033 >>>>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: >>>>> 00170ef0 >>>>> [ 5093.435096] DR0: DR1: DR2: >>>>> >>>>> [ 5093.436765] DR3: DR6: fffe0ff0 DR7: >>>>> 0400 >>>>> [ 5093.439689] Call Trace: >>>>> [ 5093.440954] ? load_module+0x24b6/0x27d0 >>>>> [ 5093.443212] ? __kernel_read+0xd6/0x150 >>>>> [ 5093.445140] __do_sys_finit_module+0xd3/0xf0 >>>>> [ 5093.446877] __x64_sys_finit_module+0x1a/0x20 >>>>> [ 5093.449098] do_syscall_64+0x38/0x50 >>>>> [ 5093.450877] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>>> [ 5093.456153] RIP: 0033:0x7f018f75c43d >>>>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa >>>>> 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f >>>>> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48 >>>>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: >>>>> 0139 >>>>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: >>>>> 7f018f75c43d >>>>> [ 5093.474747] RDX: RSI: 557e5c964288 RDI: >>>>> 0003 >>>>> [ 5093.478049] RBP: 0004 R08: R09: >>>>> >>>>> [ 5093.481298] R10: 0003 R11: 0246 R12: >>>>> >>>>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: >>>>> 557e5c9775c0 >>>>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel >>>>> kvm irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa] >>>>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]--- >>>>> >>>>> Guest kernel: Linux 5.9-rc7 >>>>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32 >>>>> I tried with QEMU 4.2.1 and the latest master branch: same issue. >>>>> >>>>> >>>>> I did some digging, and skipping the gdb 'add-symbol-file' command in >>>>> symbol.py >>>>> avoid the issue, but of course I don't have the symbols loaded: >>>>> >>>>> diff --git a/scripts/gdb
Re: scripts/gdb: issues when loading modules after lx-symbols
On 05.10.20 10:14, Stefano Garzarella wrote: > On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote: >> On 01.10.20 16:31, Stefano Garzarella wrote: >>> Hi, >>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7. >>> >>> If the modules are already loaded, and I do 'lx-symbols', all work fine. >>> But, if I load a kernel module after 'lx-symbols', I had this issue: >>> >>> [ 5093.393940] invalid opcode: [#1] SMP PTI >>> [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted >>> 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2 >>> [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS >>> 1.13.0-2.fc32 04/01/2014 >>> [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270 >>> [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 c1 >>> fe ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 cc >>> <1f> 44 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55 >>> [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246 >>> [ 5093.412056] RAX: RBX: c010a0c0 RCX: >>> 4ee3 >>> [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: >>> c010a0c0 >>> [ 5093.416349] RBP: c9563e50 R08: R09: >>> 0002 >>> [ 5093.418044] R10: 0096 R11: 08a4 R12: >>> 88807a0d1280 >>> [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: >>> c9563e70 >>> [ 5093.427138] FS: 7f018f632740() GS:88807dc0() >>> knlGS: >>> [ 5093.430037] CS: 0010 DS: ES: CR0: 80050033 >>> [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: >>> 00170ef0 >>> [ 5093.435096] DR0: DR1: DR2: >>> >>> [ 5093.436765] DR3: DR6: fffe0ff0 DR7: >>> 0400 >>> [ 5093.439689] Call Trace: >>> [ 5093.440954] ? load_module+0x24b6/0x27d0 >>> [ 5093.443212] ? __kernel_read+0xd6/0x150 >>> [ 5093.445140] __do_sys_finit_module+0xd3/0xf0 >>> [ 5093.446877] __x64_sys_finit_module+0x1a/0x20 >>> [ 5093.449098] do_syscall_64+0x38/0x50 >>> [ 5093.450877] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> [ 5093.456153] RIP: 0033:0x7f018f75c43d >>> [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 >>> 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 >>> <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48 >>> [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: >>> 0139 >>> [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: >>> 7f018f75c43d >>> [ 5093.474747] RDX: RSI: 557e5c964288 RDI: >>> 0003 >>> [ 5093.478049] RBP: 0004 R08: R09: >>> >>> [ 5093.481298] R10: 0003 R11: 0246 R12: >>> >>> [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: >>> 557e5c9775c0 >>> [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel kvm >>> irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa] >>> [ 5093.488695] ---[ end trace 23712ecebc11f53c ]--- >>> >>> Guest kernel: Linux 5.9-rc7 >>> gdb: GNU gdb (GDB) Fedora 9.1-6.fc32 >>> I tried with QEMU 4.2.1 and the latest master branch: same issue. >>> >>> >>> I did some digging, and skipping the gdb 'add-symbol-file' command in >>> symbol.py >>> avoid the issue, but of course I don't have the symbols loaded: >>> >>> diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py >>> index 1be9763cf8bb..eadfaa4d4907 100644 >>> --- a/scripts/gdb/linux/symbols.py >>> +++ b/scripts/gdb/linux/symbols.py >>> @@ -129,7 +129,7 @@ lx-symbols command.""" >>> filename=module_file, >>> addr=module_addr, >>> sections=self._section_arguments(module)) >>> -gdb.execute(cmdline, to_string=True) >>> +#gdb.execute(cmdline, to_string=True) >>> if module_name not in self.loaded_modules: >>>
Re: scripts/gdb: issues when loading modules after lx-symbols
On 01.10.20 16:31, Stefano Garzarella wrote: > Hi, > I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7. > > If the modules are already loaded, and I do 'lx-symbols', all work fine. > But, if I load a kernel module after 'lx-symbols', I had this issue: > > [ 5093.393940] invalid opcode: [#1] SMP PTI > [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted > 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2 > [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > 1.13.0-2.fc32 04/01/2014 > [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270 > [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 c1 fe > ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 cc <1f> 44 > 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55 > [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246 > [ 5093.412056] RAX: RBX: c010a0c0 RCX: > 4ee3 > [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: > c010a0c0 > [ 5093.416349] RBP: c9563e50 R08: R09: > 0002 > [ 5093.418044] R10: 0096 R11: 08a4 R12: > 88807a0d1280 > [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: > c9563e70 > [ 5093.427138] FS: 7f018f632740() GS:88807dc0() > knlGS: > [ 5093.430037] CS: 0010 DS: ES: CR0: 80050033 > [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: > 00170ef0 > [ 5093.435096] DR0: DR1: DR2: > > [ 5093.436765] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 5093.439689] Call Trace: > [ 5093.440954] ? load_module+0x24b6/0x27d0 > [ 5093.443212] ? __kernel_read+0xd6/0x150 > [ 5093.445140] __do_sys_finit_module+0xd3/0xf0 > [ 5093.446877] __x64_sys_finit_module+0x1a/0x20 > [ 5093.449098] do_syscall_64+0x38/0x50 > [ 5093.450877] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 5093.456153] RIP: 0033:0x7f018f75c43d > [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 > f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48 > [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: > 7f018f75c43d > [ 5093.474747] RDX: RSI: 557e5c964288 RDI: > 0003 > [ 5093.478049] RBP: 0004 R08: R09: > > [ 5093.481298] R10: 0003 R11: 0246 R12: > > [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: > 557e5c9775c0 > [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel kvm > irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa] > [ 5093.488695] ---[ end trace 23712ecebc11f53c ]--- > > Guest kernel: Linux 5.9-rc7 > gdb: GNU gdb (GDB) Fedora 9.1-6.fc32 > I tried with QEMU 4.2.1 and the latest master branch: same issue. > > > I did some digging, and skipping the gdb 'add-symbol-file' command in > symbol.py > avoid the issue, but of course I don't have the symbols loaded: > > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py > index 1be9763cf8bb..eadfaa4d4907 100644 > --- a/scripts/gdb/linux/symbols.py > +++ b/scripts/gdb/linux/symbols.py > @@ -129,7 +129,7 @@ lx-symbols command.""" > filename=module_file, > addr=module_addr, > sections=self._section_arguments(module)) > -gdb.execute(cmdline, to_string=True) > +#gdb.execute(cmdline, to_string=True) > if module_name not in self.loaded_modules: > self.loaded_modules.append(module_name) > else: > > I tried several modules and this happens every time after '(gdb) lx-symbols'. > > Do you have any hints? > I assume you are debugging a kernel inside QEMU/KVM, right? Does it work without -enable-kvm? Debugging guests in KVM mode at least was unstable for a long time. I avoided setting soft-BPs - which is what the script does for the sake of tracking modules loading -, falling back to hw-BPs, as I had no time to debug that further. /Maybe/ that's the issue here. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] scripts/gdb: fix list_for_each
On 22.09.20 16:28, George Prekas wrote:
If the next pointer is NULL, list_for_each gets stuck in an infinite
loop.
Signed-off-by: George Prekas
---
scripts/gdb/linux/lists.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
index c487ddf09d38..424a91c1aa8b 100644
--- a/scripts/gdb/linux/lists.py
+++ b/scripts/gdb/linux/lists.py
@@ -27,6 +27,8 @@ def list_for_each(head):
raise TypeError("Must be struct list_head not {}"
.format(head.type))
+ if head['next'] == 0:
+ return
node = head['next'].dereference()
while node.address != head.address:
yield node.address
Obviously, infinite loops are bad and should be avoided. But NULL is
bug, isn't it? Shouldn't we report such a corruption?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] watchdog: sp5100_tco: Enable watchdog on Family 17h devices if disabled
On 10.09.20 18:55, Jan Kiszka wrote:
> On 10.09.20 18:53, Guenter Roeck wrote:
>> Hi Jan,
>>
>> On 9/10/20 9:34 AM, Jan Kiszka wrote:
>>> On 10.09.20 18:31, Guenter Roeck wrote:
>>>> On Family 17h (Ryzen) devices, the WatchdogTmrEn bit of PmDecodeEn not only
>>>> enables watchdog memory decoding at 0xfeb0, it also enables the
>>>> watchdog hardware itself. Use this information to enable the watchdog if
>>>> it is not already enabled.
>>>>
>>>> Cc: Jan Kiszka
>>>> Signed-off-by: Guenter Roeck
>>>> ---
>>>> drivers/watchdog/sp5100_tco.c | 18 ++
>>>> 1 file changed, 18 insertions(+)
>>>>
>>>> diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
>>>> index 85e9664318c9..a730ecbf78cd 100644
>>>> --- a/drivers/watchdog/sp5100_tco.c
>>>> +++ b/drivers/watchdog/sp5100_tco.c
>>>> @@ -17,6 +17,12 @@
>>>> *AMD Publication 51192 "AMD Bolton FCH Register Reference
>>>> Guide"
>>>> *AMD Publication 52740 "BIOS and Kernel Developer’s Guide
>>>> (BKDG)
>>>> *for AMD Family 16h Models 30h-3Fh
>>>> Processors"
>>>> + *AMD Publication 55570-B1-PUB "Processor Programming
>>>> Reference (PPR)
>>>> + *for AMD Family 17h Model 18h, Revision
>>>> B1
>>>> + *Processors (PUB)
>>>> + *AMD Publication 55772-A1-PUB "Processor Programming
>>>> Reference (PPR)
>>>> + *for AMD Family 17h Model 20h, Revision
>>>> A1
>>>> + *Processors (PUB)
>>>> */
>>>>
>>>> /*
>>>> @@ -241,6 +247,18 @@ static int sp5100_tco_setupdevice(struct device *dev,
>>>>break;
>>>>case efch:
>>>>dev_name = SB800_DEVNAME;
>>>> + /*
>>>> + * On Family 17h devices, the EFCH_PM_DECODEEN_WDT_TMREN bit of
>>>> + * EFCH_PM_DECODEEN not only enables the EFCH_PM_WDT_ADDR memory
>>>> + * region, it also enables the watchdog itself.
>>>> + */
>>>> + if (boot_cpu_data.x86 == 0x17) {
>>>> + val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
>>>> + if (!(val & EFCH_PM_DECODEEN_WDT_TMREN)) {
>>>> + sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN,
>>>> 0xff,
>>>> +
>>>> EFCH_PM_DECODEEN_WDT_TMREN);
>>>> + }
>>>> + }
>>>>val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
>>>>if (val & EFCH_PM_DECODEEN_WDT_TMREN)
>>>>mmio_addr = EFCH_PM_WDT_ADDR;
>>>>
>>>
>>> Won't that bring us EFCH_PM_WDT_ADDR as address, rather than
>>> EFCH_PM_ACPI_MMIO_ADDR which worked in my case? Or is one an alias of
>>> the other.
>>>
>>
>> Yes, it does use EFCH_PM_WDT_ADDR. EFCH_PM_ACPI_MMIO_ADDR works as well,
>> but is meant to be a fallback. Both point to the watchdog memory space.
>>
>
> OK, will test, possibly only on the weekend, and confirm this also on my
> board.
>
> Jan
>
Both patches now
Tested-by: Jan Kiszka
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] watchdog: sp5100_tco: Enable watchdog on Family 17h devices if disabled
On 10.09.20 18:31, Guenter Roeck wrote:
> On Family 17h (Ryzen) devices, the WatchdogTmrEn bit of PmDecodeEn not only
> enables watchdog memory decoding at 0xfeb0, it also enables the
> watchdog hardware itself. Use this information to enable the watchdog if
> it is not already enabled.
>
> Cc: Jan Kiszka
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/sp5100_tco.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
> index 85e9664318c9..a730ecbf78cd 100644
> --- a/drivers/watchdog/sp5100_tco.c
> +++ b/drivers/watchdog/sp5100_tco.c
> @@ -17,6 +17,12 @@
> * AMD Publication 51192 "AMD Bolton FCH Register Reference Guide"
> * AMD Publication 52740 "BIOS and Kernel Developer’s Guide (BKDG)
> * for AMD Family 16h Models 30h-3Fh Processors"
> + * AMD Publication 55570-B1-PUB "Processor Programming Reference (PPR)
> + * for AMD Family 17h Model 18h, Revision B1
> + * Processors (PUB)
> + * AMD Publication 55772-A1-PUB "Processor Programming Reference (PPR)
> + * for AMD Family 17h Model 20h, Revision A1
> + * Processors (PUB)
> */
>
> /*
> @@ -241,6 +247,18 @@ static int sp5100_tco_setupdevice(struct device *dev,
> break;
> case efch:
> dev_name = SB800_DEVNAME;
> + /*
> + * On Family 17h devices, the EFCH_PM_DECODEEN_WDT_TMREN bit of
> + * EFCH_PM_DECODEEN not only enables the EFCH_PM_WDT_ADDR memory
> + * region, it also enables the watchdog itself.
> + */
> + if (boot_cpu_data.x86 == 0x17) {
> + val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
> + if (!(val & EFCH_PM_DECODEEN_WDT_TMREN)) {
> + sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN,
> 0xff,
> +
> EFCH_PM_DECODEEN_WDT_TMREN);
> + }
> + }
> val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
> if (val & EFCH_PM_DECODEEN_WDT_TMREN)
> mmio_addr = EFCH_PM_WDT_ADDR;
>
Won't that bring us EFCH_PM_WDT_ADDR as address, rather than
EFCH_PM_ACPI_MMIO_ADDR which worked in my case? Or is one an alias of
the other.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] watchdog: sp5100_tco: Enable watchdog on Family 17h devices if disabled
On 10.09.20 18:53, Guenter Roeck wrote:
> Hi Jan,
>
> On 9/10/20 9:34 AM, Jan Kiszka wrote:
>> On 10.09.20 18:31, Guenter Roeck wrote:
>>> On Family 17h (Ryzen) devices, the WatchdogTmrEn bit of PmDecodeEn not only
>>> enables watchdog memory decoding at 0xfeb0, it also enables the
>>> watchdog hardware itself. Use this information to enable the watchdog if
>>> it is not already enabled.
>>>
>>> Cc: Jan Kiszka
>>> Signed-off-by: Guenter Roeck
>>> ---
>>> drivers/watchdog/sp5100_tco.c | 18 ++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
>>> index 85e9664318c9..a730ecbf78cd 100644
>>> --- a/drivers/watchdog/sp5100_tco.c
>>> +++ b/drivers/watchdog/sp5100_tco.c
>>> @@ -17,6 +17,12 @@
>>> * AMD Publication 51192 "AMD Bolton FCH Register Reference Guide"
>>> * AMD Publication 52740 "BIOS and Kernel Developer’s Guide (BKDG)
>>> * for AMD Family 16h Models 30h-3Fh Processors"
>>> + * AMD Publication 55570-B1-PUB "Processor Programming Reference (PPR)
>>> + * for AMD Family 17h Model 18h, Revision B1
>>> + * Processors (PUB)
>>> + * AMD Publication 55772-A1-PUB "Processor Programming Reference (PPR)
>>> + * for AMD Family 17h Model 20h, Revision A1
>>> + * Processors (PUB)
>>> */
>>>
>>> /*
>>> @@ -241,6 +247,18 @@ static int sp5100_tco_setupdevice(struct device *dev,
>>> break;
>>> case efch:
>>> dev_name = SB800_DEVNAME;
>>> + /*
>>> +* On Family 17h devices, the EFCH_PM_DECODEEN_WDT_TMREN bit of
>>> +* EFCH_PM_DECODEEN not only enables the EFCH_PM_WDT_ADDR memory
>>> +* region, it also enables the watchdog itself.
>>> +*/
>>> + if (boot_cpu_data.x86 == 0x17) {
>>> + val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
>>> + if (!(val & EFCH_PM_DECODEEN_WDT_TMREN)) {
>>> + sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN,
>>> 0xff,
>>> +
>>> EFCH_PM_DECODEEN_WDT_TMREN);
>>> + }
>>> + }
>>> val = sp5100_tco_read_pm_reg8(EFCH_PM_DECODEEN);
>>> if (val & EFCH_PM_DECODEEN_WDT_TMREN)
>>> mmio_addr = EFCH_PM_WDT_ADDR;
>>>
>>
>> Won't that bring us EFCH_PM_WDT_ADDR as address, rather than
>> EFCH_PM_ACPI_MMIO_ADDR which worked in my case? Or is one an alias of
>> the other.
>>
>
> Yes, it does use EFCH_PM_WDT_ADDR. EFCH_PM_ACPI_MMIO_ADDR works as well,
> but is meant to be a fallback. Both point to the watchdog memory space.
>
OK, will test, possibly only on the weekend, and confirm this also on my
board.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: watchdog: sp5100_tco support for AMD V/R/E series
On 09.09.20 18:04, Guenter Roeck wrote: > On 9/7/20 1:45 PM, Guenter Roeck wrote: >> On 9/7/20 12:18 PM, Guenter Roeck wrote: >>> On 9/7/20 8:46 AM, Jan Kiszka wrote: >>>> On 07.09.20 17:31, Guenter Roeck wrote: >>>>> On 9/7/20 4:20 AM, Jan Kiszka wrote: >>>>>> Hi all, >>>>>> >>>>>> Arsalan reported that the upstream driver for sp5100_tco does not work >>>>>> for embedded Ryzen. Meanwhile, I was able to confirm that on an R1505G: >>>>>> >>>>>> [ 11.607251] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver >>>>>> [ 11.607337] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO >>>>>> address >>>>>> [ 11.607344] sp5100-tco sp5100-tco: Watchdog hardware is disabled >>>>>> >>>>>> ..and fix it: >>>>>> >>>>>> diff --git a/drivers/watchdog/sp5100_tco.c >>>>>> b/drivers/watchdog/sp5100_tco.c >>>>>> index 85e9664318c9..5482154fde42 100644 >>>>>> --- a/drivers/watchdog/sp5100_tco.c >>>>>> +++ b/drivers/watchdog/sp5100_tco.c >>>>>> @@ -193,7 +193,8 @@ static void tco_timer_enable(struct sp5100_tco *tco) >>>>>> /* Set the Watchdog timer resolution to 1 sec and >>>>>> enable */ >>>>>> sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN3, >>>>>>~EFCH_PM_WATCHDOG_DISABLE, >>>>>> - EFCH_PM_DECODEEN_SECOND_RES); >>>>>> + EFCH_PM_DECODEEN_SECOND_RES | >>>>>> + EFCH_PM_DECODEEN_WDT_TMREN); >>>>> >>>>> Confusing. The register in question is a 32-bit register, but only a byte >>>>> is written into it. Bit 24-25 are supposed to be the resolution, bit 25-26 >>>>> set to 0 enable the watchdog. Bit 7 is supposed to enable MMIO decoding. >>>>> This is from AMD Publication 52740. So something in the existing code >>>>> is (or seems to be) wrong, but either case I don't see how setting bit 7 >>>>> (or 31 ?) would enable the watchdog hardware. >>>>> >>>>> Hmm, I wrote that code. Guess I'll need to to spend some time figuring out >>>>> what is going on. >>>> >>>> The logic came from [1] which inspired [2] - that's where I pointed out >>>> the large overlap with the existing upstream driver. I would love to see >>>> all that consolidated. >>>> >>>> BTW, the R1505G is family 0x17. Maybe something changed there, and that >>>> bit 7 was just reserved/ignored so far. ENOSPECS >>>> >>> >>> Thanks for the pointers. >>> >>> I think you are talking about bit 31. Bit 7 is and was WatchdogTmrEn, but >>> that >>> supposedly only enables watchdog timer memory access at 0xfeb0. From >>> what >>> I glance from the other drivers, the existing code is wrong. It should set >>> the disable and resolution bits in register offset 3 (bit 24..27), not 0. >>> In other words, EFCH_PM_DECODEEN3 should be defined as 0x03, not as 0x00. >>> Which actually makes sense from the name. >>> >>> Playing with my hardware, turns out that setting bit 7 in EFCH_PM_DECODEEN >>> (register offset 0) does indeed enable the watchdog. I'll need to check >>> if it actually works. Either case, -ENOSPECS is really a problem here. >>> >> >> ... and it does work. After playing with it, it seems that on Family 17h >> CPUs EFCH_PM_DECODEEN_WDT_TMREN not only enables watchdog timer memory >> access at 0xfeb, but also enables the watchdog itself. >> >> Also, turns out the documentation is now public, at least for some of the >> Family 17h CPUs (though oddly enough not for all of them). See processor >> reference manuals at https://www.amd.com/en/support/tech-docs. The documents >> for model 18h and model 20h include a note stating that bit 7 of >> EFCH_PM_DECODEEN enables both memory access and the watchdog hardware. >> >> So we'll need two patches - one to fix the value of EFCH_PM_DECODEEN3, >> and one to enable the watchdog bit setting bit 7 of EFCH_PM_DECODEEN >> for Family 17h CPUs. >> > Jan - any chance you can submit those patches ? Or do you want me to do it ? Oh, I was reading your reply as if you were writing the patches. The first one is definitely your finding, and while I can also see now what is wrong and needed on 17h, I'm unsure about the rest. If you have a better picture, please go ahead. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: watchdog: sp5100_tco support for AMD V/R/E series
On 07.09.20 17:31, Guenter Roeck wrote: > On 9/7/20 4:20 AM, Jan Kiszka wrote: >> Hi all, >> >> Arsalan reported that the upstream driver for sp5100_tco does not work >> for embedded Ryzen. Meanwhile, I was able to confirm that on an R1505G: >> >> [ 11.607251] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver >> [ 11.607337] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO >> address >> [ 11.607344] sp5100-tco sp5100-tco: Watchdog hardware is disabled >> >> ..and fix it: >> >> diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c >> index 85e9664318c9..5482154fde42 100644 >> --- a/drivers/watchdog/sp5100_tco.c >> +++ b/drivers/watchdog/sp5100_tco.c >> @@ -193,7 +193,8 @@ static void tco_timer_enable(struct sp5100_tco *tco) >> /* Set the Watchdog timer resolution to 1 sec and enable */ >> sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN3, >>~EFCH_PM_WATCHDOG_DISABLE, >> - EFCH_PM_DECODEEN_SECOND_RES); >> + EFCH_PM_DECODEEN_SECOND_RES | >> + EFCH_PM_DECODEEN_WDT_TMREN); > > Confusing. The register in question is a 32-bit register, but only a byte > is written into it. Bit 24-25 are supposed to be the resolution, bit 25-26 > set to 0 enable the watchdog. Bit 7 is supposed to enable MMIO decoding. > This is from AMD Publication 52740. So something in the existing code > is (or seems to be) wrong, but either case I don't see how setting bit 7 > (or 31 ?) would enable the watchdog hardware. > > Hmm, I wrote that code. Guess I'll need to to spend some time figuring out > what is going on. The logic came from [1] which inspired [2] - that's where I pointed out the large overlap with the existing upstream driver. I would love to see all that consolidated. BTW, the R1505G is family 0x17. Maybe something changed there, and that bit 7 was just reserved/ignored so far. ENOSPECS Jan [1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/commit/meta-amd-bsp/recipes-kernel/amd-wdt/files/amd_wdt.c?id=cd760c9f04d276382a0f5156dabdb766594ace56 [2] https://github.com/siemens/efibootguard/commit/3a702aa96d193f26571ea4e70db29ef01a0d4d5f -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
watchdog: sp5100_tco support for AMD V/R/E series
Hi all, Arsalan reported that the upstream driver for sp5100_tco does not work for embedded Ryzen. Meanwhile, I was able to confirm that on an R1505G: [ 11.607251] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver [ 11.607337] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address [ 11.607344] sp5100-tco sp5100-tco: Watchdog hardware is disabled ..and fix it: diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c index 85e9664318c9..5482154fde42 100644 --- a/drivers/watchdog/sp5100_tco.c +++ b/drivers/watchdog/sp5100_tco.c @@ -193,7 +193,8 @@ static void tco_timer_enable(struct sp5100_tco *tco) /* Set the Watchdog timer resolution to 1 sec and enable */ sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN3, ~EFCH_PM_WATCHDOG_DISABLE, - EFCH_PM_DECODEEN_SECOND_RES); + EFCH_PM_DECODEEN_SECOND_RES | + EFCH_PM_DECODEEN_WDT_TMREN); break; } } Does anyone have an idea if such unconditional setting could be problematic on older/different efch? We probe for that bit in sp5100_tco_setupdevice but we never set it so far. I'm missing specs... Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
On 28.08.20 09:47, Vignesh Raghavendra wrote:
> Buffers need to mapped to DMA channel's device pointer instead of SPI
> controller's device pointer as its system DMA that actually does data
> transfer.
> Data inconsistencies have been reported when reading from flash
> without this fix.
>
> Fixes: 31fb632b5d43c ("spi: Move cadence-quadspi driver to drivers/spi/")
This looks wrong, ...
> Signed-off-by: Vignesh Raghavendra
> ---
>
> This issue was present in the original driver under SPI NOR framework as well.
> But only got exposed as driver started handling probe deferral for DMA channel
> request and thus uses DMA almost always unlike before.
...you rather want 935da5e5100f57d843cac4781b21f1c235059aa0 then.
Other than that:
Tested-by: Jan Kiszka
Thanks!
Jan
>
> drivers/spi/spi-cadence-quadspi.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c
> b/drivers/spi/spi-cadence-quadspi.c
> index 508b219eabf8..c6795c684b16 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -907,14 +907,16 @@ static int cqspi_direct_read_execute(struct
> cqspi_flash_pdata *f_pdata,
> struct dma_async_tx_descriptor *tx;
> dma_cookie_t cookie;
> dma_addr_t dma_dst;
> + struct device *ddev;
>
> if (!cqspi->rx_chan || !virt_addr_valid(buf)) {
> memcpy_fromio(buf, cqspi->ahb_base + from, len);
> return 0;
> }
>
> - dma_dst = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
> - if (dma_mapping_error(dev, dma_dst)) {
> + ddev = cqspi->rx_chan->device->dev;
> + dma_dst = dma_map_single(ddev, buf, len, DMA_FROM_DEVICE);
> + if (dma_mapping_error(ddev, dma_dst)) {
> dev_err(dev, "dma mapping failed\n");
> return -ENOMEM;
> }
> @@ -948,7 +950,7 @@ static int cqspi_direct_read_execute(struct
> cqspi_flash_pdata *f_pdata,
> }
>
> err_unmap:
> - dma_unmap_single(dev, dma_dst, len, DMA_FROM_DEVICE);
> + dma_unmap_single(ddev, dma_dst, len, DMA_FROM_DEVICE);
>
> return ret;
> }
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 26.08.20 14:18, Vignesh Raghavendra wrote:
>
>
> On 8/26/20 3:42 PM, Jan Kiszka wrote:
>> On 24.08.20 19:20, Jan Kiszka wrote:
>>> On 24.08.20 14:49, Jan Kiszka wrote:
>>>> On 24.08.20 13:45, Vignesh Raghavendra wrote:
>>>>>
>>>>>
>>>>> On 8/22/20 11:35 PM, Jan Kiszka wrote:
>>>>>> On 01.06.20 09:04, Vignesh Raghavendra wrote:
>>>>>>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
>>>>>>> is not yet probed. Currently driver just falls back to using PIO mode
>>>>>>> (which is less efficient) in this case. Instead return probe deferral
>>>>>>> error as is so that driver will be re probed once DMA provider is
>>>>>>> available.
>>>>>>>
>>>>>>> Signed-off-by: Vignesh Raghavendra
>>>>>>> Reviewed-by: Tudor Ambarus
>>>>>>> ---
>>>>> [...]
>>>>>>>
>>>>>>> static const struct spi_nor_controller_ops cqspi_controller_ops = {
>>>>>>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st
>>>>>>> *cqspi, struct device_node *np)
>>>>>>> dev_dbg(nor->dev, "using direct mode for %s\n",
>>>>>>> mtd->name);
>>>>>>>
>>>>>>> - if (!cqspi->rx_chan)
>>>>>>> - cqspi_request_mmap_dma(cqspi);
>>>>>>> + if (!cqspi->rx_chan) {
>>>>>>> + ret = cqspi_request_mmap_dma(cqspi);
>>>>>>> + if (ret == -EPROBE_DEFER)
>>>>>>> + goto err;
>>>>>>> + }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This seem to break reading the SPI flash on our IOT2050 [1] (didn't test
>>>>>> the eval board yet).
>>>>>>
>>>>>> Without that commit, read happens via PIO, and that works. With the
>>>>>> commit, the pattern
>>>>>>
>>>>>> with open("out.bin", "wb") as out:
>>>>>> pos = 0
>>>>>> while pos < 2:
>>>>>> with open("/dev/mtd0", "rb") as mtd:
>>>>>>mtd.seek(pos * 0x1)
>>>>>>out.write(mtd.read(0x1))
>>>>>> pos += 1
>>>>>>
>>>>>> gives the wrong result for the second block while
>>>>>
>>>>> Interesting... Could you please explain wrong result? Is the data move
>>>>> around or completely garbage?
>>>>
>>>> It looks like some stripes contain data from other parts of the flash or
>>>> kernel RAM. It's not just garbage, there are readable strings included.
>>>>
>>>>>
>>>>> Does this fail even on AM654 EVM? Could you share full script for me to
>>>>> test locally?
>>>>
>>>> The scripts are complete (python). Just binary-diff the outputs.
>>>>
>>>> I'll try on the EVM later.
>>>
>>> Done so now, could reproduce.
>>
>> ..."could *not* reproduce" there. Sorry if that caused confusion.
>>
>
> Oh, thanks! I was wondering why I cannot see this issue on AM654 EVM at my
> end...
>
>>>
>>> But the OSPIs are definitely different. EVM reports
>>>
>>> spi-nor spi0.0: mt35xu512aba (65536 Kbytes)
>>>
>>> with 4K erase size. Our our board, we have
>>>
>>> spi-nor spi7.0: w25q128 (16384 Kbytes)
>>>
>>> with 64K erase size.
>>>
>>> Here is some extract of the hex-diffs between out.bin and out2.bin (the
>>> latter being the good one):
>>>
>>> --- /dev/fd/63 2020-08-24 17:16:58.776409282 +
>>> +++ /dev/fd/62 2020-08-24 17:16:58.776409282 +
>>> @@ -6,18 +6,18 @@
>>> 0050 0f 30 0d 06 03 55 04 07 0c 06 44 61 6c 6c 61 73
>>> |.0...UDallas|
>>> 0060 31 27 30 25 06 03 55 04 0a 0c 1e 54 65 78 61 73
>>> |1'0%..UTexas|
>>> 0070
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 24.08.20 19:20, Jan Kiszka wrote:
> On 24.08.20 14:49, Jan Kiszka wrote:
>> On 24.08.20 13:45, Vignesh Raghavendra wrote:
>>>
>>>
>>> On 8/22/20 11:35 PM, Jan Kiszka wrote:
>>>> On 01.06.20 09:04, Vignesh Raghavendra wrote:
>>>>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
>>>>> is not yet probed. Currently driver just falls back to using PIO mode
>>>>> (which is less efficient) in this case. Instead return probe deferral
>>>>> error as is so that driver will be re probed once DMA provider is
>>>>> available.
>>>>>
>>>>> Signed-off-by: Vignesh Raghavendra
>>>>> Reviewed-by: Tudor Ambarus
>>>>> ---
>>> [...]
>>>>>
>>>>> static const struct spi_nor_controller_ops cqspi_controller_ops = {
>>>>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st
>>>>> *cqspi, struct device_node *np)
>>>>> dev_dbg(nor->dev, "using direct mode for %s\n",
>>>>> mtd->name);
>>>>>
>>>>> - if (!cqspi->rx_chan)
>>>>> - cqspi_request_mmap_dma(cqspi);
>>>>> + if (!cqspi->rx_chan) {
>>>>> + ret = cqspi_request_mmap_dma(cqspi);
>>>>> + if (ret == -EPROBE_DEFER)
>>>>> + goto err;
>>>>> + }
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>
>>>> This seem to break reading the SPI flash on our IOT2050 [1] (didn't test
>>>> the eval board yet).
>>>>
>>>> Without that commit, read happens via PIO, and that works. With the
>>>> commit, the pattern
>>>>
>>>> with open("out.bin", "wb") as out:
>>>> pos = 0
>>>> while pos < 2:
>>>> with open("/dev/mtd0", "rb") as mtd:
>>>>mtd.seek(pos * 0x1)
>>>>out.write(mtd.read(0x1))
>>>> pos += 1
>>>>
>>>> gives the wrong result for the second block while
>>>
>>> Interesting... Could you please explain wrong result? Is the data move
>>> around or completely garbage?
>>
>> It looks like some stripes contain data from other parts of the flash or
>> kernel RAM. It's not just garbage, there are readable strings included.
>>
>>>
>>> Does this fail even on AM654 EVM? Could you share full script for me to
>>> test locally?
>>
>> The scripts are complete (python). Just binary-diff the outputs.
>>
>> I'll try on the EVM later.
>
> Done so now, could reproduce.
..."could *not* reproduce" there. Sorry if that caused confusion.
>
> But the OSPIs are definitely different. EVM reports
>
> spi-nor spi0.0: mt35xu512aba (65536 Kbytes)
>
> with 4K erase size. Our our board, we have
>
> spi-nor spi7.0: w25q128 (16384 Kbytes)
>
> with 64K erase size.
>
> Here is some extract of the hex-diffs between out.bin and out2.bin (the
> latter being the good one):
>
> --- /dev/fd/63 2020-08-24 17:16:58.776409282 +
> +++ /dev/fd/62 2020-08-24 17:16:58.776409282 +
> @@ -6,18 +6,18 @@
> 0050 0f 30 0d 06 03 55 04 07 0c 06 44 61 6c 6c 61 73
> |.0...UDallas|
> 0060 31 27 30 25 06 03 55 04 0a 0c 1e 54 65 78 61 73
> |1'0%..UTexas|
> 0070 20 49 6e 73 74 72 75 6d 65 6e 74 73 20 49 6e 63 | Instruments
> Inc|
> -0080 84 8b 96 2c 0c 12 18 03 01 05 05 04 01 02 00 00
> |...,|
> -0090 07 06 44 45 20 01 0d 14 2a 01 00 32 05 24 30 48 |..DE
> ...*..2.$0H|
> -00a0 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04
> |`l0.|
> -00b0 01 00 00 0f ac 02 0c 00 2d 1a 6f 18 17 ff ff ff
> |-.o.|
> +0080 6f 72 70 6f 72 61 74 65 64 31 13 30 11 06 03 55
> |orporated1.0...U|
> +0090 04 0b 0c 0a 50 72 6f 63 65 73 73 6f 72 73 31 13
> |Processors1.|
> +00a0 30 11 06 03 55 04 03 0c 0a 54 49 20 73 75 70 70 |0...UTI
> supp|
> +00b0 6f 72 74 31 1d 30 1b 06 09 2a 86 48 86 f7 0d 01
> |ort1.0...*.H|
> 00c0 09 01 16 0e 73 75 70 70 6f 72 74 40 74 69 2e 63
> |support@ti.c|
> 00d0 6f 6d 30 1e 17 0d 32 30 30 37 32 32 31 31 30 30
> |om0...2007221100|
> 00e0 3
Re: [PATCH 0/2][next] update gdb scripts for lockless printk ringbuffer
On 25.08.20 14:35, Petr Mladek wrote: > On Mon 2020-08-24 10:20:53, Kieran Bingham wrote: >> Hi Petr, >> >> On 21/08/2020 09:55, Jan Kiszka wrote: >>> On 21.08.20 10:08, Petr Mladek wrote: >>>> On Fri 2020-08-14 23:31:23, John Ogness wrote: >>>>> Hi, >>>>> >>>>> When we brought in the new lockless printk ringbuffer, we overlooked the >>>>> gdb >>>>> scripts. Here are a set of patches to implement gdb support for the new >>>>> ringbuffer. >>>>> >>>>> John Ogness (2): >>>>> scripts/gdb: add utils.read_ulong() >>>>> scripts/gdb: update for lockless printk ringbuffer >>>> >>>> I am not fluent in the gdb macros and python so I did not try any >>>> deep review. But both patches work for me: >>>> >>>> Tested-by: Petr Mladek >>>> >>>> I am going to give it few more days before pushing just in case there is >>>> another feedback. >> >> Before 'pushing' ? >> >> What context do you mean here? These patches go through AKPM don't they? >> Did I miss some update to procedures? > > Both patches should go into mainline together with the lockless printk > ring buffer. It is already in linux-next via printk/linux.git, > branch printk-rework. > > The plan is to get it into mainline when pr_cont() handling is solved. > It is more complicated than we hoped for, see > https://lore.kernel.org/r/20200824103538.31446-1-john.ogn...@linutronix.de > It is still not clear whether it will be ready for 5.10. > > Andrew, would you mind when I take the three gdb/lockless-printk > related changes via printk tree to avoid synchronization problems? >From my POV, that would be best in this case - but actually also in other cases where developers happen to notice the dependency between their refactorings and gdb scripts. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 24.08.20 14:49, Jan Kiszka wrote:
> On 24.08.20 13:45, Vignesh Raghavendra wrote:
>>
>>
>> On 8/22/20 11:35 PM, Jan Kiszka wrote:
>>> On 01.06.20 09:04, Vignesh Raghavendra wrote:
>>>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
>>>> is not yet probed. Currently driver just falls back to using PIO mode
>>>> (which is less efficient) in this case. Instead return probe deferral
>>>> error as is so that driver will be re probed once DMA provider is
>>>> available.
>>>>
>>>> Signed-off-by: Vignesh Raghavendra
>>>> Reviewed-by: Tudor Ambarus
>>>> ---
>> [...]
>>>>
>>>> static const struct spi_nor_controller_ops cqspi_controller_ops = {
>>>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st
>>>> *cqspi, struct device_node *np)
>>>>dev_dbg(nor->dev, "using direct mode for %s\n",
>>>>mtd->name);
>>>>
>>>> - if (!cqspi->rx_chan)
>>>> - cqspi_request_mmap_dma(cqspi);
>>>> + if (!cqspi->rx_chan) {
>>>> + ret = cqspi_request_mmap_dma(cqspi);
>>>> + if (ret == -EPROBE_DEFER)
>>>> + goto err;
>>>> + }
>>>>}
>>>>}
>>>>
>>>>
>>>
>>> This seem to break reading the SPI flash on our IOT2050 [1] (didn't test
>>> the eval board yet).
>>>
>>> Without that commit, read happens via PIO, and that works. With the
>>> commit, the pattern
>>>
>>> with open("out.bin", "wb") as out:
>>> pos = 0
>>> while pos < 2:
>>> with open("/dev/mtd0", "rb") as mtd:
>>>mtd.seek(pos * 0x1)
>>>out.write(mtd.read(0x1))
>>> pos += 1
>>>
>>> gives the wrong result for the second block while
>>
>> Interesting... Could you please explain wrong result? Is the data move
>> around or completely garbage?
>
> It looks like some stripes contain data from other parts of the flash or
> kernel RAM. It's not just garbage, there are readable strings included.
>
>>
>> Does this fail even on AM654 EVM? Could you share full script for me to
>> test locally?
>
> The scripts are complete (python). Just binary-diff the outputs.
>
> I'll try on the EVM later.
Done so now, could reproduce.
But the OSPIs are definitely different. EVM reports
spi-nor spi0.0: mt35xu512aba (65536 Kbytes)
with 4K erase size. Our our board, we have
spi-nor spi7.0: w25q128 (16384 Kbytes)
with 64K erase size.
Here is some extract of the hex-diffs between out.bin and out2.bin (the
latter being the good one):
--- /dev/fd/63 2020-08-24 17:16:58.776409282 +
+++ /dev/fd/62 2020-08-24 17:16:58.776409282 +
@@ -6,18 +6,18 @@
0050 0f 30 0d 06 03 55 04 07 0c 06 44 61 6c 6c 61 73 |.0...UDallas|
0060 31 27 30 25 06 03 55 04 0a 0c 1e 54 65 78 61 73 |1'0%..UTexas|
0070 20 49 6e 73 74 72 75 6d 65 6e 74 73 20 49 6e 63 | Instruments Inc|
-0080 84 8b 96 2c 0c 12 18 03 01 05 05 04 01 02 00 00 |...,|
-0090 07 06 44 45 20 01 0d 14 2a 01 00 32 05 24 30 48 |..DE ...*..2.$0H|
-00a0 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 |`l0.|
-00b0 01 00 00 0f ac 02 0c 00 2d 1a 6f 18 17 ff ff ff |-.o.|
+0080 6f 72 70 6f 72 61 74 65 64 31 13 30 11 06 03 55 |orporated1.0...U|
+0090 04 0b 0c 0a 50 72 6f 63 65 73 73 6f 72 73 31 13 |Processors1.|
+00a0 30 11 06 03 55 04 03 0c 0a 54 49 20 73 75 70 70 |0...UTI supp|
+00b0 6f 72 74 31 1d 30 1b 06 09 2a 86 48 86 f7 0d 01 |ort1.0...*.H|
00c0 09 01 16 0e 73 75 70 70 6f 72 74 40 74 69 2e 63 |support@ti.c|
00d0 6f 6d 30 1e 17 0d 32 30 30 37 32 32 31 31 30 30 |om0...2007221100|
00e0 30 30 5a 17 0d 32 30 30 38 32 31 31 31 30 30 30 |00Z..20082111000|
00f0 30 5a 30 81 9d 31 0b 30 09 06 03 55 04 06 13 02 |0Z0..1.0...U|
-0100 00 00 27 a4 00 00 42 43 5e 00 62 32 2f 00 b4 96 |..'...BC^.b2/...|
-0110 24 44 0c 00 c6 00 43 0a 00 00 0b f0 43 a5 2a 01 |$DC.C.*.|
-0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
-*
+0100 55 53 31 0b 30 09 06 03 55 04 08 0c 02 54 58 31 |US1.0...UTX1|
+0110 0f 30 0d 06 03 55 04 07 0c 06 44 61 6c 6c 61 73 |.0...UDallas|
+0120 31 27 30 25 06 03 55 04 0a 0c 1e 54 65
Re: [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 24.08.20 14:04, Boris Brezillon wrote:
> On Mon, 24 Aug 2020 17:14:56 +0530
> Vignesh Raghavendra wrote:
>
>> Hi Jan,
>>
>> On 8/24/20 11:25 AM, Jan Kiszka wrote:
>> [...]
>>
>>>> +MODULE_AUTHOR("Vignesh Raghavendra ");
>>>>
>>> On the AM65x, this changes mtd->name (thus mtd-id for
>>> parser/cmdlinepart) from 4704.spi.0 to spi7.0. The besides having to
>>> deal with both names now, "spi7" sounds like it could easily change
>>> again if someone plugs or unplugs some other SPI device. Is this intended?
>>>
>>
>> You could use DT aliases to make sure OSPI0 is always at given bus num
>> (say spi7):
>>
>> aliases {
>> spi7 =
>> };
>
> FWIW, we've added the ->get_name() method [1][2] to avoid such
> regressions.
>
> [1]https://elixir.bootlin.com/linux/latest/source/include/linux/spi/spi-mem.h#L218
> [2]https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-fsl-qspi.c#L810
>
OK, that reads like I was not the first to run into this.
Vignesh, please use it so that I can drop the local workaround.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 24.08.20 13:45, Vignesh Raghavendra wrote:
>
>
> On 8/22/20 11:35 PM, Jan Kiszka wrote:
>> On 01.06.20 09:04, Vignesh Raghavendra wrote:
>>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
>>> is not yet probed. Currently driver just falls back to using PIO mode
>>> (which is less efficient) in this case. Instead return probe deferral
>>> error as is so that driver will be re probed once DMA provider is
>>> available.
>>>
>>> Signed-off-by: Vignesh Raghavendra
>>> Reviewed-by: Tudor Ambarus
>>> ---
> [...]
>>>
>>> static const struct spi_nor_controller_ops cqspi_controller_ops = {
>>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
>>> struct device_node *np)
>>> dev_dbg(nor->dev, "using direct mode for %s\n",
>>> mtd->name);
>>>
>>> - if (!cqspi->rx_chan)
>>> - cqspi_request_mmap_dma(cqspi);
>>> + if (!cqspi->rx_chan) {
>>> + ret = cqspi_request_mmap_dma(cqspi);
>>> + if (ret == -EPROBE_DEFER)
>>> + goto err;
>>> + }
>>> }
>>> }
>>>
>>>
>>
>> This seem to break reading the SPI flash on our IOT2050 [1] (didn't test
>> the eval board yet).
>>
>> Without that commit, read happens via PIO, and that works. With the
>> commit, the pattern
>>
>> with open("out.bin", "wb") as out:
>> pos = 0
>> while pos < 2:
>> with open("/dev/mtd0", "rb") as mtd:
>>mtd.seek(pos * 0x1)
>>out.write(mtd.read(0x1))
>> pos += 1
>>
>> gives the wrong result for the second block while
>
> Interesting... Could you please explain wrong result? Is the data move
> around or completely garbage?
It looks like some stripes contain data from other parts of the flash or
kernel RAM. It's not just garbage, there are readable strings included.
>
> Does this fail even on AM654 EVM? Could you share full script for me to
> test locally?
The scripts are complete (python). Just binary-diff the outputs.
I'll try on the EVM later.
>
> What is the flash on the board?
Le, could you answer that more precisely than I could?
Thanks,
Jan
>
>>
>> with open("out2.bin", "wb") as out:
>> with open("/dev/mtd0", "rb") as mtd:
>> out.write(mtd.read(0x2))
>>
>> (or "mtd_debug read") is fine.
>>
>> What could be the reason? Our DTBs and k3-am654-base-board.dtb had some
>> deviations /wrt the ospi node, but aligning ours to the base board made
>> no difference.
>>
>> Jan
>>
>> [1] https://github.com/siemens/linux/commits/jan/iot2050
>>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 24.08.20 13:44, Vignesh Raghavendra wrote:
> Hi Jan,
>
> On 8/24/20 11:25 AM, Jan Kiszka wrote:
> [...]
>
>>> +MODULE_AUTHOR("Vignesh Raghavendra ");
>>>
>> On the AM65x, this changes mtd->name (thus mtd-id for
>> parser/cmdlinepart) from 4704.spi.0 to spi7.0. The besides having to
>> deal with both names now, "spi7" sounds like it could easily change
>> again if someone plugs or unplugs some other SPI device. Is this intended?
>>
>
> You could use DT aliases to make sure OSPI0 is always at given bus num
> (say spi7):
>
> aliases {
> spi7 =
> };
Ah, looks like this is a common pattern... Thanks, will try that.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH v3] usb-serial:cp210x: add support to software flow control
On 24.08.20 11:28, Wang, Sheng Long (EXT) (RC-CN DI FA R SW) wrote: > Hi Johan, > > Thanks for your reminding. I am adjusting patch according to the latest > Linux Master branch. Use git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git, branch is likely usb-linus, as Johan requested - just in case there is another conflict due to a patch not yet in Linux master but in that tree. > > With best regards, > Wang Sheng Long > Siemens Ltd., China > RC-CN DI FA R SW > Tianyuan road No.99 > 611731 CHENGDU, China > Mobil: +86 15281074996 > mailto:shenglong.wang@siemens.com > > > > -Original Message- > From: Johan Hovold > Sent: Monday, August 24, 2020 5:10 PM > To: Kiszka, Jan (CT RDA IOT SES-DE) > Cc: Sheng Long Wang ; Wang, Sheng Long (EXT) (RC-CN > DI FA R SW) ; jo...@kernel.org; > gre...@linuxfoundation.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v3] usb-serial:cp210x: add support to software flow > control > > On Fri, Aug 21, 2020 at 07:32:58AM +0200, Jan Kiszka wrote: >> On 20.08.20 09:52, Sheng Long Wang wrote: >>> From: Wang Sheng Long >>> >>> When data is transmitted between two serial ports, the phenomenon of >>> data loss often occurs. The two kinds of flow control commonly used >>> in serial communication are hardware flow control and software flow >>> control. >>> >>> In serial communication, If you only use RX/TX/GND Pins, you can't >>> do hardware flow. So we often used software flow control and prevent >>> data loss. The user sets the software flow control through the >>> application program, and the application program sets the software >>> flow control mode for the serial port chip through the driver. >>> >>> For the cp210 serial port chip, its driver lacks the software flow >>> control setting code, so the user cannot set the software flow >>> control function through the application program. This adds the >>> missing software flow control. >>> >>> Signed-off-by: Wang Sheng Long >>> >>> Changes in v3: >>> -fixed code style, It mainly adjusts the code style acccording to >>> kernel specification. >> >> Patch does not apply. You forgot to rebase over latest tty/tty-next or >> linux master. > > That should be the usb-next branch of the usb-serial tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/ > > or linux-next (or, currently, Linus's master branch). > > You can use "scripts/get_maintainer.sh --scm" to determine which tree to base > your work against. Thanks for correcting! But it's scripts/get_maintainer.pl. ;) Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 01.06.20 09:04, Vignesh Raghavendra wrote:
> From: Ramuthevar Vadivel Murugan
>
> Move cadence-quadspi driver to use spi-mem framework. This is required
> to make the driver support for SPI NAND flashes in future.
>
> Driver is feature compliant with existing SPI NOR version.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> Signed-off-by: Vignesh Raghavendra
> Reviewed-by: Tudor Ambarus
> ---
> .../mtd/spi-nor/controllers/cadence-quadspi.c | 476 +++---
> 1 file changed, 191 insertions(+), 285 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> index 6b1cbad25e3f6..c12a1c0191b92 100644
> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> @@ -3,6 +3,8 @@
> * Driver for Cadence QSPI Controller
> *
> * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
> + * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
> */
> #include
> #include
> @@ -17,9 +19,6 @@
> #include
> #include
> #include
> -#include
> -#include
> -#include
> #include
> #include
> #include
> @@ -27,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define CQSPI_NAME "cadence-qspi"
> @@ -36,16 +36,12 @@
> #define CQSPI_NEEDS_WR_DELAY BIT(0)
> #define CQSPI_DISABLE_DAC_MODE BIT(1)
>
> -/* Capabilities mask */
> -#define CQSPI_BASE_HWCAPS_MASK \
> - (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
> - SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
> - SNOR_HWCAPS_PP)
> +/* Capabilities */
> +#define CQSPI_SUPPORTS_OCTAL BIT(0)
>
> struct cqspi_st;
>
> struct cqspi_flash_pdata {
> - struct spi_nor nor;
> struct cqspi_st *cqspi;
> u32 clk_rate;
> u32 read_delay;
> @@ -57,8 +53,6 @@ struct cqspi_flash_pdata {
> u8 addr_width;
> u8 data_width;
> u8 cs;
> - boolregistered;
> - booluse_direct_mode;
> };
>
> struct cqspi_st {
> @@ -71,7 +65,6 @@ struct cqspi_st {
> void __iomem*ahb_base;
> resource_size_t ahb_size;
> struct completion transfer_complete;
> - struct mutexbus_mutex;
>
> struct dma_chan *rx_chan;
> struct completion rx_dma_complete;
> @@ -85,6 +78,7 @@ struct cqspi_st {
> boolrclk_en;
> u32 trigger_address;
> u32 wr_delay;
> + booluse_direct_mode;
> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
> };
>
> @@ -283,9 +277,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
> *dev)
> return IRQ_HANDLED;
> }
>
> -static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
> +static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
> {
> - struct cqspi_flash_pdata *f_pdata = nor->priv;
> u32 rdreg = 0;
>
> rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
> @@ -352,19 +345,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
> unsigned int reg)
> return cqspi_wait_idle(cqspi);
> }
>
> -static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
> - u8 *rxbuf, size_t n_rx)
> +static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
> + const struct spi_mem_op *op)
> {
> - struct cqspi_flash_pdata *f_pdata = nor->priv;
> struct cqspi_st *cqspi = f_pdata->cqspi;
> void __iomem *reg_base = cqspi->iobase;
> + u8 *rxbuf = op->data.buf.in;
> + u8 opcode = op->cmd.opcode;
> + size_t n_rx = op->data.nbytes;
> unsigned int rdreg;
> unsigned int reg;
> size_t read_len;
> int status;
>
> if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
> - dev_err(nor->dev,
> + dev_err(>pdev->dev,
> "Invalid input argument, len %zu rxbuf 0x%p\n",
> n_rx, rxbuf);
> return -EINVAL;
> @@ -372,7 +367,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
> opcode,
>
> reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
>
> - rdreg = cqspi_calc_rdreg(nor);
> + rdreg = cqspi_calc_rdreg(f_pdata);
> writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
>
> reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
> @@ -401,25 +396,36 @@ static int cqspi_command_read(struct spi_nor *nor, u8
> opcode,
> return 0;
> }
>
> -static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
> -const u8 *txbuf, size_t n_tx)
> +static int
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 01.06.20 09:04, Vignesh Raghavendra wrote:
> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
> is not yet probed. Currently driver just falls back to using PIO mode
> (which is less efficient) in this case. Instead return probe deferral
> error as is so that driver will be re probed once DMA provider is
> available.
>
> Signed-off-by: Vignesh Raghavendra
> Reviewed-by: Tudor Ambarus
> ---
> .../mtd/spi-nor/controllers/cadence-quadspi.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> index 608ca657ff7f5..0570ebca135a9 100644
> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> @@ -1169,7 +1169,7 @@ static void cqspi_controller_init(struct cqspi_st
> *cqspi)
> cqspi_controller_enable(cqspi, 1);
> }
>
> -static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
> +static int cqspi_request_mmap_dma(struct cqspi_st *cqspi)
> {
> dma_cap_mask_t mask;
>
> @@ -1178,11 +1178,16 @@ static void cqspi_request_mmap_dma(struct cqspi_st
> *cqspi)
>
> cqspi->rx_chan = dma_request_chan_by_mask();
> if (IS_ERR(cqspi->rx_chan)) {
> - dev_err(>pdev->dev, "No Rx DMA available\n");
> + int ret = PTR_ERR(cqspi->rx_chan);
> +
> + if (ret != -EPROBE_DEFER)
> + dev_err(>pdev->dev, "No Rx DMA available\n");
> cqspi->rx_chan = NULL;
> - return;
> + return ret;
> }
> init_completion(>rx_dma_complete);
> +
> + return 0;
> }
>
> static const struct spi_nor_controller_ops cqspi_controller_ops = {
> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
> struct device_node *np)
> dev_dbg(nor->dev, "using direct mode for %s\n",
> mtd->name);
>
> - if (!cqspi->rx_chan)
> - cqspi_request_mmap_dma(cqspi);
> + if (!cqspi->rx_chan) {
> + ret = cqspi_request_mmap_dma(cqspi);
> + if (ret == -EPROBE_DEFER)
> + goto err;
> + }
> }
> }
>
>
This seem to break reading the SPI flash on our IOT2050 [1] (didn't test
the eval board yet).
Without that commit, read happens via PIO, and that works. With the
commit, the pattern
with open("out.bin", "wb") as out:
pos = 0
while pos < 2:
with open("/dev/mtd0", "rb") as mtd:
mtd.seek(pos * 0x1)
out.write(mtd.read(0x1))
pos += 1
gives the wrong result for the second block while
with open("out2.bin", "wb") as out:
with open("/dev/mtd0", "rb") as mtd:
out.write(mtd.read(0x2))
(or "mtd_debug read") is fine.
What could be the reason? Our DTBs and k3-am654-base-board.dtb had some
deviations /wrt the ospi node, but aligning ours to the base board made
no difference.
Jan
[1] https://github.com/siemens/linux/commits/jan/iot2050
Re: [PATCH 0/2][next] update gdb scripts for lockless printk ringbuffer
On 21.08.20 10:08, Petr Mladek wrote: > On Fri 2020-08-14 23:31:23, John Ogness wrote: >> Hi, >> >> When we brought in the new lockless printk ringbuffer, we overlooked the gdb >> scripts. Here are a set of patches to implement gdb support for the new >> ringbuffer. >> >> John Ogness (2): >> scripts/gdb: add utils.read_ulong() >> scripts/gdb: update for lockless printk ringbuffer > > I am not fluent in the gdb macros and python so I did not try any > deep review. But both patches work for me: > > Tested-by: Petr Mladek > > I am going to give it few more days before pushing just in case there is > another feedback. > Thanks, perfect! > Best Regards, > Petr > > BTW: Are you aware of https://github.com/crash-python/crash-python project? > The ambition is to implement "crash" features and even more into > gdb using python extensions. It similar approach like > scripts/gdb/ > > crash-python is being developed sporadically in waves. It is > mostly during a week that is dedicated for such projects > at SUSE. It would be great to get more contributors. > The problem with all those out-of-tree kernel debugging projects is that they are even further away from the changes in upstream they need to adjust to over and over again. It's already hard for scripts/gdb to keep up as only few people are aware of the dependencies, and it's always easy to forget. But it's getting better and better here IMHO. And that was my idea behind pushing things into upstream. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
