Re: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Mika Westerberg]

On Mon, Jun 20, 2016 at 12:38:58PM +0100, Adam Thomson wrote:
> For device nodes in both DT and ACPI, it possible to have named
> child nodes which contain properties (an existing example being
> gpio-leds). This adds a function to find a named child node for
> a device which can be used by drivers for property retrieval.
> 
> For DT data node name matching, of_node_cmp() and similar functions
> are made available outside of CONFIG_OF block so the new function
> can reference these for DT and non-DT builds.
> 
> For ACPI data node name matching, a helper function is also added
> which returns false if CONFIG_ACPI is not set, otherwise it
> performs a string comparison on the data node name. This avoids
> using the acpi_data_node struct for non CONFIG_ACPI builds,
> which would otherwise cause a build failure.
> 
> Signed-off-by: Adam Thomson 
> Tested-by: Sathyanarayana Nujella 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v3:
>  - Move of_*_cmp() functions in of.h outside of CONFIG_OF block so they are
>available for non-DT builds
>  - In device_get_named_child_node(), use of_node_cmp() helper macro instead of
>strcasecmp() (node names not alway case insensitive, depending on 
> platform).
> 
> Changes in v2:
>  - Rebase to v4.7-rc1
> 
>  drivers/base/property.c  | 28 
>  include/acpi/acpi_bus.h  |  7 +++
>  include/linux/acpi.h |  6 ++
>  include/linux/of.h   | 14 +++---
>  include/linux/property.h |  3 +++
>  5 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f38c21d..43a36d6 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -888,6 +888,34 @@ struct fwnode_handle *device_get_next_child_node(struct 
> device *dev,
>  EXPORT_SYMBOL_GPL(device_get_next_child_node);
> 
>  /**
> + * device_get_named_child_node - Return first matching named child node 
> handle
> + * @dev: Device to find the named child node for.
> + * @childname: String to match child node name against.
> + */
> +struct fwnode_handle *device_get_named_child_node(struct device *dev,
> +   const char *childname)
> +{
> + struct fwnode_handle *child;
> +
> + /*
> +  * Find first matching named child node of this device.
> +  * For ACPI this will be a data only sub-node.
> +  */
> + device_for_each_child_node(dev, child) {
> + if (is_of_node(child)) {
> + if (!of_node_cmp(to_of_node(child)->name, childname))
> + return child;
> + } else if (is_acpi_data_node(child)) {
> + if (acpi_data_node_match(child, childname))
> + return child;
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(device_get_named_child_node);
> +
> +/**
>   * fwnode_handle_put - Drop reference to a device node
>   * @fwnode: Pointer to the device node to drop the reference to.
>   *
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 788c6c3..993bdd0 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -420,6 +420,13 @@ static inline struct acpi_data_node 
> *to_acpi_data_node(struct fwnode_handle *fwn
>   container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return is_acpi_data_node(fwnode) ?
> + (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
> +}

Looks fine to me.

One question - is it expected that matching ACPI data nodes is always
case insensitive?

Re: [PATCH v2] HID: i2c-hid: set power sleep before shutdown

[Jiri Kosina]

On Tue, 21 Jun 2016, Guohua Zhong wrote:

> Add i2c_hid_shutdown for i2c-hid driver to send suspend cmd & free
> irq before device shutdown.
> 
> Some HW design (i.e. Umaro, a chromebook model) is that the power to
> i2c hid device won't down after device shutdown. Also the i2c-hid driver
> do not send suspend cmd to the hid i2c device and free its irq before
> shutdown.So if We touch the touchscreen or some other i2c hid device,
> the power consumtion will be go up even when the device is in shutdown
> state.
> 
> Though the root cause maybe a HW issue. But it seems that it is a
> good pratice to set power sleep for i2c-hid device before shutdown.

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

[PATCH] tracing: Fix oops caused by graph notrace filter

[Chunyu Hu]

wakeup tracer can use function_graph trace when display_graph trace
option is setup by user via tracefs, and bypass the set_graph_function
and set_graph_notrace. But the bypass of set_graph_notrace is not clean.
Although wakeup_graph_entry does most of the bypass, and both the enry
and exit event will be submitted to the trace ring buffer, the ret_stack
index, which will be assigned to depth field of graph enrty event is not
handled. The issue is that the depth is used as the array index of
fgraph_cpu_data and can cause an oops when it's negative. irqsoff tracer
has same issue. To see the oops:

echo 1 > options/display_graph
echo schedule > set_graph_notrace
echo wakeup > current_tracer
cat trace
cat trace

Making ftrace_graph_notrace_addr always return false when tracers need
to bypass it is a proposed fix.

Signed-off-by: Chunyu Hu 
---
 kernel/trace/ftrace.c| 1 +
 kernel/trace/trace.h | 4 
 kernel/trace/trace_functions_graph.c | 2 ++
 kernel/trace/trace_irqsoff.c | 7 +++
 kernel/trace/trace_sched_wakeup.c| 8 
 5 files changed, 22 insertions(+)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a680482..bb06828 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4471,6 +4471,7 @@ static DEFINE_MUTEX(graph_lock);
 
 int ftrace_graph_count;
 int ftrace_graph_notrace_count;
+int ftrace_graph_ignore_notrace;
 unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
 unsigned long ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 5167c36..b089e04 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -757,6 +757,7 @@ extern void __trace_graph_return(struct trace_array *tr,
 extern int ftrace_graph_count;
 extern unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS];
 extern int ftrace_graph_notrace_count;
+extern int ftrace_graph_ignore_notrace;
 extern unsigned long ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS];
 
 static inline int ftrace_graph_addr(unsigned long addr)
@@ -791,6 +792,9 @@ static inline int ftrace_graph_notrace_addr(unsigned long 
addr)
if (!ftrace_graph_notrace_count)
return 0;
 
+   if (unlikely(ftrace_graph_ignore_notrace))
+   return 0;
+
for (i = 0; i < ftrace_graph_notrace_count; i++) {
if (addr == ftrace_graph_notrace_funcs[i])
return 1;
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index 3a0244f..24d92f0 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -822,6 +822,8 @@ print_graph_entry_nested(struct trace_iterator *iter,
cpu_data = per_cpu_ptr(data->cpu_data, cpu);
cpu_data->depth = call->depth;
 
+   WARN(call->depth < 0, "call->depth = %d\n", call->depth);
+
/* Save this function pointer to see if the exit matches */
if (call->depth < FTRACE_RETFUNC_DEPTH)
cpu_data->enter_funcs[call->depth] = call->func;
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 03cdff8..3d76e0f 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -32,6 +32,8 @@ static int trace_type __read_mostly;
 
 static int save_flags;
 
+extern int ftrace_graph_ignore_notrace;
+
 static void stop_irqsoff_tracer(struct trace_array *tr, int graph);
 static int start_irqsoff_tracer(struct trace_array *tr, int graph);
 
@@ -629,6 +631,9 @@ static int __irqsoff_tracer_init(struct trace_array *tr)
 
ftrace_init_array_ops(tr, irqsoff_tracer_call);
 
+   /* bypass function_graph notrace filter */
+   ftrace_graph_ignore_notrace = 1;
+
/* Only toplevel instance supports graph tracing */
if (start_irqsoff_tracer(tr, (tr->flags & TRACE_ARRAY_FL_GLOBAL &&
  is_graph(tr
@@ -650,6 +655,8 @@ static void irqsoff_tracer_reset(struct trace_array *tr)
ftrace_reset_array_ops(tr);
 
irqsoff_busy = false;
+
+   ftrace_graph_ignore_notrace = 0;
 }
 
 static void irqsoff_tracer_start(struct trace_array *tr)
diff --git a/kernel/trace/trace_sched_wakeup.c 
b/kernel/trace/trace_sched_wakeup.c
index 9d4399b..81dd566 100644
--- a/kernel/trace/trace_sched_wakeup.c
+++ b/kernel/trace/trace_sched_wakeup.c
@@ -37,6 +37,8 @@ static void __wakeup_reset(struct trace_array *tr);
 
 static int save_flags;
 
+extern int ftrace_graph_ignore_notrace;
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 static int wakeup_display_graph(struct trace_array *tr, int set);
 # define is_graph(tr) ((tr)->trace_flags & TRACE_ITER_DISPLAY_GRAPH)
@@ -672,6 +674,10 @@ static int __wakeup_tracer_init(struct trace_array *tr)
tr->max_latency = 0;
wakeup_trace = tr;
ftrace_init_array_ops(tr, wakeup_tracer_call);
+
+   /* bypass function_gr

Re: [PATCH 05/27] [AARCH64] Use PTR_REG in crti.S.

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> +#ifdef __LP64__
> +#define RTLD_START RTLD_START_1("x", "3", "sp")
> +#else
> +#define RTLD_START RTLD_START_1("w", "2", "wsp")
> +#endif

As well as preprocessor indentation, this is missing spaces after '('; 
check for and fix that issue throughout this patch series.  (There are 
only a few cases where a macro is used to construct a type / variable 
name, such as ElfW, where missing the space is more usual.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 26/27] [AARCH64] Change type of __align to long long

[Zhangjian (Bamvor)]

Hi, Yury

On 2016/6/21 13:07, Yury Norov wrote:

From: Andrew Pinski 

So that ILP32 is aligned to 64bits.

Signed-off-by: Yury Norov 
---
  sysdeps/aarch64/nptl/bits/semaphore.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sysdeps/aarch64/nptl/bits/semaphore.h 
b/sysdeps/aarch64/nptl/bits/semaphore.h
index 3cc5b37..3fe6047 100644
--- a/sysdeps/aarch64/nptl/bits/semaphore.h
+++ b/sysdeps/aarch64/nptl/bits/semaphore.h
@@ -31,5 +31,5 @@
  typedef union
  {
char __size[__SIZEOF_SEM_T];
-  long int __align;
+  long long int __align;

Why we need align to 64bit?

Regard

Bamvor

  } sem_t;

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

[Felipe Balbi]

Hi,

Tony Lindgren  writes:
> * Felipe Balbi  [160621 03:06]:
>> 8<--
>>  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>> set_role(id);
>> set_vbus(vbus);
>
> We should use regulator framework API for set_vbus() because of
> the delays involved bringing it up. And we already have separate
> PHY and charger chips where VBUS is provided by the charger chip.

yeah, no arguments there.

-- 
balbi


signature.asc
Description: PGP signature

Re: Using DT overlays for adding virtual hardware

[Pantelis Antoniou]

Hi Jan,

> On Jun 21, 2016, at 13:13 , Jan Kiszka  wrote:
> 
> Hi Pantelis,
> 
> coming back to this topic:
> 
> On 2016-06-09 08:03, Jan Kiszka wrote:
>> OK, trial and error, and some interesting insights: I've played with DT
>> fragments and the overlay configfs patch of Pantelis [1] to have a
>> convenient start. Interestingly, I wasn't able to load a fragment that
>> followed the format specification for overlays ("Failed to resolve
>> tree"). By chance, I got this one working:
>> 
>> /dts-v1/;
>> / {
>>  fragment {
>>  target-path = "/soc@01c0";
>>  __overlay__ {
>>  #address-cells = <2>;
>>  #size-cells = <2>;
>> 
>>  vpci@0x200 {
>>  compatible = "pci-host-cam-generic";
>>  device_type = "pci";
>>  #address-cells = <3>;
>>  #size-cells = <2>;
>>  reg = <0 0x200 0 0x100>;
>>  ranges =
>>  <0x0200 0x00 0x1000 0x00 
>> 0x1000 0x00 0x3000>;
>>  };
>>  };
>>  };
>> };
>> 
>> It successfully makes a BananaPi kernel add a pci host with the
>> specified config space and MMIO window.
>> 
>> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
>> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, using 
>> [bus 00-ff]
>> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
>> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
>> 0x0200-0x02ff] for [bus 00-ff]
>> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus :00
>> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
>> [   81.620814] pci_bus :00: root bus resource [mem 0x1000-0x3fff]
>> [   81.620851] PCI: bus0: Fast back to back transfers enabled
>> 
>> So, no /plugin/ statement, no phandles resolution. This format even
>> builds with the in-kernel dtc. Any explanations? Does the code make
>> sense (at least it builds without warnings)?
>> 
>> Now I need to back this with some code in Jailhouse.
> 
> Meanwhile I got a virtual PCI device recognized by Linux when running
> over Jailhouse. However, my hack above doesn't get me to proper
> interrupt mapping yet. This is what I was trying with upstream dtc:
> 
> /dts-v1/;
> / {
>   compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
> 
>   fragment@0 {
>   target-path = "/soc@01c0";
>   __overlay__ {
>   #address-cells = <2>;
>   #size-cells = <2>;
> 
>   vpci@200 {
>   compatible = "pci-host-ecam-generic";
>   device_type = "pci";
>   bus-range = <0 0>;
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
>   interrupt-map-mask = <0 0 0 7>;
>   interrupt-map = <0 0 0 1 &gic 0 0 0 123 4>,
>   <0 0 0 2 &gic 0 0 0 124 4>,
>   <0 0 0 3 &gic 0 0 0 125 4>,
>   <0 0 0 4 &gic 0 0 0 126 4>;
>   reg = <0 0x200 0 0x10>;
>   ranges =
>   <0x0200 0x00 0x1000 0x00 
> 0x1000 0x00 0x3000>;
>   };
>   };
>   };
> 
>   gic: fragment@1 {
>   target-path = "/soc@01c0/interrupt-controller@01c81000";
>   __overlay__ {
>   };
>   };
> };
> 

^ This is not going to work: You need the reference to the real gic not the 
empty fragment
here that has a target there.

You need to compile with the correct dtc, and you also need to compile the base 
dts
with dtc too, using the -@ flag. You can hack around it by adding something like

__symbols__ {
gic = "/soc@01c0/interrupt-controller@01c81000”;
};

But you really need the __symbols__ node of the base dts generated by the dtc 
proper cause
the above is a dirty hack.


> And this is what Linux detects on that PCI bus:
> 
> 00:0f.0 RAM memory: Red Hat, Inc Inter-VM shared memory
>Subsystem: Red Hat, Inc Inter-VM shared memory
>Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR- Interrupt: pin A routed to IRQ 17
>Region 0: Memory at 1000 (64-bit, non-prefetchable) [size=256]
>Region 4: Memory at 1100 (64-bit, non-prefetchable) [size=32]
>Kernel modules: ivshmem_net
> 
> H

pull-request: wireless-drivers-next 2016-06-21

[Kalle Valo]

Hi Dave,

I hope it's ok to send two pull requests the same day, both for net and
net-next? This is targeted to 4.8 so it is for net-next.

Even though is this the first pull request for 4.8 we actually remove
more code than add, thanks to Guenter Roeck's on removing unused "phy_a"
support from b43. Otherwise there's not really anything standing out,
adding new chipset support to brcmfmac and ath10k, lots of fixes and the
usual.

Please let me know if there any issues.

Kalle

The following changes since commit 76f21b99004ef1f16be6184678f660eab911b8b8:

  net: Add docbook description for 'mtu' arg to skb_gso_validate_mtu() 
(2016-06-03 22:56:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2016-06-21

for you to fetch changes up to 1bb57c8a5e33bcbec031ce0c629968922d5af89d:

  Merge ath-next from ath.git (2016-06-19 11:19:30 +0300)



wireless-drivers patches for 4.8

Major changes:

ath10k

* enable btcoex support without restarting firmware
* enable ipq4019 support using AHB bus
* add QCA9887 chipset support
* retrieve calibration data from EEPROM, currently only for QCA9887

wil6210

* add pm_notify handling

brcmfmac

* add support for the PCIE devices 43525 and 43465


Adrian Chadd (1):
  b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM.

Amitkumar Karwar (1):
  mwifiex: inform disconnection initiator correctly.

Arend van Spriel (1):
  brcm80211: update maintainers email addresses

Arnd Bergmann (4):
  iwlegacy: avoid warning about missing braces
  wl3501_cs: avoid bogus gcc-6 warning
  rtlwifi: fix error handling in *_read_adapter_info()
  mwifiex: fix link error against sdio

Ashok Raj Nagarajan (1):
  ath10k: fix diag_read to collect data for larger memory

Bhaktipriya Shridhar (1):
  libertas: Remove create_workqueue

Bob Copeland (1):
  ath5k: fix misplaced default label in sifs switch

Christian Daudt (2):
  brcmfmac: Fix kernel oops in failed chip_attach
  brcmfmac: Fix 'did not remove int handler' warning

Eduardo Abinader (3):
  ath9k: Remove empty test condition
  ath9k: allow tx99 for ar9002 based cards
  ath9k: Proper TX99 interrupt ref count

Guenter Roeck (3):
  libertas_tf: Drop unused variable and define
  b43: Remove unused phy_a code
  b43: Completely remove support for phy_a

Hante Meuleman (2):
  brcmfmac: fix skb priority handling
  brcmfmac: add support for the PCIE devices 43525 and 43465

Heinrich Schuchardt (7):
  ath6kl: simplify logical condition
  rsi: eliminate superfluous NULL check
  mwifiex: illegal assignment
  rtlwifi: rtl8723be: avoid undefined behavior
  mwiflex: avoid possible null pointer dereference
  rtlwifi: rtl8192ee: simplify coding
  brcm80211: simplify assignment

Javier Martinez Canillas (8):
  mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
  mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()
  mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()
  mwifiex: consolidate mwifiex_sdio_probe() error paths
  mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
  mwifiex: check if mwifiex_sdio_probe_of() fails and return error
  mwifiex: don't print an error if an optional DT property is missing
  mwifiex: use better message and error code when OF node doesn't match

Julia Lawall (2):
  ath6kl: fix typo
  mwifiex: fix typo

Kalle Valo (1):
  Merge ath-next from ath.git

Lauri Kasanen (1):
  carl9170: Clarify kconfig text

Lior David (1):
  wil6210: abort P2P search when stopping P2P device

Lucas Stach (1):
  b43: only hardcode LED behavior if SPROM doesn't encode any

Mathias Krause (1):
  mwifiex: remove misleading GFP_DMA flag in buffer allocations

Maya Erez (7):
  wil6210: fix race conditions between TX send and completion
  wil6210: guarantee safe access to rx descriptors shared memory
  wil6210: protect wil_vring_fini_tx in parallel to tx completions
  wil6210: fix dma mapping error cleanup in __wil_tx_vring_tso
  wil6210: add pm_notify handling
  wil6210: align wil log functions to wil_dbg_ratelimited implementation
  wil6210: fix chan check in wil_p2p_listen

Michal Kazior (1):
  ath10k: improve tx scheduling

Mohammed Shafi Shajakhan (5):
  ath10k: reduce warning messages during rx without proper channel context
  ath10k: fix legacy rate packet debug messages
  ath10k: fix error while writing 'simulate_fw_crash' debugfs
  ath10k: remove duplicate and unused rx rate flags
  ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

Muhammad Falak R Wani (1):
  brcmfmac: use kmemdup

Rafał Miłecki (8

Re: [PATCH v2 2/3] iio: Add driver for Broadcom iproc-static-adc

[Raveendra Padasalagi]

Hi Jonathan,

Thanks for the review comments. I will address these in the next patch.
Please find my reply inline.

Regards,
Raveendra

On Mon, Jun 20, 2016 at 1:05 AM, Jonathan Cameron  wrote:
> On 19/06/16 11:06, Raveendra Padasalagi wrote:
>> This patch adds basic driver implementation for Broadcom's
>> static adc controller used in iProc SoC's family.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
> Hi All,
>
> The inconvenience of lunch and an afternoon of gardening occured in the
> middle of this review, so much of what I have may well have been covered
> by Peter!
>
> Anyhow, various bits inline.  In particular, there is very little handling
> of potential regmap functions returning errors in here.  I know they are
> pretty unlikely, but I think it would be nice to handle them anyway.
>
> Interesting bit of kit so I hope you have the oportunity to look at fuller
> support of those fifos. Any public info on the part in question?

Currently details of ADC controller is not publicly available. Yes, I
have plan for
improving this driver to make use of fifo's in the next step, This ADC has
a continuous capture mode feature.

> Thanks
>
> Jonathan
>> ---
>>  drivers/iio/adc/Kconfig |  13 +
>>  drivers/iio/adc/Makefile|   1 +
>>  drivers/iio/adc/bcm_iproc_adc.c | 563 
>> 
>>  3 files changed, 577 insertions(+)
>>  create mode 100644 drivers/iio/adc/bcm_iproc_adc.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 25378c5..195dcd4 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -153,6 +153,19 @@ config AXP288_ADC
>> To compile this driver as a module, choose M here: the module will be
>> called axp288_adc.
>>
>> +config BCM_IPROC_ADC
>> + tristate "Broadcom IPROC ADC driver"
>> + depends on ARCH_BCM_IPROC || COMPILE_TEST
>> + depends on MFD_SYSCON
>> + default ARCH_BCM_CYGNUS
>> + help
>> +   Say Y here if you want to add support for the Broadcom static
>> +   ADC driver.
>> +
>> +   Broadcom iProc ADC driver. Broadcom iProc ADC controller has 8
>> +   channels. The driver allows the user to read voltage and
>> +   temperature values.
>> +
>>  config BERLIN2_ADC
>>   tristate "Marvell Berlin2 ADC driver"
>>   depends on ARCH_BERLIN
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 38638d4..0ba0d50 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -16,6 +16,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
>>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>>  obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
>>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>> +obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
>>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>> diff --git a/drivers/iio/adc/bcm_iproc_adc.c 
>> b/drivers/iio/adc/bcm_iproc_adc.c
>> new file mode 100644
>> index 000..6bfc160
>> --- /dev/null
>> +++ b/drivers/iio/adc/bcm_iproc_adc.c
>> @@ -0,0 +1,563 @@
>> +/*
>> + * Copyright 2016 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License, version 2, as
>> + * published by the Free Software Foundation (the "GPL").
>> + *
>> + * 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 version 2 (GPLv2) for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * version 2 (GPLv2) along with this source code.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> Why?  Not immediately seeing any use of iio_maps in here...

Yes, we don't need iio_maps.will remove it in the next patch.

>> +#include 
> snap.
>> +
>> +#define IPROC_ADC_READ_TIMEOUT(HZ*2)
>> +
>> +/* Register offsets */
>> +#define REGCTL1  0x00
>> +#define REGCTL2  0x04
>> +#define INTERRUPT_THRES  0x08
>> +#define INTRPT_MASK  0x0c
>> +#define INTRPT_STATUS0x10
>> +#define ANALOG_CONTROL   0x1c
>> +#define CONTROLLER_STATUS0x14
>> +#define AUX_DATA 0x20
>> +#define SOFT_BYPASS_CONTROL  0x38
>> +#define SOFT_BYPASS_DATA 0x3C
>> +
>> +/* ADC Channel register offsets */
>> +#define ADC_CHANNEL_REGCTL1  0x800
>> +#define ADC_CHANNEL_REGCTL2  0x804
>> +#define ADC_CHANNEL_STATUS   0x808
>> +#define ADC_CHANNEL_INTERRUPT_STATUS 0x80c
>> +#define 

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

[Wei Hu (Xavier)]

On 2016/6/20 21:33, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:

This patch added the operation for cmd, and added some functions
for initializing eq table and selecting cmd mode.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---
PATCH v9/v8/v7/v6:
- No change over the PATCH v5

PATCH v5:
- The initial patch which was redesigned based on the second patch
   in PATCH v4
---

<...>


+#define CMD_MAX_NUM32
+
+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
+{
+   struct device *dev = &hr_dev->pdev->dev;
+
+   mutex_init(&hr_dev->cmd.hcr_mutex);
+   sema_init(&hr_dev->cmd.poll_sem, 1);
+   hr_dev->cmd.use_events = 0;
+   hr_dev->cmd.toggle = 1;
+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;

<...>


+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
+hr_cmd->token_mask <<= 1)
+   ;
+   --hr_cmd->token_mask;

It doesn't look that you dynamically change max_cmds supported.
Why do you need to calculate token_mask dynamically?

Hi, Leon

1. The four lines above are in the function named 
hns_roce_cmd_use_events.

 and now this function is only called once in hns_roce_probe.
2. In hns_roce_cmd_use_events,
we use these 4 lines to achieve the value of hr_cmd->token_mask 
according to hr_cmd->max_cmds dynamically,

then we only define one marco for hr_cmd->max_cmds as below:

#define CMD_MAX_NUM 32

   And it looks more flexible.

Regards
Wei Hu

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

[Tony Lindgren]

* Felipe Balbi  [160621 03:06]:
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
> 
> set_role(id);
> set_vbus(vbus);

We should use regulator framework API for set_vbus() because of
the delays involved bringing it up. And we already have separate
PHY and charger chips where VBUS is provided by the charger chip.

Regards,

Tony

Re: [Query] mwifiex: few observations to reduce number of endian conversions

[Prasun Maiti]

Hi Amitkumar,


On Tue, Jun 21, 2016 at 3:47 PM, Amitkumar Karwar  wrote:

> I agree with your observations. We'll prepare a cleanup patch to address this.
>
> Regards,
> Amitkumar

I have already made some changes. I will send you a patch for this.

-- 
Thanks,
Prasun

Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

[kbuild test robot]

Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
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=sparc64 

All errors (new ones prefixed by >>):

   net/mac802154/llsec.c: In function 'llsec_dev_find_long':
>> net/mac802154/llsec.c:333:15: error: 'struct ieee802154_llsec_device' has no 
>> member named 'hwaddr'
  if (dev->dev.hwaddr == hwaddr)
  ^
   net/mac802154/llsec.c: In function 'llsec_lookup_dev':
   net/mac802154/llsec.c:799:16: error: 'struct ieee802154_llsec_device' has no 
member named 'hwaddr'
   if (dev->dev.hwaddr == devaddr.extended_addr)
   ^
   net/mac802154/llsec.c: In function 'mac802154_llsec_decrypt':
   net/mac802154/llsec.c:1037:21: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'
 dev_addr = dev->dev.hwaddr;
^

vim +333 net/mac802154/llsec.c

5d637d5a Phoebe Buckheister 2014-05-16  327  llsec_dev_find_long(struct 
mac802154_llsec *sec, __le64 hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  328  {
5d637d5a Phoebe Buckheister 2014-05-16  329 struct mac802154_llsec_device 
*dev;
5d637d5a Phoebe Buckheister 2014-05-16  330 u64 key = 
llsec_dev_hash_long(hwaddr);
5d637d5a Phoebe Buckheister 2014-05-16  331  
5d637d5a Phoebe Buckheister 2014-05-16  332 
hash_for_each_possible_rcu(sec->devices_hw, dev, bucket_hw, key) {
5d637d5a Phoebe Buckheister 2014-05-16 @333 if (dev->dev.hwaddr == 
hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  334 return dev;
5d637d5a Phoebe Buckheister 2014-05-16  335 }
5d637d5a Phoebe Buckheister 2014-05-16  336  

:: The code at line 333 was first introduced by commit
:: 5d637d5aabd85132bd85779677d8acb708e0ed90 mac802154: add llsec structures 
and mutators

:: TO: Phoebe Buckheister 
:: CC: David S. Miller 

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


.config.gz
Description: Binary data

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/llseek.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/lseek.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/mmap.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/readahead.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate64.c

I don't like how you need so many ilp32 files.

Presumably this is a new convention to be followed for all future ilp32 
ABIs on 64-bit architectures.  Meaning that you should have some sysdeps 
macros to say whether this convention is in use and then make either the 
sysdeps/unix/sysv/linux files, or the .../generic files, or a new 
architecture-independent sysdeps directory, implement that convention.

Note also how Adhemerval recently unified pread / pwrite implementations.  
Adding new files for those functions goes against that unification.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

[Andy Shevchenko]

On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
> From: Daode Huang 
> 
> For SoC hip06, PFC pause handled in dsaf, while hip05 in XGMAC,
> so change the statistics of pfc pause in dsaf and remove the old
> pfc pause frame statistics.
> 


> +static char *hns_dsaf_get_node_stats_strings(char *data, int node,
> +  struct dsaf_device
> *dsaf_dev)
>  {
>   char *buff = data;
> + int i;
> + bool is_ver1 = AE_IS_VER1(dsaf_dev->dsaf_ver);
>  
>   snprintf(buff, ETH_GSTRING_LEN, "innod%d_pad_drop_pkts",
> node);
>   buff = buff + ETH_GSTRING_LEN;
> @@ -2502,6 +2530,18 @@ static char
> *hns_dsaf_get_node_stats_strings(char *data, int node)
>   buff = buff + ETH_GSTRING_LEN;
>   snprintf(buff, ETH_GSTRING_LEN, "innod%d_stp_drop_pkts",
> node);
>   buff = buff + ETH_GSTRING_LEN;
> + if ((node < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {

Redundant parens.

> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + snprintf(buff, ETH_GSTRING_LEN,
> +  "inod%d_pfc_prio%d_pkts", node, i);
> + buff = buff + ETH_GSTRING_LEN;

buff += ...

> + }
> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + snprintf(buff, ETH_GSTRING_LEN,
> +  "onod%d_pfc_prio%d_pkts", node, i);
> + buff = buff + ETH_GSTRING_LEN;

Ditto.

>  {
>   u64 *p = data;
> + int i;
>   struct dsaf_hw_stats *hw_stats = &ddev->hw_stats[node_num];
> + bool is_ver1 = AE_IS_VER1(ddev->dsaf_ver);
>  
>   p[0] = hw_stats->pad_drop;
>   p[1] = hw_stats->man_pkts;
> @@ -2527,8 +2569,16 @@ static u64 *hns_dsaf_get_node_stats(struct
> dsaf_device *ddev, u64 *data,
>   p[10] = hw_stats->local_addr_false;
>   p[11] = hw_stats->vlan_drop;
>   p[12] = hw_stats->stp_drop;
> - p[13] = hw_stats->tx_pkts;
> + if ((node_num < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {
> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + p[13 + i] = hw_stats->rx_pfc[i];
> + p[13 + i + DSAF_PRIO_NR] = hw_stats-
> >tx_pfc[i];
> + }

Two different approaches how to assign data. Above uses 2 for-loops,
here you put everything to one.

> + p[29] = hw_stats->tx_pkts;
> + return &p[30];
> + }
>  
> + p[13] = hw_stats->tx_pkts;
>   return &p[14];
>  }

-- 

Andy Shevchenko 
Intel Finland Oy

pull-request: wireless-drivers 2016-06-21

[Kalle Valo]

Hi Dave,

here is a pull request for 4.7, really small fixes this time, some of
them fix important regressions. Please let me know if there are any
problems.

Kalle

The following changes since commit 182fd9eecb287e696c82b30d06c6150d80a49c5b:

  MAINTAINERS: Add file patterns for wireless device tree bindings (2016-06-04 
17:24:02 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2016-06-21

for you to fetch changes up to 034fdd4a17ff089c2428ece18efa65c5396810d2:

  Merge ath-current from ath.git (2016-06-16 17:55:19 +0300)



wireless-drivers fixes for 4.7

iwlwifi

* fix the scan timeout for long scans
* fix an RCU splat caused when updating the TKIP key
* fix a potential NULL-derefence introduced recently
* fix a IGTK key bug that has existed since the MVM driver was introduced
* fix some fw capabilities checks that got accidentally inverted

rtl8xxxu

* fix typo on variable name

ath10k

* fix deadlock when peer cannot be created
* fix crash related to printing features
* fix deadlock while processing rx_in_ord_ind

ath9k

* fix GPIO mask regression for AR9462 and AR9565


Ayala Beker (1):
  iwlwifi: mvm: set the encryption type of an IGTK key

Ben Greear (2):
  ath10k: fix deadlock when peer cannot be created
  ath10k: fix crash related to printing features

Colin Ian King (1):
  rtl8xxxu: fix typo on variable name, compare against correct variable

Emmanuel Grumbach (1):
  iwlwifi: mvm: fix RCU splat in TKIP's update_key

Johannes Berg (1):
  iwlwifi: mvm: fix a few firmware capability checks

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2016-06-10' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-current from ath.git

Luca Coelho (2):
  iwlwifi: mvm: increase scan timeout to 20 seconds
  iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder()

Miaoqing Pan (1):
  ath9k: fix GPIO mask for AR9462 and AR9565

Rajkumar Manoharan (1):
  ath10k: fix deadlock while processing rx_in_ord_ind

 drivers/net/wireless/ath/ath10k/core.c |2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c   |1 -
 drivers/net/wireless/ath/ath10k/mac.c  |2 +-
 drivers/net/wireless/ath/ath9k/reg.h   |8 
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |8 
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |   16 +++-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c |2 +-
 9 files changed, 30 insertions(+), 15 deletions(-)

Re: [LKP] [lkp] [x86 tsc] 19fa5e7364: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x72/0x80

[Wanpeng Li]

2016-06-21 18:10 GMT+08:00 Paolo Bonzini :
>
>
> On 21/06/2016 08:08, Wanpeng Li wrote:
>> Cc KVM ML, Paolo, Radim,
 FYI, raw QEMU command line is:

 qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
 /pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
  -append 'root=/dev/ram0 user=lkp 
 job=/lkp/scheduled/vm-kbuild-yocto-x86_64-32/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-w0-06180628-19fa5e73647fde1e6a7038a8f05cddf4c43f08d3-20160618-25535-h82bax-0.yaml~
  ARCH=x86_64 kconfig=x86_64-randconfig-w0-06180628 
 branch=internal-eywa/master 
 commit=19fa5e73647fde1e6a7038a8f05cddf4c43f08d3 
 BOOT_IMAGE=/pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
  max_uptime=600 
 RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/0
  LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug 
 apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 
 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
 ip=vm-kbuild-yocto-x86_64-32::dhcp drbd.minor_count=8'  -initrd 
 /fs/sdh1/initrd-vm-kbuild-yocto-x86_64-32 -m 320 -smp 1 -device 
 e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
 i6300esb -rtc base=localtime -drive 
 file=/fs/sdh1/disk0-vm-kbuild-yocto-x86_64-32,media=disk,if=virtio 
 -pidfile /dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-32 -serial 
 file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-32 -daemonize -display 
 none -monitor null

>>> This  problem was caused due to kvm does not support 
>>> MSR_PLATFORM_INFO(0xce),
>>> according to Wanpeng's feedback.
>>>
>>> Hi Wanpeng, is it possible for kvm to simulate this MSR, otherwise we
>>> might have to use
>>> rdmsr_safe instead.
>>
>> There is a thread discussed this before
>> https://patchwork.kernel.org/patch/8833021/, MSR_PLATFORM_INFO can't
>> be simple emulation.
>>
>> Ping Paolo, Radim. :)
>
> rdmsr_safe must be used instead.  I'll prepare a patch.

Actually I have such a patch on hand under testing, I will send out soon. :)

Regards,
Wanpeng Li

Re: [PATCH v1 19/25] PCI: rcar Gen2: Request host bridge window resources

[Geert Uytterhoeven]

Hi Bjorn,

On Tue, Jun 7, 2016 at 1:07 AM, Bjorn Helgaas  wrote:
> Request host bridge window resources so they appear in ioport_resource and
> iomem_resource and are reflected in /proc/ioports and /proc/iomem.
>
> Signed-off-by: Bjorn Helgaas 
> ---
>  drivers/pci/host/pci-rcar-gen2.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/host/pci-rcar-gen2.c 
> b/drivers/pci/host/pci-rcar-gen2.c
> index 9980a4b..617a6b2 100644
> --- a/drivers/pci/host/pci-rcar-gen2.c
> +++ b/drivers/pci/host/pci-rcar-gen2.c
> @@ -194,6 +194,7 @@ static int rcar_pci_setup(int nr, struct pci_sys_data 
> *sys)
> struct rcar_pci_priv *priv = sys->private_data;
> void __iomem *reg = priv->reg;
> u32 val;
> +   int ret;
>
> pm_runtime_enable(priv->dev);
> pm_runtime_get_sync(priv->dev);
> @@ -275,6 +276,9 @@ static int rcar_pci_setup(int nr, struct pci_sys_data 
> *sys)
> /* Add PCI resources */
> pci_add_resource(&sys->resources, &priv->io_res);
> pci_add_resource(&sys->resources, &priv->mem_res);
> +   ret = devm_request_pci_bus_resources(priv->dev, &sys->resources);
> +   if (ret < 0)
> +   return ret;
>
> /* Setup bus number based on platform device id / of bus-range */
> sys->busnr = priv->busnr;

This patch (commit 1bd019707b7c9249d34c5d348f1ef75eb4d83e89 in pci/next)
broke PCI on r8a7791/koelsch. Dmesg differences are:

 pci-rcar-gen2 ee09.pci: PCI: bus0 revision 11
-pci-rcar-gen2 ee09.pci: PCI host bridge to bus :00
-pci_bus :00: root bus resource [io  0xee08-0xee0810ff]
-pci_bus :00: root bus resource [mem 0xee08-0xee0810ff]
-pci_bus :00: No busn resource found for root bus, will use [bus 00-ff]
-pci :00:00.0: [1033:] type 00 class 0x06
-pci :00:00.0: reg 0x10: [mem 0xee090800-0xee090bff]
-pci :00:00.0: reg 0x14: [mem 0x4000-0x7fff pref]
-pci :00:01.0: [1033:0035] type 00 class 0x0c0310
-pci :00:01.0: reg 0x10: [mem 0x-0x0fff]
-pci :00:01.0: supports D1 D2
-pci :00:01.0: PME# supported from D0 D1 D2 D3hot
-pci :00:02.0: [1033:00e0] type 00 class 0x0c0320
-pci :00:02.0: reg 0x10: [mem 0x-0x00ff]
-pci :00:02.0: supports D1 D2
-pci :00:02.0: PME# supported from D0 D1 D2 D3hot
-PCI: bus0: Fast back to back transfers disabled
-pci_bus :00: busn_res: [bus 00-ff] end is updated to 00
-pci :00:01.0: BAR 0: assigned [mem 0xee08-0xee080fff]
-pci :00:02.0: BAR 0: assigned [mem 0xee081000-0xee0810ff]
+pci-rcar-gen2 ee09.pci: resource collision: [io
0xee08-0xee0810ff] conflicts with PCI IO [io  0x-0xf]

and:

 pci-rcar-gen2 ee0d.pci: PCI: bus0 revision 11
-pci-rcar-gen2 ee0d.pci: PCI host bridge to bus 0001:01
-pci_bus 0001:01: root bus resource [io  0xee0c-0xee0c10ff]
-pci_bus 0001:01: root bus resource [mem 0xee0c-0xee0c10ff]
-pci_bus 0001:01: No busn resource found for root bus, will use [bus 01-ff]
-pci 0001:01:00.0: [1033:] type 00 class 0x06
-pci 0001:01:00.0: reg 0x10: [mem 0xee0d0800-0xee0d0bff]
-pci 0001:01:00.0: reg 0x14: [mem 0x4000-0x7fff pref]
-pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310
-pci 0001:01:01.0: reg 0x10: [mem 0x-0x0fff]
-pci 0001:01:01.0: supports D1 D2
-pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
-pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320
-pci 0001:01:02.0: reg 0x10: [mem 0x-0x00ff]
-pci 0001:01:02.0: supports D1 D2
-pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
-PCI: bus1: Fast back to back transfers disabled
-pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
-pci 0001:01:01.0: BAR 0: assigned [mem 0xee0c-0xee0c0fff]
-pci 0001:01:02.0: BAR 0: assigned [mem 0xee0c1000-0xee0c10ff]
+pci-rcar-gen2 ee0d.pci: resource collision: [io
0xee0c-0xee0c10ff] conflicts with PCI IO [io  0x-0xf]

# cat /proc/iomem
3000-37ff : /pcie@fe00
3800-3fff : /pcie@fe00
4000-6fff : System RAM
  40008000-40a1c15b : Kernel code
  40e0-40e9ea97 : Kernel data
e606-e606024f : /pfc@e606
e60b-e60b0424 : /i2c@e60b
e615-e6150fff : /clock-controller@e615
e61f-e61f0013 : /thermal@e61f
e61f0100-e61f0137 : /thermal@e61f
e653-e653003f : /i2c@e653
e659-e65900ff : /usb@e659
e6590100-e65901ff : /usb-phy@e6590100
e65a-e65a00ff : /dma-controller@e65a
e65b-e65b00ff : /dma-controller@e65b
e670-e671 : /dma-controller@e670
e672-e673 : /dma-controller@e672
e6b1-e6b1002b : /spi@e6b1
e6e2-e6e20063 : /spi@e6e2
e6e6-e6e6003f : e6e6.serial
e6e68000-e6e6803f : e6e68000.serial
e6ef1000-e6ef1fff : /video@e6ef1000
ec50-ec500fff : scu
ec54-ec540fff : ssiu
ec541000-ec54127f : ssi
ec5a-ec5a00ff : adg
ec70-ec70 : /dma-controller@ec70
ec72-ec72 : /dma-controller@ec72
ec74-ec7401ff : audmapp
e

Re: [PATCH 1/3] ARM: dts: rockchip: add i2s nodes for RK3228 SoCs

[kbuild test robot]

Hi,

[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v4.7-rc4 next-20160621]
[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/Xing-Zheng/ARM-dts-rockchip-add-i2s-nodes-for-RK3228-SoCs/20160621-152723
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git 
for-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
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=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/rk3228.dtsi:249.29-30 syntax error
   FATAL ERROR: Unable to parse input tree

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


.config.gz
Description: Binary data

Re: [RFC PATCH v2 00/15] ACPI IORT ARM SMMU v3 support

[Hanjun Guo]

Hi Lorenzo,

On 2016/6/7 21:30, Lorenzo Pieralisi wrote:

This RFC patch series is v2 of a previous posting:

https://lkml.org/lkml/2016/4/14/702

v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2
  owing to patch series dependencies [1]
- Moved platform device creation logic to IORT code to
  generalize its usage for ARM SMMU v1-v2-v3 components
- Removed reliance on ACPI early device probing
- Created IORT specific iommu_xlate() translation hook leaving
  OF code unchanged according to v1 reviews

The ACPI IORT table provides information that allows instantiating
ARM SMMU devices and carrying out id mappings between components on
ARM based systems (devices, IOMMUs, interrupt controllers).

http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf

Building on basic IORT support, available through [2]:

this patchset enables ARM SMMU v3 support on ACPI systems.


I'm trying to test your patches on D03 (SMMUv3 based) but ...

[...]

[1] R.Murphy "Generic DT bindings for PCI and ARM SMMU v3"
http://marc.info/?l=linux-arm-kernel&m=146497432413816&w=2


...This patch set is still in discussion and seems not work
for non-PCI devices.



[2] T.Nowicki "Introduce ACPI world to ITS irqchip" v5
http://marc.info/?l=linux-acpi&m=146469369703684&w=2


Tomasz sent out the v7 and included patches in your series.

I think a updated version before the test makes sense, what
do you think? Let me know your thoughts.

Thanks
Hanjun

Re: [PATCH] arm64: add boot image dependencies to not generate invalid images

[Masahiro Yamada]

2016-06-21 19:32 GMT+09:00 Catalin Marinas :
> On Tue, Jun 21, 2016 at 10:44:00AM +0900, Masahiro Yamada wrote:
>> I fixed boot image dependencies for arch/arm in commit 3939f3345050
>> ("ARM: 8418/1: add boot image dependencies to not generate invalid
>> images").
>>
>> I see a similar problem for arch/arm64; "make -jN Image Image.gz"
>> would sometimes end up generating bad images where N > 1.
>>
>> Fix the dependency in arch/arm64/Makefile to avoid the race
>> between "make Image" and "make Image.*".
>>
>> Signed-off-by: Masahiro Yamada 
>
> Acked-by: Catalin Marinas 
>
> Will, could you please pick this up for 4.7? Maybe with a cc stable.
> Thanks.


If possible, could you change the subject?


arm64: add boot image dependencies to not generate invalid images

 --->

arm64: fix boot image dependencies to not generate invalid images



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 08/19] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)

[Zhangjian (Bamvor)]

Hi,

On 2016/6/18 7:54, Yury Norov wrote:

Based on patch of Andrew Pinski.

This patch introduces is_a32_compat_task and is_a32_thread so it is
easier to say this is a a32 specific thread or a generic compat thread/task.
Corresponding functions are located in  to avoid mess in
headers.

Some files include both  and ,
and this is wrong because  has  already
included. It was fixed too.

Signed-off-by: Yury Norov 
Signed-off-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Andrew Pinski 
Reviewed-by: David Daney 
---
  arch/arm64/include/asm/compat.h  | 19 ++-
  arch/arm64/include/asm/elf.h | 10 +++---
  arch/arm64/include/asm/ftrace.h  |  2 +-
  arch/arm64/include/asm/is_compat.h   | 64 
  arch/arm64/include/asm/memory.h  |  5 +--
  arch/arm64/include/asm/processor.h   |  5 +--
  arch/arm64/include/asm/syscall.h |  2 +-
  arch/arm64/include/asm/thread_info.h |  2 +-
  arch/arm64/kernel/hw_breakpoint.c| 10 +++---
  arch/arm64/kernel/perf_regs.c|  2 +-
  arch/arm64/kernel/process.c  |  7 ++--
  arch/arm64/kernel/ptrace.c   | 11 +++
  arch/arm64/kernel/signal.c   |  4 +--
  arch/arm64/kernel/traps.c|  3 +-
  14 files changed, 98 insertions(+), 48 deletions(-)
  create mode 100644 arch/arm64/include/asm/is_compat.h

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index eb8432b..df2f72d 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -24,6 +24,8 @@
  #include 
  #include 

+#include 
+
  #define COMPAT_USER_HZ100
  #ifdef __AARCH64EB__
  #define COMPAT_UTS_MACHINE"armv8b\0\0"
@@ -298,23 +300,6 @@ struct compat_shmid64_ds {
compat_ulong_t __unused5;
  };

-static inline int is_compat_task(void)
-{
-   return test_thread_flag(TIF_32BIT);
-}
-
-static inline int is_compat_thread(struct thread_info *thread)
-{
-   return test_ti_thread_flag(thread, TIF_32BIT);
-}
-
-#else /* !CONFIG_COMPAT */
-
-static inline int is_compat_thread(struct thread_info *thread)
-{
-   return 0;
-}
-
  #endif /* CONFIG_COMPAT */
  #endif /* __KERNEL__ */
  #endif /* __ASM_COMPAT_H */
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 579b6e6..bef2d90 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -16,6 +16,10 @@
  #ifndef __ASM_ELF_H
  #define __ASM_ELF_H

+#ifndef __ASSEMBLY__
+#include 
+#endif
+
  #include 

  /*
@@ -152,13 +156,9 @@ extern int arch_setup_additional_pages(struct linux_binprm 
*bprm,
   int uses_interp);

  /* 1GB of VA */
-#ifdef CONFIG_COMPAT
-#define STACK_RND_MASK (test_thread_flag(TIF_32BIT) ? \
+#define STACK_RND_MASK (is_compat_task() ? \
0x7ff >> (PAGE_SHIFT - 12) : \
0x3 >> (PAGE_SHIFT - 12))
-#else
-#define STACK_RND_MASK (0x3 >> (PAGE_SHIFT - 12))
-#endif

  #ifdef __AARCH64EB__
  #define COMPAT_ELF_PLATFORM   ("v8b")
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index caa955f..0feb28a 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -54,7 +54,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long 
addr)
  #define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
  static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
  {
-   return is_compat_task();
+   return is_a32_compat_task();
  }
  #endif /* ifndef __ASSEMBLY__ */

diff --git a/arch/arm64/include/asm/is_compat.h 
b/arch/arm64/include/asm/is_compat.h
new file mode 100644
index 000..8dba5ca
--- /dev/null
+++ b/arch/arm64/include/asm/is_compat.h
@@ -0,0 +1,64 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 .
+ */
+
+#ifndef __ASM_IS_COMPAT_H
+#define __ASM_IS_COMPAT_H
+#ifndef __ASSEMBLY__
+
+#include 
+
+#ifdef CONFIG_AARCH32_EL0
+
+static inline int is_a32_compat_task(void)
+{
+   return test_thread_flag(TIF_32BIT);
+}
+
+static inline int is_a32_compat_thread(struct thread_info *thread)
+{
+   return test_ti_thread_flag(thread, TIF_32BIT);
+}
+
+#else
+
+static inline int is_a32_compat_task(void)
+
+{
+   return 0;
+}
+
+static inline int is_a32_compat_thread(struct thread_info *thread)
+{
+   return 0;
+}

Re: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Andy Shevchenko]

On Tue, 2016-06-21 at 10:20 +, Opensource [Adam Thomson] wrote:
> There still seems to be an issue with this patch set reaching the
> linux-acpi mailing list (as well as the other vger.kernel.org lists).
> Have
> spent some time looking into it but so far can't see anything
> obviously wrong
> with the mail format. Also tried to reduce down the number of people
> on the
> To/Cc list

There is still _a lot_ of addresses in the Cc and To fields.

-- 

Andy Shevchenko 
Intel Finland Oy

Re: [PATCH] irqchip: fix the config HISILICON_IRQ_MBIGEN dependency error.

[Marc Zyngier]

On 21/06/16 10:26, Jiancheng Xue wrote:
> This patch fixes the compiling error caused when
> config HISILICON_IRQ_MBIGEN is selected but
> PCI_MSI is not seleted.
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  drivers/irqchip/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index fa33c50..23dcf3e 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -110,7 +110,7 @@ config DW_APB_ICTL
>  config HISILICON_IRQ_MBIGEN
>   bool
>   select ARM_GIC_V3
> - select ARM_GIC_V3_ITS
> + select ARM_GIC_V3_ITS if PCI_MSI
>   select GENERIC_MSI_IRQ_DOMAIN

How can this be correct? The MBIGEN uses platform MSI (not PCI) and
relies on the ITS (it doesn't work without it). It seems that you're
papering over another issue.

Thanks,

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

Re: [PATCH 23/27] [AARCH64] delouse input arguments in system functions

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> Signed-off-by: Yury Norov 

You're missing a patch description.  What does "delouse" even mean?  What 
is the ABI peculiarity that means there are ABI-conforming arguments to 
these functions that need such a manipulation?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v12 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but
> that requires a system with suitable hardware.
>
> The basic conception of the usb charger is that, when one usb charger
> is added or removed by reporting from the usb gadget state change or
> the extcon device state change, the usb charger will report to power
> user to set the current limitation.
>
> The usb charger will register notifiees on the usb gadget or the extcon
> device to get notified the usb charger state. It also supplies the
> notification mechanism to userspace When the usb charger state is changed.
>
> Power user will register a notifiee on the usb charger to get notified
> by status changes from the usb charger. It will report to power user
> to set the current limitation when detecting the usb charger is added
> or removed from extcon device state or usb gadget state.
>
> This patch doesn't yet integrate with the gadget code, so some functions
> which rely on the 'gadget' are not completed, that will be implemented
> in the following patches.
>
> Signed-off-by: Baolin Wang 
> Reviewed-by: Li Jun 
> Tested-by: Li Jun 
> ---
>  drivers/usb/gadget/Kconfig   |7 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  770 
> ++
>  include/linux/usb/charger.h  |  191 ++
>  include/uapi/linux/usb/charger.h |   31 ++
>  5 files changed, 1000 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c
>  create mode 100644 include/linux/usb/charger.h
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 2057add..89f4e9b 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -134,6 +134,13 @@ config U_SERIAL_CONSOLE
>   help
>  It supports the serial gadget can be used as a console.
>  
> +config USB_CHARGER
> + bool "USB charger support"

you didn't build test all possibilities, did you?

I have a feeling this won't link if USB_GADGET=m. Can you test that?

> diff --git a/drivers/usb/gadget/udc/charger.c 
> b/drivers/usb/gadget/udc/charger.c
[...]
> +struct class *usb_charger_class;

We already have a UDC class, do we really, really need another class
here?

> +subsys_initcall(usb_charger_class_init);

this should always work as module_init(). Please make sure that's the
case.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Naveen N. Rao]

On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > 
> > > Hi, Michael and Naveen.
> > > 
> > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > and
> > > worked out the patch below before I noticed Naveen's patchset and the 
> > > latest
> > > changes in ppc tree for a better way to check for ABI versions.
> > > 
> > > However, since the issue described below affect mainline and stable 
> > > kernels,
> > > would you consider applying it before merging your two patchsets, so that 
> > > we can
> > > more easily backport the fix?
> > 
> > Hi Cascardo,
> > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > fixing it. But, I can see why this would be a good thing to have for 
> > -stable and existing distros. However, while your patch below may fix 
> > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > changes in bpf_jit_asm.S as well.
> 
> Hi, Naveen.
> 
> Any tips on how to exercise possible issues there? Or what changes you think
> would be sufficient?

The calling convention is different with ABIv2 and so we'll need changes 
in bpf_slow_path_common() and sk_negative_common().

However, rather than enabling classic JIT for ppc64le, are we better off 
just disabling it?

--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,7 +128,7 @@ config PPC
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
-   select HAVE_CBPF_JIT
+   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL


Michael,
Let me know your thoughts on whether you intend to take this patch or 
Cascardo's patch for -stable before the eBPF patches. I can redo my 
patches accordingly.


- Naveen

RE: [PATCH] sparc64: Swap registers for fault code and address in mna trap

[神田 尚]

Hi, David

Thank you for your reply.

> If you can really trigger this code path, please post the kernel log
> backtrace that happens when the BUG() triggers.  That way we can
> figure out what the real problem is.
I'm sorry I cannot show the information. I don't have now.
In fact, BUG() in do_sparc64_fault occurred in modified version
of linux-2.6.25.8 on SPARC64VIIIfx. I'm misunderstanding that
the same problem remains in the latest. 

> Your patch is also wrong for other reasons, it would break the
> unaligned trap code paths that don't go via user_rtt_fill_64bit
> fixups.
And from the first, I was wrong. I got it.

I have some questions.
I think that if %tl > 1, winfix_mna will be called. Is it correct?
And, the call trace is never occurred?


From: David Miller 
Date: 2016年6月18日 15:12
To: 神田　尚
CC: sparcli...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sparc64: Swap registers for fault code and address in mna 
trap

From: 神田　尚 
Date: Fri, 17 Jun 2016 01:49:11 +

> This bug may occur in the following.
>
> user_rtt_fill_64bit  <= If mna trap occurred, call do_mna
> +-> do_mna   <= Mistake storing registers for fault code and 
> address
> +-> winfix_mna
> +-> user_rtt_fill_fixup  <= Put fault address into 
> thread_info->flag's TI_FAULT_CODE
> +-> do_sparc64_fault() <= If fault address has FAULT_CODE_ITLB 
> and FAULT_CODE_DTLB bits, call BUG()
> +-> BUG()

We should not be invoking do_sparc64_fault() in this case.

Instead, we call either sun4v_do_mna() or mem_address_unaligned().

Neither of which care about the values stored in the thread's fault
address and code.

If you can really trigger this code path, please post the kernel log
backtrace that happens when the BUG() triggers.  That way we can
figure out what the real problem is.

Your patch is also wrong for other reasons, it would break the
unaligned trap code paths that don't go via user_rtt_fill_64bit
fixups.

[PATCH] PM / clk: Add support for adding a specific clock from device-tree

[Jon Hunter]

Some drivers using the PM clocks framework need to add specific clocks
from device-tree using a name by calling the functions
of_clk_get_by_name() and then pm_clk_add_clk(). Rather than having
drivers call both functions, add a helper function of_pm_clk_add_clk()
that will call these functions so drivers can call a single function
to add a specific clock from device-tree.

Signed-off-by: Jon Hunter 
---

Some examples of drivers that would be able to make use of this new
function are drivers/dma/tegra210-adma.c and
drivers/irqchip/irq-gic-pm.c.

 drivers/base/power/clock_ops.c | 32 
 include/linux/pm_clock.h   |  1 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 761f5c21f9f0..8e2e4757adcb 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -141,6 +141,38 @@ EXPORT_SYMBOL_GPL(pm_clk_add_clk);
 
 
 /**
+ * of_pm_clk_add_clk - Start using a device clock for power management.
+ * @dev: Device whose clock is going to be used for power management.
+ * @name: Name of clock that is going to be used for power management.
+ *
+ * Add the clock described in the 'clocks' device-tree node that matches
+ * with the 'name' provided, to the list of clocks used for the power
+ * management of @dev. On success, returns 0. Returns a negative error
+ * code if the clock is not found or cannot be added.
+ */
+int of_pm_clk_add_clk(struct device *dev, const char *name)
+{
+   struct clk *clk;
+   int ret;
+
+   if (!dev || !dev->of_node || !name)
+   return -EINVAL;
+
+   clk = of_clk_get_by_name(dev->of_node, name);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   ret = pm_clk_add_clk(dev, clk);
+   if (ret) {
+   clk_put(clk);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_pm_clk_add_clk);
+
+/**
  * of_pm_clk_add_clks - Start using device clock(s) for power management.
  * @dev: Device whose clock(s) is going to be used for power management.
  *
diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h
index 308d6044f153..09779b0ae720 100644
--- a/include/linux/pm_clock.h
+++ b/include/linux/pm_clock.h
@@ -42,6 +42,7 @@ extern int pm_clk_create(struct device *dev);
 extern void pm_clk_destroy(struct device *dev);
 extern int pm_clk_add(struct device *dev, const char *con_id);
 extern int pm_clk_add_clk(struct device *dev, struct clk *clk);
+extern int of_pm_clk_add_clk(struct device *dev, const char *name);
 extern int of_pm_clk_add_clks(struct device *dev);
 extern void pm_clk_remove(struct device *dev, const char *con_id);
 extern void pm_clk_remove_clk(struct device *dev, struct clk *clk);
-- 
2.1.4

Re: [PATCH net-next 01/19] net: hns: bug fix of ge reset sequence

[Andy Shevchenko]

On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
> From: Qianqian Xie 
> 
> The bit fileds of PPE reset register are different between HNS v1 and
> HNS v2, but the current procedure just only match HNS v1. Here is a
> patch to fix it.
> 
> Signed-off-by: Kejian Yan 
> Signed-off-by: Qianqian Xie 
> Signed-off-by: Yisen Zhuang 
> ---
>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> index 96cb628..09e60d6 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> @@ -271,7 +271,11 @@ static void hns_dsaf_ge_srst_by_port(struct
> dsaf_device *dsaf_dev, u32 port,
>   }
>   } else {
>   reg_val_1 = 0x15540 << dsaf_dev->reset_offset;
> - reg_val_2 = 0x100 << dsaf_dev->reset_offset;
> +
> + if (AE_IS_VER1(dsaf_dev->dsaf_ver))
> + reg_val_2 = 0x100 << dsaf_dev->reset_offset;
> + else
> + reg_val_2 = 0x40 << dsaf_dev->reset_offset;

reg_val_1 = 0x15540;
reg_val_2 = AE_IS_VER1(dsaf_dev->dsaf_ver) ? 0x100 : 0x40;

reg_val_1 <<= dsaf_dev->reset_offset;
reg_val_2 <<= dsaf_dev-
>reset_offset;


>  
>   if (!dereset) {
>   dsaf_write_sub(dsaf_dev,
> DSAF_SUB_SC_GE_RESET_REQ1_REG,

-- 

Andy Shevchenko 
Intel Finland Oy

Re: [PATCH] memcg: mem_cgroup_migrate() may be called with irq disabled

[Vladimir Davydov]

On Mon, Jun 20, 2016 at 02:41:58PM -0400, Tejun Heo wrote:
> mem_cgroup_migrate() uses local_irq_disable/enable() but can be called
> with irq disabled from migrate_page_copy().  This ends up enabling irq
> while holding a irq context lock triggering the following lockdep
> warning.  Fix it by using irq_save/restore instead.
> 
>   =
>   [ INFO: inconsistent lock state ]
>   4.7.0-rc1+ #52 Tainted: GW  
>   -
>   inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
>   kcompactd0/151 [HC0[0]:SC0[0]:HE1:SE1] takes:
>(&(&ctx->completion_lock)->rlock){+.?.-.}, at: [<0038fd96>] 
> aio_migratepage+0x156/0x1e8
>   {IN-SOFTIRQ-W} state was registered at:
> [<001a8366>] __lock_acquire+0x5b6/0x1930
> [<001a9b9e>] lock_acquire+0xee/0x270
> [<00951fee>] _raw_spin_lock_irqsave+0x66/0xb0
> [<00390108>] aio_complete+0x98/0x328
> [<0037c7d4>] dio_complete+0xe4/0x1e0
> [<00650e64>] blk_update_request+0xd4/0x450
> [<0072a1a8>] scsi_end_request+0x48/0x1c8
> [<0072d7e2>] scsi_io_completion+0x272/0x698
> [<0065adb2>] blk_done_softirq+0xca/0xe8
> [<00953f80>] __do_softirq+0xc8/0x518
> [<001495de>] irq_exit+0xee/0x110
> [<0010ceba>] do_IRQ+0x6a/0x88
> [<0095342e>] io_int_handler+0x11a/0x25c
> [<0094fb5c>] __mutex_unlock_slowpath+0x144/0x1d8
> [<0094fb58>] __mutex_unlock_slowpath+0x140/0x1d8
> [<003c6114>] kernfs_iop_permission+0x64/0x80
> [<0033ba86>] __inode_permission+0x9e/0xf0
> [<0033ea96>] link_path_walk+0x6e/0x510
> [<0033f09c>] path_lookupat+0xc4/0x1a8
> [<0034195c>] filename_lookup+0x9c/0x160
> [<00341b44>] user_path_at_empty+0x5c/0x70
> [<00335250>] SyS_readlinkat+0x68/0x140
> [<00952f8e>] system_call+0xd6/0x270
>   irq event stamp: 971410
>   hardirqs last  enabled at (971409): [<0030f982>] 
> migrate_page_move_mapping+0x3ea/0x588
>   hardirqs last disabled at (971410): [<00951fc4>] 
> _raw_spin_lock_irqsave+0x3c/0xb0
>   softirqs last  enabled at (970526): [<00954318>] 
> __do_softirq+0x460/0x518
>   softirqs last disabled at (970519): [<001495de>] irq_exit+0xee/0x110
> 
>   other info that might help us debug this:
>Possible unsafe locking scenario:
> 
>CPU0
>
> lock(&(&ctx->completion_lock)->rlock);
> 
>   lock(&(&ctx->completion_lock)->rlock);
> 
> *** DEADLOCK ***
> 
>   3 locks held by kcompactd0/151:
>#0:  (&(&mapping->private_lock)->rlock){+.+.-.}, at: [<0038fc82>] 
> aio_migratepage+0x42/0x1e8
>#1:  (&ctx->ring_lock){+.+.+.}, at: [<0038fc9a>] 
> aio_migratepage+0x5a/0x1e8
>#2:  (&(&ctx->completion_lock)->rlock){+.?.-.}, at: [<0038fd96>] 
> aio_migratepage+0x156/0x1e8
> 
>   stack backtrace:
>   CPU: 20 PID: 151 Comm: kcompactd0 Tainted: GW   4.7.0-rc1+ #52
>0001c6cbb730 0001c6cbb7c0 0002  
>0001c6cbb860 0001c6cbb7d8 0001c6cbb7d8 00114496 
> 00b517ec 00b680b6 000b 
>0001c6cbb820 0001c6cbb7c0   
>04000184ad18 00114496 0001c6cbb7c0 0001c6cbb820 
>   Call Trace:
>   ([<001143d2>] show_trace+0xea/0xf0)
>   ([<0011444a>] show_stack+0x72/0xf0)
>   ([<00684522>] dump_stack+0x9a/0xd8)
>   ([<0028679c>] print_usage_bug.part.27+0x2d4/0x2e8)
>   ([<001a71ce>] mark_lock+0x17e/0x758)
>   ([<001a784a>] mark_held_locks+0xa2/0xd0)
>   ([<001a79b8>] trace_hardirqs_on_caller+0x140/0x1c0)
>   ([<00326026>] mem_cgroup_migrate+0x266/0x370)
>   ([<0038fdaa>] aio_migratepage+0x16a/0x1e8)
>   ([<00310568>] move_to_new_page+0xb0/0x260)
>   ([<003111b4>] migrate_pages+0x8f4/0x9f0)
>   ([<002c507c>] compact_zone+0x4dc/0xdc8)
>   ([<002c5e22>] kcompactd_do_work+0x1aa/0x358)
>   ([<002c608a>] kcompactd+0xba/0x2c8)
>   ([<0016b09a>] kthread+0x10a/0x110)
>   ([<0095315a>] kernel_thread_starter+0x6/0xc)
>   ([<00953154>] kernel_thread_starter+0x0/0xc)
>   INFO: lockdep is turned off.
> 
> Signed-off-by: Tejun Heo 
> Reported-by: Christian Borntraeger 
> Link: http://lkml.kernel.org/g/5767cfe5.7080...@de.ibm.com

Reviewed-by: Vladimir Davydov 

Re: [PATCH v12 2/4] gadget: Support for the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
>
> It will report to the usb charger when the gadget state is changed,
> then the usb charger can do the power things.
>
> Signed-off-by: Baolin Wang 
> Reviewed-by: Li Jun 
> Tested-by: Li Jun 

Before anything, I must say that I really liked this patch. It's
minimaly invasive to udc core and does all the necessary changes. If it
wasn't for the extra charger class, this would've been perfect.

Can't you just tie a charger to a UDC and avoid the charger class
completely?

>  static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned 
> mA)
>  {
> + if (gadget->charger)

I guess you could do this check inside
usb_gadget_set_cur_limit_by_type() itself.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing

[Peter Zijlstra]

On Mon, Jun 20, 2016 at 10:26:30AM +, Odzioba, Lukasz wrote:
> On 08.06.2016 Peter Zijlstra wrote:
> > How does this work in the light of intel_alt_er() ?
> 
> Hi Peter,
> 
> If the constrained bit is valid on only one of the OCR MSRs (like in case of 
> KNL), 
> then OCR valid mask will forbid altering it by the other MSR in intel_alt_er.

Yes, that is the intent, but how is this achieved? I'm not sure I see
how the patch ensure this.

Also, intel_get_event_constraints() has a path where it copies the
constraint, should it not also copy the new field?

[PATCH v7 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

Signed-off-by: Frank Wang 
Suggested-by: Heiko Stuebner 
Suggested-by: Guenter Roeck 
Suggested-by: Doug Anderson 
---

Changes in v7:
 - renamed functions *usb2phy_resume/*usb2phy_suspend to 
*usb2phy_power_on/usb2phy_power_off.

Changes in v6:
 - Fixed the output clock would be disabled more than once while phy-port was 
going to suspend.
 - Improved the driver to avoid the currently empty otg-port would cause 
null-pointer dereferences.

Changes in v5:
 - Added 'reg' in the data block to match the different phy-blocks in dt.

Changes in v4:
 - Removed some processes related to 'vbus_host-supply'.

Changes in v3:
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Optimized 480m output clock register function.
 - Code cleanup.

Changes in v2:
 - Changed vbus_host operation from gpio to regulator in *_probe.
 - Improved the fault treatment relate to 480m clock register.
 - Cleaned up some meaningless codes in *_clk480m_disable.
 - made more clear the comment of *_sm_work.

 drivers/phy/Kconfig  |7 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-inno-usb2.c |  658 ++
 3 files changed, 666 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..29ef15c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_INNO_USB2
+   tristate "Rockchip INNO USB2PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Support for Rockchip USB2.0 PHY with Innosilicon IP block.
+
 config PHY_ROCKCHIP_EMMC
tristate "Rockchip EMMC PHY Driver"
depends on ARCH_ROCKCHIP && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..4963fbc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
new file mode 100644
index 000..299f599
--- /dev/null
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -0,0 +1,658 @@
+/*
+ * Rockchip USB2.0 PHY with Innosilicon IP block driver
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BIT_WRITEABLE_SHIFT16
+#define SCHEDULE_DELAY (60 * HZ)
+
+enum rockchip_usb2phy_port_id {
+   USB2PHY_PORT_OTG,
+   USB2PHY_PORT_HOST,
+   USB2PHY_NUM_PORTS,
+};
+
+enum rockchip_usb2phy_host_state {
+   PHY_STATE_HS_ONLINE = 0,
+   PHY_STATE_DISCONNECT= 1,
+   PHY_STATE_HS_CONNECT= 2,
+   PHY_STATE_FS_CONNECT= 4,
+};
+
+struct usb2phy_reg {
+   unsigned intoffset;
+   unsigned intbitend;
+   unsigned intbitstart;
+   unsigned intdisable;
+   unsigned intenable;
+};
+
+/**
+ * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
+ * @phy_sus: phy suspend register.
+ * @ls_det_en: linestate detection enable register.
+ * @ls_det_st: linestate detection state register.
+ * @ls_det_clr: linestate detection clear register.
+ * @utmi_ls: utmi linestate state register.
+ * @utmi_hstdet: utmi host disconnect register.
+ */
+struct rockchip_usb2phy_port_cfg {
+   struct usb2phy_reg  phy_sus;
+   struct usb2phy_reg  ls_det_en;
+   struct usb2phy_reg  ls_det_st;
+   struct usb2phy_reg  ls_det_clr;
+   struct usb2phy_reg  utm

Re: [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs

[Vladimir Davydov]

On Fri, Jun 17, 2016 at 12:25:16PM -0400, Johannes Weiner wrote:
> The memory controller has quite a bit of state that usually outlives
> the cgroup and pins its CSS until said state disappears. At the same
> time it imposes a 16-bit limit on the CSS ID space to economically
> store IDs in the wild. Consequently, when we use cgroups to contain
> frequent but small and short-lived jobs that leave behind some page
> cache, we quickly run into the 64k limitations of outstanding CSSs.
> Creating a new cgroup fails with -ENOSPC while there are only a few,
> or even no user-visible cgroups in existence.
> 
> Although pinning CSSs past cgroup removal is common, there are only
> two instances that actually need an ID after a cgroup is deleted:
> cache shadow entries and swapout records.
> 
> Cache shadow entries reference the ID weakly and can deal with the CSS
> having disappeared when it's looked up later. They pose no hurdle.
> 
> Swap-out records do need to pin the css to hierarchically attribute
> swapins after the cgroup has been deleted; though the only pages that
> remain swapped out after offlining are tmpfs/shmem pages. And those
> references are under the user's control, so they are manageable.
> 
> This patch introduces a private 16-bit memcg ID and switches swap and
> cache shadow entries over to using that. This ID can then be recycled
> after offlining when the CSS remains pinned only by objects that don't
> specifically need it.
> 
> This script demonstrates the problem by faulting one cache page in a
> new cgroup and deleting it again:
> 
> set -e
> mkdir -p pages
> for x in `seq 128000`; do
>   [ $((x % 1000)) -eq 0 ] && echo $x
>   mkdir /cgroup/foo
>   echo $$ >/cgroup/foo/cgroup.procs
>   echo trex >pages/$x
>   echo $$ >/cgroup/cgroup.procs
>   rmdir /cgroup/foo
> done
> 
> When run on an unpatched kernel, we eventually run out of possible IDs
> even though there are no visible cgroups:
> 
> [root@ham ~]# ./cssidstress.sh
> [...]
> 65000
> mkdir: cannot create directory '/cgroup/foo': No space left on device
> 
> After this patch, the IDs get released upon cgroup destruction and the
> cache and css objects get released once memory reclaim kicks in.

With 65K cgroups it will take the reclaimer a substantial amount of time
to iterate over all of them, which might result in latency spikes.
Probably, to avoid that, we could move pages from a dead cgroup's lru to
its parent's one on offline while still leaving dead cgroups pinned,
like we do in case of list_lru entries.

> 
> Signed-off-by: Johannes Weiner 

Reviewed-by: Vladimir Davydov 

One nit below.

...
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 75e74408cc8f..dc92b2df2585 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4057,6 +4057,60 @@ static struct cftype mem_cgroup_legacy_files[] = {
>   { },/* terminate */
>  };
>  
> +/*
> + * Private memory cgroup IDR
> + *
> + * Swap-out records and page cache shadow entries need to store memcg
> + * references in constrained space, so we maintain an ID space that is
> + * limited to 16 bit (MEM_CGROUP_ID_MAX), limiting the total number of
> + * memory-controlled cgroups to 64k.
> + *
> + * However, there usually are many references to the oflline CSS after
> + * the cgroup has been destroyed, such as page cache or reclaimable
> + * slab objects, that don't need to hang on to the ID. We want to keep
> + * those dead CSS from occupying IDs, or we might quickly exhaust the
> + * relatively small ID space and prevent the creation of new cgroups
> + * even when there are much fewer than 64k cgroups - possibly none.
> + *
> + * Maintain a private 16-bit ID space for memcg, and allow the ID to
> + * be freed and recycled when it's no longer needed, which is usually
> + * when the CSS is offlined.
> + *
> + * The only exception to that are records of swapped out tmpfs/shmem
> + * pages that need to be attributed to live ancestors on swapin. But
> + * those references are manageable from userspace.
> + */
> +
> +static struct idr mem_cgroup_idr;

static DEFINE_IDR(mem_cgroup_idr);

Re: [PATCH v12 4/4] power: wm831x_power: Support USB charger current limit management

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata->usb_gadget);

the fact that you rely on strings and pass them via pdata is an
indication that you don't have enough description of the HW. Seems like
we need to come up with a set of DT properties which tie a charger to a
UDC.

I'm thinking a phandle would be enough?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v7 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Frank Wang]

Signed-off-by: Frank Wang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

Changes in v6:
 - Changed '_' to '-' for otg-id and otg-bvalid property.

Changes in v5:
 - Added 'reg' property to identify the different phy-blocks.

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Added 'clocks' and 'clock-names' optional properties.
 - Specified 'otg-port' and 'host-port' as the sub-node name.

Changes in v2:
 - Changed vbus_host optional property from gpio to regulator.
 - Specified vbus_otg-supply optional property.
 - Specified otg_id and otg_bvalid property.

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   64 
 1 file changed, 64 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
new file mode 100644
index 000..3c29c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,64 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+   * "rockchip,rk3366-usb2phy"
+   * "rockchip,rk3399-usb2phy"
+ - reg : the address offset of grf for usb-phy configuration.
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify host or otg port,
+and shall be the following entries:
+   * "otg-port" : the name of otg port.
+   * "host-port" : the name of host port.
+
+Required properties (port (child) node):
+ - #phy-cells : must be 0. See ./phy-bindings.txt for details.
+ - interrupts : specify an interrupt for each entry in interrupt-names.
+ - interrupt-names : a list which shall be the following entries:
+   * "otg-id" : for the otg id interrupt.
+   * "otg-bvalid" : for the otg vbus interrupt.
+   * "linestate" : for the host/otg linestate interrupt.
+
+Optional properties:
+ - phy-supply : phandle to a regulator that provides power to VBUS.
+   See ./phy-bindings.txt for details.
+
+Example:
+
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+...
+
+   u2phy: usb2-phy@700 {
+   compatible = "rockchip,rk3366-usb2phy";
+   reg = <0x700 0x2c>;
+   #clock-cells = <0>;
+   clock-output-names = "sclk_otgphy0_480m";
+
+   u2phy_otg: otg-port {
+   #phy-cells = <0>;
+   interrupts = ,
+,
+;
+   interrupt-names = "otg-id", "otg-bvalid", "linestate";
+   status = "okay";
+   };
+
+   u2phy_host: host-port {
+   #phy-cells = <0>;
+   interrupts = ;
+   interrupt-names = "linestate";
+   status = "okay";
+   };
+   };
+};
-- 
1.7.9.5

[PATCH v7 0/2] Add a new Rockchip usb2 phy driver

[Frank Wang]

The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy
IP block than rk3288 and before, and most of phy-related registers are
also different from the past, so a new phy driver is required necessarily.

These series patches add phy-rockchip-inno-usb2.c and the corresponding
documentation.

Changes in v7:
 - renamed functions *usb2phy_resume/*usb2phy_suspend to 
*usb2phy_power_on/usb2phy_power_off.

Changes in v6:
 - Changed '_' to '-' for otg-id and otg-bvalid property in devicetree bindings.
 - Fixed the output clock would be disabled more than once while phy-port was 
going to suspend.
 - Improved the driver to avoid the currently empty otg-port would cause 
null-pointer dereferences.

Changes in v5:
 - Added 'reg' property both in devicetree bindings and driver to match the 
different phy-blocks.

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Supplemented some hardware-description into the devicetree bindings.
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Code cleanup.

Changes in v2:
 - Specified more hardware-description into the devicetree bindings.
 - Optimized some process of driver.

Frank Wang (2):
  Documentation: bindings: add DT documentation for Rockchip USB2PHY
  phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   64 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-rockchip-inno-usb2.c   |  658 
 4 files changed, 730 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

-- 
1.7.9.5

[PATCH v2] HID: i2c-hid: set power sleep before shutdown

[Guohua Zhong]

Add i2c_hid_shutdown for i2c-hid driver to send suspend cmd & free
irq before device shutdown.

Some HW design (i.e. Umaro, a chromebook model) is that the power to
i2c hid device won't down after device shutdown. Also the i2c-hid driver
do not send suspend cmd to the hid i2c device and free its irq before
shutdown.So if We touch the touchscreen or some other i2c hid device,
the power consumtion will be go up even when the device is in shutdown
state.

Though the root cause maybe a HW issue. But it seems that it is a
good pratice to set power sleep for i2c-hid device before shutdown.

Signed-off-by: Guohua Zhong 
---
 drivers/hid/i2c-hid/i2c-hid.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 2e021ba..79406ae 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1106,6 +1106,14 @@ static int i2c_hid_remove(struct i2c_client *client)
return 0;
 }
 
+static void i2c_hid_shutdown(struct i2c_client *client)
+{
+   struct i2c_hid *ihid = i2c_get_clientdata(client);
+
+   i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
+   free_irq(client->irq, ihid);
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int i2c_hid_suspend(struct device *dev)
 {
@@ -1230,7 +1238,7 @@ static struct i2c_driver i2c_hid_driver = {
 
.probe  = i2c_hid_probe,
.remove = i2c_hid_remove,
-
+   .shutdown   = i2c_hid_shutdown,
.id_table   = i2c_hid_id_table,
 };
 
-- 
1.9.1

Re: [PATCH v3 05/13] mm: Fix memcg stack accounting for sub-page stacks

[Vladimir Davydov]

On Mon, Jun 20, 2016 at 04:43:35PM -0700, Andy Lutomirski wrote:
> We should account for stacks regardless of stack size, and we need
> to account in sub-page units if THREAD_SIZE < PAGE_SIZE.  Change the
> units to kilobytes and Move it into account_kernel_stack().
> 
> Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 
> memory.stat")
> Cc: Vladimir Davydov 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: linux...@kvack.org
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Vladimir Davydov 

This patch is going to have a minor conflict with recent changes in
mmotm, where {alloc,free}_kmem_pages were dropped, The conflict should
be trivial to resolve - we only need to replace {alloc,free}_kmem_pages
with {alloc,free}_pages in this patch.

> ---
>  include/linux/memcontrol.h |  2 +-
>  kernel/fork.c  | 15 ++-
>  mm/memcontrol.c|  2 +-
>  3 files changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index a805474df4ab..3b653b86bb8f 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -52,7 +52,7 @@ enum mem_cgroup_stat_index {
>   MEM_CGROUP_STAT_SWAP,   /* # of pages, swapped out */
>   MEM_CGROUP_STAT_NSTATS,
>   /* default hierarchy stats */
> - MEMCG_KERNEL_STACK = MEM_CGROUP_STAT_NSTATS,
> + MEMCG_KERNEL_STACK_KB = MEM_CGROUP_STAT_NSTATS,
>   MEMCG_SLAB_RECLAIMABLE,
>   MEMCG_SLAB_UNRECLAIMABLE,
>   MEMCG_SOCK,
> diff --git a/kernel/fork.c b/kernel/fork.c
> index be7f006af727..ff3c41c2ba96 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -165,20 +165,12 @@ static struct thread_info 
> *alloc_thread_info_node(struct task_struct *tsk,
>   struct page *page = alloc_kmem_pages_node(node, THREADINFO_GFP,
> THREAD_SIZE_ORDER);
>  
> - if (page)
> - memcg_kmem_update_page_stat(page, MEMCG_KERNEL_STACK,
> - 1 << THREAD_SIZE_ORDER);
> -
>   return page ? page_address(page) : NULL;
>  }
>  
>  static inline void free_thread_info(struct thread_info *ti)
>  {
> - struct page *page = virt_to_page(ti);
> -
> - memcg_kmem_update_page_stat(page, MEMCG_KERNEL_STACK,
> - -(1 << THREAD_SIZE_ORDER));
> - __free_kmem_pages(page, THREAD_SIZE_ORDER);
> + free_kmem_pages((unsigned long)ti, THREAD_SIZE_ORDER);
>  }
>  # else
>  static struct kmem_cache *thread_info_cache;
> @@ -227,6 +219,11 @@ static void account_kernel_stack(struct thread_info *ti, 
> int account)
>  
>   mod_zone_page_state(zone, NR_KERNEL_STACK_KB,
>   THREAD_SIZE / 1024 * account);
> +
> + /* All stack pages belong to the same memcg. */
> + memcg_kmem_update_page_stat(
> + virt_to_page(ti), MEMCG_KERNEL_STACK_KB,
> + account * (THREAD_SIZE / 1024));
>  }
>  
>  void free_task(struct task_struct *tsk)
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 75e74408cc8f..8e13a2419dad 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5133,7 +5133,7 @@ static int memory_stat_show(struct seq_file *m, void *v)
>   seq_printf(m, "file %llu\n",
>  (u64)stat[MEM_CGROUP_STAT_CACHE] * PAGE_SIZE);
>   seq_printf(m, "kernel_stack %llu\n",
> -(u64)stat[MEMCG_KERNEL_STACK] * PAGE_SIZE);
> +(u64)stat[MEMCG_KERNEL_STACK_KB] * 1024);
>   seq_printf(m, "slab %llu\n",
>  (u64)(stat[MEMCG_SLAB_RECLAIMABLE] +
>stat[MEMCG_SLAB_UNRECLAIMABLE]) * PAGE_SIZE);

Re: [lkp] [btrfs] 164a91c9be: xfstests.generic.088.fail

[Anand Jain]

Thanks for the report.

> _check_btrfs_filesystem: filesystem on /dev/sda5 is inconsistent (see 
/lkp/benchmarks/xfstests/results//check.full)

> generic/088 0s

Ran tests again unfortunately I couldn't reproduce..
-
generic/088 0s ... 0s
generic/089 21s ... 39s
generic/090 4s ... 4s
generic/091 58s ... 58s
generic/092 1s ... 0s
generic/096  [not run] xfs_io fzero failed (old kernel/wrong fs?)
generic/098 2s ... 2s
generic/100 18s ... 18s
generic/101  3s
generic/102  8s
generic/103  2s
--

But a possible scenario .. in systems where rcu_callback itself
could be deferred it needs rcu_barrier(). Fixed this in V2, by
restoring rcu_barrier() and then grace period wait for devices
to close.



+mount: /dev/sda6 is already mounted or /fs/scratch busy

::

+umount: /dev/sda6: not mounted


This might be different issue, when this happens generally
wipefs all scratch pool devices helps.


Thanks, Anand

Re: [PATCH 02/27] [AARCH64] Add header guards to sysdep.h headers.

[Szabolcs Nagy]

On 21/06/16 06:06, Yury Norov wrote:
> From: Andrew Pinski 
> 
> * sysdeps/aarch64/sysdep.h: Add header guards.
> 

the things listed below are not part of the patch
(upstream glibc already has these fixes)

> [AARCH64] Remove 64 from some relocation names as they have been renamed in 
> later versions of the spec.
> 
> The AARCH64 elf ABI spec renamed some relocations removing 64 from the TLS
> relocation names to make them constaint with the ILP32 named ones.
> 
> * elf/elf.h (R_AARCH64_TLS_DTPMOD64): Rename to ..
> (R_AARCH64_TLS_DTPMOD): This.
> (R_AARCH64_TLS_DTPREL64): Rename to ...
> (R_AARCH64_TLS_DTPREL): This.
> (R_AARCH64_TLS_TPREL64): Rename to ...
> (R_AARCH64_TLS_TPREL): This.
> * sysdeps/aarch64/dl-machine.h (elf_machine_type_class): Update
> R_AARCH64_TLS_DTPMOD64, R_AARCH64_TLS_DTPREL64, and R_AARCH64_TLS_TPREL64.
> (elf_machine_rela): Likewise.
...

[PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

[Thomas Rowland]

Renamed the ieee802154_llsec_device member 'hwaddr' to 'extended_addr'

Signed-off-by: Thomas Rowland 
---
 include/net/cfg802154.h   |  2 +-
 net/ieee802154/nl802154.c | 15 +--
 net/mac802154/llsec.c |  4 ++--
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index 171cd76..1b5bb10 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -292,7 +292,7 @@ struct ieee802154_llsec_device {
 
__le16 pan_id;
__le16 short_addr;
-   __le64 hwaddr;
+   __le64 extended_addr;
u32 frame_counter;
bool seclevel_exempt;
 
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 116187b..f0cb080 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1628,7 +1628,7 @@ static int nl802154_send_device(struct sk_buff *msg, u32 
cmd, u32 portid,
nla_put_le16(msg, NL802154_DEV_ATTR_SHORT_ADDR,
 dev_desc->short_addr) ||
nla_put_le64(msg, NL802154_DEV_ATTR_EXTENDED_ADDR,
-dev_desc->hwaddr, NL802154_DEV_ATTR_PAD) ||
+dev_desc->extended_addr, NL802154_DEV_ATTR_PAD) ||
nla_put_u8(msg, NL802154_DEV_ATTR_SECLEVEL_EXEMPT,
   dev_desc->seclevel_exempt) ||
nla_put_u32(msg, NL802154_DEV_ATTR_KEY_MODE, dev_desc->key_mode))
@@ -1725,8 +1725,7 @@ ieee802154_llsec_parse_device(struct nlattr *nla,
dev->frame_counter = 
nla_get_u32(attrs[NL802154_DEV_ATTR_FRAME_COUNTER]);
dev->pan_id = nla_get_le16(attrs[NL802154_DEV_ATTR_PAN_ID]);
dev->short_addr = nla_get_le16(attrs[NL802154_DEV_ATTR_SHORT_ADDR]);
-   /* TODO rename hwaddr to extended_addr */
-   dev->hwaddr = nla_get_le64(attrs[NL802154_DEV_ATTR_EXTENDED_ADDR]);
+   dev->extended_addr = 
nla_get_le64(attrs[NL802154_DEV_ATTR_EXTENDED_ADDR]);
dev->seclevel_exempt = 
nla_get_u8(attrs[NL802154_DEV_ATTR_SECLEVEL_EXEMPT]);
dev->key_mode = nla_get_u32(attrs[NL802154_DEV_ATTR_KEY_MODE]);
 
@@ -1850,7 +1849,7 @@ nl802154_dump_llsec_devkey(struct sk_buff *skb, struct 
netlink_callback *cb)
 cb->nlh->nlmsg_seq,
 NLM_F_MULTI, rdev,
 wpan_dev->netdev,
-dpos->hwaddr,
+dpos->extended_addr,
 kpos) < 0) {
/* TODO */
err = -EIO;
@@ -1903,9 +1902,7 @@ static int nl802154_add_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
 
/* TODO be32 */
key.frame_counter = 
nla_get_u32(attrs[NL802154_DEVKEY_ATTR_FRAME_COUNTER]);
-   /* TODO change naming hwaddr -> extended_addr
-* check unique identifier short+pan OR extended_addr
-*/
+   /* TODO check unique identifier short+pan OR extended_addr */
extended_addr = nla_get_le64(attrs[NL802154_DEVKEY_ATTR_EXTENDED_ADDR]);
return rdev_add_devkey(rdev, wpan_dev, extended_addr, &key);
 }
@@ -1932,9 +1929,7 @@ static int nl802154_del_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
  &key.key_id) < 0)
return -ENOBUFS;
 
-   /* TODO change naming hwaddr -> extended_addr
-* check unique identifier short+pan OR extended_addr
-*/
+   /* TODO check unique identifier short+pan OR extended_addr */
extended_addr = nla_get_le64(attrs[NL802154_DEVKEY_ATTR_EXTENDED_ADDR]);
return rdev_del_devkey(rdev, wpan_dev, extended_addr, &key);
 }
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index 6a3e1c2..e8a1f76 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -358,13 +358,13 @@ int mac802154_llsec_dev_add(struct mac802154_llsec *sec,
 {
struct mac802154_llsec_device *entry;
u32 skey = llsec_dev_hash_short(dev->short_addr, dev->pan_id);
-   u64 hwkey = llsec_dev_hash_long(dev->hwaddr);
+   u64 hwkey = llsec_dev_hash_long(dev->extended_addr);
 
BUILD_BUG_ON(sizeof(hwkey) != IEEE802154_ADDR_LEN);
 
if ((llsec_dev_use_shortaddr(dev->short_addr) &&
 llsec_dev_find_short(sec, dev->short_addr, dev->pan_id)) ||
-llsec_dev_find_long(sec, dev->hwaddr))
+llsec_dev_find_long(sec, dev->extended_addr))
return -EEXIST;
 
entry = kmalloc(sizeof(*entry), GFP_KERNEL);
-- 
2.1.4

Re: [RFC PATCH 00/27] ARM64: support ILP32

[Joseph Myers]

On Tue, 21 Jun 2016, Yury Norov wrote:

> Please review it. Any comments appreciated.

General comments:

Please make sure you go through all the review comments from the previous 
patch series posted in Oct 2014 and either address them, or explicitly 
justify why you think they are incorrect or not applicable to this version 
of the series.  That's both my comments and comments from other people.

Please make sure you follow the GNU Coding Standards throughout.  Also 
glibc standards such as every file having a one-line description before 
the copyright notice.

Please send patches against current master, not 2.23.  Each new revision 
of the series should be rebased against the latest master.

Please give details of the test results you see running the full glibc 
testsuite with this patch series under the indicated kernel version.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Hi Frank,

Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang:
> On 2016/6/20 12:56, Guenter Roeck wrote:
> > On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang  
wrote:
> >>> Turns out my problem was one of terminology. Using "suspend" and
> >>> "resume" to me suggested the common use of suspend and resume
> >>> functions. That is not the case here. After mentally replacing
> >>> "suspend" with "power_off" and "resume" with "power_on", you are
> >>> right, no problem exists. Sorry for the noise.
> >>> 
> >>> Maybe it would be useful to replace "resume" with "power_on" and
> >>> "suspend" with "power_off" in the function and variable names to
> >>> reduce confusion and misunderstandings.
> >>> 
> >>> Thanks,
> >>> Guenter
> >> 
> >> Well, it does have a bits confusion, however, the phy-port always just
> >> goes
> >> to suspend and resume mode (Not power off and power on) in a fact. So
> >> must
> >> it be renamed?
> > 
> > Other phy drivers name the functions _power_off and _power_on and
> > avoid the confusion. The callbacks are named .power_off and .power_on,
> > which gives a clear indication of its intended purpose. Other drivers
> > implementing suspend/resume (such as the omap usb phy driver) tie
> > those functions not into the power_off/power_on callbacks, but into
> > the driver's suspend/resume callbacks. At least the omap driver has
> > separate power management functions.
> > 
> > Do the functions _have_ to be renamed ? Surely not. But, if the
> > functions are really suspend/resume functions and not
> > power_off/power_on functions, maybe they should tie to the
> > suspend/resume functions and not register themselves as
> > power_off/power_on functions ?
> 
> As Guenter mentioned above,  I doped out two solutions, one is that keep
> current process but renaming *_resume/*_suspend to
> *_power_on/*_power_off;

in a way, naming stuff "power_off", "power_on" actually matches. For one, the 
phy-block goes from unusable to usable by usb-devices and also will power-on a 
phy-supply regulator (often named vcc_host* on Rockchip boards) from the phy-
core.

> another is that do not assign power_on/power_off
> functions for phy_ops at phy creating time, then, shorten
> _SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port
> suspend/resume mechanism depend on _sm_work_ completely.

Which in turn would mean that we would always depend on a fully controllable 
phy block. Right now it seems, rk3036, rk3228, rk3368 (probably forgot some) 
have the same type of phy, but with at least the unplug-detection missing.
In its current form the driver can very well support those (later on) by 
simply working statically (only acting on phy_power callbacks and not going to 
suspend on its own).

Also having the work running in 10-second intervall seems wasteful.

> 
> So which is the better way from your view? or would you like to give
> other unique perceptions please?

As obvious from the above, I would prefer just renaming the functions :-)


Heiko

Re: [PATCH] regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()

[Keerthy]

On Tuesday 21 June 2016 12:29 PM, Axel Lin wrote:

No need to pass _nlr to LP873X_REGULATOR(), use ARRAY_SIZE to calculate it.


Looks good to me.

Acked-by: Keerthy 



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

diff --git a/drivers/regulator/lp873x-regulator.c 
b/drivers/regulator/lp873x-regulator.c
index b4ffd11..e504b91 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -20,7 +20,7 @@
  #include 

  #define LP873X_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, _er, _em, \
-_delay, _lr, _nlr, _cr)\
+_delay, _lr, _cr)  \
[_id] = {   \
.desc = {   \
.name   = _name,\
@@ -37,7 +37,7 @@
.enable_mask= _em,  \
.ramp_delay = _delay,   \
.linear_ranges  = _lr,  \
-   .n_linear_ranges= _nlr, \
+   .n_linear_ranges= ARRAY_SIZE(_lr),  \
},  \
.ctrl2_reg = _cr,   \
}
@@ -175,22 +175,20 @@ static const struct lp873x_regulator regulators[] = {
 256, LP873X_REG_BUCK0_VOUT,
 LP873X_BUCK0_VOUT_BUCK0_VSET, LP873X_REG_BUCK0_CTRL_1,
 LP873X_BUCK0_CTRL_1_BUCK0_EN, 1,
-buck0_buck1_ranges, 4, LP873X_REG_BUCK0_CTRL_2),
+buck0_buck1_ranges, LP873X_REG_BUCK0_CTRL_2),
LP873X_REGULATOR("BUCK1", LP873X_BUCK_1, "buck1", lp873x_buck01_ops,
 256, LP873X_REG_BUCK1_VOUT,
 LP873X_BUCK1_VOUT_BUCK1_VSET, LP873X_REG_BUCK1_CTRL_1,
 LP873X_BUCK1_CTRL_1_BUCK1_EN, 1,
-buck0_buck1_ranges, 4, LP873X_REG_BUCK1_CTRL_2),
+buck0_buck1_ranges, LP873X_REG_BUCK1_CTRL_2),
LP873X_REGULATOR("LDO0", LP873X_LDO_0, "ldo0", lp873x_ldo01_ops, 26,
 LP873X_REG_LDO0_VOUT, LP873X_LDO0_VOUT_LDO0_VSET,
 LP873X_REG_LDO0_CTRL,
-LP873X_LDO0_CTRL_LDO0_EN, 0, ldo0_ldo1_ranges, 1,
-0xFF),
+LP873X_LDO0_CTRL_LDO0_EN, 0, ldo0_ldo1_ranges, 0xFF),
LP873X_REGULATOR("LDO1", LP873X_LDO_1, "ldo1", lp873x_ldo01_ops, 26,
 LP873X_REG_LDO1_VOUT, LP873X_LDO1_VOUT_LDO1_VSET,
 LP873X_REG_LDO1_CTRL,
-LP873X_LDO1_CTRL_LDO1_EN, 0, ldo0_ldo1_ranges, 1,
-0xFF),
+LP873X_LDO1_CTRL_LDO1_EN, 0, ldo0_ldo1_ranges, 0xFF),
  };

  static int lp873x_regulator_probe(struct platform_device *pdev)

[[PATCH v2] 09/11] irqchip/s3c24xx: fixup IO accessors for big endian

[Ben Dooks]

Instead of using the __raw accesors, use the _relaxed versions
to deal with any issues due to endian-ness of the CPU.

Signed-off-by: Ben Dooks 

---
CC: Thomas Gleixner  (maintainer:IRQCHIP DRIVERS)
CC: Jason Cooper  (maintainer:IRQCHIP DRIVERS)
CC: Marc Zyngier  (maintainer:IRQCHIP DRIVERS)
CC: linux-kernel@vger.kernel.org (open list:IRQCHIP DRIVERS)
CC: linux-arm-ker...@lists.infradead.org
---
 drivers/irqchip/irq-s3c24xx.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 5dc5a76..c25ce5a 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -92,9 +92,9 @@ static void s3c_irq_mask(struct irq_data *data)
unsigned long mask;
unsigned int irqno;
 
-   mask = __raw_readl(intc->reg_mask);
+   mask = readl_relaxed(intc->reg_mask);
mask |= (1UL << irq_data->offset);
-   __raw_writel(mask, intc->reg_mask);
+   writel_relaxed(mask, intc->reg_mask);
 
if (parent_intc) {
parent_data = &parent_intc->irqs[irq_data->parent_irq];
@@ -119,9 +119,9 @@ static void s3c_irq_unmask(struct irq_data *data)
unsigned long mask;
unsigned int irqno;
 
-   mask = __raw_readl(intc->reg_mask);
+   mask = readl_relaxed(intc->reg_mask);
mask &= ~(1UL << irq_data->offset);
-   __raw_writel(mask, intc->reg_mask);
+   writel_relaxed(mask, intc->reg_mask);
 
if (parent_intc) {
irqno = irq_find_mapping(parent_intc->domain,
@@ -136,9 +136,9 @@ static inline void s3c_irq_ack(struct irq_data *data)
struct s3c_irq_intc *intc = irq_data->intc;
unsigned long bitval = 1UL << irq_data->offset;
 
-   __raw_writel(bitval, intc->reg_pending);
+   writel_relaxed(bitval, intc->reg_pending);
if (intc->reg_intpnd)
-   __raw_writel(bitval, intc->reg_intpnd);
+   writel_relaxed(bitval, intc->reg_intpnd);
 }
 
 static int s3c_irq_type(struct irq_data *data, unsigned int type)
@@ -172,9 +172,9 @@ static int s3c_irqext_type_set(void __iomem *gpcon_reg,
unsigned long newvalue = 0, value;
 
/* Set the GPIO to external interrupt mode */
-   value = __raw_readl(gpcon_reg);
+   value = readl_relaxed(gpcon_reg);
value = (value & ~(3 << gpcon_offset)) | (0x02 << gpcon_offset);
-   __raw_writel(value, gpcon_reg);
+   writel_relaxed(value, gpcon_reg);
 
/* Set the external interrupt to pointed trigger type */
switch (type)
@@ -208,9 +208,9 @@ static int s3c_irqext_type_set(void __iomem *gpcon_reg,
return -EINVAL;
}
 
-   value = __raw_readl(extint_reg);
+   value = readl_relaxed(extint_reg);
value = (value & ~(7 << extint_offset)) | (newvalue << extint_offset);
-   __raw_writel(value, extint_reg);
+   writel_relaxed(value, extint_reg);
 
return 0;
 }
@@ -315,8 +315,8 @@ static void s3c_irq_demux(struct irq_desc *desc)
 
chained_irq_enter(chip, desc);
 
-   src = __raw_readl(sub_intc->reg_pending);
-   msk = __raw_readl(sub_intc->reg_mask);
+   src = readl_relaxed(sub_intc->reg_pending);
+   msk = readl_relaxed(sub_intc->reg_mask);
 
src &= ~msk;
src &= irq_data->sub_bits;
@@ -337,7 +337,7 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc 
*intc,
int pnd;
int offset;
 
-   pnd = __raw_readl(intc->reg_intpnd);
+   pnd = readl_relaxed(intc->reg_intpnd);
if (!pnd)
return false;
 
@@ -352,7 +352,7 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc 
*intc,
 *
 * Thanks to Klaus, Shannon, et al for helping to debug this problem
 */
-   offset = __raw_readl(intc->reg_intpnd + 4);
+   offset = readl_relaxed(intc->reg_intpnd + 4);
 
/* Find the bit manually, when the offset is wrong.
 * The pending register only ever contains the one bit of the next
@@ -406,7 +406,7 @@ int s3c24xx_set_fiq(unsigned int irq, bool on)
intmod = 0;
}
 
-   __raw_writel(intmod, S3C2410_INTMOD);
+   writel_relaxed(intmod, S3C2410_INTMOD);
return 0;
 }
 
@@ -508,14 +508,14 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc *intc)
 
last = 0;
for (i = 0; i < 4; i++) {
-   pend = __raw_readl(reg_source);
+   pend = readl_relaxed(reg_source);
 
if (pend == 0 || pend == last)
break;
 
-   __raw_writel(pend, intc->reg_pending);
+   writel_relaxed(pend, intc->reg_pending);
if (intc->reg_intpnd)
-   __raw_writel(pend, intc->reg_intpnd);
+   writel_relaxed(pend, intc->reg_intpnd);
 
pr_info("irq: clearing pending status %08x\n", (int)pend);
last = pend;
-- 
2.8.1

Re: [PATCH v3 03/13] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

[Matt Fleming]

On Mon, 20 Jun, at 04:43:33PM, Andy Lutomirski wrote:
> kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in
> init_mm.pgd were to be cleared, callers would need to ensure that
> the pgd entry hadn't been propagated to any other pgd.
> 
> Its only caller was efi_cleanup_page_tables(), and that, in turn,
> was unused, so just delete both functions.  This leaves a couple of
> other helpers unused, so delete them, too.
> 
> Cc: Matt Fleming 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/efi.h   |  1 -
>  arch/x86/include/asm/pgtable_types.h |  2 --
>  arch/x86/mm/pageattr.c   | 28 
>  arch/x86/platform/efi/efi.c  |  2 --
>  arch/x86/platform/efi/efi_32.c   |  3 ---
>  arch/x86/platform/efi/efi_64.c   |  5 -
>  6 files changed, 41 deletions(-)

Looks fine.

Reviewed-by: Matt Fleming 

RE: [RESEND PATCH v3 1/2] device property: Add function to search for named child of device

[Opensource [Adam Thomson]]

On 20 June 2016 12:39, Adam Thomson wrote:

> For device nodes in both DT and ACPI, it possible to have named
> child nodes which contain properties (an existing example being
> gpio-leds). This adds a function to find a named child node for
> a device which can be used by drivers for property retrieval.
> 
> For DT data node name matching, of_node_cmp() and similar functions
> are made available outside of CONFIG_OF block so the new function
> can reference these for DT and non-DT builds.
> 
> For ACPI data node name matching, a helper function is also added
> which returns false if CONFIG_ACPI is not set, otherwise it
> performs a string comparison on the data node name. This avoids
> using the acpi_data_node struct for non CONFIG_ACPI builds,
> which would otherwise cause a build failure.
> 
> Signed-off-by: Adam Thomson 
> Tested-by: Sathyanarayana Nujella 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v3:
>  - Move of_*_cmp() functions in of.h outside of CONFIG_OF block so they are
>available for non-DT builds
>  - In device_get_named_child_node(), use of_node_cmp() helper macro instead of
>strcasecmp() (node names not alway case insensitive, depending on 
> platform).
> 
> Changes in v2:
>  - Rebase to v4.7-rc1
> 
>  drivers/base/property.c  | 28 
>  include/acpi/acpi_bus.h  |  7 +++
>  include/linux/acpi.h |  6 ++
>  include/linux/of.h   | 14 +++---
>  include/linux/property.h |  3 +++
>  5 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f38c21d..43a36d6 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -888,6 +888,34 @@ struct fwnode_handle *device_get_next_child_node(struct
> device *dev,
>  EXPORT_SYMBOL_GPL(device_get_next_child_node);
> 
>  /**
> + * device_get_named_child_node - Return first matching named child node 
> handle
> + * @dev: Device to find the named child node for.
> + * @childname: String to match child node name against.
> + */
> +struct fwnode_handle *device_get_named_child_node(struct device *dev,
> +   const char *childname)
> +{
> + struct fwnode_handle *child;
> +
> + /*
> +  * Find first matching named child node of this device.
> +  * For ACPI this will be a data only sub-node.
> +  */
> + device_for_each_child_node(dev, child) {
> + if (is_of_node(child)) {
> + if (!of_node_cmp(to_of_node(child)->name, childname))
> + return child;
> + } else if (is_acpi_data_node(child)) {
> + if (acpi_data_node_match(child, childname))
> + return child;
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(device_get_named_child_node);
> +
> +/**
>   * fwnode_handle_put - Drop reference to a device node
>   * @fwnode: Pointer to the device node to drop the reference to.
>   *
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 788c6c3..993bdd0 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -420,6 +420,13 @@ static inline struct acpi_data_node
> *to_acpi_data_node(struct fwnode_handle *fwn
>   container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return is_acpi_data_node(fwnode) ?
> + (!strcasecmp(to_acpi_data_node(fwnode)->name, name)) : false;
> +}
> +
>  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
> *adev)
>  {
>   return &adev->fwnode;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 288fac5..03039c4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -568,6 +568,12 @@ static inline struct acpi_data_node
> *to_acpi_data_node(struct fwnode_handle *fwn
>   return NULL;
>  }
> 
> +static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
> + const char *name)
> +{
> + return false;
> +}
> +
>  static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device 
> *adev)
>  {
>   return NULL;
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 74eb28c..310e32f 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -238,13 +238,6 @@ static inline unsigned long of_read_ulong(const __be32
> *cell, int size)
>  #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>  #endif
> 
> -/* Default string compare functions, Allow arch asm/prom.h to override */
> -#if !defined(of_compat_cmp)
> -#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
> -#define of_prop_cmp(s1, s2)  strcmp((s1), (s2))
> -#define of_node_cmp(s1, s2)  strcasecmp((s1), (s2))
> -#endif
> -
>  #define OF_IS_DYNAMIC(x) test_bit(OF_DYNAMIC, &x->_flags)
>  #define 

Re: Using DT overlays for adding virtual hardware

[Jan Kiszka]

Hi Pantelis,

coming back to this topic:

On 2016-06-09 08:03, Jan Kiszka wrote:
> OK, trial and error, and some interesting insights: I've played with DT
> fragments and the overlay configfs patch of Pantelis [1] to have a
> convenient start. Interestingly, I wasn't able to load a fragment that
> followed the format specification for overlays ("Failed to resolve
> tree"). By chance, I got this one working:
> 
> /dts-v1/;
> / {
>   fragment {
>   target-path = "/soc@01c0";
>   __overlay__ {
>   #address-cells = <2>;
>   #size-cells = <2>;
> 
>   vpci@0x200 {
>   compatible = "pci-host-cam-generic";
>   device_type = "pci";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   reg = <0 0x200 0 0x100>;
>   ranges =
>   <0x0200 0x00 0x1000 0x00 
> 0x1000 0x00 0x3000>;
>   };
>   };
>   };
> };
> 
> It successfully makes a BananaPi kernel add a pci host with the
> specified config space and MMIO window.
> 
> [   81.619583] PCI host bridge /soc@01c0/vpci@0x200 ranges:
> [   81.619610]   No bus range found for /soc@01c0/vpci@0x200, using 
> [bus 00-ff]
> [   81.619634]   MEM 0x1000..0x3fff -> 0x1000
> [   81.620482] pci-host-generic 200.vpci: ECAM at [mem 
> 0x0200-0x02ff] for [bus 00-ff]
> [   81.620779] pci-host-generic 200.vpci: PCI host bridge to bus :00
> [   81.620801] pci_bus :00: root bus resource [bus 00-ff]
> [   81.620814] pci_bus :00: root bus resource [mem 0x1000-0x3fff]
> [   81.620851] PCI: bus0: Fast back to back transfers enabled
> 
> So, no /plugin/ statement, no phandles resolution. This format even
> builds with the in-kernel dtc. Any explanations? Does the code make
> sense (at least it builds without warnings)?
> 
> Now I need to back this with some code in Jailhouse.

Meanwhile I got a virtual PCI device recognized by Linux when running
over Jailhouse. However, my hack above doesn't get me to proper
interrupt mapping yet. This is what I was trying with upstream dtc:

/dts-v1/;
/ {
compatible = "lemaker,bananapi", "allwinner,sun7i-a20";

fragment@0 {
target-path = "/soc@01c0";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;

vpci@200 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &gic 0 0 0 123 4>,
<0 0 0 2 &gic 0 0 0 124 4>,
<0 0 0 3 &gic 0 0 0 125 4>,
<0 0 0 4 &gic 0 0 0 126 4>;
reg = <0 0x200 0 0x10>;
ranges =
<0x0200 0x00 0x1000 0x00 
0x1000 0x00 0x3000>;
};
};
};

gic: fragment@1 {
target-path = "/soc@01c0/interrupt-controller@01c81000";
__overlay__ {
};
};
};

And this is what Linux detects on that PCI bus:

00:0f.0 RAM memory: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- ;
#size-cells = <2>;

vpci@200 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &gic 0 0 0 123 4>,
<0 0 0 2 &gic 0 0 0 124 4>,
<0 0 0 3 &gic 0 0 0 125 4>,
<0 0 0 4 &gic 0 0 0 126 4>;
reg = <0 0x200 0 0x10>;
 

Re: [PATCH 2/3] iio: potentiometer: mcp4531: Add device tree binding documentation

[Peter Rosin]

On 2016-06-21 08:55, Florian Vaussard wrote:
> Add the device tree documentation for all the supported parts. Apart the
> compatible string and standard I2C binding, no other binding is currently
> needed.
> 
> Signed-off-by: Florian Vaussard 
> ---
>  .../bindings/iio/potentiometer/mcp4531.txt | 84 
> ++
>  1 file changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt 
> b/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> new file mode 100644
> index 000..b052299
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/potentiometer/mcp4531.txt
> @@ -0,0 +1,84 @@
> +* Microchip MCP453X/454X/455X/456X/463X/464X/465X/466X Digital Potentiometer
> +  driver
> +
> +The node for this driver must be a child node of a I2C controller, hence
> +all mandatory properties for your controller must be specified. See 
> directory:
> +
> +Documentation/devicetree/bindings/i2c
> +
> +for more details.
> +
> +Required properties:
> + - compatible:   Must be one of the following, depending on the
> + model:
> + "microchip,mcp4531-502"
> + "microchip,mcp4531-103"
> + "microchip,mcp4531-503"

*snip*

I'm not directly opposed, but I have used the following and DT booting
works like a charm here.

mcp4651-104@28 {
compatible = "mcp4651-104";
reg = <0x28>;
};

But, I suppose some DT documentation is not bad, and my understanding of
the device instantiation process and the i2c/dt interactions are not
complete, so my DT snippet might be an abomination? I'll leave the
decision if this is needed to someone with more experience on how other
drivers handle this.

Cheers,
Peter

Re: Using irq-crossbar.c

[Marc Zyngier]

[been away for a while, catching up...]

On 16/06/16 13:39, Sebastian Frias wrote:
> Hi Marc,
> 
> On 06/14/2016 06:39 PM, Sebastian Frias wrote:
>> On 06/14/2016 06:37 PM, Sebastian Frias wrote:
>> Also, without seeing the code,
>> it is pretty difficult to make any meaningful comment...
>
> Base code is either 4.7rc1 or 4.4.
> The irq-crossbar code is not much different from TI, but you can find it 
> attached.

 Please post it separately (and inline), the email client I have here
 makes it hard to review attached patches.
>>>
>>> Ok, I'll post it in a separate email and inline.
>>>
>>
>> Here it goes:
>>
>>
> 
>  
> 
>> IRQCHIP_DECLARE(tangox_intc, "sigma,smp-irq-mux", tangox_of_irq_mux_init);
>>
>>
> 
> I have tested the code, and aside from the missing #interrupt-cells
> in the DT that you pointed out, it seems it is working (devices using
> IRQ appear functional), here's some log:
> 
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 1 (0x1) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 18 (0x12) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 18 (0x12) hwirq 1 (0x1)
> tangox_setup_irq_route(): route irq  1 (@ 0xf006f804) => irq 23
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 38 (0x26) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 19 (0x13) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 19 (0x13) hwirq 38 (0x26)
> tangox_setup_irq_route(): route irq 38 (@ 0xf006f898) => irq 22
> tangox_irq_mux_domain_translate(): domain 0xcf805000
> tangox_irq_mux_domain_translate(): hwirq 67 (0x43) type 4 (0x4)
> tangox_irq_mux_domain_alloc(): domain 0xcf805000, virq 20 (0x14) nr_irqs 1
> tangox_allocate_gic_irq(): domain 0xcf805000, virq 20 (0x14) hwirq 67 (0x43)
> tangox_setup_irq_route(): route irq 67 (@ 0xf006f90c) => irq 21
> 
> Since irq-tango_v2.c is similar to irq-crossbar.c from TI (since it
> is based on it), I was wondering what is the policy or recommendation
> in such cases?
> Should I attempt to merge the code (mainly the way to set up the
> registers) on irq-crossbar.c or should we consider irq-tango_v2.c to
> live its own life?

If the HW is significantly different, I'd rather have a separate driver.
We can always share some things later on by having a small library of
"stuff".

> NOTE: IMHO, irq-crossbar.c could benefit from clearer names for some
> DT properties, because "max_irqs" and "max-crossbar-sources" are not
> straight forward names for "mux_outputs" and "mux_inputs"
> (respectively)

Maybe, but this ship has sailed a long time ago. This is an ABI now, and
it is not going to change unless proven to be broken. On the other hand,
you can name your own properties as you see fit.

> NOTE2: current irq-tango_v2.c code still has a 24 IRQ limitation
> since it is not using any API that would allow it to setup IRQ
> sharing.

Unless you limit your mux level interrupts only, I cannot see how you
could deal with cascaded interrupts. By the time you receive an edge,
the line will have dropped, and you won't be able to identify the source
interrupt.

Thanks,

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

[PATCH] Staging: comedi: pcmuio: fix bare use of 'unsigned'

[Ravishankar Karkala Mallikarjunayya]

This fixes up a WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/pcmuio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/pcmuio.c 
b/drivers/staging/comedi/drivers/pcmuio.c
index 7ea8130..8ad64f2 100644
--- a/drivers/staging/comedi/drivers/pcmuio.c
+++ b/drivers/staging/comedi/drivers/pcmuio.c
@@ -307,7 +307,7 @@ static void pcmuio_stop_intr(struct comedi_device *dev,
 
 static void pcmuio_handle_intr_subdev(struct comedi_device *dev,
  struct comedi_subdevice *s,
- unsigned triggered)
+ unsigned int triggered)
 {
struct pcmuio_private *devpriv = dev->private;
int asic = pcmuio_subdevice_to_asic(s);
-- 
1.9.1

RE: [Query] mwifiex: few observations to reduce number of endian conversions

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 17, 2016 6:42 PM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: Linux Kernel; Linux Next; WiFi Mailing List; Johannes Berg
> Subject: [Query] mwifiex: few observations to reduce number of endian
> conversions
> 
> Hi Amitkumar,
> 
> I have two observations:
> 
> 1. I have found that in the command response path for host command
> "HostCmd_CMD_802_11_EEPROM_ACCESS", a "0" value has been endian
> converted. It can only be a safe futuristic approach for any non-zero
> value there however! Otherwise, the endian conversion can be removed.
> 
> 2. For multiple Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS
> etc.) "cpu_to_leX"-converted values are saved to driver. So "leX_to_cpu"
> conversion is required too many times afterwards in driver.
> On the contrary, we can save the values to driver without any
> conversion, and only command buffer(s) are prepared with endian
> converted values. In this way we can gain some efficiency [code size /
> time] by reducing the number of endian conversion considerably.
> 

I agree with your observations. We'll prepare a cleanup patch to address this.

Regards,
Amitkumar

[PATCH] ARM: AM33xx: PRM: Remove wrongly defined RSTST offset for PER Domain

[Keerthy]

As per the TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
offset 0x4 is reserved for PRM_PER. Hence removing the wrongly
defined address offset.

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/prm33xx.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 2bc4ec5..66302c6 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -52,8 +52,6 @@
 /* PRM.PER_PRM register offsets */
 #define AM33XX_RM_PER_RSTCTRL_OFFSET   0x
 #define AM33XX_RM_PER_RSTCTRL  
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x)
-#define AM33XX_RM_PER_RSTST_OFFSET 0x0004
-#define AM33XX_RM_PER_RSTST
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004)
 #define AM33XX_PM_PER_PWRSTST_OFFSET   0x0008
 #define AM33XX_PM_PER_PWRSTST  
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008)
 #define AM33XX_PM_PER_PWRSTCTRL_OFFSET 0x000c
-- 
1.9.1

Re: [GIT PULL 00/10] perf/core improvements and fixes

[Paolo Bonzini]

On 21/06/2016 05:11, Brendan Gregg wrote:
>>> > > - Add stackcollapse.py script to help generating flame graphs (Paolo 
>>> > > Bonzini)
>> >
>> > I think this is already done by '-g folded'.  Please see:
>> >
>> >   http://www.brendangregg.com/blog/2016-04-30/linux-perf-folded.html
>> >
> Pretty much. Two similar solutions were developed around the same
> time. Although I have to use some awk to get "perf -g folded" in the
> exact right format, and stackcollapse-perf.py does that directly.

Yes, the idea for stackcollapse-perf.py was:

- to do everything directly and emit "the right" format for the
flamegraph tools.  This however is a very minimal output, and it's not
necessarily the best for perf in general.

- to provide an example of visiting callgraphs from the scripting
interface, since it's not really documented.  From the commit message:
"Add stackcollapse.py script as an example of parsing call chains, and
also of using optparse to access command line options".

Paolo

[PATCH] MAINTAINERS: update STi maintainer list

[Maxime Coquelin]

Remove myself as STi maintainer as I will no longer have access to
STi platforms, and remove Srini too, who now works on other
platforms.

Patrice will manage the pull requests.

Signed-off-by: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Srinivas Kandagatla 
Cc: Arnd Bergmann 
---
 MAINTAINERS | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..1ea14565d9d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1689,8 +1689,6 @@ S:Maintained
 F: drivers/edac/altera_edac.
 
 ARM/STI ARCHITECTURE
-M: Srinivas Kandagatla 
-M: Maxime Coquelin 
 M: Patrice Chotard 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: ker...@stlinux.com
-- 
1.9.1

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

[Szabolcs Nagy]

On 21/06/16 06:06, Yury Norov wrote:
> From: Andrew Pinski 
> 
> NOTE This is an ABI change for AARCH64.
> If you have some AARCH32 and AARCH64 applications and they both use
> utmp, one of them will fail due to the use of time_t inside the
> utmp binary format.
> 
> This fixes the problem by setting __WORDSIZE_TIME64_COMPAT32.

i think changing the abi now is not ok.

this is BZ 17470 and i think it should be discussed separately
from ilp32.

if it's possible to detect the utmp file format, that would
allow a reasonable fix, the way glibc changes the struct def
based on lp64 targets is non-conforming.

Re: [LKP] [lkp] [x86 tsc] 19fa5e7364: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x72/0x80

[Paolo Bonzini]

On 21/06/2016 08:08, Wanpeng Li wrote:
> Cc KVM ML, Paolo, Radim,
>>> FYI, raw QEMU command line is:
>>>
>>> qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
>>> /pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
>>>  -append 'root=/dev/ram0 user=lkp 
>>> job=/lkp/scheduled/vm-kbuild-yocto-x86_64-32/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-w0-06180628-19fa5e73647fde1e6a7038a8f05cddf4c43f08d3-20160618-25535-h82bax-0.yaml~
>>>  ARCH=x86_64 kconfig=x86_64-randconfig-w0-06180628 
>>> branch=internal-eywa/master commit=19fa5e73647fde1e6a7038a8f05cddf4c43f08d3 
>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
>>>  max_uptime=600 
>>> RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/0
>>>  LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug 
>>> apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
>>> softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
>>> prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
>>> ip=vm-kbuild-yocto-x86_64-32::dhcp drbd.minor_count=8'  -initrd 
>>> /fs/sdh1/initrd-vm-kbuild-yocto-x86_64-32 -m 320 -smp 1 -device 
>>> e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
>>> i6300esb -rtc base=localtime -drive 
>>> file=/fs/sdh1/disk0-vm-kbuild-yocto-x86_64-32,media=disk,if=virtio -pidfile 
>>> /dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-32 -serial 
>>> file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-32 -daemonize -display 
>>> none -monitor null
>>>
>> This  problem was caused due to kvm does not support MSR_PLATFORM_INFO(0xce),
>> according to Wanpeng's feedback.
>>
>> Hi Wanpeng, is it possible for kvm to simulate this MSR, otherwise we
>> might have to use
>> rdmsr_safe instead.
> 
> There is a thread discussed this before
> https://patchwork.kernel.org/patch/8833021/, MSR_PLATFORM_INFO can't
> be simple emulation.
> 
> Ping Paolo, Radim. :)

rdmsr_safe must be used instead.  I'll prepare a patch.

Paolo

Re: cross compilers [was build failure of sorts]

[Vineet Gupta]

On Tuesday 21 June 2016 03:15 PM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 09:28:56AM +, Vineet Gupta wrote:
>> On Tuesday 21 June 2016 01:13 PM, Peter Zijlstra wrote:
>>> On Tue, Jun 21, 2016 at 05:29:28AM +, Vineet Gupta wrote:
> On Saturday 18 June 2016 03:47 PM, Peter Zijlstra wrote:
>>> As you can see, arc doesn't even build upstream binutils :/
>>> (binutils-2_26-branch as of today).
>
> Hmm - we are still in fight w.r.t. upstreaming gcc fully (ARCv2 gcc 
> support)
> although ARCompact has been there for some time. binutils upstream should 
> work -
> I'll check why the buildall stuff fails.
>>> I can run that build again and send you the resulting log files in
>>> private.
>>
>> Thx for the off-list log. The issue is gdb not yet upstream. So it seems we 
>> will
>> have to wait for things on upstreaming to settle down before I can formally 
>> update
>> segher's scripts to support ARC.
> 
> Ah, lemme add --disable-gdb to the binutils build.

Right - that works around gdb, but gcc upstream still has partial support for
ARCv2 with patches being reviewed very slwly by the old ARC port maintainer.
You could give it a try though !

> Should arc-*-* list gdb in their noconfigdirs like many other archs do
> too?

Yeah indeed that chould be done while gdb upstream is waiting. @Anton can we do
that - update binutils/configure.ac to not configure gdb for ARC.

Re: [PATCH v2] tty: serial: msm: Don't reconfigure same baud rate

[Nicolas Dechesne]

On Fri, Jun 17, 2016 at 1:02 PM, Nicolas Dechesne
 wrote:
>  wrote:
>> msm_set_termios() is called whenever the tty is opened. Setting the baud
>> rate requires a full reset of the msm serial block, even when the rate
>> is unchanged. In the case when the same uart is used as console this
>> reset will discard any console output data still being clocked out of
>> the TX fifo.
>>
>> By skipping the rate-change in the case where the baud rate is unchanged
>> since last request we can avoid the reset and the discarding of the
>> data.
>>
>> Signed-off-by: Bjorn Andersson 
>
>
> Tested-by: Nicolas Dechesne 
>
> I no longer see this type of corruption on serial console
>
> [6.325118] ALSA device �[6.38] Freeing unused kernel
> memory: 572K (ffc000c1 - ffc000c9f000)
> [   13.800269]  remoteproc2: remote processor a20400�[  OK  ] Started
> Start the WCN core.
> [ � Starting Update UTMP about System Runlevel Changes...


oops. today i tried on APQ8064 boards , both IFC6410Plus and SD
600eval, and I can no longer 'type' into the serial console, I can get
debug messages though. Reverting this change 'fixes' the problem.

Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

[Jean-Francois Moine]

On Tue,  7 Jun 2016 22:41:39 +0200
Maxime Ripard  wrote:

> The current code has been tested on the H3 and an Orange Pi PC,
> including making sure that MMC still works, so the general approach
> seems ok.
> 
> Let me know what you think,

Hi Maxime,

I used your code in both the H3 and A83T, and it worked fine for the
current clocks.

But I had some problems with some features as the 'mode select' in the
A83T MMC2 clock.
Also, I think that you did not go far enough in the changes.
For example, most clock gates as well as most resets could be removed
from the DT and automatically set/de-asserted on clock prepare or clock
enable.

So, I am rewriting a generic sunxi clock driver into one file (about
1000 lines) and I have the full (simpler and clearer) description of
the H3 and the A863T clocks.

Coding is not finished yet. I will submit a RFC as soon as I will have
something working.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[RFC PATCH v2 2/9] dt-bindings: mailbox: Add Amlogic Meson MHU Bindings

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/mailbox/meson-mhu.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt

diff --git a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt 
b/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
new file mode 100644
index 000..4a80b44
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
@@ -0,0 +1,33 @@
+Amlogic Meson MHU Mailbox Driver
+
+
+The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
+that has 2 independent channels/links to communicate with remote processor(s).
+MHU links are hardwired on a platform. A link raises interrupt for any
+received data. However, there is no specified way of knowing if the sent
+data has been read by the remote. This driver assumes the sender polls
+STAT register and the remote clears it after having read the data.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible:  Shall be "amlogic,meson-gxbb-mhu"
+- reg: Contains the mailbox register address range (base
+   address and length)
+- #mbox-cells  Shall be 1 - the index of the channel needed.
+- interrupts:  Contains the interrupt information corresponding to
+   each of the 2 links of MHU.
+
+Example:
+
+
+   mailbox: mailbox@c883c400 {
+   #mbox-cells = <1>;
+   compatible = "amlogic,meson-gxbb-mhu";
+   reg = <0 0xc883c400 0 0x4c>;
+   interrupts = <0 209 IRQ_TYPE_EDGE_RISING>,
+  <0 210 IRQ_TYPE_EDGE_RISING>;
+   #mbox-cells = <1>;
+   };
-- 
2.7.0

Re: [RFC 0/8] usb: phy: msm: various cleanups

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> I stumbled over this warning last week, which showed up after I had
> removed an incorrect patch from my randconfig build setup:
>
> drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_probe':
> drivers/usb/phy/phy-msm-usb.c:1735:14: error: 'regs[0].consumer' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   motg->vddcx = regs[0].consumer;
>   ^~
> drivers/usb/phy/phy-msm-usb.c:1736:14: error: 'regs[1].consumer' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   motg->v3p3  = regs[1].consumer;
>   ^~
> drivers/usb/phy/phy-msm-usb.c:1737:14: error: 'regs[2].consumer' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   motg->v1p8  = regs[2].consumer;
>   ^~
>
> Having already fixed the same problem in the phy-qcom-8x16-usb.c
> driver before, I tried to do the same thing here, but it turned
> out to be somewhat different, and I ended up running into several
> unrelated issues in the driver that I now try to fix up.
>
> The series is not tested beyond verifying that it no longer causes
> randconfig warnings, and some patches are not entirely obvious.
> In particular the ehci-msm and chipidea changes are probably a
> good idea, but they actually change the behavior of the drivers
> in a way that I cannot verify through inspection alone. The
> last patch in the series probably requires some changes to the
> devicetree files to go along with it.
>
> Please have a look and test this, provided the patches make sense
> conceptually.
>
>   Arnd
>
> Arnd Bergmann (8):
>   usb: phy: move msm_hsusb.h into driver
>   usb: ehci-msm: call usb_phy_init instead of open-coding it
>   usb: chipidea: msm: remove open-coded phy init
>   usb: phy: move TCSR driver into new file
>   usb: phy: msm: move register definitions into driver
>   usb: phy: qcom: use bulk regulator interfaces
>   usb: phy: msm: remove v1p8/v3p3 voltage setting
>   usb: phy: msm: disable regulator for remove()

I managed to apply a few of these. Some didn't apply. If you can rebase
on my testing/next and fix comments, then I can apply the rest.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] ARM: AM43XX: hwmod: Fix RSTST register offset for pruss

[Keerthy]

On Tuesday 21 June 2016 01:22 PM, Mohammed, Afzal wrote:

Hi Suman,

Anna, Suman wrote on Monday, June 20, 2016 9:49 PM:


It does happen when the pruss module is exercised. We found this when we
tried to do a standby test on suspend, and while it worked on AM33xx,
AM437x failed because of this difference.


Okay, seems on am335x, PER doesn't have RSTST register itself.


Seems like code has some reference!

arch/arm/mach-omap2/prm33xx.h
#define AM33XX_RM_PER_RSTST_OFFSET  0x0004

But TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
claims that offset is reserved.

Should i remove the above lines altogether?



Regards
afzal

Re: [PATCH v2 1/3] Documentation: DT: Add iproc-static-adc binding

[Raveendra Padasalagi]

Hi Rob,

Please find my reply inline.

Regards,
Raveendra

On Mon, Jun 20, 2016 at 11:34 PM, Rob Herring  wrote:
> On Sun, Jun 19, 2016 at 03:36:28PM +0530, Raveendra Padasalagi wrote:
>> The patch adds devicetree binding document for broadcom's
>> iproc-static-adc controller driver.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../bindings/iio/adc/brcm,iproc-static-adc.txt | 43 
>> ++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt 
>> b/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt
>> new file mode 100644
>> index 000..1de0dfa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt
>> @@ -0,0 +1,43 @@
>> +* Broadcom's IPROC Static ADC controller
>> +
>> +Required properties:
>> +
>> +- compatible: Must be "brcm,iproc-static-adc"
>> +
>
>> +- #address-cells: Specify the number of u32 entries needed in child nodes.
>> +  Should set to 1.
>> +
>> +- #size-cells: Specify number of u32 entries needed to specify child nodes 
>> size
>> +  in reg property. Should set to 1.
>
> Why are these needed? What child nodes can you have?

Yes, these are not needed. ADC can't have any child nodes.

I will fix it in the next patch. Thanks.

>> +
>> +- adc-syscon: Handler of syscon node defining physical base address of the
>> +  controller and length of memory mapped region.
>> +
>> +- #io-channel-cells = <1>; As ADC has multiple outputs
>> +  refer to Documentation/devicetree/bindings/iio/iio-bindings.txt for 
>> details.
>> +
>> +- clocks: Clock used for this block.
>> +
>> +- clock-names: Clock name should be given as tsc_clk.
>> +
>> +- interrupts: interrupt line number.
>> +
>> +For example:
>> +
>> + ts_adc_syscon: ts_adc_syscon@180a6000 {
>> + compatible = "brcm,iproc-ts-adc-syscon","syscon";
>> + reg = <0x180a6000 0xc30>;
>> + };
>> +
>> + adc: adc@180a6000 {
>> + compatible = "brcm,iproc-static-adc";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + adc-syscon = <&ts_adc_syscon>;
>> + #io-channel-cells = <1>;
>> + io-channel-ranges;
>> + clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
>> + clock-names = "tsc_clk";
>> + interrupts = ;
>> + status = "disabled";
>> + };
>> --
>> 1.9.1
>>

[RFC PATCH v2 1/9] mailbox: Add Amlogic Meson Message-Handling-Unit

[Neil Armstrong]

Add Amlogic Meson SoCs Message-Handling-Unit as mailbox controller
with 2 independent channels/links to communicate with a remote processor.

Signed-off-by: Neil Armstrong 
---
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/meson_mhu.c | 199 
 2 files changed, 201 insertions(+)
 create mode 100644 drivers/mailbox/meson_mhu.c

diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 0be3e74..6aa9dbe 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -25,3 +25,5 @@ obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o
 obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
 
 obj-$(CONFIG_HI6220_MBOX)  += hi6220-mailbox.o
+
+obj-$(CONFIG_ARCH_MESON)   += meson_mhu.o
diff --git a/drivers/mailbox/meson_mhu.c b/drivers/mailbox/meson_mhu.c
new file mode 100644
index 000..0576b92
--- /dev/null
+++ b/drivers/mailbox/meson_mhu.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2016 BayLibre SAS.
+ * Author: Neil Armstrong 
+ * Heavily based on meson_mhu.c from :
+ * Copyright (C) 2013-2015 Fujitsu Semiconductor Ltd.
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Jassi Brar 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INTR_SET_OFS   0x0
+#define INTR_STAT_OFS  0x4
+#define INTR_CLR_OFS   0x8
+
+#define MHU_LP_OFFSET  0x10
+#define MHU_HP_OFFSET  0x1c
+
+#define TX_REG_OFFSET  0x24
+
+#define MHU_CHANS  2
+
+struct meson_mhu_link {
+   unsigned int irq;
+   void __iomem *tx_reg;
+   void __iomem *rx_reg;
+};
+
+struct meson_mhu {
+   void __iomem *base;
+   struct meson_mhu_link mlink[MHU_CHANS];
+   struct mbox_chan chan[MHU_CHANS];
+   struct mbox_controller mbox;
+};
+
+static irqreturn_t meson_mhu_rx_interrupt(int irq, void *p)
+{
+   struct mbox_chan *chan = p;
+   struct meson_mhu_link *mlink = chan->con_priv;
+   u32 val;
+
+   val = readl_relaxed(mlink->rx_reg + INTR_STAT_OFS);
+   if (!val)
+   return IRQ_NONE;
+
+   mbox_chan_received_data(chan, (void *)&val);
+
+   writel_relaxed(~0, mlink->rx_reg + INTR_CLR_OFS);
+
+   return IRQ_HANDLED;
+}
+
+static bool meson_mhu_last_tx_done(struct mbox_chan *chan)
+{
+   struct meson_mhu_link *mlink = chan->con_priv;
+   u32 val = readl_relaxed(mlink->tx_reg + INTR_STAT_OFS);
+
+   return (val == 0);
+}
+
+static int meson_mhu_send_data(struct mbox_chan *chan, void *data)
+{
+   struct meson_mhu_link *mlink = chan->con_priv;
+   u32 *arg = data;
+
+   writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
+
+   return 0;
+}
+
+static int meson_mhu_startup(struct mbox_chan *chan)
+{
+   struct meson_mhu_link *mlink = chan->con_priv;
+   int ret;
+
+   ret = request_irq(mlink->irq, meson_mhu_rx_interrupt,
+ IRQF_ONESHOT, "meson_mhu_link", chan);
+   if (ret) {
+   dev_err(chan->mbox->dev,
+   "Unable to acquire IRQ %d\n", mlink->irq);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void meson_mhu_shutdown(struct mbox_chan *chan)
+{
+   struct meson_mhu_link *mlink = chan->con_priv;
+
+   free_irq(mlink->irq, chan);
+}
+
+static const struct mbox_chan_ops meson_mhu_ops = {
+   .send_data = meson_mhu_send_data,
+   .startup = meson_mhu_startup,
+   .shutdown = meson_mhu_shutdown,
+   .last_tx_done = meson_mhu_last_tx_done,
+};
+
+static int meson_mhu_probe(struct platform_device *pdev)
+{
+   int i, err;
+   struct meson_mhu *mhu;
+   struct device *dev = &pdev->dev;
+   struct resource *res;
+   int meson_mhu_reg[MHU_CHANS] = {MHU_LP_OFFSET, MHU_HP_OFFSET};
+
+   /* Allocate memory for device */
+   mhu = devm_kzalloc(dev, sizeof(*mhu), GFP_KERNEL);
+   if (!mhu)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mhu->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mhu->base)) {
+   dev_err(dev, "ioremap failed\n");
+   return PTR_ERR(mhu->base);
+   }
+
+   for (i = 0; i < MHU_CHANS; i++) {
+   mhu->chan[i].con_priv = &mhu->mlink[i];
+   mhu->mlink[i].irq = platform_get_irq(pdev, i);
+   if (mhu->mlink[i].irq < 0) {
+   dev_err(dev, "failed to get irq%d\n", i);
+   return mhu->mlink[i].irq;
+   }
+   mhu->

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Joerg Roedel]

On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> Add the dtsi node of iommu and smi for mt2701.
> 
> Signed-off-by: Honghui Zhang 
> ---
>  arch/arm/boot/dts/mt2701.dtsi | 51 
> +++
>  1 file changed, 51 insertions(+)

Okay, I pushed my arm/mediatek branch to my tree at

git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git

Please base the patch on that branch and re-send.

Thanks,

Joerg

Re: 答复: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[Takashi Iwai]

On Tue, 21 Jun 2016 11:57:28 +0200,
高峰 wrote:
> 
> Oh, I get it.
> 
> I met the compile error when compile the kernel 3.10 on CentOS7 and fix it, 
> then I find the seq_device of upstream is same.
> So I thought it should be fixed.
> 
> OK. Let me compile the upstream codes on CentOS7 again.

Well, I see a potential problem even in the upstream, but it's only
when CONFIG_LTO is set.  However, CONFIG_LTO isn't used any other
places (or even set) in the upstream tree yet, so the issue must not
happen there.

And yet, even if CONFIG_LTO is enabled, the first place to be fixed is
rather in include/linux/init.h, not each code calling module_init()
without a terminator semicolon.  There are lots of such codes in the
tree, and calls of init/exit without semicolon are official ways.

Though, having semicolons looks nicer nowadays, so it'd make sense to
add semicolons in the end.  If so, we may fix all of them in a shot by
a script.


Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de] 
> 发送时间: 2016年6月21日 17:54
> 收件人: 高峰 
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> 主题: Re: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 11:35:39 +0200,
> 高峰 wrote:
> > 
> > I have sent the new commit with the compile errors.
> > Is it ok now?
> > 
> > BTW, I think the compile error is caused by that "subsys_initcall" 
> > statement losts the semicolon. 
> 
> Does this happen with the latest upstream kernel code at all...?
> 
> 
> Takashi
> 
> > 
> > -邮件原件-
> > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > 发送时间: 2016年6月21日 17:20
> > 收件人: 高峰 
> > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> > linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> > 主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > 
> > On Tue, 21 Jun 2016 10:48:30 +0200,
> > 高峰 wrote:
> > > 
> > > The lastest CentOS7 platform, and the gcc version is gcc version 
> > > 4.8.5
> > > 20150623 (Red Hat 4.8.5-4) (GCC).
> > > It could pass compilation after append the lost semicolon. 
> > > 
> > > from sound/core/seq/seq_device.c:39:
> > > include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
> > >   static exitcall_t __exitcall_##fn __exit_call = fn
> > >   ^
> > > include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
> > >  #define module_exit(x) __exitcall(x);
> > > ^
> > > sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> > > ‘module_exit’
> > >  module_exit(alsa_seq_device_exit)
> > >  ^
> > > make[3]: *** [sound/core/seq/seq_device.o] Error 1
> > > make[2]: *** [sound/core/seq] Error 2
> > > make[1]: *** [sound/core] Error 2
> > > make: *** [sound] Error 2
> > 
> > It's a RH specific issue.  The upstream code has a different definition of 
> > module_init(), thus no such an error would occur.
> > 
> > Note that I'm fine to apply the patch, it's a trivial change.
> > But you need to give the clear reason why to apply it.  In this case, it's 
> > no fault of the upstream code.  But if it would make someone's life a bit 
> > easier, it's OK to apply such a change.
> > 
> > That being said, please resubmit the patch with a more explanation.
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > 
> > > -邮件原件-
> > > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > > 发送时间: 2016年6月21日 16:45
> > > 收件人: f...@ikuai8.com
> > > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> > > org; gfree.w...@gmail.com
> > > 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > > 
> > > On Tue, 21 Jun 2016 10:34:25 +0200,
> > >  wrote:
> > > > 
> > > > From: Gao Feng 
> > > > 
> > > > Signed-off-by: Gao Feng 
> > > 
> > > What compile error did you get?
> > > 
> > > 
> > > Takashi
> > > 
> > > > ---
> > > >  sound/core/seq/seq_device.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/sound/core/seq/seq_device.c 
> > > > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > > > --- a/sound/core/seq/seq_device.c
> > > > +++ b/sound/core/seq/seq_device.c
> > > > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > > > bus_unregister(&snd_seq_bus_type);
> > > >  }
> > > >  
> > > > -subsys_initcall(alsa_seq_device_init)
> > > > -module_exit(alsa_seq_device_exit)
> > > > +subsys_initcall(alsa_seq_device_init);
> > > > +module_exit(alsa_seq_device_exit);
> > > > --
> > > > 1.9.1
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 

[RFC PATCH v2 5/9] firmware: scpi: Switch arm_scpi to use new registry

[Neil Armstrong]

Change the arm_scpi.c to use the registry layer instead of returning it's
context ->ops pointer.

Signed-off-by: Neil Armstrong 
---
 drivers/firmware/arm_scpi.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 7e3e595..ba6bc53 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -162,7 +162,6 @@ struct scpi_drvinfo {
u32 firmware_version;
int num_chans;
atomic_t next_chan;
-   struct scpi_ops *scpi_ops;
struct scpi_chan *channels;
struct scpi_dvfs_info *dvfs[MAX_DVFS_DOMAINS];
 };
@@ -526,7 +525,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct 
scpi_sensor_info *info)
return ret;
 }
 
-int scpi_sensor_get_value(u16 sensor, u64 *val)
+static int scpi_sensor_get_value(u16 sensor, u64 *val)
 {
__le16 id = cpu_to_le16(sensor);
struct sensor_value buf;
@@ -554,12 +553,6 @@ static struct scpi_ops scpi_ops = {
.sensor_get_value = scpi_sensor_get_value,
 };
 
-struct scpi_ops *get_scpi_ops(void)
-{
-   return scpi_info ? scpi_info->scpi_ops : NULL;
-}
-EXPORT_SYMBOL_GPL(get_scpi_ops);
-
 static int scpi_init_versions(struct scpi_drvinfo *info)
 {
int ret;
@@ -743,7 +736,10 @@ err:
  FW_REV_MAJOR(scpi_info->firmware_version),
  FW_REV_MINOR(scpi_info->firmware_version),
  FW_REV_PATCH(scpi_info->firmware_version));
-   scpi_info->scpi_ops = &scpi_ops;
+
+   ret = devm_scpi_ops_register(dev, &scpi_ops);
+   if (ret)
+   return ret;
 
ret = sysfs_create_groups(&dev->kobj, versions_groups);
if (ret)
-- 
2.7.0

Re: [PATCH] rxrpc: fix uninitialized variable use

[David Howells]

Arnd Bergmann  wrote:

> > I'm actually more tempted to put a BUG() in there because if any new family
> > support (say AF_INET6) is added, I want to make sure I catch all the places.
> 
> Makes sense. Do you want to do the patch yourself, or should I send
> a new one doing that?
> 
> Maybe WARN() would be better than BUG()? That would still get the attention
> it needs but not kill the process.

I can stick a WARN() into your patch.

David

[RFC PATCH v2 6/9] firmware: Add legacy SCPI protocol driver

[Neil Armstrong]

Add legacy SCPI driver based on the latest SCPI driver but modified to behave
like an earlier technology preview SCPI implementation that at least the
Amlogic GXBB ARMv8 based platform uses in it's SCP firmware implementation.

The main differences between the mainline, public and recommended SCPI
implementation are :
 - virtual channels is not implemented
 - command word is passed by the MHU instead of the virtual channel ID
 - uses "sender id" in the command word for each commands groups
 - payload size shift in command word is different
 - command word is not in SRAM, so command queuing is not possible
 - command indexes are different
 - command data structures differs
 - commands are redirected to low or high priority channels by their indexes, 
   so round-robin redirection is not possible

A clear disclaimer is added to make it clear this implementation should not
be used for new products and is only here to support already released SoCs.

Signed-off-by: Neil Armstrong 
---
 drivers/firmware/Kconfig   |  20 ++
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/legacy_scpi.c | 644 +
 3 files changed, 665 insertions(+)
 create mode 100644 drivers/firmware/legacy_scpi.c

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 95b01f4..b9c2a33 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -31,6 +31,26 @@ config ARM_SCPI_PROTOCOL
  This protocol library provides interface for all the client drivers
  making use of the features offered by the SCP.
 
+config LEGACY_SCPI_PROTOCOL
+   bool "Legacy System Control and Power Interface (SCPI) Message Protocol"
+   default y if ARCH_MESON
+   select ARM_SCPI_FW
+   help
+ System Control and Power Interface (SCPI) Message Protocol is
+ defined for the purpose of communication between the Application
+ Cores(AP) and the System Control Processor(SCP). The MHU peripheral
+ provides a mechanism for inter-processor communication between SCP
+ and AP.
+
+ SCP controls most of the power managament on the Application
+ Processors. It offers control and management of: the core/cluster
+ power states, various power domain DVFS including the core/cluster,
+ certain system clocks configuration, thermal sensors and many
+ others.
+
+ This protocol library provides interface for all the client drivers
+ making use of the features offered by the legacy SCP protocol.
+
 config EDD
tristate "BIOS Enhanced Disk Drive calls determine boot disk"
depends on X86
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index b697462..c2cac9c 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -4,6 +4,7 @@
 obj-$(CONFIG_ARM_PSCI_FW)  += psci.o
 obj-$(CONFIG_SCPI_FW)  += scpi.o
 obj-$(CONFIG_ARM_SCPI_PROTOCOL)+= arm_scpi.o
+obj-$(CONFIG_LEGACY_SCPI_PROTOCOL) += legacy_scpi.o
 obj-$(CONFIG_DMI)  += dmi_scan.o
 obj-$(CONFIG_DMI_SYSFS)+= dmi-sysfs.o
 obj-$(CONFIG_EDD)  += edd.o
diff --git a/drivers/firmware/legacy_scpi.c b/drivers/firmware/legacy_scpi.c
new file mode 100644
index 000..4bd3ff7
--- /dev/null
+++ b/drivers/firmware/legacy_scpi.c
@@ -0,0 +1,644 @@
+/*
+ * Legacy System Control and Power Interface (SCPI) Message Protocol driver
+ *
+ * SCPI Message Protocol is used between the System Control Processor(SCP)
+ * and the Application Processors(AP). The Message Handling Unit(MHU)
+ * provides a mechanism for inter-processor communication between SCP's
+ * Cortex M3 and AP.
+ *
+ * SCP offers control and management of the core/cluster power states,
+ * various power domain DVFS including the core/cluster, certain system
+ * clocks configuration, thermal sensors and many others.
+ *
+ * Copyright (C) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Heavily based on arm_scpi.c from :
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * 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 .
+ */
+
+/*
+ * DISCLAIMER
+ *
+ * This SCPI implementation is based on a technology preview release
+ * and new ARMv8 SoCs implementations should use the standard SCPI
+ * implementation as defined in the ARM DUI 0922G and implemented
+ * in the arm_scpi.c driver.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 

[RFC PATCH v2 9/9] ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes

[Neil Armstrong]

Add the vcpu DVFS clock, the SCPU shared SRAM and the SCPI sensors nodes.

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

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 913ba86..0f2596e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -61,6 +61,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+   clocks = <&scpi_dvfs 0>;
};
 
cpu1: cpu@1 {
@@ -68,6 +69,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+   clocks = <&scpi_dvfs 0>;
};
 
cpu2: cpu@2 {
@@ -75,6 +77,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+   clocks = <&scpi_dvfs 0>;
};
 
cpu3: cpu@3 {
@@ -82,6 +85,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+   clocks = <&scpi_dvfs 0>;
};
};
 
@@ -99,6 +103,28 @@
method = "smc";
};
 
+   scpi {
+   compatible = "amlogic,meson-gxbb-scpi";
+   mboxes = <&mailbox 0 &mailbox 1>;
+   shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+   clocks {
+   compatible = "arm,scpi-clocks";
+
+   scpi_dvfs: scpi_clocks@0 {
+   compatible = "arm,scpi-dvfs-clocks";
+   #clock-cells = <1>;
+   clock-indices = <0>;
+   clock-output-names = "vcpu";
+   };
+   };
+
+   scpi_sensors: sensors {
+   compatible = "arm,scpi-sensors";
+   #thermal-sensor-cells = <1>;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
#size-cells = <1>;
ranges = <0 0x0 0xc800 0x14000>;
+
+   cpu_scp_lpri: scp-shmem@0 {
+   compatible = "amlogic,meson-gxbb-scp-shmem";
+   reg = <0x13000 0x400>;
+   };
+
+   cpu_scp_hpri: scp-shmem@200 {
+   compatible = "amlogic,meson-gxbb-scp-shmem";
+   reg = <0x13400 0x400>;
+   };
};
 
cbus: cbus@c110 {
-- 
2.7.0

[RFC PATCH v2 7/9] dt-bindings: arm: Update arm,scpi bindings with Meson GXBB SCPI

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 313dabd..fe58212 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,7 @@ by Linux to initiate various system control and power 
operations.
 
 Required properties:
 
-- compatible : should be "arm,scpi"
+- compatible : should be "arm,scpi" or "amlogic,meson-gxbb-scpi"
 - mboxes: List of phandle and mailbox channel specifiers
  All the channels reserved by remote SCP firmware for use by
  SCPI message protocol should be specified in any order
@@ -60,7 +60,8 @@ A small area of SRAM is reserved for SCPI communication 
between application
 processors and SCP.
 
 Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno,
+   or "amlogic,meson-gxbb-sram" for Amlogic GXBB SoC.
 
 The rest of the properties should follow the generic mmio-sram description
 found in ../../sram/sram.txt
@@ -70,7 +71,8 @@ Each sub-node represents the reserved area for SCPI.
 Required sub-node properties:
 - reg : The base offset and size of the reserved area with the SRAM
 - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
-  shared memory on Juno platforms
+  shared memory on Juno platforms or
+  "amlogic,meson-gxbb-scp-shmem" for Amlogic GXBB SoC.
 
 Sensor bindings for the sensors based on SCPI Message Protocol
 --
-- 
2.7.0

[RFC PATCH v2 8/9] ARM64: dts: meson-gxbb: Add SRAM node

[Neil Armstrong]

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

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 77381d0..913ba86 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -124,6 +124,15 @@
#size-cells = <2>;
ranges;
 
+   sram: sram@c800 {
+   compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
+   reg = <0x0 0xc800 0x0 0x14000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0 0xc800 0x14000>;
+   };
+
cbus: cbus@c110 {
compatible = "simple-bus";
reg = <0x0 0xc110 0x0 0x10>;
-- 
2.7.0

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

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> host and peripheral roles, but we really don't want all the extra cost
>> >> of the OTG specification".
>> >> 
>> >
>> > That's what I thought before, but the request from the Marketing guy is
>> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> > see the SoC reference manual say "it supports HNP and SRP"?
>> >
>> > If there is no request, who else wants to implement so complicated FSM
>> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> 
>> I stand corrected :-)
>> 
>> So there is one user for this layer. And this user has its own role
>> control registers. I'm not convinced we need this large generic layer
>> for one user.
>> 
>
> You mean chipidea or dwc3? I have more comments below.

chipidea. From the point of OTG (or DRD) dwc3 is very
self-sufficient. HW itself tracks state machine, much like MUSB does.

>> >> > For the real use case, some Carplay platforms need it.
>> >> 
>> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> >> specification which is not OTG-compliant.
>> >> 
>> >
>> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>> > states to finish role swap.
>> 
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

For this, granted, you need the state machine if your HW doesn't
track it. This is a given. With only one user, however, perhaps
we don't need a generic layer. There are not enough different
setups to design a good enough generic layer. We will end up
with a pseudo-generic framework which is coupled with its only
user.

2. Dual-role support, without OTG compliance

In this case, you don't need a stack. All you need is a signal
to tell you state of ID pin and another to tell you state of
VBUS level. If you have those, you don't need to walk an OTG
state machine at all. You don't need any of those quirky OTG
timers, agreed?

Given the above, why would you even want to use a subset of OTG
state machine to implement something that's _usually_ as simple
as:

8<--
vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);


>> > Notice, it needs to swap role without disconnect cable.
>> 
>> right, I can swap role without changing cable, but that's not OTG. The
>> mechanism for that, AFAICT, is not HNP. I don't know details about
>> CarPlay because the spec isn't public, but my understanding is that
>> CarPlay doesn't rely on anything from OTG spec.
>
> Since it is non-public, I can't say much. Some flows of its role-swap
> refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> Specification. 
>
> But OTG FSM is not the only way, the platform which can do role-swap
> without disconnection can support it too.

Right, all you need for CarPlay is what I wrote above. You don't need
full OTG compliance for that, right?

>> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> >> > index f4fc0aa..1d74fb8 100644
>> >> >> > --- a/include/linux/usb/gadget.h
>> >> >> > +++ b/include/linux/usb/gadget.h
>> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >> >   * @in_epnum: last used in ep number
>> >> >> >   * @mA: last set mA value
>> >> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >> > core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > It may not be a real separate OTG controller. It can be a hardware part
>> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
>> >> > vbus
>> >> > ,id and other signals which are used for role swap.
>> >> 
>> >> That's already solved. EXTCON solved that years back and OMAP has been
>> >> using EXTCON to program its UTMI mailbox.
>> >> 
>> >
>> > No, that's not the same thing, it does not include the swap role.
>> 
>> Read your original comment:
>> 
>> "handle vbus, id and other signals which are *used for* role swap"
>> 
>> You didn't include role swap in your original comment. Semantics aside...
>> 
>> > Consider the use case the host driver is at host/ and udc driver is
>> > at gadget/udc, how to finish to role swap?
>> 
>> ... why does the source code placement matter? And what do you mean by
>> "finish role swap"?
>> 
>
> Well, it dep

Re: [PATCH] HID: i2c-hid: set power sleep before shutdown

[Jiri Kosina]

On Tue, 21 Jun 2016, ghzhong wrote:

> > > Some HW design is that the power to i2c hid device won't down
> > > after device shutdown. Also the i2c-hid driver do not send suspend
> > > cmd to the hid i2c device and disable its irq before shutdown.So
> > > if We touch the touchscreen or some other i2c hid device ,the power
> > > consumtion will be go up even when the device is in shutdown state.
> > Wow, that's a new one! Could you tell us which device board is behaving
> > that way (if not under NDA or such)
> Umaro, a chromebook model.

Could you please send me a v2 with updated changelog (specifying the model 
that is known to need this) and the free_irq() change?

Thanks,

-- 
Jiri Kosina
SUSE Labs

[RFC PATCH v2 3/9] ARM64: dts: meson-gxbb: Add Meson MHU Node

[Neil Armstrong]

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

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 806b903..77381d0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -315,6 +315,14 @@
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc883c000 0x0 0x2000>;
+
+   mailbox: mailbox@400 {
+   compatible = "amlogic,meson-gxbb-mhu";
+   reg = <0 0x400 0 0x4c>;
+   interrupts = <0 209 IRQ_TYPE_EDGE_RISING>,
+<0 210 IRQ_TYPE_EDGE_RISING>;
+   #mbox-cells = <1>;
+};
};
 
apb: apb@d000 {
-- 
2.7.0

[PATCH] net: ethernet: fix odd_ptr_err.cocci warnings

[Julia Lawall]

PTR_ERR should normally access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Tien Hock Loh 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

This patch refers to the following code:

url:
https://github.com/0day-ci/linux/commits/thloh-altera-com/net-ethernet-Add-T
SE-PCS-support-to-dwmac-socfpga/20160621-164854

 dwmac-socfpga.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -224,7 +224,7 @@ static int socfpga_dwmac_parse_data(stru
dev_err(dev,
"%s: ERROR: failed mapping tse control 
port\n",
__func__);
-   return PTR_ERR(dwmac->pcs.sgmii_adapter_base);
+   return PTR_ERR(dwmac->pcs.tse_pcs_base);
}
}
}

[RFC PATCH v2 4/9] firmware: Add a SCPI registry to handle multiple implementations

[Neil Armstrong]

Add a thin registry layer to store the current scpi_ops pointer out of the
arm_scpi.c location.
Add a register/unregister and devres managed unregister calls, and their
static inline disabled stubs.
Add the SCPI_FW config to enable the registry layer build.

Signed-off-by: Neil Armstrong 
---
 drivers/firmware/Kconfig  |  4 ++
 drivers/firmware/Makefile |  1 +
 drivers/firmware/scpi.c   | 94 +++
 include/linux/scpi_protocol.h | 15 ++-
 4 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/scpi.c

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6664f11..95b01f4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -8,9 +8,13 @@ menu "Firmware Drivers"
 config ARM_PSCI_FW
bool
 
+config SCPI_FW
+   bool
+
 config ARM_SCPI_PROTOCOL
tristate "ARM System Control and Power Interface (SCPI) Message 
Protocol"
depends on ARM_MHU
+   select SCPI_FW
help
  System Control and Power Interface (SCPI) Message Protocol is
  defined for the purpose of communication between the Application
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 474bada..b697462 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -2,6 +2,7 @@
 # Makefile for the linux kernel.
 #
 obj-$(CONFIG_ARM_PSCI_FW)  += psci.o
+obj-$(CONFIG_SCPI_FW)  += scpi.o
 obj-$(CONFIG_ARM_SCPI_PROTOCOL)+= arm_scpi.o
 obj-$(CONFIG_DMI)  += dmi_scan.o
 obj-$(CONFIG_DMI_SYSFS)+= dmi-sysfs.o
diff --git a/drivers/firmware/scpi.c b/drivers/firmware/scpi.c
new file mode 100644
index 000..87a559a
--- /dev/null
+++ b/drivers/firmware/scpi.c
@@ -0,0 +1,94 @@
+/*
+ * System Control and Power Interface (SCPI) Message Protocol registry
+ *
+ * SCPI Message Protocol is used between the System Control Processor(SCP)
+ * and the Application Processors(AP). The Message Handling Unit(MHU)
+ * provides a mechanism for inter-processor communication between SCP's
+ * Cortex M3 and AP.
+ *
+ * SCP offers control and management of the core/cluster power states,
+ * various power domain DVFS including the core/cluster, certain system
+ * clocks configuration, thermal sensors and many others.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct scpi_ops *g_ops;
+
+struct scpi_ops *get_scpi_ops(void)
+{
+   return g_ops;
+}
+EXPORT_SYMBOL_GPL(get_scpi_ops);
+
+int scpi_ops_register(struct scpi_ops *ops)
+{
+   if (!ops)
+   return -EINVAL;
+
+   if (g_ops)
+   return -EEXIST;
+
+   g_ops = ops;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(scpi_ops_register);
+
+void scpi_ops_unregister(struct scpi_ops *ops)
+{
+   if (g_ops == ops)
+   g_ops = NULL;
+}
+EXPORT_SYMBOL_GPL(scpi_ops_unregister);
+
+static void devm_scpi_ops_unregister(struct device *dev, void *res)
+{
+   scpi_ops_unregister(*(struct scpi_ops **)res);
+}
+
+int devm_scpi_ops_register(struct device *dev,
+   struct scpi_ops *ops)
+{
+   struct scpi_ops **rcops;
+   int ret;
+
+   rcops = devres_alloc(devm_scpi_ops_unregister, sizeof(*ops),
+GFP_KERNEL);
+   if (!rcops)
+   return -ENOMEM;
+
+   ret = scpi_ops_register(ops);
+   if (!ret) {
+   *rcops = ops;
+   devres_add(dev, rcops);
+   } else
+   devres_free(rcops);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_scpi_ops_register);
diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
index 35de50a..38c15d1 100644
--- a/include/linux/scpi_protocol.h
+++ b/include/linux/scpi_protocol.h
@@ -72,8 +72,21 @@ struct scpi_ops {
int (*sensor_get_value)(u16, u64 *);
 };
 
-#if IS_REACHABLE(CONFIG_ARM_SCPI_PROTOCOL)
+#if IS_REACHABLE(CONFIG_SCPI_FW)
 struct scpi_ops *get_scpi_ops(void);
+int scpi_ops_register(struct scpi_ops *drv);
+void scpi_ops_unregister(struct scpi_ops *drv);
+int devm_scpi_ops_register(struct device *dev, struct scpi_ops *drv);
 #else
 static inline struct scpi_ops *get_scpi_ops(void) { return NULL; }
+
+stati

Re: [PATCH v2 1/3] coccinelle: also catch kzfree() issues

[Michal Marek]

Dne 20.6.2016 v 22:21 Julia Lawall napsal(a):
> 
> 
> On Mon, 20 Jun 2016, Michal Marek wrote:
> 
>> On 2016-05-23 17:18, Julia Lawall wrote:
>>>
>>>
>>> On Mon, 23 May 2016, Yann Droneaud wrote:
>>>
 Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'),
 kfree() is no more the only function to be considered:
 kzfree() should be recognized too.

 In particular, kzfree() must not be called on memory
 allocated through devm_*() functions.

 Cc: Johannes Weiner 
 Signed-off-by: Yann Droneaud 
>>>
>>> Acked-by: Julia Lawall 
>>
>> Hi Julia,
>>
>> does your ACK apply to the other two patches as well?
> 
> Sorry, I seem to have missed the other two.  I have reviewed them now, and 
> the ack applies to all three.  Thanks for checking on it.

Np. Applied to kbuild.git#misc now.

Michal

Re: cross compilers [was build failure of sorts]

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 11:45:37AM +0200, Peter Zijlstra wrote:

> Should arc-*-* list gdb in their noconfigdirs like many other archs do
> too?

Something like so I suppose.

---
 configure.ac |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 4977d97..464eab5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1088,8 +1088,9 @@ case "${target}" in
   sh*-*-pe|mips*-*-pe|*arm-wince-pe)
 noconfigdirs="$noconfigdirs tcl tk itcl libgui sim"
 ;;
+# The arc target doesn't support gdb yet.
   arc-*-*|arceb-*-*)
-noconfigdirs="$noconfigdirs target-libgloss"
+noconfigdirs="$noconfigdirs gdb target-libgloss"
 ;;
   arm-*-pe*)
 noconfigdirs="$noconfigdirs target-libgloss"

[RFC PATCH v2 0/9] scpi: Add SCPI registry to handle legacy protocol

[Neil Armstrong]

This patchset aims to support the legacy SCPI firmware implementation that was
delivered as early technology preview for the JUNO platform.

Finally a stable, maintained and public implementation for the SCPI protocol
has been upstreamed part of the JUNO support and it is the recommended way
of implementing SCP communication on ARMv8 platforms.

The Amlogic GXBB platform is using this legacy protocol, as the RK3368 & RK3399
platforms. Only the GXBB example is provided here, but it's unclear if other
Amlogic ARMv8 based SoCs uses this legacy procotol.

In order to support the legacy protocol :
 - Move the scpi_get_ops to a thin registry layer
 - Change the arm_scpi.c to use the registry layer
 - Add a separate config option to build the registry layer
 - Add the legacy SCPI driver based on the new implementation
 - For example, add the Amlogic GXBB MHU and SCPI DT cpufreq & sensors nodes

Initial RFC discution tread can be found at https://lkml.org/lkml/2016/5/26/111

Neil Armstrong (9):
  mailbox: Add Amlogic Meson Message-Handling-Unit
  dt-bindings: mailbox: Add Amlogic Meson MHU Bindings
  ARM64: dts: meson-gxbb: Add Meson MHU Node
  firmware: Add a SCPI registry to handle multiple implementations
  firmware: scpi: Switch arm_scpi to use new registry
  firmware: Add legacy SCPI protocol driver
  dt-bindings: arm: Update arm,scpi bindings with Meson GXBB SCPI
  ARM64: dts: meson-gxbb: Add SRAM node
  ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes

 Documentation/devicetree/bindings/arm/arm,scpi.txt |   8 +-
 .../devicetree/bindings/mailbox/meson-mhu.txt  |  33 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|  53 ++
 drivers/firmware/Kconfig   |  24 +
 drivers/firmware/Makefile  |   2 +
 drivers/firmware/arm_scpi.c|  14 +-
 drivers/firmware/legacy_scpi.c | 644 +
 drivers/firmware/scpi.c|  94 +++
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/meson_mhu.c| 199 +++
 include/linux/scpi_protocol.h  |  15 +-
 11 files changed, 1075 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
 create mode 100644 drivers/firmware/legacy_scpi.c
 create mode 100644 drivers/firmware/scpi.c
 create mode 100644 drivers/mailbox/meson_mhu.c

-- 
2.7.0

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

[Jann Horn]

On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski  wrote:
> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
> vmalloc_node.
[...]
>  static struct thread_info *alloc_thread_info_node(struct task_struct *tsk,
>   int node)
>  {
> +#ifdef CONFIG_VMAP_STACK
> +   struct thread_info *ti = __vmalloc_node_range(
> +   THREAD_SIZE, THREAD_SIZE, VMALLOC_START, VMALLOC_END,
> +   THREADINFO_GFP | __GFP_HIGHMEM, PAGE_KERNEL,
> +   0, node, __builtin_return_address(0));
> +

After spender gave some hints on IRC about the guard pages not working
reliably, I decided to have a closer look at this. As far as I can
tell, the idea is that __vmalloc_node_range() automatically adds guard
pages unless the VM_NO_GUARD flag is specified. However, those guard
pages are *behind* allocations, not in front of them, while a stack
guard primarily needs to be in front of the allocation. This wouldn't
matter if all allocations in the vmalloc area had guard pages behind
them, but if someone first does some data allocation with VM_NO_GUARD
and then a stack allocation directly behind that, there won't be a
guard between the data allocation and the stack allocation.

(I might be wrong though; this is only from looking at the code, not
from testing it.)

Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Joerg Roedel]

On Wed, Jun 08, 2016 at 07:31:10PM +0100, Matthew Leach wrote:
> From: Ben Dooks 
> 
> Add initial support for big endian by always writing the pte
> in le32. Note, revisit if hardware capable of doing big endian
> fetches.
> 
> Signed-off-by: Ben Dooks 
> ---
> Cc: Marek Szyprowski 
> Cc: Joerg Roedel 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: io...@lists.linux-foundation.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org (open list)
> ---
>  drivers/iommu/exynos-iommu.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied, thanks.

答复: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[高峰]

Oh, I get it.

I met the compile error when compile the kernel 3.10 on CentOS7 and fix it, 
then I find the seq_device of upstream is same.
So I thought it should be fixed.

OK. Let me compile the upstream codes on CentOS7 again.

-邮件原件-
发件人: Takashi Iwai [mailto:ti...@suse.de] 
发送时间: 2016年6月21日 17:54
收件人: 高峰 
抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; 
gfree.w...@gmail.com
主题: Re: 答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

On Tue, 21 Jun 2016 11:35:39 +0200,
高峰 wrote:
> 
> I have sent the new commit with the compile errors.
> Is it ok now?
> 
> BTW, I think the compile error is caused by that "subsys_initcall" statement 
> losts the semicolon. 

Does this happen with the latest upstream kernel code at all...?


Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de]
> 发送时间: 2016年6月21日 17:20
> 收件人: 高峰 
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; 
> linux-kernel@vger.kernel.org; gfree.w...@gmail.com
> 主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 10:48:30 +0200,
> 高峰 wrote:
> > 
> > The lastest CentOS7 platform, and the gcc version is gcc version 
> > 4.8.5
> > 20150623 (Red Hat 4.8.5-4) (GCC).
> > It could pass compilation after append the lost semicolon. 
> > 
> > from sound/core/seq/seq_device.c:39:
> > include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
> >   static exitcall_t __exitcall_##fn __exit_call = fn
> >   ^
> > include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
> >  #define module_exit(x) __exitcall(x);
> > ^
> > sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> > ‘module_exit’
> >  module_exit(alsa_seq_device_exit)
> >  ^
> > make[3]: *** [sound/core/seq/seq_device.o] Error 1
> > make[2]: *** [sound/core/seq] Error 2
> > make[1]: *** [sound/core] Error 2
> > make: *** [sound] Error 2
> 
> It's a RH specific issue.  The upstream code has a different definition of 
> module_init(), thus no such an error would occur.
> 
> Note that I'm fine to apply the patch, it's a trivial change.
> But you need to give the clear reason why to apply it.  In this case, it's no 
> fault of the upstream code.  But if it would make someone's life a bit 
> easier, it's OK to apply such a change.
> 
> That being said, please resubmit the patch with a more explanation.
> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > -邮件原件-
> > 发件人: Takashi Iwai [mailto:ti...@suse.de]
> > 发送时间: 2016年6月21日 16:45
> > 收件人: f...@ikuai8.com
> > 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> > org; gfree.w...@gmail.com
> > 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> > 
> > On Tue, 21 Jun 2016 10:34:25 +0200,
> >  wrote:
> > > 
> > > From: Gao Feng 
> > > 
> > > Signed-off-by: Gao Feng 
> > 
> > What compile error did you get?
> > 
> > 
> > Takashi
> > 
> > > ---
> > >  sound/core/seq/seq_device.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/sound/core/seq/seq_device.c 
> > > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > > --- a/sound/core/seq/seq_device.c
> > > +++ b/sound/core/seq/seq_device.c
> > > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > >   bus_unregister(&snd_seq_bus_type);
> > >  }
> > >  
> > > -subsys_initcall(alsa_seq_device_init)
> > > -module_exit(alsa_seq_device_exit)
> > > +subsys_initcall(alsa_seq_device_init);
> > > +module_exit(alsa_seq_device_exit);
> > > --
> > > 1.9.1
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Honghui Zhang]

On Tue, 2016-06-21 at 11:41 +0200, Joerg Roedel wrote:
> On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Add the dtsi node of iommu and smi for mt2701.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 51 
> > +++
> >  1 file changed, 51 insertions(+)
> 
> Applied the series, except this last patch. It didn't apply cleanly and
> I was not sure how to correctly fix that. Can you please resubmit the
> patch based on my arm/mediatek branch once I pushed it?
> 

I will rebase this one later after your push.
Thanks.

> Thanks,
> 
>   Joerg
> 

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

[Netanel Belgazal]

On 06/21/2016 01:43 AM, Francois Romieu wrote:
> Netanel Belgazal  :
> [...]
>>> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h 
>>> b/drivers/net/ethernet/amazon/ena/ena_com.h
>>> new file mode 100644
>>> index 000..e49ba43
>>> --- /dev/null
>>> [...]
>>> +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg 
>>> *intr_reg,
>>> +  u32 rx_delay_interval,
>>> +  u32 tx_delay_interval,
>>> +  bool unmask)
>>> +{
>>> +   intr_reg->intr_control = 0;
>>> +   intr_reg->intr_control |= rx_delay_interval &
>>> +   ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>> +
>>> +   intr_reg->intr_control |=
>>> +   (tx_delay_interval << ENA_ETH_IO_INTR_REG_TX_INTR_DELAY_SHIFT)
>>> +   & ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>>   ^^ TX ?
>>>
>>> Extra: you should not return NETDEV_TX_BUSY in the xmit handler while
>>> queueing is still enabled. Please drop packet and return NETDEV_TX_OK.
>> Ack.
>>
>> Thanks for your review.
> Ack/nack regarding use of ..._RX_INTR_DELAY_MASK with ..._TX_INTR_DELAY_SHIFT 
> ?
You are right, it should have been TX_INTR_DELAY_SHIFT.
I'll fix that.

RE: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

[Zheng, Lv]

Hi, Mika

> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Subject: Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC
> support triggers dead lock in dynamic table loading
> 
> On Tue, Jun 21, 2016 at 12:34:15PM +0800, Lv Zheng wrote:
> > The new MLC approach invokes MLC per-table basis. But the dynamic
> loading
> > support of this is incorrect because of the lock order:
> >  acpi_ns_evaluate
> >acpi_ex_enter_intperter
> >  acpi_ns_load_table (triggered by Load opcode)
> >acpi_ns_exec_module_code_list
> >  acpi_ex_enter_intperter
> > The regression is introduced by the following commit:
> >   Commit: 2785ce8d0da1cac9d8f78615e116cf929e9a9123
> >   ACPICA Commit: 071eff738c59eda1792ac24b3b688b61691d7e7c
> >   Subject: ACPICA: Add per-table execution of module-level code
> > This patch fixes this regression by unlocking the interpreter lock before
> > invoking MLC. However the unlocking is done to the
> acpi_ns_load_table(), in
> > which, the interpreter lock should be locked by acpi_ns_parse_table()
> but
> > wasn't. Reported by Mika Westerberg. Fixed by Lv Zheng.
> >
> > Fixes: 2785ce8d0da1 ("ACPICA: Add per-table execution of module-level
> code")
> > Cc: Mika Westerberg 
> > Reported-by: Mika Westerberg 
> 
> Now builds fine and fixes the hang, thanks :)
> 
> Tested-by: Mika Westerberg 
[Lv Zheng] 
Great! :)
I'll leave the SOB correction for Rafael in order not to bother others by 
re-sending an update.

Thanks and best regards
-Lv

答复: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

[高峰]

I have sent the new commit with the compile errors.
Is it ok now?

BTW, I think the compile error is caused by that "subsys_initcall" statement 
losts the semicolon. 

-邮件原件-
发件人: Takashi Iwai [mailto:ti...@suse.de] 
发送时间: 2016年6月21日 17:20
收件人: 高峰 
抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; 
gfree.w...@gmail.com
主题: Re: 答复: [PATCH 1/1] sound: Fix compile error of seq_device.c

On Tue, 21 Jun 2016 10:48:30 +0200,
高峰 wrote:
> 
> The lastest CentOS7 platform, and the gcc version is gcc version 4.8.5
> 20150623 (Red Hat 4.8.5-4) (GCC).
> It could pass compilation after append the lost semicolon. 
> 
> from sound/core/seq/seq_device.c:39:
> include/linux/init.h:216:2: error: expected ‘,’ or ‘;’ before ‘static’
>   static exitcall_t __exitcall_##fn __exit_call = fn
>   ^
> include/linux/init.h:279:24: note: in expansion of macro ‘__exitcall’
>  #define module_exit(x) __exitcall(x);
> ^
> sound/core/seq/seq_device.c:315:1: note: in expansion of macro 
> ‘module_exit’
>  module_exit(alsa_seq_device_exit)
>  ^
> make[3]: *** [sound/core/seq/seq_device.o] Error 1
> make[2]: *** [sound/core/seq] Error 2
> make[1]: *** [sound/core] Error 2
> make: *** [sound] Error 2

It's a RH specific issue.  The upstream code has a different definition of 
module_init(), thus no such an error would occur.

Note that I'm fine to apply the patch, it's a trivial change.
But you need to give the clear reason why to apply it.  In this case, it's no 
fault of the upstream code.  But if it would make someone's life a bit easier, 
it's OK to apply such a change.

That being said, please resubmit the patch with a more explanation.


thanks,

Takashi

> 
> -邮件原件-
> 发件人: Takashi Iwai [mailto:ti...@suse.de]
> 发送时间: 2016年6月21日 16:45
> 收件人: f...@ikuai8.com
> 抄送: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.
> org; gfree.w...@gmail.com
> 主题: Re: [PATCH 1/1] sound: Fix compile error of seq_device.c
> 
> On Tue, 21 Jun 2016 10:34:25 +0200,
>  wrote:
> > 
> > From: Gao Feng 
> > 
> > Signed-off-by: Gao Feng 
> 
> What compile error did you get?
> 
> 
> Takashi
> 
> > ---
> >  sound/core/seq/seq_device.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/sound/core/seq/seq_device.c 
> > b/sound/core/seq/seq_device.c index c4acf17..4e859e4 100644
> > --- a/sound/core/seq/seq_device.c
> > +++ b/sound/core/seq/seq_device.c
> > @@ -311,5 +311,5 @@ static void __exit alsa_seq_device_exit(void)
> > bus_unregister(&snd_seq_bus_type);
> >  }
> >  
> > -subsys_initcall(alsa_seq_device_init)
> > -module_exit(alsa_seq_device_exit)
> > +subsys_initcall(alsa_seq_device_init);
> > +module_exit(alsa_seq_device_exit);
> > --
> > 1.9.1
> > 
> > 
> > 
> > 
> > 
> 
> 
> 

[PATCH] irqchip: fix the config HISILICON_IRQ_MBIGEN dependency error.

[Jiancheng Xue]

This patch fixes the compiling error caused when
config HISILICON_IRQ_MBIGEN is selected but
PCI_MSI is not seleted.

Signed-off-by: Jiancheng Xue 
---
 drivers/irqchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fa33c50..23dcf3e 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -110,7 +110,7 @@ config DW_APB_ICTL
 config HISILICON_IRQ_MBIGEN
bool
select ARM_GIC_V3
-   select ARM_GIC_V3_ITS
+   select ARM_GIC_V3_ITS if PCI_MSI
select GENERIC_MSI_IRQ_DOMAIN
 
 config IMGPDC_IRQ
-- 
1.9.1

Re: [PATCH v3 04/13] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

[Vladimir Davydov]

On Mon, Jun 20, 2016 at 04:43:34PM -0700, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone.  This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
> 
> Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
> allocations in a unit that divides both THREAD_SIZE and PAGE_SIZE on
> all architectures.  Keep it simple and use KiB.
> 
> Cc: Vladimir Davydov 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: linux...@kvack.org
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Vladimir Davydov 

[PATCH 1/2] ACPI / EC: Cleanup boot EC code using acpi_ec_alloc()

[Lv Zheng]

Failure handling of the boot EC code is not tidy. This patch cleans
them up with acpi_ec_alloc().
This patch also changes acpi_ec_dsdt_probe(), always switches the boot EC
from the ECDT one to the DSDT one in this function.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   85 ++---
 1 file changed, 48 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 73c76d6..f63a43a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1348,13 +1348,9 @@ static void ec_remove_handlers(struct acpi_ec *ec)
}
 }
 
-static int acpi_ec_add(struct acpi_device *device)
+static struct acpi_ec *acpi_ec_alloc(void)
 {
-   struct acpi_ec *ec = NULL;
-   int ret;
-
-   strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
-   strcpy(acpi_device_class(device), ACPI_EC_CLASS);
+   struct acpi_ec *ec;
 
/* Check for boot EC */
if (boot_ec) {
@@ -1365,9 +1361,21 @@ static int acpi_ec_add(struct acpi_device *device)
first_ec = NULL;
} else {
ec = make_acpi_ec();
-   if (!ec)
-   return -ENOMEM;
}
+   return ec;
+}
+
+static int acpi_ec_add(struct acpi_device *device)
+{
+   struct acpi_ec *ec = NULL;
+   int ret;
+
+   strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
+   strcpy(acpi_device_class(device), ACPI_EC_CLASS);
+
+   ec = acpi_ec_alloc();
+   if (!ec)
+   return -ENOMEM;
if (ec_parse_device(device->handle, 0, ec, NULL) !=
AE_CTRL_TERMINATE) {
kfree(ec);
@@ -1454,27 +1462,31 @@ static const struct acpi_device_id ec_device_ids[] = {
 int __init acpi_ec_dsdt_probe(void)
 {
acpi_status status;
+   struct acpi_ec *ec;
+   int ret;
 
-   if (boot_ec)
-   return 0;
-
+   ec = acpi_ec_alloc();
+   if (!ec)
+   return -ENOMEM;
/*
 * Finding EC from DSDT if there is no ECDT EC available. When this
 * function is invoked, ACPI tables have been fully loaded, we can
 * walk namespace now.
 */
-   boot_ec = make_acpi_ec();
-   if (!boot_ec)
-   return -ENOMEM;
status = acpi_get_devices(ec_device_ids[0].id,
- ec_parse_device, boot_ec, NULL);
-   if (ACPI_FAILURE(status) || !boot_ec->handle)
-   return -ENODEV;
-   if (!ec_install_handlers(boot_ec)) {
-   first_ec = boot_ec;
-   return 0;
+ ec_parse_device, ec, NULL);
+   if (ACPI_FAILURE(status) || !ec->handle) {
+   ret = -ENODEV;
+   goto error;
}
-   return -EFAULT;
+   ret = ec_install_handlers(ec);
+
+error:
+   if (ret)
+   kfree(ec);
+   else
+   first_ec = boot_ec = ec;
+   return ret;
 }
 
 #if 0
@@ -1548,12 +1560,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = 
{
 
 int __init acpi_ec_ecdt_probe(void)
 {
-   int ret = 0;
+   int ret;
acpi_status status;
struct acpi_table_ecdt *ecdt_ptr;
+   struct acpi_ec *ec;
 
-   boot_ec = make_acpi_ec();
-   if (!boot_ec)
+   ec = acpi_ec_alloc();
+   if (!ec)
return -ENOMEM;
/*
 * Generate a boot ec context
@@ -1583,22 +1596,20 @@ int __init acpi_ec_ecdt_probe(void)
 * MSI MS-171F
 * https://bugzilla.kernel.org/show_bug.cgi?id=12461
 */
-   boot_ec->command_addr = ecdt_ptr->data.address;
-   boot_ec->data_addr = ecdt_ptr->control.address;
+   ec->command_addr = ecdt_ptr->data.address;
+   ec->data_addr = ecdt_ptr->control.address;
} else {
-   boot_ec->command_addr = ecdt_ptr->control.address;
-   boot_ec->data_addr = ecdt_ptr->data.address;
+   ec->command_addr = ecdt_ptr->control.address;
+   ec->data_addr = ecdt_ptr->data.address;
}
-   boot_ec->gpe = ecdt_ptr->gpe;
-   boot_ec->handle = ACPI_ROOT_OBJECT;
-   ret = ec_install_handlers(boot_ec);
-   if (!ret)
-   first_ec = boot_ec;
+   ec->gpe = ecdt_ptr->gpe;
+   ec->handle = ACPI_ROOT_OBJECT;
+   ret = ec_install_handlers(ec);
 error:
-   if (ret) {
-   kfree(boot_ec);
-   boot_ec = NULL;
-   }
+   if (ret)
+   kfree(ec);
+   else
+   first_ec = boot_ec = ec;
return ret;
 }
 
-- 
1.7.10

[PATCH 2/2] ACPI / EC: Remove wrong ECDT correction quirks

[Lv Zheng]

Our Windows probe result shows that EC._REG is evaluated after evaluating
all _INI/_STA control methods.

With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as
long as there is no EC opregion accesses in the MLC (module level code, AML
code out of any control methods) and in _INI/_STA, there is no need to make
sure that ECDT must be correct.

Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA
evaluations contain EC accesses while the ECDT setting is wrong.

>From the acpidump output posted on bug 9399, we can see that it is actually
a different issue. In this table, if EC._REG is not executed, EC accesses
will be done in a platform specific manner. As we've already ensured not to
execute EC._REG during the eary stage, we can remove the quirks for bug
9399.

>From the acpidump output posted on bug 12461, we can see that it still
needs the quirk. In this table, EC._REG flags a named object whose default
value is One, thus BAT1._STA surely should invoke EC accesses whatever we
invoke EC._REG or not. We have to keep the quirk for it before we can root
cause the issue.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index f63a43a..b1050a0 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1530,6 +1530,11 @@ static int ec_clear_on_resume(const struct dmi_system_id 
*id)
return 0;
 }
 
+/*
+ * Some ECDTs contain wrong register addresses.
+ * MSI MS-171F
+ * https://bugzilla.kernel.org/show_bug.cgi?id=12461
+ */
 static int ec_correct_ecdt(const struct dmi_system_id *id)
 {
pr_debug("Detected system needing ECDT address correction.\n");
@@ -1539,16 +1544,6 @@ static int ec_correct_ecdt(const struct dmi_system_id 
*id)
 
 static struct dmi_system_id ec_dmi_table[] __initdata = {
{
-   ec_correct_ecdt, "Asus L4R", {
-   DMI_MATCH(DMI_BIOS_VERSION, "1008.006"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),
-   DMI_MATCH(DMI_BOARD_NAME, "L4R") }, NULL},
-   {
-   ec_correct_ecdt, "Asus M6R", {
-   DMI_MATCH(DMI_BIOS_VERSION, "0207"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "M6R"),
-   DMI_MATCH(DMI_BOARD_NAME, "M6R") }, NULL},
-   {
ec_correct_ecdt, "MSI MS-171F", {
DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star"),
DMI_MATCH(DMI_PRODUCT_NAME, "MS-171F"),}, NULL},
@@ -1590,12 +1585,6 @@ int __init acpi_ec_ecdt_probe(void)
 
pr_info("EC description table is found, configuring boot EC\n");
if (EC_FLAGS_CORRECT_ECDT) {
-   /*
-* Asus L4R, Asus M6R
-* https://bugzilla.kernel.org/show_bug.cgi?id=9399
-* MSI MS-171F
-* https://bugzilla.kernel.org/show_bug.cgi?id=12461
-*/
ec->command_addr = ecdt_ptr->data.address;
ec->data_addr = ecdt_ptr->control.address;
} else {
-- 
1.7.10

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Joerg Roedel]

On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> Add the dtsi node of iommu and smi for mt2701.
> 
> Signed-off-by: Honghui Zhang 
> ---
>  arch/arm/boot/dts/mt2701.dtsi | 51 
> +++
>  1 file changed, 51 insertions(+)

Applied the series, except this last patch. It didn't apply cleanly and
I was not sure how to correctly fix that. Can you please resubmit the
patch based on my arm/mediatek branch once I pushed it?

Thanks,

Joerg

Re: [PATCH] net: stmmac: dwmac-rk: add rk322x-specific data

[Heiko Stübner]

Am Dienstag, 21. Juni 2016, 15:13:55 schrieb Xing Zheng:
> Add constants and callback functions for the dwmac on rk322x socs.
> As can be seen, the base structure is the same, only registers and
> the bits in them moved slightly.
> 
> Signed-off-by: Xing Zheng 
> ---
> 
>  .../devicetree/bindings/net/rockchip-dwmac.txt |3 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c |  117
>  2 files changed, 119 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt index
> 93eac7c..5040ed4 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -3,7 +3,8 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
>  The device node has following properties.
> 
>  Required properties:
> - - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3368-gmac"
> + - compatible: Can be one of "rockchip,rk322x-gmac",

devicetree names are normally expected to be real, aka no "x" as catchall. So 
I guess either just add compatibles for both the rk3228 and rk3229 which point 
to the same structure in the driver. (So driver-side can stay as it is below, 
just add a second compatible).


> "rockchip,rk3288-gmac", +
> "rockchip,rk3368-gmac"
>   - reg: addresses and length of the register sets for the device.
>   - interrupts: Should contain the GMAC interrupts.
>   - interrupt-names: Should contain the interrupt names "macirq".
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index 0cd3ecf..7f045db
> 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -72,6 +72,122 @@ struct rk_priv_data {
>  #define GRF_BIT(nr)  (BIT(nr) | BIT(nr+16))
>  #define GRF_CLR_BIT(nr)  (BIT(nr+16))
> 
> +#define RK322X_GRF_MAC_CON0  0x0900
> +#define RK322X_GRF_MAC_CON1  0x0904
> +
> +/* RK322X_GRF_MAC_CON0 */
> +#define RK322X_GMAC_CLK_RX_DL_CFG(val)   HIWORD_UPDATE(val, 0x7F, 7)
> +#define RK322X_GMAC_CLK_TX_DL_CFG(val)   HIWORD_UPDATE(val, 0x7F, 0)
> +
> +/* RK322X_GRF_MAC_CON1 */
> +#define RK322X_GMAC_PHY_INTF_SEL_RGMII   \
> + (GRF_BIT(4) | GRF_CLR_BIT(5) | GRF_CLR_BIT(6))
> +#define RK322X_GMAC_PHY_INTF_SEL_RMII\
> + (GRF_CLR_BIT(4) | GRF_CLR_BIT(5) | GRF_BIT(6))
> +#define RK322X_GMAC_FLOW_CTRLGRF_BIT(3)
> +#define RK322X_GMAC_FLOW_CTRL_CLRGRF_CLR_BIT(3)
> +#define RK322X_GMAC_SPEED_10MGRF_CLR_BIT(2)
> +#define RK322X_GMAC_SPEED_100M   GRF_BIT(2)
> +#define RK322X_GMAC_RMII_CLK_25M GRF_BIT(7)
> +#define RK322X_GMAC_RMII_CLK_2_5MGRF_CLR_BIT(7)
> +#define RK322X_GMAC_CLK_125M (GRF_CLR_BIT(8) | GRF_CLR_BIT(9))
> +#define RK322X_GMAC_CLK_25M  (GRF_BIT(8) | GRF_BIT(9))
> +#define RK322X_GMAC_CLK_2_5M (GRF_CLR_BIT(8) | GRF_BIT(9))
> +#define RK322X_GMAC_RMII_MODEGRF_BIT(10)
> +#define RK322X_GMAC_RMII_MODE_CLRGRF_CLR_BIT(10)
> +#define RK322X_GMAC_TXCLK_DLY_ENABLE GRF_BIT(0)
> +#define RK322X_GMAC_TXCLK_DLY_DISABLEGRF_CLR_BIT(0)
> +#define RK322X_GMAC_RXCLK_DLY_ENABLE GRF_BIT(1)
> +#define RK322X_GMAC_RXCLK_DLY_DISABLEGRF_CLR_BIT(1)
> +
> +static void rk322x_set_to_rgmii(struct rk_priv_data *bsp_priv,
> + int tx_delay, int rx_delay)
> +{
> + struct device *dev = &bsp_priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + return;
> + }
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1,
> +  RK322X_GMAC_PHY_INTF_SEL_RGMII |
> +  RK322X_GMAC_RMII_MODE_CLR |
> +  RK322X_GMAC_RXCLK_DLY_ENABLE |
> +  RK322X_GMAC_TXCLK_DLY_ENABLE);
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON0,
> +  RK322X_GMAC_CLK_RX_DL_CFG(rx_delay) |
> +  RK322X_GMAC_CLK_TX_DL_CFG(tx_delay));
> +}
> +
> +static void rk322x_set_to_rmii(struct rk_priv_data *bsp_priv)
> +{
> + struct device *dev = &bsp_priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + return;
> + }
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1,
> +  RK322X_GMAC_PHY_INTF_SEL_RMII |
> +  RK322X_GMAC_RMII_MODE);
> +
> + /* set MAC to RMII mode */
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1, GRF_BIT(11));
> +}
> +
> +static void rk322x_set_rgmii_speed(struct rk_priv_data *bsp_priv, int
> speed) +{
> + struct device *dev = &bsp_priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + return;
> + }

Re: cross compilers [was build failure of sorts]

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 09:28:56AM +, Vineet Gupta wrote:
> On Tuesday 21 June 2016 01:13 PM, Peter Zijlstra wrote:
> > On Tue, Jun 21, 2016 at 05:29:28AM +, Vineet Gupta wrote:
> >> > On Saturday 18 June 2016 03:47 PM, Peter Zijlstra wrote:
> >>> > > As you can see, arc doesn't even build upstream binutils :/
> >>> > > (binutils-2_26-branch as of today).
> >> > 
> >> > Hmm - we are still in fight w.r.t. upstreaming gcc fully (ARCv2 gcc 
> >> > support)
> >> > although ARCompact has been there for some time. binutils upstream 
> >> > should work -
> >> > I'll check why the buildall stuff fails.
> > I can run that build again and send you the resulting log files in
> > private.
> 
> Thx for the off-list log. The issue is gdb not yet upstream. So it seems we 
> will
> have to wait for things on upstreaming to settle down before I can formally 
> update
> segher's scripts to support ARC.

Ah, lemme add --disable-gdb to the binutils build.

Should arc-*-* list gdb in their noconfigdirs like many other archs do
too?

Documenting ptrace access mode checking

[Michael Kerrisk (man-pages)]

Hi Jann, Stephen, et al.

Jann, since you recently committed a patch in this area, and Stephen,
since you committed 006ebb40d3d much further back in time, I wonder if
you might help me by reviewing the text below that I propose to add to
the ptrace(2) man page, in order to document "ptrace access mode 
checking" that is performed in various parts of the kernel-user-space
interface. Of course, I welcome input from anyone else as well.

Here's the new ptrace(2) text. Any comments, technical or terminological
fixes, other improvements, etc. are welcome.

[[
   Ptrace access mode checking
   Various parts of the kernel-user-space API (not just  ptrace(2)
   operations), require so-called "ptrace access mode permissions"
   which are gated  by  Linux  Security  Modules  (LSMs)  such  as
   SELinux,  Yama,  Smack,  or  the  default  LSM.  Prior to Linux
   2.6.27, all such checks were of a  single  type.   Since  Linux
   2.6.27, two access mode levels are distinguished:

   PTRACE_MODE_READ
  For  "read" operations or other operations that are less
  dangerous, such as: get_robust_list(2); kcmp(2); reading
  /proc/[pid]/auxv, /proc/[pid]/environ,or
  /proc/[pid]/stat; or readlink(2) of  a  /proc/[pid]/ns/*
  file.

   PTRACE_MODE_ATTACH
  For  "write"  operations,  or  other operations that are
  moredangerous,suchas:ptraceattaching
  (PTRACE_ATTACH)to   another   process   or   calling
  process_vm_writev(2).   (PTRACE_MODE_ATTACH  was  effec‐
  tively the default before Linux 2.6.27.)

   Since  Linux  4.5, the above access mode checks may be combined
   (ORed) with one of the following modifiers:

   PTRACE_MODE_FSCREDS
  Use the caller's filesystem UID  and  GID  (see  creden‐
  tials(7)) or effective capabilities for LSM checks.

   PTRACE_MODE_REALCREDS
  Use the caller's real UID and GID or permitted capabili‐
  ties for LSM checks.  This was effectively  the  default
  before Linux 4.5.

   Because  combining  one of the credential modifiers with one of
   the aforementioned access modes is  typical,  some  macros  are
   defined in the kernel sources for the combinations:

   PTRACE_MODE_READ_FSCREDS
  Defined as PTRACE_MODE_READ | PTRACE_MODE_FSCREDS.

   PTRACE_MODE_READ_REALCREDS
  Defined as PTRACE_MODE_READ | PTRACE_MODE_REALCREDS.

   PTRACE_MODE_ATTACH_FSCREDS
  Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS.

   PTRACE_MODE_ATTACH_REALCREDS
  Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS.

   One further modifier can be ORed with the access mode:

   PTRACE_MODE_NOAUDIT (since Linux 3.3)
  Don't audit this access mode check.

[I'd quite welcome some text to explain "auditing" here.]

   The  algorithm  employed for ptrace access mode checking deter‐
   mines whether the calling process is  allowed  to  perform  the
   corresponding action on the target process, as follows:

   1.  If the calling thread and the target thread are in the same
   thread group, access is always allowed.

   2.  If the access mode specifies PTRACE_MODE_FSCREDS, then  for
   the  check in the next step, employ the caller's filesystem
   user ID and group ID (see credentials(7));  otherwise  (the
   access  mode  specifies  PTRACE_MODE_REALCREDS, so) use the
   caller's real user ID and group ID.

   3.  Deny access if neither of the following is true:

   · The real, effective, and saved-set user IDs of the target
 match  the caller's user ID, and the real, effective, and
 saved-set group IDs of  the  target  match  the  caller's
 group ID.

   · The caller has the CAP_SYS_PTRACE capability.

   4.  Deny  access if the target process "dumpable" attribute has
   a value other than 1 (SUID_DUMP_USER; see the discussion of
   PR_SET_DUMPABLE  in prctl(2)), and the caller does not have
   the CAP_SYS_PTRACE capability in the user namespace of  the
   target process.

   5.  The  kernel LSM security_ptrace_access_check() interface is
   invoked to see if ptrace access is permitted.  The  results
   depend on the LSM.  The implementation of this interface in
   the default LSM performs the following steps:

   a) If the access mode  includes  PTRACE_MODE_FSCREDS,  then
  use the caller's effective capability set in the follow‐
  ing  check;  otherwise  (the   access   mode   specifies
  PTRACE_MODE_REALCREDS,  so)  use  the caller's permitted
  capability set.

   b) Deny access if neither of the following is true:

Re: [PATCH] iommu/mediatek: Do not call of_node_put in mtk_iommu_of_xlate

[Joerg Roedel]

On Wed, Jun 08, 2016 at 05:50:44PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> The device_node will be released in of_iommu_configure, it may be double
> released if call of_node_put in mtk_iommu_of_xlate.
> 
> Signed-off-by: Honghui Zhang 
> ---
>  drivers/iommu/mtk_iommu.c | 1 -
>  1 file changed, 1 deletion(-)

Applied, thanks.

[PATCH 1/3] iio: adc: max1363: Fix missing i2c_device_id for MAX1164x parts

[Florian Vaussard]

The driver supports MAX11644, MAX11645, MAX11646 and MAX11647 parts. But
the corresponding i2c_device_id are missing. Add them!

Signed-off-by: Florian Vaussard 
---
 drivers/iio/adc/max1363.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index 929508e..b5d28c0 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/adc/max1363.c
@@ -1680,6 +1680,10 @@ static const struct i2c_device_id max1363_id[] = {
{ "max11615", max11615 },
{ "max11616", max11616 },
{ "max11617", max11617 },
+   { "max11644", max11644 },
+   { "max11645", max11645 },
+   { "max11646", max11646 },
+   { "max11647", max11647 },
{}
 };
 
-- 
2.5.0