Re: [PATCH 4/9] virtio_pci: simplify MSI-X setup

On 2017年01月27日 16:16, Christoph Hellwig wrote: Try to grab the MSI-X vectors early and fall back to the shared one before doing lots of allocations. Signed-off-by: Christoph Hellwig --- Reviewed-by: Jason Wang drivers/virtio/virtio_pci_common.c | 58

Re: [PATCH 4/9] virtio_pci: simplify MSI-X setup

On 2017年01月27日 16:16, Christoph Hellwig wrote: Try to grab the MSI-X vectors early and fall back to the shared one before doing lots of allocations. Signed-off-by: Christoph Hellwig --- Reviewed-by: Jason Wang drivers/virtio/virtio_pci_common.c | 58

Re: [PATCH 3/9] virtio_pci: don't duplicate the msix_enable flag in struct pci_dev

On 2017年01月27日 16:16, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig --- Reviewed-by: Jason Wang drivers/virtio/virtio_pci_common.c | 5 ++--- drivers/virtio/virtio_pci_common.h | 2 -- drivers/virtio/virtio_pci_legacy.c | 2 +-

Re: [PATCH 3/9] virtio_pci: don't duplicate the msix_enable flag in struct pci_dev

On 2017年01月27日 16:16, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig --- Reviewed-by: Jason Wang drivers/virtio/virtio_pci_common.c | 5 ++--- drivers/virtio/virtio_pci_common.h | 2 -- drivers/virtio/virtio_pci_legacy.c | 2 +- drivers/virtio/virtio_pci_modern.c | 2 +-

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

On 2017年01月27日 16:16, Christoph Hellwig wrote: We don't really need struct virtio_pci_vq_info, as most field in there are redundant: - the vq backpointer is not strictly neede to start with - the entry in the vqs list is not needed - the generic virtqueue already has list, we only

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

On 2017年01月27日 16:16, Christoph Hellwig wrote: We don't really need struct virtio_pci_vq_info, as most field in there are redundant: - the vq backpointer is not strictly neede to start with - the entry in the vqs list is not needed - the generic virtqueue already has list, we only

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

