Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

Hi, [added Peter, Ingo and Arnaldo] > Vince Weaver hat am 17. Mai 2018 um 18:34 > geschrieben: > > > On Thu, 17 May 2018, Stefan Wahren wrote: > > > > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > > > > The a53 and a7

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

Hi, [added Peter, Ingo and Arnaldo] > Vince Weaver hat am 17. Mai 2018 um 18:34 > geschrieben: > > > On Thu, 17 May 2018, Stefan Wahren wrote: > > > > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > > > > The a53 and a7 counters seem to match up, so we advertise a7

Re: linux-next: Tree for May 17 (usb/gadget/udc/aspeed-vhub/)

On 05/17/2018 12:06 AM, Stephen Rothwell wrote: > > The usb-gadget tree gained a conflict against the usb tree. > on x86_64: drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request': hub.c:(.text+0x3a7): undefined reference to `usb_gadget_get_string'

Re: linux-next: Tree for May 17 (usb/gadget/udc/aspeed-vhub/)

On 05/17/2018 12:06 AM, Stephen Rothwell wrote: > > The usb-gadget tree gained a conflict against the usb tree. > on x86_64: drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request': hub.c:(.text+0x3a7): undefined reference to `usb_gadget_get_string'

Re: [PATCH] vfs: change iterate_supers callback to take an int arg instead of a void *

On Thu, 2018-05-17 at 18:39 +0200, Jan Kara wrote: > On Thu 17-05-18 11:46:46, Jeff Layton wrote: > > From: Jeff Layton > > > > All of the callback functions for iterate_supers either ignore the > > opaque argument, or dereference the pointer only to fetch the int > > to

Re: [PATCH] vfs: change iterate_supers callback to take an int arg instead of a void *

On Thu, 2018-05-17 at 18:39 +0200, Jan Kara wrote: > On Thu 17-05-18 11:46:46, Jeff Layton wrote: > > From: Jeff Layton > > > > All of the callback functions for iterate_supers either ignore the > > opaque argument, or dereference the pointer only to fetch the int > > to which it points. > > >

Re: [Xen-devel] [RFC][PATCH] KVM: APPLES can improve the performance of applications and virtualized systems by up to 49%

On Sat, 2018-05-12 at 16:27 +0800, Weiwei Jia wrote: > We already have a prototype implementation based on KVM (Linux Kernel > 3.19.8). Our patch for Linux Kernel 3.19.8 and the paper describing > our idea are available in Github repository [1][2][3]. We are pleased > to revise our patch in order

Re: [Xen-devel] [RFC][PATCH] KVM: APPLES can improve the performance of applications and virtualized systems by up to 49%

On Sat, 2018-05-12 at 16:27 +0800, Weiwei Jia wrote: > We already have a prototype implementation based on KVM (Linux Kernel > 3.19.8). Our patch for Linux Kernel 3.19.8 and the paper describing > our idea are available in Github repository [1][2][3]. We are pleased > to revise our patch in order

Re: [PATCH v7 03/14] clk: qcom: Add CPU clock driver for msm8996

Hi Ilia, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc5] [cannot apply to clk/clk-next next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v7 03/14] clk: qcom: Add CPU clock driver for msm8996

