Re: [PATCH v2 1/2] i2c: octeon: thunderx: Check bus state before starting a transaction

[Jan Glauber]

On Sat, Sep 24, 2016 at 11:24:19AM +0200, Wolfram Sang wrote:
> On Fri, Sep 23, 2016 at 11:40:38AM +0200, Jan Glauber wrote:
> > Add an additional status check before starting a transaction. If the
> > check fails wait for some time to tolerate multi-master mode. After the
> > timeout expires trigger the recovery.
> > 
> > Signed-off-by: Jan Glauber 
> 
> Need to think more about it, needs to wait for next cycle.
> 

OK, please share your thoughts when you get to it.

--Jan

Re: [PATCH v2 1/2] i2c: octeon: thunderx: Check bus state before starting a transaction

[Jan Glauber]

On Sat, Sep 24, 2016 at 11:24:19AM +0200, Wolfram Sang wrote:
> On Fri, Sep 23, 2016 at 11:40:38AM +0200, Jan Glauber wrote:
> > Add an additional status check before starting a transaction. If the
> > check fails wait for some time to tolerate multi-master mode. After the
> > timeout expires trigger the recovery.
> > 
> > Signed-off-by: Jan Glauber 
> 
> Need to think more about it, needs to wait for next cycle.
> 

OK, please share your thoughts when you get to it.

--Jan

RE: [PATCH 1/3] megaraid_sas: mark symbols static where possible

[Sumit Saxena]

