[PATCH v4 2/2] clk: uniphier: add clock data for UniPhier SoCs

Add clock data arrays for all UniPhier SoCs. Signed-off-by: Masahiro Yamada --- .../devicetree/bindings/clock/uniphier-clock.txt | 123 drivers/clk/uniphier/Makefile | 3 + drivers/clk/uniphier/clk-uniphier-core.c | 91 +++

[PATCH v4 2/2] clk: uniphier: add clock data for UniPhier SoCs

Add clock data arrays for all UniPhier SoCs. Signed-off-by: Masahiro Yamada --- .../devicetree/bindings/clock/uniphier-clock.txt | 123 drivers/clk/uniphier/Makefile | 3 + drivers/clk/uniphier/clk-uniphier-core.c | 91 +++

[PATCH v4 0/2] clk: uniphier: add clock drivers for UniPhier SoCs

I split into two patches to make review easier. 1/2: core support code 2/2: data arrays Changes in v4: - Unify module_platform_driver() boilerplate into a single place - Add binding document - Add USB3 clocks Changes in v3: - Change to platform drivers instead of OF_CLK_DECLARE -

[PATCH v4 1/2] clk: uniphier: add core support code for UniPhier clock drivers

This is the common code for the clock drivers of UniPhier SoCs. Signed-off-by: Masahiro Yamada --- MAINTAINERS | 1 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile

[PATCH v4 0/2] clk: uniphier: add clock drivers for UniPhier SoCs

I split into two patches to make review easier. 1/2: core support code 2/2: data arrays Changes in v4: - Unify module_platform_driver() boilerplate into a single place - Add binding document - Add USB3 clocks Changes in v3: - Change to platform drivers instead of OF_CLK_DECLARE -

[PATCH v4 1/2] clk: uniphier: add core support code for UniPhier clock drivers

This is the common code for the clock drivers of UniPhier SoCs. Signed-off-by: Masahiro Yamada --- MAINTAINERS | 1 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 +