Hi Ilia, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc5] [cannot apply to clk/clk-next next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

On Thu 17-05-18 16:58:32, Ville Syrjälä wrote: > On Thu, May 17, 2018 at 04:36:29PM +0300, Ville Syrjälä wrote: > > On Thu, May 17, 2018 at 03:21:09PM +0200, Michal Hocko wrote: > > > On Thu 17-05-18 15:59:59, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > >

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

On Thu 17-05-18 16:58:32, Ville Syrjälä wrote: > On Thu, May 17, 2018 at 04:36:29PM +0300, Ville Syrjälä wrote: > > On Thu, May 17, 2018 at 03:21:09PM +0200, Michal Hocko wrote: > > > On Thu 17-05-18 15:59:59, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > This reverts commit

Applied "regulator: core: Change voltage setting path" to the regulator tree

The patch regulator: core: Change voltage setting path has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: core: Change voltage setting path" to the regulator tree

The patch regulator: core: Change voltage setting path has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: core: Parse coupled regulators properties" to the regulator tree

The patch regulator: core: Parse coupled regulators properties has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Parse coupled regulators properties" to the regulator tree

The patch regulator: core: Parse coupled regulators properties has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Add voltage balancing mechanism" to the regulator tree

The patch regulator: core: Add voltage balancing mechanism has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Add voltage balancing mechanism" to the regulator tree

The patch regulator: core: Add voltage balancing mechanism has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: s2mps11: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: s2mps11: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: s2mps11: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: s2mps11: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Re: [PATCH 19/19 v3] ARM: s3c64xx: Tidy up handling of regulator GPIO lookups

On Mon, May 14, 2018 at 10:06:40AM +0200, Linus Walleij wrote: > From: Charles Keepax > > Rather than unconditionally registering the GPIO lookup table only do so > for devices that require it. > > Signed-off-by: Charles Keepax >

Re: [PATCH 19/19 v3] ARM: s3c64xx: Tidy up handling of regulator GPIO lookups

On Mon, May 14, 2018 at 10:06:40AM +0200, Linus Walleij wrote: > From: Charles Keepax > > Rather than unconditionally registering the GPIO lookup table only do so > for devices that require it. > > Signed-off-by: Charles Keepax > [Fixed up to also handle wm5102 and wm5102 reva] >

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, May 17, 2018 at 2:17 PM, Eric Anholt wrote: > The a53 and a7 counters seem to match up, so we advertise a7 so that > arm32 can probe. > > Signed-off-by: Eric Anholt Tested-by: Peter Robinson We've carried the same/equiv patch in

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, May 17, 2018 at 2:17 PM, Eric Anholt wrote: > The a53 and a7 counters seem to match up, so we advertise a7 so that > arm32 can probe. > > Signed-off-by: Eric Anholt Tested-by: Peter Robinson We've carried the same/equiv patch in Fedora for a while with no issues. Peter > --- >

Applied "regulator: core: Make locks re-entrant" to the regulator tree

The patch regulator: core: Make locks re-entrant has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Applied "regulator: core: Make locks re-entrant" to the regulator tree

The patch regulator: core: Make locks re-entrant has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

On Mon, May 07, 2018 at 02:29:45PM -0600, Mahadevan, Girish wrote: > On 5/3/2018 5:38 PM, Mark Brown wrote: > > This is a DT based driver but there is no binding documentation. > > Binding documentation is required for any new DT stuff. > The DT documentation for the SPI driver was done as part

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

On Mon, May 07, 2018 at 02:29:45PM -0600, Mahadevan, Girish wrote: > On 5/3/2018 5:38 PM, Mark Brown wrote: > > This is a DT based driver but there is no binding documentation. > > Binding documentation is required for any new DT stuff. > The DT documentation for the SPI driver was done as part

Re: [PATCH] regulator: core: Quiet -EPROBE_DEFER from regulator_bulk_get()

On Mon, May 14, 2018 at 03:40:27PM -0700, Douglas Anderson wrote: > The -EPROBE_DEFER virus demands special case code to avoid printing > error messages when the error is only -EPROBE_DEFER. Spread the virus > to a new host: regulator_bulk_get() There's no requirement to suppress probe deferral

Re: [PATCH] regulator: core: Quiet -EPROBE_DEFER from regulator_bulk_get()

On Mon, May 14, 2018 at 03:40:27PM -0700, Douglas Anderson wrote: > The -EPROBE_DEFER virus demands special case code to avoid printing > error messages when the error is only -EPROBE_DEFER. Spread the virus > to a new host: regulator_bulk_get() There's no requirement to suppress probe deferral

Re: [PATCH v2 2/6] spi: sun6i: handle chip select polarity flag

On Fri, Mar 30, 2018 at 03:50:43PM +0300, Sergey Suloev wrote: > The chip select polarity flag is declared as supported > but is not handled in the code. This is more of a fix and should really have come before the cosmetic changes in patch 1. In general it's best to put fixes fist in a series

Re: [PATCH v2 2/6] spi: sun6i: handle chip select polarity flag

On Fri, Mar 30, 2018 at 03:50:43PM +0300, Sergey Suloev wrote: > The chip select polarity flag is declared as supported > but is not handled in the code. This is more of a fix and should really have come before the cosmetic changes in patch 1. In general it's best to put fixes fist in a series

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote: > On 04/24/2018 10:41 AM, Mark Brown wrote: > > If the hardware has full knowledge of all these constraints and enforces > > them transparently then why does the kernel care that it's doing that? > > Doesn't it defeat the point of it

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote: > On 04/24/2018 10:41 AM, Mark Brown wrote: > > If the hardware has full knowledge of all these constraints and enforces > > them transparently then why does the kernel care that it's doing that? > > Doesn't it defeat the point of it

Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi Lee, On 5/16/18, 11:25 PM, "Lee Jones" wrote: On Wed, 16 May 2018, Hoan Tran wrote: > Hi Phil, > > On 5/11/18, 1:31 AM, "Phil Edworthy" wrote: > > The DesignWare GPIO IP can be configured for either 1

Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi Lee, On 5/16/18, 11:25 PM, "Lee Jones" wrote: On Wed, 16 May 2018, Hoan Tran wrote: > Hi Phil, > > On 5/11/18, 1:31 AM, "Phil Edworthy" wrote: > > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote: > On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote: > > So, what is not going as expected in "SPI core takes care of CSs" > > case? > > Did you use oscilloscope for that? > Yes, I used and CSs was not asserted. Anyway, I will

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote: > On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote: > > So, what is not going as expected in "SPI core takes care of CSs" > > case? > > Did you use oscilloscope for that? > Yes, I used and CSs was not asserted. Anyway, I will

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

On Fri, May 11, 2018 at 01:38:21PM +0300, Radu Pirea wrote: > +config SPI_AT91_USART > +tristate "Atmel USART Controller as SPI" > + depends on HAS_DMA > + depends on (ARCH_AT91 || COMPILE_TEST) > +select MFD_AT91_USART > + help > + This selects a driver for the

Re: [PATCH v2 1/6] spi: sun6i: coding style/readability improvements

On Fri, Mar 30, 2018 at 03:50:42PM +0300, Sergey Suloev wrote: > Minor changes to fulfill the coding style and improve > the readability of the code. > > Changes in v2: > 1) Fixed issue with misplacing a piece of code that requires access > to the transfer structure into

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