On 2017年01月27日 16:16, Christoph Hellwig wrote: + snprintf(vp_dev->msix_names[i + 1], +sizeof(*vp_dev->msix_names), "%s-%s", dev_name(_dev->vdev.dev), names[i]); err = request_irq(pci_irq_vector(vp_dev->pci_dev,

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

On 2017年01月27日 16:16, Christoph Hellwig wrote: + snprintf(vp_dev->msix_names[i + 1], +sizeof(*vp_dev->msix_names), "%s-%s", dev_name(_dev->vdev.dev), names[i]); err = request_irq(pci_irq_vector(vp_dev->pci_dev,

ATTENTION,

ATTENTION, Your mailbox has exceeded the storage limit, which is 5 GB as defined by the administrator, who is currently running on 10.9GB, you may not be able to send or receive new mail until you re-validate your mailbox mail. To revalidate your mailbox, send the following information below:

ATTENTION,

ATTENTION, Your mailbox has exceeded the storage limit, which is 5 GB as defined by the administrator, who is currently running on 10.9GB, you may not be able to send or receive new mail until you re-validate your mailbox mail. To revalidate your mailbox, send the following information below:

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > Yeah, that might work. You could kmalloc the buffer array according to > the maxsize value. For small ones we could even consider using an on- > stack buffer. For the block direct I/O code we defintively want to avoid any allocations

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > Yeah, that might work. You could kmalloc the buffer array according to > the maxsize value. For small ones we could even consider using an on- > stack buffer. For the block direct I/O code we defintively want to avoid any allocations

Re: [PATCH 6/7] mm: vmscan: move dirty pages out of the way until they're flushed

On February 03, 2017 3:20 AM Johannes Weiner wrote: > @@ -1063,7 +1063,7 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > PageReclaim(page) && > test_bit(PGDAT_WRITEBACK, >flags)) { >

Re: [PATCH 6/7] mm: vmscan: move dirty pages out of the way until they're flushed

On February 03, 2017 3:20 AM Johannes Weiner wrote: > @@ -1063,7 +1063,7 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > PageReclaim(page) && > test_bit(PGDAT_WRITEBACK, >flags)) { >

RE: READ

Hello, I need your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley, Stationed in Uijeongbu, South Korea. Please get back to me for more info. Thank you for your time. Sgt. Monica Martinez.

RE: READ

Hello, I need your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley, Stationed in Uijeongbu, South Korea. Please get back to me for more info. Thank you for your time. Sgt. Monica Martinez.

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > > I'm not sure we need to touch any get_user_pages_fast() at all; let it > > fill a medium-sized array and use that as a buffer. In particular, > > I *really* don't like the idea of having the callbacks done in an > > inconsistent

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

On Thu, Feb 02, 2017 at 08:00:52AM -0500, Jeff Layton wrote: > > I'm not sure we need to touch any get_user_pages_fast() at all; let it > > fill a medium-sized array and use that as a buffer. In particular, > > I *really* don't like the idea of having the callbacks done in an > > inconsistent

Re: [RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

On Fri, 03 Feb 2017 06:28:08 +0100, Satendra Singh Thakur wrote: > > From: satendra singh thakur > > 1.Added 2 ioctls in alsa driver's control interface > -Added an ioctl to read values of multiple elements at once > -Added an ioctl to write values of multiple elements

Re: [RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

On Fri, 03 Feb 2017 06:28:08 +0100, Satendra Singh Thakur wrote: > > From: satendra singh thakur > > 1.Added 2 ioctls in alsa driver's control interface > -Added an ioctl to read values of multiple elements at once > -Added an ioctl to write values of multiple elements at once > -In the absence

Re: [RFC] [ALSA][CONTROL] Added 2 ioctls for reading/writing values of multiple controls in one go (at once)

On Thu, 02 Feb 2017 04:45:48 +0100, Takashi Sakamoto wrote: > > Hi, > > On Feb 2 2017 12:14, Satendra Singh Thakur wrote: > > From: satendra singh thakur > > > > -Added 2 ioctls in alsa driver's control interface > > -Added an ioctl to read values of multiple elements at

Re: [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

On 26/01/17 20:41, Boris Ostrovsky wrote: > Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall > page, initialize boot_params, enable early page tables. > > Since this stub is executed before kernel entry point we cannot use > variables in .bss which is cleared by kernel. We

Re: [RFC] [ALSA][CONTROL] Added 2 ioctls for reading/writing values of multiple controls in one go (at once)

On Thu, 02 Feb 2017 04:45:48 +0100, Takashi Sakamoto wrote: > > Hi, > > On Feb 2 2017 12:14, Satendra Singh Thakur wrote: > > From: satendra singh thakur > > > > -Added 2 ioctls in alsa driver's control interface > > -Added an ioctl to read values of multiple elements at once > > -Added an

Re: [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

On 26/01/17 20:41, Boris Ostrovsky wrote: > Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall > page, initialize boot_params, enable early page tables. > > Since this stub is executed before kernel entry point we cannot use > variables in .bss which is cleared by kernel. We

Re: [PATCH 4.9 00/51] 4.9.8-stable review

On Thu, Feb 02, 2017 at 09:14:30PM -0800, Guenter Roeck wrote: > On 02/02/2017 10:37 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.8 release. > > There are 51 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 00/51] 4.9.8-stable review

On Thu, Feb 02, 2017 at 09:14:30PM -0800, Guenter Roeck wrote: > On 02/02/2017 10:37 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.8 release. > > There are 51 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 00/10] android: binder: support for domains and scatter-gather.

On Thu, Feb 02, 2017 at 08:56:04PM -0800, John Stultz wrote: > On Mon, Oct 24, 2016 at 6:20 AM, Martijn Coenen wrote: > > Android userspace will start using binder IPC for communication with HAL > > modules. To clearly separate this IPC domain from the existing framework > > IPC

Re: [PATCH 00/10] android: binder: support for domains and scatter-gather.

On Thu, Feb 02, 2017 at 08:56:04PM -0800, John Stultz wrote: > On Mon, Oct 24, 2016 at 6:20 AM, Martijn Coenen wrote: > > Android userspace will start using binder IPC for communication with HAL > > modules. To clearly separate this IPC domain from the existing framework > > IPC domain, this

Re: [PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

On 01/27/17 at 05:03pm, Ard Biesheuvel wrote: > On 16 January 2017 at 02:45, Dave Young wrote: > > Hi, > > > > Here the the update of the series for moving bgrt init code to early init. > > > > Main changes is: > > - Move the 1st patch to the last because it does not block the

Re: [PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

On 01/27/17 at 05:03pm, Ard Biesheuvel wrote: > On 16 January 2017 at 02:45, Dave Young wrote: > > Hi, > > > > Here the the update of the series for moving bgrt init code to early init. > > > > Main changes is: > > - Move the 1st patch to the last because it does not block the 2nd patch > > any

ATTENZIONE;

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

ATTENZIONE;

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

[PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches

When for instance a mobile Linux device roams from one access point to another with both APs sharing the same broadcast domain and a multicast snooping switch in between: 1)(c) <~~~> (AP1) <--[SSW]--> (AP2) 2) (AP1) <--[SSW]--> (AP2) <~~~> (c) Then currently IPv6 multicast

[PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches

When for instance a mobile Linux device roams from one access point to another with both APs sharing the same broadcast domain and a multicast snooping switch in between: 1)(c) <~~~> (AP1) <--[SSW]--> (AP2) 2) (AP1) <--[SSW]--> (AP2) <~~~> (c) Then currently IPv6 multicast

Re: [PATCH 1/4] selftests, x86, protection_keys: fix unused variable compile warnings

* Shuah Khan wrote: > On 02/02/2017 04:45 PM, Dave Hansen wrote: > > On 02/02/2017 03:36 PM, Shuah Khan wrote: > >> This patches is already in linux-kselftest next for 4.11 > >> > >> Is there a reason why you chose to resend these. > > > > Oh, my apologies! I didn't

Re: [PATCH 1/4] selftests, x86, protection_keys: fix unused variable compile warnings

* Shuah Khan wrote: > On 02/02/2017 04:45 PM, Dave Hansen wrote: > > On 02/02/2017 03:36 PM, Shuah Khan wrote: > >> This patches is already in linux-kselftest next for 4.11 > >> > >> Is there a reason why you chose to resend these. > > > > Oh, my apologies! I didn't realize it had been picked

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

2017년 02월 03일 15:38에 Inki Dae 이(가) 쓴 글: > > > 2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글: >> On TM2/TM2e platforms HDMI output is connected to MHL bridge >> SiI8620. To allow configure UltraHD modes on the bridge >> and to eliminate unsupported modes this bridge should be >> attached to

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

2017년 02월 03일 15:38에 Inki Dae 이(가) 쓴 글: > > > 2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글: >> On TM2/TM2e platforms HDMI output is connected to MHL bridge >> SiI8620. To allow configure UltraHD modes on the bridge >> and to eliminate unsupported modes this bridge should be >> attached to

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글: > On TM2/TM2e platforms HDMI output is connected to MHL bridge > SiI8620. To allow configure UltraHD modes on the bridge > and to eliminate unsupported modes this bridge should be > attached to drm_encoder implemented in exynos_hdmi. > >

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글: > On TM2/TM2e platforms HDMI output is connected to MHL bridge > SiI8620. To allow configure UltraHD modes on the bridge > and to eliminate unsupported modes this bridge should be > attached to drm_encoder implemented in exynos_hdmi. > >

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 02, 2017 at 11:44:22AM +0100, Michal Hocko wrote: > On Tue 31-01-17 14:32:08, Vinayak Menon wrote: > > During global reclaim, the nr_reclaimed passed to vmpressure > > includes the pages reclaimed from slab. But the corresponding > > scanned slab pages is not passed. This can cause

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 02, 2017 at 11:44:22AM +0100, Michal Hocko wrote: > On Tue 31-01-17 14:32:08, Vinayak Menon wrote: > > During global reclaim, the nr_reclaimed passed to vmpressure > > includes the pages reclaimed from slab. But the corresponding > > scanned slab pages is not passed. This can cause

Re: [PATCH] pciehp: Fix race condition handling surprise link-down

Hi Bjorn On Thu, Feb 02, 2017 at 08:59:01PM -0600, Bjorn Helgaas wrote: > Hi Ashok, > > Sorry it took me so long to review this. I never felt like I really > understood it, and it took me a long time to try to figure out a more > useful response. No worries. Agree its a litte tricky, and took

Re: [PATCH] pciehp: Fix race condition handling surprise link-down

Hi Bjorn On Thu, Feb 02, 2017 at 08:59:01PM -0600, Bjorn Helgaas wrote: > Hi Ashok, > > Sorry it took me so long to review this. I never felt like I really > understood it, and it took me a long time to try to figure out a more > useful response. No worries. Agree its a litte tricky, and took

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글: > On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote: >> On 1 February 2017 at 14:52, Thierry Reding wrote: >>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: Thierry Reding

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글: > On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote: >> On 1 February 2017 at 14:52, Thierry Reding wrote: >>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: Thierry Reding writes: > [ Unknown signature status ]

[PATCH v2 3/4] seccomp: Create an action to log before allowing

Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set

[PATCH v2 1/4] seccomp: Add sysctl to display available actions

This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow".

[PATCH v2 3/4] seccomp: Create an action to log before allowing

Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set

[PATCH v2 1/4] seccomp: Add sysctl to display available actions

This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow".

[PATCH v2 2/4] seccomp: Add sysctl to configure actions that should be logged

Administrators can write to this sysctl to set the maximum seccomp action that should be logged. Any actions with values greater than what's written to the sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be logged if "errno" were

[PATCH v2 4/4] seccomp: Add tests for SECCOMP_RET_LOG

Extend the kernel selftests for seccomp to test the newly added SECCOMP_RET_LOG action. The added tests follow the example of existing tests. Unfortunately, the tests are not capable of inspecting the audit log to verify that the syscall was logged. Signed-off-by: Tyler Hicks

[PATCH v2 2/4] seccomp: Add sysctl to configure actions that should be logged

Administrators can write to this sysctl to set the maximum seccomp action that should be logged. Any actions with values greater than what's written to the sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be logged if "errno" were

[PATCH v2 4/4] seccomp: Add tests for SECCOMP_RET_LOG

Extend the kernel selftests for seccomp to test the newly added SECCOMP_RET_LOG action. The added tests follow the example of existing tests. Unfortunately, the tests are not capable of inspecting the audit log to verify that the syscall was logged. Signed-off-by: Tyler Hicks ---

[PATCH v2 0/4] Improved seccomp logging

This patch set is the second revision of the following two previously submitted patch sets: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhi...@canonical.com http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhi...@canonical.com The patch set aims to address some known

[PATCH v2 0/4] Improved seccomp logging

This patch set is the second revision of the following two previously submitted patch sets: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhi...@canonical.com http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhi...@canonical.com The patch set aims to address some known

[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

linux-next: Tree for Feb 3

Hi all, Changes since 20170202: Dropped tree: vfs-miklos (build failure and out of date) The powerpc tree gained a conflict against the powerpc-fixes tree. The vfs-miklos tree still had its build failure, so I just dropped it again for today. The v4l-dvb tree still had its build failure so I

linux-next: Tree for Feb 3

Hi all, Changes since 20170202: Dropped tree: vfs-miklos (build failure and out of date) The powerpc tree gained a conflict against the powerpc-fixes tree. The vfs-miklos tree still had its build failure, so I just dropped it again for today. The v4l-dvb tree still had its build failure so I

[RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

From: satendra singh thakur 1.Added 2 ioctls in alsa driver's control interface -Added an ioctl to read values of multiple elements at once -Added an ioctl to write values of multiple elements at once -In the absence of above ioctls user needs to call N ioctls to

[RFC v2] [ALSA][CONTROL] 1. Added 2 ioctls for reading/writing values of multiple controls in one go (at once) 2. Restructured the code for read/write of a single control

From: satendra singh thakur 1.Added 2 ioctls in alsa driver's control interface -Added an ioctl to read values of multiple elements at once -Added an ioctl to write values of multiple elements at once -In the absence of above ioctls user needs to call N ioctls to read/write value of N elements

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko wrote: > > Why would you like to chose and kill a task when the slab reclaim can > still make sufficient progres? Are you sure that the slab contribution > to the stats makes all the above happening? > I agree that a task need not be

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko wrote: > > Why would you like to chose and kill a task when the slab reclaim can > still make sufficient progres? Are you sure that the slab contribution > to the stats makes all the above happening? > I agree that a task need not be killed if

[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

[PATCH v4] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. [Patch v1] is rejected as the changes done is not following the linux coding style and [Patch v2] is rejected because forgot to mention the cause of rejection of [Patch v1].The cause of rejection of [Patch v3] is that the

Re: [PATCH 4.9 00/51] 4.9.8-stable review

On 02/02/2017 10:37 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.8 release. There are 51 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/51] 4.9.8-stable review

On 02/02/2017 10:37 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.8 release. There are 51 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/20] 4.4.47-stable review

On 02/02/2017 10:33 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.47 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/20] 4.4.47-stable review

On 02/02/2017 10:33 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.47 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

Chris Packham writes: > On 03/02/17 12:55, Michael Ellerman wrote: >> Chris if you want to send a patch to add the compatible string to the >> l2cache.txt I would merge that, but honestly it doesn't achieve much >> other than possibly catching a typo in the

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

Chris Packham writes: > On 03/02/17 12:55, Michael Ellerman wrote: >> Chris if you want to send a patch to add the compatible string to the >> l2cache.txt I would merge that, but honestly it doesn't achieve much >> other than possibly catching a typo in the compatible name. > > I think catching

Re: modversions: redefine kcrctab entries as 32-bit values

+++ Jessica Yu [02/02/17 22:54 -0500]: +++ Ard Biesheuvel [24/01/17 16:16 +]: This v4 is a followup to [0] 'modversions: redefine kcrctab entries as relative CRC pointers', but since relative CRC pointers do not work in modules, and are actually only needed by powerpc with

Re: modversions: redefine kcrctab entries as 32-bit values

+++ Jessica Yu [02/02/17 22:54 -0500]: +++ Ard Biesheuvel [24/01/17 16:16 +]: This v4 is a followup to [0] 'modversions: redefine kcrctab entries as relative CRC pointers', but since relative CRC pointers do not work in modules, and are actually only needed by powerpc with

Re: [PATCH 00/10] android: binder: support for domains and scatter-gather.

On Mon, Oct 24, 2016 at 6:20 AM, Martijn Coenen wrote: > Android userspace will start using binder IPC for communication with HAL > modules. To clearly separate this IPC domain from the existing framework > IPC domain, this patch series adds support for multiple "binder

Re: [PATCH 00/10] android: binder: support for domains and scatter-gather.

On Mon, Oct 24, 2016 at 6:20 AM, Martijn Coenen wrote: > Android userspace will start using binder IPC for communication with HAL > modules. To clearly separate this IPC domain from the existing framework > IPC domain, this patch series adds support for multiple "binder domains". > This is

linux-next: manual merge of the akpm tree with the block tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: fs/block_dev.c between commit: b1d2dc5659b4 ("block: Make blk_get_backing_dev_info() safe without open bdev") from the block tree and patch: "fs: add i_blocksize()" from the akpm tree. I fixed it up (see below)

linux-next: manual merge of the akpm tree with the block tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: fs/block_dev.c between commit: b1d2dc5659b4 ("block: Make blk_get_backing_dev_info() safe without open bdev") from the block tree and patch: "fs: add i_blocksize()" from the akpm tree. I fixed it up (see below)

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글: > On 1 February 2017 at 14:52, Thierry Reding wrote: >> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: >>> Thierry Reding writes: >>> [ Unknown signature status ] On Tue, Jan

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글: > On 1 February 2017 at 14:52, Thierry Reding wrote: >> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: >>> Thierry Reding writes: >>> [ Unknown signature status ] On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

[ 173.493547] [c004f7b83e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74 [ 243.913715] INFO: task kworker/0:2:380 blocked for more than 120 seconds. [ 243.913732] Not tainted 4.10.0-rc6-next-20170202 #6 [ 243.913735] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" dis

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

b4e8] ret_from_kernel_thread+0x5c/0x74 [ 243.913715] INFO: task kworker/0:2:380 blocked for more than 120 seconds. [ 243.913732] Not tainted 4.10.0-rc6-next-20170202 #6 [ 243.913735] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.913738] kworker/

Re: [PATCH 3/3] MIPS: BMIPS: enable CPUfreq

On 01-02-17, 17:06, Markus Mayer wrote: > From: Markus Mayer > > Enable all applicable CPUfreq options. > > Signed-off-by: Markus Mayer > --- > arch/mips/configs/bmips_stb_defconfig | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git

Re: [PATCH 3/3] MIPS: BMIPS: enable CPUfreq

On 01-02-17, 17:06, Markus Mayer wrote: > From: Markus Mayer > > Enable all applicable CPUfreq options. > > Signed-off-by: Markus Mayer > --- > arch/mips/configs/bmips_stb_defconfig | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/mips/configs/bmips_stb_defconfig >

Re: [PATCH 2/3] cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs

You must be a cpufreq driver expert by now. What's the count? Is this the 3rd one you have written ? :) On 01-02-17, 17:06, Markus Mayer wrote: > diff --git a/drivers/cpufreq/bmips-cpufreq.c b/drivers/cpufreq/bmips-cpufreq.c > +static struct cpufreq_frequency_table * >

Re: [PATCH 2/3] cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs

You must be a cpufreq driver expert by now. What's the count? Is this the 3rd one you have written ? :) On 01-02-17, 17:06, Markus Mayer wrote: > diff --git a/drivers/cpufreq/bmips-cpufreq.c b/drivers/cpufreq/bmips-cpufreq.c > +static struct cpufreq_frequency_table * >

Re: [patch 1/3] cpufreq: implement min/max/up/down functions

On 02-02-17, 15:47, Marcelo Tosatti wrote: > +++ kvm-pvfreq/drivers/cpufreq/cpufreq_userspace.c2017-02-02 > 15:32:53.456262640 -0200 > @@ -118,6 +118,178 @@ > mutex_unlock(_mutex); > } > > +static int cpufreq_is_userspace_governor(int cpu) > +{ > + int ret; > + > +

Re: [patch 1/3] cpufreq: implement min/max/up/down functions

On 02-02-17, 15:47, Marcelo Tosatti wrote: > +++ kvm-pvfreq/drivers/cpufreq/cpufreq_userspace.c2017-02-02 > 15:32:53.456262640 -0200 > @@ -118,6 +118,178 @@ > mutex_unlock(_mutex); > } > > +static int cpufreq_is_userspace_governor(int cpu) > +{ > + int ret; > + > +

Re: modversions: redefine kcrctab entries as 32-bit values

+++ Ard Biesheuvel [24/01/17 16:16 +]: This v4 is a followup to [0] 'modversions: redefine kcrctab entries as relative CRC pointers', but since relative CRC pointers do not work in modules, and are actually only needed by powerpc with CONFIG_RELOCATABLE=y, I have made it a Kconfig selectable

Re: modversions: redefine kcrctab entries as 32-bit values

+++ Ard Biesheuvel [24/01/17 16:16 +]: This v4 is a followup to [0] 'modversions: redefine kcrctab entries as relative CRC pointers', but since relative CRC pointers do not work in modules, and are actually only needed by powerpc with CONFIG_RELOCATABLE=y, I have made it a Kconfig selectable

[PATCH] Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"

This reverts commit c7070619f3408d9a0dffbed9149e6f00479cf43b. This has been shown to regress on some ARM systems: by forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly

[PATCH] Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"

This reverts commit c7070619f3408d9a0dffbed9149e6f00479cf43b. This has been shown to regress on some ARM systems: by forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly

Re: [PATCH] thermal: use cpumask_var_t for on-stack cpu masks

On 02-02-17, 15:46, Arnd Bergmann wrote: > Putting a bare cpumask structure on the stack produces a warning on > large SMP configurations: > > drivers/thermal/cpu_cooling.c: In function 'cpufreq_state2power': > drivers/thermal/cpu_cooling.c:644:1: warning: the frame size of 1056 bytes is >

Re: [PATCH] thermal: use cpumask_var_t for on-stack cpu masks

On 02-02-17, 15:46, Arnd Bergmann wrote: > Putting a bare cpumask structure on the stack produces a warning on > large SMP configurations: > > drivers/thermal/cpu_cooling.c: In function 'cpufreq_state2power': > drivers/thermal/cpu_cooling.c:644:1: warning: the frame size of 1056 bytes is >

Re: [PATCHv2] ARM: dts: Add EMAC AXI settings for Arria10

On Thu, Feb 2, 2017 at 4:05 PM, wrote: > From: Thor Thayer > > Add the device tree entries needed to support the EMAC AXI > bus settings on the Arria10 SoCFPGA chip. > > Signed-off-by: Thor Thayer > --- > v2

Re: [PATCHv2] ARM: dts: Add EMAC AXI settings for Arria10

On Thu, Feb 2, 2017 at 4:05 PM, wrote: > From: Thor Thayer > > Add the device tree entries needed to support the EMAC AXI > bus settings on the Arria10 SoCFPGA chip. > > Signed-off-by: Thor Thayer > --- > v2 Add the AXI configuration to the other DW EMACs in the chip. > --- >

[PATCH 1/4] ARM: dts: armada-xp-98dx3236: combine dfx server nodes

Rather than having a separate node for the dfx server add a reg property to the parent node. This give somes compatibility with the Marvell supplied SDK. Signed-off-by: Chris Packham --- Documentation/devicetree/bindings/net/marvell,prestera.txt | 13

[PATCH 1/4] ARM: dts: armada-xp-98dx3236: combine dfx server nodes

Rather than having a separate node for the dfx server add a reg property to the parent node. This give somes compatibility with the Marvell supplied SDK. Signed-off-by: Chris Packham --- Documentation/devicetree/bindings/net/marvell,prestera.txt | 13 +

[PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support

The initial implementation in commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency. Port code from the Marvell supplied Linux kernel to support different PLL frequencies and provide clock gating support. Signed-off-by: Chris Packham

[PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support

The initial implementation in commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency. Port code from the Marvell supplied Linux kernel to support different PLL frequencies and provide clock gating support. Signed-off-by: Chris Packham ---

  1   2   3   4   5   6   7   8   9   10   >