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] -
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 +-
>
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
[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
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 h
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
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
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
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 S
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
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
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
PU_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&qu
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
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
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 m
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
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.
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
> ---
>
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
st_for_each: Uninitialized list '{}' treated as
>> empty\n"
>> + .format(head.address))
>> + return
>> +
>> node = head['next'].dereference()
>> while node.address != head.address:
>> yield node.address
>
> Hap
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
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 simple
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
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
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
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
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 wro
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]
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
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 decodi
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
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 +---
>
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 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:
>>>>> dm
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:
>>>>
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 provide
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 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
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/cmdl
re...@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 w
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.
>
>
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
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):
>>
1 - 100 of 2566 matches
Mail list logo
