* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Huang Shijie @ 2016-12-06 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205093100.GF30758@dhcp22.suse.cz>
On Mon, Dec 05, 2016 at 05:31:01PM +0800, Michal Hocko wrote:
> On Mon 05-12-16 17:17:07, Huang Shijie wrote:
> [...]
> > The failure is caused by:
> > 1) kernel fails to allocate a gigantic page for the surplus case.
> > And the gather_surplus_pages() will return NULL in the end.
> >
> > 2) The condition checks for some functions are wrong:
> > return_unused_surplus_pages()
> > nr_overcommit_hugepages_store()
> > hugetlb_overcommit_handler()
>
> OK, so how is this any different from gigantic (1G) hugetlb pages on
I think there is no different from gigantic (1G) hugetlb pages on
x86_64. Do anyone ever tested the 1G hugetlb pages in x86_64 with the "counter.sh"
before?
> x86_64? Do we need the same functionality or is it just 32MB not being
> handled in the same way as 1G?
Yes, we need this functionality for gigantic pages, no matter it is
X86_64 or S390 or arm64, no matter it is 32MB or 1G. :)
But anyway, I will try to find some machine and try the 1G gigantic page
on ARM64.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2016-12-06 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbf4b99b-e453-acd5-d864-f709708fbab0@baylibre.com>
On Tuesday 06 December 2016 03:21 PM, Alexandre Bailon wrote:
> On 12/06/2016 10:33 AM, Sekhar Nori wrote:
>> On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
>>> Everytime the usb20 phy is enabled, there is a
>>> "sleeping function called from invalid context" BUG.
>>>
>>> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
>>> before to invoke the callback usb20_phy_clk_enable().
>>> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
>>> which may sleep.
>>> Move clk_get() to da8xx_register_usb20_phy_clk() and
>>> replace clk_prepare_enable() by clk_enable().
>>>
>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>
>> This will still cause the recursive locking problem reported by David.
>> Not sure what the point of sending this version was.
>>
>> Thanks,
>> Sekhar
>>
> What am I supposed to do ?
That needs to be resolved between you and David. Perhaps convert the fix
sent by David into a proper patch and base this patch on that. Or wait
for David to send it himself and let him also make the modifications
needed in this patch.
David ?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Alexandre Torgue @ 2016-12-06 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206094835.GB25385@dell.home>
Hi Lee,
On 12/06/2016 10:48 AM, Lee Jones wrote:
> On Mon, 05 Dec 2016, Alexandre Torgue wrote:
>> On 12/02/2016 02:22 PM, Lee Jones wrote:
>>> On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
>>>
>>>> Add general purpose timers and it sub-nodes into DT for stm32f4.
>>>> Define and enable pwm1 and pwm3 for stm32f469 discovery board
>>>>
>>>> version 3:
>>>> - use "st,stm32-timer-trigger" in DT
>>>>
>>>> version 2:
>>>> - use parameters to describe hardware capabilities
>>>> - do not use references for pwm and iio timer subnodes
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> ---
>>>> arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
>>>> arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
>>>> 2 files changed, 360 insertions(+), 1 deletion(-)
>
> [...]
>
> If you're only commenting on a little piece of the patch, it's always
> a good idea to trim the rest.
>
>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> index 8a163d7..df4ca7e 100644
>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> @@ -81,3 +81,31 @@
>>>> &usart3 {
>>>> status = "okay";
>>>> };
>>>> +
>>>> +&gptimer1 {
>>>> + status = "okay";
>>>> +
>>>> + pwm1 at 0 {
>>>> + pinctrl-0 = <&pwm1_pins>;
>>>> + pinctrl-names = "default";
>>>> + status = "okay";
>>>> + };
>>>> +
>>>> + timer1 at 0 {
>>>> + status = "okay";
>>>> + };
>>>> +};
>>>
>>> This is a much *better* format than before.
>>>
>>> I still don't like the '&' syntax though.
>>
>> Please keep "&" format to match with existing nodes.
>
> Right. I wasn't suggesting that he differs from the current format in
> *this* set. I am suggesting that we change the format in a subsequent
> set though.
Why change? Looking at Linux ARM kernel patchwork, new DT board file
contains this format. Did you already discuss with Arnd or Olof about it
?
regards
Alex
>
>>>> +&gptimer3 {
>>>> + status = "okay";
>>>> +
>>>> + pwm3 at 0 {
>>>> + pinctrl-0 = <&pwm3_pins>;
>>>> + pinctrl-names = "default";
>>>> + status = "okay";
>>>> + };
>>>> +
>>>> + timer3 at 0 {
>>>> + status = "okay";
>>>> + };
>>>> +};
>>>
>
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Ming Lei @ 2016-12-06 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201113031.GB5813@arm.com>
Hi Will,
On Thu, Dec 1, 2016 at 7:30 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
>> When I run stress-ng via the following steps on one ARM64 dual
>> socket system(Cavium Thunder), the kernel oops[1] can often be
>> triggered after running the stress test for several hours(sometimes
>> it may take longer):
>>
>> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
>> - apply the attachment patch which just makes the posix file
>> lock stress test more aggressive
>> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>>
>>
>> From the oops log, looks one garbage file_lock node is got
>> from the linked list of 'ctx->flc_posix' when the issue happens.
>>
>> BTW, the issue isn't observed on single socket Cavium Thunder yet,
>> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
>> too.
>
> FWIW, I've been running this on Seattle for 24 hours with your patch applied
> and not seen any problems yet. That said, Thomas did just fix an rt_mutex
> race which only seemed to pop up on Thunder, so you could give those
> patches a try.
>
> https://lkml.kernel.org/r/20161130205431.629977871 at linutronix.de
I applied the patch against Ubuntu Yakkety kernel(v4.8 based), and run
the test again on one dual-socket Cavium ThunderX system, and the
issue can still be triggered.
So looks not a same issue with David Daney's.
Anyway, thank you for providing this input!
Thanks,
Ming
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-06 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fc7a4ef-02ad-fc15-66ea-9f75756086f8@ti.com>
On 12/06/2016 10:33 AM, Sekhar Nori wrote:
> On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
>> Everytime the usb20 phy is enabled, there is a
>> "sleeping function called from invalid context" BUG.
>>
>> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
>> before to invoke the callback usb20_phy_clk_enable().
>> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
>> which may sleep.
>> Move clk_get() to da8xx_register_usb20_phy_clk() and
>> replace clk_prepare_enable() by clk_enable().
>>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>
> This will still cause the recursive locking problem reported by David.
> Not sure what the point of sending this version was.
>
> Thanks,
> Sekhar
>
What am I supposed to do ?
Thanks,
Alexandre
^ permalink raw reply
* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Lee Jones @ 2016-12-06 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e15186cb-a93e-c2e7-13bb-6704be5e8949@st.com>
On Mon, 05 Dec 2016, Alexandre Torgue wrote:
> On 12/02/2016 02:22 PM, Lee Jones wrote:
> > On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
> >
> > > Add general purpose timers and it sub-nodes into DT for stm32f4.
> > > Define and enable pwm1 and pwm3 for stm32f469 discovery board
> > >
> > > version 3:
> > > - use "st,stm32-timer-trigger" in DT
> > >
> > > version 2:
> > > - use parameters to describe hardware capabilities
> > > - do not use references for pwm and iio timer subnodes
> > >
> > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> > > ---
> > > arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
> > > arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
> > > 2 files changed, 360 insertions(+), 1 deletion(-)
[...]
If you're only commenting on a little piece of the patch, it's always
a good idea to trim the rest.
> > > diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> > > index 8a163d7..df4ca7e 100644
> > > --- a/arch/arm/boot/dts/stm32f469-disco.dts
> > > +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> > > @@ -81,3 +81,31 @@
> > > &usart3 {
> > > status = "okay";
> > > };
> > > +
> > > +&gptimer1 {
> > > + status = "okay";
> > > +
> > > + pwm1 at 0 {
> > > + pinctrl-0 = <&pwm1_pins>;
> > > + pinctrl-names = "default";
> > > + status = "okay";
> > > + };
> > > +
> > > + timer1 at 0 {
> > > + status = "okay";
> > > + };
> > > +};
> >
> > This is a much *better* format than before.
> >
> > I still don't like the '&' syntax though.
>
> Please keep "&" format to match with existing nodes.
Right. I wasn't suggesting that he differs from the current format in
*this* set. I am suggesting that we change the format in a subsequent
set though.
> > > +&gptimer3 {
> > > + status = "okay";
> > > +
> > > + pwm3 at 0 {
> > > + pinctrl-0 = <&pwm3_pins>;
> > > + pinctrl-names = "default";
> > > + status = "okay";
> > > + };
> > > +
> > > + timer3 at 0 {
> > > + status = "okay";
> > > + };
> > > +};
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Will Deacon @ 2016-12-06 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205122619.25045-1-lorenzo.pieralisi@arm.com>
On Mon, Dec 05, 2016 at 12:26:19PM +0000, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Sricharan R <sricharan@codeaurora.org>
> ---
> Joerg,
>
> pending Rafael's ACK on it, given the 4.10 release timing and that the
> series is queued via the IOMMU tree please consider applying this patch to
> your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> the x86/ia64 code path; I prefer preventing any issue related to default
> dma masks on x86/ia64 so I hope it can get merged along with the rest of
> the ACPI IORT SMMU series.
>
> Thanks a lot and apologies,
> Lorenzo
>
> drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
> drivers/acpi/scan.c | 14 +-------------
> include/linux/acpi_iort.h | 2 ++
> 3 files changed, 25 insertions(+), 13 deletions(-)
Looks straightforward to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Joerg can probably just pick this on top of his queue.
Will
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: imx6: Support Poslab Savageboard dual & quad
From: Fabio Estevam @ 2016-12-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206070829.24098-1-woogyom.kim@gmail.com>
Hi Milo,
On Tue, Dec 6, 2016 at 5:08 AM, Milo Kim <woogyom.kim@gmail.com> wrote:
> Poslab Savageboard is i.MX6 SoC base, but BSP code from the vendor is
> not mainline u-boot and kernel. Personal reason of using this board is
> testing etnaviv user-space driver, so I re-write device tree files based on
> mainline kernel for the first step.
>
> This patchset includes common DT file, dual and quad board files.
>
> Supported components are
> - Display: HDMI and LVDS panel
> - eMMC and SD card
> - Ethernet
> - Pinmux configuration
> - SATA: only for Savageboard quad
> - UART1 for debug console
> - USB host
>
> Missing features are
> - Audio (WM8903)
> - USB OTG
> - PMIC WM8326: default settings are used so no issue to bring-up the system
> - MIPI DSI, CSI
>
> Patches are tested on the Savageboard quad but the dual version should work
> because the only difference between dual and quad is SATA support.
>
> More information in http://www.savageboard.org
>
> v2:
> Fix DT node for regulator, phy-reset-gpios and iomuxc node.
>
> Milo Kim (3):
> ARM: dts: imx6: Add Savageboard common file
> ARM: dts: imx6: Support Savageboard dual
> ARM: dts: imx6: Support Savageboard quad
>
> arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++
> arch/arm/boot/dts/imx6q-savageboard.dts | 54 ++++++
> arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
You missed to add imx6q-savageboard.dtb and imx6dl-savageboard.dtb
entries into arch/arm/boot/dts/Makefile
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Lorenzo Pieralisi @ 2016-12-06 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hbc61=QCYDgHZ_KbxR7VkSSWrHVGvU47fG6hsQrSJKhw@mail.gmail.com>
Hi Joerg,
On Mon, Dec 05, 2016 at 11:18:56PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > The introduction of acpi_dma_configure() allows to configure DMA
> > and related IOMMU for any device that is DMA capable. To achieve
> > that goal it ensures DMA masks are set-up to sane default values
> > before proceeding with IOMMU and DMA ops configuration.
> >
> > On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> > called for every device that has an ACPI companion, in that every device
> > is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> > which has the side effect of initializing dma masks also for
> > pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> > whose dma masks were not set-up before the acpi_dma_configure() API was
> > introduced, which may have noxious side effects.
> >
> > Therefore, in preparation for IORT firmware specific DMA masks set-up,
> > wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> > specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> > default expected behaviour on x86/ia64 systems and keeping DMA default
> > masks set-up on IORT based (ie ARM) arch configurations.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Tomasz Nowicki <tn@semihalf.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Sricharan R <sricharan@codeaurora.org>
>
> Acked -by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> > ---
> > Joerg,
> >
> > pending Rafael's ACK on it, given the 4.10 release timing and that the
> > series is queued via the IOMMU tree please consider applying this patch to
> > your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> > the x86/ia64 code path; I prefer preventing any issue related to default
> > dma masks on x86/ia64 so I hope it can get merged along with the rest of
> > the ACPI IORT SMMU series.
I can apply Rafael and Hanjun's tags and resend a v2 to you if you
prefer, it would be great if you could apply this patch to your arm/smmu
branch for v4.10 as per description above, please let me know.
Thank you !
Lorenzo
> >
> > Thanks a lot and apologies,
> > Lorenzo
> >
> > drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
> > drivers/acpi/scan.c | 14 +-------------
> > include/linux/acpi_iort.h | 2 ++
> > 3 files changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 47bace8..e0d2e6e 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
> > }
> >
> > /**
> > + * iort_set_dma_mask - Set-up dma mask for a device.
> > + *
> > + * @dev: device to configure
> > + */
> > +void iort_set_dma_mask(struct device *dev)
> > +{
> > + /*
> > + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> > + * setup the correct supported mask.
> > + */
> > + if (!dev->coherent_dma_mask)
> > + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > +
> > + /*
> > + * Set it to coherent_dma_mask by default if the architecture
> > + * code has not set it.
> > + */
> > + if (!dev->dma_mask)
> > + dev->dma_mask = &dev->coherent_dma_mask;
> > +}
> > +
> > +/**
> > * iort_iommu_configure - Set-up IOMMU configuration for a device.
> > *
> > * @dev: device to configure
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 80698d3..93b00cf 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> > {
> > const struct iommu_ops *iommu;
> >
> > - /*
> > - * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> > - * setup the correct supported mask.
> > - */
> > - if (!dev->coherent_dma_mask)
> > - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > -
> > - /*
> > - * Set it to coherent_dma_mask by default if the architecture
> > - * code has not set it.
> > - */
> > - if (!dev->dma_mask)
> > - dev->dma_mask = &dev->coherent_dma_mask;
> > + iort_set_dma_mask(dev);
> >
> > iommu = iort_iommu_configure(dev);
> >
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index dcb2b60..77e0809 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
> > u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> > struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> > /* IOMMU interface */
> > +void iort_set_dma_mask(struct device *dev);
> > const struct iommu_ops *iort_iommu_configure(struct device *dev);
> > #else
> > static inline void acpi_iort_init(void) { }
> > @@ -45,6 +46,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> > u32 req_id)
> > { return NULL; }
> > /* IOMMU interface */
> > +static inline void iort_set_dma_mask(struct device *dev) { }
> > static inline
> > const struct iommu_ops *iort_iommu_configure(struct device *dev)
> > { return NULL; }
> > --
> > 2.10.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 14/18] arm64: signal32: move ilp32 and aarch32 common code to separated file
From: Yury Norov @ 2016-12-06 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205161823.GF14429@e104818-lin.cambridge.arm.com>
On Mon, Dec 05, 2016 at 04:18:24PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:13PM +0300, Yury Norov wrote:
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
>
> Please add some description, even if it means copying the subject.
>
> > ---
> > arch/arm64/include/asm/signal32.h | 3 +
> > arch/arm64/include/asm/signal32_common.h | 27 +++++++
> > arch/arm64/kernel/Makefile | 2 +-
> > arch/arm64/kernel/signal32.c | 107 ------------------------
> > arch/arm64/kernel/signal32_common.c | 135 +++++++++++++++++++++++++++++++
> > 5 files changed, 166 insertions(+), 108 deletions(-)
> > create mode 100644 arch/arm64/include/asm/signal32_common.h
> > create mode 100644 arch/arm64/kernel/signal32_common.c
>
> I wonder whether you can make such patches more readable by setting
> "diff.renames" to "copy" in your gitconfig (unless it's set already and
> Git cannot detect partial file code moving/copying).
I tried "git format-patch -C --find-copies-harder" - the same result.
Yury
^ permalink raw reply
* [PATCH] ARM: dts: da850: enable high speed for mmc
From: Sekhar Nori @ 2016-12-06 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201141041.31386-1-ahaslam@baylibre.com>
On Thursday 01 December 2016 07:40 PM, Axel Haslam wrote:
> The mmc controller in da850 supports high speed modes
> so add cap-sd-highspeed and cap-mmc-highspeed.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Forgot to reply earlier, but this was applied.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2016-12-06 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480947224-26222-1-git-send-email-abailon@baylibre.com>
On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
> Everytime the usb20 phy is enabled, there is a
> "sleeping function called from invalid context" BUG.
>
> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
> before to invoke the callback usb20_phy_clk_enable().
> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
> which may sleep.
> Move clk_get() to da8xx_register_usb20_phy_clk() and
> replace clk_prepare_enable() by clk_enable().
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
This will still cause the recursive locking problem reported by David.
Not sure what the point of sending this version was.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Ard Biesheuvel @ 2016-12-06 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481012975-44478-1-git-send-email-maninder1.s@samsung.com>
On 6 December 2016 at 08:29, Maninder Singh <maninder1.s@samsung.com> wrote:
> This patch defines new macro MODULE_START to ensure kernel text
> and module remains within 32 MB of address range.
>
> Tried this patch by inserting 20 MB size module on 4.1 kernel:-
>
> Earlier:-
> ==========
> sh# insmod size.ko
> ....
> insmod: ERROR: could not insert module size.ko: Cannot allocate memory
> sh#
>
> With this patch
> ===============
> sh# insmod size.ko
> ...
> sh# lsmod
> Module Size Used by
> size 20972425 0
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> Reviewed-by: Ajeet Yadav <ajeet.y@samsung.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++--
> arch/arm/kernel/module.c | 9 ++++++++-
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c..1a0a6e5 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -37,7 +37,7 @@
> * TASK_SIZE - the maximum size of a user space task.
> * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
> */
> -#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
> +#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_32M))
> #define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M)
>
> /*
> @@ -50,7 +50,7 @@
> * and PAGE_OFFSET - it must be within 32MB of the kernel text.
> */
> #ifndef CONFIG_THUMB2_KERNEL
> -#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
> +#define MODULES_VADDR (PAGE_OFFSET - SZ_32M)
> #else
> /* smaller range for Thumb-2 symbols relocation (2^24)*/
> #define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index 4f14b5c..b8e1f9c 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -35,12 +35,19 @@
> */
> #undef MODULES_VADDR
> #define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
> +#define MODULES_START MODULES_VADDR
> +#else
> +#ifndef CONFIG_THUMB2_KERNEL
> +#define MODULES_START ALIGN((unsigned long)_etext - SZ_32M, PAGE_SIZE)
On a multi_v7_defconfig kernel, the text size is >8 MB, which means
you are only adding ~7 MB to the module area, while consuming 16 MB of
additional address space. Given that 20 MB modules are very uncommon,
I think it is better to enable CONFIG_ARM_MODULE_PLTS instead. That
way, there is no need to update these defaults for everyone.
> +#else
> +#define MODULES_START MODULES_VADDR
> +#endif
> #endif
>
> #ifdef CONFIG_MMU
> void *module_alloc(unsigned long size)
> {
> - void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> + void *p = __vmalloc_node_range(size, 1, MODULES_START, MODULES_END,
> GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
> __builtin_return_address(0));
> if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ARM: dts: STiH410-b2260: Identify the UART RTS line
From: Patrice Chotard @ 2016-12-06 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-1-lee.jones@linaro.org>
Hi Lee
Except the typo in patch 2
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
On 12/02/2016 03:11 PM, Lee Jones wrote:
> Configure the UART RTS line as a GPIO for manipulation within the UART driver.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/stih410-b2260.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stih410-b2260.dts b/arch/arm/boot/dts/stih410-b2260.dts
> index 7fb507f..f46603f 100644
> --- a/arch/arm/boot/dts/stih410-b2260.dts
> +++ b/arch/arm/boot/dts/stih410-b2260.dts
> @@ -63,6 +63,7 @@
> uart0: serial at 9830000 {
> label = "LS-UART0";
> status = "okay";
> + rts-gpios = <&pio17 3 GPIO_ACTIVE_LOW>;
> };
>
> /* Low speed expansion connector */
>
^ permalink raw reply
* [PATCH 06/11] ARM: dts: imx: Add imx6sll EVK board dts support
From: Jacky Bai @ 2016-12-06 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C5-tq-OWTYcmzJt=_57wOyXzNMUes1mctwwyoegwzJyQ@mail.gmail.com>
Hi Fabio,
Please see below.
> Subject: Re: [PATCH 06/11] ARM: dts: imx: Add imx6sll EVK board dts support
>
> On Fri, Dec 2, 2016 at 4:39 AM, Bai Ping <ping.bai@nxp.com> wrote:
> > Add basic dts support for imx6sll EVK baoard.
>
> s/baord/board
ok, I will fix this typo.
>
> > + battery: max8903 at 0 {
> > + compatible = "fsl,max8903-charger";
> > + pinctrl-names = "default";
> > + dok_input = <&gpio4 13 1>;
> > + uok_input = <&gpio4 13 1>;
> > + chg_input = <&gpio4 15 1>;
> > + flt_input = <&gpio4 14 1>;
> > + fsl,dcm_always_high;
> > + fsl,dc_valid;
> > + fsl,adc_disable;
>
> These properties do not exist in mainline, please remove them.
ok, thanks for you comment.
>
>
> > + status = "okay";
> > + };
> > +
> > + pxp_v4l2_out {
> > + compatible = "fsl,imx6sl-pxp-v4l2";
> > + status = "okay";
> > + };
>
> We don't have pxp support in mainline kernel, please remove it.
Ok, I will remove it.
>
> > +
> > + regulators {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
>
> Please remove it and place the regulator nodes directly as below:
ok, I will fix it.
>
>
> > +
> > + reg_usb_otg1_vbus: regulator at 0 {
> > + compatible = "regulator-fixed";
> > + reg = <0>;
> > + regulator-name = "usb_otg1_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio4 0 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
>
> reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb_otg1_vbus";
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> gpio = <&gpio4 0 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
>
> > +&cpu0 {
> > + arm-supply = <&sw1a_reg>;
> > + soc-supply = <&sw1c_reg>;
> > +};
>
> This is only for LDO bypass mode, right? We don't support LDO-bypass in
> mainline.
>
On i.MX6SLL, no internal LDO for ARM and SOC. We can only use external regulator for DVFS.
> > +&gpc {
> > + fsl,ldo-bypass = <1>;
>
> We don't support ldo-bypass in mainline, please remove it.
>
> > +&pxp {
> > + status = "okay";
> > +};
>
> We don't support PXP in mainline, please remove it.
ok I will remove it.
BR
Jacky Bai
^ permalink raw reply
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: kbuild test robot @ 2016-12-06 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480979542-26871-3-git-send-email-jon.mason@broadcom.com>
Hi Jon,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jon-Mason/arm64-dts-NS2-reserve-memory-for-Nitro-firmware/20161206-125631
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:56.1-6 Label or path enet not found
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:132.1-7 Label or path pcie8 not found
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:148.1-6 Label or path qspi not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 52465 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/fc197763/attachment-0001.gz>
^ permalink raw reply
* ILP32 for ARM64: testing with glibc testsuite
From: Andreas Schwab @ 2016-12-06 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480966437.29811.23.camel@caviumnetworks.com>
On Dez 05 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:
> FAIL: nptl/tst-cancel26
> FAIL: nptl/tst-cancel27
> FAIL: rt/tst-mqueue1
> FAIL: rt/tst-mqueue2
> FAIL: rt/tst-mqueue4
> FAIL: rt/tst-mqueue7
I don't see these failures. Maybe you need to rebuild libgcc?
https://build.opensuse.org/package/live_build_log/devel:ARM:AArch64:ILP32/glibc-testsuite/standard/aarch64_ilp32
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Maninder Singh @ 2016-12-06 8:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch defines new macro MODULE_START to ensure kernel text
and module remains within 32 MB of address range.
Tried this patch by inserting 20 MB size module on 4.1 kernel:-
Earlier:-
==========
sh# insmod size.ko
....
insmod: ERROR: could not insert module size.ko: Cannot allocate memory
sh#
With this patch
===============
sh# insmod size.ko
...
sh# lsmod
Module Size Used by
size 20972425 0
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Reviewed-by: Ajeet Yadav <ajeet.y@samsung.com>
---
arch/arm/include/asm/memory.h | 4 ++--
arch/arm/kernel/module.c | 9 ++++++++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c..1a0a6e5 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -37,7 +37,7 @@
* TASK_SIZE - the maximum size of a user space task.
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
*/
-#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
+#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_32M))
#define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M)
/*
@@ -50,7 +50,7 @@
* and PAGE_OFFSET - it must be within 32MB of the kernel text.
*/
#ifndef CONFIG_THUMB2_KERNEL
-#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_32M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5c..b8e1f9c 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -35,12 +35,19 @@
*/
#undef MODULES_VADDR
#define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
+#define MODULES_START MODULES_VADDR
+#else
+#ifndef CONFIG_THUMB2_KERNEL
+#define MODULES_START ALIGN((unsigned long)_etext - SZ_32M, PAGE_SIZE)
+#else
+#define MODULES_START MODULES_VADDR
+#endif
#endif
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ void *p = __vmalloc_node_range(size, 1, MODULES_START, MODULES_END,
GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
--
1.9.1
^ permalink raw reply related
* [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: David.Wu @ 2016-12-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1737869.ycGphUXI8X@phil>
Hi Heiko,
? 2016/12/5 18:54, Heiko Stuebner ??:
> Hi David,
>
> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>> During suspend there may still be some i2c access happening.
>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>> i2c is in irq mode of operation.
>
> can you describe the issue you're trying to fix a bit more please?
Sometimes we could see the i2c timeout errors during suspend/resume,
which makes the duration of suspend/resume too longer.
[ 484.171541] CPU4: Booted secondary processor [410fd082]
[ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
800000 800000 mV): -110
[ 487.172874] cpu cpu4: failed to set volt 800000
>
> I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
> these should be able to finish up their ongoing transfers and not start any
> new ones instead?
>
> Your irq can still happen slightly after the system started going to actually
> sleep, so to me it looks like you just widened the window where irqs can be
> handled. Especially as your irq could also just simply stem from the start
> state, so you cannot even be sure if your transaction actually is finished.
Okay, you are right. I want to give it a double insurance at first, but
it may hide the unhappend issue.
>
> So to me it looks like the i2c-connected device driver should be fixed instead?
I tell them to fix it in rk808 driver.
>
> In the past I solved this for example in the zforce_ts driver [0] to
> prevent i2c transfers from happening during suspend.
>
>
> Heiko
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/touchscreen/zforce_ts.c
>
>
>>
>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>> ---
>> drivers/i2c/busses/i2c-rk3x.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
>> index df22066..67af32a 100644
>> --- a/drivers/i2c/busses/i2c-rk3x.c
>> +++ b/drivers/i2c/busses/i2c-rk3x.c
>> @@ -1261,7 +1261,7 @@ static int rk3x_i2c_probe(struct platform_device
>> *pdev) }
>>
>> ret = devm_request_irq(&pdev->dev, irq, rk3x_i2c_irq,
>> - 0, dev_name(&pdev->dev), i2c);
>> + IRQF_NO_SUSPEND, dev_name(&pdev->dev), i2c);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "cannot request IRQ\n");
>> return ret;
>
>
>
>
>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-06 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
has a dedicated enable pin (PL8 in the reference design).
Enable the pin in the same way as the WLAN enable pins.
Tested on an A33 Q8 tablet with RTL8703AS.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
This patch should be coupled with the uart1 node patch I send before:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
https://github.com/lwfinger/rtl8723bs_bt
arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index c676940..4aeb5bb 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -88,7 +88,7 @@
&r_pio {
wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
- pins = "PL6", "PL7", "PL11";
+ pins = "PL6", "PL7", "PL8", "PL11";
function = "gpio_in";
bias-pull-up;
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-06 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17819681480935706@web24g.yandex.ru>
On Mon, Dec 05, 2016 at 07:01:46PM +0800, Icenowy Zheng wrote:
>
>
> 05.12.2016, 17:40, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Mon, Dec 05, 2016 at 04:59:44PM +0800, Icenowy Zheng wrote:
> >> ?2016?12?5? 16:52? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >> ?>
> >> ?> On Fri, Dec 02, 2016 at 10:22:30PM +0800, Icenowy Zheng wrote:
> >> ?> >
> >> ?> >
> >> ?> > 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> ?> > > On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
> >> ?> > >> ?> Something more interesting happened.
> >> ?> > >> ?>
> >> ?> > >> ?> Xunlong made a add-on board for Orange Pi Zero, which exposes the
> >> ?> > >> ?> two USB Controllers exported at expansion bus as USB Type-A
> >> ?> > >> ?> connectors.
> >> ?> > >> ?>
> >> ?> > >> ?> Also it exposes a analog A/V jack and a microphone.
> >> ?> > >> ?>
> >> ?> > >> ?> Should I enable {e,o}hci{2.3} in the device tree?
> >> ?> > >>
> >> ?> > >> ?Actually we should do this regardless of this extension board. The USB
> >> ?> > >> ?pins are not multiplexed and are exposed on user accessible pins (just
> >> ?> > >> ?not soldered, but that's a detail), so I think they qualify for DT
> >> ?> > >> ?enablement. And even if a user can't use them, it doesn't hurt to have
> >> ?> > >> ?them (since they are not multiplexed).
> >> ?> > >
> >> ?> > > My main concern about this is that we'll leave regulators enabled by
> >> ?> > > default, for a minority of users. And that minority will prevent to do
> >> ?> > > a proper power management when the times come since we'll have to keep
> >> ?> > > that behaviour forever.
> >> ?> >
> >> ?> > I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
> >> ?>
> >> ?> You can't ask that from the majority of users. These users will take
> >> ?> debian or fedora, install it, and expect everything to work
> >> ?> properly. I would make the opposite argument actually. If someone is
> >> ?> knowledgeable enough to solder the USB pins a connector, then (s)he'll
> >> ?> be able to make that u-boot call.
> >>
> >> ?Now (s)he do not need soldering.
> >>
> >> ?(S)he needs only paying $1.99 more to Xunlong to get the expansion
> >> ?board, and insert it on the OPi Zero.
> >
> > Which is going to require an overlay anyway, so we could have the USB
> > bits in there too.
>
> If so, I think the [PATCH -next v3 2/2] is ready to be merged ;-)
I meant enabling the USB in the overlay, you enabled it in the base DT.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/efad492b/attachment.sig>
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Hanjun Guo @ 2016-12-06 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205122619.25045-1-lorenzo.pieralisi@arm.com>
On 2016/12/5 20:26, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
Add this patch on top of your v9 acpi smmu patchset,
tested on Hisilicon D03 (ARM64), devices with SMMU
enabled work fine,
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
^ permalink raw reply
* [PATCH] media/platform/exynos4-is/fimc-is - Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-12-06 7:42 UTC (permalink / raw)
To: linux-arm-kernel
Free memory mapping, if fimc_is_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/media/platform/exynos4-is/fimc-is.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 32ca55f..10d98a5 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -818,12 +818,13 @@ static int fimc_is_probe(struct platform_device *pdev)
is->irq = irq_of_parse_and_map(dev->of_node, 0);
if (!is->irq) {
dev_err(dev, "no irq found\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_iounmap;
}
ret = fimc_is_get_clocks(is);
if (ret < 0)
- return ret;
+ goto err_iounmap;
platform_set_drvdata(pdev, is);
@@ -877,6 +878,8 @@ err_irq:
free_irq(is->irq, is);
err_clk:
fimc_is_put_clocks(is);
+err_iounmap:
+ iounmap(is->pmu_regs);
return ret;
}
@@ -932,6 +935,7 @@ static int fimc_is_remove(struct platform_device *pdev)
fimc_is_unregister_subdevs(is);
vb2_dma_contig_clear_max_seg_size(dev);
fimc_is_put_clocks(is);
+ iounmap(is->pmu_regs);
fimc_is_debugfs_remove(is);
release_firmware(is->fw.f_w);
fimc_is_free_cpu_memory(is);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 11/18] arm64: ilp32: share aarch32 syscall handlers
From: Yury Norov @ 2016-12-06 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205171242.GH14429@e104818-lin.cambridge.arm.com>
On Mon, Dec 05, 2016 at 05:12:43PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:10PM +0300, Yury Norov wrote:
> > off_t is passed in register pair just like in aarch32.
> > In this patch corresponding aarch32 handlers are shared to
> > ilp32 code.
> [...]
> > +/*
> > + * Note: off_4k (w5) is always in units of 4K. If we can't do the
> > + * requested offset because it is not page-aligned, we return -EINVAL.
> > + */
> > +ENTRY(compat_sys_mmap2_wrapper)
> > +#if PAGE_SHIFT > 12
> > + tst w5, #~PAGE_MASK >> 12
> > + b.ne 1f
> > + lsr w5, w5, #PAGE_SHIFT - 12
> > +#endif
> > + b sys_mmap_pgoff
> > +1: mov x0, #-EINVAL
> > + ret
> > +ENDPROC(compat_sys_mmap2_wrapper)
>
> For compat sys_mmap2, the pgoff argument is in multiples of 4K. This was
> traditionally used for architectures where off_t is 32-bit to allow
> mapping files to 2^44.
>
> Since off_t is 64-bit with AArch64/ILP32, should we just pass the off_t
> as a 64-bit value in two different registers (w5 and w6)?
Current glibc implementation becomes broken for 64-bit off_t if
if I'll do what you want.
sysdeps/unix/sysv/linux/generic/wordsize-32/mmap.c
28 __ptr_t
29 __mmap (__ptr_t addr, size_t len, int prot, int flags, int fd, off_t offset)
30 {
31 if (offset & (MMAP_PAGE_UNIT - 1))
32 {
33 __set_errno (EINVAL);
34 return MAP_FAILED;
35 }
36 return (__ptr_t) INLINE_SYSCALL (mmap2, 6, addr, len, prot, flags, fd,
37 offset / MMAP_PAGE_UNIT);
38 }
39
40 weak_alias (__mmap, mmap)
So it requires changes both in glibc and in kernel. I can do it. But
I'd like to collect opinions of kernel and glibc developers before
starting it.
Yury
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1
From: Milo Kim @ 2016-12-06 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205080932.xaqyl2httgxgso67@lukather>
On 12/05/2016 05:09 PM, Maxime Ripard wrote:
> On Mon, Dec 05, 2016 at 11:00:31AM +0900, Milo Kim wrote:
>> The board has DDR3 512MB. This patch helps scanning the memory and
>> adding memblock through the DT.
>>
>> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
>> ---
>> arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> index ec63d10..be3668f 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> @@ -45,6 +45,11 @@
>> / {
>> model = "FriendlyArm NanoPi M1";
>> compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
>> +
>> + memory at 40000000 {
>> + device_type = "memory";
>> + reg = <0x40000000 0x20000000>;
>> + };
>
> U-boot will fill that up, so there's no need to put it there.
Right, my intention was adding memblock through the DT whether the
bootload does or not. However I'm not sure the situation (missing
memblock in u-boot) could really happen.
Best regards,
Milo
^ 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