RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

Hi Guenter > -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Saturday, September 10, 2016 10:23 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani >

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

Hi Guenter > -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Saturday, September 10, 2016 10:23 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani > ; Bruce Ashfield > ; Bin Gao ; Pranav Tipnis > ; Heikki Krogerus > ;

ACPI/APD Making Module

Hi, Current implementation of acpi_apd.c makes AMD I2C,GPIO and UART from acpi devices to platform devices. This is done as part of boot sequence. For some reason i would like to make it kernel module. The current implementation calls acpi_apd_create_device as part of attach callback. Now this

linux-next: Tree for Sep 12

Hi all, Changes since 20160909: The arm64 tree gained a conflict against Linus' tree. The btrfs-kdave tree lost its build failure. The v4l-dvb tree gained a build failure for which I reverted a commit. The net-next tree gained a conflict against the net tree. The kbuild tree still had its

ACPI/APD Making Module

Hi, Current implementation of acpi_apd.c makes AMD I2C,GPIO and UART from acpi devices to platform devices. This is done as part of boot sequence. For some reason i would like to make it kernel module. The current implementation calls acpi_apd_create_device as part of attach callback. Now this

linux-next: Tree for Sep 12

Hi all, Changes since 20160909: The arm64 tree gained a conflict against Linus' tree. The btrfs-kdave tree lost its build failure. The v4l-dvb tree gained a build failure for which I reverted a commit. The net-next tree gained a conflict against the net tree. The kbuild tree still had its

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

On 09/11/2016 11:29 PM, vad...@mellanox.com wrote: From: Vadim Pasternak Enable system support for the Mellanox Technologies platform, which provides support for the next Mellanox basic systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

On 09/11/2016 11:29 PM, vad...@mellanox.com wrote: From: Vadim Pasternak Enable system support for the Mellanox Technologies platform, which provides support for the next Mellanox basic systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100"

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

On 09/09/2016 01:54 AM, Dave Hansen wrote: > On 09/07/2016 07:46 PM, Anshuman Khandual wrote: >> > after memory or node hot[un]plug is desirable. This change adds one >> > new sysfs interface (/sys/devices/system/memory/system_zone_details) >> > which will fetch and dump this information. >

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

On 09/09/2016 01:54 AM, Dave Hansen wrote: > On 09/07/2016 07:46 PM, Anshuman Khandual wrote: >> > after memory or node hot[un]plug is desirable. This change adds one >> > new sysfs interface (/sys/devices/system/memory/system_zone_details) >> > which will fetch and dump this information. >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: > I think this goes back to our previous discussion about support for the PMEM > programming model. Really I think what NVML needs isn't a way to tell if it > is getting a DAX mapping, but whether it is getting a DAX mapping on a >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: > I think this goes back to our previous discussion about support for the PMEM > programming model. Really I think what NVML needs isn't a way to tell if it > is getting a DAX mapping, but whether it is getting a DAX mapping on a >

RE: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Monday, September 12, 2016 7:42 AM > To: Vadim Pasternak ; t...@linutronix.de > Cc: mi...@redhat.com; da...@davemloft.net; ge...@linux-m68k.org; > a...@linux-foundation.org;

RE: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Monday, September 12, 2016 7:42 AM > To: Vadim Pasternak ; t...@linutronix.de > Cc: mi...@redhat.com; da...@davemloft.net; ge...@linux-m68k.org; > a...@linux-foundation.org; gre...@linuxfoundation.org; >

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

On 09/09/2016 07:06 PM, Michal Hocko wrote: > On Thu 08-09-16 08:16:58, Anshuman Khandual wrote: >> > Each individual node in the system has a ZONELIST_FALLBACK zonelist >> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback >> > order of zones during memory allocations.

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

On 09/09/2016 07:06 PM, Michal Hocko wrote: > On Thu 08-09-16 08:16:58, Anshuman Khandual wrote: >> > Each individual node in the system has a ZONELIST_FALLBACK zonelist >> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback >> > order of zones during memory allocations.

Use of schedule() function while holding a lock in ql4_nx.c

Hello, I was wondering about the call to schedule in function qla4_82xx_crb_win_lock for driver drivers/scsi/qla4xxx/ql4_nx.c. It is called in 2 functions [qla4_82xx_rd_32 and qla4_82xx_wr_32] while holding a write_lock_irqsave. Normally we avoid using sleeping functions while holding a lock.

Use of schedule() function while holding a lock in ql4_nx.c

