* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Catalin Marinas @ 2016-10-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKMZTo7m=ygm7x8w__1my0jiQiVAiv9NowQ8pfQqCnjmw@mail.gmail.com>
Hi Kees,
On Fri, Oct 14, 2016 at 02:44:33PM -0700, Kees Cook wrote:
> Just checking in on this feature -- I don't see it in -next nor
> already in the tree. Is there any chance this is going to make the
> v4.9 merge window?
As I said in the cover letter, I'll rebase it on top of 4.9-rc1 as there
are some clean-ups that this series would conflict with. So I am
targeting 4.10 with this patch series.
> It didn't sound like there were any unresolved issues remaining?
There are a few issues spotted by Mark which I'll address in the next
version, but nothing major.
--
Catalin
^ permalink raw reply
* [PATCH V3 2/3] Revert "ACPI, PCI, IRQ: remove SCI penalize function"
From: Rafael J. Wysocki @ 2016-10-15 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-3-git-send-email-okaya@codeaurora.org>
On Sat, Oct 15, 2016 at 6:31 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The SCI function was removed in two steps (first refactor and then remove).
> This patch does the revert in one step.
"The SCI penalize function was removed in two steps (first refactor
and then remove) and these changes are reverted here in one go."
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. This patch does a partial
> revert for the SCI functionality only.
I'd write the last sentence this way:
"That change is partially reverted here, specifically for the SCI IRQ alone."
> The commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function") is
> for the removal of the function. SCI penalty API was replaced by the
> runtime penalty calculation based on the value of
> acpi_gbl_FADT.sci_interrupt.
"The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
(ACPI,PCI,IRQ: remove SCI penalize function) that replaced the old SCI
penalty API with penalty calculation carried out dynamically and based
on the acpi_gbl_FADT.sci_interrupt value."
> The IRQ 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.
"However, that new algorithm relies on the accurate setting of IRQ
types and that doesn't happen early enough on some platforms which
leads to incorrect penalty assignments for PCI IRQs. In those cases,
irq_get_trigger_type() returns incorrect values for the IRQs in
question, because they have not been registered yet by the time the
penalties are calculated."
And then you don't need the paragraph below then.
> The register_gsi function delivers the IRQ found in the ACPI table to
> the interrupt controller driver. Penalties are calculated before a
> link object is enabled to find out which interrupt has the least number
> of users. By the time penalties are calculated, the IRQ is not registered
> yet and the API returns the wrong type.
And I would add:
"For this reason, revert commit 9e5ed6d1fb87 (ACPI,PCI,IRQ: remove SCI
penalize function) completely to restore the correct behavior."
Also, please add Fixes: tags pointing to the commits you're fixing here.
> Tested-by: Jonathan Liu <net147@gmail.com>
> Tested-by: Ondrej Zary <linux@rainbow-software.org>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 32 +++++++++++++-------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 15 insertions(+), 19 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 a212709..1934e2a 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -494,27 +494,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_isa_irq_penalty[irq];
> + return acpi_isa_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)
> @@ -885,6 +868,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_isa_irq_penalty)) {
> + if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
> + polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
> + acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
> + else
> + acpi_isa_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 c5eaf2f..67d1d3e 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);
> --
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Rafael J. Wysocki @ 2016-10-15 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-2-git-send-email-okaya@codeaurora.org>
On Sat, Oct 15, 2016 at 6:31 AM, 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 interrupts greater than 16.
>
> The array size has been reduced to 16 and array name got prefixed as ISA
> since it only is accountable for the ISA interrupts.
>
> The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed penalty assignment in the code for PCI
> thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
> function.
I'd write the above this way:
"Commit 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
dropped the PCI_USING penalty from acpi_pci_link_allocate() with the
assumption that the penalty will be added later in
acpi_irq_pci_sharing_penalty()."
This conveys essentially the same information (up to some irrelevant
bits), but in a clearer way IMO.
>
> However, this function only gets called if the IRQ number is greater than
> 16 and acpi_irq_get_penalty function gets called before ACPI start in
> acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
> on iterating the link list.
"However, acpi_irq_pci_sharing_penalty() is only called for IRQ
numbers above 15. Moreover, acpi_irq_get_penalty() is invoked by
acpi_isa_irq_available() and acpi_penalize_isa_irq() before the ACPI
initialization and the PCI interrupt links list is not ready at that
point, so it cannot be relied on when computing the penalty."
>
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.
"For this reason, the PCI_USING penalty has to be added in
acpi_pci_link_allocate() directly if the link has been enabled
successfully and the IRQ number is within the ISA range."
IIUC
>
> 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 c983bf7..a212709 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -619,6 +619,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_ISA_IRQS)
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
There's no need to break the line here and I would put the above after
the printk().
Or even after the whole "else" branch (which is unnecessary, but let's
limit changes in this patch).
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
> --
Thanks,
Rafael
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Stefan Wahren @ 2016-10-15 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015112740.GB11674@kroah.com>
Hi Greg,
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 15. Oktober 2016 um
> 13:27 geschrieben:
>
>
> On Sat, Oct 15, 2016 at 10:35:25AM +0200, Stefan Wahren wrote:
> >
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> > > 09:05 geschrieben:
> > >
> > >
> > > On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > > > The driver builds now.
> > > >
> > > > Signed-off-by: Eric Anholt <eric@anholt.net>
> > > > ---
> > > > drivers/staging/vc04_services/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/vc04_services/Kconfig
> > > > b/drivers/staging/vc04_services/Kconfig
> > > > index 9676fb29075a..db8e1beb89f9 100644
> > > > --- a/drivers/staging/vc04_services/Kconfig
> > > > +++ b/drivers/staging/vc04_services/Kconfig
> > > > @@ -1,6 +1,6 @@
> > > > config BCM2708_VCHIQ
> > > > tristate "Videocore VCHIQ"
> > > > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > > > + depends on RASPBERRYPI_FIRMWARE
> > > > default y
> > > > help
> > > > Kernel to VideoCore communication interface for the
> > >
> > > I've dropped this patch from my branch as there are build errors on
> > > arm64 systems still, and we don't want regressions like that.
> > >
> > > I've forwarded you the error messages, and I'll be glad to add this
> > > patch back once these issues are fixed.
> >
> > I ask the author of this downstream pull request [1] to send the VHCIQ part
> > as
> > indiviual patches.
> > He is interested to submit them upstream.
> >
> > [1] - https://github.com/raspberrypi/linux/pull/1611
>
> Ok, but what does that mean for us here? The code should be all now
> merged into our "upstream" trees, it just needs to be cleaned up
> properly.
>
> confused,
>
> greg k-h
sorry for the confusion. I mean that he wants to send email patches based on
your staging tree. So we avoid patching the kernel twice.
The link was only for illustration that he already fixed most of the arm64 build
issues.
Stefan
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Greg Kroah-Hartman @ 2016-10-15 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <886598225.386698.0cc5acd0-af27-4ef7-892f-3c2dd86176ba.open-xchange@email.1und1.de>
On Sat, Oct 15, 2016 at 10:35:25AM +0200, Stefan Wahren wrote:
>
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> > 09:05 geschrieben:
> >
> >
> > On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > > The driver builds now.
> > >
> > > Signed-off-by: Eric Anholt <eric@anholt.net>
> > > ---
> > > drivers/staging/vc04_services/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/vc04_services/Kconfig
> > > b/drivers/staging/vc04_services/Kconfig
> > > index 9676fb29075a..db8e1beb89f9 100644
> > > --- a/drivers/staging/vc04_services/Kconfig
> > > +++ b/drivers/staging/vc04_services/Kconfig
> > > @@ -1,6 +1,6 @@
> > > config BCM2708_VCHIQ
> > > tristate "Videocore VCHIQ"
> > > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > > + depends on RASPBERRYPI_FIRMWARE
> > > default y
> > > help
> > > Kernel to VideoCore communication interface for the
> >
> > I've dropped this patch from my branch as there are build errors on
> > arm64 systems still, and we don't want regressions like that.
> >
> > I've forwarded you the error messages, and I'll be glad to add this
> > patch back once these issues are fixed.
>
> I ask the author of this downstream pull request [1] to send the VHCIQ part as
> indiviual patches.
> He is interested to submit them upstream.
>
> [1] - https://github.com/raspberrypi/linux/pull/1611
Ok, but what does that mean for us here? The code should be all now
merged into our "upstream" trees, it just needs to be cleaned up
properly.
confused,
greg k-h
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2131339088.8778.d47a56f6-921e-4d6c-9a5c-2e77bfd5d281.open-xchange@email.1und1.de>
Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren <stefan.wahren@i2se.com>:
>Hi J?rg,
>
>> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um
>10:46
>> geschrieben:
>>
>>
>> Thanks!
>>
>>
>> For the record:
>>
>> Note, this is the result for the wireless interface.
>>
>> I got one of my custom boards running the legacy Linux Kernel 2.6.35
>> officially supported from Freescale (NXP) and the bcmdhd driver from
>> the Wiced project, where I get >20Mbps TCP throughput. The firmware
>> version reported is:
>>
>> # wl ver
>> 5.90 RC115.2
>> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>>
>>
>> I got it also running with the Linux Kernel 4.1.15 from Freescale
>[2],
>> which is not officially supported for the i.MX28 target, with the
>> latest bcmdhd version where I get <7Mbps TCP throughput (which is
>much
>> the same I get with the brcmfmac driver). The firmware version
>reported
>> is:
>>
>> # wl ver
>> 1.107 RC5.0
>> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>>
>> So, probably something is missing in the newer Kernel version, which
>is
>> present in the legacy Kernel 2.6.35.
>>
>> [1]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_2.6.35_1.1.0
>> [2]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_4.1.15_1.0.0_ga
>
>during implementation of DDR mode for the mmc driver [1] i noticed a
>performance
>gap between the vendor kernel and mainline by a factor of 2. I expect
>that your
>wireless interface is connected via SDIO.
I wonder if this [2] might be related. As far as I can see it is not present in mainline.
>
>[1] -
>http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
[2]
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_2.6.35_1.1.0&id=c105f3ef1d461aaeedbc6361941096b6684cc812
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2131339088.8778.d47a56f6-921e-4d6c-9a5c-2e77bfd5d281.open-xchange@email.1und1.de>
Hi Stefan,
Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren <stefan.wahren@i2se.com>:
>Hi J?rg,
>
>> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um
>10:46
>> geschrieben:
>>
>>
>> Thanks!
>>
>>
>> For the record:
>>
>> Note, this is the result for the wireless interface.
>>
>> I got one of my custom boards running the legacy Linux Kernel 2.6.35
>> officially supported from Freescale (NXP) and the bcmdhd driver from
>> the Wiced project, where I get >20Mbps TCP throughput. The firmware
>> version reported is:
>>
>> # wl ver
>> 5.90 RC115.2
>> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>>
>>
>> I got it also running with the Linux Kernel 4.1.15 from Freescale
>[2],
>> which is not officially supported for the i.MX28 target, with the
>> latest bcmdhd version where I get <7Mbps TCP throughput (which is
>much
>> the same I get with the brcmfmac driver). The firmware version
>reported
>> is:
>>
>> # wl ver
>> 1.107 RC5.0
>> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>>
>> So, probably something is missing in the newer Kernel version, which
>is
>> present in the legacy Kernel 2.6.35.
>>
>> [1]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_2.6.35_1.1.0
>> [2]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_4.1.15_1.0.0_ga
>
>during implementation of DDR mode for the mmc driver [1] i noticed a
>performance
>gap between the vendor kernel and mainline by a factor of 2. I expect
>that your
>wireless interface is connected via SDIO.
Yes, it is. I had the suspicion that the MMC or the DMA driver is the bootleneck, too.
>
>[1] -
>http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
Looks like the patches might help. Have you tried SDIO wifi so far?
J?rg
^ permalink raw reply
* [PATCH] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
From: Ard Biesheuvel @ 2016-10-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
The symbol CRCs are emitted as ELF symbols, which allows us to easily
populate the kcrctab sections by relying on the linker to associate
each kcrctab slot with the correct value.
This has two downsides:
- given that the CRCs are treated as pointers, we waste 4 bytes for
each CRC on 64 bit architectures,
- on architectures that support runtime relocation, a relocation entry is
emitted for each CRC value, which may take up 24 bytes of __init space
(on ELF64 systems)
This comes down to a x8 overhead in [uncompressed] kernel size. In addition,
each relocation has to be reverted before the CRC value can be used, which
has resulted in an ugly workaround involving ARCH_RELOCATES_KCRCTAB, and an
even uglier workaround around the workaround involving the "TOC." symbol on
PPC64. This patch gets rid of all of that.
So switch to explicit 32 bit values on 64 bit architectures. This fixes
both issues, given that 32 bit values are not treated as runtime relocatable
quantities on ELF64 systems, even if they ultimately resolve to linker
supplied values. Also note that the only two architectures affected by the
runtime relocation issue are PPC and arm64, both of which rely on the
toolchain's PIE routines to create a runtime relocatable vmlinux. While x86
also implements CONFIG_RELOCATABLE, it relies on its own build tools, which
disregard kcrctab entries explicitly.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do no exceed 0xffffffff).
Also remove the special handling for PPC64, this should no longer be
required.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
I received some feedback on draft versions of this patch from the kbuild
test robot, but none of it regarding the inline asm in this patch.
Hopefully, that means it works on all 64 bit architectures we support,
but I have not been able to test that exhaustively myself.
On an arm64 defconfig build with CONFIG_RELOCATABLE=y, this patch reduces
the CRC footprint by 24 KB for .rodata, and by 217 KB for .init
Before:
[ 9] __kcrctab PROGBITS ffff000008b992a8 00b292a8
0000000000009440 0000000000000000 A 0 0 8
[10] __kcrctab_gpl PROGBITS ffff000008ba26e8 00b326e8
0000000000008d40 0000000000000000 A 0 0 8
...
[22] .rela RELA ffff000008c96e20 00c26e20
00000000001cc758 0000000000000018 A 0 0 8
After:
[ 9] __kcrctab PROGBITS ffff000008b728a8 00b028a8
0000000000004a20 0000000000000000 A 0 0 1
[10] __kcrctab_gpl PROGBITS ffff000008b772c8 00b072c8
00000000000046a0 0000000000000000 A 0 0 1
...
[22] .rela RELA ffff000008c66e20 00bf6e20
00000000001962d8 0000000000000018 A 0 0 8
arch/powerpc/include/asm/module.h | 4 --
arch/powerpc/kernel/module_64.c | 8 ----
include/linux/export.h | 8 ++++
include/linux/module.h | 16 ++++----
kernel/module.c | 39 +++++++-------------
5 files changed, 30 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
index cd4ffd86765f..94a7f7aa3ae8 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -94,9 +94,5 @@ struct exception_table_entry;
void sort_ex_table(struct exception_table_entry *start,
struct exception_table_entry *finish);
-#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
-#define ARCH_RELOCATES_KCRCTAB
-#define reloc_start PHYSICAL_START
-#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MODULE_H */
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 183368e008cf..be9b2d5ff846 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -286,14 +286,6 @@ static void dedotify_versions(struct modversion_info *vers,
for (end = (void *)vers + size; vers < end; vers++)
if (vers->name[0] == '.') {
memmove(vers->name, vers->name+1, strlen(vers->name));
-#ifdef ARCH_RELOCATES_KCRCTAB
- /* The TOC symbol has no CRC computed. To avoid CRC
- * check failing, we must force it to the expected
- * value (see CRC check in module.c).
- */
- if (!strcmp(vers->name, "TOC."))
- vers->crc = -(unsigned long)reloc_start;
-#endif
}
}
diff --git a/include/linux/export.h b/include/linux/export.h
index d7df4922da1d..1d2f841e8368 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -40,6 +40,7 @@ extern struct module __this_module;
#if defined(__KERNEL__) && !defined(__GENKSYMS__)
#ifdef CONFIG_MODVERSIONS
+#ifndef CONFIG_64BIT
/* Mark the CRC weak since genksyms apparently decides not to
* generate a checksums for some symbols */
#define __CRC_SYMBOL(sym, sec) \
@@ -49,6 +50,13 @@ extern struct module __this_module;
__attribute__((section("___kcrctab" sec "+" #sym), unused)) \
= (unsigned long) &__crc_##sym;
#else
+#define __CRC_SYMBOL(sym, sec) \
+ asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
+ " .weak " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
+ " .word " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
+ " .previous \n");
+#endif
+#else
#define __CRC_SYMBOL(sym, sec)
#endif
diff --git a/include/linux/module.h b/include/linux/module.h
index 0c3207d26ac0..a51b70fcbc6b 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -33,7 +33,7 @@
#define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
struct modversion_info {
- unsigned long crc;
+ u32 crc;
char name[MODULE_NAME_LEN];
};
@@ -346,7 +346,7 @@ struct module {
/* Exported symbols */
const struct kernel_symbol *syms;
- const unsigned long *crcs;
+ const u32 *crcs;
unsigned int num_syms;
/* Kernel parameters. */
@@ -359,18 +359,18 @@ struct module {
/* GPL-only exported symbols. */
unsigned int num_gpl_syms;
const struct kernel_symbol *gpl_syms;
- const unsigned long *gpl_crcs;
+ const u32 *gpl_crcs;
#ifdef CONFIG_UNUSED_SYMBOLS
/* unused exported symbols. */
const struct kernel_symbol *unused_syms;
- const unsigned long *unused_crcs;
+ const u32 *unused_crcs;
unsigned int num_unused_syms;
/* GPL-only, unused exported symbols. */
unsigned int num_unused_gpl_syms;
const struct kernel_symbol *unused_gpl_syms;
- const unsigned long *unused_gpl_crcs;
+ const u32 *unused_gpl_crcs;
#endif
#ifdef CONFIG_MODULE_SIG
@@ -382,7 +382,7 @@ struct module {
/* symbols that will be GPL-only in the near future. */
const struct kernel_symbol *gpl_future_syms;
- const unsigned long *gpl_future_crcs;
+ const u32 *gpl_future_crcs;
unsigned int num_gpl_future_syms;
/* Exception table */
@@ -523,7 +523,7 @@ struct module *find_module(const char *name);
struct symsearch {
const struct kernel_symbol *start, *stop;
- const unsigned long *crcs;
+ const u32 *crcs;
enum {
NOT_GPL_ONLY,
GPL_ONLY,
@@ -539,7 +539,7 @@ struct symsearch {
*/
const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
- const unsigned long **crc,
+ const u32 **crc,
bool gplok,
bool warn);
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..f2d39148814a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -386,16 +386,16 @@ extern const struct kernel_symbol __start___ksymtab_gpl[];
extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const struct kernel_symbol __start___ksymtab_gpl_future[];
extern const struct kernel_symbol __stop___ksymtab_gpl_future[];
-extern const unsigned long __start___kcrctab[];
-extern const unsigned long __start___kcrctab_gpl[];
-extern const unsigned long __start___kcrctab_gpl_future[];
+extern const u32 __start___kcrctab[];
+extern const u32 __start___kcrctab_gpl[];
+extern const u32 __start___kcrctab_gpl_future[];
#ifdef CONFIG_UNUSED_SYMBOLS
extern const struct kernel_symbol __start___ksymtab_unused[];
extern const struct kernel_symbol __stop___ksymtab_unused[];
extern const struct kernel_symbol __start___ksymtab_unused_gpl[];
extern const struct kernel_symbol __stop___ksymtab_unused_gpl[];
-extern const unsigned long __start___kcrctab_unused[];
-extern const unsigned long __start___kcrctab_unused_gpl[];
+extern const u32 __start___kcrctab_unused[];
+extern const u32 __start___kcrctab_unused_gpl[];
#endif
#ifndef CONFIG_MODVERSIONS
@@ -494,7 +494,7 @@ struct find_symbol_arg {
/* Output */
struct module *owner;
- const unsigned long *crc;
+ const u32 *crc;
const struct kernel_symbol *sym;
};
@@ -560,7 +560,7 @@ static bool find_symbol_in_section(const struct symsearch *syms,
* (optional) module which owns it. Needs preempt disabled or module_mutex. */
const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
- const unsigned long **crc,
+ const u32 **crc,
bool gplok,
bool warn)
{
@@ -1257,22 +1257,11 @@ static int try_to_force_load(struct module *mod, const char *reason)
}
#ifdef CONFIG_MODVERSIONS
-/* If the arch applies (non-zero) relocations to kernel kcrctab, unapply it. */
-static unsigned long maybe_relocated(unsigned long crc,
- const struct module *crc_owner)
-{
-#ifdef ARCH_RELOCATES_KCRCTAB
- if (crc_owner == NULL)
- return crc - (unsigned long)reloc_start;
-#endif
- return crc;
-}
-
static int check_version(Elf_Shdr *sechdrs,
unsigned int versindex,
const char *symname,
struct module *mod,
- const unsigned long *crc,
+ const u32 *crc,
const struct module *crc_owner)
{
unsigned int i, num_versions;
@@ -1294,10 +1283,10 @@ static int check_version(Elf_Shdr *sechdrs,
if (strcmp(versions[i].name, symname) != 0)
continue;
- if (versions[i].crc == maybe_relocated(*crc, crc_owner))
+ if (versions[i].crc == *crc)
return 1;
- pr_debug("Found checksum %lX vs module %lX\n",
- maybe_relocated(*crc, crc_owner), versions[i].crc);
+ pr_debug("Found checksum %X vs module %X\n",
+ *crc, versions[i].crc);
goto bad_version;
}
@@ -1314,7 +1303,7 @@ static inline int check_modstruct_version(Elf_Shdr *sechdrs,
unsigned int versindex,
struct module *mod)
{
- const unsigned long *crc;
+ const u32 *crc;
/*
* Since this should be found in kernel (which can't be removed), no
@@ -1347,7 +1336,7 @@ static inline int check_version(Elf_Shdr *sechdrs,
unsigned int versindex,
const char *symname,
struct module *mod,
- const unsigned long *crc,
+ const u32 *crc,
const struct module *crc_owner)
{
return 1;
@@ -1375,7 +1364,7 @@ static const struct kernel_symbol *resolve_symbol(struct module *mod,
{
struct module *owner;
const struct kernel_symbol *sym;
- const unsigned long *crc;
+ const u32 *crc;
int err;
/*
--
2.7.4
^ permalink raw reply related
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-10-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476521171.1670.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um 10:46
> geschrieben:
>
>
> Thanks!
>
>
> For the record:
>
> Note, this is the result for the wireless interface.
>
> I got one of my custom boards running the legacy Linux Kernel 2.6.35
> officially supported from Freescale (NXP) and the bcmdhd driver from
> the Wiced project, where I get >20Mbps TCP throughput. The firmware
> version reported is:
>
> # wl ver
> 5.90 RC115.2
> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>
>
> I got it also running with the Linux Kernel 4.1.15 from Freescale [2],
> which is not officially supported for the i.MX28 target, with the
> latest bcmdhd version where I get <7Mbps TCP throughput (which is much
> the same I get with the brcmfmac driver). The firmware version reported
> is:
>
> # wl ver
> 1.107 RC5.0
> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>
> So, probably something is missing in the newer Kernel version, which is
> present in the legacy Kernel 2.6.35.
>
> [1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> imx_2.6.35_1.1.0
> [2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> imx_4.1.15_1.0.0_ga
during implementation of DDR mode for the mmc driver [1] i noticed a performance
gap between the vendor kernel and mainline by a factor of 2. I expect that your
wireless interface is connected via SDIO.
Stefan
[1] -
http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014081349.1afb22c6@ipc1.ka-ro>
On Fri, 2016-10-14 at 08:13 +0200, Lothar Wa?mann wrote:
> Hi,
>
> On Thu, 13 Oct 2016 21:43:00 +0200 J?rg Krause wrote:
> > Am 13. Oktober 2016 08:48:07 MESZ, schrieb "Lothar Wa?mann" <LW@KAR
> > O-electronics.de>:
> > > On Thu, 13 Oct 2016 01:09:13 +0200 J?rg Krause wrote:
>
> [...]
> > > This is the iperf output on a TX28 with current mainline kernel
> > > (4.8.0-rc5):
> > > ------------------------------------------------------------
> > > Client connecting to 192.168.100.1, TCP port 5001
> > > TCP window size: 43.8 KByte (default)
> > > ------------------------------------------------------------
> > > [??3] local 192.168.100.56 port 60325 connected with
> > > 192.168.100.1 port
> > > 5001
> > > [ ID] Interval???????Transfer?????Bandwidth
> > > [??3]??0.0-10.0 sec??57.5 MBytes??48.2 Mbits/sec
> > >
> > > You might check your kernel DEBUG configs (especially
> > > CONFIG_DEBUG_PAGEALLOC).
> >
> > Thanks for sharing the iperf output. What LAN transceiver does the
> > TX28 has assembled?
> >
>
> The ethernet PHY is an SMSC LAN8710A.
Thanks!
For the record:
Note, this is the result for the wireless interface.
I got one of my custom boards running the legacy Linux Kernel 2.6.35
officially supported from Freescale (NXP) and the bcmdhd driver from
the Wiced project, where I get >20Mbps TCP throughput. The firmware
version reported is:
# wl ver
5.90 RC115.2
wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
I got it also running with the Linux Kernel 4.1.15 from Freescale [2],
which is not officially supported for the i.MX28 target, with the
latest bcmdhd version where I get <7Mbps TCP throughput (which is much
the same I get with the brcmfmac driver). The firmware version reported
is:
# wl ver
1.107 RC5.0
wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
So, probably something is missing in the newer Kernel version, which is
present in the legacy Kernel 2.6.35.
[1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
imx_2.6.35_1.1.0
[2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
imx_4.1.15_1.0.0_ga
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Stefan Wahren @ 2016-10-15 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013070535.GA23147@kroah.com>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> 09:05 geschrieben:
>
>
> On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > The driver builds now.
> >
> > Signed-off-by: Eric Anholt <eric@anholt.net>
> > ---
> > drivers/staging/vc04_services/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/vc04_services/Kconfig
> > b/drivers/staging/vc04_services/Kconfig
> > index 9676fb29075a..db8e1beb89f9 100644
> > --- a/drivers/staging/vc04_services/Kconfig
> > +++ b/drivers/staging/vc04_services/Kconfig
> > @@ -1,6 +1,6 @@
> > config BCM2708_VCHIQ
> > tristate "Videocore VCHIQ"
> > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > + depends on RASPBERRYPI_FIRMWARE
> > default y
> > help
> > Kernel to VideoCore communication interface for the
>
> I've dropped this patch from my branch as there are build errors on
> arm64 systems still, and we don't want regressions like that.
>
> I've forwarded you the error messages, and I'll be glad to add this
> patch back once these issues are fixed.
I ask the author of this downstream pull request [1] to send the VHCIQ part as
indiviual patches.
He is interested to submit them upstream.
[1] - https://github.com/raspberrypi/linux/pull/1611
>
> thanks,
>
> greg k-h
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply
* [arm-soc:to-build 23/23] arch/sh/kernel/cpu/clock.c:25:6: warning: 'ret' may be used uninitialized in this function
From: kbuild test robot @ 2016-10-15 8:12 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 0f460ef4d0b0e50f64b03962048dec6fa1d40d20
commit: 0f460ef4d0b0e50f64b03962048dec6fa1d40d20 [23/23] Revert "Disable "maybe-uninitialized" warning globally"
config: sh-allmodconfig (attached as .config)
compiler: sh4-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
git checkout 0f460ef4d0b0e50f64b03962048dec6fa1d40d20
# save the attached .config to linux build tree
make.cross ARCH=sh
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
arch/sh/kernel/cpu/clock.c: In function 'clk_init':
>> arch/sh/kernel/cpu/clock.c:25:6: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
int ret;
^~~
vim +/ret +25 arch/sh/kernel/cpu/clock.c
36ddf31b6 Paul Mundt 2006-01-16 9 * Written by Tuukka Tikkanen <tuukka.tikkanen@elektrobit.com>
36ddf31b6 Paul Mundt 2006-01-16 10 *
1d118562c Paul Mundt 2006-12-01 11 * Modified for omap shared clock framework by Tony Lindgren <tony@atomide.com>
1d118562c Paul Mundt 2006-12-01 12 *
36ddf31b6 Paul Mundt 2006-01-16 13 * This file is subject to the terms and conditions of the GNU General Public
36ddf31b6 Paul Mundt 2006-01-16 14 * License. See the file "COPYING" in the main directory of this archive
36ddf31b6 Paul Mundt 2006-01-16 15 * for more details.
36ddf31b6 Paul Mundt 2006-01-16 16 */
36ddf31b6 Paul Mundt 2006-01-16 17 #include <linux/kernel.h>
36ddf31b6 Paul Mundt 2006-01-16 18 #include <linux/init.h>
51a5006af Paul Mundt 2010-03-08 19 #include <linux/clk.h>
36ddf31b6 Paul Mundt 2006-01-16 20 #include <asm/clock.h>
253b0887b Paul Mundt 2009-05-13 21 #include <asm/machvec.h>
36ddf31b6 Paul Mundt 2006-01-16 22
36ddf31b6 Paul Mundt 2006-01-16 23 int __init clk_init(void)
36ddf31b6 Paul Mundt 2006-01-16 24 {
253b0887b Paul Mundt 2009-05-13 @25 int ret;
36ddf31b6 Paul Mundt 2006-01-16 26
15f0c8f2f Rich Felker 2016-07-31 27 #ifndef CONFIG_COMMON_CLK
253b0887b Paul Mundt 2009-05-13 28 ret = arch_clk_init();
253b0887b Paul Mundt 2009-05-13 29 if (unlikely(ret)) {
253b0887b Paul Mundt 2009-05-13 30 pr_err("%s: CPU clock registration failed.\n", __func__);
253b0887b Paul Mundt 2009-05-13 31 return ret;
36ddf31b6 Paul Mundt 2006-01-16 32 }
15f0c8f2f Rich Felker 2016-07-31 33 #endif
:::::: The code at line 25 was first introduced by commit
:::::: 253b0887b3736160feac9ccdcf146a2073e41463 sh: clkfwk: Rework legacy CPG clock handling.
:::::: TO: Paul Mundt <lethal@linux-sh.org>
:::::: CC: Paul Mundt <lethal@linux-sh.org>
---
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: 42098 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161015/dd2d2730/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/4] ARM: bcm2835: Add #define for VCHIQ property message.
From: Stefan Wahren @ 2016-10-15 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <487621239.358635.2bd73c71-f221-4323-833d-b752e7c41a53.open-xchange@email.1und1.de>
> Stefan Wahren <stefan.wahren@i2se.com> hat am 15. Oktober 2016 um 09:53
> geschrieben:
>
>
> Hi Greg,
>
> > Eric Anholt <eric@anholt.net> hat am 3. Oktober 2016 um 20:52 geschrieben:
> >
> >
> > This comes from the downstream tree and is needed for the new VCHIQ
> > driver in staging.
>
> maybe it's not clear from the commit message, but RPI_FIRMWARE_VCHIQ_INIT is
> already used in
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>
> So this patch fixes also a build issue.
>
Sorry about the noise. You already applied it.
^ permalink raw reply
* [PATCH 3/4] ARM: bcm2835: Add #define for VCHIQ property message.
From: Stefan Wahren @ 2016-10-15 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003185209.27733-4-eric@anholt.net>
Hi Greg,
> Eric Anholt <eric@anholt.net> hat am 3. Oktober 2016 um 20:52 geschrieben:
>
>
> This comes from the downstream tree and is needed for the new VCHIQ
> driver in staging.
maybe it's not clear from the commit message, but RPI_FIRMWARE_VCHIQ_INIT is
already used in
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
So this patch fixes also a build issue.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
> b/include/soc/bcm2835/raspberrypi-firmware.h
> index 3fb357193f09..a06baffdf580 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -109,6 +109,8 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_FRAMEBUFFER_SET_OVERSCAN = 0x0004800a,
> RPI_FIRMWARE_FRAMEBUFFER_SET_PALETTE = 0x0004800b,
>
> + RPI_FIRMWARE_VCHIQ_INIT = 0x00048010,
> +
> RPI_FIRMWARE_GET_COMMAND_LINE = 0x00050001,
> RPI_FIRMWARE_GET_DMA_CHANNELS = 0x00060001,
> };
> --
> 2.9.3
>
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply
* [PATCH V3 3/3] ACPI,PCI,IRQ: correct SCI penalty calculation
From: Sinan Kaya @ 2016-10-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-1-git-send-email-okaya@codeaurora.org>
It seems like the problem is that we removed acpi_penalize_sci_irq(),
which told us the polarity and trigger mode. We tried to get that
information via irq_get_trigger_type(), but that didn't work in this
case because we use the acpi_irq_get_penalty() path before the SCI is
registered.
To fix this problem, we only need to fix the penalty for the SCI interrupt.
It seems better to add a single "sci_penalty" variable, set it to
PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
otherwise, and add "sci_penalty" in when appropriate. That should fix it
for *any* SCI IRQ, not just those less than 256, and we don't have to add
these extra penalty table entries that are all unused (except possibly for
one entry if we have an SCI in the 16-255 range).
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/pci_link.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 1934e2a..34bf527 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -87,6 +87,7 @@ struct acpi_pci_link {
static LIST_HEAD(acpi_link_list);
static DEFINE_MUTEX(acpi_link_lock);
+static int sci_irq = -1, sci_penalty;
/* --------------------------------------------------------------------------
PCI Link Device Management
@@ -494,10 +495,15 @@ static int acpi_irq_pci_sharing_penalty(int irq)
static int acpi_irq_get_penalty(int irq)
{
+ int penalty = 0;
+
+ if (irq == sci_irq)
+ penalty += sci_penalty;
+
if (irq < ACPI_MAX_ISA_IRQS)
- return acpi_isa_irq_penalty[irq];
+ return penalty + acpi_isa_irq_penalty[irq];
- return acpi_irq_pci_sharing_penalty(irq);
+ return penalty + acpi_irq_pci_sharing_penalty(irq);
}
int __init acpi_irq_penalty_init(void)
@@ -870,13 +876,13 @@ bool acpi_isa_irq_available(int irq)
void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
{
- if (irq >= 0 && irq < ARRAY_SIZE(acpi_isa_irq_penalty)) {
- if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
- polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
- acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
- else
- acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
- }
+ sci_irq = irq;
+
+ if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
+ polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
+ sci_penalty = PIRQ_PENALTY_PCI_USING;
+ else
+ sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
}
/*
--
1.9.1
^ permalink raw reply related
* [PATCH V3 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-1-git-send-email-okaya@codeaurora.org>
The SCI function was removed in two steps (first refactor and then remove).
This patch does the revert in one step.
The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
refactored the original code so that SCI penalty is calculated dynamically
by the time get_penalty function is called. This patch does a partial
revert for the SCI functionality only.
The commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function") is
for the removal of the function. SCI penalty API was replaced by the
runtime penalty calculation based on the value of
acpi_gbl_FADT.sci_interrupt.
The IRQ 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.
The register_gsi function delivers the IRQ found in the ACPI table to
the interrupt controller driver. Penalties are calculated before a
link object is enabled to find out which interrupt has the least number
of users. By the time penalties are calculated, the IRQ is not registered
yet and the API returns the wrong type.
Tested-by: Jonathan Liu <net147@gmail.com>
Tested-by: Ondrej Zary <linux@rainbow-software.org>
Link: https://lkml.org/lkml/2016/10/4/283
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 32 +++++++++++++-------------------
include/linux/acpi.h | 1 +
3 files changed, 15 insertions(+), 19 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 a212709..1934e2a 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -494,27 +494,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_isa_irq_penalty[irq];
+ return acpi_isa_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)
@@ -885,6 +868,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_isa_irq_penalty)) {
+ if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
+ polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
+ acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
+ else
+ acpi_isa_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 c5eaf2f..67d1d3e 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);
--
1.9.1
^ permalink raw reply related
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-1-git-send-email-okaya@codeaurora.org>
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 interrupts greater than 16.
The array size has been reduced to 16 and array name got prefixed as ISA
since it only is accountable for the ISA interrupts.
The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
resource requirements") removed penalty assignment in the code for PCI
thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
function.
However, this function only gets called if the IRQ number is greater than
16 and acpi_irq_get_penalty function gets called before ACPI start in
acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
on iterating the link list.
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 c983bf7..a212709 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -619,6 +619,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_ISA_IRQS)
+ acpi_isa_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);
--
1.9.1
^ permalink raw reply related
* [PATCH V3 0/3] ACPI, PCI, IRQ: revert penalty calculation for ISA and SCI interrupts
From: Sinan Kaya @ 2016-10-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
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 reverted changes were in the direction to remove these external API and
try to calculate the penalties at runtime for the ISA, SCI as well as PCI
IRQS. This didn't work out well with the existing platforms.
V3:
* drop patch #1 as discussed with Bjorn
* add patch #3 to track SCI irq and penalty separately
V2: https://lkml.org/lkml/2016/10/1/106
* Commit message updates
V1:
http://lists-archives.com/linux-kernel/28673954-revert-acpi-pci-irq-reduce-static-irq-array-size-to-16.html
* initial implementation
Sinan Kaya (3):
ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
Revert "ACPI,PCI,IRQ: remove SCI penalize function"
ACPI,PCI,IRQ: correct SCI penalty calculation
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 34 +++++++++++++++++++---------------
include/linux/acpi.h | 1 +
3 files changed, 21 insertions(+), 15 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V2 1/3] Revert "ACPI, PCI, IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-15 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09f93442-89c8-7b2c-467d-d29b857739ff@codeaurora.org>
On 10/12/2016 6:46 PM, Sinan Kaya wrote:
>> Which API are you thinking about here? pcibios_penalize_isa_irq() is
>> > called by ACPI and PNP, which should both be after ACPI is started.
> Correct, I was talking about acpi_penalize_sci_irq function here.
>
Now that I'm looking at the code. There are two more functions that get
called before ACPI start.
These are acpi_isa_irq_available and acpi_penalize_isa_irq functions.
We can't rely on iterating the link list.
--
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 V3 10/10] arm64: KVM: add guest SEA support
From: Baicar, Tyler @ 2016-10-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878ttrs22f.fsf@e105922-lin.cambridge.arm.com>
On 10/14/2016 2:38 AM, Punit Agrawal wrote:
> "Baicar, Tyler" <tbaicar@codeaurora.org> writes:
>
>> Hello Punit,
>>
>> On 10/13/2016 7:14 AM, Punit Agrawal wrote:
>>> Hi Tyler,
>>>
>>> I know I've had my last comment already ;), but I thought I'd rather
>>> raise the question than stay confused...
>>>
>>> Tyler Baicar <tbaicar@codeaurora.org> writes:
>>>
>>>> Currently external aborts are unsupported by the guest abort
>>>> handling. Add handling for SEAs so that the host kernel reports
>>>> SEAs which occur in the guest kernel.
>>>>
>>>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>>>> ---
>>>> arch/arm/include/asm/kvm_arm.h | 1 +
>>>> arch/arm/include/asm/system_misc.h | 5 +++++
>>>> arch/arm/kvm/mmu.c | 15 +++++++++++++--
>>>> arch/arm64/include/asm/kvm_arm.h | 1 +
>>>> arch/arm64/include/asm/system_misc.h | 2 ++
>>>> arch/arm64/mm/fault.c | 13 +++++++++++++
>>>> 6 files changed, 35 insertions(+), 2 deletions(-)
[...]
>>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>>> index 81cb7ad..d714432 100644
>>>> --- a/arch/arm64/mm/fault.c
>>>> +++ b/arch/arm64/mm/fault.c
>>>> @@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
>>>> }
>>>> /*
>>>> + * Handle Synchronous External Aborts that occur in a guest kernel.
>>>> + */
>>>> +int handle_guest_sea(unsigned long addr, unsigned int esr)
>>>> +{
>>>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>>>> +
>>>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>>>> + fault_name(esr), esr, addr);
>>>> +
>>>> + return 0;
>>>> +}
>>> Don't we need to pass the abort to the guest?
>> This requires some infrastructure to implement virtual "ACPI platform
>> error interface" to expose the details of the abort to the guest. This
>> patchset does not cover that and focuses on feature parity with other
>> architectures that support APEI. There are discussions among Linaro
>> partners about how this can be achieved in the long term, but that
>> work is outside the scope of this patchset. This patch will ensure
>> that if a guest encounters one of these errors then it will be
>> reported before getting killed. Before this patch we would just get an
>> unsupported FSC print out and then the guest would be killed.
> OK.
>
> I think we might be talking about different things though.
>
> I am referring to the injection of the synchronous external abort into
> the guest - similar to what's been done for prefetch abort in the
> kvm_guest_handle_abort.
>
> Maybe there is no benefit in passing the abort to the guest. In that
> case, can you please add a comment where you handle external abort
> (FSC_EXTABT) in kvm_guest_handle_abort.
Yes, I will add a comment there in the next version.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Kees Cook @ 2016-10-14 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-1-git-send-email-catalin.marinas@arm.com>
Hi,
Just checking in on this feature -- I don't see it in -next nor
already in the tree. Is there any chance this is going to make the
v4.9 merge window?
It didn't sound like there were any unresolved issues remaining?
Thanks!
-Kees
On Tue, Sep 13, 2016 at 10:46 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> This is the third version of the arm64 PAN emulation using TTBR0_EL1
> switching. The series has not yet included the alternative nop patches
> from Mark Rutland, nor the empty_zero_page from Ard B. This will be done
> in a subsequent version once 4.9-rc1 is out (which will include Mark's
> alternative nop patches).
>
> Changes since v2:
>
> - efi_set_pgd() reworked to update the saved ttbr0 during run-time
> services as this value is used during exception return
>
> - uaccess_(enable|disable) C macros no longer take an 'alt' parameter
> Instead, uaccess_(enable|disable)_not_uao are introduced for the case
> where hardware PAN switching is not required when UAO is present
>
> - post_ttbr0_update_workaround macro no longer takes a 'ret' parameter
>
> - system_supports_ttbr0_pan renamed to system_uses_ttbr0_pan
>
> - init_thread_info.ttbr0 moved towards the end of the setup_arch()
> function and comment updated
>
> - vmlinux.lds.S fixed to use RESERVED_TTBR0_SIZE
>
> - Config option changed to ARM64_SW_TTBR0_PAN
>
> - Some comment clean-ups and commit log updates
>
> Catalin Marinas (7):
> arm64: Factor out PAN enabling/disabling into separate uaccess_*
> macros
> arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm
> macro
> arm64: Introduce uaccess_{disable,enable} functionality based on
> TTBR0_EL1
> arm64: Disable TTBR0_EL1 during normal kernel execution
> arm64: Handle faults caused by inadvertent user access with PAN
> enabled
> arm64: xen: Enable user access before a privcmd hvc call
> arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN
>
> The patches are also available on this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux ttbr0-pan
>
> Thanks for reviewing/testing.
>
> arch/arm64/Kconfig | 8 ++
> arch/arm64/include/asm/assembler.h | 33 +++++++
> arch/arm64/include/asm/cpufeature.h | 6 ++
> arch/arm64/include/asm/efi.h | 26 ++++-
> arch/arm64/include/asm/futex.h | 14 +--
> arch/arm64/include/asm/kernel-pgtable.h | 7 ++
> arch/arm64/include/asm/mmu_context.h | 51 +++++++---
> arch/arm64/include/asm/ptrace.h | 2 +
> arch/arm64/include/asm/thread_info.h | 3 +
> arch/arm64/include/asm/uaccess.h | 163 ++++++++++++++++++++++++++++++--
> arch/arm64/kernel/armv8_deprecated.c | 10 +-
> arch/arm64/kernel/asm-offsets.c | 3 +
> arch/arm64/kernel/cpufeature.c | 1 +
> arch/arm64/kernel/entry.S | 71 +++++++++++++-
> arch/arm64/kernel/head.S | 6 +-
> arch/arm64/kernel/setup.c | 9 ++
> arch/arm64/kernel/vmlinux.lds.S | 5 +
> arch/arm64/lib/clear_user.S | 8 +-
> arch/arm64/lib/copy_from_user.S | 8 +-
> arch/arm64/lib/copy_in_user.S | 8 +-
> arch/arm64/lib/copy_to_user.S | 8 +-
> arch/arm64/mm/context.c | 7 +-
> arch/arm64/mm/fault.c | 22 +++--
> arch/arm64/mm/proc.S | 11 +--
> arch/arm64/xen/hypercall.S | 19 ++++
> 25 files changed, 428 insertions(+), 81 deletions(-)
>
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH v3 1/2] devicetree: Add vendor prefix for Rikomagic
From: Rob Herring @ 2016-10-14 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7746988.aAT8rmUZDV@phil>
On Fri, Oct 14, 2016 at 1:21 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Samstag, 8. Oktober 2016, 22:22:05 CEST schrieb Pawe? Jarosz:
>> Add Rikomagic to vendor-prefixes.txt
>>
>> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
>> ---
>>
>> Changes in v2:
>> - none
>>
>> Changes in v3:
>> - none
>>
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
>> 69caf14..3edfa08 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
>> renesas Renesas Electronics Corporation
>> richtek Richtek Technology Corporation
>> ricoh Ricoh Co. Ltd.
>> +rikomagic Rikomagic
> ^ Rikomagic Tech Corp. Ltd
>
> (according to http://www.rikomagic.com/en/index.html)
>
> But I can change that myself. I'll just need to wait a bit more if Rob or Mark
> want to Ack this vendor-prefix addition.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 28/57] [media] c8sectpfe: don't break long lines
From: Mauro Carvalho Chehab @ 2016-10-14 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476475770.git.mchehab@s-opensource.com>
Due to the 80-cols checkpatch warnings, several strings
were broken into multiple lines. This is not considered
a good practice anymore, as it makes harder to grep for
strings at the source code. So, join those continuation
lines.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index 30c148b9d65e..7a2c8fdfbe51 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -112,8 +112,7 @@ static void channel_swdemux_tsklet(unsigned long data)
buf = (u8 *) channel->back_buffer_aligned;
dev_dbg(fei->dev,
- "chan=%d channel=%p num_packets = %d, buf = %p, pos = 0x%x\n\t"
- "rp=0x%lx, wp=0x%lx\n",
+ "chan=%d channel=%p num_packets = %d, buf = %p, pos = 0x%x\n\trp=0x%lx, wp=0x%lx\n",
channel->tsin_id, channel, num_packets, buf, pos, rp, wp);
for (n = 0; n < num_packets; n++) {
@@ -789,8 +788,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
/* sanity check value */
if (tsin->tsin_id > fei->hw_stats.num_ib) {
dev_err(&pdev->dev,
- "tsin-num %d specified greater than number\n\t"
- "of input block hw in SoC! (%d)",
+ "tsin-num %d specified greater than number\n\tof input block hw in SoC! (%d)",
tsin->tsin_id, fei->hw_stats.num_ib);
ret = -EINVAL;
goto err_clk_disable;
@@ -855,8 +853,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
tsin->demux_mapping = index;
dev_dbg(fei->dev,
- "channel=%p n=%d tsin_num=%d, invert-ts-clk=%d\n\t"
- "serial-not-parallel=%d pkt-clk-valid=%d dvb-card=%d\n",
+ "channel=%p n=%d tsin_num=%d, invert-ts-clk=%d\n\tserial-not-parallel=%d pkt-clk-valid=%d dvb-card=%d\n",
fei->channel_data[index], index,
tsin->tsin_id, tsin->invert_ts_clk,
tsin->serial_not_parallel, tsin->async_not_sync,
@@ -1045,8 +1042,7 @@ static void load_imem_segment(struct c8sectpfei *fei, Elf32_Phdr *phdr,
*/
dev_dbg(fei->dev,
- "Loading IMEM segment %d 0x%08x\n\t"
- " (0x%x bytes) -> 0x%p (0x%x bytes)\n", seg_num,
+ "Loading IMEM segment %d 0x%08x\n\t (0x%x bytes) -> 0x%p (0x%x bytes)\n", seg_num,
phdr->p_paddr, phdr->p_filesz,
dest, phdr->p_memsz + phdr->p_memsz / 3);
@@ -1075,8 +1071,7 @@ static void load_dmem_segment(struct c8sectpfei *fei, Elf32_Phdr *phdr,
*/
dev_dbg(fei->dev,
- "Loading DMEM segment %d 0x%08x\n\t"
- "(0x%x bytes) -> 0x%p (0x%x bytes)\n",
+ "Loading DMEM segment %d 0x%08x\n\t(0x%x bytes) -> 0x%p (0x%x bytes)\n",
seg_num, phdr->p_paddr, phdr->p_filesz,
dst, phdr->p_memsz);
--
2.7.4
^ permalink raw reply related
* [PATCH 27/57] [media] s5p-mfc: don't break long lines
From: Mauro Carvalho Chehab @ 2016-10-14 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476475770.git.mchehab@s-opensource.com>
Due to the 80-cols checkpatch warnings, several strings
were broken into multiple lines. This is not considered
a good practice anymore, as it makes harder to grep for
strings at the source code. So, join those continuation
lines.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 6 ++----
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 7 ++-----
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 52081ddc9bf2..c0e464dcc7d0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -793,8 +793,7 @@ static int vidioc_g_crop(struct file *file, void *priv,
cr->c.top = top;
cr->c.width = ctx->img_width - left - right;
cr->c.height = ctx->img_height - top - bottom;
- mfc_debug(2, "Cropping info [h264]: l=%d t=%d "
- "w=%d h=%d (r=%d b=%d fw=%d fh=%d\n", left, top,
+ mfc_debug(2, "Cropping info [h264]: l=%d t=%d w=%d h=%d (r=%d b=%d fw=%d fh=%d\n", left, top,
cr->c.width, cr->c.height, right, bottom,
ctx->buf_width, ctx->buf_height);
} else {
@@ -802,8 +801,7 @@ static int vidioc_g_crop(struct file *file, void *priv,
cr->c.top = 0;
cr->c.width = ctx->img_width;
cr->c.height = ctx->img_height;
- mfc_debug(2, "Cropping info: w=%d h=%d fw=%d "
- "fh=%d\n", cr->c.width, cr->c.height, ctx->buf_width,
+ mfc_debug(2, "Cropping info: w=%d h=%d fw=%d fh=%d\n", cr->c.width, cr->c.height, ctx->buf_width,
ctx->buf_height);
}
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 81e1e4ce6c24..f4301d5bbd32 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1293,14 +1293,11 @@ static int s5p_mfc_run_init_dec_buffers(struct s5p_mfc_ctx *ctx)
* First set the output frame buffers
*/
if (ctx->capture_state != QUEUE_BUFS_MMAPED) {
- mfc_err("It seems that not all destionation buffers were "
- "mmaped\nMFC requires that all destination are mmaped "
- "before starting processing\n");
+ mfc_err("It seems that not all destionation buffers were mmaped\nMFC requires that all destination are mmaped before starting processing\n");
return -EAGAIN;
}
if (list_empty(&ctx->src_queue)) {
- mfc_err("Header has been deallocated in the middle of"
- " initialization\n");
+ mfc_err("Header has been deallocated in the middle of initialization\n");
return -EIO;
}
temp_vb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
--
2.7.4
^ permalink raw reply related
* [PATCH 23/57] [media] exynos4-is: don't break long lines
From: Mauro Carvalho Chehab @ 2016-10-14 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476475770.git.mchehab@s-opensource.com>
Due to the 80-cols checkpatch warnings, several strings
were broken into multiple lines. This is not considered
a good practice anymore, as it makes harder to grep for
strings at the source code. So, join those continuation
lines.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/exynos4-is/media-dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 1a1154a9dfa4..e3a8709138fa 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -938,8 +938,7 @@ static int fimc_md_create_links(struct fimc_md *fmd)
csis = fmd->csis[pdata->mux_id].sd;
if (WARN(csis == NULL,
- "MIPI-CSI interface specified "
- "but s5p-csis module is not loaded!\n"))
+ "MIPI-CSI interface specified but s5p-csis module is not loaded!\n"))
return -EINVAL;
pad = sensor->entity.num_pads - 1;
--
2.7.4
^ 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