RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi, > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Monday, July 18, 2016 6:02 PM > On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for your reply. > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] > > > Sent: Wednesday, July 13, 2016 11:04 AM > > >

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi, > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Monday, July 18, 2016 6:02 PM > On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for your reply. > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] > > > Sent: Wednesday, July 13, 2016 11:04 AM > > >

scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or directory

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 47ef4ad2684d380dd6d596140fb79395115c3950 commit: 283e8ba2dfde54f8f27d7d0f459a07de79a39d55 MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old date: 10 months ago config: arm-allmodconfig

scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or directory

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 47ef4ad2684d380dd6d596140fb79395115c3950 commit: 283e8ba2dfde54f8f27d7d0f459a07de79a39d55 MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old date: 10 months ago config: arm-allmodconfig

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

On Mon, Jul 18, 2016 at 08:59:52PM -0700, Christoph Hellwig wrote: > On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote: > > >From kernel guys working on android. > > Well, until it's mainline it simply doesn't matter, so NAK to this > patch. Tying power behavior to plugs also sounds

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

On Mon, Jul 18, 2016 at 08:59:52PM -0700, Christoph Hellwig wrote: > On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote: > > >From kernel guys working on android. > > Well, until it's mainline it simply doesn't matter, so NAK to this > patch. Tying power behavior to plugs also sounds

[Patch-V2 1/3] cxgb4: Add Chelsio LLD support Chelsio Crypto ULD

The Chelsio crypto driver is an Upper Layer Driver (ULD), making use of the Chelsio Lower Layer Driver (LLD - cxgb4). The LLD facilitates the basic infrastructure services of the ULD. These services include queue allocation, deallocation and registration with LLD. The queues are used for sending

[Patch-V2 1/3] cxgb4: Add Chelsio LLD support Chelsio Crypto ULD

The Chelsio crypto driver is an Upper Layer Driver (ULD), making use of the Chelsio Lower Layer Driver (LLD - cxgb4). The LLD facilitates the basic infrastructure services of the ULD. These services include queue allocation, deallocation and registration with LLD. The queues are used for sending

Re: [PATCH] net/sched/sch_htb: clamp xstats tokens to fit into 32-bit int

From: Konstantin Khlebnikov Date: Sat, 16 Jul 2016 17:08:56 +0300 > In kernel HTB keeps tokens in signed 64-bit in nanoseconds. In netlink > protocol these values are converted into pshed ticks (64ns for now) and > truncated to 32-bit. In struct tc_htb_xstats fields

Re: [PATCH] net/sched/sch_htb: clamp xstats tokens to fit into 32-bit int

From: Konstantin Khlebnikov Date: Sat, 16 Jul 2016 17:08:56 +0300 > In kernel HTB keeps tokens in signed 64-bit in nanoseconds. In netlink > protocol these values are converted into pshed ticks (64ns for now) and > truncated to 32-bit. In struct tc_htb_xstats fields "tokens" and "ctokens" > are

[Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

The Chelsio's Crypto Hardware can perform the following operations: SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-XTS, AES-256-XTS This patch implements the driver for above mentioned

[Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

The Chelsio's Crypto Hardware can perform the following operations: SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-XTS, AES-256-XTS This patch implements the driver for above mentioned

[Patch-V2 0/3] crypto/chcr: Add Chelsio Crypto Driver

Hi Herbert, This patch series contains 3 patches that add support for Chelsio's Crypto Hardware. The patch series has been created against Herbert Xu's tree (crypto-2.6). It includes patches for Chelsio Low Level Driver(cxgb4) and adds the new crypto Upper Layer Driver(chcr) under a new

[Patch-V2 0/3] crypto/chcr: Add Chelsio Crypto Driver

Hi Herbert, This patch series contains 3 patches that add support for Chelsio's Crypto Hardware. The patch series has been created against Herbert Xu's tree (crypto-2.6). It includes patches for Chelsio Low Level Driver(cxgb4) and adds the new crypto Upper Layer Driver(chcr) under a new

[Patch-V2 3/3] crypto: Added Chelsio Menu to the Kconfig file

Adds the config entry for the Chelsio Crypto Driver, Makefile changes for the same. Signed-off-by: Yeshaswi M R Gowda --- drivers/crypto/Kconfig |2 ++ drivers/crypto/Makefile |1 + 2 files changed, 3 insertions(+) diff --git a/drivers/crypto/Kconfig

[Patch-V2 3/3] crypto: Added Chelsio Menu to the Kconfig file

Adds the config entry for the Chelsio Crypto Driver, Makefile changes for the same. Signed-off-by: Yeshaswi M R Gowda --- drivers/crypto/Kconfig |2 ++ drivers/crypto/Makefile |1 + 2 files changed, 3 insertions(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index

Re: [PATCH v2 2/4] iio: adc: add support for Allwinner SoCs ADC

On 15/07/16 10:59, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a touchscreen > controller and a thermal sensor. This patch adds the ADC driver which is > based on the MFD for the same SoCs ADC. > > This also registers the thermal adc channel in the iio map

Re: [PATCH v2 2/2] iio: adc: sun4i_lradc: new driver

On 12/07/16 20:04, Alexandre Belloni wrote: > Add an IIO driver for the Allwinner Low Resolution ADC. This ADC is usually > used for physical buttons connected using a resistor ladder. > > Signed-off-by: Alexandre Belloni A few small bits and pieces from

Re: [PATCH 06/10] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. > Creates an IIO device for each functions. > > Signed-off-by: Guenter Roeck > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH v4 5/8] drm/mediatek: add dsi interrupt control

Hi, YT: Some comments inline. On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote: > From: shaoming chen > > add dsi interrupt control > > Signed-off-by: shaoming chen > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 130 >

Re: [PATCH v2 2/4] iio: adc: add support for Allwinner SoCs ADC

On 15/07/16 10:59, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a touchscreen > controller and a thermal sensor. This patch adds the ADC driver which is > based on the MFD for the same SoCs ADC. > > This also registers the thermal adc channel in the iio map

Re: [PATCH v2 2/2] iio: adc: sun4i_lradc: new driver

On 12/07/16 20:04, Alexandre Belloni wrote: > Add an IIO driver for the Allwinner Low Resolution ADC. This ADC is usually > used for physical buttons connected using a resistor ladder. > > Signed-off-by: Alexandre Belloni A few small bits and pieces from me... Jonathan > --- > Changes in v2: >

Re: [PATCH 06/10] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. > Creates an IIO device for each functions. > > Signed-off-by: Guenter Roeck > Signed-off-by: Enric Balletbo i Serra Few more nitpicks, but basically the same as the

Re: [PATCH v4 5/8] drm/mediatek: add dsi interrupt control

Hi, YT: Some comments inline. On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote: > From: shaoming chen > > add dsi interrupt control > > Signed-off-by: shaoming chen > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 130 > > 1 file changed, 130 insertions(+)

Re: [PATCH 04/10] iio: cros_ec: Add common functions for cros_ec sensors.

On 18/07/16 08:29, Peter Meerwald-Stadler wrote: > >> Add the core functions to be able to support the sensors attached behind >> the ChromeOS Embedded Controller and used by other IIO cros-ec sensor >> drivers. > > comments below from a quick read > there is plenty on undocumented private API

Re: [PATCH 02/10] mfd: cros_ec: update MOTIONSENSE definitions and commands.

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Let's update the command header to include the definitions related to > the sensors attached behind the ChromeOS Embedded Controller. The new > commands and definitions allow us to get information from these sensors. > > Signed-off-by: Gwendal

Re: [PATCH 05/10] iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle 3d contiguous sensors like Accelerometers, Gyroscope and > Magnetometer that are presented by the ChromeOS EC Sensor hub. > > Signed-off-by: Guenter Roeck > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH 05/10] iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle 3d contiguous sensors like Accelerometers, Gyroscope and > Magnetometer that are presented by the ChromeOS EC Sensor hub. > > Signed-off-by: Guenter Roeck > Signed-off-by: Enric Balletbo i Serra Various nitpicks inline. Jonathan > --- >

Re: [PATCH 04/10] iio: cros_ec: Add common functions for cros_ec sensors.

On 18/07/16 08:29, Peter Meerwald-Stadler wrote: > >> Add the core functions to be able to support the sensors attached behind >> the ChromeOS Embedded Controller and used by other IIO cros-ec sensor >> drivers. > > comments below from a quick read > there is plenty on undocumented private API

Re: [PATCH 02/10] mfd: cros_ec: update MOTIONSENSE definitions and commands.

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Let's update the command header to include the definitions related to > the sensors attached behind the ChromeOS Embedded Controller. The new > commands and definitions allow us to get information from these sensors. > > Signed-off-by: Gwendal

Re: [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon

On 15/07/16 10:59, Quentin Schulz wrote: > Currently, iio_hwmon only exposes values of the IIO channels it can read > but no label by channel is exposed. > > This adds exposition of sysfs files containing label for IIO channels it > can read based on extended_name field of the iio_chan_spec of

Re: [PATCH v4 2/3] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

On 11/07/16 07:39, Zhiyong Tao wrote: > Add Mediatek auxadc driver based on iio. > It will register a device in iio and support iio. > So thermal can read auxadc channel to sample data by iio device. > It is tested successfully on mt2701 platform. > Mt8173 and mt6577 platforms are not tested. >

Re: [PATCH 03/10] iio: core: Add double tap as possible gesture

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > From: Gwendal Grignou > > This is an interface change: however, the sysfs entry is based on string, > so if other gestures are added on the trunk in the meantime, we will > still be able to merge this change. > >

Re: [PATCH] staging: iio: light: isl29018/28: remove I2C_CLASS_HWMON .class setting

On 18/07/16 09:50, Laxman Dewangan wrote: > > On Saturday 16 July 2016 07:58 AM, Alison Schofield wrote: >> I2C_CLASS_HWMON is for a hardware monitoring chip wanting >> auto-detection. IIO drivers don't typically use .class. >> Remove it. >> >> Signed-off-by: Alison Schofield

Re: [PATCH 08/10] iio: cros_ec_sensors_ring: add ChromeOS EC Sensors Ring

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Add support for handling sensor events FIFO produced by the sensor > hub. A single device with a buffer will collect all samples produced > by the sensors managed by the CrosEC sensor hub. So you are defining a different device to support the

Re: [PATCH v2 3/4] mfd: add support for Allwinner SoCs ADC

On 15/07/16 10:59, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a touchscreen > controller and a thermal sensor. For now, only the ADC and the thermal > sensor drivers are probed by the MFD, the touchscreen controller support > will be added later. > >

Re: [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon

On 15/07/16 10:59, Quentin Schulz wrote: > Currently, iio_hwmon only exposes values of the IIO channels it can read > but no label by channel is exposed. > > This adds exposition of sysfs files containing label for IIO channels it > can read based on extended_name field of the iio_chan_spec of

Re: [PATCH v4 2/3] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

On 11/07/16 07:39, Zhiyong Tao wrote: > Add Mediatek auxadc driver based on iio. > It will register a device in iio and support iio. > So thermal can read auxadc channel to sample data by iio device. > It is tested successfully on mt2701 platform. > Mt8173 and mt6577 platforms are not tested. >

Re: [PATCH 03/10] iio: core: Add double tap as possible gesture

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > From: Gwendal Grignou > > This is an interface change: however, the sysfs entry is based on string, > so if other gestures are added on the trunk in the meantime, we will > still be able to merge this change. > > Signed-off-by: Gwendal Grignou

Re: [PATCH] staging: iio: light: isl29018/28: remove I2C_CLASS_HWMON .class setting

On 18/07/16 09:50, Laxman Dewangan wrote: > > On Saturday 16 July 2016 07:58 AM, Alison Schofield wrote: >> I2C_CLASS_HWMON is for a hardware monitoring chip wanting >> auto-detection. IIO drivers don't typically use .class. >> Remove it. >> >> Signed-off-by: Alison Schofield >> Cc: Daniel

Re: [PATCH 08/10] iio: cros_ec_sensors_ring: add ChromeOS EC Sensors Ring

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Add support for handling sensor events FIFO produced by the sensor > hub. A single device with a buffer will collect all samples produced > by the sensors managed by the CrosEC sensor hub. So you are defining a different device to support the

Re: [PATCH v2 3/4] mfd: add support for Allwinner SoCs ADC

On 15/07/16 10:59, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a touchscreen > controller and a thermal sensor. For now, only the ADC and the thermal > sensor drivers are probed by the MFD, the touchscreen controller support > will be added later. > >

Re: [PATCH 01/10] mfd: cros_ec: add ChromeOS EC sensor platform information.

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > The platform information will be used for the new cros-ec sensors driver > that presents sensors attached to the ChromeOS Embedded Controller. > > Signed-off-by: Gwendal Grignou > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH 07/10] iio: cros_ec_activity: add ChromeOS EC Activity Sensors

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle activity events detections presented by the ChromeOS > EC Sensor hub. Activities can be simple (low/no motion) or more complex > (riding train). They are being reported by physical devices or the EC > itself. > > Signed-off-by: Guenter

Re: [PATCH 01/10] mfd: cros_ec: add ChromeOS EC sensor platform information.

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > The platform information will be used for the new cros-ec sensors driver > that presents sensors attached to the ChromeOS Embedded Controller. > > Signed-off-by: Gwendal Grignou > Signed-off-by: Enric Balletbo i Serra Bring this in as an when

Re: [PATCH 07/10] iio: cros_ec_activity: add ChromeOS EC Activity Sensors

On 18/07/16 08:02, Enric Balletbo i Serra wrote: > Handle activity events detections presented by the ChromeOS > EC Sensor hub. Activities can be simple (low/no motion) or more complex > (riding train). They are being reported by physical devices or the EC > itself. > > Signed-off-by: Guenter

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Mon, Jul 18, 2016 at 10:07:24AM +0300, Felipe Balbi wrote: > > Hi, > > Bin Gao writes: > >> > +int pd_sink_queue_msg(struct pd_sink_msg *msg) > >> > +{ > >> > +unsigned long flags; > >> > +struct pd_sink_port *port; > >> > + > >> > +if

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Mon, Jul 18, 2016 at 10:07:24AM +0300, Felipe Balbi wrote: > > Hi, > > Bin Gao writes: > >> > +int pd_sink_queue_msg(struct pd_sink_msg *msg) > >> > +{ > >> > +unsigned long flags; > >> > +struct pd_sink_port *port; > >> > + > >> > +if (msg->port < 0 || msg->port >=

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Sat, Jul 16, 2016 at 08:49:53AM +0900, Greg Kroah-Hartman wrote: > On Fri, Jul 15, 2016 at 03:41:10PM -0700, Bin Gao wrote: > > On Fri, Jul 15, 2016 at 02:21:48PM +0300, Felipe Balbi wrote: > > > Greg Kroah-Hartman writes: > > > > On Fri, Jul 15, 2016 at 01:38:12PM

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

On Sat, Jul 16, 2016 at 08:49:53AM +0900, Greg Kroah-Hartman wrote: > On Fri, Jul 15, 2016 at 03:41:10PM -0700, Bin Gao wrote: > > On Fri, Jul 15, 2016 at 02:21:48PM +0300, Felipe Balbi wrote: > > > Greg Kroah-Hartman writes: > > > > On Fri, Jul 15, 2016 at 01:38:12PM +0300, Felipe Balbi wrote: >

Re: [PATCH v3 4/4] vfs: Use dlock list for superblock's inode list

On Fri, Jul 15, 2016 at 01:39:43PM -0400, Waiman Long wrote: > void iterate_bdevs(void (*func)(struct block_device *, void *), void *arg) > { > struct inode *inode, *old_inode = NULL; > + DEFINE_DLOCK_LIST_ITER(iter); > > - spin_lock(_superblock->s_inode_list_lock); > -

Re: [PATCH v3 4/4] vfs: Use dlock list for superblock's inode list

On Fri, Jul 15, 2016 at 01:39:43PM -0400, Waiman Long wrote: > void iterate_bdevs(void (*func)(struct block_device *, void *), void *arg) > { > struct inode *inode, *old_inode = NULL; > + DEFINE_DLOCK_LIST_ITER(iter); > > - spin_lock(_superblock->s_inode_list_lock); > -

Re: [PATCH net-next] macvtap: correctly free skb during socket destruction

From: Jason Wang Date: Tue, 19 Jul 2016 11:02:59 +0800 > We should use kfree_skb() instead of kfree() to free an skb. > > Fixes: 362899b8725b ("macvtap: switch to use skb array") > Reported-by: Dan Carpenter > Signed-off-by: Jason Wang

Re: [PATCH net-next] macvtap: correctly free skb during socket destruction

From: Jason Wang Date: Tue, 19 Jul 2016 11:02:59 +0800 > We should use kfree_skb() instead of kfree() to free an skb. > > Fixes: 362899b8725b ("macvtap: switch to use skb array") > Reported-by: Dan Carpenter > Signed-off-by: Jason Wang Applied, thanks Jason.

Re: [RFC PATCH 00/30] Kernel NET policy

From: "Liang, Kan" Date: Tue, 19 Jul 2016 01:49:41 + > Yes, rtnl will bring some overheads. But the configuration is one > time thing for application or socket. It only happens on receiving > first packet. Thanks for destroying our connection rates. This kind of

Re: [RFC PATCH 00/30] Kernel NET policy

From: "Liang, Kan" Date: Tue, 19 Jul 2016 01:49:41 + > Yes, rtnl will bring some overheads. But the configuration is one > time thing for application or socket. It only happens on receiving > first packet. Thanks for destroying our connection rates. This kind of overhead is simply

Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists

On Fri, Jul 15, 2016 at 01:39:40PM -0400, Waiman Long wrote: > +struct dlock_list_head_percpu { > + struct list_head list; > + spinlock_t lock; > +}; > +#define DLOCK_LIST_HEAD_PERCPU_INIT(name)\ > + { \ > +

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Nicolas, On 18/07/16 13:31, Nicolas Pitre wrote: > Remove excessive casts, do some code grouping, etc. > No functional changes. > > Signed-off-by: Nicolas Pitre > --- > fs/binfmt_flat.c | 118 > ++- > 1 file changed, 56

Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists

On Fri, Jul 15, 2016 at 01:39:40PM -0400, Waiman Long wrote: > +struct dlock_list_head_percpu { > + struct list_head list; > + spinlock_t lock; > +}; > +#define DLOCK_LIST_HEAD_PERCPU_INIT(name)\ > + { \ > +

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Nicolas, On 18/07/16 13:31, Nicolas Pitre wrote: > Remove excessive casts, do some code grouping, etc. > No functional changes. > > Signed-off-by: Nicolas Pitre > --- > fs/binfmt_flat.c | 118 > ++- > 1 file changed, 56 insertions(+), 62

Re: Kernel stability on baytrail machines

Dne 13.7.2016 v 12:48 Pavel Machek napsal(a) Are there any updates on the status of this issue? The current bugzilla report [1] marks this as a power management issue. However, many reports indicate that it would only freeze when running X, so it's not completely clear if it's related to the

Re: Kernel stability on baytrail machines

Dne 13.7.2016 v 12:48 Pavel Machek napsal(a) Are there any updates on the status of this issue? The current bugzilla report [1] marks this as a power management issue. However, many reports indicate that it would only freeze when running X, so it's not completely clear if it's related to the

Re: [PATCH v3 12/17] mm, compaction: more reliably increase direct compaction priority

On Mon, Jul 18, 2016 at 02:21:02PM +0200, Vlastimil Babka wrote: > On 07/18/2016 06:41 AM, Joonsoo Kim wrote: > >On Fri, Jul 15, 2016 at 03:37:52PM +0200, Vlastimil Babka wrote: > >>On 07/06/2016 07:39 AM, Joonsoo Kim wrote: > >>>On Fri, Jun 24, 2016 at 11:54:32AM +0200, Vlastimil Babka wrote: >

Re: [PATCH v3 12/17] mm, compaction: more reliably increase direct compaction priority

On Mon, Jul 18, 2016 at 02:21:02PM +0200, Vlastimil Babka wrote: > On 07/18/2016 06:41 AM, Joonsoo Kim wrote: > >On Fri, Jul 15, 2016 at 03:37:52PM +0200, Vlastimil Babka wrote: > >>On 07/06/2016 07:39 AM, Joonsoo Kim wrote: > >>>On Fri, Jun 24, 2016 at 11:54:32AM +0200, Vlastimil Babka wrote: >

RE: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new usage model

Hi, Benjamin > From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com] > Subject: Re: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new > usage model > > Hi, > > On Tue, Jul 12, 2016 at 12:17 PM, Lv Zheng wrote: > > There are many AML tables reporting wrong

Re: [PATCH 3/3] f2fs: support clone_file_range

On Mon, Jul 18, 2016 at 08:47:36PM -0700, Christoph Hellwig wrote: > On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote: > > This patch implements clone_file_range in f2fs. > > [...] > > > +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in, > > + struct file

RE: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new usage model

Hi, Benjamin > From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com] > Subject: Re: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new > usage model > > Hi, > > On Tue, Jul 12, 2016 at 12:17 PM, Lv Zheng wrote: > > There are many AML tables reporting wrong initial lid state, and

Re: [PATCH 3/3] f2fs: support clone_file_range

On Mon, Jul 18, 2016 at 08:47:36PM -0700, Christoph Hellwig wrote: > On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote: > > This patch implements clone_file_range in f2fs. > > [...] > > > +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in, > > + struct file

[PATCH][v2] timekeeping: Fix memory overwrite of sleep_time_bin array

It is reported the hibernation fails at 2nd attempt, which hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further

[PATCH][v2] timekeeping: Fix memory overwrite of sleep_time_bin array

It is reported the hibernation fails at 2nd attempt, which hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further

RE: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by implementing prepare_late/finish_early suspend_ops callbacks

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Subject: Re: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by > implementing prepare_late/finish_early suspend_ops callbacks > > On Tuesday, June 28, 2016 04:04:46

RE: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by implementing prepare_late/finish_early suspend_ops callbacks

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Subject: Re: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by > implementing prepare_late/finish_early suspend_ops callbacks > > On Tuesday, June 28, 2016 04:04:46

[PATCH v3] virtio_blk: Fix a slient kernel panic

From: Minfei Huang We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is

[PATCH v3] virtio_blk: Fix a slient kernel panic

From: Minfei Huang We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is used to drive disk.

Re: [PATCH v1] ESIA : Dummy eisa_driver_register should return error code

On Tue, Jul 19, 2016 at 12:15:01AM +0530, Arvind Yadav wrote: > The inline eisa_driver_register stub simply allows compilation on > systems with CONFIG_EISA disabled. the dummy eisa_driver_register > does not register an *_eisa_driver at all. The inline > eisa_driver_register should return to

Re: [PATCH v1] ESIA : Dummy eisa_driver_register should return error code

On Tue, Jul 19, 2016 at 12:15:01AM +0530, Arvind Yadav wrote: > The inline eisa_driver_register stub simply allows compilation on > systems with CONFIG_EISA disabled. the dummy eisa_driver_register > does not register an *_eisa_driver at all. The inline > eisa_driver_register should return to

Re: [PATCH net-next v3 10/12] net: dsa: support switchdev ageing time attr

Le 18/07/2016 à 20:24, Andrew Lunn a écrit : > On Mon, Jul 18, 2016 at 08:45:38PM -0400, Vivien Didelot wrote: >> Add a new function for DSA drivers to handle the switchdev >> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute. >> >> The ageing time is passed as milliseconds. >> >> Also because we can

Re: [PATCH net-next v3 10/12] net: dsa: support switchdev ageing time attr

Le 18/07/2016 à 20:24, Andrew Lunn a écrit : > On Mon, Jul 18, 2016 at 08:45:38PM -0400, Vivien Didelot wrote: >> Add a new function for DSA drivers to handle the switchdev >> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute. >> >> The ageing time is passed as milliseconds. >> >> Also because we can

Re: [PATCH] radix-tree: fix radix_tree_iter_retry() for tagged iterators.

On Sat, Jul 16, 2016 at 04:45:31PM +0300, Konstantin Khlebnikov wrote: > On Fri, Jul 15, 2016 at 10:00 PM, Ross Zwisler > wrote: <> > > 3) radix_tree_iter_next() via via a non-tagged iteration like > > radix_tree_for_each_slot(). This currently happens in

Re: [PATCH] radix-tree: fix radix_tree_iter_retry() for tagged iterators.

On Sat, Jul 16, 2016 at 04:45:31PM +0300, Konstantin Khlebnikov wrote: > On Fri, Jul 15, 2016 at 10:00 PM, Ross Zwisler > wrote: <> > > 3) radix_tree_iter_next() via via a non-tagged iteration like > > radix_tree_for_each_slot(). This currently happens in shmem_tag_pins() > > and

Re: [PATCH] i2c: efm32: fix a failure path in efm32_i2c_probe()

On Sat, Jul 16, 2016 at 02:36:38AM +0300, Alexey Khoroshilov wrote: > There is the only failure path in efm32_i2c_probe(), > where clk_disable_unprepare() is missed. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov

Re: [PATCH] i2c: efm32: fix a failure path in efm32_i2c_probe()

On Sat, Jul 16, 2016 at 02:36:38AM +0300, Alexey Khoroshilov wrote: > There is the only failure path in efm32_i2c_probe(), > where clk_disable_unprepare() is missed. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Applied to for-next,

[PATCH V2 0/2] Automatically load the vmx_crypto module if supported

From: Alastair D'Silva This series allows the vmx_crypto module to be detected and automatically loaded via UDEV if the CPU supports the vector crypto feature. Alastair D'Silva (2): powerpc: Add module autoloading based on CPU features crypto: vmx - Convert to CPU

[PATCH V2 2/2] crypto: vmx - Convert to CPU feature based module autoloading

From: Alastair D'Silva This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by: Alastair D'Silva --- drivers/crypto/vmx/Kconfig | 2 +- drivers/crypto/vmx/vmx.c

[PATCH V2 2/2] crypto: vmx - Convert to CPU feature based module autoloading

From: Alastair D'Silva This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by: Alastair D'Silva --- drivers/crypto/vmx/Kconfig | 2 +- drivers/crypto/vmx/vmx.c | 6 ++ 2 files changed, 3

[PATCH V2 0/2] Automatically load the vmx_crypto module if supported

From: Alastair D'Silva This series allows the vmx_crypto module to be detected and automatically loaded via UDEV if the CPU supports the vector crypto feature. Alastair D'Silva (2): powerpc: Add module autoloading based on CPU features crypto: vmx - Convert to CPU feature based module

[PATCH V2 1/2] powerpc: Add module autoloading based on CPU features

From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed

[PATCH V2 1/2] powerpc: Add module autoloading based on CPU features

From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed are a mirror of the

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote: > >From kernel guys working on android. Well, until it's mainline it simply doesn't matter, so NAK to this patch. Tying power behavior to plugs also sounds pretty broken, so we'd probably come up with something better if they bothered

Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

On Tue, Jul 19, 2016 at 11:01:55AM +1000, Michael Ellerman wrote: > > Can you please ask for an ack before merging arch patches? > > That's a 70 line powerpc patch and a 6 line crypto patch. It has no > reviews and no acks. I would have preferred it if we could take it via > the powerpc tree.

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote: > >From kernel guys working on android. Well, until it's mainline it simply doesn't matter, so NAK to this patch. Tying power behavior to plugs also sounds pretty broken, so we'd probably come up with something better if they bothered

Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

On Tue, Jul 19, 2016 at 11:01:55AM +1000, Michael Ellerman wrote: > > Can you please ask for an ack before merging arch patches? > > That's a 70 line powerpc patch and a 6 line crypto patch. It has no > reviews and no acks. I would have preferred it if we could take it via > the powerpc tree.

Re: linux-next: manual merge of the pm tree with the i2c tree

> > Well, not knowing much about ACPI, I just need the conflict resolution > > for my latest i2c/for-next and your above branch. If you want to do it, > > fine with me. But maybe Jarkko will be back to office on Monday, too. > > Unfortunately, I don't see how these branches can be merged in a

Re: linux-next: manual merge of the pm tree with the i2c tree

> > Well, not knowing much about ACPI, I just need the conflict resolution > > for my latest i2c/for-next and your above branch. If you want to do it, > > fine with me. But maybe Jarkko will be back to office on Monday, too. > > Unfortunately, I don't see how these branches can be merged in a

Re: [PATCH 3/3] f2fs: support clone_file_range

On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote: > This patch implements clone_file_range in f2fs. [...] > +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in, > + struct file *file_out, loff_t pos_out, u64 len) > +{ > + return f2fs_clone_files(file_in,

Re: [PATCH 3/3] f2fs: support clone_file_range

On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote: > This patch implements clone_file_range in f2fs. [...] > +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in, > + struct file *file_out, loff_t pos_out, u64 len) > +{ > + return f2fs_clone_files(file_in,

Re: [PATCH] hwmon-ntc_thermistor: Delete an unnecessary check before the function call "iio_channel_release"

On 07/18/2016 11:54 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Mon, 18 Jul 2016 20:34:41 +0200 The iio_channel_release() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This

Re: [PATCH] hwmon-ntc_thermistor: Delete an unnecessary check before the function call "iio_channel_release"

On 07/18/2016 11:54 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Mon, 18 Jul 2016 20:34:41 +0200 The iio_channel_release() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the

Re: [RFC PATCH V2] s390/perf: fix 'start' address of module's map

在 7/19/2016 9:50 AM, Songshan Gong 写道: 在 7/19/2016 9:37 AM, Songshan Gong 写道: 在 7/18/2016 10:07 PM, Jiri Olsa 写道: On Fri, Jul 15, 2016 at 06:15:11PM +0800, Song Shan Gong wrote: At preset, when creating module's map, perf gets 'start' address by parsing '/proc/modules', but it's module

Re: [RFC PATCH V2] s390/perf: fix 'start' address of module's map

在 7/19/2016 9:50 AM, Songshan Gong 写道: 在 7/19/2016 9:37 AM, Songshan Gong 写道: 在 7/18/2016 10:07 PM, Jiri Olsa 写道: On Fri, Jul 15, 2016 at 06:15:11PM +0800, Song Shan Gong wrote: At preset, when creating module's map, perf gets 'start' address by parsing '/proc/modules', but it's module

  1   2   3   4   5   6   7   8   9   10   >