[PATCH v4 0/7] support '%pd' and '%pD' for print file name

2024-01-23 Thread Ye Bin
During fault locating, the file name needs to be printed based on the dentry/file address. The offset needs to be calculated each time, which is troublesome. Similar to printk, kprobe supports printing file names for dentry/file addresses. Diff v4 vs v3: 1. Use "argv[i][idx + 3] == 'd'" instead

Re: (subset) [PATCH v4 0/7] Add initial support for SM7125 and Xiaomi SM7125 platform

2023-09-19 Thread Bjorn Andersson
On Sun, 23 Jul 2023 21:05:01 +0200, David Wronek wrote: > This series introduces support for the Qualcomm SM7125 SoC and the > Xiaomi SM7125 platform. > > Applied, thanks! [3/7] dt-bindings: arm: qcom: Document SM7125 and xiaomi,joyeuse board commit:

[PATCH v4 0/7] arm64: dts: renesas: Enable GMSL on R8A77970 V3M Eagle

2021-04-15 Thread Jacopo Mondi
Following the recent v3, this new version: - Two new patches (minor fixes) - Address Laurent's comments on gpio-poc bindings and implementation. Naming might still be discussed - Address Laurent's comments on DTS patches - Last patch not for inclusion Thanks j Jacopo Mondi (4):

Re: [PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming

2021-04-12 Thread Bjorn Andersson
On Mon 12 Apr 00:11 CDT 2021, Viresh Kumar wrote: > On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote: > > ** > > ** NOTE: To "view the full picture", please look at the following > > ** patch series: > > ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355 > >

Re: [PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming

2021-04-11 Thread Viresh Kumar
On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote: > ** > ** NOTE: To "view the full picture", please look at the following > ** patch series: > ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355 > ** This is a subset of that series. > ** > >

[PATCH v4 0/7] fsdax,xfs: Add reflink support for fsdax

2021-04-08 Thread Shiyang Ruan
This patchset is attempt to add CoW support for fsdax, and take XFS, which has both reflink and fsdax feature, as an example. Changes from V3: - Take out the first 3 patches as a cleanup patchset[1], which has been sent yesterday. - Fix usage of code in dax_iomap_cow_copy() - Add comments

[PATCH v4 0/7] Extend regulator notification support

2021-04-06 Thread Matti Vaittinen
Extend regulator notification support This series extends the regulator notification and error flag support. Initial discussion on the topic can be found here: https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/ This series is built on top of the

[PATCH v4 0/7] clk: st: embed clock outputs within drivers

2021-03-31 Thread Alain Volmat
Most of ST clock drivers used by STi platform are updated in order to introduce clock outputs informations within each drivers and thus allow to avoid having to rely on clock-output-names properties within DT clock nodes. For that purpose, drivers are updated to allow handling both modes (with or

[PATCH v4 0/7] phy: qcom-qmp: provide DP phy support for sm8250

2021-03-26 Thread Dmitry Baryshkov
Changes since v3: - Move qcom,sc7180-qmp-usb3-phy and qcom,sdm845-qmp-usb3-phy from qcom,qmp-usb3-dp.yaml to qcom,qmp-phy.yaml - Do not touch qcom,sm8250-qmp-usb3-phy compatible Changes since v2: - Drop unused qmp_v4_usb3_rx_tbl Changes since v1: - Provide dt bindings - Split register

[PATCH V4 0/7] vDPA/ifcvf: enables Intel C5000X-PL virtio-net

2021-03-15 Thread Zhu Lingshan
This series enabled Intel FGPA SmartNIC C5000X-PL virtio-net for vDPA. vDPA requires VIRTIO_F_ACCESS_PLATFORM as a must, this series verify this feature bit when set features. Changes from V3: checks features to set in verify_min_features(Jason) deduce VIRTIO device ID from pdev ids in

[PATCH v4 0/7] Couple improvements for Tegra clk driver

2021-03-12 Thread Dmitry Osipenko
This series fixes couple minor standalone problems of the Tegra clk driver. Changelog: v4: - Added new patch that converts DT bindings to schema. v3: - Added acks from Thierry Reding that he gave to v2. - Added new patch "clk: tegra: Don't allow zero clock rate for PLLs". v2: - Added

[PATCH v4 0/7] Add SR-IOV support in PCIe Endpoint Core

2021-03-10 Thread Kishon Vijay Abraham I
Patch series *) Adds support to add virtual functions to enable endpoint controller which supports SR-IOV capability *) Add support in Cadence endpoint driver to configure virtual functions *) Enable pci_endpoint_test driver to create pci_device for virtual functions v1 of the patch series