Hello, I was wondering about the call to schedule in function qla4_82xx_crb_win_lock for driver drivers/scsi/qla4xxx/ql4_nx.c. It is called in 2 functions [qla4_82xx_rd_32 and qla4_82xx_wr_32] while holding a write_lock_irqsave. Normally we avoid using sleeping functions while holding a lock.

Re: [PATCH] logfs: remove from tree

On Mon, Sep 12, 2016 at 11:53:19AM +1000, Dave Chinner wrote: > Wasn't the lib/btree.c implementation introduced with and only used > by logfs? Should that go as well? The qla2xxx SCSI target driver also uses the btree library.

Re: [PATCH] logfs: remove from tree

On Mon, Sep 12, 2016 at 11:53:19AM +1000, Dave Chinner wrote: > Wasn't the lib/btree.c implementation introduced with and only used > by logfs? Should that go as well? The qla2xxx SCSI target driver also uses the btree library.

linux-next: build failure after merge of the v4l-dvb tree

Hi all, After merging the dax-misc tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition of `soc_mbus_config_compatible' drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined

linux-next: build failure after merge of the v4l-dvb tree

Hi all, After merging the dax-misc tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition of `soc_mbus_config_compatible' drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote: > On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote: > > > > > I've posted some initial work toward a) a while ago, and once we > > > > > > Did it get merged? Do you have a pointer? > > > >

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote: > On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote: > > > > > I've posted some initial work toward a) a while ago, and once we > > > > > > Did it get merged? Do you have a pointer? > > > >

Re: [PATCH 07/26] net/mlx4_core: constify local structures

On Sun, Sep 11, 2016 at 03:05:49PM +0200, Julia Lawall wrote: > For structure types defined in the same file or local header files, find > top-level static structure declarations that have the following > properties: > 1. Never reassigned. > 2. Address never taken > 3. Not passed to a top-level

Re: [PATCH 07/26] net/mlx4_core: constify local structures

On Sun, Sep 11, 2016 at 03:05:49PM +0200, Julia Lawall wrote: > For structure types defined in the same file or local header files, find > top-level static structure declarations that have the following > properties: > 1. Never reassigned. > 2. Address never taken > 3. Not passed to a top-level

Re: [PATCH] IB/rdmavt: free the userspace memory region with kfree instead of vfree

On Fri, Sep 09, 2016 at 08:15:37AM +0100, Colin King wrote: > From: Colin Ian King > > The userspace memory region 'mr' is allocated with kzalloc in > __rvt_alloc_mr however it is incorrectly being freed with vfree in > __rvt_free_mr. Fix this by using kfree to free it.

Re: [PATCH] IB/rdmavt: free the userspace memory region with kfree instead of vfree

On Fri, Sep 09, 2016 at 08:15:37AM +0100, Colin King wrote: > From: Colin Ian King > > The userspace memory region 'mr' is allocated with kzalloc in > __rvt_alloc_mr however it is incorrectly being freed with vfree in > __rvt_free_mr. Fix this by using kfree to free it. > > Signed-off-by: Colin

Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers

Borislav Petkov writes: > On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote: >> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it >> from powerpc-only drivers. >> >> Signed-off-by: Michael Ellerman >> --- >>

Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers

Borislav Petkov writes: > On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote: >> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it >> from powerpc-only drivers. >> >> Signed-off-by: Michael Ellerman >> --- >> drivers/edac/mpc85xx_edac.c | 6 +++--- >>

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote: >From: Vadim Pasternak > >Enable system support for the Mellanox Technologies platform, which >provides support for the next Mellanox basic systems: "msx6710", >"msx6720", "msb7700", "msn2700", "msx1410",

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote: >From: Vadim Pasternak > >Enable system support for the Mellanox Technologies platform, which >provides support for the next Mellanox basic systems: "msx6710", >"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",

[patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

From: Vadim Pasternak Enable system support for the Mellanox Technologies platform, which provides support for the next Mellanox basic systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100" and also various number of

[patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

From: Vadim Pasternak Enable system support for the Mellanox Technologies platform, which provides support for the next Mellanox basic systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100" and also various number of derivative systems from the

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

On Sat, Sep 10, 2016 at 12:36:57AM +, Yu, Fenghua wrote: > > > Hmm, I don't know how applications are going to use the interface. > > > Nobody knows it right now. But we do have some candicate workloads > > > which want to configure the cache partition at runtime, so it's not > > > just a boot

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

On Sat, Sep 10, 2016 at 12:36:57AM +, Yu, Fenghua wrote: > > > Hmm, I don't know how applications are going to use the interface. > > > Nobody knows it right now. But we do have some candicate workloads > > > which want to configure the cache partition at runtime, so it's not > > > just a boot

[PATCH v2] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

A discrepancy between cpu_online_mask and cpuset's effective_cpus mask is inevitable during hotplug since cpuset defers updating of effective_cpus mask using a workqueue, during which time nothing prevents the system from more hotplug operations. For that reason guarantee_online_cpus() walks up

[PATCH v2] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

A discrepancy between cpu_online_mask and cpuset's effective_cpus mask is inevitable during hotplug since cpuset defers updating of effective_cpus mask using a workqueue, during which time nothing prevents the system from more hotplug operations. For that reason guarantee_online_cpus() walks up

Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0

On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote: > tpm_write() does not check whether the buffer has at least enough space > for the header before passing it to tpm_transmit() so an overflow can > happen. Eh? tpm_write uses a hard wired buffer size of TPM_BUFSIZE when working

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

On Mon, Sep 12, 2016 at 10:48:31AM +0800, Zefan Li wrote: > Cc: Tejun > > On 2016/9/9 8:41, Joonwoo Park wrote: > > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on > > cpuset hierarchy is inevitable since cpuset defers updating of > > effective CPU masks with workqueue

Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0

On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote: > tpm_write() does not check whether the buffer has at least enough space > for the header before passing it to tpm_transmit() so an overflow can > happen. Eh? tpm_write uses a hard wired buffer size of TPM_BUFSIZE when working

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

On Mon, Sep 12, 2016 at 10:48:31AM +0800, Zefan Li wrote: > Cc: Tejun > > On 2016/9/9 8:41, Joonwoo Park wrote: > > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on > > cpuset hierarchy is inevitable since cpuset defers updating of > > effective CPU masks with workqueue

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

Hi Paul, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9395452b4aab7bc2475ef8935b4a4fb99d778d70 commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch policy to be changed date: 11 months

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

Hi Paul, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9395452b4aab7bc2475ef8935b4a4fb99d778d70 commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch policy to be changed date: 11 months

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

>Whether msync/fsync can make data persistent depends on ADR feature on >memory controller, if it exists everything works well, otherwise, we need >to have another interface that is why 'Flush hint table' in ACPI comes >in. 'Flush hint table' is particularly useful for nvdimm virtualization if >we

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

>Whether msync/fsync can make data persistent depends on ADR feature on >memory controller, if it exists everything works well, otherwise, we need >to have another interface that is why 'Flush hint table' in ACPI comes >in. 'Flush hint table' is particularly useful for nvdimm virtualization if >we

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

On Sun, 11 Sep 2016 10:31:35 -0700 Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

On Sun, 11 Sep 2016 10:31:35 -0700 Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > explicit "is dax"

[PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

Recently, Redhat reported that nvml test suite failed on QEMU/KVM, more detailed info please refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1365721 Actually, this bug is not only for NVDIMM/DAX but also for any other file systems. This simple test case abstracted from nvml can easily

[PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

Recently, Redhat reported that nvml test suite failed on QEMU/KVM, more detailed info please refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1365721 Actually, this bug is not only for NVDIMM/DAX but also for any other file systems. This simple test case abstracted from nvml can easily

Re: [PATCH] powerpc: set used_vsr/used_vr/used_spe in sigreturn path when MSR bits are active

On Tue, Jul 26, 2016 at 04:06:01PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > Normally, when MSR[VSX/VR/SPE] bits = 1, the used_vsr/used_vr/used_spe > bit have already been set. However signal frame locates at user space > and it is controlled by user

Re: [PATCH] powerpc: set used_vsr/used_vr/used_spe in sigreturn path when MSR bits are active

On Tue, Jul 26, 2016 at 04:06:01PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > Normally, when MSR[VSX/VR/SPE] bits = 1, the used_vsr/used_vr/used_spe > bit have already been set. However signal frame locates at user space > and it is controlled by user application. It is up to

Linux 4.8-rc6

Things calmed down, and look very normal. About two thirds driver updates, with half of the remainder being misc architecture updates, and the rest being random stuff (some fs/crypto fixes etc). Of course, just minutes after I pushed it out, David sent me the networking pull request, so there's

Linux 4.8-rc6

Things calmed down, and look very normal. About two thirds driver updates, with half of the remainder being misc architecture updates, and the rest being random stuff (some fs/crypto fixes etc). Of course, just minutes after I pushed it out, David sent me the networking pull request, so there's

Re: [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, Bibby: Sorry for the late reply. On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote: > From: Junzhi Zhao > > Pixel clock should be 297MHz when resolution is 4K. > >From the code you modified, I think title should be: "Enlarge pll_rate range from (, ) to (, )"

Re: [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, Bibby: Sorry for the late reply. On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote: > From: Junzhi Zhao > > Pixel clock should be 297MHz when resolution is 4K. > >From the code you modified, I think title should be: "Enlarge pll_rate range from (, ) to (, )" In description, you can

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

> -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Monday, September 12, 2016 10:24 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani >

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

> -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Monday, September 12, 2016 10:24 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani > ; Bruce Ashfield > ; Bin Gao ; Pranav Tipnis > ; Heikki Krogerus > ;

[GIT] Networking

Mostly small sets of driver fixes scattered all over the place. 1) Mediatek driver fixes from Sean Wang. Forward port not written correctly during TX map, missed handling of EPROBE_DEFER, and mistaken use of put_page() instead of skb_free_frag(). 2) Fix socket double-free in KCM code,

[GIT] Networking

Mostly small sets of driver fixes scattered all over the place. 1) Mediatek driver fixes from Sean Wang. Forward port not written correctly during TX map, missed handling of EPROBE_DEFER, and mistaken use of put_page() instead of skb_free_frag(). 2) Fix socket double-free in KCM code,

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

On Sun, Sep 11, 2016 at 4:14 PM, One Thousand Gnomes wrote: > On Fri, 9 Sep 2016 17:37:01 -0500 > Rob Herring wrote: > >> This patch series removes or prepares to remove some of the dependencies >> on tty_struct within tty_port drivers. This will

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

On Sun, Sep 11, 2016 at 4:14 PM, One Thousand Gnomes wrote: > On Fri, 9 Sep 2016 17:37:01 -0500 > Rob Herring wrote: > >> This patch series removes or prepares to remove some of the dependencies >> on tty_struct within tty_port drivers. This will allow using tty_ports >> directly for so called

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: include/linux/jump_label.h between commit: ef0da55a84a3 ("jump_labels: Allow array initialisers") from the arm64 tree and commit: b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE macros") from

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: include/linux/jump_label.h between commit: ef0da55a84a3 ("jump_labels: Allow array initialisers") from the arm64 tree and commit: b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE macros") from

Re: linux-next: manual merge of the kbuild tree with Linus' tree

On Mon, 12 Sep 2016 11:32:24 +1000 Stephen Rothwell wrote: > Hi Michal, > > Today's linux-next merge of the kbuild tree got a conflict in: > > arch/Kconfig > > between commit: > > 0f60a8efe400 ("mm: Implement stack frame object validation") > > from Linus' tree

Re: linux-next: manual merge of the kbuild tree with Linus' tree

On Mon, 12 Sep 2016 11:32:24 +1000 Stephen Rothwell wrote: > Hi Michal, > > Today's linux-next merge of the kbuild tree got a conflict in: > > arch/Kconfig > > between commit: > > 0f60a8efe400 ("mm: Implement stack frame object validation") > > from Linus' tree and commits: > >

[PATCH] iommu/vt-d: Fix the size calculation of pasid table

According to the vt-d spec, the size of pasid (state) entry is 8B which equals 3 in power of 2, the number of pasid (state) entries is (ecap_pss + 1) in power of 2. Thus the right size of pasid (state) table in power of 2 should be ecap_pss(iommu->ecap) plus "1+3=4" other than 7. Signed-off-by:

[PATCH] iommu/vt-d: Fix the size calculation of pasid table

According to the vt-d spec, the size of pasid (state) entry is 8B which equals 3 in power of 2, the number of pasid (state) entries is (ecap_pss + 1) in power of 2. Thus the right size of pasid (state) table in power of 2 should be ecap_pss(iommu->ecap) plus "1+3=4" other than 7. Signed-off-by:

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

Cc: Tejun On 2016/9/9 8:41, Joonwoo Park wrote: > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on > cpuset hierarchy is inevitable since cpuset defers updating of > effective CPU masks with workqueue while nothing prevents system from > doing CPU hotplug. For that reason

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

Cc: Tejun On 2016/9/9 8:41, Joonwoo Park wrote: > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on > cpuset hierarchy is inevitable since cpuset defers updating of > effective CPU masks with workqueue while nothing prevents system from > doing CPU hotplug. For that reason

Re: [PATCH 25/26] pch_gbe: constify local structures

Julia, I went over the networking driver patches in this series and I have to say that I'd rather see these changes be more durable and self-checking. By this I mean that I want you to also make the driver private pointer that holds these structures be const too. Then if there are really any

Re: [PATCH 25/26] pch_gbe: constify local structures

Julia, I went over the networking driver patches in this series and I have to say that I'd rather see these changes be more durable and self-checking. By this I mean that I want you to also make the driver private pointer that holds these structures be const too. Then if there are really any

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote: > > your stack trace is broken. Did you fail to install the System.map file? > > Regards > Oliver A laptop, more broken than the rest, does not output anything after inserting. Later on it crashes. No system.map

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote: > > your stack trace is broken. Did you fail to install the System.map file? > > Regards > Oliver A laptop, more broken than the rest, does not output anything after inserting. Later on it crashes. No system.map

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

Hi Guenter, On 2016년 09월 12일 11:29, Guenter Roeck wrote: > On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi wrote: >> Hi Chris, >> >> On 2016년 09월 12일 10:03, Chanwoo Choi wrote: >>> Hi Chris, >>> >>> On 2016년 09월 10일 09:33, Chris Zhong wrote: EXTCON_PROP_DISP_HPD is need

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

Hi Guenter, On 2016년 09월 12일 11:29, Guenter Roeck wrote: > On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi wrote: >> Hi Chris, >> >> On 2016년 09월 12일 10:03, Chanwoo Choi wrote: >>> Hi Chris, >>> >>> On 2016년 09월 10일 09:33, Chris Zhong wrote: EXTCON_PROP_DISP_HPD is need by display port, if

Re: [PATCH] MAINTAINERS: Add MFD's DT bindings directory to MFD entry

On Thu, 2016-09-08 at 09:07 +0100, Lee Jones wrote: > Signed-off-by: Lee Jones Reviewed-by: Andrew Jeffery > --- >  MAINTAINERS | 1 + >  1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a306795..022da8c 100644 > ---

Re: [PATCH] MAINTAINERS: Add MFD's DT bindings directory to MFD entry

On Thu, 2016-09-08 at 09:07 +0100, Lee Jones wrote: > Signed-off-by: Lee Jones Reviewed-by: Andrew Jeffery > --- >  MAINTAINERS | 1 + >  1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a306795..022da8c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@

Re: Question on smp_mb__before_spinlock

On Wed, 7 Sep 2016 14:51:47 +0100 Will Deacon wrote: > On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote: > > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > > It seems okay, but why not make it a special sched-only function name > > > to

Re: Question on smp_mb__before_spinlock

On Wed, 7 Sep 2016 14:51:47 +0100 Will Deacon wrote: > On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote: > > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > > It seems okay, but why not make it a special sched-only function name > > > to prevent it being used

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi wrote: > Hi Chris, > > On 2016년 09월 12일 10:03, Chanwoo Choi wrote: >> Hi Chris, >> >> On 2016년 09월 10일 09:33, Chris Zhong wrote: >>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd >>> interrupt, this

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi wrote: > Hi Chris, > > On 2016년 09월 12일 10:03, Chanwoo Choi wrote: >> Hi Chris, >> >> On 2016년 09월 10일 09:33, Chris Zhong wrote: >>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd >>> interrupt, this property can be used. >> >>

Re: Question on smp_mb__before_spinlock

On Wed, 7 Sep 2016 15:23:54 +0200 Peter Zijlstra wrote: > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > > /* > > > + * This barrier must provide two things: > > > + * > > > + * - it must guarantee a STORE before the spin_lock() is ordered > > >

Re: Question on smp_mb__before_spinlock

On Wed, 7 Sep 2016 15:23:54 +0200 Peter Zijlstra wrote: > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote: > > > /* > > > + * This barrier must provide two things: > > > + * > > > + * - it must guarantee a STORE before the spin_lock() is ordered > > > against a > > > + *

Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

On Sun, Sep 11, 2016 at 7:16 PM, Jun Li wrote: > Hi Guenter > >> -Original Message- >> From: Guenter Roeck [mailto:gro...@google.com] >> Sent: Saturday, September 10, 2016 10:23 AM >> To: Jun Li >> Cc: Guenter Roeck ; Felipe Balbi >>

Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

On Sun, Sep 11, 2016 at 7:16 PM, Jun Li wrote: > Hi Guenter > >> -Original Message- >> From: Guenter Roeck [mailto:gro...@google.com] >> Sent: Saturday, September 10, 2016 10:23 AM >> To: Jun Li >> Cc: Guenter Roeck ; Felipe Balbi >> ; Chandra Sekhar Anagani >> ; Bruce Ashfield >> ; Bin

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

Hi Chris, On 2016년 09월 12일 10:03, Chanwoo Choi wrote: > Hi Chris, > > On 2016년 09월 10일 09:33, Chris Zhong wrote: >> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd >> interrupt, this property can be used. > > What is meaning of HPD? So, you need to add the > description

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

Hi Chris, On 2016년 09월 12일 10:03, Chanwoo Choi wrote: > Hi Chris, > > On 2016년 09월 10일 09:33, Chris Zhong wrote: >> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd >> interrupt, this property can be used. > > What is meaning of HPD? So, you need to add the > description

RE: Kernel panic - encryption/decryption failed when open file on Arm64

Hi Ard, Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway. As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does

RE: Kernel panic - encryption/decryption failed when open file on Arm64

Hi Ard, Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway. As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does

Re: [PATCH 4/4] clk: mediatek: Add MT6797 clock support

Hi Stephen Thanks for your review. Response inlined. On Thu, 2016-09-08 at 12:50 -0700, Stephen Boyd wrote: > On 09/08/2016 03:49 AM, Mars Cheng wrote: > > Add MT6797 clock support, include topckgen, apmixedsys, > > infracfg and subsystem clocks. > > > > Signed-off-by: Mars Cheng

Re: [PATCH 4/4] clk: mediatek: Add MT6797 clock support

Hi Stephen Thanks for your review. Response inlined. On Thu, 2016-09-08 at 12:50 -0700, Stephen Boyd wrote: > On 09/08/2016 03:49 AM, Mars Cheng wrote: > > Add MT6797 clock support, include topckgen, apmixedsys, > > infracfg and subsystem clocks. > > > > Signed-off-by: Mars Cheng > > --- > >

Re: [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware

Hi Stephen, Looks good to me. But, there are something that need to be modified. - add the author information - add the description of driver - use the extcon_set_state() instead of extcon_set_cable_state_() I modified this patch and applied it because I should send the pull request within this

Re: [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware

Hi Stephen, Looks good to me. But, there are something that need to be modified. - add the author information - add the description of driver - use the extcon_set_state() instead of extcon_set_cable_state_() I modified this patch and applied it because I should send the pull request within this

Re: [PATCH] pinctrl: ret needs to be an int for -ve return value from regmap_update_bits

On Sun, 2016-09-11 at 09:36 +0100, Colin King wrote: > From: Colin Ian King > > Macro regmap_update_bits can return a -ve on an error value so ret > needs to be an integer rather than a bool type. > > Fixes warning found by static analysis with cppcheck: >

Re: [PATCH] pinctrl: ret needs to be an int for -ve return value from regmap_update_bits

On Sun, 2016-09-11 at 09:36 +0100, Colin King wrote: > From: Colin Ian King > > Macro regmap_update_bits can return a -ve on an error value so ret > needs to be an integer rather than a bool type. > > Fixes warning found by static analysis with cppcheck: >

Re: [PATCH] logfs: remove from tree

On Sun, Sep 11, 2016 at 03:04:22PM +0200, Christoph Hellwig wrote: > Logfs was introduced to the kernel in 2009, and hasn't seen any non > drive-by changes since 2012, while having lots of unsolved issues > including the complete lack of error handling, with more and more > issues popping up

Re: [PATCH] logfs: remove from tree

On Sun, Sep 11, 2016 at 03:04:22PM +0200, Christoph Hellwig wrote: > Logfs was introduced to the kernel in 2009, and hasn't seen any non > drive-by changes since 2012, while having lots of unsolved issues > including the complete lack of error handling, with more and more > issues popping up

Re: [PATCH] pinctrl: aspeed: fix regmap error handling

On Mon, 2016-09-12 at 10:52 +0930, Joel Stanley wrote: > On Fri, Sep 9, 2016 at 6:56 PM, Arnd Bergmann wrote: > > > > The newly added aspeed driver tries to check for a negative return > > value from a pinctrl function, but stores the intermediate value in > > a 'bool' variable,

Re: [PATCH] pinctrl: aspeed: fix regmap error handling

On Mon, 2016-09-12 at 10:52 +0930, Joel Stanley wrote: > On Fri, Sep 9, 2016 at 6:56 PM, Arnd Bergmann wrote: > > > > The newly added aspeed driver tries to check for a negative return > > value from a pinctrl function, but stores the intermediate value in > > a 'bool' variable, which cannot

  1   2   3   4   >