On Fri, May 11, 2018 at 01:38:21PM +0300, Radu Pirea wrote: > +config SPI_AT91_USART > +tristate "Atmel USART Controller as SPI" > + depends on HAS_DMA > + depends on (ARCH_AT91 || COMPILE_TEST) > +select MFD_AT91_USART > + help > + This selects a driver for the

Re: [PATCH v2 1/6] spi: sun6i: coding style/readability improvements

On Fri, Mar 30, 2018 at 03:50:42PM +0300, Sergey Suloev wrote: > Minor changes to fulfill the coding style and improve > the readability of the code. > > Changes in v2: > 1) Fixed issue with misplacing a piece of code that requires access > to the transfer structure into

Re: [Ksummit-discuss] bug-introducing patches

On Mon, May 14, 2018 at 10:36:04AM +0200, Ulf Hansson wrote: > I will ping the kernelci folkz to request them to include your new > fixes branch for daily builds. No need, I already added it. signature.asc Description: PGP signature

Re: [PATCH 43/45] sound/soc/zte: remove duplicate includes

On Mon, Dec 11, 2017 at 12:02:03AM +0530, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. Please use subject lines matching the style for the subsystem. This makes it easier for

Re: [Ksummit-discuss] bug-introducing patches

On Mon, May 14, 2018 at 10:36:04AM +0200, Ulf Hansson wrote: > I will ping the kernelci folkz to request them to include your new > fixes branch for daily builds. No need, I already added it. signature.asc Description: PGP signature

