[PATCH 7/7] mm: kill arch_mremap

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and commit 2ae416b142b6 ("mm: new mm hook framework"). It also keeps the same functionality of mremapping vDSO blob with introducing vm_special_mapping mremap op for powerpc. Cc: Laurent Dufour Cc:

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

On 10/25/16 20:42, Alex Williamson wrote: > On Tue, 25 Oct 2016 20:24:19 +0200 > Laszlo Ersek wrote: > >> Some systems have multiple instances of the exact same kind of PCI device >> installed. When VFIO users intend to assign these devices to VMs, they >> occasionally don't want to assign all

Applied "ASoC: tlv320aic31xx: add explicit support for tlv320dac31xx" to the asoc tree

The patch ASoC: tlv320aic31xx: add explicit support for tlv320dac31xx has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH 7/7] mm: kill arch_mremap

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and commit 2ae416b142b6 ("mm: new mm hook framework"). It also keeps the same functionality of mremapping vDSO blob with introducing vm_special_mapping mremap op for powerpc. Cc: Laurent Dufour Cc: Benjamin Herrenschmidt Cc: Paul

[PATCH] iio: si7020: Add devicetree support and trivial bindings

This adds devicetree support for the si7020 iio driver. Since it works well without requiring any additional property, its compatible string is added to the trivial i2c devices bindings list. Signed-off-by: Paul Kocialkowski ---

Re: [RFC 5/8] mm: Add new flag VM_CDM for coherent device memory

Dave Hansen writes: > On 10/23/2016 09:31 PM, Anshuman Khandual wrote: >> VMAs containing coherent device memory should be marked with VM_CDM. These >> VMAs need to be identified in various core kernel paths and this new flag >> will help in this regard. > > ... and it's

[PATCH] iio: si7020: Add devicetree support and trivial bindings

This adds devicetree support for the si7020 iio driver. Since it works well without requiring any additional property, its compatible string is added to the trivial i2c devices bindings list. Signed-off-by: Paul Kocialkowski --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +

Re: [RFC 5/8] mm: Add new flag VM_CDM for coherent device memory

Dave Hansen writes: > On 10/23/2016 09:31 PM, Anshuman Khandual wrote: >> VMAs containing coherent device memory should be marked with VM_CDM. These >> VMAs need to be identified in various core kernel paths and this new flag >> will help in this regard. > > ... and it's sticky? So if a VMA