[PATCH v4 0/7] Add basic support for Loongson-2K1000

2021-03-09 Thread Qing Zhang
These patches support single-core DTS boot to the serial port login interface, which can be operated using conventional commands. I have successfully tested it on the Loongson 2K1000 machine. pmon: http://cgit.loongnix.org/cgit/pmon-loongson3/ Note: After the basic support is merged, I will

[PATCH v4 0/7] ASoC: codecs: add support for LPASS Codec TX and RX macros

2021-02-10 Thread Srinivas Kandagatla
This patchset adds support for two Codec Macro blocks(TX and RX) available in Qualcomm LPASS (Low Power Audio SubSystem). There are WSA, VA, TX and RX Macros on LPASS IP, each of the Macro block has specific connectivity like WSA Macros are intended to connect to WSA Smart speaker codecs via

Re: [PATCH v4 0/7] gpio: ep93xx: fixes series patch

2021-02-05 Thread Andy Shevchenko
On Fri, Feb 5, 2021 at 12:34 PM Bartosz Golaszewski wrote: > > Nikita, > > please include the review tags from previous series in the future. > Linus has left his Reviewed-by: under v3. As far as I can tell some patches probably can't carry tags due to design changes, otherwise absolutely true,

Re: [PATCH v4 0/7] gpio: ep93xx: fixes series patch

2021-02-05 Thread Bartosz Golaszewski
Nikita, please include the review tags from previous series in the future. Linus has left his Reviewed-by: under v3. Bart On Fri, Feb 5, 2021 at 9:05 AM Nikita Shubin wrote: > > v2: > https://lore.kernel.org/linux-gpio/20210127104617.1173-1-nikita.shu...@maquefel.me/ > > v3: >

[PATCH v4 0/7] gpio: ep93xx: fixes series patch

2021-02-05 Thread Nikita Shubin
v2: https://lore.kernel.org/linux-gpio/20210127104617.1173-1-nikita.shu...@maquefel.me/ v3: https://lore.kernel.org/linux-gpio/20210128122123.25341-1-nikita.shu...@maquefel.me/ v3->v4 changes [PATCH v4 1/7] gpio: ep93xx: fix BUG_ON port F usage As suggested Alexander and Andy, drop confusing

Re: [PATCH v4 0/7] MediaTek IOMMU improve tlb flush performance in map/unmap

2021-01-27 Thread Will Deacon
On Thu, 7 Jan 2021 20:29:02 +0800, Yong Wu wrote: > This patchset is to improve tlb flushing performance in iommu_map/unmap > for MediaTek IOMMU. > > For iommu_map, currently MediaTek IOMMU use IO_PGTABLE_QUIRK_TLBI_ON_MAP > to do tlb_flush for each a memory chunk. this is so unnecessary. we

Re: [PATCH v4 0/7] MediaTek IOMMU improve tlb flush performance in map/unmap

2021-01-22 Thread Will Deacon
On Thu, Jan 07, 2021 at 08:29:02PM +0800, Yong Wu wrote: > This patchset is to improve tlb flushing performance in iommu_map/unmap > for MediaTek IOMMU. > > For iommu_map, currently MediaTek IOMMU use IO_PGTABLE_QUIRK_TLBI_ON_MAP > to do tlb_flush for each a memory chunk. this is so unnecessary.

[PATCH v4 0/7] Count rlimits in each user namespace

2021-01-22 Thread Alexey Gladkov
Preface --- These patches are for binding the rlimit counters to a user in user namespace. This patch set can be applied on top of: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v5.11-rc2 Problem --- The RLIMIT_NPROC, RLIMIT_MEMLOCK, RLIMIT_SIGPENDING, RLIMIT_MSGQUEUE

Re: (subset) [PATCH v4 0/7] Really implement Qualcomm LAB/IBB regulators

2021-01-20 Thread Mark Brown
On Tue, 19 Jan 2021 18:44:14 +0100, AngeloGioacchino Del Regno wrote: > Okay, the title may be a little "aggressive"? However, the qcom-labibb > driver wasn't really .. doing much. > The current form of this driver is only taking care of enabling or > disabling the regulators, which is pretty