>-Original Message-
>From: Baoyou Xie [mailto:baoyou@linaro.org]
>Sent: Sunday, September 25, 2016 11:21 AM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-s...@vger.kernel.org; linux-
>ker...@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
>xie.bao...@zte.com.cn
>Subject: [PATCH 1/3] megaraid_sas: mark symbols static where possible
>
>We get a few warnings when building kernel with W=1:
>drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no previous
prototype
>for 'mega_mod64' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no previous
prototype
>for 'mega_div64_32' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:177:6: warning: no previous
prototype
>for 'MR_PopulateDrvRaidMap' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:315:5: warning: no previous
prototype
>for 'MR_GetSpanBlock' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:451:5: warning: no previous
prototype
>for 'mr_spanset_get_span_block' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:692:4: warning: no previous
prototype
>for 'get_arm' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:815:4: warning: no previous
prototype
>for 'MR_GetPhyParams' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:1293:4: warning: no previous
>prototype for 'megasas_get_best_arm_pd' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:106:1: warning: no previous
>prototype for 'megasas_enable_intr_fusion' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:127:1: warning: no previous
>prototype for 'megasas_disable_intr_fusion' [-Wmissing-prototypes] 
>
>In fact, these functions are only used in the file in which they are
declared and
>don't need a declaration, but can be made static.
>so this patch marks these functions with 'static'.
>
>Signed-off-by: Baoyou Xie 
>---
> drivers/scsi/megaraid/megaraid_sas_base.c   |  6 ++--
> drivers/scsi/megaraid/megaraid_sas_fp.c | 30 ++---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 52
+++--
> 3 files changed, 48 insertions(+), 40 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c236c4d..1b033da 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -209,7 +209,7 @@ static int megasas_get_ld_vf_affiliation(struct
>megasas_instance *instance,  int megasas_check_mpio_paths(struct
>megasas_instance *instance,
>struct scsi_cmnd *scmd);
>
>-int
>+static int
> megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd
>*cmd)  {
>   instance->instancet->fire_cmd(instance,
>@@ -2057,7 +2057,7 @@ megasas_internal_reset_defer_cmds(struct
>megasas_instance *instance);  static void
process_fw_state_change_wq(struct
>work_struct *work);
>
>-void megasas_do_ocr(struct megasas_instance *instance)
>+static void megasas_do_ocr(struct megasas_instance *instance)
> {
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_SAS1064R) ||
>   (instance->pdev->device == PCI_DEVICE_ID_DELL_PERC5) || @@ -
>3981,7 +3981,7 @@ int megasas_alloc_cmds(struct megasas_instance
*instance)
>  * Return 0 for only Fusion adapter, if driver load/unload is not in
progress
>  * or FW is not under OCR.
>  */
>-inline int
>+static inline int
> dcmd_timeout_ocr_possible(struct megasas_instance *instance) {
>
>   if (!instance->ctrl_context)
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
>b/drivers/scsi/megaraid/megaraid_sas_fp.c
>index e413113..d22bb59 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
>@@ -91,7 +91,7 @@ static u8 mr_spanset_get_phy_params(struct
>megasas_instance *instance, u32 ld,  static u64 get_row_from_strip(struct
>megasas_instance *instance, u32 ld,
>   u64 strip, struct MR_DRV_RAID_MAP_ALL *map);
>
>-u32 mega_mod64(u64 dividend, u32 divisor)
>+static u32 mega_mod64(u64 dividend, u32 divisor)
> {
>   u64 d;
>   u32 remainder;
>@@ -109,7 +109,7 @@ u32 mega_mod64(u64 dividend, u32 divisor)
>  *
>  * @return quotient
>  **/
>-u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
>+static u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
> {
>   u32 remainder;
>   u64 d;
>@@ -174,7 +174,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGet(u32 ld,
>u32 span,
> /*
>  * This function will Populate Driver Map using firmware raid map
>  */
>-void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
>+static void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
> {
>   struct fusion_context *fusion = instance->ctrl_context;
>   struct MR_FW_RAID_MAP_ALL *fw_map_old= NULL;
>@@ -312,8 

RE: [PATCH 1/3] megaraid_sas: mark symbols static where possible

[Sumit Saxena]

>-Original Message-
>From: Baoyou Xie [mailto:baoyou@linaro.org]
>Sent: Sunday, September 25, 2016 11:21 AM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-s...@vger.kernel.org; linux-
>ker...@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
>xie.bao...@zte.com.cn
>Subject: [PATCH 1/3] megaraid_sas: mark symbols static where possible
>
>We get a few warnings when building kernel with W=1:
>drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no previous
prototype
>for 'mega_mod64' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no previous
prototype
>for 'mega_div64_32' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:177:6: warning: no previous
prototype
>for 'MR_PopulateDrvRaidMap' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:315:5: warning: no previous
prototype
>for 'MR_GetSpanBlock' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:451:5: warning: no previous
prototype
>for 'mr_spanset_get_span_block' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:692:4: warning: no previous
prototype
>for 'get_arm' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:815:4: warning: no previous
prototype
>for 'MR_GetPhyParams' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:1293:4: warning: no previous
>prototype for 'megasas_get_best_arm_pd' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:106:1: warning: no previous
>prototype for 'megasas_enable_intr_fusion' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:127:1: warning: no previous
>prototype for 'megasas_disable_intr_fusion' [-Wmissing-prototypes] 
>
>In fact, these functions are only used in the file in which they are
declared and
>don't need a declaration, but can be made static.
>so this patch marks these functions with 'static'.
>
>Signed-off-by: Baoyou Xie 
>---
> drivers/scsi/megaraid/megaraid_sas_base.c   |  6 ++--
> drivers/scsi/megaraid/megaraid_sas_fp.c | 30 ++---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 52
+++--
> 3 files changed, 48 insertions(+), 40 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c236c4d..1b033da 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -209,7 +209,7 @@ static int megasas_get_ld_vf_affiliation(struct
>megasas_instance *instance,  int megasas_check_mpio_paths(struct
>megasas_instance *instance,
>struct scsi_cmnd *scmd);
>
>-int
>+static int
> megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd
>*cmd)  {
>   instance->instancet->fire_cmd(instance,
>@@ -2057,7 +2057,7 @@ megasas_internal_reset_defer_cmds(struct
>megasas_instance *instance);  static void
process_fw_state_change_wq(struct
>work_struct *work);
>
>-void megasas_do_ocr(struct megasas_instance *instance)
>+static void megasas_do_ocr(struct megasas_instance *instance)
> {
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_SAS1064R) ||
>   (instance->pdev->device == PCI_DEVICE_ID_DELL_PERC5) || @@ -
>3981,7 +3981,7 @@ int megasas_alloc_cmds(struct megasas_instance
*instance)
>  * Return 0 for only Fusion adapter, if driver load/unload is not in
progress
>  * or FW is not under OCR.
>  */
>-inline int
>+static inline int
> dcmd_timeout_ocr_possible(struct megasas_instance *instance) {
>
>   if (!instance->ctrl_context)
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
>b/drivers/scsi/megaraid/megaraid_sas_fp.c
>index e413113..d22bb59 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
>@@ -91,7 +91,7 @@ static u8 mr_spanset_get_phy_params(struct
>megasas_instance *instance, u32 ld,  static u64 get_row_from_strip(struct
>megasas_instance *instance, u32 ld,
>   u64 strip, struct MR_DRV_RAID_MAP_ALL *map);
>
>-u32 mega_mod64(u64 dividend, u32 divisor)
>+static u32 mega_mod64(u64 dividend, u32 divisor)
> {
>   u64 d;
>   u32 remainder;
>@@ -109,7 +109,7 @@ u32 mega_mod64(u64 dividend, u32 divisor)
>  *
>  * @return quotient
>  **/
>-u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
>+static u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
> {
>   u32 remainder;
>   u64 d;
>@@ -174,7 +174,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGet(u32 ld,
>u32 span,
> /*
>  * This function will Populate Driver Map using firmware raid map
>  */
>-void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
>+static void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
> {
>   struct fusion_context *fusion = instance->ctrl_context;
>   struct MR_FW_RAID_MAP_ALL *fw_map_old= NULL;
>@@ -312,8 +312,8 @@ u8 

Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER

[Masahiro Yamada]

Hi Philipp,


2016-09-20 19:44 GMT+09:00 Philipp Zabel :
> Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
>> Hi Philipp,
>>
>>
>> 2016-09-20 16:30 GMT+09:00 Philipp Zabel :
>> > Hi Masahiro,
>> >
>> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> >> merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>> >>
>> >> Signed-off-by: Masahiro Yamada 
>> >> ---
>> >>
>> >> Philipp,
>> >>
>> >> IIRC, you mentioned that you were planning to consolidate the double
>> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>> >>
>> >> I have not seen it in the ML, so I am sending this.
>> >>
>> >> Please let me know if you have some updates.
>> >
>> > I had started to doodle a bit, see
>> >
>> > git fetch git://git.pengutronix.de/git/pza/linux.git 
>> > refs/heads/reset/kconfig
>> >
>> > but I haven't found time for cleanup and testing.
>>
>>
>> OK, I will merge this patch for now.
>>
>>
>>
>> BTW, I did not understand some of your commits under way.
>>
>>
>> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
>> Author: Philipp Zabel 
>> Date:   Tue Aug 9 11:18:51 2016 +0200
>>
>> dmaengine: sunx6i: do not depend on reset controller framework
>>
>> The reset controller framework provides inline function stubs if
>> disabled.
>>
>> Signed-off-by: Philipp Zabel 
>>
>>
>>
>>
>>
>> As far as I see from drivers/dma/sun6i-dma.c,
>> the reset control is mandatory for this driver.
>>
>> Why are you removing the dependency?
>>
>>
>> Don't you care if it works on run-time
>> as long as it can build?
>
> I have not thought about this too hard, it's just there because the
> reset framework is not a build dependency (anymore). Some patches were
> necessary to remove dependency loops, but I think this one could just be
> dropped.


I have not taken a close look at it, but
if "dependency loops" is the reason for the change,
please mention it in the git-log.

I do not think we should remove the "depends on"
only for the reason "inline function stubs are already provided".



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER

[Masahiro Yamada]

Hi Philipp,


2016-09-20 19:44 GMT+09:00 Philipp Zabel :
> Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
>> Hi Philipp,
>>
>>
>> 2016-09-20 16:30 GMT+09:00 Philipp Zabel :
>> > Hi Masahiro,
>> >
>> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> >> merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>> >>
>> >> Signed-off-by: Masahiro Yamada 
>> >> ---
>> >>
>> >> Philipp,
>> >>
>> >> IIRC, you mentioned that you were planning to consolidate the double
>> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>> >>
>> >> I have not seen it in the ML, so I am sending this.
>> >>
>> >> Please let me know if you have some updates.
>> >
>> > I had started to doodle a bit, see
>> >
>> > git fetch git://git.pengutronix.de/git/pza/linux.git 
>> > refs/heads/reset/kconfig
>> >
>> > but I haven't found time for cleanup and testing.
>>
>>
>> OK, I will merge this patch for now.
>>
>>
>>
>> BTW, I did not understand some of your commits under way.
>>
>>
>> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
>> Author: Philipp Zabel 
>> Date:   Tue Aug 9 11:18:51 2016 +0200
>>
>> dmaengine: sunx6i: do not depend on reset controller framework
>>
>> The reset controller framework provides inline function stubs if
>> disabled.
>>
>> Signed-off-by: Philipp Zabel 
>>
>>
>>
>>
>>
>> As far as I see from drivers/dma/sun6i-dma.c,
>> the reset control is mandatory for this driver.
>>
>> Why are you removing the dependency?
>>
>>
>> Don't you care if it works on run-time
>> as long as it can build?
>
> I have not thought about this too hard, it's just there because the
> reset framework is not a build dependency (anymore). Some patches were
> necessary to remove dependency loops, but I think this one could just be
> dropped.


I have not taken a close look at it, but
if "dependency loops" is the reason for the change,
please mention it in the git-log.

I do not think we should remove the "depends on"
only for the reason "inline function stubs are already provided".



-- 
Best Regards
Masahiro Yamada

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Andrey Utkin  writes:

> On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
>> I wonder if the following fixes the problem (completely untested).
>
> I have given this a run, and it still hangs.

Does (only) adding the

pci_read_config_word(solo_dev->pdev, PCI_STATUS, );

in solo_reg_write() help?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Andrey Utkin  writes:

> On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
>> I wonder if the following fixes the problem (completely untested).
>
> I have given this a run, and it still hangs.

Does (only) adding the

pci_read_config_word(solo_dev->pdev, PCI_STATUS, );

in solo_reg_write() help?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

drivers/iio/pressure/bmp280-core.c:985: undefined reference to `devm_gpiod_get'

[kbuild test robot]

Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   08895a8b6b06ed2323cd97a36ee40a116b3db8ed
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   5 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `bgpio_map':
   drivers/gpio/gpio-mmio.c:571: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `dwapb_gpio_probe':
   drivers/gpio/gpio-dwapb.c:554: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `zx_gpio_probe':
   drivers/gpio/gpio-zx.c:229: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `xgene_mdio_probe':
   

drivers/iio/pressure/bmp280-core.c:985: undefined reference to `devm_gpiod_get'

[kbuild test robot]

Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   08895a8b6b06ed2323cd97a36ee40a116b3db8ed
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   5 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `bgpio_map':
   drivers/gpio/gpio-mmio.c:571: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `dwapb_gpio_probe':
   drivers/gpio/gpio-dwapb.c:554: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `zx_gpio_probe':
   drivers/gpio/gpio-zx.c:229: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `xgene_mdio_probe':
   

Re: [PATCH 0/2] NFS: Use complete() instead complete_all()

[Daniel Wagner]

Hi Anna,

On 09/23/2016 03:48 PM, Anna Schumaker wrote:

Besides trying to analys all the code paths to the wait_for_completion()
call and convince myself that there is only one waiter, I also run
a few tests:

 - some fio benchmarks
 - pynfs
  -cthon04


Thanks for the patches, and for the extensive testing!  I haven't
tried them with xfstests yet, but They look okay to me otherwise.
Assuming I don't see any new failures there I'll plan on adding them
for v4.9.


I tried a few tests from xfstests but I was not sure which make sense to 
run, that's why I went for the more NFS specific tests.


I'll see what happens when I run the generic tests from xfstests. Should 
all of them pass?


cheers,
daniel

Re: [PATCH 0/2] NFS: Use complete() instead complete_all()

[Daniel Wagner]

Hi Anna,

On 09/23/2016 03:48 PM, Anna Schumaker wrote:

Besides trying to analys all the code paths to the wait_for_completion()
call and convince myself that there is only one waiter, I also run
a few tests:

 - some fio benchmarks
 - pynfs
  -cthon04


Thanks for the patches, and for the extensive testing!  I haven't
tried them with xfstests yet, but They look okay to me otherwise.
Assuming I don't see any new failures there I'll plan on adding them
for v4.9.


I tried a few tests from xfstests but I was not sure which make sense to 
run, that's why I went for the more NFS specific tests.


I'll see what happens when I run the generic tests from xfstests. Should 
all of them pass?


cheers,
daniel

Re: [RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

[Viresh Kumar]

On 23-09-16, 15:07, Dave Gerlach wrote:
> The OPP framework allows each OPP to set a opp-supported-hw property
> which provides values that are matched against supported_hw values
> provided by the platform to limit support for certain OPPs on specific
> hardware. Currently, if the platform does not set supported_hw values,
> all OPPs are interpreted as supported, even if they have provided their
> own opp-supported-hw values.
> 
> If an OPP has provided opp-supported-hw, it is indicating that there is
> some specific hardware configuration it is supported by. These constraints
> should be honored, and if no supported_hw has been provided by the
> platform, there is no way to determine if that OPP is actually supported,
> so it should be marked as not supported.
> 
> Signed-off-by: Dave Gerlach 
> ---
>  drivers/base/power/opp/of.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
> index 1dfd3dd92624..af9f8968 100644
> --- a/drivers/base/power/opp/of.c
> +++ b/drivers/base/power/opp/of.c
> @@ -71,8 +71,18 @@ static bool _opp_is_supported(struct device *dev, struct 
> opp_table *opp_table,
>   u32 version;
>   int ret;
>  
> - if (!opp_table->supported_hw)
> - return true;
> + if (!opp_table->supported_hw) {
> + /*
> +  * In the case that no supported_hw has been set by the
> +  * platform but there is an opp-supported-hw value set for
> +  * an OPP then the OPP should not be enabled as there is
> +  * no way to see if the hardware supports it.
> +  */
> + if (of_find_property(np, "opp-supported-hw", NULL))
> + return false;
> + else
> + return true;
> + }
>  
>   while (count--) {
>   ret = of_property_read_u32_index(np, "opp-supported-hw", count,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

[Viresh Kumar]

On 23-09-16, 15:07, Dave Gerlach wrote:
> The OPP framework allows each OPP to set a opp-supported-hw property
> which provides values that are matched against supported_hw values
> provided by the platform to limit support for certain OPPs on specific
> hardware. Currently, if the platform does not set supported_hw values,
> all OPPs are interpreted as supported, even if they have provided their
> own opp-supported-hw values.
> 
> If an OPP has provided opp-supported-hw, it is indicating that there is
> some specific hardware configuration it is supported by. These constraints
> should be honored, and if no supported_hw has been provided by the
> platform, there is no way to determine if that OPP is actually supported,
> so it should be marked as not supported.
> 
> Signed-off-by: Dave Gerlach 
> ---
>  drivers/base/power/opp/of.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
> index 1dfd3dd92624..af9f8968 100644
> --- a/drivers/base/power/opp/of.c
> +++ b/drivers/base/power/opp/of.c
> @@ -71,8 +71,18 @@ static bool _opp_is_supported(struct device *dev, struct 
> opp_table *opp_table,
>   u32 version;
>   int ret;
>  
> - if (!opp_table->supported_hw)
> - return true;
> + if (!opp_table->supported_hw) {
> + /*
> +  * In the case that no supported_hw has been set by the
> +  * platform but there is an opp-supported-hw value set for
> +  * an OPP then the OPP should not be enabled as there is
> +  * no way to see if the hardware supports it.
> +  */
> + if (of_find_property(np, "opp-supported-hw", NULL))
> + return false;
> + else
> + return true;
> + }
>  
>   while (count--) {
>   ret = of_property_read_u32_index(np, "opp-supported-hw", count,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 09/12] x86/process: Pin the target stack in get_wchan()

[Tycho Andersen]

On Fri, Sep 23, 2016 at 08:34:43PM +0200, Jann Horn wrote:
> On Fri, Sep 23, 2016 at 11:28:26AM -0700, Kees Cook wrote:
> > Does CRIU use this? I wouldn't expect so, since they're using ptrace,
> > IIUC, to freeze/restore.
> 
> As far as I can tell:
> 
> parse_pid_stat() parses them into a struct proc_pid_stat as "esp" and "eip",
> but those struct members are never used (like, probably, most other members
> of that struct).

Yes, that's my reading of it too.

> child_opened_proc.c just opens /proc/%d/stat and then closes it again
> immediately.

This is just a test for ordering of things that are restored, and it
could use any file in /proc, stat was just convenient.

> So in summary: I don't think so.

Yep, agreed.

Tycho

Re: [PATCH 09/12] x86/process: Pin the target stack in get_wchan()

[Tycho Andersen]

On Fri, Sep 23, 2016 at 08:34:43PM +0200, Jann Horn wrote:
> On Fri, Sep 23, 2016 at 11:28:26AM -0700, Kees Cook wrote:
> > Does CRIU use this? I wouldn't expect so, since they're using ptrace,
> > IIUC, to freeze/restore.
> 
> As far as I can tell:
> 
> parse_pid_stat() parses them into a struct proc_pid_stat as "esp" and "eip",
> but those struct members are never used (like, probably, most other members
> of that struct).

Yes, that's my reading of it too.

> child_opened_proc.c just opens /proc/%d/stat and then closes it again
> immediately.

This is just a test for ordering of things that are restored, and it
could use any file in /proc, stat was just convenient.

> So in summary: I don't think so.

Yep, agreed.

Tycho

Re: [PATCH 2/2] PM / OPP: Multiple regulators aren't supported yet

[Viresh Kumar]

On 23-09-16, 14:59, Rob Herring wrote:
> On Wed, Sep 21, 2016 at 03:02:50PM +0530, Viresh Kumar wrote:
> > Multiple regulators per device aren't supported yet by the kernel code
> > and the bindings provided in documentation aren't sufficient to handle
> > that case (as there is no way for kernel code to link multiple
> > voltage/current values to a power supply).
> 
> What do you mean? Because the supplies are in the cpu node?

Not just that. For example if two supplies are present in CPU node like:
ABC-supply and XYZ-supply. And the values present in OPP node are like:

   opp00 {
   opp-hz = /bits/ 64 <17>;
/* ABC supplyXYZ
supply */
   opp-microvolt = <130 130 130>, <140 
140 140>;
   opp-microamp = <7>;
   clock-latency-ns = <30>;
   opp-suspend;
   };


Then the code can get regulators with those names (ABC and XYZ), but it can't
figure out which triplet in the "opp-microvolt" property belongs to which
supply.

I am working on some solution to that, but wanted to keep the entire series self
sufficient and so removing the leftovers first in this patch.

-- 
viresh

Re: [PATCH 2/2] PM / OPP: Multiple regulators aren't supported yet

[Viresh Kumar]

On 23-09-16, 14:59, Rob Herring wrote:
> On Wed, Sep 21, 2016 at 03:02:50PM +0530, Viresh Kumar wrote:
> > Multiple regulators per device aren't supported yet by the kernel code
> > and the bindings provided in documentation aren't sufficient to handle
> > that case (as there is no way for kernel code to link multiple
> > voltage/current values to a power supply).
> 
> What do you mean? Because the supplies are in the cpu node?

Not just that. For example if two supplies are present in CPU node like:
ABC-supply and XYZ-supply. And the values present in OPP node are like:

   opp00 {
   opp-hz = /bits/ 64 <17>;
/* ABC supplyXYZ
supply */
   opp-microvolt = <130 130 130>, <140 
140 140>;
   opp-microamp = <7>;
   clock-latency-ns = <30>;
   opp-suspend;
   };


Then the code can get regulators with those names (ABC and XYZ), but it can't
figure out which triplet in the "opp-microvolt" property belongs to which
supply.

I am working on some solution to that, but wanted to keep the entire series self
sufficient and so removing the leftovers first in this patch.

-- 
viresh

Re: [PATCH] phy: meson-usb2: Fix build dependency

[Kishon Vijay Abraham I]

On Wednesday 21 September 2016 09:43 AM, Axel Lin wrote:
> 2016-09-21 12:06 GMT+08:00 Kishon Vijay Abraham I :
>>
>>
>> On Monday 19 September 2016 10:14 PM, Kevin Hilman wrote:
>>> Martin Blumenstingl  writes:
>>>
 Hi Axel,

 On Fri, Sep 16, 2016 at 4:07 AM, Axel Lin  wrote:
> of_usb_get_dr_mode_by_phy will not be compiled if !USB_COMMON, fix below
> build error:
>
> drivers/built-in.o: In function `phy_meson_usb2_probe':
> debugfs.c:(.text+0x76b4): undefined reference to 
> `of_usb_get_dr_mode_by_phy'
> Makefile:961: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Axel Lin 
> ---
>  drivers/phy/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6ad87ec..cc27c12 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -458,6 +458,8 @@ config PHY_MESON_USB2
> tristate "Meson USB2 PHY driver"
> default ARCH_MESON
> depends on OF && (ARCH_MESON || COMPILE_TEST)
> +   depends on USB_SUPPORT
> +   select USB_COMMON
> select GENERIC_PHY
> help
>   Enable this to support the Meson USB2 PHYs found in Meson8b
> --
> 2.7.4
>
 thanks for this patch!

 How do we handle patches for drivers which will (unfortunately) not
 land in the linux 4.8 - should I integrate that into v3 of the patch
 (which I'll have to send anyways) or do we keep them separate?
 Maybe Kishon and/or Kevin can share their opinion on this.
>>
>> Since you are anyways planning to send v3, merge this patch too.
> 
> I got confused why this driver appears in linux-next but it's not from phy
> tree? I thought it's because other dependency so it needs to go via other 
> tree,
> but looks like not the case. And the driver does not get Kishon's Ack?
> 
> BTW, Kishon, do you consider to add phy tree to linux-next?

yes.. that's been pending for a long time.

-Kishon

Re: [PATCH] phy: meson-usb2: Fix build dependency

[Kishon Vijay Abraham I]

On Wednesday 21 September 2016 09:43 AM, Axel Lin wrote:
> 2016-09-21 12:06 GMT+08:00 Kishon Vijay Abraham I :
>>
>>
>> On Monday 19 September 2016 10:14 PM, Kevin Hilman wrote:
>>> Martin Blumenstingl  writes:
>>>
 Hi Axel,

 On Fri, Sep 16, 2016 at 4:07 AM, Axel Lin  wrote:
> of_usb_get_dr_mode_by_phy will not be compiled if !USB_COMMON, fix below
> build error:
>
> drivers/built-in.o: In function `phy_meson_usb2_probe':
> debugfs.c:(.text+0x76b4): undefined reference to 
> `of_usb_get_dr_mode_by_phy'
> Makefile:961: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Axel Lin 
> ---
>  drivers/phy/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6ad87ec..cc27c12 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -458,6 +458,8 @@ config PHY_MESON_USB2
> tristate "Meson USB2 PHY driver"
> default ARCH_MESON
> depends on OF && (ARCH_MESON || COMPILE_TEST)
> +   depends on USB_SUPPORT
> +   select USB_COMMON
> select GENERIC_PHY
> help
>   Enable this to support the Meson USB2 PHYs found in Meson8b
> --
> 2.7.4
>
 thanks for this patch!

 How do we handle patches for drivers which will (unfortunately) not
 land in the linux 4.8 - should I integrate that into v3 of the patch
 (which I'll have to send anyways) or do we keep them separate?
 Maybe Kishon and/or Kevin can share their opinion on this.
>>
>> Since you are anyways planning to send v3, merge this patch too.
> 
> I got confused why this driver appears in linux-next but it's not from phy
> tree? I thought it's because other dependency so it needs to go via other 
> tree,
> but looks like not the case. And the driver does not get Kishon's Ack?
> 
> BTW, Kishon, do you consider to add phy tree to linux-next?

yes.. that's been pending for a long time.

-Kishon

Re: [PATCH 1/2] PM / OPP: compatible is an optional property

[Viresh Kumar]

On 23-09-16, 14:55, Rob Herring wrote:
> On Fri, Sep 23, 2016 at 10:45:26AM +0530, Viresh Kumar wrote:
> > On 22-09-16, 12:24, Stephen Boyd wrote:
> > > On 09/21/2016 02:32 AM, Viresh Kumar wrote:
> > > > It was never compulsory to have a compatible string in the OPP table.
> > > > Fix the documentation to mark it optional.
> > > >
> 
> NAK.
> 
> > > > Also update its description a bit.
> > > >
> > > > Signed-off-by: Viresh Kumar 
> > > > ---
> > > 
> > > Why? I'd prefer the compatible string to be required so we know what
> > > sort of node it is.
> 
> Agreed.
> 
> > Okay, the code doesn't have any checks for it then and that needs to be 
> > fixed.
> 
> Why? The kernel is not a DT validator.

Hmm.. I thought it should be checking if it can parse those bindings or not.
What if someone adds compatible property as "foo" for OPP node? Should the OPP
code even try to parse it?

> > Just for my clarity, for platforms with special OPP bindings and so a 
> > different
> > compatible string like: "operating-points-v2-XYZ", should the compatible 
> > string
> > contain both "operating-points-v2" and the above one? It would be easier to
> > check for "operating-points-v2" in that case from core code.
> 
> That would imply operating-points-v2-XYZ has extra properties or is 
> different in some way. If an OS only understanding operating-points-v2 
> will work, then yes it should have both. If not, then no.

Well, in this case that can't be done fully, so we should have only the -xyz
one. Got it, thanks.

-- 
viresh

Re: [PATCH 1/2] PM / OPP: compatible is an optional property

[Viresh Kumar]

On 23-09-16, 14:55, Rob Herring wrote:
> On Fri, Sep 23, 2016 at 10:45:26AM +0530, Viresh Kumar wrote:
> > On 22-09-16, 12:24, Stephen Boyd wrote:
> > > On 09/21/2016 02:32 AM, Viresh Kumar wrote:
> > > > It was never compulsory to have a compatible string in the OPP table.
> > > > Fix the documentation to mark it optional.
> > > >
> 
> NAK.
> 
> > > > Also update its description a bit.
> > > >
> > > > Signed-off-by: Viresh Kumar 
> > > > ---
> > > 
> > > Why? I'd prefer the compatible string to be required so we know what
> > > sort of node it is.
> 
> Agreed.
> 
> > Okay, the code doesn't have any checks for it then and that needs to be 
> > fixed.
> 
> Why? The kernel is not a DT validator.

Hmm.. I thought it should be checking if it can parse those bindings or not.
What if someone adds compatible property as "foo" for OPP node? Should the OPP
code even try to parse it?

> > Just for my clarity, for platforms with special OPP bindings and so a 
> > different
> > compatible string like: "operating-points-v2-XYZ", should the compatible 
> > string
> > contain both "operating-points-v2" and the above one? It would be easier to
> > check for "operating-points-v2" in that case from core code.
> 
> That would imply operating-points-v2-XYZ has extra properties or is 
> different in some way. If an OS only understanding operating-points-v2 
> will work, then yes it should have both. If not, then no.

Well, in this case that can't be done fully, so we should have only the -xyz
one. Got it, thanks.

-- 
viresh

Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs

[Viresh Kumar]

On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > +  struct cpufreq_frequency_table *table,
> > > +  int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > +  true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> > 
> > I wouldn't prefer altering the opp tables from individual drivers at all. 
> > At the
> > least, it should be done via some helpers exposed by the core.
> > 
> > But before that I would like to hear from Stephen a bit as I recall he was 
> > also
> > working on something similar.
> > 
> 
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?

Perhaps yes, we should have a common place for doing all that.

> Does this need to modify
> anything besides the OPP the device is currently running at?

Finlye, can you please answer this ?

-- 
viresh

Re: [PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct

[Finn Thain]

On Sat, 24 Sep 2016, Ondrej Zary wrote:

> Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. Then 
> remove all code iterating the overrides[] array and reduce it to struct 
> card.

There is a reference to the compile-time override in 
Documentation/scsi/g_NCR5380.txt which needs to be removed also.

The patch looks fine aside from that.

-- 

Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs

[Viresh Kumar]

On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > +  struct cpufreq_frequency_table *table,
> > > +  int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > +  true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> > 
> > I wouldn't prefer altering the opp tables from individual drivers at all. 
> > At the
> > least, it should be done via some helpers exposed by the core.
> > 
> > But before that I would like to hear from Stephen a bit as I recall he was 
> > also
> > working on something similar.
> > 
> 
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?

Perhaps yes, we should have a common place for doing all that.

> Does this need to modify
> anything besides the OPP the device is currently running at?

Finlye, can you please answer this ?

-- 
viresh

Re: [PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct

[Finn Thain]

On Sat, 24 Sep 2016, Ondrej Zary wrote:

> Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. Then 
> remove all code iterating the overrides[] array and reduce it to struct 
> card.

There is a reference to the compile-time override in 
Documentation/scsi/g_NCR5380.txt which needs to be removed also.

The patch looks fine aside from that.

-- 

Re: [PATCH] cpufreq: st: add missing \n to end of dev_err message

[Viresh Kumar]

On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King 
> 
> Trival fix, dev_err message is missing a \n, so add it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/cpufreq/sti-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>  
>   reg_fields = sti_cpufreq_match();
>   if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
>   return -ENODEV;
>   }
>  

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: st: add missing \n to end of dev_err message

[Viresh Kumar]

On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King 
> 
> Trival fix, dev_err message is missing a \n, so add it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/cpufreq/sti-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>  
>   reg_fields = sti_cpufreq_match();
>   if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
>   return -ENODEV;
>   }
>  

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: kirkwood: add missing \n to end of dev_err messages

[Viresh Kumar]

On 25-09-16, 14:35, Colin King wrote:
> From: Colin Ian King 
> 
> Trival fix, dev_err messages are missing a \n, so add it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index be42f10..1b9bcd7 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -123,7 +123,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
>   if (IS_ERR(priv.cpu_clk)) {
> - dev_err(priv.dev, "Unable to get cpuclk");
> + dev_err(priv.dev, "Unable to get cpuclk\n");
>   return PTR_ERR(priv.cpu_clk);
>   }
>  
> @@ -132,7 +132,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");
>   if (IS_ERR(priv.ddr_clk)) {
> - dev_err(priv.dev, "Unable to get ddrclk");
> + dev_err(priv.dev, "Unable to get ddrclk\n");
>   err = PTR_ERR(priv.ddr_clk);
>   goto out_cpu;
>   }
> @@ -142,7 +142,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.powersave_clk = of_clk_get_by_name(np, "powersave");
>   if (IS_ERR(priv.powersave_clk)) {
> - dev_err(priv.dev, "Unable to get powersave");
> + dev_err(priv.dev, "Unable to get powersave\n");
>   err = PTR_ERR(priv.powersave_clk);
>   goto out_ddr;
>   }
> @@ -155,7 +155,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   if (!err)
>   return 0;
>  
> - dev_err(priv.dev, "Failed to register cpufreq driver");
> + dev_err(priv.dev, "Failed to register cpufreq driver\n");
>  
>   clk_disable_unprepare(priv.powersave_clk);
>  out_ddr:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: kirkwood: add missing \n to end of dev_err messages

[Viresh Kumar]

On 25-09-16, 14:35, Colin King wrote:
> From: Colin Ian King 
> 
> Trival fix, dev_err messages are missing a \n, so add it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index be42f10..1b9bcd7 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -123,7 +123,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
>   if (IS_ERR(priv.cpu_clk)) {
> - dev_err(priv.dev, "Unable to get cpuclk");
> + dev_err(priv.dev, "Unable to get cpuclk\n");
>   return PTR_ERR(priv.cpu_clk);
>   }
>  
> @@ -132,7 +132,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");
>   if (IS_ERR(priv.ddr_clk)) {
> - dev_err(priv.dev, "Unable to get ddrclk");
> + dev_err(priv.dev, "Unable to get ddrclk\n");
>   err = PTR_ERR(priv.ddr_clk);
>   goto out_cpu;
>   }
> @@ -142,7 +142,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   priv.powersave_clk = of_clk_get_by_name(np, "powersave");
>   if (IS_ERR(priv.powersave_clk)) {
> - dev_err(priv.dev, "Unable to get powersave");
> + dev_err(priv.dev, "Unable to get powersave\n");
>   err = PTR_ERR(priv.powersave_clk);
>   goto out_ddr;
>   }
> @@ -155,7 +155,7 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   if (!err)
>   return 0;
>  
> - dev_err(priv.dev, "Failed to register cpufreq driver");
> + dev_err(priv.dev, "Failed to register cpufreq driver\n");
>  
>   clk_disable_unprepare(priv.powersave_clk);
>  out_ddr:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] net: smc91x: take into account register shift

[David Miller]

From: Robert Jarzmik 
Date: Sun, 25 Sep 2016 23:00:45 +0200

> This aligns smc91x with its cousin, namely smc911x.c.
> This also allows the driver to run also in a device-tree based lubbock
> board build, on which it was tested.
> 
> Signed-off-by: Robert Jarzmik 

Applied to net-next, thanks.

Re: [PATCH] net: smc91x: take into account register shift

[David Miller]

From: Robert Jarzmik 
Date: Sun, 25 Sep 2016 23:00:45 +0200

> This aligns smc91x with its cousin, namely smc911x.c.
> This also allows the driver to run also in a device-tree based lubbock
> board build, on which it was tested.
> 
> Signed-off-by: Robert Jarzmik 

Applied to net-next, thanks.

Re: [PATCH][V2] cxgb4: fix -ve error check on a signed iq

[David Miller]

From: Colin King 
Date: Sun, 25 Sep 2016 14:14:45 -0700

> From: Colin Ian King 
> 
> iq is unsigned, so the error check for iq < 0 has no effect so errors
> can slip past this check.  Fix this by making iq signed and also
> get_filter_steerq return a signed int so a -ve error can be returned.
> 
> Signed-off-by: Colin Ian King 

Applied, thanks.

Re: [PATCH][V2] cxgb4: fix -ve error check on a signed iq

[David Miller]

From: Colin King 
Date: Sun, 25 Sep 2016 14:14:45 -0700

> From: Colin Ian King 
> 
> iq is unsigned, so the error check for iq < 0 has no effect so errors
> can slip past this check.  Fix this by making iq signed and also
> get_filter_steerq return a signed int so a -ve error can be returned.
> 
> Signed-off-by: Colin Ian King 

Applied, thanks.

[PATCH v2] Staging: android: fixed permissions style issue

[Eric Salem]

Fixed a coding style issue. Changed symbolic permissions to octal.

Signed-off-by: Eric Salem 
---
 drivers/staging/android/lowmemorykiller.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 80d7adf..ec3b665 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -204,10 +204,9 @@ device_initcall(lowmem_init);
  * not really modular, but the easiest way to keep compat with existing
  * bootargs behaviour is to continue using module_param here.
  */
-module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
-module_param_array_named(adj, lowmem_adj, short, _adj_size,
-S_IRUGO | S_IWUSR);
+module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
+module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
-S_IRUGO | S_IWUSR);
-module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR);
+0644);
+module_param_named(debug_level, lowmem_debug_level, uint, 0644);
 
-- 
2.7.4

On 09/25/2016 10:00 PM, Joe Perches wrote:
> On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote:
>> Fixed a coding style issue. Changed symbolic permissions to octal.
> 
> If you do these, please shorten the lines where possible.
> 
>> diff --git a/drivers/staging/android/lowmemorykiller.c 
>> b/drivers/staging/android/lowmemorykiller.c
> []
>> @@ -204,10 +204,10 @@ device_initcall(lowmem_init);
>>   * not really modular, but the easiest way to keep compat with existing
>>   * bootargs behaviour is to continue using module_param here.
>>   */
>> -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
>> +module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
>>  module_param_array_named(adj, lowmem_adj, short, _adj_size,
>> - S_IRUGO | S_IWUSR);
>> + 0644);
> 
> module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);
> 
> etc...
> 

[PATCH v2] Staging: android: fixed permissions style issue

[Eric Salem]

Fixed a coding style issue. Changed symbolic permissions to octal.

Signed-off-by: Eric Salem 
---
 drivers/staging/android/lowmemorykiller.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 80d7adf..ec3b665 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -204,10 +204,9 @@ device_initcall(lowmem_init);
  * not really modular, but the easiest way to keep compat with existing
  * bootargs behaviour is to continue using module_param here.
  */
-module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
-module_param_array_named(adj, lowmem_adj, short, _adj_size,
-S_IRUGO | S_IWUSR);
+module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
+module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
-S_IRUGO | S_IWUSR);
-module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR);
+0644);
+module_param_named(debug_level, lowmem_debug_level, uint, 0644);
 
-- 
2.7.4

On 09/25/2016 10:00 PM, Joe Perches wrote:
> On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote:
>> Fixed a coding style issue. Changed symbolic permissions to octal.
> 
> If you do these, please shorten the lines where possible.
> 
>> diff --git a/drivers/staging/android/lowmemorykiller.c 
>> b/drivers/staging/android/lowmemorykiller.c
> []
>> @@ -204,10 +204,10 @@ device_initcall(lowmem_init);
>>   * not really modular, but the easiest way to keep compat with existing
>>   * bootargs behaviour is to continue using module_param here.
>>   */
>> -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
>> +module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
>>  module_param_array_named(adj, lowmem_adj, short, _adj_size,
>> - S_IRUGO | S_IWUSR);
>> + 0644);
> 
> module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);
> 
> etc...
> 

Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[Peter Chen]

On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > > 
> > > > [1] 
> > > > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > 
> > > > Cc: MyungJoo Ham 
> > > > Cc: Chanwoo Choi 
> > > > Cc: 
> > > > Signed-off-by: Stephen Boyd 
> > > > ---
> > > > 
> > > > Should I make the extcon part optional? I could see a case where there 
> > > > are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an 
> > > > extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe 
> > > > of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux 
> > > > over
> > > > a port it can do so.
> > > 
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > > 
> > >   soc {
> > >   usb@78d9000 {
> > >   extcon = <_id>, <_id>;
> > 
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
> 
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.

I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <_idx> for both id and
vbus event.

-- 

Best Regards,
Peter Chen

Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[Peter Chen]

On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > > 
> > > > [1] 
> > > > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > 
> > > > Cc: MyungJoo Ham 
> > > > Cc: Chanwoo Choi 
> > > > Cc: 
> > > > Signed-off-by: Stephen Boyd 
> > > > ---
> > > > 
> > > > Should I make the extcon part optional? I could see a case where there 
> > > > are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an 
> > > > extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe 
> > > > of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux 
> > > > over
> > > > a port it can do so.
> > > 
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > > 
> > >   soc {
> > >   usb@78d9000 {
> > >   extcon = <_id>, <_id>;
> > 
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
> 
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.

I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <_idx> for both id and
vbus event.

-- 

Best Regards,
Peter Chen

Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c

[Finn Thain]

On Sat, 24 Sep 2016, Ondrej Zary wrote:

> Convert g_NCR5380 to use scsi_add_host instead of scsi_module.c
> Use pnp_driver and isa_driver to manage cards.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/g_NCR5380.c |  310 
> +-
>  drivers/scsi/g_NCR5380.h |8 --
>  2 files changed, 169 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 5162de6..6cf6b00 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -30,24 +30,25 @@
>  #include "NCR5380.h"
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
>  
> -static int ncr_irq;
> -static int ncr_dma;
> -static int ncr_addr;
> -static int ncr_5380;
> -static int ncr_53c400;
> -static int ncr_53c400a;
> -static int dtc_3181e;
> -static int hp_c2502;
> -
> -static struct card {
> - NCR5380_map_type NCR5380_map_name;
> - int irq;
> - int dma;
> - int board;  /* Use NCR53c400, Ricoh, etc. extensions ? */
> -} card;
> +#define MAX_CARDS 8
> +
> +static int irq[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(irq, int, NULL, 0);
> +MODULE_PARM_DESC(irq, "IRQ number(s)");
> +
> +static int base[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(base, int, NULL, 0);
> +MODULE_PARM_DESC(base, "base address(es)");
> +
> +static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };
> +module_param_array(card, int, NULL, 0);
> +MODULE_PARM_DESC(card, "card type (0=NCR5380, 1=NCR53C400, 2=NCR53C400A, 
> 3=DTC3181E, 4=HP C2502)");
> +
> +MODULE_LICENSE("GPL");


If you are going to change all of the module parameters and break every 
user's setup, at least explain what changed and why in the commit log and 
update the documentation in the kernel tree.

If you really want to help those users (most of whom gain nothing from 
this patch) you could also update the documentation elsewhere:

http://www.sane-project.org/man/sane-scsi.5.html
http://www.xsane.org/rauch-domain/sane-umax/sane-umax-config-doc.html
http://www.meier-geinitz.de/sane/mustek-backend/

I'm not in favour of this patch, but Christoph liked it so I'll leave it 
at that.

>  
>  #ifndef SCSI_G_NCR5380_MEM
>  /*
> @@ -73,17 +74,9 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
>  }
>  #endif
>  
> -/**
> - *   generic_NCR5380_detect  -   look for NCR5380 controllers
> - *   @tpnt: the scsi template
> - *
> - *   Scan for the present of NCR5380, NCR53C400, NCR53C400A, DTC3181E
> - *   and DTC436(ISAPnP) controllers.
> - *
> - *   Locks: none
> - */
> -
> -static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> +static struct Scsi_Host *generic_NCR5380_hw_init(
> + struct scsi_host_template *tpnt, struct device *pdev,
> + int base, int irq, int board)

This allocates and returns a Scsi_Host so the name is misleading.

But the name isn't the only problem; the real problem has already been 
pointed out by Christoph: the caller needs the error code to be returned 
not the Scsi_Host pointer.


>  {
>   unsigned int *ports;
>   u8 *magic = NULL;
> @@ -108,64 +101,13 @@ static int __init generic_NCR5380_detect(struct 
> scsi_host_template *tpnt)
>   struct Scsi_Host *instance;
>   struct NCR5380_hostdata *hostdata;
>  #ifdef SCSI_G_NCR5380_MEM
> - unsigned long base;
>   void __iomem *iomem;
>   resource_size_t iomem_size;
>  #endif
>  
> - if (ncr_irq)
> - card.irq = ncr_irq;
> - if (ncr_dma)
> - card.dma = ncr_dma;
> - if (ncr_addr)
> - card.NCR5380_map_name = (NCR5380_map_type) ncr_addr;
> - if (ncr_5380)
> - card.board = BOARD_NCR5380;
> - else if (ncr_53c400)
> - card.board = BOARD_NCR53C400;
> - else if (ncr_53c400a)
> - card.board = BOARD_NCR53C400A;
> - else if (dtc_3181e)
> - card.board = BOARD_DTC3181E;
> - else if (hp_c2502)
> - card.board = BOARD_HP_C2502;
> -#ifndef SCSI_G_NCR5380_MEM
> - if (isapnp_present()) {
> - struct pnp_dev *dev = NULL;
> - while ((dev = pnp_find_dev(NULL, ISAPNP_VENDOR('D', 'T', 'C'), 
> ISAPNP_FUNCTION(0x436e), dev))) {
> - if (pnp_device_attach(dev) < 0)
> - continue;
> - if (pnp_activate_dev(dev) < 0) {
> - printk(KERN_ERR "dtc436e probe: activate 
> failed\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (!pnp_port_valid(dev, 0)) {
> - printk(KERN_ERR "dtc436e probe: no valid 
> port\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (pnp_irq_valid(dev, 0))
> - 

Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c

[Finn Thain]

On Sat, 24 Sep 2016, Ondrej Zary wrote:

> Convert g_NCR5380 to use scsi_add_host instead of scsi_module.c
> Use pnp_driver and isa_driver to manage cards.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/g_NCR5380.c |  310 
> +-
>  drivers/scsi/g_NCR5380.h |8 --
>  2 files changed, 169 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 5162de6..6cf6b00 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -30,24 +30,25 @@
>  #include "NCR5380.h"
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
>  
> -static int ncr_irq;
> -static int ncr_dma;
> -static int ncr_addr;
> -static int ncr_5380;
> -static int ncr_53c400;
> -static int ncr_53c400a;
> -static int dtc_3181e;
> -static int hp_c2502;
> -
> -static struct card {
> - NCR5380_map_type NCR5380_map_name;
> - int irq;
> - int dma;
> - int board;  /* Use NCR53c400, Ricoh, etc. extensions ? */
> -} card;
> +#define MAX_CARDS 8
> +
> +static int irq[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(irq, int, NULL, 0);
> +MODULE_PARM_DESC(irq, "IRQ number(s)");
> +
> +static int base[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(base, int, NULL, 0);
> +MODULE_PARM_DESC(base, "base address(es)");
> +
> +static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };
> +module_param_array(card, int, NULL, 0);
> +MODULE_PARM_DESC(card, "card type (0=NCR5380, 1=NCR53C400, 2=NCR53C400A, 
> 3=DTC3181E, 4=HP C2502)");
> +
> +MODULE_LICENSE("GPL");


If you are going to change all of the module parameters and break every 
user's setup, at least explain what changed and why in the commit log and 
update the documentation in the kernel tree.

If you really want to help those users (most of whom gain nothing from 
this patch) you could also update the documentation elsewhere:

http://www.sane-project.org/man/sane-scsi.5.html
http://www.xsane.org/rauch-domain/sane-umax/sane-umax-config-doc.html
http://www.meier-geinitz.de/sane/mustek-backend/

I'm not in favour of this patch, but Christoph liked it so I'll leave it 
at that.

>  
>  #ifndef SCSI_G_NCR5380_MEM
>  /*
> @@ -73,17 +74,9 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
>  }
>  #endif
>  
> -/**
> - *   generic_NCR5380_detect  -   look for NCR5380 controllers
> - *   @tpnt: the scsi template
> - *
> - *   Scan for the present of NCR5380, NCR53C400, NCR53C400A, DTC3181E
> - *   and DTC436(ISAPnP) controllers.
> - *
> - *   Locks: none
> - */
> -
> -static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> +static struct Scsi_Host *generic_NCR5380_hw_init(
> + struct scsi_host_template *tpnt, struct device *pdev,
> + int base, int irq, int board)

This allocates and returns a Scsi_Host so the name is misleading.

But the name isn't the only problem; the real problem has already been 
pointed out by Christoph: the caller needs the error code to be returned 
not the Scsi_Host pointer.


>  {
>   unsigned int *ports;
>   u8 *magic = NULL;
> @@ -108,64 +101,13 @@ static int __init generic_NCR5380_detect(struct 
> scsi_host_template *tpnt)
>   struct Scsi_Host *instance;
>   struct NCR5380_hostdata *hostdata;
>  #ifdef SCSI_G_NCR5380_MEM
> - unsigned long base;
>   void __iomem *iomem;
>   resource_size_t iomem_size;
>  #endif
>  
> - if (ncr_irq)
> - card.irq = ncr_irq;
> - if (ncr_dma)
> - card.dma = ncr_dma;
> - if (ncr_addr)
> - card.NCR5380_map_name = (NCR5380_map_type) ncr_addr;
> - if (ncr_5380)
> - card.board = BOARD_NCR5380;
> - else if (ncr_53c400)
> - card.board = BOARD_NCR53C400;
> - else if (ncr_53c400a)
> - card.board = BOARD_NCR53C400A;
> - else if (dtc_3181e)
> - card.board = BOARD_DTC3181E;
> - else if (hp_c2502)
> - card.board = BOARD_HP_C2502;
> -#ifndef SCSI_G_NCR5380_MEM
> - if (isapnp_present()) {
> - struct pnp_dev *dev = NULL;
> - while ((dev = pnp_find_dev(NULL, ISAPNP_VENDOR('D', 'T', 'C'), 
> ISAPNP_FUNCTION(0x436e), dev))) {
> - if (pnp_device_attach(dev) < 0)
> - continue;
> - if (pnp_activate_dev(dev) < 0) {
> - printk(KERN_ERR "dtc436e probe: activate 
> failed\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (!pnp_port_valid(dev, 0)) {
> - printk(KERN_ERR "dtc436e probe: no valid 
> port\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (pnp_irq_valid(dev, 0))
> - card.irq = 

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Huang, Ying]

Shaohua Li  writes:

> On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote:
>> Rik van Riel  writes:
>> 
>> > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote:
>> >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
>> >> >.
>> >> > - It will help the memory fragmentation, especially when the THP is
>> >> > . heavily used by the applications.. The 2M continuous pages will
>> >> > be
>> >> > . free up after THP swapping out.
>> >> 
>> >> So this is impossible without THP swapin. While 2M swapout makes a
>> >> lot of
>> >> sense, I doubt 2M swapin is really useful. What kind of application
>> >> is
>> >> 'optimized' to do sequential memory access?
>> >
>> > I suspect a lot of this will depend on the ratio of storage
>> > speed to CPU & RAM speed.
>> >
>> > When swapping to a spinning disk, it makes sense to avoid
>> > extra memory use on swapin, and work in 4kB blocks.
>> 
>> For spinning disk, the THP swap optimization will be turned off in
>> current implementation.  Because huge swap cluster allocation based on
>> swap cluster management, which is available only for non-rotating block
>> devices (blk_queue_nonrot()).
>
> For 2m swapin, as long as one byte is changed in the 2m, next time we must do
> 2m swapout. There is huge waste of memory and IO bandwidth and increases
> unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD
> and makes IO the bottleneck. Not sure about NVRAM though.

One solution is to make 2M swapin configurable, maybe via a sysfs file
in /sys/kernel/mm/transparent_hugepage/, so that we can turn on it only
for really fast storage devices, such as NVRAM, etc.

Best Regards,
Huang, Ying

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Huang, Ying]

Shaohua Li  writes:

> On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote:
>> Rik van Riel  writes:
>> 
>> > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote:
>> >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
>> >> >.
>> >> > - It will help the memory fragmentation, especially when the THP is
>> >> > . heavily used by the applications.. The 2M continuous pages will
>> >> > be
>> >> > . free up after THP swapping out.
>> >> 
>> >> So this is impossible without THP swapin. While 2M swapout makes a
>> >> lot of
>> >> sense, I doubt 2M swapin is really useful. What kind of application
>> >> is
>> >> 'optimized' to do sequential memory access?
>> >
>> > I suspect a lot of this will depend on the ratio of storage
>> > speed to CPU & RAM speed.
>> >
>> > When swapping to a spinning disk, it makes sense to avoid
>> > extra memory use on swapin, and work in 4kB blocks.
>> 
>> For spinning disk, the THP swap optimization will be turned off in
>> current implementation.  Because huge swap cluster allocation based on
>> swap cluster management, which is available only for non-rotating block
>> devices (blk_queue_nonrot()).
>
> For 2m swapin, as long as one byte is changed in the 2m, next time we must do
> 2m swapout. There is huge waste of memory and IO bandwidth and increases
> unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD
> and makes IO the bottleneck. Not sure about NVRAM though.

One solution is to make 2M swapin configurable, maybe via a sysfs file
in /sys/kernel/mm/transparent_hugepage/, so that we can turn on it only
for really fast storage devices, such as NVRAM, etc.

Best Regards,
Huang, Ying

RE: [v12, 0/8] Fix eSDHC host version register bug

[Y.B. Lu]

Any comments about this version patchset ?

:)


> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
> 
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
>   - dts compatible method
>   - syscon method
>   - ifdef PPC method
>   - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
> 
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
> 
> Arnd Bergmann (1):
>   base: soc: introduce soc_device_match() interface
> 
> Yangbo Lu (7):
>   dt: bindings: update Freescale DCFG compatible
>   ARM64: dts: ls2080a: add device configuration node
>   dt: bindings: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   soc: fsl: add GUTS driver for QorIQ platforms
>   MAINTAINERS: add entry for Freescale SoC drivers
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> 
>  Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  MAINTAINERS|  11 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  arch/powerpc/sysdev/fsl_pci.c  |   2 +-
>  drivers/base/Kconfig   |   1 +
>  drivers/base/soc.c |  66 ++
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|  19 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 257
> +
>  include/linux/fsl/guts.h   | 125 ++
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  include/linux/sys_soc.h|   3 +
>  21 files changed, 478 insertions(+), 61 deletions(-)  rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig  create mode 100644
> drivers/soc/fsl/guts.c  rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
> 
> --
> 2.1.0.27.g96db324

RE: [v12, 0/8] Fix eSDHC host version register bug

[Y.B. Lu]

Any comments about this version patchset ?

:)


> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
> 
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
>   - dts compatible method
>   - syscon method
>   - ifdef PPC method
>   - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
> 
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
> 
> Arnd Bergmann (1):
>   base: soc: introduce soc_device_match() interface
> 
> Yangbo Lu (7):
>   dt: bindings: update Freescale DCFG compatible
>   ARM64: dts: ls2080a: add device configuration node
>   dt: bindings: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   soc: fsl: add GUTS driver for QorIQ platforms
>   MAINTAINERS: add entry for Freescale SoC drivers
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> 
>  Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  MAINTAINERS|  11 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  arch/powerpc/sysdev/fsl_pci.c  |   2 +-
>  drivers/base/Kconfig   |   1 +
>  drivers/base/soc.c |  66 ++
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|  19 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 257
> +
>  include/linux/fsl/guts.h   | 125 ++
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  include/linux/sys_soc.h|   3 +
>  21 files changed, 478 insertions(+), 61 deletions(-)  rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig  create mode 100644
> drivers/soc/fsl/guts.c  rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
> 
> --
> 2.1.0.27.g96db324

RE: [PATCH V1] regulator: pv88080: Update regulator for PV88080 BB silicon support

[Eric Hyeung Dong Jeong]

On September 25, 2016 3:23 AM, Mark Brown wrote:

> On Wed, Sep 21, 2016 at 01:44:39PM +0900, Eric Jeong wrote:
> 
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id pv88080_dt_ids[] = {
> > +   { .compatible = "pvs,pv88080-aa", .data = (void *)TYPE_PV88080_AA },
> > +   { .compatible = "pvs,pv88080-ba", .data = (void *)TYPE_PV88080_BA },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, pv88080_dt_ids); #endif
> 
> This doesn't list the old compatible string and therefore ends up breaking
> since the code defaults to assuming something it hasn't heard of is BB when
> it seems more likely that old DTs using the old compatible string will be for
> boards that also use the old silicon.  It would be much better practice to
> explicitly list the old compatible string and how we handle it, that won't 
> break
> in future and avoids this kind of error.
> 
> Is it really not possible to read the chip revision from the device using ID
> registers?  That'd be even better.

The address of ID register is different between each chip revision.
So, It is difficult to read the chip revision from the device using ID register.
And, I will send a patch with old compatible.

RE: [PATCH V1] regulator: pv88080: Update regulator for PV88080 BB silicon support

[Eric Hyeung Dong Jeong]

On September 25, 2016 3:23 AM, Mark Brown wrote:

> On Wed, Sep 21, 2016 at 01:44:39PM +0900, Eric Jeong wrote:
> 
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id pv88080_dt_ids[] = {
> > +   { .compatible = "pvs,pv88080-aa", .data = (void *)TYPE_PV88080_AA },
> > +   { .compatible = "pvs,pv88080-ba", .data = (void *)TYPE_PV88080_BA },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, pv88080_dt_ids); #endif
> 
> This doesn't list the old compatible string and therefore ends up breaking
> since the code defaults to assuming something it hasn't heard of is BB when
> it seems more likely that old DTs using the old compatible string will be for
> boards that also use the old silicon.  It would be much better practice to
> explicitly list the old compatible string and how we handle it, that won't 
> break
> in future and avoids this kind of error.
> 
> Is it really not possible to read the chip revision from the device using ID
> registers?  That'd be even better.

The address of ID register is different between each chip revision.
So, It is difficult to read the chip revision from the device using ID register.
And, I will send a patch with old compatible.

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Linus Torvalds]

On Sun, Sep 25, 2016 at 7:25 PM, Dave Chinner  wrote:
>> You have some nasty unicode corruption. The email is marked as being
>>
>>   Content-Type: text/plain; charset=UTF-8
>>   Content-Transfer-Encoding: 8bit
>
> It's whatever git-send-email spat out. I was under the impression it
> encodes like that whenever it sees a utf-8 character in a commit...

Yes. But it assumes that the commit text was in UTF-8 too. So I
suspect it happened as you were writing the commit message:

> I turned off utf-8 support in vim on the machine I write all my code
> on

I guess that's probably it. You probably had vim try to convert it to
latin1 or something, and the odd utf-8 tick/back-tick thing doesn't do
so cleanly, so..

>- I got sick of stupid stray marks in my code, digraphs being
> composed when I just want to replace a single character, git sending
> patches in utf-8 encoding because I copied a SoB with a utf-8
> character in the name, etc

Hmm. Generally, the only place we should have non-us-ascii tensd to be
exactly those names. But a sane editor should "just work" and not do
odd crazy digraph crap or things like that. But I don't use vim, so I
don't know what the magic incantation for sanity there is.

> 7 characters, 12 characters, whatever. Neither make any sense in
> commit messages by themselves without the short description that
> goes along with the hash.

No, I agree, the right format for describing a commit tends to be
along the lines of

  .. commit %h ("%s") ..

exactly like you did.  It's just that with 12 characters in the hex
format, people will still be able to cut-and-paste the hash into git
to get the full commit details even a year from now. With just 7 hex
digits, you may well end up in the situation where you do

git show e23d415

and git says

error: short SHA1 e23d415 is ambiguous.
fatal: ambiguous argument 'e23d415': unknown revision or path not
in the working tree.

(it's not ambiguous today, but in a year or two it quite possibly will be).

It's not impossible to figure out the different possible ambiguous
commits, but it's just inconvenient.

Right now, of the roughly 618,000 commits in the mainline tree, about
98% can be uniquely represented with 7 hex digits. But about 2% o
commits need eight or more hex digits to be unique (the git ID space
includes all the tree and blob objects too, so the uniqueness is not
just "unique within commits", but any kernel git object).

Linus

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Linus Torvalds]

On Sun, Sep 25, 2016 at 7:25 PM, Dave Chinner  wrote:
>> You have some nasty unicode corruption. The email is marked as being
>>
>>   Content-Type: text/plain; charset=UTF-8
>>   Content-Transfer-Encoding: 8bit
>
> It's whatever git-send-email spat out. I was under the impression it
> encodes like that whenever it sees a utf-8 character in a commit...

Yes. But it assumes that the commit text was in UTF-8 too. So I
suspect it happened as you were writing the commit message:

> I turned off utf-8 support in vim on the machine I write all my code
> on

I guess that's probably it. You probably had vim try to convert it to
latin1 or something, and the odd utf-8 tick/back-tick thing doesn't do
so cleanly, so..

>- I got sick of stupid stray marks in my code, digraphs being
> composed when I just want to replace a single character, git sending
> patches in utf-8 encoding because I copied a SoB with a utf-8
> character in the name, etc

Hmm. Generally, the only place we should have non-us-ascii tensd to be
exactly those names. But a sane editor should "just work" and not do
odd crazy digraph crap or things like that. But I don't use vim, so I
don't know what the magic incantation for sanity there is.

> 7 characters, 12 characters, whatever. Neither make any sense in
> commit messages by themselves without the short description that
> goes along with the hash.

No, I agree, the right format for describing a commit tends to be
along the lines of

  .. commit %h ("%s") ..

exactly like you did.  It's just that with 12 characters in the hex
format, people will still be able to cut-and-paste the hash into git
to get the full commit details even a year from now. With just 7 hex
digits, you may well end up in the situation where you do

git show e23d415

and git says

error: short SHA1 e23d415 is ambiguous.
fatal: ambiguous argument 'e23d415': unknown revision or path not
in the working tree.

(it's not ambiguous today, but in a year or two it quite possibly will be).

It's not impossible to figure out the different possible ambiguous
commits, but it's just inconvenient.

Right now, of the roughly 618,000 commits in the mainline tree, about
98% can be uniquely represented with 7 hex digits. But about 2% o
commits need eight or more hex digits to be unique (the git ID space
includes all the tree and blob objects too, so the uniqueness is not
just "unique within commits", but any kernel git object).

Linus

Re: [PATCH] Staging: android: fixed permissions style issue

[Joe Perches]

On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote:
> Fixed a coding style issue. Changed symbolic permissions to octal.

If you do these, please shorten the lines where possible.

> diff --git a/drivers/staging/android/lowmemorykiller.c 
> b/drivers/staging/android/lowmemorykiller.c
[]
> @@ -204,10 +204,10 @@ device_initcall(lowmem_init);
>   * not really modular, but the easiest way to keep compat with existing
>   * bootargs behaviour is to continue using module_param here.
>   */
> -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
> +module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
>  module_param_array_named(adj, lowmem_adj, short, _adj_size,
> -  S_IRUGO | S_IWUSR);
> +  0644);

module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);

etc...

Re: [PATCH] Staging: android: fixed permissions style issue

[Joe Perches]

On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote:
> Fixed a coding style issue. Changed symbolic permissions to octal.

If you do these, please shorten the lines where possible.

> diff --git a/drivers/staging/android/lowmemorykiller.c 
> b/drivers/staging/android/lowmemorykiller.c
[]
> @@ -204,10 +204,10 @@ device_initcall(lowmem_init);
>   * not really modular, but the easiest way to keep compat with existing
>   * bootargs behaviour is to continue using module_param here.
>   */
> -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
> +module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
>  module_param_array_named(adj, lowmem_adj, short, _adj_size,
> -  S_IRUGO | S_IWUSR);
> +  0644);

module_param_array_named(adj, lowmem_adj, short, _adj_size, 0644);

etc...

[PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

[Ioan-Adrian Ratiu]

This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
because the "fix" is bogus. That report descriptor is different in
hardware (see below) and it's the way the hardware works, it can't be
fixed at this level because it reuses axes by design.

What this change tried to fix is a regression caused by commit 20aef664f139
("HID: input: force generic axis to be mapped to their user space axis") by
working around the problem and trying to change the report descriptor in
hid-dr, which obviously can't work and introduces more breakage because it
adds another unnecessary layer of multiplexing/indirection, making the
dragonrise gamepad practically unusable in userspace.

This needs to be fixed where the regression was initially introduced in
hid-input (the next patch does this).

Here's the descriptor taken directly from the device via lsusb:
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 101
  Report Descriptor: (length is 101)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x04 ] 4
Joystick
Item(Main  ): Collection, data= [ 0x01 ] 1
Application
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x05 ] 5
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x35 ] 53
Rotate-Z
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Report Size, data= [ 0x04 ] 4
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Global): Logical Maximum, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
Item(Global): Unit, data= [ 0x14 ] 20
System: English Rotation, Unit: Degrees
Item(Local ): Usage, data= [ 0x39 ] 57
Hat Switch
Item(Main  ): Input, data= [ 0x42 ] 66
Data Variable Absolute No_Wrap Linear
Preferred_State Null_State Non_Volatile Bitfield
Item(Global): Unit, data= [ 0x00 ] 0
System: None, Unit: (None)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x0c ] 12
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Global): Usage Page, data= [ 0x09 ] 9
Buttons
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
Button 1 (Primary)
Item(Local ): Usage Maximum, data= [ 0x0c ] 12
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Main  ): End Collection, data=none
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 

[PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

[Ioan-Adrian Ratiu]

Commit 79346d620e9d ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.

Now the result is that different device axes appear on a single axis in
userspace, which is clearly a regression in the hid-input driver because it
needs to continue to handle this hardware as expected before the forcing
to provide the same interface to userspace.

Since these lower-end gamepads like 0079:0006 are definitely the exception,
create a quirk to fix them.

Signed-off-by: Ioan-Adrian Ratiu 
---
 drivers/hid/hid-dr.c|  2 ++
 drivers/hid/hid-input.c | 16 +++-
 include/linux/hid.h |  1 +
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/hid-dr.c b/drivers/hid/hid-dr.c
index 2523f8a..27fc826 100644
--- a/drivers/hid/hid-dr.c
+++ b/drivers/hid/hid-dr.c
@@ -274,6 +274,8 @@ static int dr_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
hid_hw_stop(hdev);
goto err;
}
+   /* has only 5 axes and reuses X, Y */
+   hdev->quirks |= HID_QUIRK_REUSE_AXES;
break;
}
 
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index fb9ace1..1cc6fe4 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -633,11 +633,17 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
/* These usage IDs map directly to the usage codes. */
case HID_GD_X: case HID_GD_Y: case HID_GD_Z:
case HID_GD_RX: case HID_GD_RY: case HID_GD_RZ:
-   if (field->flags & HID_MAIN_ITEM_RELATIVE)
-   map_rel(usage->hid & 0xf);
-   else
-   map_abs_clear(usage->hid & 0xf);
-   break;
+
+   /* if quirk is active don't force the userspace mapping,
+* instead search and use the next available axis.
+*/
+   if (!(device->quirks & HID_QUIRK_REUSE_AXES)) {
+   if (field->flags & HID_MAIN_ITEM_RELATIVE)
+   map_rel(usage->hid & 0xf);
+   else
+   map_abs_clear(usage->hid & 0xf);
+   break;
+   }
 
case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 75b66ec..0979920 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -320,6 +320,7 @@ struct hid_item {
 #define HID_QUIRK_NO_EMPTY_INPUT   0x0100
 #define HID_QUIRK_NO_INIT_INPUT_REPORTS0x0200
 #define HID_QUIRK_ALWAYS_POLL  0x0400
+#define HID_QUIRK_REUSE_AXES   0x0800
 #define HID_QUIRK_SKIP_OUTPUT_REPORTS  0x0001
 #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID0x0002
 #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x0004
-- 
2.10.0

[PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

[Ioan-Adrian Ratiu]

This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
because the "fix" is bogus. That report descriptor is different in
hardware (see below) and it's the way the hardware works, it can't be
fixed at this level because it reuses axes by design.

What this change tried to fix is a regression caused by commit 20aef664f139
("HID: input: force generic axis to be mapped to their user space axis") by
working around the problem and trying to change the report descriptor in
hid-dr, which obviously can't work and introduces more breakage because it
adds another unnecessary layer of multiplexing/indirection, making the
dragonrise gamepad practically unusable in userspace.

This needs to be fixed where the regression was initially introduced in
hid-input (the next patch does this).

Here's the descriptor taken directly from the device via lsusb:
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 101
  Report Descriptor: (length is 101)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x04 ] 4
Joystick
Item(Main  ): Collection, data= [ 0x01 ] 1
Application
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x05 ] 5
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x35 ] 53
Rotate-Z
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Report Size, data= [ 0x04 ] 4
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Global): Logical Maximum, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
Item(Global): Unit, data= [ 0x14 ] 20
System: English Rotation, Unit: Degrees
Item(Local ): Usage, data= [ 0x39 ] 57
Hat Switch
Item(Main  ): Input, data= [ 0x42 ] 66
Data Variable Absolute No_Wrap Linear
Preferred_State Null_State Non_Volatile Bitfield
Item(Global): Unit, data= [ 0x00 ] 0
System: None, Unit: (None)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x0c ] 12
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Global): Usage Page, data= [ 0x09 ] 9
Buttons
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
Button 1 (Primary)
Item(Local ): Usage Maximum, data= [ 0x0c ] 12
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Main  ): End Collection, data=none
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 

[PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

[Ioan-Adrian Ratiu]

Commit 79346d620e9d ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.

Now the result is that different device axes appear on a single axis in
userspace, which is clearly a regression in the hid-input driver because it
needs to continue to handle this hardware as expected before the forcing
to provide the same interface to userspace.

Since these lower-end gamepads like 0079:0006 are definitely the exception,
create a quirk to fix them.

Signed-off-by: Ioan-Adrian Ratiu 
---
 drivers/hid/hid-dr.c|  2 ++
 drivers/hid/hid-input.c | 16 +++-
 include/linux/hid.h |  1 +
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/hid-dr.c b/drivers/hid/hid-dr.c
index 2523f8a..27fc826 100644
--- a/drivers/hid/hid-dr.c
+++ b/drivers/hid/hid-dr.c
@@ -274,6 +274,8 @@ static int dr_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
hid_hw_stop(hdev);
goto err;
}
+   /* has only 5 axes and reuses X, Y */
+   hdev->quirks |= HID_QUIRK_REUSE_AXES;
break;
}
 
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index fb9ace1..1cc6fe4 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -633,11 +633,17 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
/* These usage IDs map directly to the usage codes. */
case HID_GD_X: case HID_GD_Y: case HID_GD_Z:
case HID_GD_RX: case HID_GD_RY: case HID_GD_RZ:
-   if (field->flags & HID_MAIN_ITEM_RELATIVE)
-   map_rel(usage->hid & 0xf);
-   else
-   map_abs_clear(usage->hid & 0xf);
-   break;
+
+   /* if quirk is active don't force the userspace mapping,
+* instead search and use the next available axis.
+*/
+   if (!(device->quirks & HID_QUIRK_REUSE_AXES)) {
+   if (field->flags & HID_MAIN_ITEM_RELATIVE)
+   map_rel(usage->hid & 0xf);
+   else
+   map_abs_clear(usage->hid & 0xf);
+   break;
+   }
 
case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 75b66ec..0979920 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -320,6 +320,7 @@ struct hid_item {
 #define HID_QUIRK_NO_EMPTY_INPUT   0x0100
 #define HID_QUIRK_NO_INIT_INPUT_REPORTS0x0200
 #define HID_QUIRK_ALWAYS_POLL  0x0400
+#define HID_QUIRK_REUSE_AXES   0x0800
 #define HID_QUIRK_SKIP_OUTPUT_REPORTS  0x0001
 #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID0x0002
 #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x0004
-- 
2.10.0

Re: [PATCH v2 1/1] mm/hugetlb: fix memory offline with hugepage size > memory block size

[Rui Teng]

On 9/23/16 7:03 PM, Gerald Schaefer wrote:

On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng  wrote:


On 9/22/16 5:51 PM, Michal Hocko wrote:

On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:

dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb page
with a size > memory block size.

When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
will trigger directly. In the other case we will run into an addressing
exception later, because dissolve_free_huge_page() will not work on the
head page of the compound hugetlb page which will result in a NULL
hstate from page_hstate().

To fix this, first remove the VM_BUG_ON() because it is wrong, and then
use the compound head page in dissolve_free_huge_page().


OK so dissolve_free_huge_page will work also on tail pages now which
makes some sense. I would appreciate also few words why do we want to
sacrifice something as precious as gigantic page rather than fail the
page block offline. Dave pointed out dim offline usecase for example.


Also change locking in dissolve_free_huge_page(), so that it only takes
the lock when actually removing a hugepage.


From a quick look it seems this has been broken since introduced by
c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
hugepage"). Do we want to have this backported to stable? In any way
Fixes: SHA1 would be really nice.



If the huge page hot-plug function was introduced by c8721bbbdd36, and
it has already indicated that the gigantic page is not supported:

"As for larger hugepages (1GB for x86_64), it's not easy to do
hotremove over them because it's larger than memory block.  So
we now simply leave it to fail as it is."

Is it possible that the gigantic page hot-plugin has never been
supported?


Offlining blocks with gigantic pages only fails when they are in-use,
I guess that was meant by the description. Maybe it was also meant to
fail in any case, but that was not was the patch did.

With free gigantic pages, it looks like it only ever worked when
offlining the first block of a gigantic page. And as long as you only
have gigantic pages, the VM_BUG_ON() would actually have triggered on
every block that is not gigantic-page-aligned, even if the block is not
part of any gigantic page at all.


I have not met the VM_BUG_ON() issue on my powerpc architecture. Seems
it does not always have the align issue on other architectures.



Given the age of the patch it is a little bit surprising that it never
struck anyone, and that we now have found it on two architectures at
once :-)



I made another patch for this problem, and also tried to apply the
first version of this patch on my system too. But they only postpone
the error happened. The HugePages_Free will be changed from 2 to 1, if I
offline a huge page. I think it does not have a correct roll back.

# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:   2
HugePages_Free:1
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   16777216 kB


HugePages_Free is supposed to be reduced when offlining a block, but
then HugePages_Total should also be reduced, so that is strange. On my
system both were reduced. Does this happen with any version of my patch?


No, I only tested your first version. I do not have any question on
your patch, because the error was not introduced by your patch.



What do you mean with postpone the error? Can you reproduce the BUG_ON
or the addressing exception with my patch?


I mean the gigantic offlining function does not work at all on my
environment, even if the correct head page has been found. My method is
to filter all the tail pages out, and your method is to find head page
from tail pages.

Since you can offline gigantic page successful, I think such function
is supported now. I will debug the problem on my environment.





I will make more test on it, but can any one confirm that this function
has been implemented and tested before?

Re: [PATCH v2 1/1] mm/hugetlb: fix memory offline with hugepage size > memory block size

[Rui Teng]

On 9/23/16 7:03 PM, Gerald Schaefer wrote:

On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng  wrote:


On 9/22/16 5:51 PM, Michal Hocko wrote:

On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:

dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb page
with a size > memory block size.

When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
will trigger directly. In the other case we will run into an addressing
exception later, because dissolve_free_huge_page() will not work on the
head page of the compound hugetlb page which will result in a NULL
hstate from page_hstate().

To fix this, first remove the VM_BUG_ON() because it is wrong, and then
use the compound head page in dissolve_free_huge_page().


OK so dissolve_free_huge_page will work also on tail pages now which
makes some sense. I would appreciate also few words why do we want to
sacrifice something as precious as gigantic page rather than fail the
page block offline. Dave pointed out dim offline usecase for example.


Also change locking in dissolve_free_huge_page(), so that it only takes
the lock when actually removing a hugepage.


From a quick look it seems this has been broken since introduced by
c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
hugepage"). Do we want to have this backported to stable? In any way
Fixes: SHA1 would be really nice.



If the huge page hot-plug function was introduced by c8721bbbdd36, and
it has already indicated that the gigantic page is not supported:

"As for larger hugepages (1GB for x86_64), it's not easy to do
hotremove over them because it's larger than memory block.  So
we now simply leave it to fail as it is."

Is it possible that the gigantic page hot-plugin has never been
supported?


Offlining blocks with gigantic pages only fails when they are in-use,
I guess that was meant by the description. Maybe it was also meant to
fail in any case, but that was not was the patch did.

With free gigantic pages, it looks like it only ever worked when
offlining the first block of a gigantic page. And as long as you only
have gigantic pages, the VM_BUG_ON() would actually have triggered on
every block that is not gigantic-page-aligned, even if the block is not
part of any gigantic page at all.


I have not met the VM_BUG_ON() issue on my powerpc architecture. Seems
it does not always have the align issue on other architectures.



Given the age of the patch it is a little bit surprising that it never
struck anyone, and that we now have found it on two architectures at
once :-)



I made another patch for this problem, and also tried to apply the
first version of this patch on my system too. But they only postpone
the error happened. The HugePages_Free will be changed from 2 to 1, if I
offline a huge page. I think it does not have a correct roll back.

# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:   2
HugePages_Free:1
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   16777216 kB


HugePages_Free is supposed to be reduced when offlining a block, but
then HugePages_Total should also be reduced, so that is strange. On my
system both were reduced. Does this happen with any version of my patch?


No, I only tested your first version. I do not have any question on
your patch, because the error was not introduced by your patch.



What do you mean with postpone the error? Can you reproduce the BUG_ON
or the addressing exception with my patch?


I mean the gigantic offlining function does not work at all on my
environment, even if the correct head page has been found. My method is
to filter all the tail pages out, and your method is to find head page
from tail pages.

Since you can offline gigantic page successful, I think such function
is supported now. I will debug the problem on my environment.





I will make more test on it, but can any one confirm that this function
has been implemented and tested before?

[PATCH] Staging: android: fixed permissions style issue

[Eric Salem]

Fixed a coding style issue. Changed symbolic permissions to octal.

Signed-off-by: Eric Salem 
---
 drivers/staging/android/lowmemorykiller.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 80d7adf..553a3ee 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -204,10 +204,10 @@ device_initcall(lowmem_init);
  * not really modular, but the easiest way to keep compat with existing
  * bootargs behaviour is to continue using module_param here.
  */
-module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
+module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
 module_param_array_named(adj, lowmem_adj, short, _adj_size,
-S_IRUGO | S_IWUSR);
+0644);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
-S_IRUGO | S_IWUSR);
-module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR);
+0644);
+module_param_named(debug_level, lowmem_debug_level, uint, 0644);
 
-- 
2.7.4

[PATCH] Staging: android: fixed permissions style issue

[Eric Salem]

Fixed a coding style issue. Changed symbolic permissions to octal.

Signed-off-by: Eric Salem 
---
 drivers/staging/android/lowmemorykiller.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 80d7adf..553a3ee 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -204,10 +204,10 @@ device_initcall(lowmem_init);
  * not really modular, but the easiest way to keep compat with existing
  * bootargs behaviour is to continue using module_param here.
  */
-module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
+module_param_named(cost, lowmem_shrinker.seeks, int, 0644);
 module_param_array_named(adj, lowmem_adj, short, _adj_size,
-S_IRUGO | S_IWUSR);
+0644);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
-S_IRUGO | S_IWUSR);
-module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR);
+0644);
+module_param_named(debug_level, lowmem_debug_level, uint, 0644);
 
-- 
2.7.4

[PATCH] sched: Change READ_ONCE(jiffies) into jiffies

[Bart Van Assche]

A quote from Documentation/memory_barriers.txt:

For example, because 'jiffies' is marked volatile, it is never
necessary to say READ_ONCE(jiffies).  The reason for this is
that READ_ONCE() and WRITE_ONCE() are implemented as volatile
casts, which has no effect when its argument is already marked
volatile.

Hence change all 'READ_ONCE(jiffies)' occurrences into 'jiffies'.

Signed-off-by: Bart Van Assche 
Cc: Peter Zijlstra 
Cc: Oleg Nesterov 
---
 kernel/sched/core.c| 2 +-
 kernel/sched/cputime.c | 4 ++--
 kernel/sched/fair.c| 8 
 kernel/sched/wait.c| 6 --
 4 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..edb811e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3100,7 +3100,7 @@ void scheduler_tick(void)
 u64 scheduler_tick_max_deferment(void)
 {
struct rq *rq = this_rq();
-   unsigned long next, now = READ_ONCE(jiffies);
+   unsigned long next, now = jiffies;
 
next = rq->last_sched_tick + HZ;
 
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index a846cf8..9aecaad 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -691,7 +691,7 @@ void thread_group_cputime_adjusted(struct task_struct *p, 
cputime_t *ut, cputime
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
 static cputime_t vtime_delta(struct task_struct *tsk)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
 
if (time_before(now, (unsigned long)tsk->vtime_snap))
return 0;
@@ -701,7 +701,7 @@ static cputime_t vtime_delta(struct task_struct *tsk)
 
 static cputime_t get_vtime_delta(struct task_struct *tsk)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
cputime_t delta, other;
 
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 039de34..db5ae54 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4802,7 +4802,7 @@ static void cpu_load_update_idle(struct rq *this_rq)
if (weighted_cpuload(cpu_of(this_rq)))
return;
 
-   cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0);
+   cpu_load_update_nohz(this_rq, jiffies, 0);
 }
 
 /*
@@ -4828,7 +4828,7 @@ void cpu_load_update_nohz_start(void)
  */
 void cpu_load_update_nohz_stop(void)
 {
-   unsigned long curr_jiffies = READ_ONCE(jiffies);
+   unsigned long curr_jiffies = jiffies;
struct rq *this_rq = this_rq();
unsigned long load;
 
@@ -4851,7 +4851,7 @@ static void cpu_load_update_periodic(struct rq *this_rq, 
unsigned long load)
 {
 #ifdef CONFIG_NO_HZ_COMMON
/* See the mess around cpu_load_update_nohz(). */
-   this_rq->last_load_update_tick = READ_ONCE(jiffies);
+   this_rq->last_load_update_tick = jiffies;
 #endif
cpu_load_update(this_rq, load, 1);
 }
@@ -4864,7 +4864,7 @@ void cpu_load_update_active(struct rq *this_rq)
unsigned long load = weighted_cpuload(cpu_of(this_rq));
 
if (tick_nohz_tick_stopped())
-   cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
+   cpu_load_update_nohz(this_rq, jiffies, load);
else
cpu_load_update_periodic(this_rq, load);
 }
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index f15d6b6..af4959d 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -601,7 +601,8 @@ EXPORT_SYMBOL(bit_wait_io);
 
 __sched int bit_wait_timeout(struct wait_bit_key *word, int mode)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
schedule_timeout(word->timeout - now);
@@ -613,7 +614,8 @@ EXPORT_SYMBOL_GPL(bit_wait_timeout);
 
 __sched int bit_wait_io_timeout(struct wait_bit_key *word, int mode)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
io_schedule_timeout(word->timeout - now);
-- 
2.10.0

[PATCH] sched: Change READ_ONCE(jiffies) into jiffies

[Bart Van Assche]

A quote from Documentation/memory_barriers.txt:

For example, because 'jiffies' is marked volatile, it is never
necessary to say READ_ONCE(jiffies).  The reason for this is
that READ_ONCE() and WRITE_ONCE() are implemented as volatile
casts, which has no effect when its argument is already marked
volatile.

Hence change all 'READ_ONCE(jiffies)' occurrences into 'jiffies'.

Signed-off-by: Bart Van Assche 
Cc: Peter Zijlstra 
Cc: Oleg Nesterov 
---
 kernel/sched/core.c| 2 +-
 kernel/sched/cputime.c | 4 ++--
 kernel/sched/fair.c| 8 
 kernel/sched/wait.c| 6 --
 4 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..edb811e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3100,7 +3100,7 @@ void scheduler_tick(void)
 u64 scheduler_tick_max_deferment(void)
 {
struct rq *rq = this_rq();
-   unsigned long next, now = READ_ONCE(jiffies);
+   unsigned long next, now = jiffies;
 
next = rq->last_sched_tick + HZ;
 
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index a846cf8..9aecaad 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -691,7 +691,7 @@ void thread_group_cputime_adjusted(struct task_struct *p, 
cputime_t *ut, cputime
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
 static cputime_t vtime_delta(struct task_struct *tsk)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
 
if (time_before(now, (unsigned long)tsk->vtime_snap))
return 0;
@@ -701,7 +701,7 @@ static cputime_t vtime_delta(struct task_struct *tsk)
 
 static cputime_t get_vtime_delta(struct task_struct *tsk)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
cputime_t delta, other;
 
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 039de34..db5ae54 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4802,7 +4802,7 @@ static void cpu_load_update_idle(struct rq *this_rq)
if (weighted_cpuload(cpu_of(this_rq)))
return;
 
-   cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0);
+   cpu_load_update_nohz(this_rq, jiffies, 0);
 }
 
 /*
@@ -4828,7 +4828,7 @@ void cpu_load_update_nohz_start(void)
  */
 void cpu_load_update_nohz_stop(void)
 {
-   unsigned long curr_jiffies = READ_ONCE(jiffies);
+   unsigned long curr_jiffies = jiffies;
struct rq *this_rq = this_rq();
unsigned long load;
 
@@ -4851,7 +4851,7 @@ static void cpu_load_update_periodic(struct rq *this_rq, 
unsigned long load)
 {
 #ifdef CONFIG_NO_HZ_COMMON
/* See the mess around cpu_load_update_nohz(). */
-   this_rq->last_load_update_tick = READ_ONCE(jiffies);
+   this_rq->last_load_update_tick = jiffies;
 #endif
cpu_load_update(this_rq, load, 1);
 }
@@ -4864,7 +4864,7 @@ void cpu_load_update_active(struct rq *this_rq)
unsigned long load = weighted_cpuload(cpu_of(this_rq));
 
if (tick_nohz_tick_stopped())
-   cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
+   cpu_load_update_nohz(this_rq, jiffies, load);
else
cpu_load_update_periodic(this_rq, load);
 }
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index f15d6b6..af4959d 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -601,7 +601,8 @@ EXPORT_SYMBOL(bit_wait_io);
 
 __sched int bit_wait_timeout(struct wait_bit_key *word, int mode)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
schedule_timeout(word->timeout - now);
@@ -613,7 +614,8 @@ EXPORT_SYMBOL_GPL(bit_wait_timeout);
 
 __sched int bit_wait_io_timeout(struct wait_bit_key *word, int mode)
 {
-   unsigned long now = READ_ONCE(jiffies);
+   unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
io_schedule_timeout(word->timeout - now);
-- 
2.10.0

About 1000Mbps capability for the GMAC of RK3288

[Randy Li]

I have confirmed the 1000Mbps won't work with kernel 4.4, I have to 
disable it in dts.
The TRM shows that it may not support 1000Mbps, as the gmac_speed in 
GRF_SOC_CON1 is just a bit length flag.
Also I have test the performance at the firefly plus with upstream 
kernel, it even looks bad at 100Mpbs mode, only 5~6 MBytes per second. I 
wonder whether it is the hardware design problem or some problem in 
driver, I would report if I got more information.



 Forwarded Message 
Subject: About 1000Mbps with RK3288 and performance
Date: Tue, 20 Sep 2016 09:31:57 +0800
From: Randy Li 
Organization: Fuzhou Rockchip
To: david...@rock-chips.com
CC: roger.c...@rock-chips.com

Hello Wu
   Have you guys confirmed the RK3288 EVB with 1000Mbps network? I meet 
this issue in the weekend. The kernel is 4.4, when I connected the board 
into a 1000Mbps switch(Dell PowerConnect Serial), the speed negatived 
1000Mbps at both side(I checked with console in switch), but the network 
can't work at all. I have downgrade the speed to 100Mbps or packages 
loss is nearly 100%.
   Also I have been reported with performance of ethernet in Upstream 
kernel, it could barely 5-6MBytes in my test, do you have some idea 
about this?

   You could dial internal number 8308 to talk with me.
Yours Randy

--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

About 1000Mbps capability for the GMAC of RK3288

[Randy Li]

I have confirmed the 1000Mbps won't work with kernel 4.4, I have to 
disable it in dts.
The TRM shows that it may not support 1000Mbps, as the gmac_speed in 
GRF_SOC_CON1 is just a bit length flag.
Also I have test the performance at the firefly plus with upstream 
kernel, it even looks bad at 100Mpbs mode, only 5~6 MBytes per second. I 
wonder whether it is the hardware design problem or some problem in 
driver, I would report if I got more information.



 Forwarded Message 
Subject: About 1000Mbps with RK3288 and performance
Date: Tue, 20 Sep 2016 09:31:57 +0800
From: Randy Li 
Organization: Fuzhou Rockchip
To: david...@rock-chips.com
CC: roger.c...@rock-chips.com

Hello Wu
   Have you guys confirmed the RK3288 EVB with 1000Mbps network? I meet 
this issue in the weekend. The kernel is 4.4, when I connected the board 
into a 1000Mbps switch(Dell PowerConnect Serial), the speed negatived 
1000Mbps at both side(I checked with console in switch), but the network 
can't work at all. I have downgrade the speed to 100Mbps or packages 
loss is nearly 100%.
   Also I have been reported with performance of ethernet in Upstream 
kernel, it could barely 5-6MBytes in my test, do you have some idea 
about this?

   You could dial internal number 8308 to talk with me.
Yours Randy

--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

RE: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

[Johnny.Chuang]

There is only one different which is adding a new empty line for coding
style.

>   if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
>   if (!error)
>   error = elants_i2c_query_fw_version(ts);

-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] 
Sent: Saturday, September 24, 2016 5:31 AM
To: Johnny Chuang
Cc: Daniel Kurtz; Jennifer Tsai; linux-kernel@vger.kernel.org;
linux-in...@vger.kernel.org; James Chen; Paul Liang; Jeff Chuang; Agnes
Cheng
Subject: Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode
for FW update

On Fri, Sep 23, 2016 at 04:01:17PM +0800, Johnny Chuang wrote:
> This CL takes the responsibility for getting product/hardware id on 
> recovery mode.
> It will fix firmware update script could not find correspond firmware 
> file name on recovery mode.
> BTW, firmware must need to support reading product/hardware id on boot 
> code.
> 
> Signed-off-by: Johnny Chuang 

This appears to be exactly the same as to what I already have in my "next"
branch...

> ---
>  drivers/input/touchscreen/elants_i2c.c | 31 
> ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c 
> b/drivers/input/touchscreen/elants_i2c.c
> index ac09855..02aec28 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -298,7 +298,7 @@ static u16 elants_i2c_parse_version(u8 *buf)
>   return get_unaligned_be32(buf) >> 4;  }
>  
> -static int elants_i2c_query_fw_id(struct elants_data *ts)
> +static int elants_i2c_query_hw_version(struct elants_data *ts)
>  {
>   struct i2c_client *client = ts->client;
>   int error, retry_cnt;
> @@ -318,8 +318,13 @@ static int elants_i2c_query_fw_id(struct elants_data
*ts)
>   error, (int)sizeof(resp), resp);
>   }
>  
> - dev_err(>dev,
> - "Failed to read fw id or fw id is invalid\n");
> + if (error) {
> + dev_err(>dev,
> + "Failed to read fw id: %d\n", error);
> + return error;
> + }
> +
> + dev_err(>dev, "Invalid fw id: %#04x\n", ts->hw_version);
>  
>   return -EINVAL;
>  }
> @@ -508,7 +513,7 @@ static int elants_i2c_fastboot(struct i2c_client 
> *client)  static int elants_i2c_initialize(struct elants_data *ts)  {
>   struct i2c_client *client = ts->client;
> - int error, retry_cnt;
> + int error, error2, retry_cnt;
>   const u8 hello_packet[] = { 0x55, 0x55, 0x55, 0x55 };
>   const u8 recov_packet[] = { 0x55, 0x55, 0x80, 0x80 };
>   u8 buf[HEADER_SIZE];
> @@ -553,18 +558,22 @@ static int elants_i2c_initialize(struct elants_data
*ts)
>   }
>   }
>  
> + /* hw version is available even if device in recovery state */
> + error2 = elants_i2c_query_hw_version(ts);
>   if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
>   if (!error)
>   error = elants_i2c_query_fw_version(ts);
> + if (!error)
> + error = elants_i2c_query_test_version(ts);
> + if (!error)
> + error = elants_i2c_query_bc_version(ts);
> + if (!error)
> + error = elants_i2c_query_ts_info(ts);
>  
> - if (error) {
> + if (error)
>   ts->iap_mode = ELAN_IAP_RECOVERY;
> - } else {
> - elants_i2c_query_test_version(ts);
> - elants_i2c_query_bc_version(ts);
> - elants_i2c_query_ts_info(ts);
> - }
>  
>   return 0;
>  }
> --
> 1.8.3.2
> 