Re: [PATCH 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

On 10/25/2016 08:52 AM, Alexandre Bailon wrote: If we configure the da8xx OTG phy in OTG mode, neither device or host mode will work. That is because the PHY is not able to detect and notify the driver that value of ID pin changed. To work despite this hardware limitation, the da8xx glue

Re: [PATCH 2/3] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

On 10/25/2016 08:52 AM, Alexandre Bailon wrote: If we configure the da8xx OTG phy in OTG mode, neither device or host mode will work. That is because the PHY is not able to detect and notify the driver that value of ID pin changed. To work despite this hardware limitation, the da8xx glue

Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

On Mon, Oct 24, 2016 at 10:37:53PM +0200, Arnd Bergmann wrote: > I think my patch (the version I sent) should ideally make it into > v4.9 as a bugfix. This was the powerpc warning I saw from Olof's > autobuilder with the -Wmaybe-uninitialized warning added back, and > it's one of the actual bugs

Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

On Mon, Oct 24, 2016 at 10:37:53PM +0200, Arnd Bergmann wrote: > I think my patch (the version I sent) should ideally make it into > v4.9 as a bugfix. This was the powerpc warning I saw from Olof's > autobuilder with the -Wmaybe-uninitialized warning added back, and > it's one of the actual bugs

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

On 10/25/2016 09:04 PM, Colin King wrote: > From: Colin Ian King > > In the case that the read size is not 2 or 4 bytes > then maxim_thermocouple_read is not initializing ret and > hence may return early with a bogus error return or > just through to return with a bogos

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

On 10/25/2016 09:04 PM, Colin King wrote: > From: Colin Ian King > > In the case that the read size is not 2 or 4 bytes > then maxim_thermocouple_read is not initializing ret and > hence may return early with a bogus error return or > just through to return with a bogos unread value in *val. >

Re: [PATCH 1/3] usb: musb: da8xx: Call earlier clk_prepare_enable()

On 10/25/2016 08:52 AM, Alexandre Bailon wrote: The first attempt to read a register may fail because the clock may not be enabled, and then the probe of musb driver will fail. Call clk_prepare_enable() before the first register read. Signed-off-by: Alexandre Bailon ---

Re: [PATCH 1/3] usb: musb: da8xx: Call earlier clk_prepare_enable()

On 10/25/2016 08:52 AM, Alexandre Bailon wrote: The first attempt to read a register may fail because the clock may not be enabled, and then the probe of musb driver will fail. Call clk_prepare_enable() before the first register read. Signed-off-by: Alexandre Bailon ---

[PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

From: Colin Ian King In the case that the read size is not 2 or 4 bytes then maxim_thermocouple_read is not initializing ret and hence may return early with a bogus error return or just through to return with a bogos unread value in *val. Fix this by setting ret to

[PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

From: Colin Ian King In the case that the read size is not 2 or 4 bytes then maxim_thermocouple_read is not initializing ret and hence may return early with a bogus error return or just through to return with a bogos unread value in *val. Fix this by setting ret to -EINVAL for invalid

[PATCH] usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

This suppresses printing the error message "failed to get phy" in the kernel log when the error is -EPROBE_DEFER. This prevents usless noise in the kernel log. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH] usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

This suppresses printing the error message "failed to get phy" in the kernel log when the error is -EPROBE_DEFER. This prevents usless noise in the kernel log. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH V2 8/8] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators()

On 10/20, Viresh Kumar wrote: > If a platform specific OPP driver has called this routine first and set > the regulators, then the second call from cpufreq-dt driver will hit the > WARN_ON(). Remove the WARN_ON(), but continue to return error in such > cases. > > Signed-off-by: Viresh Kumar

Re: [PATCH V2 8/8] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators()

On 10/20, Viresh Kumar wrote: > If a platform specific OPP driver has called this routine first and set > the regulators, then the second call from cpufreq-dt driver will hit the > WARN_ON(). Remove the WARN_ON(), but continue to return error in such > cases. > > Signed-off-by: Viresh Kumar >

Re: [PATCH V2 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks

On 10/20, Viresh Kumar wrote: > The generic opp_set_rate() handler isn't sufficient for platforms with > complex DVFS. For example, some TI platforms have multiple regulators > for a CPU device. The order in which various supplies need to be > programmed is only known to the platform code and its

Re: [PATCH V2 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks

On 10/20, Viresh Kumar wrote: > The generic opp_set_rate() handler isn't sufficient for platforms with > complex DVFS. For example, some TI platforms have multiple regulators > for a CPU device. The order in which various supplies need to be > programmed is only known to the platform code and its

Re: [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate()

On 10/20, Viresh Kumar wrote: > Later patches would add support for custom opp_set_rate callbacks. This I know the OPP consumer function has "rate" in the name, but it makes more sense to call the callback set_opp instead because we could be doing a lot more than setting the opp rate. > patch

Re: [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate()

On 10/20, Viresh Kumar wrote: > Later patches would add support for custom opp_set_rate callbacks. This I know the OPP consumer function has "rate" in the name, but it makes more sense to call the callback set_opp instead because we could be doing a lot more than setting the opp rate. > patch

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

On 10/25/2016 11:57 AM, Tobias Jakobi wrote: > Hello Shuah, > > > Shuah Khan wrote: >> On 10/19/2016 04:27 PM, Shuah Khan wrote: >>> On 10/19/2016 08:16 AM, Inki Dae wrote: Hi Shuah, 2016-10-13 8:11 GMT+09:00 Shuah Khan : > Hi Inki, > > On

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

On 10/25/2016 11:57 AM, Tobias Jakobi wrote: > Hello Shuah, > > > Shuah Khan wrote: >> On 10/19/2016 04:27 PM, Shuah Khan wrote: >>> On 10/19/2016 08:16 AM, Inki Dae wrote: Hi Shuah, 2016-10-13 8:11 GMT+09:00 Shuah Khan : > Hi Inki, > > On 08/15/2016 10:40 PM, Inki Dae

Re: [RFC 0/8] Define coherent device memory node

On Tue, Oct 25, 2016 at 11:01:08PM +0530, Aneesh Kumar K.V wrote: > Jerome Glisse writes: > > > On Tue, Oct 25, 2016 at 10:29:38AM +0530, Aneesh Kumar K.V wrote: > >> Jerome Glisse writes: > >> > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual

Re: [RFC 0/8] Define coherent device memory node

On Tue, Oct 25, 2016 at 11:01:08PM +0530, Aneesh Kumar K.V wrote: > Jerome Glisse writes: > > > On Tue, Oct 25, 2016 at 10:29:38AM +0530, Aneesh Kumar K.V wrote: > >> Jerome Glisse writes: > >> > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > > > > [...] > > > >> > You can

Re: [PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

On 10/25/2016 08:44 PM, Colin King wrote: > From: Colin Ian King > > For a IIO_VOLTAGE case, ret is not being set causing an > uninitialized value being returned by ad7746_read_raw. Fix > this by setting ret to IIO_VAL_INT for this specific case. > > Signed-off-by:

Re: [PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

On 10/25/2016 08:44 PM, Colin King wrote: > From: Colin Ian King > > For a IIO_VOLTAGE case, ret is not being set causing an > uninitialized value being returned by ad7746_read_raw. Fix > this by setting ret to IIO_VAL_INT for this specific case. > > Signed-off-by: Colin Ian King Arnd did

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek wrote: > On Mon 2016-10-24 12:58:25, Matt Ranostay wrote: >> Pavel + Sebastian this is the patchset that need I some input on :) > > Better then previous one. > > But my version of bq27xxx_battery.c already contains this: This is for

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek wrote: > On Mon 2016-10-24 12:58:25, Matt Ranostay wrote: >> Pavel + Sebastian this is the patchset that need I some input on :) > > Better then previous one. > > But my version of bq27xxx_battery.c already contains this: This is for allowing udev

[PATCH] lib/genalloc.c: Start search from start of chunk

gen_pool_alloc_algo() iterates over the chunks of a pool trying to find a contiguous block of memory that satisfies the allocation request. The shortcut if (size > atomic_read(>avail)) continue; makes the loop skip over chunks that do not have enough bytes left to

[PATCH] lib/genalloc.c: Start search from start of chunk

gen_pool_alloc_algo() iterates over the chunks of a pool trying to find a contiguous block of memory that satisfies the allocation request. The shortcut if (size > atomic_read(>avail)) continue; makes the loop skip over chunks that do not have enough bytes left to

[PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

From: Colin Ian King For a IIO_VOLTAGE case, ret is not being set causing an uninitialized value being returned by ad7746_read_raw. Fix this by setting ret to IIO_VAL_INT for this specific case. Signed-off-by: Colin Ian King ---

[PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

From: Colin Ian King For a IIO_VOLTAGE case, ret is not being set causing an uninitialized value being returned by ad7746_read_raw. Fix this by setting ret to IIO_VAL_INT for this specific case. Signed-off-by: Colin Ian King --- drivers/staging/iio/cdc/ad7746.c | 1 + 1 file changed, 1

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

On Tue, 25 Oct 2016 20:24:19 +0200 Laszlo Ersek wrote: > Some systems have multiple instances of the exact same kind of PCI device > installed. When VFIO users intend to assign these devices to VMs, they > occasionally don't want to assign all of them; they'd keep a few for >

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

On Tue, 25 Oct 2016 20:24:19 +0200 Laszlo Ersek wrote: > Some systems have multiple instances of the exact same kind of PCI device > installed. When VFIO users intend to assign these devices to VMs, they > occasionally don't want to assign all of them; they'd keep a few for > host-side use. The

Re: [PATCH] cw1200: fix bogus maybe-uninitialized warning

On Tue, Oct 25, 2016 at 01:24:55PM +, David Laight wrote: > > - if (count > 1) { > > - /* We already released one buffer, now for the rest */ > > - ret = wsm_release_tx_buffer(priv, count - 1); > > - if (ret < 0) > > - return ret; > > -

Re: [PATCH] cw1200: fix bogus maybe-uninitialized warning

On Tue, Oct 25, 2016 at 01:24:55PM +, David Laight wrote: > > - if (count > 1) { > > - /* We already released one buffer, now for the rest */ > > - ret = wsm_release_tx_buffer(priv, count - 1); > > - if (ret < 0) > > - return ret; > > -

Re: [PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

On 10/21/2016 10:18 PM, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Apparently trying to poke a disabled or non-existent APIC > leads to a box that doesn't even boot. Let's not do that. > > No real clue if this is the right fix, but at least

Re: [PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

On 10/21/2016 10:18 PM, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Apparently trying to poke a disabled or non-existent APIC > leads to a box that doesn't even boot. Let's not do that. > > No real clue if this is the right fix, but at least my > P3 machine boots again. >

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

On 10/24/2016 05:46 AM, Yuriy Kolerov wrote: > Originally an initial distribution mode (its value resides in Device Tree) > for each common interrupt is set in idu_irq_xlate. This leads to the > following problems. idu_irq_xlate may be called several times during parsing > of the Device Tree and

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

On 10/24/2016 05:46 AM, Yuriy Kolerov wrote: > Originally an initial distribution mode (its value resides in Device Tree) > for each common interrupt is set in idu_irq_xlate. This leads to the > following problems. idu_irq_xlate may be called several times during parsing > of the Device Tree and

[PATCH v4 1/1] workqueue: ignore dead tasks in a workqueue sleep hook

If panic_on_oops is not set and oops happens inside workqueue kthread, kernel kills this kthread. Current patch fixes recursive GPF which happens when wq_worker_sleeping() function unconditionally accesses the NULL kthread->vfork_done ptr thru kthread_data() -> to_kthread(). The stack is the

[PATCH v4 1/1] workqueue: ignore dead tasks in a workqueue sleep hook

If panic_on_oops is not set and oops happens inside workqueue kthread, kernel kills this kthread. Current patch fixes recursive GPF which happens when wq_worker_sleeping() function unconditionally accesses the NULL kthread->vfork_done ptr thru kthread_data() -> to_kthread(). The stack is the

Re: [PATCH -next 1/2] Input: synaptics-rmi4 - add support for F55 sensor tuning

On 10/24/2016 08:13 PM, Guenter Roeck wrote: Hi Andrew, On 10/24/2016 05:59 PM, Andrew Duggan wrote: Hi Guenter, I have a couple of comments below. Thanks a lot for the feedback. On 09/30/2016 08:22 PM, Guenter Roeck wrote: Sensor tuning support is needed to determine the number of

Re: [PATCH -next 1/2] Input: synaptics-rmi4 - add support for F55 sensor tuning

On 10/24/2016 08:13 PM, Guenter Roeck wrote: Hi Andrew, On 10/24/2016 05:59 PM, Andrew Duggan wrote: Hi Guenter, I have a couple of comments below. Thanks a lot for the feedback. On 09/30/2016 08:22 PM, Guenter Roeck wrote: Sensor tuning support is needed to determine the number of

[PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

Some systems have multiple instances of the exact same kind of PCI device installed. When VFIO users intend to assign these devices to VMs, they occasionally don't want to assign all of them; they'd keep a few for host-side use. The current ID- and class-based matching in pci-stub doesn't

[PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

Some systems have multiple instances of the exact same kind of PCI device installed. When VFIO users intend to assign these devices to VMs, they occasionally don't want to assign all of them; they'd keep a few for host-side use. The current ID- and class-based matching in pci-stub doesn't

Re: [PATCH] gpio: gpiolib-devprop: Check chip->parent pointer before dereferencing

On Tue, Oct 25, 2016 at 6:31 PM, wrote: > From: Thor Thayer > > Confirm the chip->parent is valid before dereferencing because > the parent parameter is optional. > > Signed-off-by: Thor Thayer I

Re: [PATCH] gpio: gpiolib-devprop: Check chip->parent pointer before dereferencing

On Tue, Oct 25, 2016 at 6:31 PM, wrote: > From: Thor Thayer > > Confirm the chip->parent is valid before dereferencing because > the parent parameter is optional. > > Signed-off-by: Thor Thayer I wish it wasn't. Not much to do about though. Patch applied. Yours, Linus Walleij

Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq

On Tue, Oct 25, 2016 at 5:31 PM, Jerome Brunet wrote: > On Tue, 2016-10-25 at 15:47 +0100, Marc Zyngier wrote: >> Is gpio_to_irq() supposed to allocate an interrupt? Or merely to >> report the existence of a mapping? It should provide an IRQ corresponding to the gpio line,

Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq

On Tue, Oct 25, 2016 at 5:31 PM, Jerome Brunet wrote: > On Tue, 2016-10-25 at 15:47 +0100, Marc Zyngier wrote: >> Is gpio_to_irq() supposed to allocate an interrupt? Or merely to >> report the existence of a mapping? It should provide an IRQ corresponding to the gpio line, if possible. However

Re: dm block manager: use do/while(0) for empty macros

On Tue, Oct 25 2016 at 11:54am -0400, Arnd Bergmann wrote: > make W=1 reports a new warning for the dm-block-manager: > > drivers/md/persistent-data/dm-block-manager.c: In function ‘dm_bm_unlock’: > drivers/md/persistent-data/dm-block-manager.c:598:3: error: suggest braces >

Re: dm block manager: use do/while(0) for empty macros

On Tue, Oct 25 2016 at 11:54am -0400, Arnd Bergmann wrote: > make W=1 reports a new warning for the dm-block-manager: > > drivers/md/persistent-data/dm-block-manager.c: In function ‘dm_bm_unlock’: > drivers/md/persistent-data/dm-block-manager.c:598:3: error: suggest braces > around empty body

RE: [PATCH v2 5/5] ARC: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

> -Original Message- > From: Vineet Gupta [mailto:vgu...@synopsys.com] > Sent: Tuesday, October 25, 2016 8:53 PM > To: Yuriy Kolerov ; linux-snps- > a...@lists.infradead.org > Cc: marc.zyng...@arm.com; vineet.gup...@synopsys.com; > alexey.brod...@synopsys.com;

RE: [PATCH v2 5/5] ARC: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

> -Original Message- > From: Vineet Gupta [mailto:vgu...@synopsys.com] > Sent: Tuesday, October 25, 2016 8:53 PM > To: Yuriy Kolerov ; linux-snps- > a...@lists.infradead.org > Cc: marc.zyng...@arm.com; vineet.gup...@synopsys.com; > alexey.brod...@synopsys.com; linux-kernel@vger.kernel.org;

Re: [PATCH v3 1/1] workqueue: ignore dead tasks in a workqueue sleep hook

On Tue, Oct 25, 2016 at 6:08 PM, Oleg Nesterov wrote: > sorry for noise, forgot to mention... > > On 10/25, Oleg Nesterov wrote: >> >> On 10/25, Oleg Nesterov wrote: >> > >> > void oops_end_exit(void) >> > { >> > current->flags &= ~PF_WQ_WORKER; >> >

Re: [PATCH v3 1/1] workqueue: ignore dead tasks in a workqueue sleep hook

On Tue, Oct 25, 2016 at 6:08 PM, Oleg Nesterov wrote: > sorry for noise, forgot to mention... > > On 10/25, Oleg Nesterov wrote: >> >> On 10/25, Oleg Nesterov wrote: >> > >> > void oops_end_exit(void) >> > { >> > current->flags &= ~PF_WQ_WORKER; >> > perhaps

Re: [PATCH] PM / Domains: check for negative return from of_count_phandle_with_args

Colin King writes: > From: Colin Ian King > > The return from of_count_phandle_with_args can be negative, so we > should avoid kcalloc of a negative count of genpd_power_stat structs > by sanity checking if count is zero or less. > >

Re: [PATCH] PM / Domains: check for negative return from of_count_phandle_with_args

Colin King writes: > From: Colin Ian King > > The return from of_count_phandle_with_args can be negative, so we > should avoid kcalloc of a negative count of genpd_power_stat structs > by sanity checking if count is zero or less. > > Signed-off-by: Colin Ian King Acked-by: Kevin Hilman >

Re: [PATCH v2 2/6] perf report: Caculate and return the branch counting in callchain

Em Fri, Oct 21, 2016 at 08:23:41AM +0800, Jin, Yao escreveu: > Hi Andi, Hi Nilay, > > Thanks so much for your comments! > > I will upgrade the patch to just display the count for abort. Ok, waiting for that then, - Arnaldo > Thanks > > Jin Yao > > On 10/21/2016 2:20 AM, Andi Kleen wrote: >

Re: [PATCH v2 2/6] perf report: Caculate and return the branch counting in callchain

Em Fri, Oct 21, 2016 at 08:23:41AM +0800, Jin, Yao escreveu: > Hi Andi, Hi Nilay, > > Thanks so much for your comments! > > I will upgrade the patch to just display the count for abort. Ok, waiting for that then, - Arnaldo > Thanks > > Jin Yao > > On 10/21/2016 2:20 AM, Andi Kleen wrote: >

Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq

On Tue, Oct 25, 2016 at 4:47 PM, Marc Zyngier wrote: > On 25/10/16 15:22, Jerome Brunet wrote: >> There is a few problems to guarantee that gpio == hwirq. >> 1. We have 2 instances of pinctrl, to guarantee that the linux gpio >> number == hwirq, we would have to guarantee

Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq

On Tue, Oct 25, 2016 at 4:47 PM, Marc Zyngier wrote: > On 25/10/16 15:22, Jerome Brunet wrote: >> There is a few problems to guarantee that gpio == hwirq. >> 1. We have 2 instances of pinctrl, to guarantee that the linux gpio >> number == hwirq, we would have to guarantee the order in which they

Re: [PATCH 00/14] staging: fsl-mc: cleanup and uprev to MC v10.x

On Tue, Oct 25, 2016 at 03:43:56PM +, Stuart Yoder wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Tuesday, October 25, 2016 2:50 AM > > To: Stuart Yoder > > Cc: German Rivera ;

Re: [PATCH 00/14] staging: fsl-mc: cleanup and uprev to MC v10.x

On Tue, Oct 25, 2016 at 03:43:56PM +, Stuart Yoder wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Tuesday, October 25, 2016 2:50 AM > > To: Stuart Yoder > > Cc: German Rivera ; de...@driverdev.osuosl.org; > >

[PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Signed-off-by: Bhumika Goyal ---

[PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Signed-off-by: Bhumika Goyal ---

[PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Signed-off-by: Bhumika Goyal ---

[PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Signed-off-by: Bhumika Goyal ---

Re: [PATCH 1/3] perf sched map: Apply cpu color when there's an activity

Em Mon, Oct 24, 2016 at 11:02:43AM +0900, Namhyung Kim escreveu: > Applying cpu color always doesn't help readability IMHO. Instead it > might be better to applying the color when there's an activity on those > CPUs. thanks, applied the three patches. - Arnaldo > Cc: Jiri Olsa

[PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Also, replace __initdata with __initconst.

Re: [PATCH 1/3] perf sched map: Apply cpu color when there's an activity

Em Mon, Oct 24, 2016 at 11:02:43AM +0900, Namhyung Kim escreveu: > Applying cpu color always doesn't help readability IMHO. Instead it > might be better to applying the color when there's an activity on those > CPUs. thanks, applied the three patches. - Arnaldo > Cc: Jiri Olsa >

[PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures

Check for iommu_gather_ops structures that are only stored in the tlb field of an io_pgtable_cfg structure. The tlb field is of type const struct iommu_gather_ops *, so iommu_gather_ops structures having this property can be declared as const. Also, replace __initdata with __initconst.

[PATCH 0/3] drivers: iommu: declare iommu_gather_ops structures as const

Constify iommu_gather_ops structures and replace __initdata with __initconst where needed. Bhumika Goyal (3): drivers: iommu: arm-smmu: constify iommu_gather_ops structures drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures drivers: iommu: io-pgtable-arm: use const and

[PATCH 0/3] drivers: iommu: declare iommu_gather_ops structures as const

Constify iommu_gather_ops structures and replace __initdata with __initconst where needed. Bhumika Goyal (3): drivers: iommu: arm-smmu: constify iommu_gather_ops structures drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures drivers: iommu: io-pgtable-arm: use const and

Re: [RFC v3 1/6] Track the active utilisation

On Tue, 25 Oct 2016 09:58:11 -0400 Steven Rostedt wrote: > On Tue, 25 Oct 2016 11:29:16 +0200 > luca abeni wrote: > > > Hi Daniel, > > > > On Tue, 25 Oct 2016 11:09:52 +0200 > > Daniel Bristot de Oliveira wrote: > > [...] > > > >

Re: [RFC v3 1/6] Track the active utilisation

On Tue, 25 Oct 2016 09:58:11 -0400 Steven Rostedt wrote: > On Tue, 25 Oct 2016 11:29:16 +0200 > luca abeni wrote: > > > Hi Daniel, > > > > On Tue, 25 Oct 2016 11:09:52 +0200 > > Daniel Bristot de Oliveira wrote: > > [...] > > > > +static void add_running_bw(struct sched_dl_entity *dl_se, > >

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, 2016-10-25 at 10:55 -0700, Linus Torvalds wrote: > And yes, what we probably *should* do is to do the newline breaking > when adding things to the log, rather than doing it in the > "msg_print_text()" phase. Yeah. One thing that'd be nice one day is to remove all the #define pr_fmt(fmt)

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, 2016-10-25 at 10:55 -0700, Linus Torvalds wrote: > And yes, what we probably *should* do is to do the newline breaking > when adding things to the log, rather than doing it in the > "msg_print_text()" phase. Yeah. One thing that'd be nice one day is to remove all the #define pr_fmt(fmt)

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, Oct 25, 2016 at 10:38:31AM -0700, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland wrote: > > > > That does not appear to be the case; as fr as I can tell the core prints a > > timestamp per line as required. If I run: > > > >

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, Oct 25, 2016 at 10:38:31AM -0700, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland wrote: > > > > That does not appear to be the case; as fr as I can tell the core prints a > > timestamp per line as required. If I run: > > > >

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hello Shuah, Shuah Khan wrote: > On 10/19/2016 04:27 PM, Shuah Khan wrote: >> On 10/19/2016 08:16 AM, Inki Dae wrote: >>> Hi Shuah, >>> >>> 2016-10-13 8:11 GMT+09:00 Shuah Khan : Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hello Shuah, Shuah Khan wrote: > On 10/19/2016 04:27 PM, Shuah Khan wrote: >> On 10/19/2016 08:16 AM, Inki Dae wrote: >>> Hi Shuah, >>> >>> 2016-10-13 8:11 GMT+09:00 Shuah Khan : Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the very first commit that

Re: [RFC v2] ARM: memory: da8xx-ddrctl: new driver

Bartosz Golaszewski writes: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski > --- >

Re: [RFC v2] ARM: memory: da8xx-ddrctl: new driver

Bartosz Golaszewski writes: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski > --- > .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++ >

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, Oct 25, 2016 at 10:38 AM, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland wrote: >> >> That does not appear to be the case; as fr as I can tell the core prints a >> timestamp per line as required. If I run: >> >>

Re: [PATCH] arm64: Neaten show_regs, remove KERN_CONT

On Tue, Oct 25, 2016 at 10:38 AM, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland wrote: >> >> That does not appear to be the case; as fr as I can tell the core prints a >> timestamp per line as required. If I run: >> >> printk("TEST\nLINE1\nLINE2\nLINE3\nLINE4\n");

[PATCH] ARM: davinci: da850: Fix pwm name matching

This fixes pwm name matching for DA850 familiy devices. When using device tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact same name, which caused errors when trying to register the devices. The names for clock matching in da850_clks[] also have to be updated to to

[PATCH] ARM: davinci: da850: Fix pwm name matching

This fixes pwm name matching for DA850 familiy devices. When using device tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact same name, which caused errors when trying to register the devices. The names for clock matching in da850_clks[] also have to be updated to to

Re: [PATCH v2 5/5] ARC: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

On 10/24/2016 05:46 AM, Yuriy Kolerov wrote: > ARC linux uses 2 distribution modes for common interrupts: round robin > mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST). > The first one is used when more than 1 cores may handle a common interrupt > and the second one is

Re: [PATCH v2 5/5] ARC: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

On 10/24/2016 05:46 AM, Yuriy Kolerov wrote: > ARC linux uses 2 distribution modes for common interrupts: round robin > mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST). > The first one is used when more than 1 cores may handle a common interrupt > and the second one is

Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop)

On Tue, Oct 25, 2016 at 09:55:21AM -0700, Eric Wheeler wrote: > Sure, I'll put it up with my -rc2 pull request to Jens. > > A couple of sanity checks (for my understanding at least): > > Why does bch_data_insert_start() no longer need to call > set_gc_sectors(op->c) now that

Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop)

On Tue, Oct 25, 2016 at 09:55:21AM -0700, Eric Wheeler wrote: > Sure, I'll put it up with my -rc2 pull request to Jens. > > A couple of sanity checks (for my understanding at least): > > Why does bch_data_insert_start() no longer need to call > set_gc_sectors(op->c) now that

Re: Untested patch to recheck idle state for expedited grace periods

On Tue, Oct 11, 2016 at 09:15:40AM -0700, Paul E. McKenney wrote: > On Tue, Oct 11, 2016 at 06:28:49AM -0700, Paul E. McKenney wrote: > > Hello, Rik, > > > > And it turns out that I did not in fact do the recheck at IPI time. > > The (untested) patch below is an alleged fix. Thoughts? > > And

Re: Untested patch to recheck idle state for expedited grace periods

On Tue, Oct 11, 2016 at 09:15:40AM -0700, Paul E. McKenney wrote: > On Tue, Oct 11, 2016 at 06:28:49AM -0700, Paul E. McKenney wrote: > > Hello, Rik, > > > > And it turns out that I did not in fact do the recheck at IPI time. > > The (untested) patch below is an alleged fix. Thoughts? > > And

<    1   2   3   4   5   6   7   8   9   10   >