Re: testing io.low limit for blk-throttle

Hi Jianchao, On 18/4/27 10:09, jianchao.wang wrote: > Hi Tejun and Joseph > > On 04/27/2018 02:32 AM, Tejun Heo wrote: >> Hello, >> >> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote: >>> +Tejun (I guess he might be interested in the results below) >> >> Our experiments didn't work

Re: testing io.low limit for blk-throttle

Hi Jianchao, On 18/4/27 10:09, jianchao.wang wrote: > Hi Tejun and Joseph > > On 04/27/2018 02:32 AM, Tejun Heo wrote: >> Hello, >> >> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote: >>> +Tejun (I guess he might be interested in the results below) >> >> Our experiments didn't work

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 21:13:51 -0400 Steven Rostedt wrote: > On Thu, 26 Apr 2018 17:10:03 +0900 > Masami Hiramatsu wrote: > > > Replace %p with appropriate pointer types (or just remove it) > > - Use %pS if possible > > - Use %px only for the function

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 21:13:51 -0400 Steven Rostedt wrote: > On Thu, 26 Apr 2018 17:10:03 +0900 > Masami Hiramatsu wrote: > > > Replace %p with appropriate pointer types (or just remove it) > > - Use %pS if possible > > - Use %px only for the function right before BUG(). > > - Remove unneeded

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek wrote: > The function travers the lookup table to check if the request alias > id is compatible with the device driver match structure. > This function will be used by serial drivers to check if requested alias > is allocated

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek wrote: > The function travers the lookup table to check if the request alias > id is compatible with the device driver match structure. > This function will be used by serial drivers to check if requested alias > is allocated or free to use. > >

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

On 2018/4/27 0:36, Jaegeuk Kim wrote: > On 04/26, Chao Yu wrote: >> On 2018/4/26 23:48, Jaegeuk Kim wrote: >>> On 04/26, Chao Yu wrote: Thread A Thread B - f2fs_ioc_commit_atomic_write - commit_inmem_pages - f2fs_submit_merged_write_cond :

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

On 2018/4/27 0:36, Jaegeuk Kim wrote: > On 04/26, Chao Yu wrote: >> On 2018/4/26 23:48, Jaegeuk Kim wrote: >>> On 04/26, Chao Yu wrote: Thread A Thread B - f2fs_ioc_commit_atomic_write - commit_inmem_pages - f2fs_submit_merged_write_cond :

MHI initial design review

Hi Greg Kroah-Hartman\All This is the initial submit of Modem Host Interface (MHI) stack for upstream consideration. MHI is a communication protocol to communicate with external Qualcomm modems and Wi-Fi chipsets over high speed peripheral buses. Even though MHI doesn’t dictate underlying

MHI initial design review

Hi Greg Kroah-Hartman\All This is the initial submit of Modem Host Interface (MHI) stack for upstream consideration. MHI is a communication protocol to communicate with external Qualcomm modems and Wi-Fi chipsets over high speed peripheral buses. Even though MHI doesn’t dictate underlying

[PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

QCOM PCIe based modems uses MHI as the communication protocol. MHI control driver is the bus master for such modems. As the bus master driver, it oversees power management operations such as suspend, resume, powering on and off the device. Signed-off-by: Sujeev Dias ---

[PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

QCOM PCIe based modems uses MHI as the communication protocol. MHI control driver is the bus master for such modems. As the bus master driver, it oversees power management operations such as suspend, resume, powering on and off the device. Signed-off-by: Sujeev Dias ---

[PATCH v1 3/4] mhi_bus: dev: netdev: add network interface driver

MHI based net device driver is used for transferring IP traffic between host and modem. Driver allows clients to transfer data using standard network interface. Signed-off-by: Sujeev Dias --- Documentation/devicetree/bindings/bus/mhi.txt | 36 ++ drivers/bus/Kconfig

[PATCH v1 3/4] mhi_bus: dev: netdev: add network interface driver

MHI based net device driver is used for transferring IP traffic between host and modem. Driver allows clients to transfer data using standard network interface. Signed-off-by: Sujeev Dias --- Documentation/devicetree/bindings/bus/mhi.txt | 36 ++ drivers/bus/Kconfig |

[PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

This module allows user space clients to transfer data between external modem and host using standard file operations. Signed-off-by: Sujeev Dias --- drivers/bus/mhi/devices/Kconfig | 9 + drivers/bus/mhi/devices/Makefile | 1 + drivers/bus/mhi/devices/mhi_uci.c |

[PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

This module allows user space clients to transfer data between external modem and host using standard file operations. Signed-off-by: Sujeev Dias --- drivers/bus/mhi/devices/Kconfig | 9 + drivers/bus/mhi/devices/Makefile | 1 + drivers/bus/mhi/devices/mhi_uci.c | 662

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

On 04/26/2018 12:31 PM, Rich Felker wrote: On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: From: Bartosz Golaszewski This is a follow to my series[1] the aim of which was to introduce device tree support for early platform devices. It was

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

On 04/26/2018 12:31 PM, Rich Felker wrote: On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: From: Bartosz Golaszewski This is a follow to my series[1] the aim of which was to introduce device tree support for early platform devices. It was received rather negatively.

RE: [PATCH] USB: serial: option: adding support for ublox R410M

> > Option is likely the right driver for this device. > > qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the > modem port > and a secondary DIAG/DM port driven by qcaux. The DM port doesn't have an > interrupt > endpoint thus it's not a normal modem port requiring

RE: [PATCH] USB: serial: option: adding support for ublox R410M

> > Option is likely the right driver for this device. > > qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the > modem port > and a secondary DIAG/DM port driven by qcaux. The DM port doesn't have an > interrupt > endpoint thus it's not a normal modem port requiring

Re: [PATCH v2] of: overlay: Stop leaking resources on overlay removal

On Thu, Apr 26, 2018 at 01:00:30PM +0200, Jan Kiszka wrote: > Only the overlay notifier callbacks have a chance to potentially get > hold of references to those two resources, but they are not supposed to > store them beyond OF_OVERLAY_POST_REMOVE. > > Document the overlay notifier API, its

Re: [PATCH v2] of: overlay: Stop leaking resources on overlay removal

On Thu, Apr 26, 2018 at 01:00:30PM +0200, Jan Kiszka wrote: > Only the overlay notifier callbacks have a chance to potentially get > hold of references to those two resources, but they are not supposed to > store them beyond OF_OVERLAY_POST_REMOVE. > > Document the overlay notifier API, its

Re: [PATCH 3/3] thermal: armada_thermal: Replace mdelay with usleep_range in armada380_init_sensor

On Tue, Apr 10, 2018 at 04:13:28PM +0800, Jia-Ju Bai wrote: > armada380_init_sensor() is never called in atomic context. > > armada380_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe() is set as

Re: [PATCH 3/3] thermal: armada_thermal: Replace mdelay with usleep_range in armada380_init_sensor

On Tue, Apr 10, 2018 at 04:13:28PM +0800, Jia-Ju Bai wrote: > armada380_init_sensor() is never called in atomic context. > > armada380_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe() is set as

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

On Thu, Apr 26, 2018 at 2:42 PM, Thomas Petazzoni wrote: > Hello, > > On Thu, 26 Apr 2018 11:02:55 +0530, Viresh Kumar wrote: >> @Thomas: Do you guys use this ? >> >> On 25-04-18, 20:57, Rob Herring wrote: >> > Remove LPC32xx and SPEAr ADC bindings in staging. They

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

On Thu, Apr 26, 2018 at 2:42 PM, Thomas Petazzoni wrote: > Hello, > > On Thu, 26 Apr 2018 11:02:55 +0530, Viresh Kumar wrote: >> @Thomas: Do you guys use this ? >> >> On 25-04-18, 20:57, Rob Herring wrote: >> > Remove LPC32xx and SPEAr ADC bindings in staging. They have not been >> > touched

RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support

Anson Huang Best Regards! > -Original Message- > From: Anson Huang > Sent: Friday, April 27, 2018 9:37 AM > To: 'Fabio Estevam' > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Rob > Herring

RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support

Anson Huang Best Regards! > -Original Message- > From: Anson Huang > Sent: Friday, April 27, 2018 9:37 AM > To: 'Fabio Estevam' > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Rob > Herring ; Mark Rutland ; > dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC > ARM ARCHITECTURE

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

Hi Geert, test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511 indicate the RDB parser bug is fixed by the patch given there, so if Martin now submits the patch, all should be well? (MSDOS partition support is not the only one with limitations - the SGI partition parser also uses

Re: [PATCH 2/3] thermal: armada_thermal: Replace mdelay with msleep in armada375_init_sensor

On Tue, Apr 10, 2018 at 04:13:16PM +0800, Jia-Ju Bai wrote: > armada375_init_sensor() is never called in atomic context. > > armada375_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe() is set as

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

Hi Geert, test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511 indicate the RDB parser bug is fixed by the patch given there, so if Martin now submits the patch, all should be well? (MSDOS partition support is not the only one with limitations - the SGI partition parser also uses

Re: [PATCH 2/3] thermal: armada_thermal: Replace mdelay with msleep in armada375_init_sensor

On Tue, Apr 10, 2018 at 04:13:16PM +0800, Jia-Ju Bai wrote: > armada375_init_sensor() is never called in atomic context. > > armada375_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe() is set as

Re: [PATCH 1/3] thermal: armada_thermal: Replace mdelay with usleep_range in armada370_init_sensor

Hey Jia-Ju, On Tue, Apr 10, 2018 at 04:13:02PM +0800, Jia-Ju Bai wrote: > armada370_init_sensor() is never called in atomic context. > > armada370_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe()

Re: [PATCH 1/3] thermal: armada_thermal: Replace mdelay with usleep_range in armada370_init_sensor

Hey Jia-Ju, On Tue, Apr 10, 2018 at 04:13:02PM +0800, Jia-Ju Bai wrote: > armada370_init_sensor() is never called in atomic context. > > armada370_init_sensor() is set as ".init_sensor" in > struct armada_thermal_data. > ".init_sensor" is called armada_thermal_probe(). > armada_thermal_probe()

Re: testing io.low limit for blk-throttle

Hi Tejun and Joseph On 04/27/2018 02:32 AM, Tejun Heo wrote: > Hello, > > On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote: >> +Tejun (I guess he might be interested in the results below) > > Our experiments didn't work out too well either. At this point, it > isn't clear whether

Re: testing io.low limit for blk-throttle

Hi Tejun and Joseph On 04/27/2018 02:32 AM, Tejun Heo wrote: > Hello, > > On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote: >> +Tejun (I guess he might be interested in the results below) > > Our experiments didn't work out too well either. At this point, it > isn't clear whether

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/27 10:04, Chao Yu wrote: > On 2018/4/27 0:03, Jaegeuk Kim wrote: >> On 04/24, Chao Yu wrote: >>> Thread AThread BThread C >>> - f2fs_remount >>> - stop_gc_thread >>> - f2fs_sbi_store >>>

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/27 10:04, Chao Yu wrote: > On 2018/4/27 0:03, Jaegeuk Kim wrote: >> On 04/24, Chao Yu wrote: >>> Thread AThread BThread C >>> - f2fs_remount >>> - stop_gc_thread >>> - f2fs_sbi_store >>>

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/27 0:03, Jaegeuk Kim wrote: > On 04/24, Chao Yu wrote: >> Thread A Thread BThread C >> - f2fs_remount >> - stop_gc_thread >> - f2fs_sbi_store >> - issue_discard_thread

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/27 0:03, Jaegeuk Kim wrote: > On 04/24, Chao Yu wrote: >> Thread A Thread BThread C >> - f2fs_remount >> - stop_gc_thread >> - f2fs_sbi_store >> - issue_discard_thread

[PATCH net-next 2/3] net: dsa: mv88e6xxx: move device mapping setup

Move the Device Mapping setup out of the specific Global 2 code, into the top level device setup function. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c| 27 + drivers/net/dsa/mv88e6xxx/global2.c | 37

[PATCH net-next 0/3] net: dsa: mv88e6xxx: remove Global 2 setup

Parts of the mv88e6xxx driver still write arbitrary registers of different banks at setup time, which is misleading especially when supporting multiple device models. This patchset moves two features setup into the top lovel mv88e6xxx_setup function and kills the old Global 2 register bank setup

[PATCH net-next 2/3] net: dsa: mv88e6xxx: move device mapping setup

Move the Device Mapping setup out of the specific Global 2 code, into the top level device setup function. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c| 27 + drivers/net/dsa/mv88e6xxx/global2.c | 37 +

[PATCH net-next 0/3] net: dsa: mv88e6xxx: remove Global 2 setup

Parts of the mv88e6xxx driver still write arbitrary registers of different banks at setup time, which is misleading especially when supporting multiple device models. This patchset moves two features setup into the top lovel mv88e6xxx_setup function and kills the old Global 2 register bank setup

[PATCH net-next 3/3] net: dsa: mv88e6xxx: remove Global 2 setup

The remaining values written to the Switch Management Register in the mv88e6xxx_g2_setup function are specific to 88E6352 and older, and are the default values anyway. Thus remove completely this function. The mv88e6xxx driver no more contains setup code to access arbitrary Global 2 registers.

[PATCH net-next 3/3] net: dsa: mv88e6xxx: remove Global 2 setup

The remaining values written to the Switch Management Register in the mv88e6xxx_g2_setup function are specific to 88E6352 and older, and are the default values anyway. Thus remove completely this function. The mv88e6xxx driver no more contains setup code to access arbitrary Global 2 registers.

[PATCH net-next 1/3] net: dsa: mv88e6xxx: move trunk setup

Move the trunking setup out of Global 2 specific setup into the top level mv88e6xxx_setup function. Note that the 88E6390 family calls this LAG instead of Trunk and supports 32 possible ID routing vectors, with LAG ID bit 4 being placed in Global 2 register 0x1D... We don't need Trunk (or LAG)

[PATCH net-next 1/3] net: dsa: mv88e6xxx: move trunk setup

Move the trunking setup out of Global 2 specific setup into the top level mv88e6xxx_setup function. Note that the 88E6390 family calls this LAG instead of Trunk and supports 32 possible ID routing vectors, with LAG ID bit 4 being placed in Global 2 register 0x1D... We don't need Trunk (or LAG)

Re: [f2fs-dev] [PATCH 4/5 v2] f2fs: sanity check for total valid blocks

On 2018/4/26 23:29, Jaegeuk Kim wrote: > This patch enhances sanity check for SIT entries. > > syzbot hit the following crash on upstream commit > 83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +) > Merge branch 'fixes' of >

Re: [f2fs-dev] [PATCH 4/5 v2] f2fs: sanity check for total valid blocks

On 2018/4/26 23:29, Jaegeuk Kim wrote: > This patch enhances sanity check for SIT entries. > > syzbot hit the following crash on upstream commit > 83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +) > Merge branch 'fixes' of >

Re: [PATCH v2] f2fs: avoid stucking GC due to atomic write

On 2018/4/26 23:54, Jaegeuk Kim wrote: > On 04/24, Chao Yu wrote: >> f2fs doesn't allow abuse on atomic write class interface, so except >> limiting in-mem pages' total memory usage capacity, we need to limit >> atomic-write usage as well when filesystem is seriously fragmented, >> otherwise we

Re: [PATCH v2] f2fs: avoid stucking GC due to atomic write

On 2018/4/26 23:54, Jaegeuk Kim wrote: > On 04/24, Chao Yu wrote: >> f2fs doesn't allow abuse on atomic write class interface, so except >> limiting in-mem pages' total memory usage capacity, we need to limit >> atomic-write usage as well when filesystem is seriously fragmented, >> otherwise we

[PATCH v2 1/2] pinctrl: uniphier: add LD20 MPEG2-TS I/O pin-mux settings

The MPEG2-TS input/output core both accepts serial TS and parallel TS. The serial TS interface uses following pins: hscin0_s : HS0DOUT[0-3] hscin1_s : HS0DOUT[4-7] hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 hscin3_s : HS1DIN[2-5] hscout0_s: HS0DOUT[0-3] hscout1_s: HS0DOUT[4-7]

[PATCH v2 1/2] pinctrl: uniphier: add LD20 MPEG2-TS I/O pin-mux settings

The MPEG2-TS input/output core both accepts serial TS and parallel TS. The serial TS interface uses following pins: hscin0_s : HS0DOUT[0-3] hscin1_s : HS0DOUT[4-7] hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 hscin3_s : HS1DIN[2-5] hscout0_s: HS0DOUT[0-3] hscout1_s: HS0DOUT[4-7]

[PATCH v2 2/2] pinctrl: uniphier: add LD11 MPEG2-TS I/O pin-mux settings

The MPEG2-TS input/output core both accepts serial TS and parallel TS. The serial TS interface uses following pins: hscin0_s : HS0DOUT[0-3] hscin1_s : HS0DOUT[4-7] hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 hscout0_s: HS0DOUT[0-3] hscout1_s: HS0DOUT[4-7] And the parallel TS

[PATCH v2 2/2] pinctrl: uniphier: add LD11 MPEG2-TS I/O pin-mux settings

The MPEG2-TS input/output core both accepts serial TS and parallel TS. The serial TS interface uses following pins: hscin0_s : HS0DOUT[0-3] hscin1_s : HS0DOUT[4-7] hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 hscout0_s: HS0DOUT[0-3] hscout1_s: HS0DOUT[4-7] And the parallel TS

Re: Unable to handle kernel paging request in snd_seq_oss_readq_puts

On Thu, Apr 26, 2018 at 09:17:45AM +0200, Takashi Iwai wrote: > On Thu, 26 Apr 2018 06:52:27 +0200, > DaeRyong Jeong wrote: > > > > We report the crash: > > unable to handle kernel paging request in snd_seq_oss_readq_puts > > > > This crash has been found in v4.16 using RaceFuzzer (a modified >

Re: Unable to handle kernel paging request in snd_seq_oss_readq_puts

On Thu, Apr 26, 2018 at 09:17:45AM +0200, Takashi Iwai wrote: > On Thu, 26 Apr 2018 06:52:27 +0200, > DaeRyong Jeong wrote: > > > > We report the crash: > > unable to handle kernel paging request in snd_seq_oss_readq_puts > > > > This crash has been found in v4.16 using RaceFuzzer (a modified >

Re: [PATCH] do not call trace_printk on non-debug build

On Wed, 25 Apr 2018 04:53:33 + Wei Wang wrote: > On Tue, Apr 24, 2018 at 12:26 PM Steven Rostedt wrote: > > A lot of kernel developers use trace_printk() and I want to make it as > > easy to use as possible. I don't want to add a config to enable it, >

Re: [PATCH] do not call trace_printk on non-debug build

On Wed, 25 Apr 2018 04:53:33 + Wei Wang wrote: > On Tue, Apr 24, 2018 at 12:26 PM Steven Rostedt wrote: > > A lot of kernel developers use trace_printk() and I want to make it as > > easy to use as possible. I don't want to add a config to enable it, > > because that would be something that

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Wed, 25 Apr 2018 21:16:06 +0900 Masami Hiramatsu wrote: > Hi, > > This is the 7th version of the fetch-arg improvement series. > This includes variable changes on fetcharg framework like, > > - Add fetcharg testcases (syntax, argN, symbol, string and array) > and

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Wed, 25 Apr 2018 21:16:06 +0900 Masami Hiramatsu wrote: > Hi, > > This is the 7th version of the fetch-arg improvement series. > This includes variable changes on fetcharg framework like, > > - Add fetcharg testcases (syntax, argN, symbol, string and array) > and probepoint testcase. > -

Re: [f2fs-dev] [PATCH 5/5] f2fs: enforce fsync_mode=strict for renamed directory

On 2018/4/26 23:32, Jaegeuk Kim wrote: > On 04/25, Chao Yu wrote: >> On 2018/4/25 13:46, Jaegeuk Kim wrote: >>> This is to give a option for user to be able to recover B/foo in the below >>> case. >>> >>> mkdir A >>> sync() >>> rename(A, B) >>> creat (B/foo) >>> fsync (B/foo) >>> ---crash--- >> >>

Re: [f2fs-dev] [PATCH 5/5] f2fs: enforce fsync_mode=strict for renamed directory

On 2018/4/26 23:32, Jaegeuk Kim wrote: > On 04/25, Chao Yu wrote: >> On 2018/4/25 13:46, Jaegeuk Kim wrote: >>> This is to give a option for user to be able to recover B/foo in the below >>> case. >>> >>> mkdir A >>> sync() >>> rename(A, B) >>> creat (B/foo) >>> fsync (B/foo) >>> ---crash--- >> >>

Re: [PATCH 0/3] A few hist trigger fixes

On Thu, 26 Apr 2018 20:04:46 -0500 Tom Zanussi wrote: > Hi Steve, > > Here are a few patches that fix some problems found when testing the > hist trigger inter-event (e.g. latency) support patches. > > The first fixes a problem I noticed when printing flags. > >

Re: [PATCH 0/3] A few hist trigger fixes

On Thu, 26 Apr 2018 20:04:46 -0500 Tom Zanussi wrote: > Hi Steve, > > Here are a few patches that fix some problems found when testing the > hist trigger inter-event (e.g. latency) support patches. > > The first fixes a problem I noticed when printing flags. > > The remaining two add some

RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support

Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Friday, April 27, 2018 1:29 AM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam

RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support

Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Friday, April 27, 2018 1:29 AM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Rob > Herring ; Mark Rutland ; > dl-linux-imx ; moderated list:ARM/FREESCALE IMX

Re: [PATCH] m68k: Fix calendar month regression on M68328

Hi Finn, On 27/04/18 11:12, Finn Thain wrote: > My earlier fix for read_persistent_clock() neglected to cover > m68328_hwclk(). Correct this oversight. > > Cc: Geert Uytterhoeven > Signed-off-by: Finn Thain > --- > Greg, the

Re: [PATCH] m68k: Fix calendar month regression on M68328

Hi Finn, On 27/04/18 11:12, Finn Thain wrote: > My earlier fix for read_persistent_clock() neglected to cover > m68328_hwclk(). Correct this oversight. > > Cc: Geert Uytterhoeven > Signed-off-by: Finn Thain > --- > Greg, the read_persistent_clock() change has already been queued > by Geert.

RE: [PATCH V4 3/6] ARM: dts: imx6sx-sabreauto: add IO expander max7310 support

Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Friday, April 27, 2018 1:24 AM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam

RE: [PATCH V4 3/6] ARM: dts: imx6sx-sabreauto: add IO expander max7310 support

Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Friday, April 27, 2018 1:24 AM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Rob > Herring ; Mark Rutland ; > Russell King - ARM Linux ; dl-linux-imx > ;

Re: [PATCH net-next v5 1/3] vmcore: add API to collect hardware dump in second kernel

While looking this over I found a bug in the way elf notes are being composed. Rahul Lakkireddy writes: > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index a45f0af22a60..7395462d2f86 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -1145,6

Re: [PATCH net-next v5 1/3] vmcore: add API to collect hardware dump in second kernel

While looking this over I found a bug in the way elf notes are being composed. Rahul Lakkireddy writes: > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index a45f0af22a60..7395462d2f86 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -1145,6 +1150,132 @@ static int __init

[PATCH] Documentation: driver-api: fix device_connection.rst kernel-doc error

ead.org> Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com> --- Documentation/driver-api/device_connection.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180426.orig/Documentation/driver-api/device_connection.rst +++ linux-next-20180426/Documentation/driv

[PATCH] Documentation: driver-api: fix device_connection.rst kernel-doc error

driver-api/device_connection.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180426.orig/Documentation/driver-api/device_connection.rst +++ linux-next-20180426/Documentation/driver-api/device_connection.rst @@ -40,4 +40,4 @@ API --- .. kernel-doc:: drivers/bas

[PATCH 0/4] FPGA Manager Patches for 4.18

Hi Greg, Here's Alan's reworked patchset changing the API for creating and registering FPGA Managers, Bridges and Regions following your suggestions on the API. These go on top of Paolo and Alan's patches that you queued up the other day. Thanks, Moritz Alan Tull (4): fpga: region: don't

[PATCH 0/4] FPGA Manager Patches for 4.18

Hi Greg, Here's Alan's reworked patchset changing the API for creating and registering FPGA Managers, Bridges and Regions following your suggestions on the API. These go on top of Paolo and Alan's patches that you queued up the other day. Thanks, Moritz Alan Tull (4): fpga: region: don't

[PATCH 1/4] fpga: region: don't use drvdata in common fpga code

From: Alan Tull Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes,

[PATCH 1/4] fpga: region: don't use drvdata in common fpga code

From: Alan Tull Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution

[PATCH 4/4] fpga: region: change api, add fpga_region_create/free

From: Alan Tull Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct

[PATCH 4/4] fpga: region: change api, add fpga_region_create/free

From: Alan Tull Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct fpga_manager *mgr,

[PATCH 2/4] fpga: manager: change api, don't use drvdata

From: Alan Tull Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only

[PATCH 3/4] fpga: bridge: change api, don't use drvdata

From: Alan Tull Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the

[PATCH 2/4] fpga: manager: change api, don't use drvdata

From: Alan Tull Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only parameter. struct

[PATCH 3/4] fpga: bridge: change api, don't use drvdata

From: Alan Tull Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the only parameter.

Re: [PATCH v2 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH v2 6/6] rpmsg: glink: Expose rpmsg name attr for glink

Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

[PATCH] mac80211: fix kernel-doc "bad line" warning

> --- include/net/mac80211.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180426.orig/include/net/mac80211.h +++ linux-next-20180426/include/net/mac80211.h @@ -2080,7 +2080,7 @@ struct ieee80211_txq { * virtual interface might not be given air time

[PATCH] mac80211: fix kernel-doc "bad line" warning

nux-next-20180426.orig/include/net/mac80211.h +++ linux-next-20180426/include/net/mac80211.h @@ -2080,7 +2080,7 @@ struct ieee80211_txq { * virtual interface might not be given air time for the transmission of * the frame, as it is not synced with the AP/P2P GO yet, and t

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 17:10:03 +0900 Masami Hiramatsu wrote: > Replace %p with appropriate pointer types (or just remove it) > - Use %pS if possible > - Use %px only for the function right before BUG(). > - Remove unneeded error message. I'm not sure "right before BUG()"

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 17:10:03 +0900 Masami Hiramatsu wrote: > Replace %p with appropriate pointer types (or just remove it) > - Use %pS if possible > - Use %px only for the function right before BUG(). > - Remove unneeded error message. I'm not sure "right before BUG()" is legitimate for

Re: [PATCH 7/7] clk: meson: axg: add the audio clock controller driver

Hi Jerome, I love your patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH 7/7] clk: meson: axg: add the audio clock controller driver

Hi Jerome, I love your patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH -tip v2 0/7] kprobes: Fix %p in kprobes

On Thu, 26 Apr 2018 10:40:22 +0200 Greg KH wrote: > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this

Re: [PATCH -tip v2 0/7] kprobes: Fix %p in kprobes

On Thu, 26 Apr 2018 10:40:22 +0200 Greg KH wrote: > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > > Is it because he

[PATCH] m68k: Fix calendar month regression on M68328

My earlier fix for read_persistent_clock() neglected to cover m68328_hwclk(). Correct this oversight. Cc: Geert Uytterhoeven Signed-off-by: Finn Thain --- Greg, the read_persistent_clock() change has already been queued by Geert. Should this

[PATCH] m68k: Fix calendar month regression on M68328

My earlier fix for read_persistent_clock() neglected to cover m68328_hwclk(). Correct this oversight. Cc: Geert Uytterhoeven Signed-off-by: Finn Thain --- Greg, the read_persistent_clock() change has already been queued by Geert. Should this patch be pushed together with that one (presuming

[PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

gether into the (newly named) CRC and Math Functions chapter Signed-off-by: Randy Dunlap <rdun...@infradead.org> --- Documentation/core-api/kernel-api.rst | 60 1 file changed, 30 insertions(+), 30 deletions(-) --- linux-next-20180426.orig/Documentation/cor

[PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

) CRC and Math Functions chapter Signed-off-by: Randy Dunlap --- Documentation/core-api/kernel-api.rst | 60 1 file changed, 30 insertions(+), 30 deletions(-) --- linux-next-20180426.orig/Documentation/core-api/kernel-api.rst +++ linux-next-20180426/Documentation/core

<    1   2   3   4   5   6   7   8   9   10   >