* Re: [PATCH] media: cedrus: don't initialize pointers with zero
From: Mauro Carvalho Chehab @ 2018-12-07 12:58 UTC (permalink / raw)
To: Ian Arkver
Cc: devel, Paul Kocialkowski, Maxime Ripard, Greg Kroah-Hartman,
Mauro Carvalho Chehab, Hans Verkuil, Chen-Yu Tsai,
linux-arm-kernel, Linux Media Mailing List
In-Reply-To: <948a841b-efde-b43c-9532-abf72c7a6a97@gmail.com>
Em Fri, 7 Dec 2018 12:27:09 +0000
Ian Arkver <ian.arkver.dev@gmail.com> escreveu:
> On 07/12/2018 11:37, Hans Verkuil wrote:
> > On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> >> Em Fri, 7 Dec 2018 12:14:50 +0100
> >> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >>
> >>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> >>>> A common mistake is to assume that initializing a var with:
> >>>> struct foo f = { 0 };
> >>>>
> >>>> Would initialize a zeroed struct. Actually, what this does is
> >>>> to initialize the first element of the struct to zero.
> >>>>
> >>>> According to C99 Standard 6.7.8.21:
> >>>>
> >>>> "If there are fewer initializers in a brace-enclosed
> >>>> list than there are elements or members of an aggregate,
> >>>> or fewer characters in a string literal used to initialize
> >>>> an array of known size than there are elements in the array,
> >>>> the remainder of the aggregate shall be initialized implicitly
> >>>> the same as objects that have static storage duration."
> >>>>
> >>>> So, in practice, it could zero the entire struct, but, if the
> >>>> first element is not an integer, it will produce warnings:
> >>>>
> >>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
> >>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
> >>>>
> >>>> A proper way to initialize it with gcc is to use:
> >>>>
> >>>> struct foo f = { };
> >>>>
> >>>> But that seems to be a gcc extension. So, I decided to check upstream
> >>>
> >>> No, this is not a gcc extension. It's part of the latest C standard.
> >>
> >> Sure? Where the C standard spec states that? I've been seeking for
> >> such info for a while, as '= {}' is also my personal preference.
> >
> > I believe it was added in C11, but I've loaned the book that stated
> > that to someone else, so I can't check.
>
> Sadly I don't see mention of empty initializer lists in section 6.7.9 of
> ISO/IEC 9899:2011, though I've only got a draft version.
Yeah, as far as I checked, this is not really part of the standard.
Depending on how you read:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
One may infere that a brace-enclosed list with zero elements
would fit, and "the remainder of the aggregate shall be
initialized implicitly".
I suspect that this is how gcc people interpreted it.
> I had a play with Compiler Explorer[1] and it seems like clang is OK
> with the {} form though just out of interest msvc isn't.
Yeah, I'm aware that msvc won't support it. Good to know that clang
does the right thing cleaning the struct.
To be realistic, we only really care with gcc at the Kernel side, as
clang upstream versions still can't build upstream Kernels, and
nobody uses any other compiler for the Kernel anymore. Yet, with
regards to clang, there's a push to let it to build the Kernel.
So, it seems wise to add something that would work for both.
Anyway, I'll post a version 2 of this patch using ={} and placing
some rationale on it.
> I didn't try
> exploring other command line options.
>
> [1] https://gcc.godbolt.org/z/XIDC7W
>
> Regards,
> Ian
> >
> > In any case, it's used everywhere:
> >
> > git grep '= *{ *}' drivers/
> >
> > So it is really pointless to *not* use it.
> >
> > Regards,
> >
> > Hans
> >
> >> I tried to build the Kernel with clang, just to be sure that this
> >> won't cause issues with the clang support, but, unfortunately, the
> >> clang compiler (not even the upstream version) is able to build
> >> the upstream Kernel yet, as it lacks asm-goto support (there is an
> >> OOT patch for llvm solving it - but it sounds too much effort for
> >> my time to have to build llvm from their sources just for a simple
> >> check like this).
> >>
> >>> It's used all over in the kernel, so please use {} instead of { NULL }.
> >>>
> >>> Personally I think {} is a fantastic invention and I wish C++ had it as
> >>> well.
> >>
> >> Fully agreed on that.
> >>
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> >>>> what's the most commonly pattern. The gcc pattern has about 2000 entries:
> >>>>
> >>>> $ git grep -E "=\s*\{\s*\}"|wc -l
> >>>> 1951
> >>>>
> >>>> The standard-C compliant pattern has about 2500 entries:
> >>>>
> >>>> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> >>>> 137
> >>>> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> >>>> 2323
> >>>>
> >>>> So, let's initialize those structs with:
> >>>> = { NULL }
> >>>>
> >>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> >>>> ---
> >>>> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> >>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> >>>> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
> >>>> index b538eb0321d8..44c45c687503 100644
> >>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> >>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> >>>> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
> >>>> memset(ctx->ctrls, 0, ctrl_size);
> >>>>
> >>>> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> >>>> - struct v4l2_ctrl_config cfg = { 0 };
> >>>> + struct v4l2_ctrl_config cfg = { NULL };
> >>>>
> >>>> cfg.elem_size = cedrus_controls[i].elem_size;
> >>>> cfg.id = cedrus_controls[i].id;
> >>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> >>>> index e40180a33951..4099a42dba2d 100644
> >>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> >>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> >>>> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> >>>> {
> >>>> struct cedrus_ctx *ctx = priv;
> >>>> struct cedrus_dev *dev = ctx->dev;
> >>>> - struct cedrus_run run = { 0 };
> >>>> + struct cedrus_run run = { NULL };
> >>>> struct media_request *src_req;
> >>>> unsigned long flags;
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> Thanks,
> >> Mauro
> >>
> >
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629
From: Jianjun Wang @ 2018-12-07 12:56 UTC (permalink / raw)
To: Honghui Zhang
Cc: mark.rutland, devicetree, lorenzo.pieralisi, linux-pci,
youlin.pei, linux-kernel, robh+dt, matthias.bgg, ryder.lee,
linux-mediatek, bhelgaas, linux-arm-kernel
In-Reply-To: <1544075633.3753.11.camel@mhfsdcap03>
On Thu, 2018-12-06 at 13:53 +0800, Honghui Zhang wrote:
> On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> > MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> >
> > The read value of BAR0 is 0xffff_ffff, it's size will be calculated as 4GB
> > in arm64 but bogus alignment values at arm32, the pcie device and devices
>
> :s /the pcie device /the bridge device
>
> > behind this bridge will not be enabled. Fix it's BAR0 resource size to
> > guarantee the pcie devices will be enabled correctly.
> >
> > The HW default value of its device id is invalid, fix it's device id to
> > match the hardware implementation.
> >
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > ---
> > drivers/pci/controller/pcie-mediatek.c | 26 ++++++++++++++++++++++++++
> > include/linux/pci_ids.h | 1 +
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > index d20cf461ba00..f8937cc3c87c 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -73,6 +73,7 @@
> > #define PCIE_MSI_VECTOR 0x0c0
> >
> > #define PCIE_CONF_VEND_ID 0x100
> > +#define PCIE_CONF_DEVICE_ID 0x102
> > #define PCIE_CONF_CLASS_ID 0x106
> >
> > #define PCIE_INT_MASK 0x420
> > @@ -135,12 +136,14 @@ struct mtk_pcie_port;
> > /**
> > * struct mtk_pcie_soc - differentiate between host generations
> > * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> > + * @need_fix_device_id: whether this host's device ID needed to be fixed or not
> > * @ops: pointer to configuration access functions
> > * @startup: pointer to controller setting functions
> > * @setup_irq: pointer to initialize IRQ functions
> > */
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > + bool need_fix_device_id;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >
> > + if (soc->need_fix_device_id) {
> > + val = PCI_DEVICE_ID_MEDIATEK_7629;
> > + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> > + }
> > +
> > /* 100ms timeout value should be enough for Gen1/2 training */
> > err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > !!(val & PCIE_PORT_LINKUP_V2), 20,
> > @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 = {
> > .setup_irq = mtk_pcie_setup_irq,
> > };
> >
> > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > + .need_fix_class_id = true,
> > + .need_fix_device_id = true,
> > + .ops = &mtk_pcie_ops_v2,
> > + .startup = mtk_pcie_startup_port_v2,
> > + .setup_irq = mtk_pcie_setup_irq,
> > +};
> > +
> > +static void mtk_fixup_bar_size(struct pci_dev *dev)
> > +{
> > + struct resource *dev_res = &dev->resource[0];
> > + /* 32bit resource length will calculate size to 0, set it smaller */
> > + dev_res->end = 0xfffffffe;
> > +}
>
> I'm not sure assign the BAR0 size in driver to fit in the bogus
> alignment is a good idea. Seems the size value of 0xffff_fffe also is an
> arbitrary value.
> Do we have a chance to change the resource framework code to make it
> adopt this scenario?
>
> Thanks.
I'm afraid not, the resource size length defined by phys_addr_t, which
related to the hardware's physical address length.
It will be much more better if the BAR0 size is not related with the
pcie to axi window, when we set the window to 4GB, the BAR0 size still
have initial value, and we can set the BAR0 size value or just disable
it independently.
The BAR0 size value need bigger than the MMIO space size, so the
software will think it's a invalid resource but not a bogus alignment
one, since we can't disable the BAR0 by hardware, and the flow of enable
devices will keep going.
>
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
> > + mtk_fixup_bar_size);
> > +
> > static const struct of_device_id mtk_pcie_ids[] = {
> > { .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
> > { .compatible = "mediatek,mt7622-pcie", .data = &mtk_pcie_soc_mt7622 },
> > + { .compatible = "mediatek,mt7629-pcie", .data = &mtk_pcie_soc_mt7629 },
> > {},
> > };
> >
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 69f0abe1ba1a..77b278bac3a8 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2126,6 +2126,7 @@
> > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> >
> > #define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +#define PCI_DEVICE_ID_MEDIATEK_7629 0x7629
> >
> > #define PCI_VENDOR_ID_TITAN 0x14D2
> > #define PCI_DEVICE_ID_TITAN_010L 0x8001
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Fix OMAP4430 SDP Ethernet startup
From: Russell King - ARM Linux @ 2018-12-07 12:52 UTC (permalink / raw)
To: Tony Lindgren, linux-arm-kernel, linux-omap, Santosh Shilimkar
It was noticed that unbinding and rebinding the KSZ8851 ethernet
resulted in the driver reporting "failed to read device ID" at probe.
Probing the reset line with a 'scope while repeatedly attempting to
bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
constantly held at zero, meaning the device is held in reset, and
does not respond on the SPI bus.
Experimentation with the startup delay on the regulator set to 50ms
shows that the reset is positively released after 20ms.
Schematics for this board are not available, and the traces are buried
in the inner layers of the board which makes tracing where the RSTN pin
extremely difficult. We can only guess that the RSTN pin is wired to a
reset generator chip driven off the ethernet supply, which fits the
observed behaviour.
Include this delay in the regulator startup delay - effectively
treating the reset as a "supply stable" indicator.
This can not be modelled as a delay in the KSZ8851 driver since the
reset generation is board specific - if the RSTN pin had been wired to
a GPIO, reset could be released earlier via the already provided support
in the KSZ8851 driver.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/omap4-sdp.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 0831a2bf6cec..57acf3a8b8a1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -33,6 +33,7 @@
gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>; /* gpio line 48 */
enable-active-high;
regulator-boot-on;
+ startup-delay-us = <25000>;
};
vbat: fixedregulator-vbat {
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/3] arm: Convert arm boot_lock to raw
From: Linus Walleij @ 2018-12-07 12:49 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: ext Tony Lindgren, viresh kumar, David Brown, Xu Wei,
Manivannan Sadhasivam, linux-samsung-soc, Viresh Kumar,
Russell King, Krzysztof Kozlowski, Maxime Ripard, Chen-Yu Tsai,
Kukjin Kim, Andy Gross, Arnd Bergmann, linux-arm-msm,
Thomas Gleixner, Linux-OMAP, Linux ARM, Barry Song, Frank Rowand,
Patrice CHOTARD, shiraz hashim, Andreas Färber
In-Reply-To: <20181207102749.15205-2-bigeasy@linutronix.de>
On Fri, Dec 7, 2018 at 11:28 AM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> From: Frank Rowand <frank.rowand@am.sony.com>
>
> The arm boot_lock is used by the secondary processor startup code. The locking
> task is the idle thread, which has idle->sched_class == &idle_sched_class.
> idle_sched_class->enqueue_task == NULL, so if the idle task blocks on the
> lock, the attempt to wake it when the lock becomes available will fail:
>
> try_to_wake_up()
> ...
> activate_task()
> enqueue_task()
> p->sched_class->enqueue_task(rq, p, flags)
>
> Fix by converting boot_lock to a raw spin lock.
This makes perfect sense.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: hibernate: Avoid sending cross-calling with interrupts disabled
From: Will Deacon @ 2018-12-07 12:47 UTC (permalink / raw)
To: catalin.marinas
Cc: Will Deacon, stable, james.morse, hayashi.kunihiko,
linux-arm-kernel
Since commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the
I-cache for kernel mappings"), a call to flush_icache_range() will use
an IPI to cross-call other online CPUs so that any stale instructions
are flushed from their pipelines. This triggers a WARN during the
hibernation resume path, where flush_icache_range() is called with
interrupts disabled and is therefore prone to deadlock:
| Disabling non-boot CPUs ...
| CPU1: shutdown
| psci: CPU1 killed.
| CPU2: shutdown
| psci: CPU2 killed.
| CPU3: shutdown
| psci: CPU3 killed.
| WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
| Modules linked in:
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1
Since all secondary CPUs have been taken offline prior to invalidating
the I-cache, there's actually no need for an IPI and we can simply call
__flush_icache_range() instead.
Cc: <stable@vger.kernel.org>
Fixes: 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 6b2686d54411..29cdc99688f3 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -214,7 +214,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
}
memcpy((void *)dst, src_start, length);
- flush_icache_range(dst, dst + length);
+ __flush_icache_range(dst, dst + length);
pgdp = pgd_offset_raw(allocator(mask), dst_addr);
if (pgd_none(READ_ONCE(*pgdp))) {
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/4] ARM: dts: am437x: Move l4 child devices to probe them with ti-sysc
From: Peter Ujfalusi @ 2018-12-07 12:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, Dave Gerlach, Keerthy, Tero Kristo,
Benoît Cousson, linux-omap, linux-arm-kernel
In-Reply-To: <20181205230242.GH6707@atomide.com>
Tony,
On 06/12/2018 1.02, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [181205 19:00]:
>> I think we're missing the top level ranges for mcasp l3 port
>> and the translation goes wrong there, I'll fix it hopefully
>> today.
>
> Below is a fix for am473x that works for me as tested with
> am473x-sk-evm. Care to test please?
the patch works, thanks!
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> I'll send also a similar fix for am335x separately. And
> then for dra7. Looks like for dra7 we're also missing the
> mcasp optional clocks too.
>
> Regards,
>
> Tony
>
> 8< ------------
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 5 Dec 2018 14:08:21 -0800
> Subject: [PATCH] ARM: dts: Add missing ranges for am437x mcasp l3 ports
>
> We need to add mcasp l3 port ranges for mcasp to use a correct l3
> data port address for dma.
>
> Fixes: d95adfd45853 ("ARM: dts: am437x: Move l4 child devices to
> probe them with ti-sysc")
> Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/am437x-l4.dtsi | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
> --- a/arch/arm/boot/dts/am437x-l4.dtsi
> +++ b/arch/arm/boot/dts/am437x-l4.dtsi
> @@ -613,7 +613,9 @@
> ranges = <0x00000000 0x48000000 0x100000>, /* segment 0 */
> <0x00100000 0x48100000 0x100000>, /* segment 1 */
> <0x00200000 0x48200000 0x100000>, /* segment 2 */
> - <0x00300000 0x48300000 0x100000>; /* segment 3 */
> + <0x00300000 0x48300000 0x100000>, /* segment 3 */
> + <0x46000000 0x46000000 0x400000>, /* l3 data port */
> + <0x46400000 0x46400000 0x400000>; /* l3 data port */
>
> segment@0 { /* 0x48000000 */
> compatible = "simple-bus";
> @@ -664,7 +666,9 @@
> <0x00034000 0x00034000 0x001000>, /* ap 80 */
> <0x00035000 0x00035000 0x001000>, /* ap 81 */
> <0x00036000 0x00036000 0x001000>, /* ap 84 */
> - <0x00037000 0x00037000 0x001000>; /* ap 85 */
> + <0x00037000 0x00037000 0x001000>, /* ap 85 */
> + <0x46000000 0x46000000 0x400000>, /* l3 data port */
> + <0x46400000 0x46400000 0x400000>; /* l3 data port */
>
> target-module@8000 { /* 0x48008000, ap 6 10.0 */
> compatible = "ti,sysc";
> @@ -826,7 +830,8 @@
> clock-names = "fck";
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0x0 0x38000 0x2000>;
> + ranges = <0x0 0x38000 0x2000>,
> + <0x46000000 0x46000000 0x400000>;
>
> mcasp0: mcasp@0 {
> compatible = "ti,am33xx-mcasp-audio";
> @@ -857,7 +862,8 @@
> clock-names = "fck";
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0x0 0x3c000 0x2000>;
> + ranges = <0x0 0x3c000 0x2000>,
> + <0x46400000 0x46400000 0x400000>;
>
> mcasp1: mcasp@0 {
> compatible = "ti,am33xx-mcasp-audio";
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] gpio: uniphier: convert to SPDX License Identifier
From: Linus Walleij @ 2018-12-07 12:40 UTC (permalink / raw)
To: Masahiro Yamada
Cc: open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org, Linux ARM,
Bartosz Golaszewski
In-Reply-To: <1544014449-5104-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, Dec 5, 2018 at 1:54 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> checkpatch.pl suggests to use SPDX license tag. I am happy to
> follow it.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: uniphier: convert to SPDX License Identifier
From: Linus Walleij @ 2018-12-07 12:39 UTC (permalink / raw)
To: Masahiro Yamada
Cc: open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <1544014419-5028-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, Dec 5, 2018 at 1:54 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> checkpatch.pl suggests to use SPDX license tag. I am happy to
> follow it.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: sunxi: a83t: Fix IRQ offset typo for PH11
From: Linus Walleij @ 2018-12-07 12:32 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, linux-kernel@vger.kernel.org, stable,
open list:GPIO SUBSYSTEM, linux-sunxi, Linux ARM
In-Reply-To: <20181204090457.15597-1-wens@csie.org>
On Tue, Dec 4, 2018 at 10:05 AM Chen-Yu Tsai <wens@csie.org> wrote:
> Pin PH11 is used on various A83T board to detect a change in the OTG
> port's ID pin, as in when an OTG host cable is plugged in.
>
> The incorrect offset meant the gpiochip/irqchip was activating the wrong
> pin for interrupts.
>
> Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Patch applied for fixes with Maxime's ACK.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: sunxi: a64: Drop numeral from csi0/ts0
From: Linus Walleij @ 2018-12-07 12:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, linux-sunxi, jagan, Linux ARM
In-Reply-To: <20181203154100.4280-1-wens@csie.org>
On Mon, Dec 3, 2018 at 4:41 PM Chen-Yu Tsai <wens@csie.org> wrote:
> This small series renames the csi0 and ts0 pin function names to csi and
> ts. This makes the names match the datasheet. As there are only one of
> each type of controller, having a numeral suffix doesn't make sense.
>
> I'd like to do the rename now while we don't have users nor support for
> these two controllers. I planned to send this together with CSI support
> for the A64, but Jagan beat me to it, so here it is.
Patch applied with Maxime's ACK.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mfd: convert to DEFINE_SHOW_ATTRIBUTE
From: Linus Walleij @ 2018-12-07 12:27 UTC (permalink / raw)
To: tiny.windzz; +Cc: Lee Jones, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <20181202021710.9307-1-tiny.windzz@gmail.com>
On Sun, Dec 2, 2018 at 3:17 AM Yangtao Li <tiny.windzz@gmail.com> wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: cedrus: don't initialize pointers with zero
From: Ian Arkver @ 2018-12-07 12:27 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <4a2f5566-c021-ed9c-a9f0-03d6bcd894d0@xs4all.nl>
On 07/12/2018 11:37, Hans Verkuil wrote:
> On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
>> Em Fri, 7 Dec 2018 12:14:50 +0100
>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>
>>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
>>>> A common mistake is to assume that initializing a var with:
>>>> struct foo f = { 0 };
>>>>
>>>> Would initialize a zeroed struct. Actually, what this does is
>>>> to initialize the first element of the struct to zero.
>>>>
>>>> According to C99 Standard 6.7.8.21:
>>>>
>>>> "If there are fewer initializers in a brace-enclosed
>>>> list than there are elements or members of an aggregate,
>>>> or fewer characters in a string literal used to initialize
>>>> an array of known size than there are elements in the array,
>>>> the remainder of the aggregate shall be initialized implicitly
>>>> the same as objects that have static storage duration."
>>>>
>>>> So, in practice, it could zero the entire struct, but, if the
>>>> first element is not an integer, it will produce warnings:
>>>>
>>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
>>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
>>>>
>>>> A proper way to initialize it with gcc is to use:
>>>>
>>>> struct foo f = { };
>>>>
>>>> But that seems to be a gcc extension. So, I decided to check upstream
>>>
>>> No, this is not a gcc extension. It's part of the latest C standard.
>>
>> Sure? Where the C standard spec states that? I've been seeking for
>> such info for a while, as '= {}' is also my personal preference.
>
> I believe it was added in C11, but I've loaned the book that stated
> that to someone else, so I can't check.
Sadly I don't see mention of empty initializer lists in section 6.7.9 of
ISO/IEC 9899:2011, though I've only got a draft version.
I had a play with Compiler Explorer[1] and it seems like clang is OK
with the {} form though just out of interest msvc isn't. I didn't try
exploring other command line options.
[1] https://gcc.godbolt.org/z/XIDC7W
Regards,
Ian
>
> In any case, it's used everywhere:
>
> git grep '= *{ *}' drivers/
>
> So it is really pointless to *not* use it.
>
> Regards,
>
> Hans
>
>> I tried to build the Kernel with clang, just to be sure that this
>> won't cause issues with the clang support, but, unfortunately, the
>> clang compiler (not even the upstream version) is able to build
>> the upstream Kernel yet, as it lacks asm-goto support (there is an
>> OOT patch for llvm solving it - but it sounds too much effort for
>> my time to have to build llvm from their sources just for a simple
>> check like this).
>>
>>> It's used all over in the kernel, so please use {} instead of { NULL }.
>>>
>>> Personally I think {} is a fantastic invention and I wish C++ had it as
>>> well.
>>
>> Fully agreed on that.
>>
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>>>>
>>>> $ git grep -E "=\s*\{\s*\}"|wc -l
>>>> 1951
>>>>
>>>> The standard-C compliant pattern has about 2500 entries:
>>>>
>>>> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
>>>> 137
>>>> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
>>>> 2323
>>>>
>>>> So, let's initialize those structs with:
>>>> = { NULL }
>>>>
>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>>>> ---
>>>> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
>>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>>> index b538eb0321d8..44c45c687503 100644
>>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>>> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
>>>> memset(ctx->ctrls, 0, ctrl_size);
>>>>
>>>> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
>>>> - struct v4l2_ctrl_config cfg = { 0 };
>>>> + struct v4l2_ctrl_config cfg = { NULL };
>>>>
>>>> cfg.elem_size = cedrus_controls[i].elem_size;
>>>> cfg.id = cedrus_controls[i].id;
>>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>>> index e40180a33951..4099a42dba2d 100644
>>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>>> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
>>>> {
>>>> struct cedrus_ctx *ctx = priv;
>>>> struct cedrus_dev *dev = ctx->dev;
>>>> - struct cedrus_run run = { 0 };
>>>> + struct cedrus_run run = { NULL };
>>>> struct media_request *src_req;
>>>> unsigned long flags;
>>>>
>>>>
>>>
>>
>>
>>
>> Thanks,
>> Mauro
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64: WARN_ON_ONCE issue when resuming from hibernation
From: Kunihiko Hayashi @ 2018-12-07 12:24 UTC (permalink / raw)
To: Will Deacon, James Morse; +Cc: arm, linux-arm-kernel
In-Reply-To: <a21290d6-12c3-4a4a-0156-71a28b5acab6@arm.com>
Hi Will, James,
On Fri, 7 Dec 2018 12:02:57 +0000 <james.morse@arm.com> wrote:
> Hi Kunihiko, Will,
>
> On 07/12/2018 10:47, Will Deacon wrote:
> > On Fri, Dec 07, 2018 at 10:40:50AM +0900, Kunihiko Hayashi wrote:
> >> I found that a WARN_ON_ONCE dump occured in the resuming sequence from
> >> hibernation on arm64 SoC (I use UniPhier LD20 environment).
> >>
> >> ...
> >> Disabling non-boot CPUs ...
> >> CPU1: shutdown
> >> psci: CPU1 killed.
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> CPU3: shutdown
> >> psci: CPU3 killed.
> >> WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
> >> Modules linked in:
> >> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1
> >> ...
> >>
> >> I show the result of reading the code, however,
> >> I'm not sure that this issue occurs in other arm64 SoC.
>
> It does, but you can only see it if you also have 'no_console_suspend' on the
> command-line, otherwise the console driver is frozen with the rest of the system
> when this happens.
Yes, I added 'no_console_suspend' to command-line.
Surely the console was frozen without it.
>
> Thanks for the report!
>
>
> >> In the resuming sequence, once all CPUs are stopped and local IRQs
> >> are disabled [1].
>
> >> What is the possible way to solve this issue?
> >
> > Given that all secondary CPUs are hotplugged out at this point, we can
> > just use the non-IPI version of flush_icache_range().
>
> Sounds good,
Thanks for your solution.
Surely we can call this non-IPI version in create_safe_exec_page().
> > --->8
> >
> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > index 6b2686d54411..29cdc99688f3 100644
> > --- a/arch/arm64/kernel/hibernate.c
> > +++ b/arch/arm64/kernel/hibernate.c
> > @@ -214,7 +214,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> > }
> >
> > memcpy((void *)dst, src_start, length);
> > - flush_icache_range(dst, dst + length);
> > + __flush_icache_range(dst, dst + length);
> >
> > pgdp = pgd_offset_raw(allocator(mask), dst_addr);
> > if (pgd_none(READ_ONCE(*pgdp))) {
> >
>
> Tested-by: James Morse <james.morse@arm.com>
I also tried your diff and resume sequence from hibernation finished successfully
without WARN_ON_ONCE().
Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> This changed came from commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after
> invalidating the I-cache for kernel mappings"). Which came in with v4.19 if you
> want to send it to stable. (let me know if its easier for you if I re-post your
> patch)
Agreed.
Thank you,
>
> Thanks,
>
> James
---
Best Regards,
Kunihiko Hayashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document
From: Russell King - ARM Linux @ 2018-12-07 12:17 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Mark Rutland, Rob Herring, Jason Cooper, Andrew Lunn, netdev,
Gregory CLEMENT, Maxime Chevallier, devicetree, Thomas Petazzoni,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sebastian Hesselbarth
In-Reply-To: <0dc0916f-2654-53fe-226d-f75c9498bb39@ti.com>
On Fri, Dec 07, 2018 at 05:30:52PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 07/12/18 5:03 PM, Russell King - ARM Linux wrote:
> > On Fri, Dec 07, 2018 at 04:43:27PM +0530, Kishon Vijay Abraham I wrote:
> >> Russell,
> >>
> >> No, I haven't merged patches from this series. That would have failed
> >> compilation since Grygorii modified enum phy_mode which is used in this series.
> >> You have also noted this in your cover letter.
> >
> > Ok, but in any case, given the complexities of modifying the patch
> > and properly testing it, I think I'll wait until those changes have
> > hit mainline before re-spinning this series. Alternatively, if
> > you're happy to take just build-tested version, I could re-spin
> > with that so at least we can get the phy bits queued for the merge
> > window.
>
> I'd prefer we test it before merging.
Okay, expect it sometime after Christmas. In any case, waiting for
the upheaval in the phy API to hit mainline will need to happen to
that netdev is in sync with the revised phy API.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [2nd RESEND PATCH 1/2] i2c: enable buses to save their clock frequency in adapter
From: Peter Rosin @ 2018-12-07 12:17 UTC (permalink / raw)
To: Tudor.Ambarus@microchip.com, wsa@the-dreams.de
Cc: alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org,
Ludovic.Desroches@microchip.com, linux-i2c@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181207112939.15791-2-tudor.ambarus@microchip.com>
On 2018-12-07 12:29, Tudor.Ambarus@microchip.com wrote:
> From: "Tudor.Ambarus@microchip.com" <Tudor.Ambarus@microchip.com>
>
> The clock-frequency property is not mandatory for the i2c buses. If it's
> not present in the device tree, the buses __usually__ assume it's 100kHZ
> (see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
> clock-frequency, so the default clock frequency varies from bus to bus.
>
> There are i2c clients that need to know the bus clock frequency in order to
> compute their wake token (see atecc508a i2c client).
>
> The clock-frequency value has to be propagated to the i2c clients, otherwise,
> if they will not find the i2c bus clock frequency in the device tree, they
> will have to make their own assumption of the clock frequency.
>
> Spare the i2c clients of making wrong assumptions of the i2c bus clock
> frequency and enable the buses to save their clock frequency in adapter.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> Reviwed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
This is not the correct spelling of the tag and probably the reason for
the lack of reaction from Wolfram. The tag has simply not showed up in
patchwork and the patch has thus been postponed. Probably...
Cheers,
Peter
> ---
> include/linux/i2c.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 65b4eaed1d96..f238da204c49 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -677,6 +677,7 @@ struct i2c_adapter {
> struct rt_mutex bus_lock;
> struct rt_mutex mux_lock;
>
> + u32 bus_freq_hz;
> int timeout; /* in jiffies */
> int retries;
> struct device dev; /* the adapter device */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: WIP: UFS on apq8098
From: Marc Gonzalez @ 2018-12-07 12:10 UTC (permalink / raw)
To: Evan Green
Cc: Jeffrey Hugo, MSM, Stephen Boyd, Bjorn Andersson, Andy Gross,
Nicolas Dechesne, Linux ARM
In-Reply-To: <CAE=gft7Pd5u4Axa1XNf+tSYC_awxT8VLNXfJg7820LA1z9RtZg@mail.gmail.com>
On 06/12/2018 17:45, Evan Green wrote:
> I'll throw my random thought into the hopper here. With one particular
> brand of UFS part on SDM845 we needed to make sure we banged on the
> ufs_reset pin before the device would re-initialize fully. My hunch
> says this is not your issue, but it can't hurt to make sure this is
> happening.
You might be on to something.
Downstream handles the pinctrl nodes, while upstream doesn't.
$ git grep pinc vendor -- drivers/scsi/ufs/
vendor:drivers/scsi/ufs/ufshcd-pltfrm.c:static int ufshcd_parse_pinctrl_info(struct ufs_hba *hba)
vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: /* Try to obtain pinctrl handle */
vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: hba->pctrl = devm_pinctrl_get(hba->dev);
vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: err = ufshcd_parse_pinctrl_info(hba);
vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: dev_dbg(&pdev->dev, "%s: unable to parse pinctrl data %d\n",
vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-assert"));
vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-deassert"));
vendor:drivers/scsi/ufs/ufshcd.h: struct pinctrl *pctrl;
$ git grep pinc master -- drivers/scsi/ufs/
/* NOTHING */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64: WARN_ON_ONCE issue when resuming from hibernation
From: James Morse @ 2018-12-07 12:02 UTC (permalink / raw)
To: Will Deacon, Kunihiko Hayashi; +Cc: arm, linux-arm-kernel
In-Reply-To: <20181207104743.GB23587@arm.com>
Hi Kunihiko, Will,
On 07/12/2018 10:47, Will Deacon wrote:
> On Fri, Dec 07, 2018 at 10:40:50AM +0900, Kunihiko Hayashi wrote:
>> I found that a WARN_ON_ONCE dump occured in the resuming sequence from
>> hibernation on arm64 SoC (I use UniPhier LD20 environment).
>>
>> ...
>> Disabling non-boot CPUs ...
>> CPU1: shutdown
>> psci: CPU1 killed.
>> CPU2: shutdown
>> psci: CPU2 killed.
>> CPU3: shutdown
>> psci: CPU3 killed.
>> WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1
>> ...
>>
>> I show the result of reading the code, however,
>> I'm not sure that this issue occurs in other arm64 SoC.
It does, but you can only see it if you also have 'no_console_suspend' on the
command-line, otherwise the console driver is frozen with the rest of the system
when this happens.
Thanks for the report!
>> In the resuming sequence, once all CPUs are stopped and local IRQs
>> are disabled [1].
>> What is the possible way to solve this issue?
>
> Given that all secondary CPUs are hotplugged out at this point, we can
> just use the non-IPI version of flush_icache_range().
Sounds good,
> --->8
>
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 6b2686d54411..29cdc99688f3 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -214,7 +214,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> }
>
> memcpy((void *)dst, src_start, length);
> - flush_icache_range(dst, dst + length);
> + __flush_icache_range(dst, dst + length);
>
> pgdp = pgd_offset_raw(allocator(mask), dst_addr);
> if (pgd_none(READ_ONCE(*pgdp))) {
>
Tested-by: James Morse <james.morse@arm.com>
This changed came from commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after
invalidating the I-cache for kernel mappings"). Which came in with v4.19 if you
want to send it to stable. (let me know if its easier for you if I re-post your
patch)
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 4/7] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD
From: Suzuki K Poulose @ 2018-12-07 12:04 UTC (permalink / raw)
To: Steve Capper, linux-mm, linux-arm-kernel
Cc: catalin.marinas, will.deacon, jcm, ard.biesheuvel
In-Reply-To: <20181206225042.11548-5-steve.capper@arm.com>
On 12/06/2018 10:50 PM, Steve Capper wrote:
> Enabling 52-bit VAs on arm64 requires that the PGD table expands from 64
> entries (for the 48-bit case) to 1024 entries. This quantity,
> PTRS_PER_PGD is used as follows to compute which PGD entry corresponds
> to a given virtual address, addr:
>
> pgd_index(addr) -> (addr >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)
>
> Userspace addresses are prefixed by 0's, so for a 48-bit userspace
> address, uva, the following is true:
> (uva >> PGDIR_SHIFT) & (1024 - 1) == (uva >> PGDIR_SHIFT) & (64 - 1)
>
> In other words, a 48-bit userspace address will have the same pgd_index
> when using PTRS_PER_PGD = 64 and 1024.
>
> Kernel addresses are prefixed by 1's so, given a 48-bit kernel address,
> kva, we have the following inequality:
> (kva >> PGDIR_SHIFT) & (1024 - 1) != (kva >> PGDIR_SHIFT) & (64 - 1)
>
> In other words a 48-bit kernel virtual address will have a different
> pgd_index when using PTRS_PER_PGD = 64 and 1024.
>
> If, however, we note that:
> kva = 0xFFFF << 48 + lower (where lower[63:48] == 0b)
> and, PGDIR_SHIFT = 42 (as we are dealing with 64KB PAGE_SIZE)
>
> We can consider:
> (kva >> PGDIR_SHIFT) & (1024 - 1) - (kva >> PGDIR_SHIFT) & (64 - 1)
> = (0xFFFF << 6) & 0x3FF - (0xFFFF << 6) & 0x3F // "lower" cancels out
> = 0x3C0
>
> In other words, one can switch PTRS_PER_PGD to the 52-bit value globally
> provided that they increment ttbr1_el1 by 0x3C0 * 8 = 0x1E00 bytes when
> running with 48-bit kernel VAs (TCR_EL1.T1SZ = 16).
>
> For kernel configuration where 52-bit userspace VAs are possible, this
> patch offsets ttbr1_el1 and sets PTRS_PER_PGD corresponding to the
> 52-bit value.
>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
>
> ---
>
> Changed in V5, removed ttbr1 save/restore logic for software PAN as
> hardware PAN is a mandatory ARMv8.1 feature anyway. The logic to enable
> 52-bit VAs has also been changed to depend on
> ARM64_PAN || !ARM64_SW_TTBR0_PAN
> (in a later patch)
>
> This patch is new in V4 of the series
> ---
> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
> arch/arm64/include/asm/pgtable-hwdef.h | 9 +++++++++
> arch/arm64/kernel/head.S | 1 +
> arch/arm64/kernel/hibernate-asm.S | 1 +
> arch/arm64/mm/proc.S | 4 ++++
> 5 files changed, 38 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 6142402c2eb4..e2fe378d2a63 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -515,6 +515,29 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU
> mrs \rd, sp_el0
> .endm
>
> +/*
> + * Offset ttbr1 to allow for 48-bit kernel VAs set with 52-bit PTRS_PER_PGD.
> + * orr is used as it can cover the immediate value (and is idempotent).
> + * In future this may be nop'ed out when dealing with 52-bit kernel VAs.
> + * ttbr: Value of ttbr to set, modified.
> + */
> + .macro offset_ttbr1, ttbr
> +#ifdef CONFIG_ARM64_52BIT_VA
> + orr \ttbr, \ttbr, #TTBR1_BADDR_4852_OFFSET
> +#endif
> + .endm
> +
> +/*
> + * Perform the reverse of offset_ttbr1.
> + * bic is used as it can cover the immediate value and, in future, won't need
> + * to be nop'ed out when dealing with 52-bit kernel VAs.
> + */
> + .macro restore_ttbr1, ttbr
> +#ifdef CONFIG_ARM64_52BIT_VA
> + bic \ttbr, \ttbr, #TTBR1_BADDR_4852_OFFSET
> +#endif
> + .endm
> +
The above operation is safe as long as the TTBR1_BADDR_4852_OFFSET is
aligned to 2^6 or more. Otherwise we could corrupt the Bits[51:48]
of the BADDR stored in TTBR1[5:2] and thus the TTBR1:BADDR must be
aligned to 64bytes minimum as per v8.2LVA restrictions. Since we have
restricted the VA_BITS to 48, we should be safe here.
Do we need a BUILD_BUG_ON() or something to check if this is still valid?
Eitherway,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document
From: Kishon Vijay Abraham I @ 2018-12-07 12:00 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Rob Herring, Jason Cooper, Andrew Lunn, netdev,
Gregory CLEMENT, Maxime Chevallier, devicetree, Thomas Petazzoni,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sebastian Hesselbarth
In-Reply-To: <20181207113301.GZ30658@n2100.armlinux.org.uk>
Hi,
On 07/12/18 5:03 PM, Russell King - ARM Linux wrote:
> On Fri, Dec 07, 2018 at 04:43:27PM +0530, Kishon Vijay Abraham I wrote:
>> Russell,
>>
>> No, I haven't merged patches from this series. That would have failed
>> compilation since Grygorii modified enum phy_mode which is used in this series.
>> You have also noted this in your cover letter.
>
> Ok, but in any case, given the complexities of modifying the patch
> and properly testing it, I think I'll wait until those changes have
> hit mainline before re-spinning this series. Alternatively, if
> you're happy to take just build-tested version, I could re-spin
> with that so at least we can get the phy bits queued for the merge
> window.
I'd prefer we test it before merging.
>
> In any case, I'm busy trying to get to the bottom of several OMAP4
> bugs while ill, so this isn't something I want to do at the moment.
Take care!
Thanks
Kishon
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 6/7] arm64: mm: introduce 52-bit userspace support
From: Catalin Marinas @ 2018-12-07 11:55 UTC (permalink / raw)
To: Steve Capper
Cc: suzuki.poulose, jcm, ard.biesheuvel, will.deacon, linux-mm,
linux-arm-kernel
In-Reply-To: <20181206225042.11548-7-steve.capper@arm.com>
On Thu, Dec 06, 2018 at 10:50:41PM +0000, Steve Capper wrote:
> On arm64 there is optional support for a 52-bit virtual address space.
> To exploit this one has to be running with a 64KB page size and be
> running on hardware that supports this.
>
> For an arm64 kernel supporting a 48 bit VA with a 64KB page size,
> some changes are needed to support a 52-bit userspace:
> * TCR_EL1.T0SZ needs to be 12 instead of 16,
> * TASK_SIZE needs to reflect the new size.
>
> This patch implements the above when the support for 52-bit VAs is
> detected at early boot time.
>
> On arm64 userspace addresses translation is controlled by TTBR0_EL1. As
> well as userspace, TTBR0_EL1 controls:
> * The identity mapping,
> * EFI runtime code.
>
> It is possible to run a kernel with an identity mapping that has a
> larger VA size than userspace (and for this case __cpu_set_tcr_t0sz()
> would set TCR_EL1.T0SZ as appropriate). However, when the conditions for
> 52-bit userspace are met; it is possible to keep TCR_EL1.T0SZ fixed at
> 12. Thus in this patch, the TCR_EL1.T0SZ size changing logic is
> disabled.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: cedrus: don't initialize pointers with zero
From: Mauro Carvalho Chehab @ 2018-12-07 11:31 UTC (permalink / raw)
To: Hans Verkuil
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <ff5fe553-fee4-bc5c-d1e9-9dc4cc1319ba@xs4all.nl>
Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > A common mistake is to assume that initializing a var with:
> > struct foo f = { 0 };
> >
> > Would initialize a zeroed struct. Actually, what this does is
> > to initialize the first element of the struct to zero.
> >
> > According to C99 Standard 6.7.8.21:
> >
> > "If there are fewer initializers in a brace-enclosed
> > list than there are elements or members of an aggregate,
> > or fewer characters in a string literal used to initialize
> > an array of known size than there are elements in the array,
> > the remainder of the aggregate shall be initialized implicitly
> > the same as objects that have static storage duration."
> >
> > So, in practice, it could zero the entire struct, but, if the
> > first element is not an integer, it will produce warnings:
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
> >
> > A proper way to initialize it with gcc is to use:
> >
> > struct foo f = { };
> >
> > But that seems to be a gcc extension. So, I decided to check upstream
>
> No, this is not a gcc extension. It's part of the latest C standard.
Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.
I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).
> It's used all over in the kernel, so please use {} instead of { NULL }.
>
> Personally I think {} is a fantastic invention and I wish C++ had it as
> well.
Fully agreed on that.
>
> Regards,
>
> Hans
>
> > what's the most commonly pattern. The gcc pattern has about 2000 entries:
> >
> > $ git grep -E "=\s*\{\s*\}"|wc -l
> > 1951
> >
> > The standard-C compliant pattern has about 2500 entries:
> >
> > $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> > 137
> > $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> > 2323
> >
> > So, let's initialize those structs with:
> > = { NULL }
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > index b538eb0321d8..44c45c687503 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
> > memset(ctx->ctrls, 0, ctrl_size);
> >
> > for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> > - struct v4l2_ctrl_config cfg = { 0 };
> > + struct v4l2_ctrl_config cfg = { NULL };
> >
> > cfg.elem_size = cedrus_controls[i].elem_size;
> > cfg.id = cedrus_controls[i].id;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index e40180a33951..4099a42dba2d 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> > {
> > struct cedrus_ctx *ctx = priv;
> > struct cedrus_dev *dev = ctx->dev;
> > - struct cedrus_run run = { 0 };
> > + struct cedrus_run run = { NULL };
> > struct media_request *src_req;
> > unsigned long flags;
> >
> >
>
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 30/34] dt-bindings: arm: Convert Tegra board/soc bindings to json-schema
From: Thierry Reding @ 2018-12-07 11:46 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, Frank Rowand, linux-kernel@vger.kernel.org,
Jon Hunter, Grant Likely, linux-tegra, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+NWVoFzBCYVwu-YM_90mYUdgmaW4ctJim2LkxfpRbg=Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4849 bytes --]
On Thu, Dec 06, 2018 at 04:38:44PM -0600, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 2:50 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Mon, Dec 03, 2018 at 03:32:19PM -0600, Rob Herring wrote:
> > > Convert Tegra SoC bindings to DT schema format using json-schema.
> > >
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Thierry Reding <thierry.reding@gmail.com>
> > > Cc: Jonathan Hunter <jonathanh@nvidia.com>
> > > Cc: devicetree@vger.kernel.org
> > > Cc: linux-tegra@vger.kernel.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > .../devicetree/bindings/arm/tegra.txt | 65 -----------
> > > .../devicetree/bindings/arm/tegra.yaml | 101 ++++++++++++++++++
> > > 2 files changed, 101 insertions(+), 65 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt
> > > create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
> > > deleted file mode 100644
> > > index c59b15f64346..000000000000
> > > --- a/Documentation/devicetree/bindings/arm/tegra.txt
> > > +++ /dev/null
> > > @@ -1,65 +0,0 @@
> > > -NVIDIA Tegra device tree bindings
> > > --------------------------------------------
> > > -
> > > -SoCs
> > > --------------------------------------------
> > > -
> > > -Each device tree must specify which Tegra SoC it uses, using one of the
> > > -following compatible values:
> > > -
> > > - nvidia,tegra20
> > > - nvidia,tegra30
> > > - nvidia,tegra114
> > > - nvidia,tegra124
> > > - nvidia,tegra132
> > > - nvidia,tegra210
> > > - nvidia,tegra186
> > > - nvidia,tegra194
> > > -
> > > -Boards
> > > --------------------------------------------
> > > -
> > > -Each device tree must specify which one or more of the following
> > > -board-specific compatible values:
> > > -
> > > - ad,medcom-wide
> > > - ad,plutux
> > > - ad,tamonten
> > > - ad,tec
> > > - compal,paz00
> > > - compulab,trimslice
> > > - nvidia,beaver
> > > - nvidia,cardhu
> > > - nvidia,cardhu-a02
> > > - nvidia,cardhu-a04
> > > - nvidia,dalmore
> > > - nvidia,harmony
> > > - nvidia,jetson-tk1
> > > - nvidia,norrin
> > > - nvidia,p2371-0000
> > > - nvidia,p2371-2180
> > > - nvidia,p2571
> > > - nvidia,p2771-0000
> > > - nvidia,p2972-0000
> > > - nvidia,roth
> > > - nvidia,seaboard
> > > - nvidia,tn7
> > > - nvidia,ventana
> > > - toradex,apalis_t30
> > > - toradex,apalis_t30-eval
> > > - toradex,apalis_t30-v1.1
> > > - toradex,apalis_t30-v1.1-eval
> > > - toradex,apalis-tk1
> > > - toradex,apalis-tk1-eval
> > > - toradex,apalis-tk1-v1.2
> > > - toradex,apalis-tk1-v1.2-eval
> > > - toradex,colibri_t20
> > > - toradex,colibri_t20-eval-v3
> > > - toradex,colibri_t20-iris
> > > - toradex,colibri_t30
> > > - toradex,colibri_t30-eval-v3
> > > -
> > > -Trusted Foundations
> > > --------------------------------------------
> > > -Tegra supports the Trusted Foundation secure monitor. See the
> > > -"tlm,trusted-foundations" binding's documentation for more details.
> > > diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
> > > new file mode 100644
> > > index 000000000000..66493892ffc1
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
> > > @@ -0,0 +1,101 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/tegra.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > Could you explain what these are? They give 404, so I assume they are
> > more like placeholders and not actually used?
>
> Please read the documentation in patch 2. They are used, but aren't live URLs.
Okay, thanks for pointing that out. I wasn't Cc'ed on that patch, so it
took a while to hunt it down.
> > > +
> > > +title: NVIDIA Tegra device tree bindings
> > > +
> > > +maintainers:
> > > + - Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > + - Peter De Schrijver <pdeschrijver@nvidia.com>
> >
> > Not sure how you got that list, but probably from git history. I think
> > it makes sense to replace Marcel and Peter with Jon and myself.
>
> Will do.
>
> > Other than that, looks fine to me. Some of the enumerations below look
> > somewhat hard to parse, but I suspect that it will become second nature
> > in no time.
>
> We can add descriptions and/or comments if that helps. I didn't add
> them if not already there.
My comment was regarding the schema syntax with the oneOf, - items, etc.
That's all new to me and difficult to read, but I'm sure I'll get used
to it.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: cedrus: don't initialize pointers with zero
From: Hans Verkuil @ 2018-12-07 11:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <20181207093106.4f112d0b@coco.lan>
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
>>> A common mistake is to assume that initializing a var with:
>>> struct foo f = { 0 };
>>>
>>> Would initialize a zeroed struct. Actually, what this does is
>>> to initialize the first element of the struct to zero.
>>>
>>> According to C99 Standard 6.7.8.21:
>>>
>>> "If there are fewer initializers in a brace-enclosed
>>> list than there are elements or members of an aggregate,
>>> or fewer characters in a string literal used to initialize
>>> an array of known size than there are elements in the array,
>>> the remainder of the aggregate shall be initialized implicitly
>>> the same as objects that have static storage duration."
>>>
>>> So, in practice, it could zero the entire struct, but, if the
>>> first element is not an integer, it will produce warnings:
>>>
>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
>>>
>>> A proper way to initialize it with gcc is to use:
>>>
>>> struct foo f = { };
>>>
>>> But that seems to be a gcc extension. So, I decided to check upstream
>>
>> No, this is not a gcc extension. It's part of the latest C standard.
>
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.
I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.
In any case, it's used everywhere:
git grep '= *{ *}' drivers/
So it is really pointless to *not* use it.
Regards,
Hans
> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support, but, unfortunately, the
> clang compiler (not even the upstream version) is able to build
> the upstream Kernel yet, as it lacks asm-goto support (there is an
> OOT patch for llvm solving it - but it sounds too much effort for
> my time to have to build llvm from their sources just for a simple
> check like this).
>
>> It's used all over in the kernel, so please use {} instead of { NULL }.
>>
>> Personally I think {} is a fantastic invention and I wish C++ had it as
>> well.
>
> Fully agreed on that.
>
>>
>> Regards,
>>
>> Hans
>>
>>> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>>>
>>> $ git grep -E "=\s*\{\s*\}"|wc -l
>>> 1951
>>>
>>> The standard-C compliant pattern has about 2500 entries:
>>>
>>> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
>>> 137
>>> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
>>> 2323
>>>
>>> So, let's initialize those structs with:
>>> = { NULL }
>>>
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>>> ---
>>> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> index b538eb0321d8..44c45c687503 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
>>> memset(ctx->ctrls, 0, ctrl_size);
>>>
>>> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
>>> - struct v4l2_ctrl_config cfg = { 0 };
>>> + struct v4l2_ctrl_config cfg = { NULL };
>>>
>>> cfg.elem_size = cedrus_controls[i].elem_size;
>>> cfg.id = cedrus_controls[i].id;
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> index e40180a33951..4099a42dba2d 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
>>> {
>>> struct cedrus_ctx *ctx = priv;
>>> struct cedrus_dev *dev = ctx->dev;
>>> - struct cedrus_run run = { 0 };
>>> + struct cedrus_run run = { NULL };
>>> struct media_request *src_req;
>>> unsigned long flags;
>>>
>>>
>>
>
>
>
> Thanks,
> Mauro
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] PCIE support for i.MX8MQ
From: Lorenzo Pieralisi @ 2018-12-07 11:37 UTC (permalink / raw)
To: Andrey Smirnov
Cc: A.s. Dong, Richard Zhu, linux-arm-kernel, linux-pci, linux-kernel,
Fabio Estevam, linux-imx, bhelgaas, Leonard Crestez, cphealy,
l.stach
In-Reply-To: <20181117181225.10737-1-andrew.smirnov@gmail.com>
On Sat, Nov 17, 2018 at 10:12:22AM -0800, Andrey Smirnov wrote:
>
> Everyone:
>
> This series contains changes I made in order to enable support of PCIE
> IP block on i.MX8MQ SoCs (full tree can be found at [github-v0]). This series
> is _very_ preliminary and by no means is ready for inclusion (it also
> has some unmet dependencies). However is should be in OK enough shape
> to get some early feedback on, which is the intent of this submission.
>
> Specifically, I'd like to get some feedback on whether newly
> introduced "fsl,iomux-gpr1x" and "fsl,gpr12-device-type" DT
> properties, added to handle differences between PCIE0 and PCIE1, is a
> good (acceptable) solution for the problem.
>
> All other feedback is appreciated as well!
>
> Thank you,
> Andrey Smirnov
>
> [github-v0] https://github.com/ndreys/linux/commits/imx8mq-pcie-v0
>
> Andrey Smirnov (3):
> PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D
> PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D
> PCI: imx: Add support for i.MX8MQ
>
> drivers/pci/controller/dwc/Kconfig | 2 +-
> drivers/pci/controller/dwc/pci-imx6.c | 119 +++++++++++++++++++++++++-
> 2 files changed, 117 insertions(+), 4 deletions(-)
Applied to pci/dwc for v4.21, thanks.
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Biju Das @ 2018-12-07 11:27 UTC (permalink / raw)
To: Simon Horman
Cc: linux-rtc, Fabrizio Castro, Alexandre Belloni, Geert Uytterhoeven,
Magnus Damm, Russell King, Biju Das, linux-renesas-soc,
Chris Paterson, Srinivas Kandagatla, linux-arm-kernel
In-Reply-To: <1544182066-31528-1-git-send-email-biju.das@bp.renesas.com>
The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
support enable the driver in the shmobile_defconfig multiplatform
configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V1-->V2
* No change.
V2-->V3
* No change.
V3-->V4
* No Change.
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 9e5a5ad..fdac4e4 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -177,6 +177,7 @@ CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_PCF85363=y
CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
CONFIG_RTC_DRV_RX8581=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox