[PATCH v2 3/3] hw_random: timeriomem_rng: Improve performance for sub-jiffie update periods

2017-04-05 Thread Rick Altherr
Some hardware RNGs provide a single register for obtaining random data.
Instead of signaling when new data is available, the reader must wait a
fixed amount of time between reads for new data to be generated.
timeriomem_rng implements this scheme with the period specified in
platform data or device tree.  While the period is specified in
microseconds, the implementation used a standard timer which has a
minimum delay of 1 jiffie and caused a significant bottleneck for
devices that can update at 1us.  By switching to an hrtimer, 1us periods
now only delay at most 2us per read.

Signed-off-by: Rick Altherr 
---

Changes in v2:
- Split performance improvements into separate patch

 drivers/char/hw_random/timeriomem-rng.c | 86 +
 1 file changed, 45 insertions(+), 41 deletions(-)

diff --git a/drivers/char/hw_random/timeriomem-rng.c 
b/drivers/char/hw_random/timeriomem-rng.c
index 024bdff7999f..a0faa5f05deb 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -21,23 +21,24 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 
 struct timeriomem_rng_private {
void __iomem*io_base;
-   unsigned intexpires;
-   unsigned intperiod;
+   ktime_t period;
unsigned intpresent:1;
 
-   struct timer_list   timer;
+   struct hrtimer  timer;
struct completion   completion;
 
struct hwrngrng_ops;
@@ -48,10 +49,13 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void 
*data,
 {
struct timeriomem_rng_private *priv =
container_of(hwrng, struct timeriomem_rng_private, rng_ops);
-   unsigned long cur;
-   s32 delay;
+   int retval = 0;
+   int period_us = ktime_to_us(priv->period);
 
-   /* The RNG provides 32-bit per read.  Ensure there is enough space. */
+   /*
+* The RNG provides 32-bits per read.  Ensure there is enough space for
+* at minimum one read.
+*/
if (max < sizeof(u32))
return 0;
 
@@ -66,33 +70,44 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void 
*data,
 
wait_for_completion(>completion);
 
-   *(u32 *)data = readl(priv->io_base);
+   do {
+   /*
+* After the first read, all additional reads will need to wait
+* for the RNG to generate new data.  Since the period can have
+* a wide range of values (1us to 1s have been observed), allow
+* for 1% tolerance in the sleep time rather than a fixed value.
+*/
+   if (retval > 0)
+   usleep_range(period_us,
+   period_us + min(1, period_us / 100));
+
+   *(u32 *)data = readl(priv->io_base);
+   retval += sizeof(u32);
+   data += sizeof(u32);
+   max -= sizeof(u32);
+   } while (wait && max > sizeof(u32));
 
/*
 * Block any new callers until the RNG has had time to generate new
 * data.
 */
-   cur = jiffies;
-
-   delay = cur - priv->expires;
-   delay = priv->period - (delay % priv->period);
-
-   priv->expires = cur + delay;
priv->present = 0;
-
reinit_completion(>completion);
-   mod_timer(>timer, priv->expires);
+   hrtimer_forward_now(>timer, priv->period);
+   hrtimer_restart(>timer);
 
-   return 4;
+   return retval;
 }
 
-static void timeriomem_rng_trigger(unsigned long data)
+static enum hrtimer_restart timeriomem_rng_trigger(struct hrtimer *timer)
 {
struct timeriomem_rng_private *priv
-   = (struct timeriomem_rng_private *)data;
+   = container_of(timer, struct timeriomem_rng_private, timer);
 
priv->present = 1;
complete(>completion);
+
+   return HRTIMER_NORESTART;
 }
 
 static int timeriomem_rng_probe(struct platform_device *pdev)
@@ -140,43 +155,33 @@ static int timeriomem_rng_probe(struct platform_device 
*pdev)
period = pdata->period;
}
 
-   priv->period = usecs_to_jiffies(period);
-   if (priv->period < 1) {
-   dev_err(>dev, "period is less than one jiffy\n");
-   return -EINVAL;
-   }
-
-   priv->expires   = jiffies;
-   priv->present   = 1;
-
+   priv->period = ns_to_ktime(period * NSEC_PER_USEC);
init_completion(>completion);
-   complete(>completion);
-
-   setup_timer(>timer, timeriomem_rng_trigger, (unsigned long)priv);
+   hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+   priv->timer.function = timeriomem_rng_trigger;
 
priv->rng_ops.name = dev_name(>dev);
priv->rng_ops.read = 

[PATCH v2 0/3] hw_random: timeriomem_rng: Migrate to new API and improve performance

2017-04-05 Thread Rick Altherr
AST2400 can generate 32-bits of random data every 1us.  Original driver
was limited to one 32-bit read every jiffie due to deprecated API and use
of timers.  Migrating to new hwrng API and switching to hrtimers
improves read performance of /dev/hwrng to 13Mb/s.

Changes in v2:
- Split API migration into separate patch
- Split type and variable renames into separate patch
- Split performance improvements into separate patch

Rick Altherr (3):
  hw_random: Migrate timeriomem_rng to new API
  hw_random: timeriomem_rng: Shorten verbose type and variable names
  hw_random: timeriomem_rng: Improve performance for sub-jiffie update
periods

 drivers/char/hw_random/timeriomem-rng.c | 157 
 1 file changed, 80 insertions(+), 77 deletions(-)

-- 
2.12.2.715.g7642488e1d-goog



Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver

2017-04-05 Thread Stephen Boyd
On 03/15, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> This patch enables clocks for STM32H743 boards.

Like what clocks exactly? All of them?

> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt 
> b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> new file mode 100644
> index 000..9d4b587
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> @@ -0,0 +1,152 @@
> +STMicroelectronics STM32H7 Reset and Clock Controller
> +=
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please refer to clock-bindings.txt for common clock controller binding usage.
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Required properties:
> +- compatible: Should be:
> +  "st,stm32h743-rcc"
> +
> +- reg: should be register base and length as documented in the
> +  datasheet
> +
> +- #reset-cells: 1, see below
> +
> +- #clock-cells : from common clock binding; shall be set to 1
> +
> +- clocks: External oscillator clock phandle
> +  - high speed external clock signal (HSE)
> +  - low speed external clock signal (LSE)
> +  - external I2S clock (I2S_CKIN)
> +
> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
> +  write protection (RTC clock).
> +
> +- pll x node: Allow to register a pll with specific parameters.
> +  Please see PLL section below.
> +
> +Example:
> +
> + rcc: rcc@58024400 {
> + #reset-cells = <1>;
> + #clock-cells = <2>
> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
> + reg = <0x58024400 0x400>;
> + clocks = <_hse>, <_lse>, <_i2s_ckin>;
> +
> + st,syscfg = <>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vco1@58024430 {
> + #clock-cells = <0>;
> + compatible = "stm32,pll";
> + reg = <0>;

reg is super confusing and doesn't match unit address.

> + };

Why? Shouldn't we know this from the compatible string how many
PLLs there are and where they're located? Export the PLLs through
rcc node's clock-cells?

> +
> + vco2@58024438 {
> + #clock-cells = <0>;
> + compatible = "stm32,pll";
> + reg = <1>;

reg is super confusing and doesn't match unit address.

> + st,clock-div = <2>;
> + st,clock-mult = <40>;
> + st,frac-status = <0>;
> + st,frac = <0>;
> + st,vcosel = <1>;
> + st,pllrge = <2>;

Does this stuff change on a per-board basis? I hope none of these
properties need to be in DT.

> + };
> + };
> +
> +
> +STM32H7 PLL
> +---
> +
[...]
> +
> +Specifying softreset control of devices
> +===
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index 
> specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example, for CRC reset:
> +  crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 
> 1107
> +
> +All available preprocessor macros for reset are defined 
> dt-bindings//mfd/stm32h7-rcc.h

One too many slashes?

> +header and can be used in device tree sources.
> +
> +example:
> +
> + timer2 {
> + resets  = < STM32H7_APB1L_RESET(TIM2)>;
> + };
> diff --git a/drivers/clk/clk-stm32h7.c b/drivers/clk/clk-stm32h7.c
> new file mode 100644
> index 000..c8eb729
> --- /dev/null
> +++ b/drivers/clk/clk-stm32h7.c
> @@ -0,0 +1,1586 @@
> +/*
> + * Copyright (C) Gabriel Fernandez 2017
> + * Author: Gabriel Fernandez 
> + *
> + * License terms: GPL V2.0.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 

Is this used?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* Reset Clock 

Re: [PATCH v6] vfio error recovery: kernel support

2017-04-05 Thread Michael S. Tsirkin
On Wed, Apr 05, 2017 at 04:19:10PM -0600, Alex Williamson wrote:
> On Thu, 6 Apr 2017 00:50:22 +0300
> "Michael S. Tsirkin"  wrote:
> 
> > On Wed, Apr 05, 2017 at 01:38:22PM -0600, Alex Williamson wrote:
> > > The previous intention of trying to handle all sorts of AER faults
> > > clearly had more value, though even there the implementation and
> > > configuration requirements restricted the practicality.  For instance
> > > is AER support actually useful to a customer if it requires all ports
> > > of a multifunction device assigned to the VM?  This seems more like a
> > > feature targeting whole system partitioning rather than general VM
> > > device assignment use cases.  Maybe that's ok, but it should be a clear
> > > design decision.  
> > 
> > Alex, what kind of testing do you expect to be necessary?
> > Would you say testing on real hardware and making it trigger
> > AER errors is a requirement?
> 
> Testing various fatal, non-fatal, and corrected errors with aer-inject,
> especially in multfunction configurations (where more than one port
> is actually usable) would certainly be required.  If we have cases where
> the driver for a companion function can escalate a non-fatal error to a
> bus reset, that should be tested, even if it requires temporary hacks to
> the host driver for the companion function to trigger that case.  AER
> handling is not something that the typical user is going to experience,
> so it should to be thoroughly tested to make sure it works when needed
> or there's little point to doing it at all.  Thanks,
> 
> Alex

Some things can be tested within a VM. What would you
say would be sufficient on a VM and what has to be
tested on bare metal?

-- 
MST


Re: [PATCH] x86/signals: Fix lower/upper bound reporting in compat siginfo

2017-04-05 Thread Dave Hansen
On 04/04/2017 02:53 PM, Joerg Roedel wrote:
> On Tue, Apr 04, 2017 at 09:56:45AM -0700, Dave Hansen wrote:
>> On 04/04/2017 09:15 AM, Joerg Roedel wrote:
>>> Put the right values from the original siginfo into the
>>> userspace compat-siginfo.
>>>
>>> This fixes the 32-bit mpx tabletest on a 64-bit kernel.
>>
>> Ugh, thanks for finding that.
> 
> Yeah, I was also looking at the vaddrexhaust test, but is that supposed
> to work? It does pretty weird things at least, on 64 bit the function
> effectivly does nothing because nr_to_fill evaluates to 0 there, and on
> 32 bit it gets a (probably #BF) exception which is not caught, so that
> the test fails.
> 
> I am a bit confused, but maybe I just didn't stare long enough at it :-)
> Hope you can sched some light on it.

That code can probably just get removed from the tests.  I haven't run
it in a while and it's probably not worth refreshing.



Re: [PATCH 0/5] fpga: enhancements to support non-dt code

2017-04-05 Thread Alan Tull
On Fri, Mar 24, 2017 at 2:11 PM, Moritz Fischer
 wrote:
> On Fri, Mar 24, 2017 at 01:09:22PM -0500, Alan Tull wrote:
>> On Mon, Mar 13, 2017 at 4:53 PM, Alan Tull  wrote:
>> > Set of patches that supports writing code that uses
>> > FPGA regions without Device Tree overlays.
>>
>> OK here's where I try to clarify my intention for this code.  And
>> beg for reviews :)
>
> It's on the todo list ;-)

Thanks!  I could post a branch on linux-fpga git if that's helpful.

Most of the patches are small.  The last patch is large as it is moving
code from fpga-region.c to a new header and new of-fpga-region.c.
I think this patchset will be useful for the current 'Intel FPGA Driver'
patchset.

Alan

>
> Cheers,
>
> Moritz


Re: [PATCH V7 1/4] dt-bindings: phy: Add support for QUSB2 phy

2017-04-05 Thread Stephen Boyd
On 04/05, Vivek Gautam wrote:
> Qualcomm chipsets have QUSB2 phy controller that provides
> HighSpeed functionality for DWC3 controller.
> Adding dt binding information for the same.
> 
> Signed-off-by: Vivek Gautam 
> Acked-by: Rob Herring 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH V7 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

2017-04-05 Thread Stephen Boyd
On 04/05, Vivek Gautam wrote:
> Qualcomm SOCs have QMP phy controller that provides support
> to a number of controller, viz. PCIe, UFS, and USB.
> Add a new driver, based on generic phy framework, for this
> phy controller.
> 
> Signed-off-by: Vivek Gautam 
> Tested-by: Srinivas Kandagatla 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


[PATCH v6 5/6] platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure

2017-04-05 Thread Kuppuswamy Sathyanarayanan
iTCO_wdt driver need access to PMC_CFG GCR register to modify the
noreboot setting. Currently, this is done by passing PMC_CFG reg
address as memory resource to watchdog driver and allowing it directly
modify the PMC_CFG register. But currently PMC driver also has
requirement to memory map the entire GCR register space in this driver.
This causes mem request failure in watchdog driver. So this patch fixes
this issue by adding API to update noreboot flag and passes them
to watchdog driver via platform data.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/platform/x86/intel_pmc_ipc.c | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

Changes since v5:
 * Fixed some style issues in commit history.
 * removed unused variable gcr_size from intel_pmc_ipc_dev

Changes since v4:
 * Fixed some style issues in commit history.
 * Used macros instead of BIT() calls.

Changes since v3:
 * Rebased on top of latest changes.

Changes since v2: 
 * Added support for update_noreboot_bit api.

diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index a0c773b..173940f 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -112,6 +112,13 @@
 #define TCO_PMC_OFFSET 0x8
 #define TCO_PMC_SIZE   0x4
 
+/* PMC register bit definitions */
+
+/* PMC_CFG_REG bit masks */
+#define PMC_CFG_NO_REBOOT_MASK BIT(4)
+#define PMC_CFG_NO_REBOOT_ENABLE   BIT(4)
+#define PMC_CFG_NO_REBOOT_DISABLE  0
+
 static struct intel_pmc_ipc_dev {
struct device *dev;
void __iomem *ipc_base;
@@ -126,8 +133,6 @@ static struct intel_pmc_ipc_dev {
struct platform_device *tco_dev;
 
/* gcr */
-   resource_size_t gcr_base;
-   int gcr_size;
void __iomem *gcr_mem_base;
bool has_gcr_regs;
 
@@ -313,6 +318,18 @@ int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val)
 }
 EXPORT_SYMBOL_GPL(intel_pmc_gcr_update);
 
+static int update_no_reboot_bit(void *priv, bool set)
+{
+   if (set)
+   return intel_pmc_gcr_update(PMC_GCR_PMC_CFG_REG,
+   PMC_CFG_NO_REBOOT_MASK,
+   PMC_CFG_NO_REBOOT_ENABLE);
+
+   return intel_pmc_gcr_update(PMC_GCR_PMC_CFG_REG,
+   PMC_CFG_NO_REBOOT_MASK,
+   PMC_CFG_NO_REBOOT_DISABLE);
+}
+
 static int intel_pmc_ipc_check_status(void)
 {
int status;
@@ -630,15 +647,13 @@ static struct resource tco_res[] = {
{
.flags = IORESOURCE_IO,
},
-   /* GCS */
-   {
-   .flags = IORESOURCE_MEM,
-   },
 };
 
 static struct itco_wdt_platform_data tco_info = {
.name = "Apollo Lake SoC",
.version = 5,
+   .no_reboot_priv = ,
+   .update_no_reboot_bit = update_no_reboot_bit,
 };
 
 #define TELEMETRY_RESOURCE_PUNIT_SSRAM 0
@@ -695,10 +710,6 @@ static int ipc_create_tco_device(void)
res->start = ipcdev.acpi_io_base + SMI_EN_OFFSET;
res->end = res->start + SMI_EN_SIZE - 1;
 
-   res = tco_res + TCO_RESOURCE_GCR_MEM;
-   res->start = ipcdev.gcr_base + TCO_PMC_OFFSET;
-   res->end = res->start + TCO_PMC_SIZE - 1;
-
pdev = platform_device_register_full();
if (IS_ERR(pdev))
return PTR_ERR(pdev);
@@ -860,9 +871,7 @@ static int ipc_plat_get_res(struct platform_device *pdev)
}
ipcdev.ipc_base = addr;
 
-   ipcdev.gcr_base = res->start + PLAT_RESOURCE_GCR_OFFSET;
ipcdev.gcr_mem_base = addr + PLAT_RESOURCE_GCR_OFFSET;
-   ipcdev.gcr_size = PLAT_RESOURCE_GCR_SIZE;
dev_info(>dev, "ipc res: %pR\n", res);
 
ipcdev.telem_res_inval = 0;
-- 
2.7.4



[PATCH v6 4/6] watchdog: iTCO_wdt: Add PMC specific noreboot update api

2017-04-05 Thread Kuppuswamy Sathyanarayanan
In some SoCs, setting noreboot bit needs modification to
PMC GC registers. But not all PMC drivers allow other drivers
to memory map their GC region. This could create mem request
conflict in watchdog driver. So this patch adds facility to allow
PMC drivers to pass noreboot update function to watchdog
drivers via platform data.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-by: Guenter Roeck 
---
 drivers/watchdog/iTCO_wdt.c| 20 ++--
 include/linux/platform_data/itco_wdt.h |  4 
 2 files changed, 18 insertions(+), 6 deletions(-)

Changes since v5:
 * Added priv_data to pass private data to no_reboot_bit update function.
 * Changed update_noreboot_flag() to update_no_reboot_bit

Changes since v4:
 * Fixed some style issues.
 * used false for 0 and true for 1 in update_noreboot_flag function.

Changes since v3:
 * Rebased on top of latest.

Changes since v2: 
 * Removed use of PMC API's directly in watchdog driver.
 * Added update_noreboot_flag to handle no IPC PMC compatibility
   issue mentioned by Guenter.

diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
index d8768a2..3f00029 100644
--- a/drivers/watchdog/iTCO_wdt.c
+++ b/drivers/watchdog/iTCO_wdt.c
@@ -106,6 +106,8 @@ struct iTCO_wdt_private {
struct pci_dev *pci_dev;
/* whether or not the watchdog has been suspended */
bool suspended;
+   /* no reboot API private data */
+   void *no_reboot_priv;
/* no reboot update function pointer */
int (*update_no_reboot_bit)(void *p, bool set);
 };
@@ -225,6 +227,8 @@ void iTCO_wdt_no_reboot_bit_setup(struct iTCO_wdt_private 
*p)
p->update_no_reboot_bit = update_no_reboot_bit_pci;
else
p->update_no_reboot_bit = update_no_reboot_bit_def;
+
+   p->no_reboot_priv = p;
 }
 
 static int iTCO_wdt_start(struct watchdog_device *wd_dev)
@@ -237,7 +241,7 @@ static int iTCO_wdt_start(struct watchdog_device *wd_dev)
iTCO_vendor_pre_start(p->smi_res, wd_dev->timeout);
 
