Re: [PATCH 1/2] libsas: Don't process sas events in static works

Hi Dan, thanks for your review and comments! 在 2017/5/21 11:44, Dan Williams 写道: > On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: >> Now libsas hotplug work is static, LLDD driver queue >> the hotplug work into shost->work_q. If LLDD driver >> burst post lots hotplug

Re: [PATCH 1/2] libsas: Don't process sas events in static works

Hi Dan, thanks for your review and comments! 在 2017/5/21 11:44, Dan Williams 写道: > On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: >> Now libsas hotplug work is static, LLDD driver queue >> the hotplug work into shost->work_q. If LLDD driver >> burst post lots hotplug events to libsas, the

Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102

On 2017-05-21 16:13, Jonathan Cameron wrote: > On 21/05/17 15:06, Jonathan Cameron wrote: >> On 21/05/17 13:44, Jan Kiszka wrote: >>> On 2017-05-21 14:18, Jonathan Cameron wrote: On 21/05/17 13:17, Jonathan Cameron wrote: > On 21/05/17 12:59, Jan Kiszka wrote: >> On 2017-05-21 12:47,

Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102

On 2017-05-21 16:13, Jonathan Cameron wrote: > On 21/05/17 15:06, Jonathan Cameron wrote: >> On 21/05/17 13:44, Jan Kiszka wrote: >>> On 2017-05-21 14:18, Jonathan Cameron wrote: On 21/05/17 13:17, Jonathan Cameron wrote: > On 21/05/17 12:59, Jan Kiszka wrote: >> On 2017-05-21 12:47,

Re: [PATCH v2 0/4] ARM: dts: keystone: Add support for new K2G evm

On 5/10/17 9:08 AM, Santosh Shilimkar wrote: On 4/24/2017 1:22 PM, Franklin S Cooper Jr wrote: This patchset adds support for new K2G Industrial Communication Engine evm. For now only a bare minimal dts which will allow ram boot. Additional peripherals will be added when base K2G SoC patches

Re: [PATCH v2 0/4] ARM: dts: keystone: Add support for new K2G evm

On 5/10/17 9:08 AM, Santosh Shilimkar wrote: On 4/24/2017 1:22 PM, Franklin S Cooper Jr wrote: This patchset adds support for new K2G Industrial Communication Engine evm. For now only a bare minimal dts which will allow ram boot. Additional peripherals will be added when base K2G SoC patches

Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures

On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote: > On Wed, 17 May 2017 14:33:45 +0200, > Bhumika Goyal wrote: >> >> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote: >> > On Wed, 17 May 2017 13:38:56 +0200, >> > Bhumika Goyal wrote: >> >> >> >> Declare

Re: [PATCH] ALSA: sound/isa: constify snd_kcontrol_new structures

On Sun, May 21, 2017 at 12:39 PM, Takashi Iwai wrote: > On Wed, 17 May 2017 14:33:45 +0200, > Bhumika Goyal wrote: >> >> On Wed, May 17, 2017 at 5:50 PM, Takashi Iwai wrote: >> > On Wed, 17 May 2017 13:38:56 +0200, >> > Bhumika Goyal wrote: >> >> >> >> Declare snd_kcontrol_new structures as

Re: gpio-exar: Why filtering out Commtech devices?

On 2017-05-22 07:48, Jan Kiszka wrote: > On 2017-05-21 22:08, Sudip Mukherjee wrote: >> Hi Jan, >> >> On 21/05/17 12:46, Jan Kiszka wrote: >>> Hi Sudip, >>> >>> why do we carry >>> >>> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >>> return -ENODEV; >>> >>> in gpio_exar_probe? This

Re: gpio-exar: Why filtering out Commtech devices?

On 2017-05-22 07:48, Jan Kiszka wrote: > On 2017-05-21 22:08, Sudip Mukherjee wrote: >> Hi Jan, >> >> On 21/05/17 12:46, Jan Kiszka wrote: >>> Hi Sudip, >>> >>> why do we carry >>> >>> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >>> return -ENODEV; >>> >>> in gpio_exar_probe? This

Re: is alpha jensen support dead?

