Re: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings

[Ard Biesheuvel]

On 22 February 2016 at 21:02, Russell King - ARM Linux
 wrote:
> On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
>> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
>> attributes, but the ARM architecture simply does not allow mismatched
>> attributes, so we cannot simply replace each instance of
>> ioremap_cache() with memremap()
>>
>> Perhaps Russell can explain?
>
> ARM has had ioremap_cached() for a while - it was introduced in the
> bitkeeper times of 2.6, so pre-git.  In those kernels, and into the
> git era, pre-dating ARMv6 support, it was merely:
>
> +#define ioremap_cached(cookie,size)
> __arch_ioremap((cookie),(size),L_PTE_CACHEABLE)
>
> which means that we got write-through cache behaviour for mappings
> created by this, where supported, or if not, read-allocate writeback.
> This was completely independent of the system memory mapping
> attributes, which could be specified on the kernel command line.
>
> This was originally used by pxa2xx-flash to provide faster flash
> access on those systems - in other words, it's created to remap
> devices with cacheable attributes.
>
> When creating ARMv6 support, I ended up completely rewriting how
> the memory attributes were handled, and so it then became this:
>
> +#define ioremap_cached(cookie,size)__arch_ioremap((cookie), (size), 
> MT_DEVICE_CACHED)
>
> which gives very similar behaviour, though we now default to RAWB
> mappings, which fall back to WT on CPUs that don't support RAWB.
> Again, independent of the system memory mapping.
>
> Then, in 2013, with the advent of Xen, ioremap_cached() became
> ioremap_cache() so that Xen would build on ARM, and to align it
> with other architectures.  Whether ioremap_cached() actually was
> suitable to become ioremap_cache(), I'm not sure, but that's
> what happened.
>
> Since it was just renamed, it preserves the original goal which is
> to remap device memory with cacheable attributes, which may differ
> from the cacheable attributes of the system RAM.  It has never
> been intended for remapping system memory: none of the ioremap_*
> family of functions on ARM were ever intended for that purpose.
>
> However, some people did use it for that purpose on ARMv5 and
> earlier architectures, where, due to the virtual cache architecture,
> you could get away with remapping the same memory with differing
> attributes without any problem.  With the advent of ARMv6
> (pre-dating 2013), this was clearly stated as being illegal at
> architecture level, but people were married to the idea - despite
> me telling them not to.
>
> So eventually, I had no other option than to add a code check to
> ioremap*() which prevents any ioremap*() function from being used
> on system memory - iow, memory that Linux maps itself either as
> part of lowmem or via the kmap*() API - since an ioremap*()
> mapping would conflict with those.
>
> That's basically where we are today: ioremap*() does not permit
> system memory to be remapped, even ioremap_cache().
>

OK, thanks for the historical context.

So what is your opinion on this series, i.e., to wire up memremap() to
remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
attributes, and at the same time lift the restriction that the region
must be disjoint from memory covered by lowmem or kmap?

It would make my life a lot easier, since we can more easily share
code between x86, arm64 and ARM to permanently map memory regions that
have been populated by the firmware. As I noted in the commit log,
memremap() already does the right thing wrt lowmem, i.e., it returns
the existing mapping rather than creating a new one. For highmem, I
don't think kmap() is the way to go considering the unknown size and
the potentially permanent nature of the mappings (which resemble
ioremap more than they resemble kmap)

-- 
Ard.

[RFC] staging: iio: isl29018: use regmap to retrieve struct device

[Alison Schofield]

Remove struct device from drivers global data and use regmap
API to retrieve device info instead.

This replacement can be done for drivers that include regmap
in their global data.

Signed-off-by: Alison Schofield 
---
 drivers/staging/iio/light/isl29018.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/iio/light/isl29018.c 
