Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

On Fri, Feb 12, 2016 at 09:45:22AM +0100, Philipp Hahn wrote: > Am 12.02.2016 um 08:57 schrieb Jiri Slaby: > > On 02/11/2016, 06:32 PM, Willy Tarreau wrote: > >> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote: > >>> From: willy tarreau > >>> > >>> 3.12-stable review

Re: [PATCH 4/4] mailbox: mailbox-test: add support for separate tx/rx buffer with single channel

On Thu, 11 Feb 2016, Sudeep Holla wrote: > This patch adds support for different MMIO region for Tx and Rx paths. > If only one region is specified, it's assumed to be shared between Rx > and Tx, thereby retaining backward compatibility. > > Also in order to support single channel dealing with

[RFC v2a 08/12] fs: btrfs: Change timespec data types to use vfs_time

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. The following needs to

[RFC v2a 12/12] fs: xfs: change inode times to use vfs_time data type

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. vfs_time is an

[RFC v2a 10/12] fs: ceph: Replace timespec data type with vfs_time

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. Use vfs_time data

[RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. These timestamps are

[RFC v2a 09/12] fs: ceph: Change encode and decode functions to use vfs_time

Encode is used for iattr times, inode times and current filesystem times. Decode is mostly used for inode times. Hence, these need to use vfs_time to switch to 64 bit times along with vfs. Decode is also used for keepalive times and processing authentication tickets. Since inode times also use

Re: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build

Hi Arnd, 2016-02-12 0:41 GMT+09:00 Arnd Bergmann : > The newly added uniphier serial port driver fails to build as > a loadable module when the base 8250 driver is built-in and > its console support enabled: > > ERROR: "early_serial8250_setup"

Re: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8

On Thu, Feb 11, 2016 at 03:37:55PM -0700, Baicar, Tyler wrote: > On 2/10/2016 11:03 AM, Will Deacon wrote: > >On Fri, Feb 05, 2016 at 12:13:28PM -0700, Tyler Baicar wrote: > >>diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > >>index 6c68100..ed64b97 100644 > >>---

Re: [PATCH v5] powerpc32: provide VIRT_CPU_ACCOUNTING

On 2/11/16, Christophe Leroy wrote: > This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture. > PPC32 doesn't have the PACA structure, so we use the task_info > structure to store the accounting data. > > In order to reuse on PPC32 the PPC64 functions, all u64 data

Re: blk: accessing invalid memory with "blk-mq: dynamic h/w context count"

On Fri, 12 Feb 2016 00:41:28 -0500 Sasha Levin wrote: > Hi all, > > I've started seeing the following errors on boot: > > [6035791.296570] > == > [6035791.297467] BUG: KASAN: slab-out-of-bounds in >

[PATCH] pinctrl: sirf/atlas7: stop poking around in GPIO internals

This code is poking around in the gpio_chip:s internal structures to achieve some kind of pin to GPIO mappings. - It is wrong to poke around in these structs and the pinctrl maintainer was stupid to let it pass unnoticed, mea culpa. - The right interface to use is gpiochip_add_pin_range() -

Re: [ANNOUNCE] 4.1.5-rt5

Hi Sebastian Am Sonntag, 16. August 2015, 15:56:30 schrieb Sebastian Andrzej Siewior: > I'm pleased to announce the v4.1.5-rt5 patch set. I have just tested it with a Altera SoC ARM v7. The latencies seem to have gotten a little bit worse with each release. The first core has always been worse

Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

Am 12.02.2016 um 08:57 schrieb Jiri Slaby: > On 02/11/2016, 06:32 PM, Willy Tarreau wrote: >> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote: >>> From: willy tarreau >>> >>> 3.12-stable review patch. If anyone has any objections, please let me know. >>> >>>

[GIT PULL] Immutable branch between MFD and Regulator

Enjoy! The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3: Linux 4.5-rc2 (2016-01-31 18:12:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-regulator-v4.6 for you to fetch changes up to

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

2016-02-12 10:57 GMT+03:00 Matwey V. Kornilov : > up->em485 is always pointer, however you are right, that > serial8250_em485_init stores pointer to up when the timers are inited. > More complex issue here that serial8250_em485_init need to set RTS to > proper state and probably

[RFC v2a 07/12] fs: btrfs: Use vfs_time data type for btrfs_update_time()

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. This is set as a vfs

[RFC v2c 0/8] vfs 64 bit time transition proposal

Introduction The series is one of the proposals on how to transition VFS timestamps to use 64 bit time. The credit for the idea goes to Arnd Bergmann and it’s a mix of approaches 2a and 2b. Solution 1.Define vfs_time as alias to timespec. 2.Define accessor functions for inode timestamps.

[RFC v2c 1/8] vfs: Add vfs_time abstractions

Add vfs_time accessors to help convert vfs timestamps to use 64 bit times. These create an abstraction layer so that vfs inode times can be switched to struct timespec64 from struct timespec without breaking the individual filesystems after they have incorporated these. Add vfs_time data type

Re: [PATCH 0/4] mailbox: mailbox-test: support single channel with separate Tx and Rx buffer

On Thu, 11 Feb 2016, Sudeep Holla wrote: > Hi Lee, Jassi, > > Assuming mailbox-test was designed to be generic, I am trying to extend > it to support single channel with separate Tx and Rx buffer. With these > changes I am able to test arm_mhu driver. However I couldn't understand > the

[RFC v2a 05/12] fs: cifs: Use vfs_time_get_real_* time functions

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. Variables in the

[RFC v2a 04/12] fs: cifs: Make cnvrtDosUnixTm() y2038 safe

The seconds calculated from the server(DOS format) cannot be saved in int data type as this cannot save seconds since epoch after the year 2038. Use long long for seconds field in cnvrtDosUnixTm(). This will help represent 64 bit time even on 32 bit systems. Note that even though the theoretical

[RFC v2a 06/12] fs: btrfs: Change btrfs_inode.i_otime to use vfs_time data type

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. struct btrfs_inode is

[RFC v2a 02/12] fs: cifs: Change cifs_fscache_inode_auxdata to use vfs_time data type

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. aux data timestamps

[RFC v2a 00/12] vfs 64 bit time transition proposal

Introduction The series is one of the proposals on how to transition VFS timestamps to use 64 bit time. This is the inode_timespec idea proposed in the original RFC series. The type name has been changed to vfs_time based on Dave Chinner’s suggestion. Solution This series defines a new type

[RFC v2b 4/5] fs: ceph: Use vfs timestamp accessors

This is in preparation for changing VFS inode timestamps to use 64 bit time. The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file

[RFC v2b 2/5] fs: cifs: Use vfs_time accessors

This is preparation to make vfs inode timestamps y2038 safe. The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use

[RFC v2b 3/5] fs: btrfs: Use vfs_time accessors

This is in preparation for changing VFS inode timestamps to use 64 bit time. The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file

Re: [PATCH v8 00/10] mfd: axp20x: Add support for RSB based AXP223

On Fri, 12 Feb 2016, Chen-Yu Tsai wrote: [...] > Chen-Yu Tsai (10): > mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings > mfd: axp20x: Remove second struct device * parameter for > axp20x_match_device() > mfd: axp20x: use dev->driver->of_match_table in

Re: [PATCH 3/7] eeprom: at24: extend driver to plug into the NVMEM framework

On Fri, Jan 29, 2016 at 02:10:17PM +0100, Bartosz Golaszewski wrote: > Hi Andrew, > > the patch works, but I'm hitting the following BUG when instantiating > an at24c32 device: Hi Bortosz Sorry for taking so long to get back to you. Can you confirm you had lockdep turned on. Thanks

Re: [PATCH v2 5/6] serial: 8250/mediatek: fix building with SERIAL_8250=m

Hi Arnd, 2016-02-12 0:41 GMT+09:00 Arnd Bergmann : > The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that > breaks when SERIAL_8250 is a loadable module: > > drivers/tty/built-in.o: In function `mtk8250_set_termios': > :(.text+0x1bee8): undefined reference to

[RFC v2a 01/12] vfs: Add vfs_time abstractions

Add vfs_time aliases to help convert vfs timestamps to use 64 bit times. These create an abstraction layer so that vfs inode times can be switched to use struct timespec64 instead of struct timespec. Use uapi exposed data types, timespec and timespec64 here to keep minimal timestamp data type

Re: [patch 08/10] kernel/locking/lockdep.c: convert hash tables to hlists

* a...@linux-foundation.org wrote: > From: Andrew Morton > Subject: kernel/locking/lockdep.c: convert hash tables to hlists > > Mike said: > > : CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled, i. e > : kernel with

[RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type

This is in preparation for changing VFS inode timestamps to use 64 bit time. The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file

Re: [PATCH] Platform: goldfish: goldfish_pipe.c: Add DMA support using managed version

On Fri, 2016-02-12 at 12:53 +0530, Shraddha Barke wrote: > setup_access_params_addr has 2 goals- > > -Initialize the access_params field so that it can be used to send and read > commands from the device in access_with_param > -Get a bus address for the allocated memory to transfer to the device.

Re: [PATCH V3 08/10] irqchip, gicv3, its: Probe ITS in the ACPI way.

On 10.02.2016 12:46, Marc Zyngier wrote: On 19/01/16 13:11, Tomasz Nowicki wrote: Since we prepared ITS for being initialized different that via DT, it is now possible to parse MADT and pass mandatory info to firmware-agnostic ITS init call. Note that we are using here IORT lib to keep track

Re: [PATCH v42 3/6] clk: Provide OF helper to mark clocks as CRITICAL

On Thu, 11 Feb 2016, Michael Turquette wrote: > From: Lee Jones > > This call matches clocks which have been marked as critical in DT > and sets the appropriate flag. These flags can then be used to > mark the clock core flags appropriately prior to registration. > >

Re: [PATCH v42 1/6] clk: Allow clocks to be marked as CRITICAL

On Thu, 11 Feb 2016, Michael Turquette wrote: > From: Lee Jones > > Critical clocks are those which must not be gated, else undefined > or catastrophic failure would occur. Here we have chosen to > ensure the prepare/enable counts are correctly incremented, so as > not to

Re: [PATCH v42 0/6] critical clocks and handoff clocks

On Thu, 11 Feb 2016, Michael Turquette wrote: > This series combines Lee's critical clock patches[0] plus some small > fixes and changes with a repost of my handoff clock patches[1]. Both > features are enabled by setting new flags on static clock data within > clock provider drivers. > > In

[RFC v3 01/15] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute

Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported, this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS and FSL PAMU, at least expose this attribute. x86 IOMMUs typically don't expose the attribute since on x86, MSI write transaction addresses always are

[RFC v3 06/15] iommu/arm-smmu: add a reserved binding RB tree

we will need to track which host physical addresses are mapped to reserved IOVA. In that prospect we introduce a new RB tree indexed by physical address. This RB tree only is used for reserved IOVA bindings. It is expected this RB tree will contain very few bindings. Those generally correspond to

[RFC v3 12/15] msi: export msi_get_domain_info

We plan to use msi_get_domain_info in VFIO module so let's export it. Signed-off-by: Eric Auger --- v2 -> v3: - remove static implementation in case CONFIG_PCI_MSI_IRQ_DOMAIN is not set --- kernel/irq/msi.c | 1 + 1 file changed, 1 insertion(+) diff --git

[RFC v3 14/15] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the irq_remapping capability is abstracted on irqchip side for ARM as opposed to Intel IOMMU featuring IRQ remapping HW. So to check IRQ remmapping capability, the msi domain needs to be checked instead. Signed-off-by: Eric Auger

[RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame when needed

In case the msi_desc references a device attached to an iommu domain, the msi address needs to be mapped in the IOMMU. Else any MSI write transaction will cause a fault. gic_set_msi_addr detects that case and allocates an iova bound to the physical address page comprising the MSI frame. This iova

[RFC v3 13/15] vfio/type1: also check IRQ remapping capability at msi domain

On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted by the msi controller. vfio_msi_parent_irq_remapping_capable allows to check whether interrupts are "safe" for a given device. There are if the device does not use MSI or if the device uses MSI and the msi-parent controller

[RFC v3 11/15] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING meant to tell the domain supports IRQ REMAPPING, also known as Interrupt Translation Service. On Intel HW this capability is abstracted on IOMMU side while on ARM it is abstracted on MSI controller side. GICv3 ITS HW is the

[RFC v3 10/15] vfio: allow the user to register reserved iova range for MSI mapping

The user is allowed to register a reserved IOVA range by using the DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. It provides the base address and the size. This region is stored in the vfio_dma rb tree. At that point the iova range is not mapped to any target address

[RFC v3 05/15] iommu/arm-smmu: implement alloc/free_reserved_iova_domain

Implement alloc/free_reserved_iova_domain for arm-smmu. we use the iova allocator (iova.c). The iova_domain is attached to the arm_smmu_domain struct. A mutex is introduced to protect it. Signed-off-by: Eric Auger --- v2 -> v3: - select IOMMU_IOVA when ARM_SMMU or

Re: Computer fails to resume from suspend unless I rmmod jme before initiating the suspend

On Wed, Feb 10, 2016 at 7:36 PM, Diego Viola wrote: > On Wed, Feb 10, 2016 at 2:19 AM, Diego Viola wrote: >> Hi Guo, >> >> I have an x86 computer with this network card: >> >> 02:00.0 Ethernet controller: JMicron Technology Corp. JMC260 PCI >>

[RFC v3 09/15] iommu/arm-smmu: relinquish reserved resources on domain deletion

arm_smmu_unmap_reserved releases all reserved binding resources: destroy all bindings, free iova, free iova_domain. This happens on domain deletion. Signed-off-by: Eric Auger --- drivers/iommu/arm-smmu.c | 34 +- 1 file changed, 29

[RFC v3 04/15] iommu: add alloc/free_reserved_iova_domain

Introduce alloc/free_reserved_iova_domain in the IOMMU API. alloc_reserved_iova_domain initializes an iova domain at a given iova base address and with a given size. This iova domain will be used to allocate iova within that window. Those IOVAs will be reserved for special purpose, typically MSI

[RFC v3 08/15] iommu/arm-smmu: implement iommu_get/put_single_reserved

Implement the iommu_get/put_single_reserved API in arm-smmu. In order to track which physical address is already mapped we use the RB tree indexed by PA. Signed-off-by: Eric Auger --- v1 -> v2: - previously in vfio_iommu_type1.c --- drivers/iommu/arm-smmu.c | 114

[RFC v3 03/15] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type

We introduce a vfio_dma type since we will need to discriminate legacy vfio_dma's from new reserved ones. Since those latter are not mapped at registration, some treatments need to be reworked: removal, replay. Currently they are unplugged. In subsequent patches they will be reworked.

[RFC v3 07/15] iommu: iommu_get/put_single_reserved

This patch introduces iommu_get/put_single_reserved. iommu_get_single_reserved allows to allocate a new reserved iova page and map it onto the physical page that contains a given physical address. It returns the iova that is mapped onto the provided physical address. Hence the physical address

[RFC v3 02/15] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO

This patch allows the user-space to retrieve whether msi write transaction addresses must be mapped. This is returned through the VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP. Signed-off-by: Bharat Bhushan Signed-off-by: Eric Auger

[RFC v3 00/15] KVM PCIe/MSI passthrough on ARM/ARM64

This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64. It pursues the efforts done on [1], [2], [3]. It also aims at covering the same need on PowerPC platforms although the same kind of integration should be carried out. On x86 all accesses to the 1MB PA region [FEE0_h -

Re: [PATCH] mmc: sdhci-of-at91: fix card detect when using runtime PM

On Thu, Feb 11, 2016 at 04:10:54PM +0100, Ulf Hansson wrote: > On 11 February 2016 at 14:48, Ludovic Desroches > wrote: > > Add quirk broken card detection to enable card detection polling. It is > > a short term solution until reworking PM stuff. > > > > If the card

[RFC v2] vfs 64 bit time transition proposals

Introduction This is a follow on to the series: https://lkml.org/lkml/2016/1/7/20 [1]. This is aimed at reaching a consensus on how to transition the vfs timestamps to use 64 bit time. This demonstrates three ways (2a, 2b and 2c) of solving this problem. Each of the proposals has its own cover

Re: [PATCH] MAINTAINERS: mmc: Add Adrian Hunter as the maintainer for SDHCI

On 11/02/16 16:14, Ulf Hansson wrote: >>From discussions on linux-mmc I have been encouraging someone to pick > up the maintainer role for SDHCI. I am very pleased that Adrian Hunter > volunteered and accepted the challenge! > > The SDHCI code is currently in quite poor quality, but we have

Re: [PATCH 4/4] mailbox: mailbox-test: add support for separate tx/rx buffer with single channel

On 12/02/16 09:15, Lee Jones wrote: On Thu, 11 Feb 2016, Sudeep Holla wrote: [...] @@ -294,9 +295,13 @@ static int mbox_test_probe(struct platform_device *pdev) /* It's okay for MMIO to be NULL */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - tdev->mmio =

Re: [PATCH v2 6/6] serial: 8250/ingenic: fix building with SERIAL_8250=m

Hi Arnd, 2016-02-12 0:41 GMT+09:00 Arnd Bergmann : > The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that > breaks when SERIAL_8250 is a loadable module: > > drivers/tty/built-in.o: In function `ingenic_uart_probe': > 8250_ingenic.c:(.text+0x1c1a0): undefined reference to

[RFC v2c 6/8] fs: btrfs: Use vfs timestamp abstraction helper

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use timespec64 and conversion functions here to access inode times.

[RFC v2c 8/8] fs: xfs: change inode times to use vfs_time data type

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use timespec64 and conversion functions here to access inode times.

[RFC v2c 4/8] fs: cifs: Make cnvrtDosUnixTm() y2038 safe

The seconds calculated from the server(DOS format) cannot be saved in int data type as this cannot save seconds since epoch after the year 2038. Use long long for seconds field in cnvrtDosUnixTm(). This will help represent 64 bit time even on 32 bit systems. Note that even though the theoretical

[RFC v2c 7/8] fs: ceph: Use vfs timestamp abstraction helpers

The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use timespec64 and conversion functions here to access inode times.

[RFC v2c 2/8] fs: cifs: Change auxdata to struct timespec64 data type

Aux data timestamps are only used to read in inode timestamps for fscache. The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file

Re: [PATCH V4 15/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region.

On 10.02.2016 15:06, Lorenzo Pieralisi wrote: On Thu, Feb 04, 2016 at 06:28:53PM +0100, Tomasz Nowicki wrote: >Lets abstract two calls which allow to inject and remove MCFG regions >which may come from DSDT table. These calls will be used for x86 and ARM64 >PCI host bridge driver in the later

Re: [PATCH 3/4] mailbox: mailbox-test: use print_hex_dump_bytes to allow dynamic printk

On Thu, 11 Feb 2016, Sudeep Holla wrote: > Reduce the logging from info to debug. Also use print_hex_dump_bytes > instead as it has support for dynamic printk providing options to > conditionally enable/disable these logs. Printing out the data in this way is kinda the point of the driver. But

Re: [Xen-devel] [PATCH 2/4] xen/pciback: Save the number of MSI-X entries to be copied later.

>>> On 11.02.16 at 22:10, wrote: > c/s 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 > "xen/pciback: Save xen_pci_op commands before processing it" > would copyback the processed values - which was great. > > However it missed the case that xen_pcibk_enable_msix - when >

Re: wlcore: Fix regression in wlcore_set_partition()

> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a > regression causing the wlcore to time out and go into recovery. Reverting the > changes regarding write of the last partition size brings the module back to > it's functional state. > > Fixes: 3719c17e1816

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote: > On Thu, 11 Feb 2016 21:09:42 +0200 > "Kirill A. Shutemov" wrote: > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote: > > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1

Re: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build

On Friday 12 February 2016 18:37:08 Masahiro Yamada wrote: > > }; > > > > -#ifdef CONFIG_SERIAL_8250_CONSOLE > > +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE) > > static int __init uniphier_early_console_setup(struct earlycon_device > > *device, > >

[PATCH] net: phy: spi_ks8995: add dependency on GPIO

The builds of allmodconfig of s390, m68k, tilegx, tilepro is failing with the error: drivers/net/phy/spi_ks8995.c:477:3: error: implicit declaration of function 'gpiod_set_value' drivers/net/phy/spi_ks8995.c:477:19: error: implicit declaration of function 'gpio_to_desc' GPIO is now used to

Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base

On 11/02/16 23:15, Rob Herring wrote: > On Thu, Feb 11, 2016 at 5:04 AM, Marc Zyngier wrote: >> On 09/02/16 11:04, Robin Murphy wrote: >>> The existing msi-map code is fine for shifting the entire RID space >>> upwards, but attempting finer-grained remapping reveals a bug.

[PATCH v5 2/5] drm/dsi: Use mipi_dsi_device_register_full for DSI device creation

Use mipi_dsi_device_register_full for device creation. This takes in mipi_dsi_device_info as a template to populate the DSI device information. The reason to introduce this is to have a way to create DSI devices not available via DT. Drivers that want to create a DSI device can populate

[PATCH v5 0/5] drm/dsi: DSI for devices with different control bus

We are currently restricted when it comes to supporting DSI on devices that have a non-DSI control bus. For example, DSI encoder chips are available in the market that are configured via i2c. Configuring their registers via DSI bus is either optional or not available at all. These devices still

[PATCH v5 3/5] drm/dsi: Try to match non-DT DSI devices

Add a device name field in mipi_dsi_device. This name is different from the actual dev name (which is of the format "hostname.reg"). When the device is created via DT, this name is set to the modalias string. In the non-DT case, the driver creating the DSI device provides the name by populating a

[PATCH v5 5/5] drm/dsi: Get DSI host by DT device node

MIPI DSI devices are inherently aware of their host because they share a parent-child hierarchy in the device tree. Non-DSI drivers that create DSI device don't have this data. In order to get this information, they require to a phandle to the DSI host in the device tree. Maintain a list of all

[PATCH v5 4/5] drm/dsi: Add routine to unregister a DSI device

A driver calling mipi_dsi_device_register_full might want to unregister the device once it's done. It might also require it in an error handling path in case something didn't go right. Create mipi_dsi_device_unregister for this purpse, use it within mipi_dsi_remove_device_fn as it does the same

[PATCH v2 0/2] clk: sunxi: Fix APBS clock for Allwinner A80

Hi everyone, This is v2 of the A80 APBS clock fixes series. When I did the A80 PRCM support, I failed to notice the A80's APBS clock was not the same as the A23's APB0 clock. The former is a zero-based divider, while the latter is a power-of-two divider. But the lowest 2 dividers are the same.

[PATCH v2 1/2] clk: sunxi: Add support for A80 APBS clock

A80's APBS clock is not the same as the APB0 clock on A23. The A80's is a zero-based divider, while the A23's is a power-of-two divider. Replace the CLK_OF_DECLARE version of sun8i-a23-apb0. This also extends the common setup function to take div clk flags. Signed-off-by: Chen-Yu Tsai

[PATCH v2 2/2] ARM: dts: sun9i: Fix apbs clock compatible

The APBS clock on A80 is not compatible with A23's APB0 clock. The only reason it works is becase the lowest and default divider is the same. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun9i-a80.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 3/4] mailbox: mailbox-test: use print_hex_dump_bytes to allow dynamic printk

On 12/02/16 09:12, Lee Jones wrote: On Thu, 11 Feb 2016, Sudeep Holla wrote: Reduce the logging from info to debug. Also use print_hex_dump_bytes instead as it has support for dynamic printk providing options to conditionally enable/disable these logs. Printing out the data in this way is

[RFC v2b 0/5] vfs 64 bit time transition proposal

Introduction The series is one of the proposals on how to transition VFS timestamps to use 64 bit time. This idea was proposed by Arnd Bergmann and David Chinner on the RFC: https://lkml.org/lkml/2016/1/7/20 [1]. Solution 1.Define accessor functions for inode timestamps. 2.Change all individual

Re: [PATCH v2] ARM: mm: mark section-aligned portion of rodata NX

On Thursday 11 February 2016 18:00:32 Russell King - ARM Linux wrote: > On Fri, Jan 22, 2016 at 01:19:03PM -0800, Kees Cook wrote: > > On Tue, Dec 8, 2015 at 10:38 AM, Kees Cook wrote: > > > On Mon, Dec 7, 2015 at 11:47 PM, Ard Biesheuvel > > >

[RFC v2b 1/5] vfs: Add vfs_time accessors

Add vfs_time accessors to help convert vfs timestamps to use 64 bit times. These create an abstraction layer so that vfs inode times can be switched to use struct timespec64 from struct timespec without breaking the individual filesystems after they have incorporated these. Use uapi exposed data

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Fri, 12 Feb 2016, Will Deacon wrote: > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote: > > On Thu, 11 Feb 2016 21:09:42 +0200 > > "Kirill A. Shutemov" wrote: > > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote: > > > > Sebastian Ott

Re: [PATCH V3 06/10] irqchip, GICv3, ITS: Refator ITS dt init code to prepare for ACPI.

On 10.02.2016 11:47, Marc Zyngier wrote: On 19/01/16 13:11, Tomasz Nowicki wrote: Similarly to GICv3 core, we need to extract common code before adding ACPI support. No functional changes. Signed-off-by: Hanjun Guo Signed-off-by: Tomasz Nowicki ---

[PATCH v2] serial: earlycon: rework common framework for earlycon declarations

this is the same behavior as before. Fixes: 2eaa790989e0 ("earlycon: Use common framework for earlycon declarations") Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- I confirmed this patch can apply onto "next-20160212" tag of linux-next. In order to apply i

[PATCH] net: phy: spi_ks8995: include linux/gpio/consumer.h

The ks8995 phy driver just started using gpiod_* functions, which are declared in linux/gpio/consumer.h, not linux/gpio.h, resulting in a build failure in randconfig builds that do not have CONFIG_GPIOLIB enabled: drivers/net/phy/spi_ks8995.c: In function 'ks8995_probe':

[PATCH v2] Platform: goldfish: goldfish_pipe.c: Add DMA support using managed version

Coherent mapping guarantees that the device and CPU are in sync. Signed-off-by: Shraddha Barke --- Changes in v2- Updated commit message and removed error message. drivers/platform/goldfish/goldfish_pipe.c | 14 +++--- 1 file changed, 7 insertions(+), 7

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

On Thu, Feb 11, 2016 at 03:47:12PM -0800, Andy Lutomirski wrote: > Can you send all the fpu info that the kernel prints really early when it > boots? $ dmesg | grep -i fpu [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Supporting XSAVE feature 0x01:

Re: [PATCH v8 2/4] tee: generic TEE subsystem

On Fri, Feb 12, 2016 at 04:51:59AM +, Al Viro wrote: > On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote: > > > +static int tee_ioctl_shm_alloc(struct tee_context *ctx, > > + struct tee_ioctl_shm_alloc_data __user *udata) > > +{ > > + long ret; > > + struct

Re: [PATCH 2/4] mmc: dw_mmc: add setup_clk for init hook

On 2016/2/4 14:04, Jaehoon Chung wrote: Hi, Shawn. On 01/28/2016 10:31 AM, Shawn Lin wrote: We add this new argument into init hook for variant drivers to decide whether to do clock related stuff inside the hook. Signed-off-by: Shawn Lin ---

Re: [PATCH 05/54] perf data: Fix releasing event_class

On Thu, Feb 11, 2016 at 07:04:13PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Feb 05, 2016 at 02:01:30PM +, Wang Nan escreveu: > > A new patch of libbabeltrace [1] reveals a object leak problem in > > perf data CTF support: perf code never release event_class which is > > allocated in

[PATCH v2 6/8] power: cros_usbpd-charger: Add EC-based USB PD charger driver

From: Sameer Nanda This driver exposes the charger functionality in the PD EC to userspace. Signed-off-by: Tomeu Vizoso Cc: Sameer Nanda Cc: Benson Leung Cc: Shawn Nematbakhsh ---

[PATCH v2 7/8] platform/chrome: Register USB PD charger device

Check if a EC considers EC_CMD_USB_PD_PORTS a valid command and register a USB PD charger device if so. This check is needed for older versions of the ChromeOS EC firmware that don't support the EC_CMD_GET_FEATURES command. Signed-off-by: Tomeu Vizoso --- Changes in

[PATCH v2 4/8] mfd: cros_ec: Add cros_ec_get_host_event

This function returns the code for the host event that triggered the interrupt that is being currently handled. Is to be used by observers of the event_notifier in the EC device. Signed-off-by: Tomeu Vizoso --- Changes in v2: None

Re: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen

On Fri, Feb 12, 2016 at 12:50 PM, Stefano Stabellini wrote: > On Thu, 11 Feb 2016, Rafael J. Wysocki wrote: >> On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote: >> > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote: >> > > On Tuesday, February 09,

[PATCH v2 1/8] mfd: cros_ec: Add MKBP event support

From: Vic Yang Newer revisions of the ChromeOS EC add more events besides the keyboard ones. So handle interrupts in the MFD driver and let consumers register for notifications for the events they might care. To keep backward compatibility, if the EC doesn't support MKBP

  1   2   3   4   5   6   7   8   9   10   >