Re: [PATCH 1/3] drivers: input: powerkey for HISI 65xx SoC

[kbuild test robot]

Hi,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.7-rc2 next-20160609]
[cannot apply to input/next]
[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/John-Stultz/Hi655x-powerkey-support-for-HiKey-v3/20160610-133804
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/input/misc/hisi_powerkey.c:21:0:
>> drivers/input/misc/hisi_powerkey.c:135:25: error: 'hi65xx_powerkey_of_match' 
>> undeclared here (not in a function)
MODULE_DEVICE_TABLE(of, hi65xx_powerkey_of_match);
^
   include/linux/module.h:223:21: note: in definition of macro 
'MODULE_DEVICE_TABLE'
extern const typeof(name) __mod_##type##__##name##_device_table  \
^~~~
>> include/linux/module.h:223:27: error: 
>> '__mod_of__hi65xx_powerkey_of_match_device_table' aliased to undefined 
>> symbol 'hi65xx_powerkey_of_match'
extern const typeof(name) __mod_##type##__##name##_device_table  \
  ^
>> drivers/input/misc/hisi_powerkey.c:135:1: note: in expansion of macro 
>> 'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, hi65xx_powerkey_of_match);
^~~

vim +/hi65xx_powerkey_of_match +135 drivers/input/misc/hisi_powerkey.c

15   */
16  
17  #include 
18  #include 
19  #include 
20  #include 
  > 21  #include 
22  #include 
23  #include 
24  #include 
25  
26  /* the held interrupt will trigger after 4 seconds */
27  #define MAX_HELD_TIME   (4 * MSEC_PER_SEC)
28  
29  
30  enum id_action { ID_PRESSED, ID_RELEASED, ID_HELD, ID_LAST };
31  const char *const irq_names[ID_LAST] = {"down", "up", "hold 4s"};
32  
33  struct hi65xx_priv {
34  struct input_dev *input;
35  };
36  
37  static irqreturn_t hi65xx_power_press_isr(int irq, void *q)
38  {
39  struct hi65xx_priv *p = q;
40  
41  pm_wakeup_event(p->input->dev.parent, MAX_HELD_TIME);
42  input_report_key(p->input, KEY_POWER, 1);
43  input_sync(p->input);
44  
45  return IRQ_HANDLED;
46  }
47  
48  static irqreturn_t hi65xx_power_release_isr(int irq, void *q)
49  {
50  struct hi65xx_priv *p = q;
51  
52  pm_wakeup_event(p->input->dev.parent, MAX_HELD_TIME);
53  input_report_key(p->input, KEY_POWER, 0);
54  input_sync(p->input);
55  
56  return IRQ_HANDLED;
57  }
58  
59  static irqreturn_t hi65xx_restart_toggle_isr(int irq, void *q)
60  {
61  struct hi65xx_priv *p = q;
62  int value = test_bit(KEY_RESTART, p->input->key);
63  
64  pm_wakeup_event(p->input->dev.parent, MAX_HELD_TIME);
65  input_report_key(p->input, KEY_RESTART, !value);
66  input_sync(p->input);
67  
68  return IRQ_HANDLED;
69  }
70  
71  irqreturn_t (*irq_handlers[ID_LAST])(int irq, void *q) = {
72  hi65xx_power_press_isr,
73  hi65xx_power_release_isr,
74  hi65xx_restart_toggle_isr,
75  };
76  
77  static int hi65xx_powerkey_probe(struct platform_device *pdev)
78  {
79  struct device *dev = &pdev->dev;
80  struct hi65xx_priv *priv;
81  int irq, i, ret;
82  
83  priv = devm_kzalloc(dev, sizeof(struct hi65xx_priv), 
GFP_KERNEL);
84  if (!priv)
85  return -ENOMEM;
86  
87  priv->input = devm_input_allocate_device(&pdev->dev);
88  if (!priv->input) {
89  dev_err(&pdev->dev, "failed to allocate input 
device\n");
90  return -ENOMEM;
91  }
92  
93  priv->input->phys = "hisi_on/input0";
94  priv->input->name = "HISI 65xx PowerOn Key";
95  
96  input_set_capability(priv->input, EV_KEY, KEY_POWER);
97  input_set_capability(priv->input, EV_KEY, KEY_RESTART);
98  
99  for (i = 0; i < ID_LAST; i++) {
   100  
   101  irq = platform_get_irq_byname(pdev, irq_names[i]);
   102  if (irq < 0) {
   103  dev_err(dev, "couldn't get irq %s\n", 
irq_names[i]);
   104   

Re: [PATCH v9 03/14] usb: hcd.h: Add OTG to HCD interface

[Roger Quadros]

On 09/06/16 17:11, Alan Stern wrote:
> On Thu, 9 Jun 2016, Sergei Shtylyov wrote:
> 
>> Hello.
>>
>> On 6/9/2016 10:31 AM, Roger Quadros wrote:
>>
>>> The OTG core will use struct otg_hcd_ops to interface
>>> with the HCD controller.
>>
>>Host controller driver (HCD) controller? Maybe just HC? :-)
>
> OK.

OTOH, my googling has shown that HCD may stand for both HC driver and 
 HC device... The host controller device sounds a bit tautological 
 however...
>>>
>>> Yeah I always meant it to be Host Controller Device :).
>>
>> The question here is more what was meant by the previous Linux USB 
>> authors. :-)
> 
> I have always used "HCD" to mean Host Controller Driver, and I believe 
> that's what other people have done too.
> 
> If I want to refer to a Host Controller Device, I would write either
> "HC" or "host controller".
> 
> Admittedly, this means that struct usb_hcd has a slightly illogical 
> name.
> 

OK, I'll re-spin this series so that HCD means HC driver.

cheers,
-roger

Re: [PATCH] events/uprobes: move smp_read_barrier_depends() where needed

[Oleg Nesterov]

On 06/09, Andrea Parri wrote:
>
> There is no need to use the barrier if there is no dereference/
> memory access; move it where needed (currently, affecting only
> Alpha).

OK, although area == NULL is unlikely case,

> While touching this, also make the reads _ONCE().

Why? both xol_area/vaddr can't change.

> Signed-off-by: Andrea Parri 
> ---
>  kernel/events/uprobes.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index b7a525ab2083..b1364acd683e 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1520,10 +1520,11 @@ static unsigned long get_trampoline_vaddr(void)
>   struct xol_area *area;
>   unsigned long trampoline_vaddr = -1;
>  
> - area = current->mm->uprobes_state.xol_area;
> - smp_read_barrier_depends();
> - if (area)
> - trampoline_vaddr = area->vaddr;
> + area = READ_ONCE(current->mm->uprobes_state.xol_area);
> + if (area) {
> + smp_read_barrier_depends();
> + trampoline_vaddr = READ_ONCE(area->vaddr);
> + }
>  
>   return trampoline_vaddr;
>  }
> -- 
> 1.9.1
> 

Re: [PATCH v10 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Hi Sergei,

On 09/06/16 15:34, Sergei Shtylyov wrote:
> On 6/9/2016 10:53 AM, Roger Quadros wrote:
> 
>> It provides APIs for the following tasks
>>
>> - Registering an OTG/dual-role capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
>>
>> Provide a dual-role device (DRD) state machine.
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros 
> 
> [...]
> 
>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>> new file mode 100644
>> index 000..baebe5c
>> --- /dev/null
>> +++ b/drivers/usb/common/usb-otg.c
>> @@ -0,0 +1,833 @@
> [...]
>> +/**
>> + * Change USB protocol when there is a protocol change.
>> + * fsm->lock must be held.
>> + */
> 
>If you're using the kernel-doc comment, please follow the rules.
> 

All your comments are valid and I'll fix the issues.



> [...]
> 
>Phew, that was a long patch... normally I don't review the patches that 
> are such big. :-)

Thanks for the patience and review :)

--
cheers,
-roger

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

[Wolfram Sang]

On Thu, Jun 09, 2016 at 04:06:03PM +0300, Crestez Dan Leonard wrote:
> When devices are instatiated through devicetree the i2c_client->name is
> set to the compatible string with company name stripped out. This is
> then matched to the i2c_device_id table to pass the device_id to the
> probe function. This id parameter is used by some device drivers to
> differentiate between model numbers.
> 
> When using ACPI this id parameter is NULL and the driver usually needs
> to do ACPI-specific differentiation.
> 
> This patch attempts to find a valid i2c_device_id when using ACPI with
> DT-like compatible strings.

Note that this DT behaviour is about to be dropped to match I2C with
the "generic" behaviour".

https://lkml.org/lkml/2016/5/4/534



signature.asc
Description: PGP signature

Re: [PATCH v10 11/14] usb: otg: use dev_dbg() instead of VDBG()

[Roger Quadros]

On 09/06/16 18:43, Joe Perches wrote:
> On Thu, 2016-06-09 at 10:55 +0300, Roger Quadros wrote:
>> Now that we have a device reference in struct usb_otg
>> let's use dev_vdbg() for debug messages instead of VDBG().
>>
>> Signed-off-by: Roger Quadros 
>> Acked-by: Peter Chen 
>> ---
>> v10:
>> - in the commit message say dev_vdbg() instead of dev_dbg()
> 
> 50% - partial credit, see: patch/email subject.
> 
Oops. Will fix. :)

cheers,
-roger

Re: [PATCH v9 13/14] usb: gadget: udc: adapt to OTG core

[Roger Quadros]

Hi Yoshihiro,

On 09/06/16 13:49, Yoshihiro Shimoda wrote:
> Hi Roger,
> 
>> From: Roger Quadros
>> Sent: Wednesday, June 08, 2016 6:04 PM
>>
>> The OTG state machine needs a mechanism to start and
>> stop the gadget controller as well as connect/disconnect
>> from the bus. Add usb_gadget_start(), usb_gadget_stop()
>> and usb_gadget_connect_control().
>>
>> Introduce usb_otg_add_gadget_udc() to allow controller drivers
>> to register a gadget controller that is part of an OTG instance.
>>
>> Register with OTG core when UDC is added in usb_add_gadget_udc_release()
>> and unregister on usb_del_gadget_udc().
>>
>> Notify the OTG core when gadget function driver is available on
>> udc_bind_to_driver() and when it is removed in usb_gadget_remove_driver().
>>
>> We need to unlock the usb_lock mutex before calling
>> usb_otg_register_gadget() else it will cause a circular
>> locking dependency.
>>
>> Ignore softconnect sysfs control when we're in OTG
>> mode as OTG FSM should care of gadget softconnect using
>> the b_bus_req mechanism.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/gadget/udc/udc-core.c | 202 
>> --
>>  include/linux/usb/gadget.h|   4 +
>>  2 files changed, 196 insertions(+), 10 deletions(-)
> 
> I tried to apply this patch on the Felipe's usb.git / testing/next branch,
> but I couldn't apply because the udc-core.c was renamed to core.c.
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=a22b539c7082b6a3046b3a9cebb356a047a2d81d
> 
> I guess this patch needs rebase for that.

OK. I'll respin the whole series on Felipe's usb.git /testing/next.

cheers,
-roger

Re: [PATCH] m32r: add __ucmpdi2 to fix build failure

[Sudip Mukherjee]

On Thursday 09 June 2016 11:16 PM, Andrew Morton wrote:

On Thu,  9 Jun 2016 22:53:33 +0100 Sudip Mukherjee  
wrote:


We are having build failure with m32r and the error message being:
ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
ERROR: "__ucmpdi2" [drivers/media/i2c/adv7842.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/bcache/bcache.ko] undefined!
ERROR: "__ucmpdi2" [drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko] undefined!

__ucmpdi2 is introduced to m32r architecture taking example from other
architectures like h8300, microblaze, mips.

--- a/arch/m32r/kernel/m32r_ksyms.c
+++ b/arch/m32r/kernel/m32r_ksyms.c
@@ -41,6 +41,9 @@ EXPORT_SYMBOL(cpu_data);
  EXPORT_SYMBOL(smp_flush_tlb_page);
  #endif

+extern int __ucmpdi2(unsigned long long a, unsigned long long b);
+EXPORT_SYMBOL(__ucmpdi2);
+


This would be neater.  Does it work?


From: Andrew Morton 
Subject: m32r-add-__ucmpdi2-to-fix-build-failure-fix

avoid extern declaration in .c file

Cc: Sudip Mukherjee 
Cc: Sudip Mukherjee 
Signed-off-by: Andrew Morton 

--- a/arch/m32r/kernel/m32r_ksyms.c~m32r-add-__ucmpdi2-to-fix-build-failure-fix
+++ a/arch/m32r/kernel/m32r_ksyms.c
@@ -41,7 +41,6 @@ EXPORT_SYMBOL(cpu_data);
  EXPORT_SYMBOL(smp_flush_tlb_page);
  #endif

-extern int __ucmpdi2(unsigned long long a, unsigned long long b);
  EXPORT_SYMBOL(__ucmpdi2);

  /* compiler generated symbol */
--- a/arch/m32r/lib/libgcc.h~m32r-add-__ucmpdi2-to-fix-build-failure-fix
+++ a/arch/m32r/lib/libgcc.h
@@ -22,3 +22,4 @@ typedef union {

  #endif /* __ASM_LIBGCC_H */

+extern int __ucmpdi2(unsigned long long a, unsigned long long b);




Nope.
In file included from ../include/linux/linkage.h:6:0,
 from ../include/linux/kernel.h:6,
 from ../include/linux/list.h:8,
 from ../include/linux/module.h:9,
 from ../arch/m32r/kernel/m32r_ksyms.c:1:
../arch/m32r/kernel/m32r_ksyms.c:44:15: error: '__ucmpdi2' undeclared 
here (not in a function)

 EXPORT_SYMBOL(__ucmpdi2);
   ^
../include/linux/export.h:57:16: note: in definition of macro 
'___EXPORT_SYMBOL'

  extern typeof(sym) sym; \
^
../arch/m32r/kernel/m32r_ksyms.c:44:1: note: in expansion of macro 
'EXPORT_SYMBOL'

 EXPORT_SYMBOL(__ucmpdi2);
 ^
make[2]: *** [arch/m32r/kernel/m32r_ksyms.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/m32r/kernel] Error 2
make[1]: *** Waiting for unfinished jobs

m32r_ksyms.c is not having any reference to the name. If you want to 
remove the extern from the C file then I think we should declare it in 
some header file and include that in the m32r_ksyms.c. And if that works 
then that can be applied to all the other arch also, as almost all of 
them have these externs in *_ksyms.c.


Regards
Sudip

Re: [PATCH 1/3] drivers: input: powerkey for HISI 65xx SoC

[John Stultz]

On Thu, Jun 9, 2016 at 11:44 PM, kbuild test robot  wrote:
> Hi,
>
> [auto build test ERROR on ljones-mfd/for-mfd-next]
> [also build test ERROR on v4.7-rc2 next-20160609]
> [cannot apply to input/next]
> [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/John-Stultz/Hi655x-powerkey-support-for-HiKey-v3/20160610-133804
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> for-mfd-next
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from drivers/input/misc/hisi_powerkey.c:21:0:
>>> drivers/input/misc/hisi_powerkey.c:135:25: error: 
>>> 'hi65xx_powerkey_of_match' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, hi65xx_powerkey_of_match);
> ^
>include/linux/module.h:223:21: note: in definition of macro 
> 'MODULE_DEVICE_TABLE'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
> ^~~~
>>> include/linux/module.h:223:27: error: 
>>> '__mod_of__hi65xx_powerkey_of_match_device_table' aliased to undefined 
>>> symbol 'hi65xx_powerkey_of_match'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
>   ^
>>> drivers/input/misc/hisi_powerkey.c:135:1: note: in expansion of macro 
>>> 'MODULE_DEVICE_TABLE'
> MODULE_DEVICE_TABLE(of, hi65xx_powerkey_of_match);
> ^~~

Yep. Sorry, I realized right after I sent this that I had left the
MODULE_DEVICE_TABLE entry in there. I've already yanked it in my tree
and will resubmit with the fix next week.

Please do let me know if you have any other feedback or issues in the meantime!

Apologies and Thanks!
-john

Re: [PATCH net v2] vmxnet3: segCnt can be 1 for LRO packets

[David Miller]

From: Shrikrishna Khare 
Date: Tue,  7 Jun 2016 23:13:35 -0700

> The device emulation may send segCnt of 1 for LRO packets.
> 
> Signed-off-by: Shrikrishna Khare 
> Signed-off-by: Jin Heo 

Applied.

[PATCH 0/4] Trivial GPIO/pinctrl documentation fixes

[Andrew Jeffery]

Hi all,

The patches fix some file paths and minor grammatical issues in the
GPIO/pinctrl documentation. Patches 3 and 4 are separate to ease review.

Cheers,

Andrew

Andrew Jeffery (4):
  drivers-on-gpio.txt: Fix paths to GPIO driver source files
  pinctrl.txt: Fix grammar in pinmux request list
  pinctrl.txt: s/have/has/ in GPIO driver interaction description
  pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction

 Documentation/gpio/drivers-on-gpio.txt | 13 +++--
 Documentation/pinctrl.txt  | 22 +++---
 2 files changed, 18 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH 3/4] pinctrl.txt: s/have/has/ in GPIO driver interaction description

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 Documentation/pinctrl.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index cefcf5d88a1c..07d102c3d05a 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -286,7 +286,7 @@ see the section named "pin control requests from drivers" 
and
 "drivers needing both pin control and GPIOs" below for details. But in some
 situations a cross-subsystem mapping between pins and GPIOs is needed.
 
-Since the pin controller subsystem have its pinspace local to the pin
+Since the pin controller subsystem has its pinspace local to the pin
 controller we need a mapping so that the pin control subsystem can figure out
 which pin controller handles control of a certain GPIO pin. Since a single
 pin controller may be muxing several GPIO ranges (typically SoCs that have
-- 
2.7.4

[PATCH 1/4] drivers-on-gpio.txt: Fix paths to GPIO driver source files

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 Documentation/gpio/drivers-on-gpio.txt | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpio/drivers-on-gpio.txt 
b/Documentation/gpio/drivers-on-gpio.txt
index 14bf95a13bae..306513251713 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/gpio/drivers-on-gpio.txt
@@ -37,15 +37,16 @@ hardware descriptions such as device tree or ACPI:
   external connector status, such as a headset line for an audio driver or an
   HDMI connector. It will provide a better userspace sysfs interface than GPIO.
 
-- restart-gpio: drivers/power/gpio-restart.c is used to restart/reboot the
-  system by pulling a GPIO line and will register a restart handler so
+- restart-gpio: drivers/power/reset/gpio-restart.c is used to restart/reboot
+  the system by pulling a GPIO line and will register a restart handler so
   userspace can issue the right system call to restart the system.
 
-- poweroff-gpio: drivers/power/gpio-poweroff.c is used to power the system down
-  by pulling a GPIO line and will register a pm_power_off() callback so that
-  userspace can issue the right system call to power down the system.
+- poweroff-gpio: drivers/power/reset/gpio-poweroff.c is used to power the
+  system down by pulling a GPIO line and will register a pm_power_off()
+  callback so that userspace can issue the right system call to power down the
+  system.
 
-- gpio-gate-clock: drivers/clk/clk-gpio-gate.c is used to control a gated clock
+- gpio-gate-clock: drivers/clk/clk-gpio.c is used to control a gated clock
   (off/on) that uses a GPIO, and integrated with the clock subsystem.
 
 - i2c-gpio: drivers/i2c/busses/i2c-gpio.c is used to drive an I2C bus
-- 
2.7.4

[PATCH 2/4] pinctrl.txt: Fix grammar in pinmux request list

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 Documentation/pinctrl.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 4976389e432d..cefcf5d88a1c 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -493,12 +493,12 @@ Definitions:
 - The combination of a FUNCTION and a PIN GROUP determine a certain function
   for a certain set of pins. The knowledge of the functions and pin groups
   and their machine-specific particulars are kept inside the pinmux driver,
-  from the outside only the enumerators are known, and the driver core can:
+  from the outside only the enumerators are known, and the driver core can
+  request:
 
-  - Request the name of a function with a certain selector (>= 0)
+  - The name of a function with a certain selector (>= 0)
   - A list of groups associated with a certain function
-  - Request that a certain group in that list to be activated for a certain
-function
+  - That a certain group in that list to be activated for a certain function
 
   As already described above, pin groups are in turn self-descriptive, so
   the core will retrieve the actual pin range in a certain group from the
-- 
2.7.4

[PATCH 4/4] pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---
 Documentation/pinctrl.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 07d102c3d05a..6414a613cb8a 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -286,13 +286,13 @@ see the section named "pin control requests from drivers" 
and
 "drivers needing both pin control and GPIOs" below for details. But in some
 situations a cross-subsystem mapping between pins and GPIOs is needed.
 
-Since the pin controller subsystem has its pinspace local to the pin
-controller we need a mapping so that the pin control subsystem can figure out
-which pin controller handles control of a certain GPIO pin. Since a single
-pin controller may be muxing several GPIO ranges (typically SoCs that have
-one set of pins, but internally several GPIO silicon blocks, each modelled as
-a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
-instance like this:
+Since the pin controller subsystem has its pinspace local to the pin controller
+we need a mapping so that the pin control subsystem can figure out which pin
+controller handles control of a certain GPIO pin. Since a single pin controller
+may be muxing several GPIO ranges (typically SoCs that have one set of pins,
+but internally several GPIO silicon blocks, each modelled as a struct
+gpio_chip) any number of GPIO ranges can be added to a pin controller instance
+like this:
 
 struct gpio_chip chip_a;
 struct gpio_chip chip_b;
-- 
2.7.4

Re: [PATCH v3 2/2] arm64: dts: Fix broken architected timer interrupt trigger

[Marc Zyngier]

On Thu, 09 Jun 2016 14:06:02 -0700
David Daney  wrote:

> I spoke too soon...
> 
> On 06/09/2016 11:11 AM, David Daney wrote:
> > On 06/06/2016 10:56 AM, Marc Zyngier wrote:
> >> The ARM architected timer specification mandates that the interrupt
> >> associated with each timer is level triggered (which corresponds to
> >> the "counter >= comparator" condition).
> >>
> >> A number of DTs are being remarkably creative, declaring the interrupt
> >> to be edge triggered. A quick look at the TRM for the corresponding ARM
> >> CPUs clearly shows that this is wrong, and I've corrected those.
> >> For non-ARM designs (and in the absence of a publicly available TRM),
> >> I've made them active low as well, which can't be completely wrong
> >> as the GIC cannot disinguish between level low and level high.
> >>
> >> The respective maintainers are of course welcome to prove me wrong.
> >>
> >> While I was at it, I took the liberty to fix a couple of related issue,
> >> such as some spurious affinity bits on ThunderX, and their complete
> >> absence on ls1043a (both of which seem to be related to copy-pasting
> >> from other DTs).
> >>
> >> Signed-off-by: Marc Zyngier 
> >> ---
> >>   arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
> >>   arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
> >>   arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
> >>   arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
> >>   arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
> >>   arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
> >>   arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
> >>   arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
> >>   arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
> >>   arch/arm64/boot/dts/xilinx/zynqmp.dtsi   | 8 
> >>   10 files changed, 40 insertions(+), 40 deletions(-)
> >>
> > [...]
> >> diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> >> b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> >> index 2eb9b22..382d86f 100644
> >> --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> >> +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> >> @@ -354,10 +354,10 @@
> >>
> >>   timer {
> >>   compatible = "arm,armv8-timer";
> >> -interrupts = <1 13 0xff01>,
> >> - <1 14 0xff01>,
> >> - <1 11 0xff01>,
> >> - <1 10 0xff01>;
> >> +interrupts = <1 13 8>,
> >> + <1 14 8>,
> >> + <1 11 8>,
> >> + <1 10 8>;
> 
> 
> NAK!
> 
> According to arm,gic-v3.txt the trigger value must be either 1 or 4:
> 
>The 3rd cell is the flags, encoded as follows:
>  bits[3:0] trigger type and level flags.
>  1 = edge triggered
>  4 = level triggered

Which is a bug in the binding description. PPIs can be any trigger
(just look at the TRM for CPUs that have devices connected to a PPI to
be convinced - most of them are level low).

This doesn't mean that you can distinguish level-high from level-low
in a programmatic way. But the HW definitely can handle it.

I'll update the GICv3 binding to reflect this.

Now, coming back to your NAK: is level-low the right or wrong trigger
for your implementation of the architected timers?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616

[Sergey Senozhatsky]

that was fast!

On (06/10/16 08:34), Michal Hocko wrote:
[..]
> OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> I think we need the following. Andrew could you fold it into
> mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> it as a separate patch?
> 
> [1] 
> http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mho...@kernel.org
> 
> Thanks for the report Sergey!

after quick tests -- works for me. please see below.

> Sergey has reported that we might hit BUG_ON in new_slab() because
> unrestricted gfp mask used for the readahead purposes contains
> incompatible flags (__GFP_HIGHMEM in his case):
> [  429.191962] gfp: 2
> [  429.192634] [ cut here ]
> [  429.193281] kernel BUG at mm/slub.c:1616!
> [...]
> [  429.217369]  [] bio_alloc_bioset+0xbd/0x1b1
> [  429.218013]  [] mpage_alloc+0x28/0x7b
> [  429.218650]  [] do_mpage_readpage+0x43d/0x545
> [  429.219282]  [] mpage_readpages+0xf5/0x152
> 
> Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
> This is what was done before "mm, memcg: use consistent gfp flags during
> readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
> mpage_readpages.
> 
> Reported-by: Sergey Senozhatsky 
> Signed-off-by: Michal Hocko 
> ---
>  fs/mpage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/mpage.c b/fs/mpage.c
> index 9c11255b0797..5ce75b2e60d1 100644
> --- a/fs/mpage.c
> +++ b/fs/mpage.c
> @@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
>  {
>   struct bio *bio;
>  
> - bio = bio_alloc(gfp_flags, nr_vecs);
> + bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
>  
>   if (bio == NULL && (current->flags & PF_MEMALLOC)) {
>   while (!bio && (nr_vecs /= 2))

so the first bio_alloc() is ok now. what about the second bio_alloc()
in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?

may be something like this (composed in mail client)

static struct bio *
mpage_alloc(struct block_device *bdev,
sector_t first_sector, int nr_vecs,
gfp_t gfp_flags)
{
struct bio *bio;

+   gfp_flags &= GFP_KERNEL;

-   bio = bio_alloc(gfp_flags, nr_vecs);
+   bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);

if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
bio = bio_alloc(gfp_flags, nr_vecs);
 BUG?
}

if (bio) {
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
}
return bio;
}


=

the second part of the original report (sleeping function called from
invalid context at include/linux/sched.h:2960) is unrelated, I'll fork
a new thread; seems that it's coming from a380a3c755, Christoph Lameter,
2015-11-20.

-ss

Re: [PATCH 1/2] arm64: dts: r8a7795: add FCPF device nodes

[Geert Uytterhoeven]

On Thu, Jun 9, 2016 at 6:56 PM, Kieran Bingham  wrote:
> Provide nodes for the FCP devices dedicated to the FDP device channels.
>
> Signed-off-by: Kieran Bingham 

Reviewed-by: Geert Uytterhoeven 

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

[GIT] Networking

[David Miller]

1) nfnetlink timestamp taken from wrong skb, fix from Florian Westphal.

2) Revert some msleep conversions in rtlwifi as these spots are in
   atomic context, from Larry Finger.

3) Validate that NFTA_SET_TABLE attribute is actually specified when
   we call nf_tables_getset().  From Phil Turnbull.

