Re: [PATCH] kbuild: remove KBUILD_SUBDIR_ASFLAGS and KBUILD_SUBDIR_CCFLAGS

[Cao jin]

On 10/10/2017 07:43 PM, Masahiro Yamada wrote:
> Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS.
> Remove KBUILD_SUBDIR_{AS,CC}FLAGS.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/Makefile.lib | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 9bbb019..bc63f17a 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -5,8 +5,8 @@ cppflags-y += $(EXTRA_CPPFLAGS)
>  ldflags-y  += $(EXTRA_LDFLAGS)
>  
>  # flags that take effect in current and sub directories
> -export KBUILD_SUBDIR_ASFLAGS := $(KBUILD_SUBDIR_ASFLAGS) $(subdir-asflags-y)
> -export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y)
> +KBUILD_AFLAGS += $(subdir-asflags-y)
> +KBUILD_CFLAGS += $(subdir-ccflags-y)
>  
>  # Figure out what we need to build from the various variables
>  # ===
> @@ -94,10 +94,10 @@ basename_flags = -DKBUILD_BASENAME=$(call 
> name-fix,$(basetarget))
>  modname_flags  = $(if $(filter 1,$(words $(modname))),\
>   -DKBUILD_MODNAME=$(call name-fix,$(modname)))
>  
> -orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) 
> $(KBUILD_SUBDIR_CCFLAGS) \
> +orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) \
>   $(ccflags-y) $(CFLAGS_$(basetarget).o)
>  _c_flags   = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), 
> $(orig_c_flags))
> -orig_a_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_AFLAGS) 
> $(KBUILD_SUBDIR_ASFLAGS) \
> +orig_a_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_AFLAGS) \
>   $(asflags-y) $(AFLAGS_$(basetarget).o)
>  _a_flags   = $(filter-out $(AFLAGS_REMOVE_$(basetarget).o), 
> $(orig_a_flags))
>  _cpp_flags = $(KBUILD_CPPFLAGS) $(cppflags-y) $(CPPFLAGS_$(@F))
> 

I also think the KBUILD_SUBDIR_{AS,CC}FLAGS is unnecessary when I came
to this part. So FWIW:

Reviewed-by: Cao jin 
-- 
Sincerely,
Cao jin

Re: [PATCH] kbuild: remove KBUILD_SUBDIR_ASFLAGS and KBUILD_SUBDIR_CCFLAGS

[Cao jin]

On 10/10/2017 07:43 PM, Masahiro Yamada wrote:
> Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS.
> Remove KBUILD_SUBDIR_{AS,CC}FLAGS.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/Makefile.lib | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 9bbb019..bc63f17a 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -5,8 +5,8 @@ cppflags-y += $(EXTRA_CPPFLAGS)
>  ldflags-y  += $(EXTRA_LDFLAGS)
>  
>  # flags that take effect in current and sub directories
> -export KBUILD_SUBDIR_ASFLAGS := $(KBUILD_SUBDIR_ASFLAGS) $(subdir-asflags-y)
> -export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y)
> +KBUILD_AFLAGS += $(subdir-asflags-y)
> +KBUILD_CFLAGS += $(subdir-ccflags-y)
>  
>  # Figure out what we need to build from the various variables
>  # ===
> @@ -94,10 +94,10 @@ basename_flags = -DKBUILD_BASENAME=$(call 
> name-fix,$(basetarget))
>  modname_flags  = $(if $(filter 1,$(words $(modname))),\
>   -DKBUILD_MODNAME=$(call name-fix,$(modname)))
>  
> -orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) 
> $(KBUILD_SUBDIR_CCFLAGS) \
> +orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) \
>   $(ccflags-y) $(CFLAGS_$(basetarget).o)
>  _c_flags   = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), 
> $(orig_c_flags))
> -orig_a_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_AFLAGS) 
> $(KBUILD_SUBDIR_ASFLAGS) \
> +orig_a_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_AFLAGS) \
>   $(asflags-y) $(AFLAGS_$(basetarget).o)
>  _a_flags   = $(filter-out $(AFLAGS_REMOVE_$(basetarget).o), 
> $(orig_a_flags))
>  _cpp_flags = $(KBUILD_CPPFLAGS) $(cppflags-y) $(CPPFLAGS_$(@F))
> 

I also think the KBUILD_SUBDIR_{AS,CC}FLAGS is unnecessary when I came
to this part. So FWIW:

Reviewed-by: Cao jin 
-- 
Sincerely,
Cao jin

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

[Kai-Heng Feng]

On Fri, Sep 22, 2017 at 4:27 PM, Kai-Heng Feng
 wrote:
> On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when
> battery is full and AC is plugged.
>
> However rate_now is correct under this circumstance, hence we can use
> "rate_now == 0" as a predicate to report battery full status correctly.
>
> BugLink: https://bugs.launchpad.net/bugs/1482390
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/acpi/battery.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 13e7b56e33ae..f9f008cf3da7 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -70,6 +70,7 @@ static async_cookie_t async_cookie;
>  static bool battery_driver_registered;
>  static int battery_bix_broken_package;
>  static int battery_notification_delay_ms;
> +static int battery_full_discharging;
>  static unsigned int cache_time = 1000;
>  module_param(cache_time, uint, 0644);
>  MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
> @@ -214,7 +215,10 @@ static int acpi_battery_get_property(struct power_supply 
> *psy,
> return -ENODEV;
> switch (psp) {
> case POWER_SUPPLY_PROP_STATUS:
> -   if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> +   if (battery_full_discharging && battery->rate_now == 0 &&
> +   battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> +   val->intval = POWER_SUPPLY_STATUS_FULL;
> +   else if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
> val->intval = POWER_SUPPLY_STATUS_CHARGING;
> @@ -1166,6 +1170,13 @@ battery_notification_delay_quirk(const struct 
> dmi_system_id *d)
> return 0;
>  }
>
> +static int __init
> +battery_full_discharging_quirk(const struct dmi_system_id *d)
> +{
> +   battery_full_discharging = 1;
> +   return 0;
> +}
> +
>  static const struct dmi_system_id bat_dmi_table[] __initconst = {
> {
> .callback = battery_bix_broken_package_quirk,
> @@ -1183,6 +1194,22 @@ static const struct dmi_system_id bat_dmi_table[] 
> __initconst = {
> DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-573G"),
> },
> },
> +   {
> +   .callback = battery_full_discharging_quirk,
> +   .ident = "ASUS GL502VSK",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "GL502VSK"),
> +   },
> +   },
> +   {
> +   .callback = battery_full_discharging_quirk,
> +   .ident = "ASUS UX305LA",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
> +   },
> +   },
> {},
>  };
>

Hi,

Is there any improvement I can make for this patch?

> --
> 2.14.1
>

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

[Kai-Heng Feng]

On Fri, Sep 22, 2017 at 4:27 PM, Kai-Heng Feng
 wrote:
> On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when
> battery is full and AC is plugged.
>
> However rate_now is correct under this circumstance, hence we can use
> "rate_now == 0" as a predicate to report battery full status correctly.
>
> BugLink: https://bugs.launchpad.net/bugs/1482390
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/acpi/battery.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 13e7b56e33ae..f9f008cf3da7 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -70,6 +70,7 @@ static async_cookie_t async_cookie;
>  static bool battery_driver_registered;
>  static int battery_bix_broken_package;
>  static int battery_notification_delay_ms;
> +static int battery_full_discharging;
>  static unsigned int cache_time = 1000;
>  module_param(cache_time, uint, 0644);
>  MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
> @@ -214,7 +215,10 @@ static int acpi_battery_get_property(struct power_supply 
> *psy,
> return -ENODEV;
> switch (psp) {
> case POWER_SUPPLY_PROP_STATUS:
> -   if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> +   if (battery_full_discharging && battery->rate_now == 0 &&
> +   battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> +   val->intval = POWER_SUPPLY_STATUS_FULL;
> +   else if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
> val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
> val->intval = POWER_SUPPLY_STATUS_CHARGING;
> @@ -1166,6 +1170,13 @@ battery_notification_delay_quirk(const struct 
> dmi_system_id *d)
> return 0;
>  }
>
> +static int __init
> +battery_full_discharging_quirk(const struct dmi_system_id *d)
> +{
> +   battery_full_discharging = 1;
> +   return 0;
> +}
> +
>  static const struct dmi_system_id bat_dmi_table[] __initconst = {
> {
> .callback = battery_bix_broken_package_quirk,
> @@ -1183,6 +1194,22 @@ static const struct dmi_system_id bat_dmi_table[] 
> __initconst = {
> DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-573G"),
> },
> },
> +   {
> +   .callback = battery_full_discharging_quirk,
> +   .ident = "ASUS GL502VSK",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "GL502VSK"),
> +   },
> +   },
> +   {
> +   .callback = battery_full_discharging_quirk,
> +   .ident = "ASUS UX305LA",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
> +   },
> +   },
> {},
>  };
>

Hi,

Is there any improvement I can make for this patch?

> --
> 2.14.1
>

Re: [PATCH v6 2/4] perf tools arm64: Add support for get_cpuid_str function.

[Ganapatrao Kulkarni]