Christoph Hellwig writes: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit 6aca0503847f6329460b15b3ab2b0e30bb752793 > Author:

Re: is alpha jensen support dead?

Christoph Hellwig writes: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit 6aca0503847f6329460b15b3ab2b0e30bb752793 > Author: Christian

Re: gpio-exar: Why filtering out Commtech devices?

On 2017-05-21 22:08, Sudip Mukherjee wrote: > Hi Jan, > > On 21/05/17 12:46, Jan Kiszka wrote: >> Hi Sudip, >> >> why do we carry >> >> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >> return -ENODEV; >> >> in gpio_exar_probe? This effectively prevents that >> >> EXAR_DEVICE(COMMTECH,

Re: gpio-exar: Why filtering out Commtech devices?

On 2017-05-21 22:08, Sudip Mukherjee wrote: > Hi Jan, > > On 21/05/17 12:46, Jan Kiszka wrote: >> Hi Sudip, >> >> why do we carry >> >> if (pcidev->vendor != PCI_VENDOR_ID_EXAR) >> return -ENODEV; >> >> in gpio_exar_probe? This effectively prevents that >> >> EXAR_DEVICE(COMMTECH,

[PATCH] i2c: designware: Fix bogus sda_hold_time due to uninitialized vars

We need to initializes those variables to 0 for platforms that do not provide ACPI parameters. Otherwise, we set sda_hold_time to random values, breaking e.g. Galileo and IOT2000 boards. Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate") Signed-off-by:

[PATCH] i2c: designware: Fix bogus sda_hold_time due to uninitialized vars

We need to initializes those variables to 0 for platforms that do not provide ACPI parameters. Otherwise, we set sda_hold_time to random values, breaking e.g. Galileo and IOT2000 boards. Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate") Signed-off-by:

Re: [PATCH v2] drm: mediatek: change the variable type of rdma threshold

Hi, Bibby: One comment inline. On Fri, 2017-05-19 at 17:57 +0800, Bibby Hsieh wrote: > For some greater resolution, the rdma threshold > variable will overflow. > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 --- > 1 file

Re: [PATCH v2] drm: mediatek: change the variable type of rdma threshold

Hi, Bibby: One comment inline. On Fri, 2017-05-19 at 17:57 +0800, Bibby Hsieh wrote: > For some greater resolution, the rdma threshold > variable will overflow. > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 --- > 1 file changed, 4 insertions(+), 3

Re: is alpha jensen support dead?

On Sun, May 21, 2017 at 1:58 AM, Christoph Hellwig wrote: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit

Re: is alpha jensen support dead?

On Sun, May 21, 2017 at 1:58 AM, Christoph Hellwig wrote: > Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit

[PATCH v2] nvme/pci: remap BAR0 to cover admin CQ doorbell for large stride

The existing driver initially maps 8192 bytes of BAR0 which is intended to cover doorbells of admin SQ and CQ. However, if a large stride, e.g. 10, is used, the doorbell of admin CQ will be out of 8192 bytes. Consequently, a page fault will be raised when the admin CQ doorbell is accessed in

[PATCH v2] nvme/pci: remap BAR0 to cover admin CQ doorbell for large stride

The existing driver initially maps 8192 bytes of BAR0 which is intended to cover doorbells of admin SQ and CQ. However, if a large stride, e.g. 10, is used, the doorbell of admin CQ will be out of 8192 bytes. Consequently, a page fault will be raised when the admin CQ doorbell is accessed in

[PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 06:42:33 +0200 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH] cpufreq: dt: Set default policy->transition_delay_ns

The rate_limit_us for the schedutil governor is getting set to 500 ms by default for the ARM64 hikey board. And its way too much, even for the default value. Lets set the default transition_delay_ns to something more realistic (10 ms), while the userspace always have a chance to set something it

[PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 06:42:33 +0200 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by:

[PATCH] cpufreq: dt: Set default policy->transition_delay_ns

The rate_limit_us for the schedutil governor is getting set to 500 ms by default for the ARM64 hikey board. And its way too much, even for the default value. Lets set the default transition_delay_ns to something more realistic (10 ms), while the userspace always have a chance to set something it

[PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 06:33:48 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link:

[PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 06:33:48 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

[PATCH 0/2] usbnet: Adjustments for usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 07:04:03 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination

[PATCH 0/2] usbnet: Adjustments for usbnet_write_cmd_async()

From: Markus Elfring Date: Mon, 22 May 2017 07:04:03 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/net/usb/usbnet.c | 7 ++- 1 file

[PATCH v2 1/4] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew

[PATCH v2 0/4] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Chris Packham (4): mtd: mchp23k256: Add OF device ID table mtd: mchp23k256: switch to

[PATCH v2 3/4] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Additionally we must specify a non-zero erasesize for the partitions to be writeable. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by:

[PATCH v2 1/4] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew .../devicetree/bindings/mtd/microchip,mchp23k256.txt | 18 ++

[PATCH v2 0/4] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Chris Packham (4): mtd: mchp23k256: Add OF device ID table mtd: mchp23k256: switch to

[PATCH v2 3/4] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Additionally we must specify a non-zero erasesize for the partitions to be writeable. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect revew/test

[PATCH v2 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is software compatible with the mchp23k256, the only difference (from a software point of view) is the size. There is no way to detect the size so we must be told via a Device Tree. Signed-off-by: Chris Packham --- Changes in v2: - fix

[PATCH v2 2/4] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from

[PATCH v2 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is software compatible with the mchp23k256, the only difference (from a software point of view) is the size. There is no way to detect the size so we must be told via a Device Tree. Signed-off-by: Chris Packham --- Changes in v2: - fix formatting in switch statement - add

[PATCH v2 2/4] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew drivers/mtd/devices/mchp23k256.c | 5 ++--- 1 file changed, 2

[PATCH v3 2/2] arm64: dts: add sp804 timer node for Hi3660

The Hi3660 SoC comes with the sp804 timer in addition to the architecture timers. These ones are shutdown when reaching a deep idle states and a backup timer is needed. The sp804 belongs to another power domain and can fulfill the purpose of replacing temporarily an architecture timer when the CPU

[PATCH v3 2/2] arm64: dts: add sp804 timer node for Hi3660

The Hi3660 SoC comes with the sp804 timer in addition to the architecture timers. These ones are shutdown when reaching a deep idle states and a backup timer is needed. The sp804 belongs to another power domain and can fulfill the purpose of replacing temporarily an architecture timer when the CPU

[PATCH v3 1/2] clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER

The timer will register into system at very early phase at kernel boot; if timer needs to use clock, the clock should be get ready in function of_clk_init() so later the timer driver probe can retrieve clock successfully. This is finished in below flow on arm64: start_kernel() `->

[PATCH v3 1/2] clk: Hi3660: register fixed_rate_clks with CLK_OF_DECLARE_DRIVER

The timer will register into system at very early phase at kernel boot; if timer needs to use clock, the clock should be get ready in function of_clk_init() so later the timer driver probe can retrieve clock successfully. This is finished in below flow on arm64: start_kernel() `->

[PATCH v3 0/2] Hi3660: enable sp804 timer

This patch set is to enable sp804 timer on Hi3660 for Hikey960 platform. On Hi3660, the sp804 timer co-exists with CPUs' architecture timer; but sp804 timer is located in SoC level but CPU's architecture timer is in CPU power domain. sp804 timer is used as broadcast timer when CPU enters idle

Re: CHIPPro NAND issue with 4.12 rc1

On 2017-05-20 23:45, Boris Brezillon wrote: Le Sat, 20 May 2017 15:24:06 -0600, Angus Ainslie a écrit : On 2017-05-20 09:14, Boris Brezillon wrote: > Le Sat, 20 May 2017 08:49:04 -0600, > Angus Ainslie a écrit : > >> Hi All, >> >> I'm trying to boot a CHIPPro

[PATCH v3 0/2] Hi3660: enable sp804 timer

This patch set is to enable sp804 timer on Hi3660 for Hikey960 platform. On Hi3660, the sp804 timer co-exists with CPUs' architecture timer; but sp804 timer is located in SoC level but CPU's architecture timer is in CPU power domain. sp804 timer is used as broadcast timer when CPU enters idle

Re: CHIPPro NAND issue with 4.12 rc1

On 2017-05-20 23:45, Boris Brezillon wrote: Le Sat, 20 May 2017 15:24:06 -0600, Angus Ainslie a écrit : On 2017-05-20 09:14, Boris Brezillon wrote: > Le Sat, 20 May 2017 08:49:04 -0600, > Angus Ainslie a écrit : > >> Hi All, >> >> I'm trying to boot a CHIPPro with the stock 4.12 rc1 kernel.

[PATCH linux-next 1/1] spi: imx: only allow dynamic burst in PIO mode

Currently only PIO mode supports dynamic burst length adjust, in DMA mode, bpw (bytes per word) value still has to be used as burst length, other wise transfer issue will be caused. This patch avoid using dynamic burst in DMA mode by set reset dynamic_burst when DMA mode is used. Signed-off-by:

Re: [PATCH 3/4] mtd: mchp23k256: add partitioning support

On 18/05/17 03:29, Boris Brezillon wrote: > Hi Chris, > > On Wed, 17 May 2017 17:39:07 +1200 > Chris Packham wrote: > >> Setting the of_node for the mtd device allows the generic mtd code to >> setup the partitions. Additionally we must specify a non-zero

[PATCH linux-next 1/1] spi: imx: only allow dynamic burst in PIO mode

Currently only PIO mode supports dynamic burst length adjust, in DMA mode, bpw (bytes per word) value still has to be used as burst length, other wise transfer issue will be caused. This patch avoid using dynamic burst in DMA mode by set reset dynamic_burst when DMA mode is used. Signed-off-by:

Re: [PATCH 3/4] mtd: mchp23k256: add partitioning support

On 18/05/17 03:29, Boris Brezillon wrote: > Hi Chris, > > On Wed, 17 May 2017 17:39:07 +1200 > Chris Packham wrote: > >> Setting the of_node for the mtd device allows the generic mtd code to >> setup the partitions. Additionally we must specify a non-zero erasesize >> for the partitions to be

[PATCH] ocfs2: fix a static checker warning

This patch will fix a static checker warning, this warning was caused by commit d56a8f32e4c662509ce50a37e78fa66c777977d3. after apply this patch, the error return value will not be NULL(zero). Signed-off-by: Gang He --- fs/ocfs2/inode.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] ocfs2: fix a static checker warning

This patch will fix a static checker warning, this warning was caused by commit d56a8f32e4c662509ce50a37e78fa66c777977d3. after apply this patch, the error return value will not be NULL(zero). Signed-off-by: Gang He --- fs/ocfs2/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 4/6] ubifs: Maintain a parent pointer

Hi Richard, On Sun, May 21, 2017 at 10:20:49PM +0200, Richard Weinberger wrote: > The new feature UBIFS_FLG_PARENTPOINTER allows looking > up the parent. Usually the Linux VFS walks down the filesystem > and no parent pointers are needed. But when a filesystem > is exportable via NFS such a

Re: [PATCH 4/6] ubifs: Maintain a parent pointer

Hi Richard, On Sun, May 21, 2017 at 10:20:49PM +0200, Richard Weinberger wrote: > The new feature UBIFS_FLG_PARENTPOINTER allows looking > up the parent. Usually the Linux VFS walks down the filesystem > and no parent pointers are needed. But when a filesystem > is exportable via NFS such a

Re: [PATCH 2/3] regulator: lp87565: Add support for lp87565 PMIC regulators

On Friday 19 May 2017 09:23 PM, Andrew F. Davis wrote: > On 05/19/2017 07:42 AM, Keerthy wrote: >> The regulators set consists of 4 BUCKs. The output >> voltages are configurable and are meant to supply power to the >> main processor and other components. The ramp delay is configurable >> for

Re: [PATCH 2/3] regulator: lp87565: Add support for lp87565 PMIC regulators

On Friday 19 May 2017 09:23 PM, Andrew F. Davis wrote: > On 05/19/2017 07:42 AM, Keerthy wrote: >> The regulators set consists of 4 BUCKs. The output >> voltages are configurable and are meant to supply power to the >> main processor and other components. The ramp delay is configurable >> for

Re: [PATCH 1/3] mfd: lp87565: Add lp87565 PMIC support

On Friday 19 May 2017 09:12 PM, Andrew F. Davis wrote: > On 05/19/2017 07:42 AM, Keerthy wrote: >> The LP87565 chip is a power management IC for Portable Navigation Systems >> and Tablet Computing devices. It contains the following components: >> >> - Configurable Bucks(Single and

Re: [PATCH 1/3] mfd: lp87565: Add lp87565 PMIC support

On Friday 19 May 2017 09:12 PM, Andrew F. Davis wrote: > On 05/19/2017 07:42 AM, Keerthy wrote: >> The LP87565 chip is a power management IC for Portable Navigation Systems >> and Tablet Computing devices. It contains the following components: >> >> - Configurable Bucks(Single and

Re: linux-next: build failure after merge of the net-next tree

On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error:

Re: linux-next: build failure after merge of the net-next tree

On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first

Re: linux-next: build failure after merge of the net-next tree

Hi Dave, On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller wrote: > > From: Stephen Rothwell > Date: Mon, 22 May 2017 11:16:05 +1000 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this:

Re: linux-next: build failure after merge of the net-next tree

Hi Dave, On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller wrote: > > From: Stephen Rothwell > Date: Mon, 22 May 2017 11:16:05 +1000 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > net/socket.c: In function

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

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path") from Linus' tree and commit: d54bb72551b9 ("arm64/cpufeature: Use

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

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path") from Linus' tree and commit: d54bb72551b9 ("arm64/cpufeature: Use

Re: [PATCH v3 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

On Sat, 2017-05-20 at 15:46 -0400, Paul Gortmaker wrote: > On Tue, May 9, 2017 at 10:06 PM, Ryder Lee wrote: > > Add support for the Mediatek PCIe Gen2 controller which can > > be found on MT7623 series SoCs. > > > > Signed-off-by: Ryder Lee > >

Re: [PATCH v3 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

On Sat, 2017-05-20 at 15:46 -0400, Paul Gortmaker wrote: > On Tue, May 9, 2017 at 10:06 PM, Ryder Lee wrote: > > Add support for the Mediatek PCIe Gen2 controller which can > > be found on MT7623 series SoCs. > > > > Signed-off-by: Ryder Lee > > --- > > drivers/pci/host/Kconfig | 11 +

Re: [for-next][PATCH 09/33] selftests: ftrace: Add test to test reading of set_ftrace_file

Hi Steve, On Fri, 21 Apr 2017 17:30:29 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The set_ftrace_file lists both functions that are filtered, as well as > function probes (triggers) that are attached to a function, like traceon

Re: [for-next][PATCH 09/33] selftests: ftrace: Add test to test reading of set_ftrace_file

Hi Steve, On Fri, 21 Apr 2017 17:30:29 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The set_ftrace_file lists both functions that are filtered, as well as > function probes (triggers) that are attached to a function, like traceon or > stacktrace, etc. The reading of this

Re: linux-next: build failure after merge of the net-next tree

From: Stephen Rothwell Date: Mon, 22 May 2017 11:16:05 +1000 > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO'

Re: linux-next: build failure after merge of the net-next tree

From: Stephen Rothwell Date: Mon, 22 May 2017 11:16:05 +1000 > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use

Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c

On 05/21/2017 01:34 PM, Wolfram Sang wrote: It doesn't make sense to use include/linux/i2c for client drivers which may in fact rather be hwmon or input or whatever devices. As a result, I want to deprecate include/linux/i2c for good. This series moves the include files to a better location,

Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c

On 05/21/2017 01:34 PM, Wolfram Sang wrote: It doesn't make sense to use include/linux/i2c for client drivers which may in fact rather be hwmon or input or whatever devices. As a result, I want to deprecate include/linux/i2c for good. This series moves the include files to a better location,

Linux 4.12-rc2

I'm back on the usual Sunday schedule, and everything else looks fairly normal too. This rc2 is maybe a bit bigger than usual, but the whole merge window was bigger than most, so maybe it's just that. And it's not like it's huge - usually the rc2 week is fairly quiet as people find issues. The

Linux 4.12-rc2

I'm back on the usual Sunday schedule, and everything else looks fairly normal too. This rc2 is maybe a bit bigger than usual, but the whole merge window was bigger than most, so maybe it's just that. And it's not like it's huge - usually the rc2 week is fairly quiet as people find issues. The

linux-next: build failure after merge of the selinux tree

Hi Paul, After merging the selinux tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/infiniband/core/uverbs_cmd.c: In function 'create_qp': drivers/infiniband/core/uverbs_cmd.c:1513:4: error: label 'err_destroy' used but not defined goto err_destroy; ^

linux-next: build failure after merge of the selinux tree

Hi Paul, After merging the selinux tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/infiniband/core/uverbs_cmd.c: In function 'create_qp': drivers/infiniband/core/uverbs_cmd.c:1513:4: error: label 'err_destroy' used but not defined goto err_destroy; ^

Re: [PATCH 1/1] printk: add __printf attributes to internal functions

On (05/20/17 11:18), Nicolas Iooss wrote: > When compiling with -Wsuggest-attribute=format, gcc complains that some > functions in kernel/printk/printk_safe.c transmit their argument to > printf-like functions without having a printf attribute. Silence these > warnings by adding relevant __printf

Re: [PATCH 1/1] printk: add __printf attributes to internal functions

On (05/20/17 11:18), Nicolas Iooss wrote: > When compiling with -Wsuggest-attribute=format, gcc complains that some > functions in kernel/printk/printk_safe.c transmit their argument to > printf-like functions without having a printf attribute. Silence these > warnings by adding relevant __printf

Re: [PATCH] initramfs: Fix disabling of initramfs (and its compression)

On Sat, 20 May 2017 20:33:35 -0700 Florian Fainelli wrote: > Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded > initram compression algorithm") introduced the possibility to select the > initramfs compression algorithm from Kconfig and while this is a

Re: [PATCH] initramfs: Fix disabling of initramfs (and its compression)

On Sat, 20 May 2017 20:33:35 -0700 Florian Fainelli wrote: > Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded > initram compression algorithm") introduced the possibility to select the > initramfs compression algorithm from Kconfig and while this is a nice > feature it broke

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

Hi Paul, Today's linux-next merge of the selinux tree got a conflict in: include/rdma/ib_verbs.h between commit: 2fc775726491 ("IB/opa-vnic: RDMA NETDEV interface") from Linus' tree and commit: 89b54b4d09bd ("IB/core: Enforce PKey security on QPs") from the selinux tree. I fixed it

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

Hi Paul, Today's linux-next merge of the selinux tree got a conflict in: include/rdma/ib_verbs.h between commit: 2fc775726491 ("IB/opa-vnic: RDMA NETDEV interface") from Linus' tree and commit: 89b54b4d09bd ("IB/core: Enforce PKey security on QPs") from the selinux tree. I fixed it

Re: [PATCH v2 3/4] arm: dts: rk3229: add a new cpu opp table

Hi Heiko, On 2017/5/20 5:46, Heiko Stuebner wrote: Hi Frank, Am Mittwoch, 17. Mai 2017, 18:16:16 CEST schrieb Frank Wang: From: Finley Xiao This patch adds some new frequencies for rk3229 board. Signed-off-by: Finley Xiao

Re: [PATCH v2 3/4] arm: dts: rk3229: add a new cpu opp table

Hi Heiko, On 2017/5/20 5:46, Heiko Stuebner wrote: Hi Frank, Am Mittwoch, 17. Mai 2017, 18:16:16 CEST schrieb Frank Wang: From: Finley Xiao This patch adds some new frequencies for rk3229 board. Signed-off-by: Finley Xiao Signed-off-by: Frank Wang Acked-by: Viresh Kumar ---

RE: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g

> -Original Message- > From: Chen, Xiaoguang > Sent: Thursday, May 18, 2017 7:20 PM > To: He, Min ; alex.william...@redhat.com; > kra...@redhat.com; intel-...@lists.freedesktop.org; linux- > ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan >

RE: [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g

> -Original Message- > From: Chen, Xiaoguang > Sent: Thursday, May 18, 2017 7:20 PM > To: He, Min ; alex.william...@redhat.com; > kra...@redhat.com; intel-...@lists.freedesktop.org; linux- > ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan > ;

[PATCH] mm, THP, swap: Check whether CONFIG_THP_SWAP enabled earlier

From: Huang Ying This patch is only a code clean up patch without functionality changes. It moves CONFIG_THP_SWAP checking from inside swap slot allocation to before we start swapping the THP. This makes the code path a little easier to be followed and understood.

[PATCH] mm, THP, swap: Check whether CONFIG_THP_SWAP enabled earlier

From: Huang Ying This patch is only a code clean up patch without functionality changes. It moves CONFIG_THP_SWAP checking from inside swap slot allocation to before we start swapping the THP. This makes the code path a little easier to be followed and understood. Signed-off-by: "Huang, Ying"

[PATCH v2] ocfs2: give an obvious tip for dismatch cluster names

This patch is used to add an obvious error message, due to dismatch cluster names between on-disk and in the current cluster. We can meet this case during OCFS2 cluster migration, if we can give the user an obvious tip for why they can not mount the file system after migration, they can quickly

Re: [PATCH] perf/x86/intel: Drop kernel samples even though :u is specified

On 5/19/2017 9:33 PM, Jin, Yao wrote: On 5/19/2017 8:36 PM, Peter Zijlstra wrote: On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote: Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or something that would skip the test and preserve current behaviour. OK, I understand

[PATCH v2] ocfs2: give an obvious tip for dismatch cluster names

This patch is used to add an obvious error message, due to dismatch cluster names between on-disk and in the current cluster. We can meet this case during OCFS2 cluster migration, if we can give the user an obvious tip for why they can not mount the file system after migration, they can quickly

Re: [PATCH] perf/x86/intel: Drop kernel samples even though :u is specified

On 5/19/2017 9:33 PM, Jin, Yao wrote: On 5/19/2017 8:36 PM, Peter Zijlstra wrote: On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote: Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or something that would skip the test and preserve current behaviour. OK, I understand

[GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12

Hi Arnd, Olof, Last week, I thought I found a problem in my pull request, but it turned out my misunderstanding. So, my pull request I sent is OK. I am re-sending this request mail for clarification. Here are some ARM UniPhier SoC fixes for v4.12. Due to the eMMC driver update, PHY parameters

[GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12

Hi Arnd, Olof, Last week, I thought I found a problem in my pull request, but it turned out my misunderstanding. So, my pull request I sent is OK. I am re-sending this request mail for clarification. Here are some ARM UniPhier SoC fixes for v4.12. Due to the eMMC driver update, PHY parameters

RE: [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf

Hi Alex, >-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Saturday, May 20, 2017 12:34 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; intel-...@lists.freedesktop.org; linux- >ker...@vger.kernel.org; zhen...@linux.intel.com;

RE: [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf

Hi Alex, >-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Saturday, May 20, 2017 12:34 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; intel-...@lists.freedesktop.org; linux- >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan >;

Re: [PATCH v2] kconfig: Check for libncurses before menuconfig

2017-05-21 18:44 GMT+09:00 Borislav Petkov : > On Sun, May 21, 2017 at 06:15:53PM +0900, Masahiro Yamada wrote: >> Could you change line 199 >> >> $(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog >> >> to >> >> $(addprefix $(obj)/, mconf.o $(lxdialog)):

Re: [PATCH v2] kconfig: Check for libncurses before menuconfig

2017-05-21 18:44 GMT+09:00 Borislav Petkov : > On Sun, May 21, 2017 at 06:15:53PM +0900, Masahiro Yamada wrote: >> Could you change line 199 >> >> $(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog >> >> to >> >> $(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog >> >> and

  1   2   3   4   5   6   >