Re: ARM64 TPM start method patches

2017-04-13 Thread Abdulhamid, Harb
On 4/14/2017 12:58 AM, anjia...@codeaurora.org wrote:
> Adding Harb Abdulhamid for SMC details
> 
> On 2017-04-11 06:36, Mark Rutland wrote:
>> Hi,
>>
>> I just stumbled upon the following commits in next-20170411:
>>
>>   cf8252ca7ca76fa4 ("ACPICA: Update TPM2 ACPI table")
>>   08eff49d63ca2bf4 ("tpm/tpm_crb: Enable TPM CRB interface for ARM64")
>>
>> ... which leave me a little concerned, for two reasons.
>>
>> Firstly, the spec these are based on (TCG ACPI Specification Family
>> “1.2” and “2.0” Version 1.2, Revision 8), is a draft, open for public
>> review until April 28th 2017 [1], and still subject to change, as noted
>> in the title page of the document [2]:
>>
>> This document is an intermediate draft for comment only and is
>> subject to change without notice. Readers should not design products
>> based on this document.
>>
>> ... so I hope the plan is not to merge these until the final spec is
>> published.
That was our expectation.

>>
>> Secondly, the spec is very vague as to the workings of the SMC call, 
If you read the TPM 2.0 Mobile Command Response Buffer Interface
Specification, along side the TCG ACPI Specification, you will find that
it is pretty clear how CRB works.

https://trustedcomputinggroup.org/wp-content/uploads/Mobile-Command-Response-Buffer-Interface-v2-r12-Specification_FINAL2.pdf

The "TPM start method" is nothing more than a signal to firmware.  It
has no parameters or return values outside of what's defined in the CRB
control area (i.e. this protocol does not rely on GPRs at all).

I provide answers to your questions below.

and
>> does not define:
>>
>>  * That the SMC call follows the SMC Calling Convention [3]
Note that we have discussed this at great length with some of your
colleagues.  We had originally proposed standardizing this SMC, but ARM
elected not to reserve a Function ID (FID) for the TPM CRB start method
in the SMCCC specification.  Instead, ARM preferred that silicon vendors
rely on a vendor specific FID for this start method.

Since there are no rules in the SMCCC for the vendor specific FID space
(outside of ensuring that reserved FIDs are not used), the SMCCC does
not apply here.

The ARM extension to the TCG ACPI specification enabled us to specify
the  FID that will be used to invoke the TPM start method.

Any firmware that specifies anything outside of the vendor specific FID
space in the TCG ACPI table would be in implicit violation of the SMCCC
specification.  At the same time, we do not want to do any FID range
checking in the driver itself, because in the future we may eventually
elect to define a standard FID for this start method, and we'd like the
driver to be forward compatible with future firmware.

>>  * The parameters to the SMC call
Once the TPM start method is invoked (via SMC), The OS writes the
command and parameters to the Command Buffer.  Note that the command
buffer address is specified in the CRB control area.

Also note that, unlike standard SMC calls you are probably accustomed
to, the values in the GPRs are irrelevant and ignored.

>>  * The return value(s) of the SMC call
Trustzone firmware will ERET back to software, where software will poll
the CRB status for completion or error.  When the command is complete,
the OS will retrieve return data from the Response Buffer (the response
buffer address is also specified in the CRB control area).

>>
>> ... which I believe should be clarified in the spec before we make
>> assumptions regarding these in the Linux driver. Otherwise, this is
>> liable to vary in practice.

Anything that strays from the above behavior is in clear spec violation
and a firmware bug.  I don't see how any of these specifications (TCG
CRB, TCG ACPI, and SMCCC) allow for any variance in implementation.

I disagree that any further clarification is needed in the spec.  Folks
who study the TCG specifications will clearly understand these flows.

Again, please take a look at the TPM Mobile Command Response Buffer
Interface Specification, you will find the details there.

>>
>> Thanks,
>> Mark.
>>
>> [1] https://trustedcomputinggroup.org/specifications-public-review/
>> [2]
>> https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-reviepdf
>>
>> [3]
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
>>



Thanks,
Harb
-- 
Qualcomm Datacenter Technologies, Inc.
as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.


Re: [PATCH] perf trace: Add usage of --no-syscalls in man page

2017-04-13 Thread Ravi Bangoria
Hi Arnaldo, Thanks for pulling the patch.

On Thursday 13 April 2017 07:21 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 13, 2017 at 11:32:12AM +0530, Ravi Bangoria escreveu:
>> perf trace supports --no-syscalls option but it's not listed in
>> the man page. (Though, I see an example using --no-syscalls in
>> EXAMPLES section.)
> Thanks, applied.
>
> I'm thinking about making --no-syscalls the default when 'trace' is
> hardlinked to 'perf', i.e. 'perf trace'  remains as it is, but if one
> calls 'trace', then --no-syscalls is the default, as after non-syscall
> events got supported I find myself using --no-syscalls way too often,
> what do you think?

+1. Makes sense to me.

I also use 'perf trace' more often for non-syscall events.
So.. if others are okay please do it.

-Ravi



Re: [PATCH] md-cluster: Fix a memleak in an error handling path

2017-04-13 Thread Guoqing Jiang



On 04/14/2017 02:08 PM, Christophe JAILLET wrote:

We know that 'bm_lockres' is NULL here, so 'lockres_free(bm_lockres)' is a
no-op. According to resource handling in case of error a few lines below,
it is likely that 'bitmap_free(bitmap)' was expected instead.

Fixes: b98938d16a10 ("md-cluster: introduce cluster_check_sync_size")


Reviewed-by: Guoqing Jiang 

Thanks,
Guoqing



Signed-off-by: Christophe JAILLET 
---
  drivers/md/md-cluster.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index b21ef58819f6..7299ce2f08a8 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -1127,7 +1127,7 @@ int cluster_check_sync_size(struct mddev *mddev)
bm_lockres = lockres_init(mddev, str, NULL, 1);
if (!bm_lockres) {
pr_err("md-cluster: Cannot initialize %s\n", str);
-   lockres_free(bm_lockres);
+   bitmap_free(bitmap);
return -1;
}
bm_lockres->flags |= DLM_LKF_NOQUEUE;




[PATCH] kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7

2017-04-13 Thread Masahiro Yamada
Arnd Bergmann reported:
  "When ftrace is enabled and we build with gcc-4.7 or older, we
  get a warning for each file on architectures that select
  CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:

  warning: -ffunction-sections disabled; it makes profiling impossible [enabled 
by default]
  "

Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), warnings are treated as errors in
cc-option checks.  CC_FLAGS_FTRACE is blindly added to KBUILD_CFLAGS,
so $(call cc-option,-ffunction-sections,) should be moved below it
in order to detect the conflict between the two options.

Reported-by: Arnd Bergmann 
Signed-off-by: Masahiro Yamada 
---

 Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index efa267a..753e450 100644
--- a/Makefile
+++ b/Makefile
@@ -632,11 +632,6 @@ include arch/$(SRCARCH)/Makefile
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
-ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
-KBUILD_CFLAGS  += $(call cc-option,-ffunction-sections,)
-KBUILD_CFLAGS  += $(call cc-option,-fdata-sections,)
-endif
-
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
@@ -773,6 +768,11 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
 KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
 endif
 
+ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
+KBUILD_CFLAGS  += $(call cc-option,-ffunction-sections,)
+KBUILD_CFLAGS  += $(call cc-option,-fdata-sections,)
+endif
+
 # arch Makefile may override CC so keep this after arch Makefile is included
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
-- 
2.7.4



[PATCH v2] dt-bindings: input: add bindings document for ar1021_i2c driver

2017-04-13 Thread Martin Kepplinger
Add a simple binding document describing the supported devices and the
I2C bus address.

Signed-off-by: Martin Kepplinger 
---

revision history

v2: fixed subject line and binding; thanks Rob Herring
v1: initial idea


 .../devicetree/bindings/input/touchscreen/ar1021.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/ar1021.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt 
b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
new file mode 100644
index 000..e459e85
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
@@ -0,0 +1,16 @@
+* Microchip AR1020 and AR1021 touchscreen interface (I2C)
+
+Required properties:
+- compatible   : "microchip,ar1021-i2c"
+- reg  : I2C slave address
+- interrupt-parent : the phandle for the interrupt controller
+- interrupts   : touch controller interrupt
+
+Example:
+
+   touchscreen@4d {
+   compatible = "microchip,ar1021-i2c";
+   reg = <0x4d>;
+   interrupt-parent = <&gpio3>;
+   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+   };
-- 
2.1.4



[PATCH] md-cluster: Fix a memleak in an error handling path

2017-04-13 Thread Christophe JAILLET
We know that 'bm_lockres' is NULL here, so 'lockres_free(bm_lockres)' is a
no-op. According to resource handling in case of error a few lines below,
it is likely that 'bitmap_free(bitmap)' was expected instead.

Fixes: b98938d16a10 ("md-cluster: introduce cluster_check_sync_size")

Signed-off-by: Christophe JAILLET 
---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index b21ef58819f6..7299ce2f08a8 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -1127,7 +1127,7 @@ int cluster_check_sync_size(struct mddev *mddev)
bm_lockres = lockres_init(mddev, str, NULL, 1);
if (!bm_lockres) {
pr_err("md-cluster: Cannot initialize %s\n", str);
-   lockres_free(bm_lockres);
+   bitmap_free(bitmap);
return -1;
}
bm_lockres->flags |= DLM_LKF_NOQUEUE;
-- 
2.11.0



Re: [PATCH 3/4] net: macb: Add hardware PTP support

2017-04-13 Thread kbuild test robot
Hi Rafal,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Rafal-Ozieblo/net-macb-Add-support-for-PTP-timestamps-in-DMA-descriptors/20170414-001330
 HEAD 3b878618e04f866388fd62f6c44752e50b15658a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `macb_interrupt':
>> kfifo_buf.c:(.text+0xeabd8): undefined reference to `macb_ptp_int'
>> kfifo_buf.c:(.text+0xeac6c): undefined reference to `gem_ptp_txstamp'
   drivers/built-in.o: In function `gem_rx':