Re: [PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

On Tue, 2016-07-26 at 13:39 -0400, Jarod Wilson wrote: > Per Jesse Brandeburg, e1000e should be using flags for this sort of > thing. > > Littering functional code with device-specific checks is much messier > than > simply checking a flag, and having device-specific init set flags as > needed. >

Re: [PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

On Tue, 2016-07-26 at 13:39 -0400, Jarod Wilson wrote: > Per Jesse Brandeburg, e1000e should be using flags for this sort of > thing. > > Littering functional code with device-specific checks is much messier > than > simply checking a flag, and having device-specific init set flags as > needed. >

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Tue, 26 Jul 2016 11:26:42 -0500 Josh Poimboeuf wrote: > Ok, I think that makes sense to me now. As I understand it, the > "outermost" RIP is the authoritative one, because it was written by the > original NMI. Any nested NMIs will update the original and/or iret >

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Tue, 26 Jul 2016 11:26:42 -0500 Josh Poimboeuf wrote: > Ok, I think that makes sense to me now. As I understand it, the > "outermost" RIP is the authoritative one, because it was written by the > original NMI. Any nested NMIs will update the original and/or iret > RIPs, which will only

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Tue, Jul 26, 2016 at 12:47 PM, Josh Poimboeuf wrote: > On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: >> On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: >> > Am I correct in understanding that there can only be one level of

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Tue, Jul 26, 2016 at 12:47 PM, Josh Poimboeuf wrote: > On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: >> On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: >> > Am I correct in understanding that there can only be one level of NMI >> > nesting at any given time? If so,

Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 26 Jul 2016 07:09:41 + > I googled "S390 hypervisor socket" but didn't find anything related (I think). That would be net/iucv/ There's also VMWare's stuff under net/vmw_vsock It's just absolutely rediculous to make a new hypervisor socket

Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 26 Jul 2016 07:09:41 + > I googled "S390 hypervisor socket" but didn't find anything related (I think). That would be net/iucv/ There's also VMWare's stuff under net/vmw_vsock It's just absolutely rediculous to make a new hypervisor socket interface over and

Re: [PATCH] checkpatch: Improve 'bare use of' signed/unsigned types warning

On Tue, Jul 26, 2016 at 03:40:21AM -0700, Joe Perches wrote: > Fix false positive warning of identifiers ending in signed with an = > assignment of WARNING: Prefer 'signed int' to bare use of 'signed'. > > Reported-by: Alan Douglas > Signed-off-by: Joe Perches

Re: [PATCH] checkpatch: Improve 'bare use of' signed/unsigned types warning

On Tue, Jul 26, 2016 at 03:40:21AM -0700, Joe Perches wrote: > Fix false positive warning of identifiers ending in signed with an = > assignment of WARNING: Prefer 'signed int' to bare use of 'signed'. > > Reported-by: Alan Douglas > Signed-off-by: Joe Perches > --- > scripts/checkpatch.pl | 2

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

On Tue, 26 Jul 2016 15:04:26 +0800 Chen-Yu Tsai wrote: > Some clock muxes have holes, i.e. invalid or unconnected inputs, > between parent mux values. > > Add support for specifying a mux table to map clock parents to > mux values. Putting empty strings in the holes should work.

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

On Tue, 26 Jul 2016 15:04:26 +0800 Chen-Yu Tsai wrote: > Some clock muxes have holes, i.e. invalid or unconnected inputs, > between parent mux values. > > Add support for specifying a mux table to map clock parents to > mux values. Putting empty strings in the holes should work. No? Ex:

[PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

Per Jesse Brandeburg, e1000e should be using flags for this sort of thing. Littering functional code with device-specific checks is much messier than simply checking a flag, and having device-specific init set flags as needed. There are probably a number of other cases in the e1000e code that

[PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

Per Jesse Brandeburg, e1000e should be using flags for this sort of thing. Littering functional code with device-specific checks is much messier than simply checking a flag, and having device-specific init set flags as needed. There are probably a number of other cases in the e1000e code that

[tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

Commit-ID: efaad554b4ffae1840a2759e09e21325ddbc8b05 Gitweb: http://git.kernel.org/tip/efaad554b4ffae1840a2759e09e21325ddbc8b05 Author: Borislav Petkov AuthorDate: Tue, 26 Jul 2016 11:51:38 +0200 Committer: Ingo Molnar CommitDate: Tue, 26 Jul 2016

[tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

Commit-ID: efaad554b4ffae1840a2759e09e21325ddbc8b05 Gitweb: http://git.kernel.org/tip/efaad554b4ffae1840a2759e09e21325ddbc8b05 Author: Borislav Petkov AuthorDate: Tue, 26 Jul 2016 11:51:38 +0200 Committer: Ingo Molnar CommitDate: Tue, 26 Jul 2016 19:32:57 +0200 x86/microcode/intel:

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote: > David Vrabel writes: > > > On 26/07/16 13:30, Vitaly Kuznetsov wrote: > >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In > >> particular, when we crash on a secondary vCPU we may want to do kdump > >> and

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote: > David Vrabel writes: > > > On 26/07/16 13:30, Vitaly Kuznetsov wrote: > >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In > >> particular, when we crash on a secondary vCPU we may want to do kdump > >> and unlike plain kexec where

[PATCH v4 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[PATCH v4 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are actually changing; the values for

[PATCH v4 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v4 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v4 6/6] drm/i915/skl: Always wait for pipes to update after a flush

Unfortunately right now we don't really update watermarks on Skylake properly, since ideally we'd be updating both the ddb allocations, plane properties, and watermarks all in a single go. Until this is fixed however, we can improve things somewhat by adding a vblank wait after the third iteration

[PATCH v4 5/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v4 4/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-)

[PATCH v4 6/6] drm/i915/skl: Always wait for pipes to update after a flush

Unfortunately right now we don't really update watermarks on Skylake properly, since ideally we'd be updating both the ddb allocations, plane properties, and watermarks all in a single go. Until this is fixed however, we can improve things somewhat by adding a vblank wait after the third iteration

[PATCH v4 5/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v4 4/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH v4 3/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[PATCH v4 0/6] Finally fix watermarks

Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the whole thing to keep it in one place. Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Only flush pipes when we change the ddb allocation drm/i915/skl: Fix extra whitespace in

[PATCH v4 3/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[PATCH v4 0/6] Finally fix watermarks

Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the whole thing to keep it in one place. Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Only flush pipes when we change the ddb allocation drm/i915/skl: Fix extra whitespace in

RE: [RFC patch 1/6] random: Simplify API for random address requests

> -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Monday, July 25, 2016 8:31 PM > To: Roberts, William C ; linux- > m...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel- > harden...@lists.openwall.com > Cc:

RE: [RFC patch 1/6] random: Simplify API for random address requests

> -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Monday, July 25, 2016 8:31 PM > To: Roberts, William C ; linux- > m...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel- > harden...@lists.openwall.com > Cc: li...@arm.linux.org.uk;

Re: [PATCHv1, RFC 00/33] ext4: support of huge pages

On Tue, Jul 26, 2016 at 03:35:02AM +0300, Kirill A. Shutemov wrote: > Here's the first version of my patchset which intended to bring huge pages > to ext4. It's not yet ready for applying or serious use, but good enough > to show the approach. Thanks. The major issues I noticed when doing a

Re: [PATCHv1, RFC 00/33] ext4: support of huge pages

On Tue, Jul 26, 2016 at 03:35:02AM +0300, Kirill A. Shutemov wrote: > Here's the first version of my patchset which intended to bring huge pages > to ext4. It's not yet ready for applying or serious use, but good enough > to show the approach. Thanks. The major issues I noticed when doing a

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On 26 July 2016 at 18:52, Kees Cook wrote: > On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman > wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> Hello Eric, >>> >>> I realized I had a question after the last mail. >>>

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On 26 July 2016 at 18:52, Kees Cook wrote: > On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman > wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> Hello Eric, >>> >>> I realized I had a question after the last mail. >>> >>> On 07/21/2016 06:39 PM, Eric W. Biederman wrote: This

[GIT PULL] libata changes for v4.8-rc1

Hello, Linus. libata saw quite a bit of activities in this cycle. * SMR drive support still being worked on. * Bug fixes and improvements to misc SCSI command emulation. * Some low level driver updates. Thanks. The following changes since commit dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6:

[GIT PULL] libata changes for v4.8-rc1

Hello, Linus. libata saw quite a bit of activities in this cycle. * SMR drive support still being worked on. * Bug fixes and improvements to misc SCSI command emulation. * Some low level driver updates. Thanks. The following changes since commit dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6:

[PATCH] perf: sched out groups atomically

Groups of events are supposed to be scheduled atomically, such that it is possible to derive meaningful ratios between their values. We take great pains to achieve this when scheduling event groups to a PMU in group_sched_in(), calling {start,commit}_txn() (which fall back to

[PATCH] perf: sched out groups atomically

Groups of events are supposed to be scheduled atomically, such that it is possible to derive meaningful ratios between their values. We take great pains to achieve this when scheduling event groups to a PMU in group_sched_in(), calling {start,commit}_txn() (which fall back to

[GIT PULL] cgroup changes for v4.8-rc1

Hello, Linus. Nothing too exciting. * Updates to the pids controller so that pid limit breaches can be noticed and monitored from userland. * Cleanups and non-critical bug fixes. Thanks. The following changes since commit db06d759d6cf903aeda8c107fd3abd366dd80200: Merge branch

[GIT PULL] cgroup changes for v4.8-rc1

Hello, Linus. Nothing too exciting. * Updates to the pids controller so that pid limit breaches can be noticed and monitored from userland. * Cleanups and non-critical bug fixes. Thanks. The following changes since commit db06d759d6cf903aeda8c107fd3abd366dd80200: Merge branch

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

On Sat, 23 Jul 2016, Marcelo Tosatti wrote: On Fri, Jul 22, 2016 at 02:43:23PM -0700, Luck, Tony wrote: On Fri, Jul 22, 2016 at 04:12:04AM -0300, Marcelo Tosatti wrote: How does this patchset handle the following condition: 6) Create reservations in such a way that the sum is larger than

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

On Sat, 23 Jul 2016, Marcelo Tosatti wrote: On Fri, Jul 22, 2016 at 02:43:23PM -0700, Luck, Tony wrote: On Fri, Jul 22, 2016 at 04:12:04AM -0300, Marcelo Tosatti wrote: How does this patchset handle the following condition: 6) Create reservations in such a way that the sum is larger than

[PATCH v2] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

The workqueue health->wq was used as per device private health thread. This was done to perform delayed work. The workqueue has a single workitem(>work) and hence doesn't require ordering. It is involved in handling the health of the device and is not being used on a memory reclaim path. Hence,

[PATCH v2] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

The workqueue health->wq was used as per device private health thread. This was done to perform delayed work. The workqueue has a single workitem(>work) and hence doesn't require ordering. It is involved in handling the health of the device and is not being used on a memory reclaim path. Hence,

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Tue, Jul 26, 2016 at 10:00 AM, Jason Cooper wrote: > Hi Kees, > > On Mon, Jul 25, 2016 at 09:39:58PM -0700, Kees Cook wrote: >> On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: >> > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote:

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Tue, Jul 26, 2016 at 10:00 AM, Jason Cooper wrote: > Hi Kees, > > On Mon, Jul 25, 2016 at 09:39:58PM -0700, Kees Cook wrote: >> On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: >> > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: >> >> To date, all callers of

Re: [PATCH BUGFIX V4] block: add missing group association in bio-cloning functions

Hi, [auto build test WARNING on block/for-next] [also build test WARNING on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paolo-Valente/block-add-missing-group-association

Re: [PATCH BUGFIX V4] block: add missing group association in bio-cloning functions

Hi, [auto build test WARNING on block/for-next] [also build test WARNING on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paolo-Valente/block-add-missing-group-association

Re: [PATCH] cfag12864b: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:23:00PM +0530, Bhaktipriya Shridhar wrote: > @@ -257,7 +256,6 @@ void cfag12864b_disable(void) > if (cfag12864b_updating) { > cfag12864b_updating = 0; > cancel_delayed_work(_work); > - flush_workqueue(cfag12864b_workqueue);

Re: [PATCH] cfag12864b: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:23:00PM +0530, Bhaktipriya Shridhar wrote: > @@ -257,7 +256,6 @@ void cfag12864b_disable(void) > if (cfag12864b_updating) { > cfag12864b_updating = 0; > cancel_delayed_work(_work); > - flush_workqueue(cfag12864b_workqueue);

Re: [PATCH] mmc: rtsx: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:31:06PM +0530, Bhaktipriya Shridhar wrote: > The workqueue "workq" provides support for sd/mmc async request, which > makes next request do dma_map_sg() while previous request transferring > data. > > The workqueue has a single workitem(>work) and hence doesn't require

Re: [RFC patch 1/6] random: Simplify API for random address requests

Hi Kees, On Mon, Jul 25, 2016 at 09:39:58PM -0700, Kees Cook wrote: > On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: > > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: > >> To date, all callers of randomize_range() have set the length to 0, and > >>

[PATCH] mmc: rtsx: Remove deprecated create_singlethread_workqueue

The workqueue "workq" provides support for sd/mmc async request, which makes next request do dma_map_sg() while previous request transferring data. The workqueue has a single workitem(>work) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the

Re: [PATCH] mmc: rtsx: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:31:06PM +0530, Bhaktipriya Shridhar wrote: > The workqueue "workq" provides support for sd/mmc async request, which > makes next request do dma_map_sg() while previous request transferring > data. > > The workqueue has a single workitem(>work) and hence doesn't require

Re: [RFC patch 1/6] random: Simplify API for random address requests

Hi Kees, On Mon, Jul 25, 2016 at 09:39:58PM -0700, Kees Cook wrote: > On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: > > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: > >> To date, all callers of randomize_range() have set the length to 0, and > >> check for a zero return

[PATCH] mmc: rtsx: Remove deprecated create_singlethread_workqueue

The workqueue "workq" provides support for sd/mmc async request, which makes next request do dma_map_sg() while previous request transferring data. The workqueue has a single workitem(>work) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On Tue, Jul 26, 2016 at 10:47:16PM +0800, Caesar Wang wrote: > > On 2016年07月26日 21:39, Guenter Roeck wrote: > > > >>static int rockchip_saradc_probe(struct platform_device *pdev) > >>{ > >>struct rockchip_saradc *info = NULL; > >>@@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct >

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On Tue, Jul 26, 2016 at 10:47:16PM +0800, Caesar Wang wrote: > > On 2016年07月26日 21:39, Guenter Roeck wrote: > > > >>static int rockchip_saradc_probe(struct platform_device *pdev) > >>{ > >>struct rockchip_saradc *info = NULL; > >>@@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct >

[git pull] device mapper changes for 4.8

Hi Linus, As noted in my tag message, these DM changes for 4.8 build ontop of Jens' block 'for-4.8/core' branch. When pulling these DM change you will encounter a merge conflict with Jens' 'for-4.8/drivers' branch. Like Stephen Rothwell before me, I've resolved this merge conflict and published

[git pull] device mapper changes for 4.8

Hi Linus, As noted in my tag message, these DM changes for 4.8 build ontop of Jens' block 'for-4.8/core' branch. When pulling these DM change you will encounter a merge conflict with Jens' 'for-4.8/drivers' branch. Like Stephen Rothwell before me, I've resolved this merge conflict and published

Re: [PATCH v2 30/58] staging: lustre: create striped directory

On Tue, 2016-07-26 at 12:36 -0400, James Simmons wrote: > From: wang di > > 1. client send create request to the master MDT, which >   will allocate FIDs and create slaves. for all of slaves. > > 2. Client needs to revalidate slaves during intent getattr >    and open

Re: [PATCH v2 30/58] staging: lustre: create striped directory

On Tue, 2016-07-26 at 12:36 -0400, James Simmons wrote: > From: wang di > > 1. client send create request to the master MDT, which >   will allocate FIDs and create slaves. for all of slaves. > > 2. Client needs to revalidate slaves during intent getattr >    and open request. > > 3.

Re: [PATCH] apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling

On 07/26/2016 04:38 AM, James Morris wrote: > On Mon, 25 Jul 2016, John Johansen wrote: > >> From: Arnd Bergmann >> >> The newly added Kconfig option could never work and just causes a build error >> when disabled: >> >> security/apparmor/lsm.c:675:25: error: >>

Re: [PATCH] apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling

On 07/26/2016 04:38 AM, James Morris wrote: > On Mon, 25 Jul 2016, John Johansen wrote: > >> From: Arnd Bergmann >> >> The newly added Kconfig option could never work and just causes a build error >> when disabled: >> >> security/apparmor/lsm.c:675:25: error: >>

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote: > On 25/07/16 18:13, Catalin Marinas wrote: > >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote: > >>On 07/22/2016 06:16 AM, Catalin Marinas wrote: > >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote: > >>>[...]

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote: > On 25/07/16 18:13, Catalin Marinas wrote: > >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote: > >>On 07/22/2016 06:16 AM, Catalin Marinas wrote: > >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote: > >>>[...]

[PATCH] cfag12864b: Remove deprecated create_singlethread_workqueue

The workqueue has a single workitem(_work) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time

[PATCH] cfag12864b: Remove deprecated create_singlethread_workqueue

The workqueue has a single workitem(_work) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Eric, >> >> I realized I had a question after the last mail. >> >> On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >>> >>> This patchset

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Eric, >> >> I realized I had a question after the last mail. >> >> On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >>> >>> This patchset addresses two use cases: >>> - Implement a sane

Re: [PATCH v2] USB: appledisplay: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:19:18PM +0530, Bhaktipriya Shridhar wrote: > The workqueue "wq" is involved in controlling the brightness of an > Apple Cinema Display over USB. > > It has a single work item(>work) per appledisplay and hence > doesn't require ordering. Also, it is not being used on a

Re: [PATCH v2] USB: appledisplay: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:19:18PM +0530, Bhaktipriya Shridhar wrote: > The workqueue "wq" is involved in controlling the brightness of an > Apple Cinema Display over USB. > > It has a single work item(>work) per appledisplay and hence > doesn't require ordering. Also, it is not being used on a

Re: [PATCH] mm/memblock.c: fix index adjustment error in __next_mem_range_rev()

Hello, On Tue, Jul 26, 2016 at 03:03:58PM +, zijun...@htc.com wrote: > I am sorry, I don't take any test for the patch attached in previous > mail, and it can't fix the bug completely, please ignore it I > provide a new patch attached in this mail which pass test and can > fix the issue

Re: [PATCH] mm/memblock.c: fix index adjustment error in __next_mem_range_rev()

Hello, On Tue, Jul 26, 2016 at 03:03:58PM +, zijun...@htc.com wrote: > I am sorry, I don't take any test for the patch attached in previous > mail, and it can't fix the bug completely, please ignore it I > provide a new patch attached in this mail which pass test and can > fix the issue

Re: [PATCH 3/4] x86/ioapic: Fix lost ioapic resource after hot-removal and hotadd

Hi, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Rui-Wang/Fixing-a-set-of-bugs-for-ioapic-hotplug

Re: [PATCH 3/4] x86/ioapic: Fix lost ioapic resource after hot-removal and hotadd

Hi, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Rui-Wang/Fixing-a-set-of-bugs-for-ioapic-hotplug

[PATCH v2] USB: appledisplay: Remove deprecated create_singlethread_workqueue

The workqueue "wq" is involved in controlling the brightness of an Apple Cinema Display over USB. It has a single work item(>work) per appledisplay and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with

[PATCH v2] USB: appledisplay: Remove deprecated create_singlethread_workqueue

The workqueue "wq" is involved in controlling the brightness of an Apple Cinema Display over USB. It has a single work item(>work) per appledisplay and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: > On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: > > Am I correct in understanding that there can only be one level of NMI > > nesting at any given time? If so, could we make it easier on the > >

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: > On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: > > Am I correct in understanding that there can only be one level of NMI > > nesting at any given time? If so, could we make it easier on the > > unwinder by putting the

[PATCH BUGFIX V4] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

[PATCH BUGFIX V4] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

[PATCH 1/2] thunderbolt: Fix resume quirk for Falcon Ridge 4C.

The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon Ridge 4C controllers with subdevice/subvendor set to zero. This lead to lost pci devices on system resume. Older thunderbolt controllers (pre Falcon Ridge) used the same device id for bridges and for the controller. On Apple

[PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

From: Xavier Gnata From: Xavier Gnata Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk to support suspend/resume. Tested against 4.7 master on a MacBook Air 11" 2015. Signed-off-by: Andreas Noever

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/20/2016 07:54 AM, Michal Hocko wrote: On Wed 20-07-16 20:11:09, Janani Ravichandran wrote: On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: On Mon 11-07-16 10:12:51, Rik van Riel wrote: What mechanism do you have in mind for obtaining the name, Michal? Not sure

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/20/2016 07:54 AM, Michal Hocko wrote: On Wed 20-07-16 20:11:09, Janani Ravichandran wrote: On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: On Mon 11-07-16 10:12:51, Rik van Riel wrote: What mechanism do you have in mind for obtaining the name, Michal? Not sure whether tracing

[PATCH 1/2] thunderbolt: Fix resume quirk for Falcon Ridge 4C.

The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon Ridge 4C controllers with subdevice/subvendor set to zero. This lead to lost pci devices on system resume. Older thunderbolt controllers (pre Falcon Ridge) used the same device id for bridges and for the controller. On Apple

[PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

From: Xavier Gnata From: Xavier Gnata Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk to support suspend/resume. Tested against 4.7 master on a MacBook Air 11" 2015. Signed-off-by: Andreas Noever --- drivers/pci/quirks.c | 4 drivers/thunderbolt/nhi.c | 6

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Tue, Jul 26, 2016 at 8:55 AM, Jason Cooper wrote: > On Mon, Jul 25, 2016 at 09:44:27PM -0700, Kees Cook wrote: >> On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: >> > To date, all callers of randomize_range() have set the length to 0, and >> >

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Tue, Jul 26, 2016 at 8:55 AM, Jason Cooper wrote: > On Mon, Jul 25, 2016 at 09:44:27PM -0700, Kees Cook wrote: >> On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: >> > To date, all callers of randomize_range() have set the length to 0, and >> > check for a zero return value. For the

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