4) Don't do mdio_reset in stmmac driver with spinlock held as that can
   sleep, from Vincent Palatin.

5) sk_filter() does things other than run a BPF filter, so we should
   not elide it's call just because sk->sk_filter is NULL.  Fix from
   Eric Dumazet.

6) Fix missing backlog updates in several packet schedulers, from Cong
   Wang.

7) bnx2x driver should allow VLAN add/remove while the interface is down,
   from Michal Schmidt.

8) Several RDS/TCP race fixes from Sowmini Varadhan.

9) fq_codel scheduler doesn't return correct queue length in dumps,
   from Eric Dumazet.

10) Fix TCP stats for tail loss probe and early retransmit in ipv6,
from Yuchung Cheng.

11) Properly initialize udp_tunnel_socket_cfg in l2tp_tunnel_create(),
from Guillaume Nault.

12) qfq scheduler leaks SKBs if a kzalloc fails, fix from Florian
Westphal.

13) sock_fprog passed into PACKET_FANOUT_DATA needs compat handling,
from Willem de Bruijn.

Please pull, thanks a lot!

The following changes since commit 6b15d6650c5301ce023d8df0cc3a60b1a76d377e:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-05-31 
22:28:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 50219538ffc0493a2b451a3aa0191138ef8bfe9d:

  vmxnet3: segCnt can be 1 for LRO packets (2016-06-10 00:15:11 -0700)


Arnd Bergmann (1):
  qed: fix qed_fill_link() error handling

Ben Dooks (2):
  net-sysfs: fix missing 
  stmmac: fix parameter to dwmac4_set_umac_addr()

Bert Kenward (1):
  sfc: report supported link speeds on SFP connections

Bob Copeland (1):
  mac80211: mesh: flush mesh paths unconditionally

Colin Ian King (3):
  net/ethoc: fix null dereference on error exit path
  net: fec: fix spelling mistakes and add missing newline
  gtp: #define _UAPI_LINUX_GTP_H_ and not _UAPI_LINUX_GTP_H__

Daniel Borkmann (2):
  bpf, trace: use READ_ONCE for retrieving file ptr
  net: sched: fix tc_should_offload for specific clsact classes

David S. Miller (12):
  Merge tag 'mac80211-for-davem-2016-06-01' of 
git://git.kernel.org/.../jberg/mac80211
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'mediatek-fixes'
  Merge tag 'wireless-drivers-for-davem-2016-06-04' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'rds-packet-assembly-fixes'
  Merge branch 'bnxt_en-fixes'
  Merge branch 'u32-hwoffload-fixes'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'cls_u32-hwoffload-fixes'
  Merge branch 'mlxsw-fixes'
  Merge tag 'mac80211-for-davem-2016-06-09' of 
git://git.kernel.org/.../jberg/mac80211
  Merge branch 'mlx5-fixes'

Eli Cohen (1):
  net/mlx5e: Fix blue flame quota logic

Eran Ben Elisha (1):
  net/mlx5e: Use ndo_stop explicitly at shutdown flow

Eric Dumazet (4):
  Possible problem with e6afc8ac ("udp: remove headers from UDP packets 
before queueing")
  fq_codel: fix NET_XMIT_CN behavior
  fq_codel: return non zero qlen in class dumps
  net_sched: add missing paddattr description

Eric W. Biederman (1):
  netfilter: nf_queue: Make the queue_handler pernet

Felix Fietkau (1):
  mac80211: fix fast_tx header alignment

Florian Westphal (4):
  netfilter: nfnetlink_queue: fix timestamp attribute
  netfilter: conntrack: remove leftover binary sysctl define
  netfilter: x_tables: don't reject valid target size on some architectures
  qfq: don't leak skb if kzalloc fails

Franky Lin (1):
  brcmfmac: add eth_type_trans back for PCIe full dongle

Geert Uytterhoeven (1):
  MAINTAINERS: Add file patterns for wireless device tree bindings

Guillaume Nault (1):
  l2tp: fix configuration passed to setup_udp_tunnel_sock()

Hariprasad Shenai (1):
  cxgb4: Add device id of T540-BT adapter

Helge Deller (2):
  soreuseport: Fix reuseport_bpf testcase on 32bit architectures
  soreuseport: add compat case for setsockopt SO_ATTACH_REUSEPORT_CBPF

Ido Schimmel (2):
  mlxsw: spectrum: Make split flow match firmware requirements
  mlxsw: spectrum: Don't sleep during ndo_get_phys_port_name()

Ivan Khoronzhuk (1):
  net: ethernet: ti: cpsw: fix rx-usecs interrupt pacing consistency

Jaap Jan Meijer (1):
  brcmfmac: add fallback for devices that do not report per-chain values

Jakub Kicinski (4):
  net: cls_u32: fix error code for invalid flags
  net: cls_u32: be more strict about skip-sw flag
  net: cls_u32: catch all hardware offload errors
  net: cls_u32: be more strict about skip-sw fla

Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered

[Marc Zyngier]

On Thu, 09 Jun 2016 14:10:48 -0700
David Daney  wrote:

> On 06/06/2016 10:56 AM, Marc Zyngier wrote:
> > The ARM architected timer produces level-triggered interrupts (this
> > is mandated by the architecture). Unfortunately, most device-trees
> > get this wrong, and expose an edge-triggered interrupt.
> >
> > Until now, this wasn't too much an issue, as the programming of the
> > trigger would fail (the corresponding PPI cannot be reconfigured),
> > and the kernel would be happy with this. But we're about to change
> > this, and trust DT a lot if the driver doesn't provide its own
> > trigger information. In that context, the timer breaks badly.
> >
> > While we do need to fix the DTs, there is also some userspace out
> > there (kvmtool) that generates the same kind of broken DT on the
> > fly, and that will completely break with newer kernels.
> >
> > As a safety measure, and to keep buggy software alive as well as
> > buying us some time to fix DTs all over the place, let's check
> > what trigger configuration has been given us by the firmware.
> > If this is not a level configuration, then we know that the
> > DT/ACPI configuration is bust, and we pick some defaults which
> > won't be worse than the existing setup.
> >
> > Signed-off-by: Marc Zyngier 
> 
> 
> I tried to test this patch, but there is a problem somewhere that I have 
> not yet tracked down.  On Cavium Thunder (gic-v3 based) I have tested 
> with the device tree interrupt type of both 4 and 8 and get the same result:
> 
> 
> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ2, 
> assuming level low
> [0.00] arm_arch_timer: WARNING: Please fix your firmware
> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ3, 
> assuming level low
> [0.00] arm_arch_timer: WARNING: Please fix your firmware
> [0.00] arm_arch_timer: Architected cp15 timer(s) running at 
> 100.00MHz (phys).
> [0.00] clocksource: arch_sys_counter: mask: 0xff 
> max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
> [0.02] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps 
> every 4398046511100ns
> 
> It could be that the gic-v3 irq mapping code is broken.  I will try to 
> look into it, but there may be other fixes needed before we would 
> consider this patch to be an improvement.

That's because the core kernel has other bugs which are going to be
addressed in 4.8. So far, we cannot set the trigger of a per-cpu
interrupt from the device tree, and we end-up with whatever is the
default (edge). You can put whatever you want in the DT, it will be
ignored.

This series in preparation of these fixes landing in 4.8, where we'll
be able to do the right thing, and will start noticing stupid things
coming from the DT.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH] clk: renesas: r8a7795: Provide FDP1 clocks

[Geert Uytterhoeven]

Hi Kieran,

On Thu, Jun 9, 2016 at 6:12 PM, Kieran Bingham  wrote:
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/clk/renesas/r8a7795-cpg-mssr.c | 3 +++
>  1 file changed, 3 insertions(+)

Thanks queued in clk-renesas-for-v4.8.

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 2/2] arm64: dts: r8a7795: add FDP1 device nodes

[Geert Uytterhoeven]

On Thu, Jun 9, 2016 at 6:56 PM, Kieran Bingham  wrote:
> Signed-off-by: Kieran Bingham 

Reviewed-by: Geert Uytterhoeven 

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/3] mfd: hi655x-pmic: Add powerkey device to hi655x PMIC driver

[Lee Jones]

On Thu, 09 Jun 2016, John Stultz wrote:

> Wire up the powerkey driver functionality for the hi655x PMIC.
> 
> Cc: Dmitry Torokhov 
> Cc: Rob Herring 
> Cc: Lee Jones 
> Cc: Jorge Ramirez-Ortiz 
> Cc: Feng Chen 
> Cc: Wei Xu 
> Cc: Guodong Xu 
> Signed-off-by: John Stultz 
> ---
>  drivers/mfd/hi655x-pmic.c | 37 -
>  1 file changed, 32 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index 68ab370..f3f6bfe2 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -24,10 +24,6 @@
>  #include 
>  #include 
>  
> -static const struct mfd_cell hi655x_pmic_devs[] = {
> - { .name = "hi655x-regulator", },
> -};
> -
>  static const struct regmap_irq hi655x_irqs[] = {
>   { .reg_offset = 0, .mask = OTMP_D1R_INT },
>   { .reg_offset = 0, .mask = VSYS_2P5_R_INT },
> @@ -56,6 +52,36 @@ static struct regmap_config hi655x_regmap_config = {
>   .max_register = HI655X_BUS_ADDR(0xFFF),
>  };
>  
> +static struct resource pwrkey_resources[] = {
> + {
> + .name   = "down",
> + .start  = 6,
> + .end= 6,
> + .flags  = IORESOURCE_IRQ,
> + }, {
> + .name   = "up",
> + .start  = 5,
> + .end= 5,
> + .flags  = IORESOURCE_IRQ,
> + }, {
> + .name   = "hold 4s",
> + .start  = 4,
> + .end= 4,
> + .flags  = IORESOURCE_IRQ,
> + },
> +};

No idea what 4, 5 and 6 mean.  Please define them.

> +static const struct mfd_cell hi655x_pmic_devs[] = {
> + {
> + .name   = "hi655x-regulator",
> + },
> + {
> + .name   = "hi65xx-powerkey",
> + .num_resources  = ARRAY_SIZE(pwrkey_resources),
> + .resources  = &pwrkey_resources[0],
> + },
> +};

Nit: Place the -regulator entry at the bottom and turn it into a one
liner:

{ .name = "hi655x-regulator", },


>  static void hi655x_local_irq_clear(struct regmap *map)
>  {
>   int i;
> @@ -124,7 +150,8 @@ static int hi655x_pmic_probe(struct platform_device *pdev)
>   platform_set_drvdata(pdev, pmic);
>  
>   ret = mfd_add_devices(dev, PLATFORM_DEVID_AUTO, hi655x_pmic_devs,
> -   ARRAY_SIZE(hi655x_pmic_devs), NULL, 0, NULL);
> +   ARRAY_SIZE(hi655x_pmic_devs), NULL, 0,
> +   regmap_irq_get_domain(pmic->irq_data));
>   if (ret) {
>   dev_err(dev, "Failed to register device %d\n", ret);
>   regmap_del_irq_chip(gpio_to_irq(pmic->gpio), pmic->irq_data);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Marc Zyngier]

On Wed, 8 Jun 2016 16:05:17 +0800
Shawn Lin  wrote:

> This patch adds a binding that describes the Rockchip PCIe controller
> found on Rockchip SoCs PCIe interface.
> 
> Signed-off-by: Shawn Lin 
> 
> ---
> 
> Changes in v2:
> - fix lots clk/reset stuff suggested by Heiko
> - remove msi-parent and add msi-map suggested by Marc

I noticed this  ...

> - drop phy related stuff
> - some others minor fixes
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt  | 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> new file mode 100644
> index 000..eb92e29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -0,0 +1,86 @@
> +* Rockchip AXI PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- compatible: Should contain "rockchip,rk3399-pcie"
> +- reg: Two register ranges as listed in the reg-names property
> +- reg-names: Must include the following names
> + - "axi-base"
> + - "apb-base"
> +- clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> + - "aclk"
> + - "aclk-perf"
> + - "hclk"
> + - "pm"
> +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
> +- phy-names:  MUST be "pcie-phy".
> +- interrupts: Three interrupt entries must be specified.
> +- interrupt-names: Must include the following names
> + - "sys"
> + - "legacy"
> + - "client"
> +- resets: Must contain five entries for each entry in reset-names.
> +See ../reset/reset.txt for details.
> +- reset-names: Must include the following names
> + - "core"
> + - "mgmt"
> + - "mgmt-sticky"
> + - "pipe"
> +- pinctrl-names : The pin control state names
> +- pinctrl-0: The "default" pinctrl state
> +- interrupt-map-mask and interrupt-map: standard PCI properties
> +- interrupt-controller: identifies the node as an interrupt controller
> +
> +Optional Property:
> +- ep-gpios: contain the entry for pre-reset gpio
> +- num-lanes: number of lanes to use
> +- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +
> +Example:
> +
> +pcie0: pcie@f800 {
> + compatible = "rockchip,rk3399-pcie";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
> +  <&cru PCLK_PCIE>;
> + clock-names = "aclk", "aclk-perf",
> +   "hclk";
> + bus-range = <0x0 0x1>;
> + interrupts = ,  IRQ_TYPE_LEVEL_HIGH>,
> +  ;
> + interrupt-names: "sys", "legacy", "client";
> + assigned-clocks = <&cru SCLK_PCIEPHY_REF>;
> + assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>;
> + assigned-clock-rates = <1>;
> + ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
> + ranges = < 0x8200 0 0xfa00 0x0 0xfa00 0 0x60
> +0x8100 0 0xfa60 0x0 0xfa60 0 0x10 >;
> + num-lanes = <4>;
> + reg = < 0x0 0xf800 0x0 0x200 >, < 0x0 0xfd00 0x0 0x100 
> >;
> + reg-name = "axi-base", "apb-base";
> + resets = <&cru SRST_PCIEPHY>, <&cru SRST_PCIE_CORE>, <&cru 
> SRST_PCIE_MGMT>,
> +  <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
> + reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> + phys = <&pcie_phy>;
> + phy-names = "pcie-phy";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie_clkreq>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &pcie0 1>,
> + <0 0 0 2 &pcie0 2>,
> + <0 0 0 3 &pcie0 3>,
> + <0 0 0 4 &pcie0 4>;
> +};


And yet I don't see anything related to msi-map in the binding or in
the example. As Doug mentioned issues with MSIs being delivered, I
wonder if the two are related...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

[PATCH v3,3/5] usb: xhci-mtk: make IPPC register optional

[Chunfeng Yun]

Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..dc86832 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power on host ip */
value = readl(&ippc->ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(&ippc->u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
 
+   if (ippc == NULL)
+   return 0;
+
/* reset whole ip */
value = readl(&ippc->ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_mtk_setup(struct usb_hcd *hcd)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
 
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+   }
+
+   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+   if (ret)
+   return ret;
+
+   if (usb_hcd_is_primary_hcd(hcd)) {
+   mtk->num_u3_ports = xhci->num_usb3_ports;
+   mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
 
-   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+   return ret;
 }
 
 static int xhci_mtk_probe(struct platform_device *pdev)
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
 
+   mtk->ippc_regs = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   mtk->ippc_regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mtk->ippc_regs)) {
-   ret = PTR_ERR(mtk->ippc_regs);
-   goto put_usb2_hcd;
+   if (res) {  /* ippc register is optional */
+   mtk->ippc_regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mtk->ippc_regs)) {
+   ret = PTR_ERR(mtk->ippc_regs);
+   goto put_usb2_hcd;
+   }
}
 
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
-- 
1.7.9.5

[PATCH v3,4/5] usb: Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 ++
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 ++
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5337 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..9ca0bf0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig"
 
 endif
 
+source "drivers/usb/mtu3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..7791af6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_MON)  += mon/
+obj-$(CONFIG_USB_MTU3) += mtu3/
 
 obj-$(CONFIG_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
new file mode 100644
index 000..6850fb6
--- /dev/null
+++ b/drivers/usb/mtu3/Kconfig
@@ -0,0 +1,47 @@
+# For MTK USB3.0 IP
+
+config USB_MTU3
+   tristate "MediaTek USB3 Dual Role controller"
+   depends on (USB || USB_GADGET) && HAS_DMA
+   select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
+   help
+ Say Y or M here if your system runs on MediaTek SoCs with
+ Dual Role SuperSpeed USB controller. You can select usb
+ mode as peripheral role or host role, or both.
+
+ If you don't know what this is, please say N.
+
+ Choose M here to compile this driver as a module, and it
+ will be called mtu3.ko.
+
+
+if USB_MTU3
+choice
+   bool "MTU3 Mode Selection"
+   default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET)
+   default USB_MTU3_HOST if (USB && !USB_GADGET)
+   default USB_MTU3_GADGET if (!USB && USB_GADGET)
+
+config USB_MTU3_HOST
+   bool "Host only mode"
+   depends on USB=y || USB=USB_MTU3
+   help
+ Select this when you want to use MTU3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_MTU3_GADGET
+   bool "Gadget only mode"
+   depends on USB_GADGET=y || USB_GADGET=USB_MTU3
+   help
+ Select this when you want to use MTU3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_MTU3_DUAL_ROLE
+   bool "Dual Role mode"
+   depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   help
+ This is the default mode of working of MTU3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+endif
diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile
new file mode 100644
index 000..4a66b01
--- /dev/null
+++ b/drivers/usb/mtu3/Makefile
@@ -0,0 +1,20 @@
+
+#ifeq ($(CONFIG_USB_DEBUG),y)
+   ccflags-y   += -DDEBUG
+#endif
+
+obj-$(CONFIG_USB_MTU3) += mtu3.o
+
+mtu3-y := mtu3_plat.o
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o mtu3_qmu.o
+endif
+
+ifneq ($(CONFIG_USB_MTU3_DUAL_ROLE),)
+   mtu3-y  += mtu3_dr.o
+endif
\ No newline at end of file
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
new file mod

[PATCH v3,5/5] arm64: dts: mediatek: add USB3 DRD driver

[Chunfeng Yun]

USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   46 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   28 
 2 files changed, 65 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
 
chosen { };
 
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = <&pio 16 GPIO_ACTIVE_HIGH>;
+   };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   usb_p0_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
 };
 
 &i2c1 {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+   usb_id_pins_float: usb_iddig_pull_up {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   usb_id_pins_ground: usb_iddig_pull_down {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-down;
+   };
+   };
 };
 
 &pwm0 {
@@ -431,12 +460,25 @@
status = "okay";
 };
 
+&ssusb {
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p0_vbus>;
+   extcon = <&extcon_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-0 = <&usb_id_pins_float>;
+   pinctrl-1 = <&usb_id_pins_float>;
+   pinctrl-2 = <&usb_id_pins_ground>;
+   status = "okay";
+};
+
 &uart0 {
status = "okay";
 };
 
-&usb30 {
+&usb_host {
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p1_vbus>;
-   mediatek,wakeup-src = <1>;
+   status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 05f89c4..723ab6e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -608,11 +608,14 @@
status = "disabled";
};
 
-   usb30: usb@1127 {
-   compatible = "mediatek,mt8173-xhci";
-   reg = <0 0x1127 0 0x1000>,
+   ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
-   interrupts = ;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
 <&pericfg CLK_PERI_USB0>,
@@ -620,10 +623,21 @@
clock-names = "sys_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
-   phys = <&phy_port0 PHY_TYPE_USB3>,
-  <&phy_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <&pericfg>;
-   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys 
MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   status = "disabled";
+   };
};
 
u3phy: usb-phy@1129 {
-- 
1.7.9.5

[PATCH v3,2/5] dt-bindings: mt8173-mtu3: add devicetree bindings

[Chunfeng Yun]

add a DT binding doc for MediaTek USB3 DRD driver

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
new file mode 100644
index 000..571ae8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -0,0 +1,85 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+   depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+   with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+   parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+   when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+   "id_float" and "id_ground" are optinal which depends on
+   "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via sysfs; only used
+   when receptacle is TYPE-A and also wants to support dual-role mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p0_vbus>;
+   extcon = <&extcon_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   mediatek,syscon-wakeup = <&pericfg>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <&mt6397_vusb_reg>;
+   status = "disabled";
+   };
+};
-- 
1.7.9.5

