* Re: [PATCH 2/3] dt-bindings: pinctrl: rockchip: update example
From: Linus Walleij @ 2020-05-18 7:20 UTC (permalink / raw)
To: Johan Jonker
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heiko Stübner, open list:ARM/Rockchip SoC...,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Rob Herring, Linux ARM
In-Reply-To: <20200512203524.7317-2-jbx6244@gmail.com>
On Tue, May 12, 2020 at 10:35 PM Johan Jonker <jbx6244@gmail.com> wrote:
> The Rockchip dtsi and dts files have been bulk-converted for the
> remaining raw gpio numbers into their descriptive counterparts and
> also got rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
> mappings, so update the example as well.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] include: dt-bindings: rockchip: remove unused defines
From: Linus Walleij @ 2020-05-18 7:22 UTC (permalink / raw)
To: Johan Jonker
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heiko Stübner, open list:ARM/Rockchip SoC...,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Rob Herring, Linux ARM
In-Reply-To: <20200512203524.7317-3-jbx6244@gmail.com>
On Tue, May 12, 2020 at 10:35 PM Johan Jonker <jbx6244@gmail.com> wrote:
> The Rockchip dtsi and dts files have been bulk-converted for the
> remaining raw gpio numbers into their descriptive counterparts and
> also got rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
> mappings, so remove the unused defines in 'rockchip.h' to prevent
> that someone start using them again.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
I think patch 1 & 3 needs to be applied to the Rockchip tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 1/2] dt-bindings: serial: Document CTS/RTS gpios in STM32 UART
From: Erwan LE RAY @ 2020-05-18 7:25 UTC (permalink / raw)
To: Geert Uytterhoeven, mani@kernel.org
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:SERIAL DRIVERS, Greg KH, Linux Kernel Mailing List,
Andy Shevchenko, Rob Herring, Maxime Coquelin, Fabrice GASNIER,
linux-stm32@st-md-mailman.stormreply.com, Linux ARM
In-Reply-To: <CAMuHMdVGem_2BGQK4dqZQb3sOd0LZk+RS_z4SvSRcNECEJHdwA@mail.gmail.com>
Hi Geert,
On 5/18/20 9:04 AM, Geert Uytterhoeven wrote:
> Hi Mani,
>
> On Mon, Apr 20, 2020 at 7:02 PM <mani@kernel.org> wrote:
>> From: Manivannan Sadhasivam <mani@kernel.org>
>>
>> Document the use of CTS/RTS gpios for flow control in STM32 UART
>> controller. These properties can be used instead of 'st,hw-flow-ctrl'
>> for making use of any gpio pins for flow control instead of dedicated
>> pins. It should be noted that both CTS/RTS and 'st,hw-flow-ctrl'
>> properties cannot co-exist in a design.
>>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
>> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
>> @@ -55,6 +61,14 @@ properties:
>> linux,rs485-enabled-at-boot-time: true
>> rs485-rx-during-tx: true
>>
>> +if:
>> + required:
>> + - st,hw-flow-ctrl
> Perhaps "st,hw-flow-ctrl" should be deprecated, in favor of the standard
> "uart-has-rtscts" property?
> Of course the driver needs to gain support for the latter first.
You're fully right, the patch to deprecate "st, hw-flow-ctrl" and
introduce generic "uart-has-rtscts" property in the driver is ready and
will be sent this week on top of Mani patch.
>
>> +then:
>> + properties:
>> + cts-gpios: false
>> + rts-gpios: false
>> +
>> required:
>> - compatible
>> - reg
> Gr{oetje,eeting}s,
>
> Geert
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/14] pinctrl: ocelot: Should register GPIO's even if not irq controller
From: Linus Walleij @ 2020-05-18 7:29 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, Arnd Bergmann, Stephen Boyd, Steen Hegelund,
linux-clk, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Olof Johansson, Michael Turquette, Linux ARM
In-Reply-To: <20200513125532.24585-2-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 2:56 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> This fixes the situation where the GPIO controller is not used as an
> interrupt controller as well.
>
> Previously, the driver would silently fail to register even the
> GPIO's. With this change, the driver will only register as an
> interrupt controller if a parent interrupt is provided.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/14] pinctrl: ocelot: Remove instance number from pin functions
From: Linus Walleij @ 2020-05-18 7:31 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, Arnd Bergmann, Stephen Boyd, Steen Hegelund,
linux-clk, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Olof Johansson, Michael Turquette, Linux ARM
In-Reply-To: <20200513125532.24585-3-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 2:56 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> This patch removes the instance number from the "miim", "reco_clk" and
> "sfp" pin function.
>
> The change needed is to prepare the driver for adding new platforms
> with more of these instances. The instance number is also redundant,
> as this is implicit for each pin.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 03/14] pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2
From: Linus Walleij @ 2020-05-18 7:31 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, Arnd Bergmann, Stephen Boyd, Steen Hegelund,
linux-clk, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Olof Johansson, Michael Turquette, Linux ARM
In-Reply-To: <20200513125532.24585-4-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 2:56 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> This fixes a problem with using the GPIO as an interrupt on Jaguar2
> (and similar), as the register layout of the platforms with 64 GPIO's
> are pairwise, such that the original offset must be multiplied with
> the platform stride.
>
> Fixes: da801ab56ad8 pinctrl: ocelot: add MSCC Jaguar2 support.
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/14] dt-bindings: pinctrl: ocelot: Add Sparx5 SoC support
From: Linus Walleij @ 2020-05-18 7:33 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, Arnd Bergmann, Stephen Boyd, Steen Hegelund,
linux-clk, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Rob Herring, Olof Johansson, Michael Turquette,
Linux ARM
In-Reply-To: <20200513125532.24585-8-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 2:56 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> This adds documentation for the "compatible" value designated for Sparx5
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-05-18 7:36 UTC (permalink / raw)
To: Dmitry Torokhov, Peter Hutterer
Cc: Nick Dyer, linux-iio, Benjamin Tissoires, platform-driver-x86,
ibm-acpi-devel, Laxman Dewangan, Peter Meerwald-Stadler, kernel,
Fabio Estevam, linux-samsung-soc, Krzysztof Kozlowski,
Jonathan Hunter, linux-acpi, Kukjin Kim, NXP Linux Team,
linux-input, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Sylvain Lemieux, Henrique de Moraes Holschuh,
Vladimir Zapolskiy, Lars-Peter Clausen, linux-tegra,
linux-arm-kernel, Barry Song, Ferruh Yigit, patches,
Rafael J . Wysocki, Andrzej Pietrasiewicz, Thierry Reding,
Sangwon Jee, Pengutronix Kernel Team, Hartmut Knaack, Shawn Guo,
Jonathan Cameron
In-Reply-To: <20200518024034.GL89269@dtor-ws>
Hi,
On 5/18/20 4:40 AM, Dmitry Torokhov wrote:
> Hi Hans, Peter,
>
> On Mon, May 18, 2020 at 08:55:10AM +1000, Peter Hutterer wrote:
>> On Fri, May 15, 2020 at 08:19:10PM +0200, Hans de Goede wrote:
>>> Hi Andrezj,
>>>
>>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote:
>>>> Userspace might want to implement a policy to temporarily disregard input
>>>> from certain devices, including not treating them as wakeup sources.
>>>>
>>>> An example use case is a laptop, whose keyboard can be folded under the
>>>> screen to create tablet-like experience. The user then must hold the laptop
>>>> in such a way that it is difficult to avoid pressing the keyboard keys. It
>>>> is therefore desirable to temporarily disregard input from the keyboard,
>>>> until it is folded back. This obviously is a policy which should be kept
>>>> out of the kernel, but the kernel must provide suitable means to implement
>>>> such a policy.
>>>
>>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE
>>> generating evdev nodes and e.g. internal keyboards on devices with 360°
>>> hinges for this reason. libinput simply closes the /dev/input/event#
>>> node when folded and re-opens it when the keyboard should become active
>>> again. Thus not only suppresses events but allows e.g. touchpads to
>>> enter runtime suspend mode which saves power. Typically closing the
>>> /dev/input/event# node will also disable the device as wakeup source.
>>>
>>> So I wonder what this series actually adds for functionality for
>>> userspace which can not already be achieved this way?
>>
>> Thanks Hans. To expand on this:
>> libinput has heuristics to guess which input devices (keyboards, touchpads)
>> are built-in ones. When the tablet mode switch is on, we disable these
>> devices internally (this is not visible to callers), and re-enable it again
>> later when the tablet mode switch is off again.
>
> I think that is great that libinput has tried solving this for the
> tablet mode, but unfortunately libinput only works for users of
> libinput, leaving cases such as:
>
> 1. In-kernel input handlers, such as SysRq, VT and others
> 2. Systems that do not rely on libinput for userspace handing (Android,
> Chrome OS)
> 3. Systems with policies that are more complex than tablet mode only.
>
> Because of libinput's inability to affect the kernel, and the presence
> of "always on" input handlers (sysrq, VT keyboard, potentially others),
> while libinput may control whether consumers receive events from certain
> input devices, it will not allow power savings that an explicit
> "inhibit" allows when coming from dedicated power policy manager.
Ok, the sysrq and vt keyboard handlers keeping the device open and thus
make it keep using power is a valid reason for a separate inhibit mechanism.
> I think pushing policy decisions into a library, and trying to have all
> clients agree with it, is much harder and leaks unnecessary knowledge
> into quite a few layers. A dedicated power policy manager, that is not
> only responsible for input device, but power state of the system as a
> whole, is a very viable architecture.
Well AFAIK the kernel-policy has always been to leave policy decisions
up to userspace as much as possible, but this just adds a mechanism to
implement the policy so that is fine.
>> This is done for keyboards and touchpads atm (and I think pointing sticks)
>> and where the heuristics fail we have extra quirks in place. For example
>> the Lenovo Yogas tend to disable the keyboard mechanically in tablet mode
>> but buttons (e.g. volume keys) around the screen send events through the
>> same event node. So on those devices we don't disable the keyboard.
>>
>> We've had this code for a few years now and the only changes to it have been
>> the various device quirks for devices that must not suspend the keyboard,
>> it's otherwise working as expected.
>>
>> If we ever have a device where we need to disable parts of the keyboard
>> only, we could address this with EVIOCSMASK but so far that hasn't been
>> necessary.
>>
>> I agree with Hans, right now I don't see the usefulness of this new sysfs
>> toggle. For it to be really useful you'd have to guarantee that it's
>> available for 100% of the devices and that's IMO unlikely to happen.
>
> The inhibiting of the events works for 100% of input devices, the power
> savings work for the ones that implement it. It is responsibility of
> folds shipping the systems to make sure drivers they use support inhibit
> if they believe it will help their battery life.
>
>>
>> Cheers,
>> Peter
>>
>>> I also noticed that you keep the device open (do not call the
>>> input_device's close callback) when inhibited and just throw away
>>> any events generated. This seems inefficient and may lead to
>>> the internal state getting out of sync. What if a key is pressed
>>> while inhibited and then the device is uninhibited while the key
>>> is still pressed? Now the press event is lost and userspace
>>> querying the current state will see the pressed key as being
>>> released.
>
> This is a good point. We should look into signalling that some events
> have been dropped (via EV_SYN/SYN_DROPPED) so that clients are aware of
> it.
>
>>>
>>> On top of this you add special inhibit and uninhibit callbacks
>>> and implement those for just a few devices. How do these differ
>>> from just closing the device and later opening it again ?
>
> I believe majority will simply reuse open/close callbacks. In Chrome OS
> we have dedicated inhibit/uninhibit, but I would like to allow using
> open/close as alternatives.
Ack, maybe some driver flag to just call close on inhibit and
open on unhibit (also taking input_device.users into account of course) ?
>>> Also using a sysfs property for this is very weird given that the
>>> rest of the evdev interface is using ioctls for everything...
>
> This is not evdev interface, it is at the level above evdev (so that it
> can affect all handlers, not only evdev). As such it is not bound by
> evdev interface.
Ok I can see how on some systems the process implementing the policy
of when to inhibit would be separate from the process which has the
device open. But in e.g. the libinput case it would be good if
libinput could activate any potential power-savings by setting
the inhibit flag.
The problem with sysfs interfaces is that they typically require
root rights and that they are not really compatible with FD
passing. libinput runs as a normal user, getting a fd to the
/dev/input/event# node passed by systemd-logind.
As said I can see the reason for wanting a sysfs attribute for
this, can we perhaps have both a sysfs interface and an ioctl?
Note both could share the same boolean in the kernel, it would be
up to userspace to not try and write to both. E.g. chrome-os
would use the sysfs attr, libinput would use the ioctl.
Regards,
Hans
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc, ocelot-sgpio
From: Linus Walleij @ 2020-05-18 7:40 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Rob Herring, Linux ARM
In-Reply-To: <20200513141134.25819-2-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 4:11 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> This adds DT bindings for the Microsemi SGPIO controller, bindings
> mscc,ocelot-sgpio and mscc,luton-sgpio.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> + microchip,sgpio-ports:
> + description: This is a 32-bit bitmask, configuring whether a
> + particular port in the controller is enabled or not. This allows
> + unused ports to be removed from the bitstream and reduce latency.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
I don't know about this.
You are saying this pin controller can have up to 32 GPIO "ports"
(also known as banks).
Why can't you just represent each such port as a separate GPIO
node:
pinctrl@nnn {
gpio@0 {
....
};
gpio@1 {
....
};
....
gpio@31 {
....
};
};
Then if some of them are unused just set it to status = "disabled";
This also makes your Linux driver simpler because each GPIO port
just becomes a set of 32bit registers and you can use
select GPIO_GENERIC and bgpio_init() and save a whole
slew of standard stock code.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/14] arm64: dts: sparx5: Add basic cpu support
From: Lars Povlsen @ 2020-05-18 7:43 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, Stephen Boyd,
Linus Walleij, Olof Johansson, linux-kernel,
Microchip Linux Driver Support, linux-gpio, SoC Team,
Michael Turquette, linux-arm-kernel, Marc Zyngier, Steen Hegelund,
linux-clk, Lars Povlsen
In-Reply-To: <18c0d9ef-9a2b-31d0-b317-f051bb26a907@arm.com>
Robin Murphy writes:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 2020-05-15 16:09, Lars Povlsen wrote:
> [...]
>>>> + cpu0: cpu@0 {
>>>> + compatible = "arm,cortex-a53", "arm,armv8";
>
> Side note: only one compatible string for the real CPU please, running a
> DT bindings check should complain about that.
>
I'll change this.
>>>> + device_type = "cpu";
>>>> + reg = <0x0 0x0>;
>>>> + enable-method = "spin-table";
>>>
>>> Really? This is 2020, not 2012 any more. Surely a new platform
>>> boots using PSCI, and not *this*.
>>>
>>
>> We don't currently support PSCI. The platform does not have TrustZone,
>> hence we don't use ATF.
> AIUI, part of the purpose of ATF is to provide a nice standardised
> platform interface regardless of whether you care about Secure software
> or not. It shouldn't take much to knock up a trivial ATF port that just
> uses an internal spin-table for its PSCI backend - in fact I suspect
> that's probably just a copy-paste from the RPi3 port ;)
>
I'll change this to PSCI if that's whats expected these days. We
actually already have an ATF port. I fully understand the desire to
standardize on PSCI.
> Robin.
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-18 7:35 UTC (permalink / raw)
To: Jassi Brar
Cc: Devicetree List, Arnd Bergmann, Linux Kernel Mailing List,
Bjorn Andersson, Rob Herring, Sudeep Holla, Frank Rowand,
linux-arm-kernel
In-Reply-To: <CABb+yY1wJMzakpz0h6ZxAh4Z3OB718f+Wq3RP0R4NZ_U=vRMkw@mail.gmail.com>
On 15-05-20, 11:46, Jassi Brar wrote:
> As I asked you yesterday over the call, it may help if you could share
> some numbers to back up the doomsday scenario.
Yes, I have already asked Sudeep to get some numbers for this. He will
get back to us.
> > - With the current approach it isn't possible to assign different bits
> > (or doorbell numbers) to clients from DT and the only way of doing
> > that without adding new bindings is by extending #mbox-cells to accept
> > a value of 2 as done in this patch.
> >
> I am afraid you are confused. You can use bit/doorbell-6 by passing
> 0x40 to mhu as the data to send.
That's how the code will do it, right I agree. What I was asking was
the way this information is passed from DT.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v5.8
From: Masahiro Yamada @ 2020-05-18 7:46 UTC (permalink / raw)
To: soc, Olof Johansson, Arnd Bergmann
Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Olof, Arnd,
Here are UniPhier DT (32bit) updates for the v5.8 merge window.
(I intentionally based this on -rc4
because I needed a dt-binding fix from DMA engine tree
to avoid 'make ARCH=arm dtbs_check' regression.
I hope this is OK.)
Please pull!
The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
Linux 5.7-rc4 (2020-05-03 14:56:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v5.8
for you to fetch changes up to 137a1cecb89a024f8c92d71e07e73b14fc4d4161:
ARM: dts: uniphier: add #address-cells and #size-cells to SPI nodes
(2020-05-04 10:07:22 +0900)
----------------------------------------------------------------
UniPhier ARM SoC DT updates for v5.8
- add DMA controller nodes
----------------------------------------------------------------
Kunihiko Hayashi (2):
ARM: dts: uniphier: Add XDMAC node
ARM: dts: uniphier: Add ethernet aliases
Masahiro Yamada (1):
ARM: dts: uniphier: add #address-cells and #size-cells to SPI nodes
arch/arm/boot/dts/uniphier-ld4.dtsi | 2 ++
arch/arm/boot/dts/uniphier-ld6b-ref.dts | 1 +
arch/arm/boot/dts/uniphier-pro4-ace.dts | 1 +
arch/arm/boot/dts/uniphier-pro4-ref.dts | 1 +
arch/arm/boot/dts/uniphier-pro4-sanji.dts | 1 +
arch/arm/boot/dts/uniphier-pro4.dtsi | 10 ++++++++++
arch/arm/boot/dts/uniphier-pro5.dtsi | 12 ++++++++++++
arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 1 +
arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 1 +
arch/arm/boot/dts/uniphier-pxs2.dtsi | 12 ++++++++++++
arch/arm/boot/dts/uniphier-sld8.dtsi | 2 ++
11 files changed, 44 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: dts: uniphier: UniPhier DT updates for v5.8
From: Masahiro Yamada @ 2020-05-18 7:50 UTC (permalink / raw)
To: soc, Olof Johansson, Arnd Bergmann
Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Olof, Arnd,
Here are UniPhier DT (64bit) updates for the v5.8 merge window.
(I intentionally based this on -rc4.
because I needed a dt-binding fix from DMA engine tree
to avoid 'make ARCH=arm dtbs_check' regression.
I hope this is OK.)
Please pull!
The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
Linux 5.7-rc4 (2020-05-03 14:56:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt64-v5.8
for you to fetch changes up to 7d5620d31ecc8d19f6e4ad73196955ec0bb4a507:
arm64: dts: uniphier: Add support for Akebi96 (2020-05-04 10:07:35 +0900)
----------------------------------------------------------------
UniPhier ARM64 SoC DT updates for v5.8
- add DMA controller nodes
- add Akebi96 board support
----------------------------------------------------------------
Kunihiko Hayashi (3):
arm64: dts: uniphier: Add XDMAC node
arm64: dts: uniphier: Add ethernet aliases
arm64: dts: uniphier: Stabilize Ethernet RGMII mode of PXs3 ref board
Masahiro Yamada (1):
arm64: dts: uniphier: add #address-cells and #size-cells to SPI nodes
Masami Hiramatsu (2):
dt-bindings: arm: Add Akebi96 board support
arm64: dts: uniphier: Add support for Akebi96
.../bindings/arm/socionext/uniphier.yaml | 1 +
arch/arm64/boot/dts/socionext/Makefile | 1 +
.../dts/socionext/uniphier-ld11-global.dts | 1 +
.../dts/socionext/uniphier-ld11-ref.dts | 1 +
.../boot/dts/socionext/uniphier-ld11.dtsi | 12 +
.../socionext/uniphier-ld20-akebi96.dts | 189 ++++++++++++++++
.../dts/socionext/uniphier-ld20-global.dts | 1 +
.../dts/socionext/uniphier-ld20-ref.dts | 1 +
.../boot/dts/socionext/uniphier-ld20.dtsi | 16 ++
.../dts/socionext/uniphier-pxs3-ref.dts | 18 ++
.../boot/dts/socionext/uniphier-pxs3.dtsi | 12 +
11 files changed, 253 insertions(+)
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ld20-akebi96.dts
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: kprobes: Avoid fortify_panic() when copying optprobe template
From: Andrew Jeffery @ 2020-05-18 8:10 UTC (permalink / raw)
To: Russell King
Cc: Kees Cook, linux-kernel, mathieu.desnoyers, Masami Hiramatsu,
labbott, linux-arm-kernel
In-Reply-To: <20200517160227.GU1551@shell.armlinux.org.uk>
On Mon, 18 May 2020, at 01:32, Russell King - ARM Linux admin wrote:
> On Mon, May 18, 2020 at 01:09:59AM +0930, Andrew Jeffery wrote:
> > Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads
> > to a panic in memcpy() when injecting a kprobe despite the fixes found
> > in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
> > FORTIFY_SOURCE") and commit 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes:
> > optimized kprobes illegal instruction").
> >
> > arch/arm/include/asm/kprobes.h effectively declares
> > the target type of the optprobe_template_entry assembly label as a u32,
> > which leads memcpy()'s __builtin_object_size() call to determine that
> > the pointed-to object is of size four. In practical terms the symbol is
> > used as a handle for the optimised probe assembly template that is at
> > least 96 bytes in size. The symbol's use despite its type blows up the
> > memcpy() in ARM's arch_prepare_optimized_kprobe() with a false-positive
> > fortify_panic() when it should instead copy the optimised probe template
> > into place.
> >
> > As mentioned, a couple of attempts have been made to address the issue
> > by casting a pointer to optprobe_template_entry before providing it to
> > memcpy(), however gccs such as Ubuntu 20.04's arm-linux-gnueabi-gcc
> > 9.3.0 (Ubuntu 9.3.0-10ubuntu1) see through these efforts.
> >
> > Squash the false-positive by aliasing the template assembly with a new
> > symbol 'arm_optprobe_template'; declare it as a function object and
> > pass the function object as the argument to memcpy() such that
> > __builtin_object_size() cannot immediately determine the object size.
> >
> > Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE")
> > Fixes: 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction")
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > arch/arm/include/asm/kprobes.h | 7 +++++++
> > arch/arm/probes/kprobes/opt-arm.c | 4 +++-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
> > index 213607a1f45c..94db8bf25f9c 100644
> > --- a/arch/arm/include/asm/kprobes.h
> > +++ b/arch/arm/include/asm/kprobes.h
> > @@ -43,6 +43,13 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
> > int kprobe_exceptions_notify(struct notifier_block *self,
> > unsigned long val, void *data);
> >
> > +/*
> > + * The optprobe template buffer is not anything that should be called directly,
> > + * however describe it as a function to give ourselves a handle to it that
> > + * bypasses CONFIG_FORTIFY_SOURCE=y sanity checks in memcpy().
> > + */
> > +extern __visible void arm_optprobe_template(void);
>
> Does this really need to be globally visible to anything that happens
> to include this header?
>
> While we may abhor "extern" declarations and prototypes in .c files, it
> seems to me to be entirely reasonable for this to live in opt-arm.c and
> remove the .global for this symbol, thereby making this symbol local to
> opt-arm.c
You are right, exposing it globally was unnecessary, I got caught up poking
at the other symbols. But I think we should go with Kees' patch instead.
Thanks for the quick feedback.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/20] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"
From: Sudeep Holla @ 2020-05-18 8:15 UTC (permalink / raw)
To: Andre Przywara, Lorenzo Pieralisi, Rob Herring, Liviu Dudau
Cc: Mark Rutland, Marc Zyngier, devicetree, linux-arm-kernel,
Sudeep Holla
In-Reply-To: <20200513103016.130417-1-andre.przywara@arm.com>
On Wed, 13 May 2020 11:29:56 +0100, Andre Przywara wrote:
> A few updates compared to v2. The most important is to fix the
> interrupt-maps, triggered by changing the number of address-cells in
> the GIC node. For this I split the former patch 07/17 into two (09/20
> and 10/20), one for the foundation model, the other for Juno.
> Also I fixed a dtc complaint about device nodes without reg properties
> being inside simple-bus nodes, those are the new patches 04-06/20.
> Will took patch 01/17 from v2 already, so I removed this from this
> series.
> The rest of the patches stayed the same.
> -----------------------------------
>
> [...]
Applied to sudeep.holla/linux tree (for-next/juno), thanks!
[02/20] arm64: dts: fvp/juno: Fix node address fields
https://git.kernel.org/sudeep.holla/c/bb5cce12ac
[03/20] arm64: dts: fvp: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/849bfc3dfc
[04/20] arm64: dts: vexpress: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/d9258898ad
[05/20] arm64: dts: fvp: Move fixed clocks out of bus node
https://git.kernel.org/sudeep.holla/c/feebdc3f79
[06/20] arm64: dts: juno: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/948204a1bf
[07/20] arm64: dts: juno: Fix mem-timer
https://git.kernel.org/sudeep.holla/c/0e529dae51
[08/20] arm64: dts: fvp: Fix GIC compatible names
https://git.kernel.org/sudeep.holla/c/336edacfb9
[09/20] arm64: dts: juno: Fix GIC child nodes
https://git.kernel.org/sudeep.holla/c/a78aee9e43
[10/20] arm64: dts: fvp: Fix GIC child nodes
https://git.kernel.org/sudeep.holla/c/78631aecc5
[11/20] arm64: dts: fvp: Fix ITS node names and #msi-cells
https://git.kernel.org/sudeep.holla/c/fac959c93f
[12/20] arm64: dts: juno: Use proper DT node name for USB
https://git.kernel.org/sudeep.holla/c/17a37ff76e
[13/20] arm64: dts: fvp/juno: Fix serial node names
https://git.kernel.org/sudeep.holla/c/fa51a2a1ed
[14/20] arm64: dts: fvp: Fix SMMU DT node
https://git.kernel.org/sudeep.holla/c/19650d681b
[15/20] arm64: dts: fvp/juno: Fix bus node names
https://git.kernel.org/sudeep.holla/c/b68d15c0e6
[16/20] arm64: dts: juno: Fix GPU interrupt order
https://git.kernel.org/sudeep.holla/c/2dd42335f8
[17/20] arm64: dts: vexpress: Fix VExpress LED names
https://git.kernel.org/sudeep.holla/c/bf3f0ccf35
[18/20] arm64: dts: juno: Fix SCPI shared mem node name
https://git.kernel.org/sudeep.holla/c/93f6027abe
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 8/9] arm64: dts: actions: Add MMC controller support for S700
From: André Przywara @ 2020-05-18 8:29 UTC (permalink / raw)
To: Manivannan Sadhasivam, Amit Tomer
Cc: devicetree, linux-actions, cristian.ciocaltea, Rob Herring,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20200518061755.GA25113@mani>
On 18/05/2020 07:17, Manivannan Sadhasivam wrote:
> On 0518, Amit Tomer wrote:
>> Hi,
>>
>>> I recommend reading the DT spec, chapter 2.3.1 "compatible":
>>> https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf
>>
>> My point is more about, DT validation is not happy about this situation.
>> For instance when I run dt-validate, do see following:
>>
>> /home/amit/work/kernel_work/linux/arch/arm64/boot/dts/actions/s700-cubieboard7.dt.yaml:
>> mmc@e0210000: compatible: Additional items are not allowed
>> ('actions,s700-mmc' was unexpected)
>>
>> and I am not sure if this is because DT and driver has different
>> number of compatible strings.
This has nothing to do with the driver or the actual .dts(i), that's
purely a binding issue.
> Yeah, the DT YAML validation tool doesn't allow this. And there were patches
> removing the additional compatible from DTS.
There are tons of examples of how this is done in the .yaml bindings:
properties:
compatible:
oneOf:
- const: actions,owl-mmc
- items:
- const: action,s700-mmc
- const: actions,owl-mmc
Adding more alternatives would replace the lines after items:
- enum
- action,s700-mmc
- action,s900-mmc
- const: actions,owl-mmc
> I don't know if the DT fallback is discouraged or not.
I don't know if there is an "official" statement on this, but last thing
I heard, adding SoC specific compatibles to generic fallback strings was
encouraged. Hence my proposal, to add one.
> Anyway, is enough investigation done to justify that we need SoC specific tweaks
> in the driver? I think I did look into the downstream code for s700/s500 while
> upstreaming this driver and convinced myself that the same driver could be
> reused without modifications.
It wouldn't be the first time some tiny incompatibility would be
discovered later, also there is always the chance of a hardware errata.
So better safe than sorry.
Cheers,
Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/8] iio: at91_adc: pass ref to IIO device via param for int function
From: Ardelean, Alexandru @ 2020-05-18 8:32 UTC (permalink / raw)
To: jic23@kernel.org
Cc: alexandre.belloni@bootlin.com, alexandre.torgue@st.com,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
ludovic.desroches@microchip.com, ak@it-klinger.de,
mcoquelin.stm32@gmail.com, eugen.hristev@microchip.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200516181749.243c9515@archlinux>
On Sat, 2020-05-16 at 18:17 +0100, Jonathan Cameron wrote:
> [External]
>
> On Thu, 14 May 2020 16:17:05 +0300
> Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
>
> > Since there will be some changes to how iio_priv_to_dev() is implemented,
> > it could be that the helper becomes a bit slower, as it will be hidden away
> > in the IIO core.
> >
> > For this driver, the IIO device can be passed directly as a parameter to
> > the at91_ts_sample() function, thus making it immune to the change of
> > iio_priv_to_dev().
> > The function gets called in an interrupt context.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> I wonder. Should we just pass the struct device? It's only used for
> error printing I think, so we could make that explicit.
I was also thinking that for this series, [for some drivers] it would make sense
to put a reference to indio_dev on the state-struct; and just return it.
I'll see about it.
I am feeling that sometimes these IIO core cleanups end up being more than I
want to do. But I'll try to see about it. Maybe I can make time or delegate some
of this.
My personal interest with them, is to reduce my complaints during reviews.
People starting to write IIO drivers: well, I can see their frustration [on
their faces] when I complain that they shouldn't use something, and they copied
it from somewhere.
>
> I'm not that bothered either way though.
>
> Jonathan
>
> > ---
> > drivers/iio/adc/at91_adc.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > index 0368b6dc6d60..5999defe47cd 100644
> > --- a/drivers/iio/adc/at91_adc.c
> > +++ b/drivers/iio/adc/at91_adc.c
> > @@ -287,13 +287,12 @@ static void handle_adc_eoc_trigger(int irq, struct
> > iio_dev *idev)
> > }
> > }
> >
> > -static int at91_ts_sample(struct at91_adc_state *st)
> > +static int at91_ts_sample(struct iio_dev *idev, struct at91_adc_state *st)
> > {
> > unsigned int xscale, yscale, reg, z1, z2;
> > unsigned int x, y, pres, xpos, ypos;
> > unsigned int rxp = 1;
> > unsigned int factor = 1000;
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> >
> > unsigned int xyz_mask_bits = st->res;
> > unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> > @@ -449,7 +448,7 @@ static irqreturn_t at91_adc_9x5_interrupt(int irq, void
> > *private)
> >
> > if (status & AT91_ADC_ISR_PENS) {
> > /* validate data by pen contact */
> > - at91_ts_sample(st);
> > + at91_ts_sample(idev, st);
> > } else {
> > /* triggered by event that is no pen contact, just read
> > * them to clean the interrupt and discard all.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/2] ARM: dts: imx6qdl: Use nvmem interface to get fuse data
From: Aisheng Dong @ 2020-05-18 8:44 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589418528-26410-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Thursday, May 14, 2020 9:09 AM
>
> Although ocotp clock is always ON for i.MX6QDL, OCOTP can be accessed
> directly, but since i.MX6QDL nvmem interface is supported, and
> fsl,tempmon-data is deprecated, use it instead of getting fuse data by reading
> ocotp directly, this makes all i.MX6 SoCs aligned.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] ARM: dts: imx6sl: Use nvmem interface to get fuse data
From: Aisheng Dong @ 2020-05-18 8:45 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589418528-26410-2-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Thursday, May 14, 2020 9:09 AM
>
> Although ocotp clock is always ON for i.MX6SL, OCOTP can be accessed directly,
> but since i.MX6SL nvmem interface is supported, and fsl,tempmon-data is
> deprecated, use it instead of getting fuse data by reading ocotp directly, this
> makes all i.MX6 SoCs aligned.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Lars Povlsen @ 2020-05-18 8:58 UTC (permalink / raw)
To: Adrian Hunter
Cc: devicetree, Ulf Hansson, Alexandre Belloni, linux-mmc,
linux-kernel, Microchip Linux Driver Support, SoC Team,
linux-arm-kernel, Lars Povlsen
In-Reply-To: <6398c7a6-ce5e-1df6-d5a6-08664a7fc123@intel.com>
Adrian Hunter writes:
> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>> designware IP, but requires some extra initialization and quirks.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> drivers/mmc/host/Kconfig | 13 ++
>> drivers/mmc/host/Makefile | 1 +
>> drivers/mmc/host/sdhci-of-sparx5.c | 348 +++++++++++++++++++++++++++++
>> 3 files changed, 362 insertions(+)
>> create mode 100644 drivers/mmc/host/sdhci-of-sparx5.c
>>
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index 462b5352fea75..1e8396d09df75 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -213,6 +213,19 @@ config MMC_SDHCI_OF_DWCMSHC
>> If you have a controller with this interface, say Y or M here.
>> If unsure, say N.
>>
>> +config MMC_SDHCI_OF_SPARX5
>> + tristate "SDHCI OF support for the MCHP Sparx5 SoC"
>> + depends on MMC_SDHCI_PLTFM
>> + depends on ARCH_SPARX5
>> + select MMC_SDHCI_IO_ACCESSORS
>> + help
>> + This selects the Secure Digital Host Controller Interface (SDHCI)
>> + found in the MCHP Sparx5 SoC.
>> +
>> + If you have a Sparx5 SoC with this interface, say Y or M here.
>> +
>> + If unsure, say N.
>> +
>> config MMC_SDHCI_CADENCE
>> tristate "SDHCI support for the Cadence SD/SDIO/eMMC controller"
>> depends on MMC_SDHCI_PLTFM
>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>> index b929ef9412083..9f09b7ffaaa16 100644
>> --- a/drivers/mmc/host/Makefile
>> +++ b/drivers/mmc/host/Makefile
>> @@ -89,6 +89,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
>> obj-$(CONFIG_MMC_SDHCI_OF_ASPEED) += sdhci-of-aspeed.o
>> obj-$(CONFIG_MMC_SDHCI_OF_AT91) += sdhci-of-at91.o
>> obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
>> +obj-$(CONFIG_MMC_SDHCI_OF_SPARX5) += sdhci-of-sparx5.o
>> obj-$(CONFIG_MMC_SDHCI_OF_HLWD) += sdhci-of-hlwd.o
>> obj-$(CONFIG_MMC_SDHCI_OF_DWCMSHC) += sdhci-of-dwcmshc.o
>> obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
>> diff --git a/drivers/mmc/host/sdhci-of-sparx5.c b/drivers/mmc/host/sdhci-of-sparx5.c
>> new file mode 100644
>> index 0000000000000..8253bf80e175a
>> --- /dev/null
>> +++ b/drivers/mmc/host/sdhci-of-sparx5.c
>> @@ -0,0 +1,348 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * drivers/mmc/host/sdhci-of-sparx5.c
>> + *
>> + * MCHP Sparx5 SoC Secure Digital Host Controller Interface.
>> + *
>> + * Copyright (c) 2019 Microchip Inc.
>> + *
>> + * Author: Lars Povlsen <lars.povlsen@microchip.com>
>> + */
>> +
>> +//#define DEBUG
>> +//#define TRACE_REGISTER
>
> No commented out code please.
Yes, that's not relevant any more, I'll remove it.
>
>> +
>> +#include <linux/sizes.h>
>> +#include <linux/delay.h>
>> +#include <linux/module.h>
>> +#include <linux/regmap.h>
>> +#include <linux/of_device.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/dma-mapping.h>
>> +
>> +#include "sdhci-pltfm.h"
>> +
>> +#define CPU_REGS_GENERAL_CTRL (0x22 * 4)
>> +#define MSHC_DLY_CC_MASK GENMASK(16, 13)
>> +#define MSHC_DLY_CC_SHIFT 13
>> +#define MSHC_DLY_CC_MAX 15
>> +
>> +#define CPU_REGS_PROC_CTRL (0x2C * 4)
>> +#define ACP_CACHE_FORCE_ENA BIT(4)
>> +#define ACP_AWCACHE BIT(3)
>> +#define ACP_ARCACHE BIT(2)
>> +#define ACP_CACHE_MASK (ACP_CACHE_FORCE_ENA|ACP_AWCACHE|ACP_ARCACHE)
>> +
>> +#define MSHC2_VERSION 0x500 /* Off 0x140, reg 0x0 */
>> +#define MSHC2_TYPE 0x504 /* Off 0x140, reg 0x1 */
>> +#define MSHC2_EMMC_CTRL 0x52c /* Off 0x140, reg 0xB */
>> +#define MSHC2_EMMC_CTRL_EMMC_RST_N BIT(2)
>> +#define MSHC2_EMMC_CTRL_IS_EMMC BIT(0)
>> +
>> +struct sdhci_sparx5_data {
>> + struct sdhci_host *host;
>> + struct regmap *cpu_ctrl;
>> + int delay_clock;
>> + struct device_attribute dev_delay_clock;
>> +};
>> +
>> +#define BOUNDARY_OK(addr, len) \
>> + ((addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1)))
>> +
>> +#if defined(TRACE_REGISTER)
>
> If you want this then add a Kconfig entry for it
>
No, I'll just remove it.
>> +static void sdhci_sparx5_writel(struct sdhci_host *host, u32 val, int reg)
>> +{
>> + pr_debug("$$$ writel(0x%08x, 0x%02x)\n", val, reg);
>> + writel(val, host->ioaddr + reg);
>> +}
>> +
>> +static void sdhci_sparx5_writew(struct sdhci_host *host, u16 val, int reg)
>> +{
>> + pr_debug("$$$ writew(0x%04x, 0x%02x)\n", val, reg);
>> + writew(val, host->ioaddr + reg);
>> +}
>> +
>> +static void sdhci_sparx5_writeb(struct sdhci_host *host, u8 val, int reg)
>> +{
>> + pr_debug("$$$ writeb(0x%02x, 0x%02x)\n", val, reg);
>> + writeb(val, host->ioaddr + reg);
>> +}
>> +#endif
>> +
>> +/*
>> + * If DMA addr spans 128MB boundary, we split the DMA transfer into two
>> + * so that each DMA transfer doesn't exceed the boundary.
>> + */
>> +static void sdhci_sparx5_adma_write_desc(struct sdhci_host *host, void **desc,
>> + dma_addr_t addr, int len,
>> + unsigned int cmd)
>> +{
>> + int tmplen, offset;
>> +
>> + pr_debug("write_desc: cmd %02x: len %d, offset 0x%0llx\n",
>> + cmd, len, addr);
>
> Please prefix all kernel messages by either the mmc or device e.g.
>
> pr_debug("%s: write_desc: cmd %02x: len %d, offset 0x%0llx\n",
> mmc_hostname(host->mmc), cmd, len, addr);
Will do.
>> +
>> + if (likely(!len || BOUNDARY_OK(addr, len))) {
>> + sdhci_adma_write_desc(host, desc, addr, len, cmd);
>> + return;
>> + }
>> +
>> + pr_debug("write_desc: splitting dma len %d, offset 0x%0llx\n",
>> + len, addr);
>> +
>> + offset = addr & (SZ_128M - 1);
>> + tmplen = SZ_128M - offset;
>> + sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
>> +
>> + addr += tmplen;
>> + len -= tmplen;
>> + sdhci_adma_write_desc(host, desc, addr, len, cmd);
>> +}
>> +
>> +static void sparx5_set_cacheable(struct sdhci_host *host, u32 value)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_sparx5_data *sdhci_sparx5 = sdhci_pltfm_priv(pltfm_host);
>> +
>> + pr_debug("%s: Set Cacheable = 0x%x\n", mmc_hostname(host->mmc), value);
>> +
>> + /* Update ACP caching attributes in HW */
>> + regmap_update_bits(sdhci_sparx5->cpu_ctrl,
>> + CPU_REGS_PROC_CTRL, ACP_CACHE_MASK, value);
>> +}
>> +
>> +static void sparx5_set_delay(struct sdhci_host *host, u8 value)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_sparx5_data *sdhci_sparx5 = sdhci_pltfm_priv(pltfm_host);
>> +
>> + pr_debug("%s: Set DLY_CC = %u\n", mmc_hostname(host->mmc), value);
>> +
>> + /* Update DLY_CC in HW */
>> + regmap_update_bits(sdhci_sparx5->cpu_ctrl,
>> + CPU_REGS_GENERAL_CTRL,
>> + MSHC_DLY_CC_MASK,
>> + (value << MSHC_DLY_CC_SHIFT));
>> +}
>> +
>> +static void sdhci_sparx5_set_emmc(struct sdhci_host *host)
>> +{
>> + if (!mmc_card_is_removable(host->mmc)) {
>> + u8 value;
>> +
>> + value = sdhci_readb(host, MSHC2_EMMC_CTRL);
>> + if (!(value & MSHC2_EMMC_CTRL_IS_EMMC)) {
>> + pr_debug("Get EMMC_CTRL: 0x%08x\n", value);
>> + value |= MSHC2_EMMC_CTRL_IS_EMMC;
>> + pr_debug("Set EMMC_CTRL: 0x%08x\n", value);
>> + sdhci_writeb(host, value, MSHC2_EMMC_CTRL);
>> + }
>> + }
>> +}
>> +
>> +static void sdhci_sparx5_reset_emmc(struct sdhci_host *host)
>> +{
>> + u8 value;
>> +
>> + pr_debug("Toggle EMMC_CTRL.EMMC_RST_N\n");
>> + value = sdhci_readb(host, MSHC2_EMMC_CTRL) &
>> + ~MSHC2_EMMC_CTRL_EMMC_RST_N;
>> + sdhci_writeb(host, value, MSHC2_EMMC_CTRL);
>> + /* For eMMC, minimum is 1us but give it 10us for good measure */
>> + udelay(10);
>> + sdhci_writeb(host, value | MSHC2_EMMC_CTRL_EMMC_RST_N,
>> + MSHC2_EMMC_CTRL);
>> + /* For eMMC, minimum is 200us but give it 300us for good measure */
>> + udelay(300);
>
> usleep_range() is better here
>
Got it.
>> +}
>> +
>> +static void sdhci_sparx5_reset(struct sdhci_host *host, u8 mask)
>> +{
>> + pr_debug("*** RESET: mask %d\n", mask);
>> +
>> + sdhci_reset(host, mask);
>> +
>> + /* Be sure CARD_IS_EMMC stays set */
>> + sdhci_sparx5_set_emmc(host);
>> +}
>> +
>> +static const struct sdhci_ops sdhci_sparx5_ops = {
>> +#if defined(TRACE_REGISTER)
>> + .write_l = sdhci_sparx5_writel,
>> + .write_w = sdhci_sparx5_writew,
>> + .write_b = sdhci_sparx5_writeb,
>> +#endif
>> + .set_clock = sdhci_set_clock,
>> + .set_bus_width = sdhci_set_bus_width,
>> + .set_uhs_signaling = sdhci_set_uhs_signaling,
>> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
>> + .reset = sdhci_sparx5_reset,
>> + .adma_write_desc = sdhci_sparx5_adma_write_desc,
>> +};
>> +
>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>> + .quirks = 0,
>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>
> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
Yes, its supposedly a card quirk. I'll see to use the card quirks
methods in place.
>
>> + SDHCI_QUIRK2_NO_1_8_V, /* No sdr104, ddr50, etc */
>> + .ops = &sdhci_sparx5_ops,
>> +};
>> +
>> +static ssize_t sparx5_delay_clock_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct sdhci_sparx5_data *sdhci_sparx5;
>> +
>> + sdhci_sparx5 = container_of(attr, struct sdhci_sparx5_data,
>> + dev_delay_clock);
>> + return scnprintf(buf, PAGE_SIZE, "%d\n", sdhci_sparx5->delay_clock);
>> +}
>> +
>> +static ssize_t sparx5_delay_clock_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + unsigned int delay_clock;
>> + struct sdhci_sparx5_data *sdhci_sparx5;
>> +
>> + sdhci_sparx5 = container_of(attr, struct sdhci_sparx5_data,
>> + dev_delay_clock);
>> +
>> + if (kstrtoint(buf, 10, &delay_clock) ||
>> + delay_clock > MSHC_DLY_CC_MAX) {
>> + dev_err(dev, "sdhci-of-sparx5: wrong parameter format.\n");
>> + return -EINVAL;
>> + }
>> +
>> + sdhci_sparx5->delay_clock = delay_clock;
>> + sparx5_set_delay(sdhci_sparx5->host, sdhci_sparx5->delay_clock);
>> +
>> + return strlen(buf);
>> +}
>> +
>> +int sdhci_sparx5_probe(struct platform_device *pdev)
>> +{
>> + int ret;
>> + const char *syscon = "microchip,sparx5-cpu-syscon";
>> + struct sdhci_host *host;
>> + struct sdhci_pltfm_host *pltfm_host;
>> + struct sdhci_sparx5_data *sdhci_sparx5;
>> + struct device_node *np = pdev->dev.of_node;
>> + u32 value;
>> + u32 extra;
>> +
>> + host = sdhci_pltfm_init(pdev, &sdhci_sparx5_pdata,
>> + sizeof(*sdhci_sparx5));
>> +
>> + if (IS_ERR(host))
>> + return PTR_ERR(host);
>> +
>> + /*
>> + * extra adma table cnt for cross 128M boundary handling.
>> + */
>> + extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev), SZ_128M);
>> + if (extra > SDHCI_MAX_SEGS)
>> + extra = SDHCI_MAX_SEGS;
>> + host->adma_table_cnt += extra;
>> +
>> + pltfm_host = sdhci_priv(host);
>> + sdhci_sparx5 = sdhci_pltfm_priv(pltfm_host);
>> + sdhci_sparx5->host = host;
>> +
>> + pltfm_host->clk = devm_clk_get(&pdev->dev, "core");
>> + if (IS_ERR(pltfm_host->clk)) {
>> + ret = PTR_ERR(pltfm_host->clk);
>> + dev_err(&pdev->dev, "failed to get core clk: %d\n", ret);
>> + goto free_pltfm;
>> + }
>> + ret = clk_prepare_enable(pltfm_host->clk);
>> + if (ret)
>> + goto free_pltfm;
>> +
>> + if (!of_property_read_u32(np, "microchip,clock-delay", &value) &&
>> + value <= MSHC_DLY_CC_MAX)
>> + sdhci_sparx5->delay_clock = value;
>> + else
>> + sdhci_sparx5->delay_clock = -1; /* Autotune */
>> +
>> + /* Sysfs delay_clock interface */
>> + sdhci_sparx5->dev_delay_clock.show = sparx5_delay_clock_show;
>> + sdhci_sparx5->dev_delay_clock.store = sparx5_delay_clock_store;
>> + sysfs_attr_init(&sdhci_sparx5->dev_delay_clock.attr);
>> + sdhci_sparx5->dev_delay_clock.attr.name = "delay_clock";
>> + sdhci_sparx5->dev_delay_clock.attr.mode = 0644;
>> + ret = device_create_file(&pdev->dev, &sdhci_sparx5->dev_delay_clock);
>
> Why is this needed? It seems doubtful that user space knows what value to
> put here if neither the board information nor the driver have that information.
The interface was provided to do tuning with a scope attached. As it is
not a requirement, I'll remove it.
>
>> + if (ret)
>> + dev_err(&pdev->dev, "failure creating '%s' device file",
>> + sdhci_sparx5->dev_delay_clock.attr.name);
>> +
>> + sdhci_get_of_property(pdev);
>> +
>> + ret = mmc_of_parse(host->mmc);
>> + if (ret)
>> + goto err_clk;
>> +
>> + sdhci_sparx5->cpu_ctrl = syscon_regmap_lookup_by_compatible(syscon);
>> + if (IS_ERR(sdhci_sparx5->cpu_ctrl)) {
>> + dev_err(&pdev->dev, "No CPU syscon regmap !\n");
>> + ret = PTR_ERR(sdhci_sparx5->cpu_ctrl);
>> + goto err_clk;
>> + }
>> +
>> + if (sdhci_sparx5->delay_clock >= 0)
>> + sparx5_set_delay(host, sdhci_sparx5->delay_clock);
>> +
>> + if (!mmc_card_is_removable(host->mmc)) {
>> + /* Do a HW reset of eMMC card */
>> + sdhci_sparx5_reset_emmc(host);
>> + /* Update EMMC_CTRL */
>> + sdhci_sparx5_set_emmc(host);
>> + /* If eMMC, disable SD and SDIO */
>> + host->mmc->caps2 |= (MMC_CAP2_NO_SDIO|MMC_CAP2_NO_SD);
>> + }
>> +
>> + /* Enable v4 mode */
>> + //sdhci_enable_v4_mode(host);
>
> No commented out code please.
I'll remove this.
>
>> +
>> + ret = sdhci_add_host(host);
>> + if (ret)
>> + dev_err(&pdev->dev, "sdhci_add_host() failed (%d)\n", ret);
>> +
>> + /* Set AXI bus master to use un-cached access (for DMA) */
>> + if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA) &&
>> + IS_ENABLED(CONFIG_DMA_DECLARE_COHERENT))
>> + sparx5_set_cacheable(host, ACP_CACHE_FORCE_ENA);
>> +
>> + pr_debug("SDHC version: 0x%08x\n", sdhci_readl(host, MSHC2_VERSION));
>> + pr_debug("SDHC type: 0x%08x\n", sdhci_readl(host, MSHC2_TYPE));
>> +
>> + return ret;
>> +
>> +err_clk:
>> + clk_disable_unprepare(pltfm_host->clk);
>> +free_pltfm:
>> + sdhci_pltfm_free(pdev);
>> + return ret;
>> +}
>> +
>> +static const struct of_device_id sdhci_sparx5_of_match[] = {
>> + { .compatible = "microchip,dw-sparx5-sdhci" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, sdhci_sparx5_of_match);
>> +
>> +static struct platform_driver sdhci_sparx5_driver = {
>> + .driver = {
>> + .name = "sdhci-sparx5",
>> + .of_match_table = sdhci_sparx5_of_match,
>> + .pm = &sdhci_pltfm_pmops,
>> + },
>> + .probe = sdhci_sparx5_probe,
>> + .remove = sdhci_pltfm_unregister,
>> +};
>> +
>> +module_platform_driver(sdhci_sparx5_driver);
>> +
>> +MODULE_DESCRIPTION("Sparx5 SDHCI OF driver");
>> +MODULE_AUTHOR("Lars Povlsen <lars.povlsen@microchip.com>");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.26.2
>>
Thank you very much for your comments, I will make the suggested changes
and submit an new series asap.
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] dt-bindings: reset: Convert i.MX reset to json-schema
From: Aisheng Dong @ 2020-05-18 9:07 UTC (permalink / raw)
To: Anson Huang, p.zabel@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589250194-29441-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Tuesday, May 12, 2020 10:23 AM
>
> Convert the i.MX reset binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/reset/fsl,imx-src.txt | 49 ------------------
> .../devicetree/bindings/reset/fsl,imx-src.yaml | 58
> ++++++++++++++++++++++
> 2 files changed, 58 insertions(+), 49 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> create mode 100644
> Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> deleted file mode 100644
> index 6ed79e6..0000000
> --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -Freescale i.MX System Reset Controller
> -======================================
> -
> -Please also refer to reset.txt in this directory for common reset -controller
> binding usage.
> -
> -Required properties:
> -- compatible: Should be "fsl,<chip>-src"
> -- reg: should be register base and length as documented in the
> - datasheet
> -- interrupts: Should contain SRC interrupt and CPU WDOG interrupt,
> - in this order.
> -- #reset-cells: 1, see below
> -
> -example:
> -
> -src: src@20d8000 {
> - compatible = "fsl,imx6q-src";
> - reg = <0x020d8000 0x4000>;
> - interrupts = <0 91 0x04 0 96 0x04>;
> - #reset-cells = <1>;
> -};
> -
> -Specifying reset lines connected to IP modules
> -==============================================
> -
> -The system reset controller can be used to reset the GPU, VPU, -IPU, and
> OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device -nodes should
> specify the reset line on the SRC in their resets -property, containing a phandle
> to the SRC device node and a -RESET_INDEX specifying which module to reset,
> as described in -reset.txt
> -
> -example:
> -
> - ipu1: ipu@2400000 {
> - resets = <&src 2>;
> - };
> - ipu2: ipu@2800000 {
> - resets = <&src 4>;
> - };
> -
> -The following RESET_INDEX values are valid for i.MX5:
> -GPU_RESET 0
> -VPU_RESET 1
> -IPU1_RESET 2
> -OPEN_VG_RESET 3
> -The following additional RESET_INDEX value is valid for i.MX6:
> -IPU2_RESET 4
> diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
> b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
> new file mode 100644
> index 0000000..276a533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +title: Freescale i.MX System Reset Controller
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +description: |
> + The system reset controller can be used to reset the GPU, VPU,
> + IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device
> + nodes should specify the reset line on the SRC in their resets
> + property, containing a phandle to the SRC device node and a
> + RESET_INDEX specifying which module to reset, as described in
> + reset.txt
> +
> + The following RESET_INDEX values are valid for i.MX5:
> + GPU_RESET 0
> + VPU_RESET 1
> + IPU1_RESET 2
> + OPEN_VG_RESET 3
> + The following additional RESET_INDEX value is valid for i.MX6:
> + IPU2_RESET 4
> +
> +properties:
> + compatible:
> + items:
> + - const: "fsl,imx51-src"
What about mx6?
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
Need description here
> + minItems: 1
> + maxItems: 2
> +
> + '#reset-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + src@73fd0000 {
s/src/reset-controller
Regards
Aisheng
> + compatible = "fsl,imx51-src";
> + reg = <0x73fd0000 0x4000>;
> + interrupts = <75>;
> + #reset-cells = <1>;
> + };
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/2] ARM: dts: imx51: Add src node interrupt
From: Aisheng Dong @ 2020-05-18 9:09 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589250307-29662-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Tuesday, May 12, 2020 10:25 AM
>
> Interrupt is a required property according to SRC binding, add it for SRC node.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
> ---
> arch/arm/boot/dts/imx51.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index
> 92fbb90..3f1e913 100644
> --- a/arch/arm/boot/dts/imx51.dtsi
> +++ b/arch/arm/boot/dts/imx51.dtsi
> @@ -442,6 +442,7 @@
> src: src@73fd0000 {
> compatible = "fsl,imx51-src";
> reg = <0x73fd0000 0x4000>;
> + interrupts = <75>;
> #reset-cells = <1>;
> };
>
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] ARM: dts: imx53: Add src node interrupt
From: Aisheng Dong @ 2020-05-18 9:10 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589250307-29662-2-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Tuesday, May 12, 2020 10:25 AM
>
> Interrupt is a required property according to SRC binding, add it for SRC node.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
> ---
> arch/arm/boot/dts/imx53.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi index
> 8536f59..0d06dbd 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -591,6 +591,7 @@
> src: src@53fd0000 {
> compatible = "fsl,imx53-src", "fsl,imx51-src";
> reg = <0x53fd0000 0x4000>;
> + interrupts = <75>;
> #reset-cells = <1>;
> };
>
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-18 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel, Steven Price, harb, Sudeep Holla, Will Deacon
Hi,
This patch series adds support for SMCCCv1.2 ARCH_SOC_ID.
This doesn't add other changes added in SMCCC v1.2 yet. They will
follow these soon along with its first user SPCI/PSA-FF.
This is tested using upstream TF-A + the patch[3] fixing the original
implementation there.
v1[0]->v2[1]:
- Incorporated comments from Steven Price in patch 5/5
- Fixed build for CONFIG_PSCI_FW=n on some arm32 platforms
- Added Steven Price's review tags
v2[1]->v3[2]:
- Incorporated additional comments from Steven Price in patch 5/5
and added his review tags
- Refactored SMCCC code from PSCI and moved it under
drivers/firmware/smccc/smccc.c
- Also moved soc_id.c under drivers/firmware/smccc
v3[2]->v4:
- Incorporated all the review comments from Mark R
Regards,
Sudeep
[0] https://lore.kernel.org/r/20200430114814.14116-1-sudeep.holla@arm.com/
[1] https://lore.kernel.org/r/20200504092905.10580-1-sudeep.holla@arm.com/
[2] https://lore.kernel.org/r/20200506164411.3284-1-sudeep.holla@arm.com/
[3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4002
Sudeep Holla (7):
firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
firmware: smccc: Update link to latest SMCCC specification
firmware: smccc: Add the definition for SMCCCv1.2 version/error codes
firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead
firmware: smccc: Refactor SMCCC specific bits into separate file
firmware: smccc: Add function to fetch SMCCC version
firmware: smccc: Add ARCH_SOC_ID support
MAINTAINERS | 9 ++
arch/arm64/kernel/paravirt.c | 2 +-
drivers/firmware/Kconfig | 6 +-
drivers/firmware/Makefile | 3 +-
drivers/firmware/psci/psci.c | 22 ++---
drivers/firmware/smccc/Kconfig | 25 ++++++
drivers/firmware/smccc/Makefile | 4 +
drivers/firmware/smccc/smccc.c | 31 +++++++
drivers/firmware/smccc/soc_id.c | 151 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 27 +++++-
include/linux/psci.h | 7 --
11 files changed, 256 insertions(+), 31 deletions(-)
create mode 100644 drivers/firmware/smccc/Kconfig
create mode 100644 drivers/firmware/smccc/Makefile
create mode 100644 drivers/firmware/smccc/smccc.c
create mode 100644 drivers/firmware/smccc/soc_id.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
From: Sudeep Holla @ 2020-05-18 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel, Steven Price, harb, Sudeep Holla, Will Deacon
In-Reply-To: <20200518091222.27467-1-sudeep.holla@arm.com>
SMCCC v1.0 lacked discoverability of version and features. To accelerate
adoption of few mitigations and protect systems more rapidly from various
vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism
though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION)
which returns success on firmware compliant to SMCCC v1.1 and above.
This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for
backward compatibility. Let us introduce a new hidden config for the
same to build more features on top of SMCCC v1.1 and above.
While at it, also sort alphabetically the psci entry.
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/Kconfig | 6 ++----
drivers/firmware/smccc/Kconfig | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 4 deletions(-)
create mode 100644 drivers/firmware/smccc/Kconfig
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 8007d4aa76dc..4843e94713a4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -295,15 +295,13 @@ config TURRIS_MOX_RWTM
other manufacturing data and also utilize the Entropy Bit Generator
for hardware random number generation.
-config HAVE_ARM_SMCCC
- bool
-
-source "drivers/firmware/psci/Kconfig"
source "drivers/firmware/broadcom/Kconfig"
source "drivers/firmware/google/Kconfig"
source "drivers/firmware/efi/Kconfig"
source "drivers/firmware/imx/Kconfig"
source "drivers/firmware/meson/Kconfig"
+source "drivers/firmware/psci/Kconfig"
+source "drivers/firmware/smccc/Kconfig"
source "drivers/firmware/tegra/Kconfig"
source "drivers/firmware/xilinx/Kconfig"
diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
new file mode 100644
index 000000000000..27b675d76235
--- /dev/null
+++ b/drivers/firmware/smccc/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config HAVE_ARM_SMCCC
+ bool
+ help
+ Include support for the Secure Monitor Call (SMC) and Hypervisor
+ Call (HVC) instructions on Armv7 and above architectures.
+
+config HAVE_ARM_SMCCC_DISCOVERY
+ bool
+ depends on ARM_PSCI_FW
+ default y
+ help
+ SMCCC v1.0 lacked discoverability and hence PSCI v1.0 was updated
+ to add SMCCC discovery mechanism though the PSCI firmware
+ implementation of PSCI_FEATURES(SMCCC_VERSION) which returns
+ success on firmware compliant to SMCCC v1.1 and above.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox