[PATCH 3/3] lightnvm: rename dma helper functions

Until now, the dma pool have been exclusively used to allocate the ppa list being sent to the device. In pblk (upcoming), we use these pools to allocate metadata too. Thus, we generalize the names of some variables on the dma helper functions to make the code more readable. Signed-off-by: Javier

[PATCH 1/3] lightnvm: do not free unused metadata on rrpc

rrpc does not save any metadata on a given request. Thus, do not attempt to free the metadata dma region. Signed-off-by: Javier González --- drivers/lightnvm/rrpc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c index c7fef71..ffcfee6

[PATCH 2/3] lightnvm: enable metadata to be sent to device

Enable metadata to be sent to the device through the metadata field on the physical rw nvme command. When a single ppa is sent to the device, a 64-bit integer can be sent as metadata; when a ppa list is sent, a 64-bit integer list mapping to the ppa list can be used to send metadata.

[PATCH 3/3] lightnvm: rename dma helper functions

Until now, the dma pool have been exclusively used to allocate the ppa list being sent to the device. In pblk (upcoming), we use these pools to allocate metadata too. Thus, we generalize the names of some variables on the dma helper functions to make the code more readable. Signed-off-by: Javier

Re: [PATCH 3.16 098/217] s390/pci: enforce fmb page boundary rule

On Wed, 27 Apr 2016, Ben Hutchings wrote: > 3.16.35-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Sebastian Ott > > commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 upstream. > > The function measurement block

Re: [PATCH 3.16 098/217] s390/pci: enforce fmb page boundary rule

On Wed, 27 Apr 2016, Ben Hutchings wrote: > 3.16.35-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Sebastian Ott > > commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 upstream. > > The function measurement block must not cross a page

Linux 3.12.59

I'm announcing the release of the 3.12.59 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web

Linux 3.12.59

I'm announcing the release of the 3.12.59 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web

Re: [PATCH] tty: provide tty_name() even without CONFIG_TTY

On Wednesday 27 April 2016 12:20:02 Paul Moore wrote: > > diff --git a/include/linux/tty.h b/include/linux/tty.h > > index 3b09f235db66..17b247c94440 100644 > > --- a/include/linux/tty.h > > +++ b/include/linux/tty.h > > @@ -371,6 +371,7 @@ extern void proc_clear_tty(struct task_struct *p); > >

Re: [PATCH] tty: provide tty_name() even without CONFIG_TTY

On Wednesday 27 April 2016 12:20:02 Paul Moore wrote: > > diff --git a/include/linux/tty.h b/include/linux/tty.h > > index 3b09f235db66..17b247c94440 100644 > > --- a/include/linux/tty.h > > +++ b/include/linux/tty.h > > @@ -371,6 +371,7 @@ extern void proc_clear_tty(struct task_struct *p); > >

Re: [PATCH V4 16/18] coresight: tmc: implementing TMC-ETF AUX space API

On 27/04/16 18:22, Mathieu Poirier wrote: On 27 April 2016 at 05:21, Suzuki K Poulose wrote: On 26/04/16 23:10, Mathieu Poirier wrote: This patch implement the AUX area interfaces required to use the TMC (configured as an ETF) from the Perf sub-system. The heuristic

Re: [PATCH V4 16/18] coresight: tmc: implementing TMC-ETF AUX space API

On 27/04/16 18:22, Mathieu Poirier wrote: On 27 April 2016 at 05:21, Suzuki K Poulose wrote: On 26/04/16 23:10, Mathieu Poirier wrote: This patch implement the AUX area interfaces required to use the TMC (configured as an ETF) from the Perf sub-system. The heuristic is heavily borrowed from

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On Wed, Apr 27, 2016 at 1:05 PM, Josh Triplett wrote: > On Wed, Apr 27, 2016 at 11:20:26AM -0400, Josh Boyer wrote: >> On Wed, Apr 27, 2016 at 10:57 AM, Môshe van der Sterre wrote: >> > >> > On 04/27/2016 03:56 PM, Josh Boyer wrote: >> >> >> >> On Wed, Apr

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On Wed, Apr 27, 2016 at 1:05 PM, Josh Triplett wrote: > On Wed, Apr 27, 2016 at 11:20:26AM -0400, Josh Boyer wrote: >> On Wed, Apr 27, 2016 at 10:57 AM, Môshe van der Sterre wrote: >> > >> > On 04/27/2016 03:56 PM, Josh Boyer wrote: >> >> >> >> On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der

Re: [PATCH V4 16/18] coresight: tmc: implementing TMC-ETF AUX space API

On 27 April 2016 at 05:21, Suzuki K Poulose wrote: > On 26/04/16 23:10, Mathieu Poirier wrote: >> >> This patch implement the AUX area interfaces required to >> use the TMC (configured as an ETF) from the Perf sub-system. >> >> The heuristic is heavily borrowed from the

Re: [PATCH V4 16/18] coresight: tmc: implementing TMC-ETF AUX space API

On 27 April 2016 at 05:21, Suzuki K Poulose wrote: > On 26/04/16 23:10, Mathieu Poirier wrote: >> >> This patch implement the AUX area interfaces required to >> use the TMC (configured as an ETF) from the Perf sub-system. >> >> The heuristic is heavily borrowed from the ETB10 implementation. >>

[PATCH v5] mm: SLAB freelist randomization

Provides an optional config (CONFIG_SLAB_FREELIST_RANDOM) to randomize the SLAB freelist. The list is randomized during initialization of a new set of pages. The order on different freelist sizes is pre-computed at boot for performance. Each kmem_cache has its own randomized freelist. Before

[PATCH v5] mm: SLAB freelist randomization

Provides an optional config (CONFIG_SLAB_FREELIST_RANDOM) to randomize the SLAB freelist. The list is randomized during initialization of a new set of pages. The order on different freelist sizes is pre-computed at boot for performance. Each kmem_cache has its own randomized freelist. Before

Re: [PATCH] mm/zswap: use workqueue to destroy pool

On Tue, Apr 26, 2016 at 8:58 PM, Sergey Senozhatsky wrote: > Hello, > > On (04/26/16 17:08), Dan Streetman wrote: > [..] >> -static void __zswap_pool_release(struct rcu_head *head) >> +static void __zswap_pool_release(struct work_struct *work) >> { >> -

Re: [PATCH] mm/zswap: use workqueue to destroy pool

On Tue, Apr 26, 2016 at 8:58 PM, Sergey Senozhatsky wrote: > Hello, > > On (04/26/16 17:08), Dan Streetman wrote: > [..] >> -static void __zswap_pool_release(struct rcu_head *head) >> +static void __zswap_pool_release(struct work_struct *work) >> { >> - struct zswap_pool *pool =

[PULL REQUEST] i2c for 4.6

Linus, I2C has one buildfix, one ABBA deadlock fix and three simple 'add ID' patches for you. Please pull. Thanks, Wolfram The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) are available in the git repository at:

[PULL REQUEST] i2c for 4.6

Linus, I2C has one buildfix, one ABBA deadlock fix and three simple 'add ID' patches for you. Please pull. Thanks, Wolfram The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) are available in the git repository at:

Re: [PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div

* Tony Lindgren [160427 09:39]: > * Tero Kristo [160427 04:22]: > > On 26/04/16 20:54, J.D. Schroeder wrote: > > >From: "J.D. Schroeder" > > > > > >This commit fixes the clock data inside the DRA7xx clocks device tree > > >structure

Re: [PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div

* Tony Lindgren [160427 09:39]: > * Tero Kristo [160427 04:22]: > > On 26/04/16 20:54, J.D. Schroeder wrote: > > >From: "J.D. Schroeder" > > > > > >This commit fixes the clock data inside the DRA7xx clocks device tree > > >structure for the gmac_gmii_ref_clk_div clock. This clock is actually >

Re: [PATCH v2] net: Add Qualcomm IPC router

On Wed 27 Apr 09:22 PDT 2016, David Miller wrote: > From: Bjorn Andersson > Date: Tue, 26 Apr 2016 22:48:05 -0700 > > > + rc = qcom_smd_send(qdev->channel, skb->data, skb->len); > > I truly dislike adding networking protocols that depend upon some > piece of

Re: [PATCH v2] net: Add Qualcomm IPC router

On Wed 27 Apr 09:22 PDT 2016, David Miller wrote: > From: Bjorn Andersson > Date: Tue, 26 Apr 2016 22:48:05 -0700 > > > + rc = qcom_smd_send(qdev->channel, skb->data, skb->len); > > I truly dislike adding networking protocols that depend upon some > piece of infrastructure that only some

[PATCH] Fix might sleep warning.

When an nbd request times out then the nbd_xmit_timeout tries to close the socket by taking a spin_lock over the socket. This however generates a warning on kernel_sock_shutdown. This patch fixes this issue. Pranay Kr. Srivastava (1): fix might_sleep warning on socket shutdown

[PATCH] fix might_sleep warning on socket shutdown

This patch fixes the warning generated when a timeout occurs on the request and socket is closed from a non-sleep context by 1. Moving the socket closing on a timeout to nbd_thread_send 2. Make sock lock to be a mutex instead of a spin lock, since nbd_xmit_timeout doesn't need to hold it

[PATCH] Fix might sleep warning.

When an nbd request times out then the nbd_xmit_timeout tries to close the socket by taking a spin_lock over the socket. This however generates a warning on kernel_sock_shutdown. This patch fixes this issue. Pranay Kr. Srivastava (1): fix might_sleep warning on socket shutdown

[PATCH] fix might_sleep warning on socket shutdown

This patch fixes the warning generated when a timeout occurs on the request and socket is closed from a non-sleep context by 1. Moving the socket closing on a timeout to nbd_thread_send 2. Make sock lock to be a mutex instead of a spin lock, since nbd_xmit_timeout doesn't need to hold it

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Wed, Apr 27, 2016 at 06:41:37PM +0200, Pavel Machek wrote: > Hey look, SME slowed down 30% since being initially merged into > kernel! How is that breaking bisection? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Wed, Apr 27, 2016 at 06:41:37PM +0200, Pavel Machek wrote: > Hey look, SME slowed down 30% since being initially merged into > kernel! How is that breaking bisection? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Re: mm: pages are not freed from lru_add_pvecs after process termination

On 04/27/2016 10:01 AM, Odzioba, Lukasz wrote: > Pieces of the puzzle: > A) after process termination memory is not getting freed nor accounted as free I don't think this part is necessarily a bug. As long as we have stats *somewhere*, and we really do "reclaim" them, I don't think we need to

Re: mm: pages are not freed from lru_add_pvecs after process termination

On 04/27/2016 10:01 AM, Odzioba, Lukasz wrote: > Pieces of the puzzle: > A) after process termination memory is not getting freed nor accounted as free I don't think this part is necessarily a bug. As long as we have stats *somewhere*, and we really do "reclaim" them, I don't think we need to

Re: [PATCH] i2c: uniphier: add "\n" at the end of error log

On Thu, Apr 21, 2016 at 03:12:44PM +0900, Masahiro Yamada wrote: > Just in case. > > Signed-off-by: Masahiro Yamada Applied to for-next, thanks! signature.asc Description: PGP signature

Re: [PATCH] i2c: uniphier: add "\n" at the end of error log

On Thu, Apr 21, 2016 at 03:12:44PM +0900, Masahiro Yamada wrote: > Just in case. > > Signed-off-by: Masahiro Yamada Applied to for-next, thanks! signature.asc Description: PGP signature

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On 27/04/16 17:41, Pavel Machek wrote: On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: Doing it early will break bisect, right? How exactly? Please do tell. Hey look, SME slowed down 30% since being initially merged into

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On 27/04/16 17:41, Pavel Machek wrote: On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: Doing it early will break bisect, right? How exactly? Please do tell. Hey look, SME slowed down 30% since being initially merged into

[PATCH] gitignore: Fix typo on the line about git files

Git files are the files that we don't want to ignore even if they are dot-files. It must be "even if" but it says "even it". Signed-off-by: Kyeongmin Cho --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index

[PATCH] gitignore: Fix typo on the line about git files

Git files are the files that we don't want to ignore even if they are dot-files. It must be "even if" but it says "even it". Signed-off-by: Kyeongmin Cho --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index fd3a355..0c320bf 100644 ---

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On Wed, Apr 27, 2016 at 11:20:26AM -0400, Josh Boyer wrote: > On Wed, Apr 27, 2016 at 10:57 AM, Môshe van der Sterre wrote: > > > > On 04/27/2016 03:56 PM, Josh Boyer wrote: > >> > >> On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der Sterre > >> wrote: > >>> > >>>

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On Wed, Apr 27, 2016 at 11:20:26AM -0400, Josh Boyer wrote: > On Wed, Apr 27, 2016 at 10:57 AM, Môshe van der Sterre wrote: > > > > On 04/27/2016 03:56 PM, Josh Boyer wrote: > >> > >> On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der Sterre > >> wrote: > >>> > >>> (additionally CC-ing Josh

mm: pages are not freed from lru_add_pvecs after process termination

Hi, I encounter a problem which I'd like to discuss here (tested on 3.10 and 4.5). While running some workloads we noticed that in case of "improper" application exit (like SIGTERM) quite a bit (a few GBs) of memory is not being reclaimed after process termination. Executing echo 1 >

mm: pages are not freed from lru_add_pvecs after process termination

Hi, I encounter a problem which I'd like to discuss here (tested on 3.10 and 4.5). While running some workloads we noticed that in case of "improper" application exit (like SIGTERM) quite a bit (a few GBs) of memory is not being reclaimed after process termination. Executing echo 1 >

[PATCH V2 0/3] Urgent fixes for Intel CQM/MBM counting

Sending some urgent fixes for the MBM(memory b/w monitoring) which is upstreamed from 4.6-rc1. Patches apply on 4.6-rc1. CQM and MBM counters reported some incorrect counts for different scenarios like interval mode or for multiple perf instances. An updated V2 as per Peter feedback: fixing a

[PATCH 1/3] perf/x86/cqm,mbm: Store cqm,mbm count for all events when RMID is recycled

During RMID recycling, when an event loses the RMID we saved the counter for group leader but it was not being saved for all the events in an event group. This would lead to a situation where if 2 perf instances are counting the same PID one of them would not see the updated count which other perf

[PATCH 2/3] perf/x86/mbm: Store bytes counted for mbm during recycle

For MBM, since we report total bytes for the duration the perf counts, we need to keep the total bytes counted every time we loose an RMID. Introduce rc_count(recycle count) per event keep this history count(all bytes counted before the current RMID). If we do not keep this count separately then

[PATCH V2 0/3] Urgent fixes for Intel CQM/MBM counting

Sending some urgent fixes for the MBM(memory b/w monitoring) which is upstreamed from 4.6-rc1. Patches apply on 4.6-rc1. CQM and MBM counters reported some incorrect counts for different scenarios like interval mode or for multiple perf instances. An updated V2 as per Peter feedback: fixing a

[PATCH 1/3] perf/x86/cqm,mbm: Store cqm,mbm count for all events when RMID is recycled

During RMID recycling, when an event loses the RMID we saved the counter for group leader but it was not being saved for all the events in an event group. This would lead to a situation where if 2 perf instances are counting the same PID one of them would not see the updated count which other perf

[PATCH 2/3] perf/x86/mbm: Store bytes counted for mbm during recycle

For MBM, since we report total bytes for the duration the perf counts, we need to keep the total bytes counted every time we loose an RMID. Introduce rc_count(recycle count) per event keep this history count(all bytes counted before the current RMID). If we do not keep this count separately then

[PATCH] tpm: Fix IRQ unwind ordering in TIS

The devm for the IRQ was placed on the chip, not the pdev. This can cause the irq to be still callable after the pdev has been cleaned up (eg priv kfree'd). Found by CONFIG_DEBUG_SHIRQ=y Reported-by: Stefan Berger Fixes: 233a065e0cd0 ("tpm: Get rid of chip->pdev")

[PATCH] tpm: Fix IRQ unwind ordering in TIS

The devm for the IRQ was placed on the chip, not the pdev. This can cause the irq to be still callable after the pdev has been cleaned up (eg priv kfree'd). Found by CONFIG_DEBUG_SHIRQ=y Reported-by: Stefan Berger Fixes: 233a065e0cd0 ("tpm: Get rid of chip->pdev") Signed-off-by: Jason Gunthorpe

[PATCH 3/3] perf/x86/mbm: Fix mbm counting when RMIDs are reused

When multiple instances of perf reuse RMID for the same PID, then we need to start counting from zero for each new event, rather than reporting the current RMID count. This patch adds a st_count(start count) 'per event' to track the same. Note that this is different from the 'per rmid' start

[PATCH 3/3] perf/x86/mbm: Fix mbm counting when RMIDs are reused

When multiple instances of perf reuse RMID for the same PID, then we need to start counting from zero for each new event, rather than reporting the current RMID count. This patch adds a st_count(start count) 'per event' to track the same. Note that this is different from the 'per rmid' start

Re: [PATCH] iio: tmp006: Set correct iio name

On 04/26/2016 06:21 PM, Daniel Baluta wrote: > On Tue, Apr 26, 2016 at 4:14 PM, Yong Li wrote: >> I am thinking if there is any application is using this incorrect >> name, the application should be fix too > > The rule is: "Don't break the userspace ABI". So, if we got this

Re: [PATCH] iio: tmp006: Set correct iio name

On 04/26/2016 06:21 PM, Daniel Baluta wrote: > On Tue, Apr 26, 2016 at 4:14 PM, Yong Li wrote: >> I am thinking if there is any application is using this incorrect >> name, the application should be fix too > > The rule is: "Don't break the userspace ABI". So, if we got this wrong > from the

Re: [PATCH v4 2/7] regulator: rk808: Migrate to regulator core's simplified DT parsing code

On Tue, Apr 26, 2016 at 04:54:05PM +0200, Wadim Egorov wrote: > A common simplified DT parsing code for regulators was introduced in > commit a0c7b164ad11 ("regulator: of: Provide simplified DT parsing > method") Acked-by: Mark Brown signature.asc Description: PGP

Re: [PATCH v4 2/7] regulator: rk808: Migrate to regulator core's simplified DT parsing code

On Tue, Apr 26, 2016 at 04:54:05PM +0200, Wadim Egorov wrote: > A common simplified DT parsing code for regulators was introduced in > commit a0c7b164ad11 ("regulator: of: Provide simplified DT parsing > method") Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH] physmap_of: ensure versatile code is reachable

On Tue, Apr 26, 2016 at 01:04:38AM +0200, Arnd Bergmann wrote: > With the newly added physmap_of_versatile code, we get a build error > when physmap_of is in a module, because of_flash_probe_versatile > is not exported: > > ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko]

Re: [PATCH] physmap_of: ensure versatile code is reachable

On Tue, Apr 26, 2016 at 01:04:38AM +0200, Arnd Bergmann wrote: > With the newly added physmap_of_versatile code, we get a build error > when physmap_of is in a module, because of_flash_probe_versatile > is not exported: > > ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko]

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Wed, Apr 27, 2016 at 09:08:01AM -0700, Linus Torvalds wrote: > On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart wrote: > > > > Found myself not wanting to send a one patch pull request, but not wanting > > to > > wait until RC6 and possibly miss 4.6. > > > > Do you have a

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Wed, Apr 27, 2016 at 09:08:01AM -0700, Linus Torvalds wrote: > On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart wrote: > > > > Found myself not wanting to send a one patch pull request, but not wanting > > to > > wait until RC6 and possibly miss 4.6. > > > > Do you have a preference during the

Re: [PATCH net-next v2] taskstats: fix nl parsing in accounting/getdelays.c

From: Nicolas Dichtel Date: Wed, 27 Apr 2016 17:53:08 +0200 > The type TASKSTATS_TYPE_NULL should always be ignored. > > When jumping to the next attribute, only the length of the current > attribute should be added, not the length of all nested attributes. > This

Re: [PATCH] i2c: octeon: Add workaround for broken irqs on CN3860

On Wed, Apr 27, 2016 at 11:44:39AM +0200, Jan Glauber wrote: > From: David Daney > > CN3860 does not interrupt the CPU when the i2c status changes. If > we get a timeout, and see the status has in fact changed, we know we > have this problem, and drop back to polling. >

Re: [PATCH net-next v2] taskstats: fix nl parsing in accounting/getdelays.c

From: Nicolas Dichtel Date: Wed, 27 Apr 2016 17:53:08 +0200 > The type TASKSTATS_TYPE_NULL should always be ignored. > > When jumping to the next attribute, only the length of the current > attribute should be added, not the length of all nested attributes. > This last bug was not visible

Re: [PATCH] i2c: octeon: Add workaround for broken irqs on CN3860

On Wed, Apr 27, 2016 at 11:44:39AM +0200, Jan Glauber wrote: > From: David Daney > > CN3860 does not interrupt the CPU when the i2c status changes. If > we get a timeout, and see the status has in fact changed, we know we > have this problem, and drop back to polling. > > Signed-off-by: David