[PATCH v3,1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

[Chunfeng Yun]

Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.

Additionally add optional properties of pinctrl for host only mode

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 
 1 file changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..bec2dff 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,6 +2,14 @@ MT8173 xHCI
 
 The device node for Mediatek SOC USB3.0 host controller
 
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
  - reg : specifies physical base address and size of the registers,
@@ -27,6 +35,9 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
  - vbus-supply : reference to the VBUS regulator;
  - usb3-lpm-capable : supports USB3.0 LPM
+ - pinctrl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 
 Example:
 usb30: usb@1127 {
@@ -49,3 +60,40 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <&pericfg>;
mediatek,wakeup-src = <1>;
 };
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   should be only for xHCI IP registers
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must be
+   "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <&mt6397_vusb_reg>;
+   usb3-lpm-capable;
+};
-- 
1.7.9.5

Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

>From 8fdc924cecf0ca14da6e8aba360501e53437e548 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Fri, 10 Jun 2016 15:20:20 +0800
Subject: [PATCH 0/5] Add MediaTek USB3 DRD Driver

These patches introduce the MediaTek USB3 dual-role controller
driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only (xHCI) modes. It works well
with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
tested on MT8173 platform which only contains USB2.0 device IP,
and on MT6290 platform which contains USB3.0 device IP.

Change in v3:
1. fix some typo error
2. rename mtu3.txt to mt8173-mtu3.txt

Change in v2:
1. modify binding docs according to suggestions
2. modify some comments and remove some dummy blank lines
3. fix memory leakage

Chunfeng Yun (5):
  dt-bindings: mt8173-xhci: support host side of dual-role mode
  dt-bindings: mt8173-mtu3: add devicetree bindings
  usb: xhci-mtk: make IPPC register optional
  usb: Add MediaTek USB3 DRD Driver
  arm64: dts: mediatek: add USB3 DRD driver

 .../devicetree/bindings/usb/mt8173-mtu3.txt|   85 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   28 +-
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/host/xhci-mtk.c|   32 +-
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 ++
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 
 drivers/usb/mtu3/mtu3_dr.h |  108 +++
 drivers/usb/mtu3/mtu3_gadget.c |  731 
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 +++
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 +++
 drivers/usb/mtu3/mtu3_qmu.c|  599 +
 drivers/usb/mtu3/mtu3_qmu.h|   43 +
 20 files changed, 5562 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

--
1.7.9.5

Re: [PATCH 3/3] mfd: hi655x-pmic: Add powerkey device to hi655x PMIC driver

[John Stultz]

On Fri, Jun 10, 2016 at 12:32 AM, Lee Jones  wrote:
> On Thu, 09 Jun 2016, John Stultz wrote:
>
>> +static struct resource pwrkey_resources[] = {
>> + {
>> + .name   = "down",
>> + .start  = 6,
>> + .end= 6,
>> + .flags  = IORESOURCE_IRQ,
>> + }, {
>> + .name   = "up",
>> + .start  = 5,
>> + .end= 5,
>> + .flags  = IORESOURCE_IRQ,
>> + }, {
>> + .name   = "hold 4s",
>> + .start  = 4,
>> + .end= 4,
>> + .flags  = IORESOURCE_IRQ,
>> + },
>> +};
>
> No idea what 4, 5 and 6 mean.  Please define them.

Fair enough. It already defines PWRON_D4SR_INT, PWRON_D20F_INT and
PWRON_D20R_INT, but those are unfortunately mask values. I'll add a
patch to rename those to be clearly mask values and generate them from
a proper define value as well.

>> +static const struct mfd_cell hi655x_pmic_devs[] = {
>> + {
>> + .name   = "hi655x-regulator",
>> + },
>> + {
>> + .name   = "hi65xx-powerkey",
>> + .num_resources  = ARRAY_SIZE(pwrkey_resources),
>> + .resources  = &pwrkey_resources[0],
>> + },
>> +};
>
> Nit: Place the -regulator entry at the bottom and turn it into a one
> liner:
>
> { .name = "hi655x-regulator", },

Sure.  Will do!

Thanks for the feedback!
-john

Re: [PATCH 2/4] ASoC: sunxi: Add Allwinner A10 Digital Audio driver

[Maxime Ripard]

Hi Mark,

On Fri, Jun 10, 2016 at 01:37:55AM +0100, Mark Brown wrote:
> > > > +static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
> > > > +{
> > > > +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
> 
> > > > +   /* Enable the whole hardware block */
> > > > +   regmap_write(i2s->regmap, SUN4I_I2S_CTRL_REG,
> > > > +SUN4I_I2S_CTRL_GL_EN);
> 
> > > Runtime PM?  It also seems like this is something that ought to be
> > > covered in the suspend and resume callbacks.
> 
> > runtime_pm is supported, and uses the regmap cache to keep those
> > changes.
> 
> No, my point is that I'd expect to see the block powered off on suspend.

It is. The bus clock is disabled, which also puts the IP in reset.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

[Marc Zyngier]

On Thu, 9 Jun 2016 21:00:08 -0700
Doug Anderson  wrote:

Hi Doug,

> Shawn,
> 
> On Wed, Jun 8, 2016 at 1:05 AM, Shawn Lin  wrote:
> > This patch adds Rockchip PCIe controller support found
> > on RK3399 Soc platform.
> >
> > Signed-off-by: Shawn Lin 
> >
> > ---
> >
> > Changes in v2:
> > - remove phy related stuff and call phy API
> > - add new head file and define lots of macro to make
> >   the code more readable
> > - remove lots msi related code suggested by Marc
> > - add IO window address translation
> > - init_port and parse_dt reconstruction suggested by Bharat
> > - improve wr_own_conf suggested by Arnd
> > - make pcie as an interrupt controller and fix wrong int handler
> >   suggested by Marc
> > - remove PCI_PROBE_ONLY suggested by Lorenzo
> >
> >  drivers/pci/host/Kconfig |   11 +
> >  drivers/pci/host/Makefile|1 +
> >  drivers/pci/host/pcie-rockchip.c | 1049 
> > ++
> >  drivers/pci/host/pcie-rockchip.h |  209 
> >  4 files changed, 1270 insertions(+)
> 
> A few drive-by comments for things I ran into trying to get this
> working.  I'm no PCI expert.
> 
> 
> > +config PCIE_ROCKCHIP
> > +   bool "Rockchip PCIe controller"
> > +   depends on ARM64 && ARCH_ROCKCHIP
> > +   depends on OF
> > +   select MFD_SYSCON
> > +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> 
> Probably because I don't know what I'm doing, but when I had PCI_MSI
> configured I had trouble getting interrupts.  Figured I'd mention it
> even though it's probably user error.

Could you please elaborate on this? Do you see MSIs being
allocated but not delivered? Or something else?

The reason I'm asking is that it is very easy to end-up with MSIs
issues with the GICv3 ITS if there is *anything* between the RC and the
ITS. Typically, you'd have an SMMU that could potentially remap PCIe
Requested IDs to Device IDs. Short of describing transformations in the
msi-map property, you could end-up with no MSI being delivered.

Please let me know if I can help.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH V2 4/5] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Enric Balletbo Serra]

Hi Peter,

Only a few comments ;)

2016-06-09 18:25 GMT+02:00 Peter Senna Tschudin :
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> CC: David Airlie 
> CC: Thierry Reding 
> CC: Thierry Reding 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>  - New commit message
>  - Removed 3 empty entry points
>  - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
>  - Added a lock for mode setting
>  - Removed a few blank lines
>  - Changed the order at Makefile and Kconfig
>
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/bridge/Kconfig |  11 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 392 
> +
>  4 files changed, 412 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2ce5e91..2dd3d7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5010,6 +5010,14 @@ W:   https://linuxtv.org
>  S: Maintained
>  F: drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M: Martin Donnelly 
> +M: Peter Senna Tschudin 
> +M: Martyn Welch 
> +S: Maintained
> +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
>  GENERIC GPIO I2C DRIVER
>  M: Haavard Skinnemoen 
>  S: Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..93dae5bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
>   Designware HDMI block.  This is used in conjunction with
>   the i.MX6 HDMI driver.
>
> +config DRM_GE_B850V3_LVDS_DP
> +   tristate "GE B850v3 LVDS to DP++ display bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> +  This is a driver for the display bridge of
> +  GE B850v3 that convert dual channel LVDS
> +  to DP++. This is used with the i.MX6 imx-ldb
> +  driver.
> +
>  config DRM_NXP_PTN3460
> tristate "NXP PTN3460 DP/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..47ea6c1 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..c73cd77
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,392 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope 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.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> +
> + * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> + * display bridge of the GE B850v3. There are two physical bridges on the 
> video
> + * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). 
> However
> + * the physical bridges are au

Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616

[Michal Hocko]

On Fri 10-06-16 16:24:59, Sergey Senozhatsky wrote:
> that was fast!
> 
> On (06/10/16 08:34), Michal Hocko wrote:
> [..]
> > OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> > ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> > I think we need the following. Andrew could you fold it into
> > mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> > it as a separate patch?
> > 
> > [1] 
> > http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mho...@kernel.org
> > 
> > Thanks for the report Sergey!
> 
> after quick tests -- works for me. please see below.
[...]
> so the first bio_alloc() is ok now. what about the second bio_alloc()
> in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?

Sure, early morning for me... Thanks for catching that.
---
>From a2712312c0a36506ba003747c593dfbdf8eaa8be Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Fri, 10 Jun 2016 08:27:33 +0200
Subject: [PATCH] mm: restrict gfp mask in mpage_alloc

Sergey has reported that we might hit BUG_ON in new_slab() because
unrestricted gfp mask used for the readahead purposes contains
incompatible flags (__GFP_HIGHMEM in his case):
[  429.191962] gfp: 2
[  429.192634] [ cut here ]
[  429.193281] kernel BUG at mm/slub.c:1616!
[...]
[  429.217369]  [] bio_alloc_bioset+0xbd/0x1b1
[  429.218013]  [] mpage_alloc+0x28/0x7b
[  429.218650]  [] do_mpage_readpage+0x43d/0x545
[  429.219282]  [] mpage_readpages+0xf5/0x152

Make sure that mpage_alloc always restricts the mask to GFP_KERNEL subset.
This is what was done before "mm, memcg: use consistent gfp flags during
readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
mpage_readpages.

Reported-by: Sergey Senozhatsky 
Signed-off-by: Michal Hocko 
---
 fs/mpage.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/mpage.c b/fs/mpage.c
index 9c11255b0797..c8a05901a37b 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -71,6 +71,8 @@ mpage_alloc(struct block_device *bdev,
 {
struct bio *bio;
 
+   /* Restrict the given (page cache) mask for slab allocations */
+   gfp_flags &= GFP_KERNEL;
bio = bio_alloc(gfp_flags, nr_vecs);
 
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
-- 
2.8.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero

[Lee Jones]

On Fri, 10 Jun 2016, Lothar Waßmann wrote:

> Hi,
> 
> On Thu, 9 Jun 2016 14:51:25 +0100 Lee Jones wrote:
> > On Tue, 07 Jun 2016, Lothar Waßmann wrote:
> > 
> > > 'brightness' is usually an index into a table of duty_cycle values,
> > > where the value at index 0 may well be non-zero
> > > (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life
> > > examples).
> > > Thus brightness == 0 does not necessarily mean that the PWM output
> > > will be inactive.
> > > Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide
> > > whether to disable the PWM.
> > > 
> > > Signed-off-by: Lothar Waßmann 
> > > ---
> > > Changes wrt. v1:
> > >   - update binding docs to reflect the change
> > > 
> > >  .../devicetree/bindings/leds/backlight/pwm-backlight.txt | 9 
> > > ++---
> > >  drivers/video/backlight/pwm_bl.c | 4 ++--
> > >  2 files changed, 8 insertions(+), 5 deletions(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt 
> > > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > index 764db86..95fa8a9 100644
> > > --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > @@ -4,10 +4,13 @@ Required properties:
> > >- compatible: "pwm-backlight"
> > >- pwms: OF device-tree PWM specification (see PWM binding[0])
> > >- brightness-levels: Array of distinct brightness levels. Typically 
> > > these
> > > -  are in the range from 0 to 255, but any range starting at 0 will 
> > > do.
> > > +  are in the range from 0 to 255, but any range will do.
> > >The actual brightness level (PWM duty cycle) will be interpolated
> > > -  from these values. 0 means a 0% duty cycle (darkest/off), while the
> > > -  last value in the array represents a 100% duty cycle (brightest).
> > > +  from these values. 0 means a 0% duty cycle, while the highest 
> > > value in
> > > +  the array represents a 100% duty cycle.
> > > +  The range may be in reverse order (starting with the maximum duty 
> > > cycle
> > > +  value) to create a PWM signal with the 100% duty cycle representing
> > > +  minimum and 0% duty cycle maximum brigthness.
> > >- default-brightness-level: the default brightness level (index into 
> > > the
> > >array defined by the "brightness-levels" property)
> > >- power-supply: regulator for supply voltage
> > > diff --git a/drivers/video/backlight/pwm_bl.c 
> > > b/drivers/video/backlight/pwm_bl.c
> > > index b2b366b..80b2b52 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -103,8 +103,8 @@ static int pwm_backlight_update_status(struct 
> > > backlight_device *bl)
> > >   if (pb->notify)
> > >   brightness = pb->notify(pb->dev, brightness);
> > >  
> > > - if (brightness > 0) {
> > > - duty_cycle = compute_duty_cycle(pb, brightness);
> > > + duty_cycle = compute_duty_cycle(pb, brightness);
> > > + if (duty_cycle > 0) {
> > 
> > How does this work in the aforementioned:
> > 
> >   "The range may be in reverse order"
> > 
> > ... case?  Surely when duty_cycle is when the screen should be at it's
> > brightest?  Wouldn't it confuse the user if they turn their brightness
> > *up* and the screen goes *off*?
> > 
> Assuming that the PWM output is inactive (LOW) when the duty_cycle is
> set to zero, there will be no difference between operating the PWM at
> duty_cycle 0 or disabling it.
> 
> Currently, the screen will go bright when it should be off in this
> case.

It sounds like we need something that lets the framework know if
duty_cycle = MAX is the brightest or if duty_cycle = 0 is.  Either way
someone is going to get screwed by this logic.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 07/06/16 14:49, Grygorii Strashko wrote:
> On 06/07/2016 12:34 PM, Roger Quadros wrote:
>> On 02/06/16 14:52, Grygorii Strashko wrote:
>>> On 06/01/2016 10:46 AM, Roger Quadros wrote:
 Implementations might use different IRQs for
 host, gadget and OTG so use named interrupt resources
 to allow Device tree to specify the 3 interrupts.

 Following are the interrupt names

 Peripheral Interrupt - peripheral
 HOST Interrupt - host
 OTG Interrupt - otg
>>>
>>> or "dwc_usb3"??
>>
>> That is for backward compatibility only. I could explicitly
>> mention it in the next line.
> 
> yes pls, this confuses.
>  Also I don't see how "otg" irq name is used in code.
> 
>>
>>>

 We still maintain backward compatibility for a single named
 interrupt for all 3 interrupts (e.g. for dwc3-pci) and
 single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>>
>>> bindings
>>
>> OK.
>>>

 Signed-off-by: Roger Quadros 
 ---
 v9: rebased on top of balbi/testing/next

drivers/usb/dwc3/core.c   | 10 --
drivers/usb/dwc3/gadget.c | 20 ++--
drivers/usb/dwc3/host.c   | 19 +++
3 files changed, 37 insertions(+), 12 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 9c4e1d8d..5cedf3d 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;

 -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 -if (!res) {
 -dev_err(dev, "missing IRQ\n");
 -return -ENODEV;
 -}
 -dwc->xhci_resources[1].start = res->start;
 -dwc->xhci_resources[1].end = res->end;
 -dwc->xhci_resources[1].flags = res->flags;
 -dwc->xhci_resources[1].name = res->name;
 -
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index c37168d..c18c72f 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
intret = 0;
intirq;

 -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
 +irq = dwc->irq_gadget;
ret = request_threaded_irq(irq, dwc3_interrupt, 
 dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
 @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
irq, ret);
goto err0;
}
 -dwc->irq_gadget = irq;

spin_lock_irqsave(&dwc->lock, flags);
if (dwc->gadget_driver) {
 @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
 *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
intret;
 +struct resource *res;
 +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
 +
 +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
 +if (dwc->irq_gadget <= 0) {
>>>
>>> Is it expected to get -EPROBE_DEFER here?
>>
>> Probably not as we don't have any chance of deferring probe here. We've 
>> already
>> probed successfully and are just turning on the gadget mode here.
> 

I was mistaken here.

dwc3_gadget_init() and dwc3_host_init() get called during dwc3_core_init_mode() 
which is
in fact called during probe().

So I'll add take care -EPROBE_DEFER in the next revision.

> In general, you can't say that you've been probed successfully if not all 
> resources are ready,
> and irq is a resource :)
> It's expected that all resources will be requested in probe, but here you are 
> trying to get
> resource outside of probe. As result, it will be perfectly possible to get 
> -EPROBE_DEFER here
> if on some HW GPIO IRQ will be used as peripheral, or host or otg irq (for 
> example), because 
> GPIO IRQ controller might not be ready at the moment when IRQ resource is 
> requested.
> 

--
cheers,
-roger

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

Grygorii,

On 02/06/16 14:52, Grygorii Strashko wrote:
> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>> Implementations might use different IRQs for
>> host, gadget and OTG so use named interrupt resources
>> to allow Device tree to specify the 3 interrupts.
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
> 
> or "dwc_usb3"??
> 
>>
>> We still maintain backward compatibility for a single named
>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
> 
> bindings
> 
>>
>> Signed-off-by: Roger Quadros 
>> ---
>> v9: rebased on top of balbi/testing/next
>>
>>   drivers/usb/dwc3/core.c   | 10 --
>>   drivers/usb/dwc3/gadget.c | 20 ++--
>>   drivers/usb/dwc3/host.c   | 19 +++
>>   3 files changed, 37 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 9c4e1d8d..5cedf3d 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>   dwc->mem = mem;
>>   dwc->dev = dev;
>>
>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> -if (!res) {
>> -dev_err(dev, "missing IRQ\n");
>> -return -ENODEV;
>> -}
>> -dwc->xhci_resources[1].start = res->start;
>> -dwc->xhci_resources[1].end = res->end;
>> -dwc->xhci_resources[1].flags = res->flags;
>> -dwc->xhci_resources[1].name = res->name;
>> -
>>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>   if (!res) {
>>   dev_err(dev, "missing memory resource\n");
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index c37168d..c18c72f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>   intret = 0;
>>   intirq;
>>
>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>> +irq = dwc->irq_gadget;
>>   ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
>>   IRQF_SHARED, "dwc3", dwc->ev_buf);
>>   if (ret) {
>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>   irq, ret);
>>   goto err0;
>>   }
>> -dwc->irq_gadget = irq;
>>
>>   spin_lock_irqsave(&dwc->lock, flags);
>>   if (dwc->gadget_driver) {
>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
>>   int dwc3_gadget_init(struct dwc3 *dwc)
>>   {
>>   intret;
>> +struct resource *res;
>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>> +if (dwc->irq_gadget <= 0) {
> 
> Is it expected to get -EPROBE_DEFER here?
> 
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
>> +  "dwc_usb3");
>> +if (dwc->irq_gadget <= 0) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
> 
> It's better to use platform_get_irq().
> 
>> +if (!res) {
>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>> +return -ENODEV;
>> +}
>> +dwc->irq_gadget = res->start;
>> +}
>> +}
>>
>>   dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>>   &dwc->ctrl_req_addr, GFP_KERNEL);
>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>> index c679f63..f2b60a4 100644
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   struct platform_device*xhci;
>>   struct usb_xhci_pdatapdata;
>>   intret;
>> +struct resource*res;
>> +struct platform_device*dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ, "host");
>> +if (!res) {
>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
>> +   "dwc_usb3");
>> +if (!res) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
>> +if (!res)
> 
>> +return -ENOMEM;
>> +}
>> +}
> 
> Is it expected to have more than one IRQ here?
> 
> if not - it will better to use platform_get_irq[_byname]().
> 

The reason I used platform_get_resource variant is that i'm passing the
resource directly to the XHCI platform device below.
> 
>> +
>> +dwc->xhci_resources[1].start = res->start;
>> +dwc->xhci_resources[1].end = res->end;
>> +dwc->xhci_resources[1].flags = res->flags;
>> +dwc->xhci_resources[1].name = res->name;

This coul

Re: [PATCH v2 5/7] drm: rockchip: use common iommu api to attach iommu

[Tomasz Figa]

Hi,

On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng  wrote:
> Rockchip DRM used the arm special API, arm_iommu_*(), to attach
> iommu for ARM32 SoCs. This patch convert to common iommu API
> so it would support ARM64 like RK3399.
>
> The general idea is domain_alloc(), attach_device() and
> arch_setup_dma_ops() to set dma_ops manually for DRM at the last.
>
> Signed-off-by: Shunqian Zheng 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 130 
> +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
>  2 files changed, 89 insertions(+), 42 deletions(-)
>

Please see my comments inline.

> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index f5a68fc..7965a66 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -14,8 +14,6 @@
>   * GNU General Public License for more details.
>   */
>
> -#include 
> -
>  #include 
>  #include 
>  #include 
> @@ -24,6 +22,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_fb.h"
> @@ -46,7 +46,8 @@ static bool is_support_iommu = true;
>  int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
>struct device *dev)
>  {
> -   struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
> +   struct rockchip_drm_private *private = drm_dev->dev_private;
> +   struct iommu_domain *domain = private->domain;
> int ret;
>
> if (!is_support_iommu)
> @@ -58,16 +59,25 @@ int rockchip_drm_dma_attach_device(struct drm_device 
> *drm_dev,
>
> dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
>
> -   return arm_iommu_attach_device(dev, mapping);
> +   ret = iommu_attach_device(domain, dev);
> +

nit: Unnecessary blank line.

> +   if (ret) {
> +   dev_err(dev, "Failed to attach iommu device\n");
> +   return ret;
> +   }

nit: On the other hand, a blank line here would improve readability.

> +   arch_setup_dma_ops(dev, 0x, SZ_2G,
> +  (struct iommu_ops *)dev->bus->iommu_ops, false);

This is casting a const pointer to a non-const pointer. which isn't
really a good idea. I can see that arch_setup_dma_ops() requires a
writable pointer, though. Looking at the implementations of
arch_setup_dma_ops() around the platforms (namely arm and arm64...),
it makes me wonder if the prototype shouldn't be changed to const
instead.

> +   return 0;
>  }
>
>  void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
> struct device *dev)
>  {
> -   if (!is_support_iommu)
> -   return;
> +   struct rockchip_drm_private *private = drm_dev->dev_private;
> +   struct iommu_domain *domain = private->domain;
>
> -   arm_iommu_detach_device(dev);
> +   if (is_support_iommu)
> +   iommu_detach_device(domain, dev);
>  }
>
>  int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
> @@ -132,10 +142,70 @@ static void rockchip_drm_crtc_disable_vblank(struct 
> drm_device *dev,
> priv->crtc_funcs[pipe]->disable_vblank(crtc);
>  }
>
> +static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
> +{
> +   struct rockchip_drm_private *private = drm_dev->dev_private;
> +   struct device *dev = drm_dev->dev;
> +   int ret;
> +
> +   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> + GFP_KERNEL);
> +   if (!dev->dma_parms) {
> +   ret = -ENOMEM;
> +   return ret;

nit: return -ENOMEM;

> +   }
> +
> +   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> +   if (ret) {
> +   dev_err(dev, "Failed to set coherent mask\n");
> +   return ret;
> +   }
> +
> +   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +
> +   private->domain = iommu_domain_alloc(&platform_bus_type);
> +   if (!private->domain)
> +   return -ENOMEM;
> +
> +   ret = iommu_get_dma_cookie(private->domain);
> +   if (ret) {
> +   dev_err(dev, "Failed to get dma cookie\n");
> +   goto err_free_domain;
> +   }
> +
> +   ret = iommu_dma_init_domain(private->domain, 0x, SZ_2G);

