* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-12 16:39 UTC (permalink / raw)
To: Andrew F. Davis, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <92dc4403-8782-8dbf-b912-cc832ac748a7@ti.com>
On 8/12/19 11:36 AM, Andrew F. Davis wrote:
> On 8/12/19 12:28 PM, Suman Anna wrote:
>> On 8/12/19 10:47 AM, Andrew F. Davis wrote:
>>> On 10/23/18 9:19 PM, Suman Anna wrote:
>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>> printing the vring buffer address. This prints only a hashed
>>>> pointer even for previliged users. Use "%pK" instead so that
>>>> the address can be printed during debug using kptr_restrict
>>>> sysctl.
>>>>
>>>
>>>
>>> s/previliged/privileged
>>
>> Bjorn,
>> Can you fix this up when applying.
>>
>>>
>>> You describe what the code does, but not why you need this. %pK is used
>>> for only about 1% of pointer printing, why do you want to leak this
>>> address to userspace at all?
>>
>> Andrew,
>> Default behavior of %pK is same as %p, but it does allow you to control
>> the print. The reason is clearly mentioned in the last sentence in the
>> patch description.
>>
>
>
> Let me rephrase then, why would you ever set 'kptr_restrict' to anything
> other than 0, or why do you want to be able to leak this address to
> userspace at all? If the answer is just because you can, then all 12,000
> instances of %p in kernel could be converted for the same reason.
It is a dev_dbg statement, so it is already under dynamic debug control.
We would only ever use it during debug.
regards
Suman
>
> Andrew
>
>
>> regards
>> Suman
>>
>>>
>>> Andrew
>>>
>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> ---
>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> index f29dee731026..1345f373a1a0 100644
>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>> goto vqs_del;
>>>> }
>>>>
>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>>> bufs_va, &vrp->bufs_dma);
>>>>
>>>> /* half of the buffers is dedicated for RX */
>>>>
>>
_______________________________________________
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] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Andrew F. Davis @ 2019-08-12 16:36 UTC (permalink / raw)
To: Suman Anna, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <2ef5e274-df09-c3a0-41ed-a945d1902eaf@ti.com>
On 8/12/19 12:28 PM, Suman Anna wrote:
> On 8/12/19 10:47 AM, Andrew F. Davis wrote:
>> On 10/23/18 9:19 PM, Suman Anna wrote:
>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>> printing the vring buffer address. This prints only a hashed
>>> pointer even for previliged users. Use "%pK" instead so that
>>> the address can be printed during debug using kptr_restrict
>>> sysctl.
>>>
>>
>>
>> s/previliged/privileged
>
> Bjorn,
> Can you fix this up when applying.
>
>>
>> You describe what the code does, but not why you need this. %pK is used
>> for only about 1% of pointer printing, why do you want to leak this
>> address to userspace at all?
>
> Andrew,
> Default behavior of %pK is same as %p, but it does allow you to control
> the print. The reason is clearly mentioned in the last sentence in the
> patch description.
>
Let me rephrase then, why would you ever set 'kptr_restrict' to anything
other than 0, or why do you want to be able to leak this address to
userspace at all? If the answer is just because you can, then all 12,000
instances of %p in kernel could be converted for the same reason.
Andrew
> regards
> Suman
>
>>
>> Andrew
>>
>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> index f29dee731026..1345f373a1a0 100644
>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>> goto vqs_del;
>>> }
>>>
>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>> bufs_va, &vrp->bufs_dma);
>>>
>>> /* half of the buffers is dedicated for RX */
>>>
>
_______________________________________________
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: ep93xx: Mark expected switch fall-through
From: Alexander Sverdlin @ 2019-08-12 16:30 UTC (permalink / raw)
To: Gustavo A. R. Silva, Hartley Sweeten, Russell King
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190808023811.GA14001@embeddedor>
Hi!
On 08/08/2019 04:38, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> Fix the following warnings (Building: arm-ep93xx_defconfig arm):
>
> arch/arm/mach-ep93xx/crunch.c: In function 'crunch_do':
> arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may
> fall through [-Wimplicit-fallthrough=]
> memset(crunch_state, 0, sizeof(*crunch_state));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/arm/mach-ep93xx/crunch.c:53:2: note: here
> case THREAD_NOTIFY_EXIT:
> ^~~~
>
> Notice that, in this particular case, the code comment is
> modified in accordance with what GCC is expecting to find.
>
> Reported-by: kbuild test robot <lkp@intel.com>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> arch/arm/mach-ep93xx/crunch.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-ep93xx/crunch.c b/arch/arm/mach-ep93xx/crunch.c
> index 1c9a4be8b503..1c05c5bf7e5c 100644
> --- a/arch/arm/mach-ep93xx/crunch.c
> +++ b/arch/arm/mach-ep93xx/crunch.c
> @@ -49,6 +49,7 @@ static int crunch_do(struct notifier_block *self, unsigned long cmd, void *t)
> * FALLTHROUGH: Ensure we don't try to overwrite our newly
> * initialised state information on the first fault.
> */
> + /* Fall through */
>
> case THREAD_NOTIFY_EXIT:
> crunch_task_release(thread);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: marvell: armada-37xx: add mailbox node
From: Marek Behún @ 2019-08-12 16:30 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Gregory Clement, Miquel Raynal, Marek Behún
This adds the rWTM BIU mailbox node for communication with the secure
processor. The driver already exists in
drivers/mailbox/armada-37xx-rwtm-mailbox.c.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index f43c43168b00..7f69e3dfcb13 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -419,6 +419,13 @@
clocks = <&nb_periph_clk 15>;
};
+ rwtm: mailbox@b0000 {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb0000 0x100>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
+
sdhci1: sdhci@d0000 {
compatible = "marvell,armada-3700-sdhci",
"marvell,sdhci-xenon";
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-12 16:28 UTC (permalink / raw)
To: Andrew F. Davis, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <1cc3d697-6fde-901b-2e35-2e2b53b44425@ti.com>
On 8/12/19 10:47 AM, Andrew F. Davis wrote:
> On 10/23/18 9:19 PM, Suman Anna wrote:
>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>> printing the vring buffer address. This prints only a hashed
>> pointer even for previliged users. Use "%pK" instead so that
>> the address can be printed during debug using kptr_restrict
>> sysctl.
>>
>
>
> s/previliged/privileged
Bjorn,
Can you fix this up when applying.
>
> You describe what the code does, but not why you need this. %pK is used
> for only about 1% of pointer printing, why do you want to leak this
> address to userspace at all?
Andrew,
Default behavior of %pK is same as %p, but it does allow you to control
the print. The reason is clearly mentioned in the last sentence in the
patch description.
regards
Suman
>
> Andrew
>
>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>> index f29dee731026..1345f373a1a0 100644
>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>> goto vqs_del;
>> }
>>
>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>> bufs_va, &vrp->bufs_dma);
>>
>> /* half of the buffers is dedicated for RX */
>>
_______________________________________________
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] i.MX fixes for 5.3, round 2
From: Shawn Guo @ 2019-08-12 16:00 UTC (permalink / raw)
To: soc, arm
Cc: Stefan Agner, Li Yang, linux-imx, kernel, Fabio Estevam,
linux-arm-kernel
The following changes since commit 8d0148473dece51675d11dd59b8db5fe4b5d2e7e:
arm64: dts: imx8mq: fix SAI compatible (2019-07-23 15:37:31 +0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-5.3-2
for you to fetch changes up to a5580eb394c8a48afc3e64aaad68db0d44662cc6:
ARM: dts: vf610-bk4: Fix qspi node description (2019-08-03 17:53:24 +0200)
----------------------------------------------------------------
i.MX fixes for 5.3, round 2:
- A fix on vf610-bk4 board qspi device description to get SPI-NOR
memory recognized correctly.
----------------------------------------------------------------
Lukasz Majewski (1):
ARM: dts: vf610-bk4: Fix qspi node description
arch/arm/boot/dts/vf610-bk4.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
_______________________________________________
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 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree
From: Shawn Guo @ 2019-08-12 15:54 UTC (permalink / raw)
To: Aisheng Dong
Cc: devicetree, Dong Aisheng, sboyd@kernel.org, Michael Turquette,
Rob Herring, dl-linux-imx, Sascha Hauer, Fabio Estevam, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <AM0PR04MB42117575E82B4B762FE2143880D30@AM0PR04MB4211.eurprd04.prod.outlook.com>
On Mon, Aug 12, 2019 at 02:41:55PM +0000, Aisheng Dong wrote:
> > From: Shawn Guo <shawnguo@kernel.org>
> > Sent: Monday, August 12, 2019 9:01 PM
> > On Mon, Aug 05, 2019 at 11:27:20AM +0800, Dong Aisheng wrote:
> > > > > +- compatible: Should be one of:
> > > > > + "fsl,imx8qxp-lpcg"
> > > > > + "fsl,imx8qm-lpcg" followed by
> > "fsl,imx8qxp-lpcg".
> > > > > +- reg: Address and length of the register set.
> > > > > +- #clock-cells: Should be 1. One LPCG supports multiple
> > clocks.
> > > > > +- clocks: Input parent clocks phandle array for each clock.
> > > > > +- bit-offset: An integer array indicating the bit offset
> > for each clock.
> > > >
> > > > I guess that the driver should be able to figure bit offset from
> > > > 'clock-indices' property.
> > > >
> > >
> > > Yes, it can be done in theory.
> > > Then the binding may look like:
> > > sdhc0_lpcg: clock-controller@5b200000 {
> > > ...
> > > #clock-cells = <1>;
> > > clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
> > > <&conn_ipg_clk>, <&conn_axi_clk>;
> > > clock-indices = <0>, <16>, <20>;
> > > clock-output-names = "sdhc0_lpcg_per_clk",
> > > "sdhc0_lpcg_ipg_clk",
> > > "sdhc0_lpcg_ahb_clk";
> > > power-domains = <&pd IMX_SC_R_SDHC_0>; };
> > >
> > > usdhc1: mmc@5b010000 {
> > > ...
> > > clocks = <&sdhc0_lpcg 16>,
> > > <&sdhc0_lpcg 0>,
> > > <&sdhc0_lpcg 20>;
> > > clock-names = "ipg", "per", "ahb"; };
> > >
> > > However, after trying, i found one limitation if using clock-indices
> > > that users have to do a secondary search for the indices value from
> > > clock names which is not very friendly.
> > >
> > > Formerly from the clock output names, user can easily get the clock
> > > index as they're in fixed orders as output names, so very easily to
> > > use.
> > > e.g.
> > > clocks = <&sdhc0_lpcg 1>,
> > > <&sdhc0_lpcg 0>,
> > > <&sdhc0_lpcg 2>;
> > >
> > > If using clock-indices, users have no way to know it's clock index
> > > from clock output names order unless they do a secondary search from
> > > the clock-indice array accordingly.
> > > For example, for "sdhc0_lpcg_ahb_clk", user can easily know its
> > > reference is <&sdhc0_lpcg 2>.
> > > But if using clock-indice, we need search clock-indices array to find
> > > its reference becomes <&sdhc0_lpcg 20>. So this seems like a drawback
> > > if using clock-indices.
> >
> > Shouldn't we have constant macro defined for those numbers, so that both
> > 'clock-indices' and 'clocks' of client device can use?
> >
>
> I think we can do it.
> Does below one look ok to you?
> #define IMX_LPCG_ CLK_0 0
> #define IMX_LPCG_ CLK_1 4
> #define IMX_LPCG_ CLK_2 8
> #define IMX_LPCG_ CLK_3 12
> #define IMX_LPCG_ CLK_4 16
> #define IMX_LPCG_ CLK_5 20
> #define IMX_LPCG_ CLK_6 24
> #define IMX_LPCG_ CLK_7 28
Looks fine to me, except the space in the middle of macro name, which
compiler will complain anyway :)
Shawn
>
> The usage will look like:
> <&sdhc0_lpcg IMX_LPCG_CLK_5>
_______________________________________________
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] at91/dt: ariettag25: style cleanup
From: Nicolas.Ferre @ 2019-08-12 15:47 UTC (permalink / raw)
To: uwe, alexandre.belloni, mark.rutland, devicetree, robh+dt,
linux-arm-kernel
In-Reply-To: <20190801082622.hma5ejifj6i2a2jv@M43218.corp.atmel.com>
On 01/08/2019 at 10:26, Ludovic Desroches wrote:
> On Thu, Aug 01, 2019 at 12:00:45AM +0200, Uwe Kleine-König wrote:
>>
>> - newline between properties and sub-nodes
>> - use tags from included dtsi instead of duplicating the hierarchy
>> - status should be the last property
>> - drop duplicated alias
>>
>> There are no differences in the generated .dtb
>>
>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
>
>> ---
>> Hello,
>>
>> these are the style rules I was teached when modifying imx dts files.
>> Do they apply to at91, too?
>
> Hello Uwe,
>
> It's okay for me, we had no guidelines at the beginning, that explain
> some inconsistency among our dt files. We tend to follow these rules
> excepted the use of labels.
>
> I would like to be sure that Nicolas and Alexandre are on the same
> wavelength than me.
After I had been reluctant to use them (another syntax to learn in
addition to learning DT, remember, back in the days...), I'm now okay to
use labels as they are so convenient and widely used.
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Uwe! Best regards,
Nicolas
>> arch/arm/boot/dts/at91-ariettag25.dts | 87 +++++++++++++--------------
>> 1 file changed, 43 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/at91-ariettag25.dts b/arch/arm/boot/dts/at91-ariettag25.dts
>> index 7a34c4dc05d2..8f9f5a22cbf6 100644
>> --- a/arch/arm/boot/dts/at91-ariettag25.dts
>> +++ b/arch/arm/boot/dts/at91-ariettag25.dts
>> @@ -6,14 +6,11 @@
>> */
>> /dts-v1/;
>> #include "at91sam9g25.dtsi"
>> +
>> / {
>> model = "Acme Systems Arietta G25";
>> compatible = "acme,ariettag25", "atmel,at91sam9x5", "atmel,at91sam9";
>>
>> - aliases {
>> - serial0 = &dbgu;
>> - };
>> -
>> chosen {
>> stdout-path = "serial0:115200n8";
>> };
>> @@ -34,55 +31,16 @@
>>
>> ahb {
>> apb {
>> - mmc0: mmc@f0008000 {
>> - pinctrl-0 = <
>> - &pinctrl_mmc0_slot0_clk_cmd_dat0
>> - &pinctrl_mmc0_slot0_dat1_3>;
>> - status = "okay";
>> -
>> - slot@0 {
>> - reg = <0>;
>> - bus-width = <4>;
>> - };
>> - };
>> -
>> - tcb0: timer@f8008000 {
>> - timer@0 {
>> - compatible = "atmel,tcb-timer";
>> - reg = <0>;
>> - };
>> -
>> - timer@1 {
>> - compatible = "atmel,tcb-timer";
>> - reg = <1>;
>> - };
>> - };
>> -
>> - usb2: gadget@f803c000 {
>> - status = "okay";
>> - };
>> -
>> - dbgu: serial@fffff200 {
>> - status = "okay";
>> - };
>> -
>> rtc@fffffeb0 {
>> status = "okay";
>> };
>> };
>>
>> - usb0: ohci@600000 {
>> - status = "okay";
>> - num-ports = <3>;
>> - };
>> -
>> - usb1: ehci@700000 {
>> - status = "okay";
>> - };
>> };
>>
>> leds {
>> compatible = "gpio-leds";
>> +
>> arietta_led {
>> label = "arietta_led";
>> gpios = <&pioB 8 GPIO_ACTIVE_HIGH>; /* PB8 */
>> @@ -90,3 +48,44 @@
>> };
>> };
>> };
>> +
>> +&dbgu {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-0 = <
>> + &pinctrl_mmc0_slot0_clk_cmd_dat0
>> + &pinctrl_mmc0_slot0_dat1_3>;
>> + status = "okay";
>> +
>> + slot@0 {
>> + reg = <0>;
>> + bus-width = <4>;
>> + };
>> +};
>> +
>> +&tcb0 {
>> + timer@0 {
>> + compatible = "atmel,tcb-timer";
>> + reg = <0>;
>> + };
>> +
>> + timer@1 {
>> + compatible = "atmel,tcb-timer";
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&usb0 {
>> + num-ports = <3>;
>> + status = "okay";
>> +};
>> +
>> +&usb1 {
>> + status = "okay";
>> +};
>> +
>> +&usb2 {
>> + status = "okay";
>> +};
>> --
>> 2.20.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Nicolas Ferre
_______________________________________________
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] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Andrew F. Davis @ 2019-08-12 15:47 UTC (permalink / raw)
To: Suman Anna, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <20181024011909.21674-1-s-anna@ti.com>
On 10/23/18 9:19 PM, Suman Anna wrote:
> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> printing the vring buffer address. This prints only a hashed
> pointer even for previliged users. Use "%pK" instead so that
> the address can be printed during debug using kptr_restrict
> sysctl.
>
s/previliged/privileged
You describe what the code does, but not why you need this. %pK is used
for only about 1% of pointer printing, why do you want to leak this
address to userspace at all?
Andrew
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> index f29dee731026..1345f373a1a0 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> goto vqs_del;
> }
>
> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> bufs_va, &vrp->bufs_dma);
>
> /* half of the buffers is dedicated for RX */
>
_______________________________________________
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] arm64: cpufeature: Don't treat granule sizes as strict
From: Suzuki K Poulose @ 2019-08-12 15:48 UTC (permalink / raw)
To: will, linux-arm-kernel; +Cc: mark.rutland, khilman, catalin.marinas, maz
In-Reply-To: <20190812150225.25386-1-will@kernel.org>
Hi Will,
On 08/12/2019 04:02 PM, Will Deacon wrote:
> If a CPU doesn't support the page size for which the kernel is
> configured, then we will complain and refuse to bring it online. For
> secondary CPUs (and the boot CPU on a system booting with EFI), we will
> also print an error identifying the mismatch.
>
> Consequently, the only time that the cpufeature code can detect a
> granule size mismatch is for a granule other than the one that is
> currently being used. Although we would rather such systems didn't
> exist, we've unfortunately lost that battle and Kevin reports that
> on his amlogic S922X (odroid-n2 board) we end up warning and taining
> with defconfig because 16k pages are not supported by all of the CPUs.
>
> In such a situation, we don't actually care about the feature mismatch,
> particularly now that KVM only exposes the sanitised view of the CPU
> registers. Treat the granule fields as non-strict and let Kevin run
> without a tainted kernel.
I think it may be a good idea to mention the "KVM sanitised feature reg"
feature as a pre-req for KVM safety in the comment section to alert
people backporting this commit to older kernels.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kernel/cpufeature.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index d19d14ba9ae4..b1fdc486aed8 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
> + /*
> + * We already refuse to boot CPUs that don't support our configured
> + * page size, so we can only detect mismatches for a page size other
> + * than the one we're currently using. Unfortunately, SoCs like this
> + * exist in the wild so, even though we don't like it, we'll have to go
> + * along with it and treat them as non-strict.
> + */
> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
Eitherway,
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
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 v5 03/10] rtc: mt6397: move some common definitions into rtc.h
From: Alexandre Belloni @ 2019-08-12 15:38 UTC (permalink / raw)
To: Lee Jones
Cc: Kate Stewart, Mark Rutland, linux-kernel, Richard Fontana,
Mauro Carvalho Chehab, linux-rtc, Frank Wunderlich,
Allison Randal, devicetree, linux-pm, Sean Wang, Tianping . Fang,
Rob Herring, linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812151128.GV26727@dell>
On 12/08/2019 16:11:29+0100, Lee Jones wrote:
> On Mon, 12 Aug 2019, Frank Wunderlich wrote:
>
> > From: Josef Friedl <josef.friedl@speed.at>
> >
> > move code to separate header-file to reuse definitions later
> > in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
> >
> > Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> > Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> > Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> > ---
> > changes since v4: none
> > changes since v3: none
> > changes since v2: add missing commit-message
> > ---
> > drivers/rtc/rtc-mt6397.c | 55 +-------------------------
> > include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
>
> include/linux/rtc/mt6397.h?
>
It's just a bunch of registers and bit definitions so it may as well
stay close to include/linux/mfd/mt6397/registers.h
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
From: Eugen.Hristev @ 2019-08-12 15:38 UTC (permalink / raw)
To: adrian.hunter, Nicolas.Ferre, alexandre.belloni, ulf.hansson,
linux-arm-kernel, devicetree, linux-kernel, linux-mmc
In-Reply-To: <20190809062322.syuieymdqjs4e7lh@M43218.corp.atmel.com>
On 09.08.2019 09:23, Ludovic Desroches wrote:
> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
>> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
>>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
>>>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>>>
>>>> Add mmc capabilities for SDMMC0 for this board.
>>>> With this enabled, eMMC connected card is detected as:
>>>>
>>>> mmc0: new DDR MMC card at address 0001
>>>>
>>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>>> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
>>>
>>> I am interested to have the some insights about the use of sd-uhs-*
>>> properties.
>>>
>>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
>>> be used as the logic control input of a mux. So even if the IP claims
>>> to support UHS modes, it depends on the board.
>>>
>>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
>>> as sdhci_setup_host() will set the caps depending on the content of the
>>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
>>> quirk or sdhci-caps/sdhci-caps-mask?
>>
>> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
>>
>> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
>>
>> if (device_property_present(dev, "no-1-8-v"))
>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>
>
> Right, I forgot this property. Thanks.
>
> Eugen, do you see cases we can't cover with this property?
Hi,
For current requirements and driver support, this should be enough.
I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
the class 10 uhs1 cards are detected as SDR104 . Without this property
they are detected as DDR50. Any idea why the difference ? The controller
does not claim to have SDR104 support ? We should add it ?
Eugen
>
> Regards
>
> Ludovic
>
>>
>>>
>>> Regards
>>>
>>> Ludovic
>>>
>>>> ---
>>>> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> index 149e539..194b3a3 100644
>>>> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> @@ -54,6 +54,7 @@
>>>>
>>>> sdmmc0: sdio-host@a0000000 {
>>>> bus-width = <8>;
>>>> + mmc-ddr-3_3v;
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&pinctrl_sdmmc0_default>;
>>>> status = "okay";
>>>> --
>>>> 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 v1 2/3] arm64: dts: fix gpio node
From: Shawn Guo @ 2019-08-12 15:27 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, linux-gpio, Linus Walleij, linux-kernel,
Li Yang, Bartosz Golaszewski, Rob Herring, linux-arm-kernel
In-Reply-To: <20190808101628.36782-2-hui.song_1@nxp.com>
On Thu, Aug 08, 2019 at 06:16:27PM +0800, Hui Song wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> Update the nodes to include little-endian
> property to be consistent with the hardware
> and add ls1088a gpio specify compatible.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
The prefix should be more specific, like 'arm64: dts: ls1088a: ...'
Shawn
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 20f5ebd..d58d203 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -269,43 +269,47 @@
> };
>
> gpio0: gpio@2300000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2300000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> gpio1: gpio@2310000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2310000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> gpio2: gpio@2320000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2320000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> gpio3: gpio@2330000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2330000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> ifc: ifc@2240000 {
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 1/6] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
From: Mark Rutland @ 2019-08-12 15:26 UTC (permalink / raw)
To: Dave Martin
Cc: lorenzo.pieralisi, suzuki.poulose, marc.zyngier, catalin.marinas,
will.deacon, linux, james.morse, robin.murphy, linux-arm-kernel
In-Reply-To: <20190812151043.GU10425@arm.com>
On Mon, Aug 12, 2019 at 04:10:43PM +0100, Dave Martin wrote:
> On Mon, Aug 12, 2019 at 04:06:35PM +0100, Mark Rutland wrote:
> > On Mon, Aug 12, 2019 at 04:03:29PM +0100, Dave Martin wrote:
> > > On Fri, Aug 09, 2019 at 02:22:40PM +0100, Mark Rutland wrote:
> > > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > > > index 080012a6f025..df01a8579034 100644
> > > > --- a/include/linux/arm-smccc.h
> > > > +++ b/include/linux/arm-smccc.h
> > > > @@ -80,6 +80,22 @@
> > > >
> > > > #include <linux/linkage.h>
> > > > #include <linux/types.h>
> > > > +
> > > > +enum arm_smccc_conduit {
> > > > + SMCCC_CONDUIT_NONE,
> > >
> > > If this is intended to have the value 0, is it worth making that
> > > explicit? I can never remember whether enums start at 1 or 0 by
> > > default...
> >
> > They start at 0. I intend that checks are done explicitly against an
> > enum value, so I'm not sure that matters.
>
> Not really.
>
> It depends whether code like if (!arm_smccc_1_1_get_conduit()) { ... }
> is considered sane or not.
>
> If we don't think people should be doing this, omitting the explicit
> value specifier seems fine.
My expectation was that they'd check explicitly against
SMCCC_CONDUIT_NONE, since all of the existing callers care about the
specific conduit for other reasons (e.g. patching).
I also expect to wrap this in a sbusequent patch that provides helpers:
* arm_smccc_1_1_available()
* arm_smccc_1_1_call(...)
... for the cases where we just want to make a call and don't care about
the specific conduit.
Thanks,
Mark.
_______________________________________________
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 v5 01/10] dt-bindings: add powercontroller
From: Lee Jones @ 2019-08-12 15:15 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812121511.4169-2-frank-w@public-files.de>
On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add mt6323-rtc and mt6323-pwrc to mt6397 mfd DT bindings
> an example is shown in mt6323-poweroff.txt
>
> Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> changes since v4: use relative path
> changes since v3: none
> changes since v2: separated rtc-mt6397.txt to part 2
> ---
> .../devicetree/bindings/mfd/mt6397.txt | 20 +++++++++++++------
> .../bindings/power/reset/mt6323-poweroff.txt | 20 +++++++++++++++++++
> 2 files changed, 34 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index 0ebd08af777d..063f5fe1cace 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -8,11 +8,12 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
> - Clock
> - LED
> - Keys
> +- Power controller
>
> It is interfaced to host controller using SPI interface by a proprietary hardware
> called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
> See the following for pwarp node definitions:
> -Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +../../bindings/soc/mediatek/pwrap.txt
>
> This document describes the binding for MFD device and its sub module.
>
> @@ -22,14 +23,16 @@ compatible: "mediatek,mt6397" or "mediatek,mt6323"
> Optional subnodes:
>
> - rtc
> - Required properties:
> + Required properties: Should be one of follows
> + - compatible: "mediatek,mt6323-rtc"
> - compatible: "mediatek,mt6397-rtc"
> + For details, see ../../bindings/rtc/rtc-mt6397.txt
Apologies for the ambiguity. I don't think you need to go all the way
back to 'bindings'. Just one step back will do fine. ../rtc/* will be
fine here.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 v5 03/10] rtc: mt6397: move some common definitions into rtc.h
From: Lee Jones @ 2019-08-12 15:11 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812121511.4169-4-frank-w@public-files.de>
On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> move code to separate header-file to reuse definitions later
> in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
>
> Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v4: none
> changes since v3: none
> changes since v2: add missing commit-message
> ---
> drivers/rtc/rtc-mt6397.c | 55 +-------------------------
> include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
include/linux/rtc/mt6397.h?
> 2 files changed, 72 insertions(+), 54 deletions(-)
> create mode 100644 include/linux/mfd/mt6397/rtc.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 1/6] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
From: Dave Martin @ 2019-08-12 15:10 UTC (permalink / raw)
To: Mark Rutland
Cc: lorenzo.pieralisi, suzuki.poulose, marc.zyngier, catalin.marinas,
will.deacon, linux, james.morse, robin.murphy, linux-arm-kernel
In-Reply-To: <20190812150634.GB52896@lakrids.cambridge.arm.com>
On Mon, Aug 12, 2019 at 04:06:35PM +0100, Mark Rutland wrote:
> On Mon, Aug 12, 2019 at 04:03:29PM +0100, Dave Martin wrote:
> > On Fri, Aug 09, 2019 at 02:22:40PM +0100, Mark Rutland wrote:
> > > SMCCC callers are currently amassing a collection of enums for the SMCCC
> > > conduit, and are having to dig into the PSCI driver's internals in order
> > > to figure out what to do.
> > >
> > > Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
> > > arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
> > > internal state.
> > >
> > > We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
> > > over to the new interface.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > ---
> > > drivers/firmware/psci/psci.c | 15 +++++++++++++++
> > > include/linux/arm-smccc.h | 16 ++++++++++++++++
> > > 2 files changed, 31 insertions(+)
> > >
> > > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > > index f82ccd39a913..5f31f1bea1af 100644
> > > --- a/drivers/firmware/psci/psci.c
> > > +++ b/drivers/firmware/psci/psci.c
> > > @@ -57,6 +57,21 @@ struct psci_operations psci_ops = {
> > > .smccc_version = SMCCC_VERSION_1_0,
> > > };
> > >
> > > +enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
> >
> > Do we expect this to be specific to SMCCC v1.1?
>
> I intend it to be 1.1+
It seems overspecific, but I guess we can address this later if it
becomes an issue. This is an internal API for now (at worst I might
envisage it being EXPORT_SYMBOL_GPL()).
> > > +{
> > > + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> > > + return SMCCC_CONDUIT_NONE;
> > > +
> > > + switch (psci_ops.conduit) {
> > > + case PSCI_CONDUIT_SMC:
> > > + return SMCCC_CONDUIT_SMC;
> > > + case PSCI_CONDUIT_HVC:
> > > + return SMCCC_CONDUIT_HVC;
> > > + default:
> > > + return SMCCC_CONDUIT_NONE;
> > > + }
> > > +}
> > > +
> > > typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > > unsigned long, unsigned long);
> > > static psci_fn *invoke_psci_fn;
> > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > > index 080012a6f025..df01a8579034 100644
> > > --- a/include/linux/arm-smccc.h
> > > +++ b/include/linux/arm-smccc.h
> > > @@ -80,6 +80,22 @@
> > >
> > > #include <linux/linkage.h>
> > > #include <linux/types.h>
> > > +
> > > +enum arm_smccc_conduit {
> > > + SMCCC_CONDUIT_NONE,
> >
> > If this is intended to have the value 0, is it worth making that
> > explicit? I can never remember whether enums start at 1 or 0 by
> > default...
>
> They start at 0. I intend that checks are done explicitly against an
> enum value, so I'm not sure that matters.
Not really.
It depends whether code like if (!arm_smccc_1_1_get_conduit()) { ... }
is considered sane or not.
If we don't think people should be doing this, omitting the explicit
value specifier seems fine.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Fabio Estevam @ 2019-08-12 15:10 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev, Heiner Kallweit, Florian Fainelli,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Andrew Lunn
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
Hi Russell,
On Sun, Aug 11, 2019 at 10:37 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
>
> From what I can see, the OOM events happened on CPU1, CPU1 was
> allocated the FEC interrupt, and the PHY polling that suffered the
> MDIO timeout was on CPU0.
>
> Given that IEVENT is zero, it seems that CPU1 had read serviced the
> interrupt, but it is not clear how far through processing that it
> was - it may be that fec_enet_interrupt() had been delayed by the
> OOM condition.
>
> This seems rather fragile - as the system slowing down due to OOM
> triggers the network to completely collapse by phylib taking the
> PHY offline, making the system inaccessible except through the
> console.
>
> In my case, even serial console wasn't operational (except for
> magic sysrq). Not sure what agetty was playing at... so the only
> way I could recover any information from the system was to connect
> the HDMI and plug in a USB keyboard.
>
> Any thoughts on how FEC MDIO accesses could be made more robust?
Sorry for the delay. I am currently on vacation with limited e-mail access.
I think it is worth trying Andrew's suggestion to increase FEC_MII_TIMEOUT.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 1/6] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
From: Mark Rutland @ 2019-08-12 15:06 UTC (permalink / raw)
To: Dave Martin
Cc: lorenzo.pieralisi, suzuki.poulose, marc.zyngier, catalin.marinas,
will.deacon, linux, james.morse, robin.murphy, linux-arm-kernel
In-Reply-To: <20190812150326.GT10425@arm.com>
On Mon, Aug 12, 2019 at 04:03:29PM +0100, Dave Martin wrote:
> On Fri, Aug 09, 2019 at 02:22:40PM +0100, Mark Rutland wrote:
> > SMCCC callers are currently amassing a collection of enums for the SMCCC
> > conduit, and are having to dig into the PSCI driver's internals in order
> > to figure out what to do.
> >
> > Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
> > arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
> > internal state.
> >
> > We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
> > over to the new interface.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > drivers/firmware/psci/psci.c | 15 +++++++++++++++
> > include/linux/arm-smccc.h | 16 ++++++++++++++++
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > index f82ccd39a913..5f31f1bea1af 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -57,6 +57,21 @@ struct psci_operations psci_ops = {
> > .smccc_version = SMCCC_VERSION_1_0,
> > };
> >
> > +enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
>
> Do we expect this to be specific to SMCCC v1.1?
I intend it to be 1.1+
> > +{
> > + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> > + return SMCCC_CONDUIT_NONE;
> > +
> > + switch (psci_ops.conduit) {
> > + case PSCI_CONDUIT_SMC:
> > + return SMCCC_CONDUIT_SMC;
> > + case PSCI_CONDUIT_HVC:
> > + return SMCCC_CONDUIT_HVC;
> > + default:
> > + return SMCCC_CONDUIT_NONE;
> > + }
> > +}
> > +
> > typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > unsigned long, unsigned long);
> > static psci_fn *invoke_psci_fn;
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index 080012a6f025..df01a8579034 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -80,6 +80,22 @@
> >
> > #include <linux/linkage.h>
> > #include <linux/types.h>
> > +
> > +enum arm_smccc_conduit {
> > + SMCCC_CONDUIT_NONE,
>
> If this is intended to have the value 0, is it worth making that
> explicit? I can never remember whether enums start at 1 or 0 by
> default...
They start at 0. I intend that checks are done explicitly against an
enum value, so I'm not sure that matters.
Thanks,
Mark.
>
> > + SMCCC_CONDUIT_SMC,
> > + SMCCC_CONDUIT_HVC,
> > +};
>
> [...]
>
> Cheers
> ---Dave
_______________________________________________
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] tty/serial: atmel: remove redundant assignment to ret
From: Alexandre Belloni @ 2019-08-12 15:05 UTC (permalink / raw)
To: Colin King
Cc: Richard Genoud, Greg Kroah-Hartman, kernel-janitors, linux-kernel,
Ludovic Desroches, linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <20190809174042.6276-1-colin.king@canonical.com>
On 09/08/2019 18:40:42+0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable ret is initialized to a value that is never read and it
> is re-assigned later. The initialization is redundant and can be
> removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/tty/serial/atmel_serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 0b4f36905321..19a85d6fe3d2 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2888,7 +2888,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
> struct atmel_uart_port *atmel_port;
> struct device_node *np = pdev->dev.parent->of_node;
> void *data;
> - int ret = -ENODEV;
> + int ret;
> bool rs485_enabled;
>
> BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
> --
> 2.20.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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] arm64: cpufeature: Don't treat granule sizes as strict
From: Mark Rutland @ 2019-08-12 15:04 UTC (permalink / raw)
To: Will Deacon
Cc: khilman, Suzuki Poulose, Catalin Marinas, linux-arm-kernel,
Marc Zyngier
In-Reply-To: <20190812150225.25386-1-will@kernel.org>
On Mon, Aug 12, 2019 at 04:02:25PM +0100, Will Deacon wrote:
> If a CPU doesn't support the page size for which the kernel is
> configured, then we will complain and refuse to bring it online. For
> secondary CPUs (and the boot CPU on a system booting with EFI), we will
> also print an error identifying the mismatch.
>
> Consequently, the only time that the cpufeature code can detect a
> granule size mismatch is for a granule other than the one that is
> currently being used. Although we would rather such systems didn't
> exist, we've unfortunately lost that battle and Kevin reports that
> on his amlogic S922X (odroid-n2 board) we end up warning and taining
> with defconfig because 16k pages are not supported by all of the CPUs.
>
> In such a situation, we don't actually care about the feature mismatch,
> particularly now that KVM only exposes the sanitised view of the CPU
> registers. Treat the granule fields as non-strict and let Kevin run
> without a tainted kernel.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Will Deacon <will@kernel.org>
FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/kernel/cpufeature.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index d19d14ba9ae4..b1fdc486aed8 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
> + /*
> + * We already refuse to boot CPUs that don't support our configured
> + * page size, so we can only detect mismatches for a page size other
> + * than the one we're currently using. Unfortunately, SoCs like this
> + * exist in the wild so, even though we don't like it, we'll have to go
> + * along with it and treat them as non-strict.
> + */
> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
> +
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
> /* Linux shouldn't care about secure memory */
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 1/6] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
From: Dave Martin @ 2019-08-12 15:03 UTC (permalink / raw)
To: Mark Rutland
Cc: lorenzo.pieralisi, suzuki.poulose, marc.zyngier, catalin.marinas,
will.deacon, linux, james.morse, robin.murphy, linux-arm-kernel
In-Reply-To: <20190809132245.43505-2-mark.rutland@arm.com>
On Fri, Aug 09, 2019 at 02:22:40PM +0100, Mark Rutland wrote:
> SMCCC callers are currently amassing a collection of enums for the SMCCC
> conduit, and are having to dig into the PSCI driver's internals in order
> to figure out what to do.
>
> Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
> arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
> internal state.
>
> We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
> over to the new interface.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> drivers/firmware/psci/psci.c | 15 +++++++++++++++
> include/linux/arm-smccc.h | 16 ++++++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index f82ccd39a913..5f31f1bea1af 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -57,6 +57,21 @@ struct psci_operations psci_ops = {
> .smccc_version = SMCCC_VERSION_1_0,
> };
>
> +enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
Do we expect this to be specific to SMCCC v1.1?
> +{
> + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> + return SMCCC_CONDUIT_NONE;
> +
> + switch (psci_ops.conduit) {
> + case PSCI_CONDUIT_SMC:
> + return SMCCC_CONDUIT_SMC;
> + case PSCI_CONDUIT_HVC:
> + return SMCCC_CONDUIT_HVC;
> + default:
> + return SMCCC_CONDUIT_NONE;
> + }
> +}
> +
> typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 080012a6f025..df01a8579034 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -80,6 +80,22 @@
>
> #include <linux/linkage.h>
> #include <linux/types.h>
> +
> +enum arm_smccc_conduit {
> + SMCCC_CONDUIT_NONE,
If this is intended to have the value 0, is it worth making that
explicit? I can never remember whether enums start at 1 or 0 by
default...
> + SMCCC_CONDUIT_SMC,
> + SMCCC_CONDUIT_HVC,
> +};
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: cpufeature: Don't treat granule sizes as strict
From: Will Deacon @ 2019-08-12 15:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Marc Zyngier, Suzuki Poulose, khilman,
Catalin Marinas, Will Deacon
If a CPU doesn't support the page size for which the kernel is
configured, then we will complain and refuse to bring it online. For
secondary CPUs (and the boot CPU on a system booting with EFI), we will
also print an error identifying the mismatch.
Consequently, the only time that the cpufeature code can detect a
granule size mismatch is for a granule other than the one that is
currently being used. Although we would rather such systems didn't
exist, we've unfortunately lost that battle and Kevin reports that
on his amlogic S922X (odroid-n2 board) we end up warning and taining
with defconfig because 16k pages are not supported by all of the CPUs.
In such a situation, we don't actually care about the feature mismatch,
particularly now that KVM only exposes the sanitised view of the CPU
registers. Treat the granule fields as non-strict and let Kevin run
without a tainted kernel.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/cpufeature.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d19d14ba9ae4..b1fdc486aed8 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+ /*
+ * We already refuse to boot CPUs that don't support our configured
+ * page size, so we can only detect mismatches for a page size other
+ * than the one we're currently using. Unfortunately, SoCs like this
+ * exist in the wild so, even though we don't like it, we'll have to go
+ * along with it and treat them as non-strict.
+ */
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
/* Linux shouldn't care about secure memory */
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] usb: gadget: atmel_usba_udc: Mark expected switch fall-through
From: Alexandre Belloni @ 2019-08-12 14:58 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Felipe Balbi, Greg Kroah-Hartman, linux-usb, linux-kernel,
Ludovic Desroches, Cristian Birsan, linux-arm-kernel
In-Reply-To: <20190805184842.GA8627@embeddedor>
On 05/08/2019 13:48:42-0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: at91_dt_defconfig arm):
>
> drivers/usb/gadget/udc/atmel_usba_udc.c:329:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 503d275bc4c4..86ffc8307864 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -327,6 +327,7 @@ static int usba_config_fifo_table(struct usba_udc *udc)
> switch (fifo_mode) {
> default:
> fifo_mode = 0;
> + /* fall through */
> case 0:
> udc->fifo_cfg = NULL;
> n = 0;
> --
> 2.22.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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] at91/dt: ariettag25: style cleanup
From: Alexandre Belloni @ 2019-08-12 14:57 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, devicetree, Ludovic Desroches, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190731220045.3992-1-uwe@kleine-koenig.org>
Hi,
The subject prefix should be "ARM: dts: at91:"
On 01/08/2019 00:00:45+0200, Uwe Kleine-König wrote:
> - newline between properties and sub-nodes
> - use tags from included dtsi instead of duplicating the hierarchy
> - status should be the last property
> - drop duplicated alias
>
> There are no differences in the generated .dtb
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> Hello,
>
> these are the style rules I was teached when modifying imx dts files.
> Do they apply to at91, too?
>
> Best regards
> Uwe
>
> arch/arm/boot/dts/at91-ariettag25.dts | 87 +++++++++++++--------------
> 1 file changed, 43 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-ariettag25.dts b/arch/arm/boot/dts/at91-ariettag25.dts
> index 7a34c4dc05d2..8f9f5a22cbf6 100644
> --- a/arch/arm/boot/dts/at91-ariettag25.dts
> +++ b/arch/arm/boot/dts/at91-ariettag25.dts
> @@ -6,14 +6,11 @@
> */
> /dts-v1/;
> #include "at91sam9g25.dtsi"
> +
> / {
> model = "Acme Systems Arietta G25";
> compatible = "acme,ariettag25", "atmel,at91sam9x5", "atmel,at91sam9";
>
> - aliases {
> - serial0 = &dbgu;
> - };
> -
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -34,55 +31,16 @@
>
> ahb {
> apb {
> - mmc0: mmc@f0008000 {
> - pinctrl-0 = <
> - &pinctrl_mmc0_slot0_clk_cmd_dat0
> - &pinctrl_mmc0_slot0_dat1_3>;
> - status = "okay";
> -
> - slot@0 {
> - reg = <0>;
> - bus-width = <4>;
> - };
> - };
> -
> - tcb0: timer@f8008000 {
> - timer@0 {
> - compatible = "atmel,tcb-timer";
> - reg = <0>;
> - };
> -
> - timer@1 {
> - compatible = "atmel,tcb-timer";
> - reg = <1>;
> - };
> - };
> -
> - usb2: gadget@f803c000 {
> - status = "okay";
> - };
> -
> - dbgu: serial@fffff200 {
> - status = "okay";
> - };
> -
> rtc@fffffeb0 {
You can had a label to the rtc in a preliminary patch so you can remove
the hierarchy.
> status = "okay";
> };
> };
>
> - usb0: ohci@600000 {
> - status = "okay";
> - num-ports = <3>;
> - };
> -
> - usb1: ehci@700000 {
> - status = "okay";
> - };
> };
>
> leds {
> compatible = "gpio-leds";
> +
> arietta_led {
> label = "arietta_led";
> gpios = <&pioB 8 GPIO_ACTIVE_HIGH>; /* PB8 */
> @@ -90,3 +48,44 @@
> };
> };
> };
> +
> +&dbgu {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-0 = <
> + &pinctrl_mmc0_slot0_clk_cmd_dat0
> + &pinctrl_mmc0_slot0_dat1_3>;
> + status = "okay";
> +
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + };
> +};
> +
> +&tcb0 {
> + timer@0 {
> + compatible = "atmel,tcb-timer";
> + reg = <0>;
> + };
> +
> + timer@1 {
> + compatible = "atmel,tcb-timer";
> + reg = <1>;
> + };
> +};
> +
> +&usb0 {
> + num-ports = <3>;
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
> +&usb2 {
> + status = "okay";
> +};
> --
> 2.20.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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