On 26.06.25 18:17, Liam R. Howlett wrote:
> * Florian Fainelli [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, et
message. ]
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: David S. Miller
Signed-off-by: Jan Kiszka
---
include/linux/u64_stats_sync.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/u64_stats_sync.h b/include/linux
As 5.10 requires some manual work, here are the two patches needed to
address [1].
Note that 5.15-rt already has the fix (f036d9effdba). 6.1-rt and 6.6-rt
can pick 4a1d3acd6ea8 without conflicts or dependencies.
Pavel, please check 4.19-cip-rt and 4.4-cip-rt. I suspect the task is a
bit bigger th
: Eric Dumazet
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Jan Kiszka
---
net/netfilter/nft_counter.c | 78 +++--
1 file changed, 40 insertions(+), 38 deletions(-)
diff --git a/net/netfilter/nft_counter.c b/net/netfilter
On 19.02.25 23:07, Luis Claudio R. Goncalves wrote:
> Hello RT-list!
>
> I'm pleased to announce the 5.10.234-rt126 stable release.
>
> This release is just an update to the new stable 5.10.234 version and
> no RT-specific changes have been made.
>
Was [1] coming too late for this release cycle
On 22.08.24 07:42, Beleswar Prasad Padhi wrote:
>
> On 22-08-2024 10:57, Jan Kiszka wrote:
>> On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
>>> On 21-08-2024 23:40, Jan Kiszka wrote:
>>>> On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
>>>>> On
On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
>
> On 21-08-2024 23:40, Jan Kiszka wrote:
>> On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
>>> On 19-08-2024 20:54, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>>
>>>> By simply ba
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
>
> On 19-08-2024 20:54, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> By simply bailing out, the driver was violating its rule and internal
>
>
> Using device lifecycle managed functions to register the rproc
>
On 20.08.24 11:48, Beleswar Prasad Padhi wrote:
>
> On 20-08-2024 15:09, Jan Kiszka wrote:
>> On 20.08.24 11:30, Beleswar Prasad Padhi wrote:
>>> Hi Jan,
>>>
>>> On 19-08-2024 22:17, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>>
&g
On 20.08.24 11:30, Beleswar Prasad Padhi wrote:
> Hi Jan,
>
> On 19-08-2024 22:17, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
>> first. When core 0 should then be stopped before its removal
From: Jan Kiszka
When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
first. When core 0 should then be stopped before its removal, it will
find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
Fixes: 3c8a9066d584 ("remoteproc: k3-r5: Do not allow core1
From: Jan Kiszka
By simply bailing out, the driver was violating its rule and internal
assumptions that either both or no rproc should be initialized. E.g.,
this could cause the first core to be available but not the second one,
leading to crashes on its shutdown later on while trying to
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
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
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 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 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.
>>>>
>>>> Si
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
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
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 con
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:
> -
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
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.co
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
>>> ---
>>&g
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/zynq
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:
>>>>
>>>&g
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
>>
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
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 afte
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,
[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,
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:
>>>>&g
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
>>>>
>
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_DE
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 hard
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 avai
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 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 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:
>>>>&g
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
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:
>>>>
>
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 no
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(
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
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
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
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
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
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 = "ro
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&g
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 si
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
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
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
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
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 nu
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 nu
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
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
>&
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 S
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_tas
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
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 don
_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(&pdev->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
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 miss
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
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
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
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
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
oids?
> 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.
Signed-off-by: Jan Kiszka
---
.../devicetree/bindings/arm/ti/k3.yaml| 2 +
arch/arm64/boot/dts/ti
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/s
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 bin
e("list_for_each: Uninitialized list '{}' treated as
>> empty\n"
>> + .format(head.address))
>> + return
>> +
>> node = head['next'].dereference()
>> while node.address != head.address:
>> yie
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
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
> ---
>
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
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: Bart
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
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
>
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:
> [...
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 aea6
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 ca
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
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 functi
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 bu
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
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
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 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 wro
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
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] inval
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 c
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
eady 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..a730e
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 a
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 Kiszk
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:
>>
>> [
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
1 - 100 of 1048 matches
Mail list logo
