Re: [PATCH net-next 0/3] trace: use TP_STORE_ADDRS macro
On Sun, 10 Mar 2024 20:14:03 +0800 Jason Xing wrote: > Using the macro for other tracepoints use to be more concise. > No functional change. The merge window for 6.9 has started and we try not to apply patches to net-next during the merge window. Please repost in 2 weeks, once Linus has tagged v6.9-rc1. -- pw-bot: defer
[ANNOUNCE] 5.10.211-rt103
Hello RT-list! I'm pleased to announce the 5.10.211-rt103 stable release. This release is an update to the new stable 5.10.211 version, with no extra changes. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v5.10-rt Head SHA1: bffc88bd708c173b98b61469378f763e44c733e1 Or to build 5.10.211-rt103 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.10.tar.xz https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.10.211.xz https://www.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.211-rt103.patch.xz Signing key fingerprint: 9354 0649 9972 8D31 D464 D140 F394 A423 F8E6 7C26 All keys used for the above files and repositories can be found on the following git repository: git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git Enjoy! Luis
Re: [PATCHv2 2/2] usb: typec: anx7688: Add driver for ANX7688 USB-C HDMI bridge
Hi! > From: Ondrej Jirman > > This is driver for ANX7688 USB-C HDMI, with flashing and debugging > features removed. ANX7688 is rather criticial piece on PinePhone, > there's no display and no battery charging without it. > > There's likely more work to be done here, but having basic support > in mainline is needed to be able to work on the other stuff > (networking, cameras, power management). > > Signed-off-by: Ondrej Jirman > Co-developed-by: Martijn Braam > Co-developed-by: Samuel Holland > Signed-off-by: Pavel Machek Any comments here? Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. signature.asc Description: PGP signature
Re: [PATCHv2 1/2] dt-bindings: usb: typec: anx7688: start a binding document
Hi!
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
Any more comments here? Automatic system told me I need to replace one
character...
Best regards,
Pavel
> ---
>
> v2: implement review feedback
>
> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> new file mode 100644
> index ..9e887eafb5fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +# Pin names can be deduced from
> +#
> https://files.pine64.org/doc/PinePhone/PinePhone%20v1.2b%20Released%20Schematic.pdf
> +
> +title: Analogix ANX7688 Type-C controller
> +
> +maintainers:
> + - Pavel Machek
> +
> +properties:
> + compatible:
> +enum:
> + - analogix,anx7688
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + reset-gpios:
> +maxItems: 1
> +description: GPIO controlling RESET_N (B7) pin.
> +
> + enable-gpios:
> +maxItems: 1
> +description: GPIO controlling POWER_EN (D2) pin.
> +
> + cabledet-gpios:
> +maxItems: 1
> +description: GPIO controlling CABLE_DET (C3) pin.
> +
> + avdd10-supply:
> +description: 1.0V power supply going to AVDD10 (A4, ...) pins
> +
> + dvdd10-supply:
> +description: 1.0V power supply going to DVDD10 (D6, ...) pins
> +
> + avdd18-supply:
> +description: 1.8V power supply going to AVDD18 (E3, ...) pins
> +
> + dvdd18-supply:
> +description: 1.8V power supply going to DVDD18 (G4, ...) pins
> +
> + avdd33-supply:
> +description: 3.3V power supply going to AVDD33 (C4, ...) pins
> +
> + i2c-supply: true
> + vconn-supply: true
> + hdmi-vt-supply: true
> + vbus-supply: true
> + vbus-in-supply: true
> +
> + connector:
> +type: object
> +$ref: /schemas/connector/usb-connector.yaml
> +
> +description:
> + Properties for usb c connector.
> +
> +properties:
> + compatible:
> +const: usb-c-connector
> +
> +required:
> + - compatible
> + - reg
> + - connector
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +typec@2c {
> +compatible = "analogix,anx7688";
> +reg = <0x2c>;
> +interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
> +interrupt-parent = <>;
> +
> +enable-gpios = < 3 10 GPIO_ACTIVE_LOW>; /* PD10 */
> +reset-gpios = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> +cabledet-gpios = <_pio 0 8 GPIO_ACTIVE_HIGH>; /* PL8 */
> +
> +avdd10-supply = <_anx1v0>;
> +dvdd10-supply = <_anx1v0>;
> +avdd18-supply = <_ldo_io1>;
> +dvdd18-supply = <_ldo_io1>;
> +avdd33-supply = <_dcdc1>;
> +i2c-supply = <_ldo_io0>;
> +vconn-supply = <_vconn5v0>;
> +hdmi_vt-supply = <_dldo1>;
> +
> +vbus-supply = <_usb_5v>;
> +vbus-in-supply = <_power_supply>;
> +
> +typec_con: connector {
> +compatible = "usb-c-connector";
> +power-role = "dual";
> +data-role = "dual";
> +try-power-role = "source";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +typec_con_ep: endpoint {
> +remote-endpoint = <_hs_ep>;
> +};
> +};
> +};
> +};
> +};
> +};
> +...
>
--
People of Russia, stop Putin before his war on Ukraine escalates.
signature.asc
Description: PGP signature
Re: [RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver
On 11/03/2024 19:28:50+0100, Peter Hilber wrote:
> >> Perhaps this might be handled by the driver also setting a virtio-rtc
> >> monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM).
> >> The
> >> virtio-rtc monotonic alarm would just be used to wake up in case it was
> >> a
> >> CLOCK_BOOTTIME_ALARM alarm.
> >>
> >> Otherwise, the behavior should not differ from other RTC class drivers.
> >>
> >
> > What I don't quite get is how this is actually related to RTCs. This
> > would be a super imprecise mechanism to get the current time and date
> > from the host to the guest which is what I think your are trying to do,
> > especially since this is not supporting UIE.
> > The host system clock may come from reading the RTC at some point in
> > time but more likely from another source so is it really the best
> > synchronization mechanism?
>
> Hello,
>
> thank you for your comments.
>
> The main motivation to have the RTC class driver is the RTC alarm
> (discussed below).
>
> As for synchronization, virtio_rtc also offers a PTP clock [1] which will
> be more precise, but which needs a user space daemon. As for RTC-based
> initial synchronization, my idea was to propose, in a second step, an
> optional op for rtc_class_ops, which would read the clock with nanosecond
> precision. This optional op could then be used in rtc_hctosys(), so there
> would be no need for UIE waiting.
This would be a clear NAK, rtc_hctosys should use UIE to have proper
synchronisation. It currently does a very bad job reading the RTC and it
is a pity it has been mandated by systemd as useerspace is definitively
better placed to set the system time. I'm still very tempted delaying
everyone's boot by one second and make rtc_hctosys precise for all the
supported HW and not just a single driver.
> [1]
> https://lore.kernel.org/all/20231218073849.35294-6-peter.hil...@opensynergy.com/
>
> >
> > The other thing is that I don't quite get the point of the RTC alarm
> > versus a regular timer in this context.
>
> RTC alarms allow to resume from suspend and poweroff (esp. also through
> alarmtimers), which is of interest in embedded virtualization. In my
> understanding RTC is ATM the only way to do this.
>
> (I was indeed thinking about adding an alternate alarmtimer backend for
> CLOCK_BOOTTIME_ALARM, which should deal with the CLOCK_REALTIME_ALARM vs
> CLOCK_BOOTTIME_ALARM issue which is described in the commit message.)
>
Right but this seems like a super convoluted way of getting the host to
wakeup the guest...
> >
> >
> > [...]
> >
> >> +static const struct rtc_class_ops viortc_class_with_alarm_ops = {
> >> + .read_time = viortc_class_read_time,
> >> + .read_alarm = viortc_class_read_alarm,
> >> + .set_alarm = viortc_class_set_alarm,
> >> + .alarm_irq_enable = viortc_class_alarm_irq_enable,
> >> +};
> >> +
> >> +static const struct rtc_class_ops viortc_class_no_alarm_ops = {
> >> + .read_time = viortc_class_read_time,
> >> +};
> >> +
> >
> > [...]
> >
> >> +/**
> >> +/**
> >> + * viortc_class_init() - init RTC class wrapper and device
> >> + * @viortc: device data
> >> + * @vio_clk_id: virtio_rtc clock id
> >> + * @have_alarm: expose alarm ops
> >> + * @parent_dev: virtio device
> >> + *
> >> + * Context: Process context.
> >> + * Return: RTC class wrapper on success, ERR_PTR otherwise.
> >> + */
> >> +struct viortc_class *viortc_class_init(struct viortc_dev *viortc,
> >> + u16 vio_clk_id, bool have_alarm,
> >> + struct device *parent_dev)
> >> +{
> >> + struct viortc_class *viortc_class;
> >> + struct rtc_device *rtc;
> >> +
> >> + viortc_class =
> >> + devm_kzalloc(parent_dev, sizeof(*viortc_class),
> >> GFP_KERNEL);
> >> + if (!viortc_class)
> >> + return ERR_PTR(-ENOMEM);
> >> +
> >> + viortc_class->viortc = viortc;
> >> +
> >> + rtc = devm_rtc_allocate_device(parent_dev);
> >> + if (IS_ERR(rtc))
> >> + return ERR_PTR(PTR_ERR(rtc));
> >> +
> >> + viortc_class->rtc = rtc;
> >> +
> >> + clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
> >> +
> >> + rtc->ops = have_alarm ? _class_with_alarm_ops :
> >> + _class_no_alarm_ops;
> >
> > Don't do this, simply clear the alarm feature.
> >
>
> OK (sorry, was obviously very inelegant).
>
> Best regards,
>
> Peter
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote: > On 01/03/2024 19:16, Tanmay Shah wrote: > > From: Radhey Shyam Pandey > > > > Introduce bindings for TCM memory address space on AMD-xilinx Zynq > > UltraScale+ platform. It will help in defining TCM in device-tree > > and make it's access platform agnostic and data-driven. > > > > Tightly-coupled memories(TCMs) are low-latency memory that provides > > predictable instruction execution and predictable data load/store > > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory > > banks on the ATCM and BTCM ports, for a total of 128 KB of memory. > > > > The TCM resources(reg, reg-names and power-domain) are documented for > > each TCM in the R5 node. The reg and reg-names are made as required > > properties as we don't want to hardcode TCM addresses for future > > platforms and for zu+ legacy implementation will ensure that the > > old dts w/o reg/reg-names works and stable ABI is maintained. > > > > It also extends the examples for TCM split and lockstep modes. > > > > Signed-off-by: Radhey Shyam Pandey > > Signed-off-by: Tanmay Shah > > --- > > > > Changes in v12: > > - add "reg", "reg-names" and "power-domains" in pattern properties > > - add "reg" and "reg-names" in required list > > - keep "power-domains" in required list as it was before the change > > > > Changes in v11: > > - Fix yamllint warning and reduce indentation as needed > > > > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 -- > > 1 file changed, 168 insertions(+), 20 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > index 78aac69f1060..dc6ce308688f 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > @@ -20,9 +20,21 @@ properties: > >compatible: > > const: xlnx,zynqmp-r5fss > > > > + "#address-cells": > > +const: 2 > > + > > + "#size-cells": > > +const: 2 > > + > > + ranges: > > +description: | > > + Standard ranges definition providing address translations for > > + local R5F TCM address spaces to bus addresses. > > + > >xlnx,cluster-mode: > > $ref: /schemas/types.yaml#/definitions/uint32 > > enum: [0, 1, 2] > > +default: 1 > > description: | > >The RPU MPCore can operate in split mode (Dual-processor > > performance), Safety > >lock-step mode(Both RPU cores execute the same code in lock-step, > > @@ -37,7 +49,7 @@ properties: > >2: single cpu mode > > > > patternProperties: > > - "^r5f-[a-f0-9]+$": > > + "^r5f@[0-9a-f]+$": > > type: object > > description: | > >The RPU is located in the Low Power Domain of the Processor > > Subsystem. > > @@ -54,8 +66,17 @@ patternProperties: > >compatible: > > const: xlnx,zynqmp-r5f > > > > + reg: > > +minItems: 1 > > +maxItems: 4 > > + > > + reg-names: > > +minItems: 1 > > +maxItems: 4 > > + > >power-domains: > > -maxItems: 1 > > +minItems: 2 > > +maxItems: 5 > > > >mboxes: > > minItems: 1 > > @@ -101,35 +122,162 @@ patternProperties: > > > > required: > >- compatible > > + - reg > > + - reg-names > >- power-domains > > > > -unevaluatedProperties: false > > - > > required: > >- compatible > > + - "#address-cells" > > + - "#size-cells" > > + - ranges > > + > > +allOf: > > + - if: > > + properties: > > +xlnx,cluster-mode: > > + enum: > > +- 1 > > +then: > > + patternProperties: > > +"^r5f@[0-9a-f]+$": > > + type: object > > + > > + properties: > > +reg: > > + minItems: 1 > > + items: > > +- description: ATCM internal memory > > +- description: BTCM internal memory > > +- description: extra ATCM memory in lockstep mode > > +- description: extra BTCM memory in lockstep mode > > + > > +reg-names: > > + minItems: 1 > > + items: > > +- const: atcm0 > > +- const: btcm0 > > +- const: atcm1 > > +- const: btcm1 > > Why power domains are flexible? > > > + > > +else: > > + patternProperties: > > +"^r5f@[0-9a-f]+$": > > + type: object > > + > > + properties: > > +reg: > > + minItems: 1 > > + items: > > +- description: ATCM internal memory > > +- description: BTCM internal memory > > + > > +reg-names: > > + minItems: 1 > > + items: > > +- const: atcm0 > > +-
Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes
On 08.03.24 13:33, David Woodhouse wrote: > On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote: >> On 07.03.24 15:02, David Woodhouse wrote: >>> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote: RFC v3 updates -- This series implements a driver for a virtio-rtc device conforming to spec RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to the PTP clock driver already present before. This patch series depends on the patch series "treewide: Use clocksource id for get_device_system_crosststamp()" [3]. Pull [4] to get the combined series on top of mainline. Overview This patch series adds the virtio_rtc module, and related bugfixes. The virtio_rtc module implements a driver compatible with the proposed Virtio RTC device specification [1]. The Virtio RTC (Real Time Clock) device provides information about current time. The device can provide different clocks, e.g. for the UTC or TAI time standards, or for physical time elapsed since some past epoch. >>> >>> Hm, should we allow UTC? If you tell me the time in UTC, then >>> (sometimes) I still don't actually know what the time is, because some >>> UTC seconds occur twice. UTC only makes sense if you provide the TAI >>> offset, surely? Should the virtio_rtc specification make it mandatory >>> to provide such? >>> >>> Otherwise you're just designing it to allow crappy hypervisors to >>> expose incomplete information. >>> >> >> Hi David, >> >> (adding virtio-comm...@lists.oasis-open.org for spec discussion), >> >> thank you for your insightful comments. I think I take a broadly similar >> view. The reason why the current spec and driver is like this is that I >> took a pragmatic approach at first and only included features which work >> out-of-the-box for the current Linux ecosystem. >> >> The current virtio_rtc features work similar to ptp_kvm, and therefore >> can >> work out-of-the-box with time sync daemons such as chrony. >> >> As of RFC spec v3, UTC clock only is allowed. If mandating a TAI clock >> as >> well, I am afraid that >> >> - in some (embedded) scenarios, the TAI clock may not be available >> >> - crappy hypervisors will pass off the UTC clock as the TAI clock. >> >> For the same reasons, I am also not sure about adding a *mandatory* TAI >> offset to each readout. I don't know user-space software which would >> leverage this already (at least not through the PTP clock interface). >> And >> why would such software not go straight for the TAI clock instead? >> >> How about adding a requirement to the spec that the virtio-rtc device >> SHOULD expose the TAI clock whenever it is available - would this >> address >> your concerns? > > I think that would be too easy for implementors to miss, or decide not > to obey. Or to get *wrong*, by exposing a TAI clock but actually > putting UTC in it. > > I think I prefer to mandate the tai_offset field with the UTC clock. > Crappy implementations will just set it to zero, but at least that > gives a clear signal to the guests that it's *their* problem to > resolve. To me there are some open questions regarding how this would work. Is there a use case for this with the v3 clock reading methods, or would it be enough to address this with the Virtio timekeeper? Looking at clock_adjtime(2), the tai_offset could be exposed, but probably best alongside some additional information about leap seconds. I am not aware about any user-space user. In addition, leap second smearing should also be addressed. > > > > PTP clock interface --- virtio_rtc exposes clocks as PTP clocks to userspace, similar to ptp_kvm. If both the Virtio RTC device and this driver have special support for the current clocksource, time synchronization programs can use cross-timestamping using ioctl PTP_SYS_OFFSET_PRECISE2 aka PTP_SYS_OFFSET_PRECISE. Similar to ptp_kvm, system time synchronization with single-digit ns precision is possible with a quiescent reference clock (from the Virtio RTC device). This works even when the Virtio device response is slow compared to ptp_kvm hypercalls. >>> >>> Is PTP the right mechanism for this? As I understand it, PTP is a way >>> to precisely synchronize one clock with another. But in the case of >>> virt guests synchronizing against the host, it isn't really *another* >>> clock. It really is the *same* underlying clock. As the host clock >>> varies with temperature, for example, so does the guest clock. The only >>> difference is an offset and (on x86 perhaps) a mathematical scaling of >>> the frequency. >>> >>> I was looking at this another way, when I came across this virtio-rtc >>> work. >>> >>> My idea was just for the hypervisor to expose its own timekeeping >>> information — the counter/TSC value and TAI time at a given moment, >>>
Re: [RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver
On 08.03.24 18:03, Alexandre Belloni wrote:
> Hello,
>
> I'll start by saying that I'm sorry, I have a very very high level
> knowledge about what virtio is.
>
> On 18/12/2023 08:38:45+0100, Peter Hilber wrote:
>> Expose the virtio-rtc UTC clock as an RTC clock to userspace, if it is
>> present. Support RTC alarm if the virtio-rtc alarm feature is present.
>> The
>> virtio-rtc device signals an alarm by marking an alarmq buffer as used.
>>
>> Peculiarities
>> -
>>
>> A virtio-rtc clock is a bit special for an RTC clock in that
>>
>> - the clock may step (also backwards) autonomously at any time and
>>
>> - the device, and its notification mechanism, will be reset during boot
>> or
>> resume from sleep.
>>
>> The virtio-rtc device avoids that the driver might miss an alarm. The
>> device signals an alarm whenever the clock has reached or passed the
>> alarm
>> time, and also when the device is reset (on boot or resume from sleep),
>> if
>> the alarm time is in the past.
>>
>> Open Issue
>> --
>>
>> The CLOCK_BOOTTIME_ALARM will use the RTC clock to wake up from sleep,
>> and
>> implicitly assumes that no RTC clock steps will occur during sleep. The
>> RTC
>> class driver does not know whether the current alarm is a real-time
>> alarm
>> or a boot-time alarm.
>>
>> Perhaps this might be handled by the driver also setting a virtio-rtc
>> monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM).
>> The
>> virtio-rtc monotonic alarm would just be used to wake up in case it was
>> a
>> CLOCK_BOOTTIME_ALARM alarm.
>>
>> Otherwise, the behavior should not differ from other RTC class drivers.
>>
>
> What I don't quite get is how this is actually related to RTCs. This
> would be a super imprecise mechanism to get the current time and date
> from the host to the guest which is what I think your are trying to do,
> especially since this is not supporting UIE.
> The host system clock may come from reading the RTC at some point in
> time but more likely from another source so is it really the best
> synchronization mechanism?
Hello,
thank you for your comments.
The main motivation to have the RTC class driver is the RTC alarm
(discussed below).
As for synchronization, virtio_rtc also offers a PTP clock [1] which will
be more precise, but which needs a user space daemon. As for RTC-based
initial synchronization, my idea was to propose, in a second step, an
optional op for rtc_class_ops, which would read the clock with nanosecond
precision. This optional op could then be used in rtc_hctosys(), so there
would be no need for UIE waiting.
[1]
https://lore.kernel.org/all/20231218073849.35294-6-peter.hil...@opensynergy.com/
>
> The other thing is that I don't quite get the point of the RTC alarm
> versus a regular timer in this context.
RTC alarms allow to resume from suspend and poweroff (esp. also through
alarmtimers), which is of interest in embedded virtualization. In my
understanding RTC is ATM the only way to do this.
(I was indeed thinking about adding an alternate alarmtimer backend for
CLOCK_BOOTTIME_ALARM, which should deal with the CLOCK_REALTIME_ALARM vs
CLOCK_BOOTTIME_ALARM issue which is described in the commit message.)
>
>
> [...]
>
>> +static const struct rtc_class_ops viortc_class_with_alarm_ops = {
>> +.read_time = viortc_class_read_time,
>> +.read_alarm = viortc_class_read_alarm,
>> +.set_alarm = viortc_class_set_alarm,
>> +.alarm_irq_enable = viortc_class_alarm_irq_enable,
>> +};
>> +
>> +static const struct rtc_class_ops viortc_class_no_alarm_ops = {
>> +.read_time = viortc_class_read_time,
>> +};
>> +
>
> [...]
>
>> +/**
>> +/**
>> + * viortc_class_init() - init RTC class wrapper and device
>> + * @viortc: device data
>> + * @vio_clk_id: virtio_rtc clock id
>> + * @have_alarm: expose alarm ops
>> + * @parent_dev: virtio device
>> + *
>> + * Context: Process context.
>> + * Return: RTC class wrapper on success, ERR_PTR otherwise.
>> + */
>> +struct viortc_class *viortc_class_init(struct viortc_dev *viortc,
>> + u16 vio_clk_id, bool have_alarm,
>> + struct device *parent_dev)
>> +{
>> +struct viortc_class *viortc_class;
>> +struct rtc_device *rtc;
>> +
>> +viortc_class =
>> +devm_kzalloc(parent_dev, sizeof(*viortc_class),
>> GFP_KERNEL);
>> +if (!viortc_class)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +viortc_class->viortc = viortc;
>> +
>> +rtc = devm_rtc_allocate_device(parent_dev);
>> +if (IS_ERR(rtc))
>> +return ERR_PTR(PTR_ERR(rtc));
>> +
>> +viortc_class->rtc = rtc;
>> +
>> +clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
>> +
>> +rtc->ops = have_alarm ? _class_with_alarm_ops :
>> +_class_no_alarm_ops;
>
> Don't do this, simply clear the alarm feature.
>
OK (sorry, was obviously very inelegant).
Best regards,
Peter
[PATCH v13 4/4] remoteproc: zynqmp: parse TCM from device tree
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
1 file changed, 107 insertions(+), 5 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..d4a22caebaad 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
};
/*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
*/
static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
}
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+ int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+ struct of_phandle_args out_args;
+ struct zynqmp_r5_core *r5_core;
+ struct platform_device *cpdev;
+ struct mem_bank_data *tcm;
+ struct device_node *np;
+ struct resource *res;
+ u64 abs_addr, size;
+ struct device *dev;
+
+ for (i = 0; i < cluster->core_count; i++) {
+ r5_core = cluster->r5_cores[i];
+ dev = r5_core->dev;
+ np = r5_core->np;
+
+ pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+ if (pd_count <= 0) {
+ dev_err(dev, "invalid power-domains property, %d\n",
pd_count);
+ return -EINVAL;
+ }
+
+ /* First entry in power-domains list is for r5 core, rest for
TCM. */
+ tcm_bank_count = pd_count - 1;
+
+ if (tcm_bank_count <= 0) {
+ dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+ return -EINVAL;
+ }
+
+ r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data
*),
+ GFP_KERNEL);
+ if (!r5_core->tcm_banks)
+ return -ENOMEM;
+
+ r5_core->tcm_bank_count = tcm_bank_count;
+ for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++,
tcm_pd_idx++) {
+ tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+ GFP_KERNEL);
+ if (!tcm)
+ return -ENOMEM;
+
+ r5_core->tcm_banks[j] = tcm;
+
+ /* Get power-domains id of TCM. */
+ ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, _args);
+ if (ret) {
+ dev_err(r5_core->dev,
+ "failed to get tcm %d pm domain, ret
%d\n",
+ tcm_pd_idx, ret);
+ return ret;
+ }
+ tcm->pm_domain_id = out_args.args[0];
+ of_node_put(out_args.np);
+
+ /* Get TCM address without translation. */
+ ret = of_property_read_reg(np, j, _addr, );
+ if (ret) {
+ dev_err(dev, "failed to get reg property\n");
+ return ret;
+ }
+
+ /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+ tcm->da = (u32)abs_addr;
+ tcm->size = (u32)size;
+
+ cpdev = to_platform_device(dev);
+ res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+ if (!res) {
+ dev_err(dev, "failed to get tcm resource\n");
+ return -EINVAL;
+ }
+
+ tcm->addr = (u32)res->start;
+ tcm->bank_name = (char *)res->name;
+ res =
[PATCH v13 3/4] dts: zynqmp: add properties for TCM in remoteproc
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 65 +--
2 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102",
"xlnx,zynqmp";
};
+_split {
+ status = "okay";
+};
+
+_lockstep {
+ status = "disabled";
+};
+
{
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index eaba466804bc..c8a7fd0f3a1e 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -248,19 +248,74 @@ fpga_full: fpga-full {
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
--
2.25.1
[PATCH v13 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
From: Radhey Shyam Pandey
Introduce bindings for TCM memory address space on AMD-xilinx Zynq
UltraScale+ platform. It will help in defining TCM in device-tree
and make it's access platform agnostic and data-driven.
Tightly-coupled memories(TCMs) are low-latency memory that provides
predictable instruction execution and predictable data load/store
timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
The TCM resources(reg, reg-names and power-domain) are documented for
each TCM in the R5 node. The reg and reg-names are made as required
properties as we don't want to hardcode TCM addresses for future
platforms and for zu+ legacy implementation will ensure that the
old dts w/o reg/reg-names works and stable ABI is maintained.
It also extends the examples for TCM split and lockstep modes.
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Tanmay Shah
---
Changes in v13:
- Have power-domains property for lockstep case instead of
keeping it flexible.
- Add "items:" list in power-domains property
Changes in v12:
- add "reg", "reg-names" and "power-domains" in pattern properties
- add "reg" and "reg-names" in required list
- keep "power-domains" in required list as it was before the change
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 201 --
1 file changed, 181 insertions(+), 20 deletions(-)
diff --git
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..629084a84ce6 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -20,9 +20,21 @@ properties:
compatible:
const: xlnx,zynqmp-r5fss
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ ranges:
+description: |
+ Standard ranges definition providing address translations for
+ local R5F TCM address spaces to bus addresses.
+
xlnx,cluster-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
+default: 1
description: |
The RPU MPCore can operate in split mode (Dual-processor performance),
Safety
lock-step mode(Both RPU cores execute the same code in lock-step,
@@ -37,7 +49,7 @@ properties:
2: single cpu mode
patternProperties:
- "^r5f-[a-f0-9]+$":
+ "^r5f@[0-9a-f]+$":
type: object
description: |
The RPU is located in the Low Power Domain of the Processor Subsystem.
@@ -54,8 +66,17 @@ patternProperties:
compatible:
const: xlnx,zynqmp-r5f
+ reg:
+minItems: 1
+maxItems: 4
+
+ reg-names:
+minItems: 1
+maxItems: 4
+
power-domains:
-maxItems: 1
+minItems: 2
+maxItems: 5
mboxes:
minItems: 1
@@ -101,35 +122,175 @@ patternProperties:
required:
- compatible
+ - reg
+ - reg-names
- power-domains
-unevaluatedProperties: false
-
required:
- compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+allOf:
+ - if:
+ properties:
+xlnx,cluster-mode:
+ enum:
+- 1
+then:
+ patternProperties:
+"^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+reg:
+ minItems: 1
+ items:
+- description: ATCM internal memory
+- description: BTCM internal memory
+- description: extra ATCM memory in lockstep mode
+- description: extra BTCM memory in lockstep mode
+
+reg-names:
+ minItems: 1
+ items:
+- const: atcm0
+- const: btcm0
+- const: atcm1
+- const: btcm1
+
+power-domains:
+ minItems: 2
+ items:
+- description: RPU core power domain
+- description: ATCM power domain
+- description: BTCM power domain
+- description: second ATCM power domain
+- description: second BTCM power domain
+
+else:
+ patternProperties:
+"^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+reg:
+ minItems: 1
+ items:
+- description: ATCM internal memory
+- description: BTCM internal memory
+
+reg-names:
+ minItems: 1
+ items:
+- const: atcm0
+- const: btcm0
+
+power-domains:
+ minItems: 2
+ items:
+- description: RPU core power domain
+- description: ATCM power domain
+- description: BTCM power domain
additionalProperties: false
examples:
- |
-remoteproc {
-
[PATCH v13 1/4] remoteproc: zynqmp: fix lockstep mode memory region
In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.
| *TCM* | *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_ |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_ |
However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:
| *TCM* | *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_ |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_ |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_ |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_ |
This makes driver maintanance easy and makes design robust for future
platorms as well.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
1 file changed, 12 insertions(+), 133 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[]
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
};
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
- {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB
each */
- {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
- {0, 0, 0, PD_R5_1_ATCM, ""},
- {0, 0, 0, PD_R5_1_BTCM, ""},
+ {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each
*/
+ {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+ {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+ {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
};
/**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
}
/*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
* @rproc: single R5 core's corresponding rproc instance
*
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
*
* return 0 on success, otherwise non-zero value on failure
*/
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
{
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc
*rproc)
ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x",
pm_domain_id);
- goto release_tcm_split;
+ goto release_tcm;
}
- dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x,
size=0x%lx",
+ dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
- goto release_tcm_split;
+ goto release_tcm;
}
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
return 0;
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc
*rproc)
return ret;
}
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
- struct rproc_mem_entry *rproc_mem;
- struct zynqmp_r5_core *r5_core;
- int i, num_banks, ret;
- phys_addr_t bank_addr;
- size_t bank_size = 0;
- struct device *dev;
- u32 pm_domain_id;
- char *bank_name;
- u32 da;
-
- r5_core = rproc->priv;
- dev = r5_core->dev;
-
- /* Go through zynqmp banks for r5 node */
- num_banks =
[PATCH v13 0/4] add zynqmp TCM bindings
Tightly-Coupled Memories(TCMs) are low-latency memory that provides predictable instruction execution and predictable data load/store timing. Each Cortex-R5F processor contains exclusive two 64 KB memory banks on the ATCM and BTCM ports, for a total of 128 KB of memory. In lockstep mode, both 128KB memory is accessible to the cluster. As per ZynqMP Ultrascale+ Technical Reference Manual UG1085, following is address space of TCM memory. The bindings in this patch series introduces properties to accommodate following address space with address translation between Linux and Cortex-R5 views. | | | | | --- | --- | --- | | *Mode*| *R5 View* | *Linux view* | Notes | | *Split Mode* | *start addr*| *start addr* | | | R5_0 ATCM (64 KB) | 0x_ | 0xFFE0_ | | | R5_0 BTCM (64 KB) | 0x0002_ | 0xFFE2_ | | | R5_1 ATCM (64 KB) | 0x_ | 0xFFE9_ | alias of 0xFFE1_ | | R5_1 BTCM (64 KB) | 0x0002_ | 0xFFEB_ | alias of 0xFFE3_ | | ___ | ___ |___ | | | *Lockstep Mode*| | | | | R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_ | | | R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_ | | References: UG1085 TCM address space: https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map Changes in v13: - Have power-domains property for lockstep case instead of keeping it flexible. - Add "items:" list in power-domains property Changes in v12: - add "reg", "reg-names" and "power-domains" in pattern properties - add "reg" and "reg-names" in required list - keep "power-domains" in required list as it was before the change Changes in v11: - Fix yamllint warning and reduce indentation as needed - Remove redundant initialization of the variable - Return correct error code if memory allocation failed Changs in v10: - Add new patch (1/4) to series that changes hardcode TCM addresses in lockstep mode and removes separate handling of TCM in lockstep and split mode - modify number of "reg", "reg-names" and "power-domains" entries based on cluster mode - Add extra optional atcm and btcm in "reg" property for lockstep mode - Add "reg-names" for extra optional atcm and btcm for lockstep mode - Drop previous Ack as bindings has new change - Add individual tcm regions via "reg" and "reg-names" for lockstep mode - Add each tcm's power-domains in lockstep mode - Drop previous Ack as new change in dts patchset - Remove redundant changes in driver to handle TCM in lockstep mode Changes in v9: - Fix rproc lockstep dts - Introduce new API to request and release core1 TCM power-domains in lockstep mode. This will be used during prepare -> add_tcm_banks callback to enable TCM in lockstep mode. - Parse TCM from device-tree in lockstep mode and split mode in uniform way. - Fix TCM representation in device-tree in lockstep mode. - Fix comments as suggested Changes in v8: - Remove use of pm_domains framework - Remove checking of pm_domain_id validation to power on/off tcm - Remove spurious change - parse power-domains property from device-tree and use EEMI calls to power on/off TCM instead of using pm domains framework Changes in v7: - %s/pm_dev1/pm_dev_core0/r - %s/pm_dev_link1/pm_dev_core0_link/r - %s/pm_dev2/pm_dev_core1/r - %s/pm_dev_link2/pm_dev_core1_link/r - remove pm_domain_id check to move next patch - add comment about how 1st entry in pm domain list is used - fix loop when jump to fail_add_pm_domains loop - move checking of pm_domain_id from previous patch - fix mem_bank_data memory allocation Changes in v6: - Introduce new node entry for r5f cluster split mode dts and keep it disabled by default. - Keep remoteproc lockstep mode enabled by default to maintian back compatibility. - Enable split mode only for zcu102 board to demo split mode use - Remove spurious change - Handle errors in add_pm_domains function - Remove redundant code to handle errors from remove_pm_domains - Missing . at the end of the commit message - remove redundant initialization of variables - remove fail_tcm label and relevant code to free memory acquired using devm_* API. As this will be freed when device free it - add extra check to see if "reg" property is supported or not Changes in v5: - maintain Rob's Ack on bindings patch as no changes in bindings - split previous patch into multiple patches - Use pm domain framework to turn on/off TCM - Add support of parsing TCM information from device-tree - maintain backward compatibility with previous bindings without TCM information available in device-tree This patch series continues previous effort to upstream ZynqMP TCM bindings: Previous
Re: Re: Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)
On Thu, Feb 01, 2024 at 12:47:39PM +0100, Tobias Huschle wrote: > On Thu, Feb 01, 2024 at 03:08:07AM -0500, Michael S. Tsirkin wrote: > > On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote: > > > On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote: > > > > On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote: > > > > > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote: > > > > > > Summary > > > > > > In my (non-vhost experience) opinion the way to go would be either > > > replacing the cond_resched with a hard schedule or setting the > > > need_resched flag within vhost if the a data transfer was successfully > > > initiated. It will be necessary to check if this causes problems with > > > other workloads/benchmarks. > > > > Yes but conceptually I am still in the dark on whether the fact that > > periodically invoking cond_resched is no longer sufficient to be nice to > > others is a bug, or intentional. So you feel it is intentional? > > I would assume that cond_resched is still a valid concept. > But, in this particular scenario we have the following problem: > > So far (with CFS) we had: > 1. vhost initiates data transfer > 2. kworker is woken up > 3. CFS gives priority to woken up task and schedules it > 4. kworker runs > > Now (with EEVDF) we have: > 0. In some cases, kworker has accumulated negative lag > 1. vhost initiates data transfer > 2. kworker is woken up > -3a. EEVDF does not schedule kworker if it has negative lag > -4a. vhost continues running, kworker on same CPU starves > -- > -3b. EEVDF schedules kworker if it has positive or no lag > -4b. kworker runs > > In the 3a/4a case, the kworker is given no chance to set the > necessary flag. The flag can only be set by another CPU now. > The schedule of the kworker was not caused by cond_resched, but > rather by the wakeup path of the scheduler. > > cond_resched works successfully once the load balancer (I suppose) > decides to migrate the vhost off to another CPU. In that case, the > load balancer on another CPU sets that flag and we are good. > That then eventually allows the scheduler to pick kworker, but very > late. Are we going anywhere with this btw? > > I propose a two patch series then: > > > > patch 1: in this text in Documentation/kernel-hacking/hacking.rst > > > > If you're doing longer computations: first think userspace. If you > > **really** want to do it in kernel you should regularly check if you need > > to give up the CPU (remember there is cooperative multitasking per CPU). > > Idiom:: > > > > cond_resched(); /* Will sleep */ > > > > > > replace cond_resched -> schedule > > > > > > Since apparently cond_resched is no longer sufficient to > > make the scheduler check whether you need to give up the CPU. > > > > patch 2: make this change for vhost. > > > > WDYT? > > For patch 1, I would like to see some feedback from Peter (or someone else > from the scheduler maintainers). > For patch 2, I would prefer to do some more testing first if this might have > an negative effect on other benchmarks. > > I also stumbled upon something in the scheduler code that I want to verify. > Maybe a cgroup thing, will check that out again. > > I'll do some more testing with the cond_resched->schedule fix, check the > cgroup thing and wait for Peter then. > Will get back if any of the above yields some results. > > > > > -- > > MST > > > >
Re: [PATCH 0/2] Add Samsung Galaxy Note 3 support
On Montag, 11. März 2024 15:23:30 CET Rob Herring wrote:
>
> On Sun, 10 Mar 2024 15:13:35 +0100, Luca Weiss wrote:
> > 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
> >
> >
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y qcom/qcom-msm8974-samsung-hlte.dtb'
> for 20240310-samsung-hlte-v1-0-e9b55bf98...@z3ntu.xyz:
>
> arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: /: memory: False schema
> does not allow {'device_type': ['memory'], 'reg': [[0, 0]]}
> from schema $id: http://devicetree.org/schemas/root-node.yaml#
> arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: l2-cache: Unevaluated
> properties are not allowed ('qcom,saw' was unexpected)
> from schema $id: http://devicetree.org/schemas/cache.yaml#
> arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: idle-states: 'spc' does
> not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/cpu/idle-states.yaml#
> arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: syscon@f9011000:
> compatible: 'anyOf' conditional failed, one must be fixed:
> ['syscon'] is too short
> 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller',
> 'allwinner,sun8i-h3-system-controller',
> 'allwinner,sun8i-v3s-system-controller',
> 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon',
> 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller',
> 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg',
> 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl',
> 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg',
> 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon',
> 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg',
> 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg',
> 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon',
> 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm',
> 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos',
> 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos',
> 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
> rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain',
> 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl',
> 'ti,j784s4-pcie-ctrl']
> from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Unfortunately all existing warnings from the .dtsi.
Regards
Luca
Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Hello Krzysztof, Thanks for reviews. Please find my comments below. On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote: > On 01/03/2024 19:16, Tanmay Shah wrote: > > From: Radhey Shyam Pandey > > > > Introduce bindings for TCM memory address space on AMD-xilinx Zynq > > UltraScale+ platform. It will help in defining TCM in device-tree > > and make it's access platform agnostic and data-driven. > > > > Tightly-coupled memories(TCMs) are low-latency memory that provides > > predictable instruction execution and predictable data load/store > > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory > > banks on the ATCM and BTCM ports, for a total of 128 KB of memory. > > > > The TCM resources(reg, reg-names and power-domain) are documented for > > each TCM in the R5 node. The reg and reg-names are made as required > > properties as we don't want to hardcode TCM addresses for future > > platforms and for zu+ legacy implementation will ensure that the > > old dts w/o reg/reg-names works and stable ABI is maintained. > > > > It also extends the examples for TCM split and lockstep modes. > > > > Signed-off-by: Radhey Shyam Pandey > > Signed-off-by: Tanmay Shah > > --- > > > > Changes in v12: > > - add "reg", "reg-names" and "power-domains" in pattern properties > > - add "reg" and "reg-names" in required list > > - keep "power-domains" in required list as it was before the change > > > > Changes in v11: > > - Fix yamllint warning and reduce indentation as needed > > > > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 -- > > 1 file changed, 168 insertions(+), 20 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > index 78aac69f1060..dc6ce308688f 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > @@ -20,9 +20,21 @@ properties: > >compatible: > > const: xlnx,zynqmp-r5fss > > > > + "#address-cells": > > +const: 2 > > + > > + "#size-cells": > > +const: 2 > > + > > + ranges: > > +description: | > > + Standard ranges definition providing address translations for > > + local R5F TCM address spaces to bus addresses. > > + > >xlnx,cluster-mode: > > $ref: /schemas/types.yaml#/definitions/uint32 > > enum: [0, 1, 2] > > +default: 1 > > description: | > >The RPU MPCore can operate in split mode (Dual-processor > > performance), Safety > >lock-step mode(Both RPU cores execute the same code in lock-step, > > @@ -37,7 +49,7 @@ properties: > >2: single cpu mode > > > > patternProperties: > > - "^r5f-[a-f0-9]+$": > > + "^r5f@[0-9a-f]+$": > > type: object > > description: | > >The RPU is located in the Low Power Domain of the Processor > > Subsystem. > > @@ -54,8 +66,17 @@ patternProperties: > >compatible: > > const: xlnx,zynqmp-r5f > > > > + reg: > > +minItems: 1 > > +maxItems: 4 > > + > > + reg-names: > > +minItems: 1 > > +maxItems: 4 > > + > >power-domains: > > -maxItems: 1 > > +minItems: 2 > > +maxItems: 5 > > > >mboxes: > > minItems: 1 > > @@ -101,35 +122,162 @@ patternProperties: > > > > required: > >- compatible > > + - reg > > + - reg-names > >- power-domains > > > > -unevaluatedProperties: false > > - > > required: > >- compatible > > + - "#address-cells" > > + - "#size-cells" > > + - ranges > > + > > +allOf: > > + - if: > > + properties: > > +xlnx,cluster-mode: > > + enum: > > +- 1 > > +then: > > + patternProperties: > > +"^r5f@[0-9a-f]+$": > > + type: object > > + > > + properties: > > +reg: > > + minItems: 1 > > + items: > > +- description: ATCM internal memory > > +- description: BTCM internal memory > > +- description: extra ATCM memory in lockstep mode > > +- description: extra BTCM memory in lockstep mode > > + > > +reg-names: > > + minItems: 1 > > + items: > > +- const: atcm0 > > +- const: btcm0 > > +- const: atcm1 > > +- const: btcm1 > > Why power domains are flexible? User may not want to use all the TCMs. For example, if users want to turn-on only TCM-A and rest of them want to keep off, then they can avoid having power-domains of other TCMs in the device-tree. This helps with less power-consumption when needed. Hence flexible list of power-domains list. I can certainly mention "items:" under power-domains property. > > > + > > +else: > > + patternProperties: > > +
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
On Mon, Mar 11, 2024 at 11:26:16AM +0100, Karel Balej wrote:
> Krzysztof Kozlowski, 2024-03-10T21:35:36+01:00:
> > 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.
>
> I think I understand the practical reasons. My point was that I would
> expect the alias to be added automatically even in the case that the
> device table is absent based solely on the driver name and the
> registration method (*module*_*platform*_driver). Why is that not the
> case? Obviously the driver name matching the mfd_cell name is sufficient
> for the driver to probe when it is built in so the name does seem to
> serve as some identification for the device just as a device table entry
> would.
>
> Furthermore, drivers/input/serio/ioc3kbd.c does not seem to have an ID
> table either, nor a MODULE_ALIAS -- is that a mistake? If not, what
> mechanism causes the driver to probe when compiled as a module? It seems
> to me to effectively be the same setup as with my driver and that does
> not load automatically (because of the missing alias).
Yes, ioc3kbd is broken as far as module auto-loading goes. It probably
did not get noticed before because the driver is likely to be built-in
on the target architecture.
I'll take patches.
Thanks.
--
Dmitry
Re: [PATCH 3/3] sh: Call paging_init() earlier in the init sequence
On Fri, Feb 9, 2024 at 5:29 PM Oreoluwa Babatunde wrote: > > The unflatten_device_tree() function contains a call to > memblock_alloc(). This is a problem because this allocation is done > before any of the reserved memory is set aside in paging_init(). > This means that there is a possibility for memblock to allocate from > any of the memory regions that are supposed to be set aside as reserved. > > Hence, move the call to paging_init() to be earlier in the init > sequence so that the reserved memory regions are set aside before any > allocations are done using memblock. > > Signed-off-by: Oreoluwa Babatunde > --- > arch/sh/kernel/setup.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring
[RFC PATCH v4 5/5] MAINTAINERS: add myself for Marvell 88PM886 PMIC
From: Karel Balej Add an entry to MAINTAINERS for the Marvell 88PM886 PMIC MFD, onkey and regulator drivers. Signed-off-by: Karel Balej --- Notes: RFC v3: - Remove onkey bindings file. RFC v2: - Only mention 88PM886 in the commit message. - Add regulator driver. - Rename the entry. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 960512bec428..944f88c92df6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12949,6 +12949,15 @@ F: drivers/net/dsa/mv88e6xxx/ F: include/linux/dsa/mv88e6xxx.h F: include/linux/platform_data/mv88e6xxx.h +MARVELL 88PM886 PMIC DRIVER +M: Karel Balej +S: Maintained +F: Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml +F: drivers/input/misc/88pm886-onkey.c +F: drivers/mfd/88pm886.c +F: drivers/regulators/88pm886-regulator.c +F: include/linux/mfd/88pm886.h + MARVELL ARMADA 3700 PHY DRIVERS M: Miquel Raynal S: Maintained -- 2.44.0
[RFC PATCH v4 4/5] input: add onkey driver for Marvell 88PM886 PMIC
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.
Acked-by: Dmitry Torokhov
Signed-off-by: Karel Balej
---
Notes:
RFC v4:
- Reflect MFD driver changes:
- chip->regmaps[...] -> chip->regmap
- Address Dmitry's feedback:
- Add ID table.
- Add Ack.
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.
- Use more temporaries.
- Use dev_err_probe.
- Modify Kconfig description.
drivers/input/misc/88pm886-onkey.c | 99 ++
drivers/input/misc/Kconfig | 7 +++
drivers/input/misc/Makefile| 1 +
3 files changed, 107 insertions(+)
create mode 100644 drivers/input/misc/88pm886-onkey.c
diff --git a/drivers/input/misc/88pm886-onkey.c
b/drivers/input/misc/88pm886-onkey.c
new file mode 100644
index ..b0bfbd57d826
--- /dev/null
+++ b/drivers/input/misc/88pm886-onkey.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct pm886_onkey {
+ struct input_dev *idev;
+ struct pm886_chip *chip;
+};
+
+static irqreturn_t pm886_onkey_irq_handler(int irq, void *data)
+{
+ struct pm886_onkey *onkey = data;
+ struct regmap *regmap = onkey->chip->regmap;
+ struct input_dev *idev = onkey->idev;
+ struct device *parent = idev->dev.parent;
+ unsigned int val;
+ int err;
+
+ err = regmap_read(regmap, PM886_REG_STATUS1, );
+ if (err) {
+ dev_err(parent, "Failed to read status: %d\n", err);
+ return IRQ_NONE;
+ }
+ val &= PM886_ONKEY_STS1;
+
+ input_report_key(idev, KEY_POWER, val);
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int pm886_onkey_probe(struct platform_device *pdev)
+{
+ struct pm886_chip *chip = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = >dev;
+ struct pm886_onkey *onkey;
+ struct input_dev *idev;
+ int irq, err;
+
+ onkey = devm_kzalloc(dev, sizeof(*onkey), GFP_KERNEL);
+ if (!onkey)
+ return -ENOMEM;
+
+ onkey->chip = chip;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return dev_err_probe(dev, irq, "Failed to get IRQ\n");
+
+ idev = devm_input_allocate_device(dev);
+ if (!idev) {
+ dev_err(dev, "Failed to allocate input device\n");
+ return -ENOMEM;
+ }
+ onkey->idev = idev;
+
+ idev->name = "88pm886-onkey";
+ idev->phys = "88pm886-onkey/input0";
+ idev->id.bustype = BUS_I2C;
+
+ input_set_capability(idev, EV_KEY, KEY_POWER);
+
+ err = devm_request_threaded_irq(dev, irq, NULL, pm886_onkey_irq_handler,
+ IRQF_ONESHOT | IRQF_NO_SUSPEND, "onkey",
+ onkey);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to request IRQ\n");
+
+ err = input_register_device(idev);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to register input
device\n");
+
+ return 0;
+}
+
+static const struct platform_device_id pm886_onkey_id_table[] = {
+ { "88pm886-onkey", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, pm886_onkey_id_table);
+
+static struct platform_driver pm886_onkey_driver = {
+ .driver = {
+ .name = "88pm886-onkey",
+ },
+ .probe = pm886_onkey_probe,
+ .id_table = pm886_onkey_id_table,
+};
+module_platform_driver(pm886_onkey_driver);
+
+MODULE_DESCRIPTION("Marvell 88PM886 onkey driver");
+MODULE_AUTHOR("Karel Balej ");
+MODULE_LICENSE("GPL");
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6ba984d7f0b1..16a079d9f0f2 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -33,6 +33,13 @@ config INPUT_88PM80X_ONKEY
To compile this driver as a module, choose M here: the module
will be called 88pm80x_onkey.
+config INPUT_88PM886_ONKEY
+ tristate "Marvell 88PM886 onkey support"
+ depends on MFD_88PM886_PMIC
+ help
+ Support the onkey of Marvell 88PM886 PMIC as an input device
+ reporting power button status.
+
config INPUT_AB8500_PONKEY
tristate "AB8500 Pon (PowerOn) Key"
depends on AB8500_CORE
diff --git a/drivers/input/misc/Makefile
[RFC PATCH v4 3/5] regulator: add regulators driver for Marvell 88PM886 PMIC
From: Karel Balej
Support the LDO and buck regulators of the Marvell 88PM886 PMIC.
Signed-off-by: Karel Balej
---
Please note that most of the regulators are not yet described: the
descriptions will be added to pm886_regulators in the same manner as the
already present ones before the series leaves the RFC state. In the
meantime, general comments on the driver will be appreciated.
Notes:
RFC v4:
- Initialize regulators regmap in the regulators driver.
- Register all regulators at once.
- Drop regulator IDs.
- Add missing '\n' to dev_err_probe message.
- Fix includes.
- Add ID table.
RFC v3:
- Do not have a variable for each regulator -- define them all in the
pm886_regulators array.
- Use new regulators regmap index name.
- Use dev_err_probe.
RFC v2:
- Drop of_compatible and related code.
- Drop unused include.
- Remove some abstraction: use only one regmap for all regulators and
only mention 88PM886 in Kconfig description.
- Reword commit message.
drivers/regulator/88pm886-regulator.c | 215 ++
drivers/regulator/Kconfig | 6 +
drivers/regulator/Makefile| 1 +
3 files changed, 222 insertions(+)
create mode 100644 drivers/regulator/88pm886-regulator.c
diff --git a/drivers/regulator/88pm886-regulator.c
b/drivers/regulator/88pm886-regulator.c
new file mode 100644
index ..6a2ddb11a28a
--- /dev/null
+++ b/drivers/regulator/88pm886-regulator.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define PM886_PAGE_OFFSET_REGULATORS 1
+
+#define PM886_REG_LDO_EN1 0x09
+#define PM886_REG_LDO_EN2 0x0a
+
+#define PM886_REG_BUCK_EN 0x08
+
+#define PM886_REG_LDO1_VOUT0x20
+#define PM886_REG_LDO2_VOUT0x26
+#define PM886_REG_LDO3_VOUT0x2c
+#define PM886_REG_LDO4_VOUT0x32
+#define PM886_REG_LDO5_VOUT0x38
+#define PM886_REG_LDO6_VOUT0x3e
+#define PM886_REG_LDO7_VOUT0x44
+#define PM886_REG_LDO8_VOUT0x4a
+#define PM886_REG_LDO9_VOUT0x50
+#define PM886_REG_LDO10_VOUT 0x56
+#define PM886_REG_LDO11_VOUT 0x5c
+#define PM886_REG_LDO12_VOUT 0x62
+#define PM886_REG_LDO13_VOUT 0x68
+#define PM886_REG_LDO14_VOUT 0x6e
+#define PM886_REG_LDO15_VOUT 0x74
+#define PM886_REG_LDO16_VOUT 0x7a
+
+#define PM886_REG_BUCK1_VOUT 0xa5
+#define PM886_REG_BUCK2_VOUT 0xb3
+#define PM886_REG_BUCK3_VOUT 0xc1
+#define PM886_REG_BUCK4_VOUT 0xcf
+#define PM886_REG_BUCK5_VOUT 0xdd
+
+#define PM886_LDO_VSEL_MASK0x0f
+#define PM886_BUCK_VSEL_MASK 0x7f
+
+struct pm886_regulator {
+ struct regulator_desc desc;
+ int max_uA;
+};
+
+static int pm886_regulator_get_ilim(struct regulator_dev *rdev)
+{
+ struct pm886_regulator *data = rdev_get_drvdata(rdev);
+
+ if (!data) {
+ dev_err(>dev, "Failed to get regulator data\n");
+ return -EINVAL;
+ }
+ return data->max_uA;
+}
+
+static const struct regulator_ops pm886_ldo_ops = {
+ .list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_iterate,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .get_current_limit = pm886_regulator_get_ilim,
+};
+
+static const struct regulator_ops pm886_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .get_current_limit = pm886_regulator_get_ilim,
+};
+
+static const unsigned int pm886_ldo_volt_table1[] = {
+ 170, 180, 190, 250, 280, 290, 310, 330,
+};
+
+static const unsigned int pm886_ldo_volt_table2[] = {
+ 120, 125, 170, 180, 185, 190, 250, 260,
+ 270, 275, 280, 285, 290, 300, 310, 330,
+};
+
+static const unsigned int pm886_ldo_volt_table3[] = {
+ 170, 180, 190, 200, 210, 250, 270, 280,
+};
+
+static const struct linear_range pm886_buck_volt_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(60, 0, 79, 12500),
+ REGULATOR_LINEAR_RANGE(160, 80, 84, 5),
+};
+
+static const struct linear_range
[RFC PATCH v4 2/5] mfd: add driver for Marvell 88PM886 PMIC
From: Karel Balej
Marvell 88PM886 is a PMIC which provides various functions such as
onkey, battery, charger and regulators. It is found for instance in the
samsung,coreprimevelte smartphone with which this was tested. Implement
basic support to allow for the use of regulators and onkey.
Signed-off-by: Karel Balej
---
Notes:
RFC v4:
- Use MFD_CELL_* macros.
- Address Lee's feedback:
- Do not define regmap_config.val_bits and .reg_bits.
- Drop everything regulator related except mfd_cell (regmap
initialization, IDs enum etc.). Drop pm886_initialize_subregmaps.
- Do not store regmap pointers as an array as there is now only one
regmap. Also drop the corresponding enum.
- Move regmap_config to the header as it is needed in the regulators
driver.
- pm886_chip.whoami -> chip_id
- Reword chip ID mismatch error message and print the ID as
hexadecimal.
- Fix includes in include/linux/88pm886.h.
- Drop the pm886_irq_number enum and define the (for the moment) only
IRQ explicitly.
- Have only one MFD cell for all regulators as they are now registered
all at once in the regulators driver.
- Reword commit message.
- Make device table static and remove comma after the sentinel to signal
that nothing should come after it.
RFC v3:
- Drop onkey cell .of_compatible.
- Rename LDO page offset and regmap to REGULATORS.
RFC v2:
- Remove some abstraction.
- Sort includes alphabetically and add linux/of.h.
- Depend on OF, remove of_match_ptr and add MODULE_DEVICE_TABLE.
- Use more temporaries and break long lines.
- Do not initialize ret in probe.
- Use the wakeup-source DT property.
- Rename ret to err.
- Address Lee's comments:
- Drop patched in presets for base regmap and related defines.
- Use full sentences in comments.
- Remove IRQ comment.
- Define regmap_config member values.
- Rename data to sys_off_data.
- Add _PMIC suffix to Kconfig.
- Use dev_err_probe.
- Do not store irq_data.
- s/WHOAMI/CHIP_ID
- Drop LINUX part of include guard name.
- Merge in the regulator series modifications in order to have more
devices and modify the commit message accordingly. Changes with
respect to the original regulator series patches:
- ret -> err
- Add temporary for dev in pm88x_initialize_subregmaps.
- Drop of_compatible for the regulators.
- Do not duplicate LDO regmap for bucks.
- Rewrite commit message.
drivers/mfd/88pm886.c | 149
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile| 1 +
include/linux/mfd/88pm886.h | 38 +
4 files changed, 200 insertions(+)
create mode 100644 drivers/mfd/88pm886.c
create mode 100644 include/linux/mfd/88pm886.h
diff --git a/drivers/mfd/88pm886.c b/drivers/mfd/88pm886.c
new file mode 100644
index ..88f21f813ec1
--- /dev/null
+++ b/drivers/mfd/88pm886.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define PM886_REG_INT_STATUS1 0x05
+
+#define PM886_REG_INT_ENA_10x0a
+#define PM886_INT_ENA1_ONKEY BIT(0)
+
+#define PM886_IRQ_ONKEY0
+
+static struct regmap_irq pm886_regmap_irqs[] = {
+ REGMAP_IRQ_REG(PM886_IRQ_ONKEY, 0, PM886_INT_ENA1_ONKEY),
+};
+
+static struct regmap_irq_chip pm886_regmap_irq_chip = {
+ .name = "88pm886",
+ .irqs = pm886_regmap_irqs,
+ .num_irqs = ARRAY_SIZE(pm886_regmap_irqs),
+ .num_regs = 4,
+ .status_base = PM886_REG_INT_STATUS1,
+ .ack_base = PM886_REG_INT_STATUS1,
+ .unmask_base = PM886_REG_INT_ENA_1,
+};
+
+static struct resource pm886_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(PM886_IRQ_ONKEY, "88pm886-onkey"),
+};
+
+static struct mfd_cell pm886_devs[] = {
+ MFD_CELL_RES("88pm886-onkey", pm886_onkey_resources),
+ MFD_CELL_NAME("88pm886-regulator"),
+};
+
+static int pm886_power_off_handler(struct sys_off_data *sys_off_data)
+{
+ struct pm886_chip *chip = sys_off_data->cb_data;
+ struct regmap *regmap = chip->regmap;
+ struct device *dev = >client->dev;
+ int err;
+
+ err = regmap_update_bits(regmap, PM886_REG_MISC_CONFIG1, PM886_SW_PDOWN,
+ PM886_SW_PDOWN);
+ if (err) {
+ dev_err(dev, "Failed to power off the device: %d\n", err);
+ return NOTIFY_BAD;
+ }
+ return NOTIFY_DONE;
+}
+
+static int pm886_setup_irq(struct pm886_chip *chip,
+ struct regmap_irq_chip_data **irq_data)
+{
+ struct regmap *regmap = chip->regmap;
+ struct device *dev = >client->dev;
+ int err;
+
+ /* Set interrupt clearing mode to
[RFC PATCH v4 0/5] initial support for Marvell 88PM886 PMIC
From: Karel Balej Hello, the following implements basic support for Marvell's 88PM886 PMIC which is found for instance as a component of the samsung,coreprimevelte smartphone which inspired this and also serves as a testing platform. The code for the MFD is based primarily on this old series [1] with the addition of poweroff based on the smartphone's downstream kernel tree [2]. The onkey and regulators drivers are based on the latter. I am not in possesion of the datasheet. [1] https://lore.kernel.org/all/1434098601-3498-1-git-send-email-yizh...@marvell.com/ [2] https://github.com/CoderCharmander/g361f-kernel Thank you and kind regards, K. B. --- RFC v4: - RFC v3: https://lore.kernel.org/all/20240303101506.4187-1-kar...@gimli.ms.mff.cuni.cz/ RFC v3: - Address Rob's feedback: - Drop onkey bindings patch. - Rename PM88X -> PM886 everywhere. - RFC v2: https://lore.kernel.org/all/20240211094609.2223-1-kar...@gimli.ms.mff.cuni.cz/ RFC v2: - Merge with the regulators series to have multiple devices and thus justify the use of the MFD framework. - Rebase on v6.8-rc3. - Reorder patches. - MFD RFC v1: https://lore.kernel.org/all/20231217131838.7569-1-kar...@gimli.ms.mff.cuni.cz/ - regulators RFC v1: https://lore.kernel.org/all/20231228100208.2932-1-kar...@gimli.ms.mff.cuni.cz/ Karel Balej (5): dt-bindings: mfd: add entry for Marvell 88PM886 PMIC mfd: add driver for Marvell 88PM886 PMIC regulator: add regulators driver for Marvell 88PM886 PMIC input: add onkey driver for Marvell 88PM886 PMIC MAINTAINERS: add myself for Marvell 88PM886 PMIC .../bindings/mfd/marvell,88pm886-a1.yaml | 76 +++ MAINTAINERS | 9 + drivers/input/misc/88pm886-onkey.c| 99 drivers/input/misc/Kconfig| 7 + drivers/input/misc/Makefile | 1 + drivers/mfd/88pm886.c | 149 drivers/mfd/Kconfig | 12 + drivers/mfd/Makefile | 1 + drivers/regulator/88pm886-regulator.c | 215 ++ drivers/regulator/Kconfig | 6 + drivers/regulator/Makefile| 1 + include/linux/mfd/88pm886.h | 38 12 files changed, 614 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml create mode 100644 drivers/input/misc/88pm886-onkey.c create mode 100644 drivers/mfd/88pm886.c create mode 100644 drivers/regulator/88pm886-regulator.c create mode 100644 include/linux/mfd/88pm886.h -- 2.44.0
[RFC PATCH v4 1/5] dt-bindings: mfd: add entry for Marvell 88PM886 PMIC
From: Karel Balej
Marvell 88PM886 is a PMIC with several subdevices such as onkey,
regulators or battery and charger. It comes in at least two revisions,
A0 and A1 -- only A1 is described here at the moment.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Karel Balej
---
Notes:
RFC v4:
- Address Krzysztof's comments:
- Fix regulators indentation.
- Add Krzysztof's trailer.
RFC v3:
- Add wakeup-source property.
- Address Rob's feedback:
- Move regulators into the MFD file.
- Remove interrupt-controller and #interrupt-cells properties.
RFC v2:
- Address Rob's feedback:
- Drop mention of 88PM880.
- Make sure the file passes bindings check (add the necessary header
and fix `interrupt-cells`).
- Other small changes.
- Add regulators. Changes with respect to the regulator RFC series:
- Address Krzysztof's comments:
- Drop unused compatible.
- Fix sub-node pattern.
.../bindings/mfd/marvell,88pm886-a1.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
new file mode 100644
index ..d6a71c912b76
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/marvell,88pm886-a1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 88PM886 PMIC core
+
+maintainers:
+ - Karel Balej
+
+description:
+ Marvell 88PM886 is a PMIC providing several functions such as onkey,
+ regulators or battery and charger.
+
+properties:
+ compatible:
+const: marvell,88pm886-a1
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ wakeup-source: true
+
+ regulators:
+type: object
+additionalProperties: false
+patternProperties:
+ "^(ldo(1[0-6]|[1-9])|buck[1-5])$":
+type: object
+$ref: /schemas/regulator/regulator.yaml#
+description: LDO or buck regulator.
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@30 {
+compatible = "marvell,88pm886-a1";
+reg = <0x30>;
+interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+interrupt-parent = <>;
+wakeup-source;
+
+regulators {
+ ldo2: ldo2 {
+regulator-min-microvolt = <310>;
+regulator-max-microvolt = <330>;
+ };
+
+ ldo15: ldo15 {
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+ };
+
+ buck2: buck2 {
+regulator-min-microvolt = <180>;
+regulator-max-microvolt = <180>;
+ };
+};
+ };
+};
+...
--
2.44.0
Re: [PATCH] remoteproc: make rproc_class constant
Hi Ricardo,
On Tue, Mar 05, 2024 at 04:40:23PM -0300, Ricardo B. Marliere wrote:
> Since commit 43a7206b0963 ("driver core: class: make class_register() take
> a const *"), the driver core allows for struct class to be in read-only
> memory, so move the rproc_class structure to be declared at build time
> placing it into read-only memory, instead of having to be dynamically
> allocated at boot time.
>
> Cc: Greg Kroah-Hartman
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Ricardo B. Marliere
> ---
> drivers/remoteproc/remoteproc_internal.h | 2 +-
> drivers/remoteproc/remoteproc_sysfs.c| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_internal.h
> b/drivers/remoteproc/remoteproc_internal.h
> index f62a82d71dfa..0cd09e67ac14 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -72,7 +72,7 @@ void rproc_init_debugfs(void);
> void rproc_exit_debugfs(void);
>
> /* from remoteproc_sysfs.c */
> -extern struct class rproc_class;
> +extern const struct class rproc_class;
> int rproc_init_sysfs(void);
> void rproc_exit_sysfs(void);
>
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 8c7ea8922638..138e752c5e4e 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -254,7 +254,7 @@ static const struct attribute_group *rproc_devgroups[] = {
> NULL
> };
>
> -struct class rproc_class = {
> +const struct class rproc_class = {
> .name = "remoteproc",
> .dev_groups = rproc_devgroups,
> };
>
I am in agreement with both patches and will add them to 6.9-rc1 when it comes
out.
Thanks,
Mathieu
> ---
> base-commit: 8b46dc5cfa5ffea279aed0fc05dc4b1c39a51517
> change-id: 20240305-class_cleanup-remoteproc2-f1212934f990
>
> Best regards,
> --
> Ricardo B. Marliere
>
Re: [PATCH 0/2] Add Samsung Galaxy Note 3 support
On Sun, 10 Mar 2024 15:13:35 +0100, Luca Weiss wrote:
> 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
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/qcom-msm8974-samsung-hlte.dtb' for
20240310-samsung-hlte-v1-0-e9b55bf98...@z3ntu.xyz:
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: /: memory: False schema
does not allow {'device_type': ['memory'], 'reg': [[0, 0]]}
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: l2-cache: Unevaluated
properties are not allowed ('qcom,saw' was unexpected)
from schema $id: http://devicetree.org/schemas/cache.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: idle-states: 'spc' does
not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/cpu/idle-states.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: syscon@f9011000:
compatible: 'anyOf' conditional failed, one must be fixed:
['syscon'] is too short
'syscon' is not one of ['allwinner,sun8i-a83t-system-controller',
'allwinner,sun8i-h3-system-controller',
'allwinner,sun8i-v3s-system-controller',
'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon',
'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller',
'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg',
'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl',
'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg',
'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon',
'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg',
'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg',
'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon',
'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm',
'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos',
'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos',
'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain',
'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl',
'ti,j784s4-pcie-ctrl']
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Re: [DMARC Error] Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Hi, On 07.03.2024 03:17, Puranjay Mohan wrote: Hi Alex, On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote: Hi Puranjay, On 06/03/2024 17:59, Puranjay Mohan wrote: This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an ftrace_ops to the common ftrace trampoline, allowing each callsite to invoke distinct tracer functions without the need to fall back to list processing or to allocate custom trampolines for each callsite. This significantly speeds up cases where multiple distinct trace functions are used and callsites are mostly traced by a single tracer. The idea and most of the implementation is taken from the ARM64's implementation of the same feature. The idea is to place a pointer to the ftrace_ops as a literal at a fixed offset from the function entry point, which can be recovered by the common ftrace trampoline. We use -fpatchable-function-entry to reserve 8 bytes above the function entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer to the associated ftrace_ops for that callsite. Functions are aligned to 8 bytes to make sure that the accesses to this literal are atomic. This approach allows for directly invoking ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or part of a module), without going via ftrace_ops_list_func. I've benchamrked this with the ftrace_ops sample module on Qemu, with the next version, I will provide benchmarks on real hardware: Without this patch: +---+-++ | Number of tracers| Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15615700 |156 | - | |0 | 1 |15917600 |159 | - | |0 | 2 |15668000 |156 | - | |0 | 10 |14971500 |149 | - | |0 |100 |15417600 |154 | - | |0 |200 |15387000 |153 | - | |--++-++---| |1 | 0 | 119906800 | 1199 | 1043 | |1 | 1 | 137428600 | 1374 | 1218 | |1 | 2 | 159562400 | 1374 | 1218 | |1 | 10 | 302099900 | 3020 | 2864 | |1 |100 | 2008785500 | 20087 | 19931 | |1 |200 | 3965221900 | 39652 | 39496 | |--++-++---| |1 | 0 | 119166700 | 1191 | 1035 | |2 | 0 | 15700 | 1579 | 1423 | | 10 | 0 | 425370100 | 4253 | 4097 | | 100 | 0 | 3595252100 | 35952 | 35796 | | 200 | 0 | 7023485700 | 70234 | 70078 | +--++-++---+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. With this patch: +---+-++ | Number of tracers | Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15254600 |152 | - | |0 | 1 |16136700 |161 | - | |0 | 2 |15329500 |153 | - | |0 | 10 |15148800 |151 | - | |0 |100 |15746900 |157 | - | |0 |200 |15737400 |157 | - | |--++-++---| |1 | 0 |47909000 |479 | 327 | |1 | 1 |48297400 |482 | 330 | |1 | 2 |47314100 |473 | 321 | |1 | 10 |47844900 |478 | 326 | |1 |100 |46591900 |465 | 313 | |1 |200 |47178900 |471 | 319 | |--++-++---| |1 | 0 |46715800 |467
RE: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, March 11, 2024 12:01 PM
> To: wangyunjian
> Cc: Michael S. Tsirkin ; Paolo Abeni ;
> willemdebruijn.ker...@gmail.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 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(>tx_ring))
> > > > > > + return;
> > > > > > +
> > > > > > + spin_lock(>pool_lock);
> > > > > > + pool = tfile->xsk_pool;
> > > > > > + if (!pool) {
> > > > > > + spin_unlock(>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(>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(>tx_ring.producer_lock);
> > > > > > + spin_unlock(>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(>tx_descs[i]);
> > > > > > + /* The budget must be less than or equal to
> tx_ring.size,
> > > > > > +* so enqueuing will not fail.
> > > > > > +*/
> > > > > > + __ptr_ring_produce(>tx_ring, frame);
> > > > > > + }
> > > > > > + spin_unlock(>tx_ring.producer_lock);
> > > > > > + spin_unlock(>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().
> >
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
Krzysztof Kozlowski, 2024-03-11T11:41:53+01:00:
> On 11/03/2024 11:26, Karel Balej wrote:
> > Krzysztof Kozlowski, 2024-03-10T21:35:36+01:00:
> >> 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.
> >
> > I think I understand the practical reasons. My point was that I would
> > expect the alias to be added automatically even in the case that the
> > device table is absent based solely on the driver name and the
> > registration method (*module*_*platform*_driver). Why is that not the
> > case? Obviously the driver name matching the mfd_cell name is sufficient
>
> You mean add it automatically by macro-magic based on presence of
> id_table and/or of_match_table?
Yes, that plus: if id_table is present, use that for module aliases,
otherwise use driver name. In fact, I checked the platform core and it
seems to proceed in exactly this way when determining whether there is a
match. And while autoloading and probing are two different things, I
assume that we always want to consider a module for autoloading when we
know that it will probe because we have a compatible device.
> That's a good question. I cannot find answer why not, except that maybe
> no one ever wrote it...
>
>
> > for the driver to probe when it is built in so the name does seem to
> > serve as some identification for the device just as a device table entry
> > would.
> >
> > Furthermore, drivers/input/serio/ioc3kbd.c does not seem to have an ID
> > table either, nor a MODULE_ALIAS -- is that a mistake? If not, what
> > mechanism causes the driver to probe when compiled as a module? It seems
>
> You are now mixing two different things: probing of driver (so bind) and
> module auto-loading.
Yes, sorry, I meant autoloading.
> Probing is done also by driver name. Auto-loading,
> not sure, maybe by name as well?
Well probably not, otherwise it would work here too, no? Unless there
are some fundamental differences in this between PCI and platform
drivers. But the input driver is platform too and is required through
the MFD cell, so I think it should be the
Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver
Hi Mathieu,
On Fri, Mar 08, 2024 at 09:44:26AM -0700, Mathieu Poirier wrote:
> On Thu, 7 Mar 2024 at 12:40, Abdellatif El Khlifi
> wrote:
> >
> > Hi Mathieu,
> >
> > > > + do {
> > > > + state_reg = readl(priv->reset_cfg.state_reg);
> > > > + *rst_ack = EXTSYS_RST_ST_RST_ACK(state_reg);
> > > > +
> > > > + if (*rst_ack == EXTSYS_RST_ACK_RESERVED) {
> > > > + dev_err(dev, "unexpected RST_ACK value: 0x%x\n",
> > > > + *rst_ack);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + /* expected ACK value read */
> > > > + if ((*rst_ack & exp_ack) || (*rst_ack == exp_ack))
> > >
> > > I'm not sure why the second condition in this if() statement is needed.
> > > As far
> > > as I can tell the first condition will trigger and the second one won't be
> > > reached.
> >
> > The second condition takes care of the following: exp_ack and *rst_ack are
> > both 0.
> > This case happens when RST_REQ bit is cleared (meaning: No reset requested)
> > and
> > we expect the RST_ACK to be 00 afterwards.
> >
>
> This is the kind of conditions that definitely deserve documentation.
> Please split the conditions in two different if() statements and add a
> comment to explain what is going on.
Thanks, I'll address that.
>
> > > > +/**
> > > > + * arm_rproc_load() - Load firmware to memory function for rproc_ops
> > > > + * @rproc: pointer to the remote processor object
> > > > + * @fw: pointer to the firmware
> > > > + *
> > > > + * Does nothing currently.
> > > > + *
> > > > + * Return:
> > > > + *
> > > > + * 0 for success.
> > > > + */
> > > > +static int arm_rproc_load(struct rproc *rproc, const struct firmware
> > > > *fw)
> > > > +{
> > >
> > > What is the point of doing rproc_of_parse_firmware() if the firmware
> > > image is
> > > not loaded to memory? Does the remote processor have some kind of
> > > default ROM
> > > image to run if it doesn't find anything in memory?
> >
> > Yes, the remote processor has a default FW image already loaded by default.
> >
>
> That too would have mandated a comment - otherwise people looking at
> the code are left wondering, as I did.
>
> > rproc_boot() [1] and _request_firmware() [2] fail if there is no FW file in
> > the filesystem or a filename
> > provided.
> >
> > Please correct me if I'm wrong.
>
> You are correct, the remoteproc subsystem expects a firmware image to
> be provided _and_ loaded into memory. Providing a dummy image just to
> get the remote processor booted is a hack, but simply because the
> subsystem isn't tailored to handle this use case. So I am left
> wondering what the plans are for this driver, i.e is this a real
> scenario that needs to be addressed or just an initial patchset to get
> a foundation for the driver.
>
> In the former case we need to start talking about refactoring the
> subsystem so that it properly handles remote processors that don't
> need a firmware image. In the latter case I'd rather see a patchset
> where the firmware image is loaded into RAM.
This is an initial patchset for allowing to turn on and off the remote
processor.
The FW is already loaded before the Corstone-1000 SoC is powered on and this
is done through the FPGA board bootloader in case of the FPGA target. Or by the
Corstone-1000 FVP model
(emulator).
The plan for the driver is as follows:
Step 1: provide a foundation driver capable of turning the core on/off
Step 2: provide mailbox support for comms
Step 3: provide FW reload capability
Steps 2 & 3 are waiting for a HW update so the Cortex-A35 (running Linux) can
share memory with
the remote core.
I'm happy to provide more explanation in the commit log to reflect this status.
Is it OK that we go with step 1 as a foundation please ?
Cheers
Abdellatif
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
On 11/03/2024 11:26, Karel Balej wrote:
> Krzysztof Kozlowski, 2024-03-10T21:35:36+01:00:
>> 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.
>
> I think I understand the practical reasons. My point was that I would
> expect the alias to be added automatically even in the case that the
> device table is absent based solely on the driver name and the
> registration method (*module*_*platform*_driver). Why is that not the
> case? Obviously the driver name matching the mfd_cell name is sufficient
You mean add it automatically by macro-magic based on presence of
id_table and/or of_match_table?
That's a good question. I cannot find answer why not, except that maybe
no one ever wrote it...
> for the driver to probe when it is built in so the name does seem to
> serve as some identification for the device just as a device table entry
> would.
>
> Furthermore, drivers/input/serio/ioc3kbd.c does not seem to have an ID
> table either, nor a MODULE_ALIAS -- is that a mistake? If not, what
> mechanism causes the driver to probe when compiled as a module? It seems
You are now mixing two different things: probing of driver (so bind) and
module auto-loading. Probing is done also by driver name. Auto-loading,
not sure, maybe by name as well? However it is also likely that
auto-loading is broken. Several drivers had such issues in the past.
Best regards,
Krzysztof
Re: [RFC PATCH v3 4/5] input: add onkey driver for Marvell 88PM886 PMIC
Krzysztof Kozlowski, 2024-03-10T21:35:36+01:00:
> 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.
I think I understand the practical reasons. My point was that I would
expect the alias to be added automatically even in the case that the
device table is absent based solely on the driver name and the
registration method (*module*_*platform*_driver). Why is that not the
case? Obviously the driver name matching the mfd_cell name is sufficient
for the driver to probe when it is built in so the name does seem to
serve as some identification for the device just as a device table entry
would.
Furthermore, drivers/input/serio/ioc3kbd.c does not seem to have an ID
table either, nor a MODULE_ALIAS -- is that a mistake? If not, what
mechanism causes the driver to probe when compiled as a module? It seems
to me to effectively be the same setup as with my driver and that does
not load automatically (because of the missing alias).
> Just run `modinfo`.
Thank you very much,
K. B.
[PATCH] vhost: correct misleading printing information
Guest moved avail idx not used idx when we need to print log if
'(vq->avail_idx - last_avail_idx) > vq->num', so fix it.
Signed-off-by: Xianting Tian
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 045f666b4f12..1f3604c79394 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2515,7 +2515,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
- vq_err(vq, "Guest moved used index from %u to %u",
+ vq_err(vq, "Guest moved avail index from %u to %u",
last_avail_idx, vq->avail_idx);
return -EFAULT;
}
--
2.17.1