/* disable chipset's NO_REBOOT bit */
-   if (p->update_no_reboot_bit(p, false)) {
+   if (p->update_no_reboot_bit(p->no_reboot_priv, false)) {
spin_unlock(>io_lock);
pr_err("failed to reset NO_REBOOT flag, reboot disabled by 
hardware/BIOS\n");
return -EIO;
@@ -278,7 +282,7 @@ static int iTCO_wdt_stop(struct watchdog_device *wd_dev)
val = inw(TCO1_CNT(p));
 
/* Set the NO_REBOOT bit to prevent later reboots, just for sure */
-   p->update_no_reboot_bit(p, true);
+   p->update_no_reboot_bit(p->no_reboot_priv, true);
 
spin_unlock(>io_lock);
 
@@ -442,14 +446,18 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
 
p->iTCO_version = pdata->version;
p->pci_dev = to_pci_dev(dev->parent);
+   p->no_reboot_priv = pdata->no_reboot_priv;
 
-   iTCO_wdt_no_reboot_bit_setup(p);
+   if (pdata->update_no_reboot_bit)
+   p->update_no_reboot_bit = pdata->update_no_reboot_bit;
+   else
+   iTCO_wdt_no_reboot_bit_setup(p);
 
/*
 * Get the Memory-Mapped GCS or PMC register, we need it for the
 * NO_REBOOT flag (TCO v2 and v3).
 */
-   if (p->iTCO_version >= 2) {
+   if (p->iTCO_version >= 2 && !pdata->update_no_reboot_bit) {
p->gcs_pmc_res = platform_get_resource(pdev,
   IORESOURCE_MEM,
   ICH_RES_MEM_GCS_PMC);
@@ -459,14 +467,14 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
}
 
/* Check chipset's NO_REBOOT bit */
-   if (p->update_no_reboot_bit(p, false) &&
+   if (p->update_no_reboot_bit(p->no_reboot_priv, false) &&
iTCO_vendor_check_noreboot_on()) {
pr_info("unable to reset NO_REBOOT flag, device disabled by 
hardware/BIOS\n");
return -ENODEV; /* Cannot reset NO_REBOOT bit */
}
 
/* Set the NO_REBOOT bit to prevent later reboots, just for sure */
-   p->update_no_reboot_bit(p, true);
+   p->update_no_reboot_bit(p->no_reboot_priv, true);
 
/* The TCO logic uses the TCO_EN bit in the SMI_EN register */
if (!devm_request_region(dev, p->smi_res->start,
diff --git a/include/linux/platform_data/itco_wdt.h 
b/include/linux/platform_data/itco_wdt.h
index f16542c..0e95527 100644
--- a/include/linux/platform_data/itco_wdt.h
+++ b/include/linux/platform_data/itco_wdt.h
@@ -14,6 +14,10 @@
 struct itco_wdt_platform_data {
char name[32];
unsigned int version;
+   /* private data to be passed to update_no_reboot_bit API */
+   void *no_reboot_priv;
+   /* pointer for platform specific no reboot update function */
+   int (*update_no_reboot_bit)(void *priv, bool set);
 };
 
 #endif /* _ITCO_WDT_H_ */
-- 

[PATCH v6 3/6] watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions

2017-04-05 Thread Kuppuswamy Sathyanarayanan
iTCO_wdt no_reboot_bit set/unset functions has lot of common code between
them. So merging these two functions into a single update function would
remove these unnecessary code duplications. This patch fixes this issue
by creating a no_reboot_bit update function to handle both set/unset
functions.

Also checking for iTCO version every time you make no_reboot_bit set/unset
call is inefficient and makes the code look complex. This can be improved
by performing this check once during device probe and selecting the
appropriate no_reboot_bit update function. This patch fixes this issue
by splitting the update function into multiple helper functions.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/watchdog/iTCO_wdt.c | 83 +++--
 1 file changed, 50 insertions(+), 33 deletions(-)

Changes since v5:
 * Changed update function argument name from "status" to "set".
 * Fixed commit history.
 * Changed update function name to use "bit" instead of "flag"
 * Addressed Andy's comment on creating multiple helper functions.

diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
index 3d0abc0..d8768a2 100644
--- a/drivers/watchdog/iTCO_wdt.c
+++ b/drivers/watchdog/iTCO_wdt.c
@@ -106,6 +106,8 @@ struct iTCO_wdt_private {
struct pci_dev *pci_dev;
/* whether or not the watchdog has been suspended */
bool suspended;
+   /* no reboot update function pointer */
+   int (*update_no_reboot_bit)(void *p, bool set);
 };
 
 /* module parameters */
@@ -170,48 +172,61 @@ static inline u32 no_reboot_bit(struct iTCO_wdt_private 
*p)
return enable_bit;
 }
 
-static void iTCO_wdt_set_NO_REBOOT_bit(struct iTCO_wdt_private *p)
+static int inline update_no_reboot_bit_def(void *priv, bool set)
 {
-   u32 val32;
-
-   /* Set the NO_REBOOT bit: this disables reboots */
-   if (p->iTCO_version >= 2) {
-   val32 = readl(p->gcs_pmc);
-   val32 |= no_reboot_bit(p);
-   writel(val32, p->gcs_pmc);
-   } else if (p->iTCO_version == 1) {
-   pci_read_config_dword(p->pci_dev, 0xd4, );
-   val32 |= no_reboot_bit(p);
-   pci_write_config_dword(p->pci_dev, 0xd4, val32);
-   }
+   return 0;
 }
 
-static int iTCO_wdt_unset_NO_REBOOT_bit(struct iTCO_wdt_private *p)
+static int inline update_no_reboot_bit_pci(void *priv, bool set)
 {
-   u32 enable_bit = no_reboot_bit(p);
-   u32 val32 = 0;
+   struct iTCO_wdt_private *p = priv;
+   u32 val32 = 0, newval32 = 0;
 
-   /* Unset the NO_REBOOT bit: this enables reboots */
-   if (p->iTCO_version >= 2) {
-   val32 = readl(p->gcs_pmc);
-   val32 &= ~enable_bit;
-   writel(val32, p->gcs_pmc);
+   pci_read_config_dword(p->pci_dev, 0xd4, );
+   if (set)
+   val32 |= no_reboot_bit(p);
+   else
+   val32 &= ~no_reboot_bit(p);
+   pci_write_config_dword(p->pci_dev, 0xd4, val32);
+   pci_read_config_dword(p->pci_dev, 0xd4, );
 
-   val32 = readl(p->gcs_pmc);
-   } else if (p->iTCO_version == 1) {
-   pci_read_config_dword(p->pci_dev, 0xd4, );
-   val32 &= ~enable_bit;
-   pci_write_config_dword(p->pci_dev, 0xd4, val32);
+   /* make sure the update is successful */
+   if (val32 != newval32)
+   return -EIO;
 
-   pci_read_config_dword(p->pci_dev, 0xd4, );
-   }
+   return 0;
+}
+
+static int inline update_no_reboot_bit_mem(void *priv, bool set)
+{
+   struct iTCO_wdt_private *p = priv;
+   u32 val32 = 0, newval32 = 0;
+
+   val32 = readl(p->gcs_pmc);
+   if (set)
+   val32 |= no_reboot_bit(p);
+   else
+   val32 &= ~no_reboot_bit(p);
+   writel(val32, p->gcs_pmc);
+   newval32 = readl(p->gcs_pmc);
 
-   if (val32 & enable_bit)
+   /* make sure the update is successful */
+   if (val32 != newval32)
return -EIO;
 
return 0;
 }
 
+void iTCO_wdt_no_reboot_bit_setup(struct iTCO_wdt_private *p)
+{
+   if (p->iTCO_version >= 2)
+   p->update_no_reboot_bit = update_no_reboot_bit_mem;
+   else if (p->iTCO_version == 1)
+   p->update_no_reboot_bit = update_no_reboot_bit_pci;
+   else
+   p->update_no_reboot_bit = update_no_reboot_bit_def;
+}
+
 static int iTCO_wdt_start(struct watchdog_device *wd_dev)
 {
struct iTCO_wdt_private *p = watchdog_get_drvdata(wd_dev);
@@ -222,7 +237,7 @@ static int iTCO_wdt_start(struct watchdog_device *wd_dev)
iTCO_vendor_pre_start(p->smi_res, wd_dev->timeout);
 
/* disable chipset's NO_REBOOT bit */
-   if (iTCO_wdt_unset_NO_REBOOT_bit(p)) {
+   if (p->update_no_reboot_bit(p, false)) {
spin_unlock(>io_lock);
pr_err("failed to reset NO_REBOOT flag, reboot disabled by 

[PATCH v6 2/6] platform/x86: intel_pmc_ipc: Add pmc gcr read/write/update api's

2017-04-05 Thread Kuppuswamy Sathyanarayanan
This patch adds API's to read/write/update PMC GC registers.
PMC dependent devices like iTCO_wdt, Telemetry has requirement
to acces GCR registers. These API's can be used for this
purpose.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 arch/x86/include/asm/intel_pmc_ipc.h |  21 +++
 drivers/platform/x86/intel_pmc_ipc.c | 115 +++
 2 files changed, 136 insertions(+)

Changes since v5:
 * Removed redundant temp variable in intel_pmc_gcr_update().
 * Changed label name from "gcr_update_err" to "gcr_ipc_unlock"
 * Fixed some style issues.

Changes since v4:
 * Fixed style issue in commit history
 * Added mutex locks in read/write/update API's.

Changes since v3:
 * Added usage comments for read/write/update api
 * Created a helper function to handle GCR related range checks.

Changes since v2:
 * Removed unused reg offset from header file.
 * Modified read/write api's signatures for better error handling
 * Added function for bit level update of gcr register.

diff --git a/arch/x86/include/asm/intel_pmc_ipc.h 
b/arch/x86/include/asm/intel_pmc_ipc.h
index 4291b6a..8402efe 100644
--- a/arch/x86/include/asm/intel_pmc_ipc.h
+++ b/arch/x86/include/asm/intel_pmc_ipc.h
@@ -23,6 +23,9 @@
 #define IPC_ERR_EMSECURITY 6
 #define IPC_ERR_UNSIGNEDKERNEL 7
 
+/* GCR reg offsets from gcr base*/
+#define PMC_GCR_PMC_CFG_REG0x08
+
 #if IS_ENABLED(CONFIG_INTEL_PMC_IPC)
 
 int intel_pmc_ipc_simple_command(int cmd, int sub);
@@ -31,6 +34,9 @@ int intel_pmc_ipc_raw_cmd(u32 cmd, u32 sub, u8 *in, u32 inlen,
 int intel_pmc_ipc_command(u32 cmd, u32 sub, u8 *in, u32 inlen,
u32 *out, u32 outlen);
 int intel_pmc_s0ix_counter_read(u64 *data);
+int intel_pmc_gcr_read(u32 offset, u32 *data);
+int intel_pmc_gcr_write(u32 offset, u32 data);
+int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val);
 
 #else
 
@@ -56,6 +62,21 @@ static inline int intel_pmc_s0ix_counter_read(u64 *data)
return -EINVAL;
 }
 
+static inline int intel_pmc_gcr_read(u32 offset, u32 *data)
+{
+   return -EINVAL;
+}
+
+static inline int intel_pmc_gcr_write(u32 offset, u32 data)
+{
+   return -EINVAL;
+}
+
+static inline int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val)
+{
+   return -EINVAL;
+}
+
 #endif /*CONFIG_INTEL_PMC_IPC*/
 
 #endif
diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index 0a33592..a0c773b 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -128,6 +128,7 @@ static struct intel_pmc_ipc_dev {
/* gcr */
resource_size_t gcr_base;
int gcr_size;
+   void __iomem *gcr_mem_base;
bool has_gcr_regs;
 
/* punit */
@@ -199,6 +200,119 @@ static inline u64 gcr_data_readq(u32 offset)
return readq(ipcdev.ipc_base + offset);
 }
 
+static inline int is_gcr_valid(u32 offset)
+{
+   if (!ipcdev.has_gcr_regs)
+   return -EACCES;
+
+   if (offset > PLAT_RESOURCE_GCR_SIZE)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
+ * intel_pmc_gcr_read() - Read PMC GCR register
+ * @offset:offset of GCR register from GCR address base
+ * @data:  data pointer for storing the register output
+ *
+ * Reads the PMC GCR register of given offset.
+ *
+ * Return: negative value on error or 0 on success.
+ */
+int intel_pmc_gcr_read(u32 offset, u32 *data)
+{
+   int ret;
+
+   mutex_lock();
+
+   ret = is_gcr_valid(offset);
+   if (ret < 0) {
+   mutex_unlock();
+   return ret;
+   }
+
+   *data = readl(ipcdev.gcr_mem_base + offset);
+
+   mutex_unlock();
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(intel_pmc_gcr_read);
+
+/**
+ * intel_pmc_gcr_write() - Write PMC GCR register
+ * @offset:offset of GCR register from GCR address base
+ * @data:  register update value
+ *
+ * Writes the PMC GCR register of given offset with given
+ * value.
+ *
+ * Return: negative value on error or 0 on success.
+ */
+int intel_pmc_gcr_write(u32 offset, u32 data)
+{
+   int ret;
+
+   mutex_lock();
+
+   ret = is_gcr_valid(offset);
+   if (ret < 0) {
+   mutex_unlock();
+   return ret;
+   }
+
+   writel(data, ipcdev.gcr_mem_base + offset);
+
+   mutex_unlock();
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(intel_pmc_gcr_write);
+
+/**
+ * intel_pmc_gcr_update() - Update PMC GCR register bits
+ * @offset:offset of GCR register from GCR address base
+ * @mask:  bit mask for update operation
+ * @val:   update value
+ *
+ * Updates the bits of given GCR register as specified by
+ * @mask and @val.
+ *
+ * Return: negative value on error or 0 on success.
+ */
+int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val)
+{
+   u32 new_val;
+   int ret = 0;
+
+   mutex_lock();
+
+   ret = is_gcr_valid(offset);
+   if (ret < 0)
+ 

[PATCH v6 6/6] platform/x86: intel_pmc_ipc: use gcr mem base for S0ix counter read

2017-04-05 Thread Kuppuswamy Sathyanarayanan
To maintain the uniformity in accessing GCR registers, this patch
modifies the S0ix counter read function to use GCR address base
instead of ipc address base.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Rajneesh Bhardwaj 
Tested-by: Shanth Murthy 
---
 arch/x86/include/asm/intel_pmc_ipc.h |  2 ++
 drivers/platform/x86/intel_pmc_ipc.c | 10 +++---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/intel_pmc_ipc.h 
b/arch/x86/include/asm/intel_pmc_ipc.h
index 8402efe..fac89eb 100644
--- a/arch/x86/include/asm/intel_pmc_ipc.h
+++ b/arch/x86/include/asm/intel_pmc_ipc.h
@@ -25,6 +25,8 @@
 
 /* GCR reg offsets from gcr base*/
 #define PMC_GCR_PMC_CFG_REG0x08
+#define PMC_GCR_TELEM_DEEP_S0IX_REG0x78
+#define PMC_GCR_TELEM_SHLW_S0IX_REG0x80
 
 #if IS_ENABLED(CONFIG_INTEL_PMC_IPC)
 
diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index 173940f..3c9de18 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -57,10 +57,6 @@
 #define IPC_WRITE_BUFFER   0x80
 #define IPC_READ_BUFFER0x90
 
-/* PMC Global Control Registers */
-#define GCR_TELEM_DEEP_S0IX_OFFSET 0x1078
-#define GCR_TELEM_SHLW_S0IX_OFFSET 0x1080
-
 /* Residency with clock rate at 19.2MHz to usecs */
 #define S0IX_RESIDENCY_IN_USECS(d, s)  \
 ({ \
@@ -202,7 +198,7 @@ static inline u32 ipc_data_readl(u32 offset)
 
 static inline u64 gcr_data_readq(u32 offset)
 {
-   return readq(ipcdev.ipc_base + offset);
+   return readq(ipcdev.gcr_mem_base + offset);
 }
 
 static inline int is_gcr_valid(u32 offset)
@@ -906,8 +902,8 @@ int intel_pmc_s0ix_counter_read(u64 *data)
if (!ipcdev.has_gcr_regs)
return -EACCES;
 
-   deep = gcr_data_readq(GCR_TELEM_DEEP_S0IX_OFFSET);
-   shlw = gcr_data_readq(GCR_TELEM_SHLW_S0IX_OFFSET);
+   deep = gcr_data_readq(PMC_GCR_TELEM_DEEP_S0IX_REG);
+   shlw = gcr_data_readq(PMC_GCR_TELEM_SHLW_S0IX_REG);
 
*data = S0IX_RESIDENCY_IN_USECS(deep, shlw);
 
-- 
2.7.4



Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

2017-04-05 Thread Russell King - ARM Linux
On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote:
> When coherent DMA memory without struct page is shared, importer
> fails to find the page and runs into kernel page fault when it
> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
> for more information on this problem.
> 
> This solution allows coherent DMA memory without struct page to be
> shared by providing a way for the exporter to tag the DMA buffer as
> a special buffer without struct page association and passing the
> information in sg_table to the importer. This information is used
> in attach/map_sg to avoid cleaning D-cache and mapping.
> 
> The details of the change are:
> 
> Framework:
> - Add a new dma_attrs field to struct scatterlist.
> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>   Coherent memory without struct page.
> - Add a new dma_check_dev_coherent() interface to check if memory is
>   the device coherent area. There is no way to tell where the memory
>   returned by dma_alloc_attrs() came from.
> 
> Exporter logic:
> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>   DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>   done in the exporter context.
> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>   page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>   set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>   dma_address and dma_attrs fields in struct scatterlist for this sgl.
>   This is done in exporter context when buffer is exported. With this

This sentence appears to just end...

I'm not convinced that coherent allocations should be setting the "page"
of a scatterlist to anything that isn't a real struct page or NULL.  It
is, after all, an error to look up the virtual address etc of the
scatterlist entry or kmap it when it isn't backed by a struct page.

I'm actually already passing non-page backed memory through the DMA API
in armada-drm, although not entirely correctly, and etnaviv handles it
fine:

} else if (dobj->linear) {
/* Single contiguous physical region - no struct page */
if (sg_alloc_table(sgt, 1, GFP_KERNEL))
goto free_sgt;
sg_dma_address(sgt->sgl) = dobj->dev_addr;
sg_dma_len(sgt->sgl) = dobj->obj.size;

This is not quite correct, as it assumes (which is safe for it currently)
that the DMA address is the same on all devices.  On Dove, which is where
this is used, that is the case, but it's not true elsewhere.  Also note
that I'm avoid calling dma_map_sg() and dma_unmap_sg() - there's no iommus
to be considered.

I'd suggest that this follows the same pattern - setting the DMA address
(more appropriately for generic code) and the DMA length, while leaving
the virtual address members NULL/0.  However, there's also the
complication of setting up any IOMMUs that would be necessary.  I haven't
looked at that, or how it could work.

I also think this should be documented in the dmabuf API that it can
pass such scatterlists that are DMA-parameter only.

Lastly, I'd recommend that anything using this does _not_ provide
functional kmap/kmap_atomic support for these - kmap and kmap_atomic
are both out because there's no struct page anyway (and their use would
probably oops the kernel in this scenario.)  I avoided mmap support in
armada drm, but if there's a pressing reason and real use case for the
importer to mmap() the buffers in userspace, it's something I could be
convinced of.

What I'm quite certain of is that we do _not_ want to be passing
coherent memory allocations into the streaming DMA API, not even with
a special attribute.  The DMA API is about gaining coherent memory
(shared ownership of the buffer), or mapping system memory to a
specified device (which can imply unique ownership.)  Trying to mix
the two together muddies the separation that we have there, and makes
it harder to explain.  As can be seen from this patch, we'd end up
needing to add this special DMA_ATTR_DEV_COHERENT_NOPAGE everywhere,
which is added complexity on top of stuff that is not required for
this circumstance.

I can see why you're doing it, to avoid having to duplicate more of
the generic code in drm_prime, but I don't think plasting over this
problem in arch code by adding this special flag is a particularly
good way forward.

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


[PATCH] docs/vm/transhuge: Fix few trivial typos

2017-04-05 Thread SeongJae Park
Signed-off-by: SeongJae Park 
---
 Documentation/vm/transhuge.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index cd28d5ee5273..4e22578e50d3 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -266,7 +266,7 @@ for each mapping.
 
 The number of file transparent huge pages mapped to userspace is available
 by reading ShmemPmdMapped and ShmemHugePages fields in /proc/meminfo.
-To identify what applications are mapping file  transparent huge pages, it
+To identify what applications are mapping file transparent huge pages, it
 is necessary to read /proc/PID/smaps and count the FileHugeMapped fields
 for each mapping.
 
@@ -292,7 +292,7 @@ thp_collapse_alloc_failed is incremented if khugepaged 
found a range
the allocation.
 
 thp_file_alloc is incremented every time a file huge page is successfully
-i  allocated.
+   allocated.
 
 thp_file_mapped is incremented every time a file huge page is mapped into
user address space.
@@ -501,7 +501,7 @@ scanner can get reference to a page is 
get_page_unless_zero().
 
 All tail pages have zero ->_refcount until atomic_add(). This prevents the
 scanner from getting a reference to the tail page up to that point. After the
-atomic_add() we don't care about the ->_refcount value.  We already known how
+atomic_add() we don't care about the ->_refcount value. We already known how
 many references should be uncharged from the head page.
 
 For head page get_page_unless_zero() will succeed and we don't mind. It's
@@ -519,8 +519,8 @@ comes. Splitting will free up unused subpages.
 
 Splitting the page right away is not an option due to locking context in
 the place where we can detect partial unmap. It's also might be
-counterproductive since in many cases partial unmap unmap happens during
-exit(2) if an THP crosses VMA boundary.
+counterproductive since in many cases partial unmap happens during exit(2) if
+an THP crosses VMA boundary.
 
 Function deferred_split_huge_page() is used to queue page for splitting.
 The splitting itself will happen when we get memory pressure via shrinker
-- 
2.12.0



Re: [PATCH -v6 05/13] futex: Change locking rules

2017-04-05 Thread Darren Hart
On Wed, Mar 22, 2017 at 11:35:52AM +0100, Peter Zijlstra wrote:
> Currently futex-pi relies on hb->lock to serialize everything. Since
> hb->lock is giving us problems (PI inversions among other things,
> since on -rt hb lock itself is a rt_mutex), we want to break this up a
> bit.
> 
> This patch reworks and documents the locking. Notably, it
> consistently uses rt_mutex::wait_lock to serialize {uval, pi_state}.
> This would allow us to do rt_mutex_unlock() (including deboost)
> without holding hb->lock.
> 
> Nothing yet relies on the new locking rules.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  kernel/futex.c |  165 
> +
>  1 file changed, 132 insertions(+), 33 deletions(-)
> 
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -973,6 +973,39 @@ void exit_pi_state_list(struct task_stru
>   *
>   * [10] There is no transient state which leaves owner and user space
>   *   TID out of sync.
> + *
> + *
> + * Serialization and lifetime rules:
> + *
> + * hb->lock:
> + *
> + *   hb -> futex_q, relation
> + *   futex_q -> pi_state, relation
> + *
> + *   (cannot be raw because hb can contain arbitrary amount
> + *of futex_q's)
> + *
> + * pi_mutex->wait_lock:
> + *
> + *   {uval, pi_state}
> + *
> + *   (and pi_mutex 'obviously')
> + *
> + * p->pi_lock:

This documentation uses a mix of types and common variable names. I'd recommend
some declarations just below "Serialization and lifetime rules:" to help make
this explicit, e.g.:

struct futex_pi_state *pi_state;
struct futex_hash_bucket *hb;
struct rt_mutex *pi_mutex;
struct futex_q *q;
task_struct *p;

> + *
> + *   p->pi_state_list -> pi_state->list, relation
> + *
> + * pi_state->refcount:
> + *
> + *   pi_state lifetime
> + *
> + *
> + * Lock order:
> + *
> + *   hb->lock
> + * pi_mutex->wait_lock
> + *   p->pi_lock
> + *
>   */
>  
>  /*
> @@ -980,10 +1013,12 @@ void exit_pi_state_list(struct task_stru
>   * the pi_state against the user space value. If correct, attach to
>   * it.
>   */
> -static int attach_to_pi_state(u32 uval, struct futex_pi_state *pi_state,
> +static int attach_to_pi_state(u32 __user *uaddr, u32 uval,
> +   struct futex_pi_state *pi_state,
> struct futex_pi_state **ps)
>  {
>   pid_t pid = uval & FUTEX_TID_MASK;
> + int ret, uval2;

The uval should be an unsigned type:

u32 uval2;

>  
>   /*
>* Userspace might have messed up non-PI and PI futexes [3]
> @@ -991,9 +1026,34 @@ static int attach_to_pi_state(u32 uval,
>   if (unlikely(!pi_state))
>   return -EINVAL;
>  
> + /*
> +  * We get here with hb->lock held, and having found a
> +  * futex_top_waiter(). This means that futex_lock_pi() of said futex_q
> +  * has dropped the hb->lock in between queue_me() and unqueue_me_pi(),

This context got here like this:

futex_lock_pi
hb lock
futex_lock_pi_atomic
top waiter
attach_to_pi_state()

The queue_me and unqueue_me_pi both come after this in futex_lock_pi.
Also, the hb lock is dropped in queue_me, not between queue_me and
unqueue_me_pi.

Are you saying that in order to be here, there are at least two tasks contending
for the lock, and one that has come before us has proceeded as far as queue_me()
but has not yet entered unqueue_me_pi(), therefor we know there is a waiter and
it has a pi_state? If so, I think we can make this much clearer by at least
noting the two tasks in play.

...

> @@ -1336,6 +1418,7 @@ static int wake_futex_pi(u32 __user *uad
>  
>   if (cmpxchg_futex_value_locked(, uaddr, uval, newval)) {
>   ret = -EFAULT;
> +

Stray whitespace addition? Not explicitly against coding-style, but I don't
normally see a new line before the closing brace leading to an else...

>   } else if (curval != uval) {
>   /*
>* If a unconditional UNLOCK_PI operation (user space did not

...

-- 
Darren Hart
VMware Open Source Technology Center


Re: [PATCH] Revert "Input: bma150 - avoid binding to bma180 if IIO bma180 driver present" and "Input: bma150 - extend chip detection for bma180"

2017-04-05 Thread Dmitry Torokhov
On Wed, Apr 05, 2017 at 09:16:28PM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 01.04.2017 um 18:46 schrieb Dmitry Torokhov :
> > 
> > On Sat, Apr 01, 2017 at 04:59:26PM +0200, Hans de Goede wrote:
> >> Hi,
> >> 
> >> On 01-04-17 16:44, H. Nikolaus Schaller wrote:
> >>> This reverts commit baf28d91e7b1 ("Input: bma150 - avoid binding to 
> >>> bma180 if IIO bma180 driver present")
> >>> and commit ef3714fdbc8d ("Input: bma150 - extend chip detection for 
> >>> bma180")
> >>> 
> >>> Rationale: initially (2012) the GTA04 device using a bma180 chip simply 
> >>> refereced
> >>> the bma150 platform driver in its board file [1] which happened to work 
> >>> in all
> >>> scenarios that were tested.
> >>> 
> >>> When conversion to DT started (2014), we needed to make the driver be 
> >>> still
> >>> recognised. Hence we introduced the compatibility to the bma180 chip in
> >>> Linux 3.15-rc5 [2] without further checks if it is really 100% 
> >>> compatible. This
> >>> worked flawlessly for years with the GTA04 device.
> >>> 
> >>> Recently (2016), Hans de Goede pointed out that the chips are not as 
> >>> similar
> >>> as they appeared and the driver works with the bma180 for the GTA04 only
> >>> by good luck. He proposed to remove the bma180 support completely [3], but
> >>> we still did need it until we have a replacement. Thus, a condifional 
> >>> compile
> >>> was added.
> >>> 
> >>> We have now developed a generic iio-input-bridge which works with any 2 or
> >>> 3 axis iio based accelerometer. It has been tested on GTA04 and Pyra and
> >>> works as expected. Therefore we can remove the bma180 support from this
> >>> driver completely. User-space API compatibility can be restored by using 
> >>> the
> >>> iio-input-bridge.
> >>> 
> >>> Maybe it is time to convert the bma150 driver to iio as well and retire 
> >>> the
> >>> accelerometer input drivers completely but this is a different story and 
> >>> task.
> >>> 
> >>> [1]: 
> >>> https://github.com/neilbrown/linux/blob/gta04/3.2.y/arch/arm/mach-omap2/board-omap3gta04.c#L976
> >>> [2]: https://patchwork.kernel.org/patch/3961171/
> >>> [3]: https://patchwork.kernel.org/patch/9325481/
> >>> 
> >>> Signed-off-by: H. Nikolaus Schaller 
> >> 
> >> Looks good to me:
> >> 
> >> Reviewed-by: Hans de Goede 
> > 
> > Changed subject slightly (we are not reverting because patches were
> > defective, we are removing support for bma180), and applied.
> 
> Just noticed: the subject in linux-next has a typo:
> Should IMHO be "Input: bma150 - remove support for bma180"
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f069b5a0b27ad4a87e9351e54fbcab3d3f8a9fd5

Yeah, I screwed up there. Unfortunately it is buries too deep now.

Thanks.

-- 
Dmitry


[PATCH] qlge: avoid format string exposure in workqueue

2017-04-05 Thread Kees Cook
While unlikely, this makes sure the workqueue name won't be processed
as a format string.

Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/qlogic/qlge/qlge_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c 
b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index e9e647072596..1188d420fe53 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -4686,7 +4686,8 @@ static int ql_init_device(struct pci_dev *pdev, struct 
net_device *ndev,
/*
 * Set up the operating parameters.
 */
-   qdev->workqueue = alloc_ordered_workqueue(ndev->name, WQ_MEM_RECLAIM);
+   qdev->workqueue = alloc_ordered_workqueue("%s", WQ_MEM_RECLAIM,
+ ndev->name);
INIT_DELAYED_WORK(>asic_reset_work, ql_asic_reset_work);
INIT_DELAYED_WORK(>mpi_reset_work, ql_mpi_reset_work);
INIT_DELAYED_WORK(>mpi_work, ql_mpi_work);
-- 
2.7.4


-- 
Kees Cook
Pixel Security


Re: [PATCH v5 2/2] iio: Aspeed ADC

2017-04-05 Thread Stephen Boyd
On 04/01, Jonathan Cameron wrote:
> On 28/03/17 22:52, Rick Altherr wrote:
> > Aspeed BMC SoCs include a 16 channel, 10-bit ADC. Low and high threshold
> > interrupts are supported by the hardware but are not currently implemented.
> > 
> > Signed-off-by: Rick Altherr 
> Two really trivial things inline. I'll fix them whilst applying rather than
> having you do a v6 - please do sanity check I haven't messed it up though!
> 
> Applied to the togreg branch of iio.git and pushed out as testing for
> the autobuilders to play with it.
> 

Oh I was too late. Blame work. Anyway, I made some comments on
v4. If they're fixed in a later patch or discussed on list that's
fine. No worries on my end.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH v2 2/2] clk: stm32f4: fix timeout management for pll and ready gate

2017-04-05 Thread Stephen Boyd
On 03/16, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> Use a classic polling to test bit ready.
> And the shift of the bit ready of LSE & LSI were wrongs.
> 
> Fixes: 861adc44d290 ("clk: stm32f4: Add LSI & LSE clocks")
> 
> Signed-off-by: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH v2 1/2] clk: stm32f4: fix: exclude values 0 and 1 for PLLQ

2017-04-05 Thread Stephen Boyd
On 03/16, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> : PLLQ = 0, wrong configuration
> 0001: PLLQ = 1, wrong configuration
> ...
> 0010: PLLQ = 2
> 0011: PLLQ = 3
> 0100: PLLQ = 4
> ...
> : PLLQ = 1
> 
> Use divider table to exclude 0 and 1 values.
> 
> Fixes: 83135ad3c517 ("clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 
> boards")
> 
> Signed-off-by: Gabriel Fernandez 
> ---

Applied to clk-fixes

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

2017-04-05 Thread Matthew Wilcox
On Wed, Apr 05, 2017 at 03:49:52PM -0400, Jeff Layton wrote:
> > That only gives us 20 bits of counter, but I think that's enough.
> 
> 2^20 is 1048576, which seems a little small to me.
> 
> We may end up bumping the counter on every failed I/O. How fast can we
> generate 1M failed I/Os? :)

So there's a one-in-a-million chance of missing a failed I/O ... if
we're generating lots of errors, the next time the app calls fsync(),
it'll notice the other million times we've hit the problem :-)

> Actually...we could put this field in the inode instead of the mapping.
> I know we've traditionally tracked this in the mapping, but is that
> required here?
> 
> If we put this field in the inode then perhaps we can union it with
> something and mitigate the cost of a larger counter...maybe in the
> i_pipe union? I don't think S_ISREG inodes use anything in there, do
> they?

But writeback isn't just done on ISREG inodes, but also on S_ISBLK inodes,
which use i_bdev (right?)

Another possibility is to move this out of the address_space and into
either the super_block or the backing_device_info.  Errors don't tend
to be constrained to a single file but affect the entire filesystem,
or even multiple filesystems if you have a partitioned block device ...


Re: [PATCH v2] cris: remove unused wp_works_ok macro

2017-04-05 Thread Jesper Nilsson
On Wed, Apr 05, 2017 at 09:24:35PM +0200, Mathias Krause wrote:
> It had no use since it's introduction in v2.4.1.2. Get rid of it.
> 
> Cc: Mikael Starvik 
> Signed-off-by: Mathias Krause 
> Acked-by: Jesper Nilsson 
> ---
> Same patch as v1 but as the tip folks took only the x86 parts, I think,
> this one should go through the CRIS tree.

Allright, I'll take it through the CRIS tree.

Thanks,

> Cheers,
> Mathias

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com


Re: [PATCH] IB/hns: include linux/of.h to fix build failure

2017-04-05 Thread Doug Ledford
On 4/4/2017 9:36 AM, Tobias Regnery wrote:
> I see the following build error in an arm64 randconfig build:
> 
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c: In function 'hns_roce_v1_reset':
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1384:15: error: implicit 
> declaration of function 'of_parse_phandle' 
> [-Werror=implicit-function-declaration]
> 
> Fix this by including linux/of.h directly.
> 
> Signed-off-by: Tobias Regnery 
> ---
> This is against next-20170404
> 
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index ec68f56e8ee5..0f7e85c7b70b 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "hns_roce_common.h"
>  #include "hns_roce_device.h"
> 

Hi Tobias, I already picked up this same change from another person.
Thanks.

-- 
Doug Ledford 
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD



signature.asc
Description: OpenPGP digital signature


Re: [PATCH] arm64: xen: Implement EFI reset_system callback

2017-04-05 Thread Stefano Stabellini
On Wed, 5 Apr 2017, Julien Grall wrote:
> When rebooting DOM0 with ACPI, the kernel is crashing with the stack trace 
> [1].
> 
> This is happening because when EFI runtimes are enabled, the reset code
> (see machin_restart) will first try to use EFI restart method.
> 
> However, the EFI restart code is expecting the reset_system callback to
> be always set. This is not the case for Xen and will lead to crash.
> 
> Looking at the reboot path, it is expected to fallback on an alternative
> reboot method if one does not work. So implement reset_system callback
> as a NOP for Xen.
> 
> [   36.999270] reboot: Restarting system
> [   37.002921] Internal error: Attempting to execute userspace memory: 
> 8604 [#1] PREEMPT SMP
> [   37.011460] Modules linked in:
> [   37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 
> 4.11.0-rc1-3-g1e248b60a39b-dirty #506
> [   37.023903] Hardware name: (null) (DT)
> [   37.027734] task: 800902068000 task.stack: 800902064000
> [   37.033739] PC is at 0x0
> [   37.036359] LR is at efi_reboot+0x94/0xd0
> [   37.040438] pc : [<>] lr : [] pstate: 
> 404001c5
> [   37.047920] sp : 800902067cf0
> [   37.051314] x29: 800902067cf0 x28: 800902068000
> [   37.056709] x27: 08992000 x26: 008e
> [   37.062104] x25: 0123 x24: 0015
> [   37.067499] x23:  x22: 08e6e250
> [   37.072894] x21: 08e6e000 x20: 
> [   37.078289] x19: 08e5d4c8 x18: 0010
> [   37.083684] x17: a7c27470 x16: deadbeef
> [   37.089079] x15: 0006 x14: 88f42bef
> [   37.094474] x13: 08f42bfd x12: 08e706c0
> [   37.099870] x11: 08e7 x10: 05f5e0ff
> [   37.105265] x9 : 800902067a50 x8 : 6974726174736552
> [   37.110660] x7 : 08cc6fb8 x6 : 08cc6fb0
> [   37.116055] x5 : 08c97dd8 x4 : 
> [   37.121453] x3 :  x2 : 
> [   37.126845] x1 :  x0 : 
> [   37.132239]
> [   37.133808] Process systemd-shutdow (pid: 1, stack limit = 
> 0x800902064000)
> [   37.141118] Stack: (0x800902067cf0 to 0x800902068000)
> [   37.146949] 7ce0:   800902067d40 
> 08085334
> [   37.154869] 7d00:  08f3b000 800902067d40 
> 080852e0
> [   37.162787] 7d20: 08cc6fb0 08cc6fb8 08c7f580 
> 08c97dd8
> [   37.170706] 7d40: 800902067d60 080e2c2c  
> 01234567
> [   37.178624] 7d60: 800902067d80 080e2ee8  
> 080e2df4
> [   37.186544] 7d80:  080830f0  
> 8008ff1c1000
> [   37.194462] 7da0:  a7c4b1cc  
> 0024
> [   37.202380] 7dc0: 800902067dd0 0005 f24743c8 
> 0004
> [   37.210299] 7de0: f2475f03 0010 f2474418 
> 0005
> [   37.218218] 7e00: f2474578 000a d6b722c0 
> 0001
> [   37.226136] 7e20: 0123 0038 800902067e50 
> 081e7294
> [   37.234055] 7e40: 800902067e60 081e935c 800902067e60 
> 081e9388
> [   37.241973] 7e60: 800902067eb0 081ea388  
> 8008ff1c1000
> [   37.249892] 7e80:  a7c4a79c  
> 0002
> [   37.257810] 7ea0: 0104   
> 080830f0
> [   37.265729] 7ec0: fee1dead 28121969 01234567 
> 
> [   37.273651] 7ee0:  80800080 80008080 
> feffa9a9d4ff2d66
> [   37.281567] 7f00: 008e feffa9a9d5b60e0f 7f7f7f7f 
> 0101010101010101
> [   37.289485] 7f20: 0010 0008 003a 
> a7ccf588
> [   37.297404] 7f40: d6b87d00 a7c4b1b0 f2474be0 
> d6b88000
> [   37.305326] 7f60: f2474fb0 01234567  
> 
> [   37.313240] 7f80:  0001 d6b70d4d 
> 
> [   37.321159] 7fa0: 0001 f2474ea0 d6b5e2e0 
> f2474e80
> [   37.329078] 7fc0: a7c4b1cc  fee1dead 
> 008e
> [   37.336997] 7fe0:   9ce839cffee77eab 
> fafdbf9f7ed57f2f
> [   37.344911] Call trace:
> [   37.347437] Exception stack(0x800902067b20 to 0x800902067c50)
> [   37.353970] 7b20: 08e5d4c8 0001 80f82000 
> 
> [   37.361883] 7b40: 800902067b60 08e17000 08f44c68 
> 0001081081b4
> [   37.369802] 7b60: 800902067bf0 08108478  
> 

Re: [PATCH -v6 06/13] futex: Cleanup refcounting

2017-04-05 Thread Darren Hart
On Wed, Mar 22, 2017 at 11:35:53AM +0100, Peter Zijlstra wrote:
> Since we're going to add more refcount fiddling, introduce
> get_pi_state() to match the existing put_pi_state().
> 
> Signed-off-by: Peter Zijlstra (Intel) 

This looks awfully familiar... https://lkml.org/lkml/2015/12/20/5 ... I guess
timing is everything :-) Since we have an incoming need:

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center


Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

2017-04-05 Thread Michael S. Tsirkin
On Wed, Apr 05, 2017 at 08:29:34AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 05, 2017 at 06:24:50AM +0200, Mike Galbraith wrote:
> > On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:
> > 
> > > Any issues at all left with this tree?
> > > In particular any regressions?
> > 
> > Nothing blatantly obvious in a testdrive that lasted a couple minutes. 
> >  I'd have to beat on it a bit to look for things beyond the reported,
> > but can't afford to do that right now.
> 
> Can you check where the issues appear?  I'd like to do a pure revert
> of the shared interrupts, but that three has a lot more in it..

What I did is a revert the refactorings while keeping the affinity API -
we can safely postpone them until the next release without loss of
functionality. But that's on top of my testing tree so it has unrelated
stuff as well. I'm rather confident they aren't fixing the issues but
I'll prepare a bugfix-only tree now for testing.

-- 
MST


[PATCH] net: ethernet: wiznet: avoid format string exposure

2017-04-05 Thread Kees Cook
While unlikely, this makes sure any format strings in the device name
can't exposure information via the resulting workqueue name.

Signed-off-by: Kees Cook 
---
 drivers/net/ethernet/wiznet/w5100.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/wiznet/w5100.c 
b/drivers/net/ethernet/wiznet/w5100.c
index f90267f0519f..2bdfb39215e9 100644
--- a/drivers/net/ethernet/wiznet/w5100.c
+++ b/drivers/net/ethernet/wiznet/w5100.c
@@ -1152,7 +1152,8 @@ int w5100_probe(struct device *dev, const struct 
w5100_ops *ops,
if (err < 0)
goto err_register;
 
-   priv->xfer_wq = alloc_workqueue(netdev_name(ndev), WQ_MEM_RECLAIM, 0);
+   priv->xfer_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0,
+   netdev_name(ndev));
if (!priv->xfer_wq) {
err = -ENOMEM;
goto err_wq;
-- 
2.7.4


-- 
Kees Cook
Pixel Security


Re: [PATCH] clk: iproc: Remove redundant check

2017-04-05 Thread Stephen Boyd
On 04/05, Ray Jui wrote:
> Remove the redundant check of 'rate' in the if statement of the
> 'pll_set_rate' function
> 
> Reported-by: David Binderman 
> Signed-off-by: Ray Jui 
> Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support")
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH v6] vfio error recovery: kernel support

2017-04-05 Thread Michael S. Tsirkin
On Wed, Apr 05, 2017 at 01:38:22PM -0600, Alex Williamson wrote:
> The previous intention of trying to handle all sorts of AER faults
> clearly had more value, though even there the implementation and
> configuration requirements restricted the practicality.  For instance
> is AER support actually useful to a customer if it requires all ports
> of a multifunction device assigned to the VM?  This seems more like a
> feature targeting whole system partitioning rather than general VM
> device assignment use cases.  Maybe that's ok, but it should be a clear
> design decision.

Alex, what kind of testing do you expect to be necessary?
Would you say testing on real hardware and making it trigger
AER errors is a requirement?

-- 
MST


Re: [PATCH] phy: bcm-ns-usb3: split all writes into reg & val pairs

2017-04-05 Thread Kishon Vijay Abraham I
Hi,

On Sunday 02 April 2017 10:25 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> So far all the PHY initialization was implemented using some totally
> magic values. There was some pattern there but it wasn't clear what is
> it about.
> 
> Thanks to the patch submitted by Broadcom:
> [PATCH 5/6] phy: Add USB3 PHY support for Broadcom NSP SoC
> and the upstream "iproc-mdio" driver we now know there is a MDIO bus
> underneath with PHY(s) and their registers.
> 
> It allows us to clean the driver a bit by making all these values less
> magical. The next step is switching to using a proper MDIO layer.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/phy/phy-bcm-ns-usb3.c | 69 
> ++-
>  1 file changed, 49 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/phy/phy-bcm-ns-usb3.c b/drivers/phy/phy-bcm-ns-usb3.c
> index f420fa4bebfc..22b5e7047fa6 100644
> --- a/drivers/phy/phy-bcm-ns-usb3.c
> +++ b/drivers/phy/phy-bcm-ns-usb3.c
> @@ -2,6 +2,7 @@
>   * Broadcom Northstar USB 3.0 PHY Driver
>   *
>   * Copyright (C) 2016 Rafał Miłecki 
> + * Copyright (C) 2016 Broadcom
>   *
>   * All magic values used for initialization (and related comments) were 
> obtained
>   * from Broadcom's SDK:
> @@ -23,6 +24,23 @@
>  
>  #define BCM_NS_USB3_MII_MNG_TIMEOUT_US   1000/* usecs */
>  
> +#define BCM_NS_USB3_PHY_BASE_ADDR_REG0x1f
> +#define BCM_NS_USB3_PHY_PLL30_BLOCK  0x8000
> +#define BCM_NS_USB3_PHY_TX_PMD_BLOCK 0x8040
> +#define BCM_NS_USB3_PHY_PIPE_BLOCK   0x8060
> +
> +/* Registers of PLL30 block */
> +#define BCM_NS_USB3_PLL_CONTROL  0x01
> +#define BCM_NS_USB3_PLLA_CONTROL00x0a
> +#define BCM_NS_USB3_PLLA_CONTROL10x0b
> +
> +/* Registers of TX PMD block */
> +#define BCM_NS_USB3_TX_PMD_CONTROL1  0x01
> +
> +/* Registers of PIPE block */
> +#define BCM_NS_USB3_LFPS_CMP 0x02
> +#define BCM_NS_USB3_LFPS_DEGLITCH0x03
> +
>  enum bcm_ns_family {
>   BCM_NS_UNKNOWN,
>   BCM_NS_AX,
> @@ -76,8 +94,10 @@ static inline int bcm_ns_usb3_mii_mng_wait_idle(struct 
> bcm_ns_usb3 *usb3)
>   
> usecs_to_jiffies(BCM_NS_USB3_MII_MNG_TIMEOUT_US));
>  }
>  
> -static int bcm_ns_usb3_mii_mng_write32(struct bcm_ns_usb3 *usb3, u32 value)
> +static int bcm_ns_usb3_mdio_phy_write(struct bcm_ns_usb3 *usb3, u16 reg,
> +   u16 value)
>  {
> + u32 tmp = 0;
>   int err;
>  
>   err = bcm_ns_usb3_mii_mng_wait_idle(usb3);
> @@ -86,7 +106,11 @@ static int bcm_ns_usb3_mii_mng_write32(struct bcm_ns_usb3 
> *usb3, u32 value)
>   return err;
>   }
>  
> - writel(value, usb3->ccb_mii + BCMA_CCB_MII_MNG_CMD_DATA);
> + /* TODO: Use a proper MDIO bus layer */

Instead of using this intermediate patch, can we directly convert this to
mdio_driver or you see issues with converting it?

Thanks
Kishon


[PATCH 08/16] irqchip: Add driver for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
The Cirrus Logic Madera codecs (Cirrus Logic CS47L35/85/90/91 and WM1840)
are highly complex devices containing up to 7 programmable DSPs and many
other internal sources of interrupts plus a number of GPIOs that can be
used as interrupt inputs. The large number (>150) of internal interrupt
sources are managed by an on-board interrupt controller.

This driver provides the handling for the interrupt controller. As the
codec is accessed via regmap, we can make use of the generic IRQ
functionality from regmap to do most of the work. Only around half of
the possible interrupt source are currently of interest from the driver
so only this subset is defined. Others can be added in future if needed.

The KConfig options are not user-configurable because this driver is
mandatory so is automatically included when the parent MFD driver is
selected.

Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 .../interrupt-controller/cirrus,madera.txt |  31 ++
 MAINTAINERS|   3 +
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-madera.c   | 349 +
 include/linux/irqchip/irq-madera-pdata.h   |  19 ++
 include/linux/irqchip/irq-madera.h |  96 ++
 7 files changed, 504 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
 create mode 100644 drivers/irqchip/irq-madera.c
 create mode 100644 include/linux/irqchip/irq-madera-pdata.h
 create mode 100644 include/linux/irqchip/irq-madera.h

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt 
b/Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
new file mode 100644
index 000..4505315
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
@@ -0,0 +1,31 @@
+Cirrus Logic Madera class audio codec IRQ driver
+
+The IRQ properties are members of the parent MFD node.
+
+See also the core bindings for the parent MFD driver:
+See Documentation/devicetree/bindings/mfd/madera.txt
+
+Required properties:
+  - interrupt-controller : Madera class devices contain interrupt controllers
+and may provide interrupt services to other devices.
+
+  - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+The first cell is the IRQ number.
+The second cell is the flags, encoded as the trigger masks from
+bindings/interrupt-controller/interrupts.txt
+
+  - interrupts : The interrupt line the /IRQ signal for the device is
+connected to.
+
+  - interrupt-parent : The parent interrupt controller.
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = <_irq1>;
+   interrupt-parent = <>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1207c9c..a06701f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3266,10 +3266,13 @@ L:  patc...@opensource.wolfsonmicro.com
 T: git https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
+F: Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
 F: Documentation/devicetree/bindings/mfd/madera.txt
 F: Documentation/devicetree/bindings/regulator/madera*
+F: include/linux/irqchip/irq-madera*
 F: include/linux/mfd/madera/*
 F: include/linux/regulator/madera*
+F: drivers/irqchip/irq-madera*
 F: drivers/mfd/madera*
 F: drivers/mfd/cs47l*
 F: drivers/regulator/madera*
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 8162121..9c5eae7 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -125,6 +125,11 @@ config IMGPDC_IRQ
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config MADERA_IRQ
+   bool
+   select REGMAP_IRQ
+   default y if MFD_MADERA=y
+
 config IRQ_MIPS_CPU
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 152bc40..bcc2a8f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_S3C24XX)+= irq-s3c24xx.o
 obj-$(CONFIG_DW_APB_ICTL)  += irq-dw-apb-ictl.o
 obj-$(CONFIG_METAG)+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)   += irq-metag.o
+obj-$(CONFIG_MADERA_IRQ)   += irq-madera.o
 obj-$(CONFIG_ARCH_MOXART)  += irq-moxart.o
 obj-$(CONFIG_CLPS711X_IRQCHIP) += irq-clps711x.o
 obj-$(CONFIG_OR1K_PIC) += irq-or1k-pic.o
diff --git a/drivers/irqchip/irq-madera.c b/drivers/irqchip/irq-madera.c
new file mode 100644
index 000..461cbb9
--- /dev/null
+++ b/drivers/irqchip/irq-madera.c
@@ -0,0 

Re: [PATCH v4 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs

2017-04-05 Thread Heiko Stübner
Hi Elaine,

Am Mittwoch, 5. April 2017, 10:07:41 CEST schrieb Elaine Zhang:
> On 04/05/2017 12:04 AM, Heiko Stuebner wrote:
> > Am Montag, 27. März 2017, 17:40:48 CEST schrieb c...@rock-chips.com:
> >> From: Liang Chen 
> >> 
> >> This patch adds core dtsi file for Rockchip RK3328 SoCs.
> >> 
> >> Signed-off-by: Liang Chen 
> > 
> > applied for 4.12, with the following list of changes:
> > 
> > - reorder some properties to bring them in alphabetical order
> > - dropped the status-disabled from the power-controller
> > 
> >power-domain control is a quite essential part of the system, so if
> >boards really want to disable them, they should do it in their board
> >file
> >Having power-domains on all the time, is also our default in all other
> >devicetrees.
> > 
> > - removed #dma-cells from spi0 -> this is not a dma controller
> > - reword the cru assigned-clocks comment a bit
> > - fixed sdmmc1_bus4 pins, as indicated by Shawn and after looking up the
> > 
> >correct pins in the manual
> > 
> > And a final question, are you sure about SCLK_PDM becoming a child of the
> > APLL in your cru assigned-clocks, as the APLL will vary later on with
> > cpufreq active?
> 
> the NPLL will vary later on with cpufreq active.
> 
> The NPLL is better than APLL, so NPLL is for clk_core,and apll is for pdm.
> 
> please see the TRM in CRU:
> 1.4 Function Description
> /./
> To maximize the flexibility, some of clocks can select divider source
> from 5 PLLs. (Note: It’s
> recommended to use NEW PLL instead of ARM PLL as arm clock source,
> because NEW PLL is
> near to ARM. And it’s jitter is better than ARM PLL).

Thanks for the clarification - this way it definitly makes sense.


Thanks
Heiko


[PATCH 00/16] Add support for Cirrus Logic CS47L35/L85/L90/L91 codecs

2017-04-05 Thread Richard Fitzgerald
The Cirrus Logic CS47L35, CS47L85, CS47L90/91 codecs are complex audio SoC
devices. In addition to the core audio capability they have onboard GPIO,
regulators, DSPs and interrupt controller and a large register map space
accessed over SPI or I2C. This family of codecs is based around common IP
blocks and they are managed by a set of common drivers referred to as "Madera".

Mayuresh Kulkarni (1):
  ASoC: wm_adsp: add support for DSP region lock

Richard Fitzgerald (15):
  mfd: madera: Add register definitions for Cirrus Logic Madera codecs
  mfd: madera: Add common support for Cirrus Logic Madera codecs
  mfd: madera: Register map tables for Cirrus Logic CS47L35
  mfd: madera: Register map tables for Cirrus Logic CS47L85
  mfd: madera: Register map tables for Cirrus Logic CS47L90/91
  regulator: madera-ldo1: LDO1 driver for Cirrus Logic Madera codecs
  regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
  irqchip: Add driver for Cirrus Logic Madera codecs
  pinctrl: madera: Add driver for Cirrus Logic Madera codecs
  gpio: madera: Support Cirrus Logic Madera class codecs
  ASoC: wm_adsp: Add support for ADSP2V2
  ASoC: madera: Add common support for Cirrus Logic Madera codecs
  ASoC: cs47l35: Add codec driver for Cirrus Logic CS47L35
  ASoC: cs47l85: Add codec driver for Cirrus Logic CS47L85
  ASoC: cs47l90: Add codec driver for Cirrus Logic CS47L90

 .../devicetree/bindings/gpio/gpio-madera.txt   |   24 +
 .../interrupt-controller/cirrus,madera.txt |   31 +
 Documentation/devicetree/bindings/mfd/madera.txt   |   79 +
 .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 +
 .../devicetree/bindings/regulator/madera-ldo1.txt  |   29 +
 .../bindings/regulator/madera-micsupp.txt  |   27 +
 Documentation/devicetree/bindings/sound/madera.txt |   63 +
 MAINTAINERS|   28 +
 drivers/gpio/Kconfig   |6 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-madera.c |  173 +
 drivers/irqchip/Kconfig|5 +
 drivers/irqchip/Makefile   |1 +
 drivers/irqchip/irq-madera.c   |  349 +
 drivers/mfd/Kconfig|   41 +
 drivers/mfd/Makefile   |   13 +
 drivers/mfd/cs47l35-tables.c   | 1688 
 drivers/mfd/cs47l85-tables.c   | 3169 +++
 drivers/mfd/cs47l90-tables.c   | 2830 +++
 drivers/mfd/madera-core.c  |  689 ++
 drivers/mfd/madera-i2c.c   |  130 +
 drivers/mfd/madera-spi.c   |  131 +
 drivers/mfd/madera.h   |   52 +
 drivers/pinctrl/Kconfig|   22 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-madera.c   | 1092 +++
 drivers/regulator/Kconfig  |   16 +
 drivers/regulator/Makefile |2 +
 drivers/regulator/madera-ldo1.c|  198 +
 drivers/regulator/madera-micsupp.c |  260 +
 include/dt-bindings/sound/madera.h |   18 +
 include/linux/irqchip/irq-madera-pdata.h   |   19 +
 include/linux/irqchip/irq-madera.h |   96 +
 include/linux/mfd/madera/core.h|  175 +
 include/linux/mfd/madera/pdata.h   |   88 +
 include/linux/mfd/madera/registers.h   | 8832 
 include/linux/regulator/madera-ldo1.h  |   24 +
 include/linux/regulator/madera-micsupp.h   |   21 +
 include/sound/madera-pdata.h   |   70 +
 sound/soc/codecs/Kconfig   |   23 +
 sound/soc/codecs/Makefile  |8 +
 sound/soc/codecs/cs47l35.c | 1747 
 sound/soc/codecs/cs47l85.c | 2706 ++
 sound/soc/codecs/cs47l90.c | 2645 ++
 sound/soc/codecs/madera.c  | 4430 ++
 sound/soc/codecs/madera.h  |  470 ++
 sound/soc/codecs/wm_adsp.c |  324 +-
 sound/soc/codecs/wm_adsp.h |   24 +
 48 files changed, 32930 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-madera.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/madera-ldo1.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/madera-micsupp.txt
 create mode 100644 Documentation/devicetree/bindings/sound/madera.txt
 

[PATCH 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
The adds a driver for the microphone supply regulator on Cirrus Logic
Madera class codecs.

Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 .../bindings/regulator/madera-micsupp.txt  |  27 +++
 drivers/regulator/Kconfig  |   8 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/madera-micsupp.c | 260 +
 include/linux/regulator/madera-micsupp.h   |  21 ++
 5 files changed, 317 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/madera-micsupp.txt
 create mode 100644 drivers/regulator/madera-micsupp.c
 create mode 100644 include/linux/regulator/madera-micsupp.h

diff --git a/Documentation/devicetree/bindings/regulator/madera-micsupp.txt 
b/Documentation/devicetree/bindings/regulator/madera-micsupp.txt
new file mode 100644
index 000..08aec7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/madera-micsupp.txt
@@ -0,0 +1,27 @@
+Cirrus Logic Madera class audio codecs mic supply regulator driver
+
+Only required if the codec has an internal mic supply regulator.
+This is a subnode of the parent mfd node.
+
+See also the core bindings for the parent MFD driver:
+See Documentation/devicetree/bindings/mfd/madera.txt
+
+Required properties:
+  - compatible :  must be "cirrus,madera-micsupp"
+
+Optional subnodes:
+  Standard regulator bindings as described in bindings/regulator/regulator.txt
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   micvdd {
+   compatible = "cirrus,madera-micsupp";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <330>;
+   regulator-allow-bypass = <1>;
+   };
+};
+
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c96d9a6..4f4b531 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -376,6 +376,14 @@ config REGULATOR_MADERA_LDO1
  to supply DCVDD you must include this driver. If you are using an
  external DCVDD regulator you do not need this driver.
 
+config REGULATOR_MADERA_MICSUPP
+   tristate "Cirrus Logic Madera codecs mic supply regulator"
+   depends on MFD_MADERA
+   depends on SND_SOC
+   help
+ Support for the microphone supply regulator on Cirrus Logic
+ Madera class codecs
+
 config REGULATOR_MAX14577
tristate "Maxim 14577/77836 regulator"
depends on MFD_MAX14577
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 2db3592..28cdf6e 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
 obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
 obj-$(CONFIG_REGULATOR_LTC3676) += ltc3676.o
 obj-$(CONFIG_REGULATOR_MADERA_LDO1) += madera-ldo1.o
+obj-$(CONFIG_REGULATOR_MADERA_MICSUPP) += madera-micsupp.o
 obj-$(CONFIG_REGULATOR_MAX14577) += max14577-regulator.o
 obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
 obj-$(CONFIG_REGULATOR_MAX77620) += max77620-regulator.o
diff --git a/drivers/regulator/madera-micsupp.c 
b/drivers/regulator/madera-micsupp.c
new file mode 100644
index 000..ac8bcbd
--- /dev/null
+++ b/drivers/regulator/madera-micsupp.c
@@ -0,0 +1,260 @@
+/*
+ * madera-micsupp.c  --  Driver for the mic supply regulator on Madera codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct madera_micsupp {
+   struct regulator_dev *regulator;
+   struct madera *madera;
+
+   struct regulator_consumer_supply supply;
+   struct regulator_init_data init_data;
+
+   struct work_struct check_cp_work;
+};
+
+static void madera_micsupp_check_cp(struct work_struct *work)
+{
+   struct madera_micsupp *micsupp =
+   container_of(work, struct madera_micsupp, check_cp_work);
+   struct snd_soc_dapm_context *dapm = micsupp->madera->dapm;
+   struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
+   struct madera *madera = micsupp->madera;
+   struct regmap *regmap = madera->regmap;
+   unsigned int reg;
+   int ret;
+
+   if (dapm) {
+   ret = regmap_read(regmap, MADERA_MIC_CHARGE_PUMP_1, );
+   if (ret) {
+   dev_err(madera->dev,
+   "Failed to read CP state: %d\n", ret);
+   return;
+   }
+
+   reg &= MADERA_CPMIC_ENA | MADERA_CPMIC_BYPASS;
+   if (reg == MADERA_CPMIC_ENA)
+   

[PATCH 10/16] gpio: madera: Support Cirrus Logic Madera class codecs

2017-04-05 Thread Richard Fitzgerald
This adds support for the GPIOs on Cirrus Logic Madera class codecs.

Signed-off-by: Nariman Poushin 
Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 .../devicetree/bindings/gpio/gpio-madera.txt   |  24 +++
 MAINTAINERS|   2 +
 drivers/gpio/Kconfig   |   6 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-madera.c | 173 +
 5 files changed, 206 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-madera.txt
 create mode 100644 drivers/gpio/gpio-madera.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-madera.txt 
b/Documentation/devicetree/bindings/gpio/gpio-madera.txt
new file mode 100644
index 000..eb01c6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-madera.txt
@@ -0,0 +1,24 @@
+Cirrus Logic Madera class audio codecs gpio driver
+
+This is a subnode of the parent mfd node.
+
+See also the core bindings for the parent MFD driver:
+See Documentation/devicetree/bindings/mfd/madera.txt
+
+Required properties:
+  - compatible : must be "cirrus,madera-gpio"
+  - gpio-controller : Indicates this device is a GPIO controller.
+  - #gpio-cells : Must be 2. The first cell is the pin number. The second cell
+is reserved for future use and must be zero
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   gpio {
+   compatible = "cirrus,madera-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   }
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 85af1f9..0183692 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3266,6 +3266,7 @@ L:patc...@opensource.wolfsonmicro.com
 T: git https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
+F: Documentation/devicetree/bindings/gpio/gpio-madera.txt
 F: Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
 F: Documentation/devicetree/bindings/mfd/madera.txt
 F: Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
@@ -3273,6 +3274,7 @@ F:
Documentation/devicetree/bindings/regulator/madera*
 F: include/linux/irqchip/irq-madera*
 F: include/linux/mfd/madera/*
 F: include/linux/regulator/madera*
+F: drivers/gpio/gpio-madera*
 F: drivers/irqchip/irq-madera*
 F: drivers/mfd/madera*
 F: drivers/mfd/cs47l*
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 63ceed2..1386728 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -844,6 +844,12 @@ config GPIO_ARIZONA
help
  Support for GPIOs on Wolfson Arizona class devices.
 
+config GPIO_MADERA
+   tristate "Cirrus Logic Madera class codecs"
+   depends on MFD_MADERA
+   help
+ Support for GPIOs on Cirrus Logic Madera class codecs.
+
 config GPIO_CRYSTAL_COVE
tristate "GPIO support for Crystal Cove PMIC"
depends on (X86 || COMPILE_TEST) && INTEL_SOC_PMIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 095598e..d4b6c30 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_GPIO_LPC18XX)+= gpio-lpc18xx.o
 obj-$(CONFIG_ARCH_LPC32XX) += gpio-lpc32xx.o
 obj-$(CONFIG_GPIO_LP873X)  += gpio-lp873x.o
 obj-$(CONFIG_GPIO_LYNXPOINT)   += gpio-lynxpoint.o
+obj-$(CONFIG_GPIO_MADERA)  += gpio-madera.o
 obj-$(CONFIG_GPIO_MAX730X) += gpio-max730x.o
 obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o
 obj-$(CONFIG_GPIO_MAX7301) += gpio-max7301.o
diff --git a/drivers/gpio/gpio-madera.c b/drivers/gpio/gpio-madera.c
new file mode 100644
index 000..b4fa082
--- /dev/null
+++ b/drivers/gpio/gpio-madera.c
@@ -0,0 +1,173 @@
+/*
+ * gpio-madera.c - GPIO support for Cirrus Logic Madera codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct madera_gpio {
+   struct madera *madera;
+   struct gpio_chip gpio_chip;
+};
+
+static int madera_gpio_direction_in(struct gpio_chip *chip, unsigned int 
offset)
+{
+   struct madera_gpio *madera_gpio = gpiochip_get_data(chip);
+   struct madera *madera = madera_gpio->madera;
+
+   return regmap_update_bits(madera->regmap,
+ MADERA_GPIO1_CTRL_2 + (2 * offset),
+ MADERA_GP1_DIR_MASK, MADERA_GP1_DIR);
+}
+
+static int madera_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+   struct madera_gpio *madera_gpio = gpiochip_get_data(chip);

[PATCH 11/16] ASoC: wm_adsp: Add support for ADSP2V2

2017-04-05 Thread Richard Fitzgerald
Adds support for ADSP2V2 cores. Primary differences are that
they use a 32-bit register map compared to the 16-bit register
map of ADSP2V1, and there are some changes to clocking control.

Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 sound/soc/codecs/wm_adsp.c | 187 ++---
 sound/soc/codecs/wm_adsp.h |   1 +
 2 files changed, 145 insertions(+), 43 deletions(-)

diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index bbdb72f..a9acf22 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -112,17 +112,22 @@
 #define ADSP1_CLK_SEL_SHIFT0  /* CLK_SEL_ENA */
 #define ADSP1_CLK_SEL_WIDTH3  /* CLK_SEL_ENA */
 
-#define ADSP2_CONTROL0x0
-#define ADSP2_CLOCKING   0x1
-#define ADSP2_STATUS10x4
-#define ADSP2_WDMA_CONFIG_1 0x30
-#define ADSP2_WDMA_CONFIG_2 0x31
-#define ADSP2_RDMA_CONFIG_1 0x34
-
-#define ADSP2_SCRATCH00x40
-#define ADSP2_SCRATCH10x41
-#define ADSP2_SCRATCH20x42
-#define ADSP2_SCRATCH30x43
+#define ADSP2_CONTROL 0x0
+#define ADSP2_CLOCKING0x1
+#define ADSP2V2_CLOCKING  0x2
+#define ADSP2_STATUS1 0x4
+#define ADSP2_WDMA_CONFIG_1   0x30
+#define ADSP2_WDMA_CONFIG_2   0x31
+#define ADSP2V2_WDMA_CONFIG_2 0x32
+#define ADSP2_RDMA_CONFIG_1   0x34
+
+#define ADSP2_SCRATCH00x40
+#define ADSP2_SCRATCH10x41
+#define ADSP2_SCRATCH20x42
+#define ADSP2_SCRATCH30x43
+
+#define ADSP2V2_SCRATCH0_10x40
+#define ADSP2V2_SCRATCH2_30x42
 
 /*
  * ADSP2 Control
@@ -153,6 +158,17 @@
 #define ADSP2_CLK_SEL_WIDTH3  /* CLK_SEL_ENA */
 
 /*
+ * ADSP2V2 clocking
+ */
+#define ADSP2V2_CLK_SEL_MASK 0x7  /* CLK_SEL_ENA */
+#define ADSP2V2_CLK_SEL_SHIFT 16  /* CLK_SEL_ENA */
+#define ADSP2V2_CLK_SEL_WIDTH  3  /* CLK_SEL_ENA */
+
+#define ADSP2V2_RATE_MASK 0x7800  /* DSP_RATE */
+#define ADSP2V2_RATE_SHIFT11  /* DSP_RATE */
+#define ADSP2V2_RATE_WIDTH 4  /* DSP_RATE */
+
+/*
  * ADSP2 Status 1
  */
 #define ADSP2_RAM_RDY 0x0001
@@ -683,6 +699,9 @@ static int wm_adsp_fw_put(struct snd_kcontrol *kcontrol,
SOC_ENUM_SINGLE(0, 1, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
SOC_ENUM_SINGLE(0, 2, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
SOC_ENUM_SINGLE(0, 3, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
+   SOC_ENUM_SINGLE(0, 4, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
+   SOC_ENUM_SINGLE(0, 5, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
+   SOC_ENUM_SINGLE(0, 6, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text),
 };
 
 const struct snd_kcontrol_new wm_adsp_fw_controls[] = {
@@ -694,6 +713,12 @@ static int wm_adsp_fw_put(struct snd_kcontrol *kcontrol,
 wm_adsp_fw_get, wm_adsp_fw_put),
SOC_ENUM_EXT("DSP4 Firmware", wm_adsp_fw_enum[3],
 wm_adsp_fw_get, wm_adsp_fw_put),
+   SOC_ENUM_EXT("DSP5 Firmware", wm_adsp_fw_enum[4],
+wm_adsp_fw_get, wm_adsp_fw_put),
+   SOC_ENUM_EXT("DSP6 Firmware", wm_adsp_fw_enum[5],
+wm_adsp_fw_get, wm_adsp_fw_put),
+   SOC_ENUM_EXT("DSP7 Firmware", wm_adsp_fw_enum[6],
+wm_adsp_fw_get, wm_adsp_fw_put),
 };
 EXPORT_SYMBOL_GPL(wm_adsp_fw_controls);
 
@@ -750,6 +775,29 @@ static void wm_adsp2_show_fw_status(struct wm_adsp *dsp)
 be16_to_cpu(scratch[3]));
 }
 
+static void wm_adsp2v2_show_fw_status(struct wm_adsp *dsp)
+{
+   u32 scratch[2];
+   int ret;
+
+   ret = regmap_raw_read(dsp->regmap, dsp->base + ADSP2V2_SCRATCH0_1,
+ scratch, sizeof(scratch));
+
+   if (ret) {
+   adsp_err(dsp, "Failed to read SCRATCH regs: %d\n", ret);
+   return;
+   }
+
+   scratch[0] = be32_to_cpu(scratch[0]);
+   scratch[1] = be32_to_cpu(scratch[1]);
+
+   adsp_dbg(dsp, "FW SCRATCH 0:0x%x 1:0x%x 2:0x%x 3:0x%x\n",
+scratch[0] & 0x,
+scratch[0] >> 16,
+scratch[1] & 0x,
+scratch[1] >> 16);
+}
+
 static inline struct wm_coeff_ctl *bytes_ext_to_ctl(struct soc_bytes_ext *ext)
 {
return container_of(ext, struct wm_coeff_ctl, bytes_ext);
@@ -2435,10 +2483,17 @@ static int wm_adsp2_ena(struct wm_adsp *dsp)
unsigned int val;
int ret, count;
 
-   ret = regmap_update_bits_async(dsp->regmap, dsp->base + ADSP2_CONTROL,
-  ADSP2_SYS_ENA, ADSP2_SYS_ENA);
-   if (ret != 0)
-   return ret;
+   

[PATCH 02/16] mfd: madera: Add common support for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
This adds the generic core support for Cirrus Logic "Madera" class codecs.
These are complex audio codec SoCs with a variety of digital and analogue
I/O, onboard audio processing and DSPs, and other features.

These codecs are all based off a common set of hardware IP so can be
supported by a core of common code (with a few minor device-to-device
variations).

Signed-off-by: Charles Keepax 
Signed-off-by: Nikesh Oswal 
Signed-off-by: Richard Fitzgerald 
---
 Documentation/devicetree/bindings/mfd/madera.txt |  79 +++
 MAINTAINERS  |   3 +
 drivers/mfd/Kconfig  |  23 +
 drivers/mfd/Makefile |   4 +
 drivers/mfd/madera-core.c| 689 +++
 drivers/mfd/madera-i2c.c | 130 +
 drivers/mfd/madera-spi.c | 131 +
 drivers/mfd/madera.h |  52 ++
 include/linux/mfd/madera/core.h  | 175 ++
 include/linux/mfd/madera/pdata.h |  88 +++
 10 files changed, 1374 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
 create mode 100644 drivers/mfd/madera-core.c
 create mode 100644 drivers/mfd/madera-i2c.c
 create mode 100644 drivers/mfd/madera-spi.c
 create mode 100644 drivers/mfd/madera.h
 create mode 100644 include/linux/mfd/madera/core.h
 create mode 100644 include/linux/mfd/madera/pdata.h

diff --git a/Documentation/devicetree/bindings/mfd/madera.txt 
b/Documentation/devicetree/bindings/mfd/madera.txt
new file mode 100644
index 000..a6c3260
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/madera.txt
@@ -0,0 +1,79 @@
+Cirrus Logic Madera class audio codecs multi-function device
+
+These devices are audio SoCs with extensive digital capabilities and a range
+of analogue I/O.
+
+See also the child driver bindings in:
+bindings/extcon/extcon-madera.txt
+bindings/gpio/gpio-madera.txt
+bindings/interrupt-controller/cirrus,madera.txt
+bindings/pinctrl/cirrus,madera-pinctrl.txt
+bindings/regulator/madera-ldo1.txt
+bindings/regulator/madera-micsupp.txt
+bindings/sound/madera.txt
+
+Required properties:
+
+  - compatible : One of the following chip-specific strings:
+"cirrus,cs47l35"
+"cirrus,cs47l85"
+"cirrus,cs47l90"
+"cirrus,cs47l91"
+"cirrus,wm1840"
+
+  - reg : I2C slave address when connected using I2C, chip select number when
+using SPI.
+
+  - DCVDD-supply : Power supply for the device as defined in
+bindings/regulator/regulator.txt
+Mandatory on CS47L35, CS47L90, CS47L91
+Optional on CS47L85, WM1840
+
+  - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply :
+Power supplies for the device
+
+  - DBVDD3-supply, DBVDD4-supply : Power supplies for the device
+(CS47L85, CS47L90, CS47L91, WM1840)
+
+  - SPKVDDL-supply, SPKVDDR-supply : Power supplies for the device
+(CS47L85, WM1840)
+
+  - SPKVDD-supply : Power supply for the device
+(CS47L35)
+
+Optional properties:
+
+  - MICVDD-supply : Power supply, only need to be specified if
+powered externally
+
+  - reset-gpios : One entry specifying the GPIO controlling /RESET.
+As defined in bindings/gpio.txt.
+Although optional, it is strongly recommended to use a hardware reset
+
+  - MICBIASx : Initial data for the MICBIAS regulators, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt.
+One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...)
+(all codecs)
+
+One for each output pin (MICBIAS1A, MIBCIAS1B, MICBIAS2A, ...)
+(all except CS47L85, WM1840)
+
+The following following additional property is supported for the generator
+nodes:
+  - cirrus,ext-cap : Set to 1 if the MICBIAS has external decoupling
+capacitors attached.
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+   reg = <0>;
+
+   reset-gpios = < 0>;
+
+   MICBIAS1 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <330>;
+   cirrus,ext-cap = <1>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 02995c9..d28e53f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3266,7 +3266,10 @@ L:   patc...@opensource.wolfsonmicro.com
 T: git https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
+F: Documentation/devicetree/bindings/mfd/madera.txt
 F: include/linux/mfd/madera/*
+F: drivers/mfd/madera*
+F: drivers/mfd/cs47l*
 
 CLEANCACHE API
 M: Konrad Rzeszutek Wilk 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ce3a918..f0f9979 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -203,6 +203,29 @@ config MFD_CROS_EC_SPI
  

[PATCH 06/16] regulator: madera-ldo1: LDO1 driver for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
This patch adds a driver for the internal LDO1 regulator on
some Cirrus Logic Madera class codecs.

Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 .../devicetree/bindings/regulator/madera-ldo1.txt  |  29 +++
 MAINTAINERS|   3 +
 drivers/regulator/Kconfig  |   8 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/madera-ldo1.c| 198 +
 include/linux/regulator/madera-ldo1.h  |  24 +++
 6 files changed, 263 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/madera-ldo1.txt
 create mode 100644 drivers/regulator/madera-ldo1.c
 create mode 100644 include/linux/regulator/madera-ldo1.h

diff --git a/Documentation/devicetree/bindings/regulator/madera-ldo1.txt 
b/Documentation/devicetree/bindings/regulator/madera-ldo1.txt
new file mode 100644
index 000..688f21d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/madera-ldo1.txt
@@ -0,0 +1,29 @@
+Cirrus Logic Madera class audio codecs LDO1 regulator driver
+
+Only required if you are using the codec internal LDO1 regulator.
+This is a subnode of the parent mfd node.
+
+See also the core bindings for the parent MFD driver:
+See Documentation/devicetree/bindings/mfd/madera.txt
+
+Required properties:
+  - compatible :  must be "cirrus,madera-ldo1"
+  - LDOVDD-supply : Power supply for the LDO1 regulator.
+
+  - enable-gpio: GPIO to use to enable/disable the regulator.
+As defined in bindings/gpio.txt.
+
+Optional subnodes:
+  Standard regulator bindings as described in bindings/regulator/regulator.txt
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   ldo1 {
+   compatible = "cirrus,madera-ldo1";
+   LDOVDD-supply = <_vdd1>;
+   enable-gpio = < 0>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index d28e53f..1207c9c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3267,9 +3267,12 @@ T:   git 
https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
 F: Documentation/devicetree/bindings/mfd/madera.txt
+F: Documentation/devicetree/bindings/regulator/madera*
 F: include/linux/mfd/madera/*
+F: include/linux/regulator/madera*
 F: drivers/mfd/madera*
 F: drivers/mfd/cs47l*
+F: drivers/regulator/madera*
 
 CLEANCACHE API
 M: Konrad Rzeszutek Wilk 
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb2..c96d9a6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -368,6 +368,14 @@ config REGULATOR_LTC3676
  This enables support for the LTC3676
  8-output regulators controlled via I2C.
 
+config REGULATOR_MADERA_LDO1
+   tristate "Cirrus Logic Madera codecs LDO1 regulator"
+   depends on MFD_MADERA
+   help
+ If you want to use the internal LDO1 regulator on CS47L85 and WM1840
+ to supply DCVDD you must include this driver. If you are using an
+ external DCVDD regulator you do not need this driver.
+
 config REGULATOR_MAX14577
tristate "Maxim 14577/77836 regulator"
depends on MFD_MAX14577
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e..2db3592 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
 obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
 obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
 obj-$(CONFIG_REGULATOR_LTC3676) += ltc3676.o
+obj-$(CONFIG_REGULATOR_MADERA_LDO1) += madera-ldo1.o
 obj-$(CONFIG_REGULATOR_MAX14577) += max14577-regulator.o
 obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
 obj-$(CONFIG_REGULATOR_MAX77620) += max77620-regulator.o
diff --git a/drivers/regulator/madera-ldo1.c b/drivers/regulator/madera-ldo1.c
new file mode 100644
index 000..6504d6f
--- /dev/null
+++ b/drivers/regulator/madera-ldo1.c
@@ -0,0 +1,198 @@
+/*
+ * madera-ldo1.c  --  Driver for the LDO1 regulator on Madera codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct madera_ldo1 {
+   struct regulator_dev *regulator;
+
+   struct regulator_consumer_supply supply;
+   struct regulator_init_data init_data;
+};
+
+static const struct regulator_ops madera_ldo1_ops = {
+   .list_voltage = regulator_list_voltage_linear,
+   .map_voltage = regulator_map_voltage_linear,
+   .get_voltage_sel = 

[PATCH 12/16] ASoC: wm_adsp: add support for DSP region lock

2017-04-05 Thread Richard Fitzgerald
From: Mayuresh Kulkarni 

Newer ADSP2V2 codecs include a memory protection unit that can
be set to trap illegal accesses. When enabling an ADSPV2 core we
must configure the memory region traps so that the firmware can
access its own memory.

Signed-off-by: Mayuresh Kulkarni 
Signed-off-by: Nikesh Oswal 
Signed-off-by: Charles Keepax 
Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/wm_adsp.c | 137 +
 sound/soc/codecs/wm_adsp.h |  23 
 2 files changed, 160 insertions(+)

diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index a9acf22..20695b6 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -176,6 +176,37 @@
 #define ADSP2_RAM_RDY_SHIFT0
 #define ADSP2_RAM_RDY_WIDTH1
 
+/*
+ * ADSP2 Lock support
+ */
+#define ADSP2_LOCK_CODE_00x
+#define ADSP2_LOCK_CODE_10x
+
+#define ADSP2_WATCHDOG   0x0A
+#define ADSP2_BUS_ERR_ADDR   0x52
+#define ADSP2_REGION_LOCK_STATUS 0x64
+#define ADSP2_LOCK_REGION_1_LOCK_REGION_00x66
+#define ADSP2_LOCK_REGION_3_LOCK_REGION_20x68
+#define ADSP2_LOCK_REGION_5_LOCK_REGION_40x6A
+#define ADSP2_LOCK_REGION_7_LOCK_REGION_60x6C
+#define ADSP2_LOCK_REGION_9_LOCK_REGION_80x6E
+#define ADSP2_LOCK_REGION_CTRL   0x7A
+#define ADSP2_PMEM_ERR_ADDR_XMEM_ERR_ADDR0x7C
+
+#define ADSP2_REGION_LOCK_ERR_MASK   0x8000
+#define ADSP2_SLAVE_ERR_MASK 0x4000
+#define ADSP2_WDT_TIMEOUT_STS_MASK   0x2000
+#define ADSP2_CTRL_ERR_PAUSE_ENA 0x0002
+#define ADSP2_CTRL_ERR_EINT  0x0001
+
+#define ADSP2_BUS_ERR_ADDR_MASK  0x00FF
+#define ADSP2_XMEM_ERR_ADDR_MASK 0x
+#define ADSP2_PMEM_ERR_ADDR_MASK 0x7FFF
+#define ADSP2_PMEM_ERR_ADDR_SHIFT16
+#define ADSP2_WDT_ENA_MASK   0xFFFD
+
+#define ADSP2_LOCK_REGION_SHIFT  16
+
 #define ADSP_MAX_STD_CTRL_SIZE   512
 
 #define WM_ADSP_ACKED_CTL_TIMEOUT_MS 100
@@ -2638,6 +2669,18 @@ int wm_adsp2_preloader_put(struct snd_kcontrol *kcontrol,
 }
 EXPORT_SYMBOL_GPL(wm_adsp2_preloader_put);
 
+static void wm_adsp_stop_watchdog(struct wm_adsp *dsp)
+{
+   switch (dsp->rev) {
+   case 0:
+   case 1:
+   return;
+   default:
+   regmap_update_bits(dsp->regmap, dsp->base + ADSP2_WATCHDOG,
+  ADSP2_WDT_ENA_MASK, 0);
+   }
+}
+
 int wm_adsp2_early_event(struct snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event,
 unsigned int freq)
@@ -2710,6 +2753,8 @@ int wm_adsp2_event(struct snd_soc_dapm_widget *w,
if (ret != 0)
goto err;
 
+   wm_adsp2_lock(dsp, dsp->lock_regions);
+
ret = regmap_update_bits(dsp->regmap,
 dsp->base + ADSP2_CONTROL,
 ADSP2_CORE_ENA | ADSP2_START,
@@ -2733,6 +2778,8 @@ int wm_adsp2_event(struct snd_soc_dapm_widget *w,
/* Tell the firmware to cleanup */
wm_adsp_signal_event_controls(dsp, WM_ADSP_FW_EVENT_SHUTDOWN);
 
+   wm_adsp_stop_watchdog(dsp);
+
/* Log firmware state, it can be useful for analysis */
switch (dsp->rev) {
case 0:
@@ -3624,4 +3671,94 @@ int wm_adsp_compr_copy(struct snd_compr_stream *stream, 
char __user *buf,
 }
 EXPORT_SYMBOL_GPL(wm_adsp_compr_copy);
 
+int wm_adsp2_lock(struct wm_adsp *dsp, unsigned int lock_regions)
+{
+   struct regmap *regmap = dsp->regmap;
+   unsigned int code0, code1, lock_reg;
+
+   if (!(lock_regions & WM_ADSP2_REGION_ALL))
+   return 0;
+
+   lock_regions &= WM_ADSP2_REGION_ALL;
+   lock_reg = dsp->base + ADSP2_LOCK_REGION_1_LOCK_REGION_0;
+
+   while (lock_regions) {
+   code0 = code1 = 0;
+   if (lock_regions & BIT(0)) {
+   code0 = ADSP2_LOCK_CODE_0;
+   code1 = ADSP2_LOCK_CODE_1;
+   }
+   if (lock_regions & BIT(1)) {
+   code0 |= ADSP2_LOCK_CODE_0 << ADSP2_LOCK_REGION_SHIFT;
+   code1 |= ADSP2_LOCK_CODE_1 << ADSP2_LOCK_REGION_SHIFT;
+   }
+   regmap_write(regmap, lock_reg, code0);
+   regmap_write(regmap, lock_reg, code1);
+   lock_regions >>= 2;
+   lock_reg += 2;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(wm_adsp2_lock);
+
+irqreturn_t wm_adsp2_bus_error(struct wm_adsp *dsp)
+{
+   

[PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
These codecs have a variable number of I/O lines each of which
is individually selectable to a wide range of possible functions.

The functionality is slightly different from the traditional muxed
GPIO since most of the functions can be mapped to any pin (and even
the same function to multiple pins). Most pins have a dedicated
"alternate" function that is only available on that pin. The
alternate functions are usually a group of signals, though it is
not always necessary to enable the full group, depending on the
alternate function and how it is to be used. The mapping between
alternate functions and GPIO pins varies between codecs depending
on the number of alternate functions and available pins.

Signed-off-by: Richard Fitzgerald 
---
 .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++
 MAINTAINERS|2 +
 drivers/pinctrl/Kconfig|   22 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-madera.c   | 1092 
 5 files changed, 1220 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-madera.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
new file mode 100644
index 000..e9e20e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
@@ -0,0 +1,103 @@
+Cirrus Logic Madera class audio codecs pinctrl driver
+
+The Cirrus Logic Madera codecs provide a number of GPIO functions for
+interfacing to external hardware and to provide logic outputs to other devices.
+Certain groups of GPIO pins also have an alternate function, normally as an
+audio interface.
+
+The set of available GPIOs, functions and alternate function groups differs
+between codecs so refer to the datasheet for the codec for further information
+on what is supported on that device.
+
+The root node for this driver must be a subnode of the parent MFD driver node.
+It contains one subnode that is a container for an arbitrary number of subnodes
+to configure each pin or function group.
+
+See also
+  the core bindings for the parent MFD driver:
+Documentation/devicetree/bindings/mfd/madera.txt
+
+  the generic pinmix bindings:
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Required properties of parent mfd node:
+  - pinctrl-names : must be "defaults"
+  - pinctrl-0 : a phandle to the node containing the configuration subnodes
+
+Required properties of pinctrl subnode:
+  - compatible : must be "cirrus,madera-pinctrl"
+
+Required properties of configuration subnodes:
+  - groups : name of one pin group to configure. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic4, dmic5, dmic6,
+   gpio1, gpio2, ..., gpio40
+The gpioN groups select the single pin of this name for configuration
+
+Optional properties of configuration subnodes:
+  Any configuration option not explicitly listed in the dts will be left at
+  chip default setting.
+
+  - function : name of function to assign to this group. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic3, dmic4, dmic5, dmic6,
+   io, dsp-gpio, irq1, irq2,
+   fll1-clk, fll1-lock, fll2-clk, fll2-lock, fll3-clk, fll3-lock,
+   fllao-clk, fllao-lock,
+   opclk, opclk-async, pwm1, pwm2, spdif,
+   asrc1-in1-lock, asrc1-in2-lock, asrc2-in1-lock, asrc2-in2-lock,
+   spkl-short-circuit, spkr-short-circuit, spk-shutdown,
+   spk-overheat-shutdown, spk-overheat-warn,
+   timer1-sts, timer2-sts, timer3-sts, timer4-sts, timer5-sts, timer6-sts,
+   timer7-sts, timer8-sts,
+   log1-fifo-ne, log2-fifo-ne, log3-fifo-ne, log4-fifo-ne, log5-fifo-ne,
+   log6-fifo-ne, log7-fifo-ne, log8-fifo-ne,
+
+  - bias-disable : disable pull-up and pull-down
+  - bias-bus-hold : enable buskeeper
+  - bias-pull-up : output is pulled-up
+  - bias-pull-down : output is pulled-down
+  - drive-push-pull : CMOS output
+  - drive-open-drain : open-drain output
+  - drive-strength : drive strength in mA. Valid values are 4 or 8
+  - input-schmitt-enable : enable schmitt-trigger mode
+  - input-schmitt-disable : disable schmitt-trigger mode
+  - input-debounce : A value of 0 disables debounce, a value !=0 enables
+   debounce
+  - output-low : set the pin to output mode with low level
+  - output-high : set the pin to output mode with high level
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_defaults>;
+
+
+   pinctrl {
+   compatible = "cirrus,madera-pinctrl";
+
+   cs47l85_gpio_defaults: defaults {
+   aif1 {
+   

[PATCH 05/16] mfd: madera: Register map tables for Cirrus Logic CS47L90/91

2017-04-05 Thread Richard Fitzgerald
Regmap configuration tables for Cirrus Logic CS47L90 and CS47L91 codecs.

Signed-off-by: Nikesh Oswal 
Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 drivers/mfd/Kconfig  |6 +
 drivers/mfd/Makefile |3 +
 drivers/mfd/cs47l90-tables.c | 2830 ++
 3 files changed, 2839 insertions(+)
 create mode 100644 drivers/mfd/cs47l90-tables.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6618972..f7cb99c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -238,6 +238,12 @@ config MFD_CS47L85
help
  Support for Cirrus Logic CS47L85 Smart Codec
 
+config MFD_CS47L90
+   bool "Cirrus Logic CS47L90/91"
+   depends on MFD_MADERA
+   help
+ Support for Cirrus Logic CS47L90 and CS47L91 Smart Codecs
+
 config MFD_ASIC3
bool "Compaq ASIC3"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9fdca9a..542da6d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -79,6 +79,9 @@ endif
 ifeq ($(CONFIG_MFD_CS47L85),y)
 obj-$(CONFIG_MFD_MADERA)   += cs47l85-tables.o
 endif
+ifeq ($(CONFIG_MFD_CS47L90),y)
+obj-$(CONFIG_MFD_MADERA)   += cs47l90-tables.o
+endif
 obj-$(CONFIG_MFD_MADERA_I2C)   += madera-i2c.o
 obj-$(CONFIG_MFD_MADERA_SPI)   += madera-spi.o
 
diff --git a/drivers/mfd/cs47l90-tables.c b/drivers/mfd/cs47l90-tables.c
new file mode 100644
index 000..52ce50f
--- /dev/null
+++ b/drivers/mfd/cs47l90-tables.c
@@ -0,0 +1,2830 @@
+/*
+ * Regmap tables for CS47L90 codec
+ *
+ * Copyright 2015-2016 Cirrus Logic
+ *
+ * Author: Nikesh Oswal 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "madera.h"
+
+static const struct reg_sequence cs47l90_reva_16_patch[] = {
+   { 0x8A,   0x },
+   { 0x8A,   0x },
+   { 0x4CF,  0x0700 },
+   { 0x171,  0x0003 },
+   { 0x101,  0x0444 },
+   { 0x159,  0x0002 },
+   { 0x120,  0x0444 },
+   { 0x1D1,  0x0004 },
+   { 0x1E0,  0xC084 },
+   { 0x159,  0x },
+   { 0x120,  0x0404 },
+   { 0x101,  0x0404 },
+   { 0x171,  0x0002 },
+   { 0x17A,  0x2906 },
+   { 0x19A,  0x2906 },
+   { 0x441,  0xC750 },
+   { 0x340,  0x0001 },
+   { 0x112,  0x0405 },
+   { 0x124,  0x0C49 },
+   { 0x1300, 0x050E },
+   { 0x1302, 0x0101 },
+   { 0x1380, 0x0425 },
+   { 0x1381, 0xF6D8 },
+   { 0x1382, 0x0632 },
+   { 0x1383, 0xFEC8 },
+   { 0x1390, 0x042F },
+   { 0x1391, 0xF6CA },
+   { 0x1392, 0x0637 },
+   { 0x1393, 0xFEC8 },
+   { 0x281,  0x },
+   { 0x282,  0x },
+   { 0x4EA,  0x0100 },
+   { 0x8A,   0x },
+   { 0x8A,   0x },
+};
+
+int cs47l90_patch(struct madera *madera)
+{
+   int ret;
+
+   ret = regmap_register_patch(madera->regmap,
+   cs47l90_reva_16_patch,
+   ARRAY_SIZE(cs47l90_reva_16_patch));
+   if (ret < 0) {
+   dev_err(madera->dev,
+   "Error in applying 16-bit patch: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cs47l90_patch);
+
+static const struct reg_default cs47l90_reg_default[] = {
+   { 0x0020, 0x }, /* R32 (0x20) - Tone Generator 1 */
+   { 0x0021, 0x1000 }, /* R33 (0x21) - Tone Generator 2 */
+   { 0x0022, 0x }, /* R34 (0x22) - Tone Generator 3 */
+   { 0x0023, 0x1000 }, /* R35 (0x23) - Tone Generator 4 */
+   { 0x0024, 0x }, /* R36 (0x24) - Tone Generator 5 */
+   { 0x0030, 0x }, /* R48 (0x30) - PWM Drive 1 */
+   { 0x0031, 0x0100 }, /* R49 (0x31) - PWM Drive 2 */
+   { 0x0032, 0x0100 }, /* R50 (0x32) - PWM Drive 3 */
+   { 0x0061, 0x01ff }, /* R97 (0x61) - Sample Rate Sequence Select 1 */
+   { 0x0062, 0x01ff }, /* R98 (0x62) - Sample Rate Sequence Select 2 */
+   { 0x0063, 0x01ff }, /* R99 (0x63) - Sample Rate Sequence Select 3 */
+   { 0x0064, 0x01ff }, /* R100 (0x64) - Sample Rate Sequence Select 4 
*/
+   { 0x0066, 0x01ff }, /* R102 (0x66) - Always On Triggers Sequence 
Select 1 */
+   { 0x0067, 0x01ff }, /* R103 (0x67) - Always On Triggers Sequence 
Select 2 */
+   { 0x0090, 0x }, /* R144 (0x90) - Haptics Control 1 */
+   { 0x0091, 0x7fff }, /* R145 (0x91) - Haptics Control 2 */
+   { 0x0092, 0x }, /* R146 (0x92) - Haptics phase 1 intensity */
+   { 0x0093, 0x }, /* R147 (0x93) - Haptics phase 1 duration */
+   { 0x0094, 0x 

[PATCH 13/16] ASoC: madera: Add common support for Cirrus Logic Madera codecs

2017-04-05 Thread Richard Fitzgerald
The Cirrus Logic Madera codecs are a family of related codecs with
extensive digital and analogue I/O, digital mixing and routing,
signal processing and programmable DSPs.

This patch adds common support code shared by all Madera codecs.

Signed-off-by: Charles Keepax 
Signed-off-by: Nariman Poushin 
Signed-off-by: Nikesh Oswal 
Signed-off-by: Piotr Stankiewicz 
Signed-off-by: Ajit Pandey 
Signed-off-by: Richard Fitzgerald 
---
 Documentation/devicetree/bindings/sound/madera.txt |   63 +
 MAINTAINERS|5 +
 include/dt-bindings/sound/madera.h |   18 +
 include/sound/madera-pdata.h   |   70 +
 sound/soc/codecs/Kconfig   |5 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/madera.c  | 4430 
 sound/soc/codecs/madera.h  |  470 +++
 8 files changed, 5063 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/madera.txt
 create mode 100644 include/dt-bindings/sound/madera.h
 create mode 100644 include/sound/madera-pdata.h
 create mode 100644 sound/soc/codecs/madera.c
 create mode 100644 sound/soc/codecs/madera.h

diff --git a/Documentation/devicetree/bindings/sound/madera.txt 
b/Documentation/devicetree/bindings/sound/madera.txt
new file mode 100644
index 000..59e7a66
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/madera.txt
@@ -0,0 +1,63 @@
+Cirrus Logic Madera class audio codecs
+
+This is a subnode of the parent mfd node.
+
+See also the core bindings for the parent MFD driver:
+See Documentation/devicetree/bindings/mfd/madera.txt
+
+Required properties:
+  - compatible :  One of the following chip-specific strings:
+"cirrus,cs47l35-codec"
+"cirrus,cs47l85-codec"
+"cirrus,cs47l90-codec"
+
+Optional properties:
+  - cirrus,dmic-ref : DMIC bias reference for each input, one cell per input
+
+A value of 0 indicates MICVDD and is the default, other
+values depend on the codec - see the datasheet for the INn_DMIC_SUP field
+
+  - cirrus,inmode : A list of input mode settings for each input. A maximum
+of 16 cells, with four cells per input in the order INnAL, INnAR INnBL 
INnBR.
+For non-muxed inputs the first two cells for that input set the mode for
+the left and right channel and the second two cells must be 0.
+For muxed inputs the first two cells for that input set the mode of the
+left and right A inputs and the second two cells set the mode of the left
+and right B inputs.
+Valid mode values are one of the MADERA_INMODE_xxx (see
+include/dt-bindings/sound/madera.h). If the array is shorter than the 
number
+of inputs the unspecified inputs default to MADERA_INMODE_DIFF.
+
+  - cirrus,out-mono : Mono bit for each output, must contain six cells if
+specified. A non-zero value indicates the corresponding output is mono.
+
+  - cirrus,max-channels-clocked : The maximum number of channels to be clocked
+on each AIF, useful for I2S systems with multiple data lines being 
mastered.
+One cell for each AIF, use a value of zero for AIFs that should be handled
+normally.
+
+  - cirrus,pdm-fmt : PDM speaker data format, must contain 2 cells
+(OUT5 and OUT6). See the datasheet for values.
+The second cell is ignored for codecs that do not have OUT6.
+
+  - cirrus,pdm-mute : PDM speaker mute setting, must contain 2 cells
+(OUT5 and OUT6). See the datasheet for values.
+The second cell is ignored for codecs that do not have OUT6.
+
+Example:
+
+codec: cs47l35@0 {
+   compatible = "cirrus,cs47l35";
+
+   codec {
+   compatible = "cirrus,cs47l35-codec";
+   cirrus,dmic-ref = <0 0 1 0>;
+   cirrus,dmic-clksrc = <0 0 0 0>;
+   cirrus,inmode = <
+   2 2 1 1 /* IN1A digital, IN1B single-ended */
+   0 0 0 0 /* IN2 differential */
+   >;
+   cirrus,out-mono = <0 0 0 0 0 0>;
+   cirrus,max-channels-clocked = <2 0 0>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 0183692..b29f539 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3271,15 +3271,20 @@ F:  
Documentation/devicetree/bindings/interrupt-controller/cirrus,madera.txt
 F: Documentation/devicetree/bindings/mfd/madera.txt
 F: Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
 F: Documentation/devicetree/bindings/regulator/madera*
+F: Documentation/devicetree/bindings/sound/madera.txt
+F: include/dt-bindings/sound/madera*
 F: include/linux/irqchip/irq-madera*
 F: include/linux/mfd/madera/*
 F: include/linux/regulator/madera*
+F: 

Re: [PATCH v2 06/22] ARM: implement ioremap_nopost() interface

2017-04-05 Thread Lorenzo Pieralisi
On Fri, Mar 31, 2017 at 12:08:13PM +0100, Lorenzo Pieralisi wrote:
> Hi Russell,
> 
> On Mon, Mar 27, 2017 at 10:49:34AM +0100, Lorenzo Pieralisi wrote:
> > The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
> > and Posting") define rules for PCI configuration space transactions
> > ordering and posting, that state that configuration writes have to
> > be non-posted transactions.
> > 
> > Current ioremap interface on ARM provides mapping functions that
> > provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE
> > memory type) aka posted writes, so PCI host controller drivers have
> > no arch interface to remap PCI configuration space with memory
> > attributes that comply with the PCI specifications for configuration
> > space.
> > 
> > Implement an ARM specific ioremap_nopost() interface that allows to
> > map PCI config memory regions with MT_UNCACHED memory type (ie strongly
> > ordered - non-posted writes), providing a remap function that complies
> > with PCI specifications for config space transactions.
> > 
> > Signed-off-by: Lorenzo Pieralisi 
> > Cc: Arnd Bergmann 
> > Cc: Russell King 
> > ---
> >  arch/arm/include/asm/io.h | 10 ++
> >  arch/arm/mm/ioremap.c |  7 +++
> >  arch/arm/mm/nommu.c   |  9 +
> >  3 files changed, 26 insertions(+)
> 
> I have not added your ACK to this patch since I slightly tweaked
> it to adapt it to ioremap_nopost() interface instead of a PCI
> specific one. Furthermore, I mechanically added a ioremap_nopost()
> version for nommu too in the process, would be good to have a look
> if I did that properly please.
> 
> Can I add your ACK on this patch ? If you spot any issues please
> do let me know.

Hi Russell,

please let me know if your ACK on this patch stands as I have to respin
it shortly for hopefully final round of review.

Thanks !
Lorenzo

> Thank you !
> Lorenzo
> 
> > diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> > index 42871fb..49913d1 100644
> > --- a/arch/arm/include/asm/io.h
> > +++ b/arch/arm/include/asm/io.h
> > @@ -352,6 +352,7 @@ static inline void memcpy_toio(volatile void __iomem 
> > *to, const void *from,
> >   * mapping has specific properties.
> >   *
> >   * FunctionMemory type CacheabilityCache hint
> > + * ioremap_nopost()SO  n/a n/a
> >   * ioremap()   Device  n/a n/a
> >   * ioremap_nocache()   Device  n/a n/a
> >   * ioremap_cache() Normal  Writeback   Read allocate
> > @@ -372,6 +373,12 @@ static inline void memcpy_toio(volatile void __iomem 
> > *to, const void *from,
> >   * compiler may generate unaligned accesses - eg, via inlining its own
> >   * memcpy.
> >   *
> > + * ioremap_nopost() maps memory as strongly ordered, to be used for
> > + * specific mappings (eg PCI config space) that require non-posted
> > + * write transactions. Strongly ordered transactions are ordered wrt
> > + * device mappings, which means that ioremap_nopost() is the same
> > + * as ioremap() except for non-posted writes behaviour.
> > + *
> >   * All normal memory mappings have the following properties:
> >   * - reads can be repeated with no side effects
> >   * - repeated reads return the last value written
> > @@ -407,6 +414,9 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, 
> > size_t size);
> >  #define ioremap_wc ioremap_wc
> >  #define ioremap_wt ioremap_wc
> >  
> > +void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size);
> > +#define ioremap_nopost ioremap_nopost
> > +
> >  void iounmap(volatile void __iomem *iomem_cookie);
> >  #define iounmap iounmap
> >  
> > diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> > index ff0eed2..4ffaf16 100644
> > --- a/arch/arm/mm/ioremap.c
> > +++ b/arch/arm/mm/ioremap.c
> > @@ -463,6 +463,13 @@ void iounmap(volatile void __iomem *cookie)
> >  }
> >  EXPORT_SYMBOL(iounmap);
> >  
> > +void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
> > +{
> > +   return arch_ioremap_caller(res_cookie, size, MT_UNCACHED,
> > +  __builtin_return_address(0));
> > +}
> > +EXPORT_SYMBOL_GPL(ioremap_nopost);
> > +
> >  #ifdef CONFIG_PCI
> >  static int pci_ioremap_mem_type = MT_DEVICE;
> >  
> > diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> > index 3b5c7aa..dfd736a 100644
> > --- a/arch/arm/mm/nommu.c
> > +++ b/arch/arm/mm/nommu.c
> > @@ -21,6 +21,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  #include "mm.h"
> >  
> >  unsigned long vectors_base;
> > @@ -433,6 +435,13 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, 
> > size_t size)
> >  }
> >  EXPORT_SYMBOL(ioremap_wc);
> >  
> > +void __iomem *ioremap_nopost(resource_size_t res_cookie, size_t size)
> > +{
> > +   return __arm_ioremap_caller(res_cookie, size, MT_UNCACHED,
> > + 

[PATCH v3 2/4] f2fs: introduce f2fs_wait_discard_bios

2017-04-05 Thread Chao Yu
Split f2fs_wait_discard_bios from f2fs_wait_discard_bio, just for cleanup,
no logic change.

Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h|  2 +-
 fs/f2fs/segment.c | 37 ++---
 fs/f2fs/super.c   |  2 +-
 3 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 68e55bd6b50e..33073bd1f090 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2187,7 +2187,7 @@ void destroy_flush_cmd_control(struct f2fs_sb_info *sbi, 
bool free);
 void invalidate_blocks(struct f2fs_sb_info *sbi, block_t addr);
 bool is_checkpointed_data(struct f2fs_sb_info *sbi, block_t blkaddr);
 void refresh_sit_entry(struct f2fs_sb_info *sbi, block_t old, block_t new);
-void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, block_t blkaddr);
+void f2fs_wait_discard_bios(struct f2fs_sb_info *sbi);
 void clear_prefree_segments(struct f2fs_sb_info *sbi, struct cp_control *cpc);
 void release_discard_addrs(struct f2fs_sb_info *sbi);
 int npages_for_summary_flush(struct f2fs_sb_info *sbi, bool for_ra);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 07dddcb0d03d..4243c7539f42 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -786,13 +786,9 @@ void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, 
block_t blkaddr)
struct list_head *pend_list = &(dcc->discard_pend_list);
struct list_head *wait_list = &(dcc->discard_wait_list);
struct discard_cmd *dc, *tmp;
-   struct blk_plug plug;
 
mutex_lock(>cmd_lock);
 
-   if (blkaddr == NULL_ADDR)
-   goto release_discard;
-
list_for_each_entry_safe(dc, tmp, pend_list, list) {
if (dc->lstart <= blkaddr && blkaddr < dc->lstart + dc->len)
__punch_discard_cmd(sbi, dc, blkaddr);
@@ -806,19 +802,30 @@ void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, 
block_t blkaddr)
}
}
 
-release_discard:
-   /* this comes from f2fs_put_super */
-   if (blkaddr == NULL_ADDR) {
-   blk_start_plug();
-   list_for_each_entry_safe(dc, tmp, pend_list, list)
-   __submit_discard_cmd(sbi, dc);
-   blk_finish_plug();
+   mutex_unlock(>cmd_lock);
+}
 
-   list_for_each_entry_safe(dc, tmp, wait_list, list) {
-   wait_for_completion_io(>wait);
-   __remove_discard_cmd(sbi, dc);
-   }
+/* This comes from f2fs_put_super */
+void f2fs_wait_discard_bios(struct f2fs_sb_info *sbi)
+{
+   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
+   struct list_head *pend_list = &(dcc->discard_pend_list);
+   struct list_head *wait_list = &(dcc->discard_wait_list);
+   struct discard_cmd *dc, *tmp;
+   struct blk_plug plug;
+
+   mutex_lock(>cmd_lock);
+
+   blk_start_plug();
+   list_for_each_entry_safe(dc, tmp, pend_list, list)
+   __submit_discard_cmd(sbi, dc);
+   blk_finish_plug();
+
+   list_for_each_entry_safe(dc, tmp, wait_list, list) {
+   wait_for_completion_io(>wait);
+   __remove_discard_cmd(sbi, dc);
}
+
mutex_unlock(>cmd_lock);
 }
 
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f315b54cd840..b4c5c6298698 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -793,7 +793,7 @@ static void f2fs_put_super(struct super_block *sb)
}
 
/* be sure to wait for any on-going discard commands */
-   f2fs_wait_discard_bio(sbi, NULL_ADDR);
+   f2fs_wait_discard_bios(sbi);
 
/* write_checkpoint can update stat informaion */
f2fs_destroy_stats(sbi);
-- 
2.12.2.510.ge1104a5ee539



Re: [PATCH v2 6/9] drm/rockchip: Reoder unload sequence

2017-04-05 Thread jeffy

Hi Sean,

On 04/05/2017 03:44 AM, Sean Paul wrote:

On Sat, Apr 01, 2017 at 07:35:26PM +0800, Jeffy Chen wrote:

We should not cleanup iommu before cleanup other resources.

Reorder unload sequence, follow exynos drm.


This doesn't match the cleanup sequence in rockchip_drm_bind. Also make sure
that you're unwinding the setup sequence when you cleanup (ie: take a close look
at how you set things up and reverse it for cleanup).

ok, will reoder the bind sequence too, thanx.


Sean



Signed-off-by: Jeffy Chen 
---

Changes in v2: None

  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b360e62..a5d83cb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -244,11 +244,13 @@ static void rockchip_drm_unbind(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);

rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
drm_dev_unregister(drm_dev);
drm_dev_unref(drm_dev);
--
2.1.4








Re: [PATCH v2 7/9] drm/rockchip: Force disable all crtc when unload

2017-04-05 Thread jeffy

Hi Daniel,

On 04/03/2017 03:58 PM, Daniel Vetter wrote:

On Sat, Apr 1, 2017 at 1:35 PM, Jeffy Chen  wrote:

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a5d83cb..5dbf011 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -246,6 +246,7 @@ static void rockchip_drm_unbind(struct device *dev)
 rockchip_drm_fbdev_fini(drm_dev);
 drm_kms_helper_poll_fini(drm_dev);

+   drm_crtc_force_disable_all(drm_dev);


This will result in a WARN_ON in latest drm-next because rockchip is
atomic, and this helper is for legacy kms drivers. You want to use
drm_atomic_helper_shutdown here.
-Daniel


oops, thanx for the notice.



Re: [PATCH v2 5/9] drm/rockchip: vop: Enable pm domain when resetting vop

2017-04-05 Thread jeffy

Hi Sean,

On 04/05/2017 03:42 AM, Sean Paul wrote:

On Sat, Apr 01, 2017 at 07:35:25PM +0800, Jeffy Chen wrote:

Hi Jeffy,
Could you please add commit messages describing *why* you're making the change?
It might be obvious to you (and maybe me), but others will benefit from better
descriptions.

ok, will do.



Signed-off-by: Jeffy Chen 
---

Changes in v2: None

  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31 +++--
  1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..1d85319 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1365,6 +1365,12 @@ static int vop_initial(struct vop *vop)
return ret;
}

+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   goto err_put_pm_runtime;


This should go to err_unprepare_dclk, the next error condition should go to
err_put_pm_runtime
hmm, that's true, i copied it from vop_enable without a double 
check...will fix that too.



+   }
+
/* Enable both the hclk and aclk to setup the vop */
ret = clk_prepare_enable(vop->hclk);
if (ret < 0) {
@@ -1422,6 +1428,8 @@ static int vop_initial(struct vop *vop)

vop->is_enabled = false;

+   pm_runtime_put_sync(vop->dev);
+
return 0;

  err_disable_aclk:
@@ -1430,6 +1438,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
  err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);


Should be above err_unprepare_dclk


oh, too careless, thanx for pointing that out.

return ret;
  }

@@ -1530,12 +1540,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;

-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1556,15 +1560,22 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
/* IRQ is initially disabled; it gets enabled in power_on */
disable_irq(vop->irq);

+   pm_runtime_enable(>dev);
+
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }


This function move would be a lot easier to understand with a commit message ;-)


ok

+
ret = vop_create_crtc(vop);
if (ret)
-   goto err_enable_irq;
-
-   pm_runtime_enable(>dev);
+   goto err_disable_pm_runtime;


Do you have anything to clean up from vop_initial()?


i'll put it to the end of bind ;)


return 0;

-err_enable_irq:
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
  }
--
2.1.4








[PATCH] edac: thunderx: Fix L2C MCI interrupt disable

2017-04-05 Thread Jan Glauber
Fix a typo that disabled the MCI interrupts using the wrong bitmask.

Signed-off-by: Jan Glauber 
---
 drivers/edac/thunderx_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/thunderx_edac.c b/drivers/edac/thunderx_edac.c
index 2eae2b2..8844aef 100644
--- a/drivers/edac/thunderx_edac.c
+++ b/drivers/edac/thunderx_edac.c
@@ -2088,7 +2088,7 @@ static void thunderx_l2c_remove(struct pci_dev *pdev)
writeq(L2C_CBC_INT_ENA_ALL, l2c->regs + L2C_CBC_INT_ENA_W1C);
break;
case PCI_DEVICE_ID_THUNDER_L2C_MCI:
-   writeq(L2C_CBC_INT_ENA_ALL, l2c->regs + L2C_MCI_INT_ENA_W1C);
+   writeq(L2C_MCI_INT_ENA_ALL, l2c->regs + L2C_MCI_INT_ENA_W1C);
break;
}
 
-- 
2.9.0.rc0.21.g322



[PATCH v2] f2fs: prevent waiter encountering incorrect discard states

2017-04-05 Thread Chao Yu
In f2fs_submit_discard_endio, we will wake up waiter before setting
discard command states, so waiter may use incorrect states. Change
the order between complete() and states setting to fix this issue.

Signed-off-by: Chao Yu 
---
v2: use wait_for_completion_io before releasing discard entry to avoid
use-after-free.
 fs/f2fs/segment.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 24911c5679d6..ec19cfcfcd24 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -717,9 +717,9 @@ static void f2fs_submit_discard_endio(struct bio *bio)
 {
struct discard_cmd *dc = (struct discard_cmd *)bio->bi_private;
 
-   complete(>wait);
dc->error = bio->bi_error;
dc->state = D_DONE;
+   complete(>wait);
bio_put(bio);
 }
 
@@ -807,8 +807,7 @@ void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, 
block_t blkaddr)
 
list_for_each_entry_safe(dc, tmp, wait_list, list) {
if (dc->lstart <= blkaddr && blkaddr < dc->lstart + dc->len) {
-   if (dc->state == D_SUBMIT)
-   wait_for_completion_io(>wait);
+   wait_for_completion_io(>wait);
__punch_discard_cmd(sbi, dc, blkaddr);
}
}
@@ -868,8 +867,10 @@ static int issue_discard_thread(void *data)
blk_finish_plug();
 
list_for_each_entry_safe(dc, tmp, wait_list, list) {
-   if (dc->state == D_DONE)
+   if (dc->state == D_DONE) {
+   wait_for_completion_io(>wait);
__remove_discard_cmd(sbi, dc);
+   }
}
mutex_unlock(>cmd_lock);
 
-- 
2.12.2.510.ge1104a5ee539



Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 11:26, Ingo Molnar  wrote:
>
> * Ard Biesheuvel  wrote:
>
>> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz
>>  wrote:
>> >
>> > Hi,
>> >
>> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
>> >> Hello all,
>> >>
>> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
>> >>
>> >> The following changes since commit 
>> >> 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
>> >>
>> >>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 
>> >> +)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git 
>> >> tags/efi-urgent
>> >>
>> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
>> >>
>> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer 
>> >> (2017-04-04 15:56:43 +0100)
>> >>
>> >> 
>> >> Two fixes related to the EFI framebuffer driver:
>> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
>> >>   BLT-only -- the framebuffer base address is invalid in this case, and 
>> >> the
>> >>   Blt() method is not accessible to the kernel.
>> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
>> >>   device that has memory decoding enabled, claim the memory resource so 
>> >> that
>> >>   the PCI core will not attempt to move it later on.
>> >>
>> >> 
>> >> Ard Biesheuvel (1):
>> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer
>> >
>> > This patch breaks build if PCI support is not enabled:
>> >
>> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
>> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
>> > ‘pci_claim_resource’ [-Werror=implicit-function-declaration]
>> >
>> > (x86 ifdefs are not enough, the patch should also check for PCI support)
>> >
>> > Also please cc: linux-fbdev mailing list & me on fbdev related patches.
>> >
>>
>> Thanks for the report. The patch was tested successfully on an
>> impressive list of configurations by kbuild test robot, but
>> apparently, none of those has PCI disabled.
>>
>> Ingo, since you have queued this already, how would you like to
>> proceed? I don't think we need anything beyond
>>
>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>> index 758960b6aec9..b827a8113e26 100644
>> --- a/drivers/video/fbdev/efifb.c
>> +++ b/drivers/video/fbdev/efifb.c
>> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = {
>>
>>  builtin_platform_driver(efifb_driver);
>>
>> -#ifndef CONFIG_X86
>> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
>
> I've rebased it all, it's still pretty fresh (two hours old) and the delta fix
> would look pretty ugly in the urgent branch.
>

Thanks for cleaning that up.

-- 
Ard.


[tip:efi/urgent] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  55d728a40d368ba80443be85c02e641fc9082a3f
Gitweb: http://git.kernel.org/tip/55d728a40d368ba80443be85c02e641fc9082a3f
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 16:27:44 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:25:53 +0200

efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed via a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a non-x86 quirk to the EFI fb driver to find the BAR associated
with the GOP base address, and claim the BAR resource so that the PCI
core will not move it.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.7+
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/video/fbdev/efifb.c | 66 -
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8c4dc1e..b827a81 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -143,6 +144,8 @@ static struct attribute *efifb_attrs[] = {
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_dev_disabled;  /* FB base matches BAR of a disabled device */
+
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -152,7 +155,7 @@ static int efifb_probe(struct platform_device *dev)
unsigned int size_total;
char *option = NULL;
 
-   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
 
if (fb_get_options("efifb", ))
@@ -360,3 +363,64 @@ static struct platform_driver efifb_driver = {
 };
 
 builtin_platform_driver(efifb_driver);
+
+#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
+
+static bool pci_bar_found; /* did we find a BAR matching the efifb base? */
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+   u16 word;
+
+   pci_bar_found = true;
+
+   pci_read_config_word(dev, PCI_COMMAND, );
+   if (!(word & PCI_COMMAND_MEMORY)) {
+   pci_dev_disabled = true;
+   dev_err(>dev,
+   "BAR %d: assigned to efifb but device is disabled!\n",
+   idx);
+   return;
+   }
+
+   if (pci_claim_resource(dev, idx)) {
+   pci_dev_disabled = true;
+   dev_err(>dev,
+   "BAR %d: failed to claim resource for efifb!\n", idx);
+   return;
+   }
+
+   dev_info(>dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+   u64 base = screen_info.lfb_base;
+   u64 size = screen_info.lfb_size;
+   int i;
+
+   if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   return;
+
+   if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+   base |= (u64)screen_info.ext_lfb_base << 32;
+
+   if (!base)
+   return;
+
+   for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+   struct resource *res = >resource[i];
+
+   if (!(res->flags & IORESOURCE_MEM))
+   continue;
+
+   if (res->start <= base && res->end >= base + size - 1) {
+   claim_efifb_bar(dev, i);
+   break;
+   }
+   }
+}
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+  16, efifb_fixup_resources);
+
+#endif


Re: [PATCH v2 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

2017-04-05 Thread Andy Shevchenko
On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley  wrote:
> The probing of THRE irq behaviour assumes the other end will be reading
> bytes out of the buffer in order to probe the port at driver init. In
> some cases the other end cannot be relied upon to read these bytes, so
> provide a flag for them to skip this step.
>

> Bit 16 was chosen as the flags are a int and the top bits are taken.

19 ?

>
> Acked-by: Benjamin Herrenschmidt 
> Signed-off-by: Joel Stanley 
> ---
>  drivers/tty/serial/8250/8250_port.c | 2 +-
>  include/linux/serial_core.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_port.c 
> b/drivers/tty/serial/8250/8250_port.c
> index 6119516ef5fc..60a6c247340f 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
> }
> }
>
> -   if (port->irq) {
> +   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
> unsigned char iir1;
> /*
>  * Test for UARTs that do not reassert THRE when the
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 58484fb35cc8..260245deec94 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -195,6 +195,7 @@ struct uart_port {
>  #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
>  #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
> */ )
>
> +#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
>  /* Port has hardware-assisted h/w flow control */
>  #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
>  #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
> --
> 2.11.0
>



-- 
With Best Regards,
Andy Shevchenko


[tip:efi/core] efi/bgrt: Enable ACPI BGRT handling on arm64

2017-04-05 Thread tip-bot for Bhupesh Sharma
Commit-ID:  6e7300cff1c410dde7ac4354b6a0a8cb0a561e54
Gitweb: http://git.kernel.org/tip/6e7300cff1c410dde7ac4354b6a0a8cb0a561e54
Author: Bhupesh Sharma 
AuthorDate: Tue, 4 Apr 2017 17:02:41 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:25 +0200

efi/bgrt: Enable ACPI BGRT handling on arm64

Now that the ACPI BGRT handling code has been made generic, we can
enable it for arm64.

Signed-off-by: Bhupesh Sharma 
[ Updated commit log to reflect that BGRT is only enabled for arm64, and added
  missing 'return' statement to the dummy acpi_parse_bgrt() function. ]
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-8-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 arch/arm64/kernel/acpi.c| 3 +++
 arch/x86/kernel/acpi/boot.c | 6 --
 drivers/acpi/Kconfig| 2 +-
 drivers/acpi/bgrt.c | 6 ++
 include/linux/efi-bgrt.h| 5 +
 5 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 64d9cbd6..e25c11e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -233,6 +234,8 @@ done:
early_init_dt_scan_chosen_stdout();
} else {
parse_spcr(earlycon_init_is_deferred);
+   if (IS_ENABLED(CONFIG_ACPI_BGRT))
+   acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
}
 }
 
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b2879cc23..7085498 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1564,12 +1564,6 @@ int __init early_acpi_boot_init(void)
return 0;
 }
 
-static int __init acpi_parse_bgrt(struct acpi_table_header *table)
-{
-   efi_bgrt_init(table);
-   return 0;
-}
-
 int __init acpi_boot_init(void)
 {
/* those are executed after early-quirks are executed */
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 83e5f7e..dad02c0 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -440,7 +440,7 @@ config ACPI_CUSTOM_METHOD
 
 config ACPI_BGRT
bool "Boottime Graphics Resource Table support"
-   depends on EFI && X86
+   depends on EFI && (X86 || ARM64)
 help
  This driver adds support for exposing the ACPI Boottime Graphics
  Resource Table, which allows the operating system to obtain
diff --git a/drivers/acpi/bgrt.c b/drivers/acpi/bgrt.c
index ca28aa57..df1c629 100644
--- a/drivers/acpi/bgrt.c
+++ b/drivers/acpi/bgrt.c
@@ -81,6 +81,12 @@ static struct attribute_group bgrt_attribute_group = {
.bin_attrs = bgrt_bin_attributes,
 };
 
+int __init acpi_parse_bgrt(struct acpi_table_header *table)
+{
+   efi_bgrt_init(table);
+   return 0;
+}
+
 static int __init bgrt_init(void)
 {
int ret;
diff --git a/include/linux/efi-bgrt.h b/include/linux/efi-bgrt.h
index 2fd3993..e6f624b 100644
--- a/include/linux/efi-bgrt.h
+++ b/include/linux/efi-bgrt.h
@@ -6,6 +6,7 @@
 #ifdef CONFIG_ACPI_BGRT
 
 void efi_bgrt_init(struct acpi_table_header *table);
+int __init acpi_parse_bgrt(struct acpi_table_header *table);
 
 /* The BGRT data itself; only valid if bgrt_image != NULL. */
 extern size_t bgrt_image_size;
@@ -14,6 +15,10 @@ extern struct acpi_table_bgrt bgrt_tab;
 #else /* !CONFIG_ACPI_BGRT */
 
 static inline void efi_bgrt_init(struct acpi_table_header *table) {}
+static inline int __init acpi_parse_bgrt(struct acpi_table_header *table)
+{
+   return 0;
+}
 
 #endif /* !CONFIG_ACPI_BGRT */
 


[tip:efi/core] x86/efi/bgrt: Move efi-bgrt handling out of arch/x86

2017-04-05 Thread tip-bot for Bhupesh Sharma
Commit-ID:  75def552bb1e0d39918df31b86f7d09e754ea0fc
Gitweb: http://git.kernel.org/tip/75def552bb1e0d39918df31b86f7d09e754ea0fc
Author: Bhupesh Sharma 
AuthorDate: Tue, 4 Apr 2017 17:02:40 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:24 +0200

x86/efi/bgrt: Move efi-bgrt handling out of arch/x86

Now with open-source boot firmware (EDK2) supporting ACPI BGRT table
addition even for architectures like AARCH64, it makes sense to move
out the 'efi-bgrt.c' file and supporting infrastructure from 'arch/x86'
directory and house it inside 'drivers/firmware/efi', so that this common
code can be used across architectures.

Signed-off-by: Bhupesh Sharma 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-7-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/efi/Makefile | 1 -
 drivers/firmware/efi/Makefile  | 1 +
 {arch/x86/platform => drivers/firmware}/efi/efi-bgrt.c | 0
 3 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 066619b..f1d83b3 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1,6 +1,5 @@
 OBJECT_FILES_NON_STANDARD_efi_thunk_$(BITS).o := y
 
 obj-$(CONFIG_EFI)  += quirks.o efi.o efi_$(BITS).o 
efi_stub_$(BITS).o
-obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o
 obj-$(CONFIG_EARLY_PRINTK_EFI) += early_printk.o
 obj-$(CONFIG_EFI_MIXED)+= efi_thunk_$(BITS).o
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index ad67342..0329d31 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -9,6 +9,7 @@
 #
 KASAN_SANITIZE_runtime-wrappers.o  := n
 
+obj-$(CONFIG_ACPI_BGRT)+= efi-bgrt.o
 obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o memattr.o
 obj-$(CONFIG_EFI)  += capsule.o memmap.o
 obj-$(CONFIG_EFI_VARS) += efivars.o
diff --git a/arch/x86/platform/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
similarity index 100%
rename from arch/x86/platform/efi/efi-bgrt.c
rename to drivers/firmware/efi/efi-bgrt.c


[PATCH v4 2/8] dt-bindings: input: touschcreen: remove sun4i documentation

2017-04-05 Thread Quentin Schulz
This patch removes the sun4i touchscreen controller binding
documentation since it has been merged with the sun4i GPADC binding
documentation.

Signed-off-by: Quentin Schulz 
Acked-by: Rob Herring 
Acked-by: Dmitry Torokhov 
---

v4:
  - correct patch title,

 .../bindings/input/touchscreen/sun4i.txt   | 38 --
 1 file changed, 38 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/input/touchscreen/sun4i.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt 
b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
deleted file mode 100644
index 89abecd..000
--- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-sun4i resistive touchscreen controller
---
-
-Required properties:
- - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
-   "allwinner,sun6i-a31-ts"
- - reg: mmio address range of the chip
- - interrupts: interrupt to which the chip is connected
- - #thermal-sensor-cells: shall be 0
-
-Optional properties:
- - allwinner,ts-attached: boolean indicating that an actual touchscreen
-  is attached to the controller
- - allwinner,tp-sensitive-adjust : integer (4 bits)
-  adjust sensitivity of pen down detection
-  between 0 (least sensitive) and 15
-  (defaults to 15)
- - allwinner,filter-type: integer (2 bits)
-  select median and averaging filter
-  samples used for median / averaging filter
-  0: 4/2
-  1: 5/3
-  2: 8/4
-  3: 16/8
-  (defaults to 1)
-
-Example:
-
-   rtp: rtp@01c25000 {
-   compatible = "allwinner,sun4i-a10-ts";
-   reg = <0x01c25000 0x100>;
-   interrupts = <29>;
-   allwinner,ts-attached;
-   #thermal-sensor-cells = <0>;
-   /* sensitive/noisy touch panel */
-   allwinner,tp-sensitive-adjust = <0>;
-   allwinner,filter-type = <3>;
-   };
-- 
2.9.3



[PATCH 1/2] [media] rc-core: Add inlined stubs for core rc_* functions

2017-04-05 Thread Lee Jones
Currently users have to use all sorts of ugly #ifery within
their drivers in order to avoid linking issues at build time.
This patch allows users to safely call these functions when
!CONFIG_RC_CORE and make decisions based on the return value
instead.  This is a much more common and clean way of doing
things within the Linux kernel.

Signed-off-by: Lee Jones 
---
 include/media/rc-core.h | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 73ddd721..45ba739 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -209,7 +209,14 @@ struct rc_dev {
  * @rc_driver_type: specifies the type of the RC output to be allocated
  * returns a pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 struct rc_dev *rc_allocate_device(enum rc_driver_type);
+#else
+static inline struct rc_dev *rc_allocate_device(int unused)
+{
+   return NULL;
+}
+#endif
 
 /**
  * devm_rc_allocate_device - Managed RC device allocation
@@ -218,21 +225,42 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type);
  * @rc_driver_type: specifies the type of the RC output to be allocated
  * returns a pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 struct rc_dev *devm_rc_allocate_device(struct device *dev, enum 
rc_driver_type);
+#else
+static inline struct rc_dev *devm_rc_allocate_device(struct device *dev, int 
unused)
+{
+   return NULL;
+}
+#endif
 
 /**
  * rc_free_device - Frees a RC device
  *
  * @dev: pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 void rc_free_device(struct rc_dev *dev);
+#else
+static inline void rc_free_device(struct rc_dev *dev)
+{
+   return;
+}
+#endif
 
 /**
  * rc_register_device - Registers a RC device
  *
  * @dev: pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 int rc_register_device(struct rc_dev *dev);
+#else
+static inline int rc_register_device(struct rc_dev *dev)
+{
+   return -EOPNOTSUPP;
+}
+#endif
 
 /**
  * devm_rc_register_device - Manageded registering of a RC device
@@ -240,14 +268,28 @@ int rc_register_device(struct rc_dev *dev);
  * @parent: pointer to struct device.
  * @dev: pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 int devm_rc_register_device(struct device *parent, struct rc_dev *dev);
+#else
+static inline int devm_rc_register_device(struct device *parent, struct rc_dev 
*dev)
+{
+   return -EOPNOTSUPP;
+}
+#endif
 
 /**
  * rc_unregister_device - Unregisters a RC device
  *
  * @dev: pointer to struct rc_dev.
  */
+#ifdef CONFIG_RC_CORE
 void rc_unregister_device(struct rc_dev *dev);
+#else
+static inline void rc_unregister_device(struct rc_dev *dev)
+{
+   return;
+}
+#endif
 
 /**
  * rc_open - Opens a RC device
-- 
2.9.3



[no subject]

2017-04-05 Thread kullstj_ml
Hello Linux

http://www.freedom4you.nl/partenariat.php?lady=ge2y55bcz3d0ms





kullstj_ml


[tip:efi/core] efi/arm-stub: Correct FDT and initrd allocation rules for arm64

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  138728dd4ee30d3f35587c269c46cc829ec4d58b
Gitweb: http://git.kernel.org/tip/138728dd4ee30d3f35587c269c46cc829ec4d58b
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:02:37 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:23 +0200

efi/arm-stub: Correct FDT and initrd allocation rules for arm64

On arm64, we have made some changes over the past year to the way the
kernel itself is allocated and to how it deals with the initrd and FDT.
This patch brings the allocation logic in the EFI stub in line with that,
which is necessary because the introduction of KASLR has created the
possibility for the initrd to be allocated in a place where the kernel
may not be able to map it. (This is mostly a theoretical scenario, since
it only affects systems where the physical memory footprint exceeds the
size of the linear mapping.)

Since we know the kernel itself will be covered by the linear mapping,
choose a suitably sized window (i.e., based on the size of the linear
region) covering the kernel when allocating memory for the initrd.

The FDT may be anywhere in memory on arm64 now that we map it via the
fixmap, so we can lift the address restriction there completely.

Tested-by: Richard Ruigrok 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jeffrey Hugo 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 arch/arm/include/asm/efi.h  | 14 +-
 arch/arm64/include/asm/efi.h| 23 ++-
 drivers/firmware/efi/libstub/arm-stub.c |  7 ---
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index e4e6a9d6..17f1f1a 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -85,6 +85,18 @@ static inline void efifb_setup_from_dmi(struct screen_info 
*si, const char *opt)
  */
 #define ZIMAGE_OFFSET_LIMITSZ_128M
 #define MIN_ZIMAGE_OFFSET  MAX_UNCOMP_KERNEL_SIZE
-#define MAX_FDT_OFFSET ZIMAGE_OFFSET_LIMIT
+
+/* on ARM, the FDT should be located in the first 128 MB of RAM */
+static inline unsigned long efi_get_max_fdt_addr(unsigned long dram_base)
+{
+   return dram_base + ZIMAGE_OFFSET_LIMIT;
+}
+
+/* on ARM, the initrd should be loaded in a lowmem region */
+static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base,
+   unsigned long image_addr)
+{
+   return dram_base + SZ_512M;
+}
 
 #endif /* _ASM_ARM_EFI_H */
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index e744528..083a52d3 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -46,7 +46,28 @@ int efi_set_mapping_permissions(struct mm_struct *mm, 
efi_memory_desc_t *md);
  * 2MiB so we know it won't cross a 2MiB boundary.
  */
 #define EFI_FDT_ALIGN  SZ_2M   /* used by allocate_new_fdt_and_exit_boot() */
-#define MAX_FDT_OFFSET SZ_512M
+
+/* on arm64, the FDT may be located anywhere in system RAM */
+static inline unsigned long efi_get_max_fdt_addr(unsigned long dram_base)
+{
+   return ULONG_MAX;
+}
+
+/*
+ * On arm64, we have to ensure that the initrd ends up in the linear region,
+ * which is a 1 GB aligned region of size '1UL << (VA_BITS - 1)' that is
+ * guaranteed to cover the kernel Image.
+ *
+ * Since the EFI stub is part of the kernel Image, we can relax the
+ * usual requirements in Documentation/arm64/booting.txt, which still
+ * apply to other bootloaders, and are required for some kernel
+ * configurations.
+ */
+static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base,
+   unsigned long image_addr)
+{
+   return (image_addr & ~(SZ_1G - 1UL)) + (1UL << (VA_BITS - 1));
+}
 
 #define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
 #define __efi_call_early(f, ...)   f(__VA_ARGS__)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index d4056c6..02049ff 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -213,8 +213,9 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
if (!fdt_addr)
pr_efi(sys_table, "Generating empty DTB\n");
 
-   status = handle_cmdline_files(sys_table, image, cmdline_ptr,
- "initrd=", dram_base + SZ_512M,
+   status = handle_cmdline_files(sys_table, image, cmdline_ptr, "initrd=",
+ 

[tip:efi/core] x86/efi: Clean up a minor mistake in comment

2017-04-05 Thread tip-bot for Baoquan He
Commit-ID:  b1d1776139698d7522dfd46aa81a056f030ddaf7
Gitweb: http://git.kernel.org/tip/b1d1776139698d7522dfd46aa81a056f030ddaf7
Author: Baoquan He 
AuthorDate: Tue, 4 Apr 2017 17:02:43 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:26 +0200

x86/efi: Clean up a minor mistake in comment

EFI allocates runtime services regions from EFI_VA_START, -4G, down
to -68G, EFI_VA_END - 64G altogether, top-down.

The mechanism was introduced in commit:

  d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping")

Fix the comment that still says bottom-up.

Signed-off-by: Baoquan He 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-10-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/efi/efi_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index a4695da..6cbf9e0 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -47,7 +47,7 @@
 #include 
 
 /*
- * We allocate runtime services regions bottom-up, starting from -4G, i.e.
+ * We allocate runtime services regions top-down, starting from -4G, i.e.
  * 0x___ and limit EFI VA mapping space to 64G.
  */
 static u64 efi_va = EFI_VA_START;


[tip:efi/core] efi/arm-stub: Round up FDT allocation to mapping size

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  24d7c494ce46d5bb6c8fd03e88a48ae249ec1492
Gitweb: http://git.kernel.org/tip/24d7c494ce46d5bb6c8fd03e88a48ae249ec1492
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:02:39 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:24 +0200

efi/arm-stub: Round up FDT allocation to mapping size

The FDT is mapped via a fixmap entry that is at least 2 MB in size and
2 MB aligned on 4 KB page size kernels.

On UEFI systems, the FDT allocation may share this 2 MB mapping with a
reserved region (or another memory region that we should never map),
unless we account for this in the size of the allocation (the alignment
is already 2 MB)

So instead of taking guesses at the needed space, simply allocate 2 MB
immediately. The allocation will be recorded as EFI_LOADER_DATA, and the
kernel only memblock_reserve()'s the actual size of the FDT, so the
unused space will be released back to the kernel.

Reviewed-By: Jeffrey Hugo 
Tested-by: Richard Ruigrok 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-6-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 arch/arm64/include/asm/efi.h   |  1 +
 drivers/firmware/efi/libstub/fdt.c | 57 --
 2 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 083a52d3..8f3043a 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -1,6 +1,7 @@
 #ifndef _ASM_EFI_H
 #define _ASM_EFI_H
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/firmware/efi/libstub/fdt.c 
b/drivers/firmware/efi/libstub/fdt.c
index 260c4b4..41f457b 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -206,6 +206,10 @@ static efi_status_t exit_boot_func(efi_system_table_t 
*sys_table_arg,
return update_fdt_memmap(p->new_fdt_addr, map);
 }
 
+#ifndef MAX_FDT_SIZE
+#define MAX_FDT_SIZE   SZ_2M
+#endif
+
 /*
  * Allocate memory for a new FDT, then add EFI, commandline, and
  * initrd related fields to the FDT.  This routine increases the
@@ -233,7 +237,6 @@ efi_status_t 
allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
u32 desc_ver;
unsigned long mmap_key;
efi_memory_desc_t *memory_map, *runtime_map;
-   unsigned long new_fdt_size;
efi_status_t status;
int runtime_entry_count = 0;
struct efi_boot_memmap map;
@@ -262,41 +265,29 @@ efi_status_t 
allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
   "Exiting boot services and installing virtual address map...\n");
 
map.map = _map;
+   status = efi_high_alloc(sys_table, MAX_FDT_SIZE, EFI_FDT_ALIGN,
+   new_fdt_addr, max_addr);
+   if (status != EFI_SUCCESS) {
+   pr_efi_err(sys_table,
+  "Unable to allocate memory for new device tree.\n");
+   goto fail;
+   }
+
/*
-* Estimate size of new FDT, and allocate memory for it. We
-* will allocate a bigger buffer if this ends up being too
-* small, so a rough guess is OK here.
+* Now that we have done our final memory allocation (and free)
+* we can get the memory map key needed for exit_boot_services().
 */
-   new_fdt_size = fdt_size + EFI_PAGE_SIZE;
-   while (1) {
-   status = efi_high_alloc(sys_table, new_fdt_size, EFI_FDT_ALIGN,
-   new_fdt_addr, max_addr);
-   if (status != EFI_SUCCESS) {
-   pr_efi_err(sys_table, "Unable to allocate memory for 
new device tree.\n");
-   goto fail;
-   }
-
-   status = update_fdt(sys_table,
-   (void *)fdt_addr, fdt_size,
-   (void *)*new_fdt_addr, new_fdt_size,
-   cmdline_ptr, initrd_addr, initrd_size);
+   status = efi_get_memory_map(sys_table, );
+   if (status != EFI_SUCCESS)
+   goto fail_free_new_fdt;
 
-   /* Succeeding the first time is the expected case. */
-   if (status == EFI_SUCCESS)
-   break;
+   status = update_fdt(sys_table, (void *)fdt_addr, fdt_size,
+   (void *)*new_fdt_addr, MAX_FDT_SIZE, cmdline_ptr,
+   initrd_addr, initrd_size);
 
-   if (status == EFI_BUFFER_TOO_SMALL) {
-   /*
-* We need to allocate more space for the new
-

[tip:efi/core] efi/pstore: Return error code (if any) from efi_pstore_write()

2017-04-05 Thread tip-bot for Evgeny Kalugin
Commit-ID:  fee929ba1c9386e524ed3abcc6d5f9b64381f959
Gitweb: http://git.kernel.org/tip/fee929ba1c9386e524ed3abcc6d5f9b64381f959
Author: Evgeny Kalugin 
AuthorDate: Tue, 4 Apr 2017 17:02:42 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:25 +0200

efi/pstore: Return error code (if any) from efi_pstore_write()

For some reason return value from actual variable setting was ignored.
With this change error code get transferred upwards through call stack.

Signed-off-by: Evgeny Kalugin 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-9-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/efi-pstore.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/efi-pstore.c 
b/drivers/firmware/efi/efi-pstore.c
index f402ba2..6b5acef 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -274,9 +274,9 @@ static int efi_pstore_write(enum pstore_type_id type,
for (i = 0; i < DUMP_NAME_LEN; i++)
efi_name[i] = name[i];
 
-   efivar_entry_set_safe(efi_name, vendor, PSTORE_EFI_ATTRIBUTES,
- !pstore_cannot_block_path(reason),
- size, psi->buf);
+   ret = efivar_entry_set_safe(efi_name, vendor, PSTORE_EFI_ATTRIBUTES,
+   !pstore_cannot_block_path(reason),
+   size, psi->buf);
 
if (reason == KMSG_DUMP_OOPS)
efivar_run_worker();


[PATCH 2/2] [media] cec: Handle RC capability more elegantly

2017-04-05 Thread Lee Jones
If a user specifies the use of RC as a capability, they should
really be enabling RC Core code.  If they do not we WARN() them
of this and disable the capability for them.

Once we know RC Core code has not been enabled, we can update
the user's capabilities and use them as a term of reference for
other RC-only calls.  This is preferable to having ugly #ifery
scattered throughout C code.

Most of the functions are actually safe to call, since they
sensibly check for a NULL RC pointer before they attempt to
deference it.

Signed-off-by: Lee Jones 
---
 drivers/media/cec/cec-core.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index cfe414a..c859dcf 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -208,9 +208,15 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
return ERR_PTR(-EINVAL);
if (WARN_ON(!available_las || available_las > CEC_MAX_LOG_ADDRS))
return ERR_PTR(-EINVAL);
+
+   /* If RC Core is not available, remove driver-level capability */
+   if (!IS_REACHABLE(CONFIG_RC_CORE))
+   caps &= ~CEC_CAP_RC;
+
adap = kzalloc(sizeof(*adap), GFP_KERNEL);
if (!adap)
return ERR_PTR(-ENOMEM);
+
strlcpy(adap->name, name, sizeof(adap->name));
adap->phys_addr = CEC_PHYS_ADDR_INVALID;
adap->log_addrs.cec_version = CEC_OP_CEC_VERSION_2_0;
@@ -237,7 +243,6 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
if (!(caps & CEC_CAP_RC))
return adap;
 
-#if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!adap->rc) {
@@ -264,9 +269,7 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
adap->rc->priv = adap;
adap->rc->map_name = RC_MAP_CEC;
adap->rc->timeout = MS_TO_NS(100);
-#else
-   adap->capabilities &= ~CEC_CAP_RC;
-#endif
+
return adap;
 }
 EXPORT_SYMBOL_GPL(cec_allocate_adapter);
@@ -285,7 +288,6 @@ int cec_register_adapter(struct cec_adapter *adap,
adap->owner = parent->driver->owner;
adap->devnode.dev.parent = parent;
 
-#if IS_REACHABLE(CONFIG_RC_CORE)
if (adap->capabilities & CEC_CAP_RC) {
adap->rc->dev.parent = parent;
res = rc_register_device(adap->rc);
@@ -298,15 +300,13 @@ int cec_register_adapter(struct cec_adapter *adap,
return res;
}
}
-#endif
 
res = cec_devnode_register(>devnode, adap->owner);
if (res) {
-#if IS_REACHABLE(CONFIG_RC_CORE)
/* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
adap->rc = NULL;
-#endif
+
return res;
}
 
@@ -337,11 +337,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
if (IS_ERR_OR_NULL(adap))
return;
 
-#if IS_REACHABLE(CONFIG_RC_CORE)
/* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
adap->rc = NULL;
-#endif
+
debugfs_remove_recursive(adap->cec_dir);
cec_devnode_unregister(>devnode);
 }
@@ -357,9 +356,7 @@ void cec_delete_adapter(struct cec_adapter *adap)
kthread_stop(adap->kthread);
if (adap->kthread_config)
kthread_stop(adap->kthread_config);
-#if IS_REACHABLE(CONFIG_RC_CORE)
rc_free_device(adap->rc);
-#endif
kfree(adap);
 }
 EXPORT_SYMBOL_GPL(cec_delete_adapter);
-- 
2.9.3



Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

2017-04-05 Thread Michal Hocko
On Wed 05-04-17 13:31:23, Andrey Ryabinin wrote:
> On 04/04/2017 12:41 PM, Michal Hocko wrote:
> > On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote:
> >> From: Andrey Ryabinin 
> >> Subject: mm/vmalloc: allow to call vfree() in atomic context fix
> >>
> >> Don't spawn worker if we already purging.
> >>
> >> Signed-off-by: Andrey Ryabinin 
> > 
> > I would rather put this into a separate patch. Ideally with some numners
> > as this is an optimization...
> > 
> 
> It's quite simple optimization and don't think that this deserves to
> be a separate patch.

I disagree. I am pretty sure nobody will remember after few years. I
do not want to push too hard on this but I can tell you from my own
experience that we used to do way too many optimizations like that in
the past and they tend to be real head scratchers these days. Moreover
people just tend to build on top of them without understadning and then
chances are quite high that they are no longer relevant anymore.

> But I did some measurements though. With enabled VMAP_STACK=y and
> NR_CACHED_STACK changed to 0 running fork() 10 times gives this:
> 
> With optimization:
> 
> ~ # grep try_purge /proc/kallsyms 
> 811d0dd0 t try_purge_vmap_area_lazy
> ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 
> 'function == 0x811d0dd0' ./fork
> 
>  Performance counter stats for 'system wide' (10 runs):
> 
> 15  workqueue:workqueue_queue_work
>  ( +-  0.88% )
> 
>1.615368474 seconds time elapsed   
>( +-  0.41% )
> 
> 
> Without optimization:
> ~ # grep try_purge /proc/kallsyms 
> 811d0dd0 t try_purge_vmap_area_lazy
> ~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 
> 'function == 0x811d0dd0' ./fork
> 
>  Performance counter stats for 'system wide' (10 runs):
> 
> 30  workqueue:workqueue_queue_work
>  ( +-  1.31% )
> 
>1.613231060 seconds time elapsed   
>( +-  0.38% )
> 
> 
> So there is no measurable difference on the test itself, but we queue
> twice more jobs without this optimization.  It should decrease load of
> kworkers.

And this is really valueable for the changelog!

Thanks!
-- 
Michal Hocko
SUSE Labs


[tip:efi/core] efi/libstub: Fix harmless command line parsing bug

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  4c3f14bb87b683a2e5bbc6d6660b41893ecacfd0
Gitweb: http://git.kernel.org/tip/4c3f14bb87b683a2e5bbc6d6660b41893ecacfd0
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:02:45 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:27 +0200

efi/libstub: Fix harmless command line parsing bug

When we parse the 'efi=' command line parameter in the stub, we
fail to take spaces into account. Currently, the only way this
could result in unexpected behavior is when the string 'nochunk'
appears as a separate command line argument after 'efi=xxx,yyy,zzz ',
so this is harmless in practice. But let's fix it nonetheless.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/efi-stub-helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 919822b..3290fae 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -436,14 +436,14 @@ efi_status_t efi_parse_options(char *cmdline)
 * Remember, because efi= is also used by the kernel we need to
 * skip over arguments we don't understand.
 */
-   while (*str) {
+   while (*str && *str != ' ') {
if (!strncmp(str, "nochunk", 7)) {
str += strlen("nochunk");
__chunk_size = -1UL;
}
 
/* Group words together, delimited by "," */
-   while (*str && *str != ',')
+   while (*str && *str != ' ' && *str != ',')
str++;
 
if (*str == ',')


[tip:efi/core] efi/libstub/arm/arm64: Disable debug prints on 'quiet' cmdline arg

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  eeff7d634f4750306785be709ca444140c29b043
Gitweb: http://git.kernel.org/tip/eeff7d634f4750306785be709ca444140c29b043
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:09:09 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:28 +0200

efi/libstub/arm/arm64: Disable debug prints on 'quiet' cmdline arg

The EFI stub currently prints a number of diagnostic messages that do
not carry a lot of information. Since these prints are not controlled
by 'loglevel' or other command line parameters, and since they appear on
the EFI framebuffer as well (if enabled), it would be nice if we could
turn them off.

So let's add support for the 'quiet' command line parameter in the stub,
and disable the non-error prints if it is passed.

Signed-off-by: Ard Biesheuvel 
Acked-by: Mark Rutland 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@redhat.com
Cc: bhsha...@redhat.com
Cc: b...@alien8.de
Cc: eug...@hp.com
Cc: evgeny.kalu...@intel.com
Cc: jh...@codeaurora.org
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: roy.fr...@cavium.com
Cc: rruig...@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/arm-stub.c| 20 ++--
 drivers/firmware/efi/libstub/arm32-stub.c  |  2 ++
 drivers/firmware/efi/libstub/efi-stub-helper.c |  9 +
 drivers/firmware/efi/libstub/efistub.h |  7 +++
 drivers/firmware/efi/libstub/secureboot.c  |  2 ++
 include/linux/efi.h|  3 ---
 6 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index ac3222f..657bb72 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -116,8 +116,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
goto fail;
 
-   pr_efi(sys_table, "Booting Linux Kernel...\n");
-
status = check_platform_features(sys_table);
if (status != EFI_SUCCESS)
goto fail;
@@ -151,6 +149,16 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
goto fail;
}
 
+   if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+   IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+   cmdline_size == 0)
+   efi_parse_options(CONFIG_CMDLINE);
+
+   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
+   efi_parse_options(cmdline_ptr);
+
+   pr_efi(sys_table, "Booting Linux Kernel...\n");
+
si = setup_graphics(sys_table);
 
status = handle_kernel_image(sys_table, image_addr, _size,
@@ -162,14 +170,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
goto fail_free_cmdline;
}
 
-   if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
-   IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
-   cmdline_size == 0)
-   efi_parse_options(CONFIG_CMDLINE);
-
-   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
-   efi_parse_options(cmdline_ptr);
-
secure_boot = efi_get_secureboot(sys_table);
 
/*
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
b/drivers/firmware/efi/libstub/arm32-stub.c
index 18a8b5e..becbda4 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#include "efistub.h"
+
 efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
 {
int block;
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 2e17d2b..b018436 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -33,11 +33,16 @@
 static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
 static int __section(.data) __nokaslr;
+static int __section(.data) __quiet;
 
 int __pure nokaslr(void)
 {
return __nokaslr;
 }
+int __pure is_quiet(void)
+{
+   return __quiet;
+}
 
 #define EFI_MMAP_NR_SLACK_SLOTS8
 
@@ -424,6 +429,10 @@ efi_status_t efi_parse_options(char const *cmdline)
if (str == cmdline || (str && str > cmdline && *(str - 1) == ' '))
__nokaslr = 1;
 
+   str = strstr(cmdline, "quiet");
+   if (str == cmdline || (str && str > cmdline && *(str - 1) == ' '))
+   __quiet = 1;
+
/*
 * If no EFI parameters were specified on the cmdline we've got
 * nothing to do.
diff --git 

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

2017-04-05 Thread Xin Long
On Wed, Apr 5, 2017 at 5:14 AM, Marcelo Ricardo Leitner
 wrote:
> On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov  
>> wrote:
>> > Hi,
>> >
>> > I've got the following error report while fuzzing the kernel with 
>> > syzkaller.
>> >
>> > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>> >
>> > A reproducer and .config are attached.
>> The script is pretty hard to reproduce the issue in my env.
>
> I didn't try running it but I also found the reproducer very complicated
> to follow. Do you have any plans on having some PoC optimizer, so we can
> have a more readable code?
> strace is handy for filtering the noise, yes, but sometimes it doesn't
> cut it.
I got the script now:
1. create sk
2. set sk->sndbuf = x
3. sendmsg with size s1 (s1 < x)
4. sendmsg with size s2 (s1+s2 > x)
5. sendmsg with size s3 (wspace < 0), wait sndbuf, schedule out.
6. listen sk (abnormal operation on sctp client)
7. accept sk.

In step 6, sk->sk_state = listening, then step 7 could get the first asoc
from ep->asoc_list and alloc a new sk2, attach the asoc to sk2.

after a while, sendmsg schedule in, but asoc->sk is sk2, !=sk.
the same issue we fix for peeloff on commit dfcb9f4f99f1 ("sctp: deny
peeloff operation on asocs with threads sleeping on it") happens.

But we should not fix it by the same way as for peeloff. the real reason
causes this issue is on step 6, it should disallow listen on the established sk.

The following fix should work for this, just similar with what
inet_listen() did.

@@ -7174,6 +7175,9 @@ int sctp_inet_listen(struct socket *sock, int backlog)
if (sock->state != SS_UNCONNECTED)
goto out;

+   if (!sctp_sstate(sk, LISTENING) && !sctp_sstate(sk,CLOSED))
+   goto out;
+

what do you think ?


Re: [RFC PATCH 1/6] x86/apic: Replace init_bsp_APIC() with apic_virture_wire_mode_setup()

2017-04-05 Thread Thomas Gleixner
On Wed, 5 Apr 2017, Thomas Gleixner wrote:

> On Wed, 29 Mar 2017, Dou Liyang wrote:
> 
> > The init_bsp_APIC() setups the virtual wire mode through the local
> > APIC.
> > 
> > The function name is unsuitable which might imply that the BSP's
> > APIC will be initialized here, actually, where it will be done is
> > almost at the end of start_kernel(). And the CONFIG X86_64 is also
> > imply the X86_LOCAL_APIC is y.
> 
> Correct, but X86_32 can have X86_LOCAL_APIC=n. And by removing the ifdefs
> you break that.

Oops. Sorry, the function is replaced by an empty stub for the APIC=n
case. So that's correct.

> >  /*
> > - * An initial setup of the virtual wire mode.
> > + * Setup the through-local-APIC virtual wire mode.
> >   */
> > -void __init init_bsp_APIC(void)
> > +void apic_virture_wire_mode_setup(void)
> 
> s/virture/virtual/ ?
> 
> Why is this function not longer marked __init ?
> 
> Thanks,
> 
>   tglx
> 


[PATCH v4 3/8] iio: adc: sun4i-gpadc-iio: move code used in MFD probing to new function

2017-04-05 Thread Quentin Schulz
This moves code used in MFD probing to a new sun4i_gpadc_probe_mfd
function.

This driver was initially written for A10, A13 and A31 SoCs which
already had a DT binding for this IP, thus we needed to use an MFD to
probe the different drivers without changing the DT binding of these
SoCs.

For SoCs that will require to create a DT binding for this IP, we can
avoid using an MFD, thus we need two separate functions: one for probing
via MFD and one for probing without MFD.

This split the code specific to MFD probing in a function separated from
the driver probe function.

Signed-off-by: Quentin Schulz 
Acked-by: Jonathan Cameron 
---

v3:
  - updated commit log,

added in v2

 drivers/iio/adc/sun4i-gpadc-iio.c | 78 ++-
 1 file changed, 45 insertions(+), 33 deletions(-)

diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c 
b/drivers/iio/adc/sun4i-gpadc-iio.c
index a8e134f..7cb997a 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -454,31 +454,16 @@ static int sun4i_irq_init(struct platform_device *pdev, 
const char *name,
return 0;
 }
 
-static int sun4i_gpadc_probe(struct platform_device *pdev)
+static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
+struct iio_dev *indio_dev)
 {
-   struct sun4i_gpadc_iio *info;
-   struct iio_dev *indio_dev;
+   struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+   struct sun4i_gpadc_dev *sun4i_gpadc_dev =
+   dev_get_drvdata(pdev->dev.parent);
int ret;
-   struct sun4i_gpadc_dev *sun4i_gpadc_dev;
-
-   sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
-
-   indio_dev = devm_iio_device_alloc(>dev, sizeof(*info));
-   if (!indio_dev)
-   return -ENOMEM;
 
-   info = iio_priv(indio_dev);
-   platform_set_drvdata(pdev, indio_dev);
-
-   mutex_init(>mutex);
info->regmap = sun4i_gpadc_dev->regmap;
-   info->indio_dev = indio_dev;
-   init_completion(>completion);
-   indio_dev->name = dev_name(>dev);
-   indio_dev->dev.parent = >dev;
-   indio_dev->dev.of_node = pdev->dev.of_node;
-   indio_dev->info = _gpadc_iio_info;
-   indio_dev->modes = INDIO_DIRECT_MODE;
+
indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
indio_dev->channels = sun4i_gpadc_channels;
 
@@ -519,8 +504,7 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
dev_err(>dev,
"could not register thermal sensor: %ld\n",
PTR_ERR(tzd));
-   ret = PTR_ERR(tzd);
-   goto err;
+   return PTR_ERR(tzd);
}
} else {
indio_dev->num_channels =
@@ -528,36 +512,65 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
indio_dev->channels = sun4i_gpadc_channels_no_temp;
}
 
-   pm_runtime_set_autosuspend_delay(>dev,
-SUN4I_GPADC_AUTOSUSPEND_DELAY);
-   pm_runtime_use_autosuspend(>dev);
-   pm_runtime_set_suspended(>dev);
-   pm_runtime_enable(>dev);
-
if (IS_ENABLED(CONFIG_THERMAL_OF)) {
ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
 sun4i_gpadc_temp_data_irq_handler,
 "temp_data", >temp_data_irq,
 >ignore_temp_data_irq);
if (ret < 0)
-   goto err;
+   return ret;
}
 
ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
 sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
 >fifo_data_irq, >ignore_fifo_data_irq);
if (ret < 0)
-   goto err;
+   return ret;
 
if (IS_ENABLED(CONFIG_THERMAL_OF)) {
ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
if (ret < 0) {
dev_err(>dev,
"failed to register iio map array\n");
-   goto err;
+   return ret;
}
}
 
+   return 0;
+}
+
+static int sun4i_gpadc_probe(struct platform_device *pdev)
+{
+   struct sun4i_gpadc_iio *info;
+   struct iio_dev *indio_dev;
+   int ret;
+
+   indio_dev = devm_iio_device_alloc(>dev, sizeof(*info));
+   if (!indio_dev)
+   return -ENOMEM;
+
+   info = iio_priv(indio_dev);
+   platform_set_drvdata(pdev, indio_dev);
+
+   mutex_init(>mutex);
+   info->indio_dev = indio_dev;
+   init_completion(>completion);
+   indio_dev->name = dev_name(>dev);
+   indio_dev->dev.parent = >dev;
+   indio_dev->dev.of_node = pdev->dev.of_node;
+   indio_dev->info = 

Re: [PATCH v2 02/22] asm-generic/io.h: add ioremap_nopost remap interface

2017-04-05 Thread Russell King - ARM Linux
On Tue, Mar 28, 2017 at 03:45:43PM +0100, Lorenzo Pieralisi wrote:
> On Mon, Mar 27, 2017 at 08:41:10PM -0500, Bjorn Helgaas wrote:
> > On Mon, Mar 27, 2017 at 10:49:30AM +0100, Lorenzo Pieralisi wrote:
> > > diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> > > index 7afb0e2..50b292f 100644
> > > --- a/arch/x86/include/asm/io.h
> > > +++ b/arch/x86/include/asm/io.h
> > > @@ -171,6 +171,7 @@ static inline unsigned int isa_virt_to_bus(volatile 
> > > void *address)
> > >  extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned 
> > > long size);
> > >  extern void __iomem *ioremap_uc(resource_size_t offset, unsigned long 
> > > size);
> > >  #define ioremap_uc ioremap_uc
> > > +#define ioremap_nopost ioremap_nocache
> > 
> > These are all the same as the default from asm-generic.h.  Do we really
> > need these definitions in alpha, avr32, frv, ia64, x86?
> 
> Those arches do not include asm-generic.h (I suppose for a good reason)
> but a definition is needed anyway if we want code using ioremap_nopost()
> to be unconditional. This is one way of doing it, there are others not
> sure they are any better, I am open to suggestions.

We do have linux/io.h, which should be included in preference to asm/io.h.
linux/io.h has existed for years, but I still see (from time to time)
patches adding drivers that (imho incorrectly) use asm/io.h.

Also, this:

> > > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> > > index 7ef015e..0e81938 100644
> > > --- a/include/asm-generic/io.h
> > > +++ b/include/asm-generic/io.h
> > > @@ -915,6 +915,10 @@ extern void ioport_unmap(void __iomem *p);
> > >  #endif /* CONFIG_GENERIC_IOMAP */
> > >  #endif /* CONFIG_HAS_IOPORT_MAP */
> > >  
> > > +#ifndef ioremap_nopost
> > > +#define ioremap_nopost ioremap_nocache
> > > +#endif
> > > +
> > >  #ifndef xlate_dev_kmem_ptr
> > >  #define xlate_dev_kmem_ptr xlate_dev_kmem_ptr
> > >  static inline void *xlate_dev_kmem_ptr(void *addr)

could well be located in linux/io.h, which would make it available
everywhere.

I'd suggest one change to this though:

#ifndef ioremap_nopost
static inline void __iomem *ioremap_nopost(resource_size_t offset,
   unsigned long size)
{
return ioremap_nocache(offset, size);
}
#endif

This way, if someone forgets to define ioremap_nopost() in their
asm/io.h but provides a definition or extern prototype for
ioremap_nopost(), we end up with a compile error to highlight the
error, rather than the error being hidden by the preprocessor.

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


Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

2017-04-05 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to  extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.

$patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
Northstar2.

Sorry for not letting you know this earlier. But I feel the design of the
driver should be changed. Extcon shouldn't be used here. The extcon
notifications should be sent to the consumer driver and the consumer driver
should be responsible for invoking the phy ops.

The phy ops being invoked during extcon events doesn't look right.

Thanks
Kishon


[PATCH 03/16] mfd: madera: Register map tables for Cirrus Logic CS47L35

2017-04-05 Thread Richard Fitzgerald
Regmap configuration tables for Cirrus Logic CS47L35 codecs.

Signed-off-by: Piotr Stankiewicz 
Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 drivers/mfd/Kconfig  |6 +
 drivers/mfd/Makefile |3 +
 drivers/mfd/cs47l35-tables.c | 1688 ++
 3 files changed, 1697 insertions(+)
 create mode 100644 drivers/mfd/cs47l35-tables.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f0f9979..5aa62f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -226,6 +226,12 @@ config MFD_MADERA_SPI
  Support for the Cirrus Logic Madera platform audio SoC
  core functionality controlled via SPI.
 
+config MFD_CS47L35
+   bool "Cirrus Logic CS47L35"
+   depends on MFD_MADERA
+   help
+ Support for Cirrus Logic CS47L35 Smart Codec
+
 config MFD_ASIC3
bool "Compaq ASIC3"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c41f6c9..c14a86d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -73,6 +73,9 @@ wm8994-objs   := wm8994-core.o wm8994-irq.o 
wm8994-regmap.o
 obj-$(CONFIG_MFD_WM8994)   += wm8994.o
 
 obj-$(CONFIG_MFD_MADERA)   += madera-core.o
+ifeq ($(CONFIG_MFD_CS47L35),y)
+obj-$(CONFIG_MFD_MADERA)   += cs47l35-tables.o
+endif
 obj-$(CONFIG_MFD_MADERA_I2C)   += madera-i2c.o
 obj-$(CONFIG_MFD_MADERA_SPI)   += madera-spi.o
 
diff --git a/drivers/mfd/cs47l35-tables.c b/drivers/mfd/cs47l35-tables.c
new file mode 100644
index 000..1336c60
--- /dev/null
+++ b/drivers/mfd/cs47l35-tables.c
@@ -0,0 +1,1688 @@
+/*
+ * Regmap tables for CS47L35 codec
+ *
+ * Copyright 2015-2016 Cirrus Logic
+ *
+ * Author: Piotr Stankiewicz 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "madera.h"
+
+static const struct reg_sequence cs47l35_reva_16_patch[] = {
+   { 0x460, 0x0c40 },
+   { 0x461, 0xcd1a },
+   { 0x462, 0x0c40 },
+   { 0x463, 0xb53b },
+   { 0x464, 0x0c40 },
+   { 0x465, 0x7503 },
+   { 0x466, 0x0c40 },
+   { 0x467, 0x4a41 },
+   { 0x468, 0x0041 },
+   { 0x469, 0x3491 },
+   { 0x46a, 0x0841 },
+   { 0x46b, 0x1f50 },
+   { 0x46c, 0x0446 },
+   { 0x46d, 0x14ed },
+   { 0x46e, 0x0446 },
+   { 0x46f, 0x1455 },
+   { 0x470, 0x04c6 },
+   { 0x471, 0x1220 },
+   { 0x472, 0x04c6 },
+   { 0x473, 0x040f },
+   { 0x474, 0x04ce },
+   { 0x475, 0x0339 },
+   { 0x476, 0x05df },
+   { 0x477, 0x028f },
+   { 0x478, 0x05df },
+   { 0x479, 0x0209 },
+   { 0x47a, 0x05df },
+   { 0x47b, 0x00cf },
+   { 0x47c, 0x05df },
+   { 0x47d, 0x0001 },
+   { 0x47e, 0x07ff },
+};
+
+int cs47l35_patch(struct madera *madera)
+{
+   int ret;
+
+   ret = regmap_register_patch(madera->regmap, cs47l35_reva_16_patch,
+   ARRAY_SIZE(cs47l35_reva_16_patch));
+   if (ret < 0)
+   dev_err(madera->dev, "Error applying patch: %d\n", ret);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(cs47l35_patch);
+
+static const struct reg_default cs47l35_reg_default[] = {
+   { 0x0020, 0x }, /* R32 (0x20) - Tone Generator 1 */
+   { 0x0021, 0x1000 }, /* R33 (0x21) - Tone Generator 2 */
+   { 0x0022, 0x }, /* R34 (0x22) - Tone Generator 3 */
+   { 0x0023, 0x1000 }, /* R35 (0x23) - Tone Generator 4 */
+   { 0x0024, 0x }, /* R36 (0x24) - Tone Generator 5 */
+   { 0x0030, 0x }, /* R48 (0x30) - PWM Drive 1 */
+   { 0x0031, 0x0100 }, /* R49 (0x31) - PWM Drive 2 */
+   { 0x0032, 0x0100 }, /* R50 (0x32) - PWM Drive 3 */
+   { 0x0061, 0x01ff }, /* R97 (0x61) - Sample Rate Sequence Select 1 */
+   { 0x0062, 0x01ff }, /* R98 (0x62) - Sample Rate Sequence Select 2 */
+   { 0x0063, 0x01ff }, /* R99 (0x63) - Sample Rate Sequence Select 3 */
+   { 0x0064, 0x01ff }, /* R100 (0x64) - Sample Rate Sequence Select 4*/
+   { 0x0066, 0x01ff }, /* R102 (0x66) - Always On Triggers Sequence 
Select 1*/
+   { 0x0067, 0x01ff }, /* R103 (0x67) - Always On Triggers Sequence 
Select 2*/
+   { 0x0090, 0x }, /* R144 (0x90) - Haptics Control 1 */
+   { 0x0091, 0x7fff }, /* R145 (0x91) - Haptics Control 2 */
+   { 0x0092, 0x }, /* R146 (0x92) - Haptics phase 1 intensity */
+   { 0x0093, 0x }, /* R147 (0x93) - Haptics phase 1 duration */
+   { 0x0094, 0x }, /* R148 (0x94) - Haptics phase 2 intensity */
+   { 0x0095, 0x }, /* R149 (0x95) - Haptics phase 2 duration 

[PATCH 14/16] ASoC: cs47l35: Add codec driver for Cirrus Logic CS47L35

2017-04-05 Thread Richard Fitzgerald
Adds the codec driver for the CS47L35 SmartCodec. This is a
multi-functional codec based on the Cirrus Logic Madera platform.

Signed-off-by: Piotr Stankiewicz 
Signed-off-by: Richard Fitzgerald 
Signed-off-by: Charles Keepax 
---
 sound/soc/codecs/Kconfig   |6 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cs47l35.c | 1747 
 3 files changed, 1755 insertions(+)
 create mode 100644 sound/soc/codecs/cs47l35.c

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 753b0f1..aad4a7e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -62,6 +62,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS42XX8_I2C if I2C
select SND_SOC_CS4349 if I2C
select SND_SOC_CS47L24 if MFD_CS47L24
+   select SND_SOC_CS47L35 if MFD_CS47L35
select SND_SOC_CS53L30 if I2C
select SND_SOC_CX20442 if TTY
select SND_SOC_DA7210 if SND_SOC_I2C_AND_SPI
@@ -493,6 +494,9 @@ config SND_SOC_CS4349
 config SND_SOC_CS47L24
tristate
 
+config SND_SOC_CS47L35
+   tristate
+
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
tristate "Cirrus Logic CS53L30 CODEC"
@@ -580,6 +584,8 @@ config SND_SOC_LM49453
 
 config SND_SOC_MADERA
tristate
+   default y if SND_SOC_CS47L35=y
+   default m if SND_SOC_CS47L35=m
 
 config SND_SOC_MAX98088
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 641cf66..1b26ecb 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -55,6 +55,7 @@ snd-soc-cs42xx8-objs := cs42xx8.o
 snd-soc-cs42xx8-i2c-objs := cs42xx8-i2c.o
 snd-soc-cs4349-objs := cs4349.o
 snd-soc-cs47l24-objs := cs47l24.o
+snd-soc-cs47l35-objs := cs47l35.o
 snd-soc-cs53l30-objs := cs53l30.o
 snd-soc-cx20442-objs := cx20442.o
 snd-soc-da7210-objs := da7210.o
@@ -289,6 +290,7 @@ obj-$(CONFIG_SND_SOC_CS42XX8)   += snd-soc-cs42xx8.o
 obj-$(CONFIG_SND_SOC_CS42XX8_I2C) += snd-soc-cs42xx8-i2c.o
 obj-$(CONFIG_SND_SOC_CS4349)   += snd-soc-cs4349.o
 obj-$(CONFIG_SND_SOC_CS47L24)  += snd-soc-cs47l24.o
+obj-$(CONFIG_SND_SOC_CS47L35)  += snd-soc-cs47l35.o
 obj-$(CONFIG_SND_SOC_CS53L30)  += snd-soc-cs53l30.o
 obj-$(CONFIG_SND_SOC_CX20442)  += snd-soc-cx20442.o
 obj-$(CONFIG_SND_SOC_DA7210)   += snd-soc-da7210.o
diff --git a/sound/soc/codecs/cs47l35.c b/sound/soc/codecs/cs47l35.c
new file mode 100644
index 000..50ecc44
--- /dev/null
+++ b/sound/soc/codecs/cs47l35.c
@@ -0,0 +1,1747 @@
+/*
+ * cs47l35.c  --  ALSA SoC Audio driver for CS47L35 codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "madera.h"
+#include "wm_adsp.h"
+
+#define CS47L35_NUM_ADSP   3
+#define CS47L35_MONO_OUTPUTS   1
+
+struct cs47l35 {
+   struct madera_priv core;
+   struct madera_fll fll;
+};
+
+static const struct wm_adsp_region cs47l35_dsp1_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x08 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x0e },
+   { .type = WMFW_ADSP2_XM, .base = 0x0a },
+   { .type = WMFW_ADSP2_YM, .base = 0x0c },
+};
+
+static const struct wm_adsp_region cs47l35_dsp2_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x10 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x16 },
+   { .type = WMFW_ADSP2_XM, .base = 0x12 },
+   { .type = WMFW_ADSP2_YM, .base = 0x14 },
+};
+
+static const struct wm_adsp_region cs47l35_dsp3_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x18 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x1e },
+   { .type = WMFW_ADSP2_XM, .base = 0x1a },
+   { .type = WMFW_ADSP2_YM, .base = 0x1c },
+};
+
+static const struct wm_adsp_region *cs47l35_dsp_regions[] = {
+   cs47l35_dsp1_regions,
+   cs47l35_dsp2_regions,
+   cs47l35_dsp3_regions,
+};
+
+static const int wm_adsp2_control_bases[] = {
+   MADERA_DSP1_CONFIG_1,
+   MADERA_DSP2_CONFIG_1,
+   MADERA_DSP3_CONFIG_1,
+};
+
+static const char * const cs47l35_outdemux_texts[] = {
+   "HPOUT",
+   "EPOUT",
+};
+
+static SOC_ENUM_SINGLE_DECL(cs47l35_outdemux_enum, SND_SOC_NOPM, 0,
+   cs47l35_outdemux_texts);
+
+static const struct snd_kcontrol_new cs47l35_outdemux =
+   SOC_DAPM_ENUM_EXT("HPOUT1 Demux", cs47l35_outdemux_enum,
+ snd_soc_dapm_get_enum_double, madera_out1_demux_put);
+
+static int cs47l35_adsp_power_ev(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol 

Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Bartlomiej Zolnierkiewicz

Hi,

On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
> Hello all,
> 
> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
> 
> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
> 
>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
> 
> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
> 
>   efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 
> 15:56:43 +0100)
> 
> 
> Two fixes related to the EFI framebuffer driver:
> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
>   BLT-only -- the framebuffer base address is invalid in this case, and the
>   Blt() method is not accessible to the kernel.
> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
>   device that has memory decoding enabled, claim the memory resource so that
>   the PCI core will not attempt to move it later on.
> 
> 
> Ard Biesheuvel (1):
>   efifb: Avoid reconfiguration of BAR that covers the framebuffer

This patch breaks build if PCI support is not enabled:

drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
‘pci_claim_resource’ [-Werror=implicit-function-declaration]

(x86 ifdefs are not enough, the patch should also check for PCI support)

Also please cc: linux-fbdev mailing list & me on fbdev related patches.

> Cohen, Eugene (1):
>   efi/libstub: Skip GOP with PIXEL_BLT_ONLY format
> 
>  drivers/firmware/efi/libstub/gop.c |  6 ++--
>  drivers/video/fbdev/efifb.c| 66 
> +-
>  2 files changed, 69 insertions(+), 3 deletions(-)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics



Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi,
>
> On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
>> Hello all,
>>
>> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
>>
>> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
>>
>>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
>>
>> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
>>
>>   efifb: Avoid reconfiguration of BAR that covers the framebuffer 
>> (2017-04-04 15:56:43 +0100)
>>
>> 
>> Two fixes related to the EFI framebuffer driver:
>> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
>>   BLT-only -- the framebuffer base address is invalid in this case, and the
>>   Blt() method is not accessible to the kernel.
>> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
>>   device that has memory decoding enabled, claim the memory resource so that
>>   the PCI core will not attempt to move it later on.
>>
>> 
>> Ard Biesheuvel (1):
>>   efifb: Avoid reconfiguration of BAR that covers the framebuffer
>
> This patch breaks build if PCI support is not enabled:
>
> drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
> drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
> ‘pci_claim_resource’ [-Werror=implicit-function-declaration]
>
> (x86 ifdefs are not enough, the patch should also check for PCI support)
>
> Also please cc: linux-fbdev mailing list & me on fbdev related patches.
>

Thanks for the report. The patch was tested successfully on an
impressive list of configurations by kbuild test robot, but
apparently, none of those has PCI disabled.

Ingo, since you have queued this already, how would you like to
proceed? I don't think we need anything beyond

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 758960b6aec9..b827a8113e26 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = {

 builtin_platform_driver(efifb_driver);

-#ifndef CONFIG_X86
+#if defined(CONFIG_PCI) && !defined(CONFIG_X86)

 static bool pci_bar_found; /* did we find a BAR matching the efifb base? */


-- 
Ard.


[PATCH 16/16] ASoC: cs47l90: Add codec driver for Cirrus Logic CS47L90

2017-04-05 Thread Richard Fitzgerald
Adds the codec driver for the CS47L90 SmartCodec. This is a
multi-functional codec based on the Cirrus Logic Madera platform.

Signed-off-by: Nikesh Oswal 
Signed-off-by: Charles Keepax 
Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/Kconfig   |6 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cs47l90.c | 2645 
 3 files changed, 2653 insertions(+)
 create mode 100644 sound/soc/codecs/cs47l90.c

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 45fb885..65e2bbd 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -64,6 +64,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS47L24 if MFD_CS47L24
select SND_SOC_CS47L35 if MFD_CS47L35
select SND_SOC_CS47L85 if MFD_CS47L85
+   select SND_SOC_CS47L90 if MFD_CS47L90
select SND_SOC_CS53L30 if I2C
select SND_SOC_CX20442 if TTY
select SND_SOC_DA7210 if SND_SOC_I2C_AND_SPI
@@ -501,6 +502,9 @@ config SND_SOC_CS47L35
 config SND_SOC_CS47L85
tristate
 
+config SND_SOC_CS47L90
+   tristate
+
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
tristate "Cirrus Logic CS53L30 CODEC"
@@ -590,8 +594,10 @@ config SND_SOC_MADERA
tristate
default y if SND_SOC_CS47L35=y
default y if SND_SOC_CS47L85=y
+   default y if SND_SOC_CS47L90=y
default m if SND_SOC_CS47L35=m
default m if SND_SOC_CS47L85=m
+   default m if SND_SOC_CS47L90=m
 
 config SND_SOC_MAX98088
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 7a07241..51a37c5 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -57,6 +57,7 @@ snd-soc-cs4349-objs := cs4349.o
 snd-soc-cs47l24-objs := cs47l24.o
 snd-soc-cs47l35-objs := cs47l35.o
 snd-soc-cs47l85-objs := cs47l85.o
+snd-soc-cs47l90-objs := cs47l90.o
 snd-soc-cs53l30-objs := cs53l30.o
 snd-soc-cx20442-objs := cx20442.o
 snd-soc-da7210-objs := da7210.o
@@ -293,6 +294,7 @@ obj-$(CONFIG_SND_SOC_CS4349)+= snd-soc-cs4349.o
 obj-$(CONFIG_SND_SOC_CS47L24)  += snd-soc-cs47l24.o
 obj-$(CONFIG_SND_SOC_CS47L35)  += snd-soc-cs47l35.o
 obj-$(CONFIG_SND_SOC_CS47L85)  += snd-soc-cs47l85.o
+obj-$(CONFIG_SND_SOC_CS47L90)  += snd-soc-cs47l90.o
 obj-$(CONFIG_SND_SOC_CS53L30)  += snd-soc-cs53l30.o
 obj-$(CONFIG_SND_SOC_CX20442)  += snd-soc-cx20442.o
 obj-$(CONFIG_SND_SOC_DA7210)   += snd-soc-da7210.o
diff --git a/sound/soc/codecs/cs47l90.c b/sound/soc/codecs/cs47l90.c
new file mode 100644
index 000..e772274
--- /dev/null
+++ b/sound/soc/codecs/cs47l90.c
@@ -0,0 +1,2645 @@
+/*
+ * cs47l90.c  --  ALSA SoC Audio driver for CS47L90 codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic
+ *
+ * Author: Nikesh Oswal 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "madera.h"
+#include "wm_adsp.h"
+
+#define CS47L90_NUM_ADSP   7
+#define CS47L90_MONO_OUTPUTS   3
+
+struct cs47l90 {
+   struct madera_priv core;
+   struct madera_fll fll[3];
+};
+
+static const struct wm_adsp_region cs47l90_dsp1_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x08 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x0e },
+   { .type = WMFW_ADSP2_XM, .base = 0x0a },
+   { .type = WMFW_ADSP2_YM, .base = 0x0c },
+};
+
+static const struct wm_adsp_region cs47l90_dsp2_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x10 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x16 },
+   { .type = WMFW_ADSP2_XM, .base = 0x12 },
+   { .type = WMFW_ADSP2_YM, .base = 0x14 },
+};
+
+static const struct wm_adsp_region cs47l90_dsp3_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x18 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x1e },
+   { .type = WMFW_ADSP2_XM, .base = 0x1a },
+   { .type = WMFW_ADSP2_YM, .base = 0x1c },
+};
+
+static const struct wm_adsp_region cs47l90_dsp4_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x20 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x26 },
+   { .type = WMFW_ADSP2_XM, .base = 0x22 },
+   { .type = WMFW_ADSP2_YM, .base = 0x24 },
+};
+
+static const struct wm_adsp_region cs47l90_dsp5_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x28 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x2e },
+   { .type = WMFW_ADSP2_XM, .base = 0x2a },
+   { .type = WMFW_ADSP2_YM, .base = 0x2c },
+};
+
+static const struct wm_adsp_region cs47l90_dsp6_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 

[PATCH 15/16] ASoC: cs47l85: Add codec driver for Cirrus Logic CS47L85

2017-04-05 Thread Richard Fitzgerald
Adds the codec driver for the CS47L85 SmartCodec. This is a
multi-functional codec based on the Cirrus Logic Madera platform.

Signed-off-by: Nariman Poushin 
Signed-off-by: Charles Keepax 
Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/Kconfig   |6 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cs47l85.c | 2706 
 3 files changed, 2714 insertions(+)
 create mode 100644 sound/soc/codecs/cs47l85.c

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index aad4a7e..45fb885 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -63,6 +63,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS4349 if I2C
select SND_SOC_CS47L24 if MFD_CS47L24
select SND_SOC_CS47L35 if MFD_CS47L35
+   select SND_SOC_CS47L85 if MFD_CS47L85
select SND_SOC_CS53L30 if I2C
select SND_SOC_CX20442 if TTY
select SND_SOC_DA7210 if SND_SOC_I2C_AND_SPI
@@ -497,6 +498,9 @@ config SND_SOC_CS47L24
 config SND_SOC_CS47L35
tristate
 
+config SND_SOC_CS47L85
+   tristate
+
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
tristate "Cirrus Logic CS53L30 CODEC"
@@ -585,7 +589,9 @@ config SND_SOC_LM49453
 config SND_SOC_MADERA
tristate
default y if SND_SOC_CS47L35=y
+   default y if SND_SOC_CS47L85=y
default m if SND_SOC_CS47L35=m
+   default m if SND_SOC_CS47L85=m
 
 config SND_SOC_MAX98088
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1b26ecb..7a07241 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -56,6 +56,7 @@ snd-soc-cs42xx8-i2c-objs := cs42xx8-i2c.o
 snd-soc-cs4349-objs := cs4349.o
 snd-soc-cs47l24-objs := cs47l24.o
 snd-soc-cs47l35-objs := cs47l35.o
+snd-soc-cs47l85-objs := cs47l85.o
 snd-soc-cs53l30-objs := cs53l30.o
 snd-soc-cx20442-objs := cx20442.o
 snd-soc-da7210-objs := da7210.o
@@ -291,6 +292,7 @@ obj-$(CONFIG_SND_SOC_CS42XX8_I2C) += snd-soc-cs42xx8-i2c.o
 obj-$(CONFIG_SND_SOC_CS4349)   += snd-soc-cs4349.o
 obj-$(CONFIG_SND_SOC_CS47L24)  += snd-soc-cs47l24.o
 obj-$(CONFIG_SND_SOC_CS47L35)  += snd-soc-cs47l35.o
+obj-$(CONFIG_SND_SOC_CS47L85)  += snd-soc-cs47l85.o
 obj-$(CONFIG_SND_SOC_CS53L30)  += snd-soc-cs53l30.o
 obj-$(CONFIG_SND_SOC_CX20442)  += snd-soc-cx20442.o
 obj-$(CONFIG_SND_SOC_DA7210)   += snd-soc-da7210.o
diff --git a/sound/soc/codecs/cs47l85.c b/sound/soc/codecs/cs47l85.c
new file mode 100644
index 000..9fe76ec
--- /dev/null
+++ b/sound/soc/codecs/cs47l85.c
@@ -0,0 +1,2706 @@
+/*
+ * cs47l85.c  --  ALSA SoC Audio driver for CS47L85 codecs
+ *
+ * Copyright 2015-2017 Cirrus Logic Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "madera.h"
+#include "wm_adsp.h"
+
+#define CS47L85_NUM_ADSP   7
+#define CS47L85_MONO_OUTPUTS   4
+
+struct cs47l85 {
+   struct madera_priv core;
+   struct madera_fll fll[3];
+};
+
+static const struct wm_adsp_region cs47l85_dsp1_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x08 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x0e },
+   { .type = WMFW_ADSP2_XM, .base = 0x0a },
+   { .type = WMFW_ADSP2_YM, .base = 0x0c },
+};
+
+static const struct wm_adsp_region cs47l85_dsp2_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x10 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x16 },
+   { .type = WMFW_ADSP2_XM, .base = 0x12 },
+   { .type = WMFW_ADSP2_YM, .base = 0x14 },
+};
+
+static const struct wm_adsp_region cs47l85_dsp3_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x18 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x1e },
+   { .type = WMFW_ADSP2_XM, .base = 0x1a },
+   { .type = WMFW_ADSP2_YM, .base = 0x1c },
+};
+
+static const struct wm_adsp_region cs47l85_dsp4_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x20 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x26 },
+   { .type = WMFW_ADSP2_XM, .base = 0x22 },
+   { .type = WMFW_ADSP2_YM, .base = 0x24 },
+};
+
+static const struct wm_adsp_region cs47l85_dsp5_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x28 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x2e },
+   { .type = WMFW_ADSP2_XM, .base = 0x2a },
+   { .type = WMFW_ADSP2_YM, .base = 0x2c },
+};
+
+static const struct wm_adsp_region cs47l85_dsp6_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x30 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x36 },
+   { .type = WMFW_ADSP2_XM, .base = 0x32 },

Re: [PATCH] Staging: lustre cleanup macros in libcfs_private.h

2017-04-05 Thread Dilger, Andreas
On Apr 3, 2017, at 15:13, Craig Inches  wrote:
> 
> This resolves a checkpatch warning that "Single statement macros should
> not use a do {} while (0) loop" by removing the loop and adjusting line
> length accordingly.
> 
> Signed-off-by: Craig Inches 
> ---
> .../lustre/include/linux/libcfs/libcfs_private.h   | 51 +++---
> 1 file changed, 15 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
> b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> index 2dae857..150454f 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> @@ -87,12 +87,9 @@ do {   
> \
> #define LIBCFS_VMALLOC_SIZE   (2 << PAGE_SHIFT) /* 2 pages */
> #endif
> 
> -#define LIBCFS_ALLOC_PRE(size, mask) \
> -do { \
> - LASSERT(!in_interrupt() ||  \
> - ((size) <= LIBCFS_VMALLOC_SIZE &&   \
> -  !gfpflags_allow_blocking(mask)));  \
> -} while (0)
> +#define LIBCFS_ALLOC_PRE(size, mask) \
> + LASSERT(!in_interrupt() || ((size) <= LIBCFS_VMALLOC_SIZE   \
> + && !gfpflags_allow_blocking(mask)))

(style) keep operators at the end of the previous line, rather than the start
of the continued line

> 
> #define LIBCFS_ALLOC_POST(ptr, size)  \
> do {  \
> @@ -187,46 +184,28 @@ void  cfs_array_free(void *vars);
> #if LASSERT_ATOMIC_ENABLED
> 
> /** assert value of @a is equal to @v */
> -#define LASSERT_ATOMIC_EQ(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) == v,  \
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_EQ(a, v) LASSERTF(atomic_read(a) == v,
> \
> +  "value: %d\n", atomic_read((a)))

Minor nit - in cases like this where you need to split the line anyway, it
is cleaner (IMHO) to keep the whole statement together:

#define LASSERT_ATOMIC_EQ(a, v) \
LASSERTF(atomic_read(a) == v, "value: %d\n", atomic_read((a)))

Cheers, Andreas

> 
> /** assert value of @a is unequal to @v */
> -#define LASSERT_ATOMIC_NE(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) != v,  \
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_NE(a, v) LASSERTF(atomic_read(a) != v,
> \
> +  "value: %d\n", atomic_read((a)))
> 
> /** assert value of @a is little than @v */
> -#define LASSERT_ATOMIC_LT(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) < v,\
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_LT(a, v) LASSERTF(atomic_read(a) < v, \
> +  "value: %d\n", atomic_read((a)))
> 
> /** assert value of @a is little/equal to @v */
> -#define LASSERT_ATOMIC_LE(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) <= v,  \
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_LE(a, v) LASSERTF(atomic_read(a) <= v,
> \
> +  "value: %d\n", atomic_read((a)))
> 
> /** assert value of @a is great than @v */
> -#define LASSERT_ATOMIC_GT(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) > v,\
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_GT(a, v) LASSERTF(atomic_read(a) > v, \
> +  "value: %d\n", atomic_read((a)))
> 
> /** assert value of @a is great/equal to @v */
> -#define LASSERT_ATOMIC_GE(a, v)   \
> -do { \
> - LASSERTF(atomic_read(a) >= v,  \
> -  "value: %d\n", atomic_read((a)));\
> -} while (0)
> +#define LASSERT_ATOMIC_GE(a, v) LASSERTF(atomic_read(a) >= v,
> \
> +  "value: %d\n", atomic_read((a)))
> 
> /** assert value of 

Re: [PATCH 2/2] ASoC: codec: wm8960: Relax bit clock computation when using PLL

2017-04-05 Thread kbuild test robot
Hi Daniel,

[auto build test WARNING on asoc/for-next]
[also build test WARNING on next-20170405]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Baluta/ASoC-codec-wm8960-Relax-bit-clock-computation-when-using-PLL/20170405-144647
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
config: i386-randconfig-s0-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   sound/soc/codecs/wm8960.c: In function 'wm8960_configure_clocking':
>> sound/soc/codecs/wm8960.c:743:3: warning: 'best_freq_out' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  wm8960_set_pll(codec, freq_in, best_freq_out);
  ^
   sound/soc/codecs/wm8960.c:703:21: note: 'best_freq_out' was declared here
 int diff, closest, best_freq_out;
^
   sound/soc/codecs/wm8960.c:806:56: warning: 'j' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
 snd_soc_update_bits(codec, WM8960_CLOCK1, 0x7 << 6, j << 6);
 ~~^~~~
   sound/soc/codecs/wm8960.c:802:54: warning: 'i' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
 snd_soc_update_bits(codec, WM8960_CLOCK1, 3 << 1, i << 1);
   ~~^~~~

vim +/best_freq_out +743 sound/soc/codecs/wm8960.c

6b662dee Daniel Baluta 2017-04-04  727  
*bclk_idx = k;
6b662dee Daniel Baluta 2017-04-04  728  
best_freq_out = freq_out;
6b662dee Daniel Baluta 2017-04-04  729  
break;
6b662dee Daniel Baluta 2017-04-04  730  }
16c42f46 Daniel Baluta 2017-04-04  731  if 
(diff > 0 && closest > diff) {
16c42f46 Daniel Baluta 2017-04-04  732  
*sysclk_idx = i;
16c42f46 Daniel Baluta 2017-04-04  733  
*dac_idx = j;
16c42f46 Daniel Baluta 2017-04-04  734  
*bclk_idx = k;
16c42f46 Daniel Baluta 2017-04-04  735  
closest = diff;
16c42f46 Daniel Baluta 2017-04-04  736  
best_freq_out = freq_out;
16c42f46 Daniel Baluta 2017-04-04  737  }
6b662dee Daniel Baluta 2017-04-04  738  }
6b662dee Daniel Baluta 2017-04-04  739  }
6b662dee Daniel Baluta 2017-04-04  740  }
6b662dee Daniel Baluta 2017-04-04  741  
6b662dee Daniel Baluta 2017-04-04  742  if (*bclk_idx != -1)
6b662dee Daniel Baluta 2017-04-04 @743  wm8960_set_pll(codec, 
freq_in, best_freq_out);
6b662dee Daniel Baluta 2017-04-04  744  
6b662dee Daniel Baluta 2017-04-04  745  return *bclk_idx;
6b662dee Daniel Baluta 2017-04-04  746  }
3176bf2d Zidan Wang2015-08-11  747  static int 
wm8960_configure_clocking(struct snd_soc_codec *codec)
0e50b51a Zidan Wang2015-05-12  748  {
0e50b51a Zidan Wang2015-05-12  749  struct wm8960_priv *wm8960 = 
snd_soc_codec_get_drvdata(codec);
6b662dee Daniel Baluta 2017-04-04  750  int freq_out, freq_in;
0e50b51a Zidan Wang2015-05-12  751  u16 iface1 = 
snd_soc_read(codec, WM8960_IFACE1);

:: The code at line 743 was first introduced by commit
:: 6b662deec0da0ad4f9dce8112d01828ed72b5a4c ASoC: codec: wm9860: Refactor 
PLL out freq search

:: TO: Daniel Baluta <daniel.bal...@nxp.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip


[PATCH v3 1/4] f2fs: split discard_cmd_list

2017-04-05 Thread Chao Yu
Split discard_cmd_list to discard_{pend,wait}_list, so while sending/waiting
discard command, we can avoid traversing unneeded entries in original list.

Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
---
v3: handle discard command correctly in f2fs_wait_discard_bio
 fs/f2fs/f2fs.h|  3 ++-
 fs/f2fs/segment.c | 47 ++-
 2 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6fbdcac01d9a..68e55bd6b50e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -210,7 +210,8 @@ struct discard_cmd_control {
struct task_struct *f2fs_issue_discard; /* discard thread */
struct list_head discard_entry_list;/* 4KB discard entry list */
int nr_discards;/* # of discards in the list */
-   struct list_head discard_cmd_list;  /* discard cmd list */
+   struct list_head discard_pend_list; /* store pending entries */
+   struct list_head discard_wait_list; /* store on-flushing entries */
wait_queue_head_t discard_wait_queue;   /* waiting queue for wake-up */
struct mutex cmd_lock;
int max_discards;   /* max. discards to be issued */
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c5f0075764bf..07dddcb0d03d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -670,7 +670,7 @@ static void __add_discard_cmd(struct f2fs_sb_info *sbi,
block_t start, block_t len)
 {
struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
-   struct list_head *cmd_list = &(dcc->discard_cmd_list);
+   struct list_head *pend_list = &(dcc->discard_pend_list);
struct discard_cmd *dc;
 
dc = f2fs_kmem_cache_alloc(discard_cmd_slab, GFP_NOFS);
@@ -684,7 +684,7 @@ static void __add_discard_cmd(struct f2fs_sb_info *sbi,
init_completion(>wait);
 
mutex_lock(>cmd_lock);
-   list_add_tail(>list, cmd_list);
+   list_add_tail(>list, pend_list);
mutex_unlock(>cmd_lock);
 }
 
@@ -736,6 +736,7 @@ static void __submit_discard_cmd(struct f2fs_sb_info *sbi,
bio->bi_end_io = f2fs_submit_discard_endio;
bio->bi_opf |= REQ_SYNC;
submit_bio(bio);
+   list_move_tail(>list, >discard_wait_list);
}
} else {
__remove_discard_cmd(sbi, dc);
@@ -782,31 +783,37 @@ static void __punch_discard_cmd(struct f2fs_sb_info *sbi,
 void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, block_t blkaddr)
 {
struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
-   struct list_head *wait_list = &(dcc->discard_cmd_list);
+   struct list_head *pend_list = &(dcc->discard_pend_list);
+   struct list_head *wait_list = &(dcc->discard_wait_list);
struct discard_cmd *dc, *tmp;
struct blk_plug plug;
 
mutex_lock(>cmd_lock);
 
-   blk_start_plug();
-
-   list_for_each_entry_safe(dc, tmp, wait_list, list) {
+   if (blkaddr == NULL_ADDR)
+   goto release_discard;
 
-   if (blkaddr == NULL_ADDR) {
-   __submit_discard_cmd(sbi, dc);
-   continue;
-   }
+   list_for_each_entry_safe(dc, tmp, pend_list, list) {
+   if (dc->lstart <= blkaddr && blkaddr < dc->lstart + dc->len)
+   __punch_discard_cmd(sbi, dc, blkaddr);
+   }
 
+   list_for_each_entry_safe(dc, tmp, wait_list, list) {
if (dc->lstart <= blkaddr && blkaddr < dc->lstart + dc->len) {
if (dc->state == D_SUBMIT)
wait_for_completion_io(>wait);
__punch_discard_cmd(sbi, dc, blkaddr);
}
}
-   blk_finish_plug();
 
+release_discard:
/* this comes from f2fs_put_super */
if (blkaddr == NULL_ADDR) {
+   blk_start_plug();
+   list_for_each_entry_safe(dc, tmp, pend_list, list)
+   __submit_discard_cmd(sbi, dc);
+   blk_finish_plug();
+
list_for_each_entry_safe(dc, tmp, wait_list, list) {
wait_for_completion_io(>wait);
__remove_discard_cmd(sbi, dc);
@@ -820,7 +827,8 @@ static int issue_discard_thread(void *data)
struct f2fs_sb_info *sbi = data;
struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
wait_queue_head_t *q = >discard_wait_queue;
-   struct list_head *cmd_list = >discard_cmd_list;
+   struct list_head *pend_list = >discard_pend_list;
+   struct list_head *wait_list = >discard_wait_list;
struct discard_cmd *dc, *tmp;
struct blk_plug plug;
int iter = 0;
@@ -831,13 +839,17 @@ static int issue_discard_thread(void *data)
blk_start_plug();
 
mutex_lock(>cmd_lock);
-   

Re: [PATCH] HID: asus: support backlight on USB keyboards

2017-04-05 Thread Carlo Caione
On Wed, Apr 5, 2017 at 11:41 AM, Benjamin Tissoires
 wrote:
> Hi Carlo,

[cut]
>> With this patch we create the usual 'asus::kbd_backlight' sysfs entry
>
> Please change 'sysfs' with 'led class' or this will mislead people into
> understanding that you are adding a custom sysfs entry.

Agree

[cut]
>> +static int asus_init_kbd(struct hid_device *hdev)
>> +{
>> + int ret;
>> + const unsigned char buf[] = { FEATURE_KBD_REPORT_ID, 0x41, 0x53, 0x55,
>> +   0x53, 0x20, 0x54, 0x65, 0x63, 0x68, 0x2e,
>> +   0x49, 0x6e, 0x63, 0x2e, 0x00 };
>
> Do you have any hints in what this magical blob is?

Not for the init and the level control commands. I have some hints
about the configuration command.

>> + unsigned char *dmabuf = kmemdup(buf, sizeof(buf), GFP_KERNEL);
>> +
>> + if (!dmabuf) {
>> + ret = -ENOMEM;
>> + hid_err(hdev, "Asus failed to alloc dma buf: %d\n", ret);
>
> No need to have an error if kzalloc fails. There will already one to be
> shout by kzalloc. Please remove all of those errors after
> kzalloc/kmemdup.
>> + return ret;
>
> just return -ENOMEM.

Ok

[cut]
>> + readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
>
> That's a lot of kzalloc/kmemdup/kfree. I wonder if you couldn't just
> prepare some buffers in asus_register_kbd_leds() and just reuse them.

I'll try this.

[cut]
>> +static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>> +enum led_brightness brightness)
>> +{
>> + struct asus_kbd_leds *led = container_of(led_cdev, struct 
>> asus_kbd_leds,
>> +  cdev);
>> + led->brightness = brightness;
>> + schedule_work(>work);
>
> If a worker is already happening, aren't we losing the last brightness
> setting?

Uhm, I don't see how. The brightness setting is used in
asus_kbd_backlight_work() and this is scheduled only here.
Am I missing anything?

> When unplugging the device, you should also make sure nobody queued an
> event and that you are not allowing anybody to schedule a new work (by
> unregistering the led class interface first or adding a guard.

Good point.

[cut]
>> + drvdata->kbd_backlight = kzalloc(sizeof(struct asus_kbd_leds),
>> +  GFP_KERNEL);
>
> Unless I am mistaken, I do not see the matching kfree.
> Also note that the rest of the driver uses devres (devm_* functions) so
> for data that's allocated and which needs to stay during the entire life
> of the device, please use the devm API.

Yeah, I'll do. Thanks for noticing this.

[cut]
>> + ret = led_classdev_register(>dev, >kbd_backlight->cdev);
>
> I do not see the matching led_classdev_unregister() call too. Note that
> there is also a devm_led_classdev_register() which might help you.

Ouch.

[cut]
>> + if (drvdata->enable_backlight) {
>> + if (asus_init_kbd(hdev))
>> + return 0;
>
> Returning success here (and in the other statements below) seems wrong.

The rationale here is that if anything goes wrong with backlight
initialization it's just ok to continue, not big deal.
We have already printed the error messages so the user is already
aware, but failing here because the keyboard light is broken seems
unnecessary.

>> +
>> + ret = asus_get_kbd_functions(hdev, _func);
>> + if (ret)
>> + return 0;
>
> I do not fully understand why you need to poll the keyboard for the
> functionality if you have a quirk for it. If it's mandatory to have
> functional backlight that's OK, but otherwise it does seem like waiting
> time.

The problem here is that not all the ASUS keyboard with that PID:VID
have the leds. So for such keyboard we would create a useless (and
probably confusing) sysfs entry for a non-existent backlight.
Otherwise we could do the opposite if you agree: delete the QUIRK and
just using this test to decide whether to create the led class or not.

>> +
>> + if (kbd_func & SUPPORT_BKD_BACKLIGHT)
>> + asus_register_kbd_leds(hdev);
>
> Don't you need to check for the return value here?

As written before, I guess if we fail to register the leds it's just
ok to continue (given that we already printed the error message).

Cheers,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Ingo Molnar

* Ard Biesheuvel  wrote:

> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz
>  wrote:
> >
> > Hi,
> >
> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
> >> Hello all,
> >>
> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
> >>
> >> The following changes since commit 
> >> 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
> >>
> >>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
> >>
> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
> >>
> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer 
> >> (2017-04-04 15:56:43 +0100)
> >>
> >> 
> >> Two fixes related to the EFI framebuffer driver:
> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
> >>   BLT-only -- the framebuffer base address is invalid in this case, and the
> >>   Blt() method is not accessible to the kernel.
> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
> >>   device that has memory decoding enabled, claim the memory resource so 
> >> that
> >>   the PCI core will not attempt to move it later on.
> >>
> >> 
> >> Ard Biesheuvel (1):
> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer
> >
> > This patch breaks build if PCI support is not enabled:
> >
> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
> > ‘pci_claim_resource’ [-Werror=implicit-function-declaration]
> >
> > (x86 ifdefs are not enough, the patch should also check for PCI support)
> >
> > Also please cc: linux-fbdev mailing list & me on fbdev related patches.
> >
> 
> Thanks for the report. The patch was tested successfully on an
> impressive list of configurations by kbuild test robot, but
> apparently, none of those has PCI disabled.
> 
> Ingo, since you have queued this already, how would you like to
> proceed? I don't think we need anything beyond
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 758960b6aec9..b827a8113e26 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = {
> 
>  builtin_platform_driver(efifb_driver);
> 
> -#ifndef CONFIG_X86
> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86)

I've rebased it all, it's still pretty fresh (two hours old) and the delta fix 
would look pretty ugly in the urgent branch.

Thanks,

Ingo


Re: [PATCH 3/3] f2fs: prevent waiter encountering incorrect discard states

2017-04-05 Thread Chao Yu
On 2017/4/4 1:40, Jaegeuk Kim wrote:
> On 04/01, Chao Yu wrote:
>> Ping,
>>
>> Any problem here?
>>
>> Thanks,
>>
>> On 2017/3/28 9:17, Chao Yu wrote:
>>> On 2017/3/28 7:56, Jaegeuk Kim wrote:
 On 03/27, Chao Yu wrote:
> In f2fs_submit_discard_endio, we will wake up waiter before setting
> discard command states, so waiter may use incorrect states. Change
> the order between complete() and states setting to fix this issue.
>
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/segment.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 57a81f9c8c14..9f9542c9fe47 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -717,9 +717,9 @@ static void f2fs_submit_discard_endio(struct bio *bio)
>  {
>   struct discard_cmd *dc = (struct discard_cmd *)bio->bi_private;
>  
> - complete(>wait);
>   dc->error = bio->bi_error;
>   dc->state = D_DONE;
> + complete(>wait);

 If we set D_DONE first, the object can be released by 
 __remove_discard_cmd()?
> 
> What I mean was about use-after-free.

I updated the patch, could you help to review it?

Thanks,

> 
> Thanks,
> 
>>>
>>> Yes, I think so.
>>>
>>> Thanks,
>>>

 Thanks,

>   bio_put(bio);
>  }
>  
> -- 
> 2.8.2.295.g3f1c1d0

 .

> 
> .
> 



Re: [PATCH] iTCO_wdt: all versions count down twice

2017-04-05 Thread Andy Shevchenko
On Wed, Apr 5, 2017 at 12:03 PM, Paolo Bonzini  wrote:
> The ICH9 is listed as having TCO v2, and indeed the behavior in the
> datasheet corresponds to v2 (for example the NO_REBOOT flag is
> accessible via the 16KiB-aligned Root Complex Base Address).
>
> However, the TCO counts twice just like in v1; the documentation
> of the SECOND_TO_STS bit says: "ICH9 sets this bit to 1 to indicate
> that the TIMEOUT bit had been (or is currently) set and a second
> timeout occurred before the TCO_RLD register was written. If this
> bit is set and the NO_REBOOT config bit is 0, then the ICH9 will
> reboot the system after the second timeout.  The same can be found
> in the BayTrail (Atom E3800) datasheet, and even HOWTOs around
> the Internet say that it will reboot after _twice_ the specified
> heartbeat.
>
> I did not find the Apollo Lake datasheet, but because v4/v5 has
> a SECOND_TO_STS bit just like the previous version I'm enabling
> this for Apollo Lake as well.

Regarding to last proposed changes Apollo Lake has some register offset issue.
Nevertheless, this patch AFAIU still applies.

One nit below.
Reviewed-by: Andy Shevchenko 

>
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Paolo Bonzini 
> ---
>  Documentation/watchdog/watchdog-parameters.txt |  2 +-
>  drivers/watchdog/iTCO_wdt.c| 23 ++-
>  2 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 4f7d86dd0a5d..914518aeb972 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -117,7 +117,7 @@ nowayout: Watchdog cannot be stopped once started
>  -
>  iTCO_wdt:
>  heartbeat: Watchdog heartbeat in seconds.
> -   (2 +   (5<=heartbeat<=74 (TCO v1) or 1226 (TCO v2), default=30)
>  nowayout: Watchdog cannot be stopped once started
> (default=kernel config parameter)
>  -
> diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
> index 3d0abc0d59b4..c9230a0cdc83 100644
> --- a/drivers/watchdog/iTCO_wdt.c
> +++ b/drivers/watchdog/iTCO_wdt.c
> @@ -280,16 +280,15 @@ static int iTCO_wdt_ping(struct watchdog_device *wd_dev)
>
> iTCO_vendor_pre_keepalive(p->smi_res, wd_dev->timeout);
>
> +   /* Reset the timeout status bit so that the timer
> +* needs to count down twice again before rebooting */
> +   outw(0x0008, TCO1_STS(p));  /* write 1 to clear bit */
> +
> /* Reload the timer by writing to the TCO Timer Counter register */
> -   if (p->iTCO_version >= 2) {
> +   if (p->iTCO_version >= 2)
> outw(0x01, TCO_RLD(p));
> -   } else if (p->iTCO_version == 1) {
> -   /* Reset the timeout status bit so that the timer
> -* needs to count down twice again before rebooting */
> -   outw(0x0008, TCO1_STS(p));  /* write 1 to clear bit */
> -
> +   else if (p->iTCO_version == 1)
> outb(0x01, TCO_RLD(p));
> -   }
>
> spin_unlock(>io_lock);
> return 0;
> @@ -302,11 +301,8 @@ static int iTCO_wdt_set_timeout(struct watchdog_device 
> *wd_dev, unsigned int t)
> unsigned char val8;
> unsigned int tmrval;
>
> -   tmrval = seconds_to_ticks(p, t);
> -
> -   /* For TCO v1 the timer counts down twice before rebooting */
> -   if (p->iTCO_version == 1)
> -   tmrval /= 2;
> +   /* The timer counts down twice before rebooting */
> +   tmrval = seconds_to_ticks(p, t) / 2;
>
> /* from the specs: */
> /* "Values of 0h-3h are ignored and should not be attempted" */
> @@ -359,8 +355,9 @@ static unsigned int iTCO_wdt_get_timeleft(struct 
> watchdog_device *wd_dev)
> spin_lock(>io_lock);
> val16 = inw(TCO_RLD(p));
> val16 &= 0x3ff;
> +   if (!(inw(TCO1_STS(p)) & 0x0008))
> +   val16 += (inw(TCOv2_TMR(p)) & 0x3ff);

> spin_unlock(>io_lock);
> -
> time_left = ticks_to_seconds(p, val16);

This change does not belong to the patch.

> } else if (p->iTCO_version == 1) {
> spin_lock(>io_lock);
> --
> 2.9.3
>



-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

2017-04-05 Thread Andrey Ryabinin
On 04/04/2017 12:41 PM, Michal Hocko wrote:
> On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote:
>> From: Andrey Ryabinin 
>> Subject: mm/vmalloc: allow to call vfree() in atomic context fix
>>
>> Don't spawn worker if we already purging.
>>
>> Signed-off-by: Andrey Ryabinin 
> 
> I would rather put this into a separate patch. Ideally with some numners
> as this is an optimization...
> 

It's quite simple optimization and don't think that this deserves to be a 
separate patch.

But I did some measurements though. With enabled VMAP_STACK=y and 
NR_CACHED_STACK changed to 0
running fork() 10 times gives this:

With optimization:

~ # grep try_purge /proc/kallsyms 
811d0dd0 t try_purge_vmap_area_lazy
~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function 
== 0x811d0dd0' ./fork

 Performance counter stats for 'system wide' (10 runs):

15  workqueue:workqueue_queue_work  
   ( +-  0.88% )

   1.615368474 seconds time elapsed 
 ( +-  0.41% )


Without optimization:
~ # grep try_purge /proc/kallsyms 
811d0dd0 t try_purge_vmap_area_lazy
~ # perf stat --repeat 10 -ae workqueue:workqueue_queue_work --filter 'function 
== 0x811d0dd0' ./fork

 Performance counter stats for 'system wide' (10 runs):

30  workqueue:workqueue_queue_work  
   ( +-  1.31% )

   1.613231060 seconds time elapsed 
 ( +-  0.38% )


So there is no measurable difference on the test itself, but we queue twice 
more jobs without this optimization.
It should decrease load of kworkers.



>> ---
>>  mm/vmalloc.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index ea1b4ab..88168b8 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -737,7 +737,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>>  /* After this point, we may free va at any time */
>>  llist_add(>purge_list, _purge_list);
>>  
>> -if (unlikely(nr_lazy > lazy_max_pages()))
>> +if (unlikely(nr_lazy > lazy_max_pages()) &&
>> +!mutex_is_locked(_purge_lock))
>>  schedule_work(_vmap_work);
>>  }
>>  
>> -- 
>> 2.10.2
>>
> 


Re: [PATCH 16/16] drivers, net, intersil: convert request_context.refcount from atomic_t to refcount_t

2017-04-05 Thread Kalle Valo
"Reshetova, Elena"  writes:

>> Elena Reshetova  writes:
>> 
>> > refcount_t type and corresponding API should be
>> > used instead of atomic_t when the variable is used as
>> > a reference counter. This allows to avoid accidental
>> > refcounter overflows that might lead to use-after-free
>> > situations.
>> >
>> > Signed-off-by: Elena Reshetova 
>> > Signed-off-by: Hans Liljestrand 
>> > Signed-off-by: Kees Cook 
>> > Signed-off-by: David Windsor 
>> > ---
>> >  drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 15 ---
>> >  1 file changed, 8 insertions(+), 7 deletions(-)
>> 
>> The prefix should be "orinoco_usb:", I'll fix that.
>
> Thanks for both! Will you take the patches in?

You mean patches 15 and 16? I didn't even look rest of the patches.

But not sure yet because Dave doesn't seem to like the interface and I
want to follow the discussion first.

-- 
Kalle Valo


Re: [PATCH] padata: avoid race in reordering

2017-04-05 Thread Herbert Xu
On Tue, Apr 04, 2017 at 08:26:12PM +0200, Greg KH wrote:
> Any clue as to what the git commit id is?

It's

https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?h=linus=de5540d088fe97ad583cc7d396586437b32149a5


Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: linux-next: manual merge of the crypto tree with the amlogic tree

2017-04-05 Thread Herbert Xu
On Wed, Apr 05, 2017 at 10:21:38AM +1000, Stephen Rothwell wrote:
> Hi Herbert,
> 
> Today's linux-next merge of the crypto tree got a conflict in:
> 
>   arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> 
> between commit:
> 
>   6939db7e0dbf ("ARM64: dts: meson-gx: Add support for HDMI output")
> 
> from the amlogic tree and commit:
> 
>   1b3f6d148692 ("ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node")
> 
> from the crypto tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good to me.  Thanks Stephen.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  e69176d68d26d63d9214797c191ce65358ea1ecf
Gitweb: http://git.kernel.org/tip/e69176d68d26d63d9214797c191ce65358ea1ecf
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:09:10 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:29 +0200

ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

Update the allocation logic for the virtual mapping of the UEFI runtime
services to start from a randomized base address if KASLR is in effect,
and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.

This makes it more difficult to predict the location of exploitable
data structures in the runtime UEFI firmware, which increases robustness
against attacks. Note that these regions are only mapped during the
time a runtime service call is in progress, and only on a single CPU
at a time, bit given the lack of a downside, let's enable it nonetheless.

Signed-off-by: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@redhat.com
Cc: bhsha...@redhat.com
Cc: eug...@hp.com
Cc: evgeny.kalu...@intel.com
Cc: jh...@codeaurora.org
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: mark.rutl...@arm.com
Cc: roy.fr...@cavium.com
Cc: rruig...@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/arm-stub.c | 49 -
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 657bb72..1e45ec5 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,6 +18,22 @@
 
 #include "efistub.h"
 
+/*
+ * This is the base address at which to start allocating virtual memory ranges
+ * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
+ * any allocation we choose, and eliminate the risk of a conflict after kexec.
+ * The value chosen is the largest non-zero power of 2 suitable for this 
purpose
+ * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
+ * be mapped efficiently.
+ * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
+ * map everything below 1 GB. (512 MB is a reasonable upper bound for the
+ * entire footprint of the UEFI runtime services memory regions)
+ */
+#define EFI_RT_VIRTUAL_BASESZ_512M
+#define EFI_RT_VIRTUAL_SIZESZ_512M
+
+static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
+
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 void *__image, void **__fh)
 {
@@ -213,6 +229,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
 
efi_random_get_seed(sys_table);
 
+   if (!nokaslr()) {
+   /*
+* Randomize the base of the UEFI runtime services region.
+* Preserve the 2 MB alignment of the region by taking a
+* shift of 21 bit positions into account when scaling
+* the headroom value using a 32-bit random value.
+*/
+   u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
+  EFI_RT_VIRTUAL_SIZE;
+   u32 rnd;
+
+   status = efi_get_random_bytes(sys_table, sizeof(rnd),
+ (u8 *));
+   if (status == EFI_SUCCESS) {
+   virtmap_base = EFI_RT_VIRTUAL_BASE +
+  (((headroom >> 21) * rnd) >> (32 - 21));
+   }
+   }
+
new_fdt_addr = fdt_addr;
status = allocate_new_fdt_and_exit_boot(sys_table, handle,
_fdt_addr, efi_get_max_fdt_addr(dram_base),
@@ -242,18 +277,6 @@ fail:
return EFI_ERROR;
 }
 
-/*
- * This is the base address at which to start allocating virtual memory ranges
- * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
- * any allocation we choose, and eliminate the risk of a conflict after kexec.
- * The value chosen is the largest non-zero power of 2 suitable for this 
purpose
- * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
- * be mapped efficiently.
- * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
- * map everything below 1 GB.
- */
-#define EFI_RT_VIRTUAL_BASESZ_512M
-
 static int cmp_mem_desc(const void *l, const void *r)
 {
const efi_memory_desc_t *left = l, *right = r;
@@ -303,7 +326,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, 
unsigned long map_size,
 unsigned long desc_size, efi_memory_desc_t 

[tip:efi/core] efi/arm32-stub: Allow boot-time allocations in the vmlinux region

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  318532bf63cfab779d763527d8b93e48c4a96dba
Gitweb: http://git.kernel.org/tip/318532bf63cfab779d763527d8b93e48c4a96dba
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:02:44 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:26 +0200

efi/arm32-stub: Allow boot-time allocations in the vmlinux region

The arm32 kernel decompresses itself to the base of DRAM unconditionally,
and so it is the EFI stub's job to ensure that the region is available.

Currently, we do this by creating an allocation there, and giving up if
that fails. However, any boot services regions occupying this area are
not an issue, given that the decompressor executes strictly after the
stub calls ExitBootServices().

So let's try a bit harder to proceed if the initial allocation fails,
and check whether any memory map entries occupying the region may be
considered safe.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Eugene Cohen 
Reviewed-by: Roy Franz 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170404160245.27812-11-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/arm32-stub.c | 148 ++
 1 file changed, 128 insertions(+), 20 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
b/drivers/firmware/efi/libstub/arm32-stub.c
index e1f0b28..18a8b5e 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -63,6 +63,132 @@ void free_screen_info(efi_system_table_t *sys_table_arg, 
struct screen_info *si)
efi_call_early(free_pool, si);
 }
 
+static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
+   unsigned long dram_base,
+   unsigned long *reserve_addr,
+   unsigned long *reserve_size)
+{
+   efi_physical_addr_t alloc_addr;
+   efi_memory_desc_t *memory_map;
+   unsigned long nr_pages, map_size, desc_size, buff_size;
+   efi_status_t status;
+   unsigned long l;
+
+   struct efi_boot_memmap map = {
+   .map= _map,
+   .map_size   = _size,
+   .desc_size  = _size,
+   .desc_ver   = NULL,
+   .key_ptr= NULL,
+   .buff_size  = _size,
+   };
+
+   /*
+* Reserve memory for the uncompressed kernel image. This is
+* all that prevents any future allocations from conflicting
+* with the kernel. Since we can't tell from the compressed
+* image how much DRAM the kernel actually uses (due to BSS
+* size uncertainty) we allocate the maximum possible size.
+* Do this very early, as prints can cause memory allocations
+* that may conflict with this.
+*/
+   alloc_addr = dram_base + MAX_UNCOMP_KERNEL_SIZE;
+   nr_pages = MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE;
+   status = efi_call_early(allocate_pages, EFI_ALLOCATE_MAX_ADDRESS,
+   EFI_BOOT_SERVICES_DATA, nr_pages, _addr);
+   if (status == EFI_SUCCESS) {
+   if (alloc_addr == dram_base) {
+   *reserve_addr = alloc_addr;
+   *reserve_size = MAX_UNCOMP_KERNEL_SIZE;
+   return EFI_SUCCESS;
+   }
+   /*
+* If we end up here, the allocation succeeded but starts below
+* dram_base. This can only occur if the real base of DRAM is
+* not a multiple of 128 MB, in which case dram_base will have
+* been rounded up. Since this implies that a part of the region
+* was already occupied, we need to fall through to the code
+* below to ensure that the existing allocations don't conflict.
+* For this reason, we use EFI_BOOT_SERVICES_DATA above and not
+* EFI_LOADER_DATA, which we wouldn't able to distinguish from
+* allocations that we want to disallow.
+*/
+   }
+
+   /*
+* If the allocation above failed, we may still be able to proceed:
+* if the only allocations in the region are of types that will be
+* released to the OS after ExitBootServices(), the decompressor can
+* safely overwrite them.
+*/
+   status = efi_get_memory_map(sys_table_arg, );
+   if (status != EFI_SUCCESS) {
+   pr_efi_err(sys_table_arg,
+  "reserve_kernel_base(): Unable to retrieve memory 

Re: [RFC PATCH 1/6] x86/apic: Replace init_bsp_APIC() with apic_virture_wire_mode_setup()

2017-04-05 Thread Thomas Gleixner
On Wed, 29 Mar 2017, Dou Liyang wrote:

> The init_bsp_APIC() setups the virtual wire mode through the local
> APIC.
> 
> The function name is unsuitable which might imply that the BSP's
> APIC will be initialized here, actually, where it will be done is
> almost at the end of start_kernel(). And the CONFIG X86_64 is also
> imply the X86_LOCAL_APIC is y.

Correct, but X86_32 can have X86_LOCAL_APIC=n. And by removing the ifdefs
you break that.

>  /*
> - * An initial setup of the virtual wire mode.
> + * Setup the through-local-APIC virtual wire mode.
>   */
> -void __init init_bsp_APIC(void)
> +void apic_virture_wire_mode_setup(void)

s/virture/virtual/ ?

Why is this function not longer marked __init ?

Thanks,

tglx


Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Bartlomiej Zolnierkiewicz
On Wednesday, April 05, 2017 11:14:06 AM Ard Biesheuvel wrote:
> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz
>  wrote:
> >
> > Hi,
> >
> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
> >> Hello all,
> >>
> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
> >>
> >> The following changes since commit 
> >> 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
> >>
> >>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
> >>
> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
> >>
> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer 
> >> (2017-04-04 15:56:43 +0100)
> >>
> >> 
> >> Two fixes related to the EFI framebuffer driver:
> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
> >>   BLT-only -- the framebuffer base address is invalid in this case, and the
> >>   Blt() method is not accessible to the kernel.
> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
> >>   device that has memory decoding enabled, claim the memory resource so 
> >> that
> >>   the PCI core will not attempt to move it later on.
> >>
> >> 
> >> Ard Biesheuvel (1):
> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer
> >
> > This patch breaks build if PCI support is not enabled:
> >
> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
> > ‘pci_claim_resource’ [-Werror=implicit-function-declaration]
> >
> > (x86 ifdefs are not enough, the patch should also check for PCI support)
> >
> > Also please cc: linux-fbdev mailing list & me on fbdev related patches.
> >
> 
> Thanks for the report. The patch was tested successfully on an
> impressive list of configurations by kbuild test robot, but
> apparently, none of those has PCI disabled.

Well, it has been found by looking at the patch itself and since
none of defconfigs contains such configuration currently the issue
is rather minor one.

[ Also sorry for the late report but this is the first time I see
  these patches.  They were never posted to linux-fbdev or me. ]

> Ingo, since you have queued this already, how would you like to
> proceed? I don't think we need anything beyond

I see that Ingo fixed the patch himself so it is all fine now,
thanks!

> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 758960b6aec9..b827a8113e26 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = {
> 
>  builtin_platform_driver(efifb_driver);
> 
> -#ifndef CONFIG_X86
> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
> 
>  static bool pci_bar_found; /* did we find a BAR matching the efifb base? 
> */

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics



Re: [GIT PULL 0/2] EFI fixes for v4.11

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 11:44, Bartlomiej Zolnierkiewicz
 wrote:
> On Wednesday, April 05, 2017 11:14:06 AM Ard Biesheuvel wrote:
>> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz
>>  wrote:
>> >
>> > Hi,
>> >
>> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote:
>> >> Hello all,
>> >>
>> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems.
>> >>
>> >> The following changes since commit 
>> >> 822f5845f710e57d7e2df1fd1ee00d6e19d334fe:
>> >>
>> >>   efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 
>> >> +)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git 
>> >> tags/efi-urgent
>> >>
>> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e:
>> >>
>> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer 
>> >> (2017-04-04 15:56:43 +0100)
>> >>
>> >> 
>> >> Two fixes related to the EFI framebuffer driver:
>> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as
>> >>   BLT-only -- the framebuffer base address is invalid in this case, and 
>> >> the
>> >>   Blt() method is not accessible to the kernel.
>> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI
>> >>   device that has memory decoding enabled, claim the memory resource so 
>> >> that
>> >>   the PCI core will not attempt to move it later on.
>> >>
>> >> 
>> >> Ard Biesheuvel (1):
>> >>   efifb: Avoid reconfiguration of BAR that covers the framebuffer
>> >
>> > This patch breaks build if PCI support is not enabled:
>> >
>> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’:
>> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function 
>> > ‘pci_claim_resource’ [-Werror=implicit-function-declaration]
>> >
>> > (x86 ifdefs are not enough, the patch should also check for PCI support)
>> >
>> > Also please cc: linux-fbdev mailing list & me on fbdev related patches.
>> >
>>
>> Thanks for the report. The patch was tested successfully on an
>> impressive list of configurations by kbuild test robot, but
>> apparently, none of those has PCI disabled.
>
> Well, it has been found by looking at the patch itself and since
> none of defconfigs contains such configuration currently the issue
> is rather minor one.
>
> [ Also sorry for the late report but this is the first time I see
>   these patches.  They were never posted to linux-fbdev or me. ]
>

Apologies for that. I did cc Peter but no other fbdev maintainers.

>> Ingo, since you have queued this already, how would you like to
>> proceed? I don't think we need anything beyond
>
> I see that Ingo fixed the patch himself so it is all fine now,
> thanks!
>
>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>> index 758960b6aec9..b827a8113e26 100644
>> --- a/drivers/video/fbdev/efifb.c
>> +++ b/drivers/video/fbdev/efifb.c
>> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = {
>>
>>  builtin_platform_driver(efifb_driver);
>>
>> -#ifndef CONFIG_X86
>> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
>>
>>  static bool pci_bar_found; /* did we find a BAR matching the efifb 
>> base? */
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>


[tip:efi/core] efi/libstub: Unify command line param parsing

2017-04-05 Thread tip-bot for Ard Biesheuvel
Commit-ID:  60f38de7a8d4e816100ceafd1b382df52527bd50
Gitweb: http://git.kernel.org/tip/60f38de7a8d4e816100ceafd1b382df52527bd50
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 17:09:08 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 12:27:28 +0200

efi/libstub: Unify command line param parsing

Merge the parsing of the command line carried out in arm-stub.c with
the handling in efi_parse_options(). Note that this also fixes the
missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin
command line should supersede the one passed by the firmware.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@redhat.com
Cc: bhsha...@redhat.com
Cc: b...@alien8.de
Cc: eug...@hp.com
Cc: evgeny.kalu...@intel.com
Cc: jh...@codeaurora.org
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: mark.rutl...@arm.com
Cc: roy.fr...@cavium.com
Cc: rruig...@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/arm-stub.c| 24 +++-
 drivers/firmware/efi/libstub/arm64-stub.c  |  4 +---
 drivers/firmware/efi/libstub/efi-stub-helper.c | 19 +++
 drivers/firmware/efi/libstub/efistub.h |  2 ++
 include/linux/efi.h|  2 +-
 5 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 02049ff..ac3222f 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,8 +18,6 @@
 
 #include "efistub.h"
 
-bool __nokaslr;
-
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 void *__image, void **__fh)
 {
@@ -153,18 +151,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
goto fail;
}
 
-   /* check whether 'nokaslr' was passed on the command line */
-   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-   static const u8 default_cmdline[] = CONFIG_CMDLINE;
-   const u8 *str, *cmdline = cmdline_ptr;
-
-   if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
-   cmdline = default_cmdline;
-   str = strstr(cmdline, "nokaslr");
-   if (str == cmdline || (str > cmdline && *(str - 1) == ' '))
-   __nokaslr = true;
-   }
-
si = setup_graphics(sys_table);
 
status = handle_kernel_image(sys_table, image_addr, _size,
@@ -176,9 +162,13 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
goto fail_free_cmdline;
}
 
-   status = efi_parse_options(cmdline_ptr);
-   if (status != EFI_SUCCESS)
-   pr_efi_err(sys_table, "Failed to parse EFI cmdline options\n");
+   if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+   IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+   cmdline_size == 0)
+   efi_parse_options(CONFIG_CMDLINE);
+
+   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
+   efi_parse_options(cmdline_ptr);
 
secure_boot = efi_get_secureboot(sys_table);
 
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c 
b/drivers/firmware/efi/libstub/arm64-stub.c
index eae693e..b4c2589 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -16,8 +16,6 @@
 
 #include "efistub.h"
 
-extern bool __nokaslr;
-
 efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
 {
u64 tg;
@@ -52,7 +50,7 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table_arg,
u64 phys_seed = 0;
 
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-   if (!__nokaslr) {
+   if (!nokaslr()) {
status = efi_get_random_bytes(sys_table_arg,
  sizeof(phys_seed),
  (u8 *)_seed);
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 3290fae..2e17d2b 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -32,6 +32,13 @@
 
 static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
+static int __section(.data) __nokaslr;
+
+int __pure nokaslr(void)
+{
+   return __nokaslr;
+}
+
 #define EFI_MMAP_NR_SLACK_SLOTS8
 
 struct file_info {
@@ -409,17 +416,13 @@ static efi_status_t efi_file_close(void *handle)
  * environments, first in the early boot environment of the EFI boot
  * stub, and subsequently during the kernel boot.
  */

Re: [PATCH] phy: bcm-ns-usb3: split all writes into reg & val pairs

2017-04-05 Thread Rafał Miłecki

On 04/05/2017 12:10 PM, Kishon Vijay Abraham I wrote:

On Sunday 02 April 2017 10:25 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

So far all the PHY initialization was implemented using some totally
magic values. There was some pattern there but it wasn't clear what is
it about.

Thanks to the patch submitted by Broadcom:
[PATCH 5/6] phy: Add USB3 PHY support for Broadcom NSP SoC
and the upstream "iproc-mdio" driver we now know there is a MDIO bus
underneath with PHY(s) and their registers.

It allows us to clean the driver a bit by making all these values less
magical. The next step is switching to using a proper MDIO layer.

Signed-off-by: Rafał Miłecki 
---
 drivers/phy/phy-bcm-ns-usb3.c | 69 ++-
 1 file changed, 49 insertions(+), 20 deletions(-)

diff --git a/drivers/phy/phy-bcm-ns-usb3.c b/drivers/phy/phy-bcm-ns-usb3.c
index f420fa4bebfc..22b5e7047fa6 100644
--- a/drivers/phy/phy-bcm-ns-usb3.c
+++ b/drivers/phy/phy-bcm-ns-usb3.c
@@ -2,6 +2,7 @@
  * Broadcom Northstar USB 3.0 PHY Driver
  *
  * Copyright (C) 2016 Rafał Miłecki 
+ * Copyright (C) 2016 Broadcom
  *
  * All magic values used for initialization (and related comments) were 
obtained
  * from Broadcom's SDK:
@@ -23,6 +24,23 @@

 #define BCM_NS_USB3_MII_MNG_TIMEOUT_US 1000/* usecs */

+#define BCM_NS_USB3_PHY_BASE_ADDR_REG  0x1f
+#define BCM_NS_USB3_PHY_PLL30_BLOCK0x8000
+#define BCM_NS_USB3_PHY_TX_PMD_BLOCK   0x8040
+#define BCM_NS_USB3_PHY_PIPE_BLOCK 0x8060
+
+/* Registers of PLL30 block */
+#define BCM_NS_USB3_PLL_CONTROL0x01
+#define BCM_NS_USB3_PLLA_CONTROL0  0x0a
+#define BCM_NS_USB3_PLLA_CONTROL1  0x0b
+
+/* Registers of TX PMD block */
+#define BCM_NS_USB3_TX_PMD_CONTROL10x01
+
+/* Registers of PIPE block */
+#define BCM_NS_USB3_LFPS_CMP   0x02
+#define BCM_NS_USB3_LFPS_DEGLITCH  0x03
+
 enum bcm_ns_family {
BCM_NS_UNKNOWN,
BCM_NS_AX,
@@ -76,8 +94,10 @@ static inline int bcm_ns_usb3_mii_mng_wait_idle(struct 
bcm_ns_usb3 *usb3)

usecs_to_jiffies(BCM_NS_USB3_MII_MNG_TIMEOUT_US));
 }

-static int bcm_ns_usb3_mii_mng_write32(struct bcm_ns_usb3 *usb3, u32 value)
+static int bcm_ns_usb3_mdio_phy_write(struct bcm_ns_usb3 *usb3, u16 reg,
+ u16 value)
 {
+   u32 tmp = 0;
int err;

err = bcm_ns_usb3_mii_mng_wait_idle(usb3);
@@ -86,7 +106,11 @@ static int bcm_ns_usb3_mii_mng_write32(struct bcm_ns_usb3 
*usb3, u32 value)
return err;
}

-   writel(value, usb3->ccb_mii + BCMA_CCB_MII_MNG_CMD_DATA);
+   /* TODO: Use a proper MDIO bus layer */


Instead of using this intermediate patch, can we directly convert this to
mdio_driver or you see issues with converting it?


This is a bit more complex task with some possible issues to consider:
1) Backward compatibility - should we still support old DTB files?
2) Support for PHY DT node put in MDIO bus node - it requires reg = ; which is 
in conflict with current "reg" usage
3) Support for different reset reg - Northstar+ uses a different one - we'll 
probably need a syscon
4) My limited time (sadly)

The good point of this patch is that all changes made in:
bcm_ns_usb3_phy_init_ns_ax
bcm_ns_usb3_phy_init_ns_bx
will survive, so we're not going to change all the code back and forth.

If that's acceptable for you, I'd prefer to handle this with smaller patches.


Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

2017-04-05 Thread Andy Shevchenko
On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley  wrote:
> From: Jeremy Kerr 
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.

I would go with vUART abbreviation, but it's up to you.

>
> The VUART is two UART 'front ends' connected by their FIFO (no actual
> serial line in between). One is on the BMC side (management controller)
> and one is on the host CPU side.
>
> This driver is for the BMC side. The sysfs files allow the BMC
> userspace, which owns the system configuration policy, to specify at
> what IO port and interrupt number the host side will appear to the host
> on the Host <-> BMC LPC bus. It could be different on a different system
> (though most of them use 3f8/4).
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.

>  - Move to 8250 directory
>  - Rename ast -> aspeed to match other Aspeed drivers

>  drivers/tty/serial/8250/aspeed-vuart.c | 341 
> +

There is a pattern 8250_x[_y].c
So, I would go with 8250_aspeed_virt.c or 8250_aspeed_vuart.c or alike.

> +config SERIAL_8250_ASPEED_VUART
> +   tristate "Aspeed Virtual UART"
> +   depends on SERIAL_8250
> +   depends on OF

> + *  2 of the License, or (at your option) any later version.

> + *

Redundant line.

> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

> +static void aspeed_vuart_set_host_tx_discard(struct aspeed_vuart *vuart,
> +bool discard)
> +{
> +   u8 reg;
> +
> +   reg = readb(vuart->regs + ASPEED_VUART_GCRA);
> +

> +   /* if the HOST_TX_DISCARD bit is set, discard is *disabled* */

Perhaps "disabled" for better readability?

> +   reg &= ~ASPEED_VUART_GCRA_HOST_TX_DISCARD;
> +   if (!discard)
> +   reg |= ASPEED_VUART_GCRA_HOST_TX_DISCARD;
> +
> +   writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}

> +static int aspeed_vuart_probe(struct platform_device *pdev)
> +{
> +   struct uart_8250_port port;

> +   struct resource *res;
> +   struct aspeed_vuart *vuart;
> +   struct device_node *np;

Longest line upper.

> +   u32 clk, prop;
> +   int rc;
> +
> +   np = pdev->dev.of_node;
> +
> +   vuart = devm_kzalloc(>dev, sizeof(*vuart), GFP_KERNEL);
> +   if (!vuart)
> +   return -ENOMEM;
> +
> +   vuart->dev = >dev;
> +

> +   /* The 8510 core creates the mapping, which we grab a reference to
> +* for VUART-specific registers */

/*
 * Multi-line comments.
 * Look like this.
 */

> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   vuart->regs = devm_ioremap_resource(>dev, res);
> +   if (IS_ERR(vuart->regs))
> +   return PTR_ERR(vuart->regs);
> +
> +   memset(, 0, sizeof(port));
> +   port.port.private_data = vuart;
> +   port.port.membase = vuart->regs;
> +   port.port.mapbase = res->start;
> +   port.port.mapsize = resource_size(res);
> +   port.port.startup = aspeed_vuart_startup;
> +   port.port.shutdown = aspeed_vuart_shutdown;
> +   port.port.dev = >dev;
> +
> +   rc = sysfs_create_group(>dev->kobj, _vuart_attr_group);
> +   if (rc < 0)
> +   return rc;
> +
> +   if (of_property_read_u32(np, "clock-frequency", )) {
> +   vuart->clk = devm_clk_get(>dev, NULL);
> +   if (IS_ERR(vuart->clk)) {
> +   dev_warn(>dev,
> +   "clk or clock-frequency not defined\n");
> +   return PTR_ERR(vuart->clk);
> +   }
> +
> +   rc = clk_prepare_enable(vuart->clk);
> +   if (rc < 0)
> +   return rc;
> +
> +   clk = clk_get_rate(vuart->clk);
> +   }
> +
> +   /* If current-speed was set, then try not to change it. */
> +   if (of_property_read_u32(np, "current-speed", ) == 0)
> +   port.port.custom_divisor = clk / (16 * prop);
> +
> +   /* Check for shifted address mapping */
> +   if (of_property_read_u32(np, "reg-offset", ) == 0)
> +   port.port.mapbase += prop;
> +
> +   /* Check for registers offset within the devices address range */
> +   if (of_property_read_u32(np, "reg-shift", ) == 0)
> +   port.port.regshift = prop;
> +
> +   /* Check for fifo size */
> +   if (of_property_read_u32(np, "fifo-size", ) == 0)
> +  

Re: [STABLE REGRESSION] iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

2017-04-05 Thread Ritesh Raj Sarraf
On Tue, 2017-04-04 at 17:44 -0700, Srinivas Pandruvada wrote:
> Hi Ritesh,
> 
> Does the attached patch helps?

Thank you Srinivas. I tested your patch on top of 4.10.8 and it is working
perfect.

Ritesh

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

signature.asc
Description: This is a digitally signed message part


[PATCH] media: mtk-vcodec: remove informative log

2017-04-05 Thread Minghsiu Tsai
Driver is stable. Remove DEBUG definition from driver.

There are debug message in /var/log/messages if DEBUG is defined,
such as:
[MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
[MTK_V4L2] level=0 fops_vcodec_open(),177: 1600.vcodec decoder [0]
[MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 7d55975..1248083 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
 extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
-#define DEBUG  1
 
 #if defined(DEBUG)
 
-- 
1.9.1



Re: [PATCH v4 0/3] phy: Group phy drivers based on vendor listing

2017-04-05 Thread Kishon Vijay Abraham I
Hi Vivek,

On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
> This is the next version to an earlier posted series [1].
> Missed Cc'ing the first patch of the previous series [1] to lkml.
> Posting out this series now after addressing comments
> and after adding the received 'Acked-by' and 'Reviewed-by'
> tags.
> 
> This series is based on linux-phy/next branch.
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
> 
> Signed-off-by: Vivek Gautam 
> Cc: Kishon Vijay Abraham I 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org

The best time to merge this would be immediately after -rc1 is tagged. Can you
resend when 4.12-rc1 is tagged?

Thanks
Kishon

> 
> --
> Vivek Gautam (3):
>   phy: qcom-usb: Remove unused ulpi phy header
>   phy: Move ULPI phy header out of drivers to include path
>   phy: Group vendor specific phy drivers
> 
>  MAINTAINERS|  18 +-
>  drivers/phy/Kconfig| 471 
> +
>  drivers/phy/Makefile   |  67 +--
>  drivers/phy/allwinner/Kconfig  |  31 ++
>  drivers/phy/allwinner/Makefile |   2 +
>  drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>  drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>  drivers/phy/broadcom/Kconfig   |  64 +++
>  drivers/phy/broadcom/Makefile  |   7 +
>  drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>  drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>  drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>  drivers/phy/hisilicon/Kconfig  |  20 +
>  drivers/phy/hisilicon/Makefile |   2 +
>  drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>  drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>  drivers/phy/marvell/Kconfig|  50 +++
>  drivers/phy/marvell/Makefile   |   6 +
>  drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>  drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>  drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>  drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>  drivers/phy/qualcomm/Kconfig   |  38 ++
>  drivers/phy/qualcomm/Makefile  |   7 +
>  drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>  drivers/phy/renesas/Kconfig|  17 +
>  drivers/phy/renesas/Makefile   |   2 +
>  drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>  drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>  drivers/phy/rockchip/Kconfig   |  51 +++
>  drivers/phy/rockchip/Makefile  |   6 +
>  drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>  .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>  drivers/phy/samsung/Kconfig|  96 +
>  drivers/phy/samsung/Makefile   |  11 +
>  drivers/phy/{ => samsung}/phy-exynos-dp-video.c|   0
>  drivers/phy/{ => samsung}/phy-exynos-mipi-video.c  |   0
>  drivers/phy/{ => samsung}/phy-exynos-pcie.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4210-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5-usbdrd.c |   0
>  drivers/phy/{ => samsung}/phy-exynos5250-sata.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5250-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-s5pv210-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.h   |   0
>  

[PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

2017-04-05 Thread michael.hennerich
From: Michael Hennerich 

This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.

Signed-off-by: Michael Hennerich 

---

Changes since v1:

 - Sort makefile entries
 - Sort driver includes
 - Use proper defines
 - Miscellaneous coding style fixups
 - Rename mux select callback
 - Revise i2c-mux-idle-disconnect handling
 - Add ENABLE GPIO handling on error and device removal.
 - Remove surplus of_match_device call.

Changes since v2:

 - Stop double error reporting (i2c_mux_add_adapter)
 - Change subject
 - Split dt bindings to separate patch

Changes since v3:

 - Change subject and add spaces
 - Convert to I2C_MUX_LOCKED
 - Convert to regmap
 - Remove local register cache
 - Restore previous ENABLE GPIO handling
 - Initially pulse ENABLE low
 - Eliminate i2c client struct in driver state structure
 - Simplify error return path
 - Misc minor cleanups
---
 MAINTAINERS |   8 +
 drivers/i2c/muxes/Kconfig   |  11 ++
 drivers/i2c/muxes/Makefile  |   1 +
 drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 
 4 files changed, 330 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S:   Maintained
 F: Documentation/hwmon/ltc4261
 F: drivers/hwmon/ltc4261.c
 
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich 
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
 LTP (Linux Test Project)
 M: Mike Frysinger 
 M: Cyril Hrubis 
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..41153b4 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,17 @@ config I2C_MUX_GPIO
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-gpio.
 
+config I2C_MUX_LTC4306
+   tristate "LTC LTC4306/5 I2C multiplexer"
+   select GPIOLIB
+   select REGMAP_I2C
+   help
+ If you say yes here you get support for the LTC LTC4306 or LTC4305
+ I2C mux/switch devices.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mux-ltc4306.
+
 config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..ff7618c 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)+= 
i2c-arb-gpio-challenge.o
 obj-$(CONFIG_I2C_DEMUX_PINCTRL)+= i2c-demux-pinctrl.o
 
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_LTC4306)  += i2c-mux-ltc4306.o
 obj-$(CONFIG_I2C_MUX_MLXCPLD)  += i2c-mux-mlxcpld.o
 obj-$(CONFIG_I2C_MUX_PCA9541)  += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c 
b/drivers/i2c/muxes/i2c-mux-ltc4306.c
new file mode 100644
index 000..7d34434
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
@@ -0,0 +1,310 @@
+/*
+ * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Based on: i2c-mux-pca954x.c
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LTC4305_MAX_NCHANS 2
+#define LTC4306_MAX_NCHANS 4
+
+#define LTC_REG_STATUS 0x0
+#define LTC_REG_CONFIG 0x1
+#define LTC_REG_MODE   0x2
+#define LTC_REG_SWITCH 0x3
+
+#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
+#define LTC_UPSTREAM_ACCL_EN   BIT(7)
+
+#define LTC_GPIO_ALL_INPUT 0xC0
+#define LTC_SWITCH_MASK0xF0
+
+enum ltc_type {
+   ltc_4305,
+   ltc_4306,
+};
+
+struct chip_desc {
+   u8 nchans;
+   u8 num_gpios;
+};
+
+struct ltc4306 {
+   struct regmap *regmap;
+   struct gpio_chip gpiochip;
+   const struct chip_desc *chip;
+};
+
+static const struct chip_desc chips[] = {
+   [ltc_4305] = {
+   .nchans = LTC4305_MAX_NCHANS,
+   },
+   [ltc_4306] = {
+   .nchans = LTC4306_MAX_NCHANS,
+   .num_gpios = 2,
+   },
+};
+
+static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+   

<    4   5   6   7   8   9   10   11   12   13   >