On Wed, Oct 11, 2017 at 5:43 PM, Will Deacon  wrote:
> On Thu, Aug 24, 2017 at 05:33:47PM +0530, Ganapatrao Kulkarni wrote:
>> function get_cpuid_str returns MIDR string of the first online
>> cpu from the range of cpus associated with the pmu core device.
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  tools/perf/arch/arm64/util/Build|  1 +
>>  tools/perf/arch/arm64/util/header.c | 60 
>> +
>>  2 files changed, 61 insertions(+)
>>  create mode 100644 tools/perf/arch/arm64/util/header.c
>>
>> diff --git a/tools/perf/arch/arm64/util/Build 
>> b/tools/perf/arch/arm64/util/Build
>> index cef6fb3..b1ab72d 100644
>> --- a/tools/perf/arch/arm64/util/Build
>> +++ b/tools/perf/arch/arm64/util/Build
>> @@ -1,3 +1,4 @@
>> +libperf-y += header.o
>>  libperf-$(CONFIG_DWARF) += dwarf-regs.o
>>  libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
>>
>> diff --git a/tools/perf/arch/arm64/util/header.c 
>> b/tools/perf/arch/arm64/util/header.c
>> new file mode 100644
>> index 000..f02a32e
>> --- /dev/null
>> +++ b/tools/perf/arch/arm64/util/header.c
>> @@ -0,0 +1,60 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include "header.h"
>> +
>> +#define MIDR "/regs/identification/midr_el1"
>> +#define MIDR_SIZE 19
>> +
>> +char *get_cpuid_str(struct perf_pmu *pmu)
>> +{
>> + char *buf = NULL;
>> + char path[PATH_MAX];
>> + const char *sysfs = sysfs__mountpoint();
>> + int cpu;
>> + u64 midr = 0;
>> + struct cpu_map *cpus;
>> + FILE *file;
>> +
>> + if (!sysfs || !pmu->cpus)
>> + return NULL;
>> +
>> + buf = malloc(MIDR_SIZE);
>> + if (!buf)
>> + return NULL;
>> +
>> + /* read midr from list of cpus mapped to this pmu */
>> + cpus = cpu_map__get(pmu->cpus);
>> + for (cpu = 0; cpu < cpus->nr; cpu++) {
>> + scnprintf(path, PATH_MAX, "%s/devices/system/cpu/cpu%d"MIDR,
>> + sysfs, cpus->map[cpu]);
>> +
>> + file = fopen(path, "r");
>> + if (!file) {
>> + pr_debug("fopen failed for file %s\n", path);
>> + continue;
>> + }
>> +
>> + if (!fgets(buf, MIDR_SIZE, file))
>> + continue;
>> + fclose(file);
>
> Don't you want to fclose the file if the fgets fails?

thanks.
>
>> +
>> + /* Ignore/clear Variant[23:20] and
>> +  * Revision[3:0] of MIDR
>> +  */
>> + midr = strtoul(buf, NULL, 16);
>> + midr &= (~(0xf << 20 | 0xf));
>
> It would be cleaner if you had #defines for the MIDR fields that you're
> masking.

ok, i can add it.
I felt, it is not to required, since it is not used anywhere else and
for better code readability.

>
>> + scnprintf(buf, MIDR_SIZE, "0x%016lx", midr);
>> + /* got midr break loop */
>> + break;
>> + }
>> +
>> + if (!midr) {
>> + pr_err("failed to get cpuid string\n");
>
> Might be helpful to print the PMU name and the CPU map if there's a way
> to do that.

ok, i can print name,  need to check for cpu map.
>
> Will

thanks
Ganapat

Re: [PATCH v6 2/4] perf tools arm64: Add support for get_cpuid_str function.

[Ganapatrao Kulkarni]

On Wed, Oct 11, 2017 at 5:43 PM, Will Deacon  wrote:
> On Thu, Aug 24, 2017 at 05:33:47PM +0530, Ganapatrao Kulkarni wrote:
>> function get_cpuid_str returns MIDR string of the first online
>> cpu from the range of cpus associated with the pmu core device.
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  tools/perf/arch/arm64/util/Build|  1 +
>>  tools/perf/arch/arm64/util/header.c | 60 
>> +
>>  2 files changed, 61 insertions(+)
>>  create mode 100644 tools/perf/arch/arm64/util/header.c
>>
>> diff --git a/tools/perf/arch/arm64/util/Build 
>> b/tools/perf/arch/arm64/util/Build
>> index cef6fb3..b1ab72d 100644
>> --- a/tools/perf/arch/arm64/util/Build
>> +++ b/tools/perf/arch/arm64/util/Build
>> @@ -1,3 +1,4 @@
>> +libperf-y += header.o
>>  libperf-$(CONFIG_DWARF) += dwarf-regs.o
>>  libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
>>
>> diff --git a/tools/perf/arch/arm64/util/header.c 
>> b/tools/perf/arch/arm64/util/header.c
>> new file mode 100644
>> index 000..f02a32e
>> --- /dev/null
>> +++ b/tools/perf/arch/arm64/util/header.c
>> @@ -0,0 +1,60 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include "header.h"
>> +
>> +#define MIDR "/regs/identification/midr_el1"
>> +#define MIDR_SIZE 19
>> +
>> +char *get_cpuid_str(struct perf_pmu *pmu)
>> +{
>> + char *buf = NULL;
>> + char path[PATH_MAX];
>> + const char *sysfs = sysfs__mountpoint();
>> + int cpu;
>> + u64 midr = 0;
>> + struct cpu_map *cpus;
>> + FILE *file;
>> +
>> + if (!sysfs || !pmu->cpus)
>> + return NULL;
>> +
>> + buf = malloc(MIDR_SIZE);
>> + if (!buf)
>> + return NULL;
>> +
>> + /* read midr from list of cpus mapped to this pmu */
>> + cpus = cpu_map__get(pmu->cpus);
>> + for (cpu = 0; cpu < cpus->nr; cpu++) {
>> + scnprintf(path, PATH_MAX, "%s/devices/system/cpu/cpu%d"MIDR,
>> + sysfs, cpus->map[cpu]);
>> +
>> + file = fopen(path, "r");
>> + if (!file) {
>> + pr_debug("fopen failed for file %s\n", path);
>> + continue;
>> + }
>> +
>> + if (!fgets(buf, MIDR_SIZE, file))
>> + continue;
>> + fclose(file);
>
> Don't you want to fclose the file if the fgets fails?

thanks.
>
>> +
>> + /* Ignore/clear Variant[23:20] and
>> +  * Revision[3:0] of MIDR
>> +  */
>> + midr = strtoul(buf, NULL, 16);
>> + midr &= (~(0xf << 20 | 0xf));
>
> It would be cleaner if you had #defines for the MIDR fields that you're
> masking.

ok, i can add it.
I felt, it is not to required, since it is not used anywhere else and
for better code readability.

>
>> + scnprintf(buf, MIDR_SIZE, "0x%016lx", midr);
>> + /* got midr break loop */
>> + break;
>> + }
>> +
>> + if (!midr) {
>> + pr_err("failed to get cpuid string\n");
>
> Might be helpful to print the PMU name and the CPU map if there's a way
> to do that.

ok, i can print name,  need to check for cpu map.
>
> Will

thanks
Ganapat

Re: Add hierarchical irq_domain for i2c based gpio expander pca9505

[Abhishek Shah]

+BCM kernel feedback.
Sorry for duplicated mails, had HTML formatting issue.

On Wed, Oct 11, 2017 at 5:50 PM, Abhishek Shah
 wrote:
> Hi Linus,
>
> I am facing one issue, where; while disabling/ masking interrupts just
> before kexec reboot, access to gpio expander pca9505 residing over
> i2c bus hangs, because i2c interrupts are disabled prior to writing
> pca9505 register.
>
> In our chip, we have 3 irq_domain, namely gicv3, bcm-iproc-gpio [GPIO
> controller with ~150 pins] and pca953x [40-pin IO expander pca9505].
>
> bcm-iproc-gpio and i2c interrupts among the other interrupts  are
> registered to gicv3 and
> pca953x interrupts are registered to bcm-iproc-gpio.
>
> So, interrupt from pca953x gets routed like...
> pca953x-> bcm-iproc-gpio-> gicv3
>
> Now, I see that, got GPIO controllers, an independent IRQ domain is
> added using gpiochip_irqchip_add_nested
> or gpiochip_irqchip_add, which makes use of irq_domain_add_simple like this:
> gpiochip->irqdomain = irq_domain_add_simple(of_node,
> gpiochip->ngpio, first_irq,
> _domain_ops, gpiochip);
>
> Is it possible to add hierarchical irq_domain for pca953x to be child
> of bcm-iproc-gpio and bcm-iproc-gpio irq_domain  to be child of gicv3
> using irq_domain_add_hierarchy instead of current  irq_domain_add_simple API??
>
> Would that make sure that first all interrupts of child irq_domain
> gets disabled?
>
>
> Now, this is where I am facing issue during kexec_reboot:
>
> static void machine_kexec_mask_interrupts(void)  /*
> function is present in arch/arm64/kernel/machine_kexec.c file */
> {
> unsigned int i;
> struct irq_desc *desc;
>
> for_each_irq_desc(i, desc) {
> struct irq_chip *chip;
> int ret;
>
> chip = irq_desc_get_chip(desc);
> if (!chip)
> continue;
>
> /*
>  * First try to remove the active state. If this
>  * fails, try to EOI the interrupt.
>  */
> ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE,
> false);   /* access to PCA9505 register hangs here and kexec reboot
> fails! */
>
> if (ret && irqd_irq_inprogress(>irq_data) &&
> chip->irq_eoi)
> chip->irq_eoi(>irq_data);
>
> if (chip->irq_mask)
> chip->irq_mask(>irq_data);
>
> if (chip->irq_disable && !irqd_irq_disabled(>irq_data))
> chip->irq_disable(>irq_data);
> }
> }
>
> In my case, when this loop runs, initially it masks all GICv3
> interrupts,i.e. i2c interrupts are also disabled.
> Now when irq_set_irqchip_state gets executed in process of masking
> pca9505 interrupts, .irq_bus_sync_unlock
> callback (pca953x_irq_bus_sync_unlock) hangs because i2c interrupts are 
> masked.
>
> Do you think adding "irq_domain_add_hierarchy" for GPIO controllers
> can solve this problem?
> or do you suggest change in the way "machine_kexec_mask_interrupts" is
> implemented?
>
>
> Regards,
> Abhishek

Re: Add hierarchical irq_domain for i2c based gpio expander pca9505

[Abhishek Shah]

+BCM kernel feedback.
Sorry for duplicated mails, had HTML formatting issue.

On Wed, Oct 11, 2017 at 5:50 PM, Abhishek Shah
 wrote:
> Hi Linus,
>
> I am facing one issue, where; while disabling/ masking interrupts just
> before kexec reboot, access to gpio expander pca9505 residing over
> i2c bus hangs, because i2c interrupts are disabled prior to writing
> pca9505 register.
>
> In our chip, we have 3 irq_domain, namely gicv3, bcm-iproc-gpio [GPIO
> controller with ~150 pins] and pca953x [40-pin IO expander pca9505].
>
> bcm-iproc-gpio and i2c interrupts among the other interrupts  are
> registered to gicv3 and
> pca953x interrupts are registered to bcm-iproc-gpio.
>
> So, interrupt from pca953x gets routed like...
> pca953x-> bcm-iproc-gpio-> gicv3
>
> Now, I see that, got GPIO controllers, an independent IRQ domain is
> added using gpiochip_irqchip_add_nested
> or gpiochip_irqchip_add, which makes use of irq_domain_add_simple like this:
> gpiochip->irqdomain = irq_domain_add_simple(of_node,
> gpiochip->ngpio, first_irq,
> _domain_ops, gpiochip);
>
> Is it possible to add hierarchical irq_domain for pca953x to be child
> of bcm-iproc-gpio and bcm-iproc-gpio irq_domain  to be child of gicv3
> using irq_domain_add_hierarchy instead of current  irq_domain_add_simple API??
>
> Would that make sure that first all interrupts of child irq_domain
> gets disabled?
>
>
> Now, this is where I am facing issue during kexec_reboot:
>
> static void machine_kexec_mask_interrupts(void)  /*
> function is present in arch/arm64/kernel/machine_kexec.c file */
> {
> unsigned int i;
> struct irq_desc *desc;
>
> for_each_irq_desc(i, desc) {
> struct irq_chip *chip;
> int ret;
>
> chip = irq_desc_get_chip(desc);
> if (!chip)
> continue;
>
> /*
>  * First try to remove the active state. If this
>  * fails, try to EOI the interrupt.
>  */
> ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE,
> false);   /* access to PCA9505 register hangs here and kexec reboot
> fails! */
>
> if (ret && irqd_irq_inprogress(>irq_data) &&
> chip->irq_eoi)
> chip->irq_eoi(>irq_data);
>
> if (chip->irq_mask)
> chip->irq_mask(>irq_data);
>
> if (chip->irq_disable && !irqd_irq_disabled(>irq_data))
> chip->irq_disable(>irq_data);
> }
> }
>
> In my case, when this loop runs, initially it masks all GICv3
> interrupts,i.e. i2c interrupts are also disabled.
> Now when irq_set_irqchip_state gets executed in process of masking
> pca9505 interrupts, .irq_bus_sync_unlock
> callback (pca953x_irq_bus_sync_unlock) hangs because i2c interrupts are 
> masked.
>
> Do you think adding "irq_domain_add_hierarchy" for GPIO controllers
> can solve this problem?
> or do you suggest change in the way "machine_kexec_mask_interrupts" is
> implemented?
>
>
> Regards,
> Abhishek

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

[Masami Hiramatsu]

On Tue, 10 Oct 2017 22:32:31 +0530
"Naveen N. Rao"  wrote:

> On 2017/09/19 10:00AM, Masami Hiramatsu wrote:
> > Warn if optprobe handler tries to change execution path.
> > As described in Documentation/kprobes.txt, with optprobe
> > user handler can not change instruction pointer. In that
> > case user must avoid optimizing the kprobes by setting
> > post_handler or break_handler.
> 
> But, if the pre handler returns !0, does that necessarily mean that the 
> [n]ip has been modified?

It should be prohibited to be jump optimized.

> 
> In Documentation/kprobes.txt, under API Reference for register_kprobe, 
> we have:
>   User's pre-handler (kp->pre_handler)::
> 
> #include 
> #include 
> int pre_handler(struct kprobe *p, struct pt_regs *regs);
> 
>   Called with p pointing to the kprobe associated with the breakpoint,
>   and regs pointing to the struct containing the registers saved when
>   the breakpoint was hit.  Return 0 here unless you're a Kprobes geek.
>  ^^

Yeah, this part should be updated clearly. 
Actually, you can find below NOTE also in Documentation/kprobes.txt in the
end of "How Does Jump Optimization Work?"

=
NOTE for geeks:
The jump optimization changes the kprobe's pre_handler behavior.
Without optimization, the pre_handler can change the kernel's execution
path by changing regs->ip and returning 1.  However, when the probe
is optimized, that modification is ignored.  Thus, if you want to
tweak the kernel's execution path, you need to suppress optimization,
using one of the following techniques:

- Specify an empty function for the kprobe's post_handler or break_handler.

or

- Execute 'sysctl -w debug.kprobes_optimization=n'
=

> So, we don't seem to _require_ users to return !0 if the handler changes 
> [n]ip? Or to always change [n]ip if returning !0.
> 
> The implicit assumption seems to be that the handler returns !0 if it 
> wants to suppress executing the probed instruction since the handler has 
> already taken care of that. So, at the least, I think the message should 
> change. However...
> 
> In powerpc, we place a probe on kretprobe_trampoline and optimize it. 

Oh, what did you do?? I think kretprobe_trampoline just calls
its handler to get correct address to return and just return to it.

> This works for us (even though optprobes doesn't "honour" changes to 
> [n]ip). See commit 762df10bad6954 ("powerpc/kprobes: Optimize kprobe in 
> kretprobe_trampoline()"). With this patch, we are now seeing a warning 
> (thanks to mpe for the report):
> 
> [  520.19] [ cut here ]
> [  520.144676] WARNING: CPU: 2 PID: 6355 at kernel/kprobes.c:391 
> opt_pre_handler+0xe8/0x110
> ...
> [  520.151806] CPU: 2 PID: 6355 Comm: ftracetest Not tainted 
> 4.14.0-rc4-gcc6-next-20171009-g49827b9 #1
> [  520.152097] task: c000e9ddfb80 task.stack: c000f881c000
> [  520.152291] NIP:  c01f3b78 LR: c01f3b2c CTR: 
> c02436a0
> [  520.152527] REGS: c000f881f7f0 TRAP: 0700   Not tainted  
> (4.14.0-rc4-gcc6-next-20171009-g49827b9)
> [  520.152818] MSR:  800100021033   CR: 24002824 
>  XER: 2000
> [  520.153080] CFAR: c01f3b34 SOFTE: 0
> ...
> [  520.155113] NIP [c01f3b78] opt_pre_handler+0xe8/0x110
> [  520.155320] LR [c01f3b2c] opt_pre_handler+0x9c/0x110
> [  520.155510] Call Trace:
> [  520.155590] [c000f881fa70] [c01f3b2c] 
> opt_pre_handler+0x9c/0x110 (unreliable)
> [  520.155825] [c000f881fb00] [c0047de8] 
> optimized_callback+0xc8/0xe0
> [  520.156047] [c000f881fb40] [c0048764] optinsn_slot+0xec/0x1
> [  520.156238] [c000f881fe30] [c0046cb0] 
> kretprobe_trampoline+0x0/0x10
> [  520.156452] Instruction dump:
> [  520.156570] 7fbef840 409effa4 38210090 e8010010 eb41ffd0 eb61ffd8 eb81ffe0 
> eba1ffe8
> [  520.156792] ebc1fff0 ebe1fff8 7c0803a6 4e800020 <0fe0> e89e0028 
> 3c62ffce 386362b0
> [  520.157016] ---[ end trace d8cda029528a560d ]---
> [  520.157172] Optprobe ignores instruction pointer 
> changing.(kretprobe_trampoline+0x0/0x10)
> 
> 
> So, should this patch be reverted?

Hmm, I got it. It seems to depend on arch implementation.
Anyway, this is just adding an warning, we can safely revert it.
And the documentation should be updated.

Ingo, could you revert this change?

Thank you,

> 
> 
> - Naveen
> 


-- 
Masami Hiramatsu 

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

[Masami Hiramatsu]

On Tue, 10 Oct 2017 22:32:31 +0530
"Naveen N. Rao"  wrote:

> On 2017/09/19 10:00AM, Masami Hiramatsu wrote:
> > Warn if optprobe handler tries to change execution path.
> > As described in Documentation/kprobes.txt, with optprobe
> > user handler can not change instruction pointer. In that
> > case user must avoid optimizing the kprobes by setting
> > post_handler or break_handler.
> 
> But, if the pre handler returns !0, does that necessarily mean that the 
> [n]ip has been modified?

It should be prohibited to be jump optimized.

> 
> In Documentation/kprobes.txt, under API Reference for register_kprobe, 
> we have:
>   User's pre-handler (kp->pre_handler)::
> 
> #include 
> #include 
> int pre_handler(struct kprobe *p, struct pt_regs *regs);
> 
>   Called with p pointing to the kprobe associated with the breakpoint,
>   and regs pointing to the struct containing the registers saved when
>   the breakpoint was hit.  Return 0 here unless you're a Kprobes geek.
>  ^^

Yeah, this part should be updated clearly. 
Actually, you can find below NOTE also in Documentation/kprobes.txt in the
end of "How Does Jump Optimization Work?"

=
NOTE for geeks:
The jump optimization changes the kprobe's pre_handler behavior.
Without optimization, the pre_handler can change the kernel's execution
path by changing regs->ip and returning 1.  However, when the probe
is optimized, that modification is ignored.  Thus, if you want to
tweak the kernel's execution path, you need to suppress optimization,
using one of the following techniques:

- Specify an empty function for the kprobe's post_handler or break_handler.

or

- Execute 'sysctl -w debug.kprobes_optimization=n'
=

> So, we don't seem to _require_ users to return !0 if the handler changes 
> [n]ip? Or to always change [n]ip if returning !0.
> 
> The implicit assumption seems to be that the handler returns !0 if it 
> wants to suppress executing the probed instruction since the handler has 
> already taken care of that. So, at the least, I think the message should 
> change. However...
> 
> In powerpc, we place a probe on kretprobe_trampoline and optimize it. 

Oh, what did you do?? I think kretprobe_trampoline just calls
its handler to get correct address to return and just return to it.

> This works for us (even though optprobes doesn't "honour" changes to 
> [n]ip). See commit 762df10bad6954 ("powerpc/kprobes: Optimize kprobe in 
> kretprobe_trampoline()"). With this patch, we are now seeing a warning 
> (thanks to mpe for the report):
> 
> [  520.19] [ cut here ]
> [  520.144676] WARNING: CPU: 2 PID: 6355 at kernel/kprobes.c:391 
> opt_pre_handler+0xe8/0x110
> ...
> [  520.151806] CPU: 2 PID: 6355 Comm: ftracetest Not tainted 
> 4.14.0-rc4-gcc6-next-20171009-g49827b9 #1
> [  520.152097] task: c000e9ddfb80 task.stack: c000f881c000
> [  520.152291] NIP:  c01f3b78 LR: c01f3b2c CTR: 
> c02436a0
> [  520.152527] REGS: c000f881f7f0 TRAP: 0700   Not tainted  
> (4.14.0-rc4-gcc6-next-20171009-g49827b9)
> [  520.152818] MSR:  800100021033   CR: 24002824 
>  XER: 2000
> [  520.153080] CFAR: c01f3b34 SOFTE: 0
> ...
> [  520.155113] NIP [c01f3b78] opt_pre_handler+0xe8/0x110
> [  520.155320] LR [c01f3b2c] opt_pre_handler+0x9c/0x110
> [  520.155510] Call Trace:
> [  520.155590] [c000f881fa70] [c01f3b2c] 
> opt_pre_handler+0x9c/0x110 (unreliable)
> [  520.155825] [c000f881fb00] [c0047de8] 
> optimized_callback+0xc8/0xe0
> [  520.156047] [c000f881fb40] [c0048764] optinsn_slot+0xec/0x1
> [  520.156238] [c000f881fe30] [c0046cb0] 
> kretprobe_trampoline+0x0/0x10
> [  520.156452] Instruction dump:
> [  520.156570] 7fbef840 409effa4 38210090 e8010010 eb41ffd0 eb61ffd8 eb81ffe0 
> eba1ffe8
> [  520.156792] ebc1fff0 ebe1fff8 7c0803a6 4e800020 <0fe0> e89e0028 
> 3c62ffce 386362b0
> [  520.157016] ---[ end trace d8cda029528a560d ]---
> [  520.157172] Optprobe ignores instruction pointer 
> changing.(kretprobe_trampoline+0x0/0x10)
> 
> 
> So, should this patch be reverted?

Hmm, I got it. It seems to depend on arch implementation.
Anyway, this is just adding an warning, we can safely revert it.
And the documentation should be updated.

Ingo, could you revert this change?

Thank you,

> 
> 
> - Naveen
> 


-- 
Masami Hiramatsu 

Re: [PATCH 00/11] KASan for arm

[Liuwenliang (Lamb)]

On 10/12/2017 12:10 AM, Abbott Liu wrote:
>On 10/11/2017 12:50 PM, Florian Fainelli wrote:
>> On 10/11/2017 12:13 PM, Florian Fainelli wrote:
>>> Hi Abbott,
>>>
>>> On 10/11/2017 01:22 AM, Abbott Liu wrote:
 Hi,all:
These patches add arch specific code for kernel address sanitizer
 (see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
 big enough hole for this, so virtual addresses for shadow were
 stolen from user space.

At early boot stage the whole shadow region populated with just
 one physical page (kasan_zero_page). Later, this page reused
 as readonly zero shadow for some memory that KASan currently
 don't track (vmalloc).

   After mapping the physical memory, pages for shadow memory are
 allocated and mapped.

   KASan's stack instrumentation significantly increases stack's
 consumption, so CONFIG_KASAN doubles THREAD_SIZE.

   Functions like memset/memmove/memcpy do a lot of memory accesses.
 If bad pointer passed to one of these function it is important
 to catch this. Compiler's instrumentation cannot do this since
 these functions are written in assembly.

   KASan replaces memory functions with manually instrumented variants.
 Original functions declared as weak symbols so strong definitions
 in mm/kasan/kasan.c could replace them. Original functions have aliases
 with '__' prefix in name, so we could call non-instrumented variant
 if needed.

   Some files built without kasan instrumentation (e.g. mm/slub.c).
 Original mem* function replaced (via #define) with prefixed variants
 to disable memory access checks for such files.

   On arm LPAE architecture,  the mapping table of KASan shadow memory(if
 PAGE_OFFSET is 0xc000, the KASan shadow memory's virtual space is
 0xb6e00~0xbf00) can't be filled in do_translation_fault function,
 because kasan instrumentation maybe cause do_translation_fault function
 accessing KASan shadow memory. The accessing of KASan shadow memory in
 do_translation_fault function maybe cause dead circle. So the mapping table
 of KASan shadow memory need be copyed in pgd_alloc function.


 Most of the code comes from:
 https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
>>>
>>> Thanks for putting these patches together, I can't get a kernel to build
>>> with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:
>>>
>>>   AS  arch/arm/kernel/entry-common.o
>>> arch/arm/kernel/entry-common.S: Assembler messages:
>>> arch/arm/kernel/entry-common.S:53: Error: invalid constant
>>> (b6e0) after fixup
>>> arch/arm/kernel/entry-common.S:118: Error: invalid constant
>>> (b6e0) after fixup
>>> scripts/Makefile.build:412: recipe for target
>>> 'arch/arm/kernel/entry-common.o' failed
>>> make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
>>> Makefile:1019: recipe for target 'arch/arm/kernel' failed
>>> make[2]: *** [arch/arm/kernel] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>>
>>> This is coming from the increase in TASK_SIZE it seems.
>>>
>>> This is on top of v4.14-rc4-84-gff5abbe799e2
>>
>> Seems like we can use the following to get through that build failure:
>>
>> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
>> index 99c908226065..0de1160d136e 100644
>> --- a/arch/arm/kernel/entry-common.S
>> +++ b/arch/arm/kernel/entry-common.S
>> @@ -50,7 +50,13 @@ ret_fast_syscall:
>>   UNWIND(.cantunwind)
>> disable_irq_notrace @ disable interrupts
>> ldr r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +   movwr1, #:lower16:TASK_SIZE
>> +   movtr1, #:upper16:TASK_SIZE
>> +   cmp r2, r1
>> +#else
>> cmp r2, #TASK_SIZE
>> +#endif
>> blneaddr_limit_check_failed
>> ldr r1, [tsk, #TI_FLAGS]@ re-check for syscall
>> tracing
>> tst r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
>> @@ -115,7 +121,13 @@ ret_slow_syscall:
>> disable_irq_notrace @ disable interrupts
>>  ENTRY(ret_to_user_from_irq)
>> ldr r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +   movwr1, #:lower16:TASK_SIZE
>> +   movtr1, #:upper16:TASK_SIZE
>> +   cmp r2, r1
>> +#else
>> cmp r2, #TASK_SIZE
>> +#endif
>> blneaddr_limit_check_failed
>> ldr r1, [tsk, #TI_FLAGS]
>> tst r1, #_TIF_WORK_MASK
>>
>>
>>
>> but then we will see another set of build failures with the decompressor
>> code:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>   KSYM.tmp_kallsyms1.o
>>   KSYM.tmp_kallsyms2.o
>>   LD  vmlinux
>>   SORTEX  vmlinux
>>   

Re: [PATCH 00/11] KASan for arm

[Liuwenliang (Lamb)]

On 10/12/2017 12:10 AM, Abbott Liu wrote:
>On 10/11/2017 12:50 PM, Florian Fainelli wrote:
>> On 10/11/2017 12:13 PM, Florian Fainelli wrote:
>>> Hi Abbott,
>>>
>>> On 10/11/2017 01:22 AM, Abbott Liu wrote:
 Hi,all:
These patches add arch specific code for kernel address sanitizer
 (see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
 big enough hole for this, so virtual addresses for shadow were
 stolen from user space.

At early boot stage the whole shadow region populated with just
 one physical page (kasan_zero_page). Later, this page reused
 as readonly zero shadow for some memory that KASan currently
 don't track (vmalloc).

   After mapping the physical memory, pages for shadow memory are
 allocated and mapped.

   KASan's stack instrumentation significantly increases stack's
 consumption, so CONFIG_KASAN doubles THREAD_SIZE.

   Functions like memset/memmove/memcpy do a lot of memory accesses.
 If bad pointer passed to one of these function it is important
 to catch this. Compiler's instrumentation cannot do this since
 these functions are written in assembly.

   KASan replaces memory functions with manually instrumented variants.
 Original functions declared as weak symbols so strong definitions
 in mm/kasan/kasan.c could replace them. Original functions have aliases
 with '__' prefix in name, so we could call non-instrumented variant
 if needed.

   Some files built without kasan instrumentation (e.g. mm/slub.c).
 Original mem* function replaced (via #define) with prefixed variants
 to disable memory access checks for such files.

   On arm LPAE architecture,  the mapping table of KASan shadow memory(if
 PAGE_OFFSET is 0xc000, the KASan shadow memory's virtual space is
 0xb6e00~0xbf00) can't be filled in do_translation_fault function,
 because kasan instrumentation maybe cause do_translation_fault function
 accessing KASan shadow memory. The accessing of KASan shadow memory in
 do_translation_fault function maybe cause dead circle. So the mapping table
 of KASan shadow memory need be copyed in pgd_alloc function.


 Most of the code comes from:
 https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
>>>
>>> Thanks for putting these patches together, I can't get a kernel to build
>>> with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:
>>>
>>>   AS  arch/arm/kernel/entry-common.o
>>> arch/arm/kernel/entry-common.S: Assembler messages:
>>> arch/arm/kernel/entry-common.S:53: Error: invalid constant
>>> (b6e0) after fixup
>>> arch/arm/kernel/entry-common.S:118: Error: invalid constant
>>> (b6e0) after fixup
>>> scripts/Makefile.build:412: recipe for target
>>> 'arch/arm/kernel/entry-common.o' failed
>>> make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
>>> Makefile:1019: recipe for target 'arch/arm/kernel' failed
>>> make[2]: *** [arch/arm/kernel] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>>
>>> This is coming from the increase in TASK_SIZE it seems.
>>>
>>> This is on top of v4.14-rc4-84-gff5abbe799e2
>>
>> Seems like we can use the following to get through that build failure:
>>
>> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
>> index 99c908226065..0de1160d136e 100644
>> --- a/arch/arm/kernel/entry-common.S
>> +++ b/arch/arm/kernel/entry-common.S
>> @@ -50,7 +50,13 @@ ret_fast_syscall:
>>   UNWIND(.cantunwind)
>> disable_irq_notrace @ disable interrupts
>> ldr r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +   movwr1, #:lower16:TASK_SIZE
>> +   movtr1, #:upper16:TASK_SIZE
>> +   cmp r2, r1
>> +#else
>> cmp r2, #TASK_SIZE
>> +#endif
>> blneaddr_limit_check_failed
>> ldr r1, [tsk, #TI_FLAGS]@ re-check for syscall
>> tracing
>> tst r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
>> @@ -115,7 +121,13 @@ ret_slow_syscall:
>> disable_irq_notrace @ disable interrupts
>>  ENTRY(ret_to_user_from_irq)
>> ldr r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +   movwr1, #:lower16:TASK_SIZE
>> +   movtr1, #:upper16:TASK_SIZE
>> +   cmp r2, r1
>> +#else
>> cmp r2, #TASK_SIZE
>> +#endif
>> blneaddr_limit_check_failed
>> ldr r1, [tsk, #TI_FLAGS]
>> tst r1, #_TIF_WORK_MASK
>>
>>
>>
>> but then we will see another set of build failures with the decompressor
>> code:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>   KSYM.tmp_kallsyms1.o
>>   KSYM.tmp_kallsyms2.o
>>   LD  vmlinux
>>   SORTEX  vmlinux
>>   

Re: [PATCH v6 4/4] perf vendor events arm64: Add ThunderX2 implementation defined pmu core events

[Ganapatrao Kulkarni]

On Wed, Oct 11, 2017 at 7:25 PM, Will Deacon  wrote:
> On Wed, Oct 11, 2017 at 03:24:31PM +0200, Robert Richter wrote:
>> On 11.10.17 13:19:27, Will Deacon wrote:
>> > On Tue, Aug 29, 2017 at 02:47:30PM +0200, Robert Richter wrote:
>> > > Shaokun,
>> > >
>> > > On 29.08.17 17:26:00, Zhangshaokun wrote:
>> > > > On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>> > > > > This is not a full event list, but a short list of useful events.
>> > > > >
>> > > > > Signed-off-by: Ganapatrao Kulkarni 
>> > > > > ---
>> > > > >  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>> > > > >  .../arm64/thunderx2/implementation-defined.json| 62 
>> > > > > ++
>> > > > >  2 files changed, 77 insertions(+)
>> > > > >  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>> > > > >  create mode 100644 
>> > > > > tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>> > > > >
>> > > >
>> > > > I saw you also used thunderx2 in tools/perf/pmu-events/arch/arm64/, 
>> > > > how about John's suggestion
>> > > > that would use vendor sub-folder?
>> > > > Of course, appreciate maintainer's comments.
>> > >
>> > > this would just add another level of subdirectories. I rather would
>> > > prefer to have a per platform dir comparable to what is listed in
>> > >
>> > >  arch/arm64/Kconfig.platforms
>> > >
>> > > This is the same as Ganapat has implemented it.
>> >
>> > FWIW, I agree with Zhangshaokun here that a silicon vendor subdirectory
>> > would organise things better. It also matches what we do for
>> > arch/arm64/boot/dts/
>>
>> A file structure like:
>>
>>  
>> tools/perf/pmu-events/arch/arm64/cavium/thunderx2/implementation-defined.json
>>
>> looks quite horible. In contrast to dts dir we will need another
>> subdir for each platform and will then have two levels of subdirs.
>
> In which case, call the file thunderx2-imp-def.json or something. The
> advantage then is that the SoC names are namespaced by vendor, which is
> the best way to avoid confusion imo.

thanks, i can rename json file as suggested.

>
> Will

thanks
Ganapat

Re: [PATCH v6 4/4] perf vendor events arm64: Add ThunderX2 implementation defined pmu core events

[Ganapatrao Kulkarni]

On Wed, Oct 11, 2017 at 7:25 PM, Will Deacon  wrote:
> On Wed, Oct 11, 2017 at 03:24:31PM +0200, Robert Richter wrote:
>> On 11.10.17 13:19:27, Will Deacon wrote:
>> > On Tue, Aug 29, 2017 at 02:47:30PM +0200, Robert Richter wrote:
>> > > Shaokun,
>> > >
>> > > On 29.08.17 17:26:00, Zhangshaokun wrote:
>> > > > On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>> > > > > This is not a full event list, but a short list of useful events.
>> > > > >
>> > > > > Signed-off-by: Ganapatrao Kulkarni 
>> > > > > ---
>> > > > >  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>> > > > >  .../arm64/thunderx2/implementation-defined.json| 62 
>> > > > > ++
>> > > > >  2 files changed, 77 insertions(+)
>> > > > >  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>> > > > >  create mode 100644 
>> > > > > tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>> > > > >
>> > > >
>> > > > I saw you also used thunderx2 in tools/perf/pmu-events/arch/arm64/, 
>> > > > how about John's suggestion
>> > > > that would use vendor sub-folder?
>> > > > Of course, appreciate maintainer's comments.
>> > >
>> > > this would just add another level of subdirectories. I rather would
>> > > prefer to have a per platform dir comparable to what is listed in
>> > >
>> > >  arch/arm64/Kconfig.platforms
>> > >
>> > > This is the same as Ganapat has implemented it.
>> >
>> > FWIW, I agree with Zhangshaokun here that a silicon vendor subdirectory
>> > would organise things better. It also matches what we do for
>> > arch/arm64/boot/dts/
>>
>> A file structure like:
>>
>>  
>> tools/perf/pmu-events/arch/arm64/cavium/thunderx2/implementation-defined.json
>>
>> looks quite horible. In contrast to dts dir we will need another
>> subdir for each platform and will then have two levels of subdirs.
>
> In which case, call the file thunderx2-imp-def.json or something. The
> advantage then is that the SoC names are namespaced by vendor, which is
> the best way to avoid confusion imo.

thanks, i can rename json file as suggested.

>
> Will

thanks
Ganapat

[PATCH v2 0/4] TDA1997x HDMI video receiver

[Tim Harvey]

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver.

I've tested this on a Gateworks GW54xx with an IMX6Q which uses the TDA19971
with 16bits connected to the IMX6 CSI. For this configuration I've tested
both 16bit YUV422 and 8bit BT656 mode. While the driver should support the
TDA1993 I do not have one for testing.

Further potential development efforts include:
 - CEC support
 - HDCP support
 - mbus format selection support for bus widths that support multiple formats
 - TDA19972 support (2 inputs)

History:
v2:
 - encorporate feedback into dt bindings
 - change audio dt bindings
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - added media-ctl and v4l2-compliance details

v1:
 - initial RFC

Media device topology:
# media-ctl -d /dev/media0 -p
Media controller API version 4.13.0

Media device information

driver  imx-media
model   imx-media
serial  
bus info
hw revision 0x0
driver version  4.13.0

Device topology
- entity 1: adv7180 2-0020 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 20004
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
-> "ipu2_csi1_mux":1 []

- entity 3: tda19971 2-0048 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Source
[fmt:UYVY8_1X16/0x0]
[dv.caps:BT.656/1120 min:640x480@1300 
max:1920x1080@16500 stds:CEA-861,DMT caps:progressive]
[dv.query:no-link]
[dv.current:BT.656/1120 0x0p0 (0x0) stds: flags:]
-> "ipu1_csi0_mux":1 [ENABLED]

- entity 5: ipu1_vdic (3 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
pad1: Sink
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
pad2: Source
[fmt:AYUV8_1X32/640x480@1/60 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prp":0 []

- entity 9: ipu2_vdic (3 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu2_csi0":1 []
<- "ipu2_csi1":1 []
pad1: Sink
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
pad2: Source
[fmt:AYUV8_1X32/640x480@1/60 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu2_ic_prp":0 []

- entity 13: ipu1_ic_prp (3 pads, 5 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev4
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_vdic":2 []
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpenc":0 []
pad2: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpvf":0 []

- entity 17: ipu1_ic_prpenc (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev5
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_ic_prp":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpenc capture":0 []

- entity 20: ipu1_ic_prpenc capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video0
pad0: Sink
<- "ipu1_ic_prpenc":1 []

- entity 26: ipu1_ic_prpvf (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev6
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 

[PATCH v2 0/4] TDA1997x HDMI video receiver

[Tim Harvey]

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver.

I've tested this on a Gateworks GW54xx with an IMX6Q which uses the TDA19971
with 16bits connected to the IMX6 CSI. For this configuration I've tested
both 16bit YUV422 and 8bit BT656 mode. While the driver should support the
TDA1993 I do not have one for testing.

Further potential development efforts include:
 - CEC support
 - HDCP support
 - mbus format selection support for bus widths that support multiple formats
 - TDA19972 support (2 inputs)

History:
v2:
 - encorporate feedback into dt bindings
 - change audio dt bindings
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - added media-ctl and v4l2-compliance details

v1:
 - initial RFC

Media device topology:
# media-ctl -d /dev/media0 -p
Media controller API version 4.13.0

Media device information

driver  imx-media
model   imx-media
serial  
bus info
hw revision 0x0
driver version  4.13.0

Device topology
- entity 1: adv7180 2-0020 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 20004
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
-> "ipu2_csi1_mux":1 []

- entity 3: tda19971 2-0048 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Source
[fmt:UYVY8_1X16/0x0]
[dv.caps:BT.656/1120 min:640x480@1300 
max:1920x1080@16500 stds:CEA-861,DMT caps:progressive]
[dv.query:no-link]
[dv.current:BT.656/1120 0x0p0 (0x0) stds: flags:]
-> "ipu1_csi0_mux":1 [ENABLED]

- entity 5: ipu1_vdic (3 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
pad1: Sink
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
pad2: Source
[fmt:AYUV8_1X32/640x480@1/60 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prp":0 []

- entity 9: ipu2_vdic (3 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu2_csi0":1 []
<- "ipu2_csi1":1 []
pad1: Sink
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
pad2: Source
[fmt:AYUV8_1X32/640x480@1/60 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu2_ic_prp":0 []

- entity 13: ipu1_ic_prp (3 pads, 5 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev4
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_vdic":2 []
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpenc":0 []
pad2: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpvf":0 []

- entity 17: ipu1_ic_prpenc (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev5
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
<- "ipu1_ic_prp":1 []
pad1: Source
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 quantization:lim-range]
-> "ipu1_ic_prpenc capture":0 []

- entity 20: ipu1_ic_prpenc capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video0
pad0: Sink
<- "ipu1_ic_prpenc":1 []

- entity 26: ipu1_ic_prpvf (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev6
pad0: Sink
[fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m 
xfer:709 ycbcr:601 

[PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X

[Tim Harvey]

Cc: Rob Herring 
Signed-off-by: Tim Harvey 
---
v2:
 - add vendor prefix and remove _ from vidout-portcfg
 - remove _ from labels
 - remove max-pixel-rate property
 - describe and provide example for single output port
 - use new audio port bindings

---
 .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
 1 file changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..269d7f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety fo connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible  :
+  - "nxp,tda19971" for the TDA19971
+  - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts  : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
+ mclk.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+  The following three properties are defined in video-interfaces.txt and
+  are valid for source endpoints only:
+  - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+  - vsync-active: Vertical synchronization polarity. Defaults to active high.
+  - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+   hdmi-receiver@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p8v>;
+   /* audio */
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same pixclk cycle.
+*/
+   nxp,vidout-portcfg =
+   /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
+   < TDA1997X_VP24_V07_04 

[PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X

[Tim Harvey]

Cc: Rob Herring 
Signed-off-by: Tim Harvey 
---
v2:
 - add vendor prefix and remove _ from vidout-portcfg
 - remove _ from labels
 - remove max-pixel-rate property
 - describe and provide example for single output port
 - use new audio port bindings

---
 .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
 1 file changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..269d7f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety fo connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible  :
+  - "nxp,tda19971" for the TDA19971
+  - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts  : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
+ mclk.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+  The following three properties are defined in video-interfaces.txt and
+  are valid for source endpoints only:
+  - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+  - vsync-active: Vertical synchronization polarity. Defaults to active high.
+  - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+   hdmi-receiver@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p8v>;
+   /* audio */
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same pixclk cycle.
+*/
+   nxp,vidout-portcfg =
+   /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /* 

[PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

Add support for the TDA1997x HDMI receivers.

Cc: Hans Verkuil 
Signed-off-by: Tim Harvey 
---
v2:
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - use new audio bindings

---
 drivers/media/i2c/Kconfig|9 +
 drivers/media/i2c/Makefile   |1 +
 drivers/media/i2c/tda1997x.c | 3336 ++
 include/dt-bindings/media/tda1997x.h |   78 +
 include/media/i2c/tda1997x.h |   53 +
 5 files changed, 3477 insertions(+)
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 include/dt-bindings/media/tda1997x.h
 create mode 100644 include/media/i2c/tda1997x.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9415389..c2b0400 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
  To compile this driver as a module, choose M here: the
  module will be called tda9840.
 
+config VIDEO_TDA1997X
+   tristate "NXP TDA1997x HDMI receiver"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
 config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c843c18..58f2b2e 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
 obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..bf06684
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,3336 @@
+/*
+ * Copyright (C) 2017 Gateworks Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* debug level */
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+/* Page 0x00 - General Control */
+#define REG_VERSION0x
+#define REG_INPUT_SEL  0x0001
+#define REG_SVC_MODE   0x0002
+#define REG_HPD_MAN_CTRL   0x0003
+#define REG_RT_MAN_CTRL0x0004
+#define REG_STANDBY_SOFT_RST   0x000A
+#define REG_HDMI_SOFT_RST  0x000B
+#define REG_HDMI_INFO_RST  0x000C
+#define REG_INT_FLG_CLR_TOP0x000E
+#define REG_INT_FLG_CLR_SUS0x000F
+#define REG_INT_FLG_CLR_DDC0x0010
+#define REG_INT_FLG_CLR_RATE   0x0011
+#define REG_INT_FLG_CLR_MODE   0x0012
+#define REG_INT_FLG_CLR_INFO   0x0013
+#define REG_INT_FLG_CLR_AUDIO  0x0014
+#define REG_INT_FLG_CLR_HDCP   0x0015
+#define REG_INT_FLG_CLR_AFE0x0016
+#define REG_INT_MASK_TOP   0x0017
+#define REG_INT_MASK_SUS   0x0018
+#define REG_INT_MASK_DDC   0x0019
+#define REG_INT_MASK_RATE  0x001A
+#define REG_INT_MASK_MODE  0x001B
+#define REG_INT_MASK_INFO  0x001C
+#define REG_INT_MASK_AUDIO 0x001D
+#define REG_INT_MASK_HDCP  0x001E
+#define REG_INT_MASK_AFE   0x001F
+#define REG_DETECT_5V  0x0020
+#define REG_SUS_STATUS 0x0021
+#define REG_V_PER  0x0022
+#define REG_H_PER  0x0025
+#define REG_HS_WIDTH   0x0027
+#define REG_FMT_H_TOT  0x0029
+#define REG_FMT_H_ACT  0x002b
+#define REG_FMT_H_FRONT0x002d
+#define REG_FMT_H_SYNC 0x002f
+#define REG_FMT_H_BACK 0x0031
+#define REG_FMT_V_TOT  0x0033
+#define REG_FMT_V_ACT  0x0035
+#define REG_FMT_V_FRONT_F1 0x0037
+#define REG_FMT_V_FRONT_F2 0x0038
+#define REG_FMT_V_SYNC 0x0039
+#define REG_FMT_V_BACK_F1  0x003a
+#define REG_FMT_V_BACK_F2  0x003b
+#define REG_FMT_DE_ACT 0x003c
+#define REG_RATE_CTRL  0x0040
+#define REG_CLK_MIN_RATE   0x0043
+#define REG_CLK_MAX_RATE   0x0046
+#define REG_CLK_A_STATUS   0x0049
+#define REG_CLK_A_RATE 0x004A
+#define REG_DRIFT_CLK_A_REG0x004D
+#define REG_CLK_B_STATUS 

[PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

Add support for the TDA1997x HDMI receivers.

Cc: Hans Verkuil 
Signed-off-by: Tim Harvey 
---
v2:
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - use new audio bindings

---
 drivers/media/i2c/Kconfig|9 +
 drivers/media/i2c/Makefile   |1 +
 drivers/media/i2c/tda1997x.c | 3336 ++
 include/dt-bindings/media/tda1997x.h |   78 +
 include/media/i2c/tda1997x.h |   53 +
 5 files changed, 3477 insertions(+)
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 include/dt-bindings/media/tda1997x.h
 create mode 100644 include/media/i2c/tda1997x.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9415389..c2b0400 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
  To compile this driver as a module, choose M here: the
  module will be called tda9840.
 
+config VIDEO_TDA1997X
+   tristate "NXP TDA1997x HDMI receiver"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
 config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c843c18..58f2b2e 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
 obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..bf06684
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,3336 @@
+/*
+ * Copyright (C) 2017 Gateworks Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* debug level */
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+/* Page 0x00 - General Control */
+#define REG_VERSION0x
+#define REG_INPUT_SEL  0x0001
+#define REG_SVC_MODE   0x0002
+#define REG_HPD_MAN_CTRL   0x0003
+#define REG_RT_MAN_CTRL0x0004
+#define REG_STANDBY_SOFT_RST   0x000A
+#define REG_HDMI_SOFT_RST  0x000B
+#define REG_HDMI_INFO_RST  0x000C
+#define REG_INT_FLG_CLR_TOP0x000E
+#define REG_INT_FLG_CLR_SUS0x000F
+#define REG_INT_FLG_CLR_DDC0x0010
+#define REG_INT_FLG_CLR_RATE   0x0011
+#define REG_INT_FLG_CLR_MODE   0x0012
+#define REG_INT_FLG_CLR_INFO   0x0013
+#define REG_INT_FLG_CLR_AUDIO  0x0014
+#define REG_INT_FLG_CLR_HDCP   0x0015
+#define REG_INT_FLG_CLR_AFE0x0016
+#define REG_INT_MASK_TOP   0x0017
+#define REG_INT_MASK_SUS   0x0018
+#define REG_INT_MASK_DDC   0x0019
+#define REG_INT_MASK_RATE  0x001A
+#define REG_INT_MASK_MODE  0x001B
+#define REG_INT_MASK_INFO  0x001C
+#define REG_INT_MASK_AUDIO 0x001D
+#define REG_INT_MASK_HDCP  0x001E
+#define REG_INT_MASK_AFE   0x001F
+#define REG_DETECT_5V  0x0020
+#define REG_SUS_STATUS 0x0021
+#define REG_V_PER  0x0022
+#define REG_H_PER  0x0025
+#define REG_HS_WIDTH   0x0027
+#define REG_FMT_H_TOT  0x0029
+#define REG_FMT_H_ACT  0x002b
+#define REG_FMT_H_FRONT0x002d
+#define REG_FMT_H_SYNC 0x002f
+#define REG_FMT_H_BACK 0x0031
+#define REG_FMT_V_TOT  0x0033
+#define REG_FMT_V_ACT  0x0035
+#define REG_FMT_V_FRONT_F1 0x0037
+#define REG_FMT_V_FRONT_F2 0x0038
+#define REG_FMT_V_SYNC 0x0039
+#define REG_FMT_V_BACK_F1  0x003a
+#define REG_FMT_V_BACK_F2  0x003b
+#define REG_FMT_DE_ACT 0x003c
+#define REG_RATE_CTRL  0x0040
+#define REG_CLK_MIN_RATE   0x0043
+#define REG_CLK_MAX_RATE   0x0046
+#define REG_CLK_A_STATUS   0x0049
+#define REG_CLK_A_RATE 0x004A
+#define REG_DRIFT_CLK_A_REG0x004D
+#define REG_CLK_B_STATUS   0x004E
+#define REG_CLK_B_RATE   

[PATCH v2 4/4] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.

Signed-off-by: Tim Harvey 
---
v2:
 - use new audio bindings
 - add HDMI audio input support

---
 arch/arm/boot/dts/imx6q-gw54xx.dts| 102 ++
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |  29 +-
 2 files changed, 128 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..99dac63 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,27 @@
 /dts-v1/;
 #include "imx6q.dtsi"
 #include "imx6qdl-gw54xx.dtsi"
+#include 
 
 / {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+   cpu {
+   sound-dai = <>;
+   };
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
 };
 
  {
@@ -35,6 +52,61 @@
};
};
};
+
+   tda1997x: codec@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
 _csi1_from_ipu2_csi1_mux {
@@ -63,6 +135,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+  

[PATCH v2 1/4] MAINTAINERS: add entry for NXP TDA1997x driver

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2093060..de7124e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13019,6 +13019,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/tda18271*
 
+TDA1997x MEDIA DRIVER
+M: Tim Harvey 
+L: linux-me...@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/i2c/tda1997x.*
+
 TDA827x MEDIA DRIVER
 M: Michael Krufky 
 L: linux-me...@vger.kernel.org
-- 
2.7.4

[PATCH v2 4/4] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.

Signed-off-by: Tim Harvey 
---
v2:
 - use new audio bindings
 - add HDMI audio input support

---
 arch/arm/boot/dts/imx6q-gw54xx.dts| 102 ++
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |  29 +-
 2 files changed, 128 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..99dac63 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,27 @@
 /dts-v1/;
 #include "imx6q.dtsi"
 #include "imx6qdl-gw54xx.dtsi"
+#include 
 
 / {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+   cpu {
+   sound-dai = <>;
+   };
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
 };
 
  {
@@ -35,6 +52,61 @@
};
};
};
+
+   tda1997x: codec@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
 _csi1_from_ipu2_csi1_mux {
@@ -63,6 +135,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+   

[PATCH v2 1/4] MAINTAINERS: add entry for NXP TDA1997x driver

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2093060..de7124e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13019,6 +13019,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/tda18271*
 
+TDA1997x MEDIA DRIVER
+M: Tim Harvey 
+L: linux-me...@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/i2c/tda1997x.*
+
 TDA827x MEDIA DRIVER
 M: Michael Krufky 
 L: linux-me...@vger.kernel.org
-- 
2.7.4

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

IATU unroll feature can be enabled in EP mode as well, so we need to
have this check in pcie-designware-ep.c, so instead of making this
function as static in pcie-desigware-host.c, let's move this in
pcie-designware.c so that both pcie-designware-host.c and
pcie-designware-ep.c can use it.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/dwc/pcie-designware-ep.c   |  4 
 drivers/pci/dwc/pcie-designware-host.c | 11 ---
 drivers/pci/dwc/pcie-designware.c  | 11 +++
 drivers/pci/dwc/pcie-designware.h  |  1 +
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index d53d5f1..64803a9 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
 
+   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
+   dev_dbg(dev, "iATU unroll: %s\n",
+   pci->iatu_unroll_enabled ? "enabled" : "disabled");
+
epc = devm_pci_epc_create(dev, _ops);
if (IS_ERR(epc)) {
dev_err(dev, "failed to create epc device\n");
diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 81e2157..d3f579e 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
.write = dw_pcie_wr_conf,
 };
 
-static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
-{
-   u32 val;
-
-   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
-   if (val == 0x)
-   return 1;
-
-   return 0;
-}
-
 void dw_pcie_setup_rc(struct pcie_port *pp)
 {
u32 val;
diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..f15da90 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
*base, u32 reg,
dev_err(pci->dev, "write DBI address failed\n");
 }
 
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
+   if (val == 0x)
+   return 1;
+
+   return 0;
+}
+
 static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
 {
u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..8d6829c 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
 void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
 enum dw_pcie_region_type type);
 void dw_pcie_setup(struct dw_pcie *pci);
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
 
 static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
 {
-- 
2.7.4

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

IATU unroll feature can be enabled in EP mode as well, so we need to
have this check in pcie-designware-ep.c, so instead of making this
function as static in pcie-desigware-host.c, let's move this in
pcie-designware.c so that both pcie-designware-host.c and
pcie-designware-ep.c can use it.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/dwc/pcie-designware-ep.c   |  4 
 drivers/pci/dwc/pcie-designware-host.c | 11 ---
 drivers/pci/dwc/pcie-designware.c  | 11 +++
 drivers/pci/dwc/pcie-designware.h  |  1 +
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index d53d5f1..64803a9 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
 
+   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
+   dev_dbg(dev, "iATU unroll: %s\n",
+   pci->iatu_unroll_enabled ? "enabled" : "disabled");
+
epc = devm_pci_epc_create(dev, _ops);
if (IS_ERR(epc)) {
dev_err(dev, "failed to create epc device\n");
diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 81e2157..d3f579e 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
.write = dw_pcie_wr_conf,
 };
 
-static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
-{
-   u32 val;
-
-   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
-   if (val == 0x)
-   return 1;
-
-   return 0;
-}
-
 void dw_pcie_setup_rc(struct pcie_port *pp)
 {
u32 val;
diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..f15da90 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
*base, u32 reg,
dev_err(pci->dev, "write DBI address failed\n");
 }
 
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
+   if (val == 0x)
+   return 1;
+
+   return 0;
+}
+
 static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
 {
u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..8d6829c 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
 void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
 enum dw_pcie_region_type type);
 void dw_pcie_setup(struct dw_pcie *pci);
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
 
 static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
 {
-- 
2.7.4

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Kalle Valo]

Jes Sorensen  writes:

> On 10/11/2017 04:41 AM, Kalle Valo wrote:
>> Jes Sorensen  writes:
>>
>>> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
 In preparation to enabling -Wimplicit-fallthrough, mark switch cases
 where we are expecting to fall through.
>>>
>>> While this isn't harmful, to me this looks like pointless patch churn
>>> for zero gain and it's just ugly.
>>
>> In general I find it useful to mark fall through cases. And it's just a
>> comment with two words, so they cannot hurt your eyes that much.
>
> I don't see them being harmful in the code, but I don't see them of
> much use either. If it happened as part of natural code development,
> fine. My objection is to people running around doing this
> systematically causing patch churn for little to zero gain.

We do receive quite a lot these kind of cleanup patches found with
various analysers and tools. I guess one could classify those as churn
but I think the net result is still very much on the positive side. And
this patch in particular seems useful for me and I think we should take
it.

-- 
Kalle Valo

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

[Kalle Valo]

Jes Sorensen  writes:

> On 10/11/2017 04:41 AM, Kalle Valo wrote:
>> Jes Sorensen  writes:
>>
>>> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
 In preparation to enabling -Wimplicit-fallthrough, mark switch cases
 where we are expecting to fall through.
>>>
>>> While this isn't harmful, to me this looks like pointless patch churn
>>> for zero gain and it's just ugly.
>>
>> In general I find it useful to mark fall through cases. And it's just a
>> comment with two words, so they cannot hurt your eyes that much.
>
> I don't see them being harmful in the code, but I don't see them of
> much use either. If it happened as part of natural code development,
> fine. My objection is to people running around doing this
> systematically causing patch churn for little to zero gain.

We do receive quite a lot these kind of cleanup patches found with
various analysers and tools. I guess one could classify those as churn
but I think the net result is still very much on the positive side. And
this patch in particular seems useful for me and I think we should take
it.

-- 
Kalle Valo

[PATCH] x86: handle MSR exception when setting energy perf bias

[Gabriel Krisman Bertazi]

On very rare occasions, immediately after a suspend, one of our
SandyBridge CI boxes hits the exception below on CPU0 while trying to
reconfigure the energy bias register.  As far as I can tell, this is not
likely a race in the kernel, since we have only one cpu online, no
preempt and irqs_disabled, and it can only be reproduced in this
specific SNB-2600 on rare occasions.  It looks more of a faulty hardware
thing to me.

Still, we can handle this exception more gracefully to silence the CI,
by using the safe version of the msrl_read/write wrapper.

The log on the faulty box is as follows:

[  280.969486] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 
0x81030a4f (init_intel_energy_perf.part.3+0xf/0xb0)
[  280.969488] Call Trace:
[  280.969492]  intel_bsp_resume+0x1a/0x20
[  280.969494]  bsp_resume+0x1d/0x20
[  280.969498]  syscore_resume+0x62/0x320
[  280.969501]  suspend_devices_and_enter+0xa09/0xcd0
[  280.969506]  pm_suspend+0x574/0xa00
[  280.969509]  state_store+0x82/0xf0
[  280.969514]  kobj_attr_store+0xf/0x20
[  280.969516]  sysfs_kf_write+0x45/0x60
[  280.969519]  kernfs_fop_write+0x124/0x1c0
[  280.969524]  __vfs_write+0x28/0x130
[  280.969526]  ? rcu_read_lock_sched_held+0x7a/0x90
[  280.969528]  ? rcu_sync_lockdep_assert+0x2f/0x60
[  280.969531]  ? __sb_start_write+0x10c/0x200
[  280.969535]  vfs_write+0xc8/0x1c0
[  280.969538]  SyS_write+0x49/0xb0
[  280.969542]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  280.969544] RIP: 0033:0x7fb6721ce8f0
[  280.969546] RSP: 002b:7ffc3ac05da8 EFLAGS: 0246 ORIG_RAX: 
0001
[  280.969549] RAX: ffda RBX: 81489d83 RCX: 7fb6721ce8f0
[  280.969551] RDX: 0004 RSI: 5634312da060 RDI: 0007
[  280.969552] RBP: c90001147f88 R08: 5634312d7de0 R09: 7fb67269f700
[  280.969554] R10: 7fb672497b58 R11: 0246 R12: 5634312d7d00
[  280.969555] R13: 0001 R14: 0004 R15: 0004
[  280.969559]  ? __this_cpu_preempt_check+0x13/0x20
[  280.969566] unchecked MSR access error: WRMSR to 0x1b0 (tried to write 
0x0006) at rIP: 0x81030a8e 
(init_intel_energy_perf.part.3+0x4e/0xb0)
[  280.969567] Call Trace:
[  280.969569]  intel_bsp_resume+0x1a/0x20
[  280.969571]  bsp_resume+0x1d/0x20
[  280.969573]  syscore_resume+0x62/0x320
[  280.969576]  suspend_devices_and_enter+0xa09/0xcd0
[  280.969580]  pm_suspend+0x574/0xa00
[  280.969584]  state_store+0x82/0xf0
[  280.969587]  kobj_attr_store+0xf/0x20
[  280.969589]  sysfs_kf_write+0x45/0x60
[  280.969592]  kernfs_fop_write+0x124/0x1c0
[  280.969595]  __vfs_write+0x28/0x130
[  280.969597]  ? rcu_read_lock_sched_held+0x7a/0x90
[  280.969599]  ? rcu_sync_lockdep_assert+0x2f/0x60
[  280.969601]  ? __sb_start_write+0x10c/0x200
[  280.969605]  vfs_write+0xc8/0x1c0
[  280.969608]  SyS_write+0x49/0xb0
[  280.969612]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  280.969613] RIP: 0033:0x7fb6721ce8f0
[  280.969614] RSP: 002b:7ffc3ac05da8 EFLAGS: 0246 ORIG_RAX: 
0001
[  280.969617] RAX: ffda RBX: 81489d83 RCX: 7fb6721ce8f0
[  280.969619] RDX: 0004 RSI: 5634312da060 RDI: 0007
[  280.969620] RBP: c90001147f88 R08: 5634312d7de0 R09: 7fb67269f700
[  280.969621] R10: 7fb672497b58 R11: 0246 R12: 5634312d7d00
[  280.969623] R13: 0001 R14: 0004 R15: 0004
[  280.969626]  ? __this_cpu_preempt_check+0x13/0x20

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102365
Signed-off-by: Gabriel Krisman Bertazi 
---
 arch/x86/kernel/cpu/intel.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index dfa90a3a5145..51082a9a3d8a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -465,14 +465,17 @@ static void init_intel_energy_perf(struct cpuinfo_x86 *c)
if (!cpu_has(c, X86_FEATURE_EPB))
return;
 
-   rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
-   if ((epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
+   if (rdmsrl_safe(MSR_IA32_ENERGY_PERF_BIAS, ) ||
+   (epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
return;
 
+   epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
+   if (wrmsrl_safe(MSR_IA32_ENERGY_PERF_BIAS, epb)) {
+   pr_warn_once("ENERGY_PERF_BIAS: Failed to set to 'normal'\n");
+   return;
+   }
pr_warn_once("ENERGY_PERF_BIAS: Set to 'normal', was 'performance'\n");
pr_warn_once("ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)\n");
-   epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
-   wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
 }
 
 static void intel_bsp_resume(struct cpuinfo_x86 *c)
-- 
2.11.0

[PATCH] x86: handle MSR exception when setting energy perf bias

[Gabriel Krisman Bertazi]

On very rare occasions, immediately after a suspend, one of our
SandyBridge CI boxes hits the exception below on CPU0 while trying to
reconfigure the energy bias register.  As far as I can tell, this is not
likely a race in the kernel, since we have only one cpu online, no
preempt and irqs_disabled, and it can only be reproduced in this
specific SNB-2600 on rare occasions.  It looks more of a faulty hardware
thing to me.

Still, we can handle this exception more gracefully to silence the CI,
by using the safe version of the msrl_read/write wrapper.

The log on the faulty box is as follows:

[  280.969486] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 
0x81030a4f (init_intel_energy_perf.part.3+0xf/0xb0)
[  280.969488] Call Trace:
[  280.969492]  intel_bsp_resume+0x1a/0x20
[  280.969494]  bsp_resume+0x1d/0x20
[  280.969498]  syscore_resume+0x62/0x320
[  280.969501]  suspend_devices_and_enter+0xa09/0xcd0
[  280.969506]  pm_suspend+0x574/0xa00
[  280.969509]  state_store+0x82/0xf0
[  280.969514]  kobj_attr_store+0xf/0x20
[  280.969516]  sysfs_kf_write+0x45/0x60
[  280.969519]  kernfs_fop_write+0x124/0x1c0
[  280.969524]  __vfs_write+0x28/0x130
[  280.969526]  ? rcu_read_lock_sched_held+0x7a/0x90
[  280.969528]  ? rcu_sync_lockdep_assert+0x2f/0x60
[  280.969531]  ? __sb_start_write+0x10c/0x200
[  280.969535]  vfs_write+0xc8/0x1c0
[  280.969538]  SyS_write+0x49/0xb0
[  280.969542]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  280.969544] RIP: 0033:0x7fb6721ce8f0
[  280.969546] RSP: 002b:7ffc3ac05da8 EFLAGS: 0246 ORIG_RAX: 
0001
[  280.969549] RAX: ffda RBX: 81489d83 RCX: 7fb6721ce8f0
[  280.969551] RDX: 0004 RSI: 5634312da060 RDI: 0007
[  280.969552] RBP: c90001147f88 R08: 5634312d7de0 R09: 7fb67269f700
[  280.969554] R10: 7fb672497b58 R11: 0246 R12: 5634312d7d00
[  280.969555] R13: 0001 R14: 0004 R15: 0004
[  280.969559]  ? __this_cpu_preempt_check+0x13/0x20
[  280.969566] unchecked MSR access error: WRMSR to 0x1b0 (tried to write 
0x0006) at rIP: 0x81030a8e 
(init_intel_energy_perf.part.3+0x4e/0xb0)
[  280.969567] Call Trace:
[  280.969569]  intel_bsp_resume+0x1a/0x20
[  280.969571]  bsp_resume+0x1d/0x20
[  280.969573]  syscore_resume+0x62/0x320
[  280.969576]  suspend_devices_and_enter+0xa09/0xcd0
[  280.969580]  pm_suspend+0x574/0xa00
[  280.969584]  state_store+0x82/0xf0
[  280.969587]  kobj_attr_store+0xf/0x20
[  280.969589]  sysfs_kf_write+0x45/0x60
[  280.969592]  kernfs_fop_write+0x124/0x1c0
[  280.969595]  __vfs_write+0x28/0x130
[  280.969597]  ? rcu_read_lock_sched_held+0x7a/0x90
[  280.969599]  ? rcu_sync_lockdep_assert+0x2f/0x60
[  280.969601]  ? __sb_start_write+0x10c/0x200
[  280.969605]  vfs_write+0xc8/0x1c0
[  280.969608]  SyS_write+0x49/0xb0
[  280.969612]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  280.969613] RIP: 0033:0x7fb6721ce8f0
[  280.969614] RSP: 002b:7ffc3ac05da8 EFLAGS: 0246 ORIG_RAX: 
0001
[  280.969617] RAX: ffda RBX: 81489d83 RCX: 7fb6721ce8f0
[  280.969619] RDX: 0004 RSI: 5634312da060 RDI: 0007
[  280.969620] RBP: c90001147f88 R08: 5634312d7de0 R09: 7fb67269f700
[  280.969621] R10: 7fb672497b58 R11: 0246 R12: 5634312d7d00
[  280.969623] R13: 0001 R14: 0004 R15: 0004
[  280.969626]  ? __this_cpu_preempt_check+0x13/0x20

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102365
Signed-off-by: Gabriel Krisman Bertazi 
---
 arch/x86/kernel/cpu/intel.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index dfa90a3a5145..51082a9a3d8a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -465,14 +465,17 @@ static void init_intel_energy_perf(struct cpuinfo_x86 *c)
if (!cpu_has(c, X86_FEATURE_EPB))
return;
 
-   rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
-   if ((epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
+   if (rdmsrl_safe(MSR_IA32_ENERGY_PERF_BIAS, ) ||
+   (epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
return;
 
+   epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
+   if (wrmsrl_safe(MSR_IA32_ENERGY_PERF_BIAS, epb)) {
+   pr_warn_once("ENERGY_PERF_BIAS: Failed to set to 'normal'\n");
+   return;
+   }
pr_warn_once("ENERGY_PERF_BIAS: Set to 'normal', was 'performance'\n");
pr_warn_once("ENERGY_PERF_BIAS: View and update with 
x86_energy_perf_policy(8)\n");
-   epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
-   wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
 }
 
 static void intel_bsp_resume(struct cpuinfo_x86 *c)
-- 
2.11.0

Re: [PATCH v3 3/8] PM / devfreq: Show the available min/max frequency through sysfs node

[Chanwoo Choi]

On 2017년 10월 11일 21:57, Chanwoo Choi wrote:
> On Wed, Oct 11, 2017 at 8:15 PM, MyungJoo Ham  
> wrote:
>>> The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq
>>> are available or not. Those sysfs nodes show just the stored value
>>> in the struct devfreq.
>>>
>>> The devfreq uses the OPP interface and then dev_pm_opp_{disable|add}()
>>> might change the state of the device's supported frequency. This patch
>>> shows the available minimum and maximum frequency through sysfs node.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  drivers/devfreq/devfreq.c | 18 --
>>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index 2ce1fd0a1324..799a0cf75d39 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -1128,7 +1128,14 @@ static ssize_t min_freq_store(struct device *dev, 
>>> struct device_attribute *attr,
>>>  static ssize_t min_freq_show(struct device *dev, struct device_attribute 
>>> *attr,
>>>char *buf)
>>>  {
>>> - return sprintf(buf, "%lu\n", to_devfreq(dev)->min_freq);
>>> + struct devfreq *df = to_devfreq(dev);
>>> + unsigned long min_freq = to_devfreq(dev)->min_freq;
>>> + unsigned long available_min_freq = find_available_min_freq(df);
>>> +
>>> + if (available_min_freq != 0 && min_freq < available_min_freq)
>>
>> nitpick:
>>
>> If available_min_freq == 0,
>> it can't be min_freq < available_min_freq anyway;
>> it's unsigned.
> 
> If the dev_pm_opp_find_*() return the error in the find_available_min_freq(),
> avaiable_min_freq is zero. So, if available_min_freq is zero,
> min_freq_show doesn't need to compare 'min_freq < available_min_freq'.
> 
> In result, if 'available_min_freq' is zero, min_freq_show() only considers
> the 'min_freq' variable.

I'll modify this patch as following: How about that?

+   if (available_min_freq == 0)
+   goto out;
+   else if (min_freq < available_min_freq)
+   min_freq = available_min_freq;
+
+out:
+   return sprintf(buf, "%lu\n", min_freq);


>>
>>> + min_freq = available_min_freq;
>>> +
>>> + return sprintf(buf, "%lu\n", min_freq);
>>>  }
>>>
>>>  static ssize_t max_freq_store(struct device *dev, struct device_attribute 
>>> *attr,
>>> @@ -1162,7 +1169,14 @@ static ssize_t max_freq_store(struct device *dev, 
>>> struct device_attribute *attr,
>>>  static ssize_t max_freq_show(struct device *dev, struct device_attribute 
>>> *attr,
>>>char *buf)
>>>  {
>>> - return sprintf(buf, "%lu\n", to_devfreq(dev)->max_freq);
>>> + struct devfreq *df = to_devfreq(dev);
>>> + unsigned long max_freq = to_devfreq(dev)->max_freq;
>>> + unsigned long available_max_freq = find_available_max_freq(df);
>>> +
>>> + if (available_max_freq != 0 && max_freq > available_max_freq)
>>> + max_freq = available_max_freq;
>>
>> similar here.
> 
> ditto.
> 
>>
>>> +
>>> + return sprintf(buf, "%lu\n", max_freq);
>>>  }
>>>  static DEVICE_ATTR_RW(max_freq);
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v3 3/8] PM / devfreq: Show the available min/max frequency through sysfs node

[Chanwoo Choi]

On 2017년 10월 11일 21:57, Chanwoo Choi wrote:
> On Wed, Oct 11, 2017 at 8:15 PM, MyungJoo Ham  
> wrote:
>>> The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq
>>> are available or not. Those sysfs nodes show just the stored value
>>> in the struct devfreq.
>>>
>>> The devfreq uses the OPP interface and then dev_pm_opp_{disable|add}()
>>> might change the state of the device's supported frequency. This patch
>>> shows the available minimum and maximum frequency through sysfs node.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  drivers/devfreq/devfreq.c | 18 --
>>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index 2ce1fd0a1324..799a0cf75d39 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -1128,7 +1128,14 @@ static ssize_t min_freq_store(struct device *dev, 
>>> struct device_attribute *attr,
>>>  static ssize_t min_freq_show(struct device *dev, struct device_attribute 
>>> *attr,
>>>char *buf)
>>>  {
>>> - return sprintf(buf, "%lu\n", to_devfreq(dev)->min_freq);
>>> + struct devfreq *df = to_devfreq(dev);
>>> + unsigned long min_freq = to_devfreq(dev)->min_freq;
>>> + unsigned long available_min_freq = find_available_min_freq(df);
>>> +
>>> + if (available_min_freq != 0 && min_freq < available_min_freq)
>>
>> nitpick:
>>
>> If available_min_freq == 0,
>> it can't be min_freq < available_min_freq anyway;
>> it's unsigned.
> 
> If the dev_pm_opp_find_*() return the error in the find_available_min_freq(),
> avaiable_min_freq is zero. So, if available_min_freq is zero,
> min_freq_show doesn't need to compare 'min_freq < available_min_freq'.
> 
> In result, if 'available_min_freq' is zero, min_freq_show() only considers
> the 'min_freq' variable.

I'll modify this patch as following: How about that?

+   if (available_min_freq == 0)
+   goto out;
+   else if (min_freq < available_min_freq)
+   min_freq = available_min_freq;
+
+out:
+   return sprintf(buf, "%lu\n", min_freq);


>>
>>> + min_freq = available_min_freq;
>>> +
>>> + return sprintf(buf, "%lu\n", min_freq);
>>>  }
>>>
>>>  static ssize_t max_freq_store(struct device *dev, struct device_attribute 
>>> *attr,
>>> @@ -1162,7 +1169,14 @@ static ssize_t max_freq_store(struct device *dev, 
>>> struct device_attribute *attr,
>>>  static ssize_t max_freq_show(struct device *dev, struct device_attribute 
>>> *attr,
>>>char *buf)
>>>  {
>>> - return sprintf(buf, "%lu\n", to_devfreq(dev)->max_freq);
>>> + struct devfreq *df = to_devfreq(dev);
>>> + unsigned long max_freq = to_devfreq(dev)->max_freq;
>>> + unsigned long available_max_freq = find_available_max_freq(df);
>>> +
>>> + if (available_max_freq != 0 && max_freq > available_max_freq)
>>> + max_freq = available_max_freq;
>>
>> similar here.
> 
> ditto.
> 
>>
>>> +
>>> + return sprintf(buf, "%lu\n", max_freq);
>>>  }
>>>  static DEVICE_ATTR_RW(max_freq);
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH] documentation: Update ide-cd documentation to reflect CONFIG_BLK_DEV_HD_IDE removal

[Finn Thain]

CONFIG_BLK_DEV_HD_IDE was removed in commit 80aa31cb460d ("ide: 
remove CONFIG_BLK_DEV_HD_IDE config option (take 2)") but the ide-cd 
documentation was not updated and still asks users to disable it, 
which is misleading and involves a fruitless search.

Signed-off-by: Finn Thain 

diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd
index f4dc9de2694e..a5f2a7f1ff46 100644
--- a/Documentation/cdrom/ide-cd
+++ b/Documentation/cdrom/ide-cd
@@ -55,13 +55,9 @@ This driver provides the following features:
(to compile support as a module which can be loaded and unloaded)
to the options: 
 
-  Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
+  ATA/ATAPI/MFM/RLL support
   Include IDE/ATAPI CDROM support
 
-   and `no' to
-
-  Use old disk-only driver on primary interface
-
Depending on what type of IDE interface you have, you may need to
specify additional configuration options.  See
Documentation/ide/ide.txt.

[PATCH] documentation: Update ide-cd documentation to reflect CONFIG_BLK_DEV_HD_IDE removal

[Finn Thain]

CONFIG_BLK_DEV_HD_IDE was removed in commit 80aa31cb460d ("ide: 
remove CONFIG_BLK_DEV_HD_IDE config option (take 2)") but the ide-cd 
documentation was not updated and still asks users to disable it, 
which is misleading and involves a fruitless search.

Signed-off-by: Finn Thain 

diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd
index f4dc9de2694e..a5f2a7f1ff46 100644
--- a/Documentation/cdrom/ide-cd
+++ b/Documentation/cdrom/ide-cd
@@ -55,13 +55,9 @@ This driver provides the following features:
(to compile support as a module which can be loaded and unloaded)
to the options: 
 
-  Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
+  ATA/ATAPI/MFM/RLL support
   Include IDE/ATAPI CDROM support
 
-   and `no' to
-
-  Use old disk-only driver on primary interface
-
Depending on what type of IDE interface you have, you may need to
specify additional configuration options.  See
Documentation/ide/ide.txt.

Re: [PATCH v3 5/5] soc: qcom: smem: Increase the number of hosts

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> Increase the maximum number of hosts in a system to 10.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - None
> 
> Changes since v2:
> - None
> 
>  drivers/soc/qcom/smem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 19704baa65f4..0b94d62fad2b 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -91,7 +91,7 @@
>  #define SMEM_GLOBAL_HOST 0xfffe
>  
>  /* Max number of processors/hosts in a system */
> -#define SMEM_HOST_COUNT  9
> +#define SMEM_HOST_COUNT  10
>  
>  /**
>* struct smem_proc_comm - proc_comm communication struct (legacy)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v3 5/5] soc: qcom: smem: Increase the number of hosts

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> Increase the maximum number of hosts in a system to 10.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - None
> 
> Changes since v2:
> - None
> 
>  drivers/soc/qcom/smem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 19704baa65f4..0b94d62fad2b 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -91,7 +91,7 @@
>  #define SMEM_GLOBAL_HOST 0xfffe
>  
>  /* Max number of processors/hosts in a system */
> -#define SMEM_HOST_COUNT  9
> +#define SMEM_HOST_COUNT  10
>  
>  /**
>* struct smem_proc_comm - proc_comm communication struct (legacy)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

[PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

controller_group allocation in pci_ep_cfs_init function can fail
so we should have a check while using it in pci_ep_cfs_add_epc_group
for registering group, else we will hit NULL pointer access.

This patch adds required check for the same and returns -EPROBE_DEFER,
so that endpoint controller driver probe can be reattempted later
in case controller_group is not allocated because pci_ep_cfs_init is
not yet called.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
 drivers/pci/endpoint/pci-epc-core.c | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 424fdd6..3cac818 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const char 
*name)
group = _group->group;
 
config_group_init_type_name(group, name, _epc_type);
-   ret = configfs_register_group(controllers_group, group);
+
+   if (controllers_group)
+   ret = configfs_register_group(controllers_group, group);
+   else
+   ret = -EPROBE_DEFER;
+
if (ret) {
pr_err("failed to register configfs group for %s\n", name);
goto err_register_group;
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 42c2a11..d327a2a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
goto put_dev;
 
epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
+   if (IS_ERR(epc->group)) {
+   ret = -EPROBE_DEFER;
+   goto put_dev;
+   }
 
return epc;
 
-- 
2.7.4

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

[Kalle Valo]

Brian Norris  writes:

> Ping? Any comments? I know there's more than one way to slice this
> problem, but it's most definitely a problem...

I'm lagging behind with patches but I'll try to catch up this week.
Sorry.

-- 
Kalle Valo

[PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

controller_group allocation in pci_ep_cfs_init function can fail
so we should have a check while using it in pci_ep_cfs_add_epc_group
for registering group, else we will hit NULL pointer access.

This patch adds required check for the same and returns -EPROBE_DEFER,
so that endpoint controller driver probe can be reattempted later
in case controller_group is not allocated because pci_ep_cfs_init is
not yet called.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
 drivers/pci/endpoint/pci-epc-core.c | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 424fdd6..3cac818 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const char 
*name)
group = _group->group;
 
config_group_init_type_name(group, name, _epc_type);
-   ret = configfs_register_group(controllers_group, group);
+
+   if (controllers_group)
+   ret = configfs_register_group(controllers_group, group);
+   else
+   ret = -EPROBE_DEFER;
+
if (ret) {
pr_err("failed to register configfs group for %s\n", name);
goto err_register_group;
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 42c2a11..d327a2a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
goto put_dev;
 
epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
+   if (IS_ERR(epc->group)) {
+   ret = -EPROBE_DEFER;
+   goto put_dev;
+   }
 
return epc;
 
-- 
2.7.4

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

[Kalle Valo]

Brian Norris  writes:

> Ping? Any comments? I know there's more than one way to slice this
> problem, but it's most definitely a problem...

I'm lagging behind with patches but I'll try to catch up this week.
Sorry.

-- 
Kalle Valo

Re: [PATCH v3 4/5] soc: qcom: smem: Support dynamic item limit

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> In V12 SMEM, SBL writes SMEM parameter information after the TOC. Use
> the SBL provided item count as the max item number.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Change num_items to __le16 from __le32
> - Move max smem item warning to generic get/alloc functions
> - Use get ptable helper function
> 
> Changes since v2:
> - Rename qcom_smem_get_dynamic_item to qcom_smem_get_item_count
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 51 
> +++--
>  1 file changed, 45 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 6a3134e9c591..19704baa65f4 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -223,6 +223,24 @@ struct smem_private_entry {
>  #define SMEM_PRIVATE_CANARY  0xa5a5
>  
>  /**
> + * struct smem_info - smem region info located after the table of contents
> + * @magic:   magic number, must be SMEM_INFO_MAGIC
> + * @size:size of the smem region
> + * @base_addr:   base address of the smem region
> + * @reserved:for now reserved entry
> + * @num_items:   highest accepted item number
> + */
> +struct smem_info {
> + u8 magic[4];
> + __le32 size;
> + __le32 base_addr;
> + __le32 reserved;
> + __le16 num_items;
> +};
> +
> +static const u8 SMEM_INFO_MAGIC[] = { 0x53, 0x49, 0x49, 0x49 }; /* SIII */
> +
> +/**
>   * struct smem_region - representation of a chunk of memory used for smem
>   * @aux_base:identifier of aux_mem base
>   * @virt_base:   virtual base address of memory with this aux_mem 
> identifier
> @@ -243,6 +261,7 @@ struct smem_region {
>   * @partitions:  list of pointers to partitions affecting the current
>   *   processor/host
>   * @cacheline:   list of cacheline sizes for each host
> + * @item_count: max accepted item number
>   * @num_regions: number of @regions
>   * @regions: list of the memory regions defining the shared memory
>   */
> @@ -255,6 +274,7 @@ struct qcom_smem {
>   size_t global_cacheline;
>   struct smem_partition_header *partitions[SMEM_HOST_COUNT];
>   size_t cacheline[SMEM_HOST_COUNT];
> + u32 item_count;
>  
>   unsigned num_regions;
>   struct smem_region regions[0];
> @@ -386,9 +406,6 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
>   struct smem_global_entry *entry;
>   struct smem_header *header;
>  
> - if (WARN_ON(item >= SMEM_ITEM_COUNT))
> - return -EINVAL;
> -
>   header = smem->regions[0].virt_base;
>   entry = >toc[item];
>   if (entry->allocated)
> @@ -439,6 +456,9 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t 
> size)
>   return -EINVAL;
>   }
>  
> + if (WARN_ON(item >= __smem->item_count))
> + return -EINVAL;
> +
>   ret = hwspin_lock_timeout_irqsave(__smem->hwlock,
> HWSPINLOCK_TIMEOUT,
> );
> @@ -471,9 +491,6 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
>   u32 aux_base;
>   unsigned i;
>  
> - if (WARN_ON(item >= SMEM_ITEM_COUNT))
> - return ERR_PTR(-EINVAL);
> -
>   header = smem->regions[0].virt_base;
>   entry = >toc[item];
>   if (!entry->allocated)
> @@ -569,6 +586,9 @@ void *qcom_smem_get(unsigned host, unsigned item, size_t 
> *size)
>   if (!__smem)
>   return ptr;
>  
> + if (WARN_ON(item >= __smem->item_count))
> + return ERR_PTR(-EINVAL);
> +
>   ret = hwspin_lock_timeout_irqsave(__smem->hwlock,
> HWSPINLOCK_TIMEOUT,
> );
> @@ -656,6 +676,22 @@ static struct smem_ptable *qcom_smem_get_ptable(struct 
> qcom_smem *smem)
>   return ptable;
>  }
>  
> +static u32 qcom_smem_get_item_count(struct qcom_smem *smem)
> +{
> + struct smem_ptable *ptable;
> + struct smem_info *info;
> +
> + ptable = qcom_smem_get_ptable(smem);
> + if (IS_ERR_OR_NULL(ptable))
> + return SMEM_ITEM_COUNT;
> +
> + info = (struct smem_info *)>entry[ptable->num_entries];
> + if (memcmp(info->magic, SMEM_INFO_MAGIC, sizeof(info->magic)))
> + return SMEM_ITEM_COUNT;
> +
> + return le16_to_cpu(info->num_items);
> +}
> +
>  static int qcom_smem_set_global_partition(struct qcom_smem *smem)
>  {
>   struct smem_partition_header *header;
> @@ -883,7 +919,10 @@ static int qcom_smem_probe(struct platform_device *pdev)
>   ret = qcom_smem_set_global_partition(smem);
>   if (ret < 0)
>   return ret;
> + smem->item_count = qcom_smem_get_item_count(smem);
> + 

Re: [PATCH v3 4/5] soc: qcom: smem: Support dynamic item limit

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> In V12 SMEM, SBL writes SMEM parameter information after the TOC. Use
> the SBL provided item count as the max item number.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Change num_items to __le16 from __le32
> - Move max smem item warning to generic get/alloc functions
> - Use get ptable helper function
> 
> Changes since v2:
> - Rename qcom_smem_get_dynamic_item to qcom_smem_get_item_count
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 51 
> +++--
>  1 file changed, 45 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 6a3134e9c591..19704baa65f4 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -223,6 +223,24 @@ struct smem_private_entry {
>  #define SMEM_PRIVATE_CANARY  0xa5a5
>  
>  /**
> + * struct smem_info - smem region info located after the table of contents
> + * @magic:   magic number, must be SMEM_INFO_MAGIC
> + * @size:size of the smem region
> + * @base_addr:   base address of the smem region
> + * @reserved:for now reserved entry
> + * @num_items:   highest accepted item number
> + */
> +struct smem_info {
> + u8 magic[4];
> + __le32 size;
> + __le32 base_addr;
> + __le32 reserved;
> + __le16 num_items;
> +};
> +
> +static const u8 SMEM_INFO_MAGIC[] = { 0x53, 0x49, 0x49, 0x49 }; /* SIII */
> +
> +/**
>   * struct smem_region - representation of a chunk of memory used for smem
>   * @aux_base:identifier of aux_mem base
>   * @virt_base:   virtual base address of memory with this aux_mem 
> identifier
> @@ -243,6 +261,7 @@ struct smem_region {
>   * @partitions:  list of pointers to partitions affecting the current
>   *   processor/host
>   * @cacheline:   list of cacheline sizes for each host
> + * @item_count: max accepted item number
>   * @num_regions: number of @regions
>   * @regions: list of the memory regions defining the shared memory
>   */
> @@ -255,6 +274,7 @@ struct qcom_smem {
>   size_t global_cacheline;
>   struct smem_partition_header *partitions[SMEM_HOST_COUNT];
>   size_t cacheline[SMEM_HOST_COUNT];
> + u32 item_count;
>  
>   unsigned num_regions;
>   struct smem_region regions[0];
> @@ -386,9 +406,6 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
>   struct smem_global_entry *entry;
>   struct smem_header *header;
>  
> - if (WARN_ON(item >= SMEM_ITEM_COUNT))
> - return -EINVAL;
> -
>   header = smem->regions[0].virt_base;
>   entry = >toc[item];
>   if (entry->allocated)
> @@ -439,6 +456,9 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t 
> size)
>   return -EINVAL;
>   }
>  
> + if (WARN_ON(item >= __smem->item_count))
> + return -EINVAL;
> +
>   ret = hwspin_lock_timeout_irqsave(__smem->hwlock,
> HWSPINLOCK_TIMEOUT,
> );
> @@ -471,9 +491,6 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
>   u32 aux_base;
>   unsigned i;
>  
> - if (WARN_ON(item >= SMEM_ITEM_COUNT))
> - return ERR_PTR(-EINVAL);
> -
>   header = smem->regions[0].virt_base;
>   entry = >toc[item];
>   if (!entry->allocated)
> @@ -569,6 +586,9 @@ void *qcom_smem_get(unsigned host, unsigned item, size_t 
> *size)
>   if (!__smem)
>   return ptr;
>  
> + if (WARN_ON(item >= __smem->item_count))
> + return ERR_PTR(-EINVAL);
> +
>   ret = hwspin_lock_timeout_irqsave(__smem->hwlock,
> HWSPINLOCK_TIMEOUT,
> );
> @@ -656,6 +676,22 @@ static struct smem_ptable *qcom_smem_get_ptable(struct 
> qcom_smem *smem)
>   return ptable;
>  }
>  
> +static u32 qcom_smem_get_item_count(struct qcom_smem *smem)
> +{
> + struct smem_ptable *ptable;
> + struct smem_info *info;
> +
> + ptable = qcom_smem_get_ptable(smem);
> + if (IS_ERR_OR_NULL(ptable))
> + return SMEM_ITEM_COUNT;
> +
> + info = (struct smem_info *)>entry[ptable->num_entries];
> + if (memcmp(info->magic, SMEM_INFO_MAGIC, sizeof(info->magic)))
> + return SMEM_ITEM_COUNT;
> +
> + return le16_to_cpu(info->num_items);
> +}
> +
>  static int qcom_smem_set_global_partition(struct qcom_smem *smem)
>  {
>   struct smem_partition_header *header;
> @@ -883,7 +919,10 @@ static int qcom_smem_probe(struct platform_device *pdev)
>   ret = qcom_smem_set_global_partition(smem);
>   if (ret < 0)
>   return ret;
> + smem->item_count = qcom_smem_get_item_count(smem);
> + break;
>   case SMEM_GLOBAL_HEAP_VERSION:
> + 

Re: [PATCH v3 3/5] soc: qcom: smem: Support global partition

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> SMEM V12 creates a global partition to allocate global smem items from
> instead of a global heap. The global partition has the same structure as
> a private partition.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Move V12 descriptions to top comment
> - Add cacheline support to global partition
> - Add ptable get helper function
> - Move global partition init to version check
> 
> Changes since v2:
> - Return -ENOENT if partition table does not exist
> - Exclude -ENOENT error propagation from enumerate_partitions()
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 172 
> +++-
>  1 file changed, 142 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 540322ae409e..6a3134e9c591 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -55,6 +55,10 @@
>   * is hence the region between the cached and non-cached offsets. The header 
> of
>   * cached items comes after the data.
>   *
> + * Version 12 (SMEM_GLOBAL_PART_VERSION) changes the item alloc/get procedure
> + * for the global heap. A new global partition is created from the global 
> heap
> + * region with partition type (SMEM_GLOBAL_HOST) and the max smem item count 
> is
> + * set by the bootloader.
>   *
>   * To synchronize allocations in the shared memory heaps a remote spinlock 
> must
>   * be held - currently lock number 3 of the sfpb or tcsr is used for this on 
> all
> @@ -68,7 +72,8 @@
>   * version is a valid version as a sanity check.
>   */
>  #define SMEM_MASTER_SBL_VERSION_INDEX7
> -#define SMEM_EXPECTED_VERSION11
> +#define SMEM_GLOBAL_HEAP_VERSION 11
> +#define SMEM_GLOBAL_PART_VERSION 12
>  
>  /*
>   * The first 8 items are only to be allocated by the boot loader while
> @@ -82,6 +87,9 @@
>  /* Processor/host identifier for the application processor */
>  #define SMEM_HOST_APPS   0
>  
> +/* Processor/host identifier for the global partition */
> +#define SMEM_GLOBAL_HOST 0xfffe
> +
>  /* Max number of processors/hosts in a system */
>  #define SMEM_HOST_COUNT  9
>  
> @@ -230,6 +238,8 @@ struct smem_region {
>   * struct qcom_smem - device data for the smem device
>   * @dev: device pointer
>   * @hwlock:  reference to a hwspinlock
> + * @global_partition:pointer to global partition when in use
> + * @global_cacheline:cacheline size for global partition
>   * @partitions:  list of pointers to partitions affecting the current
>   *   processor/host
>   * @cacheline:   list of cacheline sizes for each host
> @@ -241,6 +251,8 @@ struct qcom_smem {
>  
>   struct hwspinlock *hwlock;
>  
> + struct smem_partition_header *global_partition;
> + size_t global_cacheline;
>   struct smem_partition_header *partitions[SMEM_HOST_COUNT];
>   size_t cacheline[SMEM_HOST_COUNT];
>  
> @@ -317,16 +329,14 @@ static void *cached_entry_to_item(struct 
> smem_private_entry *e)
>  #define HWSPINLOCK_TIMEOUT   1000
>  
>  static int qcom_smem_alloc_private(struct qcom_smem *smem,
> -unsigned host,
> +struct smem_partition_header *phdr,
>  unsigned item,
>  size_t size)
>  {
> - struct smem_partition_header *phdr;
>   struct smem_private_entry *hdr, *end;
>   size_t alloc_size;
>   void *cached;
>  
> - phdr = smem->partitions[host];
>   hdr = phdr_to_first_uncached_entry(phdr);
>   end = phdr_to_last_uncached_entry(phdr);
>   cached = phdr_to_last_cached_entry(phdr);
> @@ -334,8 +344,8 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
>   while (hdr < end) {
>   if (hdr->canary != SMEM_PRIVATE_CANARY) {
>   dev_err(smem->dev,
> - "Found invalid canary in host %d partition\n",
> - host);
> + "Found invalid canary in hosts %d:%d 
> partition\n",
> + phdr->host0, phdr->host1);
>   return -EINVAL;
>   }
>  
> @@ -373,8 +383,8 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
> unsigned item,
> size_t size)
>  {
> - struct smem_header *header;
>   struct smem_global_entry *entry;
> + struct smem_header *header;
>  
>   if (WARN_ON(item >= SMEM_ITEM_COUNT))
>   return -EINVAL;
> @@ -416,6 +426,7 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
>   */
>  int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
>  {
> + 

Re: [PATCH v3 3/5] soc: qcom: smem: Support global partition

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> SMEM V12 creates a global partition to allocate global smem items from
> instead of a global heap. The global partition has the same structure as
> a private partition.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Move V12 descriptions to top comment
> - Add cacheline support to global partition
> - Add ptable get helper function
> - Move global partition init to version check
> 
> Changes since v2:
> - Return -ENOENT if partition table does not exist
> - Exclude -ENOENT error propagation from enumerate_partitions()
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 172 
> +++-
>  1 file changed, 142 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 540322ae409e..6a3134e9c591 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -55,6 +55,10 @@
>   * is hence the region between the cached and non-cached offsets. The header 
> of
>   * cached items comes after the data.
>   *
> + * Version 12 (SMEM_GLOBAL_PART_VERSION) changes the item alloc/get procedure
> + * for the global heap. A new global partition is created from the global 
> heap
> + * region with partition type (SMEM_GLOBAL_HOST) and the max smem item count 
> is
> + * set by the bootloader.
>   *
>   * To synchronize allocations in the shared memory heaps a remote spinlock 
> must
>   * be held - currently lock number 3 of the sfpb or tcsr is used for this on 
> all
> @@ -68,7 +72,8 @@
>   * version is a valid version as a sanity check.
>   */
>  #define SMEM_MASTER_SBL_VERSION_INDEX7
> -#define SMEM_EXPECTED_VERSION11
> +#define SMEM_GLOBAL_HEAP_VERSION 11
> +#define SMEM_GLOBAL_PART_VERSION 12
>  
>  /*
>   * The first 8 items are only to be allocated by the boot loader while
> @@ -82,6 +87,9 @@
>  /* Processor/host identifier for the application processor */
>  #define SMEM_HOST_APPS   0
>  
> +/* Processor/host identifier for the global partition */
> +#define SMEM_GLOBAL_HOST 0xfffe
> +
>  /* Max number of processors/hosts in a system */
>  #define SMEM_HOST_COUNT  9
>  
> @@ -230,6 +238,8 @@ struct smem_region {
>   * struct qcom_smem - device data for the smem device
>   * @dev: device pointer
>   * @hwlock:  reference to a hwspinlock
> + * @global_partition:pointer to global partition when in use
> + * @global_cacheline:cacheline size for global partition
>   * @partitions:  list of pointers to partitions affecting the current
>   *   processor/host
>   * @cacheline:   list of cacheline sizes for each host
> @@ -241,6 +251,8 @@ struct qcom_smem {
>  
>   struct hwspinlock *hwlock;
>  
> + struct smem_partition_header *global_partition;
> + size_t global_cacheline;
>   struct smem_partition_header *partitions[SMEM_HOST_COUNT];
>   size_t cacheline[SMEM_HOST_COUNT];
>  
> @@ -317,16 +329,14 @@ static void *cached_entry_to_item(struct 
> smem_private_entry *e)
>  #define HWSPINLOCK_TIMEOUT   1000
>  
>  static int qcom_smem_alloc_private(struct qcom_smem *smem,
> -unsigned host,
> +struct smem_partition_header *phdr,
>  unsigned item,
>  size_t size)
>  {
> - struct smem_partition_header *phdr;
>   struct smem_private_entry *hdr, *end;
>   size_t alloc_size;
>   void *cached;
>  
> - phdr = smem->partitions[host];
>   hdr = phdr_to_first_uncached_entry(phdr);
>   end = phdr_to_last_uncached_entry(phdr);
>   cached = phdr_to_last_cached_entry(phdr);
> @@ -334,8 +344,8 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
>   while (hdr < end) {
>   if (hdr->canary != SMEM_PRIVATE_CANARY) {
>   dev_err(smem->dev,
> - "Found invalid canary in host %d partition\n",
> - host);
> + "Found invalid canary in hosts %d:%d 
> partition\n",
> + phdr->host0, phdr->host1);
>   return -EINVAL;
>   }
>  
> @@ -373,8 +383,8 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
> unsigned item,
> size_t size)
>  {
> - struct smem_header *header;
>   struct smem_global_entry *entry;
> + struct smem_header *header;
>  
>   if (WARN_ON(item >= SMEM_ITEM_COUNT))
>   return -EINVAL;
> @@ -416,6 +426,7 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
>   */
>  int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
>  {
> + struct smem_partition_header *phdr;
>   unsigned long flags;
>   

Re: [PATCH v3 2/5] soc: qcom: smem: Read version from the smem header

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> The SMEM header structure includes the version information. Read the
> version directly from the header instead of getting an item from the
> global heap.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Remove unused smem item version macro
> - Move smem get version change to separate commit
> 
> Changes since v2:
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 25 -
>  1 file changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index db04c45d4132..540322ae409e 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -63,13 +63,12 @@
>   */
>  
>  /*
> - * Item 3 of the global heap contains an array of versions for the various
> - * software components in the SoC. We verify that the boot loader version is
> - * what the expected version (SMEM_EXPECTED_VERSION) as a sanity check.
> + * The version member of the smem header contains an array of versions for 
> the
> + * various software components in the SoC. We verify that the boot loader
> + * version is a valid version as a sanity check.
>   */
> -#define SMEM_ITEM_VERSION3
> -#define  SMEM_MASTER_SBL_VERSION_INDEX   7
> -#define  SMEM_EXPECTED_VERSION   11
> +#define SMEM_MASTER_SBL_VERSION_INDEX7
> +#define SMEM_EXPECTED_VERSION11
>  
>  /*
>   * The first 8 items are only to be allocated by the boot loader while
> @@ -604,19 +603,11 @@ int qcom_smem_get_free_space(unsigned host)
>  
>  static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
>  {
> + struct smem_header *header;
>   __le32 *versions;
> - size_t size;
> -
> - versions = qcom_smem_get_global(smem, SMEM_ITEM_VERSION, );
> - if (IS_ERR(versions)) {
> - dev_err(smem->dev, "Unable to read the version item\n");
> - return -ENOENT;
> - }
>  
> - if (size < sizeof(unsigned) * SMEM_MASTER_SBL_VERSION_INDEX) {
> - dev_err(smem->dev, "Version item is too small\n");
> - return -EINVAL;
> - }
> + header = smem->regions[0].virt_base;
> + versions = header->version;
>  
>   return le32_to_cpu(versions[SMEM_MASTER_SBL_VERSION_INDEX]);
>  }
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v3 2/5] soc: qcom: smem: Read version from the smem header

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> The SMEM header structure includes the version information. Read the
> version directly from the header instead of getting an item from the
> global heap.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - Remove unused smem item version macro
> - Move smem get version change to separate commit
> 
> Changes since v2:
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 25 -
>  1 file changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index db04c45d4132..540322ae409e 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -63,13 +63,12 @@
>   */
>  
>  /*
> - * Item 3 of the global heap contains an array of versions for the various
> - * software components in the SoC. We verify that the boot loader version is
> - * what the expected version (SMEM_EXPECTED_VERSION) as a sanity check.
> + * The version member of the smem header contains an array of versions for 
> the
> + * various software components in the SoC. We verify that the boot loader
> + * version is a valid version as a sanity check.
>   */
> -#define SMEM_ITEM_VERSION3
> -#define  SMEM_MASTER_SBL_VERSION_INDEX   7
> -#define  SMEM_EXPECTED_VERSION   11
> +#define SMEM_MASTER_SBL_VERSION_INDEX7
> +#define SMEM_EXPECTED_VERSION11
>  
>  /*
>   * The first 8 items are only to be allocated by the boot loader while
> @@ -604,19 +603,11 @@ int qcom_smem_get_free_space(unsigned host)
>  
>  static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
>  {
> + struct smem_header *header;
>   __le32 *versions;
> - size_t size;
> -
> - versions = qcom_smem_get_global(smem, SMEM_ITEM_VERSION, );
> - if (IS_ERR(versions)) {
> - dev_err(smem->dev, "Unable to read the version item\n");
> - return -ENOENT;
> - }
>  
> - if (size < sizeof(unsigned) * SMEM_MASTER_SBL_VERSION_INDEX) {
> - dev_err(smem->dev, "Version item is too small\n");
> - return -EINVAL;
> - }
> + header = smem->regions[0].virt_base;
> + versions = header->version;
>  
>   return le32_to_cpu(versions[SMEM_MASTER_SBL_VERSION_INDEX]);
>  }
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v3 1/5] soc: qcom: smem: Use le32_to_cpu for comparison

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> Endianness can vary in the system, add le32_to_cpu when comparing
> partition sizes from smem.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - New change
> 
> Changes since v2:
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index c28275be0038..db04c45d4132 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -698,7 +698,7 @@ static int qcom_smem_enumerate_partitions(struct 
> qcom_smem *smem,
>   return -EINVAL;
>   }
>  
> - if (header->size != entry->size) {
> + if (le32_to_cpu(header->size) != le32_to_cpu(entry->size)) {
>   dev_err(smem->dev,
>   "Partition %d has invalid size\n", i);
>   return -EINVAL;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v3 1/5] soc: qcom: smem: Use le32_to_cpu for comparison

[Bjorn Andersson]

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote:

> From: Chris Lew 
> 
> Endianness can vary in the system, add le32_to_cpu when comparing
> partition sizes from smem.
> 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Chris Lew 
> ---
> 
> Changes since v1:
> - New change
> 
> Changes since v2:
> - Reduce subject to 50 chars and wrap summary to 72 chars
> 
>  drivers/soc/qcom/smem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index c28275be0038..db04c45d4132 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -698,7 +698,7 @@ static int qcom_smem_enumerate_partitions(struct 
> qcom_smem *smem,
>   return -EINVAL;
>   }
>  
> - if (header->size != entry->size) {
> + if (le32_to_cpu(header->size) != le32_to_cpu(entry->size)) {
>   dev_err(smem->dev,
>   "Partition %d has invalid size\n", i);
>   return -EINVAL;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

[Wei Wang]

On 10/11/2017 09:49 PM, Michael S. Tsirkin wrote:

On Wed, Oct 11, 2017 at 02:03:20PM +0800, Wei Wang wrote:

On 10/10/2017 11:15 PM, Michael S. Tsirkin wrote:

On Mon, Oct 02, 2017 at 04:38:01PM +, Wang, Wei W wrote:

On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote:

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote:

+static void ctrlq_send_cmd(struct virtio_balloon *vb,
+ struct virtio_balloon_ctrlq_cmd *cmd,
+ bool inbuf)
+{
+   struct virtqueue *vq = vb->ctrl_vq;
+
+   ctrlq_add_cmd(vq, cmd, inbuf);
+   if (!inbuf) {
+   /*
+* All the input cmd buffers are replenished here.
+* This is necessary because the input cmd buffers are lost
+* after live migration. The device needs to rewind all of
+* them from the ctrl_vq.

Confused. Live migration somehow loses state? Why is that and why is it a good
idea? And how do you know this is migration even?
Looks like all you know is you got free page end. Could be any reason for this.

I think this would be something that the current live migration lacks - what the
device read from the vq is not transferred during live migration, an example is 
the
stat_vq_elem:
Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c

This does not touch guest memory though it just manipulates
internal state to make it easier to migrate.
It's transparent to guest as migration should be.


For all the things that are added to the vq and need to be held by the device
to use later need to consider the situation that live migration might happen at 
any
time and they need to be re-taken from the vq by the device on the destination
machine.

So, even without this live migration optimization feature, I think all the 
things that are
added to the vq for the device to hold, need a way for the device to rewind 
back from
the vq - re-adding all the elements to the vq is a trick to keep a record of 
all of them
on the vq so that the device side rewinding can work.

Please let me know if anything is missed or if you have other suggestions.

IMO migration should pass enough data source to destination for
destination to continue where source left off without guest help.


I'm afraid it would be difficult to pass the entire VirtQueueElement to the
destination. I think
that would also be the reason that stats_vq_elem chose to rewind from the
guest vq, which re-do the
virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to
the guest physical
address relationship may be changed on the destination).

Yes but note how that rewind does not involve modifying the ring.
It just rolls back some indices.


Yes, it rolls back the indices, then the following 
virtio_balloon_receive_stats()

can re-pop out the previous entry given by the guest.

Recall how stats_vq_elem works: there is only one stats buffer, which is 
used by the
guest to report stats, and also used by the host to ask the guest for 
stats report.


So the host can roll back one previous entry and what it gets will 
always be stat_vq_elem.



Our case is a little more complex than that - we have both free_page_cmd_in
(for host to guest command) and free_page_cmd_out (for guest to host 
command) buffer
passed via ctrl_vq. When the host rolls back one entry, it may get the 
free_page_cmd_out
buffer which can't be used as the host to guest buffer (i.e. 
free_page_elem held by the device).


So a trick in the driver is to refill the free_page_cmd_in buffer every 
time after the free_page_cmd_out
was sent to the host, so that when the host rewind one previous entry, 
it can always get the

free_page_cmd_in buffer (may be not a very nice method).






How about another direction which would be easier - using two 32-bit device
specific configuration registers,
Host2Guest and Guest2Host command registers, to replace the ctrlq for
command exchange:

The flow can be as follows:

1) Before Host sending a StartCMD, it flushes the free_page_vq in case any
old free page hint is left there;
2) Host writes StartCMD to the Host2Guest register, and notifies the guest;

3) Upon receiving a configuration notification, Guest reads the Host2Guest
register, and detaches all the used buffers from free_page_vq;
(then for each StartCMD, the free_page_vq will always have no obsolete free
page hints, right? )

4) Guest start report free pages:
 4.1) Host may actively write StopCMD to the Host2Guest register before
the guest finishes; or
 4.2) Guest finishes reporting, write StopCMD  the Guest2HOST register,
which traps to QEMU, to stop.


Best,
Wei

I am not sure it matters whether a VQ or the config are used to start/stop.



Not matters, in terms of the flushing issue. The config method could 
avoid the above rewind issue.




But I think flushing is very fragile. You will easily run into races
if one of the actors gets out of sync and keeps adding data.
I 

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

[Wei Wang]

On 10/11/2017 09:49 PM, Michael S. Tsirkin wrote:

On Wed, Oct 11, 2017 at 02:03:20PM +0800, Wei Wang wrote:

On 10/10/2017 11:15 PM, Michael S. Tsirkin wrote:

On Mon, Oct 02, 2017 at 04:38:01PM +, Wang, Wei W wrote:

On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote:

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote:

+static void ctrlq_send_cmd(struct virtio_balloon *vb,
+ struct virtio_balloon_ctrlq_cmd *cmd,
+ bool inbuf)
+{
+   struct virtqueue *vq = vb->ctrl_vq;
+
+   ctrlq_add_cmd(vq, cmd, inbuf);
+   if (!inbuf) {
+   /*
+* All the input cmd buffers are replenished here.
+* This is necessary because the input cmd buffers are lost
+* after live migration. The device needs to rewind all of
+* them from the ctrl_vq.

Confused. Live migration somehow loses state? Why is that and why is it a good
idea? And how do you know this is migration even?
Looks like all you know is you got free page end. Could be any reason for this.

I think this would be something that the current live migration lacks - what the
device read from the vq is not transferred during live migration, an example is 
the
stat_vq_elem:
Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c

This does not touch guest memory though it just manipulates
internal state to make it easier to migrate.
It's transparent to guest as migration should be.


For all the things that are added to the vq and need to be held by the device
to use later need to consider the situation that live migration might happen at 
any
time and they need to be re-taken from the vq by the device on the destination
machine.

So, even without this live migration optimization feature, I think all the 
things that are
added to the vq for the device to hold, need a way for the device to rewind 
back from
the vq - re-adding all the elements to the vq is a trick to keep a record of 
all of them
on the vq so that the device side rewinding can work.

Please let me know if anything is missed or if you have other suggestions.

IMO migration should pass enough data source to destination for
destination to continue where source left off without guest help.


I'm afraid it would be difficult to pass the entire VirtQueueElement to the
destination. I think
that would also be the reason that stats_vq_elem chose to rewind from the
guest vq, which re-do the
virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to
the guest physical
address relationship may be changed on the destination).

Yes but note how that rewind does not involve modifying the ring.
It just rolls back some indices.


Yes, it rolls back the indices, then the following 
virtio_balloon_receive_stats()

can re-pop out the previous entry given by the guest.

Recall how stats_vq_elem works: there is only one stats buffer, which is 
used by the
guest to report stats, and also used by the host to ask the guest for 
stats report.


So the host can roll back one previous entry and what it gets will 
always be stat_vq_elem.



Our case is a little more complex than that - we have both free_page_cmd_in
(for host to guest command) and free_page_cmd_out (for guest to host 
command) buffer
passed via ctrl_vq. When the host rolls back one entry, it may get the 
free_page_cmd_out
buffer which can't be used as the host to guest buffer (i.e. 
free_page_elem held by the device).


So a trick in the driver is to refill the free_page_cmd_in buffer every 
time after the free_page_cmd_out
was sent to the host, so that when the host rewind one previous entry, 
it can always get the

free_page_cmd_in buffer (may be not a very nice method).






How about another direction which would be easier - using two 32-bit device
specific configuration registers,
Host2Guest and Guest2Host command registers, to replace the ctrlq for
command exchange:

The flow can be as follows:

1) Before Host sending a StartCMD, it flushes the free_page_vq in case any
old free page hint is left there;
2) Host writes StartCMD to the Host2Guest register, and notifies the guest;

3) Upon receiving a configuration notification, Guest reads the Host2Guest
register, and detaches all the used buffers from free_page_vq;
(then for each StartCMD, the free_page_vq will always have no obsolete free
page hints, right? )

4) Guest start report free pages:
 4.1) Host may actively write StopCMD to the Host2Guest register before
the guest finishes; or
 4.2) Guest finishes reporting, write StopCMD  the Guest2HOST register,
which traps to QEMU, to stop.


Best,
Wei

I am not sure it matters whether a VQ or the config are used to start/stop.



Not matters, in terms of the flushing issue. The config method could 
avoid the above rewind issue.




But I think flushing is very fragile. You will easily run into races
if one of the actors gets out of sync and keeps adding data.
I 

Re: [PATCH v3 7/9] soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap

[Sean Wang]

On Tue, 2017-10-10 at 12:02 +0200, Matthias Brugger wrote:
> 
> On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > Add MediaTek MT6380 regulator becoming one of PMIC wrapper slave
> > and also add extra new regmap_config of 32-bit mode for MT6380
> > since old regmap_config of 16-bit mode can't be fit into the need.
> > 
> > Signed-off-by: Chenglin Xu 
> > Signed-off-by: Chen Zhong 
> > Signed-off-by: Sean Wang 
> > ---
> >   drivers/soc/mediatek/mtk-pmic-wrap.c | 25 ++---
> >   1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index 1f8b69a..047e3d9 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -501,6 +501,7 @@ struct pmic_wrapper;
> >   struct pwrap_slv_type {
> > const u32 *dew_regs;
> > enum pmic_type type;
> > +   const struct regmap_config *regmap;
> > /* pwrap operations are highly associated with the PMIC types,
> >  * so the pointers added increases flexibility allowing determination
> >  * which type is used by the detection through device tree.
> > @@ -1109,7 +1110,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
> > *dev_id)
> > return IRQ_HANDLED;
> >   }
> >   
> > -static const struct regmap_config pwrap_regmap_config = {
> > +static const struct regmap_config pwrap_regmap_config16 = {
> > .reg_bits = 16,
> > .val_bits = 16,
> > .reg_stride = 2,
> > @@ -1118,9 +1119,19 @@ static const struct regmap_config 
> > pwrap_regmap_config = {
> > .max_register = 0x,
> >   };
> >   
> > +static const struct regmap_config pwrap_regmap_config32 = {
> > +   .reg_bits = 32,
> > +   .val_bits = 32,
> > +   .reg_stride = 4,
> > +   .reg_read = pwrap_regmap_read,
> > +   .reg_write = pwrap_regmap_write,
> > +   .max_register = 0x,
> > +};
> > +
> >   static const struct pwrap_slv_type pmic_mt6323 = {
> > .dew_regs = mt6323_regs,
> > .type = PMIC_MT6323,
> > +   .regmap = _regmap_config16,
> > .pwrap_read = pwrap_read16,
> > .pwrap_write = pwrap_write16,
> >   };
> > @@ -1128,6 +1139,7 @@ static const struct pwrap_slv_type pmic_mt6323 = {
> >   static const struct pwrap_slv_type pmic_mt6380 = {
> > .dew_regs = NULL,
> > .type = PMIC_MT6380,
> > +   .regmap = _regmap_config32,
> > .pwrap_read = pwrap_read32,
> > .pwrap_write = pwrap_write32,
> >   };
> > @@ -1135,6 +1147,7 @@ static const struct pwrap_slv_type pmic_mt6380 = {
> >   static const struct pwrap_slv_type pmic_mt6397 = {
> > .dew_regs = mt6397_regs,
> > .type = PMIC_MT6397,
> > +   .regmap = _regmap_config16,
> > .pwrap_read = pwrap_read16,
> > .pwrap_write = pwrap_write16,
> >   };
> > @@ -1144,9 +1157,15 @@ static const struct of_device_id 
> > of_slave_match_tbl[] = {
> > .compatible = "mediatek,mt6323",
> > .data = _mt6323,
> > }, {
> > +   /* The MT6380 slave device is directly pointed to the regulator
> > +* device which is different from the cases MT6323 and MT6397
> > +* where they're one kind of MFDs.
> > +*/
> > +   .compatible = "mediatek,mt6380-regulator",
> > +   .data = _mt6380,
> 
> I understand that mt6380 only provides a regulator and no other function 
> other 
> PMICs provide, right?

> Then maybe write a comment like:
> The MT6380 PMIC only implements a regulator, so we bind it directly instead 
> of 
> using a MFD. If so, we should state that in the pwrap bindings document, I 
> think.
> 

You're right. It is worth making them better in both comments and the
bindings document. I'll do it in the next version.


> Regards,
> Matthias

Re: [PATCH v3 7/9] soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap

[Sean Wang]

On Tue, 2017-10-10 at 12:02 +0200, Matthias Brugger wrote:
> 
> On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > Add MediaTek MT6380 regulator becoming one of PMIC wrapper slave
> > and also add extra new regmap_config of 32-bit mode for MT6380
> > since old regmap_config of 16-bit mode can't be fit into the need.
> > 
> > Signed-off-by: Chenglin Xu 
> > Signed-off-by: Chen Zhong 
> > Signed-off-by: Sean Wang 
> > ---
> >   drivers/soc/mediatek/mtk-pmic-wrap.c | 25 ++---
> >   1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index 1f8b69a..047e3d9 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -501,6 +501,7 @@ struct pmic_wrapper;
> >   struct pwrap_slv_type {
> > const u32 *dew_regs;
> > enum pmic_type type;
> > +   const struct regmap_config *regmap;
> > /* pwrap operations are highly associated with the PMIC types,
> >  * so the pointers added increases flexibility allowing determination
> >  * which type is used by the detection through device tree.
> > @@ -1109,7 +1110,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
> > *dev_id)
> > return IRQ_HANDLED;
> >   }
> >   
> > -static const struct regmap_config pwrap_regmap_config = {
> > +static const struct regmap_config pwrap_regmap_config16 = {
> > .reg_bits = 16,
> > .val_bits = 16,
> > .reg_stride = 2,
> > @@ -1118,9 +1119,19 @@ static const struct regmap_config 
> > pwrap_regmap_config = {
> > .max_register = 0x,
> >   };
> >   
> > +static const struct regmap_config pwrap_regmap_config32 = {
> > +   .reg_bits = 32,
> > +   .val_bits = 32,
> > +   .reg_stride = 4,
> > +   .reg_read = pwrap_regmap_read,
> > +   .reg_write = pwrap_regmap_write,
> > +   .max_register = 0x,
> > +};
> > +
> >   static const struct pwrap_slv_type pmic_mt6323 = {
> > .dew_regs = mt6323_regs,
> > .type = PMIC_MT6323,
> > +   .regmap = _regmap_config16,
> > .pwrap_read = pwrap_read16,
> > .pwrap_write = pwrap_write16,
> >   };
> > @@ -1128,6 +1139,7 @@ static const struct pwrap_slv_type pmic_mt6323 = {
> >   static const struct pwrap_slv_type pmic_mt6380 = {
> > .dew_regs = NULL,
> > .type = PMIC_MT6380,
> > +   .regmap = _regmap_config32,
> > .pwrap_read = pwrap_read32,
> > .pwrap_write = pwrap_write32,
> >   };
> > @@ -1135,6 +1147,7 @@ static const struct pwrap_slv_type pmic_mt6380 = {
> >   static const struct pwrap_slv_type pmic_mt6397 = {
> > .dew_regs = mt6397_regs,
> > .type = PMIC_MT6397,
> > +   .regmap = _regmap_config16,
> > .pwrap_read = pwrap_read16,
> > .pwrap_write = pwrap_write16,
> >   };
> > @@ -1144,9 +1157,15 @@ static const struct of_device_id 
> > of_slave_match_tbl[] = {
> > .compatible = "mediatek,mt6323",
> > .data = _mt6323,
> > }, {
> > +   /* The MT6380 slave device is directly pointed to the regulator
> > +* device which is different from the cases MT6323 and MT6397
> > +* where they're one kind of MFDs.
> > +*/
> > +   .compatible = "mediatek,mt6380-regulator",
> > +   .data = _mt6380,
> 
> I understand that mt6380 only provides a regulator and no other function 
> other 
> PMICs provide, right?

> Then maybe write a comment like:
> The MT6380 PMIC only implements a regulator, so we bind it directly instead 
> of 
> using a MFD. If so, we should state that in the pwrap bindings document, I 
> think.
> 

You're right. It is worth making them better in both comments and the
bindings document. I'll do it in the next version.


> Regards,
> Matthias

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

Dear Kishon,

Could you please review this patch?
After that, I'll make the immutable brand and then send the pull request
for power_supply, mfd, phy, usb and extcon framework.

On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
> 
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
> 
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
> 
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: Greg Kroah-Hartman 
> Acked-by: Sebastian Reichel 
> Acked-by: Chen-Yu Tsai 
> Acked-by: Charles Keepax 
> Acked-by: Lee Jones 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Don't touch drivers/usb/renesas_usbhs/common.h.
> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
> 
>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>  drivers/extcon/extcon-arizona.c   |   2 +-
>  drivers/extcon/extcon-axp288.c|   2 +-
>  drivers/extcon/extcon-gpio.c  |   2 +-
>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>  drivers/extcon/extcon-max14577.c  |   2 +-
>  drivers/extcon/extcon-max3355.c   |   2 +-
>  drivers/extcon/extcon-max77693.c  |   2 +-
>  drivers/extcon/extcon-max77843.c  |   2 +-
>  drivers/extcon/extcon-max8997.c   |   2 +-
>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>  drivers/extcon/extcon-sm5502.c|   2 +-
>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>  drivers/extcon/extcon.h   |   2 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>  drivers/power/supply/qcom_smbb.c  |   2 +-
>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
>  drivers/usb/phy/phy-tahvo.c   |   2 +-
>  include/linux/extcon-provider.h   | 142 
> ++
>  include/linux/extcon.h| 109 +---
>  include/linux/mfd/palmas.h|   2 +-
>  27 files changed, 172 insertions(+), 129 deletions(-)
>  create mode 100644 include/linux/extcon-provider.h
> 
> diff --git a/drivers/extcon/extcon-adc-jack.c 
> b/drivers/extcon/extcon-adc-jack.c
> index 6f6537ab0a79..3877d86c746a 100644
> --- a/drivers/extcon/extcon-adc-jack.c
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  /**
>   * struct adc_jack_data - internal data for adc_jack device driver
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index f84da4a17724..da0e9bc4262f 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git 

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

Dear Kishon,

Could you please review this patch?
After that, I'll make the immutable brand and then send the pull request
for power_supply, mfd, phy, usb and extcon framework.

On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
> 
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
> 
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
> 
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: Greg Kroah-Hartman 
> Acked-by: Sebastian Reichel 
> Acked-by: Chen-Yu Tsai 
> Acked-by: Charles Keepax 
> Acked-by: Lee Jones 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Don't touch drivers/usb/renesas_usbhs/common.h.
> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
> 
>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>  drivers/extcon/extcon-arizona.c   |   2 +-
>  drivers/extcon/extcon-axp288.c|   2 +-
>  drivers/extcon/extcon-gpio.c  |   2 +-
>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>  drivers/extcon/extcon-max14577.c  |   2 +-
>  drivers/extcon/extcon-max3355.c   |   2 +-
>  drivers/extcon/extcon-max77693.c  |   2 +-
>  drivers/extcon/extcon-max77843.c  |   2 +-
>  drivers/extcon/extcon-max8997.c   |   2 +-
>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>  drivers/extcon/extcon-sm5502.c|   2 +-
>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>  drivers/extcon/extcon.h   |   2 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>  drivers/power/supply/qcom_smbb.c  |   2 +-
>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
>  drivers/usb/phy/phy-tahvo.c   |   2 +-
>  include/linux/extcon-provider.h   | 142 
> ++
>  include/linux/extcon.h| 109 +---
>  include/linux/mfd/palmas.h|   2 +-
>  27 files changed, 172 insertions(+), 129 deletions(-)
>  create mode 100644 include/linux/extcon-provider.h
> 
> diff --git a/drivers/extcon/extcon-adc-jack.c 
> b/drivers/extcon/extcon-adc-jack.c
> index 6f6537ab0a79..3877d86c746a 100644
> --- a/drivers/extcon/extcon-adc-jack.c
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  /**
>   * struct adc_jack_data - internal data for adc_jack device driver
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index f84da4a17724..da0e9bc4262f 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index f4fd03e58e37..981fba56bc18 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -22,7 

RE: [PATCH 2/2] pci/layerscape: change the default error response behavior

[Z.q. Hou]

Hi Bjorn,

Thanks a lot for your review!

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2017年10月12日 3:41
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang
> ; Mingkai Hu ; M.h. Lian
> 
> Subject: Re: [PATCH 2/2] pci/layerscape: change the default error response
> behavior
> 
> On Fri, Sep 22, 2017 at 03:25:22PM +0800, Zhiqiang Hou wrote:
> > From: Minghuan Lian 
> >
> > By default, when the PCIe controller experiences an erroneous
> > completion from an external completer for its outbound non-posted
> > request, it always sends an OKAY response to the device's internal AXI
> > slave system interface. However, such default system error response
> > behavior cannot be used for other types of outbound non-posted
> > requests. For example, the outbound memory read transaction requires
> > an actual ERROR response, like UR completion or completion timeout.
> > The patch is to fix it by forwarding the error response of the
> > non-posted request.
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/dwc/pci-layerscape.c | 25 +
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pci-layerscape.c
> > b/drivers/pci/dwc/pci-layerscape.c
> > index 3b01e309a55e..a647090c140e 100644
> > --- a/drivers/pci/dwc/pci-layerscape.c
> > +++ b/drivers/pci/dwc/pci-layerscape.c
> > @@ -33,6 +33,8 @@
> >
> >  /* PEX Internal Configuration Registers */
> >  #define PCIE_STRFMR1   0x71c /* Symbol Timer & Filter Mask
> Register1 */
> > +#define PCIE_ABSERR0x8d0 /* Bridge Slave Error Response
> Register */
> > +#define PCIE_ABSERR_SETTING0x9401 /* Forward error of non-posted
> request */
> >
> >  #define PCIE_IATU_NUM  6
> >
> > @@ -54,6 +56,19 @@ struct ls_pcie {
> >
> >  #define to_ls_pcie(x)  dev_get_drvdata((x)->dev)
> >
> > +static int err_response_flag = 1;
> > +
> > +static int __init ls_pcie_param(char *p) {
> > +   if (p && strncmp(p, "no-err-response", 15) == 0)
> > +   err_response_flag = 0;
> > +   else
> > +   err_response_flag = 1;
> > +
> > +   return 0;
> > +}
> > +early_param("ls_pcie", ls_pcie_param);
> 
> What's the point of this parameter?  If it's for debugging, it's not clear 
> that
> we need it upstream.  If it's for debugging and we *do* need it upstream,
> there should be some sort of comment to that effect.
> 
> I assume you never expect an end user to need this parameter.

It is for debugging, will drop this parameter next version.

> 
> >  static bool ls_pcie_is_bridge(struct ls_pcie *pcie)  {
> > struct dw_pcie *pci = pcie->pci;
> > @@ -124,6 +139,14 @@ static int ls_pcie_link_up(struct dw_pcie *pci)
> > return 1;
> >  }
> >
> > +/* Forward error response of outbound non-posted requests */ static
> > +void ls_pcie_fix_error_response(struct ls_pcie *pcie) {
> > +   struct dw_pcie *pci = pcie->pci;
> > +
> > +   iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR); }
> > +
> >  static int ls_pcie_host_init(struct pcie_port *pp)  {
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); @@ -135,6 +158,8 @@
> > static int ls_pcie_host_init(struct pcie_port *pp)
> >  * dw_pcie_setup_rc() will reconfigure the outbound windows.
> >  */
> > ls_pcie_disable_outbound_atus(pcie);
> > +   if (err_response_flag)
> > +   ls_pcie_fix_error_response(pcie);
> >
> > dw_pcie_dbi_ro_wr_en(pci);
> > ls_pcie_clear_multifunction(pcie);
> > --
> > 2.14.1
> >

Thanks,
Zhiqiang

RE: [PATCH 2/2] pci/layerscape: change the default error response behavior

[Z.q. Hou]

Hi Bjorn,

Thanks a lot for your review!

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2017年10月12日 3:41
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang
> ; Mingkai Hu ; M.h. Lian
> 
> Subject: Re: [PATCH 2/2] pci/layerscape: change the default error response
> behavior
> 
> On Fri, Sep 22, 2017 at 03:25:22PM +0800, Zhiqiang Hou wrote:
> > From: Minghuan Lian 
> >
> > By default, when the PCIe controller experiences an erroneous
> > completion from an external completer for its outbound non-posted
> > request, it always sends an OKAY response to the device's internal AXI
> > slave system interface. However, such default system error response
> > behavior cannot be used for other types of outbound non-posted
> > requests. For example, the outbound memory read transaction requires
> > an actual ERROR response, like UR completion or completion timeout.
> > The patch is to fix it by forwarding the error response of the
> > non-posted request.
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/dwc/pci-layerscape.c | 25 +
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pci-layerscape.c
> > b/drivers/pci/dwc/pci-layerscape.c
> > index 3b01e309a55e..a647090c140e 100644
> > --- a/drivers/pci/dwc/pci-layerscape.c
> > +++ b/drivers/pci/dwc/pci-layerscape.c
> > @@ -33,6 +33,8 @@
> >
> >  /* PEX Internal Configuration Registers */
> >  #define PCIE_STRFMR1   0x71c /* Symbol Timer & Filter Mask
> Register1 */
> > +#define PCIE_ABSERR0x8d0 /* Bridge Slave Error Response
> Register */
> > +#define PCIE_ABSERR_SETTING0x9401 /* Forward error of non-posted
> request */
> >
> >  #define PCIE_IATU_NUM  6
> >
> > @@ -54,6 +56,19 @@ struct ls_pcie {
> >
> >  #define to_ls_pcie(x)  dev_get_drvdata((x)->dev)
> >
> > +static int err_response_flag = 1;
> > +
> > +static int __init ls_pcie_param(char *p) {
> > +   if (p && strncmp(p, "no-err-response", 15) == 0)
> > +   err_response_flag = 0;
> > +   else
> > +   err_response_flag = 1;
> > +
> > +   return 0;
> > +}
> > +early_param("ls_pcie", ls_pcie_param);
> 
> What's the point of this parameter?  If it's for debugging, it's not clear 
> that
> we need it upstream.  If it's for debugging and we *do* need it upstream,
> there should be some sort of comment to that effect.
> 
> I assume you never expect an end user to need this parameter.

It is for debugging, will drop this parameter next version.

> 
> >  static bool ls_pcie_is_bridge(struct ls_pcie *pcie)  {
> > struct dw_pcie *pci = pcie->pci;
> > @@ -124,6 +139,14 @@ static int ls_pcie_link_up(struct dw_pcie *pci)
> > return 1;
> >  }
> >
> > +/* Forward error response of outbound non-posted requests */ static
> > +void ls_pcie_fix_error_response(struct ls_pcie *pcie) {
> > +   struct dw_pcie *pci = pcie->pci;
> > +
> > +   iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR); }
> > +
> >  static int ls_pcie_host_init(struct pcie_port *pp)  {
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); @@ -135,6 +158,8 @@
> > static int ls_pcie_host_init(struct pcie_port *pp)
> >  * dw_pcie_setup_rc() will reconfigure the outbound windows.
> >  */
> > ls_pcie_disable_outbound_atus(pcie);
> > +   if (err_response_flag)
> > +   ls_pcie_fix_error_response(pcie);
> >
> > dw_pcie_dbi_ro_wr_en(pci);
> > ls_pcie_clear_multifunction(pcie);
> > --
> > 2.14.1
> >

Thanks,
Zhiqiang

[PATCH v13] MAINTAINERS: add entry for Rockchip RGA driver

[Jacob Chen]

Signed-off-by: Jacob Chen 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6671f375f7fc..b13dae0cbf42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11509,6 +11509,13 @@ F: drivers/hid/hid-roccat*
 F: include/linux/hid-roccat*
 F: Documentation/ABI/*/sysfs-driver-hid-roccat*
 
+ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
+M: Jacob chen 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/rockchip/rga/
+F: Documentation/devicetree/bindings/media/rockchip-rga.txt
+
 ROCKER DRIVER
 M: Jiri Pirko 
 L: net...@vger.kernel.org
-- 
2.14.1

[PATCH v13] MAINTAINERS: add entry for Rockchip RGA driver

[Jacob Chen]

Signed-off-by: Jacob Chen 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6671f375f7fc..b13dae0cbf42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11509,6 +11509,13 @@ F: drivers/hid/hid-roccat*
 F: include/linux/hid-roccat*
 F: Documentation/ABI/*/sysfs-driver-hid-roccat*
 
+ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
+M: Jacob chen 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/rockchip/rga/
+F: Documentation/devicetree/bindings/media/rockchip-rga.txt
+
 ROCKER DRIVER
 M: Jiri Pirko 
 L: net...@vger.kernel.org
-- 
2.14.1

[PATCH v2] net: ftgmac100: Request clock and set speed

[Joel Stanley]

According to the ASPEED datasheet, gigabit speeds require a clock of
100MHz or higher. Other speeds require 25MHz or higher. This patch
configures a 100MHz clock if the system has a direct-attached
PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.

There appear to be no other upstream users of the FTGMAC100 driver so it
is hard to know the clocking requirements of other platforms. Therefore
a conservative approach was taken with enabling clocks. If the platform
is not ASPEED, both requesting the clock and configuring the speed is
skipped.

Signed-off-by: Joel Stanley 
---
Andrew, as I'm travelling can you please test this on the evb and a
palmetto? Use my wip/aspeed-v4.14-clk branch, or OpenBMC's dev-4.13.

David, please wait for Andrew's tested-by before applying.

Cheers!

v2:
 - only touch the clocks on Aspeed platforms
 - unconditionally call clk_unprepare_disable

 drivers/net/ethernet/faraday/ftgmac100.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 9ed8e4b81530..cd352bf41da1 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -21,6 +21,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -59,6 +60,9 @@
 /* Min number of tx ring entries before stopping queue */
 #define TX_THRESHOLD   (MAX_SKB_FRAGS + 1)
 
+#define FTGMAC_100MHZ  1
+#define FTGMAC_25MHZ   2500
+
 struct ftgmac100 {
/* Registers */
struct resource *res;
@@ -96,6 +100,7 @@ struct ftgmac100 {
struct napi_struct napi;
struct work_struct reset_task;
struct mii_bus *mii_bus;
+   struct clk *clk;
 
/* Link management */
int cur_speed;
@@ -1734,6 +1739,22 @@ static void ftgmac100_ncsi_handler(struct ncsi_dev *nd)
nd->link_up ? "up" : "down");
 }
 
+static void ftgmac100_setup_clk(struct ftgmac100_priv *priv)
+{
+   priv->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(priv->clk))
+   return;
+
+   clk_prepare_enable(priv->clk);
+
+   /* Aspeed specifies a 100MHz clock is required for up to
+* 1000Mbit link speeds. As NCSI is limited to 100Mbit, 25MHz
+* is sufficient
+*/
+   clk_set_rate(priv->clk, priv->is_ncsi ? FTGMAC_25MHZ :
+   FTGMAC_100MHZ);
+}
+
 static int ftgmac100_probe(struct platform_device *pdev)
 {
struct resource *res;
@@ -1830,6 +1851,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
goto err_setup_mdio;
}
 
+   if (priv->is_aspeed)
+   ftgmac100_setup_clk(priv);
+
/* Default ring sizes */
priv->rx_q_entries = priv->new_rx_q_entries = DEF_RX_QUEUE_ENTRIES;
priv->tx_q_entries = priv->new_tx_q_entries = DEF_TX_QUEUE_ENTRIES;
@@ -1883,6 +1907,8 @@ static int ftgmac100_remove(struct platform_device *pdev)
 
unregister_netdev(netdev);
 
+   clk_disable_unprepare(priv->clk);
+
/* There's a small chance the reset task will have been re-queued,
 * during stop, make sure it's gone before we free the structure.
 */
-- 
2.14.1

[PATCH v2] net: ftgmac100: Request clock and set speed

[Joel Stanley]

According to the ASPEED datasheet, gigabit speeds require a clock of
100MHz or higher. Other speeds require 25MHz or higher. This patch
configures a 100MHz clock if the system has a direct-attached
PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.

There appear to be no other upstream users of the FTGMAC100 driver so it
is hard to know the clocking requirements of other platforms. Therefore
a conservative approach was taken with enabling clocks. If the platform
is not ASPEED, both requesting the clock and configuring the speed is
skipped.

Signed-off-by: Joel Stanley 
---
Andrew, as I'm travelling can you please test this on the evb and a
palmetto? Use my wip/aspeed-v4.14-clk branch, or OpenBMC's dev-4.13.

David, please wait for Andrew's tested-by before applying.

Cheers!

v2:
 - only touch the clocks on Aspeed platforms
 - unconditionally call clk_unprepare_disable

 drivers/net/ethernet/faraday/ftgmac100.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 9ed8e4b81530..cd352bf41da1 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -21,6 +21,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -59,6 +60,9 @@
 /* Min number of tx ring entries before stopping queue */
 #define TX_THRESHOLD   (MAX_SKB_FRAGS + 1)
 
+#define FTGMAC_100MHZ  1
+#define FTGMAC_25MHZ   2500
+
 struct ftgmac100 {
/* Registers */
struct resource *res;
@@ -96,6 +100,7 @@ struct ftgmac100 {
struct napi_struct napi;
struct work_struct reset_task;
struct mii_bus *mii_bus;
+   struct clk *clk;
 
/* Link management */
int cur_speed;
@@ -1734,6 +1739,22 @@ static void ftgmac100_ncsi_handler(struct ncsi_dev *nd)
nd->link_up ? "up" : "down");
 }
 
+static void ftgmac100_setup_clk(struct ftgmac100_priv *priv)
+{
+   priv->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(priv->clk))
+   return;
+
+   clk_prepare_enable(priv->clk);
+
+   /* Aspeed specifies a 100MHz clock is required for up to
+* 1000Mbit link speeds. As NCSI is limited to 100Mbit, 25MHz
+* is sufficient
+*/
+   clk_set_rate(priv->clk, priv->is_ncsi ? FTGMAC_25MHZ :
+   FTGMAC_100MHZ);
+}
+
 static int ftgmac100_probe(struct platform_device *pdev)
 {
struct resource *res;
@@ -1830,6 +1851,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
goto err_setup_mdio;
}
 
+   if (priv->is_aspeed)
+   ftgmac100_setup_clk(priv);
+
/* Default ring sizes */
priv->rx_q_entries = priv->new_rx_q_entries = DEF_RX_QUEUE_ENTRIES;
priv->tx_q_entries = priv->new_tx_q_entries = DEF_TX_QUEUE_ENTRIES;
@@ -1883,6 +1907,8 @@ static int ftgmac100_remove(struct platform_device *pdev)
 
unregister_netdev(netdev);
 
+   clk_disable_unprepare(priv->clk);
+
/* There's a small chance the reset task will have been re-queued,
 * during stop, make sure it's gone before we free the structure.
 */
-- 
2.14.1

Re: [PATCH][bpf-next] bpf: remove redundant variable old_flags

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 11:56:23 +0100

> From: Colin Ian King 
> 
> Variable old_flags is being assigned but is never read; it is redundant
> and can be removed.
> 
> Cleans up clang warning: Value stored to 'old_flags' is never read
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH][bpf-next] bpf: remove redundant variable old_flags

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 11:56:23 +0100

> From: Colin Ian King 
> 
> Variable old_flags is being assigned but is never read; it is redundant
> and can be removed.
> 
> Cleans up clang warning: Value stored to 'old_flags' is never read
> 
> Signed-off-by: Colin Ian King 

Applied.

[PATCH] scripts: fix faddr2line to work on last symbol

[NeilBrown]

If faddr2line is given a function name which is the
last one listed by "nm -n", it will fail because it
never finds the next symbol.

So teach the awk script to catch that possibility,
and use 'size' to provide the end point of the last
function.

Signed-off-by: NeilBrown 
---
 scripts/faddr2line | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/faddr2line b/scripts/faddr2line
index 29df825d375c..2f6ce802397d 100755
--- a/scripts/faddr2line
+++ b/scripts/faddr2line
@@ -103,11 +103,12 @@ __faddr2line() {
 
# Go through each of the object's symbols which match the func name.
# In rare cases there might be duplicates.
+   file_end=$(size -Ax $objfile | awk '$1 == ".text" {print $2}')
while read symbol; do
local fields=($symbol)
local sym_base=0x${fields[0]}
local sym_type=${fields[1]}
-   local sym_end=0x${fields[3]}
+   local sym_end=${fields[3]}
 
# calculate the size
local sym_size=$(($sym_end - $sym_base))
@@ -157,7 +158,7 @@ __faddr2line() {
addr2line -fpie $objfile $addr | sed "s; $dir_prefix\(\./\)*; ;"
DONE=1
 
-   done < <(nm -n $objfile | awk -v fn=$func '$3 == fn { found=1; line=$0; 
start=$1; next } found == 1 { found=0; print line, $1 }')
+   done < <(nm -n $objfile | awk -v fn=$func -v end=$file_end '$3 == fn { 
found=1; line=$0; start=$1; next } found == 1 { found=0; print line, "0x"$1 } 
END {if (found == 1) print line, end; }')
 }
 
 [[ $# -lt 2 ]] && usage
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

[PATCH] scripts: fix faddr2line to work on last symbol

[NeilBrown]

If faddr2line is given a function name which is the
last one listed by "nm -n", it will fail because it
never finds the next symbol.

So teach the awk script to catch that possibility,
and use 'size' to provide the end point of the last
function.

Signed-off-by: NeilBrown 
---
 scripts/faddr2line | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/faddr2line b/scripts/faddr2line
index 29df825d375c..2f6ce802397d 100755
--- a/scripts/faddr2line
+++ b/scripts/faddr2line
@@ -103,11 +103,12 @@ __faddr2line() {
 
# Go through each of the object's symbols which match the func name.
# In rare cases there might be duplicates.
+   file_end=$(size -Ax $objfile | awk '$1 == ".text" {print $2}')
while read symbol; do
local fields=($symbol)
local sym_base=0x${fields[0]}
local sym_type=${fields[1]}
-   local sym_end=0x${fields[3]}
+   local sym_end=${fields[3]}
 
# calculate the size
local sym_size=$(($sym_end - $sym_base))
@@ -157,7 +158,7 @@ __faddr2line() {
addr2line -fpie $objfile $addr | sed "s; $dir_prefix\(\./\)*; ;"
DONE=1
 
-   done < <(nm -n $objfile | awk -v fn=$func '$3 == fn { found=1; line=$0; 
start=$1; next } found == 1 { found=0; print line, $1 }')
+   done < <(nm -n $objfile | awk -v fn=$func -v end=$file_end '$3 == fn { 
found=1; line=$0; start=$1; next } found == 1 { found=0; print line, "0x"$1 } 
END {if (found == 1) print line, end; }')
 }
 
 [[ $# -lt 2 ]] && usage
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: [PATCH v3 5/9] soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode

[Sean Wang]

On Tue, 2017-10-10 at 11:38 +0200, Matthias Brugger wrote:
> 
> On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > Some regulators such as MediaTek MT6380 also has to be written in
> > 32-bit mode. So the patch adds pwrap_write32, rename old pwrap_write
> > into pwrap_write16 and one additional function pointer is introduced
> > for increasing flexibility allowing the determination which mode is
> > used by the pwrap slave detection through device tree.
> > 
> > Signed-off-by: Chenglin Xu 
> > Signed-off-by: Chen Zhong 
> > Signed-off-by: Sean Wang 
> > ---
> >   drivers/soc/mediatek/mtk-pmic-wrap.c | 63 
> > +++-
> >   1 file changed, 47 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index 7cd581b..9d1f4c6 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -506,6 +506,7 @@ struct pwrap_slv_type {
> >  * which type is used by the detection through device tree.
> >  */
> > int (*pwrap_read)(struct pmic_wrapper *wrp, u32 adr, u32 *rdata);
> > +   int (*pwrap_write)(struct pmic_wrapper *wrp, u32 adr, u32 wdata);
> >   };
> >   
> >   struct pmic_wrapper {
> > @@ -600,22 +601,6 @@ static int pwrap_wait_for_state(struct pmic_wrapper 
> > *wrp,
> > } while (1);
> >   }
> >   
> > -static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > -{
> > -   int ret;
> > -
> > -   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > -   if (ret) {
> > -   pwrap_leave_fsm_vldclr(wrp);
> > -   return ret;
> > -   }
> > -
> > -   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> > -   PWRAP_WACS2_CMD);
> > -
> > -   return 0;
> > -}
> > -
> >   static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
> >   {
> > int ret;
> > @@ -672,6 +657,49 @@ static int pwrap_read(struct pmic_wrapper *wrp, u32 
> > adr, u32 *rdata)
> > return wrp->slave->pwrap_read(wrp, adr, rdata);
> >   }
> >   
> > +static int pwrap_write16(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > +{
> > +   int ret;
> > +
> > +   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > +   if (ret) {
> > +   pwrap_leave_fsm_vldclr(wrp);
> > +   return ret;
> > +   }
> > +
> > +   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> > +PWRAP_WACS2_CMD);
> > +
> > +   return 0;
> > +}
> > +
> > +static int pwrap_write32(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > +{
> > +   int ret, msb, rdata;
> > +
> > +   for (msb = 0; msb < 2; msb++) {
> > +   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > +   if (ret) {
> > +   pwrap_leave_fsm_vldclr(wrp);
> > +   return ret;
> > +   }
> > +
> > +   pwrap_writel(wrp, (1 << 31) | (msb << 30) | (adr << 16) |
> > +((wdata >> (msb * 16)) & 0x),
> > +PWRAP_WACS2_CMD);
> > +
> > +   if (!msb)
> > +   pwrap_read(wrp, adr, );
> 
> Just so that I understand, you have to read back the half-written register 
> before you can write the second part?
> 

Yup, the pwrap_read operation is the requirement of hardware used for
the synchronization between two successive 16-bit pwrap_writel
operations composing one 32-bit bus writing. Otherwise, we'll find the
result fails for the lower 16-bit pwrap writing.


> Other then that it looks fine to me.
> 
> Regards,
> Matthias

Re: [PATCH v3 5/9] soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode

[Sean Wang]

On Tue, 2017-10-10 at 11:38 +0200, Matthias Brugger wrote:
> 
> On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > Some regulators such as MediaTek MT6380 also has to be written in
> > 32-bit mode. So the patch adds pwrap_write32, rename old pwrap_write
> > into pwrap_write16 and one additional function pointer is introduced
> > for increasing flexibility allowing the determination which mode is
> > used by the pwrap slave detection through device tree.
> > 
> > Signed-off-by: Chenglin Xu 
> > Signed-off-by: Chen Zhong 
> > Signed-off-by: Sean Wang 
> > ---
> >   drivers/soc/mediatek/mtk-pmic-wrap.c | 63 
> > +++-
> >   1 file changed, 47 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index 7cd581b..9d1f4c6 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -506,6 +506,7 @@ struct pwrap_slv_type {
> >  * which type is used by the detection through device tree.
> >  */
> > int (*pwrap_read)(struct pmic_wrapper *wrp, u32 adr, u32 *rdata);
> > +   int (*pwrap_write)(struct pmic_wrapper *wrp, u32 adr, u32 wdata);
> >   };
> >   
> >   struct pmic_wrapper {
> > @@ -600,22 +601,6 @@ static int pwrap_wait_for_state(struct pmic_wrapper 
> > *wrp,
> > } while (1);
> >   }
> >   
> > -static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > -{
> > -   int ret;
> > -
> > -   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > -   if (ret) {
> > -   pwrap_leave_fsm_vldclr(wrp);
> > -   return ret;
> > -   }
> > -
> > -   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> > -   PWRAP_WACS2_CMD);
> > -
> > -   return 0;
> > -}
> > -
> >   static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
> >   {
> > int ret;
> > @@ -672,6 +657,49 @@ static int pwrap_read(struct pmic_wrapper *wrp, u32 
> > adr, u32 *rdata)
> > return wrp->slave->pwrap_read(wrp, adr, rdata);
> >   }
> >   
> > +static int pwrap_write16(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > +{
> > +   int ret;
> > +
> > +   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > +   if (ret) {
> > +   pwrap_leave_fsm_vldclr(wrp);
> > +   return ret;
> > +   }
> > +
> > +   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> > +PWRAP_WACS2_CMD);
> > +
> > +   return 0;
> > +}
> > +
> > +static int pwrap_write32(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > +{
> > +   int ret, msb, rdata;
> > +
> > +   for (msb = 0; msb < 2; msb++) {
> > +   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > +   if (ret) {
> > +   pwrap_leave_fsm_vldclr(wrp);
> > +   return ret;
> > +   }
> > +
> > +   pwrap_writel(wrp, (1 << 31) | (msb << 30) | (adr << 16) |
> > +((wdata >> (msb * 16)) & 0x),
> > +PWRAP_WACS2_CMD);
> > +
> > +   if (!msb)
> > +   pwrap_read(wrp, adr, );
> 
> Just so that I understand, you have to read back the half-written register 
> before you can write the second part?
> 

Yup, the pwrap_read operation is the requirement of hardware used for
the synchronization between two successive 16-bit pwrap_writel
operations composing one 32-bit bus writing. Otherwise, we'll find the
result fails for the lower 16-bit pwrap writing.


> Other then that it looks fine to me.
> 
> Regards,
> Matthias

Re: [PATCH][net-next] net: mpls: make function ipgre_mpls_encap_hlen static

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 10:53:28 +0100

> From: Colin Ian King 
> 
> The function ipgre_mpls_encap_hlen is local to the source and
> does not need to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'ipgre_mpls_encap_hlen' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Applied, thanks Colin.

Re: [PATCH][net-next] net: mpls: make function ipgre_mpls_encap_hlen static

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 10:53:28 +0100

> From: Colin Ian King 
> 
> The function ipgre_mpls_encap_hlen is local to the source and
> does not need to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'ipgre_mpls_encap_hlen' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Applied, thanks Colin.

Re: [PATCH][next] sctp: make array sctp_sched_ops static

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 11:17:57 +0100

> From: Colin Ian King 
> 
> The array sctp_sched_ops  is local to the source and
> does not need to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'sctp_sched_ops' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH][next] sctp: make array sctp_sched_ops static

[David Miller]

From: Colin King 
Date: Wed, 11 Oct 2017 11:17:57 +0100

> From: Colin Ian King 
> 
> The array sctp_sched_ops  is local to the source and
> does not need to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'sctp_sched_ops' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Applied.

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

[Z.q. Hou]

Hi Bjorn,

Thanks a lot for your comments!

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2017年10月12日 3:38
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang
> ; Mingkai Hu ; M.h. Lian
> 
> Subject: Re: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode
> 
> On Fri, Sep 22, 2017 at 03:25:21PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The Freescale PCIe controller advertises the MSI/MSI-X capability in
> > both RC and Endpoint mode, but in RC mode it doesn't support MSI/MSI-X
> > by it self, it can only transfer MSI/MSI-X from downstream
> 
> s/it self,/itself;/

I'll fix this typo in next version.

> > devices. So add this quirk to prevent use of MSI/MSI-X in RC mode.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/quirks.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > a4d33619a7bb..c1063a420f0c 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4799,3 +4799,11 @@ static void quirk_no_ats(struct pci_dev *pdev)
> >  /* AMD Stoney platform GPU */
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
> > #endif /* CONFIG_PCI_ATS */
> > +
> > +/* Freescale PCIe doesn't support MSI in RC mode */ static void
> > +quirk_fsl_no_msi(struct pci_dev *pdev) {
> > +   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
> > +   pdev->no_msi = 1;
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> > +quirk_fsl_no_msi);
> 
> This disables MSI for all Freescale root ports, past, present, and future.  Is
> that really what you want?  This is a bug (the root port shouldn't advertise
> MSI if it doesn't support it), and presumably it might be fixed in some future
> device?

For the past and present, there isn't Freescale root ports supporting MSI. If 
the future Freescale root port support MSI, I'll add a patch for it checking 
the PCI device ID to determine if apply the quirk.
And it should be ok for the root ports without this bug.

> 
> This needs an ack from Minghuan or Mingkai (based on MAINTAINERS).
> 

Thanks,
Zhiqiang

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

[Z.q. Hou]

Hi Bjorn,

Thanks a lot for your comments!

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2017年10月12日 3:38
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang
> ; Mingkai Hu ; M.h. Lian
> 
> Subject: Re: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode
> 
> On Fri, Sep 22, 2017 at 03:25:21PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The Freescale PCIe controller advertises the MSI/MSI-X capability in
> > both RC and Endpoint mode, but in RC mode it doesn't support MSI/MSI-X
> > by it self, it can only transfer MSI/MSI-X from downstream
> 
> s/it self,/itself;/

I'll fix this typo in next version.

> > devices. So add this quirk to prevent use of MSI/MSI-X in RC mode.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/quirks.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > a4d33619a7bb..c1063a420f0c 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4799,3 +4799,11 @@ static void quirk_no_ats(struct pci_dev *pdev)
> >  /* AMD Stoney platform GPU */
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
> > #endif /* CONFIG_PCI_ATS */
> > +
> > +/* Freescale PCIe doesn't support MSI in RC mode */ static void
> > +quirk_fsl_no_msi(struct pci_dev *pdev) {
> > +   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
> > +   pdev->no_msi = 1;
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> > +quirk_fsl_no_msi);
> 
> This disables MSI for all Freescale root ports, past, present, and future.  Is
> that really what you want?  This is a bug (the root port shouldn't advertise
> MSI if it doesn't support it), and presumably it might be fixed in some future
> device?

For the past and present, there isn't Freescale root ports supporting MSI. If 
the future Freescale root port support MSI, I'll add a patch for it checking 
the PCI device ID to determine if apply the quirk.
And it should be ok for the root ports without this bug.

> 
> This needs an ack from Minghuan or Mingkai (based on MAINTAINERS).
> 

Thanks,
Zhiqiang

Re: [PATCH net] net/ncsi: Don't limit vids based on hot_channel

[David Miller]

From: Samuel Mendoza-Jonas 
Date: Wed, 11 Oct 2017 16:54:27 +1100

> Currently we drop any new VLAN ids if there are more than the current
> (or last used) channel can support. Most importantly this is a problem
> if no channel has been selected yet, resulting in a segfault.
> 
> Secondly this does not necessarily reflect the capabilities of any other
> channels. Instead only drop a new VLAN id if we are already tracking the
> maximum allowed by the NCSI specification. Per-channel limits are
> already handled by ncsi_add_filter(), but add a message to set_one_vid()
> to make it obvious that the channel can not support any more VLAN ids.
> 
> Signed-off-by: Samuel Mendoza-Jonas 

Applied, thanks.

Re: [PATCH net] net/ncsi: Don't limit vids based on hot_channel

[David Miller]

From: Samuel Mendoza-Jonas 
Date: Wed, 11 Oct 2017 16:54:27 +1100

> Currently we drop any new VLAN ids if there are more than the current
> (or last used) channel can support. Most importantly this is a problem
> if no channel has been selected yet, resulting in a segfault.
> 
> Secondly this does not necessarily reflect the capabilities of any other
> channels. Instead only drop a new VLAN id if we are already tracking the
> maximum allowed by the NCSI specification. Per-channel limits are
> already handled by ncsi_add_filter(), but add a message to set_one_vid()
> to make it obvious that the channel can not support any more VLAN ids.
> 
> Signed-off-by: Samuel Mendoza-Jonas 

Applied, thanks.

RE: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support

[M.h. Lian]

Hi Bjorn,

I greatly appreciate for your review and picking up them.

Acked-by: Minghuan Lian 


> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Thursday, October 12, 2017 2:57 AM
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; marc.zyng...@arm.com; robh...@kernel.org;
> mark.rutl...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Mingkai Hu ; M.h. Lian ; Roy
> Zang ; Thomas Gleixner ; Jason
> Cooper 
> Subject: Re: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support
> 
> On Tue, Sep 19, 2017 at 05:26:53PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > This patch set adds ls1012a MSI and PCIe support, including driver and
> > device tree nodes. The ls1046a's MSI support patch and PCIe driver
> > patch has been applied, so only adds the PCIe device tree nodes.
> >
> > Hou Zhiqiang (5):
> >   irqchip/ls-scfg-msi: add LS1012a MSI support
> >   arm64: dts: ls1012a: Add MSI controller DT node
> >   PCI: layerscape: Add support for ls1012a
> >   arm64: dts: ls1012a: Add PCIe controller DT node
> >   arm64: dts: ls1046a: add PCIe controller DT nodes
> >
> >  .../interrupt-controller/fsl,ls-scfg-msi.txt   |  1 +
> >  .../devicetree/bindings/pci/layerscape-pci.txt |  1 +
> >  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 31 +
> >  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 75
> ++
> >  drivers/irqchip/irq-ls-scfg-msi.c  |  1 +
> >  drivers/pci/dwc/pci-layerscape.c   |  1 +
> >  6 files changed, 110 insertions(+)
> 
> I'm not 100% sure who should take these.  They trivially touch PCI and I 
> haven't
> seen anybody else respond, so I put them on pci/host-layerscape with Rob's 
> acks.
> 
> If somebody else wants to take them, just let me know and I'll drop them.
> 
> They really should be acked by Minghuan or Mingkai, who are listed as the
> maintainers of drivers/pci/dwc/pci-layerscape.c and are presumably responsible
> for the related dtsi files, too.
> 
> Thomas, Jason, and Marc are listed as maintainers of 
> drivers/irqchip/irq-ls-scfg-
> msi.c.  It's a trivial change, but I added them to the cc list.

RE: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support

[M.h. Lian]

Hi Bjorn,

I greatly appreciate for your review and picking up them.

Acked-by: Minghuan Lian 


> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Thursday, October 12, 2017 2:57 AM
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; marc.zyng...@arm.com; robh...@kernel.org;
> mark.rutl...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Mingkai Hu ; M.h. Lian ; Roy
> Zang ; Thomas Gleixner ; Jason
> Cooper 
> Subject: Re: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support
> 
> On Tue, Sep 19, 2017 at 05:26:53PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > This patch set adds ls1012a MSI and PCIe support, including driver and
> > device tree nodes. The ls1046a's MSI support patch and PCIe driver
> > patch has been applied, so only adds the PCIe device tree nodes.
> >
> > Hou Zhiqiang (5):
> >   irqchip/ls-scfg-msi: add LS1012a MSI support
> >   arm64: dts: ls1012a: Add MSI controller DT node
> >   PCI: layerscape: Add support for ls1012a
> >   arm64: dts: ls1012a: Add PCIe controller DT node
> >   arm64: dts: ls1046a: add PCIe controller DT nodes
> >
> >  .../interrupt-controller/fsl,ls-scfg-msi.txt   |  1 +
> >  .../devicetree/bindings/pci/layerscape-pci.txt |  1 +
> >  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 31 +
> >  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 75
> ++
> >  drivers/irqchip/irq-ls-scfg-msi.c  |  1 +
> >  drivers/pci/dwc/pci-layerscape.c   |  1 +
> >  6 files changed, 110 insertions(+)
> 
> I'm not 100% sure who should take these.  They trivially touch PCI and I 
> haven't
> seen anybody else respond, so I put them on pci/host-layerscape with Rob's 
> acks.
> 
> If somebody else wants to take them, just let me know and I'll drop them.
> 
> They really should be acked by Minghuan or Mingkai, who are listed as the
> maintainers of drivers/pci/dwc/pci-layerscape.c and are presumably responsible
> for the related dtsi files, too.
> 
> Thomas, Jason, and Marc are listed as maintainers of 
> drivers/irqchip/irq-ls-scfg-
> msi.c.  It's a trivial change, but I added them to the cc list.

Re: [PATCH] net: ftgmac100: Request clock and set speed

[Joel Stanley]

On Tue, Oct 10, 2017 at 4:14 PM, Benjamin Herrenschmidt
 wrote:
> On Tue, 2017-10-10 at 15:19 +1030, Joel Stanley wrote:
>> According to the ASPEED datasheet, gigabit speeds require a clock of
>> 100MHz or higher. Other speeds require 25MHz or higher.
>
> Did you try "live" changing by either using ethtool or plugging into
> switches/hubs at different speed ?
>
> Also this is aspeed'isms, we should probably keep that under an
> is_aspeed test.
>
> My assumption is that we wouldn't bother, and just leave the freq
> set based on whether there's a physical gigabit capable connection or
> not (ie, real gigabit PHY vs. NC-SI really). But if it can help save a
> few milliwatts..

I didn't try changing the link speed at runtime. I don't have a setup
that lets me precisely measure power consumption, so it's hard to know
what the benefits are. In the future I can revisit this and do those
measurements.

I'll change it to be as you suggest; 100MHz for PHY and 50MHz for NC-SI.

Cheers,

Joel

Re: [PATCH] net: ftgmac100: Request clock and set speed

[Joel Stanley]

On Tue, Oct 10, 2017 at 4:14 PM, Benjamin Herrenschmidt
 wrote:
> On Tue, 2017-10-10 at 15:19 +1030, Joel Stanley wrote:
>> According to the ASPEED datasheet, gigabit speeds require a clock of
>> 100MHz or higher. Other speeds require 25MHz or higher.
>
> Did you try "live" changing by either using ethtool or plugging into
> switches/hubs at different speed ?
>
> Also this is aspeed'isms, we should probably keep that under an
> is_aspeed test.
>
> My assumption is that we wouldn't bother, and just leave the freq
> set based on whether there's a physical gigabit capable connection or
> not (ie, real gigabit PHY vs. NC-SI really). But if it can help save a
> few milliwatts..

I didn't try changing the link speed at runtime. I don't have a setup
that lets me precisely measure power consumption, so it's hard to know
what the benefits are. In the future I can revisit this and do those
measurements.

I'll change it to be as you suggest; 100MHz for PHY and 50MHz for NC-SI.

Cheers,

Joel

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

[M.h. Lian]

Hi Bjorn,

Thanks for your review.
Yes. All the freescale's PCIe controllers do not support to generate MSI 
interrupt.
The PCIe controllers developed for the next generation SoC do not support it 
either.

Acked-by: Minghuan Lian 

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Thursday, October 12, 2017 3:38 AM
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> p...@vger.kernel.org; bhelg...@google.com; Roy Zang ;
> Mingkai Hu ; M.h. Lian 
> Subject: Re: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode
> 
> On Fri, Sep 22, 2017 at 03:25:21PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The Freescale PCIe controller advertises the MSI/MSI-X capability in
> > both RC and Endpoint mode, but in RC mode it doesn't support MSI/MSI-X
> > by it self, it can only transfer MSI/MSI-X from downstream
> 
> s/it self,/itself;/
> 
> > devices. So add this quirk to prevent use of MSI/MSI-X in RC mode.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/quirks.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > a4d33619a7bb..c1063a420f0c 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4799,3 +4799,11 @@ static void quirk_no_ats(struct pci_dev *pdev)
> >  /* AMD Stoney platform GPU */
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
> > #endif /* CONFIG_PCI_ATS */
> > +
> > +/* Freescale PCIe doesn't support MSI in RC mode */ static void
> > +quirk_fsl_no_msi(struct pci_dev *pdev) {
> > +   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
> > +   pdev->no_msi = 1;
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> > +quirk_fsl_no_msi);
> 
> This disables MSI for all Freescale root ports, past, present, and future.  
> Is that
> really what you want?  This is a bug (the root port shouldn't advertise MSI 
> if it
> doesn't support it), and presumably it might be fixed in some future device?
> 
> This needs an ack from Minghuan or Mingkai (based on MAINTAINERS).
> 
> Bjorn

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

[M.h. Lian]

Hi Bjorn,

Thanks for your review.
Yes. All the freescale's PCIe controllers do not support to generate MSI 
interrupt.
The PCIe controllers developed for the next generation SoC do not support it 
either.

Acked-by: Minghuan Lian 

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Thursday, October 12, 2017 3:38 AM
> To: Z.q. Hou 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> p...@vger.kernel.org; bhelg...@google.com; Roy Zang ;
> Mingkai Hu ; M.h. Lian 
> Subject: Re: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode
> 
> On Fri, Sep 22, 2017 at 03:25:21PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The Freescale PCIe controller advertises the MSI/MSI-X capability in
> > both RC and Endpoint mode, but in RC mode it doesn't support MSI/MSI-X
> > by it self, it can only transfer MSI/MSI-X from downstream
> 
> s/it self,/itself;/
> 
> > devices. So add this quirk to prevent use of MSI/MSI-X in RC mode.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/quirks.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > a4d33619a7bb..c1063a420f0c 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4799,3 +4799,11 @@ static void quirk_no_ats(struct pci_dev *pdev)
> >  /* AMD Stoney platform GPU */
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
> > #endif /* CONFIG_PCI_ATS */
> > +
> > +/* Freescale PCIe doesn't support MSI in RC mode */ static void
> > +quirk_fsl_no_msi(struct pci_dev *pdev) {
> > +   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
> > +   pdev->no_msi = 1;
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> > +quirk_fsl_no_msi);
> 
> This disables MSI for all Freescale root ports, past, present, and future.  
> Is that
> really what you want?  This is a bug (the root port shouldn't advertise MSI 
> if it
> doesn't support it), and presumably it might be fixed in some future device?
> 
> This needs an ack from Minghuan or Mingkai (based on MAINTAINERS).
> 
> Bjorn

Re: [PATCH 1/2] drivers: firmware: psci: Add psci_is_available()

[Jisheng Zhang]

On Wed, 11 Oct 2017 10:03:01 +0200 Geert Uytterhoeven wrote:

> PSCI support may be disabled at build time (by configuration) or at
> run-time (PSCI firmware not present).  While CONFIG_ARM_PSCI_FW can be
> used to check for build time enablement, there is currently no simple
> way to check if PSCI is actually available and used.
> 
> Hence add a helper function to check if PSCI is available.
> 
> This is useful for e.g. drivers that are used on platforms with and
> without PSCI.  Such drivers may need to take provisions for proper
> operation when PSCI is used, and/or to implement functionality that is
> usually provided by PSCI.

the psci_ops is a global var, why not check psci_ops.mmnn members
individually in each drivers? check IS_ENABLED(CONFIG_ARM_PSCI_FW) for
building time ennoblement.

> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/firmware/psci.c | 5 +
>  include/linux/psci.h| 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index da469c972b503f83..a3a11e2d8aaa 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -670,6 +670,11 @@ int __init psci_dt_init(void)
>   return init_fn(np);
>  }
>  
> +bool psci_is_available(void)
> +{
> + return psci_ops.cpu_off && psci_ops.cpu_on && psci_ops.cpu_suspend;

IIRC, for PSCI 0.1, cpu_suspend is optional, we can't say the PSCI isn't
available if cpu_suspend is missing.

Thanks

Re: [PATCH 1/2] drivers: firmware: psci: Add psci_is_available()

[Jisheng Zhang]

On Wed, 11 Oct 2017 10:03:01 +0200 Geert Uytterhoeven wrote:

> PSCI support may be disabled at build time (by configuration) or at
> run-time (PSCI firmware not present).  While CONFIG_ARM_PSCI_FW can be
> used to check for build time enablement, there is currently no simple
> way to check if PSCI is actually available and used.
> 
> Hence add a helper function to check if PSCI is available.
> 
> This is useful for e.g. drivers that are used on platforms with and
> without PSCI.  Such drivers may need to take provisions for proper
> operation when PSCI is used, and/or to implement functionality that is
> usually provided by PSCI.

the psci_ops is a global var, why not check psci_ops.mmnn members
individually in each drivers? check IS_ENABLED(CONFIG_ARM_PSCI_FW) for
building time ennoblement.

> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/firmware/psci.c | 5 +
>  include/linux/psci.h| 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index da469c972b503f83..a3a11e2d8aaa 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -670,6 +670,11 @@ int __init psci_dt_init(void)
>   return init_fn(np);
>  }
>  
> +bool psci_is_available(void)
> +{
> + return psci_ops.cpu_off && psci_ops.cpu_on && psci_ops.cpu_suspend;

IIRC, for PSCI 0.1, cpu_suspend is optional, we can't say the PSCI isn't
available if cpu_suspend is missing.

Thanks

Re: [kernel-hardening] [PATCH] printk: hash addresses printed with %p

[Tobin C. Harding]

Removing k...@vger.kernel.org from the CC list.

On Wed, Oct 11, 2017 at 01:48:58PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 11, 2017 at 02:48:16PM +1100, Tobin C. Harding wrote:
> > +/*
> > + * Obfuscates pointer (algorithm taken from kptr_obfuscate(). See 
> > kernel/kcmp.c)
> > + * v is the pointer value, randval is some random value, oddval is some 
> > random
> > + * odd value.
> > + *
> > + * The obfuscation is done in two steps. First we xor the kernel pointer 
> > with
> > + * a random value, which puts pointer into a new position in a reordered 
> > space.
> > + * Secondly we multiply the xor production with a large odd random number 
> > to
> > + * permute its bits even more (the odd multiplier guarantees that the 
> > product
> > + * is unique ever after the high bits are truncated, since any odd number 
> > is
> > + * relative prime to 2^n).
> > + */
> 
> Why not just expose kptr_obfusecate() and use it, instead of copying
> code?
> 
> Also, I'm nervous about the obfuscation.  If the attacker can get a
> handful of known "real kernel pointer" and "obfuscated kernel pointer"
> values, it wouldn't be that hard for them to be able to reverse
> engineer the two secret values.
> 
> Perhaps the argument is "if the attacker can get a _single_ real
> kernel address, it's all over anyway", which is probably true for
> KASLR, but which might not be true for all attacks.
> 
> Anyway, if you use kptr_obfuscate in kernel/kcmp.c, then if we later
> decide that we should change the obfuscation algorithm to something
> stronger, we only need to do it in one place.
> 
>   - Ted

Thanks Ted, others have misgivings about this method also. The email threads 
are all a bit mixed up
(thansk to my ineptness at posting patches :).

FYI, in the other threads Jason A. Donenfel and Linus Torvalds have discussed 
SipHash as a solution.

thanks,
Tobin.

Re: [kernel-hardening] [PATCH] printk: hash addresses printed with %p

[Tobin C. Harding]

Removing k...@vger.kernel.org from the CC list.

On Wed, Oct 11, 2017 at 01:48:58PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 11, 2017 at 02:48:16PM +1100, Tobin C. Harding wrote:
> > +/*
> > + * Obfuscates pointer (algorithm taken from kptr_obfuscate(). See 
> > kernel/kcmp.c)
> > + * v is the pointer value, randval is some random value, oddval is some 
> > random
> > + * odd value.
> > + *
> > + * The obfuscation is done in two steps. First we xor the kernel pointer 
> > with
> > + * a random value, which puts pointer into a new position in a reordered 
> > space.
> > + * Secondly we multiply the xor production with a large odd random number 
> > to
> > + * permute its bits even more (the odd multiplier guarantees that the 
> > product
> > + * is unique ever after the high bits are truncated, since any odd number 
> > is
> > + * relative prime to 2^n).
> > + */
> 
> Why not just expose kptr_obfusecate() and use it, instead of copying
> code?
> 
> Also, I'm nervous about the obfuscation.  If the attacker can get a
> handful of known "real kernel pointer" and "obfuscated kernel pointer"
> values, it wouldn't be that hard for them to be able to reverse
> engineer the two secret values.
> 
> Perhaps the argument is "if the attacker can get a _single_ real
> kernel address, it's all over anyway", which is probably true for
> KASLR, but which might not be true for all attacks.
> 
> Anyway, if you use kptr_obfuscate in kernel/kcmp.c, then if we later
> decide that we should change the obfuscation algorithm to something
> stronger, we only need to do it in one place.
> 
>   - Ted

Thanks Ted, others have misgivings about this method also. The email threads 
are all a bit mixed up
(thansk to my ineptness at posting patches :).

FYI, in the other threads Jason A. Donenfel and Linus Torvalds have discussed 
SipHash as a solution.

thanks,
Tobin.

Re: [PATCH v3 22/33] tracing: Add support for 'field variables'

[Namhyung Kim]

On Fri, Sep 22, 2017 at 03:00:02PM -0500, Tom Zanussi wrote:
> Users should be able to directly specify event fields in hist trigger
> 'actions' rather than being forced to explicitly create a variable for
> that purpose.
> 
> Add support allowing fields to be used directly in actions, which
> essentially does just that - creates 'invisible' variables for each
> bare field specified in an action.  If a bare field refers to a field
> on another (matching) event, it even creates a special histogram for
> the purpose (since variables can't be defined on an existing histogram
> after histogram creation).
> 
> Here's a simple example that demonstrates both.  Basically the
> onmatch() action creates a list of variables corresponding to the
> parameters of the synthetic event to be generated, and then uses those
> values to generate the event.  So for the wakeup_latency synthetic
> event 'call' below the first param, $wakeup_lat, is a variable defined
> explicitly on sched_switch, where 'next_pid' is just a normal field on
> sched_switch, and prio is a normal field on sched_waking.
> 
> Since the mechanism works on variables, those two normal fields just
> have 'invisible' variables created internally for them.  In the case of
> 'prio', which is on another event, we actually need to create an
> additional hist trigger and define the invisible event on that, since

s/event/variable/ ?


> once a hist trigger is defined, variables can't be added to it later.
> 
>   echo 'wakeup_latency u64 lat; pid_t pid; int prio' >>
>/sys/kernel/debug/tracing/synthetic_events
> 
>   echo 'hist:keys=pid:ts0=$common_timestamp.usecs >>
>/sys/kernel/debug/tracing/events/sched/sched_waking/trigger
> 
> echo 'hist:keys=next_pid:wakeup_lat=$common_timestamp.usecs-$ts0:
>   onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,next_pid,prio)
> >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> 
> Signed-off-by: Tom Zanussi 
> ---

[SNIP]

> +static bool compatible_keys(struct hist_trigger_data *target_hist_data,
> + struct hist_trigger_data *hist_data,
> + unsigned int n_keys)
> +{
> + struct hist_field *target_hist_field, *hist_field;
> + unsigned int n, i, j;
> +
> + if (hist_data->n_fields - hist_data->n_vals != n_keys)
> + return false;
> +
> + i = hist_data->n_vals;
> + j = target_hist_data->n_vals;
> +
> + for (n = 0; n < n_keys; n++) {
> + hist_field = hist_data->fields[i + n];
> + target_hist_field = hist_data->fields[j + n];

s/hist_data/target_hist_data/

> +
> + if (strcmp(hist_field->type, target_hist_field->type) != 0)
> + return false;
> + if (hist_field->size != target_hist_field->size)
> + return false;
> + if (hist_field->is_signed != target_hist_field->is_signed)
> + return false;
> + }
> +
> + return true;
> +}

[SNIP]

> +static struct hist_field *
> +create_field_var_hist(struct hist_trigger_data *target_hist_data,
> +   char *system, char *event_name, char *field_name)
> +{
> + struct trace_array *tr = target_hist_data->event_file->tr;
> + struct hist_field *event_var = ERR_PTR(-EINVAL);
> + struct hist_trigger_data *hist_data;
> + unsigned int i, n, first = true;
> + struct field_var_hist *var_hist;
> + struct trace_event_file *file;
> + struct hist_field *key_field;
> + char *saved_filter;
> + char *cmd;
> + int ret;
> +
> + if (target_hist_data->n_field_var_hists >= SYNTH_FIELDS_MAX)
> + return ERR_PTR(-EINVAL);
> +
> + file = event_file(tr, system, event_name);
> +
> + if (IS_ERR(file)) {
> + ret = PTR_ERR(file);
> + return ERR_PTR(ret);
> + }
> +
> + hist_data = find_compatible_hist(target_hist_data, file);
> + if (!hist_data)
> + return ERR_PTR(-EINVAL);
> +
> + var_hist = kzalloc(sizeof(*var_hist), GFP_KERNEL);
> + if (!var_hist)
> + return ERR_PTR(-ENOMEM);
> +
> + cmd = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> + if (!cmd) {
> + kfree(var_hist);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + strcat(cmd, "keys=");
> +
> + for_each_hist_key_field(i, hist_data) {
> + key_field = hist_data->fields[i];
> + if (!first)
> + strcat(cmd, ",");
> + strcat(cmd, key_field->field->name);
> + first = false;
> + }
> +
> + strcat(cmd, ":synthetic_");
> + strcat(cmd, field_name);
> + strcat(cmd, "=");
> + strcat(cmd, field_name);
> +
> + saved_filter = find_trigger_filter(hist_data, file);
> + if (saved_filter) {
> + strcat(cmd, " if ");
> + strcat(cmd, saved_filter);
> + }
> +
> + var_hist->cmd = kstrdup(cmd, GFP_KERNEL);
> +

Re: [PATCH v3 22/33] tracing: Add support for 'field variables'

[Namhyung Kim]

On Fri, Sep 22, 2017 at 03:00:02PM -0500, Tom Zanussi wrote:
> Users should be able to directly specify event fields in hist trigger
> 'actions' rather than being forced to explicitly create a variable for
> that purpose.
> 
> Add support allowing fields to be used directly in actions, which
> essentially does just that - creates 'invisible' variables for each
> bare field specified in an action.  If a bare field refers to a field
> on another (matching) event, it even creates a special histogram for
> the purpose (since variables can't be defined on an existing histogram
> after histogram creation).
> 
> Here's a simple example that demonstrates both.  Basically the
> onmatch() action creates a list of variables corresponding to the
> parameters of the synthetic event to be generated, and then uses those
> values to generate the event.  So for the wakeup_latency synthetic
> event 'call' below the first param, $wakeup_lat, is a variable defined
> explicitly on sched_switch, where 'next_pid' is just a normal field on
> sched_switch, and prio is a normal field on sched_waking.
> 
> Since the mechanism works on variables, those two normal fields just
> have 'invisible' variables created internally for them.  In the case of
> 'prio', which is on another event, we actually need to create an
> additional hist trigger and define the invisible event on that, since

s/event/variable/ ?


> once a hist trigger is defined, variables can't be added to it later.
> 
>   echo 'wakeup_latency u64 lat; pid_t pid; int prio' >>
>/sys/kernel/debug/tracing/synthetic_events
> 
>   echo 'hist:keys=pid:ts0=$common_timestamp.usecs >>
>/sys/kernel/debug/tracing/events/sched/sched_waking/trigger
> 
> echo 'hist:keys=next_pid:wakeup_lat=$common_timestamp.usecs-$ts0:
>   onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,next_pid,prio)
> >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> 
> Signed-off-by: Tom Zanussi 
> ---

[SNIP]

> +static bool compatible_keys(struct hist_trigger_data *target_hist_data,
> + struct hist_trigger_data *hist_data,
> + unsigned int n_keys)
> +{
> + struct hist_field *target_hist_field, *hist_field;
> + unsigned int n, i, j;
> +
> + if (hist_data->n_fields - hist_data->n_vals != n_keys)
> + return false;
> +
> + i = hist_data->n_vals;
> + j = target_hist_data->n_vals;
> +
> + for (n = 0; n < n_keys; n++) {
> + hist_field = hist_data->fields[i + n];
> + target_hist_field = hist_data->fields[j + n];

s/hist_data/target_hist_data/

> +
> + if (strcmp(hist_field->type, target_hist_field->type) != 0)
> + return false;
> + if (hist_field->size != target_hist_field->size)
> + return false;
> + if (hist_field->is_signed != target_hist_field->is_signed)
> + return false;
> + }
> +
> + return true;
> +}

[SNIP]

> +static struct hist_field *
> +create_field_var_hist(struct hist_trigger_data *target_hist_data,
> +   char *system, char *event_name, char *field_name)
> +{
> + struct trace_array *tr = target_hist_data->event_file->tr;
> + struct hist_field *event_var = ERR_PTR(-EINVAL);
> + struct hist_trigger_data *hist_data;
> + unsigned int i, n, first = true;
> + struct field_var_hist *var_hist;
> + struct trace_event_file *file;
> + struct hist_field *key_field;
> + char *saved_filter;
> + char *cmd;
> + int ret;
> +
> + if (target_hist_data->n_field_var_hists >= SYNTH_FIELDS_MAX)
> + return ERR_PTR(-EINVAL);
> +
> + file = event_file(tr, system, event_name);
> +
> + if (IS_ERR(file)) {
> + ret = PTR_ERR(file);
> + return ERR_PTR(ret);
> + }
> +
> + hist_data = find_compatible_hist(target_hist_data, file);
> + if (!hist_data)
> + return ERR_PTR(-EINVAL);
> +
> + var_hist = kzalloc(sizeof(*var_hist), GFP_KERNEL);
> + if (!var_hist)
> + return ERR_PTR(-ENOMEM);
> +
> + cmd = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> + if (!cmd) {
> + kfree(var_hist);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + strcat(cmd, "keys=");
> +
> + for_each_hist_key_field(i, hist_data) {
> + key_field = hist_data->fields[i];
> + if (!first)
> + strcat(cmd, ",");
> + strcat(cmd, key_field->field->name);
> + first = false;
> + }
> +
> + strcat(cmd, ":synthetic_");
> + strcat(cmd, field_name);
> + strcat(cmd, "=");
> + strcat(cmd, field_name);
> +
> + saved_filter = find_trigger_filter(hist_data, file);
> + if (saved_filter) {
> + strcat(cmd, " if ");
> + strcat(cmd, saved_filter);
> + }
> +
> + var_hist->cmd = kstrdup(cmd, GFP_KERNEL);
> + if (!var_hist->cmd) {
> +   

Re: [PATCHv2 1/1] ANDROID: mmc: core: export emmc revision

[Jisheng Zhang]

On Wed, 11 Oct 2017 13:51:26 -0700
Jin Qian  wrote:

> From: Jin Qian 
> 
> Expose emmc revision as part of device attributes.

>> ANDROID: mmc: core: export emmc revision

This commit probably back port from android linux kernel repo. Could we
remove the ANDROID prefix

> 
> Signed-off-by: Jin Qian 
> ---
>  Documentation/ABI/testing/sysfs-bus-mmc | 4 
>  drivers/mmc/core/mmc.c  | 2 ++
>  2 files changed, 6 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-mmc
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-mmc 
> b/Documentation/ABI/testing/sysfs-bus-mmc
> new file mode 100644
> index ..519f028d19cc
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-mmc
> @@ -0,0 +1,4 @@
> +What:/sys/bus/mmc/devices/.../rev
> +Date:October 2017
> +Contact: Jin Qian 
> +Description: Extended CSD revision number
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 36217ad5e9b1..4aa4cfb2c9e1 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -780,6 +780,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
>  MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
>  MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
>  MMC_DEV_ATTR(prv, "0x%x\n", card->cid.prv);
> +MMC_DEV_ATTR(rev, "0x%x\n", card->ext_csd.rev);
>  MMC_DEV_ATTR(pre_eol_info, "%02x\n", card->ext_csd.pre_eol_info);
>  MMC_DEV_ATTR(life_time, "0x%02x 0x%02x\n",
>   card->ext_csd.device_life_time_est_typ_a,
> @@ -838,6 +839,7 @@ static struct attribute *mmc_std_attrs[] = {
>   _attr_name.attr,
>   _attr_oemid.attr,
>   _attr_prv.attr,
> + _attr_rev.attr,
>   _attr_pre_eol_info.attr,
>   _attr_life_time.attr,
>   _attr_serial.attr,

Re: [PATCHv2 1/1] ANDROID: mmc: core: export emmc revision

[Jisheng Zhang]

On Wed, 11 Oct 2017 13:51:26 -0700
Jin Qian  wrote:

> From: Jin Qian 
> 
> Expose emmc revision as part of device attributes.

>> ANDROID: mmc: core: export emmc revision

This commit probably back port from android linux kernel repo. Could we
remove the ANDROID prefix

> 
> Signed-off-by: Jin Qian 
> ---
>  Documentation/ABI/testing/sysfs-bus-mmc | 4 
>  drivers/mmc/core/mmc.c  | 2 ++
>  2 files changed, 6 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-mmc
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-mmc 
> b/Documentation/ABI/testing/sysfs-bus-mmc
> new file mode 100644
> index ..519f028d19cc
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-mmc
> @@ -0,0 +1,4 @@
> +What:/sys/bus/mmc/devices/.../rev
> +Date:October 2017
> +Contact: Jin Qian 
> +Description: Extended CSD revision number
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 36217ad5e9b1..4aa4cfb2c9e1 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -780,6 +780,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
>  MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
>  MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
>  MMC_DEV_ATTR(prv, "0x%x\n", card->cid.prv);
> +MMC_DEV_ATTR(rev, "0x%x\n", card->ext_csd.rev);
>  MMC_DEV_ATTR(pre_eol_info, "%02x\n", card->ext_csd.pre_eol_info);
>  MMC_DEV_ATTR(life_time, "0x%02x 0x%02x\n",
>   card->ext_csd.device_life_time_est_typ_a,
> @@ -838,6 +839,7 @@ static struct attribute *mmc_std_attrs[] = {
>   _attr_name.attr,
>   _attr_oemid.attr,
>   _attr_prv.attr,
> + _attr_rev.attr,
>   _attr_pre_eol_info.attr,
>   _attr_life_time.attr,
>   _attr_serial.attr,

Re: [PATCH] printk: hash addresses printed with %p

[Tobin C. Harding]

On Tue, Oct 10, 2017 at 09:06:50PM -0700, Joe Perches wrote:
> On Wed, 2017-10-11 at 14:48 +1100, Tobin C. Harding wrote:
> > Currently there are many places in the kernel where addresses are being
> > printed using an unadorned %p. Kernel pointers should be printed using
> > %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> > gives attackers sensitive information about the kernel layout in memory.
> []
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> []
> > @@ -1591,6 +1591,35 @@ char *device_node_string(char *buf, char *end, 
> > struct device_node *dn,
> > return widen_string(buf, buf - buf_start, end, spec);
> >  }
> >  
> > +static long get_random_odd_long(void)
> > +{
> > +   long val = 0;
> > +
> > +   while((val & 1) == 0) {
> > +   val = get_random_long();
> > +   }
> > +
> > +   return val;
> > +}
> 
> Perhaps
> 
> static long get_random_odd_long(void)
> {
>   return get_random_long() | 1L;
> }
> 

Nice.

thanks,
Tobin.

Re: [PATCH] printk: hash addresses printed with %p

[Tobin C. Harding]

On Tue, Oct 10, 2017 at 09:06:50PM -0700, Joe Perches wrote:
> On Wed, 2017-10-11 at 14:48 +1100, Tobin C. Harding wrote:
> > Currently there are many places in the kernel where addresses are being
> > printed using an unadorned %p. Kernel pointers should be printed using
> > %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> > gives attackers sensitive information about the kernel layout in memory.
> []
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> []
> > @@ -1591,6 +1591,35 @@ char *device_node_string(char *buf, char *end, 
> > struct device_node *dn,
> > return widen_string(buf, buf - buf_start, end, spec);
> >  }
> >  
> > +static long get_random_odd_long(void)
> > +{
> > +   long val = 0;
> > +
> > +   while((val & 1) == 0) {
> > +   val = get_random_long();
> > +   }
> > +
> > +   return val;
> > +}
> 
> Perhaps
> 
> static long get_random_odd_long(void)
> {
>   return get_random_long() | 1L;
> }
> 

Nice.

thanks,
Tobin.

Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs

[Chen-Yu Tsai]

On Thu, Oct 12, 2017 at 3:09 AM, Linus Walleij  wrote:
> On Wed, Oct 11, 2017 at 2:00 PM, Maxime Ripard
>  wrote:
>
>> What about not enforcing any muxing state when we want to mux to the
>> "ldo" function? We just leave it to whatever value it is, that way we
>> keep it under the regulator framework's control, and we don't disrupt
>> anything when the pin is requested.
>
> In a way since setting the bits one way means "LDO on" and another
> setting means "LDO off" those bits should be handled by the
> regulator framework when used as a regulator, not pin control.
>
> So I would say yes.

I agree. That would be the best solution.

ChenYu

Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs

[Chen-Yu Tsai]

On Thu, Oct 12, 2017 at 3:09 AM, Linus Walleij  wrote:
> On Wed, Oct 11, 2017 at 2:00 PM, Maxime Ripard
>  wrote:
>
>> What about not enforcing any muxing state when we want to mux to the
>> "ldo" function? We just leave it to whatever value it is, that way we
>> keep it under the regulator framework's control, and we don't disrupt
>> anything when the pin is requested.
>
> In a way since setting the bits one way means "LDO on" and another
> setting means "LDO off" those bits should be handled by the
> regulator framework when used as a regulator, not pin control.
>
> So I would say yes.

I agree. That would be the best solution.

ChenYu

Re: [PATCH] radix-tree: get_slot_offset() returns invalid offset when parent is NULL

[Wei Yang]

On Wed, Oct 11, 2017 at 04:39:40PM -0700, Andrew Morton wrote:
>On Wed, 11 Oct 2017 10:33:39 +0800 Wei Yang  wrote:
>
>> On Tue, Oct 10, 2017 at 01:53:11PM -0700, Andrew Morton wrote:
>> >On Tue, 10 Oct 2017 10:52:01 +0800 Wei Yang  
>> >wrote:
>> >
>> >> When parent is NULL, get_slot_offset() returns almost the address of slot.
>> >> This is an invalid value for offset.
>> >> 
>> >> One possible scenario happens on deleting #0 index, when it is the only 
>> >> one
>> >> in tree.
>> >> 
>> >> Current behavior doesn't harm the system, because the offset will not be
>> >> used when parent is NULL in the following procedure or parent is checked
>> >> before get_slot_offset() called. While it is still not safe to return an
>> >> invalid offset.
>> >> 
>> >> This patch returns 0 when parent is NULL in get_slot_offset().
>> >> 
>> >
>> >I'm confused.  If parent=NULL, get_slot_offset() will crash the kernel.
>> >So why "Current behavior doesn't harm the system"?
>> >
>> 
>> Andrew,
>> 
>> I am confused at first glace too, while this may be a feature of the 
>> compiler.
>> 
>> For example, the definition of offsetof(), which leverage the trick of the
>> compiler.
>> 
>> #define offsetof(TYPE, MEMBER)   ((size_t)&((TYPE *)0)->MEMBER)
>
>Well dereferencing that address will still oops the kernel.
>

I don't get your point why this would oops the kernel. It tries to get the
offset of a field in structure. 

A test program in user space 

#include 

struct A {
int b;
char n[8];
};

int main()
{
printf("%d\n", ((struct A*)0)->n);
return 0;
}

This works fine on my machine. Do I missed your point?

>Has this bug been seen in practice?  If so, under what situation and on
>which architecture?

The NULL pointer of "parent" is a real case. 

I see this by adding a log in __radix_tree_delete(), which prints the value of
"node" and show "node" is a NULL pointer.

Here is the diff:

@@ -1994,6 +1994,9 @@ static bool __radix_tree_delete(struct radix_tree_root
*root,
unsigned offset = get_slot_offset(node, slot);
int tag;

+   if (!node)
+   printk(KERN_ERR"%s: node is %p\n", __func__, node);
+
if (is_idr(root)))


I can't specify the exact case which leads to this, while it seems to happen a
lot from the logs printed.

>
>> BTW, I have another question on the implementation of radix tree.
>> 
>> #Question: why 6 is one of the choice of RADIX_TREE_MAP_SHIFT
>> 
>> Currently, the shift of the tree is defined as below.
>> 
>> #define RADIX_TREE_MAP_SHIFT (CONFIG_BASE_SMALL ? 4 : 6)
>> 
>> The index in the tree is with type unsigned long, which means the size is 
>> 32bits or 64bits.
>> 
>> 32 % 4 = 0, 64 % 4 = 0
>> 
>> 32 % 6 = 2, 64 % 6 = 4
>> 
>> This means when the tree shift is 6 and represents the max index, there would
>> be some unused slots at the top level.
>> 
>> So why we chose 6 instead of a 2^N?
>> 
>> The original commit is 139e561660fe11e0fc35e142a800df3dd7d03e9d, which I 
>> don't
>> see some reason for this choice.
>> 
>> If possible, I suggest to change this value to a power of 2. Or maybe I 
>> missed
>> some critical reason behind this.
>> 
>
>I'm not sure I really see the problem.  1<<6 is still a power of 2. 
>radix_tree_split_preload() is doing mod and div on shift distances
>which hurts my brain a bit.  But CONFIG_BASE_SMALL=0 is what most
>people will be using so presumably the current code tests out OK. 
>Although simple memory wastage would be hard to detect.  Matthew has
>been here recently and perhaps can consider?

Hmm, I may not state it clearly.

What I mean is to set RADIX_TREE_MAP_SHIFT a power of 2, instead of the result
of (1 << RADIX_TREE_MAP_SHIFT).

Let me explain a simplified example. Assume the max index is 16 bits.

Case 1, shift is 4

   Each 4 bit forms a group and exactly 4 groups.

   |0123|4567|0123|4567|

Case 2, shift is 6

   Each 6 bit forms a group and left 3 groups with 2 empty slots at the
   beginning.

   |  0123|456701|234567|

Radix tree is a little bit like the page table, which is divided into several
levels and each level is referenced by a "slot" of bits. 

When the shift is a power of 2, the digit fits in exact "slots". This means
there is no waste.

When the shift is not, we will have several unused digits at the most
significant part. This means several slot will never be used.

This means on theory, in a tree with shift 6

   |  0123|456701|234567|

We can store an index with value

ff ff ff

While actually the largest value a 16 bits index could represents

__ ff ff

Since radix tree will not allocate memory when there is no corresponding
index, this will just leave several unused slot at the top level.

While I still prefer to fully utilize the whole tree instead of leave some
never touch 

Re: [PATCH] radix-tree: get_slot_offset() returns invalid offset when parent is NULL

[Wei Yang]

On Wed, Oct 11, 2017 at 04:39:40PM -0700, Andrew Morton wrote:
>On Wed, 11 Oct 2017 10:33:39 +0800 Wei Yang  wrote:
>
>> On Tue, Oct 10, 2017 at 01:53:11PM -0700, Andrew Morton wrote:
>> >On Tue, 10 Oct 2017 10:52:01 +0800 Wei Yang  
>> >wrote:
>> >
>> >> When parent is NULL, get_slot_offset() returns almost the address of slot.
>> >> This is an invalid value for offset.
>> >> 
>> >> One possible scenario happens on deleting #0 index, when it is the only 
>> >> one
>> >> in tree.
>> >> 
>> >> Current behavior doesn't harm the system, because the offset will not be
>> >> used when parent is NULL in the following procedure or parent is checked
>> >> before get_slot_offset() called. While it is still not safe to return an
>> >> invalid offset.
>> >> 
>> >> This patch returns 0 when parent is NULL in get_slot_offset().
>> >> 
>> >
>> >I'm confused.  If parent=NULL, get_slot_offset() will crash the kernel.
>> >So why "Current behavior doesn't harm the system"?
>> >
>> 
>> Andrew,
>> 
>> I am confused at first glace too, while this may be a feature of the 
>> compiler.
>> 
>> For example, the definition of offsetof(), which leverage the trick of the
>> compiler.
>> 
>> #define offsetof(TYPE, MEMBER)   ((size_t)&((TYPE *)0)->MEMBER)
>
>Well dereferencing that address will still oops the kernel.
>

I don't get your point why this would oops the kernel. It tries to get the
offset of a field in structure. 

A test program in user space 

#include 

struct A {
int b;
char n[8];
};

int main()
{
printf("%d\n", ((struct A*)0)->n);
return 0;
}

This works fine on my machine. Do I missed your point?

>Has this bug been seen in practice?  If so, under what situation and on
>which architecture?

The NULL pointer of "parent" is a real case. 

I see this by adding a log in __radix_tree_delete(), which prints the value of
"node" and show "node" is a NULL pointer.

Here is the diff:

@@ -1994,6 +1994,9 @@ static bool __radix_tree_delete(struct radix_tree_root
*root,
unsigned offset = get_slot_offset(node, slot);
int tag;

+   if (!node)
+   printk(KERN_ERR"%s: node is %p\n", __func__, node);
+
if (is_idr(root)))


I can't specify the exact case which leads to this, while it seems to happen a
lot from the logs printed.

>
>> BTW, I have another question on the implementation of radix tree.
>> 
>> #Question: why 6 is one of the choice of RADIX_TREE_MAP_SHIFT
>> 
>> Currently, the shift of the tree is defined as below.
>> 
>> #define RADIX_TREE_MAP_SHIFT (CONFIG_BASE_SMALL ? 4 : 6)
>> 
>> The index in the tree is with type unsigned long, which means the size is 
>> 32bits or 64bits.
>> 
>> 32 % 4 = 0, 64 % 4 = 0
>> 
>> 32 % 6 = 2, 64 % 6 = 4
>> 
>> This means when the tree shift is 6 and represents the max index, there would
>> be some unused slots at the top level.
>> 
>> So why we chose 6 instead of a 2^N?
>> 
>> The original commit is 139e561660fe11e0fc35e142a800df3dd7d03e9d, which I 
>> don't
>> see some reason for this choice.
>> 
>> If possible, I suggest to change this value to a power of 2. Or maybe I 
>> missed
>> some critical reason behind this.
>> 
>
>I'm not sure I really see the problem.  1<<6 is still a power of 2. 
>radix_tree_split_preload() is doing mod and div on shift distances
>which hurts my brain a bit.  But CONFIG_BASE_SMALL=0 is what most
>people will be using so presumably the current code tests out OK. 
>Although simple memory wastage would be hard to detect.  Matthew has
>been here recently and perhaps can consider?

Hmm, I may not state it clearly.

What I mean is to set RADIX_TREE_MAP_SHIFT a power of 2, instead of the result
of (1 << RADIX_TREE_MAP_SHIFT).

Let me explain a simplified example. Assume the max index is 16 bits.

Case 1, shift is 4

   Each 4 bit forms a group and exactly 4 groups.

   |0123|4567|0123|4567|

Case 2, shift is 6

   Each 6 bit forms a group and left 3 groups with 2 empty slots at the
   beginning.

   |  0123|456701|234567|

Radix tree is a little bit like the page table, which is divided into several
levels and each level is referenced by a "slot" of bits. 

When the shift is a power of 2, the digit fits in exact "slots". This means
there is no waste.

When the shift is not, we will have several unused digits at the most
significant part. This means several slot will never be used.

This means on theory, in a tree with shift 6

   |  0123|456701|234567|

We can store an index with value

ff ff ff

While actually the largest value a 16 bits index could represents

__ ff ff

Since radix tree will not allocate memory when there is no corresponding
index, this will just leave several unused slot at the top level.

While I still prefer to fully utilize the whole tree instead of leave some
never touch slot. And this can be achieved by set 

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

[Tobin C. Harding]

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote:
> On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote:
> > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote:
> > > 
> > > Remove NULL pointer dereference as it results in undefined
> > > behaviour, and will usually lead to a runtime error.
> > The diff does not show any pointer dereference so it is hard to
> > understand what you are trying to do
> > with this patch.
> > 
> > > 
> > > Signed-off-by: Shreeya Patel 
> > > ---
> > >  drivers/staging/rtlwifi/base.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/rtlwifi/base.c
> > > b/drivers/staging/rtlwifi/base.c
> > > index b88b0e8..5bb8f98 100644
> > > --- a/drivers/staging/rtlwifi/base.c
> > > +++ b/drivers/staging/rtlwifi/base.c
> > > @@ -781,7 +781,7 @@ static void _rtl_txrate_selectmode(struct
> > > ieee80211_hw *hw,
> > >  
> > >   struct rtl_priv *rtlpriv = rtl_priv(hw);
> > >   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
> > > - struct rtl_sta_info *sta_entry = NULL;
> > > + struct rtl_sta_info *sta_entry;
> > Now the pointer just has garbage in it instead of the testable value
> > of NULL. If you are concerned
> > with the dereference perhaps you could add a NULL check, again it's
> > hard to say without seeing the
> > code.
> 
> Hello, 
> 
> Thanks for making me understand. 
> 
> Here is the code after declaration and initialization of sta_entry. 
> Will it be good to add a NULL check in this case? 
> 
> struct rtl_sta_info *sta_entry = NULL;
>   u8 ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
> 
>   if (sta) {
>   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
>   ratr_index = sta_entry->ratr_index;
>   }

Later in this function the macro SET_RATE_ID() is called, it relies on 
sta_entry being NULL if it
was not explicitly set.

Here is the macro;

#define SET_RATE_ID(rate_id)\
((rtlpriv->cfg->spec_ver & RTL_SPEC_NEW_RATEID) ?   \
rtl_mrate_idx_to_arfr_id(hw, rate_id,   \
(sta_entry ? sta_entry->wireless_mode : \
 WIRELESS_MODE_G)) :\
rate_id)

> If we are making a pointer point to NULL then what if any other
> variable is already pointing to NULL for some other purpose.
> Instead, removing initialization will be good right?

A pointer does not _point_ to NULL as such. A NULL pointer has a value of all 
zero bytes. Have you
read (and completed all the exercises) in KnR

https://en.wikipedia.org/wiki/The_C_Programming_Language

It is, in my opinion, one of the best tech books ever written. If you have any 
holes in your C
knowledge, this is the place to start.

Good luck,
Tobin.

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

[Tobin C. Harding]

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote:
> On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote:
> > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote:
> > > 
> > > Remove NULL pointer dereference as it results in undefined
> > > behaviour, and will usually lead to a runtime error.
> > The diff does not show any pointer dereference so it is hard to
> > understand what you are trying to do
> > with this patch.
> > 
> > > 
> > > Signed-off-by: Shreeya Patel 
> > > ---
> > >  drivers/staging/rtlwifi/base.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/rtlwifi/base.c
> > > b/drivers/staging/rtlwifi/base.c
> > > index b88b0e8..5bb8f98 100644
> > > --- a/drivers/staging/rtlwifi/base.c
> > > +++ b/drivers/staging/rtlwifi/base.c
> > > @@ -781,7 +781,7 @@ static void _rtl_txrate_selectmode(struct
> > > ieee80211_hw *hw,
> > >  
> > >   struct rtl_priv *rtlpriv = rtl_priv(hw);
> > >   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
> > > - struct rtl_sta_info *sta_entry = NULL;
> > > + struct rtl_sta_info *sta_entry;
> > Now the pointer just has garbage in it instead of the testable value
> > of NULL. If you are concerned
> > with the dereference perhaps you could add a NULL check, again it's
> > hard to say without seeing the
> > code.
> 
> Hello, 
> 
> Thanks for making me understand. 
> 
> Here is the code after declaration and initialization of sta_entry. 
> Will it be good to add a NULL check in this case? 
> 
> struct rtl_sta_info *sta_entry = NULL;
>   u8 ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
> 
>   if (sta) {
>   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
>   ratr_index = sta_entry->ratr_index;
>   }

Later in this function the macro SET_RATE_ID() is called, it relies on 
sta_entry being NULL if it
was not explicitly set.

Here is the macro;

#define SET_RATE_ID(rate_id)\
((rtlpriv->cfg->spec_ver & RTL_SPEC_NEW_RATEID) ?   \
rtl_mrate_idx_to_arfr_id(hw, rate_id,   \
(sta_entry ? sta_entry->wireless_mode : \
 WIRELESS_MODE_G)) :\
rate_id)

> If we are making a pointer point to NULL then what if any other
> variable is already pointing to NULL for some other purpose.
> Instead, removing initialization will be good right?

A pointer does not _point_ to NULL as such. A NULL pointer has a value of all 
zero bytes. Have you
read (and completed all the exercises) in KnR

https://en.wikipedia.org/wiki/The_C_Programming_Language

It is, in my opinion, one of the best tech books ever written. If you have any 
holes in your C
knowledge, this is the place to start.

Good luck,
Tobin.

[PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

This patchset adds a new hardware offload type in mqprio before adding
mqprio hardware offload support in hns3 driver.

Yunsheng Lin (2):
  mqprio: Add a new hardware offload type in mqprio
  net: hns3: Add mqprio hardware offload support in hns3 driver

 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++
 include/uapi/linux/pkt_sched.h |  1 +
 4 files changed, 55 insertions(+), 16 deletions(-)

-- 
1.9.1

[PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

This patchset adds a new hardware offload type in mqprio before adding
mqprio hardware offload support in hns3 driver.

Yunsheng Lin (2):
  mqprio: Add a new hardware offload type in mqprio
  net: hns3: Add mqprio hardware offload support in hns3 driver

 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++
 include/uapi/linux/pkt_sched.h |  1 +
 4 files changed, 55 insertions(+), 16 deletions(-)

-- 
1.9.1

[PATCH net-next 2/2] net: hns3: Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

When using tc qdisc, dcb_ops->setup_tc is used to tell hclge_dcb
module to do the tm related setup. Only TC_MQPRIO_HW_OFFLOAD_DCB
offload type is supported.

Signed-off-by: Yunsheng Lin 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++
 3 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 575f50d..3acd8db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -381,6 +381,7 @@ struct hnae3_dcb_ops {
u8   (*setdcbx)(struct hnae3_handle *, u8);
 
int (*map_update)(struct hnae3_handle *);
+   int (*setup_tc)(struct hnae3_handle *, u8, u8 *);
 };
 
 struct hnae3_ae_algo {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 1b30a6f..7ec9484 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -276,6 +276,28 @@ static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
return 0;
 }
 
+static int hclge_setup_tc(struct hnae3_handle *h, u8 tc, u8 *prio_tc)
+{
+   struct hclge_vport *vport = hclge_get_vport(h);
+   struct hclge_dev *hdev = vport->back;
+   int ret;
+
+   if (tc > hdev->tc_max) {
+   dev_err(>pdev->dev,
+   "setup tc failed, tc(%u) > tc_max(%u)\n",
+   tc, hdev->tc_max);
+   return -EINVAL;
+   }
+
+   hclge_tm_schd_info_update(hdev, tc);
+
+   ret = hclge_tm_prio_tc_info_update(hdev, prio_tc);
+   if (ret)
+   return ret;
+
+   return hclge_tm_init_hw(hdev);
+}
+
 static const struct hnae3_dcb_ops hns3_dcb_ops = {
.ieee_getets= hclge_ieee_getets,
.ieee_setets= hclge_ieee_setets,
@@ -284,6 +306,7 @@ static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
.getdcbx= hclge_getdcbx,
.setdcbx= hclge_setdcbx,
.map_update = hclge_map_update,
+   .setup_tc   = hclge_setup_tc,
 };
 
 void hclge_dcb_ops_set(struct hclge_dev *hdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index ba550c1..79d8d6b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1186,42 +1186,56 @@ static void hns3_nic_udp_tunnel_del(struct net_device 
*netdev,
}
 }
 
-static int hns3_setup_tc(struct net_device *netdev, u8 tc)
+static int hns3_setup_tc(struct net_device *netdev, u8 tc, u8 *prio_tc)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
struct hnae3_knic_private_info *kinfo = >kinfo;
+   bool if_running;
unsigned int i;
int ret;
 
if (tc > HNAE3_MAX_TC)
return -EINVAL;
 
-   if (kinfo->num_tc == tc)
-   return 0;
-
if (!netdev)
return -EINVAL;
 
-   if (!tc) {
-   netdev_reset_tc(netdev);
-   return 0;
+   if_running = netif_running(netdev);
+   if (if_running) {
+   hns3_nic_net_stop(netdev);
+   msleep(100);
}
 
-   /* Set num_tc for netdev */
-   ret = netdev_set_num_tc(netdev, tc);
+   ret = (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
+   kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
if (ret)
-   return ret;
+   goto out;
+
+   if (tc <= 1) {
+   netdev_reset_tc(netdev);
+   } else {
+   ret = netdev_set_num_tc(netdev, tc);
+   if (ret)
+   goto out;
+
+   for (i = 0; i < HNAE3_MAX_TC; i++) {
+   if (!kinfo->tc_info[i].enable)
+   continue;
 
-   /* Set per TC queues for the VSI */
-   for (i = 0; i < HNAE3_MAX_TC; i++) {
-   if (kinfo->tc_info[i].enable)
netdev_set_tc_queue(netdev,
kinfo->tc_info[i].tc,
kinfo->tc_info[i].tqp_count,
kinfo->tc_info[i].tqp_offset);
+   }
}
 
-   return 0;
+   ret = hns3_nic_set_real_num_queue(netdev);
+
+out:
+   if (if_running)
+   hns3_nic_net_open(netdev);
+
+   return ret;
 }
 
 static int hns3_nic_setup_tc(struct net_device *dev, enum tc_setup_type type,
@@ -1229,10 +1243,10 @@ static int hns3_nic_setup_tc(struct net_device *dev, 
enum tc_setup_type type,
 {
struct tc_mqprio_qopt *mqprio = type_data;
 
-   if (type != 

[PATCH net-next 2/2] net: hns3: Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

When using tc qdisc, dcb_ops->setup_tc is used to tell hclge_dcb
module to do the tm related setup. Only TC_MQPRIO_HW_OFFLOAD_DCB
offload type is supported.

Signed-off-by: Yunsheng Lin 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++
 3 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 575f50d..3acd8db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -381,6 +381,7 @@ struct hnae3_dcb_ops {
u8   (*setdcbx)(struct hnae3_handle *, u8);
 
int (*map_update)(struct hnae3_handle *);
+   int (*setup_tc)(struct hnae3_handle *, u8, u8 *);
 };
 
 struct hnae3_ae_algo {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 1b30a6f..7ec9484 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -276,6 +276,28 @@ static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
return 0;
 }
 
+static int hclge_setup_tc(struct hnae3_handle *h, u8 tc, u8 *prio_tc)
+{
+   struct hclge_vport *vport = hclge_get_vport(h);
+   struct hclge_dev *hdev = vport->back;
+   int ret;
+
+   if (tc > hdev->tc_max) {
+   dev_err(>pdev->dev,
+   "setup tc failed, tc(%u) > tc_max(%u)\n",
+   tc, hdev->tc_max);
+   return -EINVAL;
+   }
+
+   hclge_tm_schd_info_update(hdev, tc);
+
+   ret = hclge_tm_prio_tc_info_update(hdev, prio_tc);
+   if (ret)
+   return ret;
+
+   return hclge_tm_init_hw(hdev);
+}
+
 static const struct hnae3_dcb_ops hns3_dcb_ops = {
.ieee_getets= hclge_ieee_getets,
.ieee_setets= hclge_ieee_setets,
@@ -284,6 +306,7 @@ static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
.getdcbx= hclge_getdcbx,
.setdcbx= hclge_setdcbx,
.map_update = hclge_map_update,
+   .setup_tc   = hclge_setup_tc,
 };
 
 void hclge_dcb_ops_set(struct hclge_dev *hdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index ba550c1..79d8d6b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1186,42 +1186,56 @@ static void hns3_nic_udp_tunnel_del(struct net_device 
*netdev,
}
 }
 
-static int hns3_setup_tc(struct net_device *netdev, u8 tc)
+static int hns3_setup_tc(struct net_device *netdev, u8 tc, u8 *prio_tc)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
struct hnae3_knic_private_info *kinfo = >kinfo;
+   bool if_running;
unsigned int i;
int ret;
 
if (tc > HNAE3_MAX_TC)
return -EINVAL;
 
-   if (kinfo->num_tc == tc)
-   return 0;
-
if (!netdev)
return -EINVAL;
 
-   if (!tc) {
-   netdev_reset_tc(netdev);
-   return 0;
+   if_running = netif_running(netdev);
+   if (if_running) {
+   hns3_nic_net_stop(netdev);
+   msleep(100);
}
 
-   /* Set num_tc for netdev */
-   ret = netdev_set_num_tc(netdev, tc);
+   ret = (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
+   kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
if (ret)
-   return ret;
+   goto out;
+
+   if (tc <= 1) {
+   netdev_reset_tc(netdev);
+   } else {
+   ret = netdev_set_num_tc(netdev, tc);
+   if (ret)
+   goto out;
+
+   for (i = 0; i < HNAE3_MAX_TC; i++) {
+   if (!kinfo->tc_info[i].enable)
+   continue;
 
-   /* Set per TC queues for the VSI */
-   for (i = 0; i < HNAE3_MAX_TC; i++) {
-   if (kinfo->tc_info[i].enable)
netdev_set_tc_queue(netdev,
kinfo->tc_info[i].tc,
kinfo->tc_info[i].tqp_count,
kinfo->tc_info[i].tqp_offset);
+   }
}
 
-   return 0;
+   ret = hns3_nic_set_real_num_queue(netdev);
+
+out:
+   if (if_running)
+   hns3_nic_net_open(netdev);
+
+   return ret;
 }
 
 static int hns3_nic_setup_tc(struct net_device *dev, enum tc_setup_type type,
@@ -1229,10 +1243,10 @@ static int hns3_nic_setup_tc(struct net_device *dev, 
enum tc_setup_type type,
 {
struct tc_mqprio_qopt *mqprio = type_data;
 
-   if (type != TC_SETUP_MQPRIO)
+   if