* [PATCH v2 2/6] arm: dts: at91: add labels to soc dtsi for derivative boards
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
This adds labels to commonly used device-tree nodes so that derivative
boards can avoid ahb/apb hierarchy.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++++----
arch/arm/boot/dts/sama5d3.dtsi | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index a3c3c31..11c0ef1 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -389,13 +389,13 @@
};
};
- rstc at fffffe00 {
+ reset_controller: rstc at fffffe00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfffffe00 0x10>;
clocks = <&clk32k>;
};
- shdwc at fffffe10 {
+ shutdown_controller: shdwc at fffffe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfffffe10 0x10>;
clocks = <&clk32k>;
@@ -470,7 +470,7 @@
clock-names = "dma_clk";
};
- pinctrl at fffff400 {
+ pinctrl: pinctrl at fffff400 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,at91sam9x5-pinctrl", "atmel,at91rm9200-pinctrl", "simple-bus";
@@ -1206,7 +1206,7 @@
};
};
- watchdog at fffffe40 {
+ watchdog: watchdog at fffffe40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffe40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index eae5e1e..1408fa4 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -494,7 +494,7 @@
atmel,external-irqs = <47>;
};
- pinctrl at fffff200 {
+ pinctrl: pinctrl at fffff200 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,sama5d3-pinctrl", "atmel,at91sam9x5-pinctrl", "simple-bus";
@@ -1340,13 +1340,13 @@
};
};
- rstc at fffffe00 {
+ reset_controller: rstc at fffffe00 {
compatible = "atmel,sama5d3-rstc", "atmel,at91sam9g45-rstc";
reg = <0xfffffe00 0x10>;
clocks = <&clk32k>;
};
- shutdown-controller at fffffe10 {
+ shutdown_controller: shutdown-controller at fffffe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfffffe10 0x10>;
clocks = <&clk32k>;
@@ -1359,7 +1359,7 @@
clocks = <&mck>;
};
- watchdog at fffffe40 {
+ watchdog: watchdog at fffffe40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffe40 0x10>;
interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/6] dt-bindings: add laird and giantec vendor prefix
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
This adds a vendor prefix "laird" for Laird PLC who make
CPU modules and system on chips.
Also adds "giantec" for Giantec Semiconductor, Inc. who
make eeprom memory used on Laird designs.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a38d8bf..adf808c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ geekbuying GeekBuying
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.
GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
geniatech Geniatech, Inc.
+giantec Giantec Semiconductor, Inc.
giantplus Giantplus Technology Co., Ltd.
globalscale Globalscale Technologies, Inc.
gmt Global Mixed-mode Technology, Inc.
@@ -188,6 +189,7 @@ kingnovel Kingnovel Technology Co., Ltd.
kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
+laird Laird PLC
lantiq Lantiq Semiconductor
lattice Lattice Semiconductor
lego LEGO Systems A/S
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Sekhar Nori @ 2018-06-15 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615050108.GG112168@atomide.com>
Hi Tony,
On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [180614 13:07]:
>> On 12:38-20180614, Tony Lindgren wrote:
>> From A53 view, a more accurate view might be - from an interconnect
>> view of the world (still simplified - i have ignored the sub bus
>> segments in the representations below):
>>
>> msmc {
>> navss_main {
>> cbass_main{
>> cbass_mcu {
>> navss_mcu {
>> };
>> cbass_wkup{
>> };
>> };
>> };
>> };
>> };
>>
>> From R5 view, the view will be very different ofcourse:
>> view of the world (still simplified):
>>
>> cbass_mcu {
>> navss_mcu {
>> };
>> cbass_wkup{
>> };
>> cbass_main{
>> navss_main {
>> msmc {
>> };
>> };
>> };
>> };
>
> Well if we follow the hardware representation of the interconnects,
> it should not matter from which processor view you're looking at things.
> There are just different ranges provided.
AFAIK, the root node needs to have the CPU which is using the DT. So,
the hierarchy will change based on CPU view (if we describe it fully).
How well we can reuse individual interconnect segments is something I
have to think about / experiment. Will have to be wary of any "short
paths" or "cross connections".
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/9] CHROMIUM: v4l: Add H264 low-level decoder API compound controls.
From: Guenter Roeck @ 2018-06-15 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c80de4e-c070-1051-2089-2d53826c6fc7@xs4all.nl>
On Fri, Jun 15, 2018 at 5:00 AM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 13/06/18 16:07, Maxime Ripard wrote:
> > From: Pawel Osciak <posciak@chromium.org>
>
> Obviously this needs a proper commit message.
>
> >
> > Signed-off-by: Pawel Osciak <posciak@chromium.org>
> > Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
> > Tested-by: Tomasz Figa <tfiga@chromium.org>
> > [rebase44(groeck): include linux/types.h in v4l2-controls.h]
That internal note should go away.
Guenter
^ permalink raw reply
* [PATCH 0/3] arm64: kexec, kdump: fix boot failures on acpi-only system
From: Bhupesh Sharma @ 2018-06-15 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org>
Hi Akashi,
Thanks for the patchset - we have been waiting for quite some time for
this fix so that crashkernel can boot on arm64 machines which support
boot'ing via ACPI tables.
I have tested this on my huawei-taishan arm64 board, so:
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
BTW, if possible I would suggest to use:
Reported-by: Bhupesh Sharma <bhsharma@redhat.com>
rather than:
Reported-by: Bhupesh Sharma <bhupesh.linux@gmail.com>
Thanks,
Bhupesh
On Fri, Jun 15, 2018 at 1:26 PM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> # apologies for a bit late updates
>
> This patch series is a set of bug fixes to address kexec/kdump
> failures which are sometimes observed on ACPI-only system and reported
> in LAK-ML before.
>
> In short, the phenomena are:
> 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted
> by a new kernel (or other data) being loaded into System RAM. Currently
> kexec may possibly allocate space ignoring such "reserved" regions.
> We will see no messages after "Bye!"
>
> 2. crash dump (kdump) kernel can fail to boot and get into panic due to
> an alignment fault when accessing ACPI tables. This can happen because
> those tables are not always properly aligned while they are mapped
> non-cacheable (ioremap'ed) as they are not recognized as part of System
> RAM under the current implementation.
>
> After discussing several possibilities to address those issues,
> the agreed approach, in my understanding, is
> * to add resource entries for every "reserved", i.e. memblock_reserve(),
> regions to /proc/iomem.
> (NOMAP regions, also marked as "reserved," remains at top-level for
> backward compatibility.)
> * For case (1), user space (kexec-tools) should rule out such regions
> in searching for free space for loaded data.
> * For case (2), the kernel should access ACPI tables by mapping
> them with appropriate memory attributes described in UEFI memory map.
> (This means that it doesn't require any changes in /proc/iomem, and
> hence user space.)
>
> Please find past discussions about /proc/iomem in [1].
>
> Patch#1 addresses kexec case, for which you are also required to update
> user space. See necessary patches in [2]. If you want to review Patch#1,
> please also take a look at and review [2].
>
> Patch#2 and #3 addresses kdump case. This is a revised version after
> Ard's comments.[3]
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565980.html
> [2] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/resv_mem
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573655.html
>
> AKASHI Takahiro (2):
> arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump
> init: map UEFI memory map early if on arm or arm64
>
> James Morse (1):
> arm64: export memblock_reserve()d regions via /proc/iomem
>
> arch/arm64/include/asm/acpi.h | 23 ++++++++++++------
> arch/arm64/kernel/acpi.c | 11 +++------
> arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++
> drivers/firmware/efi/arm-runtime.c | 27 ++++++++++-----------
> init/main.c | 3 +++
> 5 files changed, 72 insertions(+), 30 deletions(-)
>
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] ARM: add missing of_node_put()
From: Nicholas Mc Guire @ 2018-06-15 12:28 UTC (permalink / raw)
To: linux-arm-kernel
The call to of_find_compatible_node() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage. (see drivers/of/base.c:of_find_compatible_node())
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
Problem located with an experimental coccinelle script
Patch was compile tested with: axm55xx_defconfig
(with some sparse warnings - not related to the proposed change though)
Patch is against 4.17.0 (localversion-next is next-20180614)
arch/arm/mach-axxia/platsmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-axxia/platsmp.c b/arch/arm/mach-axxia/platsmp.c
index 502e3df..c706a11 100644
--- a/arch/arm/mach-axxia/platsmp.c
+++ b/arch/arm/mach-axxia/platsmp.c
@@ -40,10 +40,11 @@ static int axxia_boot_secondary(unsigned int cpu, struct task_struct *idle)
syscon_np = of_find_compatible_node(NULL, NULL, "lsi,axxia-syscon");
if (!syscon_np)
return -ENOENT;
syscon = of_iomap(syscon_np, 0);
+ of_node_put(syscon_np);
if (!syscon)
return -ENOMEM;
tmp = readl(syscon + SC_RST_CPU_HOLD);
writel(0xab, syscon + SC_CRIT_WRITE_KEY);
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Nicolas Ferre @ 2018-06-15 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BY1PR02MB1114728E5FF0709137B4224FE77C0@BY1PR02MB1114.namprd02.prod.outlook.com>
On 15/06/2018 at 12:01, Ben Whitten wrote:
>> On 14/06/2018 at 10:51, Ben Whitten wrote:
>>> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
>>> ---
>>> arch/arm/boot/dts/Makefile | 3 +-
>>> arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
>>> arch/arm/boot/dts/at91-wb45n.dtsi | 169
>> ++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 237 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
>>> create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 7e24249..1ee94ee 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
>>> at91sam9g25ek.dtb \
>>> at91sam9g35ek.dtb \
>>> at91sam9x25ek.dtb \
>>> - at91sam9x35ek.dtb
>>> + at91sam9x35ek.dtb \
>>> + at91-wb45n.dtb
>>> dtb-$(CONFIG_SOC_SAM_V7) += \
>>> at91-kizbox2.dtb \
>>> at91-nattis-2-natte-2.dtb \
>>> diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-
>> wb45n.dts
>>> new file mode 100644
>>> index 0000000..4e88815
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/at91-wb45n.dts
>>> @@ -0,0 +1,66 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * at91-wb45n.dts - Device Tree file for WB45NBT board
>>> + *
>>> + * Copyright (C) 2018 Laird
>>> + *
>>> +*/
>>> +/dts-v1/;
>>> +#include "at91-wb45n.dtsi"
>>> +
>>> +/ {
>>> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
>>> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
>> "atmel,at91sam9";
>>
>> "laird" prefix must be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt before using it:
>> you can do a little patch as a first patch of this series.
>> Otherwise it will trigger a warning message while running
>> scripts/checkpatch.pl on top of your patch.
>>
>>
>>> +
>>> + ahb {
>>> + apb {
>>> + watchdog at fffffe40 {
>>> + status = "okay";
>>> + };
>>> + };
>>> + };
>>> +
>>> + gpio_keys {
>>> + compatible = "gpio-keys";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + irqbtn at pb18 {
>>
>> I'm not sure that the @pb18 can be used like this. This address
>> extension must be used in a "reg" property in the node. dtc used with
>> warning switch on might trigger an error for this.
>>
>>> + label = "IRQBTN";
>>> + linux,code = <99>;
>>> + gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
>>> + gpio-key,wakeup = <1>;
>>> + };
>>> + };
>>> +};
>>> +
>>> +&usb0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&macb0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&dbgu {
>>> + status = "okay";
>>> +};
>>> +
>>> +&usart0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&usart3 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&i2c1 {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-
>> wb45n.dtsi
>>> new file mode 100644
>>> index 0000000..2fa58e2
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/at91-wb45n.dtsi
>>> @@ -0,0 +1,169 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * at91-wb45n.dtsi - Device Tree file for WB45NBT board
>>> + *
>>> + * Copyright (C) 2018 Laird
>>> + *
>>> + */
>>> +
>>> +#include "at91sam9g25.dtsi"
>>> +
>>> +/ {
>>> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
>>> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
>> "atmel,at91sam9";
>>> +
>>> + chosen {
>>> + bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs
>> rw";
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + memory {
>>> + reg = <0x20000000 0x4000000>;
>>> + };
>>> +
>>> + ahb {
>>> + apb {
>>> + shdwc at fffffe10 {
>>
>> I would advice you to take exactly the node name:
>> "shutdown-controller at fffffe10"; Anyway, it will go away after you use
>> the label notation as advised by Alexandre.
>>
>>> + atmel,wakeup-mode = "low";
>>> + };
>>> +
>>> + pinctrl at fffff400 {
>>> + usb2 {
>>> + pinctrl_board_usb2: usb2-board {
>>> + atmel,pins =
>>> + <AT91_PIOB 11
>> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio
>> vbus sense, deglitch */
>>> + };
>>> + };
>>> + };
>>> +
>>> + rstc at fffffe00 {
>>> + compatible = "atmel,sama5d3-rstc";
>>> + };
>>
>> I don't think this node is needed.
>
> I dug through our old code reviews and found this message relating to testing
> reboot over several thousand times in our testbed:
> After the slow clock has been enabled on the reset controller via upstream
> changes, the dram disable access and power down code is causing the SAM9G25
> to hang occasionally on reboot. Using the simple reset function provided
> for SAMA5D3 instead.
>
> So it appears to be a workaround for a bug that existed ~2 years ago, may still be
> relevant as there haven't been many changes to the reset code in that time.
All right, I read too quickly and thought it was sama5d3... Your
feedback is interesting anyway. I'll store this for future reference and
investigation.
>>> +
>>> + };
>>> + };
>>> +
>>> + atheros {
>>> + compatible = "atheros,ath6kl";
>>> + atheros,board-id = "SD32";
>>> + };
>>> +};
>>> +
>>> +&slow_xtal {
>>> + clock-frequency = <32768>;
>>> +};
>>> +
>>> +&main_xtal {
>>> + clock-frequency = <12000000>;
>>> +};
>>> +
>>> +&ebi {
>>> + status = "okay";
>>> + nand_controller: nand-controller {
>>> + pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb
>> &pinctrl_nand_oe_we>;
>>> + pinctrl-names = "default";
>>> + status = "okay";
>>> +
>>> + nand at 3 {
>>> + reg = <0x3 0x0 0x800000>;
>>> + rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
>>> + cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
>>> + nand-bus-width = <8>;
>>> + nand-ecc-mode = "hw";
>>> + nand-ecc-strength = <4>;
>>> + nand-ecc-step-size = <512>;
>>> + nand-on-flash-bbt;
>>> + label = "atmel_nand";
>>> +
>>> + partitions {
>>> + compatible = "fixed-partitions";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> +
>>> + at91bootstrap at 0 {
>>> + label = "at91bs";
>>> + reg = <0x0 0x20000>;
>>> + };
>>> +
>>> + uboot at 20000 {
>>> + label = "u-boot";
>>> + reg = <0x20000 0x80000>;
>>> + };
>>> +
>>> + ubootenv at a0000 {
>>> + label = "u-boot-env";
>>> + reg = <0xa0000 0x20000>;
>>> + };
>>> +
>>> + ubootenv at c0000 {
>>> + label = "redund-env";
>>> + reg = <0xc0000 0x20000>;
>>> + };
>>> +
>>> + kernel-a at e0000 {
>>> + label = "kernel-a";
>>> + reg = <0xe0000 0x280000>;
>>> + };
>>> +
>>> + kernel-b at 360000 {
>>> + label = "kernel-b";
>>> + reg = <0x360000 0x280000>;
>>> + };
>>> +
>>> + rootfs-a at 5e0000 {
>>> + label = "rootfs-a";
>>> + reg = <0x5e0000 0x2600000>;
>>> + };
>>> +
>>> + rootfs-b at 2be0000 {
>>> + label = "rootfs-b";
>>> + reg = <0x2be0000 0x2600000>;
>>> + };
>>> +
>>> + user at 51e0000 {
>>> + label = "user";
>>> + reg = <0x51e0000 0x2dc0000>;
>>> + };
>>> +
>>> + logs at 7fa0000 {
>>> + label = "logs";
>>> + reg = <0x7fa0000 0x60000>;
>>> + };
>>> +
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +&usb0 {
>>
>> This must be &usb1 label, isn't it?
>> Because you are referring to ohci binding I suspect (found by having a
>> look at: atmel,oc-gpio property...).
>
> I believe usb0 is correct, as this is a at91sam9x5 part, the node in dtsi is -ohci.
> sama5d3 is usb1 for -ohci.
All right, like previous comment, I thought it was sama5d3: sorry for
the noise.
Best regards,
Nicolas
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/9] CHROMIUM: v4l: Add H264 low-level decoder API compound controls.
From: Hans Verkuil @ 2018-06-15 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613140714.1686-2-maxime.ripard@bootlin.com>
On 13/06/18 16:07, Maxime Ripard wrote:
> From: Pawel Osciak <posciak@chromium.org>
Obviously this needs a proper commit message.
>
> Signed-off-by: Pawel Osciak <posciak@chromium.org>
> Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
> Tested-by: Tomasz Figa <tfiga@chromium.org>
> [rebase44(groeck): include linux/types.h in v4l2-controls.h]
> Signed-off-by: Guenter Roeck <groeck@chromium.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 42 +++++++
> include/media/v4l2-ctrls.h | 10 ++
> include/uapi/linux/v4l2-controls.h | 164 +++++++++++++++++++++++++++
> include/uapi/linux/videodev2.h | 11 ++
> 4 files changed, 227 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index cdf860c8e3d8..1f63c725bad1 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -807,6 +807,11 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER:return "H264 Number of HC Layers";
> case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP:
> return "H264 Set QP Value for HC Layers";
> + case V4L2_CID_MPEG_VIDEO_H264_SPS: return "H264 SPS";
> + case V4L2_CID_MPEG_VIDEO_H264_PPS: return "H264 PPS";
> + case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX: return "H264 Scaling Matrix";
> + case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM: return "H264 Slice Parameters";
> + case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM: return "H264 Decode Parameters";
> case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4 I-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP: return "MPEG4 P-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP: return "MPEG4 B-Frame QP Value";
> @@ -1272,6 +1277,21 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_RDS_TX_ALT_FREQS:
> *type = V4L2_CTRL_TYPE_U32;
> break;
> + case V4L2_CID_MPEG_VIDEO_H264_SPS:
> + *type = V4L2_CTRL_TYPE_H264_SPS;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_PPS:
> + *type = V4L2_CTRL_TYPE_H264_PPS;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX:
> + *type = V4L2_CTRL_TYPE_H264_SCALING_MATRIX;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM:
> + *type = V4L2_CTRL_TYPE_H264_SLICE_PARAM;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM:
> + *type = V4L2_CTRL_TYPE_H264_DECODE_PARAM;
> + break;
> case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> break;
> @@ -1598,6 +1618,13 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 idx,
> case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> return 0;
>
> + case V4L2_CTRL_TYPE_H264_SPS:
> + case V4L2_CTRL_TYPE_H264_PPS:
> + case V4L2_CTRL_TYPE_H264_SCALING_MATRIX:
> + case V4L2_CTRL_TYPE_H264_SLICE_PARAM:
> + case V4L2_CTRL_TYPE_H264_DECODE_PARAM:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -2172,6 +2199,21 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> case V4L2_CTRL_TYPE_U32:
> elem_size = sizeof(u32);
> break;
> + case V4L2_CTRL_TYPE_H264_SPS:
> + elem_size = sizeof(struct v4l2_ctrl_h264_sps);
> + break;
> + case V4L2_CTRL_TYPE_H264_PPS:
> + elem_size = sizeof(struct v4l2_ctrl_h264_pps);
> + break;
> + case V4L2_CTRL_TYPE_H264_SCALING_MATRIX:
> + elem_size = sizeof(struct v4l2_ctrl_h264_scaling_matrix);
> + break;
> + case V4L2_CTRL_TYPE_H264_SLICE_PARAM:
> + elem_size = sizeof(struct v4l2_ctrl_h264_slice_param);
> + break;
> + case V4L2_CTRL_TYPE_H264_DECODE_PARAM:
> + elem_size = sizeof(struct v4l2_ctrl_h264_decode_param);
> + break;
> case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> break;
> diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
> index 963c37b02363..9c223793a16a 100644
> --- a/include/media/v4l2-ctrls.h
> +++ b/include/media/v4l2-ctrls.h
> @@ -41,6 +41,11 @@ struct poll_table_struct;
> * @p_u16: Pointer to a 16-bit unsigned value.
> * @p_u32: Pointer to a 32-bit unsigned value.
> * @p_char: Pointer to a string.
> + * @p_h264_sps: Pointer to a struct v4l2_ctrl_h264_sps.
> + * @p_h264_pps: Pointer to a struct v4l2_ctrl_h264_pps.
> + * @p_h264_scal_mtrx: Pointer to a struct v4l2_ctrl_h264_scaling_matrix.
> + * @p_h264_slice_param: Pointer to a struct v4l2_ctrl_h264_slice_param.
> + * @p_h264_decode_param: Pointer to a struct v4l2_ctrl_h264_decode_param.
> * @p: Pointer to a compound value.
> */
> union v4l2_ctrl_ptr {
> @@ -50,6 +55,11 @@ union v4l2_ctrl_ptr {
> u16 *p_u16;
> u32 *p_u32;
> char *p_char;
> + struct v4l2_ctrl_h264_sps *p_h264_sps;
> + struct v4l2_ctrl_h264_pps *p_h264_pps;
> + struct v4l2_ctrl_h264_scaling_matrix *p_h264_scal_mtrx;
> + struct v4l2_ctrl_h264_slice_param *p_h264_slice_param;
> + struct v4l2_ctrl_h264_decode_param *p_h264_decode_param;
> void *p;
> };
>
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 23da8bfa7e6f..ac307c59683c 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -50,6 +50,8 @@
> #ifndef __LINUX_V4L2_CONTROLS_H
> #define __LINUX_V4L2_CONTROLS_H
>
> +#include <linux/types.h>
> +
> /* Control classes */
> #define V4L2_CTRL_CLASS_USER 0x00980000 /* Old-style 'user' controls */
> #define V4L2_CTRL_CLASS_MPEG 0x00990000 /* MPEG-compression controls */
> @@ -531,6 +533,12 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type {
> };
> #define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER (V4L2_CID_MPEG_BASE+381)
> #define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP (V4L2_CID_MPEG_BASE+382)
> +#define V4L2_CID_MPEG_VIDEO_H264_SPS (V4L2_CID_MPEG_BASE+383)
> +#define V4L2_CID_MPEG_VIDEO_H264_PPS (V4L2_CID_MPEG_BASE+384)
> +#define V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX (V4L2_CID_MPEG_BASE+385)
> +#define V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM (V4L2_CID_MPEG_BASE+386)
> +#define V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM (V4L2_CID_MPEG_BASE+387)
> +
> #define V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (V4L2_CID_MPEG_BASE+400)
> #define V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP (V4L2_CID_MPEG_BASE+401)
> #define V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP (V4L2_CID_MPEG_BASE+402)
> @@ -1078,6 +1086,162 @@ enum v4l2_detect_md_mode {
> #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3)
> #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DETECT_CLASS_BASE + 4)
>
> +/* Complex controls */
The right term is 'Compounds controls'.
> +
> +#define V4L2_H264_SPS_CONSTRAINT_SET0_FLAG 0x01
> +#define V4L2_H264_SPS_CONSTRAINT_SET1_FLAG 0x02
> +#define V4L2_H264_SPS_CONSTRAINT_SET2_FLAG 0x04
> +#define V4L2_H264_SPS_CONSTRAINT_SET3_FLAG 0x08
> +#define V4L2_H264_SPS_CONSTRAINT_SET4_FLAG 0x10
> +#define V4L2_H264_SPS_CONSTRAINT_SET5_FLAG 0x20
> +
> +#define V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE 0x01
> +#define V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS 0x02
> +#define V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO 0x04
> +#define V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED 0x08
> +#define V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY 0x10
> +#define V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD 0x20
> +#define V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE 0x40
Add a newline here. Same for the other structs below.
> +struct v4l2_ctrl_h264_sps {
> + __u8 profile_idc;
> + __u8 constraint_set_flags;
> + __u8 level_idc;
> + __u8 seq_parameter_set_id;
> + __u8 chroma_format_idc;
> + __u8 bit_depth_luma_minus8;
> + __u8 bit_depth_chroma_minus8;
> + __u8 log2_max_frame_num_minus4;
> + __u8 pic_order_cnt_type;
> + __u8 log2_max_pic_order_cnt_lsb_minus4;
There is a hole in the struct here. Is that OK? Are there alignment requirements?
> + __s32 offset_for_non_ref_pic;
> + __s32 offset_for_top_to_bottom_field;
> + __u8 num_ref_frames_in_pic_order_cnt_cycle;
> + __s32 offset_for_ref_frame[255];
Perhaps use a define instead of hardcoding 255? Not sure if that makes sense.
Same for other arrays below.
> + __u8 max_num_ref_frames;
> + __u16 pic_width_in_mbs_minus1;
> + __u16 pic_height_in_map_units_minus1;
> + __u8 flags;
> +};
You have to test the struct layout for 32 bit and 64 bit systems (the latter for both
64 bit arm and Intel). The layout should be the same for all of them since the
control framework does not support compat32 conversions for compound controls.
> +
> +#define V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE 0x0001
> +#define V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT 0x0002
> +#define V4L2_H264_PPS_FLAG_WEIGHTED_PRED 0x0004
> +#define V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT 0x0008
> +#define V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED 0x0010
> +#define V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT 0x0020
> +#define V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE 0x0040
> +#define V4L2_H264_PPS_FLAG_PIC_SCALING_MATRIX_PRESENT 0x0080
> +struct v4l2_ctrl_h264_pps {
> + __u8 pic_parameter_set_id;
> + __u8 seq_parameter_set_id;
> + __u8 num_slice_groups_minus1;
> + __u8 num_ref_idx_l0_default_active_minus1;
> + __u8 num_ref_idx_l1_default_active_minus1;
> + __u8 weighted_bipred_idc;
> + __s8 pic_init_qp_minus26;
> + __s8 pic_init_qs_minus26;
> + __s8 chroma_qp_index_offset;
> + __s8 second_chroma_qp_index_offset;
> + __u8 flags;
> +};
> +
> +struct v4l2_ctrl_h264_scaling_matrix {
> + __u8 scaling_list_4x4[6][16];
> + __u8 scaling_list_8x8[6][64];
> +};
> +
> +struct v4l2_h264_weight_factors {
> + __s8 luma_weight[32];
> + __s8 luma_offset[32];
> + __s8 chroma_weight[32][2];
> + __s8 chroma_offset[32][2];
> +};
> +
> +struct v4l2_h264_pred_weight_table {
> + __u8 luma_log2_weight_denom;
> + __u8 chroma_log2_weight_denom;
> + struct v4l2_h264_weight_factors weight_factors[2];
> +};
> +
> +enum v4l2_h264_slice_type {
> + V4L2_H264_SLICE_TYPE_P = 0,
> + V4L2_H264_SLICE_TYPE_B = 1,
> + V4L2_H264_SLICE_TYPE_I = 2,
> + V4L2_H264_SLICE_TYPE_SP = 3,
> + V4L2_H264_SLICE_TYPE_SI = 4,
> +};
> +
> +#define V4L2_SLICE_FLAG_FIELD_PIC 0x01
> +#define V4L2_SLICE_FLAG_BOTTOM_FIELD 0x02
> +#define V4L2_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED 0x04
> +#define V4L2_SLICE_FLAG_SP_FOR_SWITCH 0x08
> +struct v4l2_ctrl_h264_slice_param {
> + /* Size in bytes, including header */
> + __u32 size;
> + /* Offset in bits to slice_data() from the beginning of this slice. */
> + __u32 header_bit_size;
> +
> + __u16 first_mb_in_slice;
> + enum v4l2_h264_slice_type slice_type;
Avoid enums in a struct.
> + __u8 pic_parameter_set_id;
> + __u8 colour_plane_id;
> + __u16 frame_num;
> + __u16 idr_pic_id;
> + __u16 pic_order_cnt_lsb;
> + __s32 delta_pic_order_cnt_bottom;
> + __s32 delta_pic_order_cnt0;
> + __s32 delta_pic_order_cnt1;
> + __u8 redundant_pic_cnt;
> +
> + struct v4l2_h264_pred_weight_table pred_weight_table;
> + /* Size in bits of dec_ref_pic_marking() syntax element. */
> + __u32 dec_ref_pic_marking_bit_size;
> + /* Size in bits of pic order count syntax. */
> + __u32 pic_order_cnt_bit_size;
> +
> + __u8 cabac_init_idc;
> + __s8 slice_qp_delta;
> + __s8 slice_qs_delta;
> + __u8 disable_deblocking_filter_idc;
> + __s8 slice_alpha_c0_offset_div2;
> + __s8 slice_beta_offset_div2;
> + __u32 slice_group_change_cycle;
> +
> + __u8 num_ref_idx_l0_active_minus1;
> + __u8 num_ref_idx_l1_active_minus1;
> + /* Entries on each list are indices
> + * into v4l2_ctrl_h264_decode_param.dpb[]. */
> + __u8 ref_pic_list0[32];
> + __u8 ref_pic_list1[32];
> +
> + __u8 flags;
> +};
> +
> +/* If not set, this entry is unused for reference. */
> +#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE 0x01
> +#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM 0x02
> +struct v4l2_h264_dpb_entry {
> + __u32 buf_index; /* v4l2_buffer index */
> + __u16 frame_num;
> + __u16 pic_num;
> + /* Note that field is indicated by v4l2_buffer.field */
> + __s32 top_field_order_cnt;
> + __s32 bottom_field_order_cnt;
> + __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
> +};
> +
> +struct v4l2_ctrl_h264_decode_param {
> + __u32 num_slices;
> + __u8 idr_pic_flag;
> + __u8 nal_ref_idc;
> + __s32 top_field_order_cnt;
> + __s32 bottom_field_order_cnt;
> + __u8 ref_pic_list_p0[32];
> + __u8 ref_pic_list_b0[32];
> + __u8 ref_pic_list_b1[32];
> + struct v4l2_h264_dpb_entry dpb[16];
> +};
> +
> struct v4l2_ctrl_mpeg2_frame_hdr {
> __u32 slice_len;
> __u32 slice_pos;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 242a6bfa1440..4b4a1b25a0db 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -626,6 +626,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with start codes */
> #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264 without start codes */
> #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
> +#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */
> #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263 */
> #define V4L2_PIX_FMT_MPEG1 v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES */
> #define V4L2_PIX_FMT_MPEG2 v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES */
> @@ -1589,6 +1590,11 @@ struct v4l2_ext_control {
> __u8 __user *p_u8;
> __u16 __user *p_u16;
> __u32 __user *p_u32;
> + struct v4l2_ctrl_h264_sps __user *p_h264_sps;
> + struct v4l2_ctrl_h264_pps __user *p_h264_pps;
> + struct v4l2_ctrl_h264_scaling_matrix __user *p_h264_scal_mtrx;
> + struct v4l2_ctrl_h264_slice_param __user *p_h264_slice_param;
> + struct v4l2_ctrl_h264_decode_param __user *p_h264_decode_param;
> struct v4l2_ctrl_mpeg2_frame_hdr __user *p_mpeg2_frame_hdr;
> void __user *ptr;
> };
> @@ -1635,6 +1641,11 @@ enum v4l2_ctrl_type {
> V4L2_CTRL_TYPE_U8 = 0x0100,
> V4L2_CTRL_TYPE_U16 = 0x0101,
> V4L2_CTRL_TYPE_U32 = 0x0102,
> + V4L2_CTRL_TYPE_H264_SPS = 0x0103,
> + V4L2_CTRL_TYPE_H264_PPS = 0x0104,
> + V4L2_CTRL_TYPE_H264_SCALING_MATRIX = 0x0105,
> + V4L2_CTRL_TYPE_H264_SLICE_PARAM = 0x0106,
> + V4L2_CTRL_TYPE_H264_DECODE_PARAM = 0x0107,
> V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> };
>
>
Documentation is also missing, but I assume that will be added later in a separate
patch.
I *think* that the alignments of the structs are the same for all architectures,
but I would feel much happier if you can confirm that by testing this.
Regards,
Hans
^ permalink raw reply
* [PATCH] arm64: fix infinite stacktrace
From: Mark Rutland @ 2018-06-15 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LRH.2.02.1806141457200.4243@file01.intranet.prod.int.rdu2.redhat.com>
Hi,
On Thu, Jun 14, 2018 at 02:58:21PM -0400, Mikulas Patocka wrote:
> I've got this infinite stacktrace when debugging another problem:
> [ 908.795225] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 908.796176] 1-...!: (1 GPs behind) idle=952/1/4611686018427387904 softirq=1462/1462 fqs=355
> [ 908.797692] 2-...!: (1 GPs behind) idle=f42/1/4611686018427387904 softirq=1550/1551 fqs=355
> [ 908.799189] (detected by 0, t=2109 jiffies, g=130, c=129, q=235)
> [ 908.800284] Task dump for CPU 1:
> [ 908.800871] kworker/1:1 R running task 0 32 2 0x00000022
> [ 908.802127] Workqueue: writecache-writeabck writecache_writeback [dm_writecache]
> [ 908.820285] Call trace:
> [ 908.824785] __switch_to+0x68/0x90
> [ 908.837661] 0xfffffe00603afd90
> [ 908.844119] 0xfffffe00603afd90
> [ 908.850091] 0xfffffe00603afd90
> [ 908.854285] 0xfffffe00603afd90
> [ 908.863538] 0xfffffe00603afd90
> [ 908.865523] 0xfffffe00603afd90
>
> The machine just locked up and kept on printing the same line over and
> over again. This patch fixes it.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable at vger.kernel.org
Given this can only occur when there's a corrupted stack (where a frame
record points to itself), I'm not sure this requires a cc stable.
> Index: linux-2.6/arch/arm64/kernel/stacktrace.c
> ===================================================================
> --- linux-2.6.orig/arch/arm64/kernel/stacktrace.c
> +++ linux-2.6/arch/arm64/kernel/stacktrace.c
> @@ -56,6 +56,9 @@ int notrace unwind_frame(struct task_str
> frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp));
> frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
>
> + if (frame->fp <= fp)
> + return -EINVAL;
> +
Dave Martin had a series [1] which addressed this along with a number of
other cases where stack traces might not terminate.
Dave, do you plan to respin that?
Thanks,
Mark.
[1] https://lkml.kernel.org/r/1524503223-17576-1-git-send-email-Dave.Martin at arm.com
^ permalink raw reply
* v4.18-rc0: ohci-platform on n900 oops-es on reboot
From: Pavel Machek @ 2018-06-15 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614194449.GB17808@amd>
Hi!
> When I enable
>
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_OMAP3=y
> CONFIG_USB_OHCI_HCD_PLATFORM=y
>
> on n900 (I need it on droid4 and want common config), I get oops when
> attempting to reboot the system. I believe problem is there in v4.17,
> too.
>
> I'll try to build it as a module and debug, but if you have better
> idea, let me know...
It oopses in the ohci_shutdown, see the "oopses here" below.
Any ideas?
Pavel
+ printk(KERN_CRIT "ohci_shutdown... have pointers %lx, %lx\n", hcd, ohci);
ohci_writel(ohci, (u32) ~0, &ohci->regs->intrdisable);
+ printk(KERN_CRIT "ohci_shutdown... disable done\n");
+ udelay(1000);
+ printk(KERN_CRIT "ohci_shutdown... disable done\n");
/* Software reset, after which the controller goes into SUSPEND */
ohci_writel(ohci, OHCI_HCR, &ohci->regs->cmdstatus);
+ printk(KERN_CRIT "ohci_shutdown... writel done\n");
ohci_readl(ohci, &ohci->regs->cmdstatus); /* flush the writes */
+ /* It oopses here */
+ printk(KERN_CRIT "ohci_shutdown... readl done\n");
udelay(10);
+ printk(KERN_CRIT "ohci_shutdown... reset done\n");
ohci_writel(ohci, ohci->fminterval, &ohci->regs->fminterval);
ohci->rh_state = OHCI_RH_HALTED;
+
+ printk(KERN_CRIT "ohci_shutdown... all ok?\n");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/1cb8b88e/attachment.sig>
^ permalink raw reply
* [PATCH v2] regulator: core: Enable voltage balancing
From: Tony Lindgren @ 2018-06-15 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528886026-9457-1-git-send-email-m.purski@samsung.com>
Hi,
* Maciej Purski <m.purski@samsung.com> [180613 10:39]:
> Call regulator_balance_voltage() instead of set_voltage_rdev()
> in set_voltage_unlocked() and in enabling and disabling functions,
> but only if the regulator is coupled.
>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
>
> ---
> Changes in v2:
> - fix compile errors
> - make debug messages more informative
Thanks for updating it. This series still hangs after loading
modules on beagleboard-x15:
[ 26.679749] smps12: regulator_set_voltage: 3381
[ 26.684529] smps12: regulator_set_voltage_unlocked: 3045
[ 26.695616] smps12: _regulator_do_set_voltage: 2912
[ 26.701275] smps12: regulator_set_voltage: 3381
[ 26.706002] smps12: regulator_set_voltage_unlocked: 3045
[ 26.712349] smps12: _regulator_do_set_voltage: 2912
[ 26.719329] abb_mpu: regulator_set_voltage: 3381
[ 26.724105] abb_mpu: regulator_set_voltage_unlocked: 3045
So it seems to be the abb_mpu where it hangs?
Regards,
Tony
^ permalink raw reply
* [PATCH 5/6] arm64: dts: rockchip: Add missing cooling device properties for CPUs
From: Heiko Stübner @ 2018-06-15 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7f32cb0c3b77901cb5e37320a454e5e1dfed958.1527225682.git.viresh.kumar@linaro.org>
Am Freitag, 25. Mai 2018, 07:40:05 CEST schrieb Viresh Kumar:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Do minor rearrangement as well to keep ordering consistent.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
applied for 4.19
Thanks
Heiko
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: James Morse @ 2018-06-15 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51d3d738-cdf5-2992-bba5-c3e1f34096c2@infradead.org>
Hi Geoff,
On 13/06/18 19:22, Geoff Levand wrote:
> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> a work-around for HPE ProLiant m400 APEI firmware problems.
>
> The work-around disables APEI when CONFIG_ACPI_APEI is set and
> m400 firmware is detected. Without this fixup m400 systems
> experience errors like these on startup:
>
> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [Hardware Error]: event severity: fatal
> [Hardware Error]: Error 0, type: fatal
> [Hardware Error]: section_type: memory error
> [Hardware Error]: error_status: 0x0000000000001300
"Access to a memory address which is not mapped to any component"
> [Hardware Error]: error_type: 10, invalid address
> Kernel panic - not syncing: Fatal hardware error!
Why is this a problem?
Surely this is a valid description of an error.
(okay its not particularly useful without the physical address, but the address
is optional in that structure)
When does this happen during boot? This looks like a driver mapping some
non-existent physical address space to see if its device is present...
unsurprisingly this doesn't go well.
(might also be a typo in the DSDT)
Can't we pin down the driver that does this and fix it. Its either wrong for
everyone, or still broken after you disable APEI.
> It seems unlikely there will be any m400 firmware updates to fix
> this problem.
What is the problem? This patch looks like it shoots the messenger for bringing
bad news.
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..3c315c2c7476 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -31,6 +31,8 @@
> #include <asm/cpu_ops.h>
> #include <asm/smp_plat.h>
>
> +#include <acpi/apei.h>
> +
> #ifdef CONFIG_ACPI_APEI
> # include <linux/efi.h>
> # include <asm/pgtable.h>
> @@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
> + * problems.
> + */
> +static void __init acpi_fixup_m400_quirks(void)
> +{
> + acpi_status status;
> + struct acpi_table_header *header;
> +#if !defined(CONFIG_ACPI_APEI)
> + int hest_disable = HEST_DISABLED;
> +#endif
Yuck.
> +
> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> + return;
> +
> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> +
> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
You should match the affected range of OEM table revisions too, that way a
firmware upgrade should start working, instead of being permanently disabled
because we think its unlikely.
> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
How is the CPU implementer relevant?
You suggest a firmware-update would make this issue go away...
> + hest_disable = HEST_DISABLED;
> + pr_info("Disabled APEI for m400.\n");
> + }
> +
> + acpi_put_table(header);
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
Nothing arch-specific here. You're adding this to arch/arm64 because
drivers/acpi/apei doesn't have an existing quirks table?
Thanks,
James
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Maxime Ripard @ 2018-06-15 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615091650.GC3047@Red>
On Fri, Jun 15, 2018 at 11:16:50AM +0200, Corentin Labbe wrote:
> On Fri, Jun 15, 2018 at 11:04:12AM +0200, Maxime Ripard wrote:
> > On Fri, Jun 15, 2018 at 10:15:54AM +0200, Corentin Labbe wrote:
> > > On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> > > > On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > > > > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > > > > ending boot.
> > > > > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > > > > Since the crypto hardware is not implemented, all registers are read as 0.
> > > > > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> > > > >
> > > > > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > > > > more complex and prevent a case that never happen on real hardware.
> > > > >
> > > > > The best way to fix is to check at probe time if we run on a virtual
> > > > > machine with hardware emulated but non-implemented and prevent
> > > > > sun4i-ss to be loaded in that case.
> > > > > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > > > > disabled since they will fail crypto selftests.
> > > > >
> > > > > Tested-on: qemu-cubieboard
> > > > > Tested-on: cubieboard2
> > > > >
> > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > ---
> > > > > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > > > > 1 file changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > > index a81d89b3b7d8..a178e80adcf3 100644
> > > > > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > > > > * I expect to be a sort of Security System Revision number.
> > > > > * Since the A80 seems to have an other version of SS
> > > > > * this info could be useful
> > > > > + * Detect virtual machine with non-implemented hardware
> > > > > + * (qemu-cubieboard) by checking the register value after a write to it.
> > > > > + * On non-implemented hardware, all registers are read as 0.
> > > > > + * On real hardware we should have a value > 0.
> > > > > */
> > > > > writel(SS_ENABLED, ss->base + SS_CTL);
> > > > > v = readl(ss->base + SS_CTL);
> > > > > + if (!v) {
> > > > > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > > > > + err = -ENODEV;
> > > > > + goto error_rst;
> > > > > + }
> > > >
> > > > This is wrong way to tackle the issue. There's multiple reason why
> > > > this could happen (for example the device not being clocked, or
> > > > maintained in reset). There's nothing specific about qemu here, and
> > > > the fundamental issue isn't that the device isn't functional in qemu,
> > > > it's that qemu lies about which hardware it can emulate in the DT it
> > > > passes to the kernel.
> > > >
> > > > There's no way this can scale, alone from the fact that qemu should
> > > > patch the DT according to what it can do. Not trying to chase after
> > > > each and every device that is broken in qemu.
> > > >
> > > > NAK.
> > > >
> > >
> > > My fix detect also when the device is badly clocked.
> >
> > In which case, the proper fix is to enable the clock, not throw the
> > kernel's arm up in the air.
> >
>
> By badly I mean "not clocked" or "with the wrong frequencies".
>
> I could change the clock rate range test to exit (it issue only a
> warning for now). But I think this fix detect all cases and still
> permit someone to play with overclocking/downclocking.
You're still trying to fix the consequence when you should be fixing
the cause.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
From: Vivek Gautam @ 2018-06-15 10:53 UTC (permalink / raw)
To: linux-arm-kernel
Qualcomm SoCs have an additional level of cache called as
System cache or Last level cache[1]. This cache sits right
before the DDR, and is tightly coupled with the memory
controller.
The cache is available to all the clients present in the
SoC system. The clients request their slices from this system
cache, make it active, and can then start using it. For these
clients with smmu, to start using the system cache for
dma buffers and related page tables [2], few of the memory
attributes need to be set accordingly.
This change makes the related memory Outer-Shareable, and
updates the MAIR with necessary protection.
The MAIR attribute requirements are:
Inner Cacheablity = 0
Outer Cacheablity = 1, Write-Back Write Allocate
Outer Shareablity = 1
This change is a realisation of following changes
from downstream msm-4.9:
iommu: io-pgtable-arm: Support DOMAIN_ATTRIBUTE_USE_UPSTREAM_HINT
iommu: io-pgtable-arm: Implement IOMMU_USE_UPSTREAM_HINT
[1] https://patchwork.kernel.org/patch/10422531/
[2] https://patchwork.kernel.org/patch/10302791/
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 14 ++++++++++++++
drivers/iommu/io-pgtable-arm.c | 24 +++++++++++++++++++-----
drivers/iommu/io-pgtable.h | 4 ++++
include/linux/iommu.h | 4 ++++
4 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f7a96bcf94a6..8058e7205034 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -249,6 +249,7 @@ struct arm_smmu_domain {
struct mutex init_mutex; /* Protects smmu pointer */
spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */
struct iommu_domain domain;
+ bool has_sys_cache;
};
struct arm_smmu_option_prop {
@@ -862,6 +863,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_NO_DMA;
+ if (smmu_domain->has_sys_cache)
+ pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
smmu_domain->smmu = smmu;
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
@@ -1477,6 +1480,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
return 0;
+ case DOMAIN_ATTR_USE_SYS_CACHE:
+ *((int *)data) = smmu_domain->has_sys_cache;
+ return 0;
default:
return -ENODEV;
}
@@ -1506,6 +1512,14 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+ case DOMAIN_ATTR_USE_SYS_CACHE:
+ if (smmu_domain->smmu) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+ if (*((int *)data))
+ smmu_domain->has_sys_cache = true;
+ break;
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 010a254305dd..b2aee1828524 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -169,9 +169,11 @@
#define ARM_LPAE_MAIR_ATTR_DEVICE 0x04
#define ARM_LPAE_MAIR_ATTR_NC 0x44
#define ARM_LPAE_MAIR_ATTR_WBRWA 0xff
+#define ARM_LPAE_MAIR_ATTR_SYS_CACHE 0xf4
#define ARM_LPAE_MAIR_ATTR_IDX_NC 0
#define ARM_LPAE_MAIR_ATTR_IDX_CACHE 1
#define ARM_LPAE_MAIR_ATTR_IDX_DEV 2
+#define ARM_LPAE_MAIR_ATTR_IDX_SYS_CACHE 3
/* IOPTE accessors */
#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
@@ -442,6 +444,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
+ else if (prot & IOMMU_SYS_CACHE)
+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_SYS_CACHE
+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
+
} else {
pte = ARM_LPAE_PTE_HAP_FAULT;
if (prot & IOMMU_READ)
@@ -771,7 +777,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
u64 reg;
struct arm_lpae_io_pgtable *data;
- if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NO_DMA))
+ if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NO_DMA |
+ IO_PGTABLE_QUIRK_SYS_CACHE))
return NULL;
data = arm_lpae_alloc_pgtable(cfg);
@@ -779,9 +786,14 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
return NULL;
/* TCR */
- reg = (ARM_LPAE_TCR_SH_IS << ARM_LPAE_TCR_SH0_SHIFT) |
- (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_IRGN0_SHIFT) |
- (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_ORGN0_SHIFT);
+ if (cfg->quirks & IO_PGTABLE_QUIRK_SYS_CACHE) {
+ reg = (ARM_LPAE_TCR_SH_OS << ARM_LPAE_TCR_SH0_SHIFT) |
+ (ARM_LPAE_TCR_RGN_NC << ARM_LPAE_TCR_IRGN0_SHIFT);
+ } else {
+ reg = (ARM_LPAE_TCR_SH_IS << ARM_LPAE_TCR_SH0_SHIFT) |
+ (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_IRGN0_SHIFT);
+ }
+ reg |= (ARM_LPAE_TCR_RGN_WBWA << ARM_LPAE_TCR_ORGN0_SHIFT);
switch (ARM_LPAE_GRANULE(data)) {
case SZ_4K:
@@ -833,7 +845,9 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
(ARM_LPAE_MAIR_ATTR_WBRWA
<< ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_CACHE)) |
(ARM_LPAE_MAIR_ATTR_DEVICE
- << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
+ << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV)) |
+ (ARM_LPAE_MAIR_ATTR_SYS_CACHE
+ << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_SYS_CACHE));
cfg->arm_lpae_s1_cfg.mair[0] = reg;
cfg->arm_lpae_s1_cfg.mair[1] = 0;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 2df79093cad9..b5a398380e9f 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -71,12 +71,16 @@ struct io_pgtable_cfg {
* be accessed by a fully cache-coherent IOMMU or CPU (e.g. for a
* software-emulated IOMMU), such that pagetable updates need not
* be treated as explicit DMA data.
+ *
+ * IO_PGTABLE_QUIRK_SYS_CACHE: Override the attributes set in TCR for
+ * the page table walker when using system cache.
*/
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
#define IO_PGTABLE_QUIRK_TLBI_ON_MAP BIT(2)
#define IO_PGTABLE_QUIRK_ARM_MTK_4GB BIT(3)
#define IO_PGTABLE_QUIRK_NO_DMA BIT(4)
+ #define IO_PGTABLE_QUIRK_SYS_CACHE BIT(5)
unsigned long quirks;
unsigned long pgsize_bitmap;
unsigned int ias;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee6eb31..dacb9648e9b3 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -41,6 +41,9 @@
* if the IOMMU page table format is equivalent.
*/
#define IOMMU_PRIV (1 << 5)
+/* Use last level cache available with few architectures */
+#define IOMMU_SYS_CACHE (1 << 6)
+
struct iommu_ops;
struct iommu_group;
@@ -124,6 +127,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMU_ENABLE,
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING, /* two stages of translation */
+ DOMAIN_ATTR_USE_SYS_CACHE,
DOMAIN_ATTR_MAX,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Suzuki K Poulose @ 2018-06-15 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc8bb69d-8db4-87b7-adfb-589e1dd905c0@arm.com>
On 12/06/18 14:46, Julien Thierry wrote:
>
>
> On 25/05/18 11:48, Julien Thierry wrote:
>>
>>
>> On 25/05/18 11:41, Suzuki K Poulose wrote:
>>> On 25/05/18 11:39, Julien Thierry wrote:
>>>>
>>>>
>>>> On 25/05/18 11:36, Suzuki K Poulose wrote:
>>>>> On 25/05/18 11:17, Julien Thierry wrote:
>>>>>>
>>>>>>
>>>>>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>>>>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>>>>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>>>>>>> by priority.
>>>>>>>
>>>>>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>>>>>> the description ?
>>>>>>
>>>>>> More or less.
>>>>>>
>>>>>> It is just to have an easier condition in the rest of the series. Basically the PRIO masking feature is enabled if we have a GICv3 CPUIF working *and* the option was selected at build time. Before this meant that I was checking for the GIC_CPUIF cap inside #ifdefs (and putting alternatives depending on that inside #ifdefs as well).
>>>>>>
>>>>>> Having this as a separate feature feels easier to manage in the code. It also makes it clearer at boot time that the kernel will be using irq priorities (although I admit it was not the initial intention):
>>>>>>
>>>>>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>>>>>
>>>>>>
>>>>>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF gets detected as well.
>>>>>
>>>>> Well, you could always wrap the check like :
>>>>>
>>>>> static inline bool system_has_irq_priority_masking(void)
>>>>> {
>>>>> ?????return (IS_ENABLED(CONFIG_YOUR_CONFIG) && cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
>>>>> }
>>>>>
>>>>> and use it everywhere.
>>>>>
>>>>
>>>> Yes, but I can't use that in the asm parts that use alternatives and would need to surround them in #ifdef... :\
>>>
>>> I thought there is _ALTERNATIVE_CFG() to base the alternative depend on a CONFIG_xxx ?
>>> Doesn't that solve the problem ?
>>
>> Right, I didn't see that one. It should work yes.
>>
>> I'll try that when working on the next version.
>
> I've been trying to use this now, but I can't figure out how.
>
> The _ALTERNATIVE_CFG does not seem to work in assembly code (despite having its own definition for __ASSEMBLY__), and the alternative_insn does not seem to be suited for instructions that take operands (or more than one operand)
>
> If I am mistaken, can you provide an example of how to use this in assembly with instructions having more than 1 operand?
I am sorry, but I think the ALTERNATIVE_CFG is not the right one, as it
omits the entire block, if the CONFIG is not enabled. So you are left with
only three choices :
1) Use alternative call back
2) Stick to two separate caps.
3) Use #ifdef
Cheers
Suzuki
^ permalink raw reply
* [PATCH 11/11] i2c: rename i2c_lock_adapter to i2c_lock_root
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
The i2c_lock_adapter name is ambiguous since it is unclear if it
refers to the root adapter or the adapter you name in the argument.
The natural interpretation is the adapter you name in the argument,
but there are historical reasons for that not being the case; it
in fact locks the root adapter. Rename the function to indicate
what is really going on. Also rename i2c_unlock_adapter, of course.
This patch was generated with
grep -rlI --exclude-dir=.git 'i2c_\(un\)\?lock_adapter' \
| xargs sed -i 's/i2c_\(un\)\?lock_adapter/i2c_\1lock_root/g'
followed by some minor white-space touch-up.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/busses/i2c-brcmstb.c | 8 ++++----
drivers/i2c/busses/i2c-davinci.c | 4 ++--
drivers/i2c/busses/i2c-gpio.c | 12 ++++++------
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
drivers/i2c/busses/i2c-sprd.c | 8 ++++----
drivers/i2c/busses/i2c-tegra.c | 8 ++++----
drivers/i2c/i2c-core-slave.c | 8 ++++----
drivers/iio/temperature/mlx90614.c | 4 ++--
include/linux/i2c.h | 4 ++--
9 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 78792b4d6437..c42e14d4a127 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -689,9 +689,9 @@ static int brcmstb_i2c_suspend(struct device *dev)
{
struct brcmstb_i2c_dev *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_adapter(&i2c_dev->adapter);
+ i2c_lock_root(&i2c_dev->adapter);
i2c_dev->is_suspended = true;
- i2c_unlock_adapter(&i2c_dev->adapter);
+ i2c_unlock_root(&i2c_dev->adapter);
return 0;
}
@@ -700,10 +700,10 @@ static int brcmstb_i2c_resume(struct device *dev)
{
struct brcmstb_i2c_dev *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_adapter(&i2c_dev->adapter);
+ i2c_lock_root(&i2c_dev->adapter);
brcmstb_i2c_set_bsc_reg_defaults(i2c_dev);
i2c_dev->is_suspended = false;
- i2c_unlock_adapter(&i2c_dev->adapter);
+ i2c_unlock_root(&i2c_dev->adapter);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 75d6ab177055..9139d8da29ae 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -714,14 +714,14 @@ static int i2c_davinci_cpufreq_transition(struct notifier_block *nb,
dev = container_of(nb, struct davinci_i2c_dev, freq_transition);
- i2c_lock_adapter(&dev->adapter);
+ i2c_lock_root(&dev->adapter);
if (val == CPUFREQ_PRECHANGE) {
davinci_i2c_reset_ctrl(dev, 0);
} else if (val == CPUFREQ_POSTCHANGE) {
i2c_davinci_calc_clk_dividers(dev);
davinci_i2c_reset_ctrl(dev, 1);
}
- i2c_unlock_adapter(&dev->adapter);
+ i2c_unlock_root(&dev->adapter);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index 58abb3eced58..6983968735ca 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -82,18 +82,18 @@ static int fops_##wire##_get(void *data, u64 *val) \
{ \
struct i2c_gpio_private_data *priv = data; \
\
- i2c_lock_adapter(&priv->adap); \
+ i2c_lock_root(&priv->adap); \
*val = get##wire(&priv->bit_data); \
- i2c_unlock_adapter(&priv->adap); \
+ i2c_unlock_root(&priv->adap); \
return 0; \
} \
static int fops_##wire##_set(void *data, u64 val) \
{ \
struct i2c_gpio_private_data *priv = data; \
\
- i2c_lock_adapter(&priv->adap); \
+ i2c_lock_root(&priv->adap); \
set##wire(&priv->bit_data, val); \
- i2c_unlock_adapter(&priv->adap); \
+ i2c_unlock_root(&priv->adap); \
return 0; \
} \
DEFINE_DEBUGFS_ATTRIBUTE(fops_##wire, fops_##wire##_get, fops_##wire##_set, "%llu\n")
@@ -113,7 +113,7 @@ static int fops_incomplete_transfer_set(void *data, u64 addr)
/* ADDR (7 bit) + RD (1 bit) + SDA hi (1 bit) */
pattern = (addr << 2) | 3;
- i2c_lock_adapter(&priv->adap);
+ i2c_lock_root(&priv->adap);
/* START condition */
setsda(bit_data, 0);
@@ -129,7 +129,7 @@ static int fops_incomplete_transfer_set(void *data, u64 addr)
udelay(bit_data->udelay);
}
- i2c_unlock_adapter(&priv->adap);
+ i2c_unlock_root(&priv->adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 5d97510ee48b..6e8f8d2e847c 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -921,9 +921,9 @@ static int s3c24xx_i2c_cpufreq_transition(struct notifier_block *nb,
if ((val == CPUFREQ_POSTCHANGE && delta_f < 0) ||
(val == CPUFREQ_PRECHANGE && delta_f > 0)) {
- i2c_lock_adapter(&i2c->adap);
+ i2c_lock_root(&i2c->adap);
ret = s3c24xx_i2c_clockrate(i2c, &got);
- i2c_unlock_adapter(&i2c->adap);
+ i2c_unlock_root(&i2c->adap);
if (ret < 0)
dev_err(i2c->dev, "cannot find frequency (%d)\n", ret);
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index 4053259bccb8..58a4a263984f 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -590,9 +590,9 @@ static int __maybe_unused sprd_i2c_suspend_noirq(struct device *pdev)
{
struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
- i2c_lock_adapter(&i2c_dev->adap);
+ i2c_lock_root(&i2c_dev->adap);
i2c_dev->is_suspended = true;
- i2c_unlock_adapter(&i2c_dev->adap);
+ i2c_unlock_root(&i2c_dev->adap);
return pm_runtime_force_suspend(pdev);
}
@@ -601,9 +601,9 @@ static int __maybe_unused sprd_i2c_resume_noirq(struct device *pdev)
{
struct sprd_i2c *i2c_dev = dev_get_drvdata(pdev);
- i2c_lock_adapter(&i2c_dev->adap);
+ i2c_lock_root(&i2c_dev->adap);
i2c_dev->is_suspended = false;
- i2c_unlock_adapter(&i2c_dev->adap);
+ i2c_unlock_root(&i2c_dev->adap);
return pm_runtime_force_resume(pdev);
}
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 60292d243e24..1f2ed0dfbbaf 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1055,9 +1055,9 @@ static int tegra_i2c_suspend(struct device *dev)
{
struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
- i2c_lock_adapter(&i2c_dev->adapter);
+ i2c_lock_root(&i2c_dev->adapter);
i2c_dev->is_suspended = true;
- i2c_unlock_adapter(&i2c_dev->adapter);
+ i2c_unlock_root(&i2c_dev->adapter);
return 0;
}
@@ -1067,13 +1067,13 @@ static int tegra_i2c_resume(struct device *dev)
struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
int ret;
- i2c_lock_adapter(&i2c_dev->adapter);
+ i2c_lock_root(&i2c_dev->adapter);
ret = tegra_i2c_init(i2c_dev);
if (!ret)
i2c_dev->is_suspended = false;
- i2c_unlock_adapter(&i2c_dev->adapter);
+ i2c_unlock_root(&i2c_dev->adapter);
return ret;
}
diff --git a/drivers/i2c/i2c-core-slave.c b/drivers/i2c/i2c-core-slave.c
index 4a78c65e9971..fd68678f31c2 100644
--- a/drivers/i2c/i2c-core-slave.c
+++ b/drivers/i2c/i2c-core-slave.c
@@ -47,9 +47,9 @@ int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb)
client->slave_cb = slave_cb;
- i2c_lock_adapter(client->adapter);
+ i2c_lock_root(client->adapter);
ret = client->adapter->algo->reg_slave(client);
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_root(client->adapter);
if (ret) {
client->slave_cb = NULL;
@@ -69,9 +69,9 @@ int i2c_slave_unregister(struct i2c_client *client)
return -EOPNOTSUPP;
}
- i2c_lock_adapter(client->adapter);
+ i2c_lock_root(client->adapter);
ret = client->adapter->algo->unreg_slave(client);
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_root(client->adapter);
if (ret == 0)
client->slave_cb = NULL;
diff --git a/drivers/iio/temperature/mlx90614.c b/drivers/iio/temperature/mlx90614.c
index d619e8634a00..15e7b2c3e7d7 100644
--- a/drivers/iio/temperature/mlx90614.c
+++ b/drivers/iio/temperature/mlx90614.c
@@ -433,11 +433,11 @@ static int mlx90614_wakeup(struct mlx90614_data *data)
dev_dbg(&data->client->dev, "Requesting wake-up");
- i2c_lock_adapter(data->client->adapter);
+ i2c_lock_root(data->client->adapter);
gpiod_direction_output(data->wakeup_gpio, 0);
msleep(MLX90614_TIMING_WAKEUP);
gpiod_direction_input(data->wakeup_gpio);
- i2c_unlock_adapter(data->client->adapter);
+ i2c_unlock_root(data->client->adapter);
data->ready_timestamp = jiffies +
msecs_to_jiffies(MLX90614_TIMING_STARTUP);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index c9080d49e988..40db4b0accb8 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -757,13 +757,13 @@ i2c_unlock_bus(struct i2c_adapter *adapter, unsigned int flags)
}
static inline void
-i2c_lock_adapter(struct i2c_adapter *adapter)
+i2c_lock_root(struct i2c_adapter *adapter)
{
i2c_lock_bus(adapter, I2C_LOCK_ROOT_ADAPTER);
}
static inline void
-i2c_unlock_adapter(struct i2c_adapter *adapter)
+i2c_unlock_root(struct i2c_adapter *adapter)
{
i2c_unlock_bus(adapter, I2C_LOCK_ROOT_ADAPTER);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 10/11] mfd: 88pm860x-i2c: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/mfd/88pm860x-i2c.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/88pm860x-i2c.c b/drivers/mfd/88pm860x-i2c.c
index 84e313107233..8e54fc2dc29c 100644
--- a/drivers/mfd/88pm860x-i2c.c
+++ b/drivers/mfd/88pm860x-i2c.c
@@ -146,14 +146,14 @@ int pm860x_page_reg_write(struct i2c_client *i2c, int reg,
unsigned char zero;
int ret;
- i2c_lock_adapter(i2c->adapter);
+ i2c_lock_segment(i2c->adapter);
read_device(i2c, 0xFA, 0, &zero);
read_device(i2c, 0xFB, 0, &zero);
read_device(i2c, 0xFF, 0, &zero);
ret = write_device(i2c, reg, 1, &data);
read_device(i2c, 0xFE, 0, &zero);
read_device(i2c, 0xFC, 0, &zero);
- i2c_unlock_adapter(i2c->adapter);
+ i2c_unlock_segment(i2c->adapter);
return ret;
}
EXPORT_SYMBOL(pm860x_page_reg_write);
@@ -164,14 +164,14 @@ int pm860x_page_bulk_read(struct i2c_client *i2c, int reg,
unsigned char zero = 0;
int ret;
- i2c_lock_adapter(i2c->adapter);
+ i2c_lock_segment(i2c->adapter);
read_device(i2c, 0xfa, 0, &zero);
read_device(i2c, 0xfb, 0, &zero);
read_device(i2c, 0xff, 0, &zero);
ret = read_device(i2c, reg, count, buf);
read_device(i2c, 0xFE, 0, &zero);
read_device(i2c, 0xFC, 0, &zero);
- i2c_unlock_adapter(i2c->adapter);
+ i2c_unlock_segment(i2c->adapter);
return ret;
}
EXPORT_SYMBOL(pm860x_page_bulk_read);
--
2.11.0
^ permalink raw reply related
* [PATCH 09/11] media: tda18271: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/media/tuners/tda18271-common.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/tuners/tda18271-common.c b/drivers/media/tuners/tda18271-common.c
index 7e81cd887c13..93cce2bcd601 100644
--- a/drivers/media/tuners/tda18271-common.c
+++ b/drivers/media/tuners/tda18271-common.c
@@ -225,7 +225,7 @@ static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int len,
*/
if (lock_i2c) {
tda18271_i2c_gate_ctrl(fe, 1);
- i2c_lock_adapter(priv->i2c_props.adap);
+ i2c_lock_segment(priv->i2c_props.adap);
}
while (len) {
if (max > len)
@@ -246,7 +246,7 @@ static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int len,
len -= max;
}
if (lock_i2c) {
- i2c_unlock_adapter(priv->i2c_props.adap);
+ i2c_unlock_segment(priv->i2c_props.adap);
tda18271_i2c_gate_ctrl(fe, 0);
}
@@ -300,7 +300,7 @@ int tda18271_init_regs(struct dvb_frontend *fe)
* as those could cause bad things
*/
tda18271_i2c_gate_ctrl(fe, 1);
- i2c_lock_adapter(priv->i2c_props.adap);
+ i2c_lock_segment(priv->i2c_props.adap);
/* initialize registers */
switch (priv->id) {
@@ -516,7 +516,7 @@ int tda18271_init_regs(struct dvb_frontend *fe)
/* synchronize */
__tda18271_write_regs(fe, R_EP1, 1, false);
- i2c_unlock_adapter(priv->i2c_props.adap);
+ i2c_unlock_segment(priv->i2c_props.adap);
tda18271_i2c_gate_ctrl(fe, 0);
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH 08/11] media: tda1004x: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/media/dvb-frontends/tda1004x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda1004x.c b/drivers/media/dvb-frontends/tda1004x.c
index 58e3beff5adc..1e5c183cdd86 100644
--- a/drivers/media/dvb-frontends/tda1004x.c
+++ b/drivers/media/dvb-frontends/tda1004x.c
@@ -329,7 +329,7 @@ static int tda1004x_do_upload(struct tda1004x_state *state,
tda1004x_write_byteI(state, dspCodeCounterReg, 0);
fw_msg.addr = state->config->demod_address;
- i2c_lock_adapter(state->i2c);
+ i2c_lock_segment(state->i2c);
buf[0] = dspCodeInReg;
while (pos != len) {
// work out how much to send this time
@@ -342,14 +342,14 @@ static int tda1004x_do_upload(struct tda1004x_state *state,
fw_msg.len = tx_size + 1;
if (__i2c_transfer(state->i2c, &fw_msg, 1) != 1) {
printk(KERN_ERR "tda1004x: Error during firmware upload\n");
- i2c_unlock_adapter(state->i2c);
+ i2c_unlock_segment(state->i2c);
return -EIO;
}
pos += tx_size;
dprintk("%s: fw_pos=0x%x\n", __func__, pos);
}
- i2c_unlock_adapter(state->i2c);
+ i2c_unlock_segment(state->i2c);
/* give the DSP a chance to settle 03/10/05 Hac */
msleep(100);
--
2.11.0
^ permalink raw reply related
* [PATCH 07/11] media: rtl2830: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/media/dvb-frontends/rtl2830.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2830.c b/drivers/media/dvb-frontends/rtl2830.c
index 7bbfe11d11ed..85a8a9c4d020 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -24,9 +24,9 @@ static int rtl2830_bulk_write(struct i2c_client *client, unsigned int reg,
struct rtl2830_dev *dev = i2c_get_clientdata(client);
int ret;
- i2c_lock_adapter(client->adapter);
+ i2c_lock_segment(client->adapter);
ret = regmap_bulk_write(dev->regmap, reg, val, val_count);
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_segment(client->adapter);
return ret;
}
@@ -36,9 +36,9 @@ static int rtl2830_update_bits(struct i2c_client *client, unsigned int reg,
struct rtl2830_dev *dev = i2c_get_clientdata(client);
int ret;
- i2c_lock_adapter(client->adapter);
+ i2c_lock_segment(client->adapter);
ret = regmap_update_bits(dev->regmap, reg, mask, val);
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_segment(client->adapter);
return ret;
}
@@ -48,9 +48,9 @@ static int rtl2830_bulk_read(struct i2c_client *client, unsigned int reg,
struct rtl2830_dev *dev = i2c_get_clientdata(client);
int ret;
- i2c_lock_adapter(client->adapter);
+ i2c_lock_segment(client->adapter);
ret = regmap_bulk_read(dev->regmap, reg, val, val_count);
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_segment(client->adapter);
return ret;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 06/11] media: drxk_hard: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/media/dvb-frontends/drxk_hard.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/drxk_hard.c b/drivers/media/dvb-frontends/drxk_hard.c
index 5a26ad93be10..10e6bb158712 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -213,7 +213,7 @@ static inline u32 log10times100(u32 value)
static int drxk_i2c_lock(struct drxk_state *state)
{
- i2c_lock_adapter(state->i2c);
+ i2c_lock_segment(state->i2c);
state->drxk_i2c_exclusive_lock = true;
return 0;
@@ -224,7 +224,7 @@ static void drxk_i2c_unlock(struct drxk_state *state)
if (!state->drxk_i2c_exclusive_lock)
return;
- i2c_unlock_adapter(state->i2c);
+ i2c_unlock_segment(state->i2c);
state->drxk_i2c_exclusive_lock = false;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 05/11] media: af9013: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/media/dvb-frontends/af9013.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9013.c b/drivers/media/dvb-frontends/af9013.c
index 482bce49819a..a504697ff557 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -1312,10 +1312,10 @@ static int af9013_wregs(struct i2c_client *client, u8 cmd, u16 reg,
memcpy(&buf[3], val, len);
if (lock)
- i2c_lock_adapter(client->adapter);
+ i2c_lock_segment(client->adapter);
ret = __i2c_transfer(client->adapter, msg, 1);
if (lock)
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_segment(client->adapter);
if (ret < 0) {
goto err;
} else if (ret != 1) {
@@ -1353,10 +1353,10 @@ static int af9013_rregs(struct i2c_client *client, u8 cmd, u16 reg,
buf[2] = cmd;
if (lock)
- i2c_lock_adapter(client->adapter);
+ i2c_lock_segment(client->adapter);
ret = __i2c_transfer(client->adapter, msg, 2);
if (lock)
- i2c_unlock_adapter(client->adapter);
+ i2c_unlock_segment(client->adapter);
if (ret < 0) {
goto err;
} else if (ret != 2) {
--
2.11.0
^ permalink raw reply related
* [PATCH 04/11] input: rohm_bu21023: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/input/touchscreen/rohm_bu21023.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/rohm_bu21023.c b/drivers/input/touchscreen/rohm_bu21023.c
index bda0500c9b57..22d79db07234 100644
--- a/drivers/input/touchscreen/rohm_bu21023.c
+++ b/drivers/input/touchscreen/rohm_bu21023.c
@@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
msg[1].len = len;
msg[1].buf = buf;
- i2c_lock_adapter(adap);
+ i2c_lock_segment(adap);
for (i = 0; i < 2; i++) {
if (__i2c_transfer(adap, &msg[i], 1) < 0) {
@@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
}
}
- i2c_unlock_adapter(adap);
+ i2c_unlock_segment(adap);
return ret;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 03/11] i2c: mux: pca9541: switch to i2c_lock_segment
From: Peter Rosin @ 2018-06-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-1-peda@axentia.se>
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_segment. If the device does not sit behind a mux-locked mux,
the two locking variants are equivalent.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/muxes/i2c-mux-pca9541.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c b/drivers/i2c/muxes/i2c-mux-pca9541.c
index 6a39adaf433f..74c560ed44cc 100644
--- a/drivers/i2c/muxes/i2c-mux-pca9541.c
+++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
@@ -345,11 +345,11 @@ static int pca9541_probe(struct i2c_client *client,
/*
* I2C accesses are unprotected here.
- * We have to lock the adapter before releasing the bus.
+ * We have to lock the I2C segment before releasing the bus.
*/
- i2c_lock_adapter(adap);
+ i2c_lock_segment(adap);
pca9541_release_bus(client);
- i2c_unlock_adapter(adap);
+ i2c_unlock_segment(adap);
/* Create mux adapter */
--
2.11.0
^ 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