Re: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
On Mon, Mar 4, 2024 at 9:45 PM wangyunjian wrote:
>
>
>
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: Friday, March 1, 2024 7:53 PM
> > To: wangyunjian
> > Cc: Paolo Abeni ; willemdebruijn.ker...@gmail.com;
> > jasow...@redhat.com; k...@kernel.org; bj...@kernel.org;
> > magnus.karls...@intel.com; maciej.fijalkow...@intel.com;
> > jonathan.le...@gmail.com; da...@davemloft.net; b...@vger.kernel.org;
> > net...@vger.kernel.org; linux-kernel@vger.kernel.org; k...@vger.kernel.org;
> > virtualizat...@lists.linux.dev; xudingke ; liwei (DT)
> >
> > Subject: Re: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
> >
> > On Fri, Mar 01, 2024 at 11:45:52AM +, wangyunjian wrote:
> > > > -Original Message-
> > > > From: Paolo Abeni [mailto:pab...@redhat.com]
> > > > Sent: Thursday, February 29, 2024 7:13 PM
> > > > To: wangyunjian ; m...@redhat.com;
> > > > willemdebruijn.ker...@gmail.com; jasow...@redhat.com;
> > > > k...@kernel.org; bj...@kernel.org; magnus.karls...@intel.com;
> > > > maciej.fijalkow...@intel.com; jonathan.le...@gmail.com;
> > > > da...@davemloft.net
> > > > Cc: b...@vger.kernel.org; net...@vger.kernel.org;
> > > > linux-kernel@vger.kernel.org; k...@vger.kernel.org;
> > > > virtualizat...@lists.linux.dev; xudingke ;
> > > > liwei (DT)
> > > > Subject: Re: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy
> > > > support
> > > >
> > > > On Wed, 2024-02-28 at 19:05 +0800, Yunjian Wang wrote:
> > > > > @@ -2661,6 +2776,54 @@ static int tun_ptr_peek_len(void *ptr)
> > > > > }
> > > > > }
> > > > >
> > > > > +static void tun_peek_xsk(struct tun_file *tfile) {
> > > > > + struct xsk_buff_pool *pool;
> > > > > + u32 i, batch, budget;
> > > > > + void *frame;
> > > > > +
> > > > > + if (!ptr_ring_empty(&tfile->tx_ring))
> > > > > + return;
> > > > > +
> > > > > + spin_lock(&tfile->pool_lock);
> > > > > + pool = tfile->xsk_pool;
> > > > > + if (!pool) {
> > > > > + spin_unlock(&tfile->pool_lock);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + if (tfile->nb_descs) {
> > > > > + xsk_tx_completed(pool, tfile->nb_descs);
> > > > > + if (xsk_uses_need_wakeup(pool))
> > > > > + xsk_set_tx_need_wakeup(pool);
> > > > > + }
> > > > > +
> > > > > + spin_lock(&tfile->tx_ring.producer_lock);
> > > > > + budget = min_t(u32, tfile->tx_ring.size, TUN_XDP_BATCH);
> > > > > +
> > > > > + batch = xsk_tx_peek_release_desc_batch(pool, budget);
> > > > > + if (!batch) {
> > > >
> > > > This branch looks like an unneeded "optimization". The generic loop
> > > > below should have the same effect with no measurable perf delta - and
> > smaller code.
> > > > Just remove this.
> > > >
> > > > > + tfile->nb_descs = 0;
> > > > > + spin_unlock(&tfile->tx_ring.producer_lock);
> > > > > + spin_unlock(&tfile->pool_lock);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + tfile->nb_descs = batch;
> > > > > + for (i = 0; i < batch; i++) {
> > > > > + /* Encode the XDP DESC flag into lowest bit for
> > > > > consumer to
> > differ
> > > > > +* XDP desc from XDP buffer and sk_buff.
> > > > > +*/
> > > > > + frame = tun_xdp_desc_to_ptr(&pool->tx_descs[i]);
> > > > > + /* The budget must be less than or equal to
> > > > > tx_ring.size,
> > > > > +* so enqueuing will not fail.
> > > > > +*/
> > > > > + __ptr_ring_produce(&tfile->tx_ring, frame);
> > > > > + }
> > > > > + spin_unlock(&tfile->tx_ring.producer_lock);
> > > > > + spin_unlock(&tfile->pool_lock);
> > > >
> > > > More related to the general design: it looks wrong. What if
> > > > get_rx_bufs() will fail (ENOBUF) after successful peeking? With no
> > > > more incoming packets, later peek will return 0 and it looks like
> > > > that the half-processed packets will stay in the ring forever???
> > > >
> > > > I think the 'ring produce' part should be moved into tun_do_read().
> > >
> > > Currently, the vhost-net obtains a batch descriptors/sk_buffs from the
> > > ptr_ring and enqueue the batch descriptors/sk_buffs to the
> > > virtqueue'queue, and then consumes the descriptors/sk_buffs from the
> > > virtqueue'queue in sequence. As a result, TUN does not know whether
> > > the batch descriptors have been used up, and thus does not know when to
> > return the batch descriptors.
> > >
> > > So, I think it's reasonable that when vhost-net checks ptr_ring is
> > > empty, it calls peek_len to get new xsk's descs and return the
> > > descriptors.
> > >
> > > Thanks
> >
> > What you need to think about is that if you peek, another call in parallel
> > can get
> > the same value at the same time.
>
> Thank you. I have i
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
On Sun, Mar 10, 2024 at 09:35:36PM +0100, Krzysztof Kozlowski wrote:
> On 10/03/2024 12:35, Karel Balej wrote:
> > Dmitry Torokhov, 2024-03-04T17:10:59-08:00:
> >> On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
> >>> Dmitry,
> >>>
> >>> Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
> On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> > From: Karel Balej
> >
> > Marvell 88PM886 PMIC provides onkey among other things. Add client
> > driver to handle it. The driver currently only provides a basic support
> > omitting additional functions found in the vendor version, such as long
> > onkey and GPIO integration.
> >
> > Signed-off-by: Karel Balej
> > ---
> >
> > Notes:
> > RFC v3:
> > - Drop wakeup-source.
> > RFC v2:
> > - Address Dmitry's feedback:
> > - Sort includes alphabetically.
> > - Drop onkey->irq.
> > - ret -> err in irq_handler and no initialization.
> > - Break long lines and other formatting.
> > - Do not clobber platform_get_irq error.
> > - Do not set device parent manually.
> > - Use input_set_capability.
> > - Use the wakeup-source DT property.
> > - Drop of_match_table.
>
> I only said that you should not be using of_match_ptr(), but you still
> need to have of_match_table set and have MODULE_DEVICE_TABLE() for the
> proper module loading support.
> >>>
> >>> I removed of_match_table because I no longer need compatible for this --
> >>> there are no device tree properties and the driver is being instantiated
> >>> by the MFD driver.
> >>>
> >>> Is the MODULE_DEVICE_TABLE() entry needed for the driver to probe when
> >>> compiled as module? If that is the case, given what I write above, am I
> >>> correct that MODULE_DEVICE_TABLE(platform,...) would be the right thing
> >>> to use here?
> >>
> >> Yes, if uevent generated for the device is "platform:" then
> >> MODULE_DEVICE_TABLE(platform,...) will suffice. I am not sure how MFD
> >> sets it up (OF modalias or platform), but you should be able to check
> >> the format looking at the "uevent" attribute for your device in sysfs
> >> (/sys/devices/bus/platform/...).
> >
> > The uevent is indeed platform.
> >
> > But since there is only one device, perhaps having a device table is
> > superfluous and using `MODULE_ALIAS("platform:88pm886-onkey")` is more
> > fitting?
>
> Adding aliases for standard IDs and standard cases is almost never
> correct. If you need module alias, it means your ID table is wrong (or
> missing, which is usually wrong).
>
> >
> > Although I don't understand why this is even necessary when the driver
> > name is such and the module is registered using
> > `module_platform_driver`...
>
> ID table and MODULE_DEVICE_TABLE() are necessary for modprobe to work.
> Just run `modinfo`.
MODULE_DEVICE_TABLE() and MODULE_ALIAS() reduce to the same thing, but I
agree that we should not try to be too clever and simply use the ID
table.
Thanks.
--
Dmitry
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
On 10/03/2024 12:35, Karel Balej wrote:
> Dmitry Torokhov, 2024-03-04T17:10:59-08:00:
>> On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
>>> Dmitry,
>>>
>>> Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> From: Karel Balej
>
> Marvell 88PM886 PMIC provides onkey among other things. Add client
> driver to handle it. The driver currently only provides a basic support
> omitting additional functions found in the vendor version, such as long
> onkey and GPIO integration.
>
> Signed-off-by: Karel Balej
> ---
>
> Notes:
> RFC v3:
> - Drop wakeup-source.
> RFC v2:
> - Address Dmitry's feedback:
> - Sort includes alphabetically.
> - Drop onkey->irq.
> - ret -> err in irq_handler and no initialization.
> - Break long lines and other formatting.
> - Do not clobber platform_get_irq error.
> - Do not set device parent manually.
> - Use input_set_capability.
> - Use the wakeup-source DT property.
> - Drop of_match_table.
I only said that you should not be using of_match_ptr(), but you still
need to have of_match_table set and have MODULE_DEVICE_TABLE() for the
proper module loading support.
>>>
>>> I removed of_match_table because I no longer need compatible for this --
>>> there are no device tree properties and the driver is being instantiated
>>> by the MFD driver.
>>>
>>> Is the MODULE_DEVICE_TABLE() entry needed for the driver to probe when
>>> compiled as module? If that is the case, given what I write above, am I
>>> correct that MODULE_DEVICE_TABLE(platform,...) would be the right thing
>>> to use here?
>>
>> Yes, if uevent generated for the device is "platform:" then
>> MODULE_DEVICE_TABLE(platform,...) will suffice. I am not sure how MFD
>> sets it up (OF modalias or platform), but you should be able to check
>> the format looking at the "uevent" attribute for your device in sysfs
>> (/sys/devices/bus/platform/...).
>
> The uevent is indeed platform.
>
> But since there is only one device, perhaps having a device table is
> superfluous and using `MODULE_ALIAS("platform:88pm886-onkey")` is more
> fitting?
Adding aliases for standard IDs and standard cases is almost never
correct. If you need module alias, it means your ID table is wrong (or
missing, which is usually wrong).
>
> Although I don't understand why this is even necessary when the driver
> name is such and the module is registered using
> `module_platform_driver`...
ID table and MODULE_DEVICE_TABLE() are necessary for modprobe to work.
Just run `modinfo`.
Best regards,
Krzysztof
Re: [PATCH 2/3] dt-bindings: arm: qcom: Add Sony Xperia Z3
On 10/03/2024 12:41, Luca Weiss wrote: > Add the compatible for this Sony smartphone. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Samsung Galaxy Note 3
On 10/03/2024 15:13, Luca Weiss wrote:
> Add the compatible for this Samsung smartphone ("phablet" as it was
> named in that era).
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters
On Fri, 8 Mar 2024 13:41:59 -0800 Linus Torvalds wrote: > On Fri, 8 Mar 2024 at 13:39, Linus Torvalds > wrote: > > > > So the above "complexity" is *literally* just changing the > > > > (new = atomic_read_acquire(&my->seq)) != old > > > > condition to > > > > should_exit || > > (new = atomic_read_acquire(&my->seq)) != old > > .. and obviously you'll need to add the exit condition to the actual > "deal with events" loop too. I haven't had a chance to rework this part of the patches, but I have some other fixes to push to you from earlier this week, and I think the first three patches of this series are also fine. As the loop in ring_buffer_wait() isn't needed, and patch 2 and 3 are trivial bugs. I'll send you a pull request for that work and I'll work on this code later. -- Steve
[PATCH 2/2] ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
From: Adam Honse
Add the devicetree for this "phablet" using the Snapdragon 800 SoC.
Signed-off-by: Adam Honse
[l...@z3ntu.xyz: clean up, prepare for upstream]
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 403 +
2 files changed, 404 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 9cc1e14e6cd0..845af12d15a2 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8960-cdp.dtb \
qcom-msm8960-samsung-expressatt.dtb \
qcom-msm8974-lge-nexus5-hammerhead.dtb \
+ qcom-msm8974-samsung-hlte.dtb \
qcom-msm8974-sony-xperia-rhine-amami.dtb \
qcom-msm8974-sony-xperia-rhine-honami.dtb \
qcom-msm8974pro-fairphone-fp2.dtb \
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
new file mode 100644
index ..e03227a49b67
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "qcom-msm8974.dtsi"
+#include "pm8841.dtsi"
+#include "pm8941.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "Samsung Galaxy Note 3";
+ compatible = "samsung,hlte", "qcom,msm8974";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1; /* SDC1 eMMC slot */
+ mmc1 = &sdhc_3; /* SDC3 SD card slot */
+ serial0 = &blsp1_uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pin_a>;
+
+ key-home {
+ label = "home_key";
+ gpios = <&pm8941_gpios 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+
+ key-volume-down {
+ label = "volume_down";
+ gpios = <&pm8941_gpios 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-volume-up {
+ label = "volume_up";
+ gpios = <&pm8941_gpios 5 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+ };
+
+ touch_ldo: regulator-touch {
+ compatible = "regulator-fixed";
+ regulator-name = "touch-ldo";
+
+ gpio = <&pm8941_gpios 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_ldo_pin>;
+ };
+};
+
+&blsp1_i2c2 {
+ status = "okay";
+
+ touchscreen@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+
+ interrupt-parent = <&pm8941_gpios>;
+ interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
+
+ vdd-supply = <&pm8941_l10>;
+ vio-supply = <&touch_ldo>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_pin>;
+
+ syna,startup-delay-ms = <100>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f12@12 {
+ reg = <0x12>;
+ syna,sensor-type = <1>;
+ };
+ };
+};
+
+&blsp2_i2c6 {
+ status = "okay";
+
+ fuelgauge@36 {
+ compatible = "maxim,max17048";
+ reg = <0x36>;
+
+ maxim,double-soc;
+ maxim,rcomp = /bits/ 8 <0x56>;
+
+ interrupt-parent = <&pm8941_gpios>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&fuelgauge_pin>;
+ };
+};
+
+&blsp1_uart2 {
+ status = "okay";
+};
+
+&pm8941_gpios {
+ gpio_keys_pin_a: gpio-keys-active-state {
+ pins = "gpio2", "gpio3", "gpio5";
+ function = "normal";
+ bias-pull-up;
+ power-source = ;
+ };
+
+ fuelgauge_pin: fuelgauge-int-state {
+ pins = "gpio26";
+ function = "normal";
+ bias-disable;
+ input-enable;
+ power-source = ;
+ };
+
+ touch_pin: touchscreen-int-state {
+ pins = "gpio30";
+ function = "normal";
+ bias-di
[PATCH 1/2] dt-bindings: arm: qcom: Add Samsung Galaxy Note 3
Add the compatible for this Samsung smartphone ("phablet" as it was
named in that era).
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1a5fb889a444..57182bfa27ee 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -214,6 +214,7 @@ properties:
- items:
- enum:
- lge,hammerhead
+ - samsung,hlte
- sony,xperia-amami
- sony,xperia-honami
- const: qcom,msm8974
--
2.44.0
[PATCH 0/2] Add Samsung Galaxy Note 3 support
Add the dts for "hlte" which is a phablet from 2013. Signed-off-by: Luca Weiss --- Adam Honse (1): ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3 Luca Weiss (1): dt-bindings: arm: qcom: Add Samsung Galaxy Note 3 Documentation/devicetree/bindings/arm/qcom.yaml| 1 + arch/arm/boot/dts/qcom/Makefile| 1 + .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 403 + 3 files changed, 405 insertions(+) --- base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 change-id: 20240310-samsung-hlte-78d1a287b0a8 Best regards, -- Luca Weiss
Re: [PATCH 3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone
On Sonntag, 10. März 2024 12:41:09 CET Luca Weiss wrote:
> Add the dts for the Xperia Z3 smartphone which is based on Sony's
> shinano platform, so at the moment there's little device-specific dts to
> add on top of the common parts.
>
> Signed-off-by: Luca Weiss
> ---
> .../qcom-msm8974pro-sony-xperia-shinano-leo.dts| 44 +++
+++
> 1 file changed, 44 insertions(+)
Of course I forgot to add the dtb to the Makefile...
Apparently "make qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dtb" doesn't
care about whether the dtb is in the Makefile so I didn't notice.
Will fix in v2 but I'm going to wait for any comments on this or the other
patches for at least a day or so.
Regards
Luca
>
> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-
leo.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dts
> new file mode 100644
> index ..1ed6e1cc21d5
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "qcom-msm8974pro-sony-xperia-shinano-common.dtsi"
> +
> +/ {
> + model = "Sony Xperia Z3";
> + compatible = "sony,xperia-leo", "qcom,msm8974pro", "qcom,msm8974";
> + chassis-type = "handset";
> +
> + gpio-keys {
> + key-camera-snapshot {
> + label = "camera_snapshot";
> + gpios = <&pm8941_gpios 3 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + debounce-interval = <15>;
> + };
> +
> + key-camera-focus {
> + label = "camera_focus";
> + gpios = <&pm8941_gpios 4 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + debounce-interval = <15>;
> + };
> + };
> +};
> +
> +&gpio_keys_pin_a {
> + pins = "gpio2", "gpio3", "gpio4", "gpio5";
> +};
> +
> +&smbb {
> + usb-charge-current-limit = <150>;
> + qcom,fast-charge-safe-current = <300>;
> + qcom,fast-charge-current-limit = <215>;
> + qcom,fast-charge-safe-voltage = <440>;
> + qcom,fast-charge-high-threshold-voltage = <435>;
> + qcom,auto-recharge-threshold-voltage = <428>;
> + qcom,minimum-input-voltage = <420>;
> +
> + status = "okay";
> +};
> +
> +&synaptics_touchscreen {
> + vio-supply = <&pm8941_s3>;
> +};
>
>
[PATCH 2/3] dt-bindings: arm: qcom: Add Sony Xperia Z3
Add the compatible for this Sony smartphone. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1a5fb889a444..d6a7ee5e1d91 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -224,6 +224,7 @@ properties: - oneplus,bacon - samsung,klte - sony,xperia-castor + - sony,xperia-leo - const: qcom,msm8974pro - const: qcom,msm8974 -- 2.44.0
[PATCH 3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone
Add the dts for the Xperia Z3 smartphone which is based on Sony's
shinano platform, so at the moment there's little device-specific dts to
add on top of the common parts.
Signed-off-by: Luca Weiss
---
.../qcom-msm8974pro-sony-xperia-shinano-leo.dts| 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dts
new file mode 100644
index ..1ed6e1cc21d5
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-leo.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "qcom-msm8974pro-sony-xperia-shinano-common.dtsi"
+
+/ {
+ model = "Sony Xperia Z3";
+ compatible = "sony,xperia-leo", "qcom,msm8974pro", "qcom,msm8974";
+ chassis-type = "handset";
+
+ gpio-keys {
+ key-camera-snapshot {
+ label = "camera_snapshot";
+ gpios = <&pm8941_gpios 3 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-camera-focus {
+ label = "camera_focus";
+ gpios = <&pm8941_gpios 4 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+ };
+};
+
+&gpio_keys_pin_a {
+ pins = "gpio2", "gpio3", "gpio4", "gpio5";
+};
+
+&smbb {
+ usb-charge-current-limit = <150>;
+ qcom,fast-charge-safe-current = <300>;
+ qcom,fast-charge-current-limit = <215>;
+ qcom,fast-charge-safe-voltage = <440>;
+ qcom,fast-charge-high-threshold-voltage = <435>;
+ qcom,auto-recharge-threshold-voltage = <428>;
+ qcom,minimum-input-voltage = <420>;
+
+ status = "okay";
+};
+
+&synaptics_touchscreen {
+ vio-supply = <&pm8941_s3>;
+};
--
2.44.0
[PATCH 1/3] ARM: dts: qcom: msm8974-sony-castor: Split into shinano-common
In preparation for adding the Sony Xperia Z3 smartphone, split the
common parts into shinano-common.dtsi.
No functional change intended.
Signed-off-by: Luca Weiss
---
.../qcom-msm8974pro-sony-xperia-shinano-castor.dts | 853 -
...com-msm8974pro-sony-xperia-shinano-common.dtsi} | 155 +---
2 files changed, 169 insertions(+), 839 deletions(-)
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
dissimilarity index 74%
index 20f98a9e49ea..727ad5c53e7f 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
@@ -1,686 +1,167 @@
-// SPDX-License-Identifier: GPL-2.0
-#include "qcom-msm8974pro.dtsi"
-#include "pm8841.dtsi"
-#include "pm8941.dtsi"
-#include
-#include
-#include
-
-/ {
- model = "Sony Xperia Z2 Tablet";
- compatible = "sony,xperia-castor", "qcom,msm8974pro", "qcom,msm8974";
- chassis-type = "tablet";
-
- aliases {
- mmc0 = &sdhc_1;
- mmc1 = &sdhc_2;
- serial0 = &blsp1_uart2;
- serial1 = &blsp2_uart1;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- gpio-keys {
- compatible = "gpio-keys";
-
- pinctrl-0 = <&gpio_keys_pin_a>;
- pinctrl-names = "default";
-
- key-volume-down {
- label = "volume_down";
- gpios = <&pm8941_gpios 2 GPIO_ACTIVE_LOW>;
- linux,code = ;
- debounce-interval = <15>;
- };
-
- key-volume-up {
- label = "volume_up";
- gpios = <&pm8941_gpios 5 GPIO_ACTIVE_LOW>;
- linux,code = ;
- debounce-interval = <15>;
- };
- };
-
- vreg_bl_vddio: lcd-backlight-vddio {
- compatible = "regulator-fixed";
- regulator-name = "vreg_bl_vddio";
- regulator-min-microvolt = <315>;
- regulator-max-microvolt = <315>;
-
- gpio = <&tlmm 69 0>;
- enable-active-high;
-
- vin-supply = <&pm8941_s3>;
- startup-delay-us = <7>;
-
- pinctrl-0 = <&lcd_backlight_en_pin_a>;
- pinctrl-names = "default";
- };
-
- vreg_vsp: lcd-dcdc-regulator {
- compatible = "regulator-fixed";
- regulator-name = "vreg_vsp";
- regulator-min-microvolt = <560>;
- regulator-max-microvolt = <560>;
-
- gpio = <&pm8941_gpios 20 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&lcd_dcdc_en_pin_a>;
- pinctrl-names = "default";
- };
-
- vreg_boost: vreg-boost {
- compatible = "regulator-fixed";
-
- regulator-name = "vreg-boost";
- regulator-min-microvolt = <315>;
- regulator-max-microvolt = <315>;
-
- regulator-always-on;
- regulator-boot-on;
-
- gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-names = "default";
- pinctrl-0 = <&boost_bypass_n_pin>;
- };
-
- vreg_vph_pwr: vreg-vph-pwr {
- compatible = "regulator-fixed";
- regulator-name = "vph-pwr";
-
- regulator-min-microvolt = <360>;
- regulator-max-microvolt = <360>;
-
- regulator-always-on;
- };
-
- vreg_wlan: wlan-regulator {
- compatible = "regulator-fixed";
-
- regulator-name = "wl-reg";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
-
- gpio = <&pm8941_gpios 18 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&wlan_regulator_pin>;
- pinctrl-names = "default";
- };
-};
-
-&blsp1_uart2 {
- status = "okay";
-};
-
-&blsp2_i2c2 {
- clock-frequency = <355000>;
-
- status = "okay";
-
- synaptics@2c {
- compatible = "syna,rmi4-i2c";
- reg = <0x2c>;
-
- interrupt-parent = <&tlmm>;
- interrupts = <86 IRQ_TYPE_EDGE_FALLING>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- vdd-supply = <&pm8941_l22>;
- vio-supply = <&pm8941_lvs3>;
-
- pinctrl-0 = <&ts_int_pin>;
- pinctrl-names = "default";
-
- syna,startup-delay-ms = <100>;
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
-
[PATCH 0/3] Split sony-castor into shinano-common and add Sony Xperia Z3
Prepare for adding sony-leo dts by splitting common parts into a separate dtsi file. Then add the dts for Sony Xperia Z3. Depends on: https://lore.kernel.org/linux-arm-msm/20240306-castor-changes-v1-0-2286eaf85...@z3ntu.xyz/T/ Signed-off-by: Luca Weiss --- Luca Weiss (3): ARM: dts: qcom: msm8974-sony-castor: Split into shinano-common dt-bindings: arm: qcom: Add Sony Xperia Z3 ARM: dts: qcom: Add Sony Xperia Z3 smartphone Documentation/devicetree/bindings/arm/qcom.yaml| 1 + .../qcom-msm8974pro-sony-xperia-shinano-castor.dts | 541 + ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 535 .../qcom-msm8974pro-sony-xperia-shinano-leo.dts| 44 ++ 4 files changed, 591 insertions(+), 530 deletions(-) --- base-commit: bee52eeb37d8124a07711657d1650bf3b467e7dd change-id: 20240310-shinano-common-093fe25fe3a1 Best regards, -- Luca Weiss
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
Dmitry Torokhov, 2024-03-04T17:10:59-08:00:
> On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
> > Dmitry,
> >
> > Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
> > > On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> > > > From: Karel Balej
> > > >
> > > > Marvell 88PM886 PMIC provides onkey among other things. Add client
> > > > driver to handle it. The driver currently only provides a basic support
> > > > omitting additional functions found in the vendor version, such as long
> > > > onkey and GPIO integration.
> > > >
> > > > Signed-off-by: Karel Balej
> > > > ---
> > > >
> > > > Notes:
> > > > RFC v3:
> > > > - Drop wakeup-source.
> > > > RFC v2:
> > > > - Address Dmitry's feedback:
> > > > - Sort includes alphabetically.
> > > > - Drop onkey->irq.
> > > > - ret -> err in irq_handler and no initialization.
> > > > - Break long lines and other formatting.
> > > > - Do not clobber platform_get_irq error.
> > > > - Do not set device parent manually.
> > > > - Use input_set_capability.
> > > > - Use the wakeup-source DT property.
> > > > - Drop of_match_table.
> > >
> > > I only said that you should not be using of_match_ptr(), but you still
> > > need to have of_match_table set and have MODULE_DEVICE_TABLE() for the
> > > proper module loading support.
> >
> > I removed of_match_table because I no longer need compatible for this --
> > there are no device tree properties and the driver is being instantiated
> > by the MFD driver.
> >
> > Is the MODULE_DEVICE_TABLE() entry needed for the driver to probe when
> > compiled as module? If that is the case, given what I write above, am I
> > correct that MODULE_DEVICE_TABLE(platform,...) would be the right thing
> > to use here?
>
> Yes, if uevent generated for the device is "platform:" then
> MODULE_DEVICE_TABLE(platform,...) will suffice. I am not sure how MFD
> sets it up (OF modalias or platform), but you should be able to check
> the format looking at the "uevent" attribute for your device in sysfs
> (/sys/devices/bus/platform/...).
The uevent is indeed platform.
But since there is only one device, perhaps having a device table is
superfluous and using `MODULE_ALIAS("platform:88pm886-onkey")` is more
fitting?
Although I don't understand why this is even necessary when the driver
name is such and the module is registered using
`module_platform_driver`...
Thank you, best regards,
K. B.
Re: [PATCH] openrisc: Use asm-generic's version of fix_to_virt() & virt_to_fix()
On Sat, Mar 09, 2024 at 06:24:07PM +0800, Dawei Li wrote: > Openrisc's implementation of fix_to_virt() & virt_to_fix() share same > functionality with ones of asm generic. > > Plus, generic version of fix_to_virt() can trap invalid index at compile > time. > > Thus, Replace the arch-specific implementations with asm generic's ones. > > Signed-off-by: Dawei Li Thanks, I have reviewed and tested this and it looks good. I will queue for the next merge window. -Stafford