I guess djkurtz's TODO comment could be preserved here.

Best regards,
Tomasz

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 10/06/16 11:02, Roger Quadros wrote:
> Grygorii,
> 
> On 02/06/16 14:52, Grygorii Strashko wrote:
>> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>>> Implementations might use different IRQs for
>>> host, gadget and OTG so use named interrupt resources
>>> to allow Device tree to specify the 3 interrupts.
>>>
>>> Following are the interrupt names
>>>
>>> Peripheral Interrupt - peripheral
>>> HOST Interrupt - host
>>> OTG Interrupt - otg
>>
>> or "dwc_usb3"??
>>
>>>
>>> We still maintain backward compatibility for a single named
>>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>
>> bindings
>>
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>> v9: rebased on top of balbi/testing/next
>>>
>>>   drivers/usb/dwc3/core.c   | 10 --
>>>   drivers/usb/dwc3/gadget.c | 20 ++--
>>>   drivers/usb/dwc3/host.c   | 19 +++
>>>   3 files changed, 37 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 9c4e1d8d..5cedf3d 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>>   dwc->mem = mem;
>>>   dwc->dev = dev;
>>>
>>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>> -if (!res) {
>>> -dev_err(dev, "missing IRQ\n");
>>> -return -ENODEV;
>>> -}
>>> -dwc->xhci_resources[1].start = res->start;
>>> -dwc->xhci_resources[1].end = res->end;
>>> -dwc->xhci_resources[1].flags = res->flags;
>>> -dwc->xhci_resources[1].name = res->name;
>>> -
>>>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>   if (!res) {
>>>   dev_err(dev, "missing memory resource\n");
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index c37168d..c18c72f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>   intret = 0;
>>>   intirq;
>>>
>>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>>> +irq = dwc->irq_gadget;
>>>   ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
>>>   IRQF_SHARED, "dwc3", dwc->ev_buf);
>>>   if (ret) {
>>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>   irq, ret);
>>>   goto err0;
>>>   }
>>> -dwc->irq_gadget = irq;
>>>
>>>   spin_lock_irqsave(&dwc->lock, flags);
>>>   if (dwc->gadget_driver) {
>>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
>>> *_evt)
>>>   int dwc3_gadget_init(struct dwc3 *dwc)
>>>   {
>>>   intret;
>>> +struct resource *res;
>>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>>> +
>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>>> +if (dwc->irq_gadget <= 0) {
>>
>> Is it expected to get -EPROBE_DEFER here?
>>
>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
>>> +  "dwc_usb3");
>>> +if (dwc->irq_gadget <= 0) {
>>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>>> +0);
>>
>> It's better to use platform_get_irq().
>>
>>> +if (!res) {
>>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>>> +return -ENODEV;
>>> +}
>>> +dwc->irq_gadget = res->start;
>>> +}
>>> +}
>>>
>>>   dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>>>   &dwc->ctrl_req_addr, GFP_KERNEL);
>>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>>> index c679f63..f2b60a4 100644
>>> --- a/drivers/usb/dwc3/host.c
>>> +++ b/drivers/usb/dwc3/host.c
>>> @@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
>>>   struct platform_device*xhci;
>>>   struct usb_xhci_pdatapdata;
>>>   intret;
>>> +struct resource*res;
>>> +struct platform_device*dwc3_pdev = to_platform_device(dwc->dev);
>>> +
>>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ, "host");
>>> +if (!res) {
>>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
>>> +   "dwc_usb3");
>>> +if (!res) {
>>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>>> +0);
>>> +if (!res)
>>
>>> +return -ENOMEM;
>>> +}
>>> +}
>>
>> Is it expected to have more than one IRQ here?
>>
>> if not - it will better to use platform_get_irq[_byname]().
>>
> 
> The reason I used platform_get_resource variant is that i'm passing the
> resource directly to the XHCI platform device below.
>>
>>> +
>>> +dwc->xhci_resources[1].

Re: [PATCH V5 4/9] genirq: Add runtime power management support for IRQ chips

[Jon Hunter]

On 09/06/16 23:56, Kevin Hilman wrote:
> Jon Hunter  writes:
> 
>> On 06/06/16 15:36, Grygorii Strashko wrote:
>>> On 06/06/2016 05:30 PM, Jon Hunter wrote:

 On 06/06/16 15:13, Grygorii Strashko wrote:
