* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Florian Fainelli @ 2017-01-16 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115191632.GD5643@lunn.ch>
On 01/15/2017 11:16 AM, Andrew Lunn wrote:
>>> What exactly is the relationship between these devices (a ascii-art tree
>>> or sysfs tree output might be nice) so I can try to understand what is
>>> going on here.
>
> Hi Greg, Florian
>
> A few diagrams and trees which might help understand what is going on.
>
> The first diagram comes from the 2008 patch which added all this code:
>
> +-----------+ +-----------+
> | | RGMII | |
> | +-------+ +------ 1000baseT MDI ("WAN")
> | | | 6-port +------ 1000baseT MDI ("LAN1")
> | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> | | | |
> +-----------+ +-----------+
>
> We have an ethernet switch and a host CPU. The switch is connected to
> the CPU in two different ways. RGMII allows us to get Ethernet frames
> from the CPU into the switch. MIImgmt, is the management bus normally
> used for Ethernet PHYs, but Marvell switches also use it for Managing
> switches.
>
> The diagram above is the simplest setup. You can have multiple
> Ethernet switches, connected together via switch ports. Each switch
> has its own MIImgmt connect to the CPU, but there is only one RGMII
> link.
>
> When this code was designed back in 2008, it was decided to represent
> this is a platform device, and it has a platform_data, which i have
> slightly edited to keep it simple:
>
> struct dsa_platform_data {
> /*
> * Reference to a Linux network interface that connects
> * to the root switch chip of the tree.
> */
> struct device *netdev;
>
> /*
> * Info structs describing each of the switch chips
> * connected via this network interface.
> */
> int nr_chips;
> struct dsa_chip_data *chip;
> };
>
> This netdev is the CPU side of the RGMII interface.
>
> Each switch has a dsa_chip_data, again edited:
>
> struct dsa_chip_data {
> /*
> * How to access the switch configuration registers.
> */
> struct device *host_dev;
> int sw_addr;
> ...
> }
>
> The host_dev is the CPU side of the MIImgmt, and we have the address
> the switch is using on the bus.
>
> During probe of this platform device, we need to get from the
> struct device *netdev to a struct net_device *dev.
>
> So the code looks in the device net class to find the device
>
> | | | |-- f1074000.ethernet
> | | | | |-- deferred_probe
> | | | | |-- driver -> ../../../../../bus/platform/drivers/mvneta
> | | | | |-- driver_override
> | | | | |-- modalias
> | | | | |-- net
> | | | | | `-- eth1
> | | | | | |-- addr_assign_type
> | | | | | |-- address
> | | | | | |-- addr_len
> | | | | | |-- broadcast
> | | | | | |-- carrier
> | | | | | |-- carrier_changes
> | | | | | |-- deferred_probe
> | | | | | |-- device -> ../../../f1074000.ethernet
>
> and then use container_of() to get the net_device.
>
> Similarly, the code needs to get from struct device *host_dev to a struct mii_bus *.
>
> | | | |-- f1072004.mdio
> | | | | |-- deferred_probe
> | | | | |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> | | | | |-- driver_override
> | | | | |-- mdio_bus
> | | | | | `-- f1072004.mdio-mi
> | | | | | |-- deferred_probe
> | | | | | |-- device -> ../../../f1072004.mdio
>
Thanks Andrew! Greg, does that make it clearer how these devices
references are used, do you still think the way this is done is wrong,
too cautious, or valid?
--
Florian
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2017-01-16 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116115309.GE1510@arm.com>
Hello Will,
On 1/16/2017 4:53 AM, Will Deacon wrote:
> On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
>> SEA exceptions are often caused by an uncorrected hardware
>> error, and are handled when data abort and instruction abort
>> exception classes have specific values for their Fault Status
>> Code.
>> When SEA occurs, before killing the process, go through
>> the handlers registered in the notification list.
>> Update fault_info[] with specific SEA faults so that the
>> new SEA handler is used.
>>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> arch/arm64/include/asm/system_misc.h | 13 ++++++++
>> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
>> 2 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
>> index 57f110b..e7f3440 100644
>> --- a/arch/arm64/include/asm/system_misc.h
>> +++ b/arch/arm64/include/asm/system_misc.h
>> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>>
>> #endif /* __ASSEMBLY__ */
>>
>> +/*
>> + * The functions below are used to register and unregister callbacks
>> + * that are to be invoked when a Synchronous External Abort (SEA)
>> + * occurs. An SEA is raised by certain fault status codes that have
>> + * either data or instruction abort as the exception class, and
>> + * callbacks may be registered to parse or handle such hardware errors.
>> + *
>> + * Registered callbacks are run in an interrupt/atomic context. They
>> + * are not allowed to block or sleep.
>> + */
>> +int register_sea_notifier(struct notifier_block *nb);
>> +void unregister_sea_notifier(struct notifier_block *nb);
> I still don't understand why you need notifiers for this. You register
> precisely one hook in the series.
I didn't see a response to my last comment on the previous series so I
just left it in for this series.
The notifier usage is consistent with the GHES code for SCI errors which
are also only used a single
time in the code. If you think making the call directly is a better
option I will remove the notifiers.
>> #endif /* __ASM_SYSTEM_MISC_H */
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 05d2bd7..81039c7 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -39,6 +39,22 @@
>> #include <asm/pgtable.h>
>> #include <asm/tlbflush.h>
>>
>> +/*
>> + * GHES SEA handler code may register a notifier call here to
>> + * handle HW error record passed from platform.
>> + */
>> +static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
>> +
>> +int register_sea_notifier(struct notifier_block *nb)
>> +{
>> + return atomic_notifier_chain_register(&sea_handler_chain, nb);
>> +}
>> +
>> +void unregister_sea_notifier(struct notifier_block *nb)
>> +{
>> + atomic_notifier_chain_unregister(&sea_handler_chain, nb);
>> +}
>> +
>> static const char *fault_name(unsigned int esr);
>>
>> #ifdef CONFIG_KPROBES
>> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> return 1;
>> }
>>
>> +/*
>> + * This abort handler deals with Synchronous External Abort.
>> + * It calls notifiers, and then returns "fault".
>> + */
>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> +{
>> + struct siginfo info;
>> +
>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> + fault_name(esr), esr, addr);
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + info.si_code = 0;
>> + info.si_addr = (void __user *)addr;
>> + arm64_notify_die("", regs, &info, esr);
>> +
>> + return 0;
>> +}
>> +
>> static const struct fault_info {
>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>> int sig;
>> @@ -502,22 +540,22 @@ static const struct fault_info {
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
>> - { do_bad, SIGBUS, 0, "synchronous external abort" },
>> + { do_sea, SIGBUS, 0, "synchronous external abort" },
>> { do_bad, SIGBUS, 0, "unknown 17" },
>> { do_bad, SIGBUS, 0, "unknown 18" },
>> { do_bad, SIGBUS, 0, "unknown 19" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error" },
>> + { do_sea, SIGBUS, 0, "level 0 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 1 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 2 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 3 SEA (translation table walk)" },
> Perhaps I wasn't clear enough in my previous review, but please expand the
> acronym for strings and comments.
Sorry, I will expand these.
>> + { do_sea, SIGBUS, 0, "synchronous parity or ECC err" },
> s/err/error/
>
> Will
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Christopher Spinrath @ 2017-01-16 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
Hi Philipp,
ping? It would be very nice if you comment on this patch before it's too
late for v4.11 (which is soon, I think).
Cheers,
Christopher
On 12/30/2016 03:27 PM, Shawn Guo wrote:
> On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath at rwth-aachen.de wrote:
>> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>>
>> Apart from the already enabled Designware HDMI port, the Utilite Pro
>> has a second display pipeline which has the following shape:
>>
>> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
>> --> HDMI connector.
>> Enable support for it.
>>
>> In addition, since this pipeline is hardwired to IPU1, sever the link
>> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
>> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
>> possible to drive both displays at high resolution due to the bandwidth
>> limitations of a single IPU.
>>
>> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> @Philipp, can you help review the changes?
>
>> ---
>>
>> Hi all,
>>
>> the removal of the link between IPU1 and the Designware HDMI encoder is the
>> result of a discussion I had with Philipp Zabel:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>>
>> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
>> approach has at least one disadvantage: if the resolution is low enough such
>> that a single IPU can handle both displays then muxing both displays to IPU1
>> would reduce the power consumption.
>>
>> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
>> solution since I'm not aware of any OS/driver that is capable of switching IPUs
>> or can handle the bandwidth limitation in a sane way. In particular, Linux is
>> unusable when both displays are supposed to be driven at high resolution and
>> both muxing options for the DW HDMI are available (this is not a userspace
>> issue; the system becomes almost unresponsive as soon as the kernel sets the
>> initial resolution).
>>
>> Cheers,
>> Christopher
>>
>> P.S.: this patch depends on the tfp410 bridge driver which has recently been
>> merged into drm-next.
>
> v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
>>
>> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> index 2200994..69bdd82 100644
>> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> @@ -59,6 +59,33 @@
>> rtc1 = &snvs_rtc;
>> };
>>
>> + encoder {
>> + compatible = "ti,tfp410";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint {
>> + remote-endpoint = <¶llel_display_out>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint {
>> + remote-endpoint = <&hdmi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>> pinctrl-names = "default";
>> @@ -72,6 +99,19 @@
>> };
>> };
>>
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> +
>
> The newline is unnecessary.
>
>> + type = "a";
>> + ddc-i2c-bus = <&i2c_dvi_ddc>;
>> +
>> + port {
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> + };
>> +
>> i2cmux {
>> compatible = "i2c-mux-gpio";
>> pinctrl-names = "default";
>> @@ -105,8 +145,46 @@
>> #size-cells = <0>;
>> };
>> };
>> +
>> + parallel-display {
>> + compatible = "fsl,imx-parallel-display";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ipu1>;
>> +
>
> Ditto
>
> I can fix them up if I get a Reviewed-by tag from Philipp on this
> version.
>
> Shawn
>
>> + interface-pix-fmt = "rgb24";
>> +
>> + port at 0 {
>> + reg = <0>;
>> +
>> + parallel_display_in: endpoint {
>> + remote-endpoint = <&ipu1_di0_disp0>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + reg = <1>;
>> +
>> + parallel_display_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + };
>> + };
>> + };
>> };
>>
>> +/*
>> + * A single IPU is not able to drive both display interfaces available on the
>> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
>> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
>> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
>> + * IPU2 instead of IPU1.
>> + */
>> +/delete-node/&ipu1_di0_hdmi;
>> +/delete-node/&hdmi_mux_0;
>> +/delete-node/&ipu1_di1_hdmi;
>> +/delete-node/&hdmi_mux_1;
>> +
>> &hdmi {
>> ddc-i2c-bus = <&i2c2>;
>> status = "okay";
>> @@ -151,6 +229,39 @@
>> >;
>> };
>>
>> + pinctrl_ipu1: ipu1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
>> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
>> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
>> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
>> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
>> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
>> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
>> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
>> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
>> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
>> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
>> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
>> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
>> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
>> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
>> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
>> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
>> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
>> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
>> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
>> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
>> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
>> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
>> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
>> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
>> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
>> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
>> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
>> + >;
>> + };
>> +
>> pinctrl_uart2: uart2grp {
>> fsl,pins = <
>> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
>> @@ -194,6 +305,10 @@
>> };
>> };
>>
>> +&ipu1_di0_disp0 {
>> + remote-endpoint = <¶llel_display_in>;
>> +};
>> +
>> &pcie {
>> pcie at 0,0 {
>> reg = <0x000000 0 0 0 0>;
>> --
>> 2.10.2
>>
^ permalink raw reply
* [PATCH V7 10/10] arm/arm64: KVM: add guest SEA support
From: Baicar, Tyler @ 2017-01-16 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98ed774f-fcc1-e10d-05ef-ebea52e916d2@arm.com>
Hello Marc,
On 1/16/2017 4:58 AM, Marc Zyngier wrote:
> Hi Tyler,
>
> On 12/01/17 18:15, Tyler Baicar wrote:
>> Currently external aborts are unsupported by the guest abort
>> handling. Add handling for SEAs so that the host kernel reports
>> SEAs which occur in the guest kernel.
>>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> ---
>> arch/arm/include/asm/kvm_arm.h | 1 +
>> arch/arm/include/asm/system_misc.h | 5 +++++
>> arch/arm/kvm/mmu.c | 18 ++++++++++++++++--
>> arch/arm64/include/asm/kvm_arm.h | 1 +
>> arch/arm64/include/asm/system_misc.h | 2 ++
>> arch/arm64/mm/fault.c | 13 +++++++++++++
>> 6 files changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
>> index e22089f..33a77509 100644
>> --- a/arch/arm/include/asm/kvm_arm.h
>> +++ b/arch/arm/include/asm/kvm_arm.h
>> @@ -187,6 +187,7 @@
>> #define FSC_FAULT (0x04)
>> #define FSC_ACCESS (0x08)
>> #define FSC_PERM (0x0c)
>> +#define FSC_EXTABT (0x10)
>>
>> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>> #define HPFAR_MASK (~0xf)
>> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
>> index a3d61ad..ea45d94 100644
>> --- a/arch/arm/include/asm/system_misc.h
>> +++ b/arch/arm/include/asm/system_misc.h
>> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>>
>> #endif /* !__ASSEMBLY__ */
>>
>> +static inline int handle_guest_sea(unsigned long addr, unsigned int esr)
>> +{
>> + return -1;
>> +}
>> +
>> #endif /* __ASM_ARM_SYSTEM_MISC_H */
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index e9a5c0e..1152966 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -29,6 +29,7 @@
>> #include <asm/kvm_asm.h>
>> #include <asm/kvm_emulate.h>
>> #include <asm/virt.h>
>> +#include <asm/system_misc.h>
>>
>> #include "trace.h"
>>
>> @@ -1441,8 +1442,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>
>> /* Check the stage-2 fault is trans. fault or write fault */
>> fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
>> - if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
>> - fault_status != FSC_ACCESS) {
>> +
>> + /* The host kernel will handle the synchronous external abort. There
>> + * is no need to pass the error into the guest.
>> + */
>> + if (fault_status == FSC_EXTABT) {
>> + if(handle_guest_sea((unsigned long)fault_ipa,
>> + kvm_vcpu_get_hsr(vcpu))) {
>> + kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
>> + kvm_vcpu_trap_get_class(vcpu),
>> + (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
>> + (unsigned long)kvm_vcpu_get_hsr(vcpu));
> So there's one thing I don't like here, which is that we just gave the
> guest a very nice way to pollute the host's kernel log with spurious
> messages. So I'd rather make it silent, or at the very least rate limited.
Before this patch, if a guest exits with FSC_EXTABT, then the below
print for
"Unsupported FSC..." would happen. So this print isn't really adding any
noise
that isn't already there. Also, this print would only happen if
handle_guest_sea
fails. If you still think this print should be removed then I will
remove it though.
>> + return -EFAULT;
>> + }
>> + } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
>> + fault_status != FSC_ACCESS) {
>> kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
>> kvm_vcpu_trap_get_class(vcpu),
>> (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>> index 4b5c977..be0efb6 100644
>> --- a/arch/arm64/include/asm/kvm_arm.h
>> +++ b/arch/arm64/include/asm/kvm_arm.h
>> @@ -201,6 +201,7 @@
>> #define FSC_FAULT ESR_ELx_FSC_FAULT
>> #define FSC_ACCESS ESR_ELx_FSC_ACCESS
>> #define FSC_PERM ESR_ELx_FSC_PERM
>> +#define FSC_EXTABT ESR_ELx_FSC_EXTABT
>>
>> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>> #define HPFAR_MASK (~UL(0xf))
>> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
>> index e7f3440..27816cb 100644
>> --- a/arch/arm64/include/asm/system_misc.h
>> +++ b/arch/arm64/include/asm/system_misc.h
>> @@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>> int register_sea_notifier(struct notifier_block *nb);
>> void unregister_sea_notifier(struct notifier_block *nb);
>>
>> +int handle_guest_sea(unsigned long addr, unsigned int esr);
>> +
>> #endif /* __ASM_SYSTEM_MISC_H */
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 81039c7..fa8d4d7 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
>> }
>>
>> /*
>> + * Handle Synchronous External Aborts that occur in a guest kernel.
>> + */
>> +int handle_guest_sea(unsigned long addr, unsigned int esr)
>> +{
>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> + fault_name(esr), esr, addr);
> Same here.
I will remove this print.
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> * Dispatch a data abort to the relevant handler.
>> */
>> asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
>>
> Thanks,
>
> M.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Laurent Pinchart @ 2017-01-16 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573344-11609-2-git-send-email-yannick.fertre@st.com>
Hi Yannick,
Thank you for the patch.
On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
> .../devicetree/bindings/display/st,ltdc.txt | 57 ++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
>
> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
> 100644
> index 0000000..20e89da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> @@ -0,0 +1,57 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- st-display-subsystem: Master device for DRM sub-components
> + This device must be the parent of all the sub-components and is
> responsible
> + of bind them.
Why do you need this ? At a quick glance the ltdc node should be enough.
> + Required properties:
> + - compatible: "st,display-subsystem"
> + - ranges: to allow probing of subdevices
> +
> +- ltdc_host: lcd-tft display controller host
> + must be a sub-node of st-display-subsystem
> + Required properties:
> + - compatible: "st,ltdc"
> + - reg: Physical base address of the IP registers and length of memory
> mapped region.
> + - clocks: from common clock binding: handle hardware IP needed clocks,
> the
> + number of clocks may depend of the SoC type.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: names of the clocks listed in clocks property in the same
> + order.
You need to define the required/optional clocks with their names here. If they
vary depending on the SoC, the DT bindings document need to list them for each
SoC.
> + - resets: resets to be used by the device
> + See ../reset/reset.txt for details.
> + - reset-names: names of the resets listed in resets property in the same
> + order.
> + Required nodes:
> + - Video port for RGB output.
> +
> +Example:
> +
> +/ {
> + ...
> + soc {
> + ...
> + st-display-subsystem {
> + compatible = "st,display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + dma-ranges;
> +
> + ltdc_host: stm32-ltdc at 40016800 {
> + compatible = "st,ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = <&rcc 314>;
> + clocks = <&rcc 1 8>;
> + clock-names = "clk-lcd";
> + status = "disabled";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> + ...
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/3] dts: teach newer i.MX machines to have the i.MX35 type watchdog
From: Uwe Kleine-König @ 2017-01-16 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CjkW1SdSAcSOj8Uws-xjoh=iZ1Ey9dwBdOdBzQLS6h8w@mail.gmail.com>
On Mon, Jan 16, 2017 at 04:35:26PM -0200, Fabio Estevam wrote:
> On Mon, Jan 9, 2017 at 7:50 AM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> > Only i.MX35 and newer feature a WMCR register that should be written to. Older
> > SoCs hang when this address is written.
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
>
> Only a minor nit: Subject could: ARM: dts: imx: teach...
Ack. To reference the commit id of the first patch in the third I can
prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 17/24] media: imx: Add CSI subdev driver
From: Steve Longerbeam @ 2017-01-16 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484578988.8415.160.camel@pengutronix.de>
On 01/16/2017 07:03 AM, Philipp Zabel wrote:
> On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:
>> This is a media entity subdevice for the i.MX Camera
>> Serial Interface module.
> s/Serial/Sensor/
done.
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Kconfig | 13 +
>> drivers/staging/media/imx/Makefile | 2 +
>> drivers/staging/media/imx/imx-csi.c | 644 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 659 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-csi.c
>>
>> diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
>> index bfde58d..ce2d2c8 100644
>> --- a/drivers/staging/media/imx/Kconfig
>> +++ b/drivers/staging/media/imx/Kconfig
>> @@ -6,3 +6,16 @@ config VIDEO_IMX_MEDIA
>> Say yes here to enable support for video4linux media controller
>> driver for the i.MX5/6 SOC.
>>
>> +if VIDEO_IMX_MEDIA
>> +menu "i.MX5/6 Media Sub devices"
>> +
>> +config VIDEO_IMX_CAMERA
> s/CAMERA/CSI/ ?
done.
>> + tristate "i.MX5/6 Camera driver"
> i.MX5/6 Camera Sensor Interface driver
done.
>
>> +
>> +struct csi_priv {
>> + struct device *dev;
>> + struct ipu_soc *ipu;
>> + struct imx_media_dev *md;
>> + struct v4l2_subdev sd;
>> + struct media_pad pad[CSI_NUM_PADS];
>> + struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
>> + struct v4l2_mbus_config sensor_mbus_cfg;
>> + struct v4l2_rect crop;
>> + struct ipu_csi *csi;
>> + int csi_id;
>> + int input_pad;
>> + int output_pad;
>> + bool power_on; /* power is on */
>> + bool stream_on; /* streaming is on */
>> +
>> + /* the sink for the captured frames */
>> + struct v4l2_subdev *sink_sd;
>> + enum ipu_csi_dest dest;
>> + struct v4l2_subdev *src_sd;
> src_sd is not used except that its presence marks an enabled input link.
> -> could be changed to bool.
For now I prefer to keep it a pointer to the src/sink subdevs.
At some point the CSI may have some reason to know the
identity of the source.
>
>> + struct v4l2_ctrl_handler ctrl_hdlr;
>> + struct imx_media_fim *fim;
>> +
>> + /* the attached sensor at stream on */
>> + struct imx_media_subdev *sensor;
>> +};
>> +
>> +static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
>> +{
>> + return container_of(sdev, struct csi_priv, sd);
>> +}
>> +
>> +/* Update the CSI whole sensor and active windows */
>> +static int csi_setup(struct csi_priv *priv)
>> +{
>> + struct v4l2_mbus_framefmt infmt;
>> +
>> + ipu_csi_set_window(priv->csi, &priv->crop);
>> +
>> + /*
>> + * the ipu-csi doesn't understand ALTERNATE, but it only
>> + * needs to know whether the stream is interlaced, so set
>> + * to INTERLACED if infmt field is ALTERNATE.
>> + */
>> + infmt = priv->format_mbus[priv->input_pad];
>> + if (infmt.field == V4L2_FIELD_ALTERNATE)
>> + infmt.field = V4L2_FIELD_INTERLACED;
> That should be SEQ_TB/BT depending on video standard.
fixed.
>> +
>> +static int csi_s_stream(struct v4l2_subdev *sd, int enable)
>> +{
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + int ret = 0;
>> +
>> + if (!priv->src_sd || !priv->sink_sd)
>> + return -EPIPE;
>> +
>> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
> These could be silenced a bit.
yeah, I think it is time for that. I've silenced all the
v4l2_info()'s for stream on/off, power on/off, as well
as some others.
>
>> +static int csi_s_power(struct v4l2_subdev *sd, int on)
>> +{
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + int ret = 0;
>> +
>> + v4l2_info(sd, "power %s\n", on ? "ON" : "OFF");
>> +
>> + if (priv->fim && on != priv->power_on)
>> + ret = imx_media_fim_set_power(priv->fim, on);
>> +
>> + if (!ret)
>> + priv->power_on = on;
>> + return ret;
>> +}
> Is this called multiple times? I'd expect a poweron during open and a
> poweroff during close, so no need for priv->power_on.
It is actually called multiple times. The s_power subdev callbacks are
made every time there is a new link established, in the imx-media core's
link_notify(), in order to re-establish power to the active subdevs in the
new pipeline.
This might change after I look into using v4l2_pipeline_pm_use().
>
>> +static int csi_link_setup(struct media_entity *entity,
>> + const struct media_pad *local,
>> + const struct media_pad *remote, u32 flags)
>> +{
>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + struct v4l2_subdev *remote_sd;
>> +
>> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
>> + local->entity->name);
>> +
>> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
>> +
>> + if (local->flags & MEDIA_PAD_FL_SINK) {
>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>> + if (priv->src_sd)
>> + return -EBUSY;
>> + priv->src_sd = remote_sd;
>> + } else {
>> + priv->src_sd = NULL;
>> + }
>> +
>> + return 0;
>> + }
>> +
>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>> + if (priv->sink_sd)
>> + return -EBUSY;
>> + priv->sink_sd = remote_sd;
>> + } else {
>> + priv->sink_sd = NULL;
>> + return 0;
>> + }
>> +
>> + /* set CSI destination */
>> + switch (remote_sd->grp_id) {
>> + case IMX_MEDIA_GRP_ID_SMFC0:
>> + case IMX_MEDIA_GRP_ID_SMFC1:
>> + case IMX_MEDIA_GRP_ID_SMFC2:
>> + case IMX_MEDIA_GRP_ID_SMFC3:
> With removal of the SMFC entities, CSI0 could be fixed to SMFC0 and CSI1
> to the SMFC2 channel.
right, I'll do that.
>
> [...]
>> +static int csi_set_fmt(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_format *sdformat)
>> +{
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + struct v4l2_mbus_framefmt *infmt, *outfmt;
>> + struct v4l2_rect crop;
>> + int ret;
>> +
>> + if (sdformat->pad >= CSI_NUM_PADS)
>> + return -EINVAL;
>> +
>> + if (priv->stream_on)
>> + return -EBUSY;
>> +
>> + infmt = &priv->format_mbus[priv->input_pad];
>> + outfmt = &priv->format_mbus[priv->output_pad];
>> +
>> + if (sdformat->pad == priv->output_pad) {
>> + sdformat->format.code = infmt->code;
>> + sdformat->format.field = infmt->field;
>> + crop.left = priv->crop.left;
>> + crop.top = priv->crop.top;
>> + crop.width = sdformat->format.width;
>> + crop.height = sdformat->format.height;
>> + ret = csi_try_crop(priv, &crop);
>> + if (ret)
>> + return ret;
>> + sdformat->format.width = crop.width;
>> + sdformat->format.height = crop.height;
>> + }
>> +
>> + if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
> Should there be some limitations on the format here?
done, I've added call to v4l_bound_align_image(), passing
it the min/max frame sizes. CSI's sensor/active frame size
register fields are 12 bits, so max is 4096 for both width and
height.
Steve
^ permalink raw reply
* Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker
From: Pavel Machek @ 2017-01-16 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201701150100.54214@pali>
Hi!
> > So regression seems to be between v4.9 and v4.10. Any ideas?
>
> Interesting... seems there are no sound relevant changes after v4.9.
>
> Looks like there are only three commits after v4.9 for sound/soc which
> are built for Nokia N900:
I'm at ce38207f161513ee3d2bd3860489f07ebe65bc78, which is already
broken, and first broken commit by Linus.
> e411b0b5eb9b65257a050eac333d181d6e00e2c6
Can't revert that easily.
> e7aa450fe17890e59db7d3c2d8eff5b6b41fc531
This can be reverted. Lets try. Did not help.
> 63c3194b82530bd71fd49db84eb7ab656b8d404a
Commit older than this one fails, IIRC.
> Maybe something not related to sound/soc could broke it?
Its definitely caused by something merged here:
commit ce38207f161513ee3d2bd3860489f07ebe65bc78
Merge: a9042de 995c6a7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Dec 14 11:14:28 2016 -0800
So it should be easy to find out..
Best regards,
Pavel
--
(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/20170116/a8bf5045/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 00/18] FSI device driver introduction
From: christopher.lee.bostic at gmail.com @ 2017-01-16 21:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (8):
drivers/fsi: Kick off master scan via sysfs
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Remove all scanned devices during master unregister
drivers/fsi: Add FSI bus documentation
drivers/fsi: Add documentation for GPIO based FSI master
drivers/fsi: Document FSI master sysfs files in ABI
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (10):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add FSI crc calculators to library
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
Changes for v3:
- Patch set contained an invalid 18/18 test patch not
meant for community review, corrected.
Changes for v2:
- Change from atomic global for master number to ida simple
interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
instead the device_for_each_child method available in the
bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
implementing it.
- Document all comptible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interfac for all optional GPIO pins.
Documentation/ABI/testing/sysfs-bus-fsi | 6 +
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 +++
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 23 +
drivers/fsi/Makefile | 3 +
drivers/fsi/fsi-core.c | 494 +++++++++++++++++++
drivers/fsi/fsi-master-gpio.c | 530 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 39 ++
include/linux/crc-fsi.h | 29 ++
include/linux/fsi.h | 60 +++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 ++
14 files changed, 1352 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/crc-fsi.h
create mode 100644 include/linux/fsi.h
create mode 100644 lib/crc-fsi.c
--
1.8.2.2
^ permalink raw reply
* [PATCH v3 02/18] drivers/fsi: Add device & driver definitions
From: christopher.lee.bostic at gmail.com @ 2017-01-16 21:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Jeremy Kerr <jk@ozlabs.org>
Add structs for fsi devices & drivers, and struct device conversion
functions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
include/linux/fsi.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index 47aa181..f73886a 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -17,6 +17,17 @@
#include <linux/device.h>
+struct fsi_device {
+ struct device dev;
+};
+
+struct fsi_driver {
+ struct device_driver drv;
+};
+
+#define to_fsi_dev(devp) container_of(devp, struct fsi_device, dev)
+#define to_fsi_drv(drvp) container_of(drvp, struct fsi_driver, drv)
+
extern struct bus_type fsi_bus_type;
#endif /* LINUX_FSI_H */
--
1.8.2.2
^ permalink raw reply related
* [PATCH 2/3] dts: teach newer i.MX machines to have the i.MX35 type watchdog
From: Vladimir Zapolskiy @ 2017-01-16 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116204337.j67oeknraas7ryib@pengutronix.de>
On 01/16/2017 10:43 PM, Uwe Kleine-K?nig wrote:
> On Mon, Jan 16, 2017 at 04:35:26PM -0200, Fabio Estevam wrote:
>> On Mon, Jan 9, 2017 at 7:50 AM, Uwe Kleine-K?nig
>> <u.kleine-koenig@pengutronix.de> wrote:
>>> Only i.MX35 and newer feature a WMCR register that should be written to. Older
>>> SoCs hang when this address is written.
>>>
>>> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>>
>> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
>>
>> Only a minor nit: Subject could: ARM: dts: imx: teach...
>
> Ack. To reference the commit id of the first patch in the third I can
> prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
>
This is too early for changes, which are not reviewed by Linux watchdog masters.
As I emphasized multiple times in our discussions your series is organized
improperly, it has interdependencies between DTS and driver, it lacks
atomicity feature of a proper fix, in the middle it breaks backward compatibility
with old DTB, all that makes it impossible to send an atomic fix for linux-stable,
some of the changes are captured from mine ones without preserving the authorship
or even a reported-by credit.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v5 0/2] qcom OTG regulator support
From: Sebastian Reichel @ 2017-01-16 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJOFmgySF7T1N6PDiw2rsQ+n68_k7n_M0TzXZe4S7PxTHmRapA@mail.gmail.com>
Hi Stephen,
On Wed, Dec 28, 2016 at 02:06:18PM -0800, Stephen Boyd wrote:
> On Mon, Oct 17, 2016 at 5:42 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > This is a resend/resurrection of Tim's patches to add support
> > for the OTG regulator on some of qcom's PMICs[1]. I've made
> > some minor modifications to the driver to make it work, but
> > otherwise it works fine with my USB otg testing. Changes
> > are noted in a maintainer tag.
> >
> > Tim, did you want to me to fix the name? I pulled these from patchwork
> > and it seems you sent it as "Bird, Tim" which may have not been
> > intentional.
> >
>
> Can this be picked up for v4.11? Tim hasn't responded so I assume it's
> fine with the name.
Yes, sorry for the delay. I just queued it.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/46db8ef7/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-01-16 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ9RitNC7ihC8ckJgV+49kaHk=W9tgdNBSjEfydhQS46A@mail.gmail.com>
On 01/13/2017 08:40 PM, Rob Herring wrote:
> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>>
>>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>
>>>> Rob,
>>>>
>>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>>
>>>>>>
>>>>>> Rob,
>>>>>>
>>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> v2->v3:
>>>>>>>> Update k2g_pds node docs to show it should be a child of pmmc
>>>>>>>> node.
>>>>>>>> In early versions a phandle was used to point to pmmc and
>>>>>>>> docs
>>>>>>>> still
>>>>>>>> incorrectly showed this.
>>>>>>>>
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59
>>>>>>>> ++++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 151 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..4c9064e512cb
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,59 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that
>>>>>>>> is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use
>>>>>>>> of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +Because this relies on the TI SCI protocol to communicate with the
>>>>>>>> PMMC
>>>>>>>> it
>>>>>>>> +must be a child of the pmmc node.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +
>>>>>>>> +Example (K2G):
>>>>>>>> +-------------
>>>>>>>> + pmmc: pmmc {
>>>>>>>> + compatible = "ti,k2g-sci";
>>>>>>>> + ...
>>>>>>>> +
>>>>>>>> + k2g_pds: k2g_pds {
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As I've already stated before, this goes in power-domain cells. When
>>>>>>> you
>>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>>> you
>>>>>>> you need to specify the ID for each of them in phandle args. This is
>>>>>>> how
>>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You think the reasoning for doing it this way provided by both Ulf and
>>>>>> myself on v2 [1] is not valid then?
>>>>>>
>>>>>> From Ulf:
>>>>>>
>>>>>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>>> in DT and assign to a device node. The only difference here, is that
>>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>>
>>>>>
>>>>>
>>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>>> do with DT bindings.
>>>>>
>>>>>> From me:
>>>>>>
>>>>>> Yes, you've pretty much hit it on the head. It is not an index into a
>>>>>> list
>>>>>> of genpds but rather identifies the device *within* a single genpd. It
>>>>>> is
>>>>>> a
>>>>>> property specific to each device that resides in a ti-sci-genpd, not a
>>>>>> mapping describing which genpd the device belongs to. The generic power
>>>>>> domain binding is concerned with mapping the device to a specific
>>>>>> genpd,
>>>>>> which is does fine for us, but we have a sub mapping for devices that
>>>>>> exist
>>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>>
>>>>>>
>>>>>> So to summarize, the genpd framework does interpret the phandle arg as
>>>>>> an
>>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>>> but
>>>>>> this is not what I am trying to do, we have multiple devices within
>>>>>> this
>>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>>
>>>>>
>>>>>
>>>>> Fix the genpd framework rather than work around it in DT.
>>>>
>>>>
>>>>
>>>> I still disagree that this has nothing to do with DT bindings, as the
>>>> current DT binding represents something different already. I am trying to
>>>> extend it to give me additional information needed for our platforms. Are
>>>> you saying that we should break what the current DT binding already
>>>> represents to mean something else?
>>>
>>>
>>> No idea because what's the current binding? From the patch, looks like
>>> a new binding to me.
>>
>>
>> Yes, ti,sci-id is a new binding. I am referring to the current meaning of
>> the "power-domains" binding, which is where you are asking this property to
>> be added, in "power-domains" cells. This is documented here [1] in the
>> kernel, although looking at it I must admit it is not very clear.
>>
>> The power-domains cell represents an offset into an array of power domains,
>> if you choose to use it. That's what the genpd framework is hard coded to
>> interpret it as. This is correct, as it is an index into a static list of
>> power domains, used to identify which power domain a device belongs to,
>> which is exactly what the genpd framework itself is concerned with. This is
>> already how it is used in the kernel today.
>
> Strictly speaking, the cells are purely for the interpretation of the
> phandle they are associated with. If some controller wants to have 20
> cells, then it could assuming a good reason. The reality is we tend to
> align the meaning of the cells. If genpd is interpreting the cells and
> not letting the driver for the power domain controller interpret them,
> then still, genpd needs to be fixed.
Ok, perhaps the genpd folks on the thread can jump in here with any
thoughts that they have.
>
> IIRC, initially it was said genpd required 0 cells, hence my confusion.
>
>> My ti,sci-id is not an index into a list of power domains, so it should not
>> go in the power-domains cells and go against what the power-domains binding
>> says that the cell expects. We have one single power domain, and the new
>> ti,sci-id binding is not something the genpd framework itself is concerned
>> with as it's our property to identify a device inside a power domain, not to
>> identify which power domain it is associated with.
>
> What is the id used for? I can understand why you need to know what
> power domain a device is in (as power-domains identifies), but not
> what devices are in a power domain.
We have a system control processor that provides power management
services to the OS and it responsible for handling the power state of
each device. This control happens over a communication interface we have
called TI SCI (implemented at drivers/firmware/ti-sci.c). The
communication protocol uses these ids to identify each device within the
power domain so that the control processor can do what is necessary to
enable that device.
Regards,
Dave
>
> Rob
>
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Florian Fainelli @ 2017-01-16 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNVQ9Rbuwf1i54h7uLLdkUvyGibmfJpD6zRjt1gYiQD7Hw@mail.gmail.com>
+Rafal,
On 01/12/2017 08:55 PM, Abylay Ospan wrote:
> Hi Florian,
>
>> Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
>> should fill in of_nodes accordingly, if not, that's a bug that must be
>> fixed at the BCMA layer.
>
> yes, this is a source of the problem. Devices allocated in
> 'bcma_bus_scan' but of_node doesn't assigned.
> Is some code missing in drivers/bcma/ which should assign of_node ?
bcma_of_fill_device() is responsible for assigning the core of_node
pointer based on the core discovered. It sounds like we may have to add
an entry under the "axi" bus node for the PCIe RC, very much like these
ones already exist:
gmac0: ethernet at 24000 {
reg = <0x24000 0x800>;
};
gmac1: ethernet at 25000 {
reg = <0x25000 0x800>;
};
gmac2: ethernet at 26000 {
reg = <0x26000 0x800>;
};
gmac3: ethernet at 27000 {
reg = <0x27000 0x800>;
};
Without that, you indeed do not have a proper linkage between the BCMA
discovered device and its of_node pointer.
Can you give it a spin?
>
> I can suggest following "hacky" patch for this (works for me):
>
> Author: Abylay Ospan <aospan@netup.ru>
> Date: Fri Jan 13 07:24:13 2017 +0300
>
> bcma: force assign 'of_node' for devices on the bus
>
> prevent other code to fail if no 'of_node' defined
>
> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index 2c1798e..4fe1c92 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -301,6 +301,11 @@ void bcma_init_bus(struct bcma_bus *bus)
> static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
> {
> int err;
> + struct device * dev;
> +
> + dev = bcma_bus_get_host_dev(bus);
> + if (dev && !core->dev.of_node)
> + core->dev.of_node = dev->of_node;
>
>
> if it's ok I will send this patch in separate email.
>
>>
>>>
>>>>
>>>>>
>>>>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>>>>> ---
>>>>> drivers/pci/host/pcie-iproc.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>>>> index 3ebc025..f2836a9 100644
>>>>> --- a/drivers/pci/host/pcie-iproc.c
>>>>> +++ b/drivers/pci/host/pcie-iproc.c
>>>>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>>>>> const int na = 3, ns = 2;
>>>>> int rlen;
>>>>>
>>>>> + if (!node)
>>>>> + return -ENOENT;
>>>>> +
>>>>> parser->node = node;
>>>>> parser->pna = of_n_addr_cells(node);
>>>>> parser->np = parser->pna + na + ns;
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Florian
>
>
>
--
Florian
^ permalink raw reply
* [linux-sunxi] [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Ondřej Jirman @ 2017-01-16 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116191449.50397-2-icenowy@aosc.xyz>
Dne 16.1.2017 v 20:14 Icenowy Zheng napsal(a):
> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> controller.
>
> The original driver wired it to OHCI/EHCI controller; however, as the
> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> unusable.
>
> Rename the register (according to its function and the name in BSP
> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> can support both peripheral and host mode (although the host mode of
> MUSB is buggy).
>
> The register that is renamed is now unused, as its initial value is just
> MUSB mode. However, when OHCI/EHCI mode support is added, the register
> can be used again.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> drivers/phy/phy-sun4i-usb.c | 25 +++++++++----------------
> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bf28a0fdd569..6b193a635c6b 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,7 +49,7 @@
> #define REG_PHYBIST 0x08
> #define REG_PHYTUNE 0x0c
> #define REG_PHYCTL_A33 0x10
> -#define REG_PHY_UNK_H3 0x20
> +#define REG_PHY_OTGCTL 0x20
You have added REG_PHY_OTGCTL, but it is not used below.
regards,
o.
> #define REG_PMU_UNK1 0x10
>
> @@ -269,23 +269,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> }
>
> - if (data->cfg->type == sun8i_h3_phy) {
> - if (phy->index == 0) {
> - val = readl(data->base + REG_PHY_UNK_H3);
> - writel(val & ~1, data->base + REG_PHY_UNK_H3);
> - }
> - } else {
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> - data->cfg->disc_thresh, 2);
> - }
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->cfg->disc_thresh, 2);
>
> sun4i_usb_phy_passby(phy, 1);
>
>
^ permalink raw reply
* [PATCH v3 0/2] ARM: at91: properly handle LPDDR poweroff
From: Sebastian Reichel @ 2017-01-16 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025093759.20913-1-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Tue, Oct 25, 2016 at 11:37:57AM +0200, Alexandre Belloni wrote:
> This patch set improves LPDDR support on SoCs using the Atmel MPDDR controller.
>
> LPDDR memories can only handle up to 400 uncontrolled power offs in their
> life. The proper power off sequence has to be applied before shutting down the
> SoC.
>
> I'm not too happy with the code duplication but this is a design choice
> that has been made before because both shutdown controllers are really
> different apart from the shutdown itself.
>
> I guess it is still better than slowly killing the LPDDR.
Sorry, I totally forgot about this one. I queued it into my for-next
branch using an immutable topic branch, in case you need the patch
against the arm include to also go through arm-soc. Feel free to use
or ignore it:
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/ib-psy-arm-at91-4.11
for you to fetch changes up to 0b0408745e7ff24757cbfd571d69026c0ddb803c:
power: reset: at91-poweroff: timely shutdown LPDDR memories (2017-01-16 23:21:33 +0100)
----------------------------------------------------------------
immutable branch between ARM at91 and power-supply for v4.11
----------------------------------------------------------------
Alexandre Belloni (2):
ARM: at91: define LPDDR types
power: reset: at91-poweroff: timely shutdown LPDDR memories
drivers/power/reset/Kconfig | 2 +-
drivers/power/reset/at91-poweroff.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/power/reset/at91-sama5d2_shdwc.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
include/soc/at91/at91sam9_ddrsdr.h | 3 +++
4 files changed, 105 insertions(+), 3 deletions(-)
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/b06d0fb1/attachment.sig>
^ permalink raw reply
* arm: Add livepatch arch specific code
From: Jessica Yu @ 2017-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LSU.2.20.1701161733531.17768@pobox.suse.cz>
+++ Miroslav Benes [16/01/17 17:47 +0100]:
>On Tue, 6 Dec 2016, Abel Vesa wrote:
>
>> klp_get_ftrace_location is used by ftrace to get the entry for a
>> specific function from the mcount list. klp_arch_set_pc is used
>> to set the pc from the regs passed as an argument to the
>> ftrace_ops_no_ops function to the starting address of the patched
>> function. klp_write_module_reloc is not doing anything at this
>> moment.
>>
>> Signed-off-by: Abel Vesa <abelvesa@linux.com>
>> ---
>> MAINTAINERS | 3 +++
>> arch/arm/include/asm/livepatch.h | 46 ++++++++++++++++++++++++++++++++++++++++
>> arch/arm/kernel/livepatch.c | 43 +++++++++++++++++++++++++++++++++++++
>> 3 files changed, 92 insertions(+)
>> create mode 100644 arch/arm/include/asm/livepatch.h
>> create mode 100644 arch/arm/kernel/livepatch.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index bd182a1..d43b790 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7466,12 +7466,15 @@ M: Josh Poimboeuf <jpoimboe@redhat.com>
>> M: Jessica Yu <jeyu@redhat.com>
>> M: Jiri Kosina <jikos@kernel.org>
>> M: Miroslav Benes <mbenes@suse.cz>
>> +M: Abel Vesa <abelvesa@linux.com>
>> R: Petr Mladek <pmladek@suse.com>
>> S: Maintained
>> F: kernel/livepatch/
>> F: include/linux/livepatch.h
>> F: arch/x86/include/asm/livepatch.h
>> F: arch/x86/kernel/livepatch.c
>> +F: arch/arm/include/asm/livepatch.h
>> +F: arch/arm/kernel/livepatch.c
>> F: Documentation/livepatch/
>> F: Documentation/ABI/testing/sysfs-kernel-livepatch
>> F: samples/livepatch/
>
>Thanks for the offer but I think we manage quite well ;)
>
>> diff --git a/arch/arm/include/asm/livepatch.h b/arch/arm/include/asm/livepatch.h
>> new file mode 100644
>> index 0000000..d4e3ff0
>> --- /dev/null
>> +++ b/arch/arm/include/asm/livepatch.h
>> @@ -0,0 +1,46 @@
>> +/*
>> + * livepatch.h - arm specific Kernel Live Patching Core
>> + *
>> + * Copyright (C) 2016 Abel Vesa <abelvesa@linux.com>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef _ASM_ARM_LIVEPATCH_H
>> +#define _ASM_ARM_LIVEPATCH_H
>> +
>> +#include <asm/setup.h>
>> +#include <linux/module.h>
>> +#include <linux/ftrace.h>
>> +
>> +static inline int klp_check_compiler_support(void)
>> +{
>> + return 0;
>> +}
>> +
>> +int klp_write_module_reloc(struct module *mod, unsigned long type,
>> + unsigned long loc, unsigned long value);
>
>This is not needed. See below.
>
>> +
>> +static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
>> +{
>> + regs->uregs[15] = ip;
>> +}
>> +
>> +#define klp_get_ftrace_location klp_get_ftrace_location
>> +static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
>> +{
>> + return ftrace_location_range(faddr, faddr + 24);
>
>Comment here about +24 would be great. See similar in powerpc header file.
>
>> +}
>> +
>> +#endif /* _ASM_ARM_LIVEPATCH_H */
>> diff --git a/arch/arm/kernel/livepatch.c b/arch/arm/kernel/livepatch.c
>> new file mode 100644
>> index 0000000..0656cd6
>> --- /dev/null
>> +++ b/arch/arm/kernel/livepatch.c
>> @@ -0,0 +1,43 @@
>> +/*
>> + * livepatch.c - arm specific Kernel Live Patching Core
>> + *
>> + * Copyright (C) 2016 Abel Vesa <abelvesa@linux.com>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/ftrace.h>
>> +#include <asm/elf.h>
>> +#include <asm/livepatch.h>
>> +#include <asm/insn.h>
>> +#include <asm/ftrace.h>
>> +
>> +/**
>> + * klp_write_module_reloc() - write a relocation in a module
>> + * @mod: module in which the section to be modified is found
>> + * @type: ELF relocation type (see asm/elf.h)
>> + * @loc: address that the relocation should be written to
>> + * @value: relocation value (sym address + addend)
>> + *
>> + * This function writes a relocation to the specified location for
>> + * a particular module.
>> + */
>> +int klp_write_module_reloc(struct module *mod, unsigned long type,
>> + unsigned long loc, unsigned long value)
>> +{
>> + /* Not implemented yet */
>> + return 0;
>> +}
>
>This whole file is not needed. Livepatching uses kernel's internal
>apply_relocate_add() for dealing with relocations. The only thing you need
>to do is to make sure that all needed arch-specific info is preserved
>during a module loading. Specifically mod_arch_specific structure needs to
>be examined in this respect.
Yup. Since we rely on apply_relocate_add() to apply relocations, just
make sure that you preserve anything (e.g., plt tables) you need to
make that call post-module init. In the case of s390, we needed to
make sure we kept mod->arch.syminfo, so that the call to
apply_relocate_add() would succeed.
>But apply_relocate_add() is not implemented on arm yet. I guess it would
>nice to have it... otherwise we could get to an unpleasant situation.
>Livepatch module can rely on its livepatching relocations (that is, there
>are some). apply_relocate_add() returns 0 on arm, so everything seems to
>be nice and then boom some time later.
Doesn't it return -ENOEXEC? MODULES_USE_ELF_RELA is not defined
on arm, I think (see moduleloader.h).
>The question is what happens with normal modules. There are no SHT_RELA
>records probably.
For arm, I think there are only SHT_REL relocation sections
(MODULES_USE_ELF_REL is set instead of MODULES_USE_ELF_RELA), so
during apply_relocations() in load_module(), only apply_relocate()
should be called, and not apply_relocate_add().
Hm, I guess that means if we want livepatch support for the
architectures that don't support RELA relocations, we would have to
check if the section is SHT_REL or SHT_RELA before calling the right
apply_relocate* function.
Jessica
^ permalink raw reply
* [RFC PATCH] arm64: defconfig: enable SMMUv3 config
From: Zhou Wang @ 2017-01-17 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587CF1A8.8020508@hisilicon.com>
On 2017/1/17 0:15, Wei Xu wrote:
> Hi Arnd,
>
> On 2017/1/13 16:58, Arnd Bergmann wrote:
>> On Friday, January 13, 2017 3:35:54 PM CET Wei Xu wrote:
>>> On 2017/1/12 9:47, Catalin Marinas wrote:
>>>> On Thu, Jan 12, 2017 at 08:36:12AM +0800, Zhou Wang wrote:
>>>>> On 2017/1/9 19:50, Zhou Wang wrote:
>>>>>> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
>>>>>> ---
>>>>>> arch/arm64/configs/defconfig | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>>>>> index 869dded..3520c50 100644
>>>>>> --- a/arch/arm64/configs/defconfig
>>>>>> +++ b/arch/arm64/configs/defconfig
>>>>>> @@ -440,6 +440,7 @@ CONFIG_PLATFORM_MHU=y
>>>>>> CONFIG_BCM2835_MBOX=y
>>>>>> CONFIG_HI6220_MBOX=y
>>>>>> CONFIG_ARM_SMMU=y
>>>>>> +CONFIG_ARM_SMMU_V3=y
>>>>>> CONFIG_RASPBERRYPI_POWER=y
>>>>>> CONFIG_QCOM_SMEM=y
>>>>>> CONFIG_QCOM_SMD=y
>>>>>
>>>>> I just happened to find there is no SMMUv3 config in arm64 defconfig.
>>>>>
>>>>> Maybe we should add it in defconfig or I miss something.
>>>>
>>>
>>> Hi Arnd,
>>>
>>>> It looks fine to me but it's usually the arm-soc guys picking the
>>>> defconfig patches.
>>>>
>>>
>>> It is fine to me.
>>> Is it OK for me to pick up this or will you directly pick up this?
>>> Thanks!
>>
>> Either way works for me. I usually recommend platform maintainers
>> picking up patches and then sending them on to arm at kernel.org,
>> as that gets our attention quicker. A patch that gets sent with
>> me personally on Cc might get lost in the email.
>
> In this case I will pick up it.
Many thanks,
Regards,
Zhou
> Thanks!
>
> Best Regards,
> Wei
>
>>
>> Arnd
>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply
* [Question] A question about arm64 pte
From: Yisheng Xie @ 2017-01-17 1:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116143601.GB6832@e104818-lin.cambridge.arm.com>
Hi Catalin,
Thanks again for your reply, and I will check the logic once more.
Thanks
Yisheng Xie
On 2017/1/16 22:36, Catalin Marinas wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>> I have question about arm64 pte.
>>>
>>> I assume the context is ARMv8.0 (without hardware DBM support).
>>
>> Yes.
>>>
>>>> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
>>>> and PTE_DIRTY is to mark whether the page is dirty.
>>>> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
>>>
>>> That's what set_pte_at() does.
>>>
>>
>> So if we mmap a memory region use /dev/mem like:
>> fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>> addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
>>
>> The PTE_RDONLY will be set? Right ?
>
> Possibly, I haven't checked mmap_mem(). However, that's what you would
> get with an anonymous mmap() as well.
>
>> However?when use memset to write the region it still works well, and
>> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
>> PTE_RDONLY before write that page ?
>
> See handle_pte_fault(). On the first access to a writable+clean page
> (PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
> and, if pte_write() is true (your case), it calls pte_mkdirty(). The
> subsequently called ptep_set_access_flags() function would clear
> PTE_RDONLY, giving you a writable mapping.
>
^ permalink raw reply
* [Question] A question about arm64 pte
From: Yisheng Xie @ 2017-01-17 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116125724.GA16265@e103986-lin>
On 2017/1/16 20:57, Steve Capper wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>> hi Catalin,
>> Thank you so much for you reply.
>>
>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>> I have question about arm64 pte.
>>>
>>> I assume the context is ARMv8.0 (without hardware DBM support).
>>
>> Yes.
>>>
>>>> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
>>>> and PTE_DIRTY is to mark whether the page is dirty.
>>>> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
>>>
>>> That's what set_pte_at() does.
>>>
>>
>> So if we mmap a memory region use /dev/mem like:
>> fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>> addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
>>
>> The PTE_RDONLY will be set? Right ?
>> However?when use memset to write the region it still works well, and the bit PTE_RDONLY is also cleared.
>> Is there anywhere clear the PTE_RDONLY before write that page ?
>>
>
> Hi Yisheng,
> Out of interest, why is /dev/mem being accessed directly from userspace?
hi Steve,
Thank you for your reply.
We just want to access some reserved memory region.
Thanks
Yisheng Xie.
>
> The case above will have subtley different logic (mmap_mem will affect
> how things are actually mapped); which I'm trying to understand...
>
> Cheers,
>
^ permalink raw reply
* [PATCH v2 net-next 0/2] mvneta xmit_more and bql support
From: David Miller @ 2017-01-17 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484586512-16412-1-git-send-email-mw@semihalf.com>
From: Marcin Wojtas <mw@semihalf.com>
Date: Mon, 16 Jan 2017 18:08:30 +0100
> This is a delayed v2 of short patchset, which introduces xmit_more and BQL
> to mvneta driver. The only one change was added in xmit_more support -
> condition check preventing excessive descriptors concatenation before
> flushing in HW.
>
> Any comments or feedback would be welcome.
...
> Changelog:
> v1 -> v2:
>
> * Add checking condition that ensures too much descriptors are not
> concatenated before flushing in HW.
Looks good, series applied, thanks.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add LED
From: Andreas Färber @ 2017-01-17 1:17 UTC (permalink / raw)
To: linux-arm-kernel
There is one blue LED on the front of the device. Keep it lit and
configure it as panic indicator.
Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index ab497126c9a3..b3937b72d102 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -53,6 +53,17 @@
stdout-path = "serial0:115200n8";
};
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "vega-s95:blue:on";
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+ };
+
usb_vbus: regulator-usb0-vbus {
compatible = "regulator-fixed";
--
2.10.2
^ permalink raw reply related
* [PATCH v1] ARM: dts: imx: add fsl, imx35-wdt compatible to all relevant watchdog nodes
From: Vladimir Zapolskiy @ 2017-01-17 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Watchdog device controller found on all modern SoCs from i.MX series
and firstly introduced in i.MX35 is not one in one compatible with the
watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
controlles don't have WICR (and pretimeout notification support) and
WMCR registers. To get benefit from the more advanced watchdog device
and to avoid operations over non-existing registers on legacy SoCs add
fsl,imx35-wdt compatible to descriptions of all i.MX35 compatible
watchdog controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
RFC change is found at https://patchwork.kernel.org/patch/9350007
Changes from RFC to v1:
* added the same change to devicetree bindings documentation, thanks
to Baruch Siach for review,
* replaced a new shared compatible derived from i.MX25 with an earlier
from i.MX35 SoC one, thanks to Uwe Kleine-K?nig for review.
Compatible "fsl,imx21-wdt" is preserved as a generic one, because
interface to a watchdog controller on i.MX35 is a superset of the
interface to a i.MX21 watchdog controller.
Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 +-
arch/arm/boot/dts/imx25.dtsi | 3 ++-
arch/arm/boot/dts/imx50.dtsi | 3 ++-
arch/arm/boot/dts/imx51.dtsi | 6 ++++--
arch/arm/boot/dts/imx53.dtsi | 6 ++++--
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
12 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
index 107280e..9551088 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
@@ -15,7 +15,7 @@ Optional properties:
Examples:
wdt at 73f98000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx35-wdt", "fsl,imx21-wdt";
reg = <0x73f98000 0x4000>;
interrupts = <58>;
big-endian;
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 213d86e..1194fe2 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -505,7 +505,8 @@
};
wdog at 53fdc000 {
- compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx25-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 126>;
clock-names = "";
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index fe0221e..476f54e 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -270,7 +270,8 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx50-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 33526ca..a67870b 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -347,14 +347,16 @@
};
wdog1: wdog at 73f98000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 73f9c000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index ca51dc0..4d0c5c8 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -402,14 +402,16 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 53f9c000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..16ee492 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -594,14 +594,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4fd6de2..794f44d 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -479,14 +479,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 076a30f..e36ead9 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -534,14 +534,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
@@ -1200,7 +1202,8 @@
};
wdog3: wdog at 02288000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x02288000 0x4000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 0f69a3f..33d9a2c 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -491,14 +491,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG1>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG2>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 8db1eb9..ba38b69 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -399,14 +399,16 @@
};
wdog1: wdog at 30280000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x30280000 0x10000>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG1_ROOT_CLK>;
};
wdog2: wdog at 30290000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x30290000 0x10000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG2_ROOT_CLK>;
@@ -414,7 +416,8 @@
};
wdog3: wdog at 302a0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x302a0000 0x10000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG3_ROOT_CLK>;
@@ -422,7 +425,8 @@
};
wdog4: wdog at 302b0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x302b0000 0x10000>;
interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG4_ROOT_CLK>;
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 282d854..41f5afa 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -521,7 +521,7 @@
};
wdog0: watchdog at 2ad0000 {
- compatible = "fsl,imx21-wdt";
+ compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
reg = <0x0 0x2ad0000 0x0 0x10000>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&platform_clk 1>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 5d654b5..360d590 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -326,7 +326,8 @@
};
wdoga5: wdog at 4003e000 {
- compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,vf610-wdt", "fsl,imx35-wdt",
+ "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_WDT>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Vladimir Zapolskiy @ 2017-01-17 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Power down counter enable/disable bit switch is located in WMCR register,
but watchdog controllers found on legacy i.MX21, i.MX27 and i.MX31 SoCs
don't have this register. As a result of writing data to the non-existing
register on driver probe the SoC hangs up, to fix the problem add more OF
compatible strings and on this basis get information about availability of
the WMCR register.
Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Magnus Lilja <lilja.magnus@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes from v1 to v2:
* removed i.MX27 and i.MX31 compatibles from the list, since it is expected
that their DTB files has a reference to the listed i.MX21 compatible,
many thanks to Uwe Kleine-K?nig for the hint,
* start the list of compatibles from an i.MX35 specific one, since it is
agreed that i.MX35 precedes i.MX25, thanks to Uwe Kleine-K?nig for review,
* added a comment describing any potential changes in future over the list
of watchdog compatible values,
* added all collected tags to the commit message.
Changes from RFC to v1:
* replaced private data struct with a macro as suggested by Guenter,
* updated the comment in the source code to reflect the change,
* rearranged and simplified the logic of detecting WMCR presence,
* pulled the fix out from the series with optional proposed DTS changes.
drivers/watchdog/imx2_wdt.c | 41 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 4874b0f..e08c367 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -30,6 +30,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/watchdog.h>
@@ -57,6 +58,7 @@
#define IMX2_WDT_WICR_WICT 0xFF /* -> Interrupt Count Timeout */
#define IMX2_WDT_WMCR 0x08 /* Misc Register */
+#define IMX2_WDT_NO_WMCR ((void *)true) /* Indicates unavailable WMCR */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
@@ -70,6 +72,8 @@ struct imx2_wdt_device {
bool ext_reset;
};
+static const struct of_device_id imx2_wdt_dt_ids[];
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
@@ -242,6 +246,7 @@ static const struct regmap_config imx2_wdt_regmap_config = {
static int __init imx2_wdt_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id;
struct imx2_wdt_device *wdev;
struct watchdog_device *wdog;
struct resource *res;
@@ -310,11 +315,13 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
}
/*
- * Disable the watchdog power down counter at boot. Otherwise the power
- * down counter will pull down the #WDOG interrupt line for one clock
- * cycle.
+ * If watchdog controller has WMCR, disable the watchdog power
+ * down counter at boot. Otherwise the power down counter will
+ * pull down the #WDOG interrupt line for one clock cycle.
*/
- regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
+ of_id = of_match_device(imx2_wdt_dt_ids, &pdev->dev);
+ if (of_id && !of_id->data)
+ regmap_write(wdev->regmap, IMX2_WDT_WMCR, 0);
ret = watchdog_register_device(wdog);
if (ret) {
@@ -411,8 +418,32 @@ static int imx2_wdt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
imx2_wdt_resume);
+/*
+ * The list of compatibles is added to achieve compatibility between
+ * old DTS and new kernel while fixing the incompatibility between
+ * i.MX21/i.MX27/i.MX31 and i.MX35/i.MX25/etc. watchdog controllers.
+ *
+ * Please do *NOT* extend the list by adding a compatible value for
+ * a controller, which is compatible with one of the already listed,
+ * almost certainly "fsl,imx35-wdt" compatible serves newer i.MX SoCs.
+ *
+ * You may consider to shrink the list at your own risk, but this may
+ * break the backward compatibility and users may have to update their
+ * DTB, which is good eventually.
+ */
static const struct of_device_id imx2_wdt_dt_ids[] = {
- { .compatible = "fsl,imx21-wdt", },
+ { .compatible = "fsl,imx21-wdt", .data = IMX2_WDT_NO_WMCR },
+ { .compatible = "fsl,imx35-wdt", },
+ { .compatible = "fsl,imx25-wdt", },
+ { .compatible = "fsl,imx50-wdt", },
+ { .compatible = "fsl,imx51-wdt", },
+ { .compatible = "fsl,imx53-wdt", },
+ { .compatible = "fsl,imx6q-wdt", },
+ { .compatible = "fsl,imx6sl-wdt", },
+ { .compatible = "fsl,imx6sx-wdt", },
+ { .compatible = "fsl,imx6ul-wdt", },
+ { .compatible = "fsl,imx7d-wdt", },
+ { .compatible = "fsl,vf610-wdt", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx2_wdt_dt_ids);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/8] ARM: dts: Switch to new DSA binding
From: Florian Fainelli @ 2017-01-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>
On 01/05/2017 11:29 AM, Florian Fainelli wrote:
> Hi all,
>
> This patch series converts the in-tree users to utilize the new (relatively)
> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
> new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Changes in v2:
>
> - patch 1: Use an hexadecimal reg property
> - patch 2: fixed the subject
> - patch 3: s/okay/disabled/ for the legacy DSA node
> - patches 7/8: fixed a stray whitespace
>
> In about 2-3 releases we may consider removing the old DSA binding entirely
> from the kernel.
Gregory, are you going to take this for 4.11? Thanks
>
> Thank you!
>
> Florian Fainelli (8):
> ARM: dts: armada-370-rd: Utilize new DSA binding
> ARM: dts: armada-385-linksys: Utilize new DSA binding
> ARM: dts: armada-388-clearfog: Utilize new DSA binding
> ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
> ARM: dts: kirkwood-dir665: Utilize new DSA binding
> ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
> ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
> ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
>
> arch/arm/boot/dts/armada-370-rd.dts | 44 +++++++++++++++++
> arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++++++++++++++++++++-
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 ++++++++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++++++++++++++++++++
> arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 +++++
> arch/arm/boot/dts/kirkwood-rd88f6281.dtsi | 44 +++++++++++++++++
> 9 files changed, 415 insertions(+), 1 deletion(-)
>
--
Florian
^ 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