Re: [PATCH 0/2 v6] Add I2S audio support for ARC AXS10x boards

On Wed, Apr 27, 2016 at 11:05:18AM +0100, Jose Abreu wrote: > ARC AXS10x platforms consist of a mainboard with several peripherals. > One of those peripherals is an HDMI output port controlled by the ADV7511 > transmitter. > > This patch set adds I2S audio for the AXS10x platform. I don't seem

Re: [PATCH 0/2 v6] Add I2S audio support for ARC AXS10x boards

On Wed, Apr 27, 2016 at 11:05:18AM +0100, Jose Abreu wrote: > ARC AXS10x platforms consist of a mainboard with several peripherals. > One of those peripherals is an HDMI output port controlled by the ADV7511 > transmitter. > > This patch set adds I2S audio for the AXS10x platform. I don't seem

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Hi, Arnd Bergmann writes: > On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote: >> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote: >> > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote: >> > > >> > > I would be in favour of a dma_inherit() function

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Hi, Arnd Bergmann writes: > On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote: >> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote: >> > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote: >> > > >> > > I would be in favour of a dma_inherit() function as well. We

Re: [PATCH] can: m_can: fix bitrate setup on latest silicon

On 26 April 2016 at 21:11, Oliver Hartkopp wrote: > > I wonder whether this small change covers the updates made between > v3.0.1 and v3.1.0. > Probably not, I was mainly interested in fixing basic functionality here :) (ie: with the default settings we can exchange data

Re: [PATCH] can: m_can: fix bitrate setup on latest silicon

On 26 April 2016 at 21:11, Oliver Hartkopp wrote: > > I wonder whether this small change covers the updates made between > v3.0.1 and v3.1.0. > Probably not, I was mainly interested in fixing basic functionality here :) (ie: with the default settings we can exchange data frames with another

Re: [BUG] set_pte_at: racy dirty state clearing warning

On 4/21/2016 1:49 AM, Catalin Marinas wrote: On Wed, Apr 20, 2016 at 04:01:39PM -0700, Shi, Yang wrote: When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899371fd3

Re: [BUG] set_pte_at: racy dirty state clearing warning

On 4/21/2016 1:49 AM, Catalin Marinas wrote: On Wed, Apr 20, 2016 at 04:01:39PM -0700, Shi, Yang wrote: When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899371fd3

Re: [PATCH V6 02/13] pci, acpi: Provide generic way to assign bus domain number.

On Wed, Apr 27, 2016 at 12:17:58PM +0100, Lorenzo Pieralisi wrote: > On Tue, Apr 26, 2016 at 09:26:49PM -0500, Bjorn Helgaas wrote: > > On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote: > > > As we now have valid PCI host bridge device reference we can > > > introduce code that is

Re: [PATCH V6 02/13] pci, acpi: Provide generic way to assign bus domain number.

On Wed, Apr 27, 2016 at 12:17:58PM +0100, Lorenzo Pieralisi wrote: > On Tue, Apr 26, 2016 at 09:26:49PM -0500, Bjorn Helgaas wrote: > > On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote: > > > As we now have valid PCI host bridge device reference we can > > > introduce code that is

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

Looks mostly good, a few comments. On 04/27/2016 05:08 AM, Shuah Khan wrote: [...] > @@ -428,7 +428,7 @@ static long media_device_ioctl(struct file *filp, > unsigned int cmd, > unsigned long arg) > { > struct media_devnode *devnode = media_devnode_data(filp);

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

Looks mostly good, a few comments. On 04/27/2016 05:08 AM, Shuah Khan wrote: [...] > @@ -428,7 +428,7 @@ static long media_device_ioctl(struct file *filp, > unsigned int cmd, > unsigned long arg) > { > struct media_devnode *devnode = media_devnode_data(filp);

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: > > Doing it early will break bisect, right? > > How exactly? Please do tell. Hey look, SME slowed down 30% since being initially merged into kernel!

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: > > Doing it early will break bisect, right? > > How exactly? Please do tell. Hey look, SME slowed down 30% since being initially merged into kernel!

Re: Applied "regulator: rk808: remove linear range definitions with a single range" to the regulator tree

On Wed, Apr 27, 2016 at 03:56:56PM +0200, Heiko Stübner wrote: > Am Mittwoch, 27. April 2016, 14:50:48 schrieb Mark Brown: > > Any ETA on a fix or should I revert? > I guess > [PATCH v4 1/7] regulator: rk808: Add rk808_reg_ops_ranges for LDO3 > from yesterday [0] might be the fix? At least

Re: Applied "regulator: rk808: remove linear range definitions with a single range" to the regulator tree

On Wed, Apr 27, 2016 at 03:56:56PM +0200, Heiko Stübner wrote: > Am Mittwoch, 27. April 2016, 14:50:48 schrieb Mark Brown: > > Any ETA on a fix or should I revert? > I guess > [PATCH v4 1/7] regulator: rk808: Add rk808_reg_ops_ranges for LDO3 > from yesterday [0] might be the fix? At least

Re: [PATCH net-next 9/9] taskstats: use the libnl API to align nlattr on 64-bit

From: Balbir Singh Date: Wed, 27 Apr 2016 22:29:22 +1000 > My concern is ABI breakage of user space. The "ABI" is that unrecognized attributes must be silently ignored by userspace.

Re: [PATCH net-next 9/9] taskstats: use the libnl API to align nlattr on 64-bit

From: Balbir Singh Date: Wed, 27 Apr 2016 22:29:22 +1000 > My concern is ABI breakage of user space. The "ABI" is that unrecognized attributes must be silently ignored by userspace.

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

On Wed, Apr 27, 2016 at 1:07 AM, Julia Lawall wrote: > > > On Wed, 27 Apr 2016, Dan Carpenter wrote: > >> On Wed, Apr 27, 2016 at 07:42:04AM +0200, Julia Lawall wrote: >> > >> > >> > On Tue, 26 Apr 2016, Kees Cook wrote: >> > >> > > On Mon, Apr 25, 2016 at 7:50 AM, Pengfei

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

On Wed, Apr 27, 2016 at 1:07 AM, Julia Lawall wrote: > > > On Wed, 27 Apr 2016, Dan Carpenter wrote: > >> On Wed, Apr 27, 2016 at 07:42:04AM +0200, Julia Lawall wrote: >> > >> > >> > On Tue, 26 Apr 2016, Kees Cook wrote: >> > >> > > On Mon, Apr 25, 2016 at 7:50 AM, Pengfei Wang >> > > wrote: >>

Applied "ASoC: wm_adsp: factor out freeing of alg regions" to the asoc tree

The patch ASoC: wm_adsp: factor out freeing of alg regions 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 hours) and sent

Applied "ASoC: wm_adsp: free memory when unloaded or closed" to the asoc tree

The patch ASoC: wm_adsp: free memory when unloaded or closed 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 hours) and

Re: [PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div

* Tero Kristo [160427 04:22]: > On 26/04/16 20:54, J.D. Schroeder wrote: > >From: "J.D. Schroeder" > > > >This commit fixes the clock data inside the DRA7xx clocks device tree > >structure for the gmac_gmii_ref_clk_div clock. This clock is actually >

Applied "ASoC: arizona: call wm_adsp2_remove when codec driver is removed" to the asoc tree

The patch ASoC: arizona: call wm_adsp2_remove when codec driver is removed 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

Applied "ASoC: bcm2835: Add S16_LE support via packed DMA transfers" to the asoc tree

The patch ASoC: bcm2835: Add S16_LE support via packed DMA transfers 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 hours)

Applied "ASoC: wm_adsp: factor out freeing of alg regions" to the asoc tree

The patch ASoC: wm_adsp: factor out freeing of alg regions 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 hours) and sent