> On 06/06/2016 02:53 PM, Jon Hunter wrote:
>> Some IRQ chips may be located in a power domain outside of the CPU
>> subsystem and hence will require device specific runtime power
>> management. In order to support such IRQ chips, add a pointer for a
>> device structure to the irq_chip structure, and if this pointer is
>> populated by the IRQ chip driver and CONFIG_PM is selected in the kernel
>> configuration, then the pm_runtime_get/put APIs for this chip will be
>> called when an IRQ is requested/freed, respectively.
>>
>> Signed-off-by: Jon Hunter 
>> Reviewed-by: Kevin Hilman 
>> Reviewed-by: Marc Zyngier 
>> ---
>>include/linux/irq.h|  4 
>>kernel/irq/chip.c  | 35 +++
>>kernel/irq/internals.h |  1 +
>>kernel/irq/manage.c| 31 ++-
>>4 files changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/irq.h b/include/linux/irq.h
>> index 4d758a7c604a..6c92a847394d 100644
>> --- a/include/linux/irq.h
>> +++ b/include/linux/irq.h
>> @@ -315,6 +315,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct 
>> irq_data *d)
>>/**
>> * struct irq_chip - hardware interrupt chip descriptor
>> *
>> + * @parent_device:  pointer to parent device for irqchip
>> * @name: name for /proc/interrupts
>> * @irq_startup:  start up the interrupt (defaults to ->enable if 
>> NULL)
>> * @irq_shutdown: shut down the interrupt (defaults to ->disable 
>> if NULL)
>> @@ -354,6 +355,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct 
>> irq_data *d)
>> * @flags:chip specific flags
>> */
>>struct irq_chip {
>> +struct device   *parent_device;
>>  const char  *name;
>>  unsigned int(*irq_startup)(struct irq_data *data);
>>  void(*irq_shutdown)(struct irq_data *data);
>> @@ -488,6 +490,8 @@ extern void handle_bad_irq(struct irq_desc *desc);
>>extern void handle_nested_irq(unsigned int irq);
>>
>>extern int irq_chip_compose_msi_msg(struct irq_data *data, struct 
>> msi_msg *msg);
>> +extern int irq_chip_pm_get(struct irq_data *data);
>> +extern int irq_chip_pm_put(struct irq_data *data);
>>#ifdefCONFIG_IRQ_DOMAIN_HIERARCHY
>>extern void irq_chip_enable_parent(struct irq_data *data);
>>extern void irq_chip_disable_parent(struct irq_data *data);
>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
>> index 2f9f2b0e79f2..b09226e895c7 100644
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -1093,3 +1093,38 @@ int irq_chip_compose_msi_msg(struct irq_data 
>> *data, struct msi_msg *msg)
>>
>>  return 0;
>>}
>> +
>> +/**
>> + * irq_chip_pm_get - Enable power for an IRQ chip
>> + * @data:   Pointer to interrupt specific data
>> + *
>> + * Enable the power to the IRQ chip referenced by the interrupt data
>> + * structure.
>> + */
>> +int irq_chip_pm_get(struct irq_data *data)
>> +{
>> +int retval = 0;
>> +
>> +if (IS_ENABLED(CONFIG_PM) && data->chip->parent_device)
>> +retval = pm_runtime_get_sync(data->chip->parent_device);
>
> Sry, for the late comment - above require 
> pm_runtime_put_noidle(data->chip->parent_device);
> in case of failure.

 No problem. Sorry, can you elaborate? I am not familiar with the
 _put_noidle().

>>>
>>> Question here in use counter - pm_runtime_get_sync() will increment 
>>> usage_count
>>> always and it will not decrement it in case of failure.
>>> pm_runtime_put_noidle() expected to restore usage_count state (-1).
>>
>> Thanks was not aware of that. 
>>
>> Kevin, Marc, given that you have reviewed this one, are you ok with the
>> above change Grygorii is proposing? 
> 
> Yes, that's the right thing to do on error.

Thanks. I have added this in V6. Please take a look and add your
reviewed-by again if all looks good.

Cheers
Jon

-- 
nvpublic

[PATCH 0/2] ARM: dts: sunxi: Re-order sun4i and sun7i pinctrl nodes alphabetically

[Aleksei Mamlin]

Hello,

This patchset have no functional changes, only sorting sun4i and sun7i pinctrl
nodes in alphabetical order.

Aleksei Mamlin (2):
  ARM: dts: sun4i: Re-order pinctrl nodes alphabetically
  ARM: dts: sun7i: Re-order pinctrl nodes alphabetically

 arch/arm/boot/dts/sun4i-a10.dtsi | 114 
 arch/arm/boot/dts/sun7i-a20.dtsi | 284 +++
 2 files changed, 199 insertions(+), 199 deletions(-)

-- 
2.7.3

[PATCH 2/2] ARM: dts: sun7i: Re-order pinctrl nodes alphabetically

[Aleksei Mamlin]

No functional change. Re-order sun7i pinctrl nodes alphabetically.

Signed-off-by: Aleksei Mamlin 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 284 +++
 1 file changed, 142 insertions(+), 142 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 82e28c3..de4231e 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1030,160 +1030,177 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
 
-   pwm0_pins_a: pwm0@0 {
-   allwinner,pins = "PB2";
-   allwinner,function = "pwm";
+   clk_out_a_pins_a: clk_out_a@0 {
+   allwinner,pins = "PI12";
+   allwinner,function = "clk_out_a";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   pwm1_pins_a: pwm1@0 {
-   allwinner,pins = "PI3";
-   allwinner,function = "pwm";
+   clk_out_b_pins_a: clk_out_b@0 {
+   allwinner,pins = "PI13";
+   allwinner,function = "clk_out_b";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart0_pins_a: uart0@0 {
-   allwinner,pins = "PB22", "PB23";
-   allwinner,function = "uart0";
+   emac_pins_a: emac0@0 {
+   allwinner,pins = "PA0", "PA1", "PA2",
+   "PA3", "PA4", "PA5", "PA6",
+   "PA7", "PA8", "PA9", "PA10",
+   "PA11", "PA12", "PA13", "PA14",
+   "PA15", "PA16";
+   allwinner,function = "emac";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart2_pins_a: uart2@0 {
-   allwinner,pins = "PI16", "PI17", "PI18", "PI19";
-   allwinner,function = "uart2";
+   gmac_pins_mii_a: gmac_mii@0 {
+   allwinner,pins = "PA0", "PA1", "PA2",
+   "PA3", "PA4", "PA5", "PA6",
+   "PA7", "PA8", "PA9", "PA10",
+   "PA11", "PA12", "PA13", "PA14",
+   "PA15", "PA16";
+   allwinner,function = "gmac";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart3_pins_a: uart3@0 {
-   allwinner,pins = "PG6", "PG7", "PG8", "PG9";
-   allwinner,function = "uart3";
-   allwinner,drive = ;
+   gmac_pins_rgmii_a: gmac_rgmii@0 {
+   allwinner,pins = "PA0", "PA1", "PA2",
+   "PA3", "PA4", "PA5", "PA6",
+   "PA7", "PA8", "PA10",
+   "PA11", "PA12", "PA13",
+   "PA15", "PA16";
+   allwinner,function = "gmac";
+   /*
+* data lines in RGMII mode use DDR mode
+* and need a higher signal drive strength
+*/
+   allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart3_pins_b: uart3@1 {
-   allwinner,pins = "PH0", "PH1";
-   allwinner,function = "uart3";
+   i2c0_pins_a: i2c0@0 {
+   allwinner,pins = "PB0", "PB1";
+   allwinner,function = "i2c0";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart4_pins_a: uart4@0 {
-   allwinner,pins = "PG10", "PG11";
-   allwinner,function = "uart4";
+   i2c1_pins_a: i2c1@0 {
+   allwinner,pins = "PB18", "PB19";
+   allwinner,function = "i2c1";
allwin

[PATCH 1/2] ARM: dts: sun4i: Re-order pinctrl nodes alphabetically

[Aleksei Mamlin]

No functional change. Re-order sun4i pinctrl nodes alphabetically.

Signed-off-by: Aleksei Mamlin 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 114 +++
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index a9c3190..6d9c7c70 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -958,69 +958,62 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
 
-   pwm0_pins_a: pwm0@0 {
-   allwinner,pins = "PB2";
-   allwinner,function = "pwm";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
-
-   pwm1_pins_a: pwm1@0 {
-   allwinner,pins = "PI3";
-   allwinner,function = "pwm";
+   emac_pins_a: emac0@0 {
+   allwinner,pins = "PA0", "PA1", "PA2",
+   "PA3", "PA4", "PA5", "PA6",
+   "PA7", "PA8", "PA9", "PA10",
+   "PA11", "PA12", "PA13", "PA14",
+   "PA15", "PA16";
+   allwinner,function = "emac";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart0_pins_a: uart0@0 {
-   allwinner,pins = "PB22", "PB23";
-   allwinner,function = "uart0";
+   i2c0_pins_a: i2c0@0 {
+   allwinner,pins = "PB0", "PB1";
+   allwinner,function = "i2c0";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart0_pins_b: uart0@1 {
-   allwinner,pins = "PF2", "PF4";
-   allwinner,function = "uart0";
+   i2c1_pins_a: i2c1@0 {
+   allwinner,pins = "PB18", "PB19";
+   allwinner,function = "i2c1";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   uart1_pins_a: uart1@0 {
-   allwinner,pins = "PA10", "PA11";
-   allwinner,function = "uart1";
+   i2c2_pins_a: i2c2@0 {
+   allwinner,pins = "PB20", "PB21";
+   allwinner,function = "i2c2";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   i2c0_pins_a: i2c0@0 {
-   allwinner,pins = "PB0", "PB1";
-   allwinner,function = "i2c0";
+   ir0_rx_pins_a: ir0@0 {
+   allwinner,pins = "PB4";
+   allwinner,function = "ir0";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   i2c1_pins_a: i2c1@0 {
-   allwinner,pins = "PB18", "PB19";
-   allwinner,function = "i2c1";
+   ir0_tx_pins_a: ir0@1 {
+   allwinner,pins = "PB3";
+   allwinner,function = "ir0";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   i2c2_pins_a: i2c2@0 {
-   allwinner,pins = "PB20", "PB21";
-   allwinner,function = "i2c2";
+   ir1_rx_pins_a: ir1@0 {
+   allwinner,pins = "PB23";
+   allwinner,function = "ir1";
allwinner,drive = ;
allwinner,pull = ;
};
 
-   emac_pins_a: emac0@0 {
-   allwinner,pins = "PA0", "PA1", "PA2",
-   "PA3", "PA4", "PA5", "PA6",
-   "PA7", "PA8", "PA9", "PA10",
-   "PA11", "PA12", "PA13", "PA14",
-   "PA15", "PA16";
-   allwinner,function = "emac";
+   ir1_tx_pins_a: ir1@1 {
+   allwinner

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> Is it expected to have more than one IRQ here?
>> 
>> if not - it will better to use platform_get_irq[_byname]().
>> 
>
> The reason I used platform_get_resource variant is that i'm passing the
> resource directly to the XHCI platform device below.
>> 
>>> +
>>> +dwc->xhci_resources[1].start = res->start;
>>> +dwc->xhci_resources[1].end = res->end;
>>> +dwc->xhci_resources[1].flags = res->flags;
>>> +dwc->xhci_resources[1].name = res->name;
>
> This could just change to
>
>   dwc->xhci_resource[1] = *res;

no, it cannot. Look at the definition of struct resource and how it's
used, then you'll see we don't want to copy everything.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>>  dwc->xhci_resource[1] = *res;
>
> Probably not as we don't want to change parent/child members.

oh, you had already replied. Sorry. This is correct

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 2/2] phy: ti-pipe3: Program the DPLL even if it was already locked

[Kishon Vijay Abraham I]

From: Roger Quadros 

If bootloader has set a wrong DPLL then we must trash those values
and re-program it anyways. This fixes USB3 devices not being enumerated
on beagle-x15 if usb was started in u-boot.

We don't re-program SATA DPLL if it is locked as it was causing
SATA failures if device was hotpluged after boot.

Reported-by: Robert Nelson 
Signed-off-by: Roger Quadros 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0a477d2..bf46844 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -293,11 +293,18 @@ static int ti_pipe3_init(struct phy *x)
ret = ti_pipe3_dpll_wait_lock(phy);
}
 
-   /* Program the DPLL only if not locked */
+   /* SATA has issues if re-programmed when locked */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
-   if (!(val & PLL_LOCK))
-   if (ti_pipe3_dpll_program(phy))
-   return -EINVAL;
+   if ((val & PLL_LOCK) && of_device_is_compatible(phy->dev->of_node,
+   "ti,phy-pipe3-sata"))
+   return ret;
+
+   /* Program the DPLL */
+   ret = ti_pipe3_dpll_program(phy);
+   if (ret) {
+   ti_pipe3_disable_clocks(phy);
+   return -EINVAL;
+   }
 
return ret;
 }
-- 
1.7.9.5

[GIT PULL] phy: for 4.7 -rc cycle

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for this -rc cycle below. It consists of a
couple of fixes in the phy drivers. Consider merging this in this -rc.

Let me know if you want me to change something.

Cheers
Kishon

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.7-rc

for you to fetch changes up to 31b2a32f708bb33b3f35b03ce3d2cb31f7d1e684:

  phy: ti-pipe3: Program the DPLL even if it was already locked (2016-06-03 
12:06:41 +0530)


phy: for 4.7-rc

*) Fix compiler warning in exynos-mipi-video
*) Fix in ti-pipe3 PHY to program the DPLL
   even if it was already locked

Signed-off-by: Kishon Vijay Abraham I 


Arnd Bergmann (1):
  phy: exynos-mipi-video: avoid uninitialized variable use

Roger Quadros (1):
  phy: ti-pipe3: Program the DPLL even if it was already locked

 drivers/phy/phy-exynos-mipi-video.c |6 +-
 drivers/phy/phy-ti-pipe3.c  |   15 +++
 2 files changed, 16 insertions(+), 5 deletions(-)

-- 
1.7.9.5

[PATCH v2 0/3] hw_random: Add Amlogic Meson SoCs Random Generator driver

[Neil Armstrong]

Add support for the Amlogic Meson SoCs Hardware Random generator as a hw_random 
char driver.
The generator is a single 32bit wide register.
Also adds the Meson GXBB SoC DTSI node and corresponding DT bindings.

Changes since v1 at 
http://lkml.kernel.org/r/1464943621-18278-1-git-send-email-narmstr...@baylibre.com
 :
- change to depend on ARCH_MESON || COMPILE_TEST
- check buffer max size in read

Neil Armstrong (3):
  char: hw_random: Add Amlogic Meson Hardware Random Generator
  dt-bindings: hwrng: Add Amlogic Meson Hardware Random Generator
bindings
  ARM64: dts: meson-gxbb: Add Hardware Random Generator node

 .../devicetree/bindings/rng/amlogic,meson-rng.txt  |  14 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   5 +
 drivers/char/hw_random/Kconfig |  14 +++
 drivers/char/hw_random/Makefile|   1 +
 drivers/char/hw_random/meson-rng.c | 131 +
 5 files changed, 165 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
 create mode 100644 drivers/char/hw_random/meson-rng.c

-- 
2.7.0

[PATCH v2 1/3] char: hw_random: Add Amlogic Meson Hardware Random Generator

[Neil Armstrong]

Add support for the Amlogic Meson SoCs hardware random generator.

Signed-off-by: Neil Armstrong 
---
 drivers/char/hw_random/Kconfig |  14 
 drivers/char/hw_random/Makefile|   1 +
 drivers/char/hw_random/meson-rng.c | 131 +
 3 files changed, 146 insertions(+)
 create mode 100644 drivers/char/hw_random/meson-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index ac51149..8558a61 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -396,6 +396,20 @@ config HW_RANDOM_PIC32
 
  If unsure, say Y.
 
+config HW_RANDOM_MESON
+   tristate "Amlogic Meson Random Number Generator support"
+   depends on HW_RANDOM
+   depends on ARCH_MESON || COMPILE_TEST
+   default y
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Amlogic Meson SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called meson-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 63022b4..04bb0b0 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
 obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
 obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
 obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
+obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
diff --git a/drivers/char/hw_random/meson-rng.c 
b/drivers/char/hw_random/meson-rng.c
new file mode 100644
index 000..0cfd81b
--- /dev/null
+++ b/drivers/char/hw_random/meson-rng.c
@@ -0,0 +1,131 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "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 COPYRIGHT
+ * OWNER OR CONTRIBUTORS 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RNG_DATA 0x00
+
+struct meson_rng_data {
+   void __iomem *base;
+   struct platform_device *pdev;
+   struct hwrng rng;
+};
+
+static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+   struct meson_rng_data *data =
+   container_of(rng, struct meson_rng_data, rng);
+
+   if (max < sizeof(u32))
+   return 0;
+
+   *(u32 *)buf = readl_relaxed(data->base + RNG_DATA);
+
+   return si

[PATCH v2 3/3] ARM64: dts: meson-gxbb: Add Hardware Random Generator node

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 832815d..8353621 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -167,6 +167,11 @@
};
};
 
+   rng {
+   compatible = "amlogic,meson-rng";
+   reg = <0x0 0xc8834000 0x0 0x4>;
+   };
+
apb: apb@d000 {
compatible = "simple-bus";
reg = <0x0 0xd000 0x0 0x20>;
-- 
2.7.0

[PATCH v2 2/3] dt-bindings: hwrng: Add Amlogic Meson Hardware Random Generator bindings

[Neil Armstrong]

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/rng/amlogic,meson-rng.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt 
b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
new file mode 100644
index 000..202f2d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
@@ -0,0 +1,14 @@
+Amlogic Meson Random number generator
+=
+
+Required properties:
+
+- compatible : should be "amlogic,meson-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+compatible = "amlogic,meson-rng";
+reg = <0x0 0xc8834000 0x0 0x4>;
+};
-- 
2.7.0

[PATCH 1/2] phy: exynos-mipi-video: avoid uninitialized variable use

[Kishon Vijay Abraham I]

From: Arnd Bergmann 

A rework of the exynos-mipi-video driver caused a warning
about the new __set_phy_state function potentially accessing
a variable before its initialization:

drivers/phy/phy-exynos-mipi-video.c: In function '__set_phy_state':
drivers/phy/phy-exynos-mipi-video.c:238:13: error: 'val' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
  return val & data->resetn_val;
 ^~
drivers/phy/phy-exynos-mipi-video.c:235:6: note: 'val' was declared here
  u32 val;

The failure scenario here is the offset passed into a the
stub regmap_read() function that does not modify its output,
however regmap_read() can also fail for other reasons, so
adding error handling (in this case, returning zero from
is_running) seems the best solution.

Note that this warning showed up with the ARM s5pv210_defconfig,
indicating that we most likely want to either enable CONFIG_REGMAP
in that defconfig as well, or disable the phy-exynos-mipi-video
driver.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
Fixes: 97a3042f7616 ("phy: exynos-mipi-video: Rewrite handling of phy 
registers")
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-exynos-mipi-video.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index cc093eb..8b851f7 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -233,8 +233,12 @@ static inline int __is_running(const struct 
exynos_mipi_phy_desc *data,
struct exynos_mipi_video_phy *state)
 {
u32 val;
+   int ret;
+
+   ret = regmap_read(state->regmaps[data->resetn_map], data->resetn_reg, 
&val);
+   if (ret)
+   return 0;
 
-   regmap_read(state->regmaps[data->resetn_map], data->resetn_reg, &val);
return val & data->resetn_val;
 }
 
-- 
1.7.9.5

Re: pwm: atmel: Fix disabling of PWM channels

[Alexandre Belloni]

Hi,

On 13/05/2016 at 13:09:37 +0200, Guillermo Rodriguez wrote :
> When disabling a PWM channel, the PWM clock was being stopped
> immediately after writing to PWM_DIS. As a result, the disabling
> of the PWM channel did not complete properly, and the PWM output
> might be left at the wrong level.
> 
> Fix this by waiting for the channel to be effectively disabled
> (by checking the PWM_SR register) before disabling the clock.
> 
> Signed-off-by: Guillermo Rodriguez 
> ---
>  drivers/pwm/pwm-atmel.c |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index 0e4bd4e..a714434 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -271,6 +271,16 @@ static void atmel_pwm_disable(struct pwm_chip *chip, 
> struct pwm_device *pwm)
>   mutex_unlock(&atmel_pwm->isr_lock);
>   atmel_pwm_writel(atmel_pwm, PWM_DIS, 1 << pwm->hwpwm);
>  
> + /*
> +  * Wait for the PWM channel disable operation to be effective before
> +  * stopping the clock.
> +  */
> + timeout = jiffies + 2 * HZ;
> + while ((atmel_pwm_readl(atmel_pwm, PWM_SR)& (1 << pwm->hwpwm)) &&
> +time_before(jiffies, timeout)) {
> + usleep_range(10, 100);
> + }
> +

While this seems good, can you tell on which SoC you observed that? I'd
like to understand whether this is only on v1 or v2 or both.

Thanks!

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 10/06/16 11:18, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>>> dwc->xhci_resource[1] = *res;
>>
>> Probably not as we don't want to change parent/child members.
> 
> oh, you had already replied. Sorry. This is correct
> 
np :).

So what i'll do is get the irq via platform_get_irq() and friends
and if it was a success use platform_get_resource() and friends
to get struct resource and just edit the relevant parts for the
XHCI irq resource.

Sounds OK?

something like this.

+   int ret, irq;
+   struct resource *res;
+   struct platform_device  *dwc3_pdev = to_platform_device(dwc->dev);
+
+   irq = platform_get_irq_byname(dwc3_pdev, "host");
+   if (irq == -EPROBE_DEFER)
+   return irq;
+
+   if (irq <= 0) {
+   irq = platform_get_irq_byname(dwc3_pdev, "dwc_usb3");
+   if (irq == -EPROBE_DEFER)
+   return irq;
+
+   if (irq <= 0) {
+   irq = platform_get_irq(dwc3_pdev, 0);
+   if (irq <= 0) {
+   if (irq != -EPROBE_DEFER) {
+   dev_err(dwc->dev,
+   "missing host IRQ\n");
+   }
+   return irq;
+   } else {
+   res = platform_get_resource(dwc3_pdev,
+   IORESOURCE_IRQ, 0);
+   }
+   } else {
+   res = platform_get_resource_byname(dwc3_pdev,
+  IORESOURCE_IRQ,
+  "dwc_usb3");
+   }
+
+   } else {
+   res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
+  "host");
+   }
+
+   dwc->xhci_resources[1].start = irq;
+   dwc->xhci_resources[1].end = irq;
+   dwc->xhci_resources[1].flags = res->flags;
+   dwc->xhci_resources[1].name = res->name;
 


--
cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH trivial] include/linux/memcontrol.h: Clean up code only

[Chen Gang]

On 6/10/16 14:14, Michal Hocko wrote:
> On Fri 10-06-16 08:40:30, Chen Gang wrote:
>>
>> On 6/9/16 23:46, Michal Hocko wrote:
> [...]
>>> That's being said, I appreciate an interest in making the code cleaner
>>> but try to think whether these changes are actually helpful and who is
>>> going to benefit from them.
>>>
>>
>> For me, another readers can get benefit more or less from it: if read a
>> simple line can know the whole thing (function work), why need we read
>> multiple lines?
> 
> Yes I understand that this is a matter of taste but as I've said above.
> I do not see this would add a benefit to justify the change.
> 
> If you are doing a reformating or white space cleanups always try to
> think about those who want/need to dig into the history to understand
> the code and this would add an additional step to get to the original
> commit which is added the code. This is just wasting of time.
> 
> Now this would be much more tolerable when the code in question was a
> maze but this is not the case.
> 

OK, thanks.

Cleaning up code in include/* should face to the whole header files, not
only for mm specially. It is not suitable to only focus mm in common
shared header files for cleaning up code only.

So for me, cleaning up code in include/* is still necessary, but I shall
face to all files instead of mm related files.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

[PATCH] T4/B4: add aliases for usb nodes

[Sriram Dash]

From: Sriram Dash 

Add usb aliases for consistency with the other platforms.

Signed-off-by: Laurentiu Tudor 
Signed-off-by: Sriram Dash 
---
 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi| 1 +
 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi| 1 +
 arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi| 2 ++
 4 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index bc3bf93..88d8423 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -51,6 +51,7 @@
serial2 = &serial2;
serial3 = &serial3;
pci0 = &pci0;
+   usb0 = &usb0;
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index 8797ce1..f3f968c 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -51,6 +51,7 @@
serial2 = &serial2;
serial3 = &serial3;
pci0 = &pci0;
+   usb0 = &usb0;
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
diff --git a/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
index 29dad72..fcc7e5b 100644
--- a/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
@@ -32,7 +32,7 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-usb@21 {
+usb0: usb@21 {
compatible = "fsl-usb2-dr";
reg = <0x21 0x1000>;
#address-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
index 1184a74..038cf8f 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
@@ -56,6 +56,8 @@
pci1 = &pci1;
pci2 = &pci2;
pci3 = &pci3;
+   usb0 = &usb0;
+   usb1 = &usb1;
dma0 = &dma0;
dma1 = &dma1;
dma2 = &dma2;
-- 
2.6.2.198.g614a2ac

[PATCH] powerpc: dts: t1040si: Change T1040si USB controller version

[Sriram Dash]

From: Sriram Dash 

Change USB controller version name to 2.5 in compatible string for T1040

Signed-off-by: Sriram Dash 
---
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 507649e..d3fbe72 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -607,7 +607,7 @@
 /include/ "qoriq-gpio-3.dtsi"
 /include/ "qoriq-usb2-mph-0.dtsi"
usb0: usb@21 {
-   compatible = "fsl-usb2-mph-v2.4", "fsl-usb2-mph";
+   compatible = "fsl-usb2-mph-v2.5", "fsl-usb2-mph";
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x520>; /* USB1LIODNR */
phy_type = "utmi";
@@ -615,7 +615,7 @@
};
 /include/ "qoriq-usb2-dr-0.dtsi"
usb1: usb@211000 {
-   compatible = "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x524>; /* USB2LIODNR */
dr_mode = "host";
-- 
2.6.2.198.g614a2ac

RE: [PATCH 4.2.y-ckt 006/206] drm/i915: Exit cherryview_irq_handler() after one pass

[Ursulin, Tvrtko]

Hi,

Should not be cherry picked to stable, it needs many more patches to make it 
work or otherwise breaks the platform.

Regards,

Tvrtko

> -Original Message-
> From: Kamal Mostafa [mailto:ka...@canonical.com]
> Sent: Thursday, June 09, 2016 10:14 PM
> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; kernel-
> t...@lists.ubuntu.com
> Cc: Chris Wilson; Ville Syrjälä; Antti Koskipää; Ursulin, Tvrtko; Kamal 
> Mostafa
> Subject: [PATCH 4.2.y-ckt 006/206] drm/i915: Exit cherryview_irq_handler()
> after one pass
> 
> 4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me
> know.
> 
> ---8<
> 
> From: Chris Wilson 
> 
> commit 579de73b048a0a4c66c25a033ac76a2836e0cf73 upstream.
> 
> This effectively reverts
> 
> commit 8e5fd599eb219f1054e39b40d18b217af669eea9
> Author: Ville Syrjälä 
> Date:   Wed Apr 9 13:28:50 2014 +0300
> 
> drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed
> 
> as under continuous execlists load we can saturate the IRQ handler,
> destablising the tsc clock and triggering the NMI watchdog to declare a hung
> CPU.
> 
> [  552.756051] clocksource: timekeeping watchdog on CPU0: Marking
> clocksource 'tsc' as unstable because the skew is too large:
> [  552.756080] clocksource:   'refined-jiffies' wd_now: 
> 10003b480
> wd_last: 10003b28c mask: 
> [  552.756091] clocksource:   'tsc' cs_now: d55d31aa50 
> cs_last:
> d17446166c mask: 
> [  552.756210] clocksource: Switched to clocksource refined-jiffies
> [  575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
> [  575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18
> [  575.217905] Hardware name:  /NUC5CPYB, BIOS
> PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> [  575.217915]   88027fd05bc0 81288c6d
> 
> [  575.217935]  0001 88027fd05be0 810e72d1
> 
> [  575.217951]  88027fd05c80 88027fd05c20 81114b60
> 000181015f1e
> [  575.217967] Call Trace:
> [  575.217973][] dump_stack+0x4f/0x72
> [  575.217994]  []
> watchdog_overflow_callback+0x151/0x160
> [  575.218003]  [] __perf_event_overflow+0xa0/0x1e0
> [  575.218016]  [] perf_event_overflow+0x14/0x20
> [  575.218028]  [] intel_pmu_handle_irq+0x1da/0x460
> [  575.218042]  [] ? poll_idle+0x3e/0x70
> [  575.218052]  [] ? poll_idle+0x3e/0x70
> [  575.218064]  [] perf_event_nmi_handler+0x28/0x50
> [  575.218075]  [] nmi_handle+0x60/0x130
> [  575.218086]  [] ? poll_idle+0x3e/0x70
> [  575.218096]  [] do_nmi+0x140/0x470
> [  575.218108]  [] end_repeat_nmi+0x1a/0x1e
> [  575.218119]  [] ? poll_idle+0x3e/0x70
> [  575.218129]  [] ? poll_idle+0x3e/0x70
> [  575.218139]  [] ? poll_idle+0x3e/0x70
> [  575.218148]  <>  []
> cpuidle_enter_state+0xf3/0x2f0
> [  575.218164]  [] cpuidle_enter+0x17/0x20
> [  575.218175]  [] call_cpuidle+0x2a/0x40
> [  575.218185]  [] cpu_startup_entry+0x273/0x330
> [  575.218196]  [] start_secondary+0x10e/0x130
> 
> However, not servicing all available IIR within the handler does hurt the
> throughput of pathological nop execbuf by about 20%, with a similar effect
> upon the dispatch latency of a series of execbuf.
> 
> v2: use do {} while(0) for a smaller patch, and easier to revert again
> 
> I have reasonable confidence that we do not miss GT interrupts (as
> execlists provides a stress case with a failure mechanism easily
> detected by igt), however I have less confidence about all the other
> sources of interrupts and worry that may lose a display hotplug
> interrupt, for example.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467
> Testcase: igt/gem_exec_nop/basic # requires NMI watchdog
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Antti Koskipää 
> Cc: Tvrtko Ursulin 
> Reviewed-by: Tvrtko Ursulin 
> Reviewed-by: Ville Syrjälä 
> Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-
> send-email-ch...@chris-wilson.co.uk
> Signed-off-by: Kamal Mostafa 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 6a51bc6..6f453fe 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1837,7 +1837,7 @@ static irqreturn_t cherryview_irq_handler(int irq,
> void *arg)
>   if (!intel_irqs_enabled(dev_priv))
>   return IRQ_NONE;
> 
> - for (;;) {
> + do {
>   master_ctl = I915_READ(GEN8_MASTER_IRQ) &
> ~GEN8_MASTER_IRQ_CONTROL;
>   iir = I915_READ(VLV_IIR);
> 
> @@ -1865,7 +1865,7 @@ static irqreturn_t cherryview_irq_handler(int irq,
> void *arg)
> 
>   I915_WRITE(GEN8_MASTER_IRQ,
> DE_MASTER_IRQ_CONTROL);
>   POSTING_READ(GEN8_MASTER_IRQ);
> - }
> +

[GIT PULL] sound fixes for 4.7-rc3

[Takashi Iwai]

Linus,

please pull sound fixes for v4.7-rc3 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.7-rc3

The topmost commit is 35639a0e98391036a4c7f23253c321d6621a8897



sound fixes for 4.7-rc3

We have only few, mainly HD-audio device-specific fixes.
Realtek codec driver got a slightly more LOC, but they are all for the
new codec chip, and won't affect others at all.



AceLan Kao (1):
  ALSA: hda - Fix headset mic detection problem for Dell machine

Kailang Yang (2):
  ALSA: hda/realtek - ALC256 speaker noise issue
  ALSA: hda/realtek - Add support for new codecs ALC700/ALC701/ALC703

Robert P. J. Day (1):
  ALSA: uapi: Add three missing header files to Kbuild file

Torsten Hilbrich (1):
  ALSA: hda/realtek: Add T560 docking unit fixup

Vinod Koul (1):
  ALSA: hda - Add PCI ID for Kabylake

---
 include/uapi/sound/Kbuild |  3 ++
 sound/pci/hda/hda_intel.c | 11 ++-
 sound/pci/hda/patch_realtek.c | 73 ---
 3 files changed, 81 insertions(+), 6 deletions(-)

diff --git a/include/uapi/sound/Kbuild b/include/uapi/sound/Kbuild
index a7f27704f980..691984cb0b91 100644
--- a/include/uapi/sound/Kbuild
+++ b/include/uapi/sound/Kbuild
@@ -1,5 +1,6 @@
 # UAPI Header export list
 header-y += asequencer.h
+header-y += asoc.h
 header-y += asound.h
 header-y += asound_fm.h
 header-y += compress_offload.h
@@ -10,3 +11,5 @@ header-y += hdsp.h
 header-y += hdspm.h
 header-y += sb16_csp.h
 header-y += sfnt_info.h
+header-y += tlv.h
+header-y += usb_stream.h
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9a0d1445ca5c..94089fc71884 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -365,8 +365,11 @@ enum {
 
 #define IS_SKL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa170)
 #define IS_SKL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d70)
+#define IS_KBL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa171)
+#define IS_KBL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d71)
 #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
-#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci))
+#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci)) || \
+   IS_KBL(pci) || IS_KBL_LP(pci)
 
 static char *driver_short_names[] = {
[AZX_DRIVER_ICH] = "HDA Intel",
@@ -2181,6 +2184,12 @@ static const struct pci_device_id azx_ids[] = {
/* Sunrise Point-LP */
{ PCI_DEVICE(0x8086, 0x9d70),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
+   /* Kabylake */
+   { PCI_DEVICE(0x8086, 0xa171),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
+   /* Kabylake-LP */
+   { PCI_DEVICE(0x8086, 0x9d71),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Broxton-P(Apollolake) */
{ PCI_DEVICE(0x8086, 0x5a98),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_BROXTON },
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d53c25e7a1c1..0fe18ede3e85 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -346,6 +346,9 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
case 0x10ec0234:
case 0x10ec0274:
case 0x10ec0294:
+   case 0x10ec0700:
+   case 0x10ec0701:
+   case 0x10ec0703:
alc_update_coef_idx(codec, 0x10, 1<<15, 0);
break;
case 0x10ec0662:
@@ -2655,6 +2658,7 @@ enum {
ALC269_TYPE_ALC256,
ALC269_TYPE_ALC225,
ALC269_TYPE_ALC294,
+   ALC269_TYPE_ALC700,
 };
 
 /*
@@ -2686,6 +2690,7 @@ static int alc269_parse_auto_config(struct hda_codec 
*codec)
case ALC269_TYPE_ALC256:
case ALC269_TYPE_ALC225:
case ALC269_TYPE_ALC294:
+   case ALC269_TYPE_ALC700:
ssids = alc269_ssids;
break;
default:
@@ -3618,13 +3623,20 @@ static void alc269_fixup_hp_line1_mic1_led(struct 
hda_codec *codec,
 static void alc_headset_mode_unplugged(struct hda_codec *codec)
 {
static struct coef_fw coef0255[] = {
-   WRITE_COEF(0x1b, 0x0c0b), /* LDO and MISC control */
WRITE_COEF(0x45, 0xd089), /* UAJ function set to menual mode */
UPDATE_COEFEX(0x57, 0x05, 1<<14, 0), /* Direct Drive HP Amp 
control(Set to verb control)*/
WRITE_COEF(0x06, 0x6104), /* Set MIC2 Vref gate with HP */
WRITE_COEFEX(0x57, 0x03, 0x8aa6), /* Direct Drive HP Amp 
control */
{}
};
+   static struct coef_fw coef0255_1[] = {
+   WRITE_COEF(0x1b, 0x0c0b), /* LDO and MISC control */
+   {}
+   };
+   static struct coef_fw coef0256[] = {
+   

[PATCH 1/2] slab: make GFP_SLAB_BUG_MASK information more human readable

[Michal Hocko]

From: Michal Hocko 

printk offers %pGg for quite some time so let's use it to get a human
readable list of invalid flags.

The original output would be
[  429.191962] gfp: 2

after the change
[  429.191962] Unexpected gfp: 0x2 (__GFP_HIGHMEM)

Signed-off-by: Michal Hocko 
---
 mm/slab.c | 3 ++-
 mm/slub.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 763096a247f6..03fb724d6e48 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2686,7 +2686,8 @@ static struct page *cache_grow_begin(struct kmem_cache 
*cachep,
 * critical path in kmem_cache_alloc().
 */
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
-   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   gfp_t invalid_mask = flags & GFP_SLAB_BUG_MASK;
+   pr_emerg("Unexpected gfp: %#x (%pGg)\n", invalid_mask, 
&invalid_mask);
BUG();
}
local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);
diff --git a/mm/slub.c b/mm/slub.c
index cbf4e0e07d41..dd5a9eee7df5 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1628,7 +1628,8 @@ static struct page *allocate_slab(struct kmem_cache *s, 
gfp_t flags, int node)
 static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
 {
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
-   pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
+   gfp_t invalid_mask = flags & GFP_SLAB_BUG_MASK;
+   pr_emerg("Unexpected gfp: %#x (%pGg)\n", invalid_mask, 
&invalid_mask);
BUG();
}
 
-- 
2.8.1

[PATCH 2/2] slab: do not panic on invalid gfp_mask

[Michal Hocko]

From: Michal Hocko 

both SLAB and SLUB BUG() when a caller provides an invalid gfp_mask.
This is a rather harsh way to announce a non-critical issue. Allocator
is free to ignore invalid flags. Let's simply replace BUG() by
dump_stack to tell the offender and fixup the mask to move on with the
allocation request.

This is an example for kmalloc(GFP_KERNEL|__GFP_HIGHMEM) from a test
module.
[   31.914753] Unexpected gfp: 0x2 (__GFP_HIGHMEM). Fixing up to gfp: 0x24000c0 
(GFP_KERNEL). Fix your code!
[   31.914754] CPU: 0 PID: 2916 Comm: insmod Tainted: G   O
4.6.0-slabgfp2-2-g4cdfc2ef4892-dirty #936
[   31.914755] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   31.914756]   88000d777c00 8130e2fb 
88000ec006c0
[   31.914758]  000c 88000d777c58 811791dd 
0246
[   31.914759]  0246 0046 0002024000c0 
88000fa1d888
[   31.914759] Call Trace:
[   31.914760]  [] dump_stack+0x67/0x90
[   31.914762]  [] cache_alloc_refill+0x201/0x617
[   31.914763]  [] kmem_cache_alloc_trace+0xa7/0x24a
[   31.914764]  [] ? 0xa0005000
[   31.914765]  [] mymodule_init+0x20/0x1000 [test_slab]
[   31.914767]  [] do_one_initcall+0xe7/0x16c
[   31.914768]  [] ? rcu_read_lock_sched_held+0x61/0x69
[   31.914769]  [] ? kmem_cache_alloc_trace+0x197/0x24a
[   31.914771]  [] do_init_module+0x5f/0x1d9
[   31.914772]  [] load_module+0x1a3d/0x1f21
[   31.914774]  [] ? retint_kernel+0x2d/0x2d
[   31.914775]  [] SyS_init_module+0xe8/0x10e
[   31.914776]  [] ? SyS_init_module+0xe8/0x10e
[   31.914778]  [] do_syscall_64+0x68/0x13f
[   31.914779]  [] entry_SYSCALL64_slow_path+0x25/0x25

Signed-off-by: Michal Hocko 
---
 mm/slab.c | 6 --
 mm/slub.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 03fb724d6e48..fc9496bdd038 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2687,8 +2687,10 @@ static struct page *cache_grow_begin(struct kmem_cache 
*cachep,
 */
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
gfp_t invalid_mask = flags & GFP_SLAB_BUG_MASK;
-   pr_emerg("Unexpected gfp: %#x (%pGg)\n", invalid_mask, 
&invalid_mask);
-   BUG();
+   flags &= ~GFP_SLAB_BUG_MASK;
+   pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x 
(%pGg). Fix your code!\n",
+   invalid_mask, &invalid_mask, flags, &flags);
+   dump_stack();
}
local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);
 
diff --git a/mm/slub.c b/mm/slub.c
index dd5a9eee7df5..ca60b414e569 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1629,8 +1629,9 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t 
flags, int node)
 {
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
gfp_t invalid_mask = flags & GFP_SLAB_BUG_MASK;
-   pr_emerg("Unexpected gfp: %#x (%pGg)\n", invalid_mask, 
&invalid_mask);
-   BUG();
+   flags &= ~GFP_SLAB_BUG_MASK;
+   pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x 
(%pGg). Fix your code!\n",
+   invalid_mask, &invalid_mask, flags, &flags);
}
 
return allocate_slab(s,
-- 
2.8.1

Re: [PATCH] autofs: don't stuck in a loop if vfs_write returns an error

[Ian Kent]

On Thu, 2016-06-09 at 10:27 -0700, Andrei Vagin wrote:
> On Wed, Jun 8, 2016 at 6:23 PM, Ian Kent  wrote:
> > On Mon, 2016-05-30 at 13:52 +0800, Ian Kent wrote:
> > > On Tue, 2016-05-24 at 09:34 +0800, Ian Kent wrote:
> > > > On Mon, 2016-05-23 at 14:50 -0700, Andrei Vagin wrote:
> > > > > Hi Ian,
> > > > > 
> > > > > When are you going to apply this patch? We can't test linux-next
> > > > > without
> > > > > it.
> > > > 
> > > > I though I sent this with the last series but I can't see that I have.
> > > > 
> > > > I have the rest of that series to send over to Andrew which I was
> > > > planning
> > > > to
> > > > do
> > > > after the current merge window closes (which is about now I guess).
> > > > 
> > > > I'll include it in that series.
> > > > Sorry for the hold up, ;)
> > > 
> > > Some bad news I'm afraid.
> > > 
> > > I was getting ready to send these over to Andrew and found that opendir(3)
> > > is
> > > failing on a number of tests (51 of 230, 9 fails are expected) with 4.6.0.
> > > 
> > > It's not the patches, yours or mine and it doesn't happen with 4.4.x
> > > kernels.
> > > 
> > > Looks like I'm going to have to bisect to work out what's going on and
> > > that
> > > will
> > > take a while.
> > 
> > The regression has been fixed now.
> > 
> > Al Viro sent a patch for it to Linus yesterday, it's commit e6ec03a25f1 in
> > the
> > Linux tree.
> 
> It's good!
> 
> > 
> > I can send my patches to Andrew (after re-testing) but any autofs related
> > testing of linux.next will need the above commit.
> > 
> > Andrew, surely this isn't the first time this type of problem has happened,
> > how
> > is it usually handled, what do I need to do to make this go smoothly?
> 
> In linux-next we catch two sorts of bugs.
> 
> 1. If bugs is triggered very often, we report it, when it isn't in
> Linus' tree. And such bugs are fixed very fast.
> 2. If bugs is triggered rarely. In this case we may detect this bug
> too late, when it's in Linus' tree. In this case we may need to
> workaraound it.
> 
> Here the problem belongs to the second type. It is triggered only when
> one or more tests failed and we try to kill all test processes.
> Actually it doesn't affect regular runs of tests, but it's annoying
> when we are investigating something.
> 
> Ian, I don't think that you need to do anything special. Thank you for
> handling this patch!

LOL, it's good that it was my standard (relatively simple) testing that exposed
it.

I'll wait a little longer in case Andrew has anything to add then send the patch
series to him.

> 
> Thanks,
> Andrew
> 
> > 
> > > 
> > > > 
> > > > Ian
> > > > 
> > > > > 
> > > > > Thanks,
> > > > > Andrew
> > > > > 
> > > > > 
> > > > > On Fri, Apr 1, 2016 at 12:37 AM, Ian Kent  wrote:
> > > > > > On Thu, 2016-03-31 at 22:12 -0700, Andrey Vagin wrote:
> > > > > > > From: Andrey Vagin 
> > > > > > > 
> > > > > > > __vfs_write() returns a negative value in a error case.
> > > > > > 
> > > > > > Ha, right, I'll send this along to Andrew with my next series which
> > > > > > should be soon.
> > > > > > 
> > > > > > > 
> > > > > > > Cc: Ian Kent 
> > > > > > > Signed-off-by: Andrey Vagin 
> > > > > > > ---
> > > > > > >  fs/autofs4/waitq.c | 7 ---
> > > > > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> > > > > > > index 0146d91..631f155 100644
> > > > > > > --- a/fs/autofs4/waitq.c
> > > > > > > +++ b/fs/autofs4/waitq.c
> > > > > > > @@ -66,11 +66,12 @@ static int autofs4_write(struct autofs_sb_info
> > > > > > > *sbi,
> > > > > > >   set_fs(KERNEL_DS);
> > > > > > > 
> > > > > > >   mutex_lock(&sbi->pipe_mutex);
> > > > > > > - wr = __vfs_write(file, data, bytes, &file->f_pos);
> > > > > > > - while (bytes && wr) {
> > > > > > > + while (bytes) {
> > > > > > > + wr = __vfs_write(file, data, bytes, &file->f_pos);
> > > > > > > + if (wr <= 0)
> > > > > > > + break;
> > > > > > >   data += wr;
> > > > > > >   bytes -= wr;
> > > > > > > - wr = __vfs_write(file, data, bytes, &file->f_pos);
> > > > > > >   }
> > > > > > >   mutex_unlock(&sbi->pipe_mutex);
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe autofs" in

Re: [PATCH v3 2/3] drm/arm: Add support for Mali Display Processors

[Liviu Dudau]

On Thu, Jun 09, 2016 at 08:56:29PM +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 05:18:18PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display engine being supported at the moment.
> > 
> > Cc: David Brown 
> > Cc: Brian Starkey 
> > 
> > Signed-off-by: Liviu Dudau 
> 
> Bunch of drive-by comments below. Looks rather pretty overall \o/

Thanks for reviewing this!!

> 
> Cheers, Daniel
> > ---
> >  drivers/gpu/drm/arm/Kconfig |  16 +
> >  drivers/gpu/drm/arm/Makefile|   2 +
> >  drivers/gpu/drm/arm/malidp_crtc.c   | 239 +
> >  drivers/gpu/drm/arm/malidp_drv.c| 500 ++
> >  drivers/gpu/drm/arm/malidp_drv.h|  48 +++
> >  drivers/gpu/drm/arm/malidp_hw.c | 691 
> > 
> >  drivers/gpu/drm/arm/malidp_hw.h | 241 +
> >  drivers/gpu/drm/arm/malidp_planes.c | 271 ++
> >  drivers/gpu/drm/arm/malidp_regs.h   | 172 +
> >  9 files changed, 2180 insertions(+)
> >  create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
> > 
> > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> > index eaed454..1b29065 100644
> > --- a/drivers/gpu/drm/arm/Kconfig
> > +++ b/drivers/gpu/drm/arm/Kconfig
> > @@ -25,3 +25,19 @@ config DRM_HDLCD_SHOW_UNDERRUN
> >   Enable this option to show in red colour the pixels that the
> >   HDLCD device did not fetch from framebuffer due to underrun
> >   conditions.
> > +
> > +config DRM_MALI_DISPLAY
> > +   tristate "ARM Mali Display Processor"
> > +   depends on DRM && OF && (ARM || ARM64)
> > +   depends on COMMON_CLK
> > +   select DRM_ARM
> > +   select DRM_KMS_HELPER
> > +   select DRM_KMS_CMA_HELPER
> > +   select DRM_GEM_CMA_HELPER
> > +   select VIDEOMODE_HELPERS
> > +   help
> > + Choose this option if you want to compile the ARM Mali Display
> > + Processor driver. It supports the DP500, DP550 and DP650 variants
> > + of the hardware.
> > +
> > + If compiled as a module it will be called mali-dp.
> > diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> > index 89dcb7b..bb8b158 100644
> > --- a/drivers/gpu/drm/arm/Makefile
> > +++ b/drivers/gpu/drm/arm/Makefile
> > @@ -1,2 +1,4 @@
> >  hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
> >  obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
> > +mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> > +obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
> > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> > b/drivers/gpu/drm/arm/malidp_crtc.c
> > new file mode 100644
> > index 000..21b71eb
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > @@ -0,0 +1,239 @@
> > +/*
> > + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> > + * Author: Liviu Dudau 
> > + *
> > + * This program is free software and is provided to you under the terms of 
> > the
> > + * GNU General Public License version 2 as published by the Free Software
> > + * Foundation, and any use by you of this program is subject to the terms
> > + * of such GNU licence.
> > + *
> > + * ARM Mali DP500/DP550/DP650 driver (crtc operations)
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "malidp_drv.h"
> > +#include "malidp_hw.h"
> > +
> > +static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> > +  const struct drm_display_mode *mode,
> > +  struct drm_display_mode *adjusted_mode)
> > +{
> > +   struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> > +   struct malidp_hw_device *hwdev = malidp->dev;
> > +
> > +   /*
> > +* check that the hardware can drive the required clock rate,
> > +* but skip the check if the clock is meant to be disabled (req_rate = 
> > 0)
> > +*/
> > +   long rate, req_rate = mode->crtc_clock * 1000;
> > +
> > +   if (req_rate) {
> > +   rate = clk_round_rate(hwdev->mclk, req_rate);
> > +   if (rate < req_rate) {
> > +   DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
> > +mode->crtc_clock);
> > +   return false;
> > +   }
> > +
> > +   rate = clk_round_rate(hwdev->pxlclk, req_rate);
> > +   if (rate != req_rate) {
> > +   DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
> > +req_rate);
> > +   return false;
> > +   

[PATCH] usb: dwc3: fix runtime PM in error path

[Roger Quadros]

If there is a failure after pm_runtime_enable/get_sync()
we need to call pm_runtime_disable/put_sync().

Otherwise it will lead to an unbalanced pm_runtime_enable() on the
subsequent probe if the earlier probe bailed out due to -EPROBE_DEFER.

Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/core.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5bf38f8..222d2c9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1419,7 +1419,7 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret) {
dev_err(dwc->dev, "failed to allocate event buffers\n");
ret = -ENOMEM;
-   goto err0;
+   goto err1;
}
 
if (IS_ENABLED(CONFIG_USB_DWC3_HOST) &&
@@ -1436,12 +1436,12 @@ static int dwc3_probe(struct platform_device *pdev)
 
ret = dwc3_alloc_scratch_buffers(dwc);
if (ret)
-   goto err1;
+   goto err2;
 
ret = dwc3_core_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize core\n");
-   goto err2;
+   goto err3;
}
 
/* Check the maximum_speed parameter */
@@ -1473,23 +1473,28 @@ static int dwc3_probe(struct platform_device *pdev)
 
ret = dwc3_core_init_mode(dwc);
if (ret)
-   goto err3;
+   goto err4;
 
dwc3_debugfs_init(dwc);
pm_runtime_put(dev);
 
return 0;
 
-err3:
+err4:
dwc3_event_buffers_cleanup(dwc);
 
-err2:
+err3:
dwc3_free_scratch_buffers(dwc);
 
-err1:
+err2:
dwc3_free_event_buffers(dwc);
dwc3_ulpi_exit(dwc);
 
+err1:
+   pm_runtime_allow(&pdev->dev);
+   pm_runtime_put_sync(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+
 err0:
/*
 * restore res->start back to its original value so that, in case the
-- 
2.7.4

[PATCH] base: make module_create_drivers_dir race-free

[Jiri Slaby]

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [] sysfs_warn_dup+0x62/0x80
 [] sysfs_create_dir_ns+0x77/0x90
 [] kobject_add_internal+0xb4/0x340
 [] kobject_add+0x68/0xb0
 [] kobject_create_and_add+0x31/0x70
 [] module_add_driver+0xc3/0xd0
 [] bus_add_driver+0x154/0x280
 [] driver_register+0x60/0xe0
 [] __pci_register_driver+0x60/0x70
 [] saa7146_register_extension+0x64/0x90 [saa7146]
 [] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
-> module_add_driver
  -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.

Signed-off-by: Jiri Slaby 
Cc: Greg Kroah-Hartman 
Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ 
---
 drivers/base/module.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/base/module.c b/drivers/base/module.c
index db930d3ee312..2a215780eda2 100644
--- a/drivers/base/module.c
+++ b/drivers/base/module.c
@@ -24,10 +24,12 @@ static char *make_driver_name(struct device_driver *drv)
 
 static void module_create_drivers_dir(struct module_kobject *mk)
 {
-   if (!mk || mk->drivers_dir)
-   return;
+   static DEFINE_MUTEX(drivers_dir_mutex);
 
-   mk->drivers_dir = kobject_create_and_add("drivers", &mk->kobj);
+   mutex_lock(&drivers_dir_mutex);
+   if (mk && !mk->drivers_dir)
+   mk->drivers_dir = kobject_create_and_add("drivers", &mk->kobj);
+   mutex_unlock(&drivers_dir_mutex);
 }
 
 void module_add_driver(struct module *mod, struct device_driver *drv)
-- 
2.8.4

Re: [PATCH 7/7] ARM: dts: sun7i: Enable NAND on Wexler TAB7200

[Maxime Ripard]

On Thu, Jun 09, 2016 at 11:11:00AM +0300, Aleksei Mamlin wrote:
> On Thu, 9 Jun 2016 00:03:14 +0200
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Mon, Jun 06, 2016 at 01:24:24PM +0300, Aleksei Mamlin wrote:
> > > Enable the NFC and describe the NAND flash connected to this controller.
> > > 
> > > Signed-off-by: Aleksei Mamlin 
> > > ---
> > >  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 41 
> > > ++
> > >  1 file changed, 41 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts 
> > > b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > > index 2f6b21a..42aff91 100644
> > > --- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > > +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > > @@ -159,6 +159,47 @@
> > >   status = "okay";
> > >  };
> > >  
> > > +&nfc {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&nand_pins_a>, <&nand_cs0_pins_a>, <&nand_rb0_pins_a>;
> > > + status = "okay";
> > > +
> > > + nand@0 {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + reg = <0>;
> > > + allwinner,rb = <0>;
> > > +
> > > + nand-ecc-mode = "hw";
> > > + nand-on-flash-bbt;
> > > +
> > > + boot0@0 {
> > > + label = "boot0";
> > > + reg = /bits/ 64 <0x0 0x20>;
> > > + };
> > > +
> > > + boot0-rescue@20 {
> > > + label = "boot0-rescue";
> > > + reg = /bits/ 64 <0x20 0x20>;
> > > + };
> > > +
> > > + uboot@40 {
> > > + label = "uboot";
> > > + reg = /bits/ 64 <0x40 0x20>;
> > > + };
> > > +
> > > + uboot-rescue@60 {
> > > + label = "uboot-rescue";
> > > + reg = /bits/ 64 <0x60 0x20>;
> > > + };
> > > +
> > > + main@80 {
> > > + label = "main";
> > > + reg = /bits/ 64 <0x80 0xff80>;
> > > + };
> > > + };
> > > +};
> > 
> > This feels a bit premature. The two boards you're using have an MLC
> > NAND which is not supported yet. Until there's proper MLC support in
> > the kernel, I'm not sure we want to enable that for end-users when we
> > know that things will get wrong.
> > 
> > However, after discussing this with Boris, I appreciate that we don't
> > have any example available because of this policy for people that want
> > to opt-in anyway.
> > 
> > What we could do is to still mark the status as disabled in the DTS,
> > with a big fat warning as comment just before, so that it requires
> > user action, and that user will have been warned.
> > 
> > Would that work for you?
> > Maxime
> > 
> 
> Let's drop this two patches with boards dts changes until we get proper MLC
> support in kernel.
> 
> As for examples - I'll update linux-sunxi wiki with how to enable NAND 
> controller and describe NAND chips in DTS. People who want to add NAND 
> support 
> to their boards will be warned that it is risky for now.

That works for me too.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Alan, 

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年6月9日 3:14
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; Rob Herring ; Pawel Moll
> ; Mark Brown ; Ian Campbell
> ; Kumar Gala ;
> Alexandre Belloni ; Kernel development
> list ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; USB list 
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On Wed, 8 Jun 2016, Wenyou Yang wrote:
> 
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> You never answered the questions I posted for the first version of this
> patch:
> 
> What does this mean?  What does suspending a port do?  Is it the same as a
> normal USB port suspend?
> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?

I remembered I answered your questions, 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/429245.html

Maybe not very clear.

> 
> Alan Stern


Best Regards,
Wenyou Yang

Re: [PATCH trivial] include/linux/memory_hotplug.h: Clean up code

[Chen Gang]

On 6/10/16 14:11, kbuild test robot wrote:
> Hi,
> 
> [auto build test ERROR on next-20160609]
> [also build test ERROR on v4.7-rc2]
> [cannot apply to v4.7-rc2 v4.7-rc1 v4.6-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 

Oh, my patch is for linux-next 20160609 tree, can not apply to v4.7-rc2
directly.

[...]

> 
>In file included from include/linux/mmzone.h:741:0,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from include/linux/moduleloader.h:5,
> from arch/blackfin/kernel/module.c:9:
>include/linux/memory_hotplug.h: In function 'mhp_notimplemented':
>>> include/linux/memory_hotplug.h:225:2: error: 'mod' undeclared (first use in 
>>> this function)
>include/linux/memory_hotplug.h:225:2: note: each undeclared identifier is 
> reported only once for each function it appears in
> 
> vim +/mod +225 include/linux/memory_hotplug.h
> 
>219static inline void zone_span_writelock(struct zone *zone) {}
>220static inline void zone_span_writeunlock(struct zone *zone) {}
>221static inline void zone_seqlock_init(struct zone *zone) {}
>222
>223static inline int mhp_notimplemented(const char *func)
>224{
>  > 225pr_warn("%s() called, with CONFIG_MEMORY_HOTPLUG 
> disabled\n", func);
>226dump_stack();
>227return -ENOSYS;
>228}
> 

After "grep -rn pr_fmt * | grep define" under arch/, for me, it is
blackfin's issue:

  we need use

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

  instead of

#define pr_fmt(fmt) "module %s: " fmt, mod->name

I shall send one blackfin patch for it.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

Re: SIGSYS annoyance

[Mikael Pettersson]

Andy Lutomirski writes:
 > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook  wrote:
 > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski  
 > > wrote:
 > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
 > >>
 > >> Should SIGSYS be delivered to the handler even if blocked?  What, if
 > >> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
 > >>
 > >> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
 > >> while they are blocked, the result is undefined, unless the signal was
 > >> generated by the action of another process, or by one of the functions
 > >> kill(), pthread_kill(), raise(), or sigqueue().
 > >>
 > >> It would be easy enough to change our behavior so that we deliver the
 > >> signal even if it's blocked or to at least add a flag so that users
 > >> can request that behavior.
 > >
 > > I had trouble following that bug. It sounded like glib just needed a
 > > way to define its signal mask, and that's what they ended up
 > > implementing?
 > >
 > > I think the current behavior is correct. SIGSYS is being generated by
 > > the running process (i.e. the seccomp filter) and if it has a handler
 > > but the signal is blocked, we should treat it as uncaught and kill. On
 > > the other hand, it could be seen like "raise", in which case the
 > > blocking should be ignored? Is there an active problem somewhere here?
 > > It seems like the referenced bug has been fixed already.
 > 
 > Agreed.
 > 
 > It could make sense to have a new sigaction flag SA_FORCE: when set,
 > if a non-default handler is installed, the signal is blocked, and the
 > signal is triggered synchronously (forced), then the handler will be
 > called.  But that isn't specific to seccomp.

Blocking a signal is a very deliberate act.  If some piece of code wants
to force-deliver it, it can unblock it first.  IOW, I don't see the need
for this SA_FORCE thing.

Re: [PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

[Tomasz Figa]

Hi,

On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng  wrote:
> Use DMA API instead of architecture internal functions like
> __cpuc_flush_dcache_area() etc.
>
> To support the virtual device like DRM the virtual slave iommu
> added in the previous patch, attaching to which the DRM can use
> it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
>
> With this patch, this driver is available for ARM64 like RK3399.
>

Could we instead simply allocate coherent memory for page tables using
dma_alloc_coherent() and skip any flushing on CPU side completely? If
I'm looking correctly, the driver only reads back the page directory
when checking if there is a need to allocate new page table, so there
shouldn't be any significant penalty for disabling the cache.

Other than that, please see some comments inline.

> Signed-off-by: Shunqian Zheng 
> ---
>  drivers/iommu/rockchip-iommu.c | 113 
> ++---
>  1 file changed, 71 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index d6c3051..aafea6e 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -4,8 +4,6 @@
>   * published by the Free Software Foundation.
>   */
>
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -61,8 +59,7 @@
>  #define RK_MMU_IRQ_BUS_ERROR 0x02  /* bus read error */
>  #define RK_MMU_IRQ_MASK  (RK_MMU_IRQ_PAGE_FAULT | 
> RK_MMU_IRQ_BUS_ERROR)
>
> -#define NUM_DT_ENTRIES 1024
> -#define NUM_PT_ENTRIES 1024
> +#define NUM_TLB_ENTRIES 1024 /* for both DT and PT */

Is it necessary to change this in this patch? In general, it's not a
good idea to mix multiple logical changes together.

>
>  #define SPAGE_ORDER 12
>  #define SPAGE_SIZE (1 << SPAGE_ORDER)
> @@ -82,7 +79,9 @@
>
>  struct rk_iommu_domain {
> struct list_head iommus;
> +   struct device *dev;
> u32 *dt; /* page directory table */
> +   dma_addr_t dt_dma;
> spinlock_t iommus_lock; /* lock for iommus list */
> spinlock_t dt_lock; /* lock for modifying page directory table */
>
> @@ -98,14 +97,12 @@ struct rk_iommu {
> struct iommu_domain *domain; /* domain to which iommu is attached */
>  };
>
> -static inline void rk_table_flush(u32 *va, unsigned int count)
> +static inline void rk_table_flush(struct device *dev, dma_addr_t dma,
> + unsigned int count)
>  {
> -   phys_addr_t pa_start = virt_to_phys(va);
> -   phys_addr_t pa_end = virt_to_phys(va + count);
> -   size_t size = pa_end - pa_start;
> +   size_t size = count * 4;

It would be a good idea to specify what "count" is. I'm a bit confused
that before it meant bytes and now some multiple of 4?

Best regards,
Tomasz

[PATCH 4/4] dmaengine: dma: Rename driver and config

[Kedareswara rao Appana]

In the existing vdma driver support for
AXI DMA and CDMA got added so the driver is no
longer VDMA specific.

This patch renames the driver and DT binding doc to xilinx_dma
and updates the Kconfig description for all the DMAS.

Signed-off-by: Kedareswara rao Appana 
---
 .../dma/xilinx/{xilinx_vdma.txt => xilinx_dma.txt} |0
 drivers/dma/Kconfig|   13 +
 drivers/dma/xilinx/Makefile|2 +-
 drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} |0
 4 files changed, 10 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/dma/xilinx/{xilinx_vdma.txt => 
xilinx_dma.txt} (100%)
 rename drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} (100%)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
similarity index 100%
rename from Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
rename to Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 01a53ed..d7c03b6 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -519,19 +519,24 @@ config XGENE_DMA
help
  Enable support for the APM X-Gene SoC DMA engine.
 
-config XILINX_VDMA
-   tristate "Xilinx AXI VDMA Engine"
+config XILINX_DMA
+   tristate "Xilinx AXI DMAS Engine"
depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
- Enable support for Xilinx AXI VDMA Soft IP.
+ Enable support for Xilinx AXI DMAS Soft IP.
 
- This engine provides high-bandwidth direct memory access
+ AXI VDMA engine provides high-bandwidth direct memory access
  between memory and AXI4-Stream video type target
  peripherals including peripherals which support AXI4-
  Stream Video Protocol.  It has two stream interfaces/
  channels, Memory Mapped to Stream (MM2S) and Stream to
  Memory Mapped (S2MM) for the data transfers.
+ AXI CDMA engine provides high-bandwidth direct memory access
+ between a memory-mapped source address and a memory-mapped
+ destination address.
+ AXI DMA engine provides high-bandwidth one dimensional direct
+ memory access between memory and AXI4-Stream target peripherals.
 
 config XILINX_ZYNQMP_DMA
tristate "Xilinx ZynqMP DMA Engine"
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 95469dc..9e91f8f 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1,2 +1,2 @@
-obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_DMA) += xilinx_dma.o
 obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_dma.c
similarity index 100%
rename from drivers/dma/xilinx/xilinx_vdma.c
rename to drivers/dma/xilinx/xilinx_dma.c
-- 
1.7.1

Re: [PATCH v2 7/7] iommu/rockchip: enable rockchip iommu on ARM64 platform

[Tomasz Figa]

Hi,

On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng  wrote:
> From: Simon Xue 
>

It is usual a good practice to include at least a single sentence
here, even if the patch is trivial. In this case it could say

"This patch makes it possible to compile the rockchip-iommu driver on
ARM64 platform to be used with 64-bit SoCs equipped with this type of
IOMMU."

> Signed-off-by: Simon Xue 
> Signed-off-by: Shunqian Zheng 
> ---
>  drivers/iommu/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Assuming that the above is fixed:

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

[PATCH 0/4] dmaengine: vdma: AXI DMAS Enhancments

[Kedareswara rao Appana]

This patch series does the following thing.
---> Add support for AXI DMA Multi-channel DMA mode.
---> Delete AXI DMA binding doc.
---> Rename the driver and update config options.

This patch series is created on top of the patch series
"dmaengine: Add Xilinx zynqmp dma engine driver support".

Kedareswara rao Appana (4):
  Documentation: DT: vdma: Update binding doc for multi-channel dma
mode
  dmaengine: vdma: Add support for mulit-channel dma mode
  Documentation: DT: dma: Delete binding doc for AXI DMA
  dmaengine: dma: Rename driver and config

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   92 ++--
 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |  107 -
 drivers/dma/Kconfig|   13 +-
 drivers/dma/xilinx/Makefile|2 +-
 drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} |  242 ++--
 include/linux/dma/xilinx_dma.h |   18 ++
 6 files changed, 316 insertions(+), 158 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
 rename drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} (91%)

[PATCH 1/4] Documentation: DT: vdma: Update binding doc for multi-channel dma mode

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
AXI DMA multi channel dma mode.

Signed-off-by: Kedareswara rao Appana 
---
 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a1f2683..0faa189 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -40,6 +40,8 @@ Required properties for VDMA:
 Optional properties:
 - xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+Optional properties for AXI DMA:
+- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
 Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
@@ -60,6 +62,8 @@ Optional child node properties:
 Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
+Optional child node properties for AXI DMA:
+-dma-channels: Number of dma channels in child node.
 
 Example:
 
-- 
1.7.1

[PATCH 3/4] Documentation: DT: dma: Delete binding doc for AXI DMA

[Kedareswara rao Appana]

The AXI DMA support is added to the existing AXI VDMA
driver. Device tree binding information also updated
in the VDMA binding doc.

Signed-off-by: Kedareswara rao Appana 
---
 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   65 
 1 files changed, 0 insertions(+), 65 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
deleted file mode 100644
index 3cf0072..000
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
-target devices. It can be configured to have one channel or two channels.
-If configured as two channels, one is to transmit to the device and another
-is to receive from the device.
-
-Required properties:
-- compatible: Should be "xlnx,axi-dma-1.00.a"
-- #dma-cells: Should be <1>, see "dmas" property below
-- reg: Should contain DMA registers location and length.
-- dma-channel child node: Should have at least one channel and can have up to
-   two channels per device. This node specifies the properties of each
-   DMA channel (see child node properties below).
-
-Optional properties:
-- xlnx,include-sg: Tells whether configured for Scatter-mode in
-   the hardware.
-
-Required child node properties:
-- compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
-   "xlnx,axi-dma-s2mm-channel".
-- interrupts: Should contain per channel DMA interrupts.
-- xlnx,datawidth: Should contain the stream data width, take values
-   {32,64...1024}.
-
-Option child node properties:
-- xlnx,include-dre: Tells whether hardware is configured for Data
-   Realignment Engine.
-
-Example:
-
-
-axi_dma_0: axidma@4040 {
-   compatible = "xlnx,axi-dma-1.00.a";
-   #dma_cells = <1>;
-   reg = < 0x4040 0x1 >;
-   dma-channel@4040 {
-   compatible = "xlnx,axi-dma-mm2s-channel";
-   interrupts = < 0 59 4 >;
-   xlnx,datawidth = <0x40>;
-   } ;
-   dma-channel@40400030 {
-   compatible = "xlnx,axi-dma-s2mm-channel";
-   interrupts = < 0 58 4 >;
-   xlnx,datawidth = <0x40>;
-   } ;
-} ;
-
-
-* DMA client
-
-Required properties:
-- dmas: a list of <[DMA device phandle] [Channel ID]> pairs,
-   where Channel ID is '0' for write/tx and '1' for read/rx
-   channel.
-- dma-names: a list of DMA channel names, one per "dmas" entry
-
-Example:
-
-
-dmatest_0: dmatest@0 {
-   compatible ="xlnx,axi-dma-test-1.00.a";
-   dmas = <&axi_dma_0 0
-   &axi_dma_0 1>;
-   dma-names = "dma0", "dma1";
-} ;
-- 
1.7.1

[PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

[Kedareswara rao Appana]

This patch adds support for AXI DMA multi-channel dma mode
Multichannel mode enables DMA to connect to multiple masters
And slaves on the streaming side.
In Multichannel mode AXI DMA supports 2D transfers.

Signed-off-by: Kedareswara rao Appana 
---
 drivers/dma/xilinx/xilinx_vdma.c |  242 ++
 include/linux/dma/xilinx_dma.h   |   18 +++
 2 files changed, 237 insertions(+), 23 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 20fe5ea..480b0ba 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -114,7 +114,7 @@
 #define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
 
 /* HW specific definitions */
-#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x2
+#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x20
 
 #define XILINX_DMA_DMAXR_ALL_IRQ_MASK  \
(XILINX_DMA_DMASR_FRM_CNT_IRQ | \
@@ -165,6 +165,17 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* Multi-Channel DMA Descriptor offsets*/
+#define XILINX_DMA_MCRX_CDESC(x)   (0x40 + (x-1) * 0x20)
+#define XILINX_DMA_MCRX_TDESC(x)   (0x48 + (x-1) * 0x20)
+
+/* Multi-Channel DMA Masks/Shifts */
+#define XILINX_DMA_BD_HSIZE_MASK   GENMASK(15, 0)
+#define XILINX_DMA_BD_STRIDE_MASK  GENMASK(15, 0)
+#define XILINX_DMA_BD_VSIZE_MASK   GENMASK(31, 19)
+#define XILINX_DMA_BD_STRIDE_SHIFT 0
+#define XILINX_DMA_BD_VSIZE_SHIFT  19
+
 /* AXI CDMA Specific Registers/Offsets */
 #define XILINX_CDMA_REG_SRCADDR0x18
 #define XILINX_CDMA_REG_DSTADDR0x20
@@ -172,6 +183,13 @@
 /* AXI CDMA Specific Masks */
 #define XILINX_CDMA_CR_SGMODE  BIT(3)
 
+#define mm2s_mcdmatx_control(tdest, tid, tuser, axcache, aruser) \
+((aruser << 28) | (axcache << 24) | \
+(tuser << 16) | (tid << 8) | (tdest))
+
+#define mm2s_mcdmarx_control(axcache, aruser) \
+((aruser << 28) | (axcache << 24))
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -210,8 +228,8 @@ struct xilinx_axidma_desc_hw {
u32 next_desc_msb;
u32 buf_addr;
u32 buf_addr_msb;
-   u32 pad1;
-   u32 pad2;
+   u32 mcdma_fields;
+   u32 vsize_stride;
u32 control;
u32 status;
u32 app[XILINX_DMA_NUM_APP_WORDS];
@@ -318,6 +336,7 @@ struct xilinx_dma_tx_descriptor {
  * @residue: Residue for AXI DMA
  * @seg_v: Statically allocated segments base
  * @cyclic_seg_v: Statically allocated segment base for cyclic transfers
+ * @mcdma_config: Device configuration info for MCDMA
  * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
@@ -348,6 +367,7 @@ struct xilinx_dma_chan {
u32 residue;
struct xilinx_axidma_tx_segment *seg_v;
struct xilinx_axidma_tx_segment *cyclic_seg_v;
+   struct xilinx_mcdma_config mcdma_config;
void (*start_transfer)(struct xilinx_dma_chan *chan);
 };
 
@@ -365,6 +385,7 @@ struct xilinx_dma_config {
  * @common: DMA device structure
  * @chan: Driver specific DMA channel
  * @has_sg: Specifies whether Scatter-Gather is present or not
+ * @mcdma: Specifies whether Multi-Channel is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
  * @pdev: Platform device structure pointer
@@ -374,6 +395,8 @@ struct xilinx_dma_config {
  * @txs_clk: DMA mm2s stream clock
  * @rx_clk: DMA s2mm clock
  * @rxs_clk: DMA s2mm stream clock
+ * @nr_channels: Number of channels DMA device supports
+ * @chan_id: DMA channel identifier
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -381,6 +404,7 @@ struct xilinx_dma_device {
struct dma_device common;
struct xilinx_dma_chan *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
bool has_sg;
+   bool mcdma;
u32 flush_on_fsync;
bool ext_addr;
struct platform_device  *pdev;
@@ -390,6 +414,8 @@ struct xilinx_dma_device {
struct clk *txs_clk;
struct clk *rx_clk;
struct clk *rxs_clk;
+   u32 nr_channels;
+   u32 chan_id;
 };
 
 /* Macros */
@@ -1174,6 +1200,7 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
 {
struct xilinx_dma_tx_descriptor *head_desc, *tail_desc;
struct xilinx_axidma_tx_segment *tail_segment, *old_head, *new_head;
+   struct xilinx_mcdma_config *config = &chan->mcdma_config;
u32 reg;
 
if (chan->err)
@@ -1196,18 +1223,20 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
tail_segment = list_last_entry(&tail_desc->segments,
   struct xilinx_axidma_tx_segment, node);
 
-   old_head = list_first_entry(&head_desc->segments,
-   struct xilinx_axidma_t

Re: Add MediaTek USB3 DRD Driver

[chunfeng yun]

Hi,
On Fri, 2016-06-10 at 15:32 +0800, Chunfeng Yun wrote:
> From 8fdc924cecf0ca14da6e8aba360501e53437e548 Mon Sep 17 00:00:00 2001
> From: Chunfeng Yun 
> Date: Fri, 10 Jun 2016 15:20:20 +0800
> Subject: [PATCH 0/5] Add MediaTek USB3 DRD Driver
> 
> These patches introduce the MediaTek USB3 dual-role controller
> driver.
> 
> The driver can be configured as Dual-Role Device (DRD),
> Peripheral Only and Host Only (xHCI) modes. It works well
> with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> tested on MT8173 platform which only contains USB2.0 device IP,
> and on MT6290 platform which contains USB3.0 device IP.
> 
> Change in v3:
> 1. fix some typo error
> 2. rename mtu3.txt to mt8173-mtu3.txt
> 
> Change in v2:
> 1. modify binding docs according to suggestions
> 2. modify some comments and remove some dummy blank lines
> 3. fix memory leakage
> 
> Chunfeng Yun (5):
>   dt-bindings: mt8173-xhci: support host side of dual-role mode
>   dt-bindings: mt8173-mtu3: add devicetree bindings

Could you please help me to review the following two patches based on
v4.7-rc1:
  1- usb: xhci-mtk: make IPPC register optional
  2- usb: Add MediaTek USB3 DRD Driver

Thank you very much

>   usb: xhci-mtk: make IPPC register optional
>   usb: Add MediaTek USB3 DRD Driver
>   arm64: dts: mediatek: add USB3 DRD driver
> 
>  .../devicetree/bindings/usb/mt8173-mtu3.txt|   85 ++
>  .../devicetree/bindings/usb/mt8173-xhci.txt|   48 ++
>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   28 +-
>  drivers/usb/Kconfig|2 +
>  drivers/usb/Makefile   |1 +
>  drivers/usb/host/xhci-mtk.c|   32 +-
>  drivers/usb/mtu3/Kconfig   |   47 ++
>  drivers/usb/mtu3/Makefile  |   20 +
>  drivers/usb/mtu3/mtu3.h|  422 ++
>  drivers/usb/mtu3/mtu3_core.c   |  879 
> 
>  drivers/usb/mtu3/mtu3_dr.c |  348 
>  drivers/usb/mtu3/mtu3_dr.h |  108 +++
>  drivers/usb/mtu3/mtu3_gadget.c |  731 
>  drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
> 
>  drivers/usb/mtu3/mtu3_host.c   |  294 +++
>  drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
>  drivers/usb/mtu3/mtu3_plat.c   |  490 +++
>  drivers/usb/mtu3/mtu3_qmu.c|  599 +
>  drivers/usb/mtu3/mtu3_qmu.h|   43 +
>  20 files changed, 5562 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
>  create mode 100644 drivers/usb/mtu3/Kconfig
>  create mode 100644 drivers/usb/mtu3/Makefile
>  create mode 100644 drivers/usb/mtu3/mtu3.h
>  create mode 100644 drivers/usb/mtu3/mtu3_core.c
>  create mode 100644 drivers/usb/mtu3/mtu3_dr.c
>  create mode 100644 drivers/usb/mtu3/mtu3_dr.h
>  create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
>  create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
>  create mode 100644 drivers/usb/mtu3/mtu3_host.c
>  create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
>  create mode 100644 drivers/usb/mtu3/mtu3_plat.c
>  create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
>  create mode 100644 drivers/usb/mtu3/mtu3_qmu.h
> 
> --
> 1.7.9.5
> 
> 

Re: [PATCH] usb: dwc3: fix runtime PM in error path

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> If there is a failure after pm_runtime_enable/get_sync()
> we need to call pm_runtime_disable/put_sync().
>
> Otherwise it will lead to an unbalanced pm_runtime_enable() on the
> subsequent probe if the earlier probe bailed out due to -EPROBE_DEFER.
>
> Signed-off-by: Roger Quadros 

where is this supposed to be applied? You're not checking if
pm_runtime_get() failed at all.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] arch/blackfin/kernel/module.c: Use KBUILD_MODNAME instead of mod->name for pr_fmt()

[chengang]

From: Chen Gang 

When use pr_warn(), it will break building because of mod undefined, so
fix it just like another architectures have done.

Signed-off-by: Chen Gang 
---
 arch/blackfin/kernel/module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/blackfin/kernel/module.c b/arch/blackfin/kernel/module.c
index 4489efc..162b2a2 100644
--- a/arch/blackfin/kernel/module.c
+++ b/arch/blackfin/kernel/module.c
@@ -4,7 +4,7 @@
  * Licensed under the GPL-2 or later
  */
 
-#define pr_fmt(fmt) "module %s: " fmt, mod->name
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
 #include 
-- 
1.9.3

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> On 10/06/16 11:18, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Roger Quadros  writes:
dwc->xhci_resource[1] = *res;
>>>
>>> Probably not as we don't want to change parent/child members.
>> 
>> oh, you had already replied. Sorry. This is correct
>> 
> np :).
>
> So what i'll do is get the irq via platform_get_irq() and friends
> and if it was a success use platform_get_resource() and friends
> to get struct resource and just edit the relevant parts for the
> XHCI irq resource.
>
> Sounds OK?
>
> something like this.
>
> + int ret, irq;
> + struct resource *res;
> + struct platform_device  *dwc3_pdev = to_platform_device(dwc->dev);
> +
> + irq = platform_get_irq_byname(dwc3_pdev, "host");
> + if (irq == -EPROBE_DEFER)
> + return irq;
> +
> + if (irq <= 0) {
> + irq = platform_get_irq_byname(dwc3_pdev, "dwc_usb3");
> + if (irq == -EPROBE_DEFER)
> + return irq;
> +
> + if (irq <= 0) {
> + irq = platform_get_irq(dwc3_pdev, 0);
> + if (irq <= 0) {
> + if (irq != -EPROBE_DEFER) {
> + dev_err(dwc->dev,
> + "missing host IRQ\n");
> + }
> + return irq;
> + } else {
> + res = platform_get_resource(dwc3_pdev,
> + IORESOURCE_IRQ, 0);
> + }
> + } else {
> + res = platform_get_resource_byname(dwc3_pdev,
> +IORESOURCE_IRQ,
> +"dwc_usb3");
> + }
> +
> + } else {
> + res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
> +"host");
> + }
> +
> + dwc->xhci_resources[1].start = irq;
> + dwc->xhci_resources[1].end = irq;
> + dwc->xhci_resources[1].flags = res->flags;
> + dwc->xhci_resources[1].name = res->name;

looks okay to me.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v3,2/5] dt-bindings: mt8173-mtu3: add devicetree bindings

[Felipe Balbi]

Hi,

Chunfeng Yun  writes:
> + - enable-manual-drd : supports manual dual-role switch via sysfs; only used
> + when receptacle is TYPE-A and also wants to support dual-role mode.

sorry, but this manual-drd can't be accepted. You should rely on a DT
property for this and you shouldn't expose it to sysfs. Use DebugFS for
that.


-- 
balbi


signature.asc
Description: PGP signature

[ldv-project] [net] rtl8188ee: a potential race condition

[Pavel Andrianov]

Hi!

There is a potential data race in 
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rtl8188ee.ko.


In the function rtl88ee_gpio_radio_on_off_checking the flag 
ppsc->rfchange_inprogress is set with a spinlock protection. In the 
function rtl_ps_set_rf_state the flag is read also under a spinlock. But 
the function rtl88e_dm_watchdog read it without any locks. As a result 
rtl88e_dm_watchdog may execute the succeeding code while changing (with 
the flag rfchange_inprogress == true). I do not exactly determine the 
consequences, but likely they are not good if there exists such check. 
Could anybody more confident confirm this?


The function rtl_ps_set_rf_state is always called with its parameter 
[protect_or_not == false]. Is this flag really necessary, if the value 
'true' is never used? The function is also set the flag 
ppsc->rfchange_inprogress and may affect the rtl88e_dm_watchdog as in 
the previous case.


--
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andria...@ispras.ru

Re: Add MediaTek USB3 DRD Driver

[Felipe Balbi]

Hi,

Chunfeng Yun  writes:
> From 8fdc924cecf0ca14da6e8aba360501e53437e548 Mon Sep 17 00:00:00 2001
> From: Chunfeng Yun 
> Date: Fri, 10 Jun 2016 15:20:20 +0800
> Subject: [PATCH 0/5] Add MediaTek USB3 DRD Driver
>
> These patches introduce the MediaTek USB3 dual-role controller
> driver.
>
> The driver can be configured as Dual-Role Device (DRD),
> Peripheral Only and Host Only (xHCI) modes. It works well
> with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> tested on MT8173 platform which only contains USB2.0 device IP,
> and on MT6290 platform which contains USB3.0 device IP.
>
> Change in v3:
> 1. fix some typo error
> 2. rename mtu3.txt to mt8173-mtu3.txt
>
> Change in v2:
> 1. modify binding docs according to suggestions
> 2. modify some comments and remove some dummy blank lines
> 3. fix memory leakage

I don't see anything inherently wrong with this series. But keep in mind
I don't have HW to test. I can take the peripheral driver in a few days.

-- 
balbi


signature.asc
Description: PGP signature

[tip:timers/core] hrtimer: Remove redundant #ifdef block

[tip-bot for Pratyush Patel]

Commit-ID:  86721ab63b61ef1dd7305308e4049f644703decf
Gitweb: http://git.kernel.org/tip/86721ab63b61ef1dd7305308e4049f644703decf
Author: Pratyush Patel 
AuthorDate: Tue, 1 Mar 2016 22:58:49 +0530
Committer:  Thomas Gleixner 
CommitDate: Fri, 10 Jun 2016 11:25:35 +0200

hrtimer: Remove redundant #ifdef block

Only need CONFIG_NO_HZ_COMMON as this block is already in a
CONFIG_SMP block.

Signed-off-by: Pratyush Patel 
Link: http://lkml.kernel.org/r/20160301172849.GA18152@cyborg
Signed-off-by: Thomas Gleixner 
---
 kernel/time/hrtimer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index e99df0f..d13c9ae 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -177,7 +177,7 @@ hrtimer_check_target(struct hrtimer *timer, struct 
hrtimer_clock_base *new_base)
 #endif
 }
 
-#if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
+#ifdef CONFIG_NO_HZ_COMMON
 static inline
 struct hrtimer_cpu_base *get_target_base(struct hrtimer_cpu_base *base,
 int pinned)

Re: [PATCH 1/3] drivers: input: powerkey for HISI 65xx SoC

[kbuild test robot]

Hi,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.7-rc2 next-20160609]
[cannot apply to input/next]
[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/John-Stultz/Hi655x-powerkey-support-for-HiKey-v3/20160610-133804
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   drivers/input/misc/hisi_powerkey.c:135:1: error: 'hi65xx_powerkey_of_match' 
undeclared here (not in a function)
>> drivers/input/misc/hisi_powerkey.c:135:1: error: 
>> '__mod_of__hi65xx_powerkey_of_match_device_table' aliased to undefined 
>> symbol 'hi65xx_powerkey_of_match'

vim +135 drivers/input/misc/hisi_powerkey.c

   129  static int hi65xx_powerkey_remove(struct platform_device *pdev)
   130  {
   131  device_init_wakeup(&pdev->dev, 0);
   132  return 0;
   133  }
   134  
 > 135  MODULE_DEVICE_TABLE(of, hi65xx_powerkey_of_match);
   136  
   137  static struct platform_driver hi65xx_powerkey_driver = {
   138  .driver = {

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


.config.gz
Description: Binary data

Re: [PATCH 0/3] ARM: OMAP: DRA7: Update to latest TRM and cleanup

[Tony Lindgren]

Hi,

* Nishanth Menon  [160524 06:37]:
> Hi,
> 
> Here are the final(hopefully) pending patches for DRA7 based on recent
> TRM updates. Updates include removing retention support on L3init and
> L4per as per latest SoC updates.
> 
> Test Log: X15 (no modules): http://pastebin.ubuntu.com/16655027/
> 
> Latest TRM (rev F): http://www.ti.com/lit/pdf/spruhz6 (public on May 18)
> 
> Nishanth Menon (3):
>   ARM: OMAP: DRA7: powerdomain data: Set L3init and L4per to ON
>   ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_logic_ret
>   ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_mem_ret
> 
>  arch/arm/mach-omap2/powerdomains7xx_data.c | 76 
> +-
>  1 file changed, 2 insertions(+), 74 deletions(-)

Can these wait until v4.8 merge window, are this needed as fixes to
avoid hardware problems?

Regards,

Tony

[PATCH 2/2] ARM: dts: sd_600eval: Fix eMMC lockup issue

[Srinivas Kandagatla]

From: Parth Pancholi 

This board locks up if we stress test the eMMC, as the regulator s4 is
unable to supply enough current for all the peripherials attached to it.
As this supply is wired up to most of the peripherials including DDR,
it resulted in such lockup.

This patch fixes this issue by setting s4 regulator correctly with
Auto power mode.

Reported-by: Srinivas Kandagatla 
[Srinivas Kandagatla: rewrote the change log]
Tested-by: Girish Sharma 
Signed-off-by: Parth Pancholi 
---
 arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts 
b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
index 7df0108..39ae2bc 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
@@ -1,6 +1,7 @@
 #include "qcom-apq8064-v2.0.dtsi"
 #include "qcom-apq8064-arrow-sd-600eval-pins.dtsi"
 #include 
+#include 
 
 / {
model = "Arrow Electronics, APQ8064 SD_600eval";
@@ -82,7 +83,8 @@
s4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-   qcom,switch-mode-frequency = <320>;
+   qcom,switch-mode-frequency = <160>;
+   qcom,force-mode = 
;
bias-pull-down;
regulator-always-on;
};
-- 
2.8.3

[PATCH 1/2] ARM: dts: apq8064: rename db600c to SD_600eval

[Srinivas Kandagatla]

This board has been renamed recently and announced at
https://eragon.einfochips.com/products/sd-600eval.html

So rename this board files so that it reflects actual product in market.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/Makefile |   2 +-
 .../boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi   |  52 ---
 arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts| 349 -
 .../dts/qcom-apq8064-arrow-sd-600eval-pins.dtsi|  52 +++
 .../arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts | 349 +
 5 files changed, 402 insertions(+), 402 deletions(-)
 delete mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
 delete mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval-pins.dtsi
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 488a943..66e182c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -573,7 +573,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
 dtb-$(CONFIG_ARCH_OXNAS) += \
wd-mbwe.dtb
 dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-apq8064-arrow-db600c.dtb \
+   qcom-apq8064-arrow-sd-600eval.dtb \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
qcom-apq8064-sony-xperia-yuga.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi 
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
deleted file mode 100644
index a3efb97..000
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
+++ /dev/null
@@ -1,52 +0,0 @@
-&tlmm_pinmux {
-   card_detect: card-detect {
-   mux {
-   pins = "gpio26";
-   function = "gpio";
-   bias-disable;
-   };
-   };
-
-   pcie_pins: pcie-pinmux {
-   mux {
-   pins = "gpio27";
-   function = "gpio";
-   };
-   conf {
-   pins = "gpio27";
-   drive-strength = <12>;
-   bias-disable;
-   };
-   };
-
-   user_leds: user-leds {
-   mux {
-   pins = "gpio3", "gpio7", "gpio10", "gpio11";
-   function = "gpio";
-   };
-
-   conf {
-   pins = "gpio3", "gpio7", "gpio10", "gpio11";
-   function = "gpio";
-   output-low;
-   };
-   };
-
-   magneto_pins: magneto-pins {
-   mux {
-   pins = "gpio31", "gpio48";
-   function = "gpio";
-   bias-disable;
-   };
-   };
-};
-
-&pm8921_mpps {
-   mpp_leds: mpp-leds {
-   pinconf {
-   pins = "mpp7", "mpp8";
-   function = "digital";
-   output-low;
-   };
-   };
-};
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts 
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
deleted file mode 100644
index e01b27e..000
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ /dev/null
@@ -1,349 +0,0 @@
-#include "qcom-apq8064-v2.0.dtsi"
-#include "qcom-apq8064-arrow-db600c-pins.dtsi"
-#include 
-
-/ {
-   model = "Arrow Electronics, APQ8064 DB600c";
-   compatible = "arrow,db600c", "qcom,apq8064";
-
-   aliases {
-   serial0 = &gsbi7_serial;
-   serial1 = &gsbi1_serial;
-   i2c0 = &gsbi2_i2c;
-   i2c1 = &gsbi3_i2c;
-   i2c2 = &gsbi4_i2c;
-   i2c3 = &gsbi7_i2c;
-   spi0 = &gsbi5_spi;
-   };
-
-   regulators {
-   compatible = "simple-bus";
-   vph: regulator-fixed@1 {
-   compatible = "regulator-fixed";
-   regulator-min-microvolt = <450>;
-   regulator-max-microvolt = <450>;
-   regulator-name = "VPH";
-   regulator-type = "voltage";
-   regulator-boot-on;
-   };
-
-   /* on board fixed 3.3v supply */
-   vcc3v3: vcc3v3 {
-   compatible = "regulator-fixed";
-   regulator-name = "VCC3V3";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   };
-
-   soc {
-   rpm@108000 {
-   regulators {
-   vdd_s1-supply = <&vph>;
-   vdd_s2-supply = <&vph>;
-   vdd_s3-supply = <&vph>;
-   vdd_s4-supply = <&vph>;
-   

Re: [PATCH 0/2] ARM: dts: sunxi: Re-order sun4i and sun7i pinctrl nodes alphabetically

[Maxime Ripard]

On Fri, Jun 10, 2016 at 11:05:17AM +0300, Aleksei Mamlin wrote:
> Hello,
> 
> This patchset have no functional changes, only sorting sun4i and sun7i pinctrl
> nodes in alphabetical order.

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] mm, slaub: Add __GFP_ATOMIC to the GFP reclaim mask

[Mel Gorman]

Commit d0164adc89f6 ("mm, page_alloc: distinguish between being unable to
sleep, unwilling to sleep and avoiding waking kswapd") modified __GFP_WAIT
to explicitly identify the difference between atomic callers and those that
were unwilling to sleep. Later the definition was removed entirely.

The GFP_RECLAIM_MASK is the set of flags that affect watermark checking
and reclaim behaviour but __GFP_ATOMIC was never added. Without it, atomic
users of the slab allocator strip the __GFP_ATOMIC flag and cannot access
the page allocator atomic reserves.  This patch addresses the problem.

The user-visible impact depends on the workload but potentially atomic
allocations unnecessarily fail without this path.

Cc:  # 4.4+
Reported-by: Marcin Wojtas 
Signed-off-by: Mel Gorman 
---
 mm/internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/internal.h b/mm/internal.h
index a37e5b6f9d25..2524ec880e24 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -24,7 +24,8 @@
  */
 #define GFP_RECLAIM_MASK (__GFP_RECLAIM|__GFP_HIGH|__GFP_IO|__GFP_FS|\
__GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL|\
-   __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC)
+   __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC|\
+   __GFP_ATOMIC)
 
 /* The GFP flags allowed during early boot */
 #define GFP_BOOT_MASK (__GFP_BITS_MASK & ~(__GFP_RECLAIM|__GFP_IO|__GFP_FS))

[PATCH 1/2] ARM: dts: apq8064: move sdcc1 pinctrl nodes to soc file

[Srinivas Kandagatla]

This patch moves out the sdcc1 pinctrl nodes out of board files to soc file,
so that it will be duplicated in other board files.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi   | 20 
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts | 22 --
 arch/arm/boot/dts/qcom-apq8064.dtsi|  2 ++
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi 
b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 4102a98..ca683e5 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -7,6 +7,26 @@
};
};
 
+   sdcc1_pins: sdcc1-pin-active {
+   clk {
+   pins = "sdc1_clk";
+   drive-strengh = <16>;
+   bias-disable;
+   };
+
+   cmd {
+   pins = "sdc1_cmd";
+   drive-strengh = <10>;
+   bias-pull-up;
+   };
+
+   data {
+   pins = "sdc1_data";
+   drive-strengh = <10>;
+   bias-pull-up;
+   };
+   };
+
ps_hold: ps_hold {
mux {
pins = "gpio78";
diff --git a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts 
b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
index 06b3c76..93d08b9 100644
--- a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
@@ -70,25 +70,6 @@
};
};
 
-   sdcc1_pin_a: sdcc1-pin-active {
-   clk {
-   pins = "sdc1_clk";
-   drive-strengh = <16>;
-   bias-disable;
-   };
-
-   cmd {
-   pins = "sdc1_cmd";
-   drive-strengh = <10>;
-   bias-pull-up;
-   };
-
-   data {
-   pins = "sdc1_data";
-   drive-strengh = <10>;
-   bias-pull-up;
-   };
-   };
 
sdcc3_pin_a: sdcc3-pin-active {
clk {
@@ -417,9 +398,6 @@
 
vmmc-supply = <&pm8921_l5>;
vqmmc-supply = <&pm8921_s4>;
-
-   pinctrl-names = "default";
-   pinctrl-0 = <&sdcc1_pin_a>;
};
 
sdcc3: sdcc@1218 {
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index cf37d55..ce7ce84 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -859,6 +859,8 @@
sdcc1: sdcc@1240 {
status  = "disabled";
compatible  = "arm,pl18x", "arm,primecell";
+   pinctrl-names   = "default";
+   pinctrl-0   = <&sdcc1_pins>;
arm,primecell-periphid = <0x00051180>;
reg = <0x1240 0x2000>;
interrupts  = ;
-- 
2.8.3

[PATCH 2/2] ARM: dts: apq8064: move sdcc3 pinctrls out of baord file

[Srinivas Kandagatla]

This patch move sdcc3 pinctrl nodes out of board file, so that
other boards do not duplicate the same thing.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi   | 20 
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts | 22 +-
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi 
b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index ca683e5..6b801e7 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -27,6 +27,26 @@
};
};
 
+   sdcc3_pins: sdcc3-pin-active {
+   clk {
+   pins = "sdc3_clk";
+   drive-strengh = <8>;
+   bias-disable;
+   };
+
+   cmd {
+   pins = "sdc3_cmd";
+   drive-strengh = <8>;
+   bias-pull-up;
+   };
+
+   data {
+   pins = "sdc3_data";
+   drive-strengh = <8>;
+   bias-pull-up;
+   };
+   };
+
ps_hold: ps_hold {
mux {
pins = "gpio78";
diff --git a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts 
b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
index 93d08b9..ebd675c 100644
--- a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
@@ -71,26 +71,6 @@
};
 
 
-   sdcc3_pin_a: sdcc3-pin-active {
-   clk {
-   pins = "sdc3_clk";
-   drive-strengh = <8>;
-   bias-disable;
-   };
-
-   cmd {
-   pins = "sdc3_cmd";
-   drive-strengh = <8>;
-   bias-pull-up;
-   };
-
-   data {
-   pins = "sdc3_data";
-   drive-strengh = <8>;
-   bias-pull-up;
-   };
-   };
-
sdcc3_cd_pin_a: sdcc3-cd-pin-active {
pins = "gpio26";
function = "gpio";
@@ -407,7 +387,7 @@
cd-gpios = <&tlmm_pinmux 26 GPIO_ACTIVE_LOW>;
 
pinctrl-names = "default";
-   pinctrl-0 = <&sdcc3_pin_a>, <&sdcc3_cd_pin_a>;
+   pinctrl-0 = <&sdcc3_pins>, <&sdcc3_cd_pin_a>;
};
};
};
-- 
2.8.3

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Maxime Ripard]

On Fri, Jun 03, 2016 at 02:13:36PM +0800, luoyi...@gmail.com wrote:
> From: Luo Yi 
> 
> Remove the extra empty line and add signed off. 
> 
> Signed-off-by: Luo Yi 

Please send a new patch.

> ---
>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> index 6fd55d7..f9063ba 100644
> --- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> @@ -47,7 +47,6 @@
>   compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
>  };
>  
> -
>  &codec {
>   status = "okay";
>  };
> @@ -62,11 +61,8 @@
>   interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>; 
>   interrupt-names = "host-wake";
>   };
> -
>  };
>  
>  &mmc3_pins_a {
> -/* AP6210 requires pull-up */

And that comment was fine, why did you remove it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Maxime Ripard]

On Thu, Jun 02, 2016 at 11:15:55AM +0200, Bernhard Nortmann wrote:
> Am 02.06.2016 um 10:16 schrieb Maxime Ripard:
> >[...]
> >Yes, everything that is shared with the banana-pro (which, judging
> >from Bernhard, is pretty much everything but a GPIO) should be merged
> >in the banapro DT.
> >
> >Maxime
> >
> 
> Don't take my word for granted, as I do not own this hardware or know it
> particularly well. There is no doubt that "BPi-M1+" and "Banana Pro" are
> very similar, but if in doubt the information form the wiki should be
> verified.

H, ok. Chen-Yu, any input on this? You know the banana-pis much
more than I do.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[tip:x86/cleanups] lguest: Read length of device_cap later

[tip-bot for Paul Bolle]

Commit-ID:  7faf90ef995ea470f32f43810266ece8ac8ba6c7
Gitweb: http://git.kernel.org/tip/7faf90ef995ea470f32f43810266ece8ac8ba6c7
Author: Paul Bolle 
AuthorDate: Thu, 3 Mar 2016 13:01:40 +0100
Committer:  Thomas Gleixner 
CommitDate: Fri, 10 Jun 2016 11:39:09 +0200

lguest: Read length of device_cap later

Read the length of the capability with type VIRTIO_PCI_CAP_DEVICE_CFG
only when we're sure we're going to need it. Which is just before the
check whether the virtio console actually has an emerg_wr field.

Signed-off-by: Paul Bolle 
Cc: Rusty Russell 
Cc: lgu...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1457006501-5377-2-git-send-email-pebo...@tiscali.nl
Signed-off-by: Thomas Gleixner 

---
 arch/x86/lguest/boot.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 3847e73..146d11c 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1258,7 +1258,7 @@ static void probe_pci_console(void)
u8 vndr = read_pci_config_byte(0, 1, 0, cap);
if (vndr == PCI_CAP_ID_VNDR) {
u8 type, bar;
-   u32 offset, length;
+   u32 offset;
 
type = read_pci_config_byte(0, 1, 0,
cap + offsetof(struct virtio_pci_cap, cfg_type));
@@ -1266,15 +1266,12 @@ static void probe_pci_console(void)
cap + offsetof(struct virtio_pci_cap, bar));
offset = read_pci_config(0, 1, 0,
cap + offsetof(struct virtio_pci_cap, offset));
-   length = read_pci_config(0, 1, 0,
-   cap + offsetof(struct virtio_pci_cap, length));
 
switch (type) {
case VIRTIO_PCI_CAP_DEVICE_CFG:
if (bar == 0) {
device_cap = cap;
device_offset = offset;
-   device_len = length;
}
break;
case VIRTIO_PCI_CAP_PCI_CFG:
@@ -1297,6 +1294,8 @@ static void probe_pci_console(void)
 * emerg_wr.  If it doesn't support VIRTIO_CONSOLE_F_EMERG_WRITE
 * it should ignore the access.
 */
+   device_len = read_pci_config(0, 1, 0,
+   device_cap + offsetof(struct virtio_pci_cap, length));
if (device_len < (offsetof(struct virtio_console_config, emerg_wr)
  + sizeof(u32))) {
printk(KERN_ERR "lguest: console missing emerg_wr field\n");

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

[Krzysztof Kozlowski]

On 06/09/2016 11:28 PM, Rhyland Klein wrote:
> Change power_supply_read_temp() to use power_supply_get_property()
> so that it will check the use_cnt and ensure it is > 0. The use_cnt
> will be incremented at the end of __power_supply_register, so this
> will block to case where get_property can be called before the supply
> is fully registered. This fixes the issue show in the stack below:
> 
> [1.452598] power_supply_read_temp+0x78/0x80
> [1.458680] thermal_zone_get_temp+0x5c/0x11c
> [1.464765] thermal_zone_device_update+0x34/0xb4
> [1.471195] thermal_zone_device_register+0x87c/0x8cc
> [1.477974] __power_supply_register+0x364/0x424
> [1.484317] power_supply_register_no_ws+0x10/0x18
> [1.490833] bq27xxx_battery_setup+0x10c/0x164
> [1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0
> [1.503435] i2c_device_probe+0x174/0x240
> [1.509172] driver_probe_device+0x1fc/0x29c
> [1.515167] __driver_attach+0xa4/0xa8
> [1.520643] bus_for_each_dev+0x58/0x98
> [1.526204] driver_attach+0x20/0x28
> [1.531505] bus_add_driver+0x1c8/0x22c
> [1.537067] driver_register+0x68/0x108
> [1.542630] i2c_register_driver+0x38/0x7c
> [1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20
> [1.555321] do_one_initcall+0x38/0x12c
> [1.560886] kernel_init_freeable+0x148/0x1ec
> [1.566972] kernel_init+0x10/0xfc
> [1.572101] ret_from_fork+0x10/0x40
> 
> Also make the same change to ps_get_max_charge_cntl_limit() and
> ps_get_cur_chrage_cntl_limit() to be safe. Lastly, change the return
> value of power_supply_get_property() to -EAGAIN from -ENODEV if
> use_cnt <= 0.
> 
> Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rhyland Klein 
> ---
> v4:
>  - Fixed return check conditions
>  - Removed change to power_supply_get_property return code
>  - removed whitespace change
> 
> v3:
>  - Changed calls to ->get_property() to use common
>power_supply_get_property()
>  - reworded description, added "Fixes" line
>  - Changed return value of power_supply_get_property() to -EAGAIN
> 
> v2:
>  - Added cc stable
>  - changed return to -EAGAIN in case of use_cnt < 1
>  - Removed WARNING
>  - return value check added in additional patch:
>https://patchwork.kernel.org/patch/9158805/
> 
>  drivers/power/power_supply_core.c | 27 ---
>  1 file changed, 16 insertions(+), 11 deletions(-)

Looks okay:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[tip:x86/cleanups] lguest: Read offset of device_cap later

[tip-bot for Paul Bolle]

Commit-ID:  cf2cf0f50c14e86e04cda2c684357eed77922666
Gitweb: http://git.kernel.org/tip/cf2cf0f50c14e86e04cda2c684357eed77922666
Author: Paul Bolle 
AuthorDate: Thu, 3 Mar 2016 13:01:41 +0100
Committer:  Thomas Gleixner 
CommitDate: Fri, 10 Jun 2016 11:39:09 +0200

lguest: Read offset of device_cap later

Read the offset of the capability with type VIRTIO_PCI_CAP_DEVICE_CFG
only when we're sure we're going to need it. Which is when all checks
have passed and we know we have a virtio console with an emerg_wr field.

Signed-off-by: Paul Bolle 
Cc: Rusty Russell 
Cc: lgu...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1457006501-5377-3-git-send-email-pebo...@tiscali.nl
Signed-off-by: Thomas Gleixner 

---
 arch/x86/lguest/boot.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 146d11c..25da5bc8 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1233,8 +1233,6 @@ static void write_bar_via_cfg(u32 cfg_offset, u32 off, 
u32 val)
 static void probe_pci_console(void)
 {
u8 cap, common_cap = 0, device_cap = 0;
-   /* Offset within BAR0 */
-   u32 device_offset;
u32 device_len;
 
/* Avoid recursive printk into here. */
@@ -1258,21 +1256,16 @@ static void probe_pci_console(void)
u8 vndr = read_pci_config_byte(0, 1, 0, cap);
if (vndr == PCI_CAP_ID_VNDR) {
u8 type, bar;
-   u32 offset;
 
type = read_pci_config_byte(0, 1, 0,
cap + offsetof(struct virtio_pci_cap, cfg_type));
bar = read_pci_config_byte(0, 1, 0,
cap + offsetof(struct virtio_pci_cap, bar));
-   offset = read_pci_config(0, 1, 0,
-   cap + offsetof(struct virtio_pci_cap, offset));
 
switch (type) {
case VIRTIO_PCI_CAP_DEVICE_CFG:
-   if (bar == 0) {
+   if (bar == 0)
device_cap = cap;
-   device_offset = offset;
-   }
break;
case VIRTIO_PCI_CAP_PCI_CFG:
console_access_cap = cap;
@@ -1302,7 +1295,8 @@ static void probe_pci_console(void)
return;
}
 
-   console_cfg_offset = device_offset;
+   console_cfg_offset = read_pci_config(0, 1, 0,
+   device_cap + offsetof(struct virtio_pci_cap, offset));
printk(KERN_INFO "lguest: Console via virtio-pci emerg_wr\n");
 }
 

Re: [PATCH V2 4/5] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Peter Senna Tschudin]

Hi Enric,
 
On Friday, June 10, 2016 09:39 CEST, Enric Balletbo Serra  
wrote: 
 
> Hi Peter,
> 
> Only a few comments ;)

Thanks a lot for the review!

> 
> 2016-06-09 18:25 GMT+02:00 Peter Senna Tschudin :
> > Add a driver that create a drm_bridge and a drm_connector for the LVDS
> > to DP++ display bridge of the GE B850v3.
> >
> > There are two physical bridges on the video signal pipeline: a
> > STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> > firmware made it complicated for this binding to comprise two device
> > tree nodes, as the design goal is to configure both bridges based on
> > the LVDS signal, which leave the driver powerless to control the video
> > processing pipeline. The two bridges behaves as a single bridge, and
> > the driver is only needed for telling the host about EDID / HPD, and
> > for giving the host powers to ack interrupts. The video signal pipeline
> > is as follows:
> >
> >   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> >
> > Cc: Enric Balletbo i Serra 
> > Cc: Philipp Zabel 
> > Cc: Rob Herring 
> > Cc: Fabio Estevam 
> > CC: David Airlie 
> > CC: Thierry Reding 
> > CC: Thierry Reding 
> > Signed-off-by: Peter Senna Tschudin 
> > ---
> > Changes from V1:
> >  - New commit message
> >  - Removed 3 empty entry points
> >  - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
> >  - Added a lock for mode setting
> >  - Removed a few blank lines
> >  - Changed the order at Makefile and Kconfig
> >
> >  MAINTAINERS|   8 +
> >  drivers/gpu/drm/bridge/Kconfig |  11 +
> >  drivers/gpu/drm/bridge/Makefile|   1 +
> >  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 392 
> > +
> >  4 files changed, 412 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2ce5e91..2dd3d7f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5010,6 +5010,14 @@ W:   https://linuxtv.org
> >  S: Maintained
> >  F: drivers/media/radio/radio-gemtek*
> >
> > +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> > +M: Martin Donnelly 
> > +M: Peter Senna Tschudin 
> > +M: Martyn Welch 
> > +S: Maintained
> > +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> > +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> > +
> >  GENERIC GPIO I2C DRIVER
> >  M: Haavard Skinnemoen 
> >  S: Supported
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 8f7423f..93dae5bd 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
> >   Designware HDMI block.  This is used in conjunction with
> >   the i.MX6 HDMI driver.
> >
> > +config DRM_GE_B850V3_LVDS_DP
> > +   tristate "GE B850v3 LVDS to DP++ display bridge"
> > +   depends on OF
> > +   select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > +   ---help---
> > +  This is a driver for the display bridge of
> > +  GE B850v3 that convert dual channel LVDS
> > +  to DP++. This is used with the i.MX6 imx-ldb
> > +  driver.
> > +
> >  config DRM_NXP_PTN3460
> > tristate "NXP PTN3460 DP/LVDS bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 96b13b3..47ea6c1 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
> >  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> >  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> >  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> > +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
> >  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> >  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> > b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> > new file mode 100644
> > index 000..c73cd77
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> > @@ -0,0 +1,392 @@
> > +/*
> > + * Driver for GE B850v3 DP display bridge
> > +
> > + * Copyright (c) 2016, Collabora Ltd.
> > + * Copyright (c) 2016, General Electric Company
> > +
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms and conditions of the GNU General Public License,
> > + * version 2, as published by the Free Software Foundation.
> > +
> > + * This program is distributed in the hope 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.
> > +
> > + * You should have received a copy of the GNU General Public License

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Thu, Jun 9, 2016 at 10:54 PM, Srinivas Pandruvada
 wrote:
> Hi,
> On Thu, 2016-06-09 at 22:45 +0100, Grant Likely wrote:
>> On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
>>  wrote:
>> >
>> > Starting from Cherrytrail, multiple generation of Intel processors
>> > offers
>> > on package sensor hub. Several recent tablets, 2-in-1 convertible
>> > laptops
>> > are using ISH instead of external sensor hubs. This resulted in
>> > lack of
>> > support of sensor function like device rotation and auto backlight
>> > adjustment. In addition, depending on the OEM implementation,
>> > support of ISH
>> > is required to support low power sleep states.
>> >
>> > The support of ISH on Linux platforms is not new. Android platforms
>> > with
>> > Intel SoCs had this support for a while submitted by Daniel Drubin.
>> > This patcheset is reusing most of those changes with  clean up and
>> > removing Android platform specific changes.
>> Hi Srinivas,
>>
>> Thanks for this patch series. I've got an HP Spectre x360 G2
>> (skylake), and I've built a 4.6.0 kernel with this driver patched in.
>> It detects the sensors hub, and creates IIO devices under
>> /sys/bus/iio/devices:
>>
>> $ ls /sys/bus/iio/devices/
>> iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
>> iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
>> trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
>> trigger7  trigger8  trigger9
>>
>> However, I haven't figured out how to test it yet. (This is the first
>> time I'm working with IIO). Do you have any test code or test
>> procedures to show if it is working?
>>
> If you use Fedora 23 (or any distro with iio-sensor-proxy with gnome
> rotation stuff), you should be able to do screen rotation and
> brightness using ALS.
> Each of these folders should have some raw sysfs files
> in_xxx_raw_xx
>
> You should be able to use "cat" on them.

Yes, I do see the in_*_raw_* files in sysfs, and I'm able to get data
out of them. Gnome also seems to recognize that the accelerometers are
there because it adds a rotation lock button to the system menu.

However, the events are getting through yet. It may be that I'm
missing something in my kernel config. I'm rebuilding the kernel with
Debian's config for the 4.5.5 kernel as a quick sanity test. I'll
report back when I've tried.

I'll also take some time and review the patch series later this afternoon.

g.

>
> Thanks,
> Srinivas
>
>
>> Thanks,
>> g.
>>
>> >
>> >
>> > This series is tested on:
>> > - Lenovo Yoga 260 with Skylake processor
>> > - HP Pavilion x2 detachable with Cherrytrail
>> >
>> > The user mode ABI is still same as external sensor hubs using Linux
>> > IIO. So existing user mode software should still work without
>> > change.
>> > This series primarily brings in new HID transport used in ISH.
>> >
>> > This series submitted as a RFC to try on several devices. We have
>> > received request from Linux users who wanted this support. So I
>> > hope all
>> > those users try and give feedback.
>> >
>> > Daniel Drubin (3):
>> >   hid: intel_ish-hid: ISH Transport layer
>> >   hid: intel-ish-hid: ipc layer
>> >   hid: intel-ish-hid: ISH HID client driver
>> >
>> > Srinivas Pandruvada (1):
>> >   Documentation: hid: Intel ISH HID document
>> >
>> >  Documentation/hid/intel-ish-hid.txt  |  375 +
>> >  drivers/hid/Kconfig  |2 +
>> >  drivers/hid/Makefile |2 +
>> >  drivers/hid/intel-ish-hid/Kconfig|   27 +
>> >  drivers/hid/intel-ish-hid/Makefile   |   20 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>> >  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710
>> > 
>> >  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>> >  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>> >  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672
>> > +++
>> >  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>> >  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>> >  drivers/hid/intel-ish-hid/ishtp/bus.c|  670
>> > +++
>> >  drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
>> >  drivers/hid/intel-ish-hid/ishtp/client.c | 1131
>> > ++
>> >  drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
>> >  drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
>> >  drivers/hid/intel-ish-hid/ishtp/hbm.c|  911
>> > +
>> >  drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
>> >  drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
>> >  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
>> >  include/trace/events/intel_ish.h |   30 +
>> >  23 files changed, 6661 insertions(+)
>> >  create mode 100644 Documentation/hid/intel-ish-hid.txt
>> >  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>