>> kfifo_buf.c:(.text+0xebbd8): undefined reference to `gem_ptp_rxstamp'
>> drivers/built-in.o:(.data+0xa5e0): undefined reference to `gem_ptp_init'
>> drivers/built-in.o:(.data+0xa5e4): undefined reference to `gem_ptp_remove'
>> drivers/built-in.o:(.data+0xa5f4): undefined reference to `gem_get_hwtst'
>> drivers/built-in.o:(.data+0xa5f8): undefined reference to `gem_set_hwtst'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH v3 2/2] thermal: core: Add a back up thermal shutdown mechanism

2017-04-13 Thread Eduardo Valentin
Hey,

On Fri, Apr 14, 2017 at 10:48:25AM +0530, Keerthy wrote:
> orderly_poweroff is triggered when a graceful shutdown
> of system is desired. This may be used in many critical states of the
> kernel such as when subsystems detects conditions such as critical
> temperature conditions. However, in certain conditions in system
> boot up sequences like those in the middle of driver probes being
> initiated, userspace will be unable to power off the system in a clean
> manner and leaves the system in a critical state. In cases like these,
> the /sbin/poweroff will return success (having forked off to attempt
> powering off the system. However, the system overall will fail to
> completely poweroff (since other modules will be probed) and the system
> is still functional with no userspace (since that would have shut itself
> off).
> 
> However, there is no clean way of detecting such failure of userspace
> powering off the system. In such scenarios, it is necessary for a backup
> workqueue to be able to force a shutdown of the system when orderly
> shutdown is not successful after a configurable time period.
> 
> Reported-by: Nishanth Menon 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v3:
> 
>   * Removed unnecessary mutex init.
>   * Added WARN messages instead of a simple warning message.
>   * Added Documentation.
> 
>  Documentation/thermal/sysfs-api.txt | 18 +++
>  drivers/thermal/Kconfig | 13 +++
>  drivers/thermal/thermal_core.c  | 45 
> +
>  3 files changed, 76 insertions(+)

Cool!

Just minor comments..

> 
> diff --git a/Documentation/thermal/sysfs-api.txt 
> b/Documentation/thermal/sysfs-api.txt
> index ef473dc..94b707c 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -582,3 +582,21 @@ platform data is provided, this uses the step_wise 
> throttling policy.
>  This function serves as an arbitrator to set the state of a cooling
>  device. It sets the cooling device to the deepest cooling state if
>  possible.
> +
> +6. thermal_emergency_poweroff:
> +
> +On an event of critical trip temperature crossing. Thermal framework
> +allows the system to shutdown gracefully by calling orderly_poweroff.
> +In the event of a failure of orderly_poweroff to shut down the system
> +we are in danger of keeping the system alive at undesirably high
> +temperatures. To mitigate this high risk scenario we program a work
> +queue to fire after a pre-determined number of seconds to start
> +an emergency shutdown of the device using the kernel_power_off
> +function.
> +
> +The delay should be carefully profiled so as to give adequate time for
> +orderly_poweroff. In case of failure of an orderly_poweroff the
> +emergency poweroff kicks in after the delay has elapsed and shuts down
> +the system.

Can you mark functions with () in the above, e.g., orderly_poweroff().

Also, you did not mention about the call to emergency_reset();

> +
> +If set to 0 emergency poweroff will happen immediately.
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 9347401..971fd54 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -15,6 +15,19 @@ menuconfig THERMAL
>  
>  if THERMAL
>  
> +config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
> + int "Emergency poweroff delay in milli-seconds"
> + depends on THERMAL
> + default 0
> + help
> +   The number of milliseconds to delay before emergency
> +   poweroff kicks in. The delay should be carefully profiled
> +   so as to give adequate time for orderly_poweroff. In case
> +   of failure of an orderly_poweroff the emergency poweroff
> +   kicks in after the delay has elapsed and shuts down the system.
> +
> +   If set to 0 poweroff will happen immediately.
> +
>  config THERMAL_HWMON
>   bool
>   prompt "Expose thermal sensors as hwmon device"
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 9cad1ba..30098cd 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -323,6 +323,46 @@ static void handle_non_critical_trips(struct 
> thermal_zone_device *tz,
>  def_governor->throttle(tz, trip);
>  }
>  
> +/**
> + * emergency_poweroff_func - emergency poweroff work after a known delay

s/emergency_poweroff_func/thermal_emergency_poweroff_func/g

> + * @work: work_struct associated with the emergency poweroff function
> + *
> + * This function is called in very critical situations to force
> + * a kernel poweroff after a configurable timeout value.
> + */
> +static void emergency_poweroff_func(struct work_struct *work)
> +{
> + /*
> +  * We have reached here after the emergency thermal shutdown
> +  * Waiting period has expired. This means orderly_poweroff has
> +  * not been able to shut off the system for some reason.
> +  * Try to shut down the system immediately using kernel_power_

[PATCH v2] input: touchscreen: ar1021_i2c: highlight support for AR1020

2017-04-13 Thread Martin Kepplinger
ar1021_i2c simply also supports the ar1020 device I'm using. This is
tested. They also share the same datasheet:

   http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf

So let users see that they have a compatible in front of them by adding
AR1020 to the driver's description.

Signed-off-by: Martin Kepplinger 
---

revision history

v2: leave compatible string untouched. only add description.
v1: initial idea.


 drivers/input/touchscreen/Kconfig  | 4 ++--
 drivers/input/touchscreen/ar1021_i2c.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 33c62e5..535b91a 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -96,8 +96,8 @@ config TOUCHSCREEN_AR1021_I2C
tristate "Microchip AR1021 i2c touchscreen"
depends on I2C && OF
help
- Say Y here if you have the Microchip AR1021 touchscreen controller
- chip in your system.
+ Say Y here if you have the Microchip AR1020 or AR1021 touchscreen
+ controller chip in your system.
 
  If unsure, say N.
 
diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
b/drivers/input/touchscreen/ar1021_i2c.c
index 2e7500e..03784d2 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -1,5 +1,5 @@
 /*
- * Microchip AR1021 driver for I2C
+ * Microchip AR1020 and AR1021 driver for I2C
  *
  * Author: Christian Gmeiner 
  *
@@ -175,5 +175,5 @@ static struct i2c_driver ar1021_i2c_driver = {
 module_i2c_driver(ar1021_i2c_driver);
 
 MODULE_AUTHOR("Christian Gmeiner ");
-MODULE_DESCRIPTION("Microchip AR1021 I2C Driver");
+MODULE_DESCRIPTION("Microchip AR1020 and AR1021 I2C Driver");
 MODULE_LICENSE("GPL");
-- 
2.1.4



Re: [PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

2017-04-13 Thread Keerthy


On Friday 14 April 2017 11:30 AM, Eduardo Valentin wrote:
> On Fri, Apr 14, 2017 at 10:48:24AM +0530, Keerthy wrote:
>> thermal_zone_device_check --> thermal_zone_device_update -->
>> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
>>
>> The above sequence happens every 250/500 mS based on the configuration.
>> The orderly_poweroff function is getting called every 250/500 mS.
>> With a full fledged file system it takes at least 5-10 Seconds to
>> power off gracefully.
>>
>> In that period due to the thermal_zone_device_check triggering
>> periodically the thermal work queues bombard with
>> orderly_poweroff calls multiple times eventually leading to
>> failures in gracefully powering off the system.
>>
>> Make sure that orderly_poweroff is called only once.
>>
>> Reported-by: Keerthy 
>> Signed-off-by: Keerthy 
>> ---
>>
>> Changes in v3:
>>
>>   * Changed the place where mutex was locked and unlocked.
>>
>> Changes in v2:
>>
>>   * Added a global mutex to serialize poweroff code sequence.
>>
>>  drivers/thermal/thermal_core.c | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 11f0675..9cad1ba 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -45,6 +45,7 @@
>>  
>>  static DEFINE_MUTEX(thermal_list_lock);
>>  static DEFINE_MUTEX(thermal_governor_lock);
>> +static DEFINE_MUTEX(poweroff_lock);
>>  
>>  static atomic_t in_suspend;
>>  
>> @@ -326,6 +327,7 @@ static void handle_critical_trips(struct 
>> thermal_zone_device *tz,
>>int trip, enum thermal_trip_type trip_type)
>>  {
>>  int trip_temp;
>> +static bool power_off_triggered;
> 
> I would prefer this to be closer to its lock. Can you please move this
> to the global section?

Sure. I can do that.

> 
>>  
>>  tz->ops->get_trip_temp(tz, trip, &trip_temp);
>>  
>> @@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
>> thermal_zone_device *tz,
>>  dev_emerg(&tz->device,
>>"critical temperature reached(%d C),shutting down\n",
>>tz->temperature / 1000);
>> -orderly_poweroff(true);
>> +mutex_lock(&poweroff_lock);
>> +if (!power_off_triggered) {
>> +orderly_poweroff(true);
>> +power_off_triggered = true;
>> +}
>> +mutex_unlock(&poweroff_lock);
>>  }
>>  }
>>  
>> @@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
>>  {
>>  int result;
>>  
>> +mutex_init(&poweroff_lock);
>>  result = thermal_register_governors();
>>  if (result)
>>  goto error;
>> @@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
>>  ida_destroy(&thermal_cdev_ida);
>>  mutex_destroy(&thermal_list_lock);
>>  mutex_destroy(&thermal_governor_lock);
>> +mutex_destroy(&poweroff_lock);
>>  return result;
>>  }
>>  
>> -- 
>> 1.9.1
>>


Re: [PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

2017-04-13 Thread Eduardo Valentin
On Fri, Apr 14, 2017 at 10:48:24AM +0530, Keerthy wrote:
> thermal_zone_device_check --> thermal_zone_device_update -->
> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
> 
> The above sequence happens every 250/500 mS based on the configuration.
> The orderly_poweroff function is getting called every 250/500 mS.
> With a full fledged file system it takes at least 5-10 Seconds to
> power off gracefully.
> 
> In that period due to the thermal_zone_device_check triggering
> periodically the thermal work queues bombard with
> orderly_poweroff calls multiple times eventually leading to
> failures in gracefully powering off the system.
> 
> Make sure that orderly_poweroff is called only once.
> 
> Reported-by: Keerthy 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v3:
> 
>   * Changed the place where mutex was locked and unlocked.
> 
> Changes in v2:
> 
>   * Added a global mutex to serialize poweroff code sequence.
> 
>  drivers/thermal/thermal_core.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 11f0675..9cad1ba 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -45,6 +45,7 @@
>  
>  static DEFINE_MUTEX(thermal_list_lock);
>  static DEFINE_MUTEX(thermal_governor_lock);
> +static DEFINE_MUTEX(poweroff_lock);
>  
>  static atomic_t in_suspend;
>  
> @@ -326,6 +327,7 @@ static void handle_critical_trips(struct 
> thermal_zone_device *tz,
> int trip, enum thermal_trip_type trip_type)
>  {
>   int trip_temp;
> + static bool power_off_triggered;

I would prefer this to be closer to its lock. Can you please move this
to the global section?

>  
>   tz->ops->get_trip_temp(tz, trip, &trip_temp);
>  
> @@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
> thermal_zone_device *tz,
>   dev_emerg(&tz->device,
> "critical temperature reached(%d C),shutting down\n",
> tz->temperature / 1000);
> - orderly_poweroff(true);
> + mutex_lock(&poweroff_lock);
> + if (!power_off_triggered) {
> + orderly_poweroff(true);
> + power_off_triggered = true;
> + }
> + mutex_unlock(&poweroff_lock);
>   }
>  }
>  
> @@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
>  {
>   int result;
>  
> + mutex_init(&poweroff_lock);
>   result = thermal_register_governors();
>   if (result)
>   goto error;
> @@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
>   ida_destroy(&thermal_cdev_ida);
>   mutex_destroy(&thermal_list_lock);
>   mutex_destroy(&thermal_governor_lock);
> + mutex_destroy(&poweroff_lock);
>   return result;
>  }
>  
> -- 
> 1.9.1
> 


signature.asc
Description: Digital signature


Re: [RFC PATCH] kbuild: Fix asm-offset generation to work with clang

2017-04-13 Thread Masahiro Yamada
Hi Matthias,


2017-04-14 9:37 GMT+09:00 Matthias Kaehlcke :
> El Tue, Apr 11, 2017 at 11:03:54AM -0700 Matthias Kaehlcke ha dit:
>
>> El Tue, Apr 11, 2017 at 09:01:41PM +0900 Masahiro Yamada ha dit:
>>
>> > 2017-04-04 6:25 GMT+09:00 Matthias Kaehlcke :
>> > > When using clang with -no-integerated-as clang will use the gnu
>> > > assembler instead of the integrated assembler. However clang will
>> > > still perform asm error checking before sending the inline assembly
>> > > language to gas.
>> > >
>> > > The generation of asm-offsets from within C code is dependent on gcc's
>> > > blind passing of whatever is in asm() through to gas. Arbirary text is
>> > > passed through which is then modified by a sed script into the
>> > > appropriate .h and .S code. Since the arbitrary text is not valid
>> > > assembly language, clang fails.
>> > >
>> > > This can be fixed by making the arbitrary text into an ASM comment and
>> > > then updating the sed scripts accordingly to work as expected.
>> > >
>> > > This solution works for both gcc and clang.
>> > >
>> > > Based-on-patch-from: Behan Webster 
>> > > Signed-off-by: Matthias Kaehlcke 
>> >
>> >
>> >
>> > Could you check Jeroen Hofstee's work for U-Boot?
>> >
>> > http://patchwork.ozlabs.org/patch/375026/
>>
>> No I didn't come across it, thanks for the pointer!
>>
>> > His idea is to use .ascii string
>> > in order to handle this in arch-agnostic way.
>>
>> Looks good, way cleaner than my proposed solution :)
>>
>> > If you are happy about this idea,
>> > I can forward his patch (with a little bit adjustment).
>>
>> With forward you mean you plan to port it? Otherwise I'm also happy to
>> give it a go, just let me know.
>>
>> > We may want to refactor the patch because
>> > the double mark ".ascii" and "->" seem redundant,
>> > but it is just a detail.
>>
>> Agree, since we are already touching this part we might as well remove
>> the "->".
>
> Thinking about it a bit more it seems safer to keep the "->" since
> the input file might contain actual ".ascii" directives.


I am not sure about this, but I do not have a strong option, either.

OK. I am keeping both .ascii and -> just in case.

https://patchwork.kernel.org/patch/9680709/


-- 
Best Regards
Masahiro Yamada


[PATCH 2/2] kbuild: fix asm-offset generation to work with clang

2017-04-13 Thread Masahiro Yamada
From: Jeroen Hofstee 

KBuild abuses the asm statement to write to a file and
clang chokes about these invalid asm statements. Hack it
even more by fooling this is actual valid asm code.

Signed-off-by: Jeroen Hofstee 
[masahiro:
 Import Jeroen's work for U-Boot:
 http://patchwork.ozlabs.org/patch/375026/
 Tweak sed script a little to drop garbage '#' for GCC case, like
 #define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS   # */ ]
Signed-off-by: Masahiro Yamada 

---

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/kbuild.h b/include/linux/kbuild.h
index 22a7219..4e80f3a 100644
--- a/include/linux/kbuild.h
+++ b/include/linux/kbuild.h
@@ -2,14 +2,14 @@
 #define __LINUX_KBUILD_H
 
 #define DEFINE(sym, val) \
-asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+   asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
 
-#define BLANK() asm volatile("\n->" : : )
+#define BLANK() asm volatile("\n.ascii \"->\"" : : )
 
 #define OFFSET(sym, str, mem) \
DEFINE(sym, offsetof(struct str, mem))
 
 #define COMMENT(x) \
-   asm volatile("\n->#" x)
+   asm volatile("\n.ascii \"->#" x "\"")
 
 #endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9c20690..a050859 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -414,9 +414,10 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
-   "/^->/{s:->#\(.*\):/* \1 */:; \
+   's:^\.ascii *"\(.*\)".*:\1:; \
+   /^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
-   s:->::; p;}"
+   s:->::; p;}'
 endef
 
 # Use filechk to avoid rebuilds when a header changes, but the resulting file
-- 
2.7.4



[PATCH 0/2] kbuild: cleanup asm-offset generation, and make it work with clang

2017-04-13 Thread Masahiro Yamada
1/2 is a trivial cleanup of sed script
2/2 imports clang work-around from U-Boot.


Jeroen Hofstee (1):
  kbuild: fix asm-offset generation to work with clang

Masahiro Yamada (1):
  kbuild: consolidate redundant sed script ASM offset generation

 include/linux/kbuild.h | 6 +++---
 scripts/Makefile.lib   | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.7.4



[PATCH 1/2] kbuild: consolidate redundant sed script ASM offset generation

2017-04-13 Thread Masahiro Yamada
This part ended up in redundant code after touched by multiple
people.

[1] Commit 3234282f33b2 ("x86, asm: Fix CFI macro invocations to
deal with shortcomings in gas") added parentheses for defined
expressions to support old gas for x86.

[2] Commit a22dcdb0032c ("x86, asm: Fix ancient-GAS workaround")
split the pattern into two to avoid parentheses for non-numeric
expressions.

[3] Commit 95a2f6f72d37 ("Partially revert patch that encloses
asm-offset.h numbers in brackets") removed parentheses from numeric
expressions as well because parentheses in MN10300 assembly have a
special meaning (pointer access).

Apparently, there is a conflict between [1] and [3].  After all,
[3] took precedence, and a long time has passed since then.

Now, merge the two patterns again because the first one is covered
by the other.

Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.lib | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index e36427a..9c20690 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -415,7 +415,6 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 # Default sed regexp - multiline due to syntax constraints
 define sed-offsets
"/^->/{s:->#\(.*\):/* \1 */:; \
-   s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}"
 endef
-- 
2.7.4



Re: [PATCH] Input: ar1021 - do not force raising edge IRQ trigger

2017-04-13 Thread Martin Kepplinger
On 2017-04-14 01:49, Dmitry Torokhov wrote:
> We should not be forcing edge triggered interrupt, but rather let platform
> decide the kind of trigger it needs to use. Also, the driver is not quite
> safe with regard to edge-triggered interrupts as it does not try to kick
> the controller after requesting/enabling IRQ.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 6797e123925a..6c3c79b7ff51 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -109,7 +109,7 @@ static int ar1021_i2c_probe(struct i2c_client *client,
>  
>   error = devm_request_threaded_irq(&client->dev, client->irq,
> NULL, ar1021_i2c_irq,
> -   IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> +   IRQF_ONESHOT,
> "ar1021_i2c", ar1021);
>   if (error) {
>   dev_err(&client->dev,
> 

makes sense, if users have to expect that this default can change. it works.

Tested-by: Martin Kepplinger 

 martin


[PATCH v2] powerpc/mm: Fix missing page attributes in page table dump

2017-04-13 Thread Christophe Leroy
On some targets, _PAGE_RW is 0 and this is _PAGE_RO which is used.
There is also _PAGE_SHARED that is missing.

Signed-off-by: Christophe Leroy 
---
 v2: Unlike the 3 other pgtable.h, arch/powerpc/include/asm/book3s/64/pgtable.h
 doesn't include pte-common.h . Therefore, _PAGE_SHARED has to be defined
 explicitly there, just like _PAGE_RO is. (build issue reported by kbuild robot)

 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
 arch/powerpc/mm/dump_linuxpagetables.c   | 9 +
 2 files changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index fb72ff6b98e6..fc9dc57a787b 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -13,6 +13,7 @@
 #define _PAGE_BIT_SWAP_TYPE0
 
 #define _PAGE_RO   0
+#define _PAGE_SHARED   0
 
 #define _PAGE_EXEC 0x1 /* execute permission */
 #define _PAGE_WRITE0x2 /* write access allowed */
diff --git a/arch/powerpc/mm/dump_linuxpagetables.c 
b/arch/powerpc/mm/dump_linuxpagetables.c
index 05109d7fa027..22d243f5 100644
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -119,8 +119,13 @@ static const struct flag_info flag_array[] = {
.set= "user",
.clear  = "",
}, {
+#if _PAGE_RO == 0
.mask   = _PAGE_RW,
.val= _PAGE_RW,
+#else
+   .mask   = _PAGE_RO,
+   .val= 0,
+#endif
.set= "rw",
.clear  = "ro",
}, {
@@ -207,6 +212,10 @@ static const struct flag_info flag_array[] = {
.mask   = _PAGE_SPECIAL,
.val= _PAGE_SPECIAL,
.set= "special",
+   }, {
+   .mask   = _PAGE_SHARED,
+   .val= _PAGE_SHARED,
+   .set= "shared",
}
 };
 
-- 
2.12.0



Re: [PATCH 2/3] zram: do not use copy_page with non-page alinged address

2017-04-13 Thread Sergey Senozhatsky
Hello,

On (04/13/17 09:17), Minchan Kim wrote:
> The copy_page is optimized memcpy for page-alinged address.
> If it is used with non-page aligned address, it can corrupt memory which
> means system corruption. With zram, it can happen with
> 
> 1. 64K architecture
> 2. partial IO
> 3. slub debug
> 
> Partial IO need to allocate a page and zram allocates it via kmalloc.
> With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
> address. And finally, copy_page(mem, cmem) corrupts memory.

which would be the case for many other copy_page() calls in the kernel.
right? if so - should the fix be in copy_page() then?

-ss


Re: [PATCH v2] Input: ar1021-i2c - fix too long name in driver's device table

2017-04-13 Thread Christian Gmeiner
2017-04-14 1:32 GMT+02:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we expect
> it to be NULL-terminated, however we are trying to stuff it with 21 bytes
> and thus NULL-terminator is lost. This causes issues when one creates
> device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
> and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we are
> dealing with, so let's drop it. Also, no other driver uses capitals, and
> the manufacturer name is normally not included, except in very rare cases
> of incompatible name collisions.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
> Signed-off-by: Dmitry Torokhov 
Reviewed-By: Christian Gmeiner 

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner


Re: [PATCH RFC 0/5] *** SPI Slave mode support ***

2017-04-13 Thread Jiada Wang

Hello Geert

On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:

On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown  wrote:

On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

v1:
   add Slave mode support in SPI core
   spidev create slave device when SPI controller work in slave mode
   spi-imx support to work in slave mode

Adding Geert who also had a series doing this in progress that was
getting very near to being merged.

Thank you!

Actually my plan is to fix the last remaining issues and resubmit for v4.13.

I noticed your patch set for SPI slave support,
(I am sure you can find out some of the change
in this patch set is based on your work).
we have similar requirement to add slave mode support to ecspi IP on 
imx6 Soc.


Our use case is to use spidev as an interface to communicate with 
external SPI master devices.
meanwhile the SPI bus controller can also act as master device to send 
data to other

SPI slave devices on the board.

I found in your implementation, SPI bus controller is limited to either 
work in master mode or
slave mode, is there any reasoning to not configure SPI mode based on 
SPI devices use case?



Thanks,
Jiada


References:
   - v2: https://lkml.org/lkml/2016/9/12/1065
   - v1: https://lkml.org/lkml/2016/6/22/423

BTW Jiada, what's your use case? Just spidev?

Thx!

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds




Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

2017-04-13 Thread hpa
On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke  wrote:
>El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit:
>
>> On 04/13/17 16:14, Matthias Kaehlcke wrote:
>> > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit:
>> > 
>> >> El Fri, Mar 17, 2017 at 04:50:19PM -0700 h...@zytor.com ha dit:
>> >>
>> >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson
> wrote:
>>  Suppress clang warnings about potential unaliged accesses
>>  to members in packed structs. This gets rid of almost 10,000
>>  warnings about accesses to the ring 0 stack pointer in the TSS.
>> 
>>  Signed-off-by: Michael Davidson 
>>  ---
>>  arch/x86/Makefile | 5 +
>>  1 file changed, 5 insertions(+)
>> 
>>  diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>>  index 894a8d18bf97..7f21703c475d 100644
>>  --- a/arch/x86/Makefile
>>  +++ b/arch/x86/Makefile
>>  @@ -128,6 +128,11 @@ endif
>>  KBUILD_CFLAGS += $(call
>cc-option,-maccumulate-outgoing-args)
>>  endif
>> 
>>  +ifeq ($(cc-name),clang)
>>  +# Suppress clang warnings about potential unaligned accesses.
>>  +KBUILD_CFLAGS += $(call cc-disable-warning,
>address-of-packed-member)
>>  +endif
>>  +
>>  ifdef CONFIG_X86_X32
>>  x32_ld_ok := $(call try-run,\
>>  /bin/echo -e '1: .quad 1b' | \
>> >>>
>> >>> Why conditional on clang?
>> >>
>> >> My understanding is that this warning is clang specific, it is not
>> >> listed on https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>> > 
>> > Actually this warning affects other platforms besides x86
>> > (e.g. arm64), I'll submit a patch that disables the warning on all
>> > platforms.
>> > 
>> 
>> Drop the ifeq ($(cc-name),clang).
>> 
>> You should assume that if you have to add one of those ifeq's then
>you
>> are doing something fundamentally wrong.
>
>Thanks, however in the case of the global Makefile it seems we should
>put it inside the already existing clang section:
>
>http://lxr.free-electrons.com/source/Makefile#L692
>
>Cheers
>
>Matthias

We shouldn't, unless it will actively break non-clang builds...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding

2017-04-13 Thread Hoegeun Kwon
The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
new file mode 100644
index 000..09c65f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2-e"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+&dsi {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1



Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

2017-04-13 Thread hpa
On April 13, 2017 8:51:19 PM PDT, Gary Lin  wrote:
>On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
>> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
>> >This commit adds the new config options to allow the user to modify
>the
>> >following fields in the PE-COFF header.
>> >
>> >UINT16 MajorOperatingSystemVersion
>> >UINT16 MinorOperatingSystemVersion
>> >UINT16 MajorImageVersion
>> >UINT16 MinorImageVersion
>> >
>> >Those fields are mainly for the executables or libraries in Windows
>NT
>> >or higher to specify the minimum supported Windows version and the
>> >version of the image itself.
>> >
>> >Given the fact that those fields are ignored in UEFI, we can safely
>> >reuse
>> >those fields for other purposes, e.g. Security Version(*).
>> >
>> >(*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> >Cc: Thomas Gleixner 
>> >Cc: Ingo Molnar 
>> >Cc: "H. Peter Anvin" 
>> >Cc: Masahiro Yamada 
>> >Cc: Michal Marek 
>> >Cc: Matt Fleming 
>> >Cc: Ard Biesheuvel 
>> >Cc: Joey Lee 
>> >Cc: Vojtech Pavlik 
>> >Signed-off-by: Gary Lin 
>> >Tested-by: Joey Lee 
>> >---
>[snip]
>> 
>> Reusing PECOFF fields seems doubleplusunsafe: we don't own those
>fields, the UEFI forum does.  It would make a lot more sense to add
>these fields to the bzImage header directly or indirectly (via a
>pointer), the latter would be more economical since the bzImage header
>size is bounded.
>> 
>> We could even define it as a pointer to a "security information
>header" with its own size field, so it can be grown in the future as
>needed.
>Reusing PE-COFF simplifies the implementation since shim can parse the
>header directly. I can raise the issue to the UEFI forum to clarify the
>usage of those fields.
>
>Meanwhile, I'll also look into the bzImage header in case the PE-COFF
>header is really a NO-GO.
>
>Thanks,
>
>Gary Lin

If we are going to use the PE-COFF hear then you need to write a proposal and 
get the UEFI forum to sign off on it.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[PATCH 0/3] Add support for the S6E3HA2 edge panel on TM2e board

2017-04-13 Thread Hoegeun Kwon
The purpose of this patch is add support for S6E3HA2 edge AMOLED panel
on the TM2e board. The panel has 1600x2560 resolution in 5.65"
physical panel in the TM2e device.

The S6E3HA2 edge panel(5.65") is simliar to the previous S6E3HA2
panel(5.7"), but resolution and some command message are different. So
it can be distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e3ha2 edge panel binding
  drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
  arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e
board

 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 62 +++---
 3 files changed, 96 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

-- 
1.9.1



[PATCH 3/3] arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e board

2017-04-13 Thread Hoegeun Kwon
This patch add the panel device tree node for S6E3HA2 edge display
controller to TM2e dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..79f22f7 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <27800>, <4>;
 };
 
+&dsi {
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 &ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
-- 
1.9.1



[PATCH 2/3] drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board

2017-04-13 Thread Hoegeun Kwon
This patch considers edge type of panel on TM2e board and The panel
has 1600x2560 resolution in 5.65" physical panel in the TM2e device.

This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for default
compatibility and edge type and select the drm_display_mode of default
and edge type.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 ---
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..b4a064a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
 };
 
+enum s6e3ha2_type {
+   DEFAULT_TYPE,
+   EDGE_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+   const struct drm_display_mode *mode;
+   enum s6e3ha2_type type;
+};
+
 struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+   const struct s6e3ha2_panel_desc *desc;
 };
 
 static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
 static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
 {
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+   if (ctx->desc->type == EDGE_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
-   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
-   0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+   if (ctx->desc->type == DEFAULT_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+   else
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
 }
 
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
 };
 
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2 = {
+   .mode = &default_mode,
+   .type = DEFAULT_TYPE,
+};
+
+static const struct drm_display_mode edge_mode = {
+   .clock = 247856,
+   .hdisplay = 1600,
+   .hsync_start = 1600 + 1,
+   .hsync_end = 1600 + 1 + 1,
+   .htotal = 1600 + 1 + 1 + 1,
+   .vdisplay = 2560,
+   .vsync_start = 2560 + 1,
+   .vsync_end = 2560 + 1 + 1,
+   .vtotal = 2560 + 1 + 1 + 15,
+   .vrefresh = 60,
+   .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2e = {
+   .mode = &edge_mode,
+   .type = EDGE_TYPE,
+};
+
 static int s6e3ha2_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
+   struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(panel->drm, &default_mode);
+   mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+   ctx->desc->mode->vrefresh);
return -ENOMEM;
}
 
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
 
ctx->dev = dev;
+   ctx->desc = of_device_get_match_data(dev);
 
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
 }
 
 static const struct of_device_id s6e3ha2_of_match[] = {
-   { .compatible = "samsung,s6e3ha2" },
+   { .compatible = "samsung,s6e3ha2",
+ .data = &samsung_s6e3ha2_tm2 },
+   { .compatible = "samsung,s6e3ha2-e",
+ .data = &samsung_s6e3ha2_tm2e },
{ }
 };
 MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
-- 
1.9.1



[PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

2017-04-13 Thread Keerthy
thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff

The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system it takes at least 5-10 Seconds to
power off gracefully.

In that period due to the thermal_zone_device_check triggering
periodically the thermal work queues bombard with
orderly_poweroff calls multiple times eventually leading to
failures in gracefully powering off the system.

Make sure that orderly_poweroff is called only once.

Reported-by: Keerthy 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Changed the place where mutex was locked and unlocked.

Changes in v2:

  * Added a global mutex to serialize poweroff code sequence.

 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 11f0675..9cad1ba 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -45,6 +45,7 @@
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
+static DEFINE_MUTEX(poweroff_lock);
 
 static atomic_t in_suspend;
 
@@ -326,6 +327,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
  int trip, enum thermal_trip_type trip_type)
 {
int trip_temp;
+   static bool power_off_triggered;
 
tz->ops->get_trip_temp(tz, trip, &trip_temp);
 
@@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
dev_emerg(&tz->device,
  "critical temperature reached(%d C),shutting down\n",
  tz->temperature / 1000);
-   orderly_poweroff(true);
+   mutex_lock(&poweroff_lock);
+   if (!power_off_triggered) {
+   orderly_poweroff(true);
+   power_off_triggered = true;
+   }
+   mutex_unlock(&poweroff_lock);
}
 }
 
@@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
 {
int result;
 
+   mutex_init(&poweroff_lock);
result = thermal_register_governors();
if (result)
goto error;
@@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
ida_destroy(&thermal_cdev_ida);
mutex_destroy(&thermal_list_lock);
mutex_destroy(&thermal_governor_lock);
+   mutex_destroy(&poweroff_lock);
return result;
 }
 
-- 
1.9.1



Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

2017-04-13 Thread Christoph Hellwig
On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote:
> Or maybe I'll just send a patch for that
> separately seeing it doesn't depend on anything and is pretty simple. I
> can do that next week.

Yes, please just send that patch linux-nvme, we should be able to get
it into 4.12.


[PATCH v3 2/2] thermal: core: Add a back up thermal shutdown mechanism

2017-04-13 Thread Keerthy
orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle of driver probes being
initiated, userspace will be unable to power off the system in a clean
manner and leaves the system in a critical state. In cases like these,
the /sbin/poweroff will return success (having forked off to attempt
powering off the system. However, the system overall will fail to
completely poweroff (since other modules will be probed) and the system
is still functional with no userspace (since that would have shut itself
off).

However, there is no clean way of detecting such failure of userspace
powering off the system. In such scenarios, it is necessary for a backup
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.

Reported-by: Nishanth Menon 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Removed unnecessary mutex init.
  * Added WARN messages instead of a simple warning message.
  * Added Documentation.

 Documentation/thermal/sysfs-api.txt | 18 +++
 drivers/thermal/Kconfig | 13 +++
 drivers/thermal/thermal_core.c  | 45 +
 3 files changed, 76 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index ef473dc..94b707c 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -582,3 +582,21 @@ platform data is provided, this uses the step_wise 
throttling policy.
 This function serves as an arbitrator to set the state of a cooling
 device. It sets the cooling device to the deepest cooling state if
 possible.
+
+6. thermal_emergency_poweroff:
+
+On an event of critical trip temperature crossing. Thermal framework
+allows the system to shutdown gracefully by calling orderly_poweroff.
+In the event of a failure of orderly_poweroff to shut down the system
+we are in danger of keeping the system alive at undesirably high
+temperatures. To mitigate this high risk scenario we program a work
+queue to fire after a pre-determined number of seconds to start
+an emergency shutdown of the device using the kernel_power_off
+function.
+
+The delay should be carefully profiled so as to give adequate time for
+orderly_poweroff. In case of failure of an orderly_poweroff the
+emergency poweroff kicks in after the delay has elapsed and shuts down
+the system.
+
+If set to 0 emergency poweroff will happen immediately.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9347401..971fd54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,19 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
+   int "Emergency poweroff delay in milli-seconds"
+   depends on THERMAL
+   default 0
+   help
+ The number of milliseconds to delay before emergency
+ poweroff kicks in. The delay should be carefully profiled
+ so as to give adequate time for orderly_poweroff. In case
+ of failure of an orderly_poweroff the emergency poweroff
+ kicks in after the delay has elapsed and shuts down the system.
+
+ If set to 0 poweroff will happen immediately.
+
 config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9cad1ba..30098cd 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -323,6 +323,46 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+/**
+ * emergency_poweroff_func - emergency poweroff work after a known delay
+ * @work: work_struct associated with the emergency poweroff function
+ *
+ * This function is called in very critical situations to force
+ * a kernel poweroff after a configurable timeout value.
+ */
+static void emergency_poweroff_func(struct work_struct *work)
+{
+   /*
+* We have reached here after the emergency thermal shutdown
+* Waiting period has expired. This means orderly_poweroff has
+* not been able to shut off the system for some reason.
+* Try to shut down the system immediately using kernel_power_off
+* if populated
+*/
+   WARN(1, "Attempting kernel_power_off: Temperature too high\n");
+   kernel_power_off();
+
+   /*
+* Worst of the worst case trigger emergency restart
+*/
+   WARN(1, "Attempting emergency_restart: Temperature too high\n");
+   emergency_restart();
+}
+
+static DECLARE_DELAYED_WORK(emergency_poweroff_work, emergency_poweroff_func);
+
+/**
+ * emergency_poweroff - Trigger an emergency system pow

Re: [PATCH 4/6] kvm: nVMX: support EPT accessed/dirty bits

2017-04-13 Thread Paolo Bonzini


On 13/04/2017 07:02, Bandan Das wrote:
>> For EPT it is, you're right it's fishy.  The "nested_access" should be
>> computed in translate_nested_gpa, which is where kvm->arch.nested_mmu
>> (non-EPT) requests to access kvm->arch.mmu (EPT).
>
> Thanks for the clarification. Is it the case when L1 runs L2 without
> EPT ? I can't figure out the case where translate_nested_gpa will actually
> be called.

It happens when L2 instruction are emulated by L0, for example when L1
is passing through I/O ports to L2 and L2 runs an "insb" instruction.  I
think this case is not covered by vmx.flat.

Paolo

> FNAME(walk_addr_nested) calls walk_addr_generic
> with &vcpu->arch.nested_mmu and init_kvm_nested_mmu() sets gva_to_gpa()
> with the appropriate "_nested" functions. But the gva_to_gpa() pointers
> don't seem to get invoked at all for the nested case.
> 
> BTW, just noticed that setting PFERR_USER_MASK is redundant since
> translate_nested_gpa does it too.


Re: [PATCH] KVM: nVMX: fix AD condition when handling EPT violation

2017-04-13 Thread Paolo Bonzini


On 14/04/2017 00:39, Radim Krčmář wrote:
> I have introduced this bug when applying and simplifying Paolo's patch
> as we agreed on the list.  The original was "x &= ~y; if (z) x |= y;".
> 
> Here is the story of a bad workflow:
> 
>   A maintainer was already testing with the intended change, but it was
>   applied only to a testing repo on a different machine.  When the time
>   to push tested patches to kvm/next came, he realized that this change
>   was missing and quickly added it to the maintenance repo, didn't test
>   again (because the change is trivial, right), and pushed the world to
>   fire.
> 
> Fixes: ae1e2d1082ae ("kvm: nVMX: support EPT accessed/dirty bits")
> Signed-off-by: Radim Krčmář 
> ---
>  arch/x86/kvm/vmx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index cfdb0d9389d1..837f6dd1ae9c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6221,7 +6221,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
>* page table accesses are reads or writes.
>*/
>   u64 eptp = nested_ept_get_cr3(vcpu);
> - if (eptp & VMX_EPT_AD_ENABLE_BIT)
> + if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
>   exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
>   }
>  
> 

I have done this as well, so you're forgiven. :)

More important: did kvm-unit-test catch the bug?

Paolo


Re: [PATCH 1/3] zram: fix operator precedence to get offset

2017-04-13 Thread Sergey Senozhatsky
Hello,

On (04/13/17 09:17), Minchan Kim wrote:
[..]
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9e2199060040..83c38a123242 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -930,7 +930,7 @@ static int zram_rw_page(struct block_device *bdev, 
> sector_t sector,
>   }
>  
>   index = sector >> SECTORS_PER_PAGE_SHIFT;
> - offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> + offset = (sector & (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;

sorry, can it actually produce different results?

-ss


Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe


On 13/04/17 10:59 PM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
>> This is a straight forward conversion in two places. Should kmap fail,
>> the code will return an INVALD_DATA error in the completion.
> 
> It really should be using nvmet_copy_from_sgl to make things safer,
> as we don't want to rely on any particular SG list layout.  In fact
> I'm pretty sure I did the conversion at some point, but it must never
> have made it upstream.

Ha, I did the conversion too a couple times for my RFC series. I can
change this patch to do that. Or maybe I'll just send a patch for that
separately seeing it doesn't depend on anything and is pretty simple. I
can do that next week.

Thanks,

Logan


Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

2017-04-13 Thread Christoph Hellwig
On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
> This is a straight forward conversion in two places. Should kmap fail,
> the code will return an INVALD_DATA error in the completion.

It really should be using nvmet_copy_from_sgl to make things safer,
as we don't want to rely on any particular SG list layout.  In fact
I'm pretty sure I did the conversion at some point, but it must never
have made it upstream.


Re: ARM64 TPM start method patches

2017-04-13 Thread anjiandi

Adding Harb Abdulhamid for SMC details

On 2017-04-11 06:36, Mark Rutland wrote:

Hi,

I just stumbled upon the following commits in next-20170411:

  cf8252ca7ca76fa4 ("ACPICA: Update TPM2 ACPI table")
  08eff49d63ca2bf4 ("tpm/tpm_crb: Enable TPM CRB interface for ARM64")

... which leave me a little concerned, for two reasons.

Firstly, the spec these are based on (TCG ACPI Specification Family
“1.2” and “2.0” Version 1.2, Revision 8), is a draft, open for public
review until April 28th 2017 [1], and still subject to change, as noted
in the title page of the document [2]:

This document is an intermediate draft for comment only and is
subject to change without notice. Readers should not design 
products

based on this document.

... so I hope the plan is not to merge these until the final spec is
published.

Secondly, the spec is very vague as to the workings of the SMC call, 
and

does not define:

 * That the SMC call follows the SMC Calling Convention [3]
 * The parameters to the SMC call
 * The return value(s) of the SMC call

... which I believe should be clarified in the spec before we make
assumptions regarding these in the Linux driver. Otherwise, this is
liable to vary in practice.

Thanks,
Mark.

[1] https://trustedcomputinggroup.org/specifications-public-review/
[2]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-reviepdf
[3]
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf


Re: [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API

2017-04-13 Thread Kishon Vijay Abraham I
hi Chanwoo,

On Friday 14 April 2017 06:13 AM, Chanwoo Choi wrote:
> Hi Kishon,
> 
> On 2017년 04월 13일 20:47, Kishon Vijay Abraham I wrote:
>> Hi Chanwoo,
>>
>> On Tuesday 28 March 2017 10:08 AM, Chanwoo Choi wrote:
>>> This patch uses the resource-managed extcon API for 
>>> extcon_register_notifier()
>>> and replaces the deprecated extcon API as following:
>>> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>>>
>>> Cc: Kishon Vijay Abraham I 
>>> Signed-off-by: Chanwoo Choi 
>>
>> I've missed merging this patch for the next merge window. If you want to take
>> this yourself.
>> Acked-by: Kishon Vijay Abraham I 
> 
> I already posted the pull-request to GregKH for extcon subsystem.
> So, if possible, I hope you handle these patches.
> Even if these patches are not merged to 4.12-rc1, I'm ok. 
> Just I want to handle them on your tree for next time.

Sure, I'll take them then.

Thanks
Kishon

> 
>>
>> Thanks
>> Kishon
>>> ---
>>>  drivers/phy/phy-qcom-usb-hs.c | 14 +++---
>>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
>>> index 94dfbfd739c3..f630fa553b7d 100644
>>> --- a/drivers/phy/phy-qcom-usb-hs.c
>>> +++ b/drivers/phy/phy-qcom-usb-hs.c
>>> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>> }
>>>  
>>> if (uphy->vbus_edev) {
>>> -   state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
>>> +   state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
>>> /* setup initial state */
>>> qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
>>>   uphy->vbus_edev);
>>> -   ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
>>> -   &uphy->vbus_notify);
>>> +   ret = devm_extcon_register_notifier(&ulpi->dev, uphy->vbus_edev,
>>> +   EXTCON_USB, &uphy->vbus_notify);
>>> if (ret)
>>> goto err_ulpi;
>>> }
>>> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>>>  
>>>  static int qcom_usb_hs_phy_power_off(struct phy *phy)
>>>  {
>>> -   int ret;
>>> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>>>  
>>> -   if (uphy->vbus_edev) {
>>> -   ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
>>> -&uphy->vbus_notify);
>>> -   if (ret)
>>> -   return ret;
>>> -   }
>>> -
>>> regulator_disable(uphy->v3p3);
>>> regulator_disable(uphy->v1p8);
>>> clk_disable_unprepare(uphy->sleep_clk);
>>>
>>
>>
>>
> 
> 


Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

2017-04-13 Thread PrasannaKumar Muralidharan
On 14 April 2017 at 09:28, Sean Wang  wrote:
>
> Hi PrasannaKumar,
>
> Add my comments inline
>
>>
>> Use readl_poll_timeout_atomic's return value or -EIO instead of
>> !!ready. This will simplify mtk_rng_read.
>>
>
> !!ready provided is in order to let blocking/non-blocking case could
> share same code path. And readl_poll_timeout_atomic only handles
> blocking case.

Missed this point. Makes sense. My previous comment about return value
in mtk_rng_read is invalid as I based it on a wrong assumption.

>
>> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
>> > wait)
>> > +{
>> > +   struct mtk_rng *priv = to_mtk_rng(rng);
>> > +   int retval = 0;
>> > +
>> > +   while (max >= sizeof(u32)) {
>> > +   if (!mtk_rng_wait_ready(rng, wait))
>> > +   break;
>> > +
>> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
>> > +   retval += sizeof(u32);
>> > +   buf += sizeof(u32);
>> > +   max -= sizeof(u32);
>> > +   }
>> > +
>> > +   if (unlikely(wait && max))
>> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
>>
>> Is this really necessary? Better to choose proper timeout than
>> providing this warning message. In rare cases if the timeout could
>> occur due to some reason (may be a hardware fault) print appropriate
>> warning message.
>
> It is good, I will choose the proper timeout and remove the log in the
> next one.
>
>>
>> > +   return retval || !wait ? retval : -EIO;
>> > +}
>>
>> Set retavl to mtk_rng_wait_ready and return retval.
>>
>
> Maybe i didn't get your points exactly. Adding some explanation about
> thoughts here.
>
> "return retval || !wait ? retval : -EIO;" I use can also help handling
> the both cases in one line which i think is elegant enough.
>
> And retval is accumulated with each round if some data's existing in
> hardware, so we don't return the value from mtk_rng_wait_ready().

retval can be 0 only when mkt_rng_wait_ready fails, returning 0 when
wait is true is confusing. Expected return value when 0 bytes is read
from device and wait is true is not clearly documented.

"return retval || !wait ? retval : -EIO;" is also fine.

Overall the code looks good to me. You can add:
Reviewed-by: PrasannaKumar Muralidharan .

Regards,
PrasannaKumar


Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

2017-04-13 Thread Sergey Senozhatsky
Hello Petr,

thanks for taking a look!

On (04/13/17 16:03), Petr Mladek wrote:
> > +static inline bool console_offload_printing(void)
> > +{
> > +   static struct task_struct *printing_task = NULL;
> > +   static unsigned long lines_printed = 0;
> > +
> > +   if (!atomic_print_limit || !printk_kthread_enabled())
> > +   return false;
> > +
> > +   /* We rescheduled - reset the counters. */
> > +   if (printing_task != current) {
> > +   lines_printed = 0;
> > +   printing_task = current;
> > +   return false;
> > +   }
> 
> If we want to check that the process rescheduled, we should
> store/check also current->nvcsw + current->nivcsw.

ok.

[..]
> My only fear is that it is getting more and more complicated.
> On the other hand, any partial solution is asking for
> troubles and complains.

yeah. we have to aim slightly different and conflicting targets - introducing
a new printk behavior, while preserving an already existing guarantees. which
is a bit tricky.


[..]
> > +   if (lines_printed > 2 * (unsigned long)atomic_print_limit) {
> > +   printk_enforce_emergency = true;
> > +   pr_crit("Declaring printk emergency mode.\n");
> > +   return false;
> > +   }
> 
> The only messages that are printed on my workstation are the same
> few lines everytime I connect my phone over USB to get it charged.

you are right. this is a known and yet to be resolved issue.


> It might help to check the number of process switch counts as
> suggested above.

will take a look at your 'current->nvcsw + current->nivcsw' idea.
thanks.


[..]
> > +   /*
> > +* Sometimes we may lock console_sem before printk_kthread.
> > +* In this case we will jump to `again' label (if there are
> > +* pending messages), print one more line from current
> > +* process, break out of printing loop (we don't reset the
> > +* counter of printed lines) and do up_console_sem() to
> > +* wakeup printk_kthread again.
> > +*
> > +* If printk_kthread never wakes up (which may indicate that
> > +* the system is unstable or something weird is going on),
> > +* then we will keep jumping to `again' label and printing
> > +* one message from the logbuf. This is a bit ugly, but at
> > +* least we will print out the logbuf.
> > +*
> > +* If such condition occurs, console_offload_printing() can
> > +* declare `printk_emergency' at some point.
> 
> I am a bit confused by the comment above. The again goto target is
> used only when there is a race between leaving the loop and releasing
> the console_sem. It is a corner case.

