* [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed
From: Christoffer Dall @ 2016-10-02 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b1b30b3-4199-9e18-362c-b8bc9d45277d@arm.com>
On Fri, Sep 30, 2016 at 02:24:40PM +0100, Robin Murphy wrote:
> Hi Eric,
>
> On 27/09/16 21:48, Eric Auger wrote:
> > iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on
> > IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap
> > they reserve the IOVA window to prevent the iova allocator to
> > allocate in those areas.
> >
> > Signed-off-by: Eric Auger <eric.auger@redhat.com>
> > ---
> > drivers/iommu/dma-iommu.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/dma-iommu.h | 18 ++++++++++++++++++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 04bbc85..db21143 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -759,3 +759,51 @@ int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> > return 0;
> > }
> > EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
> > +
> > +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
> > +{
> > + struct iova_domain *iovad;
> > + unsigned long lo, hi;
> > + int ret;
> > +
> > + if (domain->type != IOMMU_DOMAIN_MIXED)
> > + return -EINVAL;
> > +
> > + if (!domain->iova_cookie)
> > + return -EINVAL;
> > +
> > + iovad = cookie_iovad(domain);
> > +
> > + lo = iova_pfn(iovad, iova);
> > + hi = iova_pfn(iovad, iova + size - 1);
> > + reserve_iova(iovad, lo, hi);
>
> This can't work reliably - reserve_iova() will (for good reason) merge
> any adjacent or overlapping entries, so any unmap is liable to free more
> IOVA space than actually gets unmapped, and things will get subtly out
> of sync and go wrong later.
>
> The more general issue with this whole approach, though, is that it
> effectively rules out userspace doing guest memory hotplug or similar,
> and I'm not we want to paint ourselves into that corner. Basically, as
> soon as a device is attached to a guest, the entirety of the unallocated
> IPA space becomes reserved, and userspace can never add anything further
> to it, because any given address *might* be in use for an MSI mapping.
Ah, we didn't think of that when discussing this design at KVM Forum,
because the idea was that the IOVA allocator was in charge of that
resource, and the IOVA was a separate concept from the IPA space.
I think what tripped us up, is that while the above is true for the MSI
configuration where we trap the bar and do the allocation at VFIO init
time, the guest device driver can program DMA to any address without
trapping, and therefore there's an inherent relationship between the
IOVA and the IPA space. Is that right?
>
> I think it still makes most sense to stick with the original approach of
> cooperating with userspace to reserve a bounded area - it's just that we
> can then let automatic mapping take care of itself within that area.
I was thinking that it's also possible to do it the other way around: To
let userspace say wherever memory may be hotplugged and do the
allocation within the remaining area, but I suppose that's pretty much
the same thing, and it should just depend on what's easiest to implement
and what userspace can best predict.
>
> Speaking of which, I've realised the same fundamental reservation
> problem already applies to PCI without ACS, regardless of MSIs. I just
> tried on my Juno with guest memory placed at 0x4000000000, (i.e.
> matching the host PA of the 64-bit PCI window), and sure enough when the
> guest kicks off some DMA on the passed-through NIC, the root complex
> interprets the guest IPA as (unsupported) peer-to-peer DMA to a BAR
> claimed by the video card, and it fails. I guess this doesn't get hit in
> practice on x86 because the guest memory map is unlikely to be much
> different from the host's.
>
> It seems like we basically need a general way of communicating fixed and
> movable host reservations to userspace :/
>
Yes, this makes sense to me. Do we have any existing way of
discovering this from userspace or can we think of something?
Thanks,
-Christoffer
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-1-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array
> size to 16").
>
> The code maintains a fixed size array for IRQ penalties. The array
> gets updated by external calls such as acpi_penalize_sci_irq,
> acpi_penalize_isa_irq to reflect the actual interrupt usage of the
> system. Since the IRQ distribution is platform specific, this is
> not known ahead of time. The IRQs get updated based on the SCI
> interrupt number BIOS has chosen or the ISA IRQs that were assigned
> to existing peripherals.
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The previous change was in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA path as well. This
> didn't work out well with the existing platforms.
>
> Restoring the old behavior for IRQ < 256 and the new behavior will remain
> effective for IRQ >= 256.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 35 ++++++++++++++++++-----------------
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..f3792f4 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -438,6 +438,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> * enabled system.
> */
>
> +#define ACPI_MAX_IRQS 256
> #define ACPI_MAX_ISA_IRQS 16
>
> #define PIRQ_PENALTY_PCI_POSSIBLE (16*16)
> @@ -446,7 +447,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> #define PIRQ_PENALTY_ISA_USED (16*16*16*16*16)
> #define PIRQ_PENALTY_ISA_ALWAYS (16*16*16*16*16*16)
>
> -static int acpi_isa_irq_penalty[ACPI_MAX_ISA_IRQS] = {
> +static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ0 timer */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ1 keyboard */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ2 cascade */
> @@ -511,7 +512,7 @@ static int acpi_irq_get_penalty(int irq)
> }
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + return penalty + acpi_irq_penalty[irq];
>
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
> @@ -538,14 +539,14 @@ int __init acpi_irq_penalty_init(void)
>
> for (i = 0; i < link->irq.possible_count; i++) {
> if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> - acpi_isa_irq_penalty[link->irq.
> + acpi_irq_penalty[link->irq.
> possible[i]] +=
> penalty;
> }
>
> } else if (link->irq.active &&
> - (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> - acpi_isa_irq_penalty[link->irq.active] +=
> + (link->irq.active < ACPI_MAX_IRQS)) {
> + acpi_irq_penalty[link->irq.active] +=
> PIRQ_PENALTY_PCI_POSSIBLE;
> }
> }
> @@ -828,7 +829,7 @@ static void acpi_pci_link_remove(struct acpi_device *device)
> }
>
> /*
> - * modify acpi_isa_irq_penalty[] from cmdline
> + * modify acpi_irq_penalty[] from cmdline
> */
> static int __init acpi_irq_penalty_update(char *str, int used)
> {
> @@ -837,24 +838,24 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> for (i = 0; i < 16; i++) {
> int retval;
> int irq;
> - int new_penalty;
>
> retval = get_option(&str, &irq);
>
> if (!retval)
> break; /* no number found */
>
> - /* see if this is a ISA IRQ */
> - if ((irq < 0) || (irq >= ACPI_MAX_ISA_IRQS))
> + if (irq < 0)
> + continue;
> +
> + if (irq >= ARRAY_SIZE(acpi_irq_penalty))
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> - PIRQ_PENALTY_ISA_USED;
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + PIRQ_PENALTY_ISA_USED;
> else
> - new_penalty = 0;
> + acpi_irq_penalty[irq] = 0;
>
> - acpi_isa_irq_penalty[irq] = new_penalty;
> if (retval != 2) /* no next number */
> break;
> }
> @@ -870,14 +871,14 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> */
> void acpi_penalize_isa_irq(int irq, int active)
> {
> - if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> - (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty))
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
> bool acpi_isa_irq_available(int irq)
> {
> - return irq >= 0 && (irq >= ARRAY_SIZE(acpi_isa_irq_penalty) ||
> + return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-2-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI and IRQ interrupts.
>
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index f3792f4..06c2a11 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -620,6 +620,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (link->irq.active < ACPI_MAX_IRQS)
> + acpi_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-3-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize
> function"). SCI penalty API was replaced by the runtime penalty calculation
> based on the value of acpi_gbl_FADT.sci_interrupt.
>
> acpi_gbl_FADT.sci_interrupt type does not get updated at the right time
> for some platforms and results in incorrect penalty assignment for PCI
> IRQs as irq_get_trigger_type returns the wrong type.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 34 ++++++++++++++--------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 06c2a11..6a2af19 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -495,27 +495,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>
> static int acpi_irq_get_penalty(int irq)
> {
> - int penalty = 0;
> -
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> -
> - if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_irq_penalty[irq];
> + if (irq < ACPI_MAX_IRQS)
> + return acpi_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -886,6 +869,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
> + if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
> + polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
> + else
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
> + }
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 4d8452c..85ac7d5 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Noralf Trønnes @ 2016-10-02 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1708178720.178936.b155d019-5320-4754-bbe2-4afc1ae71cd6.open-xchange@email.1und1.de>
Den 29.09.2016 07:37, skrev Stefan Wahren:
>> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
>> geschrieben:
>>
>>
>>
>> Den 29.09.2016 00:00, skrev Eric Anholt:
>>> Noralf Tr?nnes <noralf@tronnes.org> writes:
>>>
>>>> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
>>>> the driver has no way to fill/drain the FIFO to stop the interrupts.
>>>> In this case the controller has to be disabled and the transfer
>>>> completed to avoid hang.
>>>>
>>>> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
>>>> the controller is disabled in the transfer function after completion.
>>>> Unite the code paths and do disabling inside the interrupt routine.
>>>>
>>>> Clear interrupt status bits in the united completion path instead of
>>>> trying to do it on every interrupt which isn't necessary.
>>>> Only CLKT, ERR and DONE can be cleared that way.
>>>>
>>>> Add the status value to the error value in case of TXW/RXR errors to
>>>> distinguish them from the other S_LEN error.
>>> I was surprised that not writing the TXW/RXR bits on handling their
>>> interrupts was OK, given that we were doing so before, but it's a level
>>> interrupt and those bits are basically ignored on write.
>>>
>>> This patch and 3, 4, and 6 are:
>>>
>>> Reviewed-by: Eric Anholt <eric@anholt.net>
>>>
>>> Patch 5 is:
>>>
>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>
>>> Note for future debug: The I2C_C_CLEAR on errors will take some time to
>>> resolve -- if you were in non-idle state and I2C_C_READ, it sets an
>>> abort_rx flag and runs through the state machine to send a NACK and a
>>> STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
>>> be hanging around queued up for next time we start the engine.
>> Maybe you're able to explain the issues I had with reset:
>> https://github.com/raspberrypi/linux/issues/1653
>>
>> Should we put your note into the commit message?
>> It will most likely be lost if it just stays in this email.
> I prefer to have this kind of information as a code comment.
Eric, does this look good to you as a code comment:
/*
* Note about I2C_C_CLEAR on error:
* The I2C_C_CLEAR on errors will take some time to resolve -- if you
were in
* non-idle state and I2C_C_READ, it sets an abort_rx flag and runs through
* the state machine to send a NACK and a STOP. Since we're setting CLEAR
* without I2CEN, that NACK will be hanging around queued up for next time
* we start the engine.
*/
If it is, I'll resend the series with this change and add all the ack's
and r-b's.
Noralf.
^ permalink raw reply
* [PATCH] crypto: sunxi-ss: mark sun4i_hash() static
From: Herbert Xu @ 2016-10-02 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474691326-15541-1-git-send-email-baoyou.xie@linaro.org>
On Sat, Sep 24, 2016 at 12:28:46PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
This patch has already been applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm64/sha256 - add support for SHA256 using NEON instructions
From: Herbert Xu @ 2016-10-02 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_M+FcuDSaGsJYjD96=Q1iXyFDD3KWy=4vUbeLWRgrHJw@mail.gmail.com>
On Sat, Oct 01, 2016 at 07:58:56PM -0700, Ard Biesheuvel wrote:
>
> Please disregard this patch for now. I will follow up with a more
> elaborate series for SHA256 on arm64
Thanks for the heads up.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 16:44 UTC (permalink / raw)
To: linux-arm-kernel
The LCDIF interrupt should be triggered by the rising edge of the
IRQ line because we only want the interrupt to trigger once per each
frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
by software, so the previous behavior before this patch, where the
interrupt was triggered by level-high status of the IRQ line, caused
the interrupt to fire again immediatelly after it was handled, which
caused the system to lock up due to the high rate of interrupts.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 1a473e8..9526c38 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1143,7 +1143,7 @@
lcdif1: lcdif at 02220000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02220000 0x4000>;
- interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
@@ -1154,7 +1154,7 @@
lcdif2: lcdif at 02224000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02224000 0x4000>;
- interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Fabio Estevam @ 2016-10-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
Hi Marek,
On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 1a473e8..9526c38 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1143,7 +1143,7 @@
> lcdif1: lcdif at 02220000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02220000 0x4000>;
> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DwZYawBOiXWn0FMy9SgO4+-C=y-CFCQBPSO_mDYk-a6g@mail.gmail.com>
On 10/02/2016 07:43 PM, Fabio Estevam wrote:
> Hi Marek,
Hi!
> On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
>> The LCDIF interrupt should be triggered by the rising edge of the
>> IRQ line because we only want the interrupt to trigger once per each
>> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
>> by software, so the previous behavior before this patch, where the
>> interrupt was triggered by level-high status of the IRQ line, caused
>> the interrupt to fire again immediatelly after it was handled, which
>> caused the system to lock up due to the high rate of interrupts.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> ---
>> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
>> index 1a473e8..9526c38 100644
>> --- a/arch/arm/boot/dts/imx6sx.dtsi
>> +++ b/arch/arm/boot/dts/imx6sx.dtsi
>> @@ -1143,7 +1143,7 @@
>> lcdif1: lcdif at 02220000 {
>> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
>> reg = <0x02220000 0x4000>;
>> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
>
> What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
Probably, but I don't have the hardware to test MXSFB DRM/KMS driver on
those. I can mail you the necessary patches if you want to try it out,
the latest version is not in the ML yet as there is some DRM
infrastructure work going on.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Linus Walleij @ 2016-10-02 21:53 UTC (permalink / raw)
To: linux-arm-kernel
After being asked to not depend on ARCH_QCOM* or similar,
unsurprisingly compilation fails on UM as it has no I/O
memory:
drivers/built-in.o: In function `qcom_ebi2_probe':
>> drivers/bus/qcom-ebi2.c:333: undefined reference to
`devm_ioremap_resource'
Fix this by letting the Kconfig atleast depend on HAS_IOMEM.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: linux-arm-msm at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC maintainers: please apply this directly on the offending
branch, or line it up for v4.9 fixes.
---
drivers/bus/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5a2d47c71525..7010dcac9328 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -110,6 +110,7 @@ config OMAP_OCP2SCP
config QCOM_EBI2
bool "Qualcomm External Bus Interface 2 (EBI2)"
+ depends on HAS_IOMEM
help
Say y here to enable support for the Qualcomm External Bus
Interface 2, which can be used to connect things like NAND Flash,
--
2.7.4
^ permalink raw reply related
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Jon Masters @ 2016-10-02 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5869118.UilSPY9Sai@wuerfel>
On 09/14/2016 02:32 PM, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote:
>> And there are probably multiple child devices under LPC, the global arm64_extio_ops only can cover one PIO range. It is fortunate only ipmi driver can not support I/O
>> operation registering, serial driver has serial_in/serial_out to
>> be registered. So, only the PIO range for ipmi device is stored
>> in arm64_extio_ops and the indirect-IO
>> works well for ipmi device.
>
> You should not do that in the serial driver, please just use the
> normal 8250 driver that works fine once you handle the entire
> port range.
Just for the record, Arnd has the right idea. There is only one type of
UART permitted by SBSA (PL011). We carved out an exception for a design
that was already in flight and allowed it to be 16550. That other design
was then corrected in future generations to be PL011 as we required it
to be. Then there's the Hip06. I've given feedback elsewhere about the
need for there to be (at most) two types of UART in the wild. This "LPC"
stuff needs cleaning up (feedback given elsewhere already on that), but
we won't be adding a third serial driver into the mix in order to make
it work. There will be standard ARM servers. There will not be the
kinda-sorta-standard. Thanks.
Jon.
^ permalink raw reply
* [GIT PULL 1/3] ARM: soc: exynos: Drivers for v4.9
From: Olof Johansson @ 2016-10-03 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919155302.GA4447@kozik-book>
On Mon, Sep 19, 2016 at 8:53 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Sep 19, 2016 at 05:02:40PM +0200, Arnd Bergmann wrote:
>> On Sunday, September 18, 2016 6:39:46 PM CEST Krzysztof Kozlowski wrote:
>> > Samsung drivers/soc update for v4.9:
>> > 1. Allow compile testing of exynos-mct clocksource driver on ARM64.
>> > 2. Document Exynos5433 PMU compatible (already used by clkout driver and more
>> > will be coming soon).
>>
>> Pulled into next/drivers, thanks
>>
>> Just for my understanding: why do we need the exynos-mct driver on ARM64
>> but not the delay-timer portion of it?
>
> I think we want all of it but Doug's optimization 3252a646aa2c
> ("clocksource: exynos_mct: Only use 32-bits where possible") is not
> ARM64 friendly. One way of dealing with it would be to prepare two
> versions of exynos4_read_current_timer(). One reading only lower 32-bit
> value for ARMv7 and second (slow) reading lower and upper for ARMv8.
>
>>
>> Is there an advantage in using MCT over the architected timer on these
>> chips? If so, should we also have a way to use it as the delay timer?
>
> No, there is no real advantage... except that the SoC has some
> interesting "characteristics"... The timers are tightly coupled. Very
> tightly. I spent a lot of time and failed to boot my ARMv8 board without
> some MCT magic.
What kind of magic is that? I can understand that needing the MCT for
some system-level timer functionality might be true (wakeups, etc),
but for system timesource avoiding the MMIO timer and using the arch
ones is a substantial performance improvement for gettimeofday() and
friends.
There was extensive discussion last year over using arch timers on
5420/5422, and it fizzled out with vague comments about something not
working right between A15/A7 on b.L. hardware. I'm presuming whatever
implementation details of that SoC has since been fixed on later chips
(including v8). Any chance you can confirm? It'd be very nice to leave
MCT behind on v8 as a system time source.
-Olof
^ permalink raw reply
* [PATCH 1/2] remoteproc: Split driver and consumer dereferencing
From: Bjorn Andersson @ 2016-10-03 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In order to be able to lock a rproc driver implementations only when
used by a client, we must differ between the dereference operation of a
client and the implementation itself.
This patch brings no functional change.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/remoteproc.txt | 6 +++---
drivers/remoteproc/da8xx_remoteproc.c | 4 ++--
drivers/remoteproc/omap_remoteproc.c | 4 ++--
drivers/remoteproc/qcom_q6v5_pil.c | 4 ++--
drivers/remoteproc/qcom_wcnss.c | 4 ++--
drivers/remoteproc/remoteproc_core.c | 21 ++++++++++++++++++---
drivers/remoteproc/st_remoteproc.c | 4 ++--
drivers/remoteproc/ste_modem_rproc.c | 4 ++--
drivers/remoteproc/wkup_m3_rproc.c | 4 ++--
include/linux/remoteproc.h | 1 +
10 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index ef0219fa4bb4..f07597482351 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -101,9 +101,9 @@ int dummy_rproc_example(struct rproc *my_rproc)
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
- yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
- void rproc_put(struct rproc *rproc)
+ void rproc_free(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function essentially unrolls rproc_alloc(), by decrementing the
rproc's refcount. It doesn't directly free rproc; that would happen
@@ -131,7 +131,7 @@ int dummy_rproc_example(struct rproc *my_rproc)
has completed successfully.
After rproc_del() returns, @rproc is still valid, and its
- last refcount should be decremented by calling rproc_put().
+ last refcount should be decremented by calling rproc_free().
Returns 0 on success and -EINVAL if @rproc isn't valid.
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index 12823d078e1e..1afac8f31be0 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -261,7 +261,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -290,7 +290,7 @@ static int da8xx_rproc_remove(struct platform_device *pdev)
disable_irq(drproc->irq);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 01e234cb9157..fa63bf2eb885 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -215,7 +215,7 @@ static int omap_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -224,7 +224,7 @@ static int omap_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c
index 05b04573e87d..2e0caaaa766a 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -875,7 +875,7 @@ static int q6v5_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -885,7 +885,7 @@ static int q6v5_remove(struct platform_device *pdev)
struct q6v5 *qproc = platform_get_drvdata(pdev);
rproc_del(qproc->rproc);
- rproc_put(qproc->rproc);
+ rproc_free(qproc->rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 1917de7db91c..f5cedeaafba1 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -585,7 +585,7 @@ static int wcnss_probe(struct platform_device *pdev)
return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -598,7 +598,7 @@ static int wcnss_remove(struct platform_device *pdev)
qcom_smem_state_put(wcnss->state);
rproc_del(wcnss->rproc);
- rproc_put(wcnss->rproc);
+ rproc_free(wcnss->rproc);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 3da566b0d437..ede3af14b9d0 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1307,7 +1307,7 @@ static struct device_type rproc_type = {
* On success the new rproc is returned, and on failure, NULL.
*
* Note: _never_ directly deallocate @rproc, even if it was not registered
- * yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ * yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
*/
struct rproc *rproc_alloc(struct device *dev, const char *name,
const struct rproc_ops *ops,
@@ -1386,7 +1386,22 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
EXPORT_SYMBOL(rproc_alloc);
/**
- * rproc_put() - unroll rproc_alloc()
+ * rproc_free() - unroll rproc_alloc()
+ * @rproc: the remote processor handle
+ *
+ * This function decrements the rproc dev refcount.
+ *
+ * If no one holds any reference to rproc anymore, then its refcount would
+ * now drop to zero, and it would be freed.
+ */
+void rproc_free(struct rproc *rproc)
+{
+ put_device(&rproc->dev);
+}
+EXPORT_SYMBOL(rproc_free);
+
+/**
+ * rproc_put() - release rproc reference
* @rproc: the remote processor handle
*
* This function decrements the rproc dev refcount.
@@ -1411,7 +1426,7 @@ EXPORT_SYMBOL(rproc_put);
*
* After rproc_del() returns, @rproc isn't freed yet, because
* of the outstanding reference created by rproc_alloc. To decrement that
- * one last refcount, one still needs to call rproc_put().
+ * one last refcount, one still needs to call rproc_free().
*
* Returns 0 on success and -EINVAL if @rproc isn't valid.
*/
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
index 6f056caa8a56..ae8963fcc8c8 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -262,7 +262,7 @@ static int st_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -277,7 +277,7 @@ static int st_rproc_remove(struct platform_device *pdev)
of_reserved_mem_device_release(&pdev->dev);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/ste_modem_rproc.c b/drivers/remoteproc/ste_modem_rproc.c
index 53dc17bdd54e..03d69a9a3c5b 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -257,7 +257,7 @@ static int sproc_drv_remove(struct platform_device *pdev)
rproc_del(sproc->rproc);
dma_free_coherent(sproc->rproc->dev.parent, SPROC_FW_SIZE,
sproc->fw_addr, sproc->fw_dma_addr);
- rproc_put(sproc->rproc);
+ rproc_free(sproc->rproc);
mdev->drv_data = NULL;
@@ -325,7 +325,7 @@ static int sproc_probe(struct platform_device *pdev)
free_rproc:
/* Reset device data upon error */
mdev->drv_data = NULL;
- rproc_put(rproc);
+ rproc_free(rproc);
return err;
}
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 3811cb522af3..18175d0331fd 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -208,7 +208,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
return 0;
err_put_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
err:
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
@@ -220,7 +220,7 @@ static int wkup_m3_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index c321eab5054e..930023b7c825 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -493,6 +493,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
void rproc_put(struct rproc *rproc);
int rproc_add(struct rproc *rproc);
int rproc_del(struct rproc *rproc);
+void rproc_free(struct rproc *rproc);
int rproc_boot(struct rproc *rproc);
void rproc_shutdown(struct rproc *rproc);
--
2.5.0
^ permalink raw reply related
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-03 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2bhMbkQrGG55Bq-yrFk_DC3Pz2tF0CRrt4ccmrzTmrzQ@mail.gmail.com>
On 10/2/2016 7:40 AM, Jonathan Liu wrote:
> This series fixes one or more network adapters in VirtualBox not
> working with Linux 32-bit x86 guest if I have 4 network adapters
> enabled. The following message no longer appears in the kernel log:
> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>
> Tested-by: Jonathan Liu <net147@gmail.com>
Thanks for the test. I didn't realize that VirtualBox was broken too.
So far I got some random test results in the mail list that something
is broken. I hope to hear more that we close the issue for some time
now.
The IRQ stuff got broken three times already. Hopefully, this will be
the seal.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V2 3/5] PCI: save and restore bus on parent bus reset
From: Sinan Kaya @ 2016-10-03 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8dbad89c-2646-773a-e114-42d21ce14cc7@codeaurora.org>
On 9/29/2016 7:50 PM, Sinan Kaya wrote:
> Hi Bjorn,
>
> On 9/29/2016 5:49 PM, Bjorn Helgaas wrote:
>>> + }
>> This pattern of "unlock, do something, relock" needs some
>> justification. In general it's unsafe because the lock is protecting
>> *something*, and you have to assume that something can change as soon
>> as you unlock. Maybe you know it's safe in this situation, and if so,
>> the explanation of why it's safe is what I'm looking for.
>
> Agreed.
>
> The problem is that save and restore routines obtain the lock again and
> they fails as the lock is already held.
>
> The alternative is to change the dev_locks in save and restore to try_lock
> so that it will work if locks were previously obtained or not.
>
>>
>> Also, you're now calling pci_reset_bridge_secondary_bus() with the dev
>> unlocked, where we called it with the dev locked before. Some (but
>> worryingly, not all) of the other pci_reset_bridge_secondary_bus()
>> callers also have the dev locked. I didn't look long enough to figure
>> out if there is a strategy there or if these inconsistencies are
>> latent bugs.
>>
>
> The goal of this routine is to reset the device not the bridge and the code
> will use FLR or others if available. Therefore, it makes perfect sense to
> obtain the device lock while doing this.
>
> The code tries to reset the bus if none of the other resets work. This is
> where the problem is. It destroys the context for other devices.
>
> I can fix get rid of this unlock, do something and then lock again business
> by rewriting the locks in save and restore.
>
> Sinan
>
I looked at the code a little bit more. I missed the fact pci_parent_bus_reset
will only work if there is only PCI device on the bus and that device is the
reset requesting device.
I'll drop this patch as well as the infiniband version for the same reason.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF
From: Vinod Koul @ 2016-10-03 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da6536a3-353e-1364-7074-9d3dcbcc4171@codeaurora.org>
On Sat, Oct 01, 2016 at 11:15:00AM -0400, Sinan Kaya wrote:
> On 10/1/2016 2:17 AM, Vinod Koul wrote:
> > On Wed, Sep 28, 2016 at 10:12:41PM -0400, Sinan Kaya wrote:
> >> Configure the DMA bindings for the device tree based firmware.
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> drivers/dma/qcom/hidma_mgmt.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
> >> index 82f36e4..e8f6b84 100644
> >> --- a/drivers/dma/qcom/hidma_mgmt.c
> >> +++ b/drivers/dma/qcom/hidma_mgmt.c
> >> @@ -375,8 +375,11 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
> >> ret = PTR_ERR(new_pdev);
> >> goto out;
> >> }
> >> + of_node_get(child);
> >> + new_pdev->dev.of_node = child;
> >> of_dma_configure(&new_pdev->dev, child);
> >> -
> >> + of_msi_configure(&new_pdev->dev, child);
> >> + of_node_put(child);
> >
> > should this be done unconditionally? Dont we needto call this only for
> > platforms with msi?
>
> I followed the pattern in of_platform_device_create_pdata function. of_msi_configure does
> nothing if MSI is not enabled as irq_find_matching_host returns NULL. It didn't have any
> side effects on my testing either.
yeah later on I did look up the of_msi_configure() and I suspected this. I
think it would be worthwhile to document this assumption here.
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH V4 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic
From: Vinod Koul @ 2016-10-03 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5782331-0dc6-9e0e-777c-372dc88f38e3@codeaurora.org>
On Sat, Oct 01, 2016 at 11:19:43AM -0400, Sinan Kaya wrote:
> On 10/1/2016 2:19 AM, Vinod Koul wrote:
> >> Making it atomic so that it can be updated from multiple contexts.
> > How is it multiple contexts? It's either existing context of MSI, not both!
> >
>
> I was trying to mean multiple processor contexts here. The driver allocates 11
> MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then,
> we have a race condition for common variables as they share the same interrupt
> handler with a different cause bit.
>
> I will put the above description into the commit text.
Sounds better :)
--
~Vinod
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: add device node for IRAM on-chip memory
From: Olof Johansson @ 2016-10-03 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467931601-25067-1-git-send-email-vz@mleia.com>
On Fri, Jul 08, 2016 at 01:46:41AM +0300, Vladimir Zapolskiy wrote:
> The change adds a new device node with description of generic SRAM
> on-chip memory found on NXP LPC32xx SoC series and connected to AHB
> matrix slave port 3.
>
> Note that NXP LPC3220 SoC has 128KiB of SRAM memory, the other
> LPC3230, LPC3240 and LPC3250 SoCs all have 256KiB SRAM space,
> in the shared DTSI file this change specifies 128KiB SRAM size.
>
> Also it's worth to mention that the SRAM area contains of 64KiB banks,
> 2 banks on LPC3220 and 4 banks on the other SoCs from the series, and
> all SRAM banks but the first one have independent power controls,
> the description of this feature will be added with the introduction of
> power domains for the SoC series.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
> ---
>
> Hi Arnd, Olof, Kevin,
>
> please consider to include this NXP LPC32xx DT change directly to
> ARM tree for v4.8.
>
> The SRAM device node will be utilized to store PM resume code
> and to store MAC buffers.
Hi,
When sweeping my inbox looking for patches we had missed, this still showed
up from back in July. I've now applied it, it'll make it into 4.9 (in
next/late). Sorry for missing it earlier.
-Olof
^ permalink raw reply
* [PATCH] arm64: Enable HIBERNATION in defconfig
From: Olof Johansson @ 2016-10-03 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915100231.GG2492@e104818-lin.cambridge.arm.com>
Hi,
On Thu, Sep 15, 2016 at 11:02:31AM +0100, Catalin Marinas wrote:
> On Thu, Sep 15, 2016 at 10:42:14AM +0100, Catalin Marinas wrote:
> > This patch adds CONFIG_HIBERNATION to the arm64 defconfig.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index eadf4855ad2d..91a7592029e3 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -80,6 +80,7 @@ CONFIG_KEXEC=y
> > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> > CONFIG_COMPAT=y
> > CONFIG_CPU_IDLE=y
> > +CONFIG_HIBERNATION=y
> > CONFIG_ARM_CPUIDLE=y
> > CONFIG_CPU_FREQ=y
> > CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
>
> Or maybe it could go through arm-soc as it seems Arnd has picked up a
> few other defconfig patches.
When we just get a cc of a reply to a patch, it's usually pretty error prone
whether we end up applying it. Which happened here, I just came across this
when making a final sweep.
Yes, in general we tend to have more changes to the defconfig, so it's
appreciated to get these sent our way.
Given timing, resend after -rc1? We should be OK with applying it for 4.9
still around that time.
-Olof
^ permalink raw reply
* [PATCH] net: ethernet: mediatek: mark symbols static where possible
From: David Miller @ 2016-10-03 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475221730-18773-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Fri, 30 Sep 2016 15:48:50 +0800
> We get 2 warnings when building kernel with W=1:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes]
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:2052:5: warning: no previous prototype for 'mtk_set_link_ksettings' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> So this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Olof Johansson @ 2016-10-03 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475445239-25006-1-git-send-email-linus.walleij@linaro.org>
On Sun, Oct 02, 2016 at 11:53:59PM +0200, Linus Walleij wrote:
> After being asked to not depend on ARCH_QCOM* or similar,
> unsurprisingly compilation fails on UM as it has no I/O
> memory:
>
> drivers/built-in.o: In function `qcom_ebi2_probe':
> >> drivers/bus/qcom-ebi2.c:333: undefined reference to
> `devm_ioremap_resource'
>
> Fix this by letting the Kconfig atleast depend on HAS_IOMEM.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: linux-arm-msm at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC maintainers: please apply this directly on the offending
> branch, or line it up for v4.9 fixes.
Applied to next/drivers. A Fixes: tag could have been nice, but it was
easy to find where the offender was.
-Olof
^ permalink raw reply
* [GIT PULL 1/4] Broadcom devicetree changes for 4.9 (part 2)
From: Olof Johansson @ 2016-10-03 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475263395-27653-1-git-send-email-f.fainelli@gmail.com>
On Fri, Sep 30, 2016 at 12:23:12PM -0700, Florian Fainelli wrote:
> The following changes since commit 7260ecd22baa3c62ef6efaf59e7de53f4c8df800:
>
> Merge tag 'bcm2835-dt-next-2016-08-29' into devicetree/next (2016-08-30 20:02:04 -0700)
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/devicetree-part2
>
> for you to fetch changes up to ef3bc318adeb15b38688df6a583bafea2befce43:
>
> ARM: BCM5301X: Add DT for Luxul XWR-3100 (2016-09-30 11:58:31 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based SoCs Device Tree changes for 4.9,
> please pull the following:
>
> - Rafal adds support for the Netgear R8500 routers, adds basic support
> for the Tenda AC9 router which uses the new BCM53573 SoC (single core Cortex
> A7). He also enables the UART on the Netgear R8000 and restructures the
> include files a bit for the BCM47094 SoC, finally he adds USB 3.0 PHY nodes
> which enables USB 3.0 on BCM5301X devices that support it
>
> - Kamal adds support for the QSPI controller on the Northstar Plus SoCs and updates
> the bcm958625k reference board to have it enabled
>
> - Dan adds support for the Luxul XAP-1510 and XWR-3100 devices
Hi Florian,
Given the timing of these pull requests, we'll have to hold them off
for 4.10. The defconfig changes can be considered for -rc2, but the
DT contents should wait.
Please send a fresh pull request once 4.9-rc1 is out.
Thanks,
-Olof
^ permalink raw reply
* [PATCH V3 0/2] PCI: add CRS support after hot reset and FLR
From: Sinan Kaya @ 2016-10-03 5:36 UTC (permalink / raw)
To: linux-arm-kernel
The PCIE spec allows an endpoint device to extend the initialization time
beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
vendor ID read request.
This basically means "I'm busy now, please call me back later".
There are two moving parts to CRS support from the SW perspective. One part
is to determine if CRS is supported or not. The second part is to set the
CRS visibility register.
As part of the probe, the Linux kernel sets the above two conditions in
pci_enable_crs function. The kernel is also honoring the returned CRS in
pci_bus_read_dev_vendor_id function if supported. The function will poll up
to specified amount of time while endpoint is returning CRS response.
The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
resets.
The hot reset is initiated by starting a secondary bus reset. A bus/device
restore follows the reset. This patch is adding vendor ID read into dev
restore function to validate that the device is accessible before writing
the register contents. If the device issues CRS, the code might poll up
to 60 seconds.
An endpoint is allowed to issue CRS following an FLR request to indicate
that it is not ready to accept new requests. Changing the polling mechanism
in FLR wait function to go read the vendor ID instead of the command/status
register. A CRS indication will only be given if the address to be read is
vendor ID.
v3:
* dropped parent_bus_reset change and IB/hfi1 changes as both of them work
only when there is a single device on the bus and reset is for the device
in the bus.
* dropper AER changes as AER driver broadcasts error to the endpoint device
driver which eventually cause endpoint driver to be reprobed after fatal
error.
* moved vendor id read into the pci_dev_restore function as this is the
* first
attempt to contact the endpoint after a reset.
v2:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1233472.html
* IB/hfi1 via pci_reset_bridge_secondary_bus
* PCI/AER via pci_reset_bridge_secondary_bus
* PCI: dev_reset via parent bus reset
* use walk_bus for vendor id reads since the lock is no longer held.
v1:
http://www.spinics.net/lists/linux-pci/msg53596.html
* initial implementation
Sinan Kaya (2):
PCI: add CRS support to error handling path
PCI: handle CRS returned by device after FLR
drivers/pci/pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH V3 1/2] PCI: add CRS support to error handling path
From: Sinan Kaya @ 2016-10-03 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475473021-14251-1-git-send-email-okaya@codeaurora.org>
The PCIE spec allows an endpoint device to extend the initialization time
beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
vendor ID read request.
This basically means "I'm busy now, please call me back later".
There are two moving parts to CRS support from the SW perspective. One part
is to determine if CRS is supported or not. The second part is to set the
CRS visibility register.
As part of the probe, the Linux kernel sets the above two conditions in
pci_enable_crs function. The kernel is also honoring the returned CRS in
pci_bus_read_dev_vendor_id function if supported. The function will poll up
to specified amount of time while endpoint is returning CRS response.
The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
resets.
The hot reset is initiated by starting a secondary bus reset. A bus/device
restore follows the reset. This patch is adding vendor ID read into dev
restore function to validate that the device is accessible before writing
the register contents. If the device issues CRS, the code might poll up
to 60 seconds.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index aab9d51..c8749b9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4020,6 +4020,12 @@ static void pci_dev_save_and_disable(struct pci_dev *dev)
static void pci_dev_restore(struct pci_dev *dev)
{
+ u32 l;
+
+ /* see if the device is accessible first */
+ if (!pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &l, 60 * 1000))
+ return;
+
pci_restore_state(dev);
pci_reset_notify(dev, false);
}
--
1.9.1
^ 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