[PATCH v4 0/7] Really implement Qualcomm LAB/IBB regulators

2021-01-19 Thread AngeloGioacchino Del Regno
Okay, the title may be a little "aggressive"? However, the qcom-labibb driver wasn't really .. doing much. The current form of this driver is only taking care of enabling or disabling the regulators, which is pretty useless if they were not pre-set from the bootloader, which sets them only if

[PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming

2021-01-19 Thread AngeloGioacchino Del Regno
** ** NOTE: To "view the full picture", please look at the following ** patch series: ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355 ** This is a subset of that series. ** Changes in v4: - Huge patch series has been split for better

[PATCH v4 0/7] MediaTek IOMMU improve tlb flush performance in map/unmap

2021-01-07 Thread Yong Wu
This patchset is to improve tlb flushing performance in iommu_map/unmap for MediaTek IOMMU. For iommu_map, currently MediaTek IOMMU use IO_PGTABLE_QUIRK_TLBI_ON_MAP to do tlb_flush for each a memory chunk. this is so unnecessary. we could improve it by tlb flushing one time at the end of

[PATCH v4 0/7] Add initial support for ATC260x PMICs

2020-12-29 Thread Cristian Ciocaltea
The ATC260x family of PMICs integrates Audio Codec, Power management, Clock generation and GPIO controller blocks. There are currently 3 variants: ATC2603A, ATC2603C and ATC2609A. This is re-spin of the v1 patch series submitted some time ago by Mani, who provided the MFD and regulator drivers

[PATCH v4 0/7] Convert all THP vmstat counters to pages

2020-12-10 Thread Muchun Song
Hi, This patch series is aimed to convert all THP vmstat counters to pages. The unit of some vmstat counters are pages, some are bytes, some are HPAGE_PMD_NR, and some are KiB. When we want to expose these vmstat counters to the userspace, we have to know the unit of the vmstat counters is which

Re: [PATCH v4 0/7] arm64: dts: meson: add more GX soundcards

2020-12-07 Thread Kevin Hilman
On Thu, 3 Dec 2020 06:00:16 +, Christian Hewitt wrote: > This series adds basic support for LPCM audio over HDMI and S/PDIF > to GXBB/GXL/GXM devices that I own and have tested with. Audio can > be extended in the future (some devices have DACs and headphone > hardware to connect) but this

[PATCH v4 0/7] arm64: dts: meson: add more GX soundcards

2020-12-02 Thread Christian Hewitt
This series adds basic support for LPCM audio over HDMI and S/PDIF to GXBB/GXL/GXM devices that I own and have tested with. Audio can be extended in the future (some devices have DACs and headphone hardware to connect) but this gets the basics working. Changes from v3 - Drop includes tidying in

[PATCH v4 0/7] Netronix embedded controller driver for Kobo and Tolino ebook readers

2020-11-22 Thread Jonathan Neuschäfer
This patchset adds basic support for the embedded controller found on older ebook reader boards designed by/with the ODM Netronix Inc.[1] and sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine. These drivers are based on information contained in the vendor kernel sources, but

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-20 Thread Lu Baolu
On 2020/11/3 18:54, Joerg Roedel wrote: Hi, On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote: Would that work for you? We intend to send the feature pull requests to DRM for 5.11 in the upcoming weeks. For the IOMMU side it is best to include the workaround for now. When the

[PATCH v4 0/7] Enable rk3066a HDMI sound

2020-11-17 Thread Johan Jonker
First fix some legacy things in clk-rk3188.c that was never updated, because probably nobody used rk3066a I2S before in the mainline kernel. Update the rk3066a HDMI documents with a #sound-dai-cells property. Include the code for sound in the HDMI driver. Add a simple-sound-card compatible node to

Re: [PATCH v4 0/7] gpio: exar: refactor the driver

2020-11-10 Thread Andy Shevchenko
On Tue, Nov 10, 2020 at 5:07 PM Andy Shevchenko wrote: > On Tue, Nov 10, 2020 at 03:55:45PM +0100, Bartosz Golaszewski wrote: > With reverted reg_width change I should have relaxed this to "with whatever settlement we become about regmap configuration". > Reviewed-by: Andy Shevchenko --

Re: [PATCH v4 0/7] gpio: exar: refactor the driver

2020-11-10 Thread Andy Shevchenko
On Tue, Nov 10, 2020 at 03:55:45PM +0100, 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

[PATCH v4 0/7] gpio: exar: refactor the driver

2020-11-10 Thread Bartosz Golaszewski
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. v1 -> v2: - add

Re: [PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-11-09 Thread Jagan Teki
On Mon, Nov 9, 2020 at 4:45 AM Heiko Stuebner wrote: > > Hi, > > Am Dienstag, 29. September 2020, 10:32:10 CET schrieb Jagan Teki: > > PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. > > > > PX30.Core needs to mount on top of Engicam baseboards for creating > > complete platform

Re: [PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-11-08 Thread Heiko Stuebner
Hi, Am Dienstag, 29. September 2020, 10:32:10 CET schrieb Jagan Teki: > PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. > > PX30.Core needs to mount on top of Engicam baseboards for creating > complete platform boards. > > Possible baseboards are, > - EDIMM2.2 Starter Kit > -

Re: [PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-11-04 Thread Heiko Stübner
Am Mittwoch, 4. November 2020, 20:54:40 CET schrieb Jagan Teki: > On Thu, Oct 22, 2020 at 12:27 AM Jagan Teki > wrote: > > > > Hi Heiko, > > > > On Tue, Sep 29, 2020 at 2:02 PM Jagan Teki > > wrote: > > > > > > PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. > > > > > >

Re: [PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-11-04 Thread Jagan Teki
On Thu, Oct 22, 2020 at 12:27 AM Jagan Teki wrote: > > Hi Heiko, > > On Tue, Sep 29, 2020 at 2:02 PM Jagan Teki wrote: > > > > PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. > > > > PX30.Core needs to mount on top of Engicam baseboards for creating > > complete platform boards. >

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-03 Thread Joerg Roedel
Hi, On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote: > Would that work for you? We intend to send the feature pull requests > to DRM for 5.11 in the upcoming weeks. For the IOMMU side it is best to include the workaround for now. When the DRM fixes are merged into v5.11-rc1

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-03 Thread Joonas Lahtinen
Quoting Tvrtko Ursulin (2020-11-03 11:14:32) > > > On 03/11/2020 02:53, Lu Baolu wrote: > > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote: > >> > >> On 02/11/2020 02:00, Lu Baolu wrote: > >>> Hi Tvrtko, > >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: > > On 29/09/2020 01:11, Lu Baolu

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-03 Thread Tvrtko Ursulin
On 03/11/2020 02:53, Lu Baolu wrote: On 11/2/20 7:52 PM, Tvrtko Ursulin wrote: On 02/11/2020 02:00, Lu Baolu wrote: Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-02 Thread Lu Baolu
On 11/2/20 7:52 PM, Tvrtko Ursulin wrote: On 02/11/2020 02:00, Lu Baolu wrote: Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-02 Thread Tvrtko Ursulin
On 02/11/2020 02:00, Lu Baolu wrote: Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here.

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-01 Thread Lu Baolu
Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here.

[RESEND][PATCH v4 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

2020-10-28 Thread John Stultz
Hey All, So just wanted to resend my last revision of my patch series of performance optimizations to the dma-buf system heap. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers

Re: [PATCH v4 0/7] mtd: spi-nor: add xSPI Octal DTR support

2020-10-28 Thread Tudor.Ambarus
Hi, Mason, YC Lin, We'll have to figure out how we can best use the "Command Sequences to Change to Octal DDR" table. Would be great if you continue to work on this. One has to rebase this series on top of v5.10-rc1 with Pratyush's series [1] applied in advance. Please let me know about your

Re: [PATCH v4 0/7] arm64: Default to 32-bit wide ZONE_DMA

2020-10-27 Thread Nicolas Saenz Julienne
On Fri, 2020-10-23 at 14:05 -0500, Jeremy Linton wrote: > Hi, > > On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote: > > Using two distinct DMA zones turned out to be problematic. Here's an > > attempt go back to a saner default. > > > > I tested this on both a RPi4 and QEMU. > > I've tested

Re: [PATCH v4 0/7] arm64: Default to 32-bit wide ZONE_DMA

2020-10-23 Thread Jeremy Linton
Hi, On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote: Using two distinct DMA zones turned out to be problematic. Here's an attempt go back to a saner default. I tested this on both a RPi4 and QEMU. I've tested this in ACPI mode on the rpi4 (4+8G with/without the 3G limiter) as well, with

Re: [PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-10-21 Thread Jagan Teki
Hi Heiko, On Tue, Sep 29, 2020 at 2:02 PM Jagan Teki wrote: > > PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. > > PX30.Core needs to mount on top of Engicam baseboards for creating > complete platform boards. > > Possible baseboards are, > - EDIMM2.2 Starter Kit > - C.TOUCH 2.0

[PATCH v4 0/7] arm64: Default to 32-bit wide ZONE_DMA

2020-10-21 Thread Nicolas Saenz Julienne
Using two distinct DMA zones turned out to be problematic. Here's an attempt go back to a saner default. I tested this on both a RPi4 and QEMU. --- Changes since v3: - Drop patch adding define in dma-mapping - Address small review changes - Update Ard's patch - Add new patch removing

[PATCH v4 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

2020-10-17 Thread John Stultz
Hey All, So this is another revision of my patch series to performance optimizations to the dma-buf system heap. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-12 Thread Lu Baolu
Hi Tvrtko, On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here.

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-12 Thread Tvrtko Ursulin
On 29/09/2020 01:11, Lu Baolu wrote: Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here. https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ This version

[PATCH v4 0/7] FPGA Security Manager Class Driver

2020-10-07 Thread Russ Weight
The FPGA Security Manager class driver provides a common API for user-space tools to manage updates for secure FPGA devices. Device drivers that instantiate the FPGA Security Manager class driver will interact with a HW secure update engine in order to transfer new FPGA and BMC images to FLASH so

[PATCH v4 0/7] tracing: Add dynamic strings for synthetic events

2020-10-04 Thread Tom Zanussi
Hi, This is v4 of the dynamic string support for synthetic events. This version adds several patches addressing previous comments - a new testcase for the dynamic synth event strings along with a patch adding a blurb about the synthetic_events file, which should have been there in any case,

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-02 Thread Lu Baolu
Hi Joerg, On 2020/10/1 20:17, Joerg Roedel wrote: Hi Baolu, On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote: I have no preference. It depends on which patch goes first. Let the maintainers help here. No preference on my side, except that it is too late for this now to make it into

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-01 Thread Logan Gunthorpe
Hi Lu, On 2020-09-27 12:34 a.m., Lu Baolu wrote: > Hi, > > The previous post of this series could be found here. > > https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ > > This version introduce a new patch [4/7] to fix an issue reported here. > >

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-10-01 Thread Joerg Roedel
Hi Baolu, On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote: > I have no preference. It depends on which patch goes first. Let the > maintainers help here. No preference on my side, except that it is too late for this now to make it into v5.10. Besides that I let the decission up to you

[PATCH v4 0/7] clk: axi-clk-gen: misc updates to the driver

2020-09-29 Thread Alexandru Ardelean
These patches synchronize the driver with the current state in the Analog Devices Linux tree: https://github.com/analogdevicesinc/linux/ They have been in the tree for about 2-3, so they did receive some testing. Highlights are: * Add support for fractional dividers (Lars-Peter Clausen) *

[PATCH v4 0/7] clk: axi-clk-gen: misc updates to the driver

2020-09-29 Thread Alexandru Ardelean
These patches synchronize the driver with the current state in the Analog Devices Linux tree: https://github.com/analogdevicesinc/linux/ They have been in the tree for about 2-3, so they did receive some testing. Highlights are: * Add support for fractional dividers (Lars-Peter Clausen) *

[PATCH v4 0/7] arm64: dts: rockchip: Add Engicam PX30.Core

2020-09-29 Thread Jagan Teki
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. PX30.Core needs to mount on top of Engicam baseboards for creating complete platform boards. Possible baseboards are, - EDIMM2.2 Starter Kit - C.TOUCH 2.0 Carrier Board Changes for v4: - collect Rob A-b Changes for v3: - resolved

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-09-28 Thread Lu Baolu
Hi Tvrtko, On 9/28/20 5:44 PM, Tvrtko Ursulin wrote: On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here. https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ This version introduce a new patch [4/7] to fix an

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-09-28 Thread Tvrtko Ursulin
On 27/09/2020 07:34, Lu Baolu wrote: Hi, The previous post of this series could be found here. https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ This version introduce a new patch [4/7] to fix an issue reported here.

[PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-09-27 Thread Lu Baolu
Hi, The previous post of this series could be found here. https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/ This version introduce a new patch [4/7] to fix an issue reported here.

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-18 Thread a...@ruivo.org
On Thu, Sep 17, 2020 at 03:27:18PM +, HORIGUCHI NAOYA(堀口 直也) wrote: > The test passed in my environment, so this is fine. With everything applied, it works for me as well. (apologies for the delay, the machine I was using stopped working and took a while to get another one) -- Aristeu

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread osalvador
On 2020-09-17 17:27, HORIGUCHI NAOYA wrote: Sorry, I modified the patches based on the different assumption from yours. I firstly thought of taking page off after confirming the error page is freed back to buddy. This approach leaves the possibility of reusing the error page (which is

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread 堀口 直也
On Thu, Sep 17, 2020 at 03:40:06PM +0200, Oscar Salvador wrote: > On Thu, Sep 17, 2020 at 03:09:52PM +0200, Oscar Salvador wrote: > > static bool page_handle_poison(struct page *page, bool > > hugepage_or_freepage, bool release) > > { > > if (release) { > > put_page(page);

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread Oscar Salvador
On Thu, Sep 17, 2020 at 03:09:52PM +0200, Oscar Salvador wrote: > static bool page_handle_poison(struct page *page, bool hugepage_or_freepage, > bool release) > { > if (release) { > put_page(page); > drain_all_pages(page_zone(page)); > } > >

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread Oscar Salvador
On Thu, Sep 17, 2020 at 11:39:21AM +, HORIGUCHI NAOYA(堀口 直也) wrote: > Thanks for the update. > This patchset triggers the following BUG_ON() with Aristeu's workload: I just took a look, but I found more oddities. The patchset you sent seems to be a bit buggy and it is missing some things my

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread 堀口 直也
On Thu, Sep 17, 2020 at 10:10:42AM +0200, Oscar Salvador wrote: > This patchset includes some fixups (patch#1,patch#2 and patch#3) > and some cleanups (patch#4-7). > > Patch#1 is a fix to take off HWPoison pages off a buddy freelist since > it can lead us to having HWPoison pages back in the game

[PATCH v4 0/7] HWpoison: further fixes and cleanups

2020-09-17 Thread Oscar Salvador
This patchset includes some fixups (patch#1,patch#2 and patch#3) and some cleanups (patch#4-7). Patch#1 is a fix to take off HWPoison pages off a buddy freelist since it can lead us to having HWPoison pages back in the game without no one noticing it. So fix it (we did that already for

[PATCH v4 0/7] power: supply: max17040 support compatible devices

2020-09-06 Thread Iskren Chernev
From: Iskren Chernev The max17040 fuel gauge is part of a family of 8 chips that have very similar mode of operations and registers. This patch set adds: - compatible strings for all supported devices and handles the minor differences between them; - handling for devices reporting double

[Patch v4 0/7] mm/hugetlb: code refine and simplification

2020-08-31 Thread Wei Yang
Following are some cleanup for hugetlb. Simple test with tools/testing/selftests/vm/map_hugetlb pass. v4: * fix a logic error for patch 7, thanks Mike v3: * rebase on v5.9-rc2 which adjust the last patch a little v2: * drop 5/6/10 since similar patches are merged or under review. *

Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-08-26 Thread Enric Balletbo i Serra
Hi Bilal, On 24/8/20 21:01, Bilal Wasim wrote: > Hi Chun-Kuan, Enric, > > Is there any plan to merge the following commits in this series to the > mainline? > > drm/bridge: ps8640: Get the EDID from eDP control > drm/bridge_connector: Set default status connected for eDP connectors >

[PATCH v4 0/7] perf: Stream comparison

2020-08-25 Thread Jin Yao
Sometimes, a small change in a hot function reducing the cycles of this function, but the overall workload doesn't get faster. It is interesting where the cycles are moved to. What it would like is to diff before/after streams. The stream is the branch history which is aggregated by the branch

[PATCH v4 0/7] Fix timeout clock used by hardware data timeout

2020-08-24 Thread Sowjanya Komatineni
Tegra210/Tegra186/Tegra194 has incorrectly enabled SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support. Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK) all the time for hardware data timeout instead of SDCLK and this TMCLK need to be kept enabled by

Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-08-24 Thread Bilal Wasim
Hi Chun-Kuan, Enric, Is there any plan to merge the following commits in this series to the mainline? drm/bridge: ps8640: Get the EDID from eDP control drm/bridge_connector: Set default status connected for eDP connectors I see that rest of the patchset is already merged and available in

Re: [PATCH v4 0/7] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-08-21 Thread Guenter Roeck
On 8/21/20 1:21 AM, Enric Balletbo i Serra wrote: > Hi Guenter et all, > > On 6/8/20 17:33, Guenter Roeck wrote: >> The EC reports a variety of error codes. Most of those, with the exception >> of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual >> error code gets lost. In

Re: [PATCH v4 0/7] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-08-21 Thread Enric Balletbo i Serra
Hi Guenter et all, On 6/8/20 17:33, Guenter Roeck wrote: > The EC reports a variety of error codes. Most of those, with the exception > of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual > error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors > to Linux

[PATCH v4 0/7] irqchip: qcom: pdc: Introduce irq_set_wake call

2020-08-10 Thread Maulik Shah
Changes in v4: - Drop "Remove irq_disable callback from msmgpio irqchip" patch from v3 - Introduce irq_suspend_one() and irq_resume_one() callbacks - Use the new callbacks to unmask wake interrupts during suspend - Reset only pdc interrupts that are mapped in DTSI Changes in v3: - Drop gpiolib

[PATCH v4 0/7] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-08-06 Thread Guenter Roeck
The EC reports a variety of error codes. Most of those, with the exception of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors to Linux error codes to report a more meaningful error to the caller to

[PATCH v4 0/7] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-08-06 Thread Guenter Roeck
The EC reports a variety of error codes. Most of those, with the exception of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors to Linux error codes to report a more meaningful error to the caller to

Re: [PATCH v4 0/7] Support inhibiting input devices

2020-08-03 Thread Andrzej Pietrasiewicz
Hi Dmitry, W dniu 12.06.2020 o 10:17, Hans de Goede pisze: Hi, On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote: This is a quick respin of v3, with just two small changes, please see the changelog below. Userspace might want to implement a policy to temporarily disregard input from certain

Re: [PATCH V4 0/7] Tegra XUSB charger detect support

2020-07-17 Thread Vinod Koul
On 16-07-20, 14:48, Thierry Reding wrote: > Hi Kishon, Vinod, > > did you have any further comments on this series or is it good to go > into v5.9? I dont have this series in my inbox, can you please rebase and resend -- ~Vinod

[PATCH v4 0/7] arch/x86: kprobes: Remove MODULES dependency

2020-07-16 Thread Jarkko Sakkinen
Remove MODULES dependency by migrating from module_alloc() to the new text_alloc() API. Essentially these changes provide preliminaries for allowing to compile a static kernel with a proper tracing support. The same API can be used later on in other sites that allocate space for trampolines, and

Re: [PATCH V4 0/7] Tegra XUSB charger detect support

2020-07-16 Thread Thierry Reding
On Fri, Jun 26, 2020 at 03:48:55PM +0530, Nagarjuna Kristam wrote: > This patch series adds charger detect support on XUSB hardware used in > Tegra210 and Tegra186 SoCs. > > This patchset is composed with : > - dt bindings of XUSB Pad Controller > - Tegra XUSB device mode driver to add

[PATCH v4 0/7] Remove default DMA window before creating DDW

2020-07-16 Thread Leonardo Bras
There are some devices in which a hypervisor may only allow 1 DMA window to exist at a time, and in those cases, a DDW is never created to them, since the default DMA window keeps using this resource. LoPAR recommends this procedure: 1. Remove the default DMA window, 2. Query for which configs

[PATCH v4 0/7] Add support for ipq8064 tsens

2020-07-15 Thread Ansuel Smith
Ipq8064 SoCs tsens driver is based on 8960 tsens driver. This patchset expand the 8960 unused driver with interrupt support and set_trip point. Ipq8064 needs to be registered as a gcc child as the tsens regs on this platform are shared with the controller. v4: * Fix compilation error and warning

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 10:43:11PM +0200, Sedat Dilek wrote: > If we move to LDFLAGS_vmlinux we can drop the "call ld-option" as both > linker GNU/ld.bfd and LLVM/lld.ld support this? No, because ld.bfd only started supporting it from v2.26, and the kernel aims to be buildable with v2.23. > >

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 10:35 PM Arvind Sankar wrote: > > On Tue, Jul 14, 2020 at 10:27:25PM +0200, Sedat Dilek wrote: > > On Tue, Jul 14, 2020 at 10:24 PM Sedat Dilek wrote: > > > > > > On Tue, Jul 14, 2020 at 10:21 PM Arvind Sankar > > > wrote: > > > > > > > > On Tue, Jul 14, 2020 at

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 10:27:25PM +0200, Sedat Dilek wrote: > On Tue, Jul 14, 2020 at 10:24 PM Sedat Dilek wrote: > > > > On Tue, Jul 14, 2020 at 10:21 PM Arvind Sankar > > wrote: > > > > > > On Tue, Jul 14, 2020 at 10:08:04PM +0200, Sedat Dilek wrote: > > > > > > > > > > > > In any case, I

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 10:24:07PM +0200, Sedat Dilek wrote: > On Tue, Jul 14, 2020 at 10:21 PM Arvind Sankar wrote: > > > > On Tue, Jul 14, 2020 at 10:08:04PM +0200, Sedat Dilek wrote: > > > > > > > > > > In any case, I think the right fix here would be to add -pie and > > > > >

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 10:08:04PM +0200, Sedat Dilek wrote: > > > > > > In any case, I think the right fix here would be to add -pie and > > > --no-dynamic-linker to LDFLAGS_vmlinux instead of KBUILD_LDFLAGS. > > > > Hmm, you might be right with moving to LDFLAGS_vmlinux. > > > > We will need

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 10:24 PM Sedat Dilek wrote: > > On Tue, Jul 14, 2020 at 10:21 PM Arvind Sankar wrote: > > > > On Tue, Jul 14, 2020 at 10:08:04PM +0200, Sedat Dilek wrote: > > > > > > > > > > In any case, I think the right fix here would be to add -pie and > > > > > --no-dynamic-linker to

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 10:21 PM Arvind Sankar wrote: > > On Tue, Jul 14, 2020 at 10:08:04PM +0200, Sedat Dilek wrote: > > > > > > > > In any case, I think the right fix here would be to add -pie and > > > > --no-dynamic-linker to LDFLAGS_vmlinux instead of KBUILD_LDFLAGS. > > > > > > Hmm, you

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 10:14 PM Arvind Sankar wrote: > > On Tue, Jul 14, 2020 at 10:10:14PM +0200, Sedat Dilek wrote: > > On Tue, Jul 14, 2020 at 10:07 PM Arvind Sankar > > wrote: > > > > > > On Tue, Jul 14, 2020 at 09:53:19PM +0200, Sedat Dilek wrote: > > > > > > > > Hmm, you might be right

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 10:10:14PM +0200, Sedat Dilek wrote: > On Tue, Jul 14, 2020 at 10:07 PM Arvind Sankar wrote: > > > > On Tue, Jul 14, 2020 at 09:53:19PM +0200, Sedat Dilek wrote: > > > > > > Hmm, you might be right with moving to LDFLAGS_vmlinux. > > > > > > Attached are my linux-config

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 10:07 PM Arvind Sankar wrote: > > On Tue, Jul 14, 2020 at 09:53:19PM +0200, Sedat Dilek wrote: > > > > Hmm, you might be right with moving to LDFLAGS_vmlinux. > > > > Attached are my linux-config and dmesg-output. > > > > - Sedat - > > Which tree are you building against?

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Sedat Dilek
On Tue, Jul 14, 2020 at 9:53 PM Sedat Dilek wrote: > > On Tue, Jul 14, 2020 at 9:29 PM Arvind Sankar wrote: > > > > On Tue, Jul 14, 2020 at 08:30:14PM +0200, Sedat Dilek wrote: > > > > I did a full new build... > > > > > > > > ...and it fails with ld.lld-11 as linker: > > > > > > > > ld.lld-11

Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel

2020-07-14 Thread Arvind Sankar
On Tue, Jul 14, 2020 at 09:53:19PM +0200, Sedat Dilek wrote: > > Hmm, you might be right with moving to LDFLAGS_vmlinux. > > Attached are my linux-config and dmesg-output. > > - Sedat - Which tree are you building against? I notice you have KERNEL_ZSTD enabled, which hasn't been merged yet.

  1   2   3   4   5   6   7   8   9   10   >