-- 
Dmitry

RE: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

[Johnny.Chuang]

There is only one different which is adding a new empty line for coding
style.

>   if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
>   if (!error)
>   error = elants_i2c_query_fw_version(ts);

-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] 
Sent: Saturday, September 24, 2016 5:31 AM
To: Johnny Chuang
Cc: Daniel Kurtz; Jennifer Tsai; linux-kernel@vger.kernel.org;
linux-in...@vger.kernel.org; James Chen; Paul Liang; Jeff Chuang; Agnes
Cheng
Subject: Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode
for FW update

On Fri, Sep 23, 2016 at 04:01:17PM +0800, Johnny Chuang wrote:
> This CL takes the responsibility for getting product/hardware id on 
> recovery mode.
> It will fix firmware update script could not find correspond firmware 
> file name on recovery mode.
> BTW, firmware must need to support reading product/hardware id on boot 
> code.
> 
> Signed-off-by: Johnny Chuang 

This appears to be exactly the same as to what I already have in my "next"
branch...

> ---
>  drivers/input/touchscreen/elants_i2c.c | 31 
> ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c 
> b/drivers/input/touchscreen/elants_i2c.c
> index ac09855..02aec28 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -298,7 +298,7 @@ static u16 elants_i2c_parse_version(u8 *buf)
>   return get_unaligned_be32(buf) >> 4;  }
>  
> -static int elants_i2c_query_fw_id(struct elants_data *ts)
> +static int elants_i2c_query_hw_version(struct elants_data *ts)
>  {
>   struct i2c_client *client = ts->client;
>   int error, retry_cnt;
> @@ -318,8 +318,13 @@ static int elants_i2c_query_fw_id(struct elants_data
*ts)
>   error, (int)sizeof(resp), resp);
>   }
>  
> - dev_err(>dev,
> - "Failed to read fw id or fw id is invalid\n");
> + if (error) {
> + dev_err(>dev,
> + "Failed to read fw id: %d\n", error);
> + return error;
> + }
> +
> + dev_err(>dev, "Invalid fw id: %#04x\n", ts->hw_version);
>  
>   return -EINVAL;
>  }
> @@ -508,7 +513,7 @@ static int elants_i2c_fastboot(struct i2c_client 
> *client)  static int elants_i2c_initialize(struct elants_data *ts)  {
>   struct i2c_client *client = ts->client;
> - int error, retry_cnt;
> + int error, error2, retry_cnt;
>   const u8 hello_packet[] = { 0x55, 0x55, 0x55, 0x55 };
>   const u8 recov_packet[] = { 0x55, 0x55, 0x80, 0x80 };
>   u8 buf[HEADER_SIZE];
> @@ -553,18 +558,22 @@ static int elants_i2c_initialize(struct elants_data
*ts)
>   }
>   }
>  
> + /* hw version is available even if device in recovery state */
> + error2 = elants_i2c_query_hw_version(ts);
>   if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
>   if (!error)
>   error = elants_i2c_query_fw_version(ts);
> + if (!error)
> + error = elants_i2c_query_test_version(ts);
> + if (!error)
> + error = elants_i2c_query_bc_version(ts);
> + if (!error)
> + error = elants_i2c_query_ts_info(ts);
>  
> - if (error) {
> + if (error)
>   ts->iap_mode = ELAN_IAP_RECOVERY;
> - } else {
> - elants_i2c_query_test_version(ts);
> - elants_i2c_query_bc_version(ts);
> - elants_i2c_query_ts_info(ts);
> - }
>  
>   return 0;
>  }
> --
> 1.8.3.2
> 

