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

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid5.c between commit: 48920ff2a5a9 ("block: remove the discard_zeroes_data flag") from the block tree and commit: 97d53438081e ("Revert "md/raid5: limit request size according to implementation

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

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/raid5.c between commit: 48920ff2a5a9 ("block: remove the discard_zeroes_data flag") from the block tree and commit: 97d53438081e ("Revert "md/raid5: limit request size according to implementation

[PATCH] cifs: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and both GFP_FS allows for sleeping. So these tests of the return value from mempool_alloc() cannot be needed. Signed-off-by: NeilBrown --- fs/cifs/misc.c | 14 +- fs/cifs/smb2transport.c | 30

[PATCH] cifs: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and both GFP_FS allows for sleeping. So these tests of the return value from mempool_alloc() cannot be needed. Signed-off-by: NeilBrown --- fs/cifs/misc.c | 14 +- fs/cifs/smb2transport.c | 30

Re: [PATCH] reset: hi6220: Set module license so that it can be loaded

On 8 April 2017 at 15:18, Jeremy Linton wrote: > The hi6220_reset driver can be built as a standalone module > yet it cannot be loaded because it depends on GPL exported symbols. > > Lets set the module license so that the module loads, and things like > the on-board

Re: [PATCH] reset: hi6220: Set module license so that it can be loaded

On 8 April 2017 at 15:18, Jeremy Linton wrote: > The hi6220_reset driver can be built as a standalone module > yet it cannot be loaded because it depends on GPL exported symbols. > > Lets set the module license so that the module loads, and things like > the on-board kirin drm starts working. > >

[PATCH] lightnvm: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and both GFP_KERNEL and GFP_NOIO allows for sleeping. So rrpc_move_valid_pages() and rrpc_make_rq() don't need to test the return value. Signed-off-by: NeilBrown --- drivers/lightnvm/rrpc.c | 9 - 1 file

[PATCH] lightnvm: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and both GFP_KERNEL and GFP_NOIO allows for sleeping. So rrpc_move_valid_pages() and rrpc_make_rq() don't need to test the return value. Signed-off-by: NeilBrown --- drivers/lightnvm/rrpc.c | 9 - 1 file changed, 9

[PATCH] drdb: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and GFP_NOIO allows for sleeping. So drbd_req_new() cannot fail, and drbd_request_prepare() doesn't need to check if it did. Signed-off-by: NeilBrown --- drivers/block/drbd/drbd_req.c | 11 --- 1 file

[PATCH] drdb: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow it to sleep, and GFP_NOIO allows for sleeping. So drbd_req_new() cannot fail, and drbd_request_prepare() doesn't need to check if it did. Signed-off-by: NeilBrown --- drivers/block/drbd/drbd_req.c | 11 --- 1 file changed, 11

[PATCH] scsi: lpfc: don't check for failure of mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow sleeping, specifically if __GFP_DIRECT_RECLAIM is included. GFP_KERNEL includes this flag and allows sleeping, so none of this error checking provides any value. Signed-off-by: NeilBrown --- drivers/scsi/lpfc/lpfc_attr.c |

[PATCH] scsi: lpfc: don't check for failure of mempool_alloc()

mempool_alloc() cannot fail if the gfp flags allow sleeping, specifically if __GFP_DIRECT_RECLAIM is included. GFP_KERNEL includes this flag and allows sleeping, so none of this error checking provides any value. Signed-off-by: NeilBrown --- drivers/scsi/lpfc/lpfc_attr.c | 9 --

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

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/md.h between commit: 3deff1a70d59 ("md: support REQ_OP_WRITE_ZEROES") from the block tree and commits: d8e29fbc3bed ("md: move two macros into md.h") 513e2faa0138 ("md: prepare for managing resync I/O

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

Hi Shaohua, Today's linux-next merge of the md tree got a conflict in: drivers/md/md.h between commit: 3deff1a70d59 ("md: support REQ_OP_WRITE_ZEROES") from the block tree and commits: d8e29fbc3bed ("md: move two macros into md.h") 513e2faa0138 ("md: prepare for managing resync I/O

Re: [PATCH] Remove cpuset_update_active_cpus()'s parameter.

On 2017/4/9 9:36, Rakib Mullick wrote: > In cpuset_update_active_cpus(), cpu_online isn't used anymore. Remove > it. > > Signed-off-by: Rakib Mullick Acked-by: Zefan Li

Re: [PATCH] Remove cpuset_update_active_cpus()'s parameter.

On 2017/4/9 9:36, Rakib Mullick wrote: > In cpuset_update_active_cpus(), cpu_online isn't used anymore. Remove > it. > > Signed-off-by: Rakib Mullick Acked-by: Zefan Li

Re: [PATCH 2/5] media: Add support for CXD2880 SPI I/F

Em Fri, 7 Apr 2017 08:19:58 + "Takiguchi, Yasunari" escreveu: > Dear All > > Our patches consists of the following items. > [PATCH 1/5] dt-bindings: media: Add document file for CXD2880 SPI I/F > [PATCH 2/5] media: Add support for CXD2880 SPI I/F > [PATCH

Re: [PATCH 2/5] media: Add support for CXD2880 SPI I/F

Em Fri, 7 Apr 2017 08:19:58 + "Takiguchi, Yasunari" escreveu: > Dear All > > Our patches consists of the following items. > [PATCH 1/5] dt-bindings: media: Add document file for CXD2880 SPI I/F > [PATCH 2/5] media: Add support for CXD2880 SPI I/F > [PATCH 3/5] media: Add suppurt for

Re: [PATCH net-next] net: dsa: mt7530: Include gpio/consumer.h for GPIO functions

From: Florian Fainelli Date: Sat, 8 Apr 2017 08:52:02 -0700 > Fixes build errors seen with CONFIG_GPIOLIB disabled and warnings enabled: ... > Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 > switch") > Signed-off-by: Florian Fainelli

Re: [PATCH net-next] net: dsa: mt7530: Include gpio/consumer.h for GPIO functions

From: Florian Fainelli Date: Sat, 8 Apr 2017 08:52:02 -0700 > Fixes build errors seen with CONFIG_GPIOLIB disabled and warnings enabled: ... > Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 > switch") > Signed-off-by: Florian Fainelli Applied, thanks Florian.

Re: pull-request: wireless-drivers-next 2017-04-07

From: Kalle Valo Date: Fri, 07 Apr 2017 17:36:39 +0300 > here's a pull request for net-next, more info in the signed tag below. > Please let me know if there are any problems. Pulled, thanks Kalle.

Re: pull-request: wireless-drivers-next 2017-04-07

From: Kalle Valo Date: Fri, 07 Apr 2017 17:36:39 +0300 > here's a pull request for net-next, more info in the signed tag below. > Please let me know if there are any problems. Pulled, thanks Kalle.

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote: > On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > > Unbreaks ARM and possibly other 32-bit architectures. > > Turns out those "other 32-bit architectures" happen to include i386. > > A modular build: > ERROR:

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote: > On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > > Unbreaks ARM and possibly other 32-bit architectures. > > Turns out those "other 32-bit architectures" happen to include i386. > > A modular build: > ERROR:

Re: [PATCH] mm/softoffline: Add page flag description in error paths

On Sun, Apr 09, 2017 at 08:08:29AM +0530, Anshuman Khandual wrote: > It helps to provide page flag description along with the raw value in > error paths during soft offline process. From sample experiments > > Before the patch: > > [ 132.317977] soft offline: 0x6100: migration failed 1, type

Re: [PATCH] mm/softoffline: Add page flag description in error paths

On Sun, Apr 09, 2017 at 08:08:29AM +0530, Anshuman Khandual wrote: > It helps to provide page flag description along with the raw value in > error paths during soft offline process. From sample experiments > > Before the patch: > > [ 132.317977] soft offline: 0x6100: migration failed 1, type

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

On Sun, Apr 09, 2017 at 04:02:04PM -0700, Guenter Roeck wrote: > On 04/07/2017 03:00 PM, Moritz Fischer wrote: > > From: Moritz Fischer > > > > The ChromeOS EC has mapped memory regions where things like temperature > > sensors and fan speed are stored. Provide access to those

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

On Sun, Apr 09, 2017 at 04:02:04PM -0700, Guenter Roeck wrote: > On 04/07/2017 03:00 PM, Moritz Fischer wrote: > > From: Moritz Fischer > > > > The ChromeOS EC has mapped memory regions where things like temperature > > sensors and fan speed are stored. Provide access to those from the > >

Re: [PATCH] tty:tty_ldisc: add tty_ldisc_lock|unlock to prevent concurrent update to ldisc in tty_ldisc_deinit

Wang, Applying this, with the other one on top and it doesn't fix the problem (applied on next-20170405). I tried each patch by itself, with the same bad result. Thanks for the help but the backtrace is the same: Unable to handle kernel paging request for data at address 0x2260 Faulting

Re: [PATCH] tty:tty_ldisc: add tty_ldisc_lock|unlock to prevent concurrent update to ldisc in tty_ldisc_deinit

Wang, Applying this, with the other one on top and it doesn't fix the problem (applied on next-20170405). I tried each patch by itself, with the same bad result. Thanks for the help but the backtrace is the same: Unable to handle kernel paging request for data at address 0x2260 Faulting

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > >> In the context of virtually mapped stacks / KSTACKOVERFLOW, this >> naturally leads to different solutions. The upstream kernel had a >> bunch of buggy drivers that played badly with virtually mapped stacks. >> grsecurity

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote: > >> In the context of virtually mapped stacks / KSTACKOVERFLOW, this >> naturally leads to different solutions. The upstream kernel had a >> bunch of buggy drivers that played badly with virtually mapped stacks. >> grsecurity sensibly went for the

[PATCH V3] checkpatch: Improve MULTISTATEMENT_MACRO_USE_DO_WHILE test

The logic currrently misses macros that start with an if statement. e.g.:#define foo(bar) if (bar) baz; Add a test for macro content that starts with if Original-patch-by: Alfonso Lima Reported-by: Andreas Mohr Signed-off-by: Joe Perches

[PATCH V3] checkpatch: Improve MULTISTATEMENT_MACRO_USE_DO_WHILE test

The logic currrently misses macros that start with an if statement. e.g.:#define foo(bar) if (bar) baz; Add a test for macro content that starts with if Original-patch-by: Alfonso Lima Reported-by: Andreas Mohr Signed-off-by: Joe Perches --- V3: Fix bad merge - Add missing closing

Re: [PATCH v3 33/37] mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset

Hi Boris, 2017-04-09 23:17 GMT+09:00 Boris Brezillon : > On Thu, 30 Mar 2017 17:15:04 +0900 > Masahiro Yamada wrote: > >> Some NAND controllers are using DMA engine requiring a specific >> buffer alignment. The core provides no

Re: [PATCH v3 33/37] mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset

Hi Boris, 2017-04-09 23:17 GMT+09:00 Boris Brezillon : > On Thu, 30 Mar 2017 17:15:04 +0900 > Masahiro Yamada wrote: > >> Some NAND controllers are using DMA engine requiring a specific >> buffer alignment. The core provides no guarantee on the nand_buffers >> pointers, which forces some

[RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation

From: Rafael J. Wysocki Due to the limitation of the rate of frequency changes the schedutil governor only estimates the CPU utilization entirely when it is about to update the frequency for the corresponding cpufreq policy. As a result, the intermediate utilization

[RFC/RFT][PATCH 0/2] cpufreq: schedutil: Updates related to the rate limit

Hi, These two patches result from the discussion at the OSPM-summit last week and are targeted at alleviating some issues related to the frequency change rate limitting in schedutil. They are intended to be used along with https://patchwork.kernel.org/patch/9655173/ and are based on the current

[RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent latency multupliers

From: Rafael J. Wysocki Make the schedutil governor compute the initial (default) value of the rate_limit_us sysfs attribute by multiplying the transition latency by a multiplier depending on the policy and set by the scaling driver (instead of using a constant for

[RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation

From: Rafael J. Wysocki Due to the limitation of the rate of frequency changes the schedutil governor only estimates the CPU utilization entirely when it is about to update the frequency for the corresponding cpufreq policy. As a result, the intermediate utilization values are discarded by it,

[RFC/RFT][PATCH 0/2] cpufreq: schedutil: Updates related to the rate limit

Hi, These two patches result from the discussion at the OSPM-summit last week and are targeted at alleviating some issues related to the frequency change rate limitting in schedutil. They are intended to be used along with https://patchwork.kernel.org/patch/9655173/ and are based on the current

[RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent latency multupliers

From: Rafael J. Wysocki Make the schedutil governor compute the initial (default) value of the rate_limit_us sysfs attribute by multiplying the transition latency by a multiplier depending on the policy and set by the scaling driver (instead of using a constant for this purpose). That will

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: >> > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: >> >> Then someone who cares about performance can

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote: > On 7 Apr 2017 at 21:58, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: >> > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: >> >> Then someone who cares about performance can benchmark the CR0.WP >> >> approach against

[PATCH] samples: fixed blank line after declaration

Following the code-style added a blank line to watchdog-simple.c in the examples. Signed-off-by: ronm --- samples/watchdog/watchdog-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/samples/watchdog/watchdog-simple.c b/samples/watchdog/watchdog-simple.c index

[PATCH] samples: fixed blank line after declaration

Following the code-style added a blank line to watchdog-simple.c in the examples. Signed-off-by: ronm --- samples/watchdog/watchdog-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/samples/watchdog/watchdog-simple.c b/samples/watchdog/watchdog-simple.c index ba45803..327b226 100644

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Fri, Apr 07 2017, Jeff Layton wrote: > >> ... and then there's no need to update if it's the same errno and nobody's >> seen it: >> >> if (old == new) >> break; >> > > No, we can't do this. The thing could have just been updated by a task > that is setting

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Fri, Apr 07 2017, Jeff Layton wrote: > >> ... and then there's no need to update if it's the same errno and nobody's >> seen it: >> >> if (old == new) >> break; >> > > No, we can't do this. The thing could have just been updated by a task > that is setting

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

On 04/07/2017 03:00 PM, Moritz Fischer wrote: From: Moritz Fischer The ChromeOS EC has mapped memory regions where things like temperature sensors and fan speed are stored. Provide access to those from the cros-ec mfd device. Signed-off-by: Moritz Fischer

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

On 04/07/2017 03:00 PM, Moritz Fischer wrote: From: Moritz Fischer The ChromeOS EC has mapped memory regions where things like temperature sensors and fan speed are stored. Provide access to those from the cros-ec mfd device. Signed-off-by: Moritz Fischer I'll have to consult with others

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > A 3 microsecond delay is required, however, to prevent occasional issues  > during heavy FSI bus load stress testing. > A 1 nanosecond delay using ndelay(1) had been specified prior to this  > but after looking more closely at real

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > A 3 microsecond delay is required, however, to prevent occasional issues  > during heavy FSI bus load stress testing. > A 1 nanosecond delay using ndelay(1) had been specified prior to this  > but after looking more closely at real

Re: [PATCH] x86/efi: don't try to reserve runtime regions

On Tue, 04 Apr, at 04:41:55PM, Omar Sandoval wrote: > From: Omar Sandoval > > Reserving a runtime region results in splitting the efi memory > descriptors for the runtime region. This results in runtime region > descriptors with bogus memory mappings, leading to interesting

Re: [PATCH] x86/efi: don't try to reserve runtime regions

On Tue, 04 Apr, at 04:41:55PM, Omar Sandoval wrote: > From: Omar Sandoval > > Reserving a runtime region results in splitting the efi memory > descriptors for the runtime region. This results in runtime region > descriptors with bogus memory mappings, leading to interesting crashes > like the

A long overdue fork-bomb defense ?! (idea + psuedocode, no patch yet)

Another fork bomb thread? Didn't we decide in the 90's that the answer was "configure process limits" or "if it was solvable surly a solution would have been found by now"? Somewhat continuing from: https://lkml.org/lkml/2011/4/8/275 ...but a more refined idea and psuedocode. ASAICS I have "the

A long overdue fork-bomb defense ?! (idea + psuedocode, no patch yet)

Another fork bomb thread? Didn't we decide in the 90's that the answer was "configure process limits" or "if it was solvable surly a solution would have been found by now"? Somewhat continuing from: https://lkml.org/lkml/2011/4/8/275 ...but a more refined idea and psuedocode. ASAICS I have "the

[PATCH v7 3/6] watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions

iTCO_wdt no_reboot_bit set/unset functions has lot of common code between them. So merging these two functions into a single update function would remove these unnecessary code duplications. This patch fixes this issue by creating a no_reboot_bit update function to handle both set/unset functions.

[PATCH v7 3/6] watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions

iTCO_wdt no_reboot_bit set/unset functions has lot of common code between them. So merging these two functions into a single update function would remove these unnecessary code duplications. This patch fixes this issue by creating a no_reboot_bit update function to handle both set/unset functions.

[PATCH v7 6/6] platform/x86: intel_pmc_ipc: use gcr mem base for S0ix counter read

To maintain the uniformity in accessing GCR registers, this patch modifies the S0ix counter read function to use GCR address base instead of ipc address base. Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Rajneesh Bhardwaj

[PATCH v7 6/6] platform/x86: intel_pmc_ipc: use gcr mem base for S0ix counter read

To maintain the uniformity in accessing GCR registers, this patch modifies the S0ix counter read function to use GCR address base instead of ipc address base. Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Rajneesh Bhardwaj Tested-by: Shanth Murthy ---

[PATCH v7 5/6] platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure

iTCO_wdt driver need access to PMC_CFG GCR register to modify the noreboot setting. Currently, this is done by passing PMC_CFG reg address as memory resource to watchdog driver and allowing it directly modify the PMC_CFG register. But currently PMC driver also has requirement to memory map the

[PATCH v7 5/6] platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure

iTCO_wdt driver need access to PMC_CFG GCR register to modify the noreboot setting. Currently, this is done by passing PMC_CFG reg address as memory resource to watchdog driver and allowing it directly modify the PMC_CFG register. But currently PMC driver also has requirement to memory map the

[PATCH v7 4/6] watchdog: iTCO_wdt: Add PMC specific noreboot update api

In some SoCs, setting noreboot bit needs modification to PMC GC registers. But not all PMC drivers allow other drivers to memory map their GC region. This could create mem request conflict in watchdog driver. So this patch adds facility to allow PMC drivers to pass noreboot update function to

[PATCH v7 2/6] platform/x86: intel_pmc_ipc: Add pmc gcr read/write/update api's

This patch adds API's to read/write/update PMC GC registers. PMC dependent devices like iTCO_wdt, Telemetry has requirement to acces GCR registers. These API's can be used for this purpose. Signed-off-by: Kuppuswamy Sathyanarayanan ---

[PATCH v7 4/6] watchdog: iTCO_wdt: Add PMC specific noreboot update api

In some SoCs, setting noreboot bit needs modification to PMC GC registers. But not all PMC drivers allow other drivers to memory map their GC region. This could create mem request conflict in watchdog driver. So this patch adds facility to allow PMC drivers to pass noreboot update function to

[PATCH v7 2/6] platform/x86: intel_pmc_ipc: Add pmc gcr read/write/update api's

This patch adds API's to read/write/update PMC GC registers. PMC dependent devices like iTCO_wdt, Telemetry has requirement to acces GCR registers. These API's can be used for this purpose. Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/include/asm/intel_pmc_ipc.h | 21 +++

[PATCH v7 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

According to Broxton APL spec, PMC MIMO resources for Global Control Registers(GCR) are located at 4K(0x1000) offset from IPC base address. In this driver, PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR region base address from IPC base address and its current value of 0x1008 is

[PATCH v7 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

According to Broxton APL spec, PMC MIMO resources for Global Control Registers(GCR) are located at 4K(0x1000) offset from IPC base address. In this driver, PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR region base address from IPC base address and its current value of 0x1008 is

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:53 +1000, Benjamin Herrenschmidt wrote: > FYI. pdbg in userspace operates without any  delays in practice, the > overhead between the various load/store instructions seems > sufficient. > > The only delay that's needed is when going through the FSI2PIB (to do > SCOMs)

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:53 +1000, Benjamin Herrenschmidt wrote: > FYI. pdbg in userspace operates without any  delays in practice, the > overhead between the various load/store instructions seems > sufficient. > > The only delay that's needed is when going through the FSI2PIB (to do > SCOMs)

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:41 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > > A 3 microsecond delay is required, however, to prevent occasional > > issues  > > during heavy FSI bus load stress testing. > > A 1 nanosecond delay using ndelay(1)

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:41 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > > A 3 microsecond delay is required, however, to prevent occasional > > issues  > > during heavy FSI bus load stress testing. > > A 1 nanosecond delay using ndelay(1)

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

Le 09/04/2017 à 22:46, Marek Vasut a écrit : > On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: >> Hi Marek, >> >> Le 07/04/2017 à 01:37, Marek Vasut a écrit : >>> On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: Before this patch, m25p80_read() supported few SPI protocols: - regular SPI

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

Le 09/04/2017 à 22:46, Marek Vasut a écrit : > On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: >> Hi Marek, >> >> Le 07/04/2017 à 01:37, Marek Vasut a écrit : >>> On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: Before this patch, m25p80_read() supported few SPI protocols: - regular SPI

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 04/09/2017 11:30 PM, Cyrille Pitchen wrote: > Le 09/04/2017 à 22:46, Marek Vasut a écrit : >> On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: >>> Hi Marek, >>> >>> Le 07/04/2017 à 01:37, Marek Vasut a écrit : On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > Before this patch,

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 04/09/2017 11:30 PM, Cyrille Pitchen wrote: > Le 09/04/2017 à 22:46, Marek Vasut a écrit : >> On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: >>> Hi Marek, >>> >>> Le 07/04/2017 à 01:37, Marek Vasut a écrit : On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > Before this patch,

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

On 04/09/2017 11:16 PM, Cyrille Pitchen wrote: > Hi Marek, Hi, > thanks for the review. [...] >>> +struct spi_nor_flash_parameter { >>> + u64 size; >>> + u32 page_size; >>> + >>> + struct spi_nor_hwcaps hwcaps; >>> +

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

On 04/09/2017 11:16 PM, Cyrille Pitchen wrote: > Hi Marek, Hi, > thanks for the review. [...] >>> +struct spi_nor_flash_parameter { >>> + u64 size; >>> + u32 page_size; >>> + >>> + struct spi_nor_hwcaps hwcaps; >>> +

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On 4/4/17 5:19 PM, Benjamin Herrenschmidt wrote: On Tue, 2017-04-04 at 12:32 -0500, Christopher Bostic wrote: Agreed that there is room for improvement. I intend to look further into your suggestions from here and our private conversation on the matter and make changes as appropriate. I

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On 4/4/17 5:19 PM, Benjamin Herrenschmidt wrote: On Tue, 2017-04-04 at 12:32 -0500, Christopher Bostic wrote: Agreed that there is room for improvement. I intend to look further into your suggestions from here and our private conversation on the matter and make changes as appropriate. I

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

Hi Marek, thanks for the review. my comments below: Le 07/04/2017 à 01:30, Marek Vasut a écrit : > On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: >> This patch changes the prototype of spi_nor_scan(): its 3rd parameter >> is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

Hi Marek, thanks for the review. my comments below: Le 07/04/2017 à 01:30, Marek Vasut a écrit : > On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: >> This patch changes the prototype of spi_nor_scan(): its 3rd parameter >> is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor

[PATCH] phy: qcom-qmp: select COMMON_CLK

It is impossible to build Qualcom QMP phy driver without COMMON_CLK enabled: CC drivers/phy/phy-qcom-qmp.o drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’: drivers/phy/phy-qcom-qmp.c:932:9: error: variable ‘init’ has initializer but incomplete type struct clk_init_data

[PATCH] phy: qcom-qmp: select COMMON_CLK

It is impossible to build Qualcom QMP phy driver without COMMON_CLK enabled: CC drivers/phy/phy-qcom-qmp.o drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’: drivers/phy/phy-qcom-qmp.c:932:9: error: variable ‘init’ has initializer but incomplete type struct clk_init_data

Re: [PATCH v5 22/23] drivers/fsi: Add hub master support

On 4/5/17 11:36 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Add an engine driver to expose a "hub" FSI master - which has a set of control registers in the engine address space, and uses a chunk of the slave address

Re: [PATCH v5 22/23] drivers/fsi: Add hub master support

On 4/5/17 11:36 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Add an engine driver to expose a "hub" FSI master - which has a set of control registers in the engine address space, and uses a chunk of the slave address space for actual FSI

Re: [PATCH v5 21/23] drivers/fsi: Add SCOM FSI client device driver

On 4/5/17 11:35 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Create a simple SCOM engine device driver that reads and writes its control registers via an FSI bus. Includes changes from Edward A. James

Re: [PATCH v5 21/23] drivers/fsi: Add SCOM FSI client device driver

On 4/5/17 11:35 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Create a simple SCOM engine device driver that reads and writes its control registers via an FSI bus. Includes changes from Edward A. James . Signed-off-by: Chris Bostic Signed-off-by:

Re: USB Type-C Port Manager API concern

On 04/09/2017 05:16 PM, Guenter Roeck wrote: Hi Mats, On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote: I'm working on a tcpi driver and have some concern about the tcpm api. The tcpm_register_port() is typically called from the probe function of tcpi driver where the tcpm_port

Re: USB Type-C Port Manager API concern

On 04/09/2017 05:16 PM, Guenter Roeck wrote: Hi Mats, On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote: I'm working on a tcpi driver and have some concern about the tcpm api. The tcpm_register_port() is typically called from the probe function of tcpi driver where the tcpm_port

Re: [PATCH v5 19/23] drivers/fsi: Add GPIO based FSI master

On 4/5/17 11:35 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and

Re: [PATCH v5 19/23] drivers/fsi: Add GPIO based FSI master

On 4/5/17 11:35 AM, Randy Dunlap wrote: On 04/04/17 19:06, Christopher Bostic wrote: From: Chris Bostic Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response.

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: > Hi Marek, > > Le 07/04/2017 à 01:37, Marek Vasut a écrit : >> On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: >>> Before this patch, m25p80_read() supported few SPI protocols: >>> - regular SPI 1-1-1 >>> - SPI Dual Output 1-1-2 >>> - SPI Quad Output

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 04/09/2017 09:37 PM, Cyrille Pitchen wrote: > Hi Marek, > > Le 07/04/2017 à 01:37, Marek Vasut a écrit : >> On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: >>> Before this patch, m25p80_read() supported few SPI protocols: >>> - regular SPI 1-1-1 >>> - SPI Dual Output 1-1-2 >>> - SPI Quad Output

[PATCH] regulator: isl9305: fix array size

ISL9305_MAX_REGULATOR is the last index used to access the init_data[] array, so we need to add one to this last index to obtain the necessary array size. This fixes the following smatch error: drivers/regulator/isl9305.c:160 isl9305_i2c_probe() error: buffer overflow 'pdata->init_data' 3 <=

[PATCH] regulator: isl9305: fix array size

ISL9305_MAX_REGULATOR is the last index used to access the init_data[] array, so we need to add one to this last index to obtain the necessary array size. This fixes the following smatch error: drivers/regulator/isl9305.c:160 isl9305_i2c_probe() error: buffer overflow 'pdata->init_data' 3 <=

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: > grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 Apr 2017 at 22:07, Andy Lutomirski wrote: > grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be

Re: [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote: > Not getting hangs is a good sign, but lockdep doesn't like it: > > [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418 > check_flush_dependency+0x92/0x130 > [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H)

Re: [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote: > Not getting hangs is a good sign, but lockdep doesn't like it: > > [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418 > check_flush_dependency+0x92/0x130 > [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H)

<    1   2   3   4   5   >