Re: [PATCH net-next 2/5] virtio_net: Add page_pool support to improve performance
在 2023/12/1 9:38, Xuan Zhuo 写道: On Thu, 30 Nov 2023 13:30:40 +0800, Zhu Yanjun wrote: 在 2023/11/30 10:34, Xuan Zhuo 写道: On Wed, 29 Nov 2023 23:29:10 +0800, Zhu Yanjun wrote: 在 2023/11/29 23:22, Zhu Yanjun 写道: 在 2023/11/29 22:59, Michael S. Tsirkin 写道: On Wed, Nov 29, 2023 at 10:50:57PM +0800, Zhu Yanjun wrote: 在 2023/5/26 13:46, Liang Chen 写道: what made you respond to a patch from May, now? I want to apply page_pool to our virtio_net. This virtio_net works on our device. I want to verify whether page_pool on virtio_net with our device can improve the performance or not. And I found that ethtool is wrong. I use virtio_net on our device. I found that page member variable in rq is not used in recv path. When virtio_net is modprobe, I checked page member variable in rq with kprobe or crash tool. page member variable in rq is always NULL. But sg in recv path is used. So how to use page member variable in rq? If page member variable in rq is always NULL, can we remove it? BTW, I use ping and iperf tool to make tests with virtio_net. In the tests, page member variable in rq is always NULL. And I replaced page member variable in rq with page_pool, but the statistics of page_pool are always 0. It is interesting that page_pool member variable in rq is not used in ping and iperf tests. I am not sure what tests can make page member variable not NULL. ^_^ Do you mean rq->pages? That is for big mode. Hi, Xuan Got it. What is big mode? Do you mean big packet size? I run iperf with the packet size 2^23. The rq->pages is still NULL. It is interesting. You may need to check the code of virtnet_probe(). Thanks a lot. From virtnet_probe, big mode and mergeable mode can be found. Zhu Yanjun Thanks. Zhu Yanjun Thanks. Best Regards, Zhu Yanjun It is interesting. Zhu Yanjun
[PATCH 1/2] ARM: dts: qcom: msm8226: Sort and clean up nodes
From: Matti Lehtimäki
Quite a few nodes haven't been sorted correctly by reg, so let's do this
now so that future nodes can be added at the correct place.
Also at the same time, move the status property last.
No functional change intended.
Signed-off-by: Matti Lehtimäki
[luca: add more text to commit message]
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 660 +++
1 file changed, 330 insertions(+), 330 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index 97a377b5a0ec..8757bc0c8a0f 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -20,11 +20,6 @@ / {
chosen { };
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0>;
- };
-
clocks {
xo_board: xo_board {
compatible = "fixed-clock";
@@ -47,6 +42,11 @@ scm {
};
};
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0>;
+ };
+
pmu {
compatible = "arm,cortex-a7-pmu";
interrupts = ;
};
+ timer@f902 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0xf902 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ frame@f9021000 {
+ frame-number = <0>;
+ interrupts = ,
+;
+ reg = <0xf9021000 0x1000>,
+ <0xf9022000 0x1000>;
+ };
+
+ frame@f9023000 {
+ frame-number = <1>;
+ interrupts = ;
+ reg = <0xf9023000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9024000 {
+ frame-number = <2>;
+ interrupts = ;
+ reg = <0xf9024000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9025000 {
+ frame-number = <3>;
+ interrupts = ;
+ reg = <0xf9025000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9026000 {
+ frame-number = <4>;
+ interrupts = ;
+ reg = <0xf9026000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9027000 {
+ frame-number = <5>;
+ interrupts = ;
+ reg = <0xf9027000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9028000 {
+ frame-number = <6>;
+ interrupts = ;
+ reg = <0xf9028000 0x1000>;
+ status = "disabled";
+ };
+ };
+
sdhc_1: mmc@f9824900 {
compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
@@ -201,22 +259,6 @@ sdhc_1: mmc@f9824900 {
status = "disabled";
};
- sdhc_2: mmc@f98a4900 {
- compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
- reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
- reg-names = "hc", "core";
- interrupts = ,
-;
- interrupt-names = "hc_irq", "pwr_irq";
- clocks = <&gcc GCC_SDCC2_AHB_CLK>,
-<&gcc GCC_SDCC2_APPS_CLK>,
-<&rpmcc RPM_SMD_XO_CLK_SRC>;
- clock-names = "iface", "core", "xo";
- pinctrl-names = "default";
- pinctrl-0 = <&sdhc2_default_state>;
- status = "disabled";
- };
-
sdhc_3: mmc@f9864900 {
compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
reg = <0xf9864900 0x11c>, <0xf9864000 0x800>;
@@ -233,6 +275,22 @@ sdhc_3: mmc@f9864900 {
status = "disabled";
};
+ sdhc_2: mmc@f98a4900 {
+
[PATCH 0/2] Bring up more CPU cores on MSM8226
Add some nodes to bring up SMP on msm8226 SoC. Another commit to fix the sorting of the nodes is also included since the ordering is currently a bit all over the place. Signed-off-by: Luca Weiss --- Ivaylo Ivanov (1): ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes Matti Lehtimäki (1): ARM: dts: qcom: msm8226: Sort and clean up nodes arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 751 +-- 1 file changed, 421 insertions(+), 330 deletions(-) --- base-commit: 63b325612c1e996a107fc156db8ea9b756a9f65c change-id: 20231203-msm8226-cpu-801bebbed886 Best regards, -- Luca Weiss
[PATCH 2/2] ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes
From: Ivaylo Ivanov
Add CPU and SAW/ACC nodes to enable SMP on MSM8226.
Signed-off-by: Ivaylo Ivanov
[luca: update some nodes to fix dtbs_check errors, reorder, cleanup]
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 91
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index 8757bc0c8a0f..28abaed4dd08 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -34,6 +34,57 @@ sleep_clk: sleep_clk {
};
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ compatible = "arm,cortex-a7";
+ enable-method = "qcom,msm8226-smp";
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
+ };
+
+ CPU1: cpu@1 {
+ compatible = "arm,cortex-a7";
+ enable-method = "qcom,msm8226-smp";
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ qcom,acc = <&acc1>;
+ qcom,saw = <&saw1>;
+ };
+
+ CPU2: cpu@2 {
+ compatible = "arm,cortex-a7";
+ enable-method = "qcom,msm8226-smp";
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <&L2>;
+ qcom,acc = <&acc2>;
+ qcom,saw = <&saw2>;
+ };
+
+ CPU3: cpu@3 {
+ compatible = "arm,cortex-a7";
+ enable-method = "qcom,msm8226-smp";
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <&L2>;
+ qcom,acc = <&acc3>;
+ qcom,saw = <&saw3>;
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-unified;
+ };
+ };
+
firmware {
scm {
compatible = "qcom,scm-msm8226", "qcom,scm";
@@ -243,6 +294,46 @@ frame@f9028000 {
};
};
+ acc0: power-manager@f9088000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf9088000 0x1000>, <0xf9008000 0x1000>;
+ };
+
+ saw0: power-manager@f9089000 {
+ compatible = "qcom,msm8226-saw2-v2.1-cpu", "qcom,saw2";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ acc1: power-manager@f9098000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf9098000 0x1000>, <0xf9008000 0x1000>;
+ };
+
+ saw1: power-manager@f9099000 {
+ compatible = "qcom,msm8226-saw2-v2.1-cpu", "qcom,saw2";
+ reg = <0xf9099000 0x1000>;
+ };
+
+ acc2: power-manager@f90a8000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf90a8000 0x1000>, <0xf9008000 0x1000>;
+ };
+
+ saw2: power-manager@f90a9000 {
+ compatible = "qcom,msm8226-saw2-v2.1-cpu", "qcom,saw2";
+ reg = <0xf90a9000 0x1000>;
+ };
+
+ acc3: power-manager@f90b8000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf90b8000 0x1000>, <0xf9008000 0x1000>;
+ };
+
+ saw3: power-manager@f90b9000 {
+ compatible = "qcom,msm8226-saw2-v2.1-cpu", "qcom,saw2";
+ reg = <0xf90b9000 0x1000>;
+ };
+
sdhc_1: mmc@f9824900 {
compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
--
2.43.0
Re: [PATCH vhost 0/7] vdpa/mlx5: Add support for resumable vqs
On Sun, Dec 03, 2023 at 03:21:01PM +, Dragos Tatulea wrote: > On Sat, 2023-12-02 at 15:26 -0500, Michael S. Tsirkin wrote: > > On Fri, Dec 01, 2023 at 12:48:50PM +0200, Dragos Tatulea wrote: > > > Add support for resumable vqs in the driver. This is a firmware feature > > > that can be used for the following benefits: > > > - Full device .suspend/.resume. > > > - .set_map doesn't need to destroy and create new vqs anymore just to > > > update the map. When resumable vqs are supported it is enough to > > > suspend the vqs, set the new maps, and then resume the vqs. > > > > > > The first patch exposes the relevant bits in mlx5_ifc.h. That means it > > > needs to be applied to the mlx5-vhost tree [0] first. > > > > I didn't get this. Why does this need to go through that tree? > > Is there a dependency on some other commit from that tree? > > > To avoid merge issues in Linus's tree in mlx5_ifc.h. The idea is the same as > for > the "vq descriptor mappings" patchset [1]. > > Thanks, > Dragos Are there other changes in that area that will cause non-trivial merge conflicts? > > > Once applied > > > there, the change has to be pulled from mlx5-vhost into the vhost tree > > > and only then the remaining patches can be applied. Same flow as the vq > > > descriptor mappings patchset [1]. > > > > > > To be able to use resumable vqs properly, support for selectively > > > modifying > > > vq parameters was needed. This is what the middle part of the series > > > consists of. > > > > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-vhost > > > [1] > > > https://lore.kernel.org/virtualization/20231018171456.1624030-2-dtatu...@nvidia.com/ > > > > > > Dragos Tatulea (7): > > > vdpa/mlx5: Expose resumable vq capability > > > vdpa/mlx5: Split function into locked and unlocked variants > > > vdpa/mlx5: Allow modifying multiple vq fields in one modify command > > > vdpa/mlx5: Introduce per vq and device resume > > > vdpa/mlx5: Mark vq addrs for modification in hw vq > > > vdpa/mlx5: Mark vq state for modification in hw vq > > > vdpa/mlx5: Use vq suspend/resume during .set_map > > > > > > drivers/vdpa/mlx5/core/mr.c| 31 +++--- > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 172 + > > > include/linux/mlx5/mlx5_ifc.h | 3 +- > > > include/linux/mlx5/mlx5_ifc_vdpa.h | 4 + > > > 4 files changed, 174 insertions(+), 36 deletions(-) > > > > > > -- > > > 2.42.0 > > >
Re: [PATCH vhost 0/7] vdpa/mlx5: Add support for resumable vqs
On Sat, 2023-12-02 at 15:26 -0500, Michael S. Tsirkin wrote: > On Fri, Dec 01, 2023 at 12:48:50PM +0200, Dragos Tatulea wrote: > > Add support for resumable vqs in the driver. This is a firmware feature > > that can be used for the following benefits: > > - Full device .suspend/.resume. > > - .set_map doesn't need to destroy and create new vqs anymore just to > > update the map. When resumable vqs are supported it is enough to > > suspend the vqs, set the new maps, and then resume the vqs. > > > > The first patch exposes the relevant bits in mlx5_ifc.h. That means it > > needs to be applied to the mlx5-vhost tree [0] first. > > I didn't get this. Why does this need to go through that tree? > Is there a dependency on some other commit from that tree? > To avoid merge issues in Linus's tree in mlx5_ifc.h. The idea is the same as for the "vq descriptor mappings" patchset [1]. Thanks, Dragos > > Once applied > > there, the change has to be pulled from mlx5-vhost into the vhost tree > > and only then the remaining patches can be applied. Same flow as the vq > > descriptor mappings patchset [1]. > > > > To be able to use resumable vqs properly, support for selectively modifying > > vq parameters was needed. This is what the middle part of the series > > consists of. > > > > [0] > > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-vhost > > [1] > > https://lore.kernel.org/virtualization/20231018171456.1624030-2-dtatu...@nvidia.com/ > > > > Dragos Tatulea (7): > > vdpa/mlx5: Expose resumable vq capability > > vdpa/mlx5: Split function into locked and unlocked variants > > vdpa/mlx5: Allow modifying multiple vq fields in one modify command > > vdpa/mlx5: Introduce per vq and device resume > > vdpa/mlx5: Mark vq addrs for modification in hw vq > > vdpa/mlx5: Mark vq state for modification in hw vq > > vdpa/mlx5: Use vq suspend/resume during .set_map > > > > drivers/vdpa/mlx5/core/mr.c| 31 +++--- > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 172 + > > include/linux/mlx5/mlx5_ifc.h | 3 +- > > include/linux/mlx5/mlx5_ifc_vdpa.h | 4 + > > 4 files changed, 174 insertions(+), 36 deletions(-) > > > > -- > > 2.42.0 >
[PATCH] ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default
om-msm8974-sony-xperia-rhine.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
@@ -452,6 +452,8 @@ &smbb {
qcom,fast-charge-low-threshold-voltage = <340>;
qcom,auto-recharge-threshold-voltage = <420>;
qcom,minimum-input-voltage = <430>;
+
+ status = "okay";
};
&tlmm {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
index 66c422004dcd..fe227fd3f908 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
@@ -408,6 +408,8 @@ &smbb {
qcom,fast-charge-high-threshold-voltage = <435>;
qcom,auto-recharge-threshold-voltage = <424>;
qcom,minimum-input-voltage = <445>;
+
+ status = "okay";
};
&tlmm {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
index 6d1412aec45a..4c8edadea0ac 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
@@ -460,6 +460,10 @@ &sdhc_1 {
status = "okay";
};
+&smbb {
+ status = "okay";
+};
+
&tlmm {
gpio_hall_sensor_default: gpio-hall-sensor-default-state {
pins = "gpio68";
diff --git
a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
index 818ff5835031..7c6fe442b559 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
@@ -585,6 +585,8 @@ &smbb {
qcom,fast-charge-low-threshold-voltage = <340>;
qcom,auto-recharge-threshold-voltage = <420>;
qcom,minimum-input-voltage = <430>;
+
+ status = "okay";
};
&tlmm {
---
base-commit: fe14587be497254eb07c5c8aa1c799bde2abce39
change-id: 20231203-smbb-pm8941-pm8226-9cead713628a
Best regards,
--
Luca Weiss
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
Hi,
On Wed, Nov 29, 2023 at 05:44:24PM +0900, Hyesoo Yu wrote:
> Hello.
>
> On Sun, Nov 19, 2023 at 04:57:05PM +, Alexandru Elisei wrote:
> > Allow the kernel to get the size and location of the MTE tag storage
> > regions from the DTB. This memory is marked as reserved for now.
> >
> > The DTB node for the tag storage region is defined as:
> >
> > tags0: tag-storage@8f800 {
> > compatible = "arm,mte-tag-storage";
> > reg = <0x08 0xf800 0x00 0x400>;
> > block-size = <0x1000>;
> > memory = <&memory0>;// Associated tagged memory node
> > };
> >
>
> How about using compatible = "shared-dma-pool" like below ?
>
> &reserved_memory {
> tags0: tag0@8f800 {
> compatible = "arm,mte-tag-storage";
> reg = <0x08 0xf800 0x00 0x400>;
> };
> }
>
> tag-storage {
> compatible = "arm,mte-tag-storage";
> memory-region = <&tag>;
> memory = <&memory0>;
> block-size = <0x1000>;
> }
>
> And then, the activation of CMA would be performed in the CMA code.
> We just can get the region information from memory-region and allocate it
> directly
> like alloc_contig_range, take_page_off_buddy. It seems like we can remove a
> lots of code.
Played with reserved_mem a bit. I don't think that's the correct path
forward.
The location of the tag storage is a hardware property, independent of how
Linux is configured.
early_init_fdt_scan_reserved_mem() is called from arm64_memblock_init(),
**after** the kernel enforces an upper address for various reasons. One of
the reasons can be that it's been compiled with 39 bits VA.
After early_init_fdt_scan_reserved_mem() returns, the kernel sets the
maximum address, stored in the variable "high_memory".
What can happen is that tag storage is present at an address above the
maximum addressable by the kernel, and the CMA code will trigger an
unrecovrable page fault.
I was able to trigger this with the dts change:
diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 60472d65a355..201359d014e4 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -183,6 +183,13 @@ vram: vram@1800 {
reg = <0x 0x1800 0 0x0080>;
no-map;
};
+
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reg = <0x100 0x0 0x00 0x400>;
+ reusable;
+ };
};
gic: interrupt-controller@2f00 {
And the error I got:
[0.00] Reserved memory: created CMA memory pool at 0x0100,
size 64 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id
shared-dma-pool
[0.00] OF: reserved mem: 0x0100..0x010003ff (65536
KiB) map reusable linux,cma
[..]
[0.793193] WARNING: CPU: 0 PID: 1 at mm/cma.c:111
cma_init_reserved_areas+0xa8/0x378
[..]
[0.806945] Unable to handle kernel paging request at virtual address
0001fe00
[0.807277] Mem abort info:
[0.807277] ESR = 0x9605
[0.807693] EC = 0x25: DABT (current EL), IL = 32 bits
[0.808110] SET = 0, FnV = 0
[0.808443] EA = 0, S1PTW = 0
[0.808526] FSC = 0x05: level 1 translation fault
[0.808943] Data abort info:
[0.808943] ISV = 0, ISS = 0x0005, ISS2 = 0x
[0.809360] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[0.809776] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[0.810221] [0001fe00] user address but active_mm is swapper
[..]
[0.820887] Call trace:
[0.821027] cma_init_reserved_areas+0xc4/0x378
[0.821443] do_one_initcall+0x7c/0x1c0
[0.821860] kernel_init_freeable+0x1bc/0x284
[0.822277] kernel_init+0x24/0x1dc
[0.822693] ret_from_fork+0x10/0x20
[0.823554] Code: 9127a29a cb813321 d37ae421 8b030020 (f8636822)
[0.823554] ---[ end trace ]---
[0.824360] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.824443] SMP: stopping secondary CPUs
[0.825193] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b ]---
Should reserved mem check if the reserved memory is actually addressable by
the kernel if it's not "no-map"? Should cma fail gracefully if
!pfn_valid(base_pfn)? Shold early_init_fdt_scan_reserved_mem() be moved
because arm64_bootmem_init()? I don't have the answer to any of those. And
I got a kernel panic because the kernel cannot address that memory (39 bits
VA). I don't know what would happen if the upper limit is reduced for
another reason.
What I think should happen:
1. Add the tag storage memory before any limits are enforced by
arm64_bootmem_init().
2. Call cma_declare_contiguous_nid() after arm64_bootmem_init(), because
the f
Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote: > From: Markuss Broks > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC, > add the compatible for it to the IST3038C bindings. This one is better, but would be well served by mentioning what specifically is different (register addresses or firmware commands?) Cheers, Conor. > > Signed-off-by: Markuss Broks > Signed-off-by: Karel Balej > --- > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > index 0d6b033fd5fb..b5372c4eae56 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > @@ -18,6 +18,7 @@ properties: > >compatible: > enum: > + - imagis,ist3038b >- imagis,ist3038c > >reg: > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH v3 4/5] dt-bindings: input/touchscreen: imagis: add compatible for IST3032C
On Sat, Dec 02, 2023 at 01:48:35PM +0100, Karel Balej wrote: > From: Karel Balej > > Document possible usage of the Imagis driver with the IST3032C > touchscreen. Please leave mention of the driver out of the binding patch (we deal only with the hardware here) and instead describe what is incompatibly different between these two devices. Thanks, Conor. > > Signed-off-by: Karel Balej > --- > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > index b5372c4eae56..2af71cbcc97d 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml > @@ -18,6 +18,7 @@ properties: > >compatible: > enum: > + - imagis,ist3032c >- imagis,ist3038b >- imagis,ist3038c > > -- > 2.43.0 > signature.asc Description: PGP signature
Re: [PATCH v2 1/2] arm64: dts: qcom: msm8953: Set initial address for memory
On Sonntag, 3. Dezember 2023 05:20:23 CET Bjorn Andersson wrote:
> On Sat, Nov 25, 2023 at 01:19:27PM +0100, Luca Weiss wrote:
> > The dtbs_check really doesn't like having memory without reg set.
> >
> > The base address depends on the amount of RAM you have:
> > <= 2.00 GiB RAM: 0x8000
> >
> >= 3.00 GiB RAM: 0x4000
> >= 3.75 GiB RAM: 0x1000
> >
> > (more does not fit into the 32-bit physical address space)
> >
> > So, let's pick one of the values, 0x1000 which is used on devices
> > with 3.75 GiB RAM. Since the bootloader will update it to what's present
> > on the device it doesn't matter too much.
> >
> > Signed-off-by: Luca Weiss
> > ---
> >
> > arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8953.dtsi index e7de7632669a..a3ba24ca599b
> > 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> > @@ -174,10 +174,10 @@ scm: scm {
> >
> > };
> >
> > };
> >
> > - memory {
>
> Wouldn't it be sufficient to add @0 here, to please dtbs_check?
The checker itself also seems to be okay with memory@0 and no other change,
but there's this warning with W=1
arch/arm64/boot/dts/qcom/msm8953.dtsi:177.11-181.4: Warning
(unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used
in node /soc@0)
So probably we should still try to put it at a reasonable address like
0x1000?
Regards
Luca
>
> Regards,
> Bjorn
>
> > + memory@1000 {
> >
> > device_type = "memory";
> > /* We expect the bootloader to fill in the reg */
> >
> > - reg = <0 0 0 0>;
> > + reg = <0 0x1000 0 0>;
> >
> > };
> >
> > pmu {
Re: (subset) [PATCH 0/3] Add watchdog nodes to msm8226 & msm8974
On Sonntag, 3. Dezember 2023 05:54:39 CET Bjorn Andersson wrote: > On Wed, 11 Oct 2023 18:33:12 +0200, Luca Weiss wrote: > > Document the compatible for the watchdog found on both SoCs, and add > > them to the SoC dtsi file. And especially for the case where the > > bootloader has already enabled the watchdog we need to start petting it > > on time, otherwise the system gets rebooted. > > > > It's worth noting that the watchdog behaves a bit unexpectedly. > > It appears the watchdog counts down significantly slower when there's no > > load on the system and can last far longer than 30 seconds until they > > bark. Only when putting load on the system, e.g. with stress-ng does the > > watchdog interrupt fire and kill the system within an expected amount of > > time. > > > > [...] > > Applied, thanks! > > [3/3] ARM: dts: qcom: msm8974: Add watchdog node > commit: 95053f6bc8ffca438a261400d7c06bd74e3f106e Hi Bjorn, Any reason you didn't pick up the msm8226 patch? Doesn't seem to be just your ty email, I only see the msm8974 patch in https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=arm32-for-6.8 Regards Luca > > Best regards,
Re: [PATCH] init: move THIS_MODULE from to
On Sun, Nov 26, 2023 at 4:19 PM Masahiro Yamada wrote:
>
> Commit f50169324df4 ("module.h: split out the EXPORT_SYMBOL into
> export.h") appropriately separated EXPORT_SYMBOL into
> because modules and EXPORT_SYMBOL are orthogonal; modules are symbol
> consumers, while EXPORT_SYMBOL are used by symbol providers, which
> may not be necessarily a module.
>
> However, that commit also relocated THIS_MODULE. As explained in the
> commit description, the intention was to define THIS_MODULE in a
> lightweight header, but I do not believe was the
> suitable location because EXPORT_SYMBOL and THIS_MODULE are unrelated.
>
> Move it to another lightweight header, . The reason for
> choosing is to make self-contained
> without relying on incorrectly including
> .
>
> With this adjustment, the role of becomes clearer as
> it only defines EXPORT_SYMBOL.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to kbuild.
I did not get any report from the 0day bot so far,
but I hope it will get a little more compile tests
before getting into linux-next.
>
> include/linux/export.h | 18 --
> include/linux/init.h | 7 +++
> 2 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/export.h b/include/linux/export.h
> index 9911508a9604..0bbd02fd351d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -6,15 +6,6 @@
> #include
> #include
>
> -/*
> - * Export symbols from the kernel to modules. Forked from module.h
> - * to reduce the amount of pointless cruft we feed to gcc when only
> - * exporting a simple symbol or two.
> - *
> - * Try not to add #includes here. It slows compilation and makes kernel
> - * hackers place grumpy comments in header files.
> - */
> -
> /*
> * This comment block is used by fixdep. Please do not remove.
> *
> @@ -23,15 +14,6 @@
> * side effect of the *.o build rule.
> */
>
> -#ifndef __ASSEMBLY__
> -#ifdef MODULE
> -extern struct module __this_module;
> -#define THIS_MODULE (&__this_module)
> -#else
> -#define THIS_MODULE ((struct module *)0)
> -#endif
> -#endif /* __ASSEMBLY__ */
> -
> #ifdef CONFIG_64BIT
> #define __EXPORT_SYMBOL_REF(sym) \
> .balign 8 ASM_NL \
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 01b52c9c7526..3fa3f6241350 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -179,6 +179,13 @@ extern void (*late_time_init)(void);
>
> extern bool initcall_debug;
>
> +#ifdef MODULE
> +extern struct module __this_module;
> +#define THIS_MODULE (&__this_module)
> +#else
> +#define THIS_MODULE ((struct module *)0)
> +#endif
> +
> #endif
>
> #ifndef MODULE
> --
> 2.40.1
>
--
Best Regards
Masahiro Yamada