b/drivers/staging/iio/light/isl29018.c
index 03dbfb6..76d9f74 100644
--- a/drivers/staging/iio/light/isl29018.c
+++ b/drivers/staging/iio/light/isl29018.c
@@ -100,7 +100,6 @@ static const struct isl29018_scale {
 };
 
 struct isl29018_chip {
-   struct device   *dev;
struct regmap   *regmap;
struct mutexlock;
int type;
@@ -180,30 +179,31 @@ static int isl29018_read_sensor_input(struct 
isl29018_chip *chip, int mode)
int status;
unsigned int lsb;
unsigned int msb;
+   struct device *dev = regmap_get_device(chip->regmap);
 
/* Set mode */
status = regmap_write(chip->regmap, ISL29018_REG_ADD_COMMAND1,
  mode << COMMMAND1_OPMODE_SHIFT);
if (status) {
-   dev_err(chip->dev,
+   dev_err(dev,
"Error in setting operating mode err %d\n", status);
return status;
}
msleep(CONVERSION_TIME_MS);
status = regmap_read(chip->regmap, ISL29018_REG_ADD_DATA_LSB, &lsb);
if (status < 0) {
-   dev_err(chip->dev,
+   dev_err(dev,
"Error in reading LSB DATA with err %d\n", status);
return status;
}
 
status = regmap_read(chip->regmap, ISL29018_REG_ADD_DATA_MSB, &msb);
if (status < 0) {
-   dev_err(chip->dev,
+   dev_err(dev,
"Error in reading MSB DATA with error %d\n", status);
return status;
}
-   dev_vdbg(chip->dev, "MSB 0x%x and LSB 0x%x\n", msb, lsb);
+   dev_vdbg(dev, "MSB 0x%x and LSB 0x%x\n", msb, lsb);
 
return (msb << 8) | lsb;
 }
@@ -246,13 +246,14 @@ static int isl29018_read_proximity_ir(struct 
isl29018_chip *chip, int scheme,
int status;
int prox_data = -1;
int ir_data = -1;
+   struct device *dev = regmap_get_device(chip->regmap);
 
/* Do proximity sensing with required scheme */
status = regmap_update_bits(chip->regmap, ISL29018_REG_ADD_COMMANDII,
COMMANDII_SCHEME_MASK,
scheme << COMMANDII_SCHEME_SHIFT);
if (status) {
-   dev_err(chip->dev, "Error in setting operating mode\n");
+   dev_err(dev, "Error in setting operating mode\n");
return status;
}
 
@@ -525,10 +526,11 @@ static int isl29035_detect(struct isl29018_chip *chip)
 {
int status;
unsigned int id;
+   struct device *dev = regmap_get_device(chip->regmap);
 
status = regmap_read(chip->regmap, ISL29035_REG_DEVICE_ID, &id);
if (status < 0) {
-   dev_err(chip->dev,
+   dev_err(dev,
"Error reading ID register with error %d\n",
status);
return status;
@@ -553,6 +555,7 @@ enum {
 static int isl29018_chip_init(struct isl29018_chip *chip)
 {
int status;
+   struct device *dev = regmap_get_device(chip->regmap);
 
if (chip->type == isl29035) {
status = isl29035_detect(chip);
@@ -582,7 +585,7 @@ static int isl29018_chip_init(struct isl29018_chip *chip)
 */
status = regmap_write(chip->regmap, ISL29018_REG_TEST, 0x0);
if (status < 0) {
-   dev_err(chip->dev, "Failed to clear isl29018 TEST reg.(%d)\n",
+   dev_err(dev, "Failed to clear isl29018 TEST reg.(%d)\n",
status);
return status;
}
@@ -593,7 +596,7 @@ static int isl29018_chip_init(struct isl29018_chip *chip)
 */
status = regmap_write(chip->regmap, ISL29018_REG_ADD_COMMAND1, 0);
if (status < 0) {
-   dev_err(chip->dev, "Failed to clear isl29018 CMD1 reg.(%d)\n",
+   dev_err(dev, "Failed to clear isl29018 CMD1 reg.(%d)\n",
status);
return status;
}
@@ -604,14 +607,14 @@ static int isl29018_chip_init(struct isl29018_chip *chip)
status = isl29018_set_scale(chip, chip->scale.scale,
chip->scale.uscale);
if (status < 0) {
-   dev_err(chip->dev, "Init of isl29018 fails\n");
+   dev_err(dev, "Init of isl29018 fails\n");
return status;
}
 
status = isl29018_set_integration_time(chip,
isl29018_int_utimes[chip->type][chip->int_time]);
if (status < 0) {
-   d

[PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

[dinguyen]

From: Dinh Nguyen 

There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can
have multiple parents. Fix up the __socfpga_periph_init() to call
of_clk_parent_fill() that will return the appropriate number of parents.

Also, update __socfpga_gate_init() to call of_clk_parent_fill() helper
function.

Signed-off-by: Dinh Nguyen 
---
 drivers/clk/socfpga/clk-gate-a10.c   | 5 +
 drivers/clk/socfpga/clk-periph-a10.c | 5 ++---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/socfpga/clk-gate-a10.c 
b/drivers/clk/socfpga/clk-gate-a10.c
index 1cebf25..0b6ee7b 100644
--- a/drivers/clk/socfpga/clk-gate-a10.c
+++ b/drivers/clk/socfpga/clk-gate-a10.c
@@ -167,12 +167,9 @@ static void __init __socfpga_gate_init(struct device_node 
*node,
init.name = clk_name;
init.ops = ops;
init.flags = 0;
-   while (i < SOCFPGA_MAX_PARENTS && (parent_name[i] =
-   of_clk_get_parent_name(node, i)) != NULL)
-   i++;
 
+   init.num_parents = of_clk_parent_fill(node, parent_name, 
SOCFPGA_MAX_PARENTS);
init.parent_names = parent_name;
-   init.num_parents = i;
socfpga_clk->hw.hw.init = &init;
 
clk = clk_register(NULL, &socfpga_clk->hw.hw);
diff --git a/drivers/clk/socfpga/clk-periph-a10.c 
b/drivers/clk/socfpga/clk-periph-a10.c
index 1f397cb..2b7e215 100644
--- a/drivers/clk/socfpga/clk-periph-a10.c
+++ b/drivers/clk/socfpga/clk-periph-a10.c
@@ -74,7 +74,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
struct clk *clk;
struct socfpga_periph_clk *periph_clk;
const char *clk_name = node->name;
-   const char *parent_name;
+   const char *parent_name[SOCFPGA_MAX_PARENTS];
struct clk_init_data init;
int rc;
u32 fixed_div;
@@ -109,8 +109,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
init.ops = ops;
init.flags = 0;
 
-   parent_name = of_clk_get_parent_name(node, 0);
-   init.num_parents = 1;
+   init.num_parents = of_clk_parent_fill(node, parent_name, 
SOCFPGA_MAX_PARENTS);
init.parent_names = &parent_name;
 
periph_clk->hw.hw.init = &init;
-- 
2.6.2

Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

[Gabriel L. Somlo]

On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > +static void fw_cfg_io_cleanup(void)
> > > > +{
> > > > +   if (fw_cfg_is_mmio) {
> > > > +   iounmap(fw_cfg_dev_base);
> > > > +   release_mem_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > +   } else {
> > > > +   ioport_unmap(fw_cfg_dev_base);
> > > > +   release_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > +   }
> > > > +}
> > > > +
> > > > +/* arch-specific ctrl & data register offsets are not available in 
> > > > ACPI, DT */
> > > 
> > > So for all arches which support ACPI, I think this driver
> > > should just rely on ACPI.
> > 
> > There was a discussion about that a few versions ago, and IIRC the
> > conclusion was not to expect the firmware to contend for fw_cfg access
> > after the guest kernel boots:
> > 
> > https://lkml.org/lkml/2015/10/5/283
> > 
> 
> So it looks like NVDIMM at least wants to pass label data to guest -
> for which fw cfg might be a reasonable choice.
> 
> I suspect things changed - fw cfg used to be very slow but we now have
> DMA interface which makes it useful for a range of applications.
> 
> > (I even had a prototype version doing what you suggested, but per the above
> > reference decided to drop it -- which IMHO is for the better, since 
> > otherwise
> > I'd have had to ifdef between ACPI and non-ACPI versions of the driver --
> > see https://lkml.org/lkml/2015/11/4/534 )
> 
> I'm not sure why you have these ifdefs - they are on the host, are they
> not?

Think of those as "pseudocode" ifdefs, they're there to distinguish
between AML that would be generated on MMIO vs. IOPORT systems
(specifically, arm vs. x86, respectively)

Some of the AML is the same, but obviously the _CRS, and
OperationRegion + Field are different, and I wanted to point that out
somehow :)

Cheers,
--Gabriel

Re: [PATCH 4/4] tools lib traceevent: Implements '%' operation

[Steven Rostedt]

On Mon, 22 Feb 2016 14:08:22 -0300
Daniel Bristot de Oliveira  wrote:

> The operation '%' is not implemented on event-parse.c, causing
> an error on the parse of events with '%' operation on its
> printk format. For example,
> 
> # perf record -e sched:sched_deadline_yield ~/y
>   Warning: [sched:sched_deadline_yield] unknown op '%'
> 
> # perf script
>   Warning: [sched:sched_deadline_yield] unknown op '%'
>   y  1641 [006]  3364.109319: sched:sched_deadline_yield: \
>   [FAILED TO PARSE] now=3364109314595 \
>   deadline=3364139295135 runtime=19975597
> 
> This patch implements the '%' operation. With this patch, we see the
> correct output:
> 
> # perf record -e sched:sched_deadline_yield ~/y
>   No Warning
> 
> # perf script
>   y  4005 [001]  4623.650978: sched:sched_deadline_yield: \
>   now=4623.650974050  \
>   deadline=4623.680957364 remaining_runtime=19979611
> 
> Signed-off-by: Daniel Bristot de Oliveira 

Arnaldo,

This patch is not dependent on the rest of the series and looks like a
good general fix.

Can you pull this one into your tree, and please add my:

Reviewed-by: Steven Rostedt 

Thanks!

-- Steve

> ---
>  tools/lib/traceevent/event-parse.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tools/lib/traceevent/event-parse.c 
> b/tools/lib/traceevent/event-parse.c
> index c3bd294..575e751 100644
> --- a/tools/lib/traceevent/event-parse.c
> +++ b/tools/lib/traceevent/event-parse.c
> @@ -1951,6 +1951,7 @@ process_op(struct event_format *event, struct print_arg 
> *arg, char **tok)
>  strcmp(token, "*") == 0 ||
>  strcmp(token, "^") == 0 ||
>  strcmp(token, "/") == 0 ||
> +strcmp(token, "%") == 0 ||
>  strcmp(token, "<") == 0 ||
>  strcmp(token, ">") == 0 ||
>  strcmp(token, "<=") == 0 ||
> @@ -3689,6 +3690,9 @@ eval_num_arg(void *data, int size, struct event_format 
> *event, struct print_arg
>   case '/':
>   val = left / right;
>   break;
> + case '%':
> + val = left % right;
> + break;
>   case '*':
>   val = left * right;
>   break;

Re: [GIT PULL] hwmon fixes for v4.5-rc6

[Linus Torvalds]

Hi Guenter,

 Please don't do things like this to me:

On Sun, Feb 21, 2016 at 10:22 AM, Guenter Roeck  wrote:
>
> Please pull hwmon fixes for Linux v4.5-rc6 from signed tag:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-v4.5-rc6
>
> ...
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> tags/hwmon-for-linus-v4.5-rc6

Notice the difference? My tiny little brain gets all confused about
things like this, and starts worrying about whether the two might be
different.

Anyway, pulled, but please try to avoid this kind of
duplicate-and-different pull request target thing..

Linus

Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

[Michael S. Tsirkin]

On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > +static void fw_cfg_io_cleanup(void)
> > > +{
> > > + if (fw_cfg_is_mmio) {
> > > + iounmap(fw_cfg_dev_base);
> > > + release_mem_region(fw_cfg_p_base, fw_cfg_p_size);
> > > + } else {
> > > + ioport_unmap(fw_cfg_dev_base);
> > > + release_region(fw_cfg_p_base, fw_cfg_p_size);
> > > + }
> > > +}
> > > +
> > > +/* arch-specific ctrl & data register offsets are not available in ACPI, 
> > > DT */
> > 
> > So for all arches which support ACPI, I think this driver
> > should just rely on ACPI.
> 
> There was a discussion about that a few versions ago, and IIRC the
> conclusion was not to expect the firmware to contend for fw_cfg access
> after the guest kernel boots:
> 
> https://lkml.org/lkml/2015/10/5/283
> 

So it looks like NVDIMM at least wants to pass label data to guest -
for which fw cfg might be a reasonable choice.

I suspect things changed - fw cfg used to be very slow but we now have
DMA interface which makes it useful for a range of applications.

> (I even had a prototype version doing what you suggested, but per the above
> reference decided to drop it -- which IMHO is for the better, since otherwise
> I'd have had to ifdef between ACPI and non-ACPI versions of the driver --
> see https://lkml.org/lkml/2015/11/4/534 )

I'm not sure why you have these ifdefs - they are on the host, are they
not?

-- 
MST

Re: [PATCH 10/61] gpio: ath79: Use devm_gpiochip_add_data() for gpio registration

[Alban]

On Mon, 22 Feb 2016 19:37:59 +0530
Laxman Dewangan  wrote:

> Use devm_gpiochip_add_data() for GPIO registration.
> 
> Signed-off-by: Laxman Dewangan 
> Cc: Alban Bedel 
> ---
>  drivers/gpio/gpio-ath79.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
> index d13dd13..a6aad59 100644
> --- a/drivers/gpio/gpio-ath79.c
> +++ b/drivers/gpio/gpio-ath79.c
> @@ -182,7 +182,7 @@ static int ath79_gpio_probe(struct platform_device *pdev)
>   ctrl->chip.direction_output = ar934x_gpio_direction_output;
>   }
>  
> - err = gpiochip_add_data(&ctrl->chip, ctrl);
> + err = devm_gpiochip_add_data(&pdev->dev, &ctrl->chip, ctrl);
>   if (err) {
>   dev_err(&pdev->dev,
>   "cannot add AR71xx GPIO chip, error=%d", err);

With the patches already applied to the devel branch a few more changes
will be needed to remove the calls to gpiochip_remove() in the probe
error path and the remove callback.

Alban

Re: [PATCH][V2] rtlwifi: pass struct rtl_stats by reference as it is more efficient

[Larry Finger]

On 02/22/2016 05:35 AM, Colin King wrote:

From: Colin Ian King 

passing rtl_stats by value is inefficient; the structure is over 300
bytes in size and generally just one field (packet_report_type)
is being accessed, so the pass by value is a relatively large overhead.
This change just affects just the rx_command_packet calls.

Signed-off-by: Colin Ian King 


Looks good and tests OK with rtl8723be.

Acked-by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/pci.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +++---
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 2 +-
  drivers/net/wireless/realtek/rtlwifi/wifi.h  | 2 +-
  12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..4153e7f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -855,7 +855,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
-   rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
+   rtlpriv->cfg->ops->rx_command_packet(hw, &stats, skb)) {
dev_kfree_skb_any(skb);
goto new_trx_end;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index 791efbe..1170106 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -851,7 +851,7 @@ void rtl88ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
  }

  u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
  struct sk_buff *skb)
  {
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
index eab5ae0..5a24d19 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
@@ -790,7 +790,7 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
  u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
  struct sk_buff *skb);

  #endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index d39ee67..24eff8e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -1105,13 +1105,13 @@ void rtl92ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
  }

  u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
  struct sk_buff *skb)
  {
u32 result = 0;
struct rtl_priv *rtlpriv = rtl_priv(hw);

-   switch (status.packet_report_type) {
+   switch (status->packet_report_type) {
case NORMAL_RX:
result = 0;
break;
@@ -1121,7 +1121,7 @@ u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
break;
default:
RT_TRACE(rtlpriv, COMP_RECV, DBG_TRACE,
-"Unknown packet type %d\n", status.packet_report_type);
+"Unknown packet type %d\n", 
status->packet_report_type);
break;
}

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
index 8f78ac9..a4c3834 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
@@ -857,6 +857,6 @@ void rtl92ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
  u32 rtl92ee_rx_command_packet(struct ieee80211_hw *h

Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler

[Daniel Bristot de Oliveira]

On 02/22/2016 02:48 PM, Steven Rostedt wrote:
> On Mon, 22 Feb 2016 18:32:59 +0100
> Peter Zijlstra  wrote:
> 
> 
>> > So I'm a bit allergic to tracepoints and this is very flimsy on reasons
>> > why I would want to do this.
> Because there's no way to know if SCHED_DEADLINE tasks are doing what
> they suppose to without hacking the kernel and adding your own
> tracepoints.

That is the point. A potential deadline user would have to become a
sched deadline developer to be able to debug its deadline tasks.

Given that many deadline scheduler users are expected from application
field, e.g. automation, and that these users generally do not even know
how to compile a kernel, having a "ready to use" way to observe sched
deadline specific points of interest is essential for deadline
scheduler adoption.

For example, the runtime is an estimated value because there is no
deterministic way define it, so be able to observe the remaining runtime
at the end of an activation is very useful to define a tighter runtime.
On the other hand, it is possible to defined that runtime was under
estimated just by observing that a task was throttled.

Another example: be able to see that a task is blocking in the middle of
an activation is useful on the identification of an unexpected behavior
of a deadline task.

Although it is possible to guess many things by doing user-space
measurements, by using a set of other tracepoints, or even by using both
together. The debug process will not be as easy and precise as using
these four tracepoints.

-- Daniel

Re: [PATCH v5 00/26] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 22/02/16 18:42, Tony Lindgren wrote:
> * Roger Quadros  [160222 02:16]:
>> On 20/02/16 00:04, Tony Lindgren wrote:
>>> * Roger Quadros  [160219 13:27]:
 Hi,

 @Tony
 Patches 15 and 24 are new and will need your review.
 I've modified patch 22 to include the new am335x boards introduced since 
 v4.4.

 Patches are based on top of omap-for-v4.6/dt so that the DT changes apply 
 cleanly.
>>>
>>> Looks OK to me. Can we merge the dts changes separately? Otherwise
>>> we will easily end up with tons of conflicts..
>>
>> I agree. But we just need to keep in mind that NAND functionality will be
>> broken till all the patches in this series are merged. We don't maintain
>> backward compatibility with the old DT implementation.
> 
> Please let's not do that! That breaks booting and git bisect.
> It's better to have a minimal branch where each patch boots fine.

Understood. I'll send out a patch set with only the minimal DT changes
that doesn't break anything. This should be a preparatory step for
the DT clean up.

> 
> Also, I think you should at least print a warning for the old
> binding. Otherwise people with out of tree boards will have
> hard time updating their patches to send to mainline tree.

OK. I'll add this warning mechanism to the omap-gpmc driver.

cheers,
-roger

[PATCH v3] pci: Wait for up to 1000ms after FLR reset

[Alex Williamson]

Some devices take longer than the spec indicates to return from FLR
reset, a notable case of this is Intel integrated graphics (IGD),
which can often take an additional 300ms powering down an attached
LCD panel as part of the FLR.  Allow devices up to 1000ms, testing
every 100ms whether the second dword of config space is read as -1.

Signed-off-by: Alex Williamson 
---
v3: Read 2nd dword since SR-IOV VFs don't implement the 1st dword
v2: Change loop to incorporate initial 100ms delay, replace delay in
callee functions, add comment.

 drivers/pci/pci.c |   27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..365ac76 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3414,6 +3414,29 @@ int pci_wait_for_pending_transaction(struct pci_dev *dev)
 }
 EXPORT_SYMBOL(pci_wait_for_pending_transaction);
 
+/*
+ * We should only need to wait 100ms after FLR, but some devices take longer.
+ * Wait for up to 1000ms for config space to return something other than -1.
+ * Intel IGD requires this when an LCD panel is attached.  We read the 2nd
+ * dword because VFs don't implement the 1st dword.
+ */
+static void pci_flr_wait(struct pci_dev *dev)
+{
+   int i = 0;
+   u32 id;
+
+   do {
+   msleep(100);
+   pci_read_config_dword(dev, PCI_COMMAND, &id);
+   } while (i++ < 10 && id == ~0);
+
+   if (id == ~0)
+   dev_warn(&dev->dev, "Failed to return from FLR\n");
+   else if (i > 1)
+   dev_info(&dev->dev, "Required additional "
+"%dms to return from FLR\n", (i - 1) * 100);
+}
+
 static int pcie_flr(struct pci_dev *dev, int probe)
 {
u32 cap;
@@ -3429,7 +3452,7 @@ static int pcie_flr(struct pci_dev *dev, int probe)
dev_err(&dev->dev, "timed out waiting for pending transaction; 
performing function level reset anyway\n");
 
pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
-   msleep(100);
+   pci_flr_wait(dev);
return 0;
 }
 
@@ -3459,7 +3482,7 @@ static int pci_af_flr(struct pci_dev *dev, int probe)
dev_err(&dev->dev, "timed out waiting for pending transaction; 
performing AF function level reset anyway\n");
 
pci_write_config_byte(dev, pos + PCI_AF_CTRL, PCI_AF_CTRL_FLR);
-   msleep(100);
+   pci_flr_wait(dev);
return 0;
 }
 

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

[Tadeusz Struk]

On 02/19/2016 09:18 AM, David Howells wrote:
> Move the RSA EMSA-PKCS1-v1_5 encoding from the asymmetric-key public_key
> subtype to the rsa crypto module.  This means that the public_key subtype
> no longer has any dependencies on public key type.
> 
> To make this work, I've made the following changes:
> 
>  (1) An indicator as to the hash algorithm employed must be passed to the
>  public key algorithm.  I have made this a string, equivalent to the
>  name in the matching crypto module and placed it in akcipher_request.
> 
>  (2) The RSA module builds the EMSA-PKCS1-v1_5 encoded message (EM) and
>  then compares that to the 'decrypted' signature.  This function can
>  then be reused for signing.
> 
>  (3) The destination buffer in akcipher_request is now an input buffer
>  holding the message digest (M) for the verify operation.  The output
>  of the verify operation is purely the error code.
> 
>  (4) The crypto driver in crypto/asymmetric_keys/rsa.c is now reduced to
>  something that doesn't care about what the encryption actually does
>  and and has been merged into public_key.c.
> 
>  (5) The test drivers set a NULL hash algorithm as I'm not sure what they
>  should be.
> 
>  (6) CONFIG_PUBLIC_KEY_ALGO_RSA is gone.  Module signing must set
>  CONFIG_CRYPTO_RSA=y instead.
> 
> Thoughts:
> 
>  (*) Should the encoding style (eg. raw, EMSA-PKCS1-v1_5) also be passed to
>  the public key algorithm?

I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
that we already have. Looks like the two do the same padding now.
Should we merge then and pass the hash param as a separate template param,
e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?

> 
> Signed-off-by: David Howells 
> ---
> 
>  crypto/asymmetric_keys/Kconfig  |7 -
>  crypto/asymmetric_keys/Makefile |1 
>  crypto/asymmetric_keys/public_key.c |   69 +--
>  crypto/asymmetric_keys/rsa.c|  224 
> ---
>  crypto/rsa.c|  210 -
>  crypto/testmgr.c|5 -
>  include/crypto/akcipher.h   |7 +
>  include/crypto/public_key.h |2 
>  init/Kconfig|2 
>  9 files changed, 248 insertions(+), 279 deletions(-)
>  delete mode 100644 crypto/asymmetric_keys/rsa.c
> 
> diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> index 905d745c2f85..91a7e047a765 100644
> --- a/crypto/asymmetric_keys/Kconfig
> +++ b/crypto/asymmetric_keys/Kconfig
> @@ -12,7 +12,6 @@ if ASYMMETRIC_KEY_TYPE
>  config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>   tristate "Asymmetric public-key crypto algorithm subtype"
>   select MPILIB
> - select PUBLIC_KEY_ALGO_RSA
>   select CRYPTO_HASH_INFO
>   help
> This option provides support for asymmetric public key type handling.
> @@ -20,12 +19,6 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> appropriate hash algorithms (such as SHA-1) must be available.
> ENOPKG will be reported if the requisite algorithm is unavailable.
>  
> -config PUBLIC_KEY_ALGO_RSA
> - tristate "RSA public-key algorithm"
> - select CRYPTO_RSA
> - help
> -   This option enables support for the RSA algorithm (PKCS#1, RFC3447).
> -
>  config X509_CERTIFICATE_PARSER
>   tristate "X.509 certificate parser"
>   depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
> index b78a194ea014..f90486256f01 100644
> --- a/crypto/asymmetric_keys/Makefile
> +++ b/crypto/asymmetric_keys/Makefile
> @@ -7,7 +7,6 @@ obj-$(CONFIG_ASYMMETRIC_KEY_TYPE) += asymmetric_keys.o
>  asymmetric_keys-y := asymmetric_type.o signature.o
>  
>  obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
> -obj-$(CONFIG_PUBLIC_KEY_ALGO_RSA) += rsa.o
>  
>  #
>  # X.509 Certificate handling
> diff --git a/crypto/asymmetric_keys/public_key.c 
> b/crypto/asymmetric_keys/public_key.c
> index b383629b9e62..66727a13d561 100644
> --- a/crypto/asymmetric_keys/public_key.c
> +++ b/crypto/asymmetric_keys/public_key.c
> @@ -17,8 +17,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  MODULE_LICENSE("GPL");
>  
> @@ -35,12 +37,6 @@ const char *const pkey_id_type_name[PKEY_ID_TYPE__LAST] = {
>  };
>  EXPORT_SYMBOL_GPL(pkey_id_type_name);
>  
> -static int (*alg_verify[PKEY_ALGO__LAST])(const struct public_key *pkey,
> - const struct public_key_signature *sig) = {
> - NULL,
> - rsa_verify_signature
> -};
> -
>  /*
>   * Provide a part of a description of the key for /proc/keys.
>   */
> @@ -68,24 +64,75 @@ void public_key_destroy(void *payload)
>  }
>  EXPORT_SYMBOL_GPL(public_key_destroy);
>  
> +struct public_key_completion {
> + struct completion completion;
> + int err;
> +};
> +
> +static void public_key_verify_done(struct crypto_async_request *req, int

[PATCH v1] ARM: dts: nitrogen6x: add USB host 1 support

[Peter Seiderer]

Regulator stuff and pin configuration copied from imx6qdl-nitrogen6_max.dtsi
and checked against Boundary Devices linux kernel tree ([1]).

[1] 
https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.14.28_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi

Signed-off-by: Peter Seiderer 
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index c6c590d..81f8c5c 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -85,9 +85,21 @@
enable-active-high;
};
 
-   reg_can_xcvr: regulator@3 {
+   reg_usb_h1_vbus: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usbh1>;
+   regulator-name = "usb_h1_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_can_xcvr: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
regulator-name = "CAN XCVR";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -96,9 +108,9 @@
gpio = <&gpio1 2 GPIO_ACTIVE_LOW>;
};
 
-   reg_wlan_vmmc: regulator@4 {
+   reg_wlan_vmmc: regulator@5 {
compatible = "regulator-fixed";
-   reg = <4>;
+   reg = <5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_wlan_vmmc>;
regulator-name = "reg_wlan_vmmc";
@@ -515,6 +527,12 @@
>;
};
 
+   pinctrl_usbh1: usbh1grp {
+   fsl,pins = <
+   MX6QDL_PAD_GPIO_17__GPIO7_IO12  0x0b0b0
+   >;
+   };
+
pinctrl_usbotg: usbotggrp {
fsl,pins = <
MX6QDL_PAD_GPIO_1__USB_OTG_ID   0x17059
@@ -632,6 +650,7 @@
 };
 
 &usbh1 {
+   vbus-supply = <®_usb_h1_vbus>;
status = "okay";
 };
 
-- 
2.1.4

Re: [PATCH 0/8] X.509: Software public key subtype changes

[Tadeusz Struk]

On 02/19/2016 09:18 AM, David Howells wrote:
> 
> Here's a set of patches that cleans up the public key handling in the
> asymmetric key functions:
> 
>  (1) - (3) These are Tadeusz's RSA akcipher conversion.

Thanks for taking this David.

> 
>  (4) This removes all knowledge of RSA from the software public key
>  asymmetric key subtype.  Instead, the public key type and the hash
>  type are indicated to the crypto layer and the RSA module there does
>  all the appropriate encoding.
> 
>  (5) This changes the various algorithm IDs to text labels instead of enums
>  as the strings are what we actually deal with (printing, passing to
>  the crypto layer).
> 
>  (6) This separates the private parts of the software public key subtype
>  into a private header in the implementation directory.
> 
>  (7) This renames public_key.c to software_pkey.c and changes the Kconfig
>  symbol to match.
> 
>  (8) This renames symbols beginning "public_key" to "software_pkey" except
>  struct for public_key_signature which is a wider API component.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
> 
> David
> ---
> David Howells (5):
>   akcipher: Move the RSA DER encoding to the crypto layer
>   X.509: Make algo identifiers text instead of enum
>   X.509: Make the public_key asymmetric key type internal data private
>   X.509: Rename public_key.c to software_pkey.c
>   X.509: Rename public_key* to software_pkey*
> 
> Tadeusz Struk (3):
>   crypto: KEYS: convert public key and digsig asym to the akcipher api
>   integrity: convert digsig to akcipher api
>   crypto: public_key: remove MPIs from public_key_signature struct
> 
> 
>  arch/s390/configs/default_defconfig   |2 
>  arch/s390/configs/gcov_defconfig  |2 
>  arch/s390/configs/performance_defconfig   |2 
>  crypto/asymmetric_keys/Kconfig|   17 +-
>  crypto/asymmetric_keys/Makefile   |   10 -
>  crypto/asymmetric_keys/mscode_parser.c|   14 +
>  crypto/asymmetric_keys/pkcs7_parser.c |   30 +--
>  crypto/asymmetric_keys/pkcs7_trust.c  |2 
>  crypto/asymmetric_keys/pkcs7_verify.c |   12 +
>  crypto/asymmetric_keys/public_key.c   |  130 --
>  crypto/asymmetric_keys/public_key.h   |   36 
>  crypto/asymmetric_keys/rsa.c  |  278 
> -
>  crypto/asymmetric_keys/software_pkey.c|  142 +++
>  crypto/asymmetric_keys/software_pkey.h|   33 +++
>  crypto/asymmetric_keys/verify_pefile.c|4 
>  crypto/asymmetric_keys/verify_pefile.h|2 
>  crypto/asymmetric_keys/x509_cert_parser.c |   67 ++-
>  crypto/asymmetric_keys/x509_parser.h  |4 
>  crypto/asymmetric_keys/x509_public_key.c  |   43 ++--
>  crypto/asymmetric_keys/x509_rsakey.asn1   |4 
>  crypto/rsa.c  |  210 +++---
>  crypto/testmgr.c  |5 -
>  include/crypto/akcipher.h |7 +
>  include/crypto/public_key.h   |   79 +---
>  init/Kconfig  |4 
>  kernel/module_signing.c   |6 +
>  security/integrity/Kconfig|3 
>  security/integrity/digsig_asymmetric.c|   16 +-
>  28 files changed, 467 insertions(+), 697 deletions(-)
>  delete mode 100644 crypto/asymmetric_keys/public_key.c
>  delete mode 100644 crypto/asymmetric_keys/public_key.h
>  delete mode 100644 crypto/asymmetric_keys/rsa.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.h
>  delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
> 

-- 
TS

Re: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings

[Russell King - ARM Linux]

On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
> 
> Perhaps Russell can explain?

ARM has had ioremap_cached() for a while - it was introduced in the
bitkeeper times of 2.6, so pre-git.  In those kernels, and into the
git era, pre-dating ARMv6 support, it was merely:

+#define ioremap_cached(cookie,size)
__arch_ioremap((cookie),(size),L_PTE_CACHEABLE)

which means that we got write-through cache behaviour for mappings
created by this, where supported, or if not, read-allocate writeback.
This was completely independent of the system memory mapping
attributes, which could be specified on the kernel command line.

This was originally used by pxa2xx-flash to provide faster flash
access on those systems - in other words, it's created to remap
devices with cacheable attributes.

When creating ARMv6 support, I ended up completely rewriting how
the memory attributes were handled, and so it then became this:

+#define ioremap_cached(cookie,size)__arch_ioremap((cookie), (size), 
MT_DEVICE_CACHED)

which gives very similar behaviour, though we now default to RAWB
mappings, which fall back to WT on CPUs that don't support RAWB.
Again, independent of the system memory mapping.

Then, in 2013, with the advent of Xen, ioremap_cached() became
ioremap_cache() so that Xen would build on ARM, and to align it
with other architectures.  Whether ioremap_cached() actually was
suitable to become ioremap_cache(), I'm not sure, but that's
what happened.

Since it was just renamed, it preserves the original goal which is
to remap device memory with cacheable attributes, which may differ
from the cacheable attributes of the system RAM.  It has never
been intended for remapping system memory: none of the ioremap_*
family of functions on ARM were ever intended for that purpose.

However, some people did use it for that purpose on ARMv5 and
earlier architectures, where, due to the virtual cache architecture,
you could get away with remapping the same memory with differing
attributes without any problem.  With the advent of ARMv6
(pre-dating 2013), this was clearly stated as being illegal at
architecture level, but people were married to the idea - despite
me telling them not to.

So eventually, I had no other option than to add a code check to
ioremap*() which prevents any ioremap*() function from being used
on system memory - iow, memory that Linux maps itself either as
part of lowmem or via the kmap*() API - since an ioremap*()
mapping would conflict with those.

That's basically where we are today: ioremap*() does not permit
system memory to be remapped, even ioremap_cache().

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 08/10] x86/xsaves: Fix PTRACE frames for XSAVES

[Dave Hansen]

On 02/22/2016 11:00 AM, Yu-cheng Yu wrote:
> + if (xsave->header.xfeatures & XFEATURE_MASK_SUPERVISOR)
> + xsave->header.xfeatures = xfeatures | XFEATURE_MASK_SUPERVISOR;
> + else
> + xsave->header.xfeatures = xfeatures;

This is dangerous.  It says, "if any supervisor feature bit is set, then
set *ALL* of the known bits".  There's no way that can work.

Don't you just want to or in the new bits that were in the passed-in
'xfeatures':

xsave->header.xfeatures |= xfeatures;

'xfeatures' is known not to contain any supervisor bits.

Re: [PATCH 07/10] x86/xsaves: Fix init_fpstate.header.xcomp_bv

[Dave Hansen]

On 02/22/2016 10:59 AM, Yu-cheng Yu wrote:
> This actually does not apply to XSAVES as XSAVES uses optimization. After
> init, all components are in INIT and not MODIFIED state and will not be
> saved. There is no need of setting xcomp_bv except for bit 63 to indicate
> a compacted format.

I look at it this way: xcomp_bv tells you the format of the buffer
xstate_bv tells you which components of the buffer are valid (not in
init state).

As it stands, every kernel xcomp_bv value should be identical, since the
kernel buffer is always in the same state and XSAVES is always called
with the same Requested Feature BitMap (RFBM).

While I don't think this patch _hurts_ anything, I think it might be a
bit confusing.  Wouldn't it just be easier if *EVERY* xcomp_bv value was
the same?

Re: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings

[Dan Williams]

On Mon, Feb 22, 2016 at 11:17 AM, Ard Biesheuvel
 wrote:
> On 22 February 2016 at 20:05, Dan Williams  wrote:
>> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
>>  wrote:
>>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>>> the kernel direct mapping, unless the region is in high memory, in which
>>> case it falls back to using ioremap_cache(). However, the semantics of
>>> ioremap_cache() are not unambiguously defined, and on ARM, it will
>>> actually result in a mapping type that differs from the attributes used
>>> for the linear mapping, and for this reason, the ioremap_cache() call
>>> fails if the region is part of the memory managed by the kernel.
>>>
>>> So instead, implement an optional hook 'arch_memremap_wb' whose default
>>> implementation calls ioremap_cache() as before, but which can be
>>> overridden by the architecture to do what is appropriate for it.
>>>
>>
>> Acked-by: Dan Williams 
>>
>> I still have patches pending to delete ioremap_cache() from ARM and
>> require memremap() to be used for cacheable mappings.  Do you see any
>> use for ioremap_cache() on ARM after this change?
>
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
>
> Perhaps Russell can explain?

>From the x86 perspective mismatched mappings are also disallowed.  The
goal of deprecating ioremap_cache() in favor of memremap() is simply
that the __iomem annotation is misplaced [1], and to clean up the
calling convention to be explicit without silent fallbacks to
different mapping types.

[1]: https://lwn.net/Articles/653585/

Re: [PATCH 2/2 v2] chrdev: allocate dynamic chardevs in all unused holes

[Linus Torvalds]

On Mon, Feb 22, 2016 at 4:20 AM, Linus Walleij  wrote:
> This is a duct-tape-and-chewing-gum solution to the problem
> with the major numbers running out when allocating major
> numbers dynamically.

Ok, much less hacky, but now the initialization is fairly unreadable,
even if the comment kind of saves it:

> +/*
> + * A bitmap for the 255 lower device numbers. A "1" means the
> + * major number is taken, a "0" means it is available. We first
> + * need to define all the assigned devices as taken so that
> + * dynamic device allocation will not go in and steal them.
> + */

But then the numbers are really hard to grok, and verify that they
actually match the comments:

> +static u32 majors_map[] = {
> +   /* 8 and 26 are free */
> +   BITS(0, 7) | BITS(9, 25) | BITS(27, 31),

That first one looks "obviously correct", but then:

> +   /* 40 and 60-63 are free */
> +   BITS(0, 7) | BITS(9, 27),
> +   /* 93 and 94 are free */
> +   BITS(0, 28) | BIT(31),

Yeah, it's not exactly obvious that 93/94 modulo 32 is 29/30 etc.

Now, we could fix it two ways:

 - make a BITS32() macro that just masks things by 32 bits, so that
you could write this as

  /* 8 and 26 are free */
  BITS32(0, 7) | BITS32(9, 25) | BITS32(27, 31),
  /* 40 and 60-63 are free */
  BITS32(32, 39) | BITS32(41, 59),
  /* 93 and 94 are free */
  BITS32(64, 92) | BIT32(95),
  ...

which would at least take away *some* of the costs.

Or, quite frankly, just waste memory, and make the array be an array
of buytes, and make it a whole lot more readable. That *could* have
advantages in that it would allow you to differentiate "used
dynamically" from "statically allocated" in the array too, in that you
now have more values than 0/1 to play with. You could also make it
show both the block and char assignments, for example, and use the
same map for both (even if perhaps only used for character devices
initially). Then the initializer could just look like

  #define CHR 1
  #define BLK 2
  #define DYNCHR 0x10  // set when allocated for dynamic char device
 #define DYNBLK 0x20 // set when allocated for dynamic block device

  static unsigned char major_map[] = {
[0] = CHR|BLK,   // unnamed block devices, no character device
[1] = CHR|BLK,   // memory devices, ramdisk
...

and that would make the source code much bigger, but it would perhaps
be worth it for the legibility and documentation reasons.

I dunno. Maybe I'm worrying about something that isn't worth worrying about.

Linus

[RFC 1/3] nvmem: Add 'of_nvmem_cell_from_device_node()'

[Andrey Smirnov]

Add 'of_nvmem_cell_from_device_node()' -- a function that allows to
obtain 'struct nvmem_cell' from a device tree node representing it. One
use-case for such a function would be to access nvmem cells with known
phandles.

Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/core.c   | 44 +-
 include/linux/nvmem-consumer.h |  7 +++
 2 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 6fd4e5a..08550dd 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -601,29 +601,21 @@ static struct nvmem_cell *nvmem_cell_get_from_list(const 
char *cell_id)
 
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
 /**
- * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ * of_nvmem_cell_from_device_node() - Get a nvmem cell from device node 
representation
  *
- * @dev node: Device tree node that uses the nvmem cell
- * @id: nvmem cell name from nvmem-cell-names property.
+ * @np node: Device tree node representing NVMEM cell
  *
  * Return: Will be an ERR_PTR() on error or a valid pointer
  * to a struct nvmem_cell.  The nvmem_cell will be freed by the
  * nvmem_cell_put().
  */
-struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
-   const char *name)
+struct nvmem_cell *of_nvmem_cell_from_device_node(struct device_node *cell_np)
 {
-   struct device_node *cell_np, *nvmem_np;
+   struct device_node *nvmem_np;
struct nvmem_cell *cell;
struct nvmem_device *nvmem;
const __be32 *addr;
-   int rval, len, index;
-
-   index = of_property_match_string(np, "nvmem-cell-names", name);
-
-   cell_np = of_parse_phandle(np, "nvmem-cells", index);
-   if (!cell_np)
-   return ERR_PTR(-EINVAL);
+   int rval, len;
 
nvmem_np = of_get_next_parent(cell_np);
if (!nvmem_np)
@@ -682,6 +674,32 @@ err_mem:
 
return ERR_PTR(rval);
 }
+EXPORT_SYMBOL_GPL(of_nvmem_cell_from_device_node);
+
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node referencing 
it and cell id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell.  The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+   const char *name)
+{
+   struct device_node *cell_np;
+   int index;
+
+   index = of_property_match_string(np, "nvmem-cell-names", name);
+
+   cell_np = of_parse_phandle(np, "nvmem-cells", index);
+   if (!cell_np)
+   return ERR_PTR(-EINVAL);
+
+   return of_nvmem_cell_from_device_node(cell_np);
+}
 EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
 #endif
 
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 9bb77d3..835c8a2 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -136,11 +136,18 @@ static inline int nvmem_device_write(struct nvmem_device 
*nvmem,
 #endif /* CONFIG_NVMEM */
 
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+struct nvmem_cell *of_nvmem_cell_from_device_node(struct device_node *np);
 struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 const char *name);
 struct nvmem_device *of_nvmem_device_get(struct device_node *np,
 const char *name);
 #else
+
+struct inline struct nvmem_cell *
+of_nvmem_cell_from_device_node(struct device_node *np)
+{
+   return ERR_PTR(-ENOSYS);
+}
 static inline struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 const char *name)
 {
-- 
2.5.0

[RFC 2/3] nvmem: Add 'nvmem-blob' driver

[Andrey Smirnov]

Add 'nvmem-blob' driver, which allows to access device tree embedded
data via NVMEM subsystem API.

Signed-off-by: Andrey Smirnov 
---
 Documentation/devicetree/bindings/nvmem/blob.txt |  35 ++
 drivers/nvmem/Makefile   |   1 +
 drivers/nvmem/blob.c | 132 +++
 3 files changed, 168 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/blob.txt
 create mode 100644 drivers/nvmem/blob.c

diff --git a/Documentation/devicetree/bindings/nvmem/blob.txt 
b/Documentation/devicetree/bindings/nvmem/blob.txt
new file mode 100644
index 000..b299576
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/blob.txt
@@ -0,0 +1,35 @@
+= Deviece Tree Embedded Blob As NVMEM Device =
+
+This binding is designed to provide a way for a developer to reference
+data, built-in into device tree blob file, as NVMEM provider and acccess
+certain portions of that data as NVMEM cells using NVMEM consumer API.
+
+Required properties:
+- compatible: should be "nvmem-blob"
+- data: specifies data contained in nvmem device
+
+= Data cells =
+Are child nodes of nvmem-composite, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   a-blob {
+   compatible = "nvmem-blob";
+   data = [aa bb cc dd ee];
+
+   cell1: cell@0 {
+   reg = <0 5>;
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   a-node {
+   ...
+   nvmem-cells = <&cell1>;
+   nvmem-cell-names = "some-data";
+   };
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 95dde3f..1a1adba 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
+obj-y += blob.o
diff --git a/drivers/nvmem/blob.c b/drivers/nvmem/blob.c
new file mode 100644
index 000..3f2296b
--- /dev/null
+++ b/drivers/nvmem/blob.c
@@ -0,0 +1,132 @@
+#define DEBUG 1
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct nvmem_blob {
+   const u8 *data;
+   size_t data_size;
+};
+
+static int nvmem_blob_write(void *context, const void *data,
+   size_t count)
+{
+   return -ENOTSUPP;
+}
+
+static int nvmem_blob_read(void *context,
+  const void *reg, size_t reg_size,
+  void *val, size_t val_size)
+{
+   struct nvmem_blob *nblob = context;
+   const unsigned int offset = *(u32 *)reg;
+   
+   memcpy(val, nblob->data + offset,
+  min(val_size, nblob->data_size - offset));
+   return 0;
+}
+
+static const struct regmap_bus nvmem_blob_regmap_bus = {
+   .write = nvmem_blob_write,
+   .read  = nvmem_blob_read,
+};
+
+
+static int nvmem_blob_validate_dt(struct device_node *np)
+{
+   return 0;
+}
+
+static int nvmem_blob_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct device *dev = &pdev->dev;
+   struct device_node *np = dev->of_node;
+   struct regmap *map;
+   struct nvmem_device *nvmem;
+   struct nvmem_blob *nblob;
+   struct property *pp;
+   struct nvmem_config  nv_cnf = {0};
+   struct regmap_config rm_cnf = {0};
+
+   ret = nvmem_blob_validate_dt(np);
+   if (ret < 0) {
+   dev_dbg(dev, "Device tree validation failed\n");
+   return ret;
+   }
+
+   nblob = devm_kzalloc(dev, sizeof(*nblob), GFP_KERNEL);
+   if (!nblob) {
+   dev_dbg(dev, "Not enough memory to allocate a blob\n");
+   return -ENOMEM;
+   }
+
+   pp = of_find_property(np, "data", NULL);
+   BUG_ON(!pp);
+   
+   nblob->data = pp->value;
+   nblob->data_size = pp->length;
+
+   rm_cnf.reg_bits = 32;
+   rm_cnf.val_bits = 8;
+   rm_cnf.reg_stride = 1;
+   rm_cnf.name = "nvmem-blob";
+   rm_cnf.max_register = nblob->data_size - 1;
+
+   map = devm_regmap_init(dev,
+  &nvmem_blob_regmap_bus,
+  nblob,
+  &rm_cnf);
+   if (IS_ERR(map)) {
+   dev_dbg(dev, "Failed to initilize regmap\n");
+   return PTR_ERR(map);
+   }
+
+   nv_cnf.name = "nvmem-blob";
+   nv_cnf.read_only = true;
+   nv_cnf.dev = dev;
+   nv_cnf.owner = THIS_MODULE;
+
+   nvmem = nvmem_register(&nv_cnf);
+   if (IS_ERR(nvmem)) {
+   dev_dbg(dev, "Filed to register nvmem device\n");
+   return PTR_ERR(nvmem);
+   }
+
+   platform_set_drvdata(pdev, nblob);
+   return 0;
+}
+
+static int nvmem_blob_remove(struct platform_device *pdev)

[RFC 0/3] Proposed extensions for NVMEM

[Andrey Smirnov]

Hello,

This RFC introduces two new drivers to NVMEM subsytem. First driver,
'nvmem-blob', serves the purpose of exposing data, embedded in DTB,
via NVMEM consumer API. Second, 'nvmem-composite', allows the user to
combin a number of NVMEM cells (or parts of them) into a single
continuos "blob" of data presented to the rest of the system as a
regular NVMEM device.

The intent of this RFC is to solicit feedback about the approach,
binding or if these features should be accepted upstream in general.

I originally proposed this extentions as a part of Barebox project (Barebox
borrows a lot of concepts from Linux kernel and adopting NVMEM
subsystem was being discussed), in order to facilitate usage of NVMEM
to initialize source of MAC address for a paticular Ethernet adapter
(Barebox would read that value and fixup DT blob with appropriate
value as a part of booting Linux). However the drivers should be
generic enough to not be tied to that case.

Please bear in mind the the code included is a very rough draft and a
lot of error checking/handling code in is was stubbed out.

Any feedback is welcome.

Thank you,
Andrey Smirnov

Andrey Smirnov (3):
  nvmem: Add 'of_nvmem_cell_from_device_node()'
  nvmem: Add 'nvmem-blob' driver
  nvmem: Add 'nvmem-composite' driver

 Documentation/devicetree/bindings/nvmem/blob.txt   |  35 
 .../devicetree/bindings/nvmem/composite.txt|  44 
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/blob.c   | 132 
 drivers/nvmem/composite.c  | 228 +
 drivers/nvmem/core.c   |  44 ++--
 include/linux/nvmem-consumer.h |   7 +
 7 files changed, 479 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/nvmem/blob.txt
 create mode 100644 Documentation/devicetree/bindings/nvmem/composite.txt
 create mode 100644 drivers/nvmem/blob.c
 create mode 100644 drivers/nvmem/composite.c

-- 
2.5.0

[RFC 3/3] nvmem: Add 'nvmem-composite' driver

[Andrey Smirnov]

Add 'nvmem-composite' driver which allows to combine multiple chunks of
various NVMEM cells into a single continuous NVMEM device.

Signed-off-by: Andrey Smirnov 
---
 .../devicetree/bindings/nvmem/composite.txt|  44 
 drivers/nvmem/Makefile |   1 +
 drivers/nvmem/composite.c  | 228 +
 3 files changed, 273 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/composite.txt
 create mode 100644 drivers/nvmem/composite.c

diff --git a/Documentation/devicetree/bindings/nvmem/composite.txt 
b/Documentation/devicetree/bindings/nvmem/composite.txt
new file mode 100644
index 000..e24cf4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/composite.txt
@@ -0,0 +1,44 @@
+= NVMEM cell compositor =
+
+This binding is designed to provide a way for a developer to combine
+portions of other NVMEM cell and acces that data as a signle NVMEM
+cell using NVMEM consumer API.
+
+Required properties:
+- compatible: should be "nvmem-composite"
+- layout: specifies which sources comprise data in nvmem device
+ format is ""
+
+= Data cells =
+Are child nodes of nvmem-composite, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   composite-nvmem {
+   compatible = "nvmem-composite";
+   layout = <&another_cell_a 0 2
+ &another_cell_b 0 1
+ &another_cell_c 3 2>;
+
+   cell1: cell@0 {
+   reg = <0 5>;
+   };
+   }
+
+the result of reading variable cell1 would be:
+
+[a[0] a[1] b[0] c[3] c[4]],
+
+where a[i], b[i], c[i], represnet i-th bytes of NVMEM cells
+another_cell_a, another_cell_b and another_cell_c respectively
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   a-node {
+   nvmem-cells = <&cell1>;
+   nvmem-cell-names = "some-data";
+   };
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 1a1adba..49c0eca 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -19,3 +19,4 @@ nvmem_sunxi_sid-y := sunxi_sid.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-y += blob.o
+obj-y += composite.o
diff --git a/drivers/nvmem/composite.c b/drivers/nvmem/composite.c
new file mode 100644
index 000..5c29923
--- /dev/null
+++ b/drivers/nvmem/composite.c
@@ -0,0 +1,228 @@
+#define DEBUG 1
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct nvmem_composite {
+   struct device *dev;
+   struct list_head layout;
+   size_t layout_size;
+};
+
+struct nvmem_composite_item {
+   struct nvmem_cell *cell;
+   unsigned int idx, start, end, size;
+   struct list_head node;
+};
+
+static struct nvmem_composite_item *
+nvmem_composite_find_first(struct nvmem_composite *ncomp,
+  unsigned int offset)
+{
+   struct nvmem_composite_item *first;
+   list_for_each_entry(first, &ncomp->layout, node) {
+   /* 
+* Skip all of the irrelevant items that end before our offset
+*/
+   if (first->end > offset)
+   return first;
+   }
+
+   return NULL;
+}
+
+static int nvmem_composite_read(void *context,
+   const void *reg, size_t reg_size,
+   void *val, size_t val_size)
+{
+   int ii;
+   struct nvmem_composite *ncomp = context;
+   const unsigned int offset = *(u32 *)reg;
+   void *dst = val;
+   size_t residue = val_size;
+   struct nvmem_composite_item *item, *first;
+   uint8_t *data;
+   size_t size, chunk;
+
+
+   first = item = nvmem_composite_find_first(ncomp, offset);
+   if (!first) {
+   dev_dbg(ncomp->dev, "Invalid offset\n");
+   return -EINVAL;
+   }
+
+   list_for_each_entry_from(item, &ncomp->layout, node) {
+   /* 
+* If our first read is not located on item boundary
+* we have to introduce artificial offset
+*/
+   ii = (item == first) ? offset - first->start : 0;
+
+   data = nvmem_cell_read(item->cell, &size);
+   if (IS_ERR(data)) {
+   dev_dbg(ncomp->dev, "Failed to read nvmem cell\n");
+   return PTR_ERR(data);
+   }
+
+   chunk = min(residue, item->size - ii);
+   memcpy(dst, &data[item->idx + ii], chunk);
+   kfree(data);
+
+   dev_dbg(ncomp->dev, "chunk %u\n", chunk);
+
+   dst += chunk;
+   residue -= chunk;
+   }
+
+   return (residue) ? -EINVAL : 0;
+}
+
+static int nvmem_composite_write(void *context, const void *data,
+ 

Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document

[Ray Jui]

On 2/22/2016 11:41 AM, Scott Branden wrote:

My comments below

On 16-02-22 11:36 AM, Dmitry Torokhov wrote:

On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:

On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring  wrote:

On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Hence touchscreen dt node bindings document is updated to take care
of above changes in the touchscreen driver.

Signed-off-by: Raveendra Padasalagi

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57
+++---
  1 file changed, 51 insertions(+), 6 deletions(-)

diff --git
a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt

index 34e3382..f530c25 100644
---
a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt

+++
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt

@@ -1,12 +1,30 @@
  * Broadcom's IPROC Touchscreen Controller

  Required properties:
-- compatible: must be "brcm,iproc-touchscreen"
-- reg: physical base address of the controller and length of
memory mapped
-  region.
+- compatible: should be one of
+"brcm,iproc-touchscreen"
+"brcm,iproc-touchscreen-syscon"


More specific and this is not how you do syscon. Either the block is or
isn't. You can't have it both ways.


Existing driver has support for reg, if we modify now to support only
syscon
then this driver will not work if some one wishes to use previous
kernel version's
dt and vice versa. Basically this breaks dt compatibility. Is that ok ?


But the issue is that the driver does not actually work correctly with
direct register access on those systems, since the registers are
actually shared with other components. I am not quite sure if it is OK
to break DT binding in this case...


The driver does work correctly with direct register access on those
systems because the other components using those registers are not
active in those systems - so syscon is not needed in those cases.

I'm ok with not containing backwards compatibility though and always
using syscon.  There are no deployed systems using older versions of the
upstreamed kernel.


Thanks.



Regards,
Scott


The iproc touchscreen is currently activated in the "bcm9hmidc.dtsi" 
that represents the optional daughter card installed on reference boards 
bcm958300k and bcm958305k. While not maintaining backwards compatibility 
*might not* be a serious issue, it would be nice if we can at least make 
sure the driver change and DT are merged into the same kernel version so 
they stay in sync.


Going forward, if we are only going to support syscon based 
implementation, the existing compatible string "brcm,iproc-touchscreen" 
is preferred over "brcm,iproc-touchscreen-syscon".


Thanks,

Ray

Re: [PATCH] Input: pwm-beeper - defer pwm config if pwm can sleep

[Dmitry Torokhov]

On Wed, Feb 17, 2016 at 02:19:26PM +0100, Manfred Schlaegl wrote:
> If the pwm can sleep defer actions to it using a worker.
> A similar approach was used in leds-pwm (c971ff185)
> 
> Trigger:
> On a Freescale i.MX53 based board we ran into "BUG: scheduling while
> atomic" because input_inject_event locks interrupts, but
> imx_pwm_config_v2 sleeps.
> 
> Tested on Freescale i.MX53 SoC with 4.5-rc1 and 4.1.
> 
> Unmodified applicable to
>  * 4.5-rc4
>  * 4.4.1 (stable)
>  * 4.3.5 (stable)
>  * 4.1.18 (longterm)
> 
> Modified applicable to
>  * 3.18.27 (longterm)
> 
> Signed-off-by: Manfred Schlaegl 
> ---
>  drivers/input/misc/pwm-beeper.c | 62 
> +
>  1 file changed, 44 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index f2261ab..c160b5e 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -20,21 +20,42 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct pwm_beeper {
>   struct input_dev *input;
>   struct pwm_device *pwm;
> + struct work_struct work;
>   unsigned long period;
> + bool can_sleep;

I wonder if it is not better to always schedule work, regardless of
whether PWM may sleep or not.

Thanks.

-- 
Dmitry

Re: [PATCH] misc: ad525x_dpot: Fix the enabling of the "otpXen" attributes

[Greg Kroah-Hartman]

On Mon, Feb 22, 2016 at 09:58:27AM +0100, Michael Hennerich wrote:
> On 11/19/2015 09:22 AM, Michael Hennerich wrote:
> >On 11/18/2015 05:16 PM, Dan Bogdan Nechita wrote:
> >>Currently writing the attributes with "echo" will result in comparing:
> >>"enabled\n" with "enabled\0" and attribute is always set to false.
> >>
> >>Use the sysfs_streq() instead because it treats both NUL and
> >>new-line-then-NUL as equivalent string terminations.
> >>
> >>Signed-off-by: Dan Bogdan Nechita 
> >
> >Acked-by: Michael Hennerich 
> 
> 
> Looks like to patch got lost?

If so, please resend it, I don't see it here in my queue, sorry.

greg k-h

Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document

[Scott Branden]

My comments below

On 16-02-22 11:36 AM, Dmitry Torokhov wrote:

On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:

On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring  wrote:

On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Hence touchscreen dt node bindings document is updated to take care
of above changes in the touchscreen driver.

Signed-off-by: Raveendra Padasalagi 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++---
  1 file changed, 51 insertions(+), 6 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
 
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
index 34e3382..f530c25 100644
--- 
a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
+++ 
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
@@ -1,12 +1,30 @@
  * Broadcom's IPROC Touchscreen Controller

  Required properties:
-- compatible: must be "brcm,iproc-touchscreen"
-- reg: physical base address of the controller and length of memory mapped
-  region.
+- compatible: should be one of
+"brcm,iproc-touchscreen"
+"brcm,iproc-touchscreen-syscon"


More specific and this is not how you do syscon. Either the block is or
isn't. You can't have it both ways.


Existing driver has support for reg, if we modify now to support only syscon
then this driver will not work if some one wishes to use previous
kernel version's
dt and vice versa. Basically this breaks dt compatibility. Is that ok ?


But the issue is that the driver does not actually work correctly with
direct register access on those systems, since the registers are
actually shared with other components. I am not quite sure if it is OK
to break DT binding in this case...


The driver does work correctly with direct register access on those 
systems because the other components using those registers are not 
active in those systems - so syscon is not needed in those cases.


I'm ok with not containing backwards compatibility though and always 
using syscon.  There are no deployed systems using older versions of the 
upstreamed kernel.


Thanks.



Regards,
Scott

Re: Implement character sets for sscanf()

[Jessica Yu]

+++ Andy Shevchenko [22/02/16 11:27 +0200]:

On Fri, 2016-02-19 at 20:20 -0500, Jessica Yu wrote:

Hi,

This patch adds support for the '%[' conversion specifier for
sscanf().
Since functions that calculate substring lengths based on accepted or
rejected characters already exist in the kernel (namely strspn() and
strcspn()), it's not much of a stretch to add some basic support for
the
bracket '%[' conversion specifier for sscanf(). This is useful in
cases
where we'd like to match substrings delimited by something other than
spaces. The original motivation for this patch actually came from
livepatch
(https://lkml.org/lkml/2016/2/8/790), where we were trying to come up
with
a clean way to parse symbol names with substrings delimited by
periods and
commas.

Patch based on linux-next-20160219.

Here are some test cases:


Test cases should land into lib/test_scanf.c and be submitted as a
separate patch.

Also, you have something misconfigured when you sent patches. git-send-
email usually does a perfect job.


Thanks for the tip. Yeah, I had a small hiccup with git-send-email,
which is why the patchset came out like that :-\ In any case, the
attached test cases are more for the benefit of the patch reviewer,
not something I intended to be merged. For v2, I will just send the
single patch out.

Jessica

Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

[Tony Lindgren]

* John Ogness  [160222 07:30]:
> Hi Tony,
> 
> On 2016-02-11, Tony Lindgren  wrote:
> >> At these speeds, nearly every DMA interrupt is accompanied by a
> >> spurious UART interrupt. So, sadly, the interrupts are doubled.
> >> 
> >> It is on my TODO list to verify if the spurious UART interrupts
> >> exactly match the recently added [0] spurious interrupt detection in
> >> omap-intc.
> >
> > If you're seeing spurious interrupts you may want try adding
> > a flush of posted write at the end of the 8250_omap interrupt
> > handler. Basically read back some register from the 8250. This
> > has fixed so far pretty much all the spurious IRQ issues for
> > omaps using the drivers/irqchip/irq-omap-intc.c, meaning omap3
> > and am335x and ti81xx variants too most likely.
> 
> I have done significant testing with this using linux-next-20160219. The
> only changes I made were to disable the "rx_dma_broken" feature so that
> DMA would definately be used. I created a simple test where I send 48000
> bytes at 230400bps over UART from one device to another. Several
> different target devices and configurations were used to test the RX-DMA
> feature of the 8250_omap. The expected result is 1000 DMA interrupts and
> 0 UART interrupts.
> 
> With the am335x (Beaglebone Black, eDMA engine) I see 1000 DMA
> interrupts and 1000 spurious UART interrupts. The spurious UART
> interrupts arrive 30-50us _before_ the DMA interrupts. Always.
> 
> If I disable UART timeout interrupts (RDI), the same test generates no
> spurious UART interrupts. Only 1000 DMA interrupts.
> 
> I ran the same test using a dra7 board (sDMA engine) as the target
> device. RDI was enabled. Here I see no spurious interrupts.
> 
> I modified the dra7 device tree to use the eDMA engine with the
> UART. RDI was enabled. Here I also see no spurious interrupts.
> 
> The dra7 uses a different interrupt controller (irq-gic instead of
> irq-omap-intc), which probably explains why dra7+edma+rdi works
> correctly.
> 
> I tried adding various and multiple register reads at the end of the
> interrupt handlers, but this made no difference. What is interesting is
> the fact that the spurious UART interrupt always _preceeds_ the DMA
> interrupt and by a significant yet relatively consistent amount
> (30-50us). Even the very first DMA interrupt is preceeded by the
> spurious interrupt. It is as if the UART timeout logic is triggering
> because it does not notice that the eDMA is pulling the data from the
> FIFO. But only when the irq-omap-intc in involved.
> 
> Tony, if you have any futher ideas, I'd be happy to try them out.
> 
> Summary: If DMA is ever going to be re-enabled for am335x/8250_omap,
> then it will be necessary to return IRQ_HANDLED for the spurious UART
> interrupts that will preceed each DMA-RX completion interrupt.

Well thanks for checking, sounds like this is some UART specific
issue. I guess one more thing you could try is adding a read backs
to the functions staring the DMA transfers and see if that makes
any difference.

Regards,

Tony

Re: [PATCHv2 00/10] RFKill airplane-mode indicator

[João Paulo Rechi Vita]

On 22 February 2016 at 12:00, Dan Williams  wrote:
> On Mon, 2016-02-22 at 11:36 -0500, João Paulo Rechi Vita wrote:
>> This series implements an airplane-mode indicator LED trigger, which
>> can be
>> used by platform drivers. The default policy have have airplane-mode
>> set when
>> all the radios known by RFKill are OFF, and unset otherwise. This
>> policy can be
>> overwritten by one single userspace application at a time using the
>> operations
>> _AIRPLANE_MODE_INDICATOR_ACQUIRE and _AIRPLANE_MODE_INDICATOR_CHANGE.
>>
> Double-check your commit messages on some of these patches; they didn't
> get updated to add INDICATOR.
>

Thanks for catching this, Dan. I've sent an updated version fixing
this problem in reply to the patch where this slept through (9/10).

--
João Paulo Rechi Vita
http://about.me/jprvita

Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document

[Dmitry Torokhov]

On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:
> On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring  wrote:
> > On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
> >> In Cygnus SOC touch screen controller registers are shared
> >> with ADC and flex timer. Using readl/writel could lead to
> >> race condition. So touch screen driver is enhanced to support
> >>
> >> 1. If touchscreen register's are not shared. Register access
> >> is handled through readl/writel if "brcm,iproc-touchscreen"
> >> compatible is provided in touchscreen dt node. This will help
> >> for future SOC's if comes with dedicated touchscreen IP register's.
> >>
> >> 2. If touchscreen register's are shared with other IP's, register
> >> access is handled through syscon framework API's to take care of
> >> mutually exclusive access. This feature can be enabled by selecting
> >> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
> >> dt node.
> >>
> >> Hence touchscreen dt node bindings document is updated to take care
> >> of above changes in the touchscreen driver.
> >>
> >> Signed-off-by: Raveendra Padasalagi 
> >> Reviewed-by: Ray Jui 
> >> Reviewed-by: Scott Branden 
> >> ---
> >>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 
> >> +++---
> >>  1 file changed, 51 insertions(+), 6 deletions(-)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >>  
> >> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> index 34e3382..f530c25 100644
> >> --- 
> >> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> +++ 
> >> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> @@ -1,12 +1,30 @@
> >>  * Broadcom's IPROC Touchscreen Controller
> >>
> >>  Required properties:
> >> -- compatible: must be "brcm,iproc-touchscreen"
> >> -- reg: physical base address of the controller and length of memory mapped
> >> -  region.
> >> +- compatible: should be one of
> >> +"brcm,iproc-touchscreen"
> >> +"brcm,iproc-touchscreen-syscon"
> >
> > More specific and this is not how you do syscon. Either the block is or
> > isn't. You can't have it both ways.
> 
> Existing driver has support for reg, if we modify now to support only syscon
> then this driver will not work if some one wishes to use previous
> kernel version's
> dt and vice versa. Basically this breaks dt compatibility. Is that ok ?

But the issue is that the driver does not actually work correctly with
direct register access on those systems, since the registers are
actually shared with other components. I am not quite sure if it is OK
to break DT binding in this case...

Thanks.

-- 
Dmitry

[patch 6/6] Staging: gdm72xx: remove duplicate condition

[Dan Carpenter]

We know "len" is not zero because we tested for that at the beginning of
the function so this test can be removed.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/gdm_wimax.c 
b/drivers/staging/gdm72xx/gdm_wimax.c
index 6d647d6..09bf64e 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.c
+++ b/drivers/staging/gdm72xx/gdm_wimax.c
@@ -667,9 +667,8 @@ static void gdm_wimax_transmit_pkt(struct net_device *dev, 
char *buf, int len)
cmd_len = be16_to_cpup((const __be16 *)&buf[2]);
 
if (len < cmd_len + HCI_HEADER_SIZE) {
-   if (len)
-   netdev_err(dev, "%s: invalid length [%d/%d]\n",
-  __func__, cmd_len + HCI_HEADER_SIZE, len);
+   netdev_err(dev, "%s: invalid length [%d/%d]\n",
+  __func__, cmd_len + HCI_HEADER_SIZE, len);
return;
}
 

[patch 5/6] Staging: gdm72xx: underflow bug in gdm_wimax_ioctl_get_data()

[Dan Carpenter]

"size" here should be unsigned, otherwise we might end up trying to copy
negative bytes in gdm_wimax_ioctl_get_data() resulting in an information
leak.

Reported-by: Alan Cox 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/wm_ioctl.h 
b/drivers/staging/gdm72xx/wm_ioctl.h
index 631cb1d..032cb07 100644
--- a/drivers/staging/gdm72xx/wm_ioctl.h
+++ b/drivers/staging/gdm72xx/wm_ioctl.h
@@ -74,12 +74,12 @@ struct fsm_s {
 };
 
 struct data_s {
-   int size;
+   unsigned int size;
void*buf;
 };
 
 struct udata_s {
-   int size;
+   unsigned intsize;
void __user *buf;
 };
 

Re: [PATCH v2] base: isa: Remove X86_32 dependency

[Greg KH]

On Mon, Feb 22, 2016 at 07:39:36PM +0100, Thomas Gleixner wrote:
> On Sun, 21 Feb 2016, William Breathitt Gray wrote:
> 
> > On 01/27/2016 05:07 AM, Thomas Gleixner wrote:
> > > On Fri, 22 Jan 2016, William Breathitt Gray wrote:
> > >> Many motherboards utilize a LPC to ISA bridge in order to decode
> > >> ISA-style port-mapped I/O addresses. This is particularly true for
> > >> embedded motherboards supporting the PC/104 bus (a bus specification
> > >> derived from ISA).
> > >>
> > >> These motherboards are now commonly running 64-bit x86 processors. The
> > >> X86_32 dependency should be removed from the ISA bus configuration
> > >> option in order to support these newer motherboards.
> > >>
> > >> A new config option, CONFIG_ISA_BUS, is introduced to allow for the
> > >> compilation of the ISA bus driver independent of the CONFIG_ISA option.
> > >> Devices which communicate via ISA-compatible buses can now be supported
> > >> independent of the dependencies of the CONFIG_ISA option.
> > >>
> > >> Signed-off-by: William Breathitt Gray 
> > > 
> > > Reviewed-by: Thomas Gleixner 
> > 
> > What more can I do to help get this patch pulled in for the merge
> > window?
> 
> If Greg doesn't pick it up, I'll pull it into x86 later this week

It's not in my queue so I don't even have it here to pick up :(

[patch 4/6] staging: gdm72xx: zero out padding

[Dan Carpenter]

We pad the start of this buffer with 256 bytes of padding.   It's not
clear to me exactly what's going on or how it's used but let's zero it
out.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/usb_boot.c 
b/drivers/staging/gdm72xx/usb_boot.c
index 3082987..4431a80 100644
--- a/drivers/staging/gdm72xx/usb_boot.c
+++ b/drivers/staging/gdm72xx/usb_boot.c
@@ -286,7 +286,7 @@ static int em_download_image(struct usb_device *usbdev, 
const char *img_name,
return ret;
}
 
-   buf = kmalloc(DOWNLOAD_CHUCK + pad_size, GFP_KERNEL);
+   buf = kzalloc(DOWNLOAD_CHUCK + pad_size, GFP_KERNEL);
if (!buf) {
release_firmware(firm);
return -ENOMEM;

[patch 3/6] Staging: gdm72xx: make "len" unsigned

[Dan Carpenter]

We had an underflow bug here and I think I fixed it but we may as
well be proactive and make "len" unsigned to be double sure.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/gdm_wimax.h 
b/drivers/staging/gdm72xx/gdm_wimax.h
index 3330cd79..ed12813 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.h
+++ b/drivers/staging/gdm72xx/gdm_wimax.h
@@ -26,10 +26,10 @@
 struct phy_dev {
void*priv_dev;
struct net_device   *netdev;
-   int (*send_func)(void *priv_dev, void *data, int len,
+   int (*send_func)(void *priv_dev, void *data, size_t len,
 void (*cb)(void *cb_data), void *cb_data);
int (*rcv_func)(void *priv_dev,
-   void (*cb)(void *cb_data, void *data, int len),
+   void (*cb)(void *cb_data, void *data, size_t len),
void *cb_data);
 };
 
diff --git a/drivers/staging/gdm72xx/gdm_usb.h 
b/drivers/staging/gdm72xx/gdm_usb.h
index d864928..1456da0 100644
--- a/drivers/staging/gdm72xx/gdm_usb.h
+++ b/drivers/staging/gdm72xx/gdm_usb.h
@@ -49,7 +49,7 @@ struct usb_rx {
struct rx_cxt   *rx_cxt;
struct urb  *urb;
u8  *buf;
-   void (*callback)(void *cb_data, void *data, int len);
+   void (*callback)(void *cb_data, void *data, size_t len);
void *cb_data;
 };
 
diff --git a/drivers/staging/gdm72xx/gdm_usb.c 
b/drivers/staging/gdm72xx/gdm_usb.c
index 7f035b1..bbf3e70 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -284,7 +284,7 @@ static void gdm_usb_send_complete(struct urb *urb)
spin_unlock_irqrestore(&tx->lock, flags);
 }
 
-static int gdm_usb_send(void *priv_dev, void *data, int len,
+static int gdm_usb_send(void *priv_dev, void *data, size_t len,
void (*cb)(void *data), void *cb_data)
 {
struct usbwm_dev *udev = priv_dev;
@@ -341,7 +341,7 @@ static int gdm_usb_send(void *priv_dev, void *data, int len,
usb_fill_bulk_urb(t->urb, usbdev, usb_sndbulkpipe(usbdev, 1), t->buf,
  len + padding, gdm_usb_send_complete, t);
 
-   dev_dbg(&usbdev->dev, "usb_send: %*ph\n", len + padding, t->buf);
+   dev_dbg(&usbdev->dev, "usb_send: %*ph\n", (int)len + padding, t->buf);
 
 #ifdef CONFIG_WIMAX_GDM72XX_USB_PM
if (usbdev->state & USB_STATE_SUSPENDED) {
@@ -460,7 +460,7 @@ static void gdm_usb_rcv_complete(struct urb *urb)
 }
 
 static int gdm_usb_receive(void *priv_dev,
-  void (*cb)(void *cb_data, void *data, int len),
+  void (*cb)(void *cb_data, void *data, size_t len),
   void *cb_data)
 {
struct usbwm_dev *udev = priv_dev;
diff --git a/drivers/staging/gdm72xx/gdm_wimax.c 
b/drivers/staging/gdm72xx/gdm_wimax.c
index 1b3da2b..6d647d6 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.c
+++ b/drivers/staging/gdm72xx/gdm_wimax.c
@@ -701,7 +701,7 @@ static void gdm_wimax_transmit_pkt(struct net_device *dev, 
char *buf, int len)
}
 }
 
-static void rx_complete(void *arg, void *data, int len)
+static void rx_complete(void *arg, void *data, size_t len)
 {
struct nic *nic = arg;
 
@@ -709,7 +709,7 @@ static void rx_complete(void *arg, void *data, int len)
gdm_wimax_rcv_with_cb(nic, rx_complete, nic);
 }
 
-static void prepare_rx_complete(void *arg, void *data, int len)
+static void prepare_rx_complete(void *arg, void *data, size_t len)
 {
struct nic *nic = arg;
int ret;

[patch 2/6] Staging: gdm72xx: silence underflow warning in netlink_send()

[Dan Carpenter]

The value of "group" comes from "idx" in __gdm_wimax_event_send():

if (sscanf(e->dev->name, "wm%d", &idx) == 1)

Smatch marks sscanf values as user controlled.  It's supposed to be a
number in 0-30 range.  We cap the upper bound but allow negatives.  Fix
this by making it type u16 instead.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/netlink_k.h 
b/drivers/staging/gdm72xx/netlink_k.h
index 1fe7198..1914347 100644
--- a/drivers/staging/gdm72xx/netlink_k.h
+++ b/drivers/staging/gdm72xx/netlink_k.h
@@ -20,6 +20,6 @@
 struct sock *netlink_init(int unit, void (*cb)(struct net_device *dev, u16 
type,
   void *msg, int len));
 void netlink_exit(struct sock *sock);
-int netlink_send(struct sock *sock, int group, u16 type, void *msg, int len);
+int netlink_send(struct sock *sock, u16 group, u16 type, void *msg, int len);
 
 #endif /* __GDM72XX_NETLINK_K_H__ */
diff --git a/drivers/staging/gdm72xx/netlink_k.c 
b/drivers/staging/gdm72xx/netlink_k.c
index 4089b17..96c9034 100644
--- a/drivers/staging/gdm72xx/netlink_k.c
+++ b/drivers/staging/gdm72xx/netlink_k.c
@@ -114,7 +114,7 @@ void netlink_exit(struct sock *sock)
netlink_kernel_release(sock);
 }
 
-int netlink_send(struct sock *sock, int group, u16 type, void *msg, int len)
+int netlink_send(struct sock *sock, u16 group, u16 type, void *msg, int len)
 {
static u32 seq;
struct sk_buff *skb = NULL;

[PATCHv3] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

Provide an interface for the airplane-mode indicator be controlled from
userspace. User has to first acquire the control through
RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE and keep the fd open for the
whole time it wants to be in control of the indicator. Closing the fd
restores the default policy.

To change state of the indicator, the
RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE operation is used, passing the
value on "struct rfkill_event.soft". If the caller has not acquired the
airplane-mode control beforehand, the operation fails.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt| 10 ++
 include/uapi/linux/rfkill.h |  6 ++
 net/rfkill/core.c   | 35 +--
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index b13025a..9dbe3fc 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 An airplane-mode indicator LED trigger is also available, which triggers
 LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
+The airplane-mode indicator LED trigger policy can be overridden by userspace.
 
 
 5. Userspace support
@@ -123,5 +124,14 @@ RFKILL_TYPE
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
 
+Userspace can also override the default airplane-mode indicator policy through
+/dev/rfkill. Control of the airplane mode indicator has to be acquired first,
+using RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE, and is only available for one
+userspace application at a time. Closing the fd reverts the airplane-mode
+indicator back to the default kernel policy and makes it available for other
+applications to take control. Changes to the airplane-mode indicator state can
+be made using RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE, passing the new value
+in the 'soft' field of 'struct rfkill_event'.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h
index 2e00dce..36e0770 100644
--- a/include/uapi/linux/rfkill.h
+++ b/include/uapi/linux/rfkill.h
@@ -61,12 +61,18 @@ enum rfkill_type {
  * @RFKILL_OP_CHANGE_ALL: userspace changes all devices (of a type, or all)
  * into a state, also updating the default state used for devices that
  * are hot-plugged later.
+ * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE: userspace acquires control of
+ * the airplane-mode indicator.
+ * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE: userspace changes the
+ * airplane-mode indicator state.
  */
 enum rfkill_operation {
RFKILL_OP_ADD = 0,
RFKILL_OP_DEL,
RFKILL_OP_CHANGE,
RFKILL_OP_CHANGE_ALL,
+   RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE,
+   RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE,
 };
 
 /**
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 04d7fa1..8ea8b73 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -89,6 +89,7 @@ struct rfkill_data {
struct mutexmtx;
wait_queue_head_t   read_wait;
boolinput_handler;
+   boolis_apm_owner;
 };
 
 
@@ -123,7 +124,7 @@ static struct {
 } rfkill_global_states[NUM_RFKILL_TYPES];
 
 static bool rfkill_epo_lock_active;
-
+static bool rfkill_apm_owned;
 
 #ifdef CONFIG_RFKILL_LEDS
 static struct led_trigger rfkill_apm_led_trigger;
@@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
-   rfkill_apm_led_trigger_event(blocked);
+   if (!rfkill_apm_owned)
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1180,9 +1182,23 @@ static ssize_t rfkill_fop_read(struct file *file, char 
__user *buf,
return ret;
 }
 
+static int rfkill_airplane_mode_release(struct rfkill_data *data)
+{
+   bool state = rfkill_global_states[RFKILL_TYPE_ALL].cur;
+
+   if (rfkill_apm_owned && data->is_apm_owner) {
+   rfkill_apm_owned = false;
+   data->is_apm_owner = false;
+   rfkill_apm_led_trigger_event(state);
+   return 0;
+   }
+   return -EACCES;
+}
+
 static ssize_t rfkill_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *pos)
 {
+   struct rfkill_data *data = file->private_data;
struct rfkill *rfkill;
struct rfkill_event ev;
int ret = 0;
@@ -1218,6 +1234,20 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
if (rfkill->idx == ev.idx && rfkill->type == ev.type)
rf

[patch 1/6] staging: gdm72xx: underflow in netlink_rcv_cb()

[Dan Carpenter]

If nlh->nlmsg_len is less than ND_IFINDEX_LEN we end up trying to memcpy
a negative size.  I also re-ordered slighty the condition to make it
more uniform.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/gdm72xx/netlink_k.c 
b/drivers/staging/gdm72xx/netlink_k.c
index cf0b47c..4089b17 100644
--- a/drivers/staging/gdm72xx/netlink_k.c
+++ b/drivers/staging/gdm72xx/netlink_k.c
@@ -55,7 +55,8 @@ static void netlink_rcv_cb(struct sk_buff *skb)
if (skb->len >= NLMSG_HDRLEN) {
nlh = (struct nlmsghdr *)skb->data;
 
-   if (skb->len < nlh->nlmsg_len ||
+   if (nlh->nlmsg_len < ND_IFINDEX_LEN ||
+   nlh->nlmsg_len > skb->len ||
nlh->nlmsg_len > ND_MAX_MSG_LEN) {
netdev_err(skb->dev, "Invalid length (%d,%d)\n",
   skb->len, nlh->nlmsg_len);

Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

[Kees Cook]

On Fri, Feb 19, 2016 at 3:07 PM, Laura Abbott  wrote:
> On 02/19/2016 02:19 PM, Kees Cook wrote:
>>
>> On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott  wrote:
>>>
>>> On 02/19/2016 11:12 AM, Kees Cook wrote:


 On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott
 
 wrote:
>
>
>
> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE
> test to test free poisoning features. Sample output when
> no sanitization is present:
>
> [   22.414170] lkdtm: Performing direct entry READ_AFTER_FREE
> [   22.415124] lkdtm: Value in memory before free: 12345678
> [   22.415900] lkdtm: Attempting to read from freed memory
> [   22.416394] lkdtm: Successfully read value: 12345678
>
> with sanitization:
>
> [   25.874585] lkdtm: Performing direct entry READ_AFTER_FREE
> [   25.875527] lkdtm: Value in memory before free: 12345678
> [   25.876382] lkdtm: Attempting to read from freed memory
> [   25.876900] general protection fault:  [#1] SMP
>
> Signed-off-by: Laura Abbott 



 Excellent! Could you mention in the changelog which CONFIG (or runtime
 values) will change the lkdtm test? (I thought there was a poisoning
 style that would result in a zero-read instead of a GP?)

>>>
>>> There was a zeroing patch in the first draft but given the direction
>>> things are going, I don't see it going in. I'll mention the debug
>>> options which will show this though.
>>
>>
>> Ah! Okay, I was having trouble following what was happening. What's
>> the current state of the use-after-free protections you've been
>> working on?
>
>
> Based on discussion, the SL*B maintainers want to use the existing
> slab poisoning features instead adding in new hooks. They also don't
> want the fast path to be affected at all. This means most of the
> actual work there is improving the performance of slub_debug=P. I
> sent out patches for some low hanging fruit in SLUB which improved
> the performance by a good bit. Those have been Acked and are sitting
> in Andrew's tree. The next performance work involves more in depth
> tinkering with the SLUB allocator. Apart from just performance, the
> other work would be poisoning for caches with ctors in SLUB and
> poisoning in SLOB. I could use some help with benchmarking some
> actual use cases to see how usable slub_debug=P would be on some
> use cases.
>
> I did sent out patches for the buddy allocator as well. The last

This must be where my confusion stems. :) IIUC, the buddy allocator is
used within the SL*B logic when splitting/joining regions? Can we add
an lkdtm test for this too?

> version I sent out didn't get much in the way of feedback except
> for some requests for benchmarks on the zeroing. I was planning
> on following up on that next week to see if there was any more feedback
> and beg for Acks.

If you can point me at the current tree, I'd be happy to run some benchmarks.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH] drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Lyude]

These warnings still seem to be present with DP MST configurations. They
don't actually indicate any impending doom, so we may as well use
I915_STATE_WARN_ON() here to help quiet things down a little bit for
distro kernel users.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a234687..1870185 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3545,7 +3545,7 @@ static void skl_update_other_pipe_wm(struct drm_device 
*dev,
 * because it was really needed, so we expect the WM values to
 * be different.
 */
-   WARN_ON(!wm_changed);
+   I915_STATE_WARN_ON(!wm_changed);
 
skl_compute_wm_results(dev, &pipe_wm, r, intel_crtc);
r->dirty[intel_crtc->pipe] = true;
-- 
2.5.0

Re: Computer fails to resume from suspend unless I rmmod jme before initiating the suspend

[Pavel Machek]

On Mon 2016-02-22 15:59:48, Diego Viola wrote:
> On Mon, Feb 22, 2016 at 7:09 AM, Pavel Machek  wrote:
> > Hi!
> >
> >>  Every time I initiate a suspend (systemctl suspend) the machine hangs
> >>  at resume unless I unload the jme driver.
> >
> > It seems to have some kind of suspend/resume support. ... and it is
> > rather complex.
> >
> > Maybe jme_start_irq(jme) should be moved to the end of jme_resume
> > function?
> >
> >> > So I found that disabling async as in:
> >> >
> >> > $ echo 0 > /sys/power/pm_async
> >> >
> >> > Helps with my issue, I can't reproduce the hang anymore, tried
> >> > suspend/resume almost ~15 times.
> >> >
> >> > Diego
> >>
> >> Can someone please help?
> 
> Hi Pavel,
> 
> This did the trick, suspend/resume is now working perfectly for me
> (tried more than 10 times). :)
> 
> Thank you so much, should I send a patch?

Yes please.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH][QUESTION] Intentional memory leak in ipmi_msghandler?

[Calvin Owens]

On Friday 02/19 at 07:14 -0600, Corey Minyard wrote:
> On 02/19/2016 12:41 AM, Calvin Owens wrote:
> >Hello,
> >
> >I've got a few boxes that are leaking memory in handle_new_recv_msgs()
> >in ipmi_msghandler. AFAICS this is intentional, there's even an explicit
> >counter that tracks the number of times smi_msg is leaked.
> 
> Are you 100% sure about this? 

I'm absolutely certain this is where I'm leaking: I threw in a printk()
and saw exact correlation between the number of times I saw that and the
number of kmalloc-1024 objects leaked. But...

> There's no intentional leak, a negative return from this function
> means the message was used for another purpose and thus shouldn't be
> freed.  There's only one situation where this happens and you should
> never hit it in normal operation.

This is actually extremely helpful: we have some horrible non-upstream code
behind this that I thought I had ruled out being at fault here, but this
sounds like it might be. In any case, I won't waste your time any more
until I can reproduce it on upstream (which is unfortunately impossible
on this particular HW I see the leak on, otherwise I would have done that
in the first place...).

Thanks very much for the prompt response, I really appreciate it.

Calvin

> >I'm guessing there was a reason for doing this, but there wasn't any
> >discussion about it on LKML when the patch was accepted. Can you clarify
> >why something like the below patch won't work? I tried it on one of my
> >leaky boxes and nothing obviously horrible happened.
> 
> Well, that's because nothing probably happened, and it probably had no
> effect on the leak.  A better comment on this code is probably in
> order.  But that patch is incorrect.
> 
> I doubt the leak is here.  If you are having a leak, is it possible to
> characterize it better?  Are you handling commands from IPMB?  Are you
> handling LAN commands here?
> 
> -corey
> 
> >
> >Thanks,
> >Calvin
> >
> >8<
> >From: Calvin Owens 
> >Subject: [PATCH] ipmi_msghandler: Don't leak memory on errors
> >
> >Signed-off-by: Calvin Owens 
> >---
> >  drivers/char/ipmi/ipmi_msghandler.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> >diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
> >b/drivers/char/ipmi/ipmi_msghandler.c
> >index 94fb407..ed82ffa 100644
> >--- a/drivers/char/ipmi/ipmi_msghandler.c
> >+++ b/drivers/char/ipmi/ipmi_msghandler.c
> >@@ -3834,10 +3834,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
> > break;
> > } else {
> > list_del(&smi_msg->link);
> >-if (rv == 0)
> >-/* Message handled */
> >-ipmi_free_smi_msg(smi_msg);
> >-/* If rv < 0, fatal error, del but don't free. */
> >+ipmi_free_smi_msg(smi_msg);
> > }
> > }
> > if (!run_to_completion)
> 

Re: [PATCH 1/2] ARM: dts: am57xx-beagle-x15: Add eeprom information

[Tony Lindgren]

* Nishanth Menon  [160222 08:51]:
> Add EEPROM at 0x50 that describes the board configuration.
> This is useful for userspace programs that may need to check board
> revision and other similar information.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 36c0fa6c362a..50312f80b972 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -591,6 +591,11 @@
>   DRVDD-supply = <&vdd_3v3>;
>   DVDD-supply = <&aic_dvdd>;
>   };
> +
> + eeprom: eeprom@50 {
> + compatible = "at,24c32";
> + reg = <0x50>;
> + };
>  };
>  

Applying into omap-for-v4.6/dt thanks.

Tony

Re: 4.5-rc4 kernel is failed to bootup on CN6880

[Yang Shi]

On 2/22/2016 4:43 AM, Aaro Koskinen wrote:

Hi,

On Fri, Feb 19, 2016 at 05:12:41PM -0800, Yang Shi wrote:

I tried to boot 4.5-rc4 kernel on my CN6880 board, but it is failed at
booting up secondary cores. The error is:

With v4.5-rc5, EBB6800 is booting fine:

[0.00] CPU0 revision is: 000d9108 (Cavium Octeon II)
[...]
[ 2286.273935] SMP: Booting CPU01 (CoreId  1)...
[ 2286.278201] CPU1 revision is: 000d9108 (Cavium Octeon II)
[...]
[ 2287.214953] SMP: Booting CPU31 (CoreId 31)...
[ 2287.224668] CPU31 revision is: 000d9108 (Cavium Octeon II)
[ 2287.224865] Brought up 32 CPUs


CPU31 revision is: 000d9101 (Cavium Octeon II)
SMP: Booting CPU32 (CoreId 32)...
Secondary boot timeout

I passed "numcores=32" in kernel commandline since there are 32 cores ion
CN6880.

You shouldn't have CPU32 in that case, the numbering starts from zero.
Also the coremask is 32-bit.

I can reproduce your issue with CONFIG_NR_CPUS=64. Possibly this code
is incorrect for NR_CPUS bigger than 32:

 /* The present CPUs get the lowest CPU numbers. */
 cpus = 1;
 for (id = 0; id < NR_CPUS; id++) {
 if ((id != coreid) && (core_mask & (1 << id))) {
 set_cpu_possible(cpus, true);
 set_cpu_present(cpus, true);

What CONFIG_NR_CPUS did you use?


Thanks. I did have 48 NR_CPUS set. It works when I changed it to 32.

I think the problem is core_mask is 32 bit. But when NR_CPUS > 32, in 
"core_mask & (1 << id)" core_mask will be sign extended, then the 
statement will return non-zero all the time.


Yang



A.

Re: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings

[Ard Biesheuvel]

On 22 February 2016 at 20:05, Dan Williams  wrote:
> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
>  wrote:
>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>> the kernel direct mapping, unless the region is in high memory, in which
>> case it falls back to using ioremap_cache(). However, the semantics of
>> ioremap_cache() are not unambiguously defined, and on ARM, it will
>> actually result in a mapping type that differs from the attributes used
>> for the linear mapping, and for this reason, the ioremap_cache() call
>> fails if the region is part of the memory managed by the kernel.
>>
>> So instead, implement an optional hook 'arch_memremap_wb' whose default
>> implementation calls ioremap_cache() as before, but which can be
>> overridden by the architecture to do what is appropriate for it.
>>
>
> Acked-by: Dan Williams 
>
> I still have patches pending to delete ioremap_cache() from ARM and
> require memremap() to be used for cacheable mappings.  Do you see any
> use for ioremap_cache() on ARM after this change?

I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
attributes, but the ARM architecture simply does not allow mismatched
attributes, so we cannot simply replace each instance of
ioremap_cache() with memremap()

Perhaps Russell can explain?

Re: [PATCH] irqchip: irq-mvebu-odmi: new driver

[Rob Herring]

On Mon, Feb 22, 2016 at 2:10 AM, Thomas Petazzoni
 wrote:
> Hello,
>
> FWIW, you're replying to the v1 of this patch, while v2 and v3 have
> already been posted, and v3 has already been merged by the irqchip
> maintainers:
>
>   
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=c27f29bbbf02168c9b1e8ba0fe7a8cb917e5a50f

Well, that's what you get when I'm working offline for a bit. :)

> On Sun, 21 Feb 2016 20:53:53 -0600, Rob Herring wrote:
>
>> > +- compatible  : The value here should contain 
>> > "marvell,odmi-controller".
>>
>> SoC specific compatible too please.
>
> I can add that in a follow-up patch.

Please do.

>
>> > +- marvell,spi-base : List of GIC base SPI interrupts, one for each
>> > + ODMI frame.
>>
>> Why not "interrupts" property?
>
> This has already been discussed with Arnd in a more recent iteration of
> the patch:
>
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409411.html
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409415.html
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409430.html

Okay, it's fine.

Rob

Re: [PATCH v3 00/12] pwm: add support for atomic update

[Doug Anderson]

Thierry,

On Mon, Feb 22, 2016 at 9:59 AM, Thierry Reding
 wrote:
>> This is because only some drivers would be able to read the hardware
>> state?  I'm not sure how we can get away from that.  In all proposals
>> we've talked about (including what you propose below, right?) the PWM
>> regulator will need a PWM driver that can read hardware state.  Only
>> PWM drivers that have been upgraded to support reading hardware state
>> can use the PWM regulator (or at least only those drivers will be able
>> to use the PWM regulator glitch-free).
>
> Yes, the key here is glitch-free. There's no reason whatsoever that the
> rugaltor-pwm driver should be limited to usage with a hardware readout-
> capable PWM driver. If you don't care about glitches, likely because no
> critical components depend on the regulator, you can simply force what
> state you choose on boot.
>
> As a matter of fact, I think that's how regulators work already. If the
> current output voltage doesn't match the specified constraints, then a
> valid value will be forced by the regulator core. If the voltage lies
> within the constraints the core won't touch the regulator. Is this not
> going to "just work" with the PWM regulator?
>
> The problem is somewhat simplified if that's the case. An implementation
> could then fail the regulator_get_voltage() if hardware readout is not
> supported and return the current voltage when readout is possible.

Based on looking at the current code, I believe it just returns 0V
until you call regulator_set_voltage() today.  I don't think that was
always the case.  Back before it was made continuous I think it
returned the voltage that matched with 0% duty cycle.

I haven't dug into what the regulator framework does in the current
system nor what happens if regulator_get_voltage() returns an error.
Perhaps Boris can dig / comment?


>> When we add a new feature then it's expected that only updated drivers
>> will support that feature.
>>
>> We need to make sure that we don't regress / negatively change the
>> behavior for anyone running non-updated drivers.  ...and we should
>> strive to require as few changes to drivers as possible.  ...but if
>> the best we can do requires changes to the PWM driver API then we will
>> certainly have differences depending on the PWM driver.
>
> How so? Drivers should behave consistently, irrespective of the API. Of
> course if you need to change behaviour of the user driver depending on
> the availability of a certain feature, that's perfectly fine.
>
> Furthermore it's out of the question that changes to the API will be
> required. That's precisely the reason why the atomic PWM proposal came
> about. It's an attempt to solve the shortcomings of the current API for
> cases such as Rockchip.

I _think_ we're on the same page here.  If there are shortcomings with
the current API that make it impossible to implement a feature, we've
got to change and/or add to the existing API.  ...but we don't want to
break existing users / drivers.

Note that historically I remember that Linus Torvalds has stated that
there is no stable API within the Linux kernel and that forcing the
in-kernel API to never change was bad for software development.  I
tracked down my memory and found
.  Linus is rabid about not
breaking userspace, but in general there's no strong requirement to
never change the driver API inside the kernel.  That being said,
changing the driver API causes a lot of churn, so presumably changing
it in a backward compatible way (like adding to the API instead of
changing it) will make things happier.


>> That means that if you call pwm_get_period() right away at boot time
>> you're not getting the current period of the hardware but the period
>> that was specified in the device tree.
>
> Yes.
>
>> So all we need is a new API call that lets you read the hardware
>> values and make sure that the PWM regulator calls that before anyone
>> calls pwm_config().  That's roughly B) above.
>
> Yes. I'm thinking that we should have a pwm_get_state() which retrieves
> the current state of the PWM. For drivers that support hardware readout
> this state should match the hardware state. For other drivers it should
> reflect whatever was specified in DT; essentially what pwm_get_period()
> and friends return today.

Excellent, so pwm_get_period() gets the period as specified in the
device tree (or other board config) and pwm_get_state() returns the
hardware state.  SGTM.


> That way if you want to get the current voltage in the regulator-pwm
> driver you'd simply do a pwm_get_state() and compute the voltage from
> the period and duty cycle. If the PWM driver that you happen to use
> doesn't support hardware readout, you'll get an initial output voltage
> of 0, which is as good as any, really.

Sounds fine to me.  PWM regulator is in charge of calling
pwm_get_state(), which can return 0 (or an error?) if driver (or
underlying hardware) doesn't support har

Re: [patch V2 28/28] x86/perf/intel/rapl: Make it modular

[Thomas Gleixner]

Andi,

On Mon, 22 Feb 2016, Andi Kleen wrote:

> Thomas Gleixner  writes:
> 
> > Add the necessary exit functions so it can be built as a module.
> 
> If you make it a module you also need to add MODULE_DEVICE_TABLE
> for the PCI IDs and also add x86_cpu_id tables/annotations
> for the model numbers.
> 
> Otherwise the module would always need to be loaded manually
> which would break existing setups.

I know. That's why I made the default Yes. We can drop that patch or add some
explanation to the help text that 'M' is for manual module loading until
someone adds the necessary magic for auto probing.

Thanks,

tglx

Re: [GIT PULL] remaining tpmdd fixes for Linux 4.5

[Jason Gunthorpe]

On Mon, Feb 22, 2016 at 09:08:28PM +0200, Jarkko Sakkinen wrote:
> On Mon, Feb 22, 2016 at 10:52:45AM -0700, Jason Gunthorpe wrote:
> > On Mon, Feb 22, 2016 at 04:50:23PM +0200, Jarkko Sakkinen wrote:
> > 
> > > I already pushed a fix to my master for this issue:
> > > 
> > > https://github.com/jsakkine/linux-tpmdd/commit/6386544ad7bceb3d0248b85da29d4d99eebe9161
> > 
> > The goal is to reduce the number of #ifdef'd code segments so we have
> > fewer problems in future with a large .config test matrix.
> > 
> > I'd rather see a __maybe_unused annotation instead.
> 
> Agreed that it's a better form but at this point it's probably revert
> the breaking change and move to that later on. Otherwise, I don't see
> reason not to include the patch that you authored to the release. I've
> used it in my test kernels for quite some time now and it has worked
> without issues.
> 
> I sent my fix for review now.

A warning with some kconfigs is very minor, we can take the time to
fix it properly for 4.6.

I am surprised the 0day -next builds/etc didn't notice this - Jarkko is
your tree included in that process somehow? (sorry, I don't remember
the details)

Jason

Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Takashi Iwai]

On Mon, 22 Feb 2016 19:58:18 +0100,
Martin Kepplinger wrote:
> 
> Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> > On Mon, 22 Feb 2016 15:02:56 +0100,
> > Martin Kepplinger wrote:
> >>> And how about my questions in the previous mail?  Does
> >>> i915_audio_component_get_eld() is called and returns 0?
> >>> And is monitor_present set true or false?
> >>
> >> i915_audio_component_get_eld() returns 0 and monitor_present is 0.
> >>>
> >>> If i915_audio_component_get_eld() is called but returns zero, track
> >>> the code flow there.  It means either intel_encoder is NULL or
> >>> intel_dig_port->audio_connector is NULL.
> >>
> >> intel_dig_port->audio_connector is NULL!
> >>
> >> (when called during boot and during HDMI plugin)
> > 
> > Interesting.  The relevant code flow should be like:
> > 
> >   intel_audio_codec_enable()
> >   -> acomp->audio_ops->pin_eld_notify()
> > -> intel_pin_eld_notify()
> >   -> check_presence_and_report()
> > -> hdmi_present_sense()
> >   -> sync_eld_via_acomp()
> > -> snd_hdac_acomp_get_eld()
> >   -> i915_audio_component_get_eld()
> > 
> > So, at first, check whether intel_dig_port in both
> > intel_audio_codec_enable() and i915_audio_component_get_eld() points
> > to the same object address.  The audio_connector must be set in
> > intel_audio_codec_enable(), thus basically it must be non-NULL at
> > i915_audio_component_get_eld(), too.
> > 
> 
> intel_dig_port is *not* the same object in these 2 places. During
> plugin, see:
> 
> [  146.934091] in intel_audio_codec_enable: intel_dig_port is
> 8800a1f54000
> [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
> 880244f7d000
> 
> sorry for the slow responses. I'll try to go back that direction unless
> again someone comes up with other suggestions.

Thanks, this makes sense.  It implies that the digital port mapping is
somehow wrong.  There are three places setting dig_port_map[], one in
intel_ddi_init(), one in intel_dp_init() and another in
intel_hdmi_init().  Try to check which function creates which object
assigned to which port number, together with drm.debug=0x0e debug
messages.


Takashi

Re: [PATCH v2 2/2] bmips: add device tree example for BCM6358

[Rob Herring]

On Sun, Feb 21, 2016 at 12:41:21PM +0100, Álvaro Fernández Rojas wrote:
> This adds a device tree example for SFR Neufbox4 (Sercomm version), which
> also serves as a real example for brcm,bcm6358-leds.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  v2: Remove led0 alias and use stdout-path only
> 
>  .../devicetree/bindings/mips/brcm/soc.txt  |   2 +-
>  arch/mips/bmips/Kconfig|   4 +
>  arch/mips/boot/dts/brcm/Makefile   |   2 +
>  arch/mips/boot/dts/brcm/bcm6358.dtsi   | 111 
> +
>  arch/mips/boot/dts/brcm/bcm96358nb4ser.dts |  46 +
>  5 files changed, 164 insertions(+), 1 deletion(-)
>  create mode 100644 arch/mips/boot/dts/brcm/bcm6358.dtsi
>  create mode 100644 arch/mips/boot/dts/brcm/bcm96358nb4ser.dts

A couple of minor things, otherwise:

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt 
> b/Documentation/devicetree/bindings/mips/brcm/soc.txt
> index 7bab90c..e58a4f6 100644
> --- a/Documentation/devicetree/bindings/mips/brcm/soc.txt
> +++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
> @@ -4,7 +4,7 @@ Required properties:
>  
>  - compatible: "brcm,bcm3384", "brcm,bcm33843"
>"brcm,bcm3384-viper", "brcm,bcm33843-viper"
> -  "brcm,bcm6328", "brcm,bcm6368",
> +  "brcm,bcm6328", "brcm,bcm6358", "brcm,bcm6368",
>"brcm,bcm7125", "brcm,bcm7346", "brcm,bcm7358", "brcm,bcm7360",
>"brcm,bcm7362", "brcm,bcm7420", "brcm,bcm7425"
>  
> diff --git a/arch/mips/bmips/Kconfig b/arch/mips/bmips/Kconfig
> index e2c4fd6..264328d 100644
> --- a/arch/mips/bmips/Kconfig
> +++ b/arch/mips/bmips/Kconfig
> @@ -21,6 +21,10 @@ config DT_BCM93384WVG_VIPER
>   bool "BCM93384WVG Viper CPU (EXPERIMENTAL)"
>   select BUILTIN_DTB
>  
> +config DT_BCM96358NB4SER
> + bool "BCM96358NB4SER"
> + select BUILTIN_DTB
> +
>  config DT_BCM96368MVWG
>   bool "BCM96368MVWG"
>   select BUILTIN_DTB
> diff --git a/arch/mips/boot/dts/brcm/Makefile 
> b/arch/mips/boot/dts/brcm/Makefile
> index eabeb60..fda9d38 100644
> --- a/arch/mips/boot/dts/brcm/Makefile
> +++ b/arch/mips/boot/dts/brcm/Makefile
> @@ -1,5 +1,6 @@
>  dtb-$(CONFIG_DT_BCM93384WVG) += bcm93384wvg.dtb
>  dtb-$(CONFIG_DT_BCM93384WVG_VIPER)   += bcm93384wvg_viper.dtb
> +dtb-$(CONFIG_DT_BCM96358NB4SER)  += bcm96358nb4ser.dtb
>  dtb-$(CONFIG_DT_BCM96368MVWG)+= bcm96368mvwg.dtb
>  dtb-$(CONFIG_DT_BCM9EJTAGPRB)+= bcm9ejtagprb.dtb
>  dtb-$(CONFIG_DT_BCM97125CBMB)+= bcm97125cbmb.dtb
> @@ -14,6 +15,7 @@ dtb-$(CONFIG_DT_BCM97435SVMB)   += 
> bcm97435svmb.dtb
>  dtb-$(CONFIG_DT_NONE)+= \
>   bcm93384wvg.dtb \
>   bcm93384wvg_viper.dtb   \
> + bcm96358nb4ser.dtb  \
>   bcm96368mvwg.dtb\
>   bcm9ejtagprb.dtb\
>   bcm97125cbmb.dtb\
> diff --git a/arch/mips/boot/dts/brcm/bcm6358.dtsi 
> b/arch/mips/boot/dts/brcm/bcm6358.dtsi
> new file mode 100644
> index 000..4da824f
> --- /dev/null
> +++ b/arch/mips/boot/dts/brcm/bcm6358.dtsi
> @@ -0,0 +1,111 @@
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "brcm,bcm6358";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mips-hpt-frequency = <15000>;
> +
> + cpu@0 {
> + compatible = "brcm,bmips4350";
> + device_type = "cpu";
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + compatible = "brcm,bmips4350";
> + device_type = "cpu";
> + reg = <1>;
> + };
> + };
> +
> + clocks {
> + periph_clk: periph_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <5000>;
> + };
> + };
> +
> + aliases {
> + uart0 = &uart0;
> + uart1 = &uart1;
> + };
> +
> + cpu_intc: cpu_intc {
> + #address-cells = <0>;
> + compatible = "mti,cpu-interrupt-controller";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + ubus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + compatible = "simple-bus";
> + ranges;
> +
> + periph_cntl: syscon@fffe {
> + compatible = "syscon";
> + reg = <0xfffe 0xc>;
> + little-endi

Re: [GIT PULL] remaining tpmdd fixes for Linux 4.5

[Jarkko Sakkinen]

On Mon, Feb 22, 2016 at 10:52:45AM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 22, 2016 at 04:50:23PM +0200, Jarkko Sakkinen wrote:
> 
> > I already pushed a fix to my master for this issue:
> > 
> > https://github.com/jsakkine/linux-tpmdd/commit/6386544ad7bceb3d0248b85da29d4d99eebe9161
> 
> The goal is to reduce the number of #ifdef'd code segments so we have
> fewer problems in future with a large .config test matrix.
> 
> I'd rather see a __maybe_unused annotation instead.

Agreed that it's a better form but at this point it's probably revert
the breaking change and move to that later on. Otherwise, I don't see
reason not to include the patch that you authored to the release. I've
used it in my test kernels for quite some time now and it has worked
without issues.

I sent my fix for review now.

> Jason

/Jarkko

Re: [patch V2 11/28] x86/topology: Create logical package id

[Thomas Gleixner]

Andi,

On Mon, 22 Feb 2016, Andi Kleen wrote:
> Thomas Gleixner  writes:
> > +   if (c->cpuid_level >= 0x0001) {
> > +   u32 eax, ebx, ecx, edx;
> > +
> > +   cpuid(0x0001, &eax, &ebx, &ecx, &edx);
> 
> Use cpuid_edx()

That does not give me EBX ...
 
> > +   /*
> > +* If HTT (EDX[28]) is set EBX[16:23] contain the number of
> > +* apicids which are reserved per package. Store the resulting
> > +* shift value for the package management code.
> > +*/
> > +   if (edx & (1U << 28))
> > +   c->x86_coreid_bits = get_count_order((ebx >> 16) & 
> > 0xff);
> > +   }
> > +++ b/arch/x86/kernel/cpu/proc.c
> > @@ -12,6 +12,7 @@ static void show_cpuinfo_core(struct seq
> >  {
> >  #ifdef CONFIG_SMP
> > seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
> > +   seq_printf(m, "logical id\t: %d\n", c->logical_proc_id);
> 
> 
> I'm not sure it makes sense to export this. What good would it be for
> the user?
>
> If it was it would need to be documented somewhere. But I would
> just drop it and keep it kernel internal.

You are right. We print already when we change the package number, so it can
be retrieved from dmesg.
 
> FWIW every time something is added to this file it usually breaks
> some (dumb) programs.

Ok, did not think about that.
 
> > +   /*
> > +* Today neither Intel nor AMD support heterogenous systems. That
> > +* might change in the future
> > +*/
> > +   ncpus = boot_cpu_data.x86_max_cores * smp_num_siblings;
> > +   __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
> 
> FWIW Hypervisors can do nearly everything today.
> 
> I assume your code handles it.

It should. At least as long as nr_cpu_ids is sufficiently large.
 
> Let's hope that the Hypervisors always set up the correct CPUID now
> for their sibling configuration. If they don't with this change
> some CPUs would be suddenly lost.

The ones I looked at are doing is sane. Famous last words :)
 
> Would it be worth to have a kernel option where the maximum can be overriden
> in case this happens?

Let's wait for it to happen. It's done in no time, but if not needed it's just
ballast.

Thanks,

tglx

Re: [PATCH 6/6] ARM: dts: n900: Rename isp1704 to isp1707 to match correct name

[Tony Lindgren]

* Pavel Machek  [160221 06:05]:
> On Sun 2016-02-21 12:28:23, Pali Rohár wrote:
> > This change does not break existing userspace or Maemo software because
> > isp1704_charger.c always export power supply device under isp1704 name.
> 
> ..exports..
> 
> > Signed-off-by: Pali Rohár 
> 
> 4,5,6: Acked-by: Pavel Machek 

Ack for this one to get merged along with the driver changes:

Acked-by: Tony Lindgren 

Regards,

Tony

Re: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings

[Dan Williams]

On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
 wrote:
> Currently, the memremap code serves MEMREMAP_WB mappings directly from
> the kernel direct mapping, unless the region is in high memory, in which
> case it falls back to using ioremap_cache(). However, the semantics of
> ioremap_cache() are not unambiguously defined, and on ARM, it will
> actually result in a mapping type that differs from the attributes used
> for the linear mapping, and for this reason, the ioremap_cache() call
> fails if the region is part of the memory managed by the kernel.
>
> So instead, implement an optional hook 'arch_memremap_wb' whose default
> implementation calls ioremap_cache() as before, but which can be
> overridden by the architecture to do what is appropriate for it.
>

Acked-by: Dan Williams 

I still have patches pending to delete ioremap_cache() from ARM and
require memremap() to be used for cacheable mappings.  Do you see any
use for ioremap_cache() on ARM after this change?

[PATCH 09/10] x86/xsaves: Fix XSTATE component offset print out

[Yu-cheng Yu]

Component offset print out was incorrect for XSAVES. Correct it and move
to a separate function.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/kernel/fpu/xstate.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 512e71f..af4182b 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -251,8 +251,6 @@ static void __init setup_xstate_features(void)
WARN_ONCE(last_good_offset > xstate_offsets[i],
"x86/fpu: misordered xstate at %d\n", last_good_offset);
last_good_offset = xstate_offsets[i];
-
-   printk(KERN_INFO "x86/fpu: xstate_offset[%d]: %4d, 
xstate_sizes[%d]: %4d\n", i, ebx, i, eax);
}
 }
 
@@ -355,6 +353,21 @@ static void __init setup_xstate_comp(void)
 }
 
 /*
+ * Print out xstate component offsets and sizes
+ */
+static void __init print_xstate_offset_size(void)
+{
+   int i;
+
+   for (i = FIRST_EXTENDED_XFEATURE; i < XFEATURE_MAX; i++) {
+   if (xfeature_enabled(i)) {
+   pr_info("x86/fpu: xstate_offset[%d]: %4d, 
xstate_sizes[%d]: %4d\n",
+i, xstate_comp_offsets[i], i, xstate_sizes[i]);
+   }
+   }
+}
+
+/*
  * setup the xstate image representing the init state
  */
 static void __init setup_init_fpu_buf(void)
@@ -687,6 +700,7 @@ void __init fpu__init_system_xstate(void)
fpu__init_prepare_fx_sw_frame();
setup_init_fpu_buf();
setup_xstate_comp();
+   print_xstate_offset_size();
 
pr_info("x86/fpu: Enabled xstate features 0x%llx, context size is %d 
bytes, using '%s' format.\n",
xfeatures_mask,
-- 
1.9.1

[PATCH v4 1/5] block: disable block device DAX by default

[Ross Zwisler]

From: Dan Williams 

The recent *sync enabling discovered that we are inserting into the
block_device pagecache counter to the expectations of the dirty data
tracking for dax mappings.  This can lead to data corruption.

We want to support DAX for block devices eventually, but it requires
wider changes to properly manage the pagecache.

  [] dump_stack+0x85/0xc2
  [] dax_writeback_mapping_range+0x60/0xe0
  [] blkdev_writepages+0x3f/0x50
  [] do_writepages+0x21/0x30
  [] __filemap_fdatawrite_range+0xc6/0x100
  [] filemap_write_and_wait+0x4a/0xa0
  [] set_blocksize+0x70/0xd0
  [] sb_set_blocksize+0x1d/0x50
  [] ext4_fill_super+0x75b/0x3360
  [] ? vsnprintf+0x201/0x4c0
  [] ? snprintf+0x49/0x60
  [] mount_bdev+0x180/0x1b0
  [] ? ext4_calculate_overhead+0x370/0x370
  [] ext4_mount+0x15/0x20
  [] mount_fs+0x38/0x170

Mark the support broken so its disabled by default, but otherwise still
available for testing.

Cc: Jan Kara 
Cc: Jens Axboe 
Cc: Matthew Wilcox 
Cc: Al Viro 
Reported-by: Ross Zwisler 
Suggested-by: Dave Chinner 
Signed-off-by: Dan Williams 
Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
---
 block/Kconfig  | 13 +
 fs/block_dev.c |  6 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/block/Kconfig b/block/Kconfig
index 161491d..0363cd7 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -88,6 +88,19 @@ config BLK_DEV_INTEGRITY
T10/SCSI Data Integrity Field or the T13/ATA External Path
Protection.  If in doubt, say N.
 
+config BLK_DEV_DAX
+   bool "Block device DAX support"
+   depends on FS_DAX
+   depends on BROKEN
+   help
+ When DAX support is available (CONFIG_FS_DAX) raw block
+ devices can also support direct userspace access to the
+ storage capacity via MMAP(2) similar to a file on a
+ DAX-enabled filesystem.  However, the DAX I/O-path disables
+ some standard I/O-statistics, and the MMAP(2) path has some
+ operational differences due to bypassing the page
+ cache.  If in doubt, say N.
+
 config BLK_DEV_THROTTLING
bool "Block layer bio throttling support"
depends on BLK_CGROUP=y
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 39b3a17..31c6d10 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1201,7 +1201,11 @@ static int __blkdev_get(struct block_device *bdev, 
fmode_t mode, int for_part)
bdev->bd_disk = disk;
bdev->bd_queue = disk->queue;
bdev->bd_contains = bdev;
-   bdev->bd_inode->i_flags = disk->fops->direct_access ? S_DAX : 0;
+   if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && disk->fops->direct_access)
+   bdev->bd_inode->i_flags = S_DAX;
+   else
+   bdev->bd_inode->i_flags = 0;
+
if (!partno) {
ret = -ENXIO;
bdev->bd_part = disk_get_part(disk, partno);
-- 
2.5.0

[PATCH 10/10] x86/xsaves: Re-enable XSAVES

[Yu-cheng Yu]

We did not handle XSAVES* instructions correctly. There were issues in
converting between standard and compacted format when interfacing with
user-space. These issues have been corrected.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/kernel/fpu/init.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index b5952d5..6bfa059 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -226,21 +226,6 @@ static void __init 
fpu__init_system_xstate_size_legacy(void)
}
 
user_xstate_size = kernel_xstate_size;
-
-   /*
-* Quirk: we don't yet handle the XSAVES* instructions
-* correctly, as we don't correctly convert between
-* standard and compacted format when interfacing
-* with user-space - so disable it for now.
-*
-* The difference is small: with recent CPUs the
-* compacted format is only marginally smaller than
-* the standard FPU state format.
-*
-* ( This is easy to backport while we are fixing
-*   XSAVES* support. )
-*/
-   setup_clear_cpu_cap(X86_FEATURE_XSAVES);
 }
 
 /*
-- 
1.9.1

[PATCH v4 3/5] ext4: Online defrag not supported with DAX

[Ross Zwisler]

Online defrag operations for ext4 are hard coded to use the page cache.
See ext4_ioctl() -> ext4_move_extents() -> move_extent_per_page()

When combined with DAX I/O, which circumvents the page cache, this can
result in data corruption.  This was observed with xfstests ext4/307 and
ext4/308.

Fix this by only allowing online defrag for non-DAX files.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
---
 fs/ext4/ioctl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index a99b010..eae5917 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -583,6 +583,11 @@ group_extend_out:
 "Online defrag not supported with bigalloc");
err = -EOPNOTSUPP;
goto mext_out;
+   } else if (IS_DAX(inode)) {
+   ext4_msg(sb, KERN_ERR,
+"Online defrag not supported with DAX");
+   err = -EOPNOTSUPP;
+   goto mext_out;
}
 
err = mnt_want_write_file(filp);
-- 
2.5.0

[PATCH v4 2/5] ext2, ext4: only set S_DAX for regular inodes

[Ross Zwisler]

When S_DAX is set on an inode we assume that if there are pages attached
to the mapping (mapping->nrpages != 0), those pages are clean zero pages
that were used to service reads from holes.  Any dirty data associated with
the inode should be in the form of DAX exceptional entries
(mapping->nrexceptional) that is written back via
dax_writeback_mapping_range().

With the current code, though, this isn't always true.  For example, ext2
and ext4 directory inodes can have S_DAX set, but have their dirty data
stored as dirty page cache entries.  For these types of inodes, having
S_DAX set doesn't really make sense since their I/O doesn't actually happen
through the DAX code path.

Instead, only allow S_DAX to be set for regular inodes for ext2 and ext4.
This allows us to have strict DAX vs non-DAX paths in the writeback code.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
---
 fs/ext2/inode.c | 2 +-
 fs/ext4/inode.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 338eefd..27e2cdd 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -1296,7 +1296,7 @@ void ext2_set_inode_flags(struct inode *inode)
inode->i_flags |= S_NOATIME;
if (flags & EXT2_DIRSYNC_FL)
inode->i_flags |= S_DIRSYNC;
-   if (test_opt(inode->i_sb, DAX))
+   if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode))
inode->i_flags |= S_DAX;
 }
 
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 9cc57c3..5708e68 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4155,7 +4155,7 @@ void ext4_set_inode_flags(struct inode *inode)
new_fl |= S_NOATIME;
if (flags & EXT4_DIRSYNC_FL)
new_fl |= S_DIRSYNC;
-   if (test_opt(inode->i_sb, DAX))
+   if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode))
new_fl |= S_DAX;
inode_set_flags(inode, new_fl,
S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
-- 
2.5.0

[PATCH 08/10] x86/xsaves: Fix PTRACE frames for XSAVES

[Yu-cheng Yu]

XSAVES uses compacted format and is a kernel instruction. The kernel
should use standard-format, non-supervisor state data for PTRACE.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/include/asm/fpu/xstate.h |   4 +
 arch/x86/kernel/fpu/regset.c  |  56 +
 arch/x86/kernel/fpu/xstate.c  | 167 +-
 3 files changed, 211 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/fpu/xstate.h 
b/arch/x86/include/asm/fpu/xstate.h
index b4f5d94..a5cd808 100644
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@ -50,5 +50,9 @@ extern void update_regset_xstate_info(unsigned int size, u64 
xstate_mask);
 void fpu__xstate_clear_all_cpu_caps(void);
 void *get_xsave_addr(struct xregs_state *xsave, int xstate);
 const void *get_xsave_field_ptr(int xstate_field);
+int copyout_from_xsaves(unsigned int pos, unsigned int count, void *kbuf,
+   void __user *ubuf, const struct xregs_state *xsave);
+int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
+struct xregs_state *xsave);
 
 #endif
diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c
index 0bc3490..61fe8e9 100644
--- a/arch/x86/kernel/fpu/regset.c
+++ b/arch/x86/kernel/fpu/regset.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * The xstateregs_active() routine is the same as the regset_fpregs_active() 
routine,
@@ -82,21 +83,30 @@ int xstateregs_get(struct task_struct *target, const struct 
user_regset *regset,
if (!cpu_has_xsave)
return -ENODEV;
 
+   xsave = &fpu->state.xsave;
+
fpu__activate_fpstate_read(fpu);
 
-   xsave = &fpu->state.xsave;
+   if (boot_cpu_has(X86_FEATURE_XSAVES)) {
+   ret = copyout_from_xsaves(pos, count, kbuf, ubuf, xsave);
+   } else {
+   fpstate_sanitize_xstate(fpu);
+
+   /*
+* Copy the 48 bytes defined by the software into the xsave
+* area in the thread struct, so that we can copy the whole
+* area to user using one user_regset_copyout().
+*/
+   memcpy(&xsave->i387.sw_reserved,
+   xstate_fx_sw_bytes, sizeof(xstate_fx_sw_bytes));
+
+   /*
+* Copy the xstate memory layout.
+*/
+   ret = user_regset_copyout(&pos,
+ &count, &kbuf, &ubuf, xsave, 0, -1);
+   }
 
-   /*
-* Copy the 48bytes defined by the software first into the xstate
-* memory layout in the thread struct, so that we can copy the entire
-* xstateregs to the user using one user_regset_copyout().
-*/
-   memcpy(&xsave->i387.sw_reserved,
-   xstate_fx_sw_bytes, sizeof(xstate_fx_sw_bytes));
-   /*
-* Copy the xstate memory layout.
-*/
-   ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, xsave, 0, -1);
return ret;
 }
 
@@ -111,11 +121,29 @@ int xstateregs_set(struct task_struct *target, const 
struct user_regset *regset,
if (!cpu_has_xsave)
return -ENODEV;
 
-   fpu__activate_fpstate_write(fpu);
+   /*
+* A whole standard-format XSAVE buffer is needed.
+*/
+   if ((pos != 0) || (count < user_xstate_size))
+   return -EFAULT;
 
xsave = &fpu->state.xsave;
 
-   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, xsave, 0, -1);
+   fpu__activate_fpstate_write(fpu);
+
+   if (boot_cpu_has(X86_FEATURE_XSAVES))
+   ret = copyin_to_xsaves(kbuf, ubuf, xsave);
+   else
+   ret = user_regset_copyin(&pos,
+&count, &kbuf, &ubuf, xsave, 0, -1);
+
+   /*
+* In case of failure, mark all states as init.
+*/
+
+   if (ret)
+   fpstate_init(&fpu->state);
+
/*
 * mxcsr reserved bits must be masked to zero for security reasons.
 */
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 4087261..512e71f 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -677,7 +677,13 @@ void __init fpu__init_system_xstate(void)
return;
}
 
-   update_regset_xstate_info(kernel_xstate_size, xfeatures_mask);
+   /*
+* Update info used for ptrace frames; use standard-format size and no
+* supervisor xstates.
+*/
+   update_regset_xstate_info(user_xstate_size,
+   xfeatures_mask & ~XFEATURE_MASK_SUPERVISOR);
+
fpu__init_prepare_fx_sw_frame();
setup_init_fpu_buf();
setup_xstate_comp();
@@ -701,6 +707,15 @@ void fpu__resume_cpu(void)
 }
 
 /*
+ * Get an xstate component address for either kernel or user mode.
+ */
+static void *get_xsave_addr_no_check(const struct xregs_state *xsave,
+int featur

[PATCH 05/10] x86/xsaves: Align xstate components according to CPUID

[Yu-cheng Yu]

CPUID function 0x0d, sub function (i, i > 1) returns in ecx[1] the
alignment requirement of component i when the compacted format is used.

If ecx[1] is 0, component i is located immediately following the preceding
component. If ecx[1] is 1, component i is located on the next 64-byte
boundary following the preceding component.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/kernel/fpu/xstate.c | 60 +++-
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index daff143..6c19375 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -252,6 +252,33 @@ static void __init print_xstate_features(void)
 }
 
 /*
+ * This check is important because it is easy to get XSTATE_*
+ * confused with XSTATE_BIT_*.
+ */
+#define CHECK_XFEATURE(nr) do {\
+   WARN_ON(nr < FIRST_EXTENDED_XFEATURE);  \
+   WARN_ON(nr >= XFEATURE_MAX);\
+} while (0)
+
+/*
+ * We could cache this like xstate_size[], but we only use
+ * it here, so it would be a waste of space.
+ */
+static int xfeature_is_aligned(int xfeature_nr)
+{
+   u32 eax, ebx, ecx, edx;
+
+   CHECK_XFEATURE(xfeature_nr);
+   cpuid_count(XSTATE_CPUID, xfeature_nr, &eax, &ebx, &ecx, &edx);
+   /*
+* The value returned by ECX[1] indicates the alignment
+* of state component i when the compacted format
+* of the extended region of an XSAVE area is used
+*/
+   return !!(ecx & 2);
+}
+
+/*
  * This function sets up offsets and sizes of all extended states in
  * xsave area. This supports both standard format and compacted format
  * of the xsave aread.
@@ -288,10 +315,14 @@ static void __init setup_xstate_comp(void)
else
xstate_comp_sizes[i] = 0;
 
-   if (i > FIRST_EXTENDED_XFEATURE)
+   if (i > FIRST_EXTENDED_XFEATURE) {
xstate_comp_offsets[i] = xstate_comp_offsets[i-1]
+ xstate_comp_sizes[i-1];
 
+   if (xfeature_is_aligned(i))
+   xstate_comp_offsets[i] =
+   ALIGN(xstate_comp_offsets[i], 64);
+   }
}
 }
 
@@ -348,33 +379,6 @@ static int xfeature_is_user(int xfeature_nr)
 }
 */
 
-/*
- * This check is important because it is easy to get XSTATE_*
- * confused with XSTATE_BIT_*.
- */
-#define CHECK_XFEATURE(nr) do {\
-   WARN_ON(nr < FIRST_EXTENDED_XFEATURE);  \
-   WARN_ON(nr >= XFEATURE_MAX);\
-} while (0)
-
-/*
- * We could cache this like xstate_size[], but we only use
- * it here, so it would be a waste of space.
- */
-static int xfeature_is_aligned(int xfeature_nr)
-{
-   u32 eax, ebx, ecx, edx;
-
-   CHECK_XFEATURE(xfeature_nr);
-   cpuid_count(XSTATE_CPUID, xfeature_nr, &eax, &ebx, &ecx, &edx);
-   /*
-* The value returned by ECX[1] indicates the alignment
-* of state component i when the compacted format
-* of the extended region of an XSAVE area is used
-*/
-   return !!(ecx & 2);
-}
-
 static int xfeature_uncompacted_offset(int xfeature_nr)
 {
u32 eax, ebx, ecx, edx;
-- 
1.9.1

[PATCH 07/10] x86/xsaves: Fix init_fpstate.header.xcomp_bv

[Yu-cheng Yu]

In setup_init_fpu_buf(), we use XRSTOR/XRSTORS with xfeatures (xstate_bv)
of 0x0 to effectively set all xstate components to init values. We then
execute XSAVE/XSAVES on the same buffer to save back init values.

This actually does not apply to XSAVES as XSAVES uses optimization. After
init, all components are in INIT and not MODIFIED state and will not be
saved. There is no need of setting xcomp_bv except for bit 63 to indicate
a compacted format.

Currently, init_fpstate is used in two ways:

(1) With copy_kernel_to_xregs(): because header.xfeatures is zero, the
content is not actually read;

(2) With memcpy(): to sanitize a standard-format xsave area; the buffer is
setup as expected.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/kernel/fpu/xstate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 13829e1..4087261 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -371,10 +371,10 @@ static void __init setup_init_fpu_buf(void)
print_xstate_features();
 
if (cpu_has_xsaves)
-   init_fpstate.xsave.header.xcomp_bv = (u64)1 << 63 | 
xfeatures_mask;
+   init_fpstate.xsave.header.xcomp_bv = (u64)1 << 63;
 
/*
-* Init all the features state with header_bv being 0x0
+* Init all the features state with header.xfeatures being 0x0
 */
copy_kernel_to_xregs_booting(&init_fpstate.xsave);
 
-- 
1.9.1

[PATCH v4 0/5] DAX fixes, move flushing calls to FS

[Ross Zwisler]

Changes since v3:
- Added Reviewed-by tags from Jan Kara.
- Dropped patch 6, "block: use dax_do_io() if blkdev_dax_capable()"

I believe that this series is ready for inclusion in v4.5.  I think it
should be merged for v4.5 because it fixes serious issues with the DAX code
including possible data corruption and kernel OOPSes.

akpm, for the v4.5 merge do you want these patches to go through the -mm
tree, or would it be better if I just sent them to Linus directly?

A working tree can be found here:
https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=fsync_bdev_v4

---
Previous summary with issue impacts added:

This patch series fixes several issues with the current DAX code:

1) DAX is used by default on raw block devices that are capable of
supporting it.  This creates an issue because there are still uses of the
block device that use the page cache, and having one block device user
doing DAX I/O and another doing page cache I/O can lead to data corruption.

2) When S_DAX is set on an inode we assume that if there are pages attached
to the mapping (mapping->nrpages != 0), those pages are clean zero pages
that were used to service reads from holes.  This wasn't true in all cases.

3) ext4 online defrag combined with DAX I/O could lead to data corruption.

4) The DAX block/sector zeroing code needs a valid struct block_device,
which it wasn't always getting.  This could lead to a kernel OOPS.

5) The DAX writeback code needs a valid struct block_device, which it
wasn't always getting.  This could lead to a kernel OOPS.

6) The DAX writeback code needs to be called for sync(2) and syncfs(2).
This could lead to data loss.

Dan Williams (1):
  block: disable block device DAX by default

Ross Zwisler (4):
  ext2, ext4: only set S_DAX for regular inodes
  ext4: Online defrag not supported with DAX
  dax: give DAX clearing code correct bdev
  dax: move writeback calls into the filesystems

 block/Kconfig  | 13 +
 fs/block_dev.c | 19 +--
 fs/dax.c   | 21 +++--
 fs/ext2/inode.c| 16 +---
 fs/ext4/inode.c|  6 +-
 fs/ext4/ioctl.c|  5 +
 fs/xfs/xfs_aops.c  |  6 +-
 fs/xfs/xfs_aops.h  |  1 +
 fs/xfs/xfs_bmap_util.c |  3 ++-
 include/linux/dax.h|  8 +---
 mm/filemap.c   | 12 
 11 files changed, 81 insertions(+), 29 deletions(-)

-- 
2.5.0

Re: [PATCH] ARM: dts: n900: Use linux input defines instead hardcoded constants

[Tony Lindgren]

* Pavel Machek  [160222 02:55]:
> On Sun 2016-02-21 12:06:48, Pali Rohár wrote:
> > This makes DTS structure more readable.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Acked-by: Pavel Machek 

Applying into omap-for-v4.6/dt.

Thanks,

Tony

[PATCH 06/10] x86/xsaves: Supervisor state component offset

[Yu-cheng Yu]

CPUID function 0x0d, sub function (i, i > 1) returns in ebx the offset of
xstate component i. Zero is returned for a supervisor state. A supervisor
state can only be saved by XSAVES and XSAVES uses a compacted format.
There is no fixed offset for a supervisor state. This patch checks and
makes sure a supervisor state offset is not recorded or mis-used. This has
no effect in practice as we currently use no supervisor states, but it
would be good to fix.

Signed-off-by: Yu-cheng Yu 
---
 arch/x86/include/asm/fpu/types.h  |  2 ++
 arch/x86/include/asm/fpu/xstate.h |  3 ++
 arch/x86/kernel/fpu/xstate.c  | 62 ---
 3 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 1c6f6ac..11466cf 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -108,6 +108,7 @@ enum xfeature {
XFEATURE_OPMASK,
XFEATURE_ZMM_Hi256,
XFEATURE_Hi16_ZMM,
+   XFEATURE_PT,
 
XFEATURE_MAX,
 };
@@ -120,6 +121,7 @@ enum xfeature {
 #define XFEATURE_MASK_OPMASK   (1 << XFEATURE_OPMASK)
 #define XFEATURE_MASK_ZMM_Hi256(1 << XFEATURE_ZMM_Hi256)
 #define XFEATURE_MASK_Hi16_ZMM (1 << XFEATURE_Hi16_ZMM)
+#define XFEATURE_MASK_PT   (1 << XFEATURE_PT)
 
 #define XFEATURE_MASK_FPSSE(XFEATURE_MASK_FP | XFEATURE_MASK_SSE)
 #define XFEATURE_MASK_AVX512   (XFEATURE_MASK_OPMASK \
diff --git a/arch/x86/include/asm/fpu/xstate.h 
b/arch/x86/include/asm/fpu/xstate.h
index c6667f2..b4f5d94 100644
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@ -18,6 +18,9 @@
 #define XSAVE_YMM_SIZE 256
 #define XSAVE_YMM_OFFSET(XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET)
 
+/* Supervisor features */
+#define XFEATURE_MASK_SUPERVISOR (XFEATURE_MASK_PT)
+
 /* Supported features which support lazy state saving */
 #define XFEATURE_MASK_LAZY (XFEATURE_MASK_FP | \
 XFEATURE_MASK_SSE)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 6c19375..13829e1 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -95,6 +95,27 @@ int cpu_has_xfeatures(u64 xfeatures_needed, const char 
**feature_name)
 }
 EXPORT_SYMBOL_GPL(cpu_has_xfeatures);
 
+static int xfeature_is_supervisor(int xfeature_nr)
+{
+   /*
+* We currently do not support supervisor states, but if
+* we did, we could find out like this.
+*
+* SDM says: If state component i is a user state component,
+* ECX[0] return 0; if state component i is a supervisor
+* state component, ECX[0] returns 1.
+*/
+   u32 eax, ebx, ecx, edx;
+
+   cpuid_count(XSTATE_CPUID, xfeature_nr, &eax, &ebx, &ecx, &edx);
+   return !!(ecx & 1);
+}
+
+static int xfeature_is_user(int xfeature_nr)
+{
+   return !xfeature_is_supervisor(xfeature_nr);
+}
+
 /*
  * When executing XSAVEOPT (or other optimized XSAVE instructions), if
  * a processor implementation detects that an FPU state component is still
@@ -213,7 +234,14 @@ static void __init setup_xstate_features(void)
continue;
 
cpuid_count(XSTATE_CPUID, i, &eax, &ebx, &ecx, &edx);
-   xstate_offsets[i] = ebx;
+
+   /*
+* If an xfeature is supervisor state, the offset
+* in ebx is invalid. We leave it to -1.
+*/
+   if (xfeature_is_user(i))
+   xstate_offsets[i] = ebx;
+
xstate_sizes[i] = eax;
/*
 * In our xstate size checks, we assume that the
@@ -357,32 +385,20 @@ static void __init setup_init_fpu_buf(void)
copy_xregs_to_kernel_booting(&init_fpstate.xsave);
 }
 
-static int xfeature_is_supervisor(int xfeature_nr)
-{
-   /*
-* We currently do not support supervisor states, but if
-* we did, we could find out like this.
-*
-* SDM says: If state component i is a user state component,
-* ECX[0] return 0; if state component i is a supervisor
-* state component, ECX[0] returns 1.
-   u32 eax, ebx, ecx, edx;
-   cpuid_count(XSTATE_CPUID, xfeature_nr, &eax, &ebx, &ecx, &edx;
-   return !!(ecx & 1);
-   */
-   return 0;
-}
-/*
-static int xfeature_is_user(int xfeature_nr)
-{
-   return !xfeature_is_supervisor(xfeature_nr);
-}
-*/
-
 static int xfeature_uncompacted_offset(int xfeature_nr)
 {
u32 eax, ebx, ecx, edx;
 
+   /*
+* Only XSAVES supports supervisor states and it uses compacted
+* format. Checking a supervisor state's uncompacted offset is
+* an error.
+*/
+   if (XFEATURE_MASK_SUPERVISOR & (1 << xfeature_nr)) {
+   WARN_ONCE(1, "No fixed offset for xstate %d\n", xfeature_nr);
+   return -1;
+   }
+
CHECK_XFEA

[PATCH 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

[Yu-cheng Yu]

XSAVES is a kernel instruction and uses a compacted format. When
working with user space, the kernel should provide standard-format,
non-supervisor state data. We cannot do __copy_to_user() from a compacted-
format kernel xstate area to a signal frame.

Note that the path to copy_fpstate_to_sigframe() does currently check if
the thread has used FPU, but add a WARN_ONCE() there to detect any
potential mis-use.

Dave Hansen proposes this method to simplify copy xstate directly to user.

Signed-off-by: Fenghua Yu 
Signed-off by: Yu-cheng Yu 
---
 arch/x86/kernel/fpu/signal.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 0fbf60c..7676718 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -130,6 +130,45 @@ static inline int copy_fpregs_to_sigframe(struct 
xregs_state __user *buf)
return err;
 }
 
+static int should_save_registers_directly(void)
+{
+   /*
+* In signal handling path, the kernel already checks if
+* FPU instructions have been used before it calls
+* copy_fpstate_to_sigframe(). We check this here again
+* to detect any potential mis-use and saving invalid
+* register values directly to a signal frame.
+*/
+   WARN_ONCE(!current->thread.fpu.fpstate_active,
+ "direct FPU save with no math use\n");
+
+   /*
+* In the case that we are using a compacted kernel
+* xsave area, we can not copy the thread.fpu.state
+* directly to userspace and *must* save it from the
+* registers directly.
+*/
+   if (boot_cpu_has(X86_FEATURE_XSAVES))
+   return 1;
+
+   /*
+* fpregs_active() means "Can I use the FPU hardware
+* without taking a device-not-available exception?" This
+* means that saving the registers directly will be
+* cheaper than copying their contents out of
+* thread.fpu.state.
+*
+* Note that fpregs_active() is inherently racy and may
+* become false at any time.  If this race happens, we
+* will take a harmless device-not-available exception
+* when we attempt the FPU save instruction.
+*/
+   if (fpregs_active())
+   return 1;
+
+   return 0;
+}
+
 /*
  * Save the fpu, extended register state to the user signal frame.
  *
@@ -167,7 +206,7 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user 
*buf_fx, int size)
sizeof(struct user_i387_ia32_struct), NULL,
(struct _fpstate_32 __user *) buf) ? -1 : 1;
 
-   if (fpregs_active()) {
+   if (should_save_registers_directly()) {
/* Save the live register state to the user directly. */
if (copy_fpregs_to_sigframe(buf_fx))
return -1;
-- 
1.9.1

[PATCH 02/10] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

[Yu-cheng Yu]

User space uses standard format xsave area. fpstate in signal frame should
have standard format size.

To explicitly distinguish between xstate size in kernel space and the one
in user space, we rename xstate_size to kernel_xstate_size. This patch is
not fixing a bug. It just makes kernel code more clear.

So we define the xsave area sizes in two global variables:

kernel_xstate_size (previous xstate_size): the xsave area size used in
xsave area allocated in kernel
user_xstate_size: the xsave area size used in xsave area used by user.

In no "xsaves" case, xsave area in both user space and kernel space are in
standard format. Therefore, kernel_xstate_size and user_xstate_size are
equal.

In "xsaves" case, xsave area in user space is in standard format while
xsave area in kernel space is in compact format. Therefore, kernel's
xstate size is less than user's xstate size.

Signed-off-by: Fenghua Yu 
Signed-off-by: Yu-cheng Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/include/asm/processor.h |  2 +-
 arch/x86/kernel/fpu/core.c   |  6 +++---
 arch/x86/kernel/fpu/init.c   | 18 +-
 arch/x86/kernel/fpu/signal.c |  2 +-
 arch/x86/kernel/fpu/xstate.c |  8 
 5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 01e127e..68a5fa4 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -365,7 +365,7 @@ DECLARE_PER_CPU(struct irq_stack *, hardirq_stack);
 DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
 #endif /* X86_64 */
 
-extern unsigned int xstate_size;
+extern unsigned int kernel_xstate_size;
 extern unsigned int user_xstate_size;
 
 struct perf_event;
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index d25097c..faa00c0 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -214,7 +214,7 @@ void fpstate_init(union fpregs_state *state)
return;
}
 
-   memset(state, 0, xstate_size);
+   memset(state, 0, kernel_xstate_size);
 
if (cpu_has_fxsr)
fpstate_init_fxstate(&state->fxsave);
@@ -238,7 +238,7 @@ static void fpu_copy(struct fpu *dst_fpu, struct fpu 
*src_fpu)
 * leak into the child task:
 */
if (use_eager_fpu())
-   memset(&dst_fpu->state.xsave, 0, xstate_size);
+   memset(&dst_fpu->state.xsave, 0, kernel_xstate_size);
 
/*
 * Save current FPU registers directly into the child
@@ -258,7 +258,7 @@ static void fpu_copy(struct fpu *dst_fpu, struct fpu 
*src_fpu)
 */
preempt_disable();
if (!copy_fpregs_to_fpstate(dst_fpu)) {
-   memcpy(&src_fpu->state, &dst_fpu->state, xstate_size);
+   memcpy(&src_fpu->state, &dst_fpu->state, kernel_xstate_size);
fpregs_deactivate(src_fpu);
}
preempt_enable();
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 4ac2561..b5952d5 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -143,8 +143,8 @@ static void __init fpu__init_system_generic(void)
  * This is inherent to the XSAVE architecture which puts all state
  * components into a single, continuous memory block:
  */
-unsigned int xstate_size;
-EXPORT_SYMBOL_GPL(xstate_size);
+unsigned int kernel_xstate_size;
+EXPORT_SYMBOL_GPL(kernel_xstate_size);
 
 /* Get alignment of the TYPE. */
 #define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)
@@ -176,7 +176,7 @@ static void __init fpu__init_task_struct_size(void)
 * Add back the dynamically-calculated register state
 * size.
 */
-   task_size += xstate_size;
+   task_size += kernel_xstate_size;
 
/*
 * We dynamically size 'struct fpu', so we require that
@@ -193,7 +193,7 @@ static void __init fpu__init_task_struct_size(void)
 }
 
 /*
- * Set up the user and kernel xstate_size based on the legacy FPU context size.
+ * Set up the user and kernel xstate sizes based on the legacy FPU context 
size.
  *
  * We set this up first, and later it will be overwritten by
  * fpu__init_system_xstate() if the CPU knows about xstates.
@@ -206,7 +206,7 @@ static void __init fpu__init_system_xstate_size_legacy(void)
on_boot_cpu = 0;
 
/*
-* Note that xstate_size might be overwriten later during
+* Note that xstate sizes might be overwriten later during
 * fpu__init_system_xstate().
 */
 
@@ -217,15 +217,15 @@ static void __init 
fpu__init_system_xstate_size_legacy(void)
 */
setup_clear_cpu_cap(X86_FEATURE_XSAVE);
setup_clear_cpu_cap(X86_FEATURE_XSAVEOPT);
-   xstate_size = sizeof(struct swregs_state);
+   kernel_xstate_size = sizeof(struct swregs_state);
} else {
if (cpu_has_fxsr)
-   xstate_size = sizeof(struct fxregs_state);
+  

[PATCH 03/10] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization

[Yu-cheng Yu]

Keep init_fpstate.xsave.header.xfeatures as zero for init optimization.
This is important for init optimization that is implemented in processor.
If a bit corresponding to an xstate in xstate_bv is 0, it means the
xstate is in init status and will not be read from memory to the processor
during XRSTOR/XRSTORS instruction. This largely impacts context switch
performance.

Signed-off-by: Fenghua Yu 
Signed-off-by: Yu-cheng Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/kernel/fpu/xstate.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index b8d6d98..daff143 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -311,10 +311,8 @@ static void __init setup_init_fpu_buf(void)
setup_xstate_features();
print_xstate_features();
 
-   if (cpu_has_xsaves) {
+   if (cpu_has_xsaves)
init_fpstate.xsave.header.xcomp_bv = (u64)1 << 63 | 
xfeatures_mask;
-   init_fpstate.xsave.header.xfeatures = xfeatures_mask;
-   }
 
/*
 * Init all the features state with header_bv being 0x0
-- 
1.9.1

Re: Computer fails to resume from suspend unless I rmmod jme before initiating the suspend

[Diego Viola]

On Mon, Feb 22, 2016 at 7:09 AM, Pavel Machek  wrote:
> Hi!
>
>>  Every time I initiate a suspend (systemctl suspend) the machine hangs
>>  at resume unless I unload the jme driver.
>
> It seems to have some kind of suspend/resume support. ... and it is
> rather complex.
>
> Maybe jme_start_irq(jme) should be moved to the end of jme_resume
> function?
>
>> > So I found that disabling async as in:
>> >
>> > $ echo 0 > /sys/power/pm_async
>> >
>> > Helps with my issue, I can't reproduce the hang anymore, tried
>> > suspend/resume almost ~15 times.
>> >
>> > Diego
>>
>> Can someone please help?
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi Pavel,

This did the trick, suspend/resume is now working perfectly for me
(tried more than 10 times). :)

Thank you so much, should I send a patch?

Diego

Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Martin Kepplinger]

Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> On Mon, 22 Feb 2016 15:02:56 +0100,
> Martin Kepplinger wrote:
>>> And how about my questions in the previous mail?  Does
>>> i915_audio_component_get_eld() is called and returns 0?
>>> And is monitor_present set true or false?
>>
>> i915_audio_component_get_eld() returns 0 and monitor_present is 0.
>>>
>>> If i915_audio_component_get_eld() is called but returns zero, track
>>> the code flow there.  It means either intel_encoder is NULL or
>>> intel_dig_port->audio_connector is NULL.
>>
>> intel_dig_port->audio_connector is NULL!
>>
>> (when called during boot and during HDMI plugin)
> 
> Interesting.  The relevant code flow should be like:
> 
>   intel_audio_codec_enable()
>   -> acomp->audio_ops->pin_eld_notify()
> -> intel_pin_eld_notify()
>   -> check_presence_and_report()
> -> hdmi_present_sense()
> -> sync_eld_via_acomp()
>   -> snd_hdac_acomp_get_eld()
> -> i915_audio_component_get_eld()
> 
> So, at first, check whether intel_dig_port in both
> intel_audio_codec_enable() and i915_audio_component_get_eld() points
> to the same object address.  The audio_connector must be set in
> intel_audio_codec_enable(), thus basically it must be non-NULL at
> i915_audio_component_get_eld(), too.
> 

intel_dig_port is *not* the same object in these 2 places. During
plugin, see:

[  146.934091] in intel_audio_codec_enable: intel_dig_port is
8800a1f54000
[  146.934121] in i915_audio_component_get_eld: intel_dig_port is
880244f7d000

sorry for the slow responses. I'll try to go back that direction unless
again someone comes up with other suggestions.

martin

[PATCH v4 5/5] dax: move writeback calls into the filesystems

[Ross Zwisler]

Previously calls to dax_writeback_mapping_range() for all DAX filesystems
(ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range().
dax_writeback_mapping_range() needs a struct block_device, and it used to
get that from inode->i_sb->s_bdev.  This is correct for normal inodes
mounted on ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
block devices and for XFS real-time files.

Instead, call dax_writeback_mapping_range() directly from the filesystem
->writepages function so that it can supply us with a valid block
device. This also fixes DAX code to properly flush caches in response to
sync(2).

Signed-off-by: Ross Zwisler 
Signed-off-by: Jan Kara 
---
 fs/block_dev.c  | 13 -
 fs/dax.c| 12 +++-
 fs/ext2/inode.c |  8 
 fs/ext4/inode.c |  4 
 fs/xfs/xfs_aops.c   |  4 
 include/linux/dax.h |  6 --
 mm/filemap.c| 12 
 7 files changed, 43 insertions(+), 16 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 31c6d10..826b164 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1697,13 +1697,24 @@ static int blkdev_releasepage(struct page *page, gfp_t 
wait)
return try_to_free_buffers(page);
 }
 
+static int blkdev_writepages(struct address_space *mapping,
+struct writeback_control *wbc)
+{
+   if (dax_mapping(mapping)) {
+   struct block_device *bdev = I_BDEV(mapping->host);
+
+   return dax_writeback_mapping_range(mapping, bdev, wbc);
+   }
+   return generic_writepages(mapping, wbc);
+}
+
 static const struct address_space_operations def_blk_aops = {
.readpage   = blkdev_readpage,
.readpages  = blkdev_readpages,
.writepage  = blkdev_writepage,
.write_begin= blkdev_write_begin,
.write_end  = blkdev_write_end,
-   .writepages = generic_writepages,
+   .writepages = blkdev_writepages,
.releasepage= blkdev_releasepage,
.direct_IO  = blkdev_direct_IO,
.is_dirty_writeback = buffer_check_dirty_writeback,
diff --git a/fs/dax.c b/fs/dax.c
index 9a173dd..7111724 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -484,11 +484,10 @@ static int dax_writeback_one(struct block_device *bdev,
  * end]. This is required by data integrity operations to ensure file data is
  * on persistent storage prior to completion of the operation.
  */
-int dax_writeback_mapping_range(struct address_space *mapping, loff_t start,
-   loff_t end)
+int dax_writeback_mapping_range(struct address_space *mapping,
+   struct block_device *bdev, struct writeback_control *wbc)
 {
struct inode *inode = mapping->host;
-   struct block_device *bdev = inode->i_sb->s_bdev;
pgoff_t start_index, end_index, pmd_index;
pgoff_t indices[PAGEVEC_SIZE];
struct pagevec pvec;
@@ -499,8 +498,11 @@ int dax_writeback_mapping_range(struct address_space 
*mapping, loff_t start,
if (WARN_ON_ONCE(inode->i_blkbits != PAGE_SHIFT))
return -EIO;
 
-   start_index = start >> PAGE_CACHE_SHIFT;
-   end_index = end >> PAGE_CACHE_SHIFT;
+   if (!mapping->nrexceptional || wbc->sync_mode != WB_SYNC_ALL)
+   return 0;
+
+   start_index = wbc->range_start >> PAGE_CACHE_SHIFT;
+   end_index = wbc->range_end >> PAGE_CACHE_SHIFT;
pmd_index = DAX_PMD_INDEX(start_index);
 
rcu_read_lock();
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 4467cbd..6bd58e6 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -876,6 +876,14 @@ ext2_direct_IO(struct kiocb *iocb, struct iov_iter *iter, 
loff_t offset)
 static int
 ext2_writepages(struct address_space *mapping, struct writeback_control *wbc)
 {
+#ifdef CONFIG_FS_DAX
+   if (dax_mapping(mapping)) {
+   return dax_writeback_mapping_range(mapping,
+  mapping->host->i_sb->s_bdev,
+  wbc);
+   }
+#endif
+
return mpage_writepages(mapping, wbc, ext2_get_block);
 }
 
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5708e68..aee960b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2478,6 +2478,10 @@ static int ext4_writepages(struct address_space *mapping,
 
trace_ext4_writepages(inode, wbc);
 
+   if (dax_mapping(mapping))
+   return dax_writeback_mapping_range(mapping, inode->i_sb->s_bdev,
+  wbc);
+
/*
 * No pages to write? This is mainly a kludge to avoid starting
 * a transaction for special inodes like journal inode on last iput()
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index fc20518..a9ebabfe 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -1208,6 +1208,10 @@ xfs_vm_writepages(
struct writeback_control *wbc)
 {
xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED);

Re: [patch V2 22/28] x86/perf/intel/rapl: Cleanup the printk output

[Thomas Gleixner]

Andi,

On Mon, 22 Feb 2016, Andi Kleen wrote:

> Thomas Gleixner  writes:
> >  
> > +static void __init rapl_advertise(void)
> > +{
> > +   int i;
> > +
> > +   pr_info("API unit is 2^-32 Joules, %d fixed counters, %llu ms ovfl 
> > timer\n",
> > +   hweight32(rapl_cntr_mask), rapl_timer_ms);
> 
> Does the final resulting line contain RAPL for grepping?

Yes. That's what the pr_fmt prepends.

[35282.080376] calling  rapl_pmu_init+0x0/0xff5 [perf_event_intel_rapl] @ 10523
[35282.080679] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms 
ovfl timer
[35282.088634] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[35282.094394] RAPL PMU: hw unit of domain package 2^-14 Joules
[35282.111347] RAPL PMU: hw unit of domain dram 2^-16 Joules
[35282.127514] initcall rapl_pmu_init+0x0/0xff5 [perf_event_intel_rapl] 
returned 0 after 46023 usecs

> Ideally would be similar as before in case someone has a parser for
> this.

It is.

Thanks,

tglx

[PATCH v4 4/5] dax: give DAX clearing code correct bdev

[Ross Zwisler]

dax_clear_blocks() needs a valid struct block_device and previously it was
using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
block devices and for XFS real-time devices.

Instead, rename dax_clear_blocks() to dax_clear_sectors(), and change its
arguments to take a bdev and a sector instead of an inode and a block.
This better reflects what the function does, and it allows the filesystem
and raw block device code to pass in an appropriate struct block_device.

Signed-off-by: Ross Zwisler 
Suggested-by: Dan Williams 
Reviewed-by: Jan Kara 
---
 fs/dax.c   | 9 -
 fs/ext2/inode.c| 6 --
 fs/xfs/xfs_aops.c  | 2 +-
 fs/xfs/xfs_aops.h  | 1 +
 fs/xfs/xfs_bmap_util.c | 3 ++-
 include/linux/dax.h| 2 +-
 6 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index fc2e314..9a173dd 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -79,15 +79,14 @@ struct page *read_dax_sector(struct block_device *bdev, 
sector_t n)
 }
 
 /*
- * dax_clear_blocks() is called from within transaction context from XFS,
+ * dax_clear_sectors() is called from within transaction context from XFS,
  * and hence this means the stack from this point must follow GFP_NOFS
  * semantics for all operations.
  */
-int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
+int dax_clear_sectors(struct block_device *bdev, sector_t _sector, long _size)
 {
-   struct block_device *bdev = inode->i_sb->s_bdev;
struct blk_dax_ctl dax = {
-   .sector = block << (inode->i_blkbits - 9),
+   .sector = _sector,
.size = _size,
};
 
@@ -109,7 +108,7 @@ int dax_clear_blocks(struct inode *inode, sector_t block, 
long _size)
wmb_pmem();
return 0;
 }
-EXPORT_SYMBOL_GPL(dax_clear_blocks);
+EXPORT_SYMBOL_GPL(dax_clear_sectors);
 
 /* the clear_pmem() calls are ordered by a wmb_pmem() in the caller */
 static void dax_new_buf(void __pmem *addr, unsigned size, unsigned first,
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 27e2cdd..4467cbd 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -737,8 +737,10 @@ static int ext2_get_blocks(struct inode *inode,
 * so that it's not found by another thread before it's
 * initialised
 */
-   err = dax_clear_blocks(inode, le32_to_cpu(chain[depth-1].key),
-   1 << inode->i_blkbits);
+   err = dax_clear_sectors(inode->i_sb->s_bdev,
+   le32_to_cpu(chain[depth-1].key) <<
+   (inode->i_blkbits - 9),
+   1 << inode->i_blkbits);
if (err) {
mutex_unlock(&ei->truncate_mutex);
goto cleanup;
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 379c089..fc20518 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -55,7 +55,7 @@ xfs_count_page_state(
} while ((bh = bh->b_this_page) != head);
 }
 
-STATIC struct block_device *
+struct block_device *
 xfs_find_bdev_for_inode(
struct inode*inode)
 {
diff --git a/fs/xfs/xfs_aops.h b/fs/xfs/xfs_aops.h
index f6ffc9a..a4343c6 100644
--- a/fs/xfs/xfs_aops.h
+++ b/fs/xfs/xfs_aops.h
@@ -62,5 +62,6 @@ int   xfs_get_blocks_dax_fault(struct inode *inode, sector_t 
offset,
 struct buffer_head *map_bh, int create);
 
 extern void xfs_count_page_state(struct page *, int *, int *);
+extern struct block_device *xfs_find_bdev_for_inode(struct inode *);
 
 #endif /* __XFS_AOPS_H__ */
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 45ec9e4..6c87601 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -75,7 +75,8 @@ xfs_zero_extent(
ssize_t size = XFS_FSB_TO_B(mp, count_fsb);
 
if (IS_DAX(VFS_I(ip)))
-   return dax_clear_blocks(VFS_I(ip), block, size);
+   return dax_clear_sectors(xfs_find_bdev_for_inode(VFS_I(ip)),
+   sector, size);
 
/*
 * let the block layer decide on the fastest method of
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 818e450..7b6bced 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -7,7 +7,7 @@
 
 ssize_t dax_do_io(struct kiocb *, struct inode *, struct iov_iter *, loff_t,
  get_block_t, dio_iodone_t, int flags);
-int dax_clear_blocks(struct inode *, sector_t block, long size);
+int dax_clear_sectors(struct block_device *bdev, sector_t _sector, long _size);
 int dax_zero_page_range(struct inode *, loff_t from, unsigned len, 
get_block_t);
 int dax_truncate_page(struct inode *, loff_t from, get_block_t);
 int dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
-- 
2.5.0

[PATCH 01/10] x86/xsaves: Define and use user_xstate_size for xstate size in signal context

[Yu-cheng Yu]

If "xsaves" is enabled, kernel always uses compacted format of xsave area.
But user space still uses standard format of xsave area. Thus, xstate size
in kernel's xsave area is smaller than xstate size in user's xsave area.
The xstate in signal frame should be in standard format for user's signal
handler to access.

In no "xsaves" case, xsave area in both user space and kernel space are in
standard format. Therefore, user's and kernel's xstate sizes are equal.

In "xsaves" case, xsave area in user space is in standard format while
xsave area in kernel space is in compacted format. Therefore, kernel's
xstate size is smaller than user's xstate size.

So here is the problem: currently kernel assumes its own xstate size is
signal frame's xstate size. This is not a problem in no "xsaves" case.
It is an issue in "xsaves" case because kernel's xstate size is smaller
than user's xstate size. In fpu__alloc_mathframe(), a smaller fpstate
buffer is allocated for the standard format xstate in signal frame.
Then kernel saves only part of xstate registers into this smaller
user's fpstate buffer and user will see part of the xstate registers in
signal context. Similar issue happens after returning from signal handler:
kernel will only restore part of xstate registers from user's fpstate
buffer in signal frame.

This patch defines and uses user_xstate_size for xstate size in signal
frame. It's read from returned value in ebx from CPUID leaf 0x0D subleaf
0x0. This is maximum size required by enabled states in XCR0 and may be
different from ecx when states at the end of the xsave area are not
enabled. This value indicates the size required for XSAVE to save all
supported user states in legacy/standard format.

Signed-off-by: Fenghua Yu 
Signed-off-by: Yu-cheng Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/include/asm/fpu/xstate.h |  1 -
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/fpu/init.c|  5 ++-
 arch/x86/kernel/fpu/signal.c  | 26 ++
 arch/x86/kernel/fpu/xstate.c  | 71 ---
 5 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/fpu/xstate.h 
b/arch/x86/include/asm/fpu/xstate.h
index af30fde..c6667f2 100644
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@ -39,7 +39,6 @@
 #define REX_PREFIX
 #endif
 
-extern unsigned int xstate_size;
 extern u64 xfeatures_mask;
 extern u64 xstate_fx_sw_bytes[USER_XSTATE_FX_SW_WORDS];
 
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 20c11d1..01e127e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -366,6 +366,7 @@ DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
 #endif /* X86_64 */
 
 extern unsigned int xstate_size;
+extern unsigned int user_xstate_size;
 
 struct perf_event;
 
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 6d9f0a7..4ac2561 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -193,7 +193,7 @@ static void __init fpu__init_task_struct_size(void)
 }
 
 /*
- * Set up the xstate_size based on the legacy FPU context size.
+ * Set up the user and kernel xstate_size based on the legacy FPU context size.
  *
  * We set this up first, and later it will be overwritten by
  * fpu__init_system_xstate() if the CPU knows about xstates.
@@ -224,6 +224,9 @@ static void __init fpu__init_system_xstate_size_legacy(void)
else
xstate_size = sizeof(struct fregs_state);
}
+
+   user_xstate_size = xstate_size;
+
/*
 * Quirk: we don't yet handle the XSAVES* instructions
 * correctly, as we don't correctly convert between
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 31c6a60..ee6d662 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -31,7 +31,7 @@ static inline int check_for_xstate(struct fxregs_state __user 
*buf,
/* Check for the first magic field and other error scenarios. */
if (fx_sw->magic1 != FP_XSTATE_MAGIC1 ||
fx_sw->xstate_size < min_xstate_size ||
-   fx_sw->xstate_size > xstate_size ||
+   fx_sw->xstate_size > user_xstate_size ||
fx_sw->xstate_size > fx_sw->extended_size)
return -1;
 
@@ -88,7 +88,7 @@ static inline int save_xstate_epilog(void __user *buf, int 
ia32_frame)
if (!use_xsave())
return err;
 
-   err |= __put_user(FP_XSTATE_MAGIC2, (__u32 *)(buf + xstate_size));
+   err |= __put_user(FP_XSTATE_MAGIC2, (__u32 *)(buf + user_xstate_size));
 
/*
 * Read the xfeatures which we copied (directly from the cpu or
@@ -125,7 +125,7 @@ static inline int copy_fpregs_to_sigframe(struct 
xregs_state __user *buf)
else
err = copy_fregs_to_user((struct fregs_state __user *) buf);
 
-   if (unlikely(err) && __clear_user(buf, xstate_size))
+   

[PATCH 00/10] x86/xsaves: Fix XSAVES known issues

[Yu-cheng Yu]

XSAVES is a kernel-mode instruction. It offers a compacted format and
memory-write optimization. These patches fix known issues in the first
implementation. They are intended for discussion and getting feedback
before actually getting applied.  

Patch 1, 2, and 4 are for converting between kernel-mode xstate area and
signal frames.

Patch 8 is for converting between kernel-mode xstate area and ptrace
frames.

Patch 3 and 7 fix optimization issues introduced by XSAVES to the buffer
init_fpstate.

Patch 5 and 6 are related to xstate component offsets.

Patch 9 fixes xstate area print out.

Patch 10 re-enables XSAVES.

Yu-cheng Yu (10):
  x86/xsaves: Define and use user_xstate_size for xstate size in signal
context
  x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly
distinguish xstate size in kernel from user space
  x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init
optimization
  x86/xsaves: Introduce a new check that allows correct xstates copy
from kernel to user directly
  x86/xsaves: Align xstate components according to CPUID
  x86/xsaves: Supervisor state component offset
  x86/xsaves: Fix init_fpstate.header.xcomp_bv
  x86/xsaves: Fix PTRACE frames for XSAVES
  x86/xsaves: Fix XSTATE component offset print out
  x86/xsaves: Re-enable XSAVES

 arch/x86/include/asm/fpu/types.h  |   2 +
 arch/x86/include/asm/fpu/xstate.h |   8 +-
 arch/x86/include/asm/processor.h  |   3 +-
 arch/x86/kernel/fpu/core.c|   6 +-
 arch/x86/kernel/fpu/init.c|  32 +---
 arch/x86/kernel/fpu/regset.c  |  56 --
 arch/x86/kernel/fpu/signal.c  |  69 ++-
 arch/x86/kernel/fpu/xstate.c  | 388 +-
 8 files changed, 425 insertions(+), 139 deletions(-)

-- 
1.9.1

Re: [PATCH 0/8] X.509: Software public key subtype changes

[Mimi Zohar]

On Fri, 2016-02-19 at 17:18 +, David Howells wrote:
> Here's a set of patches that cleans up the public key handling in the
> asymmetric key functions:
> 
>  (1) - (3) These are Tadeusz's RSA akcipher conversion.

Up to here, IMA-appraisal works properly.

Mimi  

>  (4) This removes all knowledge of RSA from the software public key
>  asymmetric key subtype.  Instead, the public key type and the hash
>  type are indicated to the crypto layer and the RSA module there does
>  all the appropriate encoding.
> 
>  (5) This changes the various algorithm IDs to text labels instead of enums
>  as the strings are what we actually deal with (printing, passing to
>  the crypto layer).
> 
>  (6) This separates the private parts of the software public key subtype
>  into a private header in the implementation directory.
> 
>  (7) This renames public_key.c to software_pkey.c and changes the Kconfig
>  symbol to match.
> 
>  (8) This renames symbols beginning "public_key" to "software_pkey" except
>  struct for public_key_signature which is a wider API component.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
> 
> David
> ---
> David Howells (5):
>   akcipher: Move the RSA DER encoding to the crypto layer
>   X.509: Make algo identifiers text instead of enum
>   X.509: Make the public_key asymmetric key type internal data private
>   X.509: Rename public_key.c to software_pkey.c
>   X.509: Rename public_key* to software_pkey*
> 
> Tadeusz Struk (3):
>   crypto: KEYS: convert public key and digsig asym to the akcipher api
>   integrity: convert digsig to akcipher api
>   crypto: public_key: remove MPIs from public_key_signature struct
> 
> 
>  arch/s390/configs/default_defconfig   |2 
>  arch/s390/configs/gcov_defconfig  |2 
>  arch/s390/configs/performance_defconfig   |2 
>  crypto/asymmetric_keys/Kconfig|   17 +-
>  crypto/asymmetric_keys/Makefile   |   10 -
>  crypto/asymmetric_keys/mscode_parser.c|   14 +
>  crypto/asymmetric_keys/pkcs7_parser.c |   30 +--
>  crypto/asymmetric_keys/pkcs7_trust.c  |2 
>  crypto/asymmetric_keys/pkcs7_verify.c |   12 +
>  crypto/asymmetric_keys/public_key.c   |  130 --
>  crypto/asymmetric_keys/public_key.h   |   36 
>  crypto/asymmetric_keys/rsa.c  |  278 
> -
>  crypto/asymmetric_keys/software_pkey.c|  142 +++
>  crypto/asymmetric_keys/software_pkey.h|   33 +++
>  crypto/asymmetric_keys/verify_pefile.c|4 
>  crypto/asymmetric_keys/verify_pefile.h|2 
>  crypto/asymmetric_keys/x509_cert_parser.c |   67 ++-
>  crypto/asymmetric_keys/x509_parser.h  |4 
>  crypto/asymmetric_keys/x509_public_key.c  |   43 ++--
>  crypto/asymmetric_keys/x509_rsakey.asn1   |4 
>  crypto/rsa.c  |  210 +++---
>  crypto/testmgr.c  |5 -
>  include/crypto/akcipher.h |7 +
>  include/crypto/public_key.h   |   79 +---
>  init/Kconfig  |4 
>  kernel/module_signing.c   |6 +
>  security/integrity/Kconfig|3 
>  security/integrity/digsig_asymmetric.c|   16 +-
>  28 files changed, 467 insertions(+), 697 deletions(-)
>  delete mode 100644 crypto/asymmetric_keys/public_key.c
>  delete mode 100644 crypto/asymmetric_keys/public_key.h
>  delete mode 100644 crypto/asymmetric_keys/rsa.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.h
>  delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [patch V2 00/28] x86/perf/intel/uncore|rapl: Fix error handling and sanitize pmu management

[Andi Kleen]

Thomas Gleixner  writes:

> This series addresses the following issues:

FWIW I did a quick read through the series, and except where commented
it looks good to me.

Reviewed-by: Andi Kleen 

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH v5 0/3] init: add support to directly boot to a mapped device

[Kees Cook]

On Sun, Feb 21, 2016 at 2:08 PM, Alasdair G Kergon  wrote:
> On Sat, Feb 20, 2016 at 10:13:49AM -0800, Kees Cook wrote:
>> This is a resurrection of a patch series from a few years back, first
>> brought to the dm maintainers in 2010. It creates a way to define dm
>> devices on the kernel command line for systems that do not use an
>> initramfs, or otherwise need a dm running before init starts.
>>
>> This has been used by Chrome OS for several years, and now by Brillo
>> (and likely Android soon).
>>
>> The last version was v4:
>> https://patchwork.kernel.org/patch/104860/
>> https://patchwork.kernel.org/patch/104861/
>
> Inconsistencies in the terminology here can be sorted out during review,
> and I see that you've taken on board some of my review comments from
> 2010, but what are your responses to the rest of them?

Ah, sorry, the threads I could find were incomplete, so I wasn't able
to find those comments that were made to Will's 2010 submission. In
some of the cleanups I did I was very confused about "target" vs
"table", and tried to fix that. Regardless, I'm open to fixing
whatever is needed. :)

Thanks for looking at this again!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [patch V2 11/28] x86/topology: Create logical package id

[Andi Kleen]

Thomas Gleixner  writes:


> +
> + if (c->cpuid_level >= 0x0001) {
> + u32 eax, ebx, ecx, edx;
> +
> + cpuid(0x0001, &eax, &ebx, &ecx, &edx);

Use cpuid_edx()

> + /*
> +  * If HTT (EDX[28]) is set EBX[16:23] contain the number of
> +  * apicids which are reserved per package. Store the resulting
> +  * shift value for the package management code.
> +  */
> + if (edx & (1U << 28))
> + c->x86_coreid_bits = get_count_order((ebx >> 16) & 
> 0xff);
> + }
> +++ b/arch/x86/kernel/cpu/proc.c
> @@ -12,6 +12,7 @@ static void show_cpuinfo_core(struct seq
>  {
>  #ifdef CONFIG_SMP
>   seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
> + seq_printf(m, "logical id\t: %d\n", c->logical_proc_id);


I'm not sure it makes sense to export this. What good would it be for
the user?

If it was it would need to be documented somewhere. But I would
just drop it and keep it kernel internal.

FWIW every time something is added to this file it usually breaks
some (dumb) programs.

> + /*
> +  * Today neither Intel nor AMD support heterogenous systems. That
> +  * might change in the future
> +  */
> + ncpus = boot_cpu_data.x86_max_cores * smp_num_siblings;
> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);

FWIW Hypervisors can do nearly everything today.

I assume your code handles it.

Let's hope that the Hypervisors always set up the correct CPUID now
for their sibling configuration. If they don't with this change
some CPUs would be suddenly lost.

Would it be worth to have a kernel option where the maximum can be overriden
in case this happens?


-Andi
-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH v7 0/8] Patchset enabling hardware based cross-timestamps for next gen Intel platforms

[John Stultz]

On Mon, Feb 22, 2016 at 10:33 AM, Christopher Hall
 wrote:
> I just sent another patchset (v8). I corrected the comment problems pointed
> out by Richard Cochran. I also changed the arch/x86 code to use "non-stop"
> TSC rather than "invariant" TSC. They are *exactly* the same thing (i.e.
> read from the same bit of the CPUID leaf). The former exists already and
> should be used instead.  Patch 6/8 is the only patch that is changed apart
> from comments.

Ok. So I see you addressed some of Andy's feedback, but did you answer
the bit about the k offset?

thanks
-john

[PATCH] tpm_tis: fix build warning with tpm_tis_resume

[Jarkko Sakkinen]

drivers/char/tpm/tpm_tis.c:838: warning: ‘tpm_tis_resume’ defined but
not used

Reported-by: James Morris 
Fixes: 00194826e6be ("tpm_tis: Clean up the force=1 module parameter")
Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_tis.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2b2eff9..a507006 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -814,6 +814,7 @@ out_err:
return rc;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static void tpm_tis_reenable_interrupts(struct tpm_chip *chip)
 {
u32 intmask;
@@ -855,6 +856,7 @@ static int tpm_tis_resume(struct device *dev)
 
return 0;
 }
+#endif
 
 static SIMPLE_DEV_PM_OPS(tpm_tis_pm, tpm_pm_suspend, tpm_tis_resume);
 
-- 
2.7.0

Re: [PATCH v6] rtc: rewrite DS1302 using SPI

[Rob Herring]

On Mon, Feb 22, 2016 at 04:41:22AM +0300, Sergei Ianovich wrote:
> DS1302 is half-duplex SPI device. The driver respects this fact now.
> 
> Pin configurations should be implemented using SPI subsystem.
> 
> Signed-off-by: Sergei Ianovich 
> CC: Alexandre Belloni 
> CC: Rob Herring 
> ---
>v5..v6
>* rewrite the driver as an SPI slave device
>* use "maxim" for vendor name per Kconfig
>* stop touching device RAM in device presence test
>* only return time from device if valid
>* use burst mode for reading/writing time
>* droppped charging control. I cannot test it, and it looks broken
> 
>v4..v5
>* drop THIS_MODULE from struct platform driver
>* use "dallas" for vendor name per vendor-prefixes.txt
> 
>v3..v4
>* move DTS bindings to a different patch
> 
>v2..v3
>* use usleep_range instead of custom nsleep
>* number change (07/16 -> 09/21)
> 
>v0..v2
>* use device tree
>* use devm helpers where possible
> 
>  .../devicetree/bindings/rtc/rtc-ds1302.txt |  46 +++
>  drivers/rtc/Kconfig|  15 +-
>  drivers/rtc/rtc-ds1302.c   | 348 
> ++---
>  3 files changed, 212 insertions(+), 197 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> 
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt 
> b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> new file mode 100644
> index 000..b6c0973
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> @@ -0,0 +1,46 @@
> +* Maxim/Dallas Semiconductor DS-1302 RTC
> +
> +Simple device which could be used to store date/time between reboots.
> +
> +The device uses the standard MicroWire half-duplex transfer timing.
> +Master output is set on low clock and sensed by the RTC on the rising
> +edge. Master input is set by the RTC on the trailing edge and is sensed
> +by the master on low clock.
> +
> +Required properties:
> +
> +- compatible : Should be "maxim,rtc-ds1302"

Just maxim,ds1032. RTC is implied by the part number and inline with 
existing dallas,ds1307.

> +
> +Required SPI properties:
> +
> +- reg : Should be address of the device chip select within
> +  the controller.
> +
> +- spi-max-frequency : DS-1302 has 500 kHz if powered at 2.2V,
> +  and 2MHz if powered at 5V.
> +
> +- spi-3wire : The device has a shared signal IN/OUT line.
> +
> +- spi-lsb-first : DS-1302 requires least significant bit first
> +  transfers.
> +
> +- spi-cs-high: DS-1302 has active high chip select line. This is
> +  required unless inverted in hardware.
> +
> +Example:
> +
> +spi0@901c {

spi@...

> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "icpdas,spi-lp8841-rtc";

And this will need updating...

> + reg = <0x901c 0x1>;
> +
> + rtc@0 {
> + compatible = "maxim,rtc-ds1302";
> + reg = <0>;
> + spi-max-frequency = <50>;
> + spi-3wire;
> + spi-lsb-first;
> + spi-cs-high;
> + };
> +};

Re: [patch V2 22/28] x86/perf/intel/rapl: Cleanup the printk output

[Andi Kleen]

Thomas Gleixner  writes:
>  
> +static void __init rapl_advertise(void)
> +{
> + int i;
> +
> + pr_info("API unit is 2^-32 Joules, %d fixed counters, %llu ms ovfl 
> timer\n",
> + hweight32(rapl_cntr_mask), rapl_timer_ms);

Does the final resulting line contain RAPL for grepping?

Ideally would be similar as before in case someone has a parser for
this.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH v2] base: isa: Remove X86_32 dependency

[Thomas Gleixner]

On Sun, 21 Feb 2016, William Breathitt Gray wrote:

> On 01/27/2016 05:07 AM, Thomas Gleixner wrote:
> > On Fri, 22 Jan 2016, William Breathitt Gray wrote:
> >> Many motherboards utilize a LPC to ISA bridge in order to decode
> >> ISA-style port-mapped I/O addresses. This is particularly true for
> >> embedded motherboards supporting the PC/104 bus (a bus specification
> >> derived from ISA).
> >>
> >> These motherboards are now commonly running 64-bit x86 processors. The
> >> X86_32 dependency should be removed from the ISA bus configuration
> >> option in order to support these newer motherboards.
> >>
> >> A new config option, CONFIG_ISA_BUS, is introduced to allow for the
> >> compilation of the ISA bus driver independent of the CONFIG_ISA option.
> >> Devices which communicate via ISA-compatible buses can now be supported
> >> independent of the dependencies of the CONFIG_ISA option.
> >>
> >> Signed-off-by: William Breathitt Gray 
> > 
> > Reviewed-by: Thomas Gleixner 
> 
> What more can I do to help get this patch pulled in for the merge
> window?

If Greg doesn't pick it up, I'll pull it into x86 later this week

Thanks,

tglx

Re: [patch V2 28/28] x86/perf/intel/rapl: Make it modular

[Andi Kleen]

Thomas Gleixner  writes:

> Add the necessary exit functions so it can be built as a module.

If you make it a module you also need to add MODULE_DEVICE_TABLE
for the PCI IDs and also add x86_cpu_id tables/annotations
for the model numbers.

Otherwise the module would always need to be loaded manually
which would break existing setups.

Of course it's a bit of a waste because in many cases the uncore
driver will not be needed. One alternative would be to only
add some module aliases and then add code in the perf core
to probe the alias when that PMU is accessed. That would
likely work for most of perf, except for perf list (which does
not know what pmu to probe)

Other than that it's very useful, it was long overdue to make
these drivers modular.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Troubles with smatch and jiffies

[Mauro Carvalho Chehab]

Hi Dan,

I'm having some things that look like false positives when testing the media
drivers against smatch. This is bothering me for some time, but, as this was
harder to debug (as I needed to do a build with -j1), I postponed trying to
fix it for a while.

Basically, smatch is complaining for things like:

time_before(jiffies, jiffies + msecs_to_jiffies(var));

I noticed the very same behavior on two places:
drivers/media/pci/ivtv/ivtv-mailbox.c
drivers/media/rc/ati_remote.c

The enclosed patch makes smatch to shut up for ivtv build, but, IMHO,
we should make it stop making it complain about it globalwide, as the
same warning may also be appearing on other places.

FYI, I'm using here gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) and the
very latest version of smatch from git://repo.or.cz/smatch.git.

Regards,
Mauro

-- 
Thanks,
Mauro
commit 6a4d1872a94ba8450c9aff6599d1e86b515fd2a9
Author: Mauro Carvalho Chehab 
Date:   Mon Feb 22 14:55:14 2016 -0300

ivtv-mailbox: avoid confusing smatch

The current logic causes smatch to be confused:
include/linux/jiffies.h:359:41: error: strange non-value function or 
array
include/linux/jiffies.h:361:42: error: strange non-value function or 
array
include/linux/jiffies.h:359:41: error: strange non-value function or 
array
include/linux/jiffies.h:361:42: error: strange non-value function or 
array

Use a different logic.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/pci/ivtv/ivtv-mailbox.c 
b/drivers/media/pci/ivtv/ivtv-mailbox.c
index e3ce96763785..4d6a3ad265a5 100644
--- a/drivers/media/pci/ivtv/ivtv-mailbox.c
+++ b/drivers/media/pci/ivtv/ivtv-mailbox.c
@@ -177,8 +177,10 @@ static int get_mailbox(struct ivtv *itv, struct 
ivtv_mailbox_data *mbdata, int f
 
/* Sleep before a retry, if not atomic */
if (!(flags & API_NO_WAIT_MB)) {
-   if (time_after(jiffies,
-  then + msecs_to_jiffies(10*retries)))
+   unsigned int timeout;
+
+   timeout = msecs_to_jiffies(10 * retries);
+   if (time_after(jiffies, then + timeout))
   break;
ivtv_msleep_timeout(10, 0);
}

Re: [PATCH v7 0/8] Patchset enabling hardware based cross-timestamps for next gen Intel platforms

[Christopher Hall]

On Thu, 18 Feb 2016 11:26:24 -0800, John Stultz   
wrote:

On Fri, Feb 12, 2016 at 12:25 PM, Christopher S. Hall
 wrote:

Modern Intel hardware adds an Always Running Timer (ART) that allows the
network and audio device clocks to precisely cross timestamp the device
clock with the system clock. This allows a precise correlation of the
device time and system time.


Thanks for your continued persistence here Christopher!  It is looking
pretty good.

I've queued these up for testing, and if that goes well, and don't hit
anything else in review, I'll likely try to submit all but the last
patch (unless there's an acked-by from the maintainer of that code)
through Thomas for 4.6.


Hi John,

I just sent another patchset (v8). I corrected the comment problems  
pointed out by Richard Cochran. I also changed the arch/x86 code to use  
"non-stop" TSC rather than "invariant" TSC. They are *exactly* the same  
thing (i.e. read from the same bit of the CPUID leaf). The former exists  
already and should be used instead.  Patch 6/8 is the only patch that is  
changed apart from comments.


Thanks for your help reviewing this.

Chris

Re: [PATCH v6 00/12] Add T210 support in Tegra soctherm

[Matt Longnecker]

Wei,

Should changes to of-thermal should be discussed on linux-pm as opposed 
to just linux-tegra and lkml?


Should you include Eduardo on the thread?

-Matt

On 02/22/2016 12:05 AM, Wei Ni wrote:

This patchset adds following functions for tegra_soctherm driver:
1. add T210 support.
2. export debugfs to show some registers.
3. add thermtrip funciton.
4. add suspend/resume function.

The v5 serial is in:
http://www.spinics.net/lists/linux-tegra/msg25079.html
The v4 serial is in:
http://www.spinics.net/lists/linux-tegra/msg24972.html
The V3 serial is in:
http://www.spinics.net/lists/linux-tegra/msg24911.html
The V2 serial is in:
http://www.spinics.net/lists/linux-tegra/msg24901.html
The V1 serial is in:
http://www.spinics.net/lists/linux-tegra/msg24808.html

Main changes from V5:
1. Change to use linux thermal framework to implement
thermtrip funciton, per Rob's comment.
2. Add .set_trip_temp() in of-thermal driver, so that
we can set trips on hardware.

Main changes from V4:
1. Change description of devicetree binding per Rob's comment.
2. Call of_node_put to decrement refcount of the node.

Main changes from V3:
1. Change structures to "const" in chip specific files.
2. Minor changes per Thieery's comments.

Main changes from V2:
1. Fix build error in patch [1/11].
2. Use of_get_child_by_name instead of of_find_node_by_name in patch [8/11].
3. Use debugfs_remove_recursive to remove debugfs in patch [6/11].

Main changes from V1:
1. Use the new type to handl different Tegra chips in one driver, which 
suggested by Thierry.
2. Changes per Thieery's other comments.

Wei Ni (12):
   thermal: tegra: move tegra thermal files into tegra directory
   thermal: tegra: combine sensor group-related data
   thermal: tegra: get rid of PDIV/HOTSPOT hack
   thermal: tegra: split tegra_soctherm driver
   thermal: tegra: add Tegra210 specific SOC_THERM driver
   thermal: tegra: add a debugfs to show registers
   thermal: of-thermal: allow setting trip_temp on hardware
   of: add notes of critical trips for soctherm
   thermal: tegra: add thermtrip function
   thermal: tegra: add PM support
   arm64: tegra: add soctherm node for Tegra210
   arm: tegra: set critical trips for Tegra124

  .../devicetree/bindings/thermal/tegra-soctherm.txt |  12 +
  arch/arm/boot/dts/tegra124.dtsi|  16 +
  arch/arm64/boot/dts/nvidia/tegra210.dtsi   |  60 ++
  drivers/thermal/Kconfig|  12 +-
  drivers/thermal/Makefile   |   2 +-
  drivers/thermal/of-thermal.c   |   8 +
  drivers/thermal/tegra/Kconfig  |  13 +
  drivers/thermal/tegra/Makefile |   5 +
  drivers/thermal/tegra/soctherm-fuse.c  | 169 +
  drivers/thermal/tegra/soctherm.c   | 685 +
  drivers/thermal/tegra/soctherm.h   | 123 
  drivers/thermal/tegra/tegra124-soctherm.c  | 196 ++
  drivers/thermal/tegra/tegra210-soctherm.c  | 197 ++
  drivers/thermal/tegra_soctherm.c   | 476 --
  include/dt-bindings/thermal/tegra124-soctherm.h|   1 +
  include/linux/thermal.h|   1 +
  16 files changed, 1489 insertions(+), 487 deletions(-)
  create mode 100644 drivers/thermal/tegra/Kconfig
  create mode 100644 drivers/thermal/tegra/Makefile
  create mode 100644 drivers/thermal/tegra/soctherm-fuse.c
  create mode 100644 drivers/thermal/tegra/soctherm.c
  create mode 100644 drivers/thermal/tegra/soctherm.h
  create mode 100644 drivers/thermal/tegra/tegra124-soctherm.c
  create mode 100644 drivers/thermal/tegra/tegra210-soctherm.c
  delete mode 100644 drivers/thermal/tegra_soctherm.c

Re: [PATCH v5 2/3] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

[Michael Turquette]

Quoting Sylwester Nawrocki (2016-02-17 02:03:36)
> On 16/02/16 07:20, Krzysztof Kozlowski wrote:
> > Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> > so it is built also on ARMv7. This does not bring any kind of benefit.
> > There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> > multi_v7 for ARMv7).
> > 
> > Instead build clock drivers only for respective SoC's architecture.
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> 
> Acked-by: Sylwester Nawrocki 
> 

Thanks for the Ack.

I've rebased patches #1 and #2 against James's b9e65ebc654d and pushed
the clk-samsung branch to the clk tree. I have deleted the
clk-samsung-kconfig branch that was blowing up the kbuild robot.
clk-samsung will not be rebased and can be used as a dependency for
arm-soc. It has been merged into clk-next.

Regards,
Mike

[PATCH v3 00/10] arm64: Introduce Allwinner A64 and Pine64 support

[Andre Przywara]

Hi,

another update of the Allwinner A64 / Pine64 support series.
I added a solution for the PLL6 reuse issue (the same patch I posted
yesterday). Also I addressed the comments I got from Rob and Chen-Yu.
For a changelog see below.

This series provides initial support for the Allwinner A64 SoC,
which is based on four ARM Cortex-A53 cores implementing the ARMv8
64-bit architecture.
On top of this there is also initial support for the Pine64 board,
for which you can find more information and links in the linux-sunxi
Wiki [1].
The resulting kernel boots fine on my development samples I have
here, though the actual boot process is a bit involved at the moment.
You can find more information and a ready-to-flash image here [2].

Patch 1/10 removes the hardcoded "pll6" name for the PLL6 clock, so
it can be reused for the A64's PLL7, patch 2/10 uses that facility
for the Allwinner H3 SoC's PLL8.
Patch 3/10 enables the Allwinner/sunxi platform for the arm64
architecture, so one can select the required drivers during
configuration.
Patch 4/10 adds the pinctrl driver, which has been on the list before.
Patch 5 and 6 add a new generic driver for the bus clock gates which
relies on DT for providing the parent relationship. That makes adding
new SoCs much easier, since there should be no more kernel code
changes necessary.
Patch 7-9 add the new vendor name and the device tree files, the former
for the SoC itself, the latter for the Pine64 boards.
The final patch 10 updates defconfig, so that the generic arm64 kernel
supports the basic SoC drivers out of the box.

In the moment we support the basic peripherals like GIC, timer, clocks,
GPIOs, UARTs and (since v2) I2C.
The MMC IP block has changed a bit compared to previous SoCs, so the
existing driver is not 100% compatible. However the default delays seem
to work fine for the SD cards, so I included all the necessary bits in
here, since working MMC makes this series indefinitely more usable.
We can fix both the MMC driver and the DT in a compatible way later.

Please have a look and comment on the patches. We might want to split
the series if some patches seem too controversial for being merged
soonish, please let me know if this is the case and I am happy to
rearrange the series.

The patches are based on mripard/sunxi/for-next (since linux-next is
a bit messy atm). A working repo can be found over here[3].

Cheers,
Andre

Changelog v1 .. v2:
- Change the naming of DT nodes, identifiers and file names to include
  the wonderful Allwinner architecture prefix everywhere. You asked
  for it, you got it, enjoy!
- Drop SUNXI_MMC to be selected automatically, instead put it in the
  defconfig.
- Add a binding documentation for the new multi-bus-gates driver.
- Add a defconfig update patch.
- Lots of changes in the DTs, see the respective patches for details.

Changelog v2 .. v3:
- Reordered sunxi section in ARM64 platform config.
- Add PLL6 reuse patch and rework the .dtsi to use the existing binding.
- Drop unneeded module boilerplate for the pinctrl driver.
- Rename "owa" pin to "spdif".
- Rename pll8 to pll7 in the DT.
- Remove leading 0 in DT node address parts.
- Added Acks from Rob.

[1] http://linux-sunxi.org/Pine64
[2] https://github.com/apritzel/pine64
[3] https://github.com/apritzel/linux/commits/a64-v3

Andre Przywara (10):
  clk: sunxi: allow PLL6 clock to be reused
  ARM: dts: sunxi: make PLL8 in the H3 a proper clock
  arm64: Introduce Allwinner SoC config option
  drivers: pinctrl: add driver for Allwinner A64 SoC
  DT: clk: sunxi: add binding doc for the multi-bus-gates clock
  clk: sunxi: add generic multi-parent bus clock gates driver
  arm64: dts: add Allwinner A64 SoC .dtsi
  of: add vendor prefix for Pine64
  arm64: dts: add Pine64 support
  arm64: add defconfig options for Allwinner SoCs

 Documentation/devicetree/bindings/arm/sunxi.txt|   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt  |   7 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi|  18 +-
 arch/arm64/Kconfig.platforms   |   6 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/allwinner/Makefile |   5 +
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi|  80 +++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  59 ++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  58 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 624 +
 arch/arm64/configs/defconfig   |   7 +
 drivers/clk/sunxi/Makefile |   1 +
 drivers/clk/sunxi/clk-factors.c|   3 +-
 drivers/clk/sunxi/clk-factors.h|   1 +
 drivers/clk/sunxi/clk-multi-gates.c| 105 
 drivers/clk/sunxi/clk-sunxi.c  |   4 +-
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/

[PATCH v3 02/10] ARM: dts: sunxi: make PLL8 in the H3 a proper clock

[Andre Przywara]

Now that we can reuse the A31 PLL6 clock driver for clocks other then
PLL6 itself, describe the PLL8 clock properly.

Signed-off-by: Andre Przywara 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3ba65c2..d84ea9b 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -137,12 +137,12 @@
clock-output-names = "pll6d2";
};
 
-   /* dummy clock until pll6 can be reused */
-   pll8: pll8_clk {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <1>;
-   clock-output-names = "pll8";
+   pll8: clk@c01c20044 {
+   #clock-cells = <1>;
+   compatible = "allwinner,sun6i-a31-pll6-clk";
+   reg = <0x01c20044 0x4>;
+   clocks = <&osc24M>;
+   clock-output-names = "pll8", "pll8x2";
};
 
cpu: cpu_clk@01c20050 {
@@ -243,7 +243,7 @@
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20088 0x4>;
-   clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+   clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
clock-output-names = "mmc0",
 "mmc0_output",
 "mmc0_sample";
@@ -253,7 +253,7 @@
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c2008c 0x4>;
-   clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+   clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
clock-output-names = "mmc1",
 "mmc1_output",
 "mmc1_sample";
@@ -263,7 +263,7 @@
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20090 0x4>;
-   clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+   clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
clock-output-names = "mmc2",
 "mmc2_output",
 "mmc2_sample";
-- 
2.6.4

[PATCH v3 05/10] DT: clk: sunxi: add binding doc for the multi-bus-gates clock

[Andre Przywara]

Recent Allwinner SoCs introduced a bus gates clock which can have
different parents for individual gates.
For the time being we encoded this relation in the driver.
This commit specifies a new binding which allows to encode this in
the DT by using a child node for each parent clock used. This allows
to specify any kind of relation efficiently and also keeps the very
same kernel driver for all SoCs at the same time.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index c09f59b..323af8e 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -79,6 +79,7 @@ Required properties:
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+   "allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
@@ -119,6 +120,11 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. 
The first output
 is the normal PLL6 output, or "pll6". The second output is rate doubled
 PLL6, or "pll6x2".
 
+The "allwinner,sunxi-multi-bus-gates-clk" holds the actual clocks in
+child nodes, where each one specifies the parent clock that the particular
+gates are depending from. The child nodes each follow the common clock
+binding as described in this document.
+
 The "allwinner,*-mmc-clk" clocks have three different outputs: the
 main clock, with the ID 0, and the output and sample clocks, with the
 IDs 1 and 2, respectively.
-- 
2.6.4

[PATCH v3 09/10] arm64: dts: add Pine64 support

[Andre Przywara]

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara 
---
Changelog v1 .. v2:
- move aliases node into the common board DT file
- move fixed MMC regulator into the common board DT file
- drop UARTs 1-4 nodes from the default DT
- add I2C node (pins seem to be dedicated to I2C)

 arch/arm64/boot/dts/Makefile   |  1 +
 arch/arm64/boot/dts/allwinner/Makefile |  5 ++
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi| 80 ++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 59 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 58 
 5 files changed, 203 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a..3b7428a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index 000..1e29a5a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
new file mode 100644
index 000..d5a7249
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library 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 library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64.dtsi"
+
+/ {
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+};
+
+&mmc0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+   vmmc-supply = <®_vcc3v3>;
+   cd-gpios = <&

[PATCH v3 07/10] arm64: dts: add Allwinner A64 SoC .dtsi

[Andre Przywara]

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
Changelog v1 .. v2:
- remove compatible string from the .dtsi
- amend compatible names to include sun50i
- drop PSCI 0.1 compatibility
- use lowercase hex digits in the GIC node too
- make pll6x2 an explicit fixed-factor clock
- make pll8 and pll8x2 proper clocks
- amend MMC clocks to match the manual, they are now mod0 clocks
- adapt MMC nodes to new MMC clocks
- add separate 4-pin and 2-pin definitions for the UARTs
- add I2C pins and driver nodes
- switch ahb_rst node to use normal compatible name, not the special,
  early-registration one.
Changelog v2 .. v3:
- remove leading zeros from node names' address part
- adapt PLL6/7/8 to proper PLL6 binding
- rename PLL6 to PLL7

 Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 624 ++
 3 files changed, 626 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc..7e59d8b 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 323af8e..b7bd40d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -80,6 +80,7 @@ Required properties:
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
+   "allwinner,sun50i-a64-bus-gates-clk" - for the bus gates on A64
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index 000..fb9c509
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,624 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *Copyright (C) 2015 Jens Kuske 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+

[PATCH v3 06/10] clk: sunxi: add generic multi-parent bus clock gates driver

[Andre Przywara]

The Allwinner H3 SoC introduced bus clock gates with potentially
different parents per clock gate. The H3 driver chose to hardcode the
actual parent clock relation in the code.
Add a new driver (which has the potential to drive the H3 and also
the simple clock gates as well) which uses the power of DT to describe
this relationship in an elegant and flexible way.
Using one subnode for every parent clock we get away with a single
DT compatible match, which can be used as a fallback value in the
actual DTs without the need to add specific compatible strings to the
code.  This avoids adding a new driver or function for every new SoC.

Signed-off-by: Andre Przywara 
Acked-by: Jean-Francois Moine 
---
 drivers/clk/sunxi/Makefile  |   1 +
 drivers/clk/sunxi/clk-multi-gates.c | 105 
 2 files changed, 106 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..3a9dc31 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-multi-gates.o
 obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
diff --git a/drivers/clk/sunxi/clk-multi-gates.c 
b/drivers/clk/sunxi/clk-multi-gates.c
new file mode 100644
index 000..76e715a
--- /dev/null
+++ b/drivers/clk/sunxi/clk-multi-gates.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * Based on clk-sun8i-bus-gates.c, which is:
+ *  Copyright (C) 2015 Jens Kuske 
+ * Based on clk-simple-gates.c, which is:
+ *  Copyright 2015 Maxime Ripard 
+ *
+ * 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 
+
+static DEFINE_SPINLOCK(gates_lock);
+
+static void __init sunxi_parse_parent(struct device_node *node,
+ struct clk_onecell_data *clk_data,
+ void __iomem *reg)
+{
+   const char *parent = of_clk_get_parent_name(node, 0);
+   const char *clk_name;
+   struct property *prop;
+   struct clk *clk;
+   const __be32 *p;
+   int index, i = 0;
+
+   of_property_for_each_u32(node, "clock-indices", prop, p, index) {
+   of_property_read_string_index(node, "clock-output-names",
+ i, &clk_name);
+
+   clk = clk_register_gate(NULL, clk_name, parent, 0,
+   reg + 4 * (index / 32), index % 32,
+   0, &gates_lock);
+   i++;
+   if (IS_ERR(clk)) {
+   pr_warn("could not register gate clock \"%s\"\n",
+   clk_name);
+   continue;
+   }
+   if (clk_data->clks[index])
+   pr_warn("bus-gate clock %s: index #%d already 
registered as %s\n",
+   clk_name, index, "?");
+   else
+   clk_data->clks[index] = clk;
+   }
+}
+
+static void __init sunxi_multi_bus_gates_init(struct device_node *node)
+{
+   struct clk_onecell_data *clk_data;
+   struct device_node *child;
+   struct property *prop;
+   struct resource res;
+   void __iomem *reg;
+   const __be32 *p;
+   int number = 0;
+   int index;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+   if (IS_ERR(reg))
+   return;
+
+   clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+   if (!clk_data)
+   goto err_unmap;
+
+   for_each_child_of_node(node, child)
+   of_property_for_each_u32(child, "clock-indices", prop, p, index)
+   number = max(number, index);
+
+   clk_data->clks = kcalloc(number + 1, sizeof(struct clk *), GFP_KERNEL);
+   if (!clk_data->clks)
+   goto err_free_data;
+
+   for_each_child_of_node(node, child)
+   sunxi_parse_parent(child, clk_data, reg);
+
+   clk_data->clk_num = number + 1;
+   if (of_clk_add_provider(node, of_clk_src_onecell_get, clk_data))
+   pr_err("registering bus-gate clock %s failed\n", node->name);
+
+   return;
+
+err_free_data:
+   kfree(clk_data);
+err_unmap:
+   iounmap(reg);
+   of_address_to_resource(node, 0, &res);
+   release_me

[PATCH v3 03/10] arm64: Introduce Allwinner SoC config option

[Andre Przywara]

To prepare for the Allwinner A64 SoC support, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for the arm64 architecture as well.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.

Signed-off-by: Andre Przywara 
---
 arch/arm64/Kconfig.platforms | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..97f5690 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -72,6 +72,11 @@ config ARCH_SEATTLE
 config ARCH_SHMOBILE
bool
 
+config ARCH_SUNXI
+   bool "Allwinner sunxi 64-bit SoC Family"
+   help
+ This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_RENESAS
bool "Renesas SoC Platforms"
select ARCH_SHMOBILE
-- 
2.6.4

[PATCH v3 04/10] drivers: pinctrl: add driver for Allwinner A64 SoC

[Andre Przywara]

Based on the Allwinner A64 user manual and on the previous sunxi
pinctrl drivers this introduces the pin multiplex assignments for
the ARMv8 Allwinner A64 SoC.
Port A is apparently used for the fixed function DRAM controller, so
the ports start at B here (the manual mentions "n from 1 to 7", so
not starting at 0).

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm64/Kconfig.platforms   |   1 +
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c | 602 +
 5 files changed, 609 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..08b2361 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun50i-a64-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 97f5690..63a690d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -74,6 +74,7 @@ config ARCH_SHMOBILE
 
 config ARCH_SUNXI
bool "Allwinner sunxi 64-bit SoC Family"
+   select PINCTRL_SUN50I_A64
help
  This enables support for Allwinner sunxi based SoCs like the A64.
 
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..c1f970f 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R
depends on RESET_CONTROLLER
select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN50I_A64
+   bool
+   select PINCTRL_SUNXI_COMMON
+
 endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..0ca7681 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)   += 
pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)+= pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)  += pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
+obj-$(CONFIG_PINCTRL_SUN50I_A64)   += pinctrl-sun50i-a64.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)   += pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c 
b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
new file mode 100644
index 000..a53cc23
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
@@ -0,0 +1,602 @@
+/*
+ * Allwinner A64 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 - ARM Ltd.
+ * Author: Andre Przywara 
+ *
+ * Based on pinctrl-sun7i-a20.c, which is:
+ * Copyright (C) 2014 Maxime Ripard 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin a64_pins[] = {
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* TX */
+ SUNXI_FUNCTION(0x4, "jtag"),  /* MS0 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* EINT0 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* RX */
+ SUNXI_FUNCTION(0x4, "jtag"),  /* CK0 */
+ SUNXI_FUNCTION(0x5, "sim"),   /* VCCEN */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* EINT1 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
+ SUNXI_FUNCTION(0x4, "jtag"),  /* DO0 */
+ SUNXI_FUNCTION(0x5, "sim"),   /* VPPEN */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* EINT2 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1