not really.

this is the part where "preserve printk guarantees" jumps in.

when we limit the number of lines we can print we have to leave this loop
with not fully flushed logbuf. so `goto again' is not solely for corner
case anymore. when we prematurely leave the printing loop, we wake_up
printk_kthread, unlock console_sem... and then we have no idea if
printk_kthread going to wake_up at all, and, if it's going to, how much
time will it take. at the same time we have a task that is already in
console_unlock() and, probably, we still have pending messages in the logbuf.
that's why the process that just has left the printing loop [and there easily
might be pending messages in the logbuf] does the whole 'retry' thing. we can
have a misbehaving high priority process or something, that would prevent
printk_kthread from becoming running just when we need it. so, at least
sometimes, the printing process (the one that breaks ouf of printing loop
and wakes up printk_kthread) can re-acquire console_sem and print one more
line, then it up() console_sem, which, hopefully, will wake_up printk_kthread.
if printk_kthread did become running then if would be in console_sem wait
list at this point. if it didn't - then we

a) wake up some other process that is probably in console_sem list
   (hopefully there is one)

or

b) continue printing from the current process. because printk_kthread
   is still not running and there are no other processes that want to
   console_lock(). not much we can do at this point.


so in expected/normal scenario, we fail to re-acquire the console_sem lock
(console_trylock()), which means that either printk_kthread or some other
process from console_sem wait list acquired the console_sem and will take
over printing.


I do something like this

---
@@ -2427,6 +2427,8 @@ void console_unlock(void)
console_seq++;
raw_spin_unlock(&logbuf_lock);
 
+   sprintf(text + 7, "{%s}", current->comm);
+
stop_critical_timings();/* don't trace print latency */
call_console_drivers(ext_text, ext_len, text, len);
start_critical_timings();
---


and fire up some silly pri

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-13 Thread Logan Gunthorpe


On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> I'd suggest just detecting if there is any translation in bus
> addresses anywhere and just hard disabling P2P on such systems.

That's a fantastic suggestion. It simplifies things significantly.
Unless there are any significant objections I think I will plan on doing
that.

> On modern hardware with 64 bit BARs there is very little reason to
> have translation, so I think this is a legacy feature.

Yes, p2pmem users are likely to be designing systems around it (ie
JBOFs) and not trying to shoehorn it onto legacy architectures.

At the very least, it makes sense to leave it out and if someone comes
along who cares they can put in the effort to support the address
translation.

Thanks,

Logan


[PATCH] drivers: input: joystick: Add PSX(Play Staion 1/2) pad with SPI driver Add PSX(Play Staion 1/2) pad with SPI driver. Pads can be connected directry SPI bus.

2017-04-13 Thread AZO
---
 drivers/input/joystick/Kconfig  |  11 +-
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 679 
 3 files changed, 690 insertions(+), 1 deletion(-)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b53..6e38a74 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,13 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
-endif
+config JOYSTICK_PSXPAD_SPI
+   tristate "PSX(Play Station 1/2) pad with SPI Bus Driver"
+   depends on INPUT_POLLDEV && SPI
+   help
+ Say Y here if you connect PSX(PS1/2) pad with SPI Interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+endifendif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de..2b71848 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_JOYSTICK_WARRIOR)+= warrior.o
 obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
 obj-$(CONFIG_JOYSTICK_ZHENHUA) += zhenhua.o
 obj-$(CONFIG_JOYSTICK_WALKERA0701) += walkera0701.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index 000..c5b497b
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,679 @@
+/*
+ * PSX(Play Station 1/2) pad (SPI Interface)
+ *
+ * Copyright (C) 2017 AZO 
+ * Licensed under the GPL-2 or later.
+ *
+ * PSX pad plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//#define PSXPAD_ENABLE_ANALOG2
+#define PSXPAD_ENABLE_FF
+
+enum {
+   PSXPAD_SPI_SPEED_125KHZ = 0,
+   PSXPAD_SPI_SPEED_250KHZ,
+   PSXPAD_SPI_SPEED_500KHZ,
+   PSXPAD_SPI_SPEED_UNKNOWN
+};
+
+#define PSXPAD_DEFAULT_SPI_DELAY   100
+#define PSXPAD_DEFAULT_SPI_SPEED   PSXPAD_SPI_SPEED_125KHZ
+#define PSXPAD_DEFAULT_INTERVAL16
+#define PSXPAD_DEFAULT_INTERVAL_MIN8
+#define PSXPAD_DEFAULT_INTERVAL_MAX32
+#define PSXPAD_DEFAULT_ADMODE  true
+#define PSXPAD_DEFAULT_INPUT_PHYSIZE   32
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) & 
0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 3) | 
(((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+enum {
+   PSXPAD_KEYSTATE_TYPE_DIGITAL = 0,
+   PSXPAD_KEYSTATE_TYPE_ANALOG1,
+#ifdef PSXPAD_ENABLE_ANALOG2
+   PSXPAD_KEYSTATE_TYPE_ANALOG2,
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+   PSXPAD_KEYSTATE_TYPE_UNKNOWN
+};
+
+#ifdef PSXPAD_ENABLE_ANALOG2
+static const u8 PSX_CMD_INIT_PRESSURE[]= {0x01, 0x40, 0x00, 0x00, 
0x02, 0x00, 0x00, 0x00, 0x00};
+static const u8 PSX_CMD_ALL_PRESSURE[] = {0x01, 0x4F, 0x00, 0xFF, 0xFF, 0x03, 
0x00, 0x00, 0x00};
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+static const u8 PSX_CMD_POLL[] = {0x01, 0x42, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00};
+static const u8 PSX_CMD_ENTER_CFG[]= {0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+static const u8 PSX_CMD_EXIT_CFG[] = {0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 
0x5A, 0x5A, 0x5A};
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {0x01, 0x4D, 0x00, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF};
+static const u8 PSX_CMD_AD_MODE[]  = {0x01, 0x44, 0x00, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00};
+
+struct psxpad_keystate {
+   int type;
+   /* PSXPAD_KEYSTATE_TYPE_DIGITAL */
+   bool select;
+   bool start;
+   bool up;
+   bool right;
+   bool down;
+   bool left;
+   bool l2;
+   bool r2;
+   bool l1;
+   bool r1;
+   bool triangle;
+   bool circle;
+   bool cross;
+   bool square;
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG1 */
+   u8 l3;
+   u8 r3;
+   u8 lx;
+   u8 ly;
+   u8 rx;
+   u8 ry;
+#ifdef PSXPAD_ENABLE_ANALOG2
+   /* PSXPAD_KEYSTATE_TYPE_ANALOG2 */
+   u8 a_right;
+   u8 a_left;
+   u8 a_up;
+   u8 a_down;
+   u8 a_triangle;
+   u8 a_circle;
+   u8 a_cross;
+   u8 a_square;
+   u8 a_l1;
+   u8 a_r1;
+   u8 a_l2;
+   u8 a_r2;
+#endif /* PSXPAD_ENABLE_ANALOG2 */
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[PSXPAD_DEFAULT_INPUT_PHYSIZE];
+   u16 spi_delay;
+ 

Re: [patch 02/13] workqueue: Provide work_on_cpu_safe()

2017-04-13 Thread Tejun Heo
On Wed, Apr 12, 2017 at 10:07:28PM +0200, Thomas Gleixner wrote:
> work_on_cpu() is not protected against CPU hotplug. For code which requires
> to be either executed on an online CPU or to fail if the CPU is not
> available the callsite would have to protect against CPU hotplug.
> 
> Provide a function which does get/put_online_cpus() around the call to
> work_on_cpu() and fails the call with -ENODEV if the target CPU is not
> online.
> 
> Preparatory patch to convert several racy task affinity manipulations.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Tejun Heo 
> Cc: Lai Jiangshan 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun


Re: [PATCH] hugetlbfs: fix offset overflow in huegtlbfs mmap

2017-04-13 Thread Naoya Horiguchi
On Tue, Apr 11, 2017 at 03:51:58PM -0700, Mike Kravetz wrote:
...
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 7163fe0..dde8613 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -136,17 +136,26 @@ static int hugetlbfs_file_mmap(struct file *file, 
> struct vm_area_struct *vma)
>   vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND;
>   vma->vm_ops = &hugetlb_vm_ops;
>  
> + /*
> +  * Offset passed to mmap (before page shift) could have been
> +  * negative when represented as a (l)off_t.
> +  */
> + if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
> + return -EINVAL;
> +
>   if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
>   return -EINVAL;
>  
>   vma_len = (loff_t)(vma->vm_end - vma->vm_start);
> + len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> + /* check for overflow */
> + if (len < vma_len)
> + return -EINVAL;

Andrew sent this patch to Linus today, so I know it's a little too late, but
I think that getting len directly from vma like below might be a simpler fix.

  len = (loff_t)(vma->vm_end - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT)); 

This shouldn't overflow because vma->vm_{end|start|pgoff} are unsigned long,
but if worried you can add VM_BUG_ON_VMA(len < 0, vma).

Thanks,
Naoya Horiguchi

>  
>   inode_lock(inode);
>   file_accessed(file);
>  
>   ret = -ENOMEM;
> - len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> -
>   if (hugetlb_reserve_pages(inode,
>   vma->vm_pgoff >> huge_page_order(h),
>   len >> huge_page_shift(h), vma,
> @@ -155,7 +164,7 @@ static int hugetlbfs_file_mmap(struct file *file, struct 
> vm_area_struct *vma)
>  
>   ret = 0;
>   if (vma->vm_flags & VM_WRITE && inode->i_size < len)
> - inode->i_size = len;
> + i_size_write(inode, len);
>  out:
>   inode_unlock(inode);
>  
> -- 
> 2.7.4
> 
> 


Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-13 Thread Jason Gunthorpe
On Thu, Apr 13, 2017 at 06:26:31PM -0500, Bjorn Helgaas wrote:
> > Ah, thanks for the tip! On my system, this translation returns the same
> > address so it was not necessary. And, yes, that means this would have to
> > find its way into the dma mapping routine somehow. This means we'll
> > eventually need a way to look-up the p2pmem device from the struct page.
> > Which means we will likely need a new flag bit in the struct page or
> > something. The big difficulty I see is testing. Do you know what
> > architectures or in what circumstances are these translations used?
> 
> Any caller of pci_add_resource_offset() uses CPU addresses different from
> the PCI bus addresses (unless the offset is zero, of course).  All ACPI
> platforms also support this translation (see "translation_offset"), though
> in most x86 systems the offset is zero.  I'm aware of one x86 system that
> was tested with a non-zero offset but I don't think it was shipped that
> way.

I'd suggest just detecting if there is any translation in bus
addresses anywhere and just hard disabling P2P on such systems.

On modern hardware with 64 bit BARs there is very little reason to
have translation, so I think this is a legacy feature.

Jason


Re: [PATCH] powerpc/mm: Fix missing page attributes in page table dump

2017-04-13 Thread kbuild test robot
Hi Christophe,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc6 next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-mm-Fix-missing-page-attributes-in-page-table-dump/20170414-013347
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> arch/powerpc/mm/dump_linuxpagetables.c:212:11: error: '_PAGE_SHARED' 
>> undeclared here (not in a function)
  .mask = _PAGE_SHARED,
  ^~~~

vim +/_PAGE_SHARED +212 arch/powerpc/mm/dump_linuxpagetables.c

   206  }, {
   207  #endif
   208  .mask   = _PAGE_SPECIAL,
   209  .val= _PAGE_SPECIAL,
   210  .set= "special",
   211  }, {
 > 212  .mask   = _PAGE_SHARED,
   213  .val= _PAGE_SHARED,
   214  .set= "shared",
   215  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

2017-04-13 Thread Sean Wang

Hi PrasannaKumar,

Add my comments inline


On Thu, 2017-04-13 at 14:09 +0530, PrasannaKumar Muralidharan wrote:
> Hi Sean,
> 
> Mostly looks good, have few minor comments.
> 
> On 13 April 2017 at 12:35,   wrote:
> > +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int ready;
> > +
> > +   ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> > +   if (!ready && wait)
> > +   readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> > + ready & RNG_READY, USEC_POLL,
> > + TIMEOUT_POLL);
> > +   return !!ready;
> > +}
> 
> Use readl_poll_timeout_atomic's return value or -EIO instead of
> !!ready. This will simplify mtk_rng_read.
> 

!!ready provided is in order to let blocking/non-blocking case could
share same code path. And readl_poll_timeout_atomic only handles
blocking case.



> > +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool 
> > wait)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   int retval = 0;
> > +
> > +   while (max >= sizeof(u32)) {
> > +   if (!mtk_rng_wait_ready(rng, wait))
> > +   break;
> > +
> > +   *(u32 *)buf = readl(priv->base + RNG_DATA);
> > +   retval += sizeof(u32);
> > +   buf += sizeof(u32);
> > +   max -= sizeof(u32);
> > +   }
> > +
> > +   if (unlikely(wait && max))
> > +   dev_warn(priv->dev, "timeout might be not properly set\n");
> 
> Is this really necessary? Better to choose proper timeout than
> providing this warning message. In rare cases if the timeout could
> occur due to some reason (may be a hardware fault) print appropriate
> warning message.

It is good, I will choose the proper timeout and remove the log in the
next one.

> 
> > +   return retval || !wait ? retval : -EIO;
> > +}
> 
> Set retavl to mtk_rng_wait_ready and return retval.
> 

Maybe i didn't get your points exactly. Adding some explanation about
thoughts here.

"return retval || !wait ? retval : -EIO;" I use can also help handling
the both cases in one line which i think is elegant enough. 

And retval is accumulated with each round if some data's existing in
hardware, so we don't return the value from mtk_rng_wait_ready().


> Regards,
> Prasanna

thanks for all your reviewing and suggestion

Sean



Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

2017-04-13 Thread Gary Lin
On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote:
> On April 11, 2017 3:20:41 AM PDT, Gary Lin  wrote:
> >This commit adds the new config options to allow the user to modify the
> >following fields in the PE-COFF header.
> >
> >UINT16 MajorOperatingSystemVersion
> >UINT16 MinorOperatingSystemVersion
> >UINT16 MajorImageVersion
> >UINT16 MinorImageVersion
> >
> >Those fields are mainly for the executables or libraries in Windows NT
> >or higher to specify the minimum supported Windows version and the
> >version of the image itself.
> >
> >Given the fact that those fields are ignored in UEFI, we can safely
> >reuse
> >those fields for other purposes, e.g. Security Version(*).
> >
> >(*) https://github.com/lcp/shim/wiki/Security-Version
> >
> >Cc: Thomas Gleixner 
> >Cc: Ingo Molnar 
> >Cc: "H. Peter Anvin" 
> >Cc: Masahiro Yamada 
> >Cc: Michal Marek 
> >Cc: Matt Fleming 
> >Cc: Ard Biesheuvel 
> >Cc: Joey Lee 
> >Cc: Vojtech Pavlik 
> >Signed-off-by: Gary Lin 
> >Tested-by: Joey Lee 
> >---
[snip]
> 
> Reusing PECOFF fields seems doubleplusunsafe: we don't own those fields, the 
> UEFI forum does.  It would make a lot more sense to add these fields to the 
> bzImage header directly or indirectly (via a pointer), the latter would be 
> more economical since the bzImage header size is bounded.
> 
> We could even define it as a pointer to a "security information header" with 
> its own size field, so it can be grown in the future as needed.
Reusing PE-COFF simplifies the implementation since shim can parse the
header directly. I can raise the issue to the UEFI forum to clarify the
usage of those fields.

Meanwhile, I'll also look into the bzImage header in case the PE-COFF
header is really a NO-GO.

Thanks,

Gary Lin


Re: [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral

2017-04-13 Thread Shawn Guo
On Thu, Apr 13, 2017 at 06:32:42AM -0700, Andrey Smirnov wrote:
> Enable PCIe peripheral on this board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index e0ff276..f77e26a 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -352,6 +352,13 @@
>   };
>  };
>  
> +&pcie {
> + pinctrl-names = "default";
> + reset-gpio = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <&gpio_spi 0 GPIO_ACTIVE_LOW>;

I do not see this disable-gpio is documented or supported.

Shawn

> + status = "okay";
> +};
> +
>  &pwm1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinctrl_pwm1>;
> -- 
> 2.9.3
> 


Re: [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node

2017-04-13 Thread Shawn Guo
On Thu, Apr 13, 2017 at 06:32:40AM -0700, Andrey Smirnov wrote:
> Add node for U38, a 74LV595PW serial-in shift register that acts as a
> GPIO expander on the board.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7d-sdb.dts | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
>   reg = <0x8000 0x8000>;
>   };
>  
> + spi4 {
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
> + status = "okay";

The 'status' is not needed in this case.

> + gpio-sck = <&gpio1 13 0>;
> + gpio-mosi = <&gpio1 9 0>;
> + cs-gpios = <&gpio1 12 0>;
> + num-chipselects = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_spi: gpio_spi@0 {

gpio-expander might be a better node name?

> + compatible = "fairchild,74hc595";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0>;
> + registers-number = <1>;
> +  /* Enable PERI_3V3, SENSOR_RST_B and HDMI_RST*/
> + registers-default = /bits/ 8 <0x74>;

I do not see this property is documented or supported by kernel.

> + spi-max-frequency = <10>;
> + };
> + };
> +
>   regulators {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -642,5 +666,13 @@
>   fsl,pins = <
>   MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT  0x110b0
>   >;
> +
> + pinctrl_spi1: spi1grp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO09__GPIO1_IO9  0x59
> + MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
> + MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
> + >;
> + };
>   };
>  };
> -- 
> 2.9.3
> 


Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC

2017-04-13 Thread Shawn Guo
On Thu, Apr 13, 2017 at 06:32:38AM -0700, Andrey Smirnov wrote:
> Add node for GPC and specify as a parent interrupt controller for SoC bus.
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx7s.dtsi | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 8fee299..1a7058f 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -119,7 +120,7 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "simple-bus";
> - interrupt-parent = <&intc>;
> + interrupt-parent = <&gpc>;
>   ranges;
>  
>   funnel@30041000 {
> @@ -301,6 +302,7 @@
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>   #interrupt-cells = <3>;
>   interrupt-controller;
> + interrupt-parent = <&intc>;
>   reg = <0x31001000 0x1000>,
> <0x31002000 0x2000>,
> <0x31004000 0x2000>,
> @@ -309,6 +311,7 @@
>  
>   timer {
>   compatible = "arm,armv7-timer";
> + interrupt-parent = <&intc>;
>   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> @@ -564,6 +567,28 @@
>   interrupts = ;
>   #reset-cells = <1>;
>   };
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&intc>;
> + #power-domain-cells = <1>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: pgc-pcie-phy-domain {

The node name should be something generic and has a unit-address when
there is a 'reg' property in the node.

> + #power-domain-cells = <0>;
> +

Drop this newline.

Shawn

> + reg = 
> ;
> + power-supply = <®_1p0d>;
> + };
> + };
> + };
>   };
>  
>   aips2: aips-bus@3040 {
> -- 
> 2.9.3
> 


Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

2017-04-13 Thread Sean Wang
Hi Corentin,

I all agree and appreciate your careful reviewing. 

They will be added into the next one.

Sean

On Thu, 2017-04-13 at 13:06 +0200, Corentin Labbe wrote:
> Hello
> 
> I have some minor comment below:
> 
> On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds support for hardware random generator on MT7623 SoC
> > and should also work on other similar Mediatek SoCs. Currently,
> > the driver is already tested successfully with rng-tools.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  drivers/char/hw_random/Kconfig   |  16 +++-
> >  drivers/char/hw_random/Makefile  |   2 +-
> >  drivers/char/hw_random/mtk-rng.c | 174 
> > +++
> >  3 files changed, 190 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/char/hw_random/mtk-rng.c
> > 
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index 0cafe08..af782ce 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> >   Generator hardware found on Cavium SoCs.
> >  
> >   To compile this driver as a module, choose M here: the
> > - module will be called cavium_rng.
> > + module will be called mtk-rng.
> 
> Unwanted change
> 
> >  
> >   If unsure, say Y.
> >  
> > +config HW_RANDOM_MTK
> > +   tristate "Mediatek Random Number Generator support"
> > +   depends on HW_RANDOM
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   default y
> > +   ---help---
> > + This driver provides kernel-side support for the Random Number
> > + Generator hardware found on Mediatek SoCs.
> > +
> > + To compile this driver as a module, choose M here. the
> > + module will be called mtk-rng.
> > +
> > + If unsure, say Y.
> > +
> >  endif # HW_RANDOM
> >  
> >  config UML_RANDOM
> > diff --git a/drivers/char/hw_random/Makefile 
> > b/drivers/char/hw_random/Makefile
> > index 5f52b1e..68be716 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -1,7 +1,6 @@
> >  #
> >  # Makefile for HW Random Number Generator (RNG) device drivers.
> >  #
> > -
> 
> Another unwanted change
> 
> >  obj-$(CONFIG_HW_RANDOM) += rng-core.o
> >  rng-core-y := core.o
> >  obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> > @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> >  obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> > +obj-$(CONFIG_HW_RANDOM_MTK)+= mtk-rng.o
> > diff --git a/drivers/char/hw_random/mtk-rng.c 
> > b/drivers/char/hw_random/mtk-rng.c
> > new file mode 100644
> > index 000..6561ee0
> > --- /dev/null
> > +++ b/drivers/char/hw_random/mtk-rng.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Driver for Mediatek Hardware Random Number Generator
> > + *
> > + * Copyright (C) 2017 Sean Wang 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#define MTK_RNG_DEV KBUILD_MODNAME
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define USEC_POLL  2
> > +#define TIMEOUT_POLL   20
> > +
> > +#define RNG_CTRL   0x00
> > +#define  RNG_ENBIT(0)
> > +#define  RNG_READY BIT(31)
> 
> Keep only one space between define and name
> 
> > +
> > +#define RNG_DATA   0x08
> > +
> > +#define to_mtk_rng(p)  container_of(p, struct mtk_rng, rng)
> > +
> > +struct mtk_rng {
> > +   struct device   *dev;
> > +   void __iomem *base;
> > +   struct clk *clk;
> > +   struct hwrng rng;
> > +};
> > +
> > +static int mtk_rng_init(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +   int err;
> > +
> > +   err = clk_prepare_enable(priv->clk);
> > +   if (err)
> > +   return err;
> > +
> > +   val = readl(priv->base + RNG_CTRL);
> > +   val |= RNG_EN;
> > +   writel(val, priv->base + RNG_CTRL);
> > +
> > +   return 0;
> > +}
> > +
> > +static void mtk_rng_cleanup(struct hwrng *rng)
> > +{
> > +   struct mtk_rng *priv = to_mtk_rng(rng);
> > +   u32 val;
> > +
> > +   val = readl(priv->base + RNG_CTRL);
> > +   val &= ~RNG_EN;
> > +   writel(val, priv->b

Re: [PATCH 3/8] ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'

2017-04-13 Thread Shawn Guo
On Thu, Apr 13, 2017 at 06:32:37AM -0700, Andrey Smirnov wrote:
> In PMU_REG_1P0Dn ENABLE_LINREG is bit 0. Bit 31 is called OVERRIDE and
> it serves the function of granting permission to GPC IP block to alter
> various bit-fields of the register. The reason why this property, that
> trickeld here from Freescale BSP, is set to 31 is because in the code
> it came from it is used in conjunction with a notifier handler for
> REGULATOR_EVENT_PRE_DO_ENABLE and REGULATOR_EVENT_PRE_DO_DISABLE
> events (not found in upstream kernel) that triggers GPC to start
> manipulating aforementioned other bitfields.
> 
> Since:
>   a) none of the aforementioned machinery is implemented by
>  upstream
>   b) using 'anatop-enable-bit' in that capacity is a bit of a
>  semantic stretch
> 
> simplify the situation by setting the value of 'anatop-enable-bit' to
> point to ENABLE_LINREG (same as i.MX6).
> 
> Cc: yurov...@gmail.com
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Andrey Smirnov 

Since patch 1 ~ 3 are all about adding anatop-enable-bit, can we squash
them into one patch?

Shawn

> ---
>  arch/arm/boot/dts/imx7s.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 22c9788..8fee299 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -516,7 +516,7 @@
>   anatop-min-bit-val = <8>;
>   anatop-min-voltage = <80>;
>   anatop-max-voltage = <120>;
> - anatop-enable-bit = <31>;
> + anatop-enable-bit = <0>;
>   };
>   };
>  
> -- 
> 2.9.3
> 


[PATCH v2 net 2/2] net: ethernet: mediatek: fix inconsistency of port number carried in TXD

2017-04-13 Thread sean.wang
From: Sean Wang 

Fix port inconsistency on TXD due to hardware BUG that would cause
different port number is carried on the same TXD between tx_map()
and tx_unmap() with the iperf test. It would cause confusing BQL
logic which leads to kernel panic when dual GMAC runs concurrently.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 14 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 +---
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 48ba617..6313c53 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -648,6 +648,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
 
WRITE_ONCE(itxd->txd1, mapped_addr);
itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   itx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+ MTK_TX_FLAGS_FPORT1;
dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
@@ -689,6 +691,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
memset(tx_buf, 0, sizeof(*tx_buf));
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
+   tx_buf->flags |= (!mac->id) ? MTK_TX_FLAGS_FPORT0 :
+MTK_TX_FLAGS_FPORT1;
+
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
frag_size -= frag_map_size;
@@ -1011,17 +1016,16 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 
while ((cpu != dma) && budget) {
u32 next_cpu = desc->txd2;
-   int mac;
+   int mac = 0;
 
desc = mtk_qdma_phys_to_virt(ring, desc->txd2);
if ((desc->txd3 & TX_DMA_OWNER_CPU) == 0)
break;
 
-   mac = (desc->txd4 >> TX_DMA_FPORT_SHIFT) &
-  TX_DMA_FPORT_MASK;
-   mac--;
-
tx_buf = mtk_desc_to_tx_buf(ring, desc);
+   if (tx_buf->flags & MTK_TX_FLAGS_FPORT1)
+   mac = 1;
+
skb = tx_buf->skb;
if (!skb) {
condition = 1;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 996024d..3c46a3b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -410,12 +410,18 @@ struct mtk_hw_stats {
struct u64_stats_sync   syncp;
 };
 
-/* PDMA descriptor can point at 1-2 segments. This enum allows us to track how
- * memory was allocated so that it can be freed properly
- */
 enum mtk_tx_flags {
+   /* PDMA descriptor can point at 1-2 segments. This enum allows us to
+* track how memory was allocated so that it can be freed properly.
+*/
MTK_TX_FLAGS_SINGLE0= 0x01,
MTK_TX_FLAGS_PAGE0  = 0x02,
+
+   /* MTK_TX_FLAGS_FPORTx allows tracking which port the transmitted
+* SKB out instead of looking up through hardware TX descriptor.
+*/
+   MTK_TX_FLAGS_FPORT0 = 0x04,
+   MTK_TX_FLAGS_FPORT1 = 0x08,
 };
 
 /* This enum allows us to identify how the clock is defined on the array of the
-- 
1.9.1



[PATCH v2 net 1/2] net: ethernet: mediatek: fix inconsistency between TXD and the used buffer

2017-04-13 Thread sean.wang
From: Sean Wang 

Fix inconsistency between the TXD descriptor and the used buffer that
would cause unexpected logic at mtk_tx_unmap() during skb housekeeping.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 14e1bd1..48ba617 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -613,7 +613,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
struct mtk_mac *mac = netdev_priv(dev);
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
-   struct mtk_tx_buf *tx_buf;
+   struct mtk_tx_buf *itx_buf, *tx_buf;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -627,8 +627,8 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
fport = (mac->id + 1) << TX_DMA_FPORT_SHIFT;
txd4 |= fport;
 
-   tx_buf = mtk_desc_to_tx_buf(ring, itxd);
-   memset(tx_buf, 0, sizeof(*tx_buf));
+   itx_buf = mtk_desc_to_tx_buf(ring, itxd);
+   memset(itx_buf, 0, sizeof(*itx_buf));
 
if (gso)
txd4 |= TX_DMA_TSO;
@@ -647,9 +647,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
return -ENOMEM;
 
WRITE_ONCE(itxd->txd1, mapped_addr);
-   tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
-   dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
-   dma_unmap_len_set(tx_buf, dma_len0, skb_headlen(skb));
+   itx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
+   dma_unmap_addr_set(itx_buf, dma_addr0, mapped_addr);
+   dma_unmap_len_set(itx_buf, dma_len0, skb_headlen(skb));
 
/* TX SG offload */
txd = itxd;
@@ -685,10 +685,9 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
   last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, fport);
 
-   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf = mtk_desc_to_tx_buf(ring, txd);
memset(tx_buf, 0, sizeof(*tx_buf));
-
+   tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
tx_buf->flags |= MTK_TX_FLAGS_PAGE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
dma_unmap_len_set(tx_buf, dma_len0, frag_map_size);
@@ -698,7 +697,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
}
 
/* store skb to cleanup */
-   tx_buf->skb = skb;
+   itx_buf->skb = skb;
 
WRITE_ONCE(itxd->txd4, txd4);
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
-- 
1.9.1



[PATCH v2 net 0/2] Fix crash caused by reporting inconsistent skb->len to BQL

2017-04-13 Thread sean.wang
From: Sean Wang 

Changes since v1:
- fix inconsistent enumeration which easily causes the potential bug

The series fixes kernel BUG caused by inconsistent SKB length reported
into BQL. The reason for inconsistent length comes from hardware BUG which
results in different port number carried on the TXD within the lifecycle of
SKB. So patch 2) is proposed for use a software way to track which port
the SKB involving instead of hardware way. And patch 1) is given for another
issue I found which causes TXD and SKB inconsistency that is not expected
in the initial logic, so it is also being corrected it in the series.

The log for the kernel BUG caused by the issue is posted as below.

[  120.825955] kernel BUG at ... lib/dynamic_queue_limits.c:26!
[  120.837684] Internal error: Oops - BUG: 0 [#1] SMP ARM
[  120.842778] Modules linked in:
[  120.845811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.11.0-rc1-191576-gdbcef47 #35
[  120.853488] Hardware name: Mediatek Cortex-A7 (Device Tree)
[  120.859012] task: c1007480 task.stack: c100
[  120.863510] PC is at dql_completed+0x108/0x17c
[  120.867915] LR is at 0x46
[  120.870512] pc : []lr : [<0046>]psr: 8113
[  120.870512] sp : c1001d58  ip : c1001d80  fp : c1001d7c
[  120.881895] r10: 003e  r9 : df6b3400  r8 : 0ed86506
[  120.887075] r7 : 0001  r6 : 0001  r5 : 0ed8654c  r4 : df0135d8
[  120.893546] r3 : 0001  r2 : df016800  r1 : fece  r0 : df6b3480
[  120.900018] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  120.907093] Control: 10c5387d  Table: 9e27806a  DAC: 0051
[  120.912789] Process swapper/0 (pid: 0, stack limit = 0xc1000218)
[  120.918744] Stack: (0xc1001d58 to 0xc1002000)



121.085331] 1fc0:  c0a52a28  c10855d4 c1003c58 c0a52a24 
c100885c 8000406a
[  121.093444] 1fe0: 410fc073   c1001ff8 8000807c c0a009cc 
 
[  121.101575] [] (dql_completed) from [] 
(mtk_napi_tx+0x1d0/0x37c)
[  121.109263] [] (mtk_napi_tx) from [] 
(net_rx_action+0x24c/0x3b8)
[  121.116951] [] (net_rx_action) from [] 
(__do_softirq+0xe4/0x35c)
[  121.124638] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x150)
[  121.131895] [] (irq_exit) from [] 
(__handle_domain_irq+0x70/0xc4)
[  121.139666] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x9c)
[  121.147953] [] (gic_handle_irq) from [] 
(__irq_svc+0x6c/0x90)
[  121.155373] Exception stack(0xc1001ef8 to 0xc1001f40)

Sean Wang (2):
  net: ethernet: mediatek: fix inconsistency between TXD and the used
buffer
  net: ethernet: mediatek: fix inconsistency of port number carried in
TXD

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 31 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 ---
 2 files changed, 26 insertions(+), 17 deletions(-)

-- 
1.9.1



Re: [PATCH v2 07/22] ARM: dts: imx: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Shawn Guo
On Thu, Apr 13, 2017 at 03:28:24PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
> 
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
> 
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
> 
> Signed-off-by: Javier Martinez Canillas 

I wouldn't apply it before driver and bindings change get accepted.
Ping me when that happens.

Shawn

> ---
> 
> Changes in v2: None
> 
>  arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 2 +-
>  arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi   | 2 +-
>  arch/arm/boot/dts/imx28-evk.dts   | 2 +-
>  arch/arm/boot/dts/imx53-tqma53.dtsi   | 2 +-
>  arch/arm/boot/dts/imx6q-cm-fx6.dts| 2 +-
>  arch/arm/boot/dts/imx6q-utilite-pro.dts   | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> index 4f3e0f473581..61e741092efa 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
> @@ -40,7 +40,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi 
> b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> index 82fec935ce83..5b6b651af18f 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
> @@ -193,7 +193,7 @@
>   status = "okay";
>  
>   at24@52 {
> - compatible = "at,24c32";
> + compatible = "at,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x52>;
>   };
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index a5ba669b4eaa..5ab990ac36b4 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -203,7 +203,7 @@
>   };
>  
>   at24@51 {
> - compatible = "at24,24c32";
> + compatible = "at24,24c32","atmel,24c32";
>   pagesize = <32>;
>   reg = <0x51>;
>   };
> diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi 
> b/arch/arm/boot/dts/imx53-tqma53.dtsi
> index 85972f2201c2..c8bc0522a1e9 100644
> --- a/arch/arm/boot/dts/imx53-tqma53.dtsi
> +++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
> @@ -272,7 +272,7 @@
>   };
>  
>   eeprom: 24c64@50 {
> - compatible = "at,24c64";
> + compatible = "at,24c64","atmel,24c64";
>   pagesize = <32>;
>   reg = <0x50>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts 
> b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 66cac5328b86..8cf478c67f83 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -215,7 +215,7 @@
>   clock-frequency = <10>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts 
> b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 69bdd82ce21f..644889d813d0 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -128,7 +128,7 @@
>   #size-cells = <0>;
>  
>   eeprom@50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02","atmel,24c02";
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> -- 
> 2.9.3
> 


[lkp-robot] [locking/ww] 57dd924e54: BUG:soft_lockup-CPU##stuck_for#s

2017-04-13 Thread kernel test robot

FYI, we noticed the following commit:

commit: 57dd924e541a98219bf3a508623db2e0c07e75a7 ("locking/ww-mutex: Limit 
stress test to 2 seconds")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 44fe84459f | 57dd924e54 |
+--+++
| boot_successes   | 0  | 0  |
| boot_failures| 8  | 8  |
| INFO:task_blocked_for_more_than#seconds  | 8  ||
| calltrace:debug_show_all_locks   | 8  ||
| calltrace:ww_mutex_lock_slow | 7  ||
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 8  ||
| calltrace:stress_inorder_work| 1  ||
| IP-Config:Auto-configuration_of_network_failed   | 0  | 4  |
| BUG:soft_lockup-CPU##stuck_for#s | 0  | 4  |
| Kernel_panic-not_syncing:softlockup:hung_tasks   | 0  | 4  |
+--+++



[  273.632796] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[swapper/0:1]
[  273.675540] irq event stamp: 4865008
[  273.685130] hardirqs last  enabled at (4865007): [] 
restore_regs_and_iret+0x0/0x1d
[  273.698804] hardirqs last disabled at (4865008): [] 
apic_timer_interrupt+0x98/0xb0
[  273.712354] softirqs last  enabled at (4865006): [] 
__do_softirq+0x1cf/0x22a
[  273.725144] softirqs last disabled at (4864999): [] 
irq_exit+0x56/0xa6
[  273.737170] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.11.0-rc2-00029-g57dd924 #1
[  273.748511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  273.763553] task: 89a4bae9c040 task.stack: 89a4baea
[  273.772653] RIP: 0010:erase_augmented+0x79/0x23b
[  273.781081] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  273.792428] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  273.802992] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  273.813680] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  273.824245] R10:  R11: 89a4bae9c768 R12: 
[  273.834880] R13: 91ce7a38 R14: 91ce7a39 R15: 91ce8200
[  273.845602] FS:  () GS:89a4bbc0() 
knlGS:
[  273.857595] CS:  0010 DS:  ES:  CR0: 80050033
[  273.884265] CR2:  CR3: 0d419000 CR4: 06a0
[  273.894885] Call Trace:
[  273.898736]  rbtree_test_init+0x1c3/0x27f
[  273.904839]  ? irq_poll_setup+0x96/0x96
[  273.910698]  ? set_debug_rodata+0x20/0x20
[  273.916791]  do_one_initcall+0xa2/0x17c
[  273.922687]  ? set_debug_rodata+0x20/0x20
[  273.928744]  kernel_init_freeable+0x202/0x2a3
[  273.935363]  ? rest_init+0x16d/0x16d
[  273.940809]  kernel_init+0xf/0x142
[  273.946056]  ? rest_init+0x16d/0x16d
[  273.951528]  ret_from_fork+0x31/0x40
[  273.956974] Code: 45 10 75 0b e8 e5 db e1 ff 4d 89 65 10 eb 17 e8 da db e1 
ff 4d 89 65 08 eb 0c e8 cf db e1 ff 4c 89 25 e7 ca 3b 04 e8 c3 db e1 ff <4d> 85 
e4 74 0e e8 b9 db e1 ff 4d 89 34 24 e9 4e 01 00 00 e8 ab 
[  273.987248] Kernel panic - not syncing: softlockup: hung tasks
[  273.996061] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G L  
4.11.0-rc2-00029-g57dd924 #1
[  274.009087] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  274.024313] Call Trace:
[  274.028133]  
[  274.031381]  dump_stack+0xb1/0x103
[  274.036617]  panic+0xfb/0x2c2
[  274.041180]  watchdog_timer_fn+0x227/0x25a
[  274.047441]  ? __touch_watchdog+0x1c/0x1c
[  274.053526]  hrtimer_run_queues+0x140/0x1e4
[  274.059914]  run_local_timers+0x1e/0x64
[  274.065741]  update_process_times+0x21/0x4d
[  274.072159]  tick_nohz_handler+0xbd/0xf6
[  274.078129]  smp_trace_apic_timer_interrupt+0x62/0x74
[  274.085735]  smp_apic_timer_interrupt+0x9/0xb
[  274.092356]  apic_timer_interrupt+0x9d/0xb0
[  274.098767] RIP: 0010:erase_augmented+0x79/0x23b
[  274.107194] RSP: :89a4baea3e20 EFLAGS: 0296 ORIG_RAX: 
ff10
[  274.118506] RAX:  RBX: 91ce7a38 RCX: 89a4bae9c040
[  274.129096] RDX: 91ce7b50 RSI:  RDI: 91ce7328
[  274.139761] RBP: 89a4baea3e50 R08: 91ce7560 R09: 
[  274.150265] R10:  R11: 89a4bae9c768 R12: 
[  274.160893] R13: fff

Re: [PATCH v9 3/5] mm: function to offer a page block on the free list

2017-04-13 Thread Matthew Wilcox
On Fri, Apr 14, 2017 at 10:30:27AM +0800, Wei Wang wrote:
> OK. What do you think if we add this:
> 
> #if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE)

That's spelled "IS_ENABLED(CONFIG_VIRTIO_BALLOON)", FYI.


Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

2017-04-13 Thread Michael S. Tsirkin
On Fri, Apr 14, 2017 at 10:28:32AM +0800, Wei Wang wrote:
> On 04/14/2017 09:50 AM, Michael S. Tsirkin wrote:
> > On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote:
> > > On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote:
> > > > 2) transfer the guest unused pages to the host so that they
> > > > can be skipped to migrate in live migration.
> > > I don't understand this second bit.  You leave the pages on the free list,
> > > and tell the host they're free.  What's preventing somebody else from
> > > allocating them and using them for something?  Is the guest semi-frozen
> > > at this point with just enough of it running to ask the balloon driver
> > > to do things?
> > There's missing documentation here.
> > 
> > The way things actually work is host sends to guest
> > a request for unused pages and then write-protects all memory.
> > 
> > So guest isn't frozen but any changes will be detected by host.
> > 
> 
> Probably it's better to say " transfer the info about the guest unused pages
> to the host so that the host gets a chance to skip the transfer of the
> unused
> pages during live migration".
> 
> Best,
> Wei

IMHO this would not be helpful.
Most people don't know how does migration work, even if they did
this isn't tied to migration in any way.
It just makes people go "oh it's some virtualization mumbo jumbo".
We want people to be able to review and for that
interfaces need to be separate from the implementation.

IOW we must document what the interface promises not how it's used.


The promise is that pages have been unused at some time between when
host sent command and when guest completed it.  Host uses that by
tracking memory changes and then discarding changes made to pages
it gets from guest before it sent the command.

Say that and drop all mention of transfer, migration etc.

-- 
MST


Re: USB Type-C Port Manager API concern

2017-04-13 Thread Guenter Roeck

On 04/09/2017 02:05 PM, Mats Karrman wrote:

On 04/09/2017 05:16 PM, Guenter Roeck wrote:


Hi Mats,

On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote:

I'm working on a tcpi driver and have some concern about the tcpm api.
The tcpm_register_port() is typically called from the probe function of
tcpi driver where the tcpm_port reference returned is stored in the
driver private data. The problem I ran into is that tcpm_register_port()
calls back to the not yet fully initialized tcpi driver, causing null-
pointer dereferences. This could of course be solved by extra logic in
the tcpi driver but I think it would be more elegant if the registration
of a port could be free of premature callbacks. E.g. it could be required
that the tcpi driver probe called tcpm_tcpc_reset() once it's done
initializing or the necessary data could be supplied in the call to
tcpm_register_port().
What do you think?

Let me think about it. In theory it should be possible to avoid callbacks into
the underlying driver until after the return from the registration code, but
that would still be racy if the underlying driver is not ready.

Basic problem seems to be that an API in general assumes that the caller is
ready to serve it once it registers itself. It is kind of unusual to have two
calls, one to register the driver and one to tell the infrastructure that it
is ready (which I assume your reset call would do). Ultimately this means
that the tcpm driver would have to have additional logic to identify if the
underlying driver is ready to handle callbacks.

Can you delay tcpm registration until after the underlying driver is ready,
ie typically to the end of its probe function ? Or am I misunderstanding
your problem ?


The problem I had was that I was trying to pull the same trick that you do ;)
I.e. the probe function calls tcpm_register_port() that is calling back
to the driver that was trying to call back to tcpm, just that the call to
tcpm_register_port() has not yet returned so the pointer to tcpm_port in the
driver data structure was still null.

I was able to fix the issue by commenting out the call to tcpm_init() at the
end of tcpm_register_port() and instead call ("your") tcpm_tcpc_reset(), that
currently does nothing but calling tcpm_init(), after I'm done.

Even though I'm not overly excited about the tcpm register function calling back
to the driver I don't think my fix is much better. I should live by my own words
and refrain from calling back to tcpm until registration has finished...


Problem is that I can't even defer the call to tcpm_init(), or for that matter 
any
other call into the low level driver code, into the worker, since there is still
no guarantee that the low level driver is "done" with its initialization. The 
only
real solution I can think of is that the low level driver should not use the 
pointer
to tcpm_port in any of its callback functions.

Overall I think there is an assumption in any API that any callback functions 
provided
in a registration call can immediately be called. Otherwise any API would be in 
trouble.
Can you modify your code to not require the port pointer in its callback 
functions ?

Thanks,
Guenter



[PATCH] regulator: vctrl: Fix out of bounds array access for vctrl->vtable

2017-04-13 Thread Axel Lin
Current code only allocates rdesc->n_voltages entries for vctrl->vtable.
Thus use rdesc->n_voltages instead of n_voltages in the for loop.

While at it, also switch to use devm_kcalloc instead of devm_kmalloc_array
+ __GFP_ZERO flag and fix the argument order.

Signed-off-by: Axel Lin 
---
 drivers/regulator/vctrl-regulator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/vctrl-regulator.c 
b/drivers/regulator/vctrl-regulator.c
index 6baadef..78de002 100644
--- a/drivers/regulator/vctrl-regulator.c
+++ b/drivers/regulator/vctrl-regulator.c
@@ -345,9 +345,9 @@ static int vctrl_init_vtable(struct platform_device *pdev)
return -EINVAL;
}
 
-   vctrl->vtable = devm_kmalloc_array(
-   &pdev->dev, sizeof(struct vctrl_voltage_table),
-   rdesc->n_voltages, GFP_KERNEL | __GFP_ZERO);
+   vctrl->vtable = devm_kcalloc(&pdev->dev, rdesc->n_voltages,
+sizeof(struct vctrl_voltage_table),
+GFP_KERNEL);
if (!vctrl->vtable)
return -ENOMEM;
 
@@ -371,7 +371,7 @@ static int vctrl_init_vtable(struct platform_device *pdev)
 NULL);
 
/* pre-calculate OVP-safe downward transitions */
-   for (i = n_voltages - 1; i > 0; i--) {
+   for (i = rdesc->n_voltages - 1; i > 0; i--) {
int j;
int ovp_min_uV = (vctrl->vtable[i].out *
  (100 - vctrl->ovp_threshold)) / 100;
-- 
2.9.3



Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

2017-04-13 Thread Guenter Roeck

On 04/13/2017 03:53 PM, Moritz Fischer wrote:

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck  wrote:

On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:

From: Moritz Fischer 

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.



Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?


This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs


Hmm - weird. I thought I saw it implemented for those, but I must have been
struck by lightning or something. Let me check with Gwendal to see how
this (ie its use from iio) is supposed to work on non-LPC systems.

Guenter


emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





[PATCH v2 15/15] [media] cxd2880 : Update MAINTAINERS file for CXD2880 driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This is MAINTAINERS file update about the driver for
the Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdd5350fe261..62543a76d6bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8042,6 +8042,15 @@ T:   git git://linuxtv.org/media_tree.git
 S: Supported
 F: drivers/media/dvb-frontends/cxd2841er*
 
+MEDIA DRIVERS FOR CXD2880
+M: Yasunari Takiguchi 
+L: linux-me...@vger.kernel.org
+W: http://linuxtv.org/
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: drivers/media/dvb-frontends/cxd2880/*
+F: drivers/media/spi/cxd2880*
+
 MEDIA DRIVERS FOR HORUS3A
 M: Sergey Kozlov 
 M: Abylay Ospan 
-- 
2.11.0



[PATCH v2 14/15] [media] cxd2880: Add all Kconfig files for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This is the Kconfig files of driver for
the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/Kconfig |  2 ++
 drivers/media/dvb-frontends/cxd2880/Kconfig |  6 ++
 drivers/media/spi/Kconfig   | 14 ++
 3 files changed, 22 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/Kconfig

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index e8c6554a47aa..3a3a7129a150 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -518,6 +518,8 @@ config DVB_GP8PSK_FE
depends on DVB_CORE
default DVB_USB_GP8PSK
 
+source "drivers/media/dvb-frontends/cxd2880/Kconfig"
+
 comment "DVB-C (cable) frontends"
depends on DVB_CORE
 
diff --git a/drivers/media/dvb-frontends/cxd2880/Kconfig 
b/drivers/media/dvb-frontends/cxd2880/Kconfig
new file mode 100644
index ..36b8b6f7c4f7
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/Kconfig
@@ -0,0 +1,6 @@
+config DVB_CXD2880
+   tristate "Sony CXD2880 DVB-T2/T tuner + demodulator"
+   depends on DVB_CORE && SPI
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y when you want to support this frontend.
\ No newline at end of file
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
index a21f5a39a440..b07ac86fc53c 100644
--- a/drivers/media/spi/Kconfig
+++ b/drivers/media/spi/Kconfig
@@ -12,3 +12,17 @@ config VIDEO_GS1662
 endmenu
 
 endif
+
+if SPI
+menu "Media SPI Adapters"
+
+config CXD2880_SPI_DRV
+   tristate "Sony CXD2880 SPI support"
+   depends on DVB_CORE && SPI
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ Choose if you would like to have SPI interface support for Sony 
CXD2880.
+
+endmenu
+
+endif
-- 
2.11.0



[PATCH v2 13/15] [media] cxd2880: Add all Makefile files for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This is the Makefile files of driver
for the Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/Makefile |  1 +
 drivers/media/dvb-frontends/cxd2880/Makefile | 21 +
 drivers/media/spi/Makefile   |  5 +
 3 files changed, 27 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/Makefile

diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index 3fccaf34ef52..d298c7954699 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -126,3 +126,4 @@ obj-$(CONFIG_DVB_HORUS3A) += horus3a.o
 obj-$(CONFIG_DVB_ASCOT2E) += ascot2e.o
 obj-$(CONFIG_DVB_HELENE) += helene.o
 obj-$(CONFIG_DVB_ZD1301_DEMOD) += zd1301_demod.o
+obj-$(CONFIG_DVB_CXD2880) += cxd2880/
diff --git a/drivers/media/dvb-frontends/cxd2880/Makefile 
b/drivers/media/dvb-frontends/cxd2880/Makefile
new file mode 100644
index ..2672c4a3d65c
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/Makefile
@@ -0,0 +1,21 @@
+cxd2880-objs := cxd2880_common.o \
+   cxd2880_devio_spi.o \
+   cxd2880_integ.o \
+   cxd2880_integ_dvbt2.o \
+   cxd2880_integ_dvbt.o \
+   cxd2880_io.o \
+   cxd2880_spi_device.o \
+   cxd2880_stopwatch_port.o \
+   cxd2880_tnrdmd.o \
+   cxd2880_tnrdmd_dvbt2.o \
+   cxd2880_tnrdmd_dvbt2_mon.o \
+   cxd2880_tnrdmd_dvbt.o \
+   cxd2880_tnrdmd_dvbt_mon.o\
+   cxd2880_tnrdmd_mon.o\
+   cxd2880_math.o \
+   cxd2880_top.o
+
+obj-$(CONFIG_DVB_CXD2880) += cxd2880.o
+
+ccflags-y += -Idrivers/media/dvb-core
+ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
index ea64013d16cc..40e0f88d9f6c 100644
--- a/drivers/media/spi/Makefile
+++ b/drivers/media/spi/Makefile
@@ -1 +1,6 @@
 obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
+obj-$(CONFIG_CXD2880_SPI_DRV) += cxd2880-spi.o
+
+ccflags-y += -Idrivers/media/dvb-core
+ccflags-y += -Idrivers/media/dvb-frontends
+ccflags-y += -Idrivers/media/dvb-frontends/cxd2880
\ No newline at end of file
-- 
2.11.0



[PATCH v2 12/15] [media] cxd2880: Add DVB-T2 monitor and integration layer functions

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Provide monitor and integration layer functions (DVB-T2)
for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c|  311 +++
 .../dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h|   64 +
 .../cxd2880/cxd2880_tnrdmd_dvbt2_mon.c | 2523 
 .../cxd2880/cxd2880_tnrdmd_dvbt2_mon.h |  170 ++
 4 files changed, 3068 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h
 create mode 100644 
drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.c
 create mode 100644 
drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
new file mode 100644
index ..1d60b9c236d8
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
@@ -0,0 +1,311 @@
+/*
+ * cxd2880_integ_dvbt2.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * integration layer functions for DVB-T2
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "cxd2880_tnrdmd_dvbt2.h"
+#include "cxd2880_tnrdmd_dvbt2_mon.h"
+#include "cxd2880_integ_dvbt2.h"
+
+static enum cxd2880_ret dvbt2_wait_demod_lock(struct cxd2880_tnrdmd *tnr_dmd,
+ enum cxd2880_dvbt2_profile
+ profile);
+
+static enum cxd2880_ret dvbt2_wait_l1_post_lock(struct cxd2880_tnrdmd 
*tnr_dmd);
+
+enum cxd2880_ret cxd2880_integ_dvbt2_tune(struct cxd2880_tnrdmd *tnr_dmd,
+ struct cxd2880_dvbt2_tune_param
+ *tune_param)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+
+   if ((!tnr_dmd) || (!tune_param))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnr_dmd->diver_mode == CXD2880_TNRDMD_DIVERMODE_SUB)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if ((tnr_dmd->state != CXD2880_TNRDMD_STATE_SLEEP) &&
+   (tnr_dmd->state != CXD2880_TNRDMD_STATE_ACTIVE))
+   return CXD2880_RESULT_ERROR_SW_STATE;
+
+   cxd2880_atomic_set(&tnr_dmd->cancel, 0);
+
+   if ((tune_param->bandwidth != CXD2880_DTV_BW_1_7_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_5_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_6_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_7_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_8_MHZ)) {
+   return CXD2880_RESULT_ERROR_NOSUPPORT;
+   }
+
+   if ((tune_param->profile != CXD2880_DVBT2_PROFILE_BASE) &&
+   (tune_param->profile != CXD2880_DVBT2_PROFILE_LITE))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   ret = cxd2880_tnrdmd_dvbt2_tune1(tnr_dmd, tune_param);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   CXD2880_SLEEP(CXD2880_TNRDMD_WAIT_AGC_STABLE);
+
+   ret = cxd2880_tnrdmd_dvbt2_tune2(tnr_dmd, tune_param);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret = dvbt2_wait_demod_lock(tnr_dmd, tune_param->profile);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret = cxd2880_tnrdmd_dvbt2_diver_fef_setting(tnr_dmd);
+   if (ret == CXD2880_RESULT_ERROR_HW_STATE)
+   return CXD2880_RESULT_ERROR_UNLOCK;
+   else if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret = dvbt2_wait_l1_post_lock(tnr_dmd);
+   if (ret != CXD2880_RESULT_OK)

[PATCH v2 11/15] [media] cxd2880: Add DVB-T2 control functions for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Provide definitions, interfaces and functions needed for DVB-T2
of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../media/dvb-frontends/cxd2880/cxd2880_dvbt2.h|  402 ++
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.c   | 1309 
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.h   |   82 ++
 3 files changed, 1793 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt2.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt2.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt2.h
new file mode 100644
index ..1870398cba9d
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt2.h
@@ -0,0 +1,402 @@
+/*
+ * cxd2880_dvbt2.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * DVB-T2 related definitions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#ifndef CXD2880_DVBT2_H
+#define CXD2880_DVBT2_H
+
+#include "cxd2880_common.h"
+
+enum cxd2880_dvbt2_profile {
+   CXD2880_DVBT2_PROFILE_BASE,
+   CXD2880_DVBT2_PROFILE_LITE,
+   CXD2880_DVBT2_PROFILE_ANY
+};
+
+enum cxd2880_dvbt2_version {
+   CXD2880_DVBT2_V111,
+   CXD2880_DVBT2_V121,
+   CXD2880_DVBT2_V131
+};
+
+enum cxd2880_dvbt2_s1 {
+   CXD2880_DVBT2_S1_BASE_SISO = 0x00,
+   CXD2880_DVBT2_S1_BASE_MISO = 0x01,
+   CXD2880_DVBT2_S1_NON_DVBT2 = 0x02,
+   CXD2880_DVBT2_S1_LITE_SISO = 0x03,
+   CXD2880_DVBT2_S1_LITE_MISO = 0x04,
+   CXD2880_DVBT2_S1_RSVD3 = 0x05,
+   CXD2880_DVBT2_S1_RSVD4 = 0x06,
+   CXD2880_DVBT2_S1_RSVD5 = 0x07,
+   CXD2880_DVBT2_S1_UNKNOWN = 0xFF
+};
+
+enum cxd2880_dvbt2_base_s2 {
+   CXD2880_DVBT2_BASE_S2_M2K_G_ANY = 0x00,
+   CXD2880_DVBT2_BASE_S2_M8K_G_DVBT = 0x01,
+   CXD2880_DVBT2_BASE_S2_M4K_G_ANY = 0x02,
+   CXD2880_DVBT2_BASE_S2_M1K_G_ANY = 0x03,
+   CXD2880_DVBT2_BASE_S2_M16K_G_ANY = 0x04,
+   CXD2880_DVBT2_BASE_S2_M32K_G_DVBT = 0x05,
+   CXD2880_DVBT2_BASE_S2_M8K_G_DVBT2 = 0x06,
+   CXD2880_DVBT2_BASE_S2_M32K_G_DVBT2 = 0x07,
+   CXD2880_DVBT2_BASE_S2_UNKNOWN = 0xFF
+};
+
+enum cxd2880_dvbt2_lite_s2 {
+   CXD2880_DVBT2_LITE_S2_M2K_G_ANY = 0x00,
+   CXD2880_DVBT2_LITE_S2_M8K_G_DVBT = 0x01,
+   CXD2880_DVBT2_LITE_S2_M4K_G_ANY = 0x02,
+   CXD2880_DVBT2_LITE_S2_M16K_G_DVBT2 = 0x03,
+   CXD2880_DVBT2_LITE_S2_M16K_G_DVBT = 0x04,
+   CXD2880_DVBT2_LITE_S2_RSVD1 = 0x05,
+   CXD2880_DVBT2_LITE_S2_M8K_G_DVBT2 = 0x06,
+   CXD2880_DVBT2_LITE_S2_RSVD2 = 0x07,
+   CXD2880_DVBT2_LITE_S2_UNKNOWN = 0xFF
+};
+
+enum cxd2880_dvbt2_guard {
+   CXD2880_DVBT2_G1_32 = 0x00,
+   CXD2880_DVBT2_G1_16 = 0x01,
+   CXD2880_DVBT2_G1_8 = 0x02,
+   CXD2880_DVBT2_G1_4 = 0x03,
+   CXD2880_DVBT2_G1_128 = 0x04,
+   CXD2880_DVBT2_G19_128 = 0x05,
+   CXD2880_DVBT2_G19_256 = 0x06,
+   CXD2880_DVBT2_G_RSVD1 = 0x07,
+   CXD2880_DVBT2_G_UNKNOWN = 0xFF
+};
+
+enum cxd2880_dvbt2_mode {
+   CXD2880_DVBT2_M2K = 0x00,
+   CXD2880_DVBT2_M8K = 0x01,
+   CXD2880_DVBT2_M4K = 0x02,
+   CXD2880_DVBT2_M1K = 0x03,
+   CXD2880_DVBT2_M16K = 0x04,
+   CXD2880_DVBT2_M32K = 0x05,
+   CXD2880_DVBT2_M_RSVD1 = 0x06,
+   CXD2880_DVBT2_M_RSVD2 = 0x07
+};
+
+enum cxd2880_dvbt2_bw {
+   CXD2880_DVBT2_BW_8 = 0x00,
+   CXD2880_DVBT2_BW_7 = 0x01,
+   CXD2880_DVBT2_BW_6 = 0x02,
+   CXD2880_DVBT2_BW_5 = 0x03,
+   CXD2880_DVBT2_BW_10 = 0x04,
+   CXD2880_DVBT2_BW_1_7 = 0x05,
+   CXD2880_DVBT2_BW

[PATCH v2 10/15] [media] cxd2880: Add DVB-T monitor and integration layer functions

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Provide monitor and integration layer functions (DVB-T)
for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../dvb-frontends/cxd2880/cxd2880_integ_dvbt.c |  197 
 .../dvb-frontends/cxd2880/cxd2880_integ_dvbt.h |   58 +
 .../cxd2880/cxd2880_tnrdmd_dvbt_mon.c  | 1190 
 .../cxd2880/cxd2880_tnrdmd_dvbt_mon.h  |  106 ++
 4 files changed, 1551 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h
 create mode 100644 
drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.c
 create mode 100644 
drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
new file mode 100644
index ..43b7da69fc6d
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
@@ -0,0 +1,197 @@
+/*
+ * cxd2880_integ_dvbt.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * integration layer functions for DVB-T
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "cxd2880_tnrdmd_dvbt.h"
+#include "cxd2880_integ_dvbt.h"
+
+static enum cxd2880_ret dvbt_wait_demod_lock(struct cxd2880_tnrdmd *tnr_dmd);
+
+enum cxd2880_ret cxd2880_integ_dvbt_tune(struct cxd2880_tnrdmd *tnr_dmd,
+struct cxd2880_dvbt_tune_param
+*tune_param)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+
+   if ((!tnr_dmd) || (!tune_param))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnr_dmd->diver_mode == CXD2880_TNRDMD_DIVERMODE_SUB)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if ((tnr_dmd->state != CXD2880_TNRDMD_STATE_SLEEP) &&
+   (tnr_dmd->state != CXD2880_TNRDMD_STATE_ACTIVE))
+   return CXD2880_RESULT_ERROR_SW_STATE;
+
+   cxd2880_atomic_set(&tnr_dmd->cancel, 0);
+
+   if ((tune_param->bandwidth != CXD2880_DTV_BW_5_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_6_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_7_MHZ) &&
+   (tune_param->bandwidth != CXD2880_DTV_BW_8_MHZ)) {
+   return CXD2880_RESULT_ERROR_NOSUPPORT;
+   }
+
+   ret = cxd2880_tnrdmd_dvbt_tune1(tnr_dmd, tune_param);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   CXD2880_SLEEP(CXD2880_TNRDMD_WAIT_AGC_STABLE);
+
+   ret = cxd2880_tnrdmd_dvbt_tune2(tnr_dmd, tune_param);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret = dvbt_wait_demod_lock(tnr_dmd);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   return ret;
+}
+
+enum cxd2880_ret cxd2880_integ_dvbt_wait_ts_lock(struct cxd2880_tnrdmd 
*tnr_dmd)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+   enum cxd2880_tnrdmd_lock_result lock =
+   CXD2880_TNRDMD_LOCK_RESULT_NOTDETECT;
+   struct cxd2880_stopwatch timer;
+   u8 continue_wait = 1;
+   u32 elapsed = 0;
+
+   if (!tnr_dmd)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnr_dmd->diver_mode == CXD2880_TNRDMD_DIVERMODE_SUB)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnr_dmd->state != CXD2880_TNRDMD_STATE_ACTIVE)
+   return CXD2880_RESULT_ERROR_SW_STATE;
+
+   ret = cxd2880_stopwatch_start(&timer);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   for (;;) {
+   ret = cxd2880_stopwatch_elapsed(&timer, &elapsed);
+  

[PATCH v2 09/15] [media] cxd2880: Add DVB-T control functions the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Provide definitions, interfaces and functions needed for DVB-T
of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h |   91 ++
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c| 1072 
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.h|   62 ++
 3 files changed, 1225 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h
new file mode 100644
index ..345c094760d2
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h
@@ -0,0 +1,91 @@
+/*
+ * cxd2880_dvbt.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * DVB-T related definitions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#ifndef CXD2880_DVBT_H
+#define CXD2880_DVBT_H
+
+#include "cxd2880_common.h"
+
+enum cxd2880_dvbt_constellation {
+   CXD2880_DVBT_CONSTELLATION_QPSK,
+   CXD2880_DVBT_CONSTELLATION_16QAM,
+   CXD2880_DVBT_CONSTELLATION_64QAM,
+   CXD2880_DVBT_CONSTELLATION_RESERVED_3
+};
+
+enum cxd2880_dvbt_hierarchy {
+   CXD2880_DVBT_HIERARCHY_NON,
+   CXD2880_DVBT_HIERARCHY_1,
+   CXD2880_DVBT_HIERARCHY_2,
+   CXD2880_DVBT_HIERARCHY_4
+};
+
+enum cxd2880_dvbt_coderate {
+   CXD2880_DVBT_CODERATE_1_2,
+   CXD2880_DVBT_CODERATE_2_3,
+   CXD2880_DVBT_CODERATE_3_4,
+   CXD2880_DVBT_CODERATE_5_6,
+   CXD2880_DVBT_CODERATE_7_8,
+   CXD2880_DVBT_CODERATE_RESERVED_5,
+   CXD2880_DVBT_CODERATE_RESERVED_6,
+   CXD2880_DVBT_CODERATE_RESERVED_7
+};
+
+enum cxd2880_dvbt_guard {
+   CXD2880_DVBT_GUARD_1_32,
+   CXD2880_DVBT_GUARD_1_16,
+   CXD2880_DVBT_GUARD_1_8,
+   CXD2880_DVBT_GUARD_1_4
+};
+
+enum cxd2880_dvbt_mode {
+   CXD2880_DVBT_MODE_2K,
+   CXD2880_DVBT_MODE_8K,
+   CXD2880_DVBT_MODE_RESERVED_2,
+   CXD2880_DVBT_MODE_RESERVED_3
+};
+
+enum cxd2880_dvbt_profile {
+   CXD2880_DVBT_PROFILE_HP = 0,
+   CXD2880_DVBT_PROFILE_LP
+};
+
+struct cxd2880_dvbt_tpsinfo {
+   enum cxd2880_dvbt_constellation constellation;
+   enum cxd2880_dvbt_hierarchy hierarchy;
+   enum cxd2880_dvbt_coderate rate_hp;
+   enum cxd2880_dvbt_coderate rate_lp;
+   enum cxd2880_dvbt_guard guard;
+   enum cxd2880_dvbt_mode mode;
+   u8 fnum;
+   u8 length_indicator;
+   u16 cell_id;
+   u8 cell_id_ok;
+   u8 reserved_even;
+   u8 reserved_odd;
+};
+
+#endif
diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c
new file mode 100644
index ..f36cf533ec17
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c
@@ -0,0 +1,1072 @@
+/*
+ * cxd2880_tnrdmd_dvbt.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * control functions for DVB-T
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRE

Re: [PATCH v9 3/5] mm: function to offer a page block on the free list

2017-04-13 Thread Wei Wang

On 04/14/2017 04:02 AM, Andrew Morton wrote:

On Thu, 13 Apr 2017 17:35:06 +0800 Wei Wang  wrote:


Add a function to find a page block on the free list specified by the
caller. Pages from the page block may be used immediately after the
function returns. The caller is responsible for detecting or preventing
the use of such pages.

...

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4498,6 +4498,93 @@ void show_free_areas(unsigned int filter)
show_swap_cache_info();
  }
  
+/**

+ * Heuristically get a page block in the system that is unused.
+ * It is possible that pages from the page block are used immediately after
+ * inquire_unused_page_block() returns. It is the caller's responsibility
+ * to either detect or prevent the use of such pages.
+ *
+ * The free list to check: zone->free_area[order].free_list[migratetype].
+ *
+ * If the caller supplied page block (i.e. **page) is on the free list, offer
+ * the next page block on the list to the caller. Otherwise, offer the first
+ * page block on the list.
+ *
+ * Return 0 when a page block is found on the caller specified free list.
+ */
+int inquire_unused_page_block(struct zone *zone, unsigned int order,
+ unsigned int migratetype, struct page **page)
+{

Perhaps we can wrap this in the appropriate ifdef so the kernels which
won't be using virtio-balloon don't carry the added overhead.




OK. What do you think if we add this:

#if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE)



Best,
Wei


[PATCH v2 08/15] [media] cxd2880: Add top level of the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This provides the main dvb frontend operation functions
for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/cxd2880/cxd2880_top.c | 1550 +
 1 file changed, 1550 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_top.c

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
new file mode 100644
index ..66d78fb93a13
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
@@ -0,0 +1,1550 @@
+/*
+ * cxd2880_top.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+
+#include "dvb_frontend.h"
+
+#include "cxd2880.h"
+#include "cxd2880_tnrdmd_mon.h"
+#include "cxd2880_tnrdmd_dvbt2_mon.h"
+#include "cxd2880_tnrdmd_dvbt_mon.h"
+#include "cxd2880_integ_dvbt2.h"
+#include "cxd2880_integ_dvbt.h"
+#include "cxd2880_devio_spi.h"
+#include "cxd2880_spi_device.h"
+#include "cxd2880_tnrdmd_driver_version.h"
+
+struct cxd2880_priv {
+   struct cxd2880_tnrdmd tnrdmd;
+   struct spi_device *spi;
+   struct cxd2880_io regio;
+   struct cxd2880_spi_device spi_device;
+   struct cxd2880_spi cxd2880_spi;
+   struct cxd2880_dvbt_tune_param dvbt_tune_param;
+   struct cxd2880_dvbt2_tune_param dvbt2_tune_param;
+   struct mutex *spi_mutex; /* For SPI access exclusive control */
+};
+
+/*
+ * return value conversion table
+ */
+static int return_tbl[] = {
+   0, /* CXD2880_RESULT_OK */
+   -EINVAL,   /* CXD2880_RESULT_ERROR_ARG*/
+   -EIO,  /* CXD2880_RESULT_ERROR_IO */
+   -EPERM,/* CXD2880_RESULT_ERROR_SW_STATE */
+   -EBUSY,/* CXD2880_RESULT_ERROR_HW_STATE */
+   -ETIME,/* CXD2880_RESULT_ERROR_TIMEOUT */
+   -EAGAIN,   /* CXD2880_RESULT_ERROR_UNLOCK */
+   -ERANGE,   /* CXD2880_RESULT_ERROR_RANGE */
+   -EOPNOTSUPP,   /* CXD2880_RESULT_ERROR_NOSUPPORT */
+   -ECANCELED,/* CXD2880_RESULT_ERROR_CANCEL */
+   -EPERM,/* CXD2880_RESULT_ERROR_OTHER */
+   -EOVERFLOW,/* CXD2880_RESULT_ERROR_OVERFLOW */
+   0, /* CXD2880_RESULT_OK_CONFIRM */
+};
+
+static enum cxd2880_ret cxd2880_pre_bit_err_t(
+   struct cxd2880_tnrdmd *tnrdmd, u32 *pre_bit_err,
+   u32 *pre_bit_count)
+{
+   u8 rdata[2];
+
+   if ((!tnrdmd) || (!pre_bit_err) || (!pre_bit_count))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnrdmd->diver_mode == CXD2880_TNRDMD_DIVERMODE_SUB)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (tnrdmd->state != CXD2880_TNRDMD_STATE_ACTIVE)
+   return CXD2880_RESULT_ERROR_SW_STATE;
+
+   if (tnrdmd->sys != CXD2880_DTV_SYS_DVBT)
+   return CXD2880_RESULT_ERROR_SW_STATE;
+
+   if (slvt_freeze_reg(tnrdmd) != CXD2880_RESULT_OK)
+   return CXD2880_RESULT_ERROR_IO;
+
+   if (tnrdmd->io->write_reg(tnrdmd->io, CXD2880_IO_TGT_DMD,
+   0x00, 0x10) != CXD2880_RESULT_OK) {
+   slvt_unfreeze_reg(tnrdmd);
+   return CXD2880_RESULT_ERROR_IO;
+   }
+
+   if (tnrdmd->io->read_regs(tnrdmd->io, CXD2880_IO_TGT_DMD,
+   0x39, rdata, 1) != CXD2880_RESULT_OK) {
+   slvt_unfreeze_reg(tnrdmd);
+   return CXD2880_RESULT_ERROR_IO;
+   }
+
+   if ((rdata[0] & 0x01) == 0) {
+   slvt_unfreeze_reg(tnrdmd);
+   return CXD2880_RESULT_ERROR_HW_STATE;
+   }
+
+   if (tnrdmd->io->read_regs(tnrdmd->io,

Re: RFC: drop the T10 OSD code and its users

2017-04-13 Thread Martin K. Petersen

Christoph,

> The only real user of the T10 OSD protocol, the pNFS object layout
> driver never went to the point of having shipping products, and the
> other two users (osdblk and exofs) were simple example of it's usage.
>
> The code has been mostly unmaintained for years and is getting in the
> way of block / SCSI changes, so I think it's finally time to drop it.

No particular objections from me.

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH v2 07/15] [media] cxd2880: Add integration layer for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

These functions monitor the driver and watch for task completion.
This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../media/dvb-frontends/cxd2880/cxd2880_integ.c| 99 ++
 .../media/dvb-frontends/cxd2880/cxd2880_integ.h| 44 ++
 2 files changed, 143 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_integ.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c
new file mode 100644
index ..5ad6685e2a1d
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c
@@ -0,0 +1,99 @@
+/*
+ * cxd2880_integ.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * integration layer common functions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "cxd2880_tnrdmd.h"
+#include "cxd2880_tnrdmd_mon.h"
+#include "cxd2880_integ.h"
+
+enum cxd2880_ret cxd2880_integ_init(struct cxd2880_tnrdmd *tnr_dmd)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+   struct cxd2880_stopwatch timer;
+   u32 elapsed_time = 0;
+   u8 cpu_task_completed = 0;
+
+   if (!tnr_dmd)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   ret = cxd2880_tnrdmd_init1(tnr_dmd);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret = cxd2880_stopwatch_start(&timer);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   while (1) {
+   ret = cxd2880_stopwatch_elapsed(&timer, &elapsed_time);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   ret =
+   cxd2880_tnrdmd_check_internal_cpu_status(tnr_dmd,
+&cpu_task_completed);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   if (cpu_task_completed)
+   break;
+
+   if (elapsed_time > CXD2880_TNRDMD_WAIT_INIT_TIMEOUT)
+   return CXD2880_RESULT_ERROR_TIMEOUT;
+   ret =
+   cxd2880_stopwatch_sleep(&timer,
+   CXD2880_TNRDMD_WAIT_INIT_INTVL);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+   }
+
+   ret = cxd2880_tnrdmd_init2(tnr_dmd);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   return CXD2880_RESULT_OK;
+}
+
+enum cxd2880_ret cxd2880_integ_cancel(struct cxd2880_tnrdmd *tnr_dmd)
+{
+   if (!tnr_dmd)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   cxd2880_atomic_set(&tnr_dmd->cancel, 1);
+
+   return CXD2880_RESULT_OK;
+}
+
+enum cxd2880_ret cxd2880_integ_check_cancellation(struct cxd2880_tnrdmd
+ *tnr_dmd)
+{
+   if (!tnr_dmd)
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (cxd2880_atomic_read(&tnr_dmd->cancel) != 0)
+   return CXD2880_RESULT_ERROR_CANCEL;
+
+   return CXD2880_RESULT_OK;
+}
diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.h
new file mode 100644
index ..9cfc52dbf9d4
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_integ.h
@@ -0,0 +1,44 @@
+/*
+ * cxd2880_integ.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * integration layer common interface
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
+ *
+ * This program is free software; you can redistribut

Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

2017-04-13 Thread Wei Wang

On 04/14/2017 09:50 AM, Michael S. Tsirkin wrote:

On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote:

On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote:

2) transfer the guest unused pages to the host so that they
can be skipped to migrate in live migration.

I don't understand this second bit.  You leave the pages on the free list,
and tell the host they're free.  What's preventing somebody else from
allocating them and using them for something?  Is the guest semi-frozen
at this point with just enough of it running to ask the balloon driver
to do things?

There's missing documentation here.

The way things actually work is host sends to guest
a request for unused pages and then write-protects all memory.

So guest isn't frozen but any changes will be detected by host.



Probably it's better to say " transfer the info about the guest unused pages
to the host so that the host gets a chance to skip the transfer of the 
unused

pages during live migration".

Best,
Wei


[PATCH v2 06/15] [media] cxd2880: Add tuner part of the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This part of the driver has the main routines to handle
the tuner and demodulator functionality.  The tnrdmd_mon.* files
have monitor functions for the driver.
This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h  |   50 +
 .../media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c   | 3925 
 .../media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h   |  395 ++
 .../cxd2880/cxd2880_tnrdmd_driver_version.h|   29 +
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c |  207 ++
 .../dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.h |   52 +
 6 files changed, 4658 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h
 create mode 100644 
drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_driver_version.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
new file mode 100644
index ..7de098d556fe
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
@@ -0,0 +1,50 @@
+/*
+ * cxd2880_dtv.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * DTV related definitions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#ifndef CXD2880_DTV_H
+#define CXD2880_DTV_H
+
+enum cxd2880_dtv_sys {
+   CXD2880_DTV_SYS_UNKNOWN,
+   CXD2880_DTV_SYS_DVBT,
+   CXD2880_DTV_SYS_DVBT2,
+   CXD2880_DTV_SYS_ISDBT,
+   CXD2880_DTV_SYS_ISDBTSB,
+   CXD2880_DTV_SYS_ISDBTMM_A,
+   CXD2880_DTV_SYS_ISDBTMM_B,
+   CXD2880_DTV_SYS_ANY
+};
+
+enum cxd2880_dtv_bandwidth {
+   CXD2880_DTV_BW_UNKNOWN = 0,
+   CXD2880_DTV_BW_1_7_MHZ = 1,
+   CXD2880_DTV_BW_5_MHZ = 5,
+   CXD2880_DTV_BW_6_MHZ = 6,
+   CXD2880_DTV_BW_7_MHZ = 7,
+   CXD2880_DTV_BW_8_MHZ = 8
+};
+
+#endif
diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
new file mode 100644
index ..286384ae0124
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
@@ -0,0 +1,3925 @@
+/*
+ * cxd2880_tnrdmd.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * common control functions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see 

[PATCH v2 05/15] [media] cxd2880: Add spi device IO routines

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Add functions for initializing, reading and writing to the SPI
device for the Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../dvb-frontends/cxd2880/cxd2880_devio_spi.c  | 147 +
 .../dvb-frontends/cxd2880/cxd2880_devio_spi.h  |  40 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_spi.h  |  51 +++
 .../dvb-frontends/cxd2880/cxd2880_spi_device.c | 130 ++
 .../dvb-frontends/cxd2880/cxd2880_spi_device.h |  45 +++
 5 files changed, 413 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
new file mode 100644
index ..516efade6bf5
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
@@ -0,0 +1,147 @@
+/*
+ * cxd2880_devio_spi.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * I/O interface via SPI
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "cxd2880_devio_spi.h"
+#include "cxd2880_stdlib.h"
+
+#define BURST_WRITE_MAX 128
+
+static enum cxd2880_ret cxd2880_io_spi_read_reg(struct cxd2880_io *io,
+   enum cxd2880_io_tgt tgt,
+   u8 sub_address, u8 *data,
+   u32 size)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+   struct cxd2880_spi *spi = NULL;
+   u8 send_data[6];
+   u8 *read_data_top = data;
+
+   if ((!io) || (!io->if_object) || (!data))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (sub_address + size > 0x100)
+   return CXD2880_RESULT_ERROR_RANGE;
+
+   spi = (struct cxd2880_spi *)(io->if_object);
+
+   if (tgt == CXD2880_IO_TGT_SYS)
+   send_data[0] = 0x0B;
+   else
+   send_data[0] = 0x0A;
+
+   send_data[3] = 0;
+   send_data[4] = 0;
+   send_data[5] = 0;
+
+   while (size > 0) {
+   send_data[1] = sub_address;
+   if (size > 255)
+   send_data[2] = 255;
+   else
+   send_data[2] = (u8)size;
+
+   ret =
+   spi->write_read(spi, send_data, sizeof(send_data),
+   read_data_top, send_data[2]);
+   if (ret != CXD2880_RESULT_OK)
+   return ret;
+
+   sub_address += send_data[2];
+   read_data_top += send_data[2];
+   size -= send_data[2];
+   }
+
+   return ret;
+}
+
+static enum cxd2880_ret cxd2880_io_spi_write_reg(struct cxd2880_io *io,
+enum cxd2880_io_tgt tgt,
+u8 sub_address,
+const u8 *data, u32 size)
+{
+   enum cxd2880_ret ret = CXD2880_RESULT_OK;
+   struct cxd2880_spi *spi = NULL;
+   u8 send_data[BURST_WRITE_MAX + 4];
+   const u8 *write_data_top = data;
+
+   if ((!io) || (!io->if_object) || (!data))
+   return CXD2880_RESULT_ERROR_ARG;
+
+   if (size > BURST_WRITE_MAX)
+   return CXD2880_RESULT_ERROR_OVERFLOW;
+
+   if (sub_address + size > 0x100)
+   

[PATCH v2 04/15] [media] cxd2880: Add math functions for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Provide some math support functions (fixed-point log functions)
for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/cxd2880/cxd2880_math.c | 89 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_math.h | 40 ++
 2 files changed, 129 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.h

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
new file mode 100644
index ..434c827898ff
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
@@ -0,0 +1,89 @@
+/*
+ * cxd2880_math.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * mathmatics functions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "cxd2880_math.h"
+
+#define MAX_BIT_PRECISION5
+#define FRAC_BITMASK   0x1F
+#define LOG2_10_100X332
+#define LOG2_E_100X  144
+
+static const u8 log2_look_up[] = {
+   0, 4,
+   9, 13,
+   17, 21,
+   25, 29,
+   32, 36,
+   39, 43,
+   46, 49,
+   52, 55,
+   58, 61,
+   64, 67,
+   70, 73,
+   75, 78,
+   81, 83,
+   86, 88,
+   91, 93,
+   95, 98
+};
+
+u32 cxd2880_math_log2(u32 x)
+{
+   u8 count = 0;
+   u8 index = 0;
+   u32 xval = x;
+
+   for (x >>= 1; x > 0; x >>= 1)
+   count++;
+
+   x = count * 100;
+
+   if (count > 0) {
+   if (count <= MAX_BIT_PRECISION) {
+   index =
+   (u8)(xval << (MAX_BIT_PRECISION - count)) &
+   FRAC_BITMASK;
+   x += log2_look_up[index];
+   } else {
+   index =
+   (u8)(xval >> (count - MAX_BIT_PRECISION)) &
+   FRAC_BITMASK;
+   x += log2_look_up[index];
+   }
+   }
+
+   return x;
+}
+
+u32 cxd2880_math_log10(u32 x)
+{
+   return ((100 * cxd2880_math_log2(x) + LOG2_10_100X / 2) / LOG2_10_100X);
+}
+
+u32 cxd2880_math_log(u32 x)
+{
+   return ((100 * cxd2880_math_log2(x) + LOG2_E_100X / 2) / LOG2_E_100X);
+}
diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
new file mode 100644
index ..94211835a4ad
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
@@ -0,0 +1,40 @@
+/*
+ * cxd2880_math.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * mathmatics definitions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE P

Re: [PATCH 2/2] xen/arm,arm64: rename __generic_dma_ops to xen_get_dma_ops

2017-04-13 Thread Konrad Rzeszutek Wilk
On Thu, Apr 13, 2017 at 08:48:48PM -0400, Boris Ostrovsky wrote:
> 
> 
> On 04/13/2017 05:04 PM, Stefano Stabellini wrote:
> > Now that __generic_dma_ops is a xen specific function, rename it to
> > xen_get_dma_ops. Change all the call sites appropriately.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: li...@armlinux.org.uk
> > CC: catalin.mari...@arm.com
> > CC: will.dea...@arm.com
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Julien Grall 
> 
> Reviewed-by: Boris Ostrovsky 
> 
> (+Konrad)

Acked-by: Konrad Rzeszutek Wilk 
> 
> 
> > ---
> >  drivers/xen/swiotlb-xen.c   |  8 
> >  include/xen/arm/page-coherent.h | 20 ++--
> >  2 files changed, 14 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index e8cef1a..8dab0d3 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -693,8 +693,8 @@ void xen_swiotlb_unmap_page(struct device *hwdev, 
> > dma_addr_t dev_addr,
> >  unsigned long attrs)
> >  {
> >  #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > -   if (__generic_dma_ops(dev)->mmap)
> > -   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr,
> > +   if (xen_get_dma_ops(dev)->mmap)
> > +   return xen_get_dma_ops(dev)->mmap(dev, vma, cpu_addr,
> > dma_addr, size, attrs);
> >  #endif
> > return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
> > @@ -711,7 +711,7 @@ void xen_swiotlb_unmap_page(struct device *hwdev, 
> > dma_addr_t dev_addr,
> > unsigned long attrs)
> >  {
> >  #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > -   if (__generic_dma_ops(dev)->get_sgtable) {
> > +   if (xen_get_dma_ops(dev)->get_sgtable) {
> >  #if 0
> > /*
> >  * This check verifies that the page belongs to the current domain and
> > @@ -721,7 +721,7 @@ void xen_swiotlb_unmap_page(struct device *hwdev, 
> > dma_addr_t dev_addr,
> > unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
> > BUG_ON (!page_is_ram(bfn));
> >  #endif
> > -   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
> > +   return xen_get_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
> >handle, size, attrs);
> > }
> >  #endif
> > diff --git a/include/xen/arm/page-coherent.h 
> > b/include/xen/arm/page-coherent.h
> > index b0a2bfc..b1b4ecd 100644
> > --- a/include/xen/arm/page-coherent.h
> > +++ b/include/xen/arm/page-coherent.h
> > @@ -5,7 +5,7 @@
> >  #include 
> >  #include 
> > 
> > -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
> > *dev)
> > +static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
> >  {
> > if (dev && dev->archdata.dev_dma_ops)
> > return dev->archdata.dev_dma_ops;
> > @@ -27,13 +27,13 @@ void __xen_dma_sync_single_for_device(struct device 
> > *hwdev,
> >  static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t 
> > size,
> > dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> >  {
> > -   return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, 
> > attrs);
> > +   return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, 
> > attrs);
> >  }
> > 
> >  static inline void xen_free_coherent_pages(struct device *hwdev, size_t 
> > size,
> > void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> >  {
> > -   __generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, 
> > attrs);
> > +   xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
> >  }
> > 
> >  static inline void xen_dma_map_page(struct device *hwdev, struct page 
> > *page,
> > @@ -57,7 +57,7 @@ static inline void xen_dma_map_page(struct device *hwdev, 
> > struct page *page,
> >  * specific function.
> >  */
> > if (local)
> > -   __generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, 
> > dir, attrs);
> > +   xen_get_dma_ops(hwdev)->map_page(hwdev, page, offset, size, 
> > dir, attrs);
> > else
> > __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, 
> > attrs);
> >  }
> > @@ -75,8 +75,8 @@ static inline void xen_dma_unmap_page(struct device 
> > *hwdev, dma_addr_t handle,
> >  * specific function.
> >  */
> > if (pfn_valid(pfn)) {
> > -   if (__generic_dma_ops(hwdev)->unmap_page)
> > -   __generic_dma_ops(hwdev)->unmap_page(hwdev, handle, 
> > size, dir, attrs);
> > +   if (xen_get_dma_ops(hwdev)->unmap_page)
> > +   xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size, 
> > dir, attrs);
> > } else
> > __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> >  }
> > @@ -86,8 +86,8 @@ static inline void xen_dma_sync_single_for_cpu(struct 
> > device *hwdev,
> >  {
> > unsigned long pfn

[PATCH v2 03/15] [media] cxd2880: Add common files for the driver

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

These are common files for the driver for the
Sony CXD2880 DVB-T2/T tuner + demodulator.
These contains helper functions for the driver.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/dvb-frontends/cxd2880/cxd2880.h  | 46 
 .../media/dvb-frontends/cxd2880/cxd2880_common.c   | 84 +
 .../media/dvb-frontends/cxd2880/cxd2880_common.h   | 86 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_io.c   | 68 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_io.h   | 62 
 .../media/dvb-frontends/cxd2880/cxd2880_stdlib.h   | 35 +
 .../dvb-frontends/cxd2880/cxd2880_stopwatch_port.c | 71 ++
 7 files changed, 452 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_stdlib.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_stopwatch_port.c

diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880.h 
b/drivers/media/dvb-frontends/cxd2880/cxd2880.h
new file mode 100644
index ..281f9a784eb5
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880.h
@@ -0,0 +1,46 @@
+/*
+ * cxd2880.h
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver public definitions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#ifndef CXD2880_H
+#define CXD2880_H
+
+struct cxd2880_config {
+   struct spi_device *spi;
+   struct mutex *spi_mutex; /* For SPI access exclusive control */
+};
+
+#if IS_REACHABLE(CONFIG_DVB_CXD2880)
+extern struct dvb_frontend *cxd2880_attach(struct dvb_frontend *fe,
+   struct cxd2880_config *cfg);
+#else
+static inline struct dvb_frontend *cxd2880_attach(struct dvb_frontend *fe,
+   struct cxd2880_config *cfg)
+{
+   pr_warn("%s: driver disabled by Kconfig\n", __func__);
+   return NULL;
+}
+#endif /* CONFIG_DVB_CXD2880 */
+
+#endif /* CXD2880_H */
diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c 
b/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
new file mode 100644
index ..850f3a76b2c7
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
@@ -0,0 +1,84 @@
+/*
+ * cxd2880_common.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * common functions
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have recei

Re: [PATCH v2] scsi: return correct blkprep status code in case scsi_init_io() fails.

2017-04-13 Thread Martin K. Petersen
Johannes Thumshirn  writes:

> When instrumenting the SCSI layer to run into the
> !blk_rq_nr_phys_segments(rq) case the following warning emitted from
> the block layer:

Applied to 4.11/scsi-fixes.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v3] ftrace/x86/32: fix triple fault with graph tracing and suspend-to-ram

2017-04-13 Thread Josh Poimboeuf
On Thu, Apr 13, 2017 at 07:02:36PM -0400, Steven Rostedt wrote:
> On Thu, 13 Apr 2017 17:53:55 -0500
> Josh Poimboeuf  wrote:
> 
> > On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable
> > function graph tracing and then suspend to RAM, it will triple fault and
> > reboot when it resumes.
> > 
> > The first fault happens when booting a secondary CPU:
> > 
> > startup_32_smp()
> >   load_ucode_ap()
> > prepare_ftrace_return()
> >   ftrace_graph_is_dead()
> > (accesses 'kill_ftrace_graph')
> > 
> > The early head_32.S code calls into load_ucode_ap(), which has an an
> > ftrace hook, so it calls prepare_ftrace_return(), which calls
> > ftrace_graph_is_dead(), which tries to access the global
> > 'kill_ftrace_graph' variable with a virtual address, causing a fault
> > because the CPU is still in real mode.
> > 
> > The fix is to add a check in prepare_ftrace_return() to make sure it's
> > running in protected mode before continuing.  The check makes sure the
> > stack pointer is a virtual kernel address.  It's a bit of a hack, but
> > it's not very intrusive and it works well enough.
> > 
> > For reference, here are a few other (more difficult) ways this could
> > have potentially been fixed:
> > 
> > - Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
> >   is enabled.  (No idea what that would break.)
> > 
> > - Track down load_ucode_ap()'s entire callee tree and mark all the
> >   functions 'notrace'.  (Probably not realistic.)
> > 
> > - Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
> >   or __cpu_up(), and ensure that the pause facility can be queried from
> >   real mode.
> > 
> > Reported-by: Paul Menzel 
> > Tested-by: Paul Menzel 
> > Cc: sta...@kernel.org
> > Signed-off-by: Josh Poimboeuf 
> 
> This is pretty much the same thing we were talking about before, right?

Yeah, the same patch from before, now with more tags!

> If so, then:
> 
> Reviewed-by: Steven Rostedt (VMware) 

Thanks!

-- 
Josh


[PATCH v2 02/15] [media] cxd2880-spi: Add support for CXD2008 SPI interface

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This is the SPI adapter part of the driver for the
Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 drivers/media/spi/cxd2880-spi.c | 728 
 1 file changed, 728 insertions(+)
 create mode 100644 drivers/media/spi/cxd2880-spi.c

diff --git a/drivers/media/spi/cxd2880-spi.c b/drivers/media/spi/cxd2880-spi.c
new file mode 100644
index ..82e122349055
--- /dev/null
+++ b/drivers/media/spi/cxd2880-spi.c
@@ -0,0 +1,728 @@
+/*
+ * cxd2880-spi.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * SPI adapter
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions 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; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+
+#include "dvb_demux.h"
+#include "dmxdev.h"
+#include "dvb_frontend.h"
+#include "cxd2880.h"
+
+#define CXD2880_MAX_FILTER_SIZE 32
+#define BURST_WRITE_MAX 128
+#define MAX_TRANS_PACKET 300
+
+struct cxd2880_ts_buf_info {
+   u8 read_ready;
+   u8 almost_full;
+   u8 almost_empty;
+   u8 overflow;
+   u8 underflow;
+   u16 packet_num;
+};
+
+struct cxd2880_pid_config {
+   u8 is_enable;
+   u16 pid;
+};
+
+struct cxd2880_pid_filter_config {
+   u8 is_negative;
+   struct cxd2880_pid_config pid_config[CXD2880_MAX_FILTER_SIZE];
+};
+
+struct cxd2880_dvb_spi {
+   struct dvb_frontend dvb_fe;
+   struct dvb_adapter adapter;
+   struct dvb_demux demux;
+   struct dmxdev dmxdev;
+   struct dmx_frontend dmx_fe;
+   struct task_struct *cxd2880_ts_read_thread;
+   struct spi_device *spi;
+   struct mutex spi_mutex; /* For SPI access exclusive control */
+   int feed_count;
+   int all_pid_feed_count;
+   u8 *ts_buf;
+   struct cxd2880_pid_filter_config filter_config;
+};
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+static int cxd2880_write_spi(struct spi_device *spi, u8 *data, u32 size)
+{
+   struct spi_message msg;
+   struct spi_transfer tx;
+   int ret = 0;
+
+   if ((!spi) || (!data)) {
+   pr_err("%s: invalid arg\n", __func__);
+   return -EINVAL;
+   }
+
+   memset(&tx, 0, sizeof(tx));
+   tx.tx_buf = data;
+   tx.len = size;
+
+   spi_message_init(&msg);
+   spi_message_add_tail(&tx, &msg);
+   ret = spi_sync(spi, &msg);
+
+   return ret;
+}
+
+static int cxd2880_write_reg(struct spi_device *spi,
+   u8 subAddress, const u8 *data, u32 size)
+{
+   u8 send_data[BURST_WRITE_MAX + 4];
+   const u8 *write_data_top = NULL;
+   int ret = 0;
+
+   if ((!spi) || (!data)) {
+   pr_err("%s: invalid arg\n", __func__);
+   return -EINVAL;
+   }
+   if (size > BURST_WRITE_MAX) {
+   pr_err("%s: data size > WRITE_MAX\n", __func__);
+   return -EINVAL;
+   }
+
+   if (subAddress + size > 0x100) {
+   pr_err("%s: out of range\n", __func__);
+   return -EINVAL;
+   }
+
+   send_data[0] = 0x0E;
+   write_data_top = data;
+
+   while (size > 0) {
+   send_data[1] = subAddress;
+   if (size > 255)
+   send_data[2] = 255;
+   else
+   send_data[2] = (u8)size;
+
+   memcpy(&send_data[3], write_data_top, send_data[2]);
+
+   ret = cxd2880_write_spi(spi, send_data, send_data[2] + 3);
+   if (ret) {
+   dev_err(&spi->dev, "%s: write spi failed %d\n",
+   __func__, ret);
+   break;
+   }
+   subAddress += send_data[2];
+   write_data_top += send_data[2];
+   size -= sen

[PATCH v2 01/15] [dt-bindings] [media] Add document file for CXD2880 SPI I/F

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator.
It contains the description of the SPI adapter binding.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---
 .../devicetree/bindings/media/spi/sony-cxd2880.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt

diff --git a/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt 
b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
new file mode 100644
index ..fc5aa263abe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
@@ -0,0 +1,14 @@
+Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter
+
+Required properties:
+- compatible: Should be "sony,cxd2880".
+- reg: SPI chip select number for the device.
+- spi-max-frequency: Maximum bus speed, should be set to <5500> (55MHz).
+
+Example:
+
+cxd2880@0 {
+   compatible = "sony,cxd2880";
+   reg = <0>; /* CE0 */
+   spi-max-frequency = <5500>; /* 55MHz */
+};
-- 
2.11.0



Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

2017-04-13 Thread Michael S. Tsirkin
On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote:
> On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote:
> > 2) transfer the guest unused pages to the host so that they
> > can be skipped to migrate in live migration.
> 
> I don't understand this second bit.  You leave the pages on the free list,
> and tell the host they're free.  What's preventing somebody else from
> allocating them and using them for something?  Is the guest semi-frozen
> at this point with just enough of it running to ask the balloon driver
> to do things?

There's missing documentation here.

The way things actually work is host sends to guest
a request for unused pages and then write-protects all memory.

So guest isn't frozen but any changes will be detected by host.



[PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

2017-04-13 Thread Yasunari.Takiguchi
From: Yasunari Takiguchi 

Hi,

This is the patch series (version 2) of Sony CXD2880 DVB-T2/T tuner + 
demodulator driver.
The driver supports DVB-API and interfaces through SPI.

We have tested the driver on Raspberry Pi 3 and got picture and sound from a 
media player.

Thanks,
Takiguchi
---
 Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt|   14 
++
 drivers/media/spi/cxd2880-spi.c | 728 

 drivers/media/dvb-frontends/cxd2880/cxd2880.h   |   46 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_common.c|   84 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_common.h|   86 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_io.c|   68 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_io.h|   62 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_stdlib.h|   35 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_stopwatch_port.c|   71 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_math.c  |   89 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_math.h  |   40 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c |  147 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.h |   40 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_spi.h   |   51 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.c|  130 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.h|   45 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h   |   50 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c| 3925 

 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h|  395 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_driver_version.h |   29 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c|  207 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.h|   52 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c |   99 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ.h |   44 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_top.c   | 1550 

 drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt.h  |   91 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c   | 1072 
+
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.h   |   62 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c|  197 ++
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h|   58 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.c   | 1190 
+
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.h   |  106 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_dvbt2.h |  402 
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.c  | 1309 
++
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.h  |   82 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c   |  311 +++
 drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h   |   64 +
 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.c  | 2523 

 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.h  |  170 ++
 drivers/media/dvb-frontends/Makefile|1 +
 drivers/media/dvb-frontends/cxd2880/Makefile|   21 
+
 drivers/media/spi/Makefile  |5 
+
 drivers/media/dvb-frontends/Kconfig |2 ++
 drivers/media/dvb-frontends/cxd2880/Kconfig |6 
++
 drivers/media/spi/Kconfig   |   14 
++
 MAINTAINERS |9 
+

 46 files changed, 15782 insertions(+)

 create mode 100644 Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
 create mode 100644 drivers/media/spi/cxd2880-spi.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_stdlib.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_stopwatch_port.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
 create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
 create mode 100644 driver

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

2017-04-13 Thread Huang, Ying
Andrew Morton  writes:

> On Fri,  7 Apr 2017 14:49:01 +0800 "Huang, Ying"  wrote:
>
>> To reduce the lock contention of swap_info_struct->lock when freeing
>> swap entry.  The freed swap entries will be collected in a per-CPU
>> buffer firstly, and be really freed later in batch.  During the batch
>> freeing, if the consecutive swap entries in the per-CPU buffer belongs
>> to same swap device, the swap_info_struct->lock needs to be
>> acquired/released only once, so that the lock contention could be
>> reduced greatly.  But if there are multiple swap devices, it is
>> possible that the lock may be unnecessarily released/acquired because
>> the swap entries belong to the same swap device are non-consecutive in
>> the per-CPU buffer.
>> 
>> To solve the issue, the per-CPU buffer is sorted according to the swap
>> device before freeing the swap entries.  Test shows that the time
>> spent by swapcache_free_entries() could be reduced after the patch.
>> 
>> Test the patch via measuring the run time of swap_cache_free_entries()
>> during the exit phase of the applications use much swap space.  The
>> results shows that the average run time of swap_cache_free_entries()
>> reduced about 20% after applying the patch.
>
> "20%" is useful info, but it is much better to present the absolute
> numbers, please.  If it's "20% of one nanosecond" then the patch isn't
> very interesting.  If it's "20% of 35 seconds" then we know we have
> more work to do.

I added memory freeing timing capability to vm-scalability test suite.
The result shows the memory freeing time reduced from 2.64s to 2.31s
(about -12.5%).

Best Regards,
Huang, Ying

> If there is indeed still a significant problem here then perhaps it
> would be better to move the percpu swp_entry_t buffer into the
> per-device structure swap_info_struct, so it becomes "per cpu, per
> device".  That way we should be able to reduce contention further.
>
> Or maybe we do something else - it all depends upon the significance of
> this problem, which is why a full description of your measurements is
> useful.


Re: [PATCH V8 3/5] PCI/ASPM: add init hook to device_add

2017-04-13 Thread Bjorn Helgaas
On Thu, Apr 13, 2017 at 8:19 PM, Sinan Kaya  wrote:
> On 4/13/2017 5:02 PM, Bjorn Helgaas wrote:
>> I do see that you change the deallocation in patch [5/5], but I think
>> the deallocation change should be in the same patch as the allocation
>> change.  Otherwise I think we have a use-after-free problem in this
>> sequence:
>
> Sure, I'll reorder. As you can see here, link will be only removed if
> root port is being removed.
>
> Without this, we'll hit the use after free issue you mentioned.
>
> if (pdev->has_secondary_link) {
> link = pdev->link_state;
> down_read(&pci_bus_sem);
> mutex_lock(&aspm_lock);
>
> list_del(&link->sibling);
> list_del(&link->link);
>
> /* Clock PM is for endpoint device */
> free_link_state(link);
> mutex_unlock(&aspm_lock);
> up_read(&pci_bus_sem);
> return;
> }

Right, but this "pdev->has_secondary_link" check is in your new code
and doesn't show up until patch [5/5].

As of *this* patch [3/5], the link is removed when the endpoint is
removed, so we could hit the use-after-free.

Granted, we'll only be susceptible to this while bisecting because
normally all the patches will be applied.  But I think this patch will
make more sense and be easier to review if it makes the link_state
lifetime match the Port's lifetime.

Bjorn


Re: [PATCH V8 3/5] PCI/ASPM: add init hook to device_add

2017-04-13 Thread Sinan Kaya
On 4/13/2017 5:02 PM, Bjorn Helgaas wrote:
> I do see that you change the deallocation in patch [5/5], but I think
> the deallocation change should be in the same patch as the allocation
> change.  Otherwise I think we have a use-after-free problem in this
> sequence:

Sure, I'll reorder. As you can see here, link will be only removed if
root port is being removed.

Without this, we'll hit the use after free issue you mentioned.

if (pdev->has_secondary_link) {
link = pdev->link_state;
down_read(&pci_bus_sem);
mutex_lock(&aspm_lock);

list_del(&link->sibling);
list_del(&link->link);

/* Clock PM is for endpoint device */
free_link_state(link);
mutex_unlock(&aspm_lock);
up_read(&pci_bus_sem);
return;
}  

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


Re: [PATCH] block: bios with an offset are always gappy

2017-04-13 Thread Ming Lei
On Thu, Apr 13, 2017 at 10:35:17PM +0200, Andreas Mohr wrote:
> On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote:
> > +   /*
> > +* don't merge if the 1st bio starts with non-zero
> > +* offset, otherwise it is quite difficult to respect
> > +* sg gap limit. We work hard to merge huge of small
> > +* bios in case of mkfs.
> 
> "huge of small bios in case" - -ENOPARSE.
> 
> "huge numbers of"?
> "huge or small"?

OK, it should be tons of or sort of description. As you can see
in the trace, there are 2560 bios merged in one request.

Thanks,
Ming


Re: [RFC 2/2] mux: mmio-based syscon mux controller

2017-04-13 Thread Steve Longerbeam



On 04/13/2017 08:48 AM, Philipp Zabel wrote:

This adds a driver for mmio-based syscon multiplexers controlled by a
single bitfield in a syscon register range.

Signed-off-by: Philipp Zabel 
---
  drivers/mux/Kconfig  |  13 +
  drivers/mux/Makefile |   1 +
  drivers/mux/mux-syscon.c | 130 +++
  3 files changed, 144 insertions(+)
  create mode 100644 drivers/mux/mux-syscon.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 86668b4d2fc52..a5e6a3b01ac24 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -43,4 +43,17 @@ config MUX_GPIO
  To compile the driver as a module, choose M here: the module will
  be called mux-gpio.
  
+config MUX_SYSCON


my preference would be CONFIG_MUX_MMIO.


+   tristate "MMIO bitfield-controlled Multiplexer"


"MMIO register bitfield-controlled Multiplexer"

The rest looks good to me.

Steve


+   depends on OF && MFD_SYSCON
+   help
+ MMIO bitfield-controlled Multiplexer controller.
+
+ The driver builds a single multiplexer controller using a bitfield
+ in a syscon register. For N bit wide bitfields, there will be 2^N
+ possible multiplexer states.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-syscon.
+
  endif
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index b00a7d37d2fbe..234309f6655f7 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -5,3 +5,4 @@
  obj-$(CONFIG_MULTIPLEXER) += mux-core.o
  obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
  obj-$(CONFIG_MUX_GPIO)+= mux-gpio.o
+obj-$(CONFIG_MUX_SYSCON)   += mux-syscon.o
diff --git a/drivers/mux/mux-syscon.c b/drivers/mux/mux-syscon.c
new file mode 100644
index 0..31cacc61f1439
--- /dev/null
+++ b/drivers/mux/mux-syscon.c
@@ -0,0 +1,130 @@
+/*
+ * syscon bitfield-controlled multiplexer driver
+ *
+ * Copyright (C) 2017 Pengutronix, Philipp Zabel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_syscon {
+   struct regmap_field *field;
+};
+
+static int mux_syscon_set(struct mux_control *mux, int state)
+{
+   struct mux_syscon *mux_syscon = mux_chip_priv(mux->chip);
+
+   return regmap_field_write(mux_syscon->field, state);
+}
+
+static const struct mux_control_ops mux_syscon_ops = {
+   .set = mux_syscon_set,
+};
+
+static const struct of_device_id mux_syscon_dt_ids[] = {
+   { .compatible = "mmio-mux", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mux_syscon_dt_ids);
+
+static int of_get_reg_field(struct device_node *node, struct reg_field *field)
+{
+   u32 bit_mask;
+   int ret;
+
+   ret = of_property_read_u32(node, "reg", &field->reg);
+   if (ret < 0)
+   return ret;
+
+   ret = of_property_read_u32(node, "bit-mask", &bit_mask);
+   if (ret < 0)
+   return ret;
+
+   ret = of_property_read_u32(node, "bit-shift", &field->lsb);
+   if (ret < 0)
+   return ret;
+
+   field->msb = field->lsb + fls(bit_mask) - 1;
+
+   return 0;
+}
+
+static int mux_syscon_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct mux_chip *mux_chip;
+   struct mux_syscon *mux_syscon;
+   struct regmap *regmap;
+   struct reg_field field;
+   int bits;
+   s32 idle_state;
+   int ret;
+
+   ret = of_get_reg_field(pdev->dev.of_node, &field);
+   if (ret) {
+   dev_err(&pdev->dev, "missing bit-field properties: %d\n", ret);
+   return ret;
+   }
+
+   regmap = syscon_node_to_regmap(pdev->dev.of_node->parent);
+   if (IS_ERR(regmap)) {
+   ret = PTR_ERR(regmap);
+   dev_err(&pdev->dev, "failed to get syscon regmap: %d\n", ret);
+   return ret;
+   }
+
+   mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_syscon));
+   if (!mux_chip)
+   return -ENOMEM;
+
+   mux_syscon = mux_chip_priv(mux_chip);
+   mux_chip->ops = &mux_syscon_ops;
+
+   mux_syscon->field = devm_regmap_field_alloc(&pdev->dev, regmap, field);
+   if (IS_ERR(mux_syscon->field)) {
+   ret = PTR_ERR(mux_syscon->field);
+   dev_err(&pdev->dev, "failed to regmap bit-field: %d\n", ret);
+   return ret;
+   }
+   bits = 1 + field.msb - field.lsb;
+
+   mux_chip->mux->states = 1 << bits;
+
+   ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
+   if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {
+   if (idle_state < 0 || idle_state >= mux_chip->mux->states) {
+   dev_err(dev, "invalid idle-st

[PATCH v3 04/21] ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts 
b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index 28eede180e4f..f24058737a13 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -171,7 +171,7 @@
/* leds device (in STM32F0) at address 0x2b */
 
eeprom@54 {
-   compatible = "at,24c64";
+   compatible = "at,24c64", "atmel,24c64";
reg = <0x54>;
 
/* The EEPROM contains data for bootloader.
-- 
2.9.3



[PATCH v3 08/21] ARM: dts: keystone: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/keystone-k2e-evm.dts  | 2 +-
 arch/arm/boot/dts/keystone-k2hk-evm.dts | 2 +-
 arch/arm/boot/dts/keystone-k2l-evm.dts  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts 
b/arch/arm/boot/dts/keystone-k2e-evm.dts
index ae1ebe7ee021..8c79caae9c1b 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -69,7 +69,7 @@
 
 &i2c0 {
dtt@50 {
-   compatible = "at,24c1024";
+   compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
 };
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts 
b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index 2156ff92d08f..7c6916a11b18 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -145,7 +145,7 @@
 
 &i2c0 {
dtt@50 {
-   compatible = "at,24c1024";
+   compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
 };
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts 
b/arch/arm/boot/dts/keystone-k2l-evm.dts
index 056b42f99d7a..685a236a57f4 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -42,7 +42,7 @@
 
 &i2c0 {
dtt@50 {
-   compatible = "at,24c1024";
+   compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
 };
-- 
2.9.3



[PATCH v3 12/21] ARM: dts: socfpga: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts 
b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index 363ee62457fe..24f566d81667 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -294,7 +294,7 @@
clock-frequency = <10>;
 
at24@50 {
-   compatible = "at24,24c02";
+   compatible = "at24,24c02", "atmel,24c02";
pagesize = <8>;
reg = <0x50>;
};
-- 
2.9.3



[PATCH v3 09/21] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/lpc4337-ciaa.dts  | 6 +++---
 arch/arm/boot/dts/lpc4350-hitex-eval.dts| 2 +-
 arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts 
b/arch/arm/boot/dts/lpc4337-ciaa.dts
index 7c16d639a1b4..beddaba85393 100644
--- a/arch/arm/boot/dts/lpc4337-ciaa.dts
+++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
@@ -174,17 +174,17 @@
clock-frequency = <40>;
 
eeprom@50 {
-   compatible = "microchip,24c512";
+   compatible = "microchip,24c512", "atmel,24c512";
reg = <0x50>;
};
 
eeprom@51 {
-   compatible = "microchip,24c02";
+   compatible = "microchip,24c02", "atmel,24c02";
reg = <0x51>;
};
 
eeprom@54 {
-   compatible = "microchip,24c512";
+   compatible = "microchip,24c512", "atmel,24c512";
reg = <0x54>;
};
 };
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts 
b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 874c75d44013..8b973f537d3a 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -429,7 +429,7 @@
};
 
eeprom@50 {
-   compatible = "nxp,24c02";
+   compatible = "nxp,24c02", "atmel,24c02";
reg = <0x50>;
};
 
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts 
b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 9b5fad622522..02b23fa29d75 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -490,7 +490,7 @@
};
 
eeprom@57 {
-   compatible = "microchip,24c64";
+   compatible = "microchip,24c64", "atmel,24c64";
reg = <0x57>;
};
 };
-- 
2.9.3



[PATCH v3 15/21] arm64: dts: ls1043a: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index c37110bc1506..5389eae627e5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -75,11 +75,11 @@
reg = <0x4c>;
};
eeprom@52 {
-   compatible = "at24,24c512";
+   compatible = "at24,24c512", "atmel,24c512";
reg = <0x52>;
};
eeprom@53 {
-   compatible = "at24,24c512";
+   compatible = "at24,24c512", "atmel,24c512";
reg = <0x53>;
};
rtc@68 {
-- 
2.9.3



[PATCH v3 16/21] arm64: zynqmp: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index ef1b9e573af0..9f29f99984f7 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -55,7 +55,7 @@
status = "okay";
clock-frequency = <40>;
eeprom@54 {
-   compatible = "at,24c64";
+   compatible = "at,24c64", "atmel,24c64";
reg = <0x54>;
};
 };
@@ -64,7 +64,7 @@
status = "okay";
clock-frequency = <40>;
eeprom@55 {
-   compatible = "at,24c64";
+   compatible = "at,24c64", "atmel,24c64";
reg = <0x55>;
};
 };
-- 
2.9.3



[PATCH v3 20/21] powerpc/83xx: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/powerpc/boot/dts/mpc8308_p1m.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8349emitx.dts | 2 +-
 arch/powerpc/boot/dts/mpc8377_rdb.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +-
 arch/powerpc/boot/dts/mpc8378_rdb.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8379_rdb.dts  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts 
b/arch/powerpc/boot/dts/mpc8308_p1m.dts
index 57f86cdf9f36..cab933b3957a 100644
--- a/arch/powerpc/boot/dts/mpc8308_p1m.dts
+++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
@@ -123,7 +123,7 @@
interrupt-parent = <&ipic>;
dfsrr;
fram@50 {
-   compatible = "ramtron,24c64";
+   compatible = "ramtron,24c64", "atmel,24c64";
reg = <0x50>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts 
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 90aed3ac2f69..00c5ef08e474 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -92,7 +92,7 @@
dfsrr;
 
eeprom: at24@50 {
-   compatible = "st,24c256";
+   compatible = "st,24c256", "atmel,24c256";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts 
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index e32613963ab0..02c59d05fe16 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -150,7 +150,7 @@
};
 
at24@50 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts 
b/arch/powerpc/boot/dts/mpc8377_wlan.dts
index c0c790168b96..2bc3ed8a18c3 100644
--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
@@ -135,7 +135,7 @@
dfsrr;
 
at24@50 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts 
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 71842fcd621f..9e681e3d6064 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -150,7 +150,7 @@
};
 
at24@50 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts 
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index e442a29b2fe0..3197bb78e19b 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -148,7 +148,7 @@
};
 
at24@50 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x50>;
};
 
-- 
2.9.3



[PATCH v3 19/21] powerpc/512x: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts 
b/arch/powerpc/boot/dts/mpc5121ads.dts
index 75888ce2c792..ece5d60256ee 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -94,7 +94,7 @@
};
 
eeprom@50 {
-   compatible = "at,24c32";
+   compatible = "at,24c32", "atmel,24c32";
reg = <0x50>;
};
 
-- 
2.9.3



[PATCH v3 21/21] powerpc/44x: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 

---

Changes in v3: None
Changes in v2: None

 arch/powerpc/boot/dts/warp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index e576ee85c42f..19e0ec83b1a5 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -238,7 +238,7 @@
 
/* This will create 52 and 53 */
at24@52 {
-   compatible = "at,24c04";
+   compatible = "at,24c04", "atmel,24c04";
reg = <0x52>;
};
};
-- 
2.9.3



[PATCH v3 18/21] powerpc/fsl: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/powerpc/boot/dts/fsl/b4qds.dtsi|  8 
 arch/powerpc/boot/dts/fsl/c293pcie.dts  |  2 +-
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi |  2 +-
 arch/powerpc/boot/dts/fsl/p1023rdb.dts  |  2 +-
 arch/powerpc/boot/dts/fsl/p2041rdb.dts  |  4 ++--
 arch/powerpc/boot/dts/fsl/p3041ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p4080ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p5020ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p5040ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/t208xqds.dtsi |  8 
 arch/powerpc/boot/dts/fsl/t4240qds.dts  | 12 ++--
 arch/powerpc/boot/dts/fsl/t4240rdb.dts  |  6 +++---
 12 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4qds.dtsi 
b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
index 3785ef826d07..18053d59be01 100644
--- a/arch/powerpc/boot/dts/fsl/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
@@ -166,19 +166,19 @@
reg = <0>;
 
eeprom@50 {
-   compatible = "at24,24c64";
+   compatible = "at24,24c64", 
"atmel,24c64";
reg = <0x50>;
};
eeprom@51 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x51>;
};
eeprom@53 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x53>;
};
eeprom@57 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", 
"atmel,24c256";
reg = <0x57>;
};
rtc@68 {
diff --git a/arch/powerpc/boot/dts/fsl/c293pcie.dts 
b/arch/powerpc/boot/dts/fsl/c293pcie.dts
index 66709788429d..5e905e0857cf 100644
--- a/arch/powerpc/boot/dts/fsl/c293pcie.dts
+++ b/arch/powerpc/boot/dts/fsl/c293pcie.dts
@@ -153,7 +153,7 @@
 &soc {
i2c@3000 {
eeprom@50 {
-   compatible = "st,24c1024";
+   compatible = "st,24c1024", "atmel,24c1024";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi 
b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
index a8e4ba070104..2ca9cee2ddeb 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
@@ -89,7 +89,7 @@
 &board_soc {
i2c@3000 {
eeprom@50 {
-   compatible = "st,24c256";
+   compatible = "st,24c256", "atmel,24c256";
reg = <0x50>;
};
 
diff --git a/arch/powerpc/boot/dts/fsl/p1023rdb.dts 
b/arch/powerpc/boot/dts/fsl/p1023rdb.dts
index 9716ca64651c..ae38ed66a7a4 100644
--- a/arch/powerpc/boot/dts/fsl/p1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/p1023rdb.dts
@@ -79,7 +79,7 @@
 
i2c@3000 {
eeprom@53 {
-   compatible = "at24,24c04";
+   compatible = "at24,24c04", "atmel,24c04";
reg = <0x53>;
};
 
diff --git a/arch/powerpc/boot/dts/fsl/p2041rdb.dts 
b/arch/powerpc/boot/dts/fsl/p2041rdb.dts
index e50fea95a853..0c34e8c46961 100644
--- a/arch/powerpc/boot/dts/fsl/p2041rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/p2041rdb.dts
@@ -127,7 +127,7 @@
reg = <0x48>;
};
eeprom@50 {
-   compatible = "at24,24c256";
+   compatible = "at24,24c256", "atmel,24c256";
reg = <0x50>;
   

[PATCH v3 14/21] ARM: dts: zynq: Add generic compatible string for I2C EEPROM

2017-04-13 Thread Javier Martinez Canillas
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/zynq-zc702.dts | 2 +-
 arch/arm/boot/dts/zynq-zc706.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 0cdad2cc8b78..9aae7e061d19 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -136,7 +136,7 @@
#size-cells = <0>;
reg = <2>;
eeprom@54 {
-   compatible = "at,24c08";
+   compatible = "at,24c08", "atmel,24c08";
reg = <0x54>;
};
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index ad4bb06dba25..ff0fca1c41c8 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -92,7 +92,7 @@
#size-cells = <0>;
reg = <2>;
eeprom@54 {
-   compatible = "at,24c08";
+   compatible = "at,24c08", "atmel,24c08";
reg = <0x54>;
};
};
-- 
2.9.3



  1   2   3   4   5   6   7   8   9   >