-- 
Dmitry

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Dave Chinner]

On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
> 
> I did happen to notice:
> 
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner  wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> > ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used 
> > [-Werror=unused-but-set-variable]
> 
> You have some nasty unicode corruption. The email is marked as being
> 
>   Content-Type: text/plain; charset=UTF-8
>   Content-Transfer-Encoding: 8bit

It's whatever git-send-email spat out. I was under the impression it
encodes like that whenever it sees a utf-8 character in a commit...

> but those are not the right unicode characters. I think gcc actually
> uses back-tick and tick (which is ugly as hell in many fonts since
> they aren't generally necessarily symmetric, but oh well). So some
> cut-and-paste path of yours corrupted the utf8.

Yup, normally I remember to fix that up when composing the patch -
ever since GNU went to those fucked up "grammatically correct"
non-ascii quotes it's caused problems with pasting error messages
into ascii-only contexts.

> Obviously not a big deal, but you might want to look at your character
> set setting in your mailer or other environment. Perhaps some odd
> non-utf8 editor environment or something?

I turned off utf-8 support in vim on the machine I write all my code
on - I got sick of stupid stray marks in my code, digraphs being
composed when I just want to replace a single character, git sending
patches in utf-8 encoding because I copied a SoB with a utf-8
character in the name, etc

> I also noticed:
> 
> > This is a regression caused by commit e23d415 ("fix
> > fault_in_multipages_...() on architectures with no-op access_ok()").
> 
> I'd suggest doing
> 
>  git config --global core.abbrev 12

Ok.

> because the default git commit shortening value of 7 is practically
> too short for the kernel these days.

7 characters, 12 characters, whatever. Neither make any sense in
commit messages by themselves without the short description that
goes along with the hash.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Dave Chinner]

On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
> 
> I did happen to notice:
> 
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner  wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> > ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used 
> > [-Werror=unused-but-set-variable]
> 
> You have some nasty unicode corruption. The email is marked as being
> 
>   Content-Type: text/plain; charset=UTF-8
>   Content-Transfer-Encoding: 8bit

It's whatever git-send-email spat out. I was under the impression it
encodes like that whenever it sees a utf-8 character in a commit...

> but those are not the right unicode characters. I think gcc actually
> uses back-tick and tick (which is ugly as hell in many fonts since
> they aren't generally necessarily symmetric, but oh well). So some
> cut-and-paste path of yours corrupted the utf8.

Yup, normally I remember to fix that up when composing the patch -
ever since GNU went to those fucked up "grammatically correct"
non-ascii quotes it's caused problems with pasting error messages
into ascii-only contexts.

> Obviously not a big deal, but you might want to look at your character
> set setting in your mailer or other environment. Perhaps some odd
> non-utf8 editor environment or something?

I turned off utf-8 support in vim on the machine I write all my code
on - I got sick of stupid stray marks in my code, digraphs being
composed when I just want to replace a single character, git sending
patches in utf-8 encoding because I copied a SoB with a utf-8
character in the name, etc

> I also noticed:
> 
> > This is a regression caused by commit e23d415 ("fix
> > fault_in_multipages_...() on architectures with no-op access_ok()").
> 
> I'd suggest doing
> 
>  git config --global core.abbrev 12

Ok.

> because the default git commit shortening value of 7 is practically
> too short for the kernel these days.

7 characters, 12 characters, whatever. Neither make any sense in
commit messages by themselves without the short description that
goes along with the hash.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Aw

[info]

Benötigen Sie eine Finanzierung?
Haben Sie einen Kredit für geschäftliche oder persönliche Bedürfnisse und 
Projektfinanzierung benötigen?
Möchten Sie Ihr Unternehmen zu refinanzieren?
Unser Unternehmen ist in den Vereinigten Staaten und Europa.
Wir bieten Ihnen ein Darlehen für jede Person oder Gesellschaft mit einem 
Anteil von 3% pro Jahr.
Für weitere Informationen, kontaktieren Sie uns bitte per E-Mail: 
info.accessf...@gmail.com

Aw

[info]

Benötigen Sie eine Finanzierung?
Haben Sie einen Kredit für geschäftliche oder persönliche Bedürfnisse und 
Projektfinanzierung benötigen?
Möchten Sie Ihr Unternehmen zu refinanzieren?
Unser Unternehmen ist in den Vereinigten Staaten und Europa.
Wir bieten Ihnen ein Darlehen für jede Person oder Gesellschaft mit einem 
Anteil von 3% pro Jahr.
Für weitere Informationen, kontaktieren Sie uns bitte per E-Mail: 
info.accessf...@gmail.com

RE: [v6,2/2] QE: remove PPCisms for QE

[Qiang Zhao]

On Sun, Sep 25, 2016 at 12:19PM -0500, Scott Wood wrote:

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Sunday, September 25, 2016 12:19 PM
> To: Qiang Zhao 
> Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie
> ; linux-kernel@vger.kernel.org
> Subject: Re: [v6,2/2] QE: remove PPCisms for QE
> 
> On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote:
> > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote:
> > > QE was supported on PowerPC, and dependent on PPC, Now it is
> > > supported on other platforms. so remove PPCisms.
> > >
> > > Signed-off-by: Zhao Qiang 
> > > ---
> > > Changes for v2:
> > >   - na
> > > Changes for v3:
> > >   - add NO_IRQ
> > > Changes for v4:
> > >   - modify spin_event_timeout to opencoded timeout loop
> > >   - remove NO_IRQ
> > >   - modify virq_to_hw to opencoed code Changes for v5:
> > >   - modify commit msg
> > >   - modify depends of QUICC_ENGINE
> > >   - add kerneldoc header for qe_issue_cmd Changes for v6:
> > >   - add dependency on FSL_SOC and PPC32 for drivers
> > > depending on QUICC_ENGING but not available on ARM
> > >
> > >  drivers/irqchip/qe_ic.c| 28 +++-
> > >  drivers/net/ethernet/freescale/Kconfig | 10 ++---
> > >  drivers/soc/fsl/qe/Kconfig |  2 +-
> > >  drivers/soc/fsl/qe/qe.c| 80 
> > > --
> > >  drivers/soc/fsl/qe/qe_io.c | 42 --
> > >  drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
> > >  drivers/soc/fsl/qe/ucc.c   | 10 ++---
> > >  drivers/soc/fsl/qe/ucc_fast.c  | 68 ++---
> > >  drivers/tty/serial/Kconfig |  2 +-
> > >  drivers/usb/gadget/udc/Kconfig |  2 +-
> > >  drivers/usb/host/Kconfig   |  2 +-
> > >  include/soc/fsl/qe/qe.h|  1 -
> > >  include/soc/fsl/qe/qe_ic.h | 12 ++---
> > >  13 files changed, 141 insertions(+), 126 deletions(-)
> >
> > I assume this means you'll be updating
> > http://patchwork.ozlabs.org/patch/654473/
> > to be based on top of this...
> 
> Apparently that assumption was wrong, since I now see that you're patching
> drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c.
> Please keep the drivers/irqchip stuff separate and send to the appropriate
> maintainers.
> 

You means separate drivers/irqchip/qe_ic.c part from this patch and send it 
with the other qe_ic patches?
Is it acceptable if I modify qe_ic.c with drivers/soc/fsl/qe/qe_ic.c, then send 
qe_ic patches to move qe_ic to drivers/irqchip?

BR
-Zhao Qiang

RE: [v6,2/2] QE: remove PPCisms for QE

[Qiang Zhao]

On Sun, Sep 25, 2016 at 12:19PM -0500, Scott Wood wrote:

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Sunday, September 25, 2016 12:19 PM
> To: Qiang Zhao 
> Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie
> ; linux-kernel@vger.kernel.org
> Subject: Re: [v6,2/2] QE: remove PPCisms for QE
> 
> On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote:
> > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote:
> > > QE was supported on PowerPC, and dependent on PPC, Now it is
> > > supported on other platforms. so remove PPCisms.
> > >
> > > Signed-off-by: Zhao Qiang 
> > > ---
> > > Changes for v2:
> > >   - na
> > > Changes for v3:
> > >   - add NO_IRQ
> > > Changes for v4:
> > >   - modify spin_event_timeout to opencoded timeout loop
> > >   - remove NO_IRQ
> > >   - modify virq_to_hw to opencoed code Changes for v5:
> > >   - modify commit msg
> > >   - modify depends of QUICC_ENGINE
> > >   - add kerneldoc header for qe_issue_cmd Changes for v6:
> > >   - add dependency on FSL_SOC and PPC32 for drivers
> > > depending on QUICC_ENGING but not available on ARM
> > >
> > >  drivers/irqchip/qe_ic.c| 28 +++-
> > >  drivers/net/ethernet/freescale/Kconfig | 10 ++---
> > >  drivers/soc/fsl/qe/Kconfig |  2 +-
> > >  drivers/soc/fsl/qe/qe.c| 80 
> > > --
> > >  drivers/soc/fsl/qe/qe_io.c | 42 --
> > >  drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
> > >  drivers/soc/fsl/qe/ucc.c   | 10 ++---
> > >  drivers/soc/fsl/qe/ucc_fast.c  | 68 ++---
> > >  drivers/tty/serial/Kconfig |  2 +-
> > >  drivers/usb/gadget/udc/Kconfig |  2 +-
> > >  drivers/usb/host/Kconfig   |  2 +-
> > >  include/soc/fsl/qe/qe.h|  1 -
> > >  include/soc/fsl/qe/qe_ic.h | 12 ++---
> > >  13 files changed, 141 insertions(+), 126 deletions(-)
> >
> > I assume this means you'll be updating
> > http://patchwork.ozlabs.org/patch/654473/
> > to be based on top of this...
> 
> Apparently that assumption was wrong, since I now see that you're patching
> drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c.
> Please keep the drivers/irqchip stuff separate and send to the appropriate
> maintainers.
> 

You means separate drivers/irqchip/qe_ic.c part from this patch and send it 
with the other qe_ic patches?
Is it acceptable if I modify qe_ic.c with drivers/soc/fsl/qe/qe_ic.c, then send 
qe_ic patches to move qe_ic to drivers/irqchip?

BR
-Zhao Qiang

[PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

[Joe Perches]

Use a bit more consistent style with kernel loglevels without
using macro argument concatenation.

Miscellanea:

o Single statement macros don't need do {} while (0)

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 --
 include/drm/drmP.h  | 26 +-
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6fd39efb7894..bc4f9895f356 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -566,7 +566,7 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_NOTE("GuC firmware load failed: %d\n", err);
+   DRM_NOTICE("GuC firmware load failed: %d\n", err);
else
DRM_WARN("GuC firmware load failed: %d\n", err);
 
@@ -574,7 +574,7 @@ int intel_guc_setup(struct drm_device *dev)
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTICE("Falling back from GuC submission to 
execlist mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -606,7 +606,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_NOTE("Firmware header is missing\n");
+   DRM_NOTICE("Firmware header is missing\n");
goto fail;
}
 
@@ -618,7 +618,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_NOTE("CSS header definition mismatch\n");
+   DRM_NOTICE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -628,7 +628,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_NOTE("RSA key size is bad\n");
+   DRM_NOTICE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -637,14 +637,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_NOTE("Missing firmware components\n");
+   DRM_NOTICE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_NOTE("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTICE("Firmware is too large to fit in WOPCM\n");
goto fail;
}
 
@@ -659,9 +659,11 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
if (guc_fw->guc_fw_major_found != guc_fw->guc_fw_major_wanted ||
guc_fw->guc_fw_minor_found < guc_fw->guc_fw_minor_wanted) {
-   DRM_NOTE("GuC firmware version %d.%d, required %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found,
-   guc_fw->guc_fw_major_wanted, 
guc_fw->guc_fw_minor_wanted);
+   DRM_NOTICE("GuC firmware version %d.%d, required %d.%d\n",
+  guc_fw->guc_fw_major_found,
+  guc_fw->guc_fw_minor_found,
+  guc_fw->guc_fw_major_wanted,
+  guc_fw->guc_fw_minor_wanted);
err = -ENOEXEC;
goto fail;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c53dc90942e0..95cd04aa9bf7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,25 +168,25 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/
 
-#define _DRM_PRINTK(once, level, fmt, ...) \
-   do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
-   } while (0)
+#define _drm_printk(level, 

[PATCH 0/2] drm: Neaten and reduce object size

[Joe Perches]

Joe Perches (2):
  drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE
  drm: Simplify drm_printk to reduce object size quite a bit

 drivers/gpu/drm/drm_drv.c   |  5 +--
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 +++--
 include/drm/drmP.h  | 56 -
 3 files changed, 42 insertions(+), 41 deletions(-)

-- 
2.10.0.rc2.1.g053435c

[PATCH 2/2] drm: Simplify drm_printk to reduce object size quite a bit

[Joe Perches]

Remove function name and special " *ERROR*" from argument list

$ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected)
   textdata bss dec hex filename
5635366  182579   14328 5832273  58fe51 drivers/gpu/drm/built-in.o.new
5779552  182579   14328 5976459  5b318b drivers/gpu/drm/built-in.o.old

Using "%ps", __builtin_return_address(0) is the same as "%s", __func__
except for static inlines, but it's more or less the same output.

Miscellanea:

o Convert args... to ##__VA_ARGS__
o The equivalent DRM_DEV_ macros are rarely used and not
  worth conversion

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_drv.c |  5 +++--
 include/drm/drmP.h| 30 ++
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 80c7f25b5b74..6efdba4993fc 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -89,7 +89,6 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 EXPORT_SYMBOL(drm_dev_printk);
 
 void drm_printk(const char *level, unsigned int category,
-   const char *function_name, const char *prefix,
const char *format, ...)
 {
struct va_format vaf;
@@ -102,7 +101,9 @@ void drm_printk(const char *level, unsigned int category,
vaf.fmt = format;
vaf.va = 
 
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
+   printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+  level, __builtin_return_address(0),
+  strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
 
va_end(args);
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 95cd04aa9bf7..4729c543d877 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -140,9 +140,8 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
 
-extern __printf(5, 6)
+extern __printf(3, 4)
 void drm_printk(const char *level, unsigned int category,
-   const char *function_name, const char *prefix,
const char *format, ...);
 
 /***/
@@ -198,8 +197,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
   fmt, ##__VA_ARGS__)
 #define DRM_ERROR(fmt, ...)\
-   drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
-  ##__VA_ARGS__)
+   drm_printk(KERN_ERR, DRM_UT_NONE, fmt,  ##__VA_ARGS__)
 
 /**
  * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
@@ -241,38 +239,38 @@ void drm_printk(const char *level, unsigned int category,
 #define DRM_DEV_DEBUG(dev, fmt, args...)   \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
   ##args)
-#define DRM_DEBUG(fmt, args...)
\
-   drm_printk(KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, ##args)
+#define DRM_DEBUG(fmt, ...)\
+   drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
   fmt, ##args)
-#define DRM_DEBUG_DRIVER(fmt, args...) \
-   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, __func__, "", fmt, ##args)
+#define DRM_DEBUG_DRIVER(fmt, ...) \
+   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_KMS(dev, fmt, args...)   \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt,  \
   ##args)
-#define DRM_DEBUG_KMS(fmt, args...)\
-   drm_printk(KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, ##args)
+#define DRM_DEBUG_KMS(fmt, ...)\
+   drm_printk(KERN_DEBUG, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_PRIME(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_PRIME, __func__, "", \
   fmt, ##args)
-#define DRM_DEBUG_PRIME(fmt, args...)  \
-   drm_printk(KERN_DEBUG, DRM_UT_PRIME, __func__, "", fmt, ##args)
+#define DRM_DEBUG_PRIME(fmt, ...)  \
+   drm_printk(KERN_DEBUG, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_ATOMIC(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ATOMIC, __func__, "",\
   fmt, 

[PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

[Joe Perches]

Use a bit more consistent style with kernel loglevels without
using macro argument concatenation.

Miscellanea:

o Single statement macros don't need do {} while (0)

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 --
 include/drm/drmP.h  | 26 +-
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6fd39efb7894..bc4f9895f356 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -566,7 +566,7 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_NOTE("GuC firmware load failed: %d\n", err);
+   DRM_NOTICE("GuC firmware load failed: %d\n", err);
else
DRM_WARN("GuC firmware load failed: %d\n", err);
 
@@ -574,7 +574,7 @@ int intel_guc_setup(struct drm_device *dev)
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTICE("Falling back from GuC submission to 
execlist mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -606,7 +606,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_NOTE("Firmware header is missing\n");
+   DRM_NOTICE("Firmware header is missing\n");
goto fail;
}
 
@@ -618,7 +618,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_NOTE("CSS header definition mismatch\n");
+   DRM_NOTICE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -628,7 +628,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_NOTE("RSA key size is bad\n");
+   DRM_NOTICE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -637,14 +637,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_NOTE("Missing firmware components\n");
+   DRM_NOTICE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_NOTE("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTICE("Firmware is too large to fit in WOPCM\n");
goto fail;
}
 
@@ -659,9 +659,11 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
if (guc_fw->guc_fw_major_found != guc_fw->guc_fw_major_wanted ||
guc_fw->guc_fw_minor_found < guc_fw->guc_fw_minor_wanted) {
-   DRM_NOTE("GuC firmware version %d.%d, required %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found,
-   guc_fw->guc_fw_major_wanted, 
guc_fw->guc_fw_minor_wanted);
+   DRM_NOTICE("GuC firmware version %d.%d, required %d.%d\n",
+  guc_fw->guc_fw_major_found,
+  guc_fw->guc_fw_minor_found,
+  guc_fw->guc_fw_major_wanted,
+  guc_fw->guc_fw_minor_wanted);
err = -ENOEXEC;
goto fail;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c53dc90942e0..95cd04aa9bf7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,25 +168,25 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/
 
-#define _DRM_PRINTK(once, level, fmt, ...) \
-   do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
-   } while (0)
+#define _drm_printk(level, fmt, ...)

[PATCH 0/2] drm: Neaten and reduce object size

[Joe Perches]

Joe Perches (2):
  drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE
  drm: Simplify drm_printk to reduce object size quite a bit

 drivers/gpu/drm/drm_drv.c   |  5 +--
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 +++--
 include/drm/drmP.h  | 56 -
 3 files changed, 42 insertions(+), 41 deletions(-)

-- 
2.10.0.rc2.1.g053435c

[PATCH 2/2] drm: Simplify drm_printk to reduce object size quite a bit

[Joe Perches]

Remove function name and special " *ERROR*" from argument list

$ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected)
   textdata bss dec hex filename
5635366  182579   14328 5832273  58fe51 drivers/gpu/drm/built-in.o.new
5779552  182579   14328 5976459  5b318b drivers/gpu/drm/built-in.o.old

Using "%ps", __builtin_return_address(0) is the same as "%s", __func__
except for static inlines, but it's more or less the same output.

Miscellanea:

o Convert args... to ##__VA_ARGS__
o The equivalent DRM_DEV_ macros are rarely used and not
  worth conversion

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_drv.c |  5 +++--
 include/drm/drmP.h| 30 ++
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 80c7f25b5b74..6efdba4993fc 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -89,7 +89,6 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 EXPORT_SYMBOL(drm_dev_printk);
 
 void drm_printk(const char *level, unsigned int category,
-   const char *function_name, const char *prefix,
const char *format, ...)
 {
struct va_format vaf;
@@ -102,7 +101,9 @@ void drm_printk(const char *level, unsigned int category,
vaf.fmt = format;
vaf.va = 
 
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
+   printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+  level, __builtin_return_address(0),
+  strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
 
va_end(args);
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 95cd04aa9bf7..4729c543d877 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -140,9 +140,8 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
 
-extern __printf(5, 6)
+extern __printf(3, 4)
 void drm_printk(const char *level, unsigned int category,
-   const char *function_name, const char *prefix,
const char *format, ...);
 
 /***/
@@ -198,8 +197,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
   fmt, ##__VA_ARGS__)
 #define DRM_ERROR(fmt, ...)\
-   drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
-  ##__VA_ARGS__)
+   drm_printk(KERN_ERR, DRM_UT_NONE, fmt,  ##__VA_ARGS__)
 
 /**
  * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
@@ -241,38 +239,38 @@ void drm_printk(const char *level, unsigned int category,
 #define DRM_DEV_DEBUG(dev, fmt, args...)   \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
   ##args)
-#define DRM_DEBUG(fmt, args...)
\
-   drm_printk(KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, ##args)
+#define DRM_DEBUG(fmt, ...)\
+   drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
   fmt, ##args)
-#define DRM_DEBUG_DRIVER(fmt, args...) \
-   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, __func__, "", fmt, ##args)
+#define DRM_DEBUG_DRIVER(fmt, ...) \
+   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_KMS(dev, fmt, args...)   \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt,  \
   ##args)
-#define DRM_DEBUG_KMS(fmt, args...)\
-   drm_printk(KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, ##args)
+#define DRM_DEBUG_KMS(fmt, ...)\
+   drm_printk(KERN_DEBUG, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_PRIME(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_PRIME, __func__, "", \
   fmt, ##args)
-#define DRM_DEBUG_PRIME(fmt, args...)  \
-   drm_printk(KERN_DEBUG, DRM_UT_PRIME, __func__, "", fmt, ##args)
+#define DRM_DEBUG_PRIME(fmt, ...)  \
+   drm_printk(KERN_DEBUG, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_ATOMIC(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ATOMIC, __func__, "",\
   fmt, ##args)
-#define 

Re: Warning from free_init_pages with large initrd

[H. Peter Anvin]

On 09/24/16 08:32, Sitsofe Wheeler wrote:
> Hi,
> 
> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel
> throws the following warning:
> 
[...]
> 
> The initrd is big because it holds all the files in the ISO (see
> https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it was
> made). The issue was originally filed on
> https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually
> against older kernels...
> 

How big is big?

внимания;

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...8715gdo7q2..2016
Почты технической поддержки ©2016

спасибо
системы администратор

Re: Warning from free_init_pages with large initrd

[H. Peter Anvin]

On 09/24/16 08:32, Sitsofe Wheeler wrote:
> Hi,
> 
> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel
> throws the following warning:
> 
[...]
> 
> The initrd is big because it holds all the files in the ISO (see
> https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it was
> made). The issue was originally filed on
> https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually
> against older kernels...
> 

How big is big?

внимания;

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...8715gdo7q2..2016
Почты технической поддержки ©2016

спасибо
системы администратор

Linux 4.8-rc8

[Linus Torvalds]

So as already mentioned last week (and hinted at as a possibility),
here's rc8. Things actually did start to calm down this week, but I
didn't get the feeling that there was no point in doing one final rc,
so here we are. I expect the final 4.8 release next weekend, unless
something really unexpected comes up.

There's a few straggling entries on Thorsten's regression list, but
nothing that makes me go "we need to hold off 4.8". And things realy
were pretty quiet, with just mostly random small fixes. See the
shortlog below, but it's small things all over: mostly drivers, with
some arch and crypto, and small MM and filesystem fixes. And a
smattering of networking.

Linus

---

AKASHI Takahiro (1):
  arm64: kgdb: handle read-only text / modules

Aaro Koskinen (2):
  MIPS: Octeon: mangle-port: fix build failure with VDSO code
  MIPS: Octeon: Fix platform bus probing

Al Viro (2):
  fix fault_in_multipages_...() on architectures with no-op access_ok()
  fix memory leaks in tracing_buffers_splice_read()

Alexander Shishkin (2):
  perf/x86/intel/bts: Make it an exclusive PMU
  perf/core: Limit matching exclusive events to one PMU

Alexandre Bounine (1):
  rapidio/rio_cm: avoid GFP_KERNEL in atomic context

Amitoj Kaur Chawla (1):
  MIPS: ath79: Fix test for error return of clk_register_fixed_factor().

Andrew Lunn (1):
  MAINTAINERS: Add an entry for the core network DSA code

Ard Biesheuvel (2):
  crypto: arm/aes-ctr - fix NULL dereference in tail processing
  crypto: arm64/aes-ctr - fix NULL dereference in tail processing

Arnd Bergmann (1):
  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning

Ashish Samant (1):
  ocfs2: fix start offset to ocfs2_zero_range_for_truncate()

Baoquan He (1):
  bnx2: Reset device during driver initialization

Beni Lev (1):
  iwlwifi: mvm: update TX queue before making a copy of the skb

Christoph Hellwig (1):
  blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx

Christophe Jaillet (1):
  drivers: net: phy: xgene: Fix 'remove' function

Dave Chinner (1):
  fault_in_multipages_readable() throws set-but-unused error

David Daney (1):
  arm64: Call numa_store_cpu_info() earlier.

Ebru Akagunduz (1):
  mm, thp: fix leaking mapped pte in __collapse_huge_page_swapin()

Eric Dumazet (3):
  tcp: fix overflow in __tcp_retransmit_skb()
  net: avoid sk_forward_alloc overflows
  net: get rid of an signed integer overflow in ip_idents_reserve()

Fabio Estevam (1):
  can: flexcan: fix resume function

Felix Fietkau (2):
  mac80211: fix tim recalculation after PS response
  mac80211: fix sequence number assignment for PS response frames

Filipe Manco (1):
  xen-netback: fix error handling on netback_probe()

Florian Fainelli (1):
  MAINTAINERS: update email for VLYNQ bus entry

Gao Feng (1):
  netfilter: synproxy: Check oom when adding synproxy and seqadj
ct extensions

Geert Uytterhoeven (1):
  [media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success

Giuseppe CAVALLARO (1):
  stmmac: fix PWRDWN into the PMT register for global unicast.

Hans Verkuil (17):
  [media] cec: rename cec_devnode fhs_lock to just lock
  [media] cec: improve locking
  [media] cec-funcs.h: fix typo: && should be &
  [media] cec-funcs.h: add reply argument for Record On/Off
  [media] cec: improve dqevent documentation
  [media] cec: add CEC_LOG_ADDRS_FL_ALLOW_UNREG_FALLBACK flag
  [media] cec: set unclaimed addresses to CEC_LOG_ADDR_INVALID
  [media] cec: add item to TODO
  [media] cec: ignore messages when log_addr_mask == 0
  [media] mtk-vcodec: add HAS_DMA dependency
  [media] pulse8-cec: set correct Signal Free Time
  [media] pulse8-cec: fix error handling
  [media] cec-edid: check for IEEE identifier
  [media] cec-funcs.h: add missing vendor-specific messages
  [media] cec: don't Feature Abort broadcast msgs when unregistered
  [media] cec: fix ioctl return code when not registered
  [media] cx23885/saa7134: assign q->dev to the PCI device

Hans Wippel (1):
  qeth: restore device features after recovery

Hans de Goede (2):
  Input: silead_gsl1680 - document firmware-name, fix implementation
  Input: silead_gsl1680 - use "silead/" prefix for firmware loading

Hariprasad Shenai (1):
  cxgb4/cxgb4vf: Allocate more queues for 25G and 100G adapter

Herbert Xu (4):
  crypto: echainiv - Replace chaining with multiplication
  crypto: skcipher - Fix blkcipher walk OOM crash
  KEYS: Fix skcipher IV clobbering
  crypto: rsa-pkcs1pad - Handle leading zero for decryption

Huacai Chen (1):
  MIPS: Add a missing ".set pop" in an early commit

Hugh Dickins (2):
  huge tmpfs: fix Committed_AS leak
  mm: delete unnecessary and unsafe init_tlb_ubc()

Ian Kent (1):
  autofs: use dentry flags to block walks during expire

Ilan Tayari (1):
 

Linux 4.8-rc8

[Linus Torvalds]

So as already mentioned last week (and hinted at as a possibility),
here's rc8. Things actually did start to calm down this week, but I
didn't get the feeling that there was no point in doing one final rc,
so here we are. I expect the final 4.8 release next weekend, unless
something really unexpected comes up.

There's a few straggling entries on Thorsten's regression list, but
nothing that makes me go "we need to hold off 4.8". And things realy
were pretty quiet, with just mostly random small fixes. See the
shortlog below, but it's small things all over: mostly drivers, with
some arch and crypto, and small MM and filesystem fixes. And a
smattering of networking.

Linus

---

AKASHI Takahiro (1):
  arm64: kgdb: handle read-only text / modules

Aaro Koskinen (2):
  MIPS: Octeon: mangle-port: fix build failure with VDSO code
  MIPS: Octeon: Fix platform bus probing

Al Viro (2):
  fix fault_in_multipages_...() on architectures with no-op access_ok()
  fix memory leaks in tracing_buffers_splice_read()

Alexander Shishkin (2):
  perf/x86/intel/bts: Make it an exclusive PMU
  perf/core: Limit matching exclusive events to one PMU

Alexandre Bounine (1):
  rapidio/rio_cm: avoid GFP_KERNEL in atomic context

Amitoj Kaur Chawla (1):
  MIPS: ath79: Fix test for error return of clk_register_fixed_factor().

Andrew Lunn (1):
  MAINTAINERS: Add an entry for the core network DSA code

Ard Biesheuvel (2):
  crypto: arm/aes-ctr - fix NULL dereference in tail processing
  crypto: arm64/aes-ctr - fix NULL dereference in tail processing

Arnd Bergmann (1):
  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning

Ashish Samant (1):
  ocfs2: fix start offset to ocfs2_zero_range_for_truncate()

Baoquan He (1):
  bnx2: Reset device during driver initialization

Beni Lev (1):
  iwlwifi: mvm: update TX queue before making a copy of the skb

Christoph Hellwig (1):
  blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx

Christophe Jaillet (1):
  drivers: net: phy: xgene: Fix 'remove' function

Dave Chinner (1):
  fault_in_multipages_readable() throws set-but-unused error

David Daney (1):
  arm64: Call numa_store_cpu_info() earlier.

Ebru Akagunduz (1):
  mm, thp: fix leaking mapped pte in __collapse_huge_page_swapin()

Eric Dumazet (3):
  tcp: fix overflow in __tcp_retransmit_skb()
  net: avoid sk_forward_alloc overflows
  net: get rid of an signed integer overflow in ip_idents_reserve()

Fabio Estevam (1):
  can: flexcan: fix resume function

Felix Fietkau (2):
  mac80211: fix tim recalculation after PS response
  mac80211: fix sequence number assignment for PS response frames

Filipe Manco (1):
  xen-netback: fix error handling on netback_probe()

Florian Fainelli (1):
  MAINTAINERS: update email for VLYNQ bus entry

Gao Feng (1):
  netfilter: synproxy: Check oom when adding synproxy and seqadj
ct extensions

Geert Uytterhoeven (1):
  [media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success

Giuseppe CAVALLARO (1):
  stmmac: fix PWRDWN into the PMT register for global unicast.

Hans Verkuil (17):
  [media] cec: rename cec_devnode fhs_lock to just lock
  [media] cec: improve locking
  [media] cec-funcs.h: fix typo: && should be &
  [media] cec-funcs.h: add reply argument for Record On/Off
  [media] cec: improve dqevent documentation
  [media] cec: add CEC_LOG_ADDRS_FL_ALLOW_UNREG_FALLBACK flag
  [media] cec: set unclaimed addresses to CEC_LOG_ADDR_INVALID
  [media] cec: add item to TODO
  [media] cec: ignore messages when log_addr_mask == 0
  [media] mtk-vcodec: add HAS_DMA dependency
  [media] pulse8-cec: set correct Signal Free Time
  [media] pulse8-cec: fix error handling
  [media] cec-edid: check for IEEE identifier
  [media] cec-funcs.h: add missing vendor-specific messages
  [media] cec: don't Feature Abort broadcast msgs when unregistered
  [media] cec: fix ioctl return code when not registered
  [media] cx23885/saa7134: assign q->dev to the PCI device

Hans Wippel (1):
  qeth: restore device features after recovery

Hans de Goede (2):
  Input: silead_gsl1680 - document firmware-name, fix implementation
  Input: silead_gsl1680 - use "silead/" prefix for firmware loading

Hariprasad Shenai (1):
  cxgb4/cxgb4vf: Allocate more queues for 25G and 100G adapter

Herbert Xu (4):
  crypto: echainiv - Replace chaining with multiplication
  crypto: skcipher - Fix blkcipher walk OOM crash
  KEYS: Fix skcipher IV clobbering
  crypto: rsa-pkcs1pad - Handle leading zero for decryption

Huacai Chen (1):
  MIPS: Add a missing ".set pop" in an early commit

Hugh Dickins (2):
  huge tmpfs: fix Committed_AS leak
  mm: delete unnecessary and unsafe init_tlb_ubc()

Ian Kent (1):
  autofs: use dentry flags to block walks during expire

Ilan Tayari (1):
 

Re: undefined reference to `printk'

[Fengguang Wu]

Hi Joe,

On Sat, Sep 24, 2016 at 08:46:26PM -0700, Joe Perches wrote:

On Sun, 2016-09-25 at 11:40 +0800, kbuild test robot wrote:

Hi Joe,


Hey Fengguang


It's probably a bug fix that unveils the link errors.


I think all of these reports about compiler-gcc integrations
are bogons.


Yes, sorry for the noises again!


tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9c0e28a7be656d737fb18998e2dcb0b8ce595643
commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the 
various compiler-gcc[345].h files


It looks there are different commit SHA1 in different trees for that patch.
I'll match it by patch subject rather than commit id.

Cheers,
Fengguang

Re: undefined reference to `printk'

[Fengguang Wu]

Hi Joe,

On Sat, Sep 24, 2016 at 08:46:26PM -0700, Joe Perches wrote:

On Sun, 2016-09-25 at 11:40 +0800, kbuild test robot wrote:

Hi Joe,


Hey Fengguang


It's probably a bug fix that unveils the link errors.


I think all of these reports about compiler-gcc integrations
are bogons.


Yes, sorry for the noises again!


tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9c0e28a7be656d737fb18998e2dcb0b8ce595643
commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the 
various compiler-gcc[345].h files


It looks there are different commit SHA1 in different trees for that patch.
I'll match it by patch subject rather than commit id.

Cheers,
Fengguang

Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang

[Wangnan (F)]

On 2016/9/24 23:16, Alexei Starovoitov wrote:

On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote:

This patch set is the first step to implement features I announced
in LinuxCon NA 2016. See page 31 of:

  
http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf

This patch set links LLVM and Clang libraries to perf, so perf
is able to compile BPF script to BPF object on the fly.

Nice!
So single perf binary won't have llvm external dependency anymore
or both ways will be maintained?
The command line stays the same?


Yes. This patch set doesn't change interface. It compiles BPF script
with builtin clang, and if it fail, fall back to external clang.


If I understand the patches correctly, this set is establishing
the basic functionality and more complex features coming?



Yes. Following steps are:

 1. Ease of use improvement: automatically include BPF functions
declaration and macros.

 2. Perf's hook: compile part of BPF script into native code, run
them in perf when something happen. Create a channel, coordinate
BPF and native code use bpf-output event.

 3. Define a new language to support common profiling task. I'm not
very clear what the new language should be. It may looks like lua,
perf converts it to C then to LLVM IR with builtin clang.

Thank you.

Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang

[Wangnan (F)]

On 2016/9/24 23:16, Alexei Starovoitov wrote:

On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote:

This patch set is the first step to implement features I announced
in LinuxCon NA 2016. See page 31 of:

  
http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf

This patch set links LLVM and Clang libraries to perf, so perf
is able to compile BPF script to BPF object on the fly.

Nice!
So single perf binary won't have llvm external dependency anymore
or both ways will be maintained?
The command line stays the same?


Yes. This patch set doesn't change interface. It compiles BPF script
with builtin clang, and if it fail, fall back to external clang.


If I understand the patches correctly, this set is establishing
the basic functionality and more complex features coming?



Yes. Following steps are:

 1. Ease of use improvement: automatically include BPF functions
declaration and macros.

 2. Perf's hook: compile part of BPF script into native code, run
them in perf when something happen. Create a channel, coordinate
BPF and native code use bpf-output event.

 3. Define a new language to support common profiling task. I'm not
very clear what the new language should be. It may looks like lua,
perf converts it to C then to LLVM IR with builtin clang.

Thank you.

RE: [PATCH] pm8001: mark symbols static where possible

[lindar_liu]

Thanks for fix.
Acked-by: Lindar Liu 

> -Original Message-
> From: Baoyou Xie [mailto:baoyou@linaro.org]
> Sent: Friday, September 23, 2016 9:54 PM
> To: jinpu.w...@profitbricks.com; lindar_...@usish.com;
> j...@linux.vnet.ibm.com; martin.peter...@oracle.com
> Cc: pmc...@pmcs.com; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
> xie.bao...@zte.com.cn
> Subject: [PATCH] pm8001: mark symbols static where possible
> 
> We get 2 warnings when building kernel with W=1:
> drivers/scsi/pm8001/pm8001_sas.c:530:23: warning: no previous prototype
> for 'pm8001_alloc_dev' [-Wmissing-prototypes]
> drivers/scsi/pm8001/pm8001_hwi.c:4495:5: warning: no previous prototype
> for 'pm8001_chip_phy_stop_req' [-Wmissing-prototypes]
> 
> In fact, these functions are only used in the file in which they are
declared and
> don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/scsi/pm8001/pm8001_hwi.c | 4 ++--
> drivers/scsi/pm8001/pm8001_sas.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 04e67a1..10546fa 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -4492,8 +4492,8 @@ pm8001_chip_phy_start_req(struct
> pm8001_hba_info *pm8001_ha, u8 phy_id)
>   * @num: the inbound queue number
>   * @phy_id: the phy id which we wanted to start up.
>   */
> -int pm8001_chip_phy_stop_req(struct pm8001_hba_info *pm8001_ha,
> - u8 phy_id)
> +static int pm8001_chip_phy_stop_req(struct pm8001_hba_info
> *pm8001_ha,
> + u8 phy_id)
>  {
>   struct phy_stop_req payload;
>   struct inbound_queue_table *circularQ; diff --git
> a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
> index dc33dfa..ce584c3 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -527,7 +527,7 @@ void pm8001_ccb_task_free(struct pm8001_hba_info
> *pm8001_ha,
>* pm8001_alloc_dev - find a empty pm8001_device
>* @pm8001_ha: our hba card information
>*/
> -struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> *pm8001_ha)
> +static struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> +*pm8001_ha)
>  {
>   u32 dev;
>   for (dev = 0; dev < PM8001_MAX_DEVICES; dev++) {
> --
> 2.7.4

RE: [PATCH] pm8001: mark symbols static where possible

[lindar_liu]

Thanks for fix.
Acked-by: Lindar Liu 

> -Original Message-
> From: Baoyou Xie [mailto:baoyou@linaro.org]
> Sent: Friday, September 23, 2016 9:54 PM
> To: jinpu.w...@profitbricks.com; lindar_...@usish.com;
> j...@linux.vnet.ibm.com; martin.peter...@oracle.com
> Cc: pmc...@pmcs.com; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
> xie.bao...@zte.com.cn
> Subject: [PATCH] pm8001: mark symbols static where possible
> 
> We get 2 warnings when building kernel with W=1:
> drivers/scsi/pm8001/pm8001_sas.c:530:23: warning: no previous prototype
> for 'pm8001_alloc_dev' [-Wmissing-prototypes]
> drivers/scsi/pm8001/pm8001_hwi.c:4495:5: warning: no previous prototype
> for 'pm8001_chip_phy_stop_req' [-Wmissing-prototypes]
> 
> In fact, these functions are only used in the file in which they are
declared and
> don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/scsi/pm8001/pm8001_hwi.c | 4 ++--
> drivers/scsi/pm8001/pm8001_sas.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 04e67a1..10546fa 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -4492,8 +4492,8 @@ pm8001_chip_phy_start_req(struct
> pm8001_hba_info *pm8001_ha, u8 phy_id)
>   * @num: the inbound queue number
>   * @phy_id: the phy id which we wanted to start up.
>   */
> -int pm8001_chip_phy_stop_req(struct pm8001_hba_info *pm8001_ha,
> - u8 phy_id)
> +static int pm8001_chip_phy_stop_req(struct pm8001_hba_info
> *pm8001_ha,
> + u8 phy_id)
>  {
>   struct phy_stop_req payload;
>   struct inbound_queue_table *circularQ; diff --git
> a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
> index dc33dfa..ce584c3 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -527,7 +527,7 @@ void pm8001_ccb_task_free(struct pm8001_hba_info
> *pm8001_ha,
>* pm8001_alloc_dev - find a empty pm8001_device
>* @pm8001_ha: our hba card information
>*/
> -struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> *pm8001_ha)
> +static struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> +*pm8001_ha)
>  {
>   u32 dev;
>   for (dev = 0; dev < PM8001_MAX_DEVICES; dev++) {
> --
> 2.7.4

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Linus Torvalds]

Thanks, applied.

I did happen to notice:

On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner  wrote:
>
> ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used 
> [-Werror=unused-but-set-variable]

You have some nasty unicode corruption. The email is marked as being

  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit

but those are not the right unicode characters. I think gcc actually
uses back-tick and tick (which is ugly as hell in many fonts since
they aren't generally necessarily symmetric, but oh well). So some
cut-and-paste path of yours corrupted the utf8.

Obviously not a big deal, but you might want to look at your character
set setting in your mailer or other environment. Perhaps some odd
non-utf8 editor environment or something?

I also noticed:

> This is a regression caused by commit e23d415 ("fix
> fault_in_multipages_...() on architectures with no-op access_ok()").

I'd suggest doing

 git config --global core.abbrev 12

because the default git commit shortening value of 7 is practically
too short for the kernel these days. What can I say? I was naïve, and
based my original abbreviation decision on the BitKeeper numbers,
where we were just about to hit 64k commits.  So seven hex digits
seemed plenty. And now, ten years later, I just look stupid.

Anyway - while git will always pick a shortname that is unique (ie it
will add characters until it is unique), it's unique only at that
moment in time. And practically speaking seven hex digits can easily
have collisions in the hear future (ie it already happens with many
commits).

So telling git "give me a minimum of 12 hex digits in hash
abbreviations" should be fairly safe for a while.

I guess I should ping Junio and see if we can just change the default,
but for smaller projects the default abbreviation is likely still
reasonable. So I've been just mentioning that simple "set core.abbrev
to 12" to kernel people..

  Linus

Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

[Linus Torvalds]

Thanks, applied.

I did happen to notice:

On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner  wrote:
>
> ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used 
> [-Werror=unused-but-set-variable]

You have some nasty unicode corruption. The email is marked as being

  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit

but those are not the right unicode characters. I think gcc actually
uses back-tick and tick (which is ugly as hell in many fonts since
they aren't generally necessarily symmetric, but oh well). So some
cut-and-paste path of yours corrupted the utf8.

Obviously not a big deal, but you might want to look at your character
set setting in your mailer or other environment. Perhaps some odd
non-utf8 editor environment or something?

I also noticed:

> This is a regression caused by commit e23d415 ("fix
> fault_in_multipages_...() on architectures with no-op access_ok()").

I'd suggest doing

 git config --global core.abbrev 12

because the default git commit shortening value of 7 is practically
too short for the kernel these days. What can I say? I was naïve, and
based my original abbreviation decision on the BitKeeper numbers,
where we were just about to hit 64k commits.  So seven hex digits
seemed plenty. And now, ten years later, I just look stupid.

Anyway - while git will always pick a shortname that is unique (ie it
will add characters until it is unique), it's unique only at that
moment in time. And practically speaking seven hex digits can easily
have collisions in the hear future (ie it already happens with many
commits).

So telling git "give me a minimum of 12 hex digits in hash
abbreviations" should be fairly safe for a while.

I guess I should ping Junio and see if we can just change the default,
but for smaller projects the default abbreviation is likely still
reasonable. So I've been just mentioning that simple "set core.abbrev
to 12" to kernel people..

  Linus

Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing

[Linus Torvalds]

On Sun, Sep 25, 2016 at 5:49 PM, Rik van Riel  wrote:
>
> Reading the code for a little bit, it looks like get_user_pages
> interprets both PROT_NONE and PAGE_NUMA ptes as present, and will
> simply return the page to the caller.

So the thing is, I don't think the code should even get that far.

It should just fail in check_vma_flags() (possibly after doing the
fast-lookup of the page tables, but that would fail with PROT_NONE).

But thanks to FOLL_FORCE, it doesn't. So things that actually use the
page array and prot_none can get access to the underlying data.

 Linus

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Minchan Kim]

On Sun, Sep 25, 2016 at 12:18:49PM -0700, Shaohua Li wrote:
> On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote:
> > Rik van Riel  writes:
> > 
> > > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote:
> > >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
> > >> > 
> > >> > - It will help the memory fragmentation, especially when the THP is
> > >> >   heavily used by the applications.  The 2M continuous pages will
> > >> > be
> > >> >   free up after THP swapping out.
> > >> 
> > >> So this is impossible without THP swapin. While 2M swapout makes a
> > >> lot of
> > >> sense, I doubt 2M swapin is really useful. What kind of application
> > >> is
> > >> 'optimized' to do sequential memory access?
> > >
> > > I suspect a lot of this will depend on the ratio of storage
> > > speed to CPU & RAM speed.
> > >
> > > When swapping to a spinning disk, it makes sense to avoid
> > > extra memory use on swapin, and work in 4kB blocks.
> > 
> > For spinning disk, the THP swap optimization will be turned off in
> > current implementation.  Because huge swap cluster allocation based on
> > swap cluster management, which is available only for non-rotating block
> > devices (blk_queue_nonrot()).
> 
> For 2m swapin, as long as one byte is changed in the 2m, next time we must do
> 2m swapout. There is huge waste of memory and IO bandwidth and increases
> unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD

I agree. No doubt THP swapout is helpful for overall performance but
THP swapin should be more careful. It would cause memory pressure which
could evict warm pages which mitigates THP's benefit. THP swapin also
would increase minor fault latency, too.

If we want to swap in a THP, I think we need something to guarantee that
subpages in a THP swapped out were hot and temporal locality so that
it's worth to swap in a THP page to lose other memory kept in in memory.

Maybe it would not matter so much in MADVISE mode where userspace knows
pros and cons and choosed it. The problem would be there in ALWAYS mode.

One of idea is we can raise bar to collapse THP page higher, for example,
reducing khugepaged_max_ptes_none and introducing khugepaged_max_pte_ref.
With that, khugepaged would collapse 4K pages into a THP only if most of
subpages are mapped and hot.

Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing

[Linus Torvalds]

On Sun, Sep 25, 2016 at 5:49 PM, Rik van Riel  wrote:
>
> Reading the code for a little bit, it looks like get_user_pages
> interprets both PROT_NONE and PAGE_NUMA ptes as present, and will
> simply return the page to the caller.

So the thing is, I don't think the code should even get that far.

It should just fail in check_vma_flags() (possibly after doing the
fast-lookup of the page tables, but that would fail with PROT_NONE).

But thanks to FOLL_FORCE, it doesn't. So things that actually use the
page array and prot_none can get access to the underlying data.

 Linus

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

[Minchan Kim]

On Sun, Sep 25, 2016 at 12:18:49PM -0700, Shaohua Li wrote:
> On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote:
> > Rik van Riel  writes:
> > 
> > > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote:
> > >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote:
> > >> > 
> > >> > - It will help the memory fragmentation, especially when the THP is
> > >> >   heavily used by the applications.  The 2M continuous pages will
> > >> > be
> > >> >   free up after THP swapping out.
> > >> 
> > >> So this is impossible without THP swapin. While 2M swapout makes a
> > >> lot of
> > >> sense, I doubt 2M swapin is really useful. What kind of application
> > >> is
> > >> 'optimized' to do sequential memory access?
> > >
> > > I suspect a lot of this will depend on the ratio of storage
> > > speed to CPU & RAM speed.
> > >
> > > When swapping to a spinning disk, it makes sense to avoid
> > > extra memory use on swapin, and work in 4kB blocks.
> > 
> > For spinning disk, the THP swap optimization will be turned off in
> > current implementation.  Because huge swap cluster allocation based on
> > swap cluster management, which is available only for non-rotating block
> > devices (blk_queue_nonrot()).
> 
> For 2m swapin, as long as one byte is changed in the 2m, next time we must do
> 2m swapout. There is huge waste of memory and IO bandwidth and increases
> unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD

I agree. No doubt THP swapout is helpful for overall performance but
THP swapin should be more careful. It would cause memory pressure which
could evict warm pages which mitigates THP's benefit. THP swapin also
would increase minor fault latency, too.

If we want to swap in a THP, I think we need something to guarantee that
subpages in a THP swapped out were hot and temporal locality so that
it's worth to swap in a THP page to lose other memory kept in in memory.

Maybe it would not matter so much in MADVISE mode where userspace knows
pros and cons and choosed it. The problem would be there in ALWAYS mode.

One of idea is we can raise bar to collapse THP page higher, for example,
reducing khugepaged_max_ptes_none and introducing khugepaged_max_pte_ref.
With that, khugepaged would collapse 4K pages into a THP only if most of
subpages are mapped and hot.

Re: [PATCH] f2fs: remove dirty inode pages in error path

[Chao Yu]

On 2016/9/25 1:47, Jaegeuk Kim wrote:
> On Sat, Sep 24, 2016 at 09:02:02AM +0800, Chao Yu wrote:
>> On 2016/9/24 5:11, Jaegeuk Kim wrote:
>>> When getting EIO while handling orphan inodes, we can get some dirty node
>>> pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try
>>> to flush node pages. But in this case, we should prevent to do that, since
>>> we will try again from the start.
>>
>> We are protected since we set SBI_POR_DOING flag in sb, so we are safe now?
> 
> Safe, but we get an infinite loop to flush node pages.

Got it.

Thanks,

> 
>>
>> Thanks,
> 
> .
> 

Re: [PATCH 2/3] f2fs: support checkpoint error injection

[Chao Yu]

On 2016/9/25 2:10, Jaegeuk Kim wrote:
> On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote:
>> On 2016/9/24 8:52, Jaegeuk Kim wrote:
>>> On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote:
 Hi Jaegeuk,

 On 2016/9/24 7:53, Jaegeuk Kim wrote:
> Hi Chao,
>
> The basic rule is to stop every operations once CP_ERROR_FLAG is set.
> But, this patch simply breaks the rule.
> For example, f2fs_write_data_page() currently exits with 
> mapping_set_error().
> So this patch incurs missing dentry blocks in a valid checkpoint.

 Yes, that's right.

 How about triggering checkpoint error in f2fs_stop_checkpoint?
>>>
>>> Let's just use src/godown in xfstests, since we don't need to trigger this
>>> multiple times in runtime.
>>
>> After we inject checkpoint error into f2fs at first time, all write IOs will 
>> be
>> refused to be writebacked to storage, meanwhile read IOs can continuously go
>> through f2fs, so with checkpoint error injection being supported, we can 
>> support
>> to trigger random analogously power off by f2fs itself, instead of using 
>> tools.
>> It means it doesn't needs specified test cases where we must use godown 
>> ioctl,
>> but with normal testcases in xfstest/fsstress/lkp, in CP error injection 
>> enabled
>> f2fs, we can test power off cases.
> 
> But, in this approach, the test coverage would be quite limited.
> In my testcase, I'm randomly injecting godown while fsstress is running, which
> mimics really random power failures, as I believe. I'm running this infinitely
> with fscking at every run.
> 
> Anyway, in order to do this without godown, how about background_gc thread to
> trigger f2fs_stop_checkpoint?

Yeap, better.

What do you think of adding random f2fs_stop_checkpoint in f2fs_balance_fs?
power off can be triggered if gc thread is not running.

Thanks,

> 
>>
>> Thanks,
> 
> .
> 

Re: [PATCH] f2fs: remove dirty inode pages in error path

[Chao Yu]

On 2016/9/25 1:47, Jaegeuk Kim wrote:
> On Sat, Sep 24, 2016 at 09:02:02AM +0800, Chao Yu wrote:
>> On 2016/9/24 5:11, Jaegeuk Kim wrote:
>>> When getting EIO while handling orphan inodes, we can get some dirty node
>>> pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try
>>> to flush node pages. But in this case, we should prevent to do that, since
>>> we will try again from the start.
>>
>> We are protected since we set SBI_POR_DOING flag in sb, so we are safe now?
> 
> Safe, but we get an infinite loop to flush node pages.

Got it.

Thanks,

> 
>>
>> Thanks,
> 
> .
> 

Re: [PATCH 2/3] f2fs: support checkpoint error injection

[Chao Yu]

On 2016/9/25 2:10, Jaegeuk Kim wrote:
> On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote:
>> On 2016/9/24 8:52, Jaegeuk Kim wrote:
>>> On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote:
 Hi Jaegeuk,

 On 2016/9/24 7:53, Jaegeuk Kim wrote:
> Hi Chao,
>
> The basic rule is to stop every operations once CP_ERROR_FLAG is set.
> But, this patch simply breaks the rule.
> For example, f2fs_write_data_page() currently exits with 
> mapping_set_error().
> So this patch incurs missing dentry blocks in a valid checkpoint.

 Yes, that's right.

 How about triggering checkpoint error in f2fs_stop_checkpoint?
>>>
>>> Let's just use src/godown in xfstests, since we don't need to trigger this
>>> multiple times in runtime.
>>
>> After we inject checkpoint error into f2fs at first time, all write IOs will 
>> be
>> refused to be writebacked to storage, meanwhile read IOs can continuously go
>> through f2fs, so with checkpoint error injection being supported, we can 
>> support
>> to trigger random analogously power off by f2fs itself, instead of using 
>> tools.
>> It means it doesn't needs specified test cases where we must use godown 
>> ioctl,
>> but with normal testcases in xfstest/fsstress/lkp, in CP error injection 
>> enabled
>> f2fs, we can test power off cases.
> 
> But, in this approach, the test coverage would be quite limited.
> In my testcase, I'm randomly injecting godown while fsstress is running, which
> mimics really random power failures, as I believe. I'm running this infinitely
> with fscking at every run.
> 
> Anyway, in order to do this without godown, how about background_gc thread to
> trigger f2fs_stop_checkpoint?

Yeap, better.

What do you think of adding random f2fs_stop_checkpoint in f2fs_balance_fs?
power off can be triggered if gc thread is not running.

Thanks,

> 
>>
>> Thanks,
> 
> .
> 

Re: [PATCH V2] staging: rtl8172: usb_intf.c: Fixed block comment coding style

[Larry Finger]

On 09/25/2016 06:00 PM, Gonçalo Salazar wrote:

Fixed a block comment indentation in the rtl8712 usb_intf.c file.
Made this as a first commit.
Resubmitted with updated subject.

Please let me know of any feedback you have.


I missed this last time, but everything above the --- line goes into the 
permanent record. Are you sure you want all this to be there? Any chatty remarks 
and any description of what changed in subsequent submissions should be below 
the ---. The maintainer will see them, but they are stripped before they get 
merged into the repo.


Larry



Thanks,
Gonçalo Salazar

Signed-off-by: Gonçalo Salazar 
---
 drivers/staging/rtl8712/usb_intf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/usb_intf.c 
b/drivers/staging/rtl8712/usb_intf.c
index 3fc65b2..897d462 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -369,7 +369,7 @@ static const struct device_type wlan_type = {
  *
  * notes: drv_init() is called when the bus driver has located a card for us
  * to support. We accept the new device by returning 0.
-*/
+ */
 static int r871xu_drv_init(struct usb_interface *pusb_intf,
   const struct usb_device_id *pdid)
 {

Re: [PATCH V2] staging: rtl8172: usb_intf.c: Fixed block comment coding style

[Larry Finger]

On 09/25/2016 06:00 PM, Gonçalo Salazar wrote:

Fixed a block comment indentation in the rtl8712 usb_intf.c file.
Made this as a first commit.
Resubmitted with updated subject.

Please let me know of any feedback you have.


I missed this last time, but everything above the --- line goes into the 
permanent record. Are you sure you want all this to be there? Any chatty remarks 
and any description of what changed in subsequent submissions should be below 
the ---. The maintainer will see them, but they are stripped before they get 
merged into the repo.


Larry



Thanks,
Gonçalo Salazar

Signed-off-by: Gonçalo Salazar 
---
 drivers/staging/rtl8712/usb_intf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/usb_intf.c 
b/drivers/staging/rtl8712/usb_intf.c
index 3fc65b2..897d462 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -369,7 +369,7 @@ static const struct device_type wlan_type = {
  *
  * notes: drv_init() is called when the bus driver has located a card for us
  * to support. We accept the new device by returning 0.
-*/
+ */
 static int r871xu_drv_init(struct usb_interface *pusb_intf,
   const struct usb_device_id *pdid)
 {