* [RFC PATCH 0/3] firmware: Add K3 Support for TISCI driver
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series enables TI System Control Interface(TISCI) support for
the newest addition in TI's SoC portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 4 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-4-am6-tisci
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The Linux development follows closely the 66AK2G SoC model in aarch64 with a
few additions to handle the flexibility of firmware.
The architecture and dts support depends on part 1 of the series:
https://marc.info/?l=linux-arm-kernel&m=152817866312732&w=2
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Nishanth Menon (3):
Documentation: dt: keystone: ti-sci: Add optional host-id parameter
firmware: ti_sci: Provide host-id as an optional dt parameter
arm64: dts: ti: k3-am6: Add Device Management Security Controller
support
.../devicetree/bindings/arm/keystone/ti,sci.txt | 4 +++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 ++++++++++++++++++++++
drivers/firmware/ti_sci.c | 24 +++++++++++++---
3 files changed, 56 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
This is introduced as an optional parameter to maintain consistency
with legacy device tree blobs.
We call this with a vendor prefix to prevent any possible confusion
with SCSI ID (m68k) kernel option.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index 31f5f9a104cc..b56a02c10ae6 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -45,11 +45,15 @@ Optional Properties:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
+ for identification of host processing entities such as virtual
+ machines
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
+ ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 2/3] firmware: ti_sci: Provide host-id as an optional dt parameter
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
Provide support as an optional parameter implementation and use the compatible
data as default if one is not provided by device tree.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/firmware/ti_sci.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index b74a533ef35b..6b08ee815b24 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -66,14 +66,14 @@ struct ti_sci_xfers_info {
/**
* struct ti_sci_desc - Description of SoC integration
- * @host_id: Host identifier representing the compute entity
+ * @default_host_id: Host identifier representing the compute entity
* @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds)
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
*/
struct ti_sci_desc {
- u8 host_id;
+ u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
@@ -94,6 +94,7 @@ struct ti_sci_desc {
* @chan_rx: Receive mailbox channel
* @minfo: Message info
* @node: list head
+ * @host_id: Host ID
* @users: Number of users of this instance
*/
struct ti_sci_info {
@@ -110,6 +111,7 @@ struct ti_sci_info {
struct mbox_chan *chan_rx;
struct ti_sci_xfers_info minfo;
struct list_head node;
+ u8 host_id;
/* protected by ti_sci_list_mutex */
int users;
@@ -370,7 +372,7 @@ static struct ti_sci_xfer *ti_sci_get_one_xfer(struct ti_sci_info *info,
hdr->seq = xfer_id;
hdr->type = msg_type;
- hdr->host = info->desc->host_id;
+ hdr->host = info->host_id;
hdr->flags = msg_flags;
return xfer;
@@ -1793,7 +1795,7 @@ static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
/* Description for K2G */
static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
- .host_id = 2,
+ .default_host_id = 2,
/* Conservative duration */
.max_rx_timeout_ms = 1000,
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
@@ -1819,6 +1821,7 @@ static int ti_sci_probe(struct platform_device *pdev)
int ret = -EINVAL;
int i;
int reboot = 0;
+ u32 h_id;
of_id = of_match_device(ti_sci_of_match, dev);
if (!of_id) {
@@ -1833,6 +1836,19 @@ static int ti_sci_probe(struct platform_device *pdev)
info->dev = dev;
info->desc = desc;
+ ret = of_property_read_u32(dev->of_node, "ti,host-id", &h_id);
+ /* if the property is not present in DT, use a default from desc */
+ if (ret < 0) {
+ info->host_id = info->desc->default_host_id;
+ } else {
+ if (!h_id) {
+ dev_warn(dev, "Host ID 0 is reserved for firmware\n");
+ info->host_id = info->desc->default_host_id;
+ } else {
+ info->host_id = h_id;
+ }
+ }
+
reboot = of_property_read_bool(dev->of_node,
"ti,system-reboot-controller");
INIT_LIST_HEAD(&info->node);
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 3/3] arm64: dts: ti: k3-am6: Add Device Management Security Controller support
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Add TISCI compatible System controller for AM6 SoCs.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
index 07e9cc05519c..898422e24b27 100644
--- a/arch/arm64/boot/dts/ti/k3-am6.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -97,6 +97,38 @@
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
};
+ dmsc: dmsc {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ /*
+ * In case of rare platforms that does not use am6 as
+ * system master, use /delete-property/
+ */
+ ti,system-reboot-controller;
+ mbox-names = "rx", "tx";
+
+ mboxes= <&secure_proxy 11>,
+ <&secure_proxy 13>;
+
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <1>;
+ };
+
+ k3_clks: clocks {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
+
wkup_uart0: serial at 42300000 {
compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
reg = <0x0 0x42300000 0x0 0x100>;
--
2.15.1
^ permalink raw reply related
* [PATCH] irqchip/gic-v3-its: fix ITS queue timeout
From: Yang Yingliang @ 2018-06-05 6:30 UTC (permalink / raw)
To: linux-arm-kernel
When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.
If LPI is bind to offline cpu, sync cmd will use zero TA,
it leads to ITS queue timeout. Fix this by choosing a
online cpu, if there is no online cpu in cpu_mask.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
drivers/irqchip/irq-gic-v3-its.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 5416f2b..edd92a9 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2309,7 +2309,9 @@ static int its_irq_domain_activate(struct irq_domain *domain,
cpu_mask = cpumask_of_node(its_dev->its->numa_node);
/* Bind the LPI to the first possible CPU */
- cpu = cpumask_first(cpu_mask);
+ cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
+ if (!cpu_online(cpu))
+ cpu = cpumask_first(cpu_online_mask);
its_dev->event_map.col_map[event] = cpu;
irq_data_update_effective_affinity(d, cpumask_of(cpu));
@@ -2466,7 +2468,10 @@ static int its_vpe_set_affinity(struct irq_data *d,
bool force)
{
struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
- int cpu = cpumask_first(mask_val);
+ int cpu = cpumask_first_and(mask_val, cpu_online_mask);
+
+ if (!cpu_online(cpu))
+ cpu = cpumask_first(cpu_online_mask);
/*
* Changing affinity is mega expensive, so let's be as lazy as
--
1.8.3
^ permalink raw reply related
* [PATCH] arm: cntvoff: Add a function definition when !SMP
From: Simon Horman @ 2018-06-05 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604162603.j3rtfbg3hqhast6p@flea>
On Mon, Jun 04, 2018 at 06:26:03PM +0200, Maxime Ripard wrote:
> On Mon, May 28, 2018 at 10:40:16AM +0200, Maxime Ripard wrote:
> > The secure_cntvoff_init function is only compiled if CONFIG_SMP is set to
> > true. However, that will lead to linking errors if one uses this function
> > without an ifdef CONFIG_SMP guard, which isn't ideal.
> >
> > Provide a dumb implementation when CONFIG_SMP is false so that we don't end
> > up with a compilation error on our hands.
What are the errors that this patch fixes?
> >
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Myl?ne Josserand <mylene.josserand@bootlin.com>
> > Cc: Simon Horman <horms@verge.net.au>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Fixes: cad160ed0a94 ("ARM: shmobile: Convert file to use cntvoff")
> > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Ping?
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH] ARM64: dts: meson-axg: fix register ranges for SD/eMMC
From: Yixun Lan @ 2018-06-05 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604222706.36167-1-khilman@baylibre.com>
Hi Kevin
On 06/05/18 06:27, Kevin Hilman wrote:
> Based on updated information from Amlogic, correct the register
> range for the SD/eMMC blocks to the right size.
>
> Reported-by: Yixun Lan <yixun.lan@amlogic.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> Yixun, please test and confirm this still works on AXG boards.
>
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index fee87737a201..67d7115e4eff 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -132,7 +132,7 @@
>
> sd_emmc_b: sd at 5000 {
> compatible = "amlogic,meson-axg-mmc";
> - reg = <0x0 0x5000 0x0 0x2000>;
> + reg = <0x0 0x5000 0x0 0x800>;
> interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> clocks = <&clkc CLKID_SD_EMMC_B>,
> @@ -144,7 +144,7 @@
>
> sd_emmc_c: mmc at 7000 {
> compatible = "amlogic,meson-axg-mmc";
> - reg = <0x0 0x7000 0x0 0x2000>;
> + reg = <0x0 0x7000 0x0 0x800>;
> interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> clocks = <&clkc CLKID_SD_EMMC_C>,
>
Starting from GXBB series, the SD/eMMC register range is changed to
0x800, so arch/arm64/boot/dts/amlogic/meson-gx.dtsi also need to be adjusted
Also, test passed on boards: GXBB(p200), GXL(p212, p230), AXG(s400)
Thanks for bringing up this, and fix them.
Yixun
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Sébastien Szymanski @ 2018-06-05 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523042953.kcp2h5xtwjrjponn@vireshk-i7>
On 05/23/2018 06:29 AM, Viresh Kumar wrote:
> On 22-05-18, 08:28, S?bastien Szymanski wrote:
>> Check the max speed supported from the fuses for i.MX6ULL and update the
>> operating points table accordingly.
>>
>> Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
>> ---
>>
>> Changes for v3:
>> - none
>
> @Sascha and Shawn: Can you guys please Ack this series if there is
> nothing wrong with it ?
>
ping...
--
S?bastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
^ permalink raw reply
* [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Maxime Ripard @ 2018-06-05 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a313ec0be4104494de319e8318e05614fb97b2fd.1528173943.git.viresh.kumar@linaro.org>
On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied both, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- 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/20180605/15dccabc/attachment.sig>
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Simon Horman @ 2018-06-05 7:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604122325.GH19674@bigcity.dyn.berto.se>
On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that use
> > them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> The more I think about this the more I lean towards that this patch
> should be dropped. The properties accurately describes the hardware and
> I think there is value in that. That the driver currently don't parse or
> make use of them don't in my view reduce there value. Maybe you should
> break out this patch to a separate series?
I also think there is value in describing the hardware not the state of the
driver at this time. Is there any missmatch between these properties and
the bindings?
^ permalink raw reply
* panic kexec broken on ARM64?
From: Petr Tesarik @ 2018-06-05 8:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
when a panic kernel is loaded. I attached a hardware debugger and found
out that all CPU cores were stopped except one which was stuck in the
idle thread. It seems that irq_set_irqchip_state() may sleep, which is
definitely not safe after a kernel panic.
If I'm right, then this is broken in general, but I have only ever seen
it on RPi 3 Model B+ (even RPi3 Model B works fine), so the issue may
be more subtle. FWIW the code for 32-bit ARM seems to work just fine
without this code in machine_kexec_mask_interrupts():
/*
* First try to remove the active state. If this
* fails, try to EOI the interrupt.
*/
ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
I wonder what breaks if this call to irq_set_irqchip_state() is removed.
For reference, here is a stack trace of the process which originally
triggered the panic:
#0 __switch_to (prev=0xffff000008e62a00 <init_task>, next=0xffff80002b796080) at ../arch/arm64/kernel/process.c:355
#1 0xffff0000088f584c in context_switch (rf=<optimized out>, next=<optimized out>, prev=<optimized out>, rq=<optimized out>) at ../kernel/sched/core.c:2896
#2 __schedule (preempt=false) at ../kernel/sched/core.c:3457
#3 0xffff0000088f5eac in schedule () at ../kernel/sched/core.c:3516
#4 0xffff0000088f9448 in schedule_timeout (timeout=<optimized out>) at ../kernel/time/timer.c:1743
#5 0xffff0000088f6afc in do_wait_for_common (state=<optimized out>, timeout=500, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:77
#6 __wait_for_common (state=<optimized out>, timeout=<optimized out>, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:96
#7 wait_for_common (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500, state=<optimized out>) at ../kernel/sched/completion.c:104
#8 0xffff0000088f6c1c in wait_for_completion_timeout (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500) at ../kernel/sched/completion.c:144
#9 0xffff000000a19f1c in usb_start_wait_urb (urb=0xffff80002c1cd700, timeout=5000, actual_length=0xffff000008e538dc <init_thread_union+14556>)
at ../drivers/usb/core/message.c:61
#10 0xffff000000a1a05c in usb_internal_control_msg (timeout=<optimized out>, len=<optimized out>, data=<optimized out>, cmd=<optimized out>, pipe=<optimized out>,
usb_dev=<optimized out>) at ../drivers/usb/core/message.c:100
#11 usb_control_msg (dev=0xffff80002c348000, pipe=2147484800, request=161 '\241', requesttype=192 '\300', value=0, index=152, data=0xffff80002b6fa080, size=4,
timeout=5000) at ../drivers/usb/core/message.c:151
#12 0xffff000001001cd0 in lan78xx_read_reg (index=152, data=0xffff000008e5396c <init_thread_union+14700>, dev=<optimized out>, dev=<optimized out>)
at ../drivers/net/usb/lan78xx.c:425
#13 0xffff00000100365c in lan78xx_irq_bus_sync_unlock (irqd=<optimized out>) at ../drivers/net/usb/lan78xx.c:1909
#14 0xffff00000813e590 in chip_bus_sync_unlock (desc=<optimized out>) at ../kernel/irq/internals.h:129
#15 __irq_put_desc_unlock (desc=0xffff80002c361c00, flags=128, bus=true) at ../kernel/irq/irqdesc.c:804
#16 0xffff00000813f604 in irq_put_desc_busunlock (flags=<optimized out>, desc=<optimized out>) at ../kernel/irq/internals.h:155
#17 irq_set_irqchip_state (irq=<optimized out>, which=<optimized out>, val=false) at ../kernel/irq/manage.c:2136
#18 0xffff00000809b7d4 in machine_kexec_mask_interrupts () at ../arch/arm64/kernel/machine_kexec.c:233
#19 machine_crash_shutdown (regs=<optimized out>) at ../arch/arm64/kernel/machine_kexec.c:259
#20 0xffff000008180fd4 in __crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:943
#21 0xffff0000081810e4 in crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:965
#22 0xffff00000808ab58 in die (str=<optimized out>, regs=0xffff000008e53d70 <init_thread_union+15728>, err=-2046820348) at ../arch/arm64/kernel/traps.c:266
#23 0xffff0000080a1c14 in __do_kernel_fault (mm=0x0, addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:226
#24 0xffff0000088fc8dc in do_page_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:476
#25 0xffff0000088fccdc in do_translation_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:502
#26 0xffff000008081478 in do_mem_abort (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:657
#27 0xffff000008082dd0 in el1_sync () at ../arch/arm64/kernel/entry.S:548
Petr T
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a7796: Add PCIe device nodes
From: Simon Horman @ 2018-06-05 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528134548-17492-1-git-send-email-ykaneko0929@gmail.com>
On Tue, Jun 05, 2018 at 02:49:08AM +0900, Yoshihiro Kaneko wrote:
> From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>
> This patch adds PCIe{0,1} device nodes for R8A7796 SoC.
>
> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-axg: fix register ranges for SD/eMMC
From: Jerome Brunet @ 2018-06-05 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604222706.36167-1-khilman@baylibre.com>
On Mon, 2018-06-04 at 15:27 -0700, Kevin Hilman wrote:
> Based on updated information from Amlogic, correct the register
> range for the SD/eMMC blocks to the right size.
>
> Reported-by: Yixun Lan <yixun.lan@amlogic.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Shouldn't we make the same the change on the gx family ?
> ---
> Yixun, please test and confirm this still works on AXG boards.
>
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index fee87737a201..67d7115e4eff 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -132,7 +132,7 @@
>
> sd_emmc_b: sd at 5000 {
> compatible = "amlogic,meson-axg-mmc";
> - reg = <0x0 0x5000 0x0 0x2000>;
> + reg = <0x0 0x5000 0x0 0x800>;
> interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> clocks = <&clkc CLKID_SD_EMMC_B>,
> @@ -144,7 +144,7 @@
>
> sd_emmc_c: mmc at 7000 {
> compatible = "amlogic,meson-axg-mmc";
> - reg = <0x0 0x7000 0x0 0x2000>;
> + reg = <0x0 0x7000 0x0 0x800>;
> interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> clocks = <&clkc CLKID_SD_EMMC_C>,
^ permalink raw reply
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Simon Horman @ 2018-06-05 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604175911.799-1-marek.vasut+renesas@gmail.com>
On Mon, Jun 04, 2018 at 07:59:11PM +0200, Marek Vasut wrote:
> Rather than hard-coding the quirk topology, which stopped scaling,
> parse the information from DT. The code looks for all compatible
> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
> to the same pin. If so, the code sends a matching sequence to the
> PMIC to deassert the IRQ.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc at vger.kernel.org
> ---
> V2: - Replace the DT shared IRQ check loop with memcmp()
> - Send the I2C message to deassert the IRQ line to all PMICs
> in the list with shared IRQ line instead of just one
> - Add comment that this works only in case all the PMICs are
> on the same I2C bus
> V3: - Drop the addr = 0x00 init
> - Drop reinit of argsa in rcar_gen2_regulator_quirk
> ---
> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 114 ++++++++++++++++-----
> 1 file changed, 90 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> index 93f628acfd94..b919073aa27e 100644
> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> @@ -31,8 +31,10 @@
> #include <linux/i2c.h>
> #include <linux/init.h>
> #include <linux/io.h>
> +#include <linux/list.h>
> #include <linux/notifier.h>
> #include <linux/of.h>
> +#include <linux/of_irq.h>
> #include <linux/mfd/da9063/registers.h>
>
>
> @@ -44,34 +46,45 @@
> /* start of DA9210 System Control and Event Registers */
> #define DA9210_REG_MASK_A 0x54
>
> +struct regulator_quirk {
> + struct list_head list;
> + const struct of_device_id *id;
> + struct of_phandle_args irq_args;
> + struct i2c_msg i2c_msg;
> + bool shared; /* IRQ line is shared */
> +};
> +
> +static LIST_HEAD(quirk_list);
> static void __iomem *irqc;
>
> /* first byte sets the memory pointer, following are consecutive reg values */
> static u8 da9063_irq_clr[] = { DA9063_REG_IRQ_MASK_A, 0xff, 0xff, 0xff, 0xff };
> static u8 da9210_irq_clr[] = { DA9210_REG_MASK_A, 0xff, 0xff };
>
> -static struct i2c_msg da9xxx_msgs[3] = {
> - {
> - .addr = 0x58,
> - .len = ARRAY_SIZE(da9063_irq_clr),
> - .buf = da9063_irq_clr,
> - }, {
> - .addr = 0x68,
> - .len = ARRAY_SIZE(da9210_irq_clr),
> - .buf = da9210_irq_clr,
> - }, {
> - .addr = 0x70,
> - .len = ARRAY_SIZE(da9210_irq_clr),
> - .buf = da9210_irq_clr,
> - },
> +static struct i2c_msg da9063_msgs = {
> + .len = ARRAY_SIZE(da9063_irq_clr),
> + .buf = da9063_irq_clr,
> +};
> +
> +static struct i2c_msg da9210_msgs = {
> + .len = ARRAY_SIZE(da9210_irq_clr),
> + .buf = da9210_irq_clr,
> +};
> +
> +static const struct of_device_id rcar_gen2_quirk_match[] = {
> + { .compatible = "dlg,da9063", .data = &da9063_msgs },
> + { .compatible = "dlg,da9210", .data = &da9210_msgs },
> + {},
> };
>
> static int regulator_quirk_notify(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> + struct regulator_quirk *pos, *tmp;
> struct device *dev = data;
> struct i2c_client *client;
> static bool done;
> + int ret;
> u32 mon;
>
> if (done)
> @@ -88,17 +101,20 @@ static int regulator_quirk_notify(struct notifier_block *nb,
> client = to_i2c_client(dev);
> dev_dbg(dev, "Detected %s\n", client->name);
>
> - if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
> - (client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
> - (client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
> - int ret, len;
> + /*
> + * Send message to all PMICs that share an IRQ line to deassert it.
> + *
> + * WARNING: This works only if all the PMICs are on the same I2C bus.
> + */
> + list_for_each_entry(pos, &quirk_list, list) {
> + if (!pos->shared)
> + continue;
>
> - /* There are two DA9210 on Stout, one on the other boards. */
> - len = of_machine_is_compatible("renesas,stout") ? 3 : 2;
> + dev_info(&client->dev, "clearing %s at 0x%02x interrupts\n",
> + pos->id->compatible, pos->i2c_msg.addr);
>
> - dev_info(&client->dev, "clearing da9063/da9210 interrupts\n");
> - ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
> - if (ret != len)
> + ret = i2c_transfer(client->adapter, &pos->i2c_msg, 1);
> + if (ret != 1)
> dev_err(&client->dev, "i2c error %d\n", ret);
> }
>
> @@ -111,6 +127,11 @@ static int regulator_quirk_notify(struct notifier_block *nb,
> remove:
> dev_info(dev, "IRQ2 is not asserted, removing quirk\n");
>
> + list_for_each_entry_safe(pos, tmp, &quirk_list, list) {
> + list_del(&pos->list);
> + kfree(pos);
> + }
> +
> done = true;
> iounmap(irqc);
> return 0;
> @@ -122,7 +143,13 @@ static struct notifier_block regulator_quirk_nb = {
>
> static int __init rcar_gen2_regulator_quirk(void)
> {
> - u32 mon;
> + struct device_node *np;
> + const struct of_device_id *id;
> + struct regulator_quirk *quirk;
> + struct regulator_quirk *pos;
> + struct of_phandle_args *argsa, *argsb;
> + u32 mon, addr;
> + int ret;
>
> if (!of_machine_is_compatible("renesas,koelsch") &&
> !of_machine_is_compatible("renesas,lager") &&
> @@ -130,6 +157,45 @@ static int __init rcar_gen2_regulator_quirk(void)
> !of_machine_is_compatible("renesas,gose"))
> return -ENODEV;
>
> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
> + if (!np || !of_device_is_available(np))
> + break;
> +
> + quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
> +
> + argsa = &quirk->irq_args;
> + memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
> +
> + ret = of_property_read_u32(np, "reg", &addr);
> + if (ret)
> + return ret;
> +
> + quirk->id = id;
> + quirk->i2c_msg.addr = addr;
> + quirk->shared = false;
> +
> + ret = of_irq_parse_one(np, 0, &quirk->irq_args);
As per my comment on v2,
&quirk->irq_args is assigned to argsa above and used directly here.
> + if (ret)
> + return ret;
> +
> + list_for_each_entry(pos, &quirk_list, list) {
> + argsb = &pos->irq_args;
> +
> + if (argsa->args_count != argsb->args_count)
> + continue;
> +
> + ret = memcmp(argsa->args, argsb->args,
> + argsa->args_count *
> + sizeof(argsa->args[0]));
> + if (!ret) {
> + pos->shared = true;
> + quirk->shared = true;
> + }
> + }
> +
> + list_add_tail(&quirk->list, &quirk_list);
> + }
> +
> irqc = ioremap(IRQC_BASE, PAGE_SIZE);
> if (!irqc)
> return -ENOMEM;
> --
> 2.16.2
>
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: jacopo mondi @ 2018-06-05 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605074938.mljwmgpjlplvkp2v@verge.net.au>
Hi Simon,
On Tue, Jun 05, 2018 at 09:49:38AM +0200, Simon Horman wrote:
> On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas S?derlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that use
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > The more I think about this the more I lean towards that this patch
> > should be dropped. The properties accurately describes the hardware and
> > I think there is value in that. That the driver currently don't parse or
> > make use of them don't in my view reduce there value. Maybe you should
> > break out this patch to a separate series?
>
> I also think there is value in describing the hardware not the state of the
> driver at this time. Is there any missmatch between these properties and
> the bindings?
Niklas and I discussed a bit offline on this yesterday. My main
concern, and sorry for being pedant on this, is that changing those
properties value does not change the interface behaviour, and this
could cause troubles when integrating image sensor not known to be
working on the VIN interface.
This said, the documentation of those (and all other) properties is in the
generic "video-interfaces.txt" file and it is my understanding, but I think
Laurent and Rob agree on this as well from their replies to my previous series,
that each driver should list which properties it actually supports, as
some aspects are very implementation specific, like default values and
what happens if the property is not specified [1]. Nonetheless, all
properties describing hardware features and documented in the generic
file should be accepted in DTS, as those aims to be OS-independent and
even independent from the single driver implementation.
A possible middle-ground would be documenting in the VIN device tree
bindings description properties whose values actually affect the VIN
interface configuration and state in bindings that all generic properties
described in 'video-interfaces.txt' are valid ones but if not
explicitly listed there their value won't affect the interface
configuration. Niklas suggested this, and I quite like the fact it
makes clear that, say, changing the 'pclk-sample' property won't
change how the VIN interface would sample data but at the same time
allows for extensive description of the hardware.
Would something like this work in your opinion?
As a consequence, this patch should be dropped as Niklas and you
suggested.
Thanks
j
[1] Ie. An interface that supports BT.656 encoding will use it if
'hsync-active' and 'vsync-active' are not specified. One that does not
support embedded synchronization would instead use defaults for those
two properties. This is specific to the single interface (or even the
single driver implementation actually) and should be listed in the single
driver's bindings description imo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/5a7706b3/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v5 0/4] kernel hacking: GCC optimization for better debug experience (-Og)
From: changbin.du at intel.com @ 2018-06-05 8:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Changbin Du <changbin.du@intel.com>
Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because they want to debug kernel with
qemu, simics, kgtp or kgdb.
Thanks for the GCC '-Og' optimization level introduced in GCC 4.8, which
offers a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is similar to '-O1' while perferring to
keep debug ability over runtime speed. With '-Og', we can build a kernel with
better debug ability and little performance drop after some simple change.
In this series, firstly introduce a new config CONFIG_NO_AUTO_INLINE after two
fixes for this new option. With this option, only functions explicitly marked
with "inline" will be inlined. This will allow the function tracer to trace
more functions because it only traces functions that the compiler has not
inlined.
Then introduce new config CC_OPTIMIZE_FOR_DEBUGGING which apply '-Og'
optimization level for whole kernel, with a simple fix in fix_to_virt().
Currently I have only tested this option on x86 and ARM platform. Other
platforms should also work but probably need some compiling fixes as what
having done in this series. I leave that to who want to try this debug
option.
Comparison of vmlinux size: a bit smaller.
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
22665554 9709674 2920908 35296136 21a9388 vmlinux
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
21499032 10102758 2920908 34522698 20ec64a vmlinux
Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74
Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
[ -f $G ] && echo performance > $G
done
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
219.764246652 seconds time elapsed ( +- 0.78% )
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time elapsed ( +- 0.19% )
v5:
o Exchange the position of last two patches to avoid compiling error.
v4:
o Remove aready merged one "regulator: add dummy function of_find_regulator_by_node".
Changbin Du (4):
x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
kernel hacking: new config NO_AUTO_INLINE to disable compiler
auto-inline optimizations
ARM: mm: fix build error in fix_to_virt with
CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og
optimization
Makefile | 10 ++++++++++
arch/arm/mm/mmu.c | 2 +-
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/kernel/head64.c | 13 ++++++-------
include/linux/compiler-gcc.h | 2 +-
include/linux/compiler.h | 2 +-
init/Kconfig | 19 +++++++++++++++++++
lib/Kconfig.debug | 17 +++++++++++++++++
8 files changed, 57 insertions(+), 10 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v5 1/4] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif
From: changbin.du at intel.com @ 2018-06-05 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528186420-6615-1-git-send-email-changbin.du@intel.com>
From: Changbin Du <changbin.du@intel.com>
The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.
Signed-off-by: Changbin Du <changbin.du@intel.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/kernel/head64.c | 13 ++++++-------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 877bc27..9e7f667 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -15,7 +15,9 @@
#include <linux/bitops.h>
#include <linux/threads.h>
+#ifdef CONFIG_X86_5LEVEL
extern p4d_t level4_kernel_pgt[512];
+#endif
extern p4d_t level4_ident_pgt[512];
extern pud_t level3_kernel_pgt[512];
extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c408f8..775d7a6 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -143,16 +143,15 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgd = fixup_pointer(&early_top_pgt, physaddr);
p = pgd + pgd_index(__START_KERNEL_map);
- if (la57)
- *p = (unsigned long)level4_kernel_pgt;
- else
- *p = (unsigned long)level3_kernel_pgt;
- *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
-
+#ifdef CONFIG_X86_5LEVEL
if (la57) {
+ *p = (unsigned long)level4_kernel_pgt;
p4d = fixup_pointer(&level4_kernel_pgt, physaddr);
p4d[511] += load_delta;
- }
+ } else
+#endif
+ *p = (unsigned long)level3_kernel_pgt;
+ *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
pud = fixup_pointer(&level3_kernel_pgt, physaddr);
pud[510] += load_delta;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
From: changbin.du at intel.com @ 2018-06-05 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528186420-6615-1-git-send-email-changbin.du@intel.com>
From: Changbin Du <changbin.du@intel.com>
This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.
With this option, only functions explicitly marked with "inline" will
be inlined. This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.
Signed-off-by: Changbin Du <changbin.du@intel.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
v2: Some grammar updates from Steven.
---
Makefile | 6 ++++++
lib/Kconfig.debug | 17 +++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/Makefile b/Makefile
index d0d2652..6720c40 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,12 @@ KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
$(call cc-option,-fno-var-tracking)
endif
+ifdef CONFIG_NO_AUTO_INLINE
+KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions) \
+ $(call cc-option, -fno-inline-small-functions) \
+ $(call cc-option, -fno-inline-functions-called-once)
+endif
+
ifdef CONFIG_FUNCTION_TRACER
ifndef CC_FLAGS_FTRACE
CC_FLAGS_FTRACE := -pg
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..da52243 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -198,6 +198,23 @@ config GDB_SCRIPTS
instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
for further details.
+config NO_AUTO_INLINE
+ bool "Disable compiler auto-inline optimizations"
+ help
+ This will prevent the compiler from optimizing the kernel by
+ auto-inlining functions not marked with the inline keyword.
+ With this option, only functions explicitly marked with
+ "inline" will be inlined. This will allow the function tracer
+ to trace more functions because it only traces functions that
+ the compiler has not inlined.
+
+ Enabling this function can help debugging a kernel if using
+ the function tracer. But it can also change how the kernel
+ works, because inlining functions may change the timing,
+ which could make it difficult while debugging race conditions.
+
+ If unsure, select N.
+
config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/4] ARM: mm: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
From: changbin.du at intel.com @ 2018-06-05 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528186420-6615-1-git-send-email-changbin.du@intel.com>
From: Changbin Du <changbin.du@intel.com>
With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.
arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./include/asm-generic/fixmap.h:31: undefined reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Signed-off-by: Changbin Du <changbin.du@intel.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
v2: use __fix_to_virt() to fix the issue.
---
arch/arm/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..c08d74e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1599,7 +1599,7 @@ static void __init early_fixmap_shutdown(void)
pte_t *pte;
struct map_desc map;
- map.virtual = fix_to_virt(i);
+ map.virtual = __fix_to_virt(i);
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), map.virtual);
/* Only i/o device mappings are supported ATM */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/4] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization
From: changbin.du at intel.com @ 2018-06-05 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528186420-6615-1-git-send-email-changbin.du@intel.com>
From: Changbin Du <changbin.du@intel.com>
This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over runtime speed.
If enabling this option breaks your kernel, you should either
disable this or find a fix (mostly in the arch code). Currently
this option has only been tested on x86_64 and arm platform.
This option can satisfy people who was searching for a method
to disable compiler optimizations so to achieve better kernel
debugging experience with kgdb or qemu.
The main problem of '-Og' is we must not use __attribute__((error(msg))).
The compiler will report error though the call to error function
still can be optimize out. So we must fallback to array tricky.
Comparison of vmlinux size: a bit smaller.
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
22665554 9709674 2920908 35296136 21a9388 vmlinux
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
21499032 10102758 2920908 34522698 20ec64a vmlinux
Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74
Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
[ -f $G ] && echo performance > $G
done
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
219.764246652 seconds time elapsed ( +- 0.78% )
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time elapsed ( +- 0.19% )
Signed-off-by: Changbin Du <changbin.du@intel.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
v3:
o Rename DEBUG_EXPERIENCE to CC_OPTIMIZE_FOR_DEBUGGING
o Move new configuration item to "General setup->Compiler optimization level"
v2:
o Improve performance benchmark as suggested by Ingo.
o Grammar updates in description. (Randy Dunlap)
---
Makefile | 4 ++++
include/linux/compiler-gcc.h | 2 +-
include/linux/compiler.h | 2 +-
init/Kconfig | 19 +++++++++++++++++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 6720c40..977418a 100644
--- a/Makefile
+++ b/Makefile
@@ -639,6 +639,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
+ifdef CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
+KBUILD_CFLAGS += $(call cc-option, -Og)
+else
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += $(call cc-option,-Oz,-Os)
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
@@ -649,6 +652,7 @@ else
KBUILD_CFLAGS += -O2
endif
endif
+endif
KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
$(call cc-disable-warning,maybe-uninitialized,))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f..586ed11 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -192,7 +192,7 @@
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
# define __compiletime_warning(message) __attribute__((warning(message)))
# define __compiletime_error(message) __attribute__((error(message)))
#endif /* __CHECKER__ */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c..e97caf4 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -301,7 +301,7 @@ unsigned long read_word_at_a_time(const void *addr)
* sparse see a constant array size without breaking compiletime_assert on old
* versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
*/
-# ifndef __CHECKER__
+# if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
# define __compiletime_error_fallback(condition) \
do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
# endif
diff --git a/init/Kconfig b/init/Kconfig
index f013afc..aa52535 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1036,6 +1036,25 @@ config CC_OPTIMIZE_FOR_SIZE
If unsure, say N.
+config CC_OPTIMIZE_FOR_DEBUGGING
+ bool "Optimize for better debugging experience (-Og)"
+ select NO_AUTO_INLINE
+ help
+ This will apply GCC '-Og' optimization level which is supported
+ since GCC 4.8. This optimization level offers a reasonable level
+ of optimization while maintaining fast compilation and a good
+ debugging experience. It is similar to '-O1' while preferring to
+ keep debug ability over runtime speed. The overall performance
+ will drop a bit (~6%).
+
+ Use only if you want to debug the kernel, especially if you want
+ to have better kernel debugging experience with gdb facilities
+ like kgdb or qemu. If enabling this option breaks your kernel,
+ you should either disable this or find a fix (mostly in the arch
+ code).
+
+ If unsure, select N.
+
endchoice
config SYSCTL
--
2.7.4
^ permalink raw reply related
* [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Geert Uytterhoeven @ 2018-06-05 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605081222.GL10472@w540>
Hi Jacopo,
On Tue, Jun 5, 2018 at 10:12 AM, jacopo mondi <jacopo@jmondi.org> wrote:
> On Tue, Jun 05, 2018 at 09:49:38AM +0200, Simon Horman wrote:
>> On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas S?derlund wrote:
>> > On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
>> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
>> > > driver and only confuse users. Remove them in all Gen2 SoC that use
>> > > them.
>> > >
>> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> >
>> > The more I think about this the more I lean towards that this patch
>> > should be dropped. The properties accurately describes the hardware and
>> > I think there is value in that. That the driver currently don't parse or
>> > make use of them don't in my view reduce there value. Maybe you should
>> > break out this patch to a separate series?
>>
>> I also think there is value in describing the hardware not the state of the
>> driver at this time. Is there any missmatch between these properties and
>> the bindings?
>
> Niklas and I discussed a bit offline on this yesterday. My main
> concern, and sorry for being pedant on this, is that changing those
> properties value does not change the interface behaviour, and this
> could cause troubles when integrating image sensor not known to be
> working on the VIN interface.
>
> This said, the documentation of those (and all other) properties is in the
> generic "video-interfaces.txt" file and it is my understanding, but I think
> Laurent and Rob agree on this as well from their replies to my previous series,
> that each driver should list which properties it actually supports, as
s/driver/device-specific binding/
> some aspects are very implementation specific, like default values and
> what happens if the property is not specified [1]. Nonetheless, all
In se defaults are not (Linux) implementation-specific, but fixed in the
DT bindings.
> properties describing hardware features and documented in the generic
> file should be accepted in DTS, as those aims to be OS-independent and
> even independent from the single driver implementation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Marc Zyngier @ 2018-06-05 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F31014@G01JPEXMBKW03>
On Tue, 05 Jun 2018 00:58:47 +0100,
Zhang, Lei wrote:
>
> Hi Marc
>
> Please let me know is there any plan to push your patch to v4.18.
None at the moment.
We're in the merge window, and no new changes will get queued unless
they fix a regression. This patch needs thorough review and testing,
as it changes a fundamental aspect of the driver. Also, it is pretty
useless on its own, as no bus supported in mainline actually make use
of the new allocator.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0
From: Neil Armstrong @ 2018-06-05 8:52 UTC (permalink / raw)
To: linux-arm-kernel
Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
devices on the P212 Reference Design based boards.
Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
index 0cfd701..a1b3101 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
@@ -189,3 +189,10 @@
&usb0 {
status = "okay";
};
+
+&usb2_phy0 {
+ /*
+ * HDMI_5V is also used as supply for the USB VBUS.
+ */
+ phy-supply = <&hdmi_5v>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V4] PCI: move early dump functionality from x86 arch into the common code
From: Andy Shevchenko @ 2018-06-05 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528164985-14099-1-git-send-email-okaya@codeaurora.org>
On Tue, Jun 5, 2018 at 5:16 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Move early dump functionality into common code so that it is available for
> all archtiectures. No need to carry arch specific reads around as the read
> hooks are already initialized by the time pci_setup_device() is getting
> called during scan.
>
Makes sense.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
One style comment below, though.
If you wait a bit, I perhaps would be able to test on x86.
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> arch/x86/include/asm/pci-direct.h | 4 ---
> arch/x86/kernel/setup.c | 5 ---
> arch/x86/pci/common.c | 4 ---
> arch/x86/pci/early.c | 44 -------------------------
> drivers/pci/pci.c | 5 +++
> drivers/pci/pci.h | 1 +
> drivers/pci/probe.c | 19 +++++++++++
> 8 files changed, 26 insertions(+), 58 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e490902..e64f1d8 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2995,7 +2995,7 @@
> See also Documentation/blockdev/paride.txt.
>
> pci=option[,option...] [PCI] various PCI subsystem options:
> - earlydump [X86] dump PCI config space before the kernel
> + earlydump dump PCI config space before the kernel
> changes anything
> off [X86] don't probe for the PCI bus
> bios [X86-32] force use of PCI BIOS, don't access
> diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
> index e1084f7..94597a3 100644
> --- a/arch/x86/include/asm/pci-direct.h
> +++ b/arch/x86/include/asm/pci-direct.h
> @@ -15,8 +15,4 @@ extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
> extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
>
> extern int early_pci_allowed(void);
> -
> -extern unsigned int pci_early_dump_regs;
> -extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
> -extern void early_dump_pci_devices(void);
> #endif /* _ASM_X86_PCI_DIRECT_H */
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 2f86d88..480f250 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
> setup_clear_cpu_cap(X86_FEATURE_APIC);
> }
>
> -#ifdef CONFIG_PCI
> - if (pci_early_dump_regs)
> - early_dump_pci_devices();
> -#endif
> -
> e820__reserve_setup_data();
> e820__finish_early_params();
>
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 563049c..d4ec117 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -22,7 +22,6 @@
> unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
> PCI_PROBE_MMCONF;
>
> -unsigned int pci_early_dump_regs;
> static int pci_bf_sort;
> int pci_routeirq;
> int noioapicquirk;
> @@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
> pci_probe |= PCI_BIG_ROOT_WINDOW;
> return NULL;
> #endif
> - } else if (!strcmp(str, "earlydump")) {
> - pci_early_dump_regs = 1;
> - return NULL;
> } else if (!strcmp(str, "routeirq")) {
> pci_routeirq = 1;
> return NULL;
> diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
> index e5f753c..f5fc953 100644
> --- a/arch/x86/pci/early.c
> +++ b/arch/x86/pci/early.c
> @@ -57,47 +57,3 @@ int early_pci_allowed(void)
> PCI_PROBE_CONF1;
> }
>
> -void early_dump_pci_device(u8 bus, u8 slot, u8 func)
> -{
> - u32 value[256 / 4];
> - int i;
> -
> - pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
> -
> - for (i = 0; i < 256; i += 4)
> - value[i / 4] = read_pci_config(bus, slot, func, i);
> -
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
> -}
> -
> -void early_dump_pci_devices(void)
> -{
> - unsigned bus, slot, func;
> -
> - if (!early_pci_allowed())
> - return;
> -
> - for (bus = 0; bus < 256; bus++) {
> - for (slot = 0; slot < 32; slot++) {
> - for (func = 0; func < 8; func++) {
> - u32 class;
> - u8 type;
> -
> - class = read_pci_config(bus, slot, func,
> - PCI_CLASS_REVISION);
> - if (class == 0xffffffff)
> - continue;
> -
> - early_dump_pci_device(bus, slot, func);
> -
> - if (func == 0) {
> - type = read_pci_config_byte(bus, slot,
> - func,
> - PCI_HEADER_TYPE);
> - if (!(type & 0x80))
> - break;
> - }
> - }
> - }
> - }
> -}
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 97acba7..04052dc 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
> /* If set, the PCIe ATS capability will not be used. */
> static bool pcie_ats_disabled;
>
> +/* If set, the PCI config space of each device is printed during boot. */
> +bool pci_early_dump;
> +
> bool pci_ats_disabled(void)
> {
> return pcie_ats_disabled;
> @@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
> pcie_ats_disabled = true;
> } else if (!strcmp(str, "noaer")) {
> pci_no_aer();
> + } else if (!strcmp(str, "earlydump")) {
> + pci_early_dump = true;
> } else if (!strncmp(str, "realloc=", 8)) {
> pci_realloc_get_opt(str + 8);
> } else if (!strncmp(str, "realloc", 7)) {
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index c358e7a0..c33265e 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -7,6 +7,7 @@
> #define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
>
> extern const unsigned char pcie_link_speed[];
> +extern bool pci_early_dump;
>
> bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 56771f3..3678f0a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1545,6 +1545,23 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
> return 0;
> }
>
> +static void early_dump_pci_device(struct pci_dev *pdev)
> +{
> + u32 value[256 / 4];
> + int i;
> +
> + if (!pci_early_dump)
> + return;
> +
> + pci_info(pdev, "config space:\n");
> +
> + for (i = 0; i < 256; i += 4)
> + pci_read_config_dword(pdev, i, &value[i / 4]);
> +
> + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
> + 256, false);
Logically better either to move value to second line, or move 256 on
the first line.
> +}
> +
> /**
> * pci_setup_device - Fill in class and map information of a device
> * @dev: the device structure to fill
> @@ -1594,6 +1611,8 @@ int pci_setup_device(struct pci_dev *dev)
> pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
> dev->vendor, dev->device, dev->hdr_type, dev->class);
>
> + early_dump_pci_device(dev);
> +
> /* Need to have dev->class ready */
> dev->cfg_size = pci_cfg_space_size(dev);
>
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Wolfram Sang @ 2018-06-05 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605080727.ygh25rmjsrs3dmlq@verge.net.au>
Hi Marek,
On Tue, Jun 05, 2018 at 10:07:28AM +0200, Simon Horman wrote:
> On Mon, Jun 04, 2018 at 07:59:11PM +0200, Marek Vasut wrote:
> > Rather than hard-coding the quirk topology, which stopped scaling,
> > parse the information from DT. The code looks for all compatible
> > PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
> > to the same pin. If so, the code sends a matching sequence to the
> > PMIC to deassert the IRQ.
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>From an I2C point of view:
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Minor nits:
> > @@ -122,7 +143,13 @@ static struct notifier_block regulator_quirk_nb = {
> >
> > static int __init rcar_gen2_regulator_quirk(void)
> > {
> > - u32 mon;
> > + struct device_node *np;
> > + const struct of_device_id *id;
> > + struct regulator_quirk *quirk;
> > + struct regulator_quirk *pos;
Merge the last two lines into one?
> > + struct of_phandle_args *argsa, *argsb;
> > + u32 mon, addr;
> > + int ret;
> >
> > if (!of_machine_is_compatible("renesas,koelsch") &&
> > !of_machine_is_compatible("renesas,lager") &&
> > @@ -130,6 +157,45 @@ static int __init rcar_gen2_regulator_quirk(void)
> > !of_machine_is_compatible("renesas,gose"))
> > return -ENODEV;
> >
> > + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
> > + if (!np || !of_device_is_available(np))
Can '!np' actually happen? This is the exit condition of the for-loop,
or am I overlooking something?
Regards,
Wolfram
-------------- 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/20180605/35898b42/attachment.sig>
^ 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