Applied "ASoC: wm_adsp: free memory when unloaded or closed" to the asoc tree

The patch ASoC: wm_adsp: free memory when unloaded or closed 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 hours) and

Re: [PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div

* Tero Kristo [160427 04:22]: > On 26/04/16 20:54, J.D. Schroeder wrote: > >From: "J.D. Schroeder" > > > >This commit fixes the clock data inside the DRA7xx clocks device tree > >structure for the gmac_gmii_ref_clk_div clock. This clock is actually > >the GMAC_MAIN_CLK and has nothing to do with

Applied "ASoC: arizona: call wm_adsp2_remove when codec driver is removed" to the asoc tree

The patch ASoC: arizona: call wm_adsp2_remove when codec driver is removed 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

Applied "ASoC: bcm2835: Add S16_LE support via packed DMA transfers" to the asoc tree

The patch ASoC: bcm2835: Add S16_LE support via packed DMA transfers 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 hours)

Applied "ASoC: add TA5720 digital amplifier DT bindings" to the asoc tree

The patch ASoC: add TA5720 digital amplifier DT bindings 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 hours) and sent to

Applied "ASoC: add TA5720 digital amplifier DT bindings" to the asoc tree

The patch ASoC: add TA5720 digital amplifier DT bindings 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 hours) and sent to

Applied "ASoC: dmaengine_pcm: Add support for packed transfers" to the asoc tree

The patch ASoC: dmaengine_pcm: Add support for packed transfers 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 hours) and

Applied "regulator: axp20x: Fix axp22x ldo_io voltage ranges" to the regulator tree

The patch regulator: axp20x: Fix axp22x ldo_io voltage ranges has been applied to the regulator tree at git://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

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