* Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity
From: Christoph Hellwig @ 2016-11-08 22:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, tglx, axboe, linux-block, linux-pci,
linux-kernel
In-Reply-To: <20161108212526.GF14322@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Nov 08, 2016 at 03:25:27PM -0600, Bjorn Helgaas wrote:
> What tree would you prefer? I vote for the IRQ tree since that seems
> to be where the interesting parts are, and I think I acked all the PCI
> bits.
Yes, that would be my preference to.
>
> > + * struct irq_affinity - Description for auto irq affinity assignements
> > + * @pre_vectors: Reserved vectors at the beginning of the MSIX
> > + * vector space
> > + * @post_vectors: Reserved vectors at the end of the MSIX
> > + * vector space
>
> Maybe include something more informative than just "reserved", e.g.,
> "Don't apply affinity to @pre_vectors at beginning of MSI-X vector
> space" or "Vectors at beginning of MSI-X vector space that are exempt
> from affinity"?
Sure.
^ permalink raw reply
* [GIT PULL] pxa-dt for v4.10
From: Robert Jarzmik @ 2016-11-08 22:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof,
This is the pxa pull request for 4.10 device-tree, can you please consider
pulling ?
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/rjarzmik/linux.git tags/pxa-dt-4.10
for you to fetch changes up to f409d2f134d499354dca0613693f27d8efd75c74:
ARM: dts: pxa: add pxa27x cpu operating points (2016-11-02 22:52:45 +0100)
----------------------------------------------------------------
This device-tree pxa update brings :
- pxa25x support
- cpu operating points in preparation for cpufreq-dt
- small fixes
----------------------------------------------------------------
Robert Jarzmik (4):
ARM: dts: add pxa25x .dtsi file
ARM: dts: pxa: fix gpio0 and gpio1 interrupts
ARM: dts: pxa: add pxa25x cpu operating points
ARM: dts: pxa: add pxa27x cpu operating points
Vijay Kumar (1):
Fix no. of gpio cells in the pxa gpio binding doucmentation
.../devicetree/bindings/gpio/mrvl-gpio.txt | 6 +-
arch/arm/boot/dts/pxa25x.dtsi | 117 +++++++++++++++++++++
arch/arm/boot/dts/pxa27x.dtsi | 40 +++++++
arch/arm/boot/dts/pxa2xx.dtsi | 4 +-
4 files changed, 163 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/pxa25x.dtsi
--
Robert
^ permalink raw reply
* [Buildroot] [PATCH master 3/3] MIPS: rename M6201 core to M6250
From: Arnout Vandecappelle @ 2016-11-08 22:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161108103258.32196-3-Vincent.Riera@imgtec.com>
On 08-11-16 11:32, Vicente Olivert Riera wrote:
> m6201 is the -march option for GCC, but the real core name is
> M6250.
>
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> arch/Config.in.mips | 6 +++---
> package/gcc/Config.in.host | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
> index f407d9a..c14a133 100644
> --- a/arch/Config.in.mips
> +++ b/arch/Config.in.mips
> @@ -51,8 +51,8 @@ config BR2_mips_m5150
> bool "M5150"
> depends on !BR2_ARCH_IS_64
> select BR2_MIPS_CPU_MIPS32R5
> -config BR2_mips_m6201
> - bool "M6201"
> +config BR2_mips_m6250
> + bool "M6250"
> depends on !BR2_ARCH_IS_64
> select BR2_MIPS_CPU_MIPS32R6
> config BR2_mips_p5600
> @@ -130,7 +130,7 @@ config BR2_GCC_TARGET_ARCH
> default "mips32r6" if BR2_mips_32r6
> default "interaptiv" if BR2_mips_interaptiv
> default "m5101" if BR2_mips_m5150
> - default "m6201" if BR2_mips_m6201
> + default "m6201" if BR2_mips_m6250
> default "p5600" if BR2_mips_p5600
> default "mips64" if BR2_mips_64
> default "mips64r2" if BR2_mips_64r2
> diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
> index eb1479a..0a63e6a 100644
> --- a/package/gcc/Config.in.host
> +++ b/package/gcc/Config.in.host
> @@ -65,7 +65,7 @@ choice
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
> # Unsupported MIPS cores
> depends on !BR2_mips_interaptiv && !BR2_mips_m5150 && \
> - !BR2_mips_m6201 && !BR2_mips_i6400 && !BR2_mips_p6600
> + !BR2_mips_m6250 && !BR2_mips_i6400 && !BR2_mips_p6600
> # musl mips64 unsupported
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_mips64 || BR2_mips64el))
> select BR2_TOOLCHAIN_GCC_AT_LEAST_5
> @@ -76,7 +76,7 @@ choice
> depends on !BR2_arc
> depends on !BR2_microblaze
> # Unsupported MIPS cores
> - depends on !BR2_mips_m6201 && !BR2_mips_p6600
> + depends on !BR2_mips_m6250 && !BR2_mips_p6600
> select BR2_TOOLCHAIN_GCC_AT_LEAST_6
>
> endchoice
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* [Buildroot] [PATCH master 2/3] MIPS: rename M5101 core to M5150
From: Arnout Vandecappelle @ 2016-11-08 22:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161108103258.32196-2-Vincent.Riera@imgtec.com>
On 08-11-16 11:32, Vicente Olivert Riera wrote:
> m5101 is the -march option for GCC, but the real core name is M5150.
>
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> arch/Config.in.mips | 6 +++---
> package/gcc/Config.in.host | 2 +-
> toolchain/toolchain-external/Config.in | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
> index 289e35d..f407d9a 100644
> --- a/arch/Config.in.mips
> +++ b/arch/Config.in.mips
> @@ -47,8 +47,8 @@ config BR2_mips_interaptiv
> bool "interAptiv"
> depends on !BR2_ARCH_IS_64
> select BR2_MIPS_CPU_MIPS32R2
> -config BR2_mips_m5101
> - bool "M5101"
> +config BR2_mips_m5150
> + bool "M5150"
> depends on !BR2_ARCH_IS_64
> select BR2_MIPS_CPU_MIPS32R5
> config BR2_mips_m6201
> @@ -129,7 +129,7 @@ config BR2_GCC_TARGET_ARCH
> default "mips32r5" if BR2_mips_32r5
> default "mips32r6" if BR2_mips_32r6
> default "interaptiv" if BR2_mips_interaptiv
> - default "m5101" if BR2_mips_m5101
> + default "m5101" if BR2_mips_m5150
> default "m6201" if BR2_mips_m6201
> default "p5600" if BR2_mips_p5600
> default "mips64" if BR2_mips_64
> diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
> index f46656c..eb1479a 100644
> --- a/package/gcc/Config.in.host
> +++ b/package/gcc/Config.in.host
> @@ -64,7 +64,7 @@ choice
> # musl ppc64 unsupported
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
> # Unsupported MIPS cores
> - depends on !BR2_mips_interaptiv && !BR2_mips_m5101 && \
> + depends on !BR2_mips_interaptiv && !BR2_mips_m5150 && \
> !BR2_mips_m6201 && !BR2_mips_i6400 && !BR2_mips_p6600
> # musl mips64 unsupported
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_mips64 || BR2_mips64el))
> diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
> index 22f760b..476b37b 100644
> --- a/toolchain/toolchain-external/Config.in
> +++ b/toolchain/toolchain-external/Config.in
> @@ -530,7 +530,7 @@ config BR2_TOOLCHAIN_EXTERNAL_MUSL_CROSS
> BR2_x86_64
> depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
> # Unsupported MIPS cores
> - depends on !BR2_mips_interaptiv && !BR2_mips_m5101
> + depends on !BR2_mips_interaptiv && !BR2_mips_m5150
> # Unsupported for MIPS R6
> depends on !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
> select BR2_TOOLCHAIN_EXTERNAL_MUSL
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v11 00/12] PCI bus support
From: Paolo Bonzini @ 2016-11-08 22:25 UTC (permalink / raw)
To: Andrew Jones, Alexander Gordeev; +Cc: kvm, Thomas Huth, Peter Xu
In-Reply-To: <20161107115557.dpiir32x37cyvvnc@kamzik.brq.redhat.com>
On 07/11/2016 12:55, Andrew Jones wrote:
> On Mon, Nov 07, 2016 at 11:14:32AM +0100, Alexander Gordeev wrote:
>> This is 11th version of PCI support.
>>
>> Changes since v9:
>> - all PCI configuration space accessors added;
>> - data size in PCI configuration space accessors fixed;
>> - PCI bus parity checking enabled;
>> - coding style errors fixed;
>>
>> Sources are avalable at:
>> https://github.com/a-gordeev/kvm-unit-tests.git pci-testdev-v11
>>
>> Cc: Thomas Huth <thuth@redhat.com>
>> Cc: Andrew Jones <drjones@redhat.com>
>> Cc: Peter Xu <peterx@redhat.com>
>>
>> Alexander Gordeev (12):
>> pci: Fix coding style in generic PCI files
>> pci: x86: Rename pci_config_read() to pci_config_readl()
>> pci: Add 'extern' to public function declarations
>> pci: x86: Add remaining PCI configuration space accessors
>> pci: Factor out pci_bar_get()
>> pci: Rework pci_bar_addr()
>> pci: Add pci_bar_set_addr()
>> pci: Add pci_dev_exists()
>> pci: Add pci_print()
>> pci: Add generic ECAM host support
>> pci: Add pci-testdev PCI bus test device
>> arm/arm64: pci: Add pci-testdev PCI device operation test
>>
>
> All patches look good to me!
>
> Paolo, please merge this version (v11).
I haven't pushed yet, but I've applied it.
Paolo
^ permalink raw reply
* Re: [PATCH kernel v4 3/4] vfio/spapr: Reference mm in tce_container
From: Alex Williamson @ 2016-11-08 22:25 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linuxppc-dev, David Gibson, Nicholas Piggin, Paul Mackerras
In-Reply-To: <1477291990-2872-4-git-send-email-aik@ozlabs.ru>
On Mon, 24 Oct 2016 17:53:09 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> In some situations the userspace memory context may live longer than
> the userspace process itself so if we need to do proper memory context
> cleanup, we better have tce_container take a reference to mm_struct and
> use it later when the process is gone (@current or @current->mm is NULL).
>
> This references mm and stores the pointer in the container; this is done
> when a container is just created so checking for !current->mm in other
> places becomes pointless.
>
> This replaces current->mm with container->mm everywhere except debug
> prints.
>
> This adds a check that current->mm is the same as the one stored in
> the container to prevent userspace from making changes to a memory
> context of other processes; in order to add this check,
> VFIO_CHECK_EXTENSION is moved out of the switch(cmd) as it is
> quite special anyway - it is the only ioctl() called when neither
> container nor container->mm is initialized.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v4:
> * added check for container->mm!=current->mm in tce_iommu_ioctl()
> for all ioctls and removed other redundand checks
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 131 ++++++++++++++++++------------------
> 1 file changed, 66 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index d0c38b2..81ab93f 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -31,49 +31,46 @@
> static void tce_iommu_detach_group(void *iommu_data,
> struct iommu_group *iommu_group);
>
> -static long try_increment_locked_vm(long npages)
> +static long try_increment_locked_vm(struct mm_struct *mm, long npages)
> {
> long ret = 0, locked, lock_limit;
>
> - if (!current || !current->mm)
> - return -ESRCH; /* process exited */
> -
> if (!npages)
> return 0;
>
> - down_write(¤t->mm->mmap_sem);
> - locked = current->mm->locked_vm + npages;
> + down_write(&mm->mmap_sem);
> + locked = mm->locked_vm + npages;
> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> if (locked > lock_limit && !capable(CAP_IPC_LOCK))
> ret = -ENOMEM;
> else
> - current->mm->locked_vm += npages;
> + mm->locked_vm += npages;
>
> pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n", current->pid,
> npages << PAGE_SHIFT,
> - current->mm->locked_vm << PAGE_SHIFT,
> + mm->locked_vm << PAGE_SHIFT,
> rlimit(RLIMIT_MEMLOCK),
> ret ? " - exceeded" : "");
>
> - up_write(¤t->mm->mmap_sem);
> + up_write(&mm->mmap_sem);
>
> return ret;
> }
>
> -static void decrement_locked_vm(long npages)
> +static void decrement_locked_vm(struct mm_struct *mm, long npages)
> {
> - if (!current || !current->mm || !npages)
> - return; /* process exited */
> + if (!npages)
> + return;
>
> - down_write(¤t->mm->mmap_sem);
> - if (WARN_ON_ONCE(npages > current->mm->locked_vm))
> - npages = current->mm->locked_vm;
> - current->mm->locked_vm -= npages;
> + down_write(&mm->mmap_sem);
> + if (WARN_ON_ONCE(npages > mm->locked_vm))
> + npages = mm->locked_vm;
> + mm->locked_vm -= npages;
> pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n", current->pid,
> npages << PAGE_SHIFT,
> - current->mm->locked_vm << PAGE_SHIFT,
> + mm->locked_vm << PAGE_SHIFT,
> rlimit(RLIMIT_MEMLOCK));
> - up_write(¤t->mm->mmap_sem);
> + up_write(&mm->mmap_sem);
> }
>
> /*
> @@ -98,6 +95,7 @@ struct tce_container {
> bool enabled;
> bool v2;
> unsigned long locked_pages;
> + struct mm_struct *mm;
> struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
> struct list_head group_list;
> };
> @@ -107,17 +105,14 @@ static long tce_iommu_unregister_pages(struct tce_container *container,
> {
> struct mm_iommu_table_group_mem_t *mem;
>
> - if (!current || !current->mm)
> - return -ESRCH; /* process exited */
> -
> if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK))
> return -EINVAL;
>
> - mem = mm_iommu_find(current->mm, vaddr, size >> PAGE_SHIFT);
> + mem = mm_iommu_find(container->mm, vaddr, size >> PAGE_SHIFT);
> if (!mem)
> return -ENOENT;
>
> - return mm_iommu_put(current->mm, mem);
> + return mm_iommu_put(container->mm, mem);
> }
>
> static long tce_iommu_register_pages(struct tce_container *container,
> @@ -127,14 +122,11 @@ static long tce_iommu_register_pages(struct tce_container *container,
> struct mm_iommu_table_group_mem_t *mem = NULL;
> unsigned long entries = size >> PAGE_SHIFT;
>
> - if (!current || !current->mm)
> - return -ESRCH; /* process exited */
> -
> if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK) ||
> ((vaddr + size) < vaddr))
> return -EINVAL;
>
> - ret = mm_iommu_get(current->mm, vaddr, entries, &mem);
> + ret = mm_iommu_get(container->mm, vaddr, entries, &mem);
> if (ret)
> return ret;
>
> @@ -143,7 +135,8 @@ static long tce_iommu_register_pages(struct tce_container *container,
> return 0;
> }
>
> -static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
> +static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl,
> + struct mm_struct *mm)
> {
> unsigned long cb = _ALIGN_UP(sizeof(tbl->it_userspace[0]) *
> tbl->it_size, PAGE_SIZE);
> @@ -152,13 +145,13 @@ static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
>
> BUG_ON(tbl->it_userspace);
>
> - ret = try_increment_locked_vm(cb >> PAGE_SHIFT);
> + ret = try_increment_locked_vm(mm, cb >> PAGE_SHIFT);
> if (ret)
> return ret;
>
> uas = vzalloc(cb);
> if (!uas) {
> - decrement_locked_vm(cb >> PAGE_SHIFT);
> + decrement_locked_vm(mm, cb >> PAGE_SHIFT);
> return -ENOMEM;
> }
> tbl->it_userspace = uas;
> @@ -166,7 +159,8 @@ static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
> return 0;
> }
>
> -static void tce_iommu_userspace_view_free(struct iommu_table *tbl)
> +static void tce_iommu_userspace_view_free(struct iommu_table *tbl,
> + struct mm_struct *mm)
> {
> unsigned long cb = _ALIGN_UP(sizeof(tbl->it_userspace[0]) *
> tbl->it_size, PAGE_SIZE);
> @@ -176,7 +170,7 @@ static void tce_iommu_userspace_view_free(struct iommu_table *tbl)
>
> vfree(tbl->it_userspace);
> tbl->it_userspace = NULL;
> - decrement_locked_vm(cb >> PAGE_SHIFT);
> + decrement_locked_vm(mm, cb >> PAGE_SHIFT);
> }
>
> static bool tce_page_is_contained(struct page *page, unsigned page_shift)
> @@ -236,9 +230,6 @@ static int tce_iommu_enable(struct tce_container *container)
> struct iommu_table_group *table_group;
> struct tce_iommu_group *tcegrp;
>
> - if (!current->mm)
> - return -ESRCH; /* process exited */
> -
> if (container->enabled)
> return -EBUSY;
>
> @@ -284,7 +275,7 @@ static int tce_iommu_enable(struct tce_container *container)
> return -EPERM;
>
> locked = table_group->tce32_size >> PAGE_SHIFT;
> - ret = try_increment_locked_vm(locked);
> + ret = try_increment_locked_vm(container->mm, locked);
> if (ret)
> return ret;
>
> @@ -302,10 +293,7 @@ static void tce_iommu_disable(struct tce_container *container)
>
> container->enabled = false;
>
> - if (!current->mm)
> - return;
> -
> - decrement_locked_vm(container->locked_pages);
> + decrement_locked_vm(container->mm, container->locked_pages);
> }
>
> static void *tce_iommu_open(unsigned long arg)
> @@ -326,13 +314,18 @@ static void *tce_iommu_open(unsigned long arg)
>
> container->v2 = arg == VFIO_SPAPR_TCE_v2_IOMMU;
>
> + /* current->mm cannot be NULL in this context */
> + container->mm = current->mm;
> + atomic_inc(&container->mm->mm_count);
Are you sure you wouldn't rather do this on the actual
preregistration? The advise I gave to Kirti for mdev was that it's
currently possible to have a configuration where a privileged user
opens a container, adds a group, sets the iommu, and then passes the
file descriptors to another user. We can then set an mm once mappings,
or preregistration occurs, and from there require that the unmapping mm
matches the mapping mm, or that both of those match the preregistration
mm. I'm not sure I see any reason to impose that current->mm that
performs this operation is the only one that's allowed to perform those
later tasks.
> +
> return container;
> }
>
> static int tce_iommu_clear(struct tce_container *container,
> struct iommu_table *tbl,
> unsigned long entry, unsigned long pages);
> -static void tce_iommu_free_table(struct iommu_table *tbl);
> +static void tce_iommu_free_table(struct tce_container *container,
> + struct iommu_table *tbl);
>
> static void tce_iommu_release(void *iommu_data)
> {
> @@ -357,10 +350,11 @@ static void tce_iommu_release(void *iommu_data)
> continue;
>
> tce_iommu_clear(container, tbl, tbl->it_offset, tbl->it_size);
> - tce_iommu_free_table(tbl);
> + tce_iommu_free_table(container, tbl);
> }
>
> tce_iommu_disable(container);
> + mmdrop(container->mm);
I imagine you'd still do this here, just:
if (container->mm)
mmdrop(container->mm);
Of course you'd need to check how many places you'd need similar
tests, maybe some of the current->mm tests would be converted to
container->mm rather than dropped. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_p
From: Lukasz Majewski @ 2016-11-08 22:25 UTC (permalink / raw)
To: Thierry Reding, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen
Cc: linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
linux-fbdev, Liu Ying
In-Reply-To: <1477985147-18835-1-git-send-email-l.majewski@majess.pl>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
Dear All,
> The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> properties when necessary") has posed some extra restrictions on
> blanking and unblanking frame buffer device.
>
> Unfortunately, pwm_bl driver's probe did not initialize members of
> struct backlight_device necessary for further blank/unblank operation.
>
> This code in case of initial unblank of backlight device (default
> behaviour) sets use_count to 1 and marks this particular backlight
> device as used by all available fb devices (since it is not known
> during probe how much and which fb devices will be assigned).
>
> Without this code, the backlight works properly until one tries to
> blank it manually from sysfs with "echo 1
> > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > were both set to 0, the logic at
> fb_notifier_callback (@backlight.c) thought that we didn't turn on
> (unblanked) the backlight device and refuses to disable (blank) it.
> As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Best regards,
Łukasz Majewski
>
> Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> ---
> The patch has been tested on i.MX6q with 4.9-rc3
> SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> ---
> Changes for v2:
> - Update commit message with proper other commit reference
>
> ---
> drivers/video/backlight/pwm_bl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> platform_device *pdev) struct pwm_bl_data *pb;
> int initial_blank = FB_BLANK_UNBLANK;
> struct pwm_args pargs;
> - int ret;
> + int ret, i;
>
> if (!data) {
> ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> platform_device *pdev)
> bl->props.brightness = data->dft_brightness;
> bl->props.power = initial_blank;
> +
> + if (initial_blank == FB_BLANK_UNBLANK) {
> + for (i = 0; i < FB_MAX; i++)
> + bl->fb_bl_on[i] = true;
> +
> + bl->use_count = 1;
> + }
> +
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH master 1/3] MIPS: remove M5100 core
From: Arnout Vandecappelle @ 2016-11-08 22:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <335eb04b-311e-4aab-d412-c88eded124ef@mind.be>
*Note that this patch is for master, not for next...*
On 08-11-16 23:19, Arnout Vandecappelle wrote:
>
>
> On 08-11-16 11:32, Vicente Olivert Riera wrote:
>> This is a microcontroller class (MCU) core which is not suitable for
>> running Linux.
>
> I don't really understand this. What makes it a microcontroller class core that
> is not suitable for running Linux? Do you mean to say that no SoCs exist with
> sufficient memory to be able to run Linux? Or is it just that it's noMMU? The
> latter shouldn't be a problem.
OK, the answer is simple: the kernel doesn't support this core.
>
>>
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>> ---
>> arch/Config.in.mips | 5 -----
>> package/gcc/Config.in.host | 5 ++---
>> toolchain/toolchain-external/Config.in | 2 +-
>> 3 files changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
>> index 3662fed..289e35d 100644
>> --- a/arch/Config.in.mips
>> +++ b/arch/Config.in.mips
>> @@ -47,10 +47,6 @@ config BR2_mips_interaptiv
>> bool "interAptiv"
>> depends on !BR2_ARCH_IS_64
>> select BR2_MIPS_CPU_MIPS32R2
>> -config BR2_mips_m5100
>> - bool "M5100"
>> - depends on !BR2_ARCH_IS_64
>> - select BR2_MIPS_CPU_MIPS32R5
>
> Missing legacy handling.
Forget it, this core was introduced in this cycle so no legacy handling is needed.
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
>
> Regards,
> Arnout
>
>> config BR2_mips_m5101
>> bool "M5101"
>> depends on !BR2_ARCH_IS_64
>> @@ -133,7 +129,6 @@ config BR2_GCC_TARGET_ARCH
>> default "mips32r5" if BR2_mips_32r5
>> default "mips32r6" if BR2_mips_32r6
>> default "interaptiv" if BR2_mips_interaptiv
>> - default "m5100" if BR2_mips_m5100
>> default "m5101" if BR2_mips_m5101
>> default "m6201" if BR2_mips_m6201
>> default "p5600" if BR2_mips_p5600
>> diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
>> index 446df4d..f46656c 100644
>> --- a/package/gcc/Config.in.host
>> +++ b/package/gcc/Config.in.host
>> @@ -64,9 +64,8 @@ choice
>> # musl ppc64 unsupported
>> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
>> # Unsupported MIPS cores
>> - depends on !BR2_mips_interaptiv && !BR2_mips_m5100 && \
>> - !BR2_mips_m5101 && !BR2_mips_m6201 && !BR2_mips_i6400 && \
>> - !BR2_mips_p6600
>> + depends on !BR2_mips_interaptiv && !BR2_mips_m5101 && \
>> + !BR2_mips_m6201 && !BR2_mips_i6400 && !BR2_mips_p6600
>> # musl mips64 unsupported
>> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_mips64 || BR2_mips64el))
>> select BR2_TOOLCHAIN_GCC_AT_LEAST_5
>> diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
>> index 5324599..22f760b 100644
>> --- a/toolchain/toolchain-external/Config.in
>> +++ b/toolchain/toolchain-external/Config.in
>> @@ -530,7 +530,7 @@ config BR2_TOOLCHAIN_EXTERNAL_MUSL_CROSS
>> BR2_x86_64
>> depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
>> # Unsupported MIPS cores
>> - depends on !BR2_mips_interaptiv && !BR2_mips_m5100 && !BR2_mips_m5101
>> + depends on !BR2_mips_interaptiv && !BR2_mips_m5101
>> # Unsupported for MIPS R6
>> depends on !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
>> select BR2_TOOLCHAIN_EXTERNAL_MUSL
>>
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* Re: [PATCH v3 00/11] pwm: imx: Provide atomic operation for IMX PWM driver
From: Lukasz Majewski @ 2016-11-08 22:24 UTC (permalink / raw)
To: Thierry Reding, Stefan Agner, Sascha Hauer, Boris Brezillon
Cc: linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
Lothar Wassmann, Bhuvanchandra DV, kernel
In-Reply-To: <1477984230-18071-1-git-send-email-l.majewski@majess.pl>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
Dear All,
> This patch set brings atomic operation to i.MX's PWMv2 driver.
Are there any more comments regarding this patch set?
Best regards,
Łukasz Majewski
>
> This work has been supported and suggested by Boris Brezillon [1] and
> Stefan Agner, by showing how simple the transition could be :-).
>
> It has been divided into several steps:
>
> - Remove ipg clock enable/disable code (as proposed by Sascha Hauer)
> - this is the most notable change for v3
>
> - Provide different pwm ops for PWMv1 and PWMv2
>
> - Separate PWMv1 commits from "generic" and non atomic PWM code
>
> NOTE: Since I do _not_ have board with PWMv1, I would like to ask
> somebody for testing
>
> - Move some imx_config_v2 code to separate functions
>
> - Provide PWM atomic implementation (the ->apply() driver) for PWMv2
> in a single patch for better readability.
>
> - Remove redundant PWM code (disable, enable, config callbacks)
>
> - Update proper documentation entries
>
> - Provide support for polarity inversion on top of atomic PWM rework
>
> Test HW:
> --------
> This patch set has been tested on i.MX6q board with
> v4.9-rc3 kernel SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
>
>
> The PWM operation has been tested with pwm_bl backlight driver by
> changing its brightness.
>
> [1]: http://patchwork.ozlabs.org/patch/685402/
>
>
> Lothar Wassmann (2):
> pwm: print error messages with pr_err() instead of pr_debug()
> pwm: core: make the PWM_POLARITY flag in DTB optional
>
> Lukasz Majewski (8):
> pwm: imx: Add separate set of pwm ops for PWMv1 and PWMv2
> pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic
> pwm operation
> pwm: imx: Move PWMv2 software reset code to a separate function
> pwm: imx: Move PWMv2 wait for fifo slot code to a separate function
> pwm: imx: Provide atomic PWM support for i.MX PWMv2
> pwm: imx: Remove redundant i.MX PWMv2 code
> pwm: imx: doc: Update imx-pwm.txt documentation entry
> pwm: imx: Add polarity inversion support to i.MX's PWMv2
>
> Sascha Hauer (1):
> pwm: imx: remove ipg clock
>
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +-
> drivers/pwm/core.c | 26 +--
> drivers/pwm/pwm-imx.c | 247
> ++++++++++------------ 3 files changed, 134 insertions(+), 145
> deletions(-)
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* powerpc-ieee1275 and grub-mkfont dependency
From: Aaro Koskinen @ 2016-11-08 22:23 UTC (permalink / raw)
To: grub-devel, Vladimir 'phcoder' Serbinenko
Hi,
When upgrading from 2.00 to 2.02~beta3, I noticed that on powerpc it's
no longer possible to build with --disable-grub-mkfont: ./configure
forces it and complains about missing fontconfig etc.
However, when I delete those checks from the configure script, I'm able
to build and install a working bootloader for my G4 & G5 Macs (with the
same functionality as with 2.00, using either OF console or serial).
So I think those configure checks should be relaxed. I think it's overkill
to require fontconfig etc. stuff just to build a serial console bootloader
for G5 server.
A.
^ permalink raw reply
* Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return
From: Arnd Bergmann @ 2016-11-08 22:22 UTC (permalink / raw)
To: Robert Jarzmik; +Cc: Stephen Boyd, Michael Turquette, linux-clk, linux-kernel
In-Reply-To: <87k2cdyhnu.fsf@belgarion.home>
On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > The new pxa2xx_determine_rate() function seems lacking in a few
> > regards:
> >
> > - For an exact match or no match at all, the rate is uninitialized
> > as reported by gcc -Wmaybe-unintialized:
> > drivers/clk/pxa/clk-pxa.c: In function 'pxa2xx_determine_rate':
> > drivers/clk/pxa/clk-pxa.c:243:5: error: 'rate' may be used uninitialized in
> > this function
> Euh I don't think that is true.
>
> For an exact match, rate is assigned the exact value in the first line after the
> for(xxx).
Right, my mistake.
> For no match at all, there are 2 cases :
> - either a closest match is found, and rate is actually assigned (see below)
> - or no match is found, and it's true rate remains uninitialized, but we have
> ret = -EINVAL
Or a third case that gcc finds but that probably won't happen in practice:
- nb_freqs==0, rate is never initialized
This is what I'm addressing by returning early in the 'else' case.
> > - If we get a non-exact match, the req->rate output is never set
> > to the actual rate but remains at the requested rate.
> Euh no, that doesn't seem correct to me.
>
> If a non-exact match is found, either by closest_below or closest_above, rate is
> set (rate = freqs[closest_xxx].cpll). And a couple of lines later after the
> if/else, req->rate = rate is set as well, so I don't think this part of the
> commit message is accurate.
It is only set if rate is zero, and that normally is not the case here:
if (!rate)
req->rate = rate;
> > - We should not attempt to print a rate if none could be found
> True.
>
> > This rewrites the logic accordingly.
> Unless I'm wrong in the analysis above, I'd rather have just "unsigned long rate
> = 0" in the variable declaration, and keep the pr_debug() even if -EINVAL is
> returned (it's better for bug tracking, with a rate == 0 in this case for example).
I think it's safer not to initialize the variable, to ensure we get a
warning if the function is changed incorrectly again later.
Arnd
^ permalink raw reply
* + proc-optimize-render_sigset_t.patch added to -mm tree
From: akpm @ 2016-11-08 22:22 UTC (permalink / raw)
To: avagin, adobriyan, keescook, linux, mm-commits
The patch titled
Subject: fs/proc/array.c: optimize render_sigset_t()
has been added to the -mm tree. Its filename is
proc-optimize-render_sigset_t.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/proc-optimize-render_sigset_t.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/proc-optimize-render_sigset_t.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrei Vagin <avagin@openvz.org>
Subject: fs/proc/array.c: optimize render_sigset_t()
render_sigset_t() requires about 30% of time to generate /proc/pid/status.
- 74.44% sys_read
- 74.40% vfs_read
- 74.01% __vfs_read
- 73.36% seq_read
- 72.97% proc_single_show
- 72.26% proc_pid_status
+ 29.79% render_sigset_t
+ 11.47% task_mem
+ 5.60% render_cap_t
+ 4.95% seq_printf
+ 4.28% cpuset_task_status_allowed
seq_printf is called for each symbol of a signal mask. This patch collect
a whole mask in a buffer and prints it for one call of seq_puts().
- 65.02% proc_single_show
- 63.75% proc_pid_status
+ 15.73% task_mem
+ 7.42% render_sigset_t
+ 7.39% render_cap_t
+ 6.46% cpuset_task_status_allowed
/proc/pid/status is generated 25% faster with this optimization.
Link: http://lkml.kernel.org/r/1478641048-11406-1-git-send-email-avagin@openvz.org
Signed-off-by: Andrei Vagin <avagin@openvz.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/array.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -puN fs/proc/array.c~proc-optimize-render_sigset_t fs/proc/array.c
--- a/fs/proc/array.c~proc-optimize-render_sigset_t
+++ a/fs/proc/array.c
@@ -232,11 +232,13 @@ static inline void task_state(struct seq
void render_sigset_t(struct seq_file *m, const char *header,
sigset_t *set)
{
- int i;
+ char buf[_NSIG / 4 + 2];
+ int i, j;
seq_puts(m, header);
i = _NSIG;
+ j = 0;
do {
int x = 0;
@@ -245,10 +247,13 @@ void render_sigset_t(struct seq_file *m,
if (sigismember(set, i+2)) x |= 2;
if (sigismember(set, i+3)) x |= 4;
if (sigismember(set, i+4)) x |= 8;
- seq_printf(m, "%x", x);
+ buf[j++] = hex_asc[x];
} while (i >= 4);
- seq_putc(m, '\n');
+ buf[j++] = '\n';
+ buf[j++] = 0;
+
+ seq_puts(m, buf);
}
static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
_
Patches currently in -mm which might be from avagin@openvz.org are
proc-optimize-render_sigset_t.patch
^ permalink raw reply
* [alternative-merged] fs-proc-arrayc-slightly-improve-render_sigset_t.patch removed from -mm tree
From: akpm @ 2016-11-08 22:21 UTC (permalink / raw)
To: linux, keescook, mm-commits
The patch titled
Subject: fs/proc/array.c: slightly improve render_sigset_t
has been removed from the -mm tree. Its filename was
fs-proc-arrayc-slightly-improve-render_sigset_t.patch
This patch was dropped because an alternative patch was merged
------------------------------------------------------
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: fs/proc/array.c: slightly improve render_sigset_t
format_decode and vsnprintf occasionally show up in perf top, so I went
looking for places that might not need the full printf power. With the
help of kprobes, I gathered some statistics on which format strings we
mostly pass to vsnprintf. On a trivial desktop workload, I hit "%x" 25%
of the time, so something apparently reads /proc/pid/status (which does
5*16 printf("%x") calls) a lot.
With this patch, reading /proc/pid/status is 30% faster according to
this microbenchmark:
char buf[4096];
int i, fd;
for (i = 0; i < 10000; ++i) {
fd = open("/proc/self/status", O_RDONLY);
read(fd, buf, sizeof(buf));
close(fd);
}
Link: http://lkml.kernel.org/r/1474410485-1305-1-git-send-email-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/array.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/proc/array.c~fs-proc-arrayc-slightly-improve-render_sigset_t fs/proc/array.c
--- a/fs/proc/array.c~fs-proc-arrayc-slightly-improve-render_sigset_t
+++ a/fs/proc/array.c
@@ -245,7 +245,7 @@ void render_sigset_t(struct seq_file *m,
if (sigismember(set, i+2)) x |= 2;
if (sigismember(set, i+3)) x |= 4;
if (sigismember(set, i+4)) x |= 8;
- seq_printf(m, "%x", x);
+ seq_putc(m, hex_asc[x]);
} while (i >= 4);
seq_putc(m, '\n');
_
Patches currently in -mm which might be from linux@rasmusvillemoes.dk are
^ permalink raw reply
* Re: linux-next: build failure after merge of the rtc tree
From: Alexandre Belloni @ 2016-11-08 22:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Paul Cercueil
In-Reply-To: <20161108174152.4a5620c4@canb.auug.org.au>
Hi,
On 08/11/2016 at 17:41:52 +1100, Stephen Rothwell wrote :
> Hi Alexandre,
>
> After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
>
> Caused by commit
>
> f9eb69d1ae2f ("rtc: jz4740: Add support for acting as the system power controller")
>
> I have used the rtc tree from next-20161028 for today.
>
Thanks for the report it is fixed in rtc-next now.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Jeff King @ 2016-11-08 22:21 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8BoEXDjwe=ZX5ZOC_mvaMjYrB3i7wcMmiOP3mm5-rwC5Q@mail.gmail.com>
On Tue, Nov 08, 2016 at 08:38:55AM +0700, Duy Nguyen wrote:
> > Another approach is to have a config option to disallow symlinks to
> > destinations outside of the repository tree (I'm not sure if it should
> > be on or off by default, though).
>
> Let's err on the safe side and disable symlinks to outside repo by
> default (or even all symlinks on .gitattributes and .gitignore as the
> first step)
Both of those are actually much harder than you might think.
For matching specific names, we have to deal with case-folding. It's
easy to hit the common ones like ".GITIGNORE" with fspathcmp(). But if
this is actually protection against malicious repositories, we have to
match all of the horrible filesystem-specific junk that we did for
".git".
Symlinks are likewise tricky. If we see that a symlink points to
"foo/../bar", then we don't know if it leaves the repository unless we
also look at "foo" to see if it is also a symlink. So you really end up
having to resolve the symlink yourself (and when checking out multiple
files, there's an ordering dependency).
I think it might be enough to check:
- leading "../" tokens in the symlink's destination can be checked
against the symlink's path. So "../foo" is OK for path "one/two",
but not for path "one".
- interior "../" can be disallowed entirely. Technically
"foo/../bar/../baz" _can_ be a fine symlink destination, but why?
It's identical to "baz" unless you are following a bunch of interior
symlinks. And if those are interior symlinks, it's still confusing
and unnecessarily obfuscated, and a good sign that somebody is
trying to do something tricky.
So one reasonable fix might be to have a config option like
"core.saneSymlinks" that enforces both of those rules for _all_ symlinks
that we checkout to the working tree. And it could either refuse to
check them out, or replace them with a file containing the symlink
content (as we do on systems that don't support symlinks, IIRC).
It could even be off by default (for backwards compatibility, as there
really are uses for symlinks reaching out of the repository in some
cases), but people cloning untrusted repos could flip it on. That seems
like an improvement over the current state.
> What I learned from my changes in .gitignore is, if we have not
> forbidden something, people likely find some creative use for it. As
> long as it's can be turned on or off, i guess those minority will stay
> happy.
Yes, it's one of the fun things about working on a 10-year-old project.
:)
-Peff
^ permalink raw reply
* [GIT PULL] pxa for v4.10
From: Robert Jarzmik @ 2016-11-08 22:19 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd, Kevin, Olof,
Please consider this pull request for pxa 4.10 cycle. This pull request strides
off from my usual ones as its spans more than just mach-pxa.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/rjarzmik/linux.git tags/pxa-for-4.10
for you to fetch changes up to e413bd33ac44b6d0bebc0ef2ac19cbe7558a7303:
ARM: pxa: fix pxa25x interrupt init (2016-11-05 21:48:18 +0100)
----------------------------------------------------------------
This is the pxa changes for v4.10 cycle.
This cycle is covering :
- some clock fixes common with sa1100 architecture
- the consequence of the pxa_camera conversion to v4l2
- a small irq related fix for pxa25x device-tree only
----------------------------------------------------------------
Robert Jarzmik (8):
ARM: sa11x0/pxa: acquire timer rate from the clock rate
watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
ARM: sa11x0/pxa: get rid of get_clock_tick_rate
ARM: pxa: pxa_cplds: honor probe deferral
ARM: pxa: mioa701: use the new pxa_camera platform_data
ARM: pxa: ezx: use the new pxa_camera platform_data
ARM: pxa: em-x270: use the new pxa_camera platform_data
ARM: pxa: fix pxa25x interrupt init
Russell King - ARM Linux (1):
clk: pxa25x: OSTIMER0 clocks from the main oscillator
Wei Yongjun (1):
ARM: pxa: remove duplicated include from spitz.c
arch/arm/mach-pxa/corgi.c | 1 -
arch/arm/mach-pxa/em-x270.c | 89 +++++---------
arch/arm/mach-pxa/ezx.c | 176 +++++++++++----------------
arch/arm/mach-pxa/generic.c | 18 +--
arch/arm/mach-pxa/include/mach/hardware.h | 2 -
arch/arm/mach-pxa/mioa701.c | 13 +-
arch/arm/mach-pxa/pxa25x.c | 2 +-
arch/arm/mach-pxa/pxa_cplds_irqs.c | 11 +-
arch/arm/mach-pxa/spitz.c | 1 -
arch/arm/mach-sa1100/generic.c | 2 +-
arch/arm/mach-sa1100/include/mach/hardware.h | 4 -
drivers/clk/pxa/clk-pxa25x.c | 2 +-
drivers/clocksource/pxa_timer.c | 11 +-
drivers/watchdog/sa1100_wdt.c | 24 +++-
include/clocksource/pxa.h | 3 +-
15 files changed, 142 insertions(+), 217 deletions(-)
--
Robert
^ permalink raw reply
* [Buildroot] [PATCH master 1/3] MIPS: remove M5100 core
From: Arnout Vandecappelle @ 2016-11-08 22:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161108103258.32196-1-Vincent.Riera@imgtec.com>
On 08-11-16 11:32, Vicente Olivert Riera wrote:
> This is a microcontroller class (MCU) core which is not suitable for
> running Linux.
I don't really understand this. What makes it a microcontroller class core that
is not suitable for running Linux? Do you mean to say that no SoCs exist with
sufficient memory to be able to run Linux? Or is it just that it's noMMU? The
latter shouldn't be a problem.
>
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
> arch/Config.in.mips | 5 -----
> package/gcc/Config.in.host | 5 ++---
> toolchain/toolchain-external/Config.in | 2 +-
> 3 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
> index 3662fed..289e35d 100644
> --- a/arch/Config.in.mips
> +++ b/arch/Config.in.mips
> @@ -47,10 +47,6 @@ config BR2_mips_interaptiv
> bool "interAptiv"
> depends on !BR2_ARCH_IS_64
> select BR2_MIPS_CPU_MIPS32R2
> -config BR2_mips_m5100
> - bool "M5100"
> - depends on !BR2_ARCH_IS_64
> - select BR2_MIPS_CPU_MIPS32R5
Missing legacy handling.
Regards,
Arnout
> config BR2_mips_m5101
> bool "M5101"
> depends on !BR2_ARCH_IS_64
> @@ -133,7 +129,6 @@ config BR2_GCC_TARGET_ARCH
> default "mips32r5" if BR2_mips_32r5
> default "mips32r6" if BR2_mips_32r6
> default "interaptiv" if BR2_mips_interaptiv
> - default "m5100" if BR2_mips_m5100
> default "m5101" if BR2_mips_m5101
> default "m6201" if BR2_mips_m6201
> default "p5600" if BR2_mips_p5600
> diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
> index 446df4d..f46656c 100644
> --- a/package/gcc/Config.in.host
> +++ b/package/gcc/Config.in.host
> @@ -64,9 +64,8 @@ choice
> # musl ppc64 unsupported
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
> # Unsupported MIPS cores
> - depends on !BR2_mips_interaptiv && !BR2_mips_m5100 && \
> - !BR2_mips_m5101 && !BR2_mips_m6201 && !BR2_mips_i6400 && \
> - !BR2_mips_p6600
> + depends on !BR2_mips_interaptiv && !BR2_mips_m5101 && \
> + !BR2_mips_m6201 && !BR2_mips_i6400 && !BR2_mips_p6600
> # musl mips64 unsupported
> depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_mips64 || BR2_mips64el))
> select BR2_TOOLCHAIN_GCC_AT_LEAST_5
> diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
> index 5324599..22f760b 100644
> --- a/toolchain/toolchain-external/Config.in
> +++ b/toolchain/toolchain-external/Config.in
> @@ -530,7 +530,7 @@ config BR2_TOOLCHAIN_EXTERNAL_MUSL_CROSS
> BR2_x86_64
> depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
> # Unsupported MIPS cores
> - depends on !BR2_mips_interaptiv && !BR2_mips_m5100 && !BR2_mips_m5101
> + depends on !BR2_mips_interaptiv && !BR2_mips_m5101
> # Unsupported for MIPS R6
> depends on !BR2_MIPS_CPU_MIPS32R6 && !BR2_MIPS_CPU_MIPS64R6
> select BR2_TOOLCHAIN_EXTERNAL_MUSL
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* [Buildroot] [PATCH 5/5] package/pseudo: provide better legacy handling for fakeroot
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1478643505.git.yann.morin.1998@free.fr>
We now have a wrapper that makes pseudo behaves like the fakeroot of the
good ol' days. So the symlink will just magically keep old scripts
working as they did before the switch to pseudo.
However, using fakeroot is deprecated, and we want people to stop using
it altogether and switch to pseudo.
So, make the wrapper recognise how it's called, and if called as
fakeroot, print a warning message.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Cc: Erico Nunes <nunes.erico@gmail.com>
Cc: Julien BOIBESSOT <julien.boibessot@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
package/pseudo/pseudo-wrapper | 9 ++++++++-
package/pseudo/pseudo.mk | 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/package/pseudo/pseudo-wrapper b/package/pseudo/pseudo-wrapper
index feaa7fc..9c8dbdb 100644
--- a/package/pseudo/pseudo-wrapper
+++ b/package/pseudo/pseudo-wrapper
@@ -1,5 +1,12 @@
#!/bin/sh
+if [ "${0##*/}" = "fakeroot" ]; then
+ cat >&2 <<-_EOF_
+ WARNING: fakeroot has been replaced with pseudo.
+ WARNING: Update your script(s) to use pseudo or pseudo-wrapper instead.
+ _EOF_
+fi
+
export PSEUDO_PREFIX="$(dirname "${0%/*}")"
export PSEUDO_OPTS="-t0"
if [ -n "${TARGET_DIR}" ]; then
@@ -9,4 +16,4 @@ if [ -n "${BASE_DIR}" ]; then
export PSEUDO_LOCALSTATEDIR="${BASE_DIR}/build/.pseudodb"
fi
-exec "${0%-wrapper}" "${@}"
+exec "${0%/*}/pseudo" "${@}"
diff --git a/package/pseudo/pseudo.mk b/package/pseudo/pseudo.mk
index 474eae2..02d6247 100644
--- a/package/pseudo/pseudo.mk
+++ b/package/pseudo/pseudo.mk
@@ -33,7 +33,7 @@ endef
HOST_PSEUDO_POST_INSTALL_HOOKS += HOST_PSEUDO_INSTALL_WRAPPER
define HOST_PSEUDO_FAKEROOT_SYMLINK
- ln -sf pseudo $(HOST_DIR)/usr/bin/fakeroot
+ ln -sf pseudo-wrapper $(HOST_DIR)/usr/bin/fakeroot
endef
HOST_PSEUDO_POST_INSTALL_HOOKS += HOST_PSEUDO_FAKEROOT_SYMLINK
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 4/5] fs: call the pseudo wrapper
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1478643505.git.yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Cc: Erico Nunes <nunes.erico@gmail.com>
Cc: Julien BOIBESSOT <julien.boibessot@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
fs/common.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/common.mk b/fs/common.mk
index 2dbef4d..22f3de5 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -97,7 +97,7 @@ endif
echo $$(s) $$(TARGET_DIR) $$(BR2_ROOTFS_POST_SCRIPT_ARGS) >> $$(FAKEROOT_SCRIPT)$$(sep))
$$(call PRINTF,$$(ROOTFS_$(2)_CMD)) >> $$(FAKEROOT_SCRIPT)
chmod a+x $$(FAKEROOT_SCRIPT)
- PATH=$$(BR_PATH) $$(HOST_DIR)/usr/bin/pseudo -- $$(FAKEROOT_SCRIPT)
+ PATH=$$(BR_PATH) $$(HOST_DIR)/usr/bin/pseudo-wrapper -- $$(FAKEROOT_SCRIPT)
$$(INSTALL) -m 0644 support/misc/target-dir-warning.txt $$(TARGET_DIR_WARNING_FILE)
- at rm -f $$(FAKEROOT_SCRIPT) $$(FULL_DEVICE_TABLE)
ifneq ($$(ROOTFS_$(2)_COMPRESS_CMD),)
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 3/5] package/pseudo: wrap the real pseudo with a wrapper
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1478643505.git.yann.morin.1998@free.fr>
Running pseudo is more involved than running fakeroot. In the transition
from using fakeroot, we just did not account for the extra requirements.
First, we explicitly tell pseudo where it is, otherwise it tries to
guess. Its guess is correct, but it prints a warning, which is not nice.
Second, we tell it where to find the passwd and group files in case it
has to emulate access to them. We currently do not use that feature, but
better safe than sorry.
Third, pseudo spawns a background daemon, and talks to it (when fakeroot
would emulate the state all in the current process' state, pseudo uses
the daemon to coordinate the state across multiple processes). We are
not much interested in the daemon lingering around, so we just tell it
to terminate as soon as the last clients quits (this can take up to one
second).
Fourth and last, pseudo always stores its internal database when
exiting, and reloads it when spawned. The database is by default stored
in a sub-directory of the prefix it was installed in, but this is
impractical for us. We want the database to be specific to the one
config dir we are building, so we store the database in a (hidden)
sub-dir of the build dir, thus ensuring it is never shared with another
build. That directory is hidden (starts with a dot) because we consider
that to be our internal state that we do not want to expose to the user.
The wrapper has to be relocatable, so we avoid using hard-coded paths
in there: we derive those paths fom the runtime path of pseudo. However,
the build directory $(BUILD_DIR) is not available in the environment
(we do not export it because it conflicts with some buildsystems).
Instead, we use $(BASE_DIR) which is exported.
Finally, when relocated, the wrapper would not be used in the Buildroot
environment, so may not have access to TARGET_DIR or BASE_DIR, unless
the user sets them. If he does not, we still want the wrapper to be
working (to avoid the warning about the prefix, and to exit the daemon
asap); thus we leave the passwd and localstatedir variable alone if we
don't have what it needs to set them, rather than set them to incorrect
values.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Cc: Erico Nunes <nunes.erico@gmail.com>
Cc: Julien BOIBESSOT <julien.boibessot@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
Changes v1 -> v2:
- do not use a variable, but use a wrapper
---
package/pseudo/pseudo-wrapper | 12 ++++++++++++
package/pseudo/pseudo.mk | 6 ++++++
2 files changed, 18 insertions(+)
create mode 100644 package/pseudo/pseudo-wrapper
diff --git a/package/pseudo/pseudo-wrapper b/package/pseudo/pseudo-wrapper
new file mode 100644
index 0000000..feaa7fc
--- /dev/null
+++ b/package/pseudo/pseudo-wrapper
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+export PSEUDO_PREFIX="$(dirname "${0%/*}")"
+export PSEUDO_OPTS="-t0"
+if [ -n "${TARGET_DIR}" ]; then
+ export PSEUDO_PASSWD="${TARGET_DIR}"
+fi
+if [ -n "${BASE_DIR}" ]; then
+ export PSEUDO_LOCALSTATEDIR="${BASE_DIR}/build/.pseudodb"
+fi
+
+exec "${0%-wrapper}" "${@}"
diff --git a/package/pseudo/pseudo.mk b/package/pseudo/pseudo.mk
index 4be5154..474eae2 100644
--- a/package/pseudo/pseudo.mk
+++ b/package/pseudo/pseudo.mk
@@ -26,6 +26,12 @@ HOST_PSEUDO_CONF_OPTS = \
--libdir=$(HOST_DIR)/usr/lib \
--with-sqlite=$(HOST_DIR)/usr
+define HOST_PSEUDO_INSTALL_WRAPPER
+ $(INSTALL) -D -m 0755 $(HOST_PSEUDO_PKGDIR)/pseudo-wrapper \
+ $(HOST_DIR)/usr/bin/pseudo-wrapper
+endef
+HOST_PSEUDO_POST_INSTALL_HOOKS += HOST_PSEUDO_INSTALL_WRAPPER
+
define HOST_PSEUDO_FAKEROOT_SYMLINK
ln -sf pseudo $(HOST_DIR)/usr/bin/fakeroot
endef
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 2/5] package/pseudo: force rpath and pass our host CFLAGS
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1478643505.git.yann.morin.1998@free.fr>
pseudo whines when those are not set, and tries to find a suitable
value; this is usually correct but risk an incorrect guess in corner
cases.
Rather than leaving those in guess-mode, just force them to values we
know are correct.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Cc: Erico Nunes <nunes.erico@gmail.com>
Cc: Julien BOIBESSOT <julien.boibessot@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
---
package/pseudo/pseudo.mk | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/package/pseudo/pseudo.mk b/package/pseudo/pseudo.mk
index 92de2c6..4be5154 100644
--- a/package/pseudo/pseudo.mk
+++ b/package/pseudo/pseudo.mk
@@ -16,7 +16,12 @@ HOST_PSEUDO_DEPENDENCIES = host-attr host-sqlite
# configure script is not generated by autoconf, so passing --libdir
# is necessary, even if the infrastructure passes --prefix already.
+# It also does not use CFLAGS from the environment, they need to be
+# specified with a custom --cflags option. Also force rpath to avoid
+# a warning at configure time.
HOST_PSEUDO_CONF_OPTS = \
+ --cflags='$(HOSTCFLAGS)' \
+ --with-rpath=$(HOST_DIR)/usr/lib \
--bits=$(if $(filter %64,$(HOSTARCH)),64,32) \
--libdir=$(HOST_DIR)/usr/lib \
--with-sqlite=$(HOST_DIR)/usr
--
2.7.4
^ permalink raw reply related
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Olof Johansson @ 2016-11-08 22:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kernel Build Reports Mailman List, Olof's autobuilder, stable,
Greg KH, Eric W. Biederman
In-Reply-To: <2049467.HlUiazMrKa@wuerfel>
On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
>> Here are the build results from automated periodic testing.
>>
>> The tree being built was stable-rc, found at:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>>
>> Topmost commit:
>>
>> f821e08 Linux 4.4.31-rc1
>>
>> Build logs (stderr only) can be found at the following link (experimental):
>>
>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
>
> These seem to be largely caused by building with gcc-6. It's probably
> a good idea to keep supporting that configuration though and
> backport the fixes. Here are the upstream commit IDs I've found.
That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
It's not entirely reasonable to expect older releases to build with
new toolchains without warnings, and I'm not sure if it makes sense to
bring back those fixes to -stable (unless they fix real bugs, of
course).
-Olof
^ permalink raw reply
* [Buildroot] [PATCH 1/5] package/pseudo: enforce the host bitness
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1478643505.git.yann.morin.1998@free.fr>
pseudo can detect the host bitness, but is not sure about it: it checks
what type of file /bin/sh is, using file(1).
However, in some conditions, /bin/sh can be of a different bitness than
the rest of the system (weird, but not impossible), which causes build
issues.
Just enforce the bitness, so that pseudo needs not (wrongly) guess it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Cc: Erico Nunes <nunes.erico@gmail.com>
Cc: Julien BOIBESSOT <julien.boibessot@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
Changes v1 -> v2:
- directly extract bitness for $(HOSTARCH) (Arnout)
---
package/pseudo/pseudo.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/pseudo/pseudo.mk b/package/pseudo/pseudo.mk
index 67538a6..92de2c6 100644
--- a/package/pseudo/pseudo.mk
+++ b/package/pseudo/pseudo.mk
@@ -17,6 +17,7 @@ HOST_PSEUDO_DEPENDENCIES = host-attr host-sqlite
# configure script is not generated by autoconf, so passing --libdir
# is necessary, even if the infrastructure passes --prefix already.
HOST_PSEUDO_CONF_OPTS = \
+ --bits=$(if $(filter %64,$(HOSTARCH)),64,32) \
--libdir=$(HOST_DIR)/usr/lib \
--with-sqlite=$(HOST_DIR)/usr
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 0/5 v2] package/pseudo: fix build and better mimic fakeroot
From: Yann E. MORIN @ 2016-11-08 22:18 UTC (permalink / raw)
To: buildroot
Hello All!
When we switched from using fakeroot to using pseudo, a lot of
assumptions were made, in that we assumed pseudo was by default
behaving as fakeroot did.
That is wrong. pseudo is a little bit more versatile than fakeroot
is, so using it is a little bit more involved.
First, its buildsystem is a bit convoluted, and can incorrectly guess
the host charateristics, like bitness.
Second, it needs to be told at runtime where to look at, and put its
own stuff. It correctly gueses, but prints a warning that it had to
gues, and the location to store its DB is not optimum (even if not
incorrect).
So, this series ensures that pseudo is correctly built and that we
correctly specify the runtime configuration.
Regards,
Yann E. MORIN.
The following changes since commit 64904f0f6d691cfea5ae1c8f58e2d61aac0684c2
mpv: fix build on powerpc64 w/ altivec (2016-11-08 09:37:17 +0100)
are available in the git repository at:
git://git.buildroot.org/~ymorin/git/buildroot.git
for you to fetch changes up to 29ffadca0013de2c9d9c7e749f13cb6e0361a9f0
package/pseudo: provide better legacy handling for fakeroot (2016-11-08 23:17:51 +0100)
----------------------------------------------------------------
Yann E. MORIN (5):
package/pseudo: enforce the host bitness
package/pseudo: force rpath and pass our host CFLAGS
package/pseudo: wrap the real pseudo with a wrapper
fs: call the pseudo wrapper
package/pseudo: provide better legacy handling for fakeroot
fs/common.mk | 2 +-
package/pseudo/pseudo-wrapper | 19 +++++++++++++++++++
package/pseudo/pseudo.mk | 14 +++++++++++++-
3 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644 package/pseudo/pseudo-wrapper
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Arnd Bergmann @ 2016-11-08 22:14 UTC (permalink / raw)
To: kernel-build-reports
Cc: Olof's autobuilder, olof, stable, Greg KH, Eric W. Biederman
In-Reply-To: <5822086c.4666420a.e9479.80e9@mx.google.com>
On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> Here are the build results from automated periodic testing.
>
> The tree being built was stable-rc, found at:
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>
> Topmost commit:
>
> f821e08 Linux 4.4.31-rc1
>
> Build logs (stderr only) can be found at the following link (experimental):
>
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
These seem to be largely caused by building with gcc-6. It's probably
a good idea to keep supporting that configuration though and
backport the fixes. Here are the upstream commit IDs I've found.
> -------------------------------------------------------------------------------
>
> Failed defconfigs:
> powerpc.pasemi_defconfig
>
> -------------------------------------------------------------------------------
>
> Errors:
>
> powerpc.pasemi_defconfig:
> /work/build/batch/arch/powerpc/kernel/ptrace.c:378:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]
> /work/build/batch/arch/powerpc/kernel/ptrace.c:406:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]
1e407ee3b21f ("powerpc/ptrace: Fix out of bounds array access warning")
> Warnings:
>
> 1 drivers/block/floppy.c:1777:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:1779:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:4479:45: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:4487:45: warning: self-comparison always evaluates to true [-Wtautological-compare]
dd665be0e243 ("ARM: 8584/1: floppy: avoid gcc-6 warning")
> 1 drivers/of/of_reserved_mem.c:131:180: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:182: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:364: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:368: warning: comparison of distinct pointer types lacks a cast
aaaab56dba9a ("of: silence warnings due to max() usage")
> 1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of
devpts an independent filesystem."), which unfortunately is not a candidate for stable
> 1 kernel/sched/core.c:2941:26: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> 1 kernel/sched/core.c:2943:27: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
A number of patches went in for this one, the last one was
ef6000b4c670 ("Disable the __builtin_return_address() warning globally after all")
> 1 mm/cma.c:186:131: warning: comparison of distinct pointer types lacks a cast
> 1 mm/cma.c:269:193: warning: comparison of distinct pointer types lacks a cast
> 1 mm/cma.c:269:379: warning: comparison of distinct pointer types lacks a cast
badbda53e505 ("mm/cma: silence warnings due to max() usage")
> 1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
Apparently also fixed as a side-effect of a larger patch:
9847371a84b0 ("netfilter: Allow xt_owner in any user namespace")
This one might be appropriate for a stable backport, Eric Biederman
would know for sure.
> 4 drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: warning: self-comparison always evaluates to false [-Wtautological-compare]
55c4b906aa2a ("drm/exynos: fix error handling in exynos_drm_subdrv_open")
> 4 drivers/i2c/busses/i2c-imx.c:1007:10: warning: 'return' with a value, in function returning void
The same one showed up in linux-4.8.y-rc earlier today and is now gone, I assume
it was already fixed there.
> 9 kernel/cgroup.c:239:396: warning: array subscript is above array bounds [-Warray-bounds]
cfe02a8a973e ("cgroup: avoid false positive gcc-6 warning")
> 19 drivers/net/ethernet/smsc/smc91x.c:563:14: warning: self-comparison always evaluates to true [-Wtautological-compare]
e3ebd894f084 ("smc91x: avoid self-comparison warning")
> 1 include/uapi/linux/swab.h:14:33: warning: integer overflow in expression [-Woverflow]
> 5 kernel/audit.c:663:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 6 kernel/taskstats.c:289:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 4 drivers/connector/cn_proc.c:349:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 2 fs/xfs/xfs_ioctl.c:1166:22: warning: self-comparison always evaluates to true [-Wtautological-compare]
No idea.
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.