Re: [PATCH 43/45] sound/soc/zte: remove duplicate includes

On Mon, Dec 11, 2017 at 12:02:03AM +0530, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. Please use subject lines matching the style for the subsystem. This makes it easier for

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On Tue, May 15, 2018 at 03:13:47PM +0530, Agrawal, Akshu wrote: > If you are Ok with this patch can you please take this. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On Tue, May 15, 2018 at 03:13:47PM +0530, Agrawal, Akshu wrote: > If you are Ok with this patch can you please take this. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some

Re: [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver

On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote: > +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token) > +{ > + struct q6afe_port *p = NULL; > + struct q6afe_port *ret = NULL; > + unsigned long flags; > + > +

Re: [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver

On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote: > +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token) > +{ > + struct q6afe_port *p = NULL; > + struct q6afe_port *ret = NULL; > + unsigned long flags; > + > +

Re: [PATCH] drivers: regmap: Skip clk_put for attached clocks when freeing context

On Tue, May 15, 2018 at 10:59:58AM +1000, James Kelly wrote: > Capability to attach an existing clk to a MMIO regmap was > introduced in 4.17rc1. Please use subject lines matching the style for the subsystem. This makes it easier for people to identify relevant patches. signature.asc

Re: [PATCH] drivers: regmap: Skip clk_put for attached clocks when freeing context

On Tue, May 15, 2018 at 10:59:58AM +1000, James Kelly wrote: > Capability to attach an existing clk to a MMIO regmap was > introduced in 4.17rc1. Please use subject lines matching the style for the subsystem. This makes it easier for people to identify relevant patches. signature.asc

Applied "regulator: max77686: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: max77686: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: max77686: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: max77686: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: bindings: Add properties for coupled regulators" to the regulator tree

The patch regulator: bindings: Add properties for coupled regulators has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: bindings: Add properties for coupled regulators" to the regulator tree

The patch regulator: bindings: Add properties for coupled regulators has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Re: general protection fault in gfn_to_rmap

On Tue, Oct 31, 2017 at 2:59 PM, Dmitry Vyukov wrote: > On Tue, Oct 31, 2017 at 4:51 PM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 0b5477d9dabd96ded4c5ef7a5f08b00188fc1dec

Re: general protection fault in gfn_to_rmap

On Tue, Oct 31, 2017 at 2:59 PM, Dmitry Vyukov wrote: > On Tue, Oct 31, 2017 at 4:51 PM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 0b5477d9dabd96ded4c5ef7a5f08b00188fc1dec >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler: gcc

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

Hi, Le mercredi 16 mai 2018 à 15:20 +0100, Dave Martin a écrit : > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > or the arch-specific headers. This is likely > to lead to mistakes. (I certainly fell foul of it...) > >

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

Hi, Le mercredi 16 mai 2018 à 15:20 +0100, Dave Martin a écrit : > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > or the arch-specific headers. This is likely > to lead to mistakes. (I certainly fell foul of it...) > >

Re: [RFC/RFT] [PATCH 02/10] cpufreq: intel_pstate: Conditional frequency invariant accounting

On Thu, 2018-05-17 at 18:16 +0200, Peter Zijlstra wrote: > On Thu, May 17, 2018 at 08:41:32AM -0700, Srinivas Pandruvada wrote: > > One more point to note. Even if we calculate some utilization based > > on > > the freq-invariant and arrive at a P-state, we will not be able to > > control any

Re: [RFC/RFT] [PATCH 02/10] cpufreq: intel_pstate: Conditional frequency invariant accounting

On Thu, 2018-05-17 at 18:16 +0200, Peter Zijlstra wrote: > On Thu, May 17, 2018 at 08:41:32AM -0700, Srinivas Pandruvada wrote: > > One more point to note. Even if we calculate some utilization based > > on > > the freq-invariant and arrive at a P-state, we will not be able to > > control any

Applied "regulator: of: add support for allowed modes configuration" to the regulator tree

The patch regulator: of: add support for allowed modes configuration has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: of: add support for allowed modes configuration" to the regulator tree

The patch regulator: of: add support for allowed modes configuration has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: of: add property for allowed modes specification" to the regulator tree

The patch regulator: of: add property for allowed modes specification has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: core: Allow for regulators that can't be read at bootup" to the regulator tree

The patch regulator: core: Allow for regulators that can't be read at bootup has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "regulator: of: add property for allowed modes specification" to the regulator tree

The patch regulator: of: add property for allowed modes specification has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: core: Allow for regulators that can't be read at bootup" to the regulator tree

The patch regulator: core: Allow for regulators that can't be read at bootup has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "MAINTAINERS: update sound/soc/intel maintainers" to the asoc tree

The patch MAINTAINERS: update sound/soc/intel maintainers has been applied to the asoc tree at https://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 hours) and sent

Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: wm8994: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: core: Resolve coupled regulators" to the regulator tree

The patch regulator: core: Resolve coupled regulators has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "MAINTAINERS: update sound/soc/intel maintainers" to the asoc tree

The patch MAINTAINERS: update sound/soc/intel maintainers has been applied to the asoc tree at https://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 hours) and sent

Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree

The patch regulator: wm8994: Pass descriptor instead of GPIO number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: core: Resolve coupled regulators" to the regulator tree

The patch regulator: core: Resolve coupled regulators has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "regmap: Skip clk_put for attached clocks when freeing context" to the regmap tree

The patch regmap: Skip clk_put for attached clocks when freeing context has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regmap: Skip clk_put for attached clocks when freeing context" to the regmap tree

The patch regmap: Skip clk_put for attached clocks when freeing context has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: arizona-ldo1: Look up a descriptor and pass to the core" to the regulator tree

The patch regulator: arizona-ldo1: Look up a descriptor and pass to the core has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "regulator: arizona-ldo1: Look up a descriptor and pass to the core" to the regulator tree

The patch regulator: arizona-ldo1: Look up a descriptor and pass to the core has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "ASoC: zte: remove duplicate includes" to the asoc tree

The patch ASoC: zte: remove duplicate includes has been applied to the asoc tree at https://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 hours) and sent to Linus

Applied "ASoC: zte: remove duplicate includes" to the asoc tree

The patch ASoC: zte: remove duplicate includes has been applied to the asoc tree at https://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 hours) and sent to Linus

Re: [PATCH] vfs: change iterate_supers callback to take an int arg instead of a void *

On Thu 17-05-18 11:46:46, Jeff Layton wrote: > From: Jeff Layton > > All of the callback functions for iterate_supers either ignore the > opaque argument, or dereference the pointer only to fetch the int > to which it points. > > Change iterate_supers to pass an opaque int

Re: [PATCH] vfs: change iterate_supers callback to take an int arg instead of a void *

On Thu 17-05-18 11:46:46, Jeff Layton wrote: > From: Jeff Layton > > All of the callback functions for iterate_supers either ignore the > opaque argument, or dereference the pointer only to fetch the int > to which it points. > > Change iterate_supers to pass an opaque int arg to the callback >

Applied "ASoC: qdsp6: q6core: Add q6core driver" to the asoc tree

The patch ASoC: qdsp6: q6core: Add q6core driver has been applied to the asoc tree at https://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 hours) and sent to Linus

Applied "ASoC: qdsp6: q6core: Add q6core driver" to the asoc tree

The patch ASoC: qdsp6: q6core: Add q6core driver has been applied to the asoc tree at https://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 hours) and sent to Linus

Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

On Thu, May 17, 2018 at 4:56 PM, Tony Lindgren wrote: > * Andy Shevchenko [180516 13:12]: >> On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote: >> > But since I am on it. You have to enable runtime-PM for the UART. So >> >

Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

On Thu, May 17, 2018 at 4:56 PM, Tony Lindgren wrote: > * Andy Shevchenko [180516 13:12]: >> On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote: >> > But since I am on it. You have to enable runtime-PM for the UART. So >> > what is the problem if you simply don't enable it for

Re: [PATCH V2 04/10] ASoC: amd: pte offset related dma driver changes

On Tue, May 15, 2018 at 03:22:46PM +0530, Mukunda,Vijendar wrote: > You have merged 1-3 patch series. Still patch no 4 to 10 remaining. > Could you please take them. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend

Re: [PATCH V2 04/10] ASoC: amd: pte offset related dma driver changes

On Tue, May 15, 2018 at 03:22:46PM +0530, Mukunda,Vijendar wrote: > You have merged 1-3 patch series. Still patch no 4 to 10 remaining. > Could you please take them. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend

Re: [PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode

On Fri, Mar 30, 2018 at 03:50:44PM +0300, Sergey Suloev wrote: > There is no need to handle 3/4 empty/full interrupts as > the maximum supported transfer length in PIO mode is > 128 bytes for sun6i- and 64 bytes for sun8i-family SoCs. Surely the whole point of the 3/4 full interrupts is to allow

Re: [PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode

On Fri, Mar 30, 2018 at 03:50:44PM +0300, Sergey Suloev wrote: > There is no need to handle 3/4 empty/full interrupts as > the maximum supported transfer length in PIO mode is > 128 bytes for sun6i- and 64 bytes for sun8i-family SoCs. Surely the whole point of the 3/4 full interrupts is to allow

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

Hi, On 05/17/2018 04:06 AM, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page fault. > > By default it is turned off, and activated depending on architecture > support, ARCH_HAS_PTE_SPECIAL, SMP and MMU. > > The architecture

Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

On Thu, May 17, 2018 at 4:48 PM, Tony Lindgren wrote: > * Sebastian Andrzej Siewior [180516 10:49]: >> On 2018-05-16 13:17:36 [+0300], Andy Shevchenko wrote: >> > > The output is usually short so there >> > > shouldn't be much benefit from using it. >> >

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

Hi, On 05/17/2018 04:06 AM, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page fault. > > By default it is turned off, and activated depending on architecture > support, ARCH_HAS_PTE_SPECIAL, SMP and MMU. > > The architecture

Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

On Thu, May 17, 2018 at 4:48 PM, Tony Lindgren wrote: > * Sebastian Andrzej Siewior [180516 10:49]: >> On 2018-05-16 13:17:36 [+0300], Andy Shevchenko wrote: >> > > The output is usually short so there >> > > shouldn't be much benefit from using it. >> > >> > > I remember Tony wanted runtime-pm

Re: [PATCH] PM / devfreq: Init user limits from OPP limits, not viceversa

On Thu, May 17, 2018 at 10:07:56AM +0900, Chanwoo Choi wrote: > Hi, > > On 2018년 05월 17일 07:57, Matthias Kaehlcke wrote: > > Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding > > the devfreq device") introduced the initialization of the user > > limits min/max_freq from the

Re: [PATCH] PM / devfreq: Init user limits from OPP limits, not viceversa

On Thu, May 17, 2018 at 10:07:56AM +0900, Chanwoo Choi wrote: > Hi, > > On 2018년 05월 17일 07:57, Matthias Kaehlcke wrote: > > Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding > > the devfreq device") introduced the initialization of the user > > limits min/max_freq from the

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Stefan Wahren wrote: > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that > > arm32 can probe. so how closely did you look at the a53/a7 differences? I see some

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Stefan Wahren wrote: > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that > > arm32 can probe. so how closely did you look at the a53/a7 differences? I see some major differences,

Re: [PATCH v2] memstick: mspro_block: fix unused variable warning

Hi Anders, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc5] [cannot apply to next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH v2] memstick: mspro_block: fix unused variable warning

Hi Anders, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc5] [cannot apply to next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

<    4   5   6   7   8   9   10   11   12   13   >