linux-next: manual merge of the scsi tree with the block tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the scsi tree got a conflict in:

  drivers/scsi/sd.c

between commit:

  c92e2f04b359 ("block: disk_events: introduce event flags")

from the block tree and commit:

  21e6ba3f0e02 ("scsi: sd: Rely on the driver core for asynchronous probing")
  d16ece577bf2 ("scsi: sd: Inline sd_probe_part2()")

from the scsi 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/scsi/sd.c
index ebc80354714c,e610b393809b..
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@@ -3404,8 -3374,49 +3342,50 @@@ static int sd_probe(struct device *dev
get_device(dev);
dev_set_drvdata(dev, sdkp);
  
-   get_device(>dev); /* prevent release before async_schedule */
-   async_schedule_domain(sd_probe_async, sdkp, _sd_probe_domain);
+   gd->major = sd_major((index & 0xf0) >> 4);
+   gd->first_minor = ((index & 0xf) << 4) | (index & 0xfff00);
+ 
+   gd->fops = _fops;
+   gd->private_data = >driver;
+   gd->queue = sdkp->device->request_queue;
+ 
+   /* defaults, until the device tells us otherwise */
+   sdp->sector_size = 512;
+   sdkp->capacity = 0;
+   sdkp->media_present = 1;
+   sdkp->write_prot = 0;
+   sdkp->cache_override = 0;
+   sdkp->WCE = 0;
+   sdkp->RCD = 0;
+   sdkp->ATO = 0;
+   sdkp->first_scan = 1;
+   sdkp->max_medium_access_timeouts = SD_MAX_MEDIUM_TIMEOUTS;
+ 
+   sd_revalidate_disk(gd);
+ 
+   gd->flags = GENHD_FL_EXT_DEVT;
+   if (sdp->removable) {
+   gd->flags |= GENHD_FL_REMOVABLE;
+   gd->events |= DISK_EVENT_MEDIA_CHANGE;
++  gd->event_flags = DISK_EVENT_FLAG_POLL | DISK_EVENT_FLAG_UEVENT;
+   }
+ 
+   blk_pm_runtime_init(sdp->request_queue, dev);
+   device_add_disk(dev, gd, NULL);
+   if (sdkp->capacity)
+   sd_dif_config_host(sdkp);
+ 
+   sd_revalidate_disk(gd);
+ 
+   if (sdkp->security) {
+   sdkp->opal_dev = init_opal_dev(sdp, _sec_submit);
+   if (sdkp->opal_dev)
+   sd_printk(KERN_NOTICE, sdkp, "supports TCG Opal\n");
+   }
+ 
+   sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n",
+ sdp->removable ? "removable " : "");
+   scsi_autopm_put_device(sdp);
  
return 0;
  


pgpGS5iuNnrxm.pgp
Description: OpenPGP digital signature


[PATCH v3] pinctrl:intel: Retain HOSTSW_OWN for requested gpio pin

2019-04-14 Thread Chris Chiu
The touchpad of the ASUS laptops E403NA, X540NA, X541NA are not
responsive after suspend/resume. The following error message
shows after resume.
 i2c_hid i2c-ELAN1200:00: failed to reset device.

On these laptops, the touchpad interrupt is connected via a GPIO
pin which is controlled by Intel pinctrl. After system resumes,
the GPIO is in ACPI mode and no longer works as an IRQ.

This commit saves the HOSTSW_OWN value during suspend, make sure
the HOSTSW_OWN mode remains the same after resume.

Signed-off-by: Chris Chiu 
---

Note:
v2: update hostown and show pr_info only when the host mode
change on requsted GPIO is not expected.
v3: change return type of intel_gpio_update_pad_mode() from
void to u32 and use dev_warn instead of pr_info.

 drivers/pinctrl/intel/pinctrl-intel.c | 56 ++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c 
b/drivers/pinctrl/intel/pinctrl-intel.c
index 8cda7b535b02..5337289c550b 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -81,6 +81,7 @@ struct intel_pad_context {
 
 struct intel_community_context {
u32 *intmask;
+   u32 *hostown;
 };
 
 struct intel_pinctrl_context {
@@ -1284,7 +1285,7 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl 
*pctrl)
 
for (i = 0; i < pctrl->ncommunities; i++) {
struct intel_community *community = >communities[i];
-   u32 *intmask;
+   u32 *intmask, *hostown;
 
intmask = devm_kcalloc(pctrl->dev, community->ngpps,
   sizeof(*intmask), GFP_KERNEL);
@@ -1292,6 +1293,13 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl 
*pctrl)
return -ENOMEM;
 
communities[i].intmask = intmask;
+
+   hostown = devm_kcalloc(pctrl->dev, community->ngpps,
+  sizeof(*hostown), GFP_KERNEL);
+   if (!hostown)
+   return -ENOMEM;
+
+   communities[i].hostown = hostown;
}
 
pctrl->context.pads = pads;
@@ -1503,6 +1511,10 @@ int intel_pinctrl_suspend(struct device *dev)
base = community->regs + community->ie_offset;
for (gpp = 0; gpp < community->ngpps; gpp++)
communities[i].intmask[gpp] = readl(base + gpp * 4);
+
+   base = community->regs + community->hostown_offset;
+   for (gpp = 0; gpp < community->ngpps; gpp++)
+   communities[i].hostown[gpp] = readl(base + gpp * 4);
}
 
return 0;
@@ -1529,6 +1541,29 @@ static void intel_gpio_irq_init(struct intel_pinctrl 
*pctrl)
}
 }
 
+static u32
+intel_gpio_is_requested(struct gpio_chip *chip, int base, unsigned int size)
+{
+   u32 requested = 0;
+   unsigned int i;
+
+   for (i = 0; i < size; i++)
+   if (gpiochip_is_requested(chip, base + i))
+   requested |= BIT(i);
+
+   return requested;
+}
+
+static u32
+intel_gpio_update_pad_mode(void __iomem *hostown, u32 mask, u32 value)
+{
+   u32 curr = readl(hostown);
+   u32 updated = (curr & ~mask) | (value & mask);
+
+   writel(updated, hostown);
+   return curr;
+}
+
 int intel_pinctrl_resume(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -1588,6 +1623,25 @@ int intel_pinctrl_resume(struct device *dev)
dev_dbg(dev, "restored mask %d/%u %#08x\n", i, gpp,
readl(base + gpp * 4));
}
+
+   base = community->regs + community->hostown_offset;
+   for (gpp = 0; gpp < community->ngpps; gpp++) {
+   const struct intel_padgroup *padgrp = 
>gpps[gpp];
+   u32 requested = 0, value = 0;
+   u32 saved = communities[i].hostown[gpp];
+
+   if (padgrp->gpio_base < 0)
+   continue;
+
+   requested = intel_gpio_is_requested(>chip,
+   padgrp->gpio_base, padgrp->size);
+   value = intel_gpio_update_pad_mode(base + gpp * 4,
+   requested, saved);
+   if ((value ^ saved) & requested) {
+   dev_warn(dev, "restore hostown %d/%u 
%#8x->%#8x\n",
+   i, gpp, value, saved);
+   }
+   }
}
 
return 0;
-- 
2.21.0



Re: [PATCH 1/1] arm: mm: Export __sync_icache_dcache() for xen-privcmd

2019-04-14 Thread Christoph Hellwig
On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
> This patch avoids
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
> observed when compiling v4.19.34.
> 
> The xen-privcmd driver, which can be modular, calls set_pte_at()
> which in turn may call __sync_icache_dcache().

Maybe that really is a sign that it should not be modular..


Re: [PATCH v2 1/3] RISC-V: Add separate asm/encoding.h for spec related defines

2019-04-14 Thread Christoph Hellwig
On Sat, Apr 13, 2019 at 03:38:35PM +, Anup Patel wrote:
> It's better to have all RISC-V spec related defines in one place
> so this patch adds separate asm/encoding.h for such defines which
> can be included in assembly as well as C code.

As per the discussion of version 1 on Saturday I disagree with this
move.  There is both a philosophical and a practical reason for that:

 a) in RISC-V CSR access is really nicely split out into a separate
number space, just accessed through a few special instructions.
It has no overlap with the rest of instruction encoding
 b)  is pulled into just about every file build in the kernel
though ,  and 

So even if you want to later add a new  for instruction
encoding details later, I'd rather prefer to keep CSR access separate
from it.


Re: [PATCH v2] sched/clock: Prevent generic sched_clock wrap caused by tick_freeze()

2019-04-14 Thread Chang-An Chen
Hi,

This is just a gentle ping for this patch.

On Fri, 2019-03-29 at 10:59 +0800, Chang-An Chen wrote:
> tick_freeze() introduced by suspend-to-idle in commit 124cf9117c5f
> ("PM / sleep: Make it possible to quiesce timers during suspend-to-idle")
> will use timekeeping_suspend() instead of syscore_suspend() during
> suspend-to-idle. It means that generic sched_clock will keep going because
> sched_clock_suspend() and sched_clock_resume() are not taken during
> suspend-to-idle. This will lead to generic sched_clock wrap.
> 
> For example:
> In my arm system with suspend-to-idle enabled, sched_clock is registered
> as "56 bits at 13MHz, resolution 76ns, wraps every 4398046511101ns", which
> means the real wrapping duration is 8796093022202ns.
> 
> [  134.551779] suspend-to-idle suspend (timekeeping_suspend())
> [ 1204.912239] suspend-to-idle resume (timekeeping_resume())
> ..
> [ 1206.912239] suspend-to-idle suspend (timekeeping_suspend())
> [ 5880.502807] suspend-to-idle resume (timekeeping_resume())
> ..
> [ 6000.403724] suspend-to-idle suspend (timekeeping_suspend())
> [ 8035.753167] suspend-to-idle resume  (timekeeping_resume())
> ..
> [ 8795.786684] (2)[321:charger_thread]..
> [ 8795.788387] (2)[321:charger_thread]..
> [0.057226] (0)[0:swapper/0]..
> [0.061447] (2)[0:swapper/2]..
> 
> Sched_clock was not stopped during suspend-to-idle, and sched_clock_poll
> hrtimer was not expired because timekeeping_suspend() is taken during
> suspend-to-idle. It makes sched_clock wrap at kernel time 8796s.
> 
> To fix this issue, we add sched_clock_suspend() and sched_clock_resume() in
> tick_freeze() together with timekeeping_suspend() and timekeeping_resume()
> to make sure generic sched_clock wrapping will not happen.
> 
> Signed-off-by: Chang-An Chen 
> Fixes: 124cf9117c5f (PM / sleep: Make it possible to quiesce timers during 
> suspend-to-idle)
> ---
>  kernel/time/sched_clock.c |4 ++--
>  kernel/time/tick-common.c |2 ++
>  kernel/time/timekeeping.h |7 +++
>  3 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index 094b82c..930113b 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -272,7 +272,7 @@ static u64 notrace suspended_sched_clock_read(void)
>   return cd.read_data[seq & 1].epoch_cyc;
>  }
>  
> -static int sched_clock_suspend(void)
> +int sched_clock_suspend(void)
>  {
>   struct clock_read_data *rd = _data[0];
>  
> @@ -283,7 +283,7 @@ static int sched_clock_suspend(void)
>   return 0;
>  }
>  
> -static void sched_clock_resume(void)
> +void sched_clock_resume(void)
>  {
>   struct clock_read_data *rd = _data[0];
>  
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 529143b..df40146 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -487,6 +487,7 @@ void tick_freeze(void)
>   trace_suspend_resume(TPS("timekeeping_freeze"),
>smp_processor_id(), true);
>   system_state = SYSTEM_SUSPEND;
> + sched_clock_suspend();
>   timekeeping_suspend();
>   } else {
>   tick_suspend_local();
> @@ -510,6 +511,7 @@ void tick_unfreeze(void)
>  
>   if (tick_freeze_depth == num_online_cpus()) {
>   timekeeping_resume();
> + sched_clock_resume();
>   system_state = SYSTEM_RUNNING;
>   trace_suspend_resume(TPS("timekeeping_freeze"),
>smp_processor_id(), false);
> diff --git a/kernel/time/timekeeping.h b/kernel/time/timekeeping.h
> index 7a9b4eb..141ab3a 100644
> --- a/kernel/time/timekeeping.h
> +++ b/kernel/time/timekeeping.h
> @@ -14,6 +14,13 @@ extern ktime_t ktime_get_update_offsets_now(unsigned int 
> *cwsseq,
>  extern void timekeeping_warp_clock(void);
>  extern int timekeeping_suspend(void);
>  extern void timekeeping_resume(void);
> +#ifdef CONFIG_GENERIC_SCHED_CLOCK
> +extern int sched_clock_suspend(void);
> +extern void sched_clock_resume(void);
> +#else
> +static inline int sched_clock_suspend(void) { return 0; }
> +static inline void sched_clock_resume(void) { }
> +#endif
>  
>  extern void do_timer(unsigned long ticks);
>  extern void update_wall_time(void);




Re: [PATCH v2 06/26] PCI: keystone: Move initializations to appropriate places

2019-04-14 Thread Kishon Vijay Abraham I
Hi Bjorn,

On 13/04/19 8:00 PM, Bjorn Helgaas wrote:
> On Mon, Mar 25, 2019 at 02:04:41PM +0530, Kishon Vijay Abraham I wrote:
>> No functional change. Move host specific platform_get_resource to
>> ks_add_pcie_port and the common platform_get_resource (applicable
>> to both host and endpoint) to probe. This is in preparation for
>> adding endpoint support to pci-keystone driver.
> 
> This seems to move platform_get_resource() *from* (not *to*)
> ks_add_pcie_port().

Maybe I should have mentioned "Keep host specific platform_get_resource() in
ks_add_pcie_port() and move the common platform_get_resource() (applicable
to both host and endpoint) to probe()"
> 
> You seem to be making a distinction in the commit log between (1) a
> resource that's only used for host mode, and (2) a common resource
> that's used for both host and endpoint mode.  But I don't see that
> distinction in the patch, so it's a little confusing to mention it in
> the commit log.
> 
> It must make endpoint support easier, but I can't quite connect the
> dots yet.  Maybe endpoint will also use ks_pcie_add_pcie_port(), but
> will have a separate .probe() function that doesn't look up the
> resource that's specific to host mode?

No ks_pcie_add_pcie_port() is specific to host mode, so "config" resource is
kept there whereas "dbics" and "app" resources are common to both host mode and
device mode, so they are moved to probe().

Thanks
Kishon

> 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/pci/controller/dwc/pci-keystone.c | 27 +--
>>  1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c 
>> b/drivers/pci/controller/dwc/pci-keystone.c
>> index 5eebef9b9ada..95997885a05c 100644
>> --- a/drivers/pci/controller/dwc/pci-keystone.c
>> +++ b/drivers/pci/controller/dwc/pci-keystone.c
>> @@ -806,11 +806,6 @@ static int __init ks_pcie_add_pcie_port(struct 
>> keystone_pcie *ks_pcie,
>>  struct resource *res;
>>  int ret;
>>  
>> -res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbics");
>> -pci->dbi_base = devm_pci_remap_cfg_resource(dev, res);
>> -if (IS_ERR(pci->dbi_base))
>> -return PTR_ERR(pci->dbi_base);
>> -
>>  res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>>  pp->va_cfg0_base = devm_pci_remap_cfg_resource(dev, res);
>>  if (IS_ERR(pp->va_cfg0_base))
>> @@ -818,13 +813,6 @@ static int __init ks_pcie_add_pcie_port(struct 
>> keystone_pcie *ks_pcie,
>>  
>>  pp->va_cfg1_base = pp->va_cfg0_base;
>>  
>> -res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
>> -ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
>> -if (IS_ERR(ks_pcie->va_app_base))
>> -return PTR_ERR(ks_pcie->va_app_base);
>> -
>> -ks_pcie->app = *res;
>> -
>>  pp->ops = _pcie_host_ops;
>>  ret = dw_pcie_host_init(pp);
>>  if (ret) {
>> @@ -895,6 +883,8 @@ static int __init ks_pcie_probe(struct platform_device 
>> *pdev)
>>  struct dw_pcie *pci;
>>  struct keystone_pcie *ks_pcie;
>>  struct device_link **link;
>> +struct resource *res;
>> +void __iomem *base;
>>  u32 num_viewport;
>>  struct phy **phy;
>>  u32 num_lanes;
>> @@ -911,6 +901,19 @@ static int __init ks_pcie_probe(struct platform_device 
>> *pdev)
>>  if (!pci)
>>  return -ENOMEM;
>>  
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
>> +ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(ks_pcie->va_app_base))
>> +return PTR_ERR(ks_pcie->va_app_base);
>> +
>> +ks_pcie->app = *res;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbics");
>> +base = devm_pci_remap_cfg_resource(dev, res);
>> +if (IS_ERR(base))
>> +return PTR_ERR(base);
>> +
>> +pci->dbi_base = base;
>>  pci->dev = dev;
>>  pci->ops = _pcie_dw_pcie_ops;
>>  
>> -- 
>> 2.17.1
>>


Re: [PATCH v3 02/26] PCI: keystone: Cleanup error_irq configuration

2019-04-14 Thread Kishon Vijay Abraham I
Hi Bjorn,

On 13/04/19 7:33 PM, Bjorn Helgaas wrote:
> Hi Kishon,
> 
> On Mon, Mar 25, 2019 at 03:09:23PM +0530, Kishon Vijay Abraham I wrote:
>> pci-keystone driver uses irq_of_parse_and_map to get irq number of
>> error_irq. Use platform_get_irq instead and move platform_get_irq()
>> and request_irq() of error_irq from ks_pcie_add_pcie_port to ks_pcie_probe
>> since error_irq is common to both RC mode and EP mode.
> 
> Does this have any DT implications?

No. platform_get_irq() uses of_irq_get(), which in-turn uses of_irq_parse_one()
and irq_create_of_mapping() while irq_of_parse_and_map() directly uses
of_irq_parse_one() and irq_create_of_mapping().

The only difference is platform_get_irq() falls back to using
platform_get_resource() if of_irq_get fails.

I thought it's better to use platform_get_irq() for platform devices.

Thanks
Kishon

> 
> It's not obvious that platform_get_irq() and irq_of_parse_and_map() work
> similarly or that they get the same result from DT.
> 
> I'm sure they *do*, but it would be nice to have some hints in the commit
> log about why that's the case.
> 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/pci/controller/dwc/pci-keystone.c | 43 +--
>>  1 file changed, 17 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c 
>> b/drivers/pci/controller/dwc/pci-keystone.c
>> index 07f55b355d75..e50f8773e768 100644
>> --- a/drivers/pci/controller/dwc/pci-keystone.c
>> +++ b/drivers/pci/controller/dwc/pci-keystone.c
>> @@ -98,8 +98,6 @@ struct keystone_pcie {
>>  struct irq_domain   *legacy_irq_domain;
>>  struct device_node  *np;
>>  
>> -int error_irq;
>> -
>>  /* Application register space */
>>  void __iomem*va_app_base;   /* DT 1st resource */
>>  struct resource app;
>> @@ -743,12 +741,6 @@ static int ks_pcie_config_legacy_irq(struct 
>> keystone_pcie *ks_pcie)
>>  return ret;
>>  }
>>  
>> -static void ks_pcie_setup_interrupts(struct keystone_pcie *ks_pcie)
>> -{
>> -if (ks_pcie->error_irq > 0)
>> -ks_pcie_enable_error_irq(ks_pcie);
>> -}
>> -
>>  /*
>>   * When a PCI device does not exist during config cycles, keystone host 
>> gets a
>>   * bus error instead of returning 0x. This handler always returns 0
>> @@ -810,7 +802,6 @@ static int __init ks_pcie_host_init(struct pcie_port *pp)
>>  
>>  ks_pcie_stop_link(pci);
>>  ks_pcie_setup_rc_app_regs(ks_pcie);
>> -ks_pcie_setup_interrupts(ks_pcie);
>>  writew(PCI_IO_RANGE_TYPE_32 | (PCI_IO_RANGE_TYPE_32 << 8),
>>  pci->dbi_base + PCI_IO_BASE);
>>  
>> @@ -854,23 +845,6 @@ static int __init ks_pcie_add_pcie_port(struct 
>> keystone_pcie *ks_pcie,
>>  struct device *dev = >dev;
>>  int ret;
>>  
>> -/*
>> - * Index 0 is the platform interrupt for error interrupt
>> - * from RC.  This is optional.
>> - */
>> -ks_pcie->error_irq = irq_of_parse_and_map(ks_pcie->np, 0);
>> -if (ks_pcie->error_irq <= 0)
>> -dev_info(dev, "no error IRQ defined\n");
>> -else {
>> -ret = request_irq(ks_pcie->error_irq, ks_pcie_err_irq_handler,
>> -  IRQF_SHARED, "pcie-error-irq", ks_pcie);
>> -if (ret < 0) {
>> -dev_err(dev, "failed to request error IRQ %d\n",
>> -ks_pcie->error_irq);
>> -return ret;
>> -}
>> -}
>> -
>>  pp->ops = _pcie_host_ops;
>>  ret = ks_pcie_dw_host_init(ks_pcie);
>>  if (ret) {
>> @@ -946,6 +920,7 @@ static int __init ks_pcie_probe(struct platform_device 
>> *pdev)
>>  u32 num_lanes;
>>  char name[10];
>>  int ret;
>> +int irq;
>>  int i;
>>  
>>  ks_pcie = devm_kzalloc(dev, sizeof(*ks_pcie), GFP_KERNEL);
>> @@ -965,6 +940,20 @@ static int __init ks_pcie_probe(struct platform_device 
>> *pdev)
>>  return ret;
>>  }
>>  
>> +irq = platform_get_irq(pdev, 0);
>> +if (irq < 0) {
>> +dev_err(dev, "missing IRQ resource: %d\n", irq);
>> +return irq;
>> +}
>> +
>> +ret = request_irq(irq, ks_pcie_err_irq_handler, IRQF_SHARED,
>> +  "ks-pcie-error-irq", ks_pcie);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to request error IRQ %d\n",
>> +irq);
>> +return ret;
>> +}
>> +
>>  ret = of_property_read_u32(np, "num-lanes", _lanes);
>>  if (ret)
>>  num_lanes = 1;
>> @@ -1020,6 +1009,8 @@ static int __init ks_pcie_probe(struct platform_device 
>> *pdev)
>>  if (ret < 0)
>>  goto err_get_sync;
>>  
>> +ks_pcie_enable_error_irq(ks_pcie);
>> +
>>  return 0;
>>  
>>  err_get_sync:
>> -- 
>> 2.17.1
>>


RE: [PATCH] MAINTAINERS: normalize Michael Hennerich's email address

2019-04-14 Thread Hennerich, Michael



> -Original Message-
> From: Lukas Bulwahn [mailto:lukas.bulw...@gmail.com]
> Sent: Samstag, 13. April 2019 11:26
> To: Hennerich, Michael 
> Cc: linux-kernel@vger.kernel.org; Lukas Bulwahn 
> Subject: [PATCH] MAINTAINERS: normalize Michael Hennerich's email address
> 
> MAINTAINERS contains a lower-case and upper-case variant of
> Michael Hennerich' s email address.
> 
> Only keep the lower-case variant in MAINTAINERS.
> 
> Signed-off-by: Lukas Bulwahn 

Acked-by: Michael Hennerich 

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index afa019b5c461..b486b9e5d73c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -949,7 +949,7 @@ F:  drivers/dma/dma-axi-dmac.c
> 
>  ANALOG DEVICES INC IIO DRIVERS
>  M: Lars-Peter Clausen 
> -M: Michael Hennerich 
> +M: Michael Hennerich 
>  W: http://wiki.analog.com/
>  W: http://ez.analog.com/community/linux-device-drivers
>  S: Supported
> --
> 2.17.1



Re: [PATCH v4 1/9] clkdev: Hold clocks_mutex while iterating clocks list

2019-04-14 Thread Matti Vaittinen
On Fri, Apr 12, 2019 at 11:31:42AM -0700, Stephen Boyd wrote:
> We recently introduced a change to support devm clk lookups. That change
> introduced a code-path that used clk_find() without holding the
> 'clocks_mutex'. Unfortunately, clk_find() iterates over the 'clocks'
> list and so we need to prevent the list from being modified at the same
> time. Do this by holding the mutex and checking to make sure it's held
> while iterating the list.
> 
> Note, we don't really care if the lookup is freed after we find it with
> clk_find() because we're just doing a pointer comparison, but if we did
> care we would need to keep holding the mutex while we dereference the
> clk_lookup pointer.
> 
> Fixes: 3eee6c7d119c ("clkdev: add managed clkdev lookup registration")
> Cc: Miquel Raynal 
> Cc: Jerome Brunet 
> Cc: Russell King 
> Cc: Michael Turquette 
> Cc: Jeffrey Hugo 
> Cc: Chen-Yu Tsai 
> Cc: Matti Vaittinen 
> Signed-off-by: Stephen Boyd 
Acked-By: Matti Vaittinen 


Re: Linux 5.1-rc5

2019-04-14 Thread Christoph Hellwig
Can we please have the page refcount overflow fixes out on the list
for review, even if it is after the fact?

On Sun, Apr 14, 2019 at 03:40:47PM -0700, Linus Torvalds wrote:
> Nothing in here makes me feel uncomfortable about this release cycle
> so far. Knock wood.
> 
> Shortlog appended with an overview of the details, as usual.
> 
> Linus
> 
> ---
> 
> Alex Deucher (1):
>   drm/amdkfd: Add picasso pci id
> 
> Alexander Potapenko (1):
>   x86/asm: Use stricter assembly constraints in bitops
> 
> Anand Jain (2):
>   btrfs: prop: fix zstd compression parameter validation
>   btrfs: prop: fix vanished compression property after failed set
> 
> Andre Przywara (1):
>   PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller
> 
> Andrei Vagin (1):
>   alarmtimer: Return correct remaining time
> 
> Annaliese McDermond (2):
>   ASoC: tlv320aic32x4: Fix Common Pins
>   ASoC: tlv320aic32x4: Change author's name
> 
> Ard Biesheuvel (1):
>   arm64/ftrace: fix inadvertent BUG() in trampoline check
> 
> Arnaud Pouliquen (1):
>   ASoC: stm32: fix sai driver name initialisation
> 
> Bart Van Assche (1):
>   locking/lockdep: Zap lock classes even with lock debugging disabled
> 
> Brian Norris (1):
>   Bluetooth: btusb: request wake pin with NOAUTOEN
> 
> CK Hu (2):
>   drm/mediatek: Implement gem prime vmap/vunmap function
>   drm/mediatek: Add Mediatek framebuffer device
> 
> Charles Keepax (6):
>   ASoC: wm_adsp: Correct handling of compressed streams that restart
>   ASoC: wm_adsp: Correct error messages in wm_adsp_buffer_get_error
>   ASoC: wm_adsp: Add locking to wm_adsp2_bus_error
>   ASoC: wm_adsp: Shutdown any compressed streams on DSP watchdog timeout
>   ASoC: wm_adsp: Check for buffer in trigger stop
>   ASoC: cs35l35: Disable regulators on driver removal
> 
> Chong Qiao (1):
>   MIPS: KGDB: fix kgdb support for SMP platforms.
> 
> Chris Wilson (2):
>   drm/i915/gvt: Annotate iomem usage
>   drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt()
> 
> Christoph Hellwig (1):
>   sparc64/pci_sun4v: fix ATU checks for large DMA masks
> 
> Christophe Leroy (2):
>   powerpc/32: Fix early boot failure with RTAS built-in
>   powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64
> 
> Chuck Lever (2):
>   NFS: Fix handling of reply page vector
>   xprtrdma: Fix helper that drains the transport
> 
> Cornelia Huck (1):
>   virtio: Honour 'may_reduce_num' in vring_create_virtqueue
> 
> Dan Carpenter (5):
>   drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata()
>   aio: Fix an error code in __io_submit_one()
>   irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init()
>   NFC: nci: Add some bounds checking in nci_hci_cmd_received()
>   nfc: nci: Potential off by one in ->pipes[] array
> 
> Daniel Drake (1):
>   mmc: alcor: don't write data before command has completed
> 
> Daniel Mack (1):
>   ASoC: cs4270: Set auto-increment bit for register writes
> 
> Daniel Mentz (1):
>   ALSA: uapi: #include  in asound.h
> 
> Dave Airlie (1):
>   drm/udl: add a release method and delay modeset teardown
> 
> David Müller (1):
>   clk: x86: Add system specific quirk to mark clocks as critical
> 
> Dongli Zhang (2):
>   virtio-blk: limit number of hw queues by nr_cpu_ids
>   scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids
> 
> Erik Schmauss (1):
>   ACPICA: Namespace: remove address node from global list after
> method termination
> 
> Faiz Abbas (1):
>   mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
> 
> Filipe Manana (1):
>   Btrfs: do not allow trimming when a fs is mounted with the
> nologreplay option
> 
> Guenter Roeck (1):
>   ASoC: intel: Fix crash at suspend/resume after failed codec registration
> 
> Gustavo A. R. Silva (1):
>   ASoC: ab8500: Mark expected switch fall-through
> 
> Hans Holmberg (1):
>   lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage 
> bvecs
> 
> Hans de Goede (1):
>   ASoC: Intel: cht_bsw_max98090_ti: Enable codec clock once and
> keep it enabled
> 
> Heiner Kallweit (1):
>   r8169: disable ASPM again
> 
> Horatiu Vultur (1):
>   MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig
> 
> Hui Wang (1):
>   ALSA: hda - Add two more machines to the power_save_blacklist
> 
> Imre Deak (1):
>   drm/i915: Get power refs in encoder->get_power_domains()
> 
> Iuliana Prodan (1):
>   crypto: caam - fix copy of next buffer for xcbc and cmac
> 
> James Smart (1):
>   nvme-fc: correct csn initialization and increments on error
> 
> Jani Nikula (1):
>   drm/i915/dp: revert back to max link rate and lane count on eDP
> 
> Jann Horn (1):
>   linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()
> 
> Jarkko Sakkinen (2):
>   tpm: turn on TPM on suspend for TPM 1.x
>   KEYS: trusted: 

Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions

2019-04-14 Thread Mike Rapoport
Hi,

On Mon, Apr 15, 2019 at 10:05:18AM +0800, Chen Zhou wrote:
> Hi Mike,
> 
> On 2019/4/14 20:10, Mike Rapoport wrote:
> >>
> >> solution A:phys_addr_t start[INIT_MEMBLOCK_RESERVED_REGIONS * 2];
> >>phys_addr_t end[INIT_MEMBLOCK_RESERVED_REGIONS * 2];
> >> start, end is physical addr
> >>
> >> solution B:int start_rgn[INIT_MEMBLOCK_REGIONS], 
> >> end_rgn[INIT_MEMBLOCK_REGIONS];
> >> start_rgn, end_rgn is rgn index
> >>
> >> Solution B do less remove operations and with no warning comparing to 
> >> solution A.
> >> I think solution B is better, could you give some suggestions?
> >  
> > Solution B is indeed better that solution A, but I'm still worried by
> > relatively large arrays on stack and the amount of loops :(
> > 
> > The very least we could do is to call memblock_cap_memory_range() to drop
> > the memory before and after the ranges we'd like to keep.
> 
> 1. relatively large arrays
> As my said above, the start_rgn, end_rgn is rgn index, we could use unsigned 
> char type.

Let's stick to int for now

> 2. loops
> Loops always exist, and the solution with fewer loops may be just 
> encapsulated well.

Of course the loops are there, I just hoped we could get rid of the nested
loop and get away with single passes in all the cases.
Apparently it's not the case :(

> Thanks,
> Chen Zhou
> 

-- 
Sincerely yours,
Mike.



Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions

2019-04-14 Thread Mike Rapoport
On Mon, Apr 15, 2019 at 10:27:30AM +0800, Chen Zhou wrote:
> Hi Mike,
> 
> On 2019/4/14 20:13, Mike Rapoport wrote:
> > Hi,
> > 
> > On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> >> After commit (arm64: kdump: support reserving crashkernel above 4G),
> >> there may be two crash kernel regions, one is below 4G, the other is
> >> above 4G.
> >>
> >> Crash dump kernel reads more than one crash kernel regions via a dtb
> >> property under node /chosen,
> >> linux,usable-memory-range = 
> > 
> > Somehow I've missed that previously, but how is this supposed to work on
> > EFI systems?
> 
> Whatever the way in which the systems work, there is FDT 
> pointer(__fdt_pointer)
> in arm64 kernel and file /sys/firmware/fdt will be created in late_initcall.
> 
> Kexec-tools read and update file /sys/firmware/fdt in EFI systems to support 
> kdump to
> boot capture kernel.
> 
> For supporting more than one crash kernel regions, kexec-tools make changes 
> accordingly.
> Details are in below:
> http://lists.infradead.org/pipermail/kexec/2019-April/022792.html
 
Thanks for the clarification!

> Thanks,
> Chen Zhou
> 
> >  
> >> Signed-off-by: Chen Zhou 
> >> ---
> >>  arch/arm64/mm/init.c | 66 
> >> 
> >>  include/linux/memblock.h |  6 +
> >>  mm/memblock.c|  7 ++---
> >>  3 files changed, 66 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> index 3bebddf..0f18665 100644
> >> --- a/arch/arm64/mm/init.c
> >> +++ b/arch/arm64/mm/init.c
> >> @@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> >>  
> >>  #ifdef CONFIG_KEXEC_CORE
> >>  
> >> +/* at most two crash kernel regions, low_region and high_region */
> >> +#define CRASH_MAX_USABLE_RANGES   2
> >> +#define LOW_REGION_IDX0
> >> +#define HIGH_REGION_IDX   1
> >> +
> >>  /*
> >>   * reserve_crashkernel() - reserves memory for crash kernel
> >>   *
> >> @@ -297,8 +302,8 @@ static int __init 
> >> early_init_dt_scan_usablemem(unsigned long node,
> >>const char *uname, int depth, void *data)
> >>  {
> >>struct memblock_region *usablemem = data;
> >> -  const __be32 *reg;
> >> -  int len;
> >> +  const __be32 *reg, *endp;
> >> +  int len, nr = 0;
> >>  
> >>if (depth != 1 || strcmp(uname, "chosen") != 0)
> >>return 0;
> >> @@ -307,22 +312,63 @@ static int __init 
> >> early_init_dt_scan_usablemem(unsigned long node,
> >>if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
> >>return 1;
> >>  
> >> -  usablemem->base = dt_mem_next_cell(dt_root_addr_cells, );
> >> -  usablemem->size = dt_mem_next_cell(dt_root_size_cells, );
> >> +  endp = reg + (len / sizeof(__be32));
> >> +  while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
> >> +  usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, );
> >> +  usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, );
> >> +
> >> +  if (++nr >= CRASH_MAX_USABLE_RANGES)
> >> +  break;
> >> +  }
> >>  
> >>return 1;
> >>  }
> >>  
> >>  static void __init fdt_enforce_memory_region(void)
> >>  {
> >> -  struct memblock_region reg = {
> >> -  .size = 0,
> >> -  };
> >> +  int i, cnt = 0;
> >> +  struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
> >> +
> >> +  memset(regs, 0, sizeof(regs));
> >> +  of_scan_flat_dt(early_init_dt_scan_usablemem, regs);
> >> +
> >> +  for (i = 0; i < CRASH_MAX_USABLE_RANGES; i++)
> >> +  if (regs[i].size)
> >> +  cnt++;
> >> +  else
> >> +  break;
> >> +
> >> +  if (cnt - 1 == LOW_REGION_IDX)
> >> +  memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
> >> +  regs[LOW_REGION_IDX].size);
> >> +  else if (cnt - 1 == HIGH_REGION_IDX) {
> >> +  /*
> >> +   * Two crash kernel regions, cap the memory range
> >> +   * [regs[LOW_REGION_IDX].base, regs[HIGH_REGION_IDX].end]
> >> +   * and then remove the memory range in the middle.
> >> +   */
> >> +  int start_rgn, end_rgn, i, ret;
> >> +  phys_addr_t mid_base, mid_size;
> >> +
> >> +  mid_base = regs[LOW_REGION_IDX].base + 
> >> regs[LOW_REGION_IDX].size;
> >> +  mid_size = regs[HIGH_REGION_IDX].base - mid_base;
> >> +  ret = memblock_isolate_range(, mid_base,
> >> +  mid_size, _rgn, _rgn);
> >>  
> >> -  of_scan_flat_dt(early_init_dt_scan_usablemem, );
> >> +  if (ret)
> >> +  return;
> >>  
> >> -  if (reg.size)
> >> -  memblock_cap_memory_range(reg.base, reg.size);
> >> +  memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
> >> +  regs[HIGH_REGION_IDX].base -
> >> +  regs[LOW_REGION_IDX].base +
> >> +  regs[HIGH_REGION_IDX].size);
> >> +  for (i = 

Re: misuse of fget_raw() in perf_event_get()

2019-04-14 Thread Alexei Starovoitov
On Sat, Apr 13, 2019 at 10:02:42PM +0100, Al Viro wrote:
>   What's the point of using fget_raw(), if you do
> _not_ accept O_PATH descriptors?  That should be fget()...

I think you're talking about commit e03e7ee34fdd ("perf/bpf: Convert 
perf_event_array to use struct file")
I don't really remember why we went with this instead of fget().
There was a bunch of back and forth back then with Peter.
Now it looks like that it can be fget just fine.
I think cgroup_get_from_fd() should do the same too?



linux-next: manual merge of the tip tree with the arm64 tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  mm/kasan/Makefile

between commit:

  e2092740b723 ("kasan: Makefile: Replace -pg with CC_FLAGS_FTRACE")

from the arm64 tree and commit:

  57b78a62e7f2 ("x86/uaccess, kasan: Fix KASAN vs SMAP")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/kasan/Makefile
index f06ee820d356,613dfe681e9f..
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@@ -5,9 -6,10 +6,10 @@@ UBSAN_SANITIZE_generic_report.o := 
  UBSAN_SANITIZE_tags.o := n
  KCOV_INSTRUMENT := n
  
 -CFLAGS_REMOVE_common.o = -pg
 -CFLAGS_REMOVE_generic.o = -pg
 -CFLAGS_REMOVE_generic_report.o = -pg
 -CFLAGS_REMOVE_tags.o = -pg
 +CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE)
 +CFLAGS_REMOVE_generic.o = $(CC_FLAGS_FTRACE)
++CFLAGS_REMOVE_generic_report.o = $(CC_FLAGS_FTRACE)
 +CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
  
  # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
  # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533


pgpAbjFkbU_bG.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the tip tree with the arm64 tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/s390/include/asm/Kbuild

between commit:

  fdcd06a8ab77 ("arch: Use asm-generic header for asm/mmiowb.h")

from the arm64 tree and commit:

  46ad0840b158 ("locking/rwsem: Remove arch specific rwsem files")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/include/asm/Kbuild
index bdc4f06a04c5,d5fadefea33c..
--- a/arch/s390/include/asm/Kbuild
+++ b/arch/s390/include/asm/Kbuild
@@@ -20,8 -20,6 +20,7 @@@ generic-y += local.
  generic-y += local64.h
  generic-y += mcs_spinlock.h
  generic-y += mm-arch-hooks.h
 +generic-y += mmiowb.h
- generic-y += rwsem.h
  generic-y += trace_clock.h
  generic-y += unaligned.h
  generic-y += word-at-a-time.h


pgpSgACLcj9JN.pgp
Description: OpenPGP digital signature


Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section

2019-04-14 Thread Benjamin Herrenschmidt
On Fri, 2019-04-12 at 14:17 +0100, Will Deacon wrote:
> 
> +the same CPU thread to a particular device will arrive in program
> +order.
> +
> + 2. A writeX() by a CPU thread to the peripheral will first wait for the
> +completion of all prior writes to memory either issued by the thread
> +or issued while holding a spinlock that was subsequently taken by the
> +thread. This ensures that writes by the CPU to an outbound DMA
> +buffer allocated by dma_alloc_coherent() will be visible to a DMA
> +engine when the CPU writes to its MMIO control register to trigger
> +the transfer.

Not particularily trying to be annoying here but I find the above
rather hard to parse :) I know what you're getting at but I'm not sure
somebody who doesn't will understand.

One way would be to instead prefix the whole thing with a blurb along
the lines of:

readX() and writeX() provide some ordering guarantees versus
each other and other memory accesses that are described below. 
Those guarantees apply to accesses performed either by the same
logical thread of execution, or by different threads but while 
holding the same lock (spinlock or mutex).

Then have as simpler description of each case. No ?

> + 3. A readX() by a CPU thread from the peripheral will complete before
> +any subsequent reads from memory by the same thread can begin. This
> +ensures that reads by the CPU from an incoming DMA buffer allocated
> +by dma_alloc_coherent() will not see stale data after reading from
> +the DMA engine's MMIO status register to establish that the DMA
> +transfer has completed.
> +
> + 4. A readX() by a CPU thread from the peripheral will complete before
> +any subsequent delay() loop can begin execution on the same thread.
> +This ensures that two MMIO register writes by the CPU to a peripheral
> +will arrive at least 1us apart if the first write is immediately read
> +back with readX() and udelay(1) is called prior to the second
> +writeX():
>  
>   writel(42, DEVICE_REGISTER_0); // Arrives at the device...
>   readl(DEVICE_REGISTER_0);
> @@ -2600,8 +2604,10 @@ guarantees:
>   These will perform appropriately for the type of access they're actually
>   doing, be it inX()/outX() or readX()/writeX().
>  
> -All of these accessors assume that the underlying peripheral is 
> little-endian,
> -and will therefore perform byte-swapping operations on big-endian 
> architectures.
> +With the exception of the string accessors (insX(), outsX(), readsX() and
> +writesX()), all of the above assume that the underlying peripheral is
> +little-endian and will therefore perform byte-swapping operations on 
> big-endian
> +architectures.
>  
>  
>  



Re: [PATCH v5 0/5] init: Do not select DEBUG_KERNEL by default

2019-04-14 Thread Kees Cook
On Sat, Apr 13, 2019 at 3:44 PM Sinan Kaya  wrote:
>
> CONFIG_DEBUG_KERNEL has been designed to just enable Kconfig options.
> Kernel code generatoin should not depend on CONFIG_DEBUG_KERNEL.
>
> Proposed alternative plan: let's add a new symbol, something like
> DEBUG_MISC ("Miscellaneous debug code that should be under a more
> specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> "default DEBUG_KERNEL" but allow itself to be turned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> "#ifdef CONFIG_DEBUG_MISC".

Thanks! This looks good to me. For the series:

Reviewed-by: Kees Cook 

Andrew, can you take these from lkml, or should the series get resent
directly to you? I think you might be the best to carry this?

Thanks!

-Kees

>
> Diff from v4:
> - collect reviewed-by
> - collect acked-by
> - fix nit on 1/5
>
> Sinan Kaya (5):
>   init: Introduce DEBUG_MISC option
>   powerpc: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
>   mips: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
>   xtensa: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
>   net: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
>
>  arch/mips/kernel/setup.c   | 2 +-
>  arch/powerpc/kernel/sysfs.c| 8 
>  arch/xtensa/include/asm/irqflags.h | 2 +-
>  arch/xtensa/kernel/smp.c   | 2 +-
>  lib/Kconfig.debug  | 9 +
>  net/netfilter/core.c   | 2 +-
>  6 files changed, 17 insertions(+), 8 deletions(-)
>
> --
> 2.21.0
>


-- 
Kees Cook


Re: [PATCH v4 2/3] csky: Add support for perf registers sampling

2019-04-14 Thread Guo Ren
Hi Mao,

On Thu, Apr 11, 2019 at 03:45:00PM +0800, Mao Han wrote:
> This patch implements the perf registers sampling and validation API
> for csky arch. The valid registers and their register ID are defined in
> perf_regs.h. Perf tool can backtrace in userspace with unwind library
> and the registers/user stack dump support.
> 
> CC: Guo Ren 
> 
> Signed-off-by: Mao Han 
> ---
>  arch/csky/Kconfig  |  2 ++
>  arch/csky/include/uapi/asm/perf_regs.h | 51 
> ++
>  arch/csky/kernel/Makefile  |  1 +
>  arch/csky/kernel/perf_regs.c   | 40 ++
>  4 files changed, 94 insertions(+)
>  create mode 100644 arch/csky/include/uapi/asm/perf_regs.h
>  create mode 100644 arch/csky/kernel/perf_regs.c
> 
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index c4974cf..8e45c7a 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -38,6 +38,8 @@ config CSKY
>   select HAVE_KERNEL_LZO
>   select HAVE_KERNEL_LZMA
>   select HAVE_PERF_EVENTS
> + select HAVE_PERF_REGS
> + select HAVE_PERF_USER_STACK_DUMP
>   select HAVE_DMA_API_DEBUG
>   select HAVE_DMA_CONTIGUOUS
>   select HAVE_SYSCALL_TRACEPOINTS
> diff --git a/arch/csky/include/uapi/asm/perf_regs.h 
> b/arch/csky/include/uapi/asm/perf_regs.h
> new file mode 100644
> index 000..ee323d8
> --- /dev/null
> +++ b/arch/csky/include/uapi/asm/perf_regs.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#ifndef _ASM_CSKY_PERF_REGS_H
> +#define _ASM_CSKY_PERF_REGS_H
> +
> +/* Index of struct pt_regs */
> +enum perf_event_csky_regs {
> + PERF_REG_CSKY_TLS,
> + PERF_REG_CSKY_LR,
> + PERF_REG_CSKY_PC,
> + PERF_REG_CSKY_SR,
> + PERF_REG_CSKY_SP,
> + PERF_REG_CSKY_ORIG_A0,
> + PERF_REG_CSKY_A0,
> + PERF_REG_CSKY_A1,
> + PERF_REG_CSKY_A2,
> + PERF_REG_CSKY_A3,
> + PERF_REG_CSKY_REGS0,
> + PERF_REG_CSKY_REGS1,
> + PERF_REG_CSKY_REGS2,
> + PERF_REG_CSKY_REGS3,
> + PERF_REG_CSKY_REGS4,
> + PERF_REG_CSKY_REGS5,
> + PERF_REG_CSKY_REGS6,
> + PERF_REG_CSKY_REGS7,
> + PERF_REG_CSKY_REGS8,
> + PERF_REG_CSKY_REGS9,
> +#if defined(__CSKYABIV2__)
> + PERF_REG_CSKY_EXREGS0,
> + PERF_REG_CSKY_EXREGS1,
> + PERF_REG_CSKY_EXREGS2,
> + PERF_REG_CSKY_EXREGS3,
> + PERF_REG_CSKY_EXREGS4,
> + PERF_REG_CSKY_EXREGS5,
> + PERF_REG_CSKY_EXREGS6,
> + PERF_REG_CSKY_EXREGS7,
> + PERF_REG_CSKY_EXREGS8,
> + PERF_REG_CSKY_EXREGS9,
> + PERF_REG_CSKY_EXREGS10,
> + PERF_REG_CSKY_EXREGS11,
> + PERF_REG_CSKY_EXREGS12,
> + PERF_REG_CSKY_EXREGS13,
> + PERF_REG_CSKY_EXREGS14,
> + PERF_REG_CSKY_HI,
> + PERF_REG_CSKY_LO,
> + PERF_REG_CSKY_DCSR,
> +#endif
> + PERF_REG_CSKY_MAX,
> +};
> +#endif /* _ASM_CSKY_PERF_REGS_H */
> diff --git a/arch/csky/kernel/Makefile b/arch/csky/kernel/Makefile
> index 4c462f5..1624b04 100644
> --- a/arch/csky/kernel/Makefile
> +++ b/arch/csky/kernel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_FUNCTION_TRACER)   += ftrace.o
>  obj-$(CONFIG_STACKTRACE) += stacktrace.o
>  obj-$(CONFIG_CSKY_PMU_V1)+= perf_event.o
>  obj-$(CONFIG_PERF_EVENTS)+= perf_callchain.o
> +obj-$(CONFIG_HAVE_PERF_REGS)+= perf_regs.o
>  
>  ifdef CONFIG_FUNCTION_TRACER
>  CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
> diff --git a/arch/csky/kernel/perf_regs.c b/arch/csky/kernel/perf_regs.c
> new file mode 100644
> index 000..88f1875
> --- /dev/null
> +++ b/arch/csky/kernel/perf_regs.c
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +u64 perf_reg_value(struct pt_regs *regs, int idx)
> +{
> + if (WARN_ON_ONCE((u32)idx >= PERF_REG_CSKY_MAX))
> + return 0;
> +
> + return ((long *)regs)[idx];
Please use:
return (u64)((u32 *)regs + idx);
> +}
> +
> +#define REG_RESERVED (~((1ULL << PERF_REG_CSKY_MAX) - 1))
> +
> +int perf_reg_validate(u64 mask)
> +{
> + if (!mask || mask & REG_RESERVED)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +u64 perf_reg_abi(struct task_struct *task)
> +{
> + return PERF_SAMPLE_REGS_ABI_32;
> +}
> +
> +void perf_get_regs_user(struct perf_regs *regs_user,
> + struct pt_regs *regs,
> + struct pt_regs *regs_user_copy)
> +{
> + regs_user->regs = task_pt_regs(current);
> + regs_user->abi = perf_reg_abi(current);
> +}

Best Regards
 Guo Ren


[PATCH 1/2] doc: Fixup definition of rcupdate.rcu_task_stall_timeout

2019-04-14 Thread Zhenzhong Duan
A positive value of rcupdate.rcu_task_stall_timeout is an interval
in seconds rather than jiffies.

Signed-off-by: Zhenzhong Duan 
---
 Documentation/RCU/stallwarn.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 1ab70c3..13e88fc 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -153,7 +153,7 @@ rcupdate.rcu_task_stall_timeout
This boot/sysfs parameter controls the RCU-tasks stall warning
interval.  A value of zero or less suppresses RCU-tasks stall
warnings.  A positive value sets the stall-warning interval
-   in jiffies.  An RCU-tasks stall warning starts with the line:
+   in seconds.  An RCU-tasks stall warning starts with the line:
 
INFO: rcu_tasks detected stalls on tasks:
 
-- 
1.8.3.1



[PATCH 2/2] doc: kernel-parameters.txt: fix documentation of nmi_watchdog parameter

2019-04-14 Thread Zhenzhong Duan
As stated in "Documentation/lockup-watchdogs.txt:line 22", the default
behaivor after 'hardlockup' is to stay locked up rather than panic.

Signed-off-by: Zhenzhong Duan 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2b8ee90..fcc9579 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2769,7 +2769,7 @@
0 - turn hardlockup detector in nmi_watchdog off
1 - turn hardlockup detector in nmi_watchdog on
When panic is specified, panic when an NMI watchdog
-   timeout occurs (or 'nopanic' to override the opposite
+   timeout occurs (or 'nopanic' which is the opposite
default). To disable both hard and soft lockup 
detectors,
please see 'nowatchdog'.
This is useful when you use a panic=... timeout and
-- 
1.8.3.1



Re: [PATCH v3 net-next 18/24] net: dsa: sja1105: Add support for traffic through standalone ports

2019-04-14 Thread Andrew Lunn
> It fails to decode the frames, obviously. But so does any other EtherType.

> Florian was hinting
> (https://lwn.net/ml/netdev/b52f4cdf-edcf-0757-1d6e-d4a831ec7...@gmail.com/)
> at the recent pull requests submitted to tcpdump and libpcap that make
> it possible to decode based on the string in
> /sys/class/net/${master}/dsa/tagging. I admit I haven't actually
> tested or studied those closely yet (there are more important things
> to focus on ATM), but since my driver returns "8021q" in sysfs and
> yours returns "edsa", I would presume tcpdump could use that
> information.

No it does not. It is a valid EtherType, that is what is used to
trigger the decoding, it takes no notice of what is in
/sys/class/net/${master}/dsa/tagging, nor the extra meta-data added to
the pcap file. There is no need. you can identify it is a Marvell EDSA
header from the EtherType.

In fact, this tcpdump code for decoding EDSA pre-dated Florians
patches by a few years.

You only need the code which Florian added when you cannot identify
the header directly from the packet. And that is true for most of the
tagging protocols. But EDSA you can.

> Anyway, since you obviously know more on this topic than I do,
> please make me understand what are the real problems in spoofing the
> Ethertype as a Marvell one.

Despite there being an EDSA EtherType in the frame, what follows is
not an ESDA header. It is like having the IPv4 EtherType but what
following is not an IP header. Broken.

Andrew


linux-next: manual merge of the block tree with Linus' tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the block tree got a conflict in:

  include/linux/bvec.h

between commit:

  1200e07f3ad4 ("block: don't use for-inside-for in bio_for_each_segment_all")

from Linus' tree and commit:

  52d52d1c98a9 ("block: only allow contiguous page structs in a bio_vec")

from the block 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.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/bvec.h
index 3bc91879e1e2,44b0f4684190..
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@@ -156,8 -151,8 +151,8 @@@ static inline void bvec_advance(const s
  {
struct bio_vec *bv = _all->bv;
  
 -  if (bv->bv_page) {
 +  if (iter_all->done) {
-   bv->bv_page = nth_page(bv->bv_page, 1);
+   bv->bv_page++;
bv->bv_offset = 0;
} else {
bv->bv_page = bvec->bv_page;


pgppe2Il3Bc9I.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the block tree with Linus' tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the block tree got a conflict in:

  block/bfq-iosched.c

between commit:

  eed47d19d936 ("block, bfq: fix use after free in bfq_bfqq_expire")

from Linus' tree and commit:

  636b8fe86bed ("block, bfq: fix some typos in comments")

from the block tree.

I fixed it up (the former included the fix from the latter, so I just
used that) 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.

-- 
Cheers,
Stephen Rothwell


pgpiKr3dDC2JG.pgp
Description: OpenPGP digital signature


Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP

2019-04-14 Thread Herbert Xu
On Sun, Apr 14, 2019 at 07:24:12PM -0700, Matthew Wilcox wrote:
> On Thu, Apr 11, 2019 at 01:32:32PM -0700, Kees Cook wrote:
> > > @@ -156,7 +156,8 @@ static int __testmgr_alloc_buf(char *buf[XBUFSIZE], 
> > > int order)
> > > int i;
> > >
> > > for (i = 0; i < XBUFSIZE; i++) {
> > > -   buf[i] = (char *)__get_free_pages(GFP_KERNEL, order);
> > > +   buf[i] = (char *)__get_free_pages(GFP_KERNEL | __GFP_COMP,
> > > + order);
> > 
> > Is there a reason __GFP_COMP isn't automatically included in all page
> > allocations? (Or rather, it seems like the exception is when things
> > should NOT be considered part of the same allocation, so something
> > like __GFP_SINGLE should exist?.)
> 
> The question is not whether or not things should be considered part of the
> same allocation.  The question is whether the allocation is of a compound
> page or of N consecutive pages.  Now you're asking what the difference is,
> and it's whether you need to be able to be able to call compound_head(),
> compound_order(), PageTail() or use a compound_dtor.  If you don't, then
> you can save some time at allocation & free by not specifying __GFP_COMP.

Thanks for clarifying Matthew.

Eric, this means that we should not use __GFP_COMP here just to
silent what is clearly a broken warning.

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


Re: [PATCH] printk: tie printk_once / printk_deferred_once into .data.once for reset

2019-04-14 Thread Sergey Senozhatsky
On (04/12/19 22:11), Paul Gortmaker wrote:
> In commit b1fca27d384e ("kernel debug: support resetting WARN*_ONCE")
> we got the opportunity to reset state on the one shot messages,
> without having to reboot.

Didn't know that.

> However printk_once (printk_deferred_once) live in a different file
> and didn't get the same kind of update/conversion, so they remain
> unconditionally one shot, until the system is rebooted.
> 
> For example, we currently have:
> 
>   sched/rt.c: printk_deferred_once("sched: RT throttling activated\n");
> 
> ..which could reasonably be tripped as someone is testing and tuning
> a new system/workload and their task placements.  For consistency, and
> to avoid reboots in the same vein as the original commit, we make these
> two instances of _once the same as the WARN*_ONCE instances are.

Looks OK to me.

Reviewed-by: Sergey Senozhatsky 

-ss


Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions

2019-04-14 Thread Chen Zhou
Hi Mike,

On 2019/4/14 20:13, Mike Rapoport wrote:
> Hi,
> 
> On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
>> After commit (arm64: kdump: support reserving crashkernel above 4G),
>> there may be two crash kernel regions, one is below 4G, the other is
>> above 4G.
>>
>> Crash dump kernel reads more than one crash kernel regions via a dtb
>> property under node /chosen,
>> linux,usable-memory-range = 
> 
> Somehow I've missed that previously, but how is this supposed to work on
> EFI systems?

Whatever the way in which the systems work, there is FDT pointer(__fdt_pointer)
in arm64 kernel and file /sys/firmware/fdt will be created in late_initcall.

Kexec-tools read and update file /sys/firmware/fdt in EFI systems to support 
kdump to
boot capture kernel.

For supporting more than one crash kernel regions, kexec-tools make changes 
accordingly.
Details are in below:
http://lists.infradead.org/pipermail/kexec/2019-April/022792.html

Thanks,
Chen Zhou

>  
>> Signed-off-by: Chen Zhou 
>> ---
>>  arch/arm64/mm/init.c | 66 
>> 
>>  include/linux/memblock.h |  6 +
>>  mm/memblock.c|  7 ++---
>>  3 files changed, 66 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 3bebddf..0f18665 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>  
>>  #ifdef CONFIG_KEXEC_CORE
>>  
>> +/* at most two crash kernel regions, low_region and high_region */
>> +#define CRASH_MAX_USABLE_RANGES 2
>> +#define LOW_REGION_IDX  0
>> +#define HIGH_REGION_IDX 1
>> +
>>  /*
>>   * reserve_crashkernel() - reserves memory for crash kernel
>>   *
>> @@ -297,8 +302,8 @@ static int __init early_init_dt_scan_usablemem(unsigned 
>> long node,
>>  const char *uname, int depth, void *data)
>>  {
>>  struct memblock_region *usablemem = data;
>> -const __be32 *reg;
>> -int len;
>> +const __be32 *reg, *endp;
>> +int len, nr = 0;
>>  
>>  if (depth != 1 || strcmp(uname, "chosen") != 0)
>>  return 0;
>> @@ -307,22 +312,63 @@ static int __init 
>> early_init_dt_scan_usablemem(unsigned long node,
>>  if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
>>  return 1;
>>  
>> -usablemem->base = dt_mem_next_cell(dt_root_addr_cells, );
>> -usablemem->size = dt_mem_next_cell(dt_root_size_cells, );
>> +endp = reg + (len / sizeof(__be32));
>> +while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
>> +usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, );
>> +usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, );
>> +
>> +if (++nr >= CRASH_MAX_USABLE_RANGES)
>> +break;
>> +}
>>  
>>  return 1;
>>  }
>>  
>>  static void __init fdt_enforce_memory_region(void)
>>  {
>> -struct memblock_region reg = {
>> -.size = 0,
>> -};
>> +int i, cnt = 0;
>> +struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
>> +
>> +memset(regs, 0, sizeof(regs));
>> +of_scan_flat_dt(early_init_dt_scan_usablemem, regs);
>> +
>> +for (i = 0; i < CRASH_MAX_USABLE_RANGES; i++)
>> +if (regs[i].size)
>> +cnt++;
>> +else
>> +break;
>> +
>> +if (cnt - 1 == LOW_REGION_IDX)
>> +memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
>> +regs[LOW_REGION_IDX].size);
>> +else if (cnt - 1 == HIGH_REGION_IDX) {
>> +/*
>> + * Two crash kernel regions, cap the memory range
>> + * [regs[LOW_REGION_IDX].base, regs[HIGH_REGION_IDX].end]
>> + * and then remove the memory range in the middle.
>> + */
>> +int start_rgn, end_rgn, i, ret;
>> +phys_addr_t mid_base, mid_size;
>> +
>> +mid_base = regs[LOW_REGION_IDX].base + 
>> regs[LOW_REGION_IDX].size;
>> +mid_size = regs[HIGH_REGION_IDX].base - mid_base;
>> +ret = memblock_isolate_range(, mid_base,
>> +mid_size, _rgn, _rgn);
>>  
>> -of_scan_flat_dt(early_init_dt_scan_usablemem, );
>> +if (ret)
>> +return;
>>  
>> -if (reg.size)
>> -memblock_cap_memory_range(reg.base, reg.size);
>> +memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
>> +regs[HIGH_REGION_IDX].base -
>> +regs[LOW_REGION_IDX].base +
>> +regs[HIGH_REGION_IDX].size);
>> +for (i = end_rgn - 1; i >= start_rgn; i--) {
>> +if (!memblock_is_nomap([i]))
>> +memblock_remove_region(, i);
>> +}
>> +memblock_remove_range(, mid_base,
>> +   

Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP

2019-04-14 Thread Matthew Wilcox
On Thu, Apr 11, 2019 at 01:32:32PM -0700, Kees Cook wrote:
> > @@ -156,7 +156,8 @@ static int __testmgr_alloc_buf(char *buf[XBUFSIZE], int 
> > order)
> > int i;
> >
> > for (i = 0; i < XBUFSIZE; i++) {
> > -   buf[i] = (char *)__get_free_pages(GFP_KERNEL, order);
> > +   buf[i] = (char *)__get_free_pages(GFP_KERNEL | __GFP_COMP,
> > + order);
> 
> Is there a reason __GFP_COMP isn't automatically included in all page
> allocations? (Or rather, it seems like the exception is when things
> should NOT be considered part of the same allocation, so something
> like __GFP_SINGLE should exist?.)

The question is not whether or not things should be considered part of the
same allocation.  The question is whether the allocation is of a compound
page or of N consecutive pages.  Now you're asking what the difference is,
and it's whether you need to be able to be able to call compound_head(),
compound_order(), PageTail() or use a compound_dtor.  If you don't, then
you can save some time at allocation & free by not specifying __GFP_COMP.

I'll agree this is not documented well, and maybe most multi-page
allocations do want __GFP_COMP and we should invert that bit, but
__GFP_SINGLE doesn't seem like the right antonym to __GFP_COMP to me.


linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:

  drivers/net/wireless/intel/iwlwifi/pcie/drv.c

between commits:

  0d5bad14226a ("iwlwifi: rename structs to fit the new names")
  972d8e137779 ("iwlwifi: add new 0x2723/0x2080 card for 22000")

from the wireless-drivers tree and commit:

  ef8a913766cd ("iwlwifi: remove misconfigured pci ids from 22260 series")

from the wireless-drivers-next 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 9f1af8da9dc1,0329b626ada6..
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -953,19 -953,15 +953,15 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA0F0, 0x1652, killer1650i_2ax_cfg_qu_b0_hr_b0)},
{IWL_PCI_DEVICE(0xA0F0, 0x4070, iwl_ax101_cfg_qu_hr)},
  
 -  {IWL_PCI_DEVICE(0x2723, 0x0080, iwl22260_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x0084, iwl22260_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x0088, iwl22260_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x008C, iwl22260_2ax_cfg)},
 +  {IWL_PCI_DEVICE(0x2723, 0x0080, iwl_ax200_cfg_cc)},
 +  {IWL_PCI_DEVICE(0x2723, 0x0084, iwl_ax200_cfg_cc)},
 +  {IWL_PCI_DEVICE(0x2723, 0x0088, iwl_ax200_cfg_cc)},
 +  {IWL_PCI_DEVICE(0x2723, 0x008C, iwl_ax200_cfg_cc)},
{IWL_PCI_DEVICE(0x2723, 0x1653, killer1650w_2ax_cfg)},
{IWL_PCI_DEVICE(0x2723, 0x1654, killer1650x_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x2080, iwl22260_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x4080, iwl22260_2ax_cfg)},
 -  {IWL_PCI_DEVICE(0x2723, 0x4088, iwl22260_2ax_cfg)},
 +  {IWL_PCI_DEVICE(0x2723, 0x2080, iwl_ax200_cfg_cc)},
 +  {IWL_PCI_DEVICE(0x2723, 0x4080, iwl_ax200_cfg_cc)},
 +  {IWL_PCI_DEVICE(0x2723, 0x4088, iwl_ax200_cfg_cc)},
- 
-   {IWL_PCI_DEVICE(0x1a56, 0x1653, killer1650w_2ax_cfg)},
-   {IWL_PCI_DEVICE(0x1a56, 0x1654, killer1650x_2ax_cfg)},
- 
{IWL_PCI_DEVICE(0x2725, 0x0090, iwlax210_2ax_cfg_so_hr_a0)},
{IWL_PCI_DEVICE(0x7A70, 0x0090, iwlax210_2ax_cfg_so_hr_a0)},
{IWL_PCI_DEVICE(0x7A70, 0x0310, iwlax210_2ax_cfg_so_hr_a0)},


pgpxsMIYwSS6A.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions

2019-04-14 Thread Chen Zhou
Hi Mike,

On 2019/4/14 20:10, Mike Rapoport wrote:
> Hi,
> 
> On Thu, Apr 11, 2019 at 08:17:43PM +0800, Chen Zhou wrote:
>> Hi Mike,
>>
>> This overall looks well.
>> Replacing memblock_cap_memory_range() with memblock_cap_memory_ranges() was 
>> what i wanted
>> to do in v1, sorry for don't express that clearly.
> 
> I didn't object to memblock_cap_memory_ranges() in general, I was worried
> about it's complexity and I hoped that we could find a simpler solution.
>  
>> But there are some issues as below. After fixing this, it can work correctly.
>>
>> On 2019/4/10 21:09, Mike Rapoport wrote:
>>> Hi,
>>>
>>> On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
 After commit (arm64: kdump: support reserving crashkernel above 4G),
 there may be two crash kernel regions, one is below 4G, the other is
 above 4G.

 Crash dump kernel reads more than one crash kernel regions via a dtb
 property under node /chosen,
 linux,usable-memory-range = 

 Signed-off-by: Chen Zhou 
 ---
  arch/arm64/mm/init.c | 66 
 
  include/linux/memblock.h |  6 +
  mm/memblock.c|  7 ++---
  3 files changed, 66 insertions(+), 13 deletions(-)

 diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
 index 3bebddf..0f18665 100644
 --- a/arch/arm64/mm/init.c
 +++ b/arch/arm64/mm/init.c
 @@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
  
  #ifdef CONFIG_KEXEC_CORE
  
 +/* at most two crash kernel regions, low_region and high_region */
 +#define CRASH_MAX_USABLE_RANGES   2
 +#define LOW_REGION_IDX0
 +#define HIGH_REGION_IDX   1
 +
  /*
   * reserve_crashkernel() - reserves memory for crash kernel
   *
 @@ -297,8 +302,8 @@ static int __init 
 early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
  {
struct memblock_region *usablemem = data;
 -  const __be32 *reg;
 -  int len;
 +  const __be32 *reg, *endp;
 +  int len, nr = 0;
  
if (depth != 1 || strcmp(uname, "chosen") != 0)
return 0;
 @@ -307,22 +312,63 @@ static int __init 
 early_init_dt_scan_usablemem(unsigned long node,
if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
return 1;
  
 -  usablemem->base = dt_mem_next_cell(dt_root_addr_cells, );
 -  usablemem->size = dt_mem_next_cell(dt_root_size_cells, );
 +  endp = reg + (len / sizeof(__be32));
 +  while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
 +  usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, );
 +  usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, );
 +
 +  if (++nr >= CRASH_MAX_USABLE_RANGES)
 +  break;
 +  }
  
return 1;
  }
  
  static void __init fdt_enforce_memory_region(void)
  {
 -  struct memblock_region reg = {
 -  .size = 0,
 -  };
 +  int i, cnt = 0;
 +  struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
>>>
>>> I only now noticed that fdt_enforce_memory_region() uses memblock_region to
>>> pass the ranges around. If we'd switch to memblock_type instead, the
>>> implementation of memblock_cap_memory_ranges() would be really
>>> straightforward. Can you check if the below patch works for you? 
>>>
>>> >From e476d584098e31273af573e1a78e308880c5cf28 Mon Sep 17 00:00:00 2001
>>> From: Mike Rapoport 
>>> Date: Wed, 10 Apr 2019 16:02:32 +0300
>>> Subject: [PATCH] memblock: extend memblock_cap_memory_range to multiple 
>>> ranges
>>>
>>> The memblock_cap_memory_range() removes all the memory except the range
>>> passed to it. Extend this function to recieve memblock_type with the
>>> regions that should be kept. This allows switching to simple iteration over
>>> memblock arrays with 'for_each_mem_range' to remove the unneeded memory.
>>>
>>> Enable use of this function in arm64 for reservation of multile regions for
>>> the crash kernel.
>>>
>>> Signed-off-by: Mike Rapoport 
>>> ---
>>>  arch/arm64/mm/init.c | 34 --
>>>  include/linux/memblock.h |  2 +-
>>>  mm/memblock.c| 45 ++---
>>>  3 files changed, 47 insertions(+), 34 deletions(-)
>>>
>>>  
>>> -void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
>>> +void __init memblock_cap_memory_ranges(struct memblock_type 
>>> *regions_to_keep)
>>>  {
>>> -   int start_rgn, end_rgn;
>>> -   int i, ret;
>>> -
>>> -   if (!size)
>>> -   return;
>>> -
>>> -   ret = memblock_isolate_range(, base, size,
>>> -   _rgn, _rgn);
>>> -   if (ret)
>>> -   return;
>>> -
>>> -   /* remove all the MAP regions */
>>> -   for (i = 

[RFC PATCH v4 4/4] x86/acrn: Add hypercall for ACRN guest

2019-04-14 Thread Zhao Yakui
When ACRN hypervisor is detected, the hypercall is needed so that the
ACRN guest can query/config some settings. For example: it can be used
to query the resources in hypervisor and manage the CPU/memory/device/
interrupt for guest operating system.

Add the hypercall so that the kernel can communicate with the low-level
ACRN hypervisor. It is implemented with vmacll instruction.

Co-developed-by: Jason Chen CJ 
Signed-off-by: Jason Chen CJ 
Signed-off-by: Zhao Yakui 
---
V1->V2: Refine the comments for the function of acrn_hypercall0/1/2
v2->v3: Use the "vmcall" mnemonic to replace hard-code byte definition
v3->v4: refine the commit log(minor change)
---
 arch/x86/include/asm/acrn_hypercall.h | 81 +++
 1 file changed, 81 insertions(+)
 create mode 100644 arch/x86/include/asm/acrn_hypercall.h

diff --git a/arch/x86/include/asm/acrn_hypercall.h 
b/arch/x86/include/asm/acrn_hypercall.h
new file mode 100644
index 000..30e256e
--- /dev/null
+++ b/arch/x86/include/asm/acrn_hypercall.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_X86_ACRNHYPERCALL_H
+#define _ASM_X86_ACRNHYPERCALL_H
+
+#include 
+
+#ifdef CONFIG_ACRN_GUEST
+
+/*
+ * Hypercalls for ACRN Guest
+ *
+ * Hypercall number is passed in r8 register.
+ * Return value will be placed in rax.
+ * Up to 2 arguments are passed in rdi, rsi.
+ */
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+   register unsigned long r8 asm("r8") = hcall_id;
+   register long result asm("rax");
+
+   /* the hypercall is implemented with vmcall instruction.
+* asm volatile is used to avoid that it is dropped because of
+* compiler optimization.
+*/
+   asm volatile("vmcall"
+   : "=r"(result)
+   : "r"(r8));
+
+   return result;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+  unsigned long param1)
+{
+   register unsigned long r8 asm("r8") = hcall_id;
+   register long result asm("rax");
+
+   asm volatile("vmcall"
+   : "=r"(result)
+   : "D"(param1), "r"(r8));
+
+   return result;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+  unsigned long param1,
+  unsigned long param2)
+{
+   register unsigned long r8 asm("r8") = hcall_id;
+   register long result asm("rax");
+
+   asm volatile("vmcall"
+   : "=r"(result)
+   : "D"(param1), "S"(param2), "r"(r8));
+
+   return result;
+}
+
+#else
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+   return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+  unsigned long param1)
+{
+   return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+  unsigned long param1,
+  unsigned long param2)
+{
+   return -ENOTSUPP;
+}
+#endif /* CONFIG_ACRN_GUEST */
+#endif /* _ASM_X86_ACRNHYPERCALL_H */
-- 
2.7.4



[RFC PATCH v4 3/4] x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for ACRN guest upcall vector

2019-04-14 Thread Zhao Yakui
Linux kernel uses the HYPERVISOR_CALLBACK_VECTOR for hypervisor upcall
vector. And it is already used for Xen and HyperV.
After ACRN hypervisor is detected, it will also use this defined vector
to notify kernel.

Co-developed-by: Jason Chen CJ 
Signed-off-by: Jason Chen CJ 
Signed-off-by: Zhao Yakui 
---
V1->V2: Remove the unused API definition of acrn_setup_intr_handler and
acrn_remove_intr_handler.
Adjust the order of header file
Add the declaration of acrn_hv_vector_handler and tracing
definition of acrn_hv_callback_vector.

v2->v3: Select the X86_HV_CALLBACK_VECTOR for ACRN guest
v3->v4: Refine the file name of acrnhyper.h to acrn.h
---
 arch/x86/Kconfig|  1 +
 arch/x86/entry/entry_64.S   |  5 +
 arch/x86/include/asm/acrn.h | 11 +++
 arch/x86/kernel/cpu/acrn.c  | 22 ++
 4 files changed, 39 insertions(+)
 create mode 100644 arch/x86/include/asm/acrn.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b33bfe5..4bad72c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -848,6 +848,7 @@ config JAILHOUSE_GUEST
 config ACRN_GUEST
bool "ACRN Guest support"
depends on X86_64
+   select X86_HV_CALLBACK_VECTOR
help
  This option allows to run Linux as guest in ACRN hypervisor. Enabling
  this will allow the kernel to boot in virtualized environment under
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1f0efdb..d1b8ad3 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1129,6 +1129,11 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
hv_stimer0_callback_vector hv_stimer0_vector_handler
 #endif /* CONFIG_HYPERV */
 
+#if IS_ENABLED(CONFIG_ACRN_GUEST)
+apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
+   acrn_hv_callback_vector acrn_hv_vector_handler
+#endif
+
 idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
 idtentry int3  do_int3 has_error_code=0
 idtentry stack_segment do_stack_segmenthas_error_code=1
diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
new file mode 100644
index 000..43ab032
--- /dev/null
+++ b/arch/x86/include/asm/acrn.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ACRN_H
+#define _ASM_X86_ACRN_H
+
+void acrn_hv_callback_vector(void);
+#ifdef CONFIG_TRACING
+#define trace_acrn_hv_callback_vector acrn_hv_callback_vector
+#endif
+
+void acrn_hv_vector_handler(struct pt_regs *regs);
+#endif /* _ASM_X86_ACRN_H */
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index f556640..d8072bf 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -9,7 +9,11 @@
  *
  */
 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 static uint32_t __init acrn_detect(void)
 {
@@ -18,6 +22,8 @@ static uint32_t __init acrn_detect(void)
 
 static void __init acrn_init_platform(void)
 {
+   alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+   acrn_hv_callback_vector);
 }
 
 static bool acrn_x2apic_available(void)
@@ -30,6 +36,22 @@ static bool acrn_x2apic_available(void)
return false;
 }
 
+static void (*acrn_intr_handler)(void);
+
+__visible void __irq_entry acrn_hv_vector_handler(struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+
+   entering_ack_irq();
+   inc_irq_stat(irq_hv_callback_count);
+
+   if (acrn_intr_handler)
+   acrn_intr_handler();
+
+   exiting_irq();
+   set_irq_regs(old_regs);
+}
+
 const __initconst struct hypervisor_x86 x86_hyper_acrn = {
.name   = "ACRN",
.detect = acrn_detect,
-- 
2.7.4



[PATCH v4 2/4] x86: Add the support of Linux guest on ACRN hypervisor

2019-04-14 Thread Zhao Yakui
ACRN is an open-source hypervisor maintained by Linux Foundation.
It is built for embedded IOT with small footprint and real-time features.
Add the ACRN guest support so that it allows linux to be booted under
ACRN hypervisor. Following this patch it will setup the upcall
notification vector, enable hypercall and provide the interface that is
used to manage the virtualized CPU/memory/device/interrupt for other
guest OS.

Co-developed-by: Jason Chen CJ 
Signed-off-by: Jason Chen CJ 
Signed-off-by: Zhao Yakui 
---
v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to
understand.
Remove the export of x86_hyper_acrn.

v2->v3: Remove the unnecessary dependency of PARAVIRT
v3->v4: Refine the commit log and add meaningful description
in Kconfig
---
 arch/x86/Kconfig  | 12 
 arch/x86/include/asm/hypervisor.h |  1 +
 arch/x86/kernel/cpu/Makefile  |  1 +
 arch/x86/kernel/cpu/acrn.c| 39 +++
 arch/x86/kernel/cpu/hypervisor.c  |  4 
 5 files changed, 57 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/acrn.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 54d1fbc..b33bfe5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -845,6 +845,18 @@ config JAILHOUSE_GUEST
  cell. You can leave this option disabled if you only want to start
  Jailhouse and run Linux afterwards in the root cell.
 
+config ACRN_GUEST
+   bool "ACRN Guest support"
+   depends on X86_64
+   help
+ This option allows to run Linux as guest in ACRN hypervisor. Enabling
+ this will allow the kernel to boot in virtualized environment under
+ the ACRN hypervisor.
+ ACRN is a flexible, lightweight reference open-source hypervisor, 
built
+ with real-time and safety-criticality in mind. It is built for 
embedded
+ IOT with small footprint and real-time features. More details can be
+ found in https://projectacrn.org/
+
 endif #HYPERVISOR_GUEST
 
 source "arch/x86/Kconfig.cpu"
diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 8c5aaba..50a30f6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,7 @@ enum x86_hypervisor_type {
X86_HYPER_XEN_HVM,
X86_HYPER_KVM,
X86_HYPER_JAILHOUSE,
+   X86_HYPER_ACRN,
 };
 
 #ifdef CONFIG_HYPERVISOR_GUEST
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index cfd24f9..17a7cdf 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_X86_CPU_RESCTRL) += resctrl/
 obj-$(CONFIG_X86_LOCAL_APIC)   += perfctr-watchdog.o
 
 obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o
+obj-$(CONFIG_ACRN_GUEST)   += acrn.o
 
 ifdef CONFIG_X86_FEATURE_NAMES
 quiet_cmd_mkcapflags = MKCAP   $@
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
new file mode 100644
index 000..f556640
--- /dev/null
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ACRN detection support
+ *
+ * Copyright (C) 2019 Intel Corporation. All rights reserved.
+ *
+ * Jason Chen CJ 
+ * Zhao Yakui 
+ *
+ */
+
+#include 
+
+static uint32_t __init acrn_detect(void)
+{
+   return hypervisor_cpuid_base("ACRNACRNACRN\0\0", 0);
+}
+
+static void __init acrn_init_platform(void)
+{
+}
+
+static bool acrn_x2apic_available(void)
+{
+   /* x2apic is not supported now.
+* Later it needs to check the X86_FEATURE_X2APIC bit of cpu info
+* returned by CPUID to determine whether the x2apic is
+* supported in Linux guest.
+*/
+   return false;
+}
+
+const __initconst struct hypervisor_x86 x86_hyper_acrn = {
+   .name   = "ACRN",
+   .detect = acrn_detect,
+   .type   = X86_HYPER_ACRN,
+   .init.init_platform = acrn_init_platform,
+   .init.x2apic_available  = acrn_x2apic_available,
+};
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 479ca47..87e39ad 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -32,6 +32,7 @@ extern const struct hypervisor_x86 x86_hyper_xen_pv;
 extern const struct hypervisor_x86 x86_hyper_xen_hvm;
 extern const struct hypervisor_x86 x86_hyper_kvm;
 extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
 
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
@@ -49,6 +50,9 @@ static const __initconst struct hypervisor_x86 * const 
hypervisors[] =
 #ifdef CONFIG_JAILHOUSE_GUEST
_hyper_jailhouse,
 #endif
+#ifdef CONFIG_ACRN_GUEST
+   _hyper_acrn,
+#endif
 };
 
 enum x86_hypervisor_type x86_hyper_type;
-- 
2.7.4



[RFC PATCH v4 0/4] x86: Add the support of ACRN guest under arch/x86

2019-04-14 Thread Zhao Yakui
ACRN is a flexible, lightweight reference hypervisor, built with real-time
and safety-criticality in mind, optimized to streamline embedded development
through an open source platform. It is built for embedded IOT with small
footprint and real-time features. More details can be found
in https://projectacrn.org/

This is the patch set that allows the Linux to work on ACRN hypervisor and it 
can
work with the following patch set to manage the Linux guest on acrn-hypervisor. 
It
includes the detection of acrn_hypervisor, upcall notification vector from
hypervisor, hypercall. The hypervisor detection is similar to Xen/VMWARE/Hyperv.
ACRN also uses the upcall notification mechanism similar to that in 
Xen/Microsoft
HyperV when it needs to send the notification to Linux OS. The hypercall 
provides
the mechanism that can be used to query/configure the acrn-hypervisor by Linux 
guest.

Following this patch set, we will send acrn driver part, which provides the 
interface
that can be used to manage the virtualized CPU/memory/device/interrupt for 
other guest
OS after the acrn hypervisor is detected.


v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to
understand.
Remove the export of x86_hyper_acrn.
Remove the unused API definition of acrn_setup_intr_handler and
acrn_remove_intr_handler.
Adjust the order of header file
Add the declaration of acrn_hv_vector_handler and tracing
definition of acrn_hv_callback_vector.
Refine the comments for the function of acrn_hypercall0/1/2

v2-v3:  Add one new config symbol to unify the conditional definition
of hv_irq_callback_count
Use the "vmcall" mnemonic to replace the hard-code byte definition
Remove the unnecessary dependency of CONFIG_PARAVIRT for ACRN_GUEST

v3-v4:  Rename the file name of acrnhyper.h to acrn.h
Refine the commit log and some other minor changes(more comments and 
redundant ifdef in acrn.h, sorting the header file in acrn.c)

Zhao Yakui (4):
  x86/Kconfig: Add new config symbol to unify conditional definition of
hv_irq_callback_count
  x86: Add the support of Linux guest on ACRN hypervisor
  x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for ACRN guest upcall vector
  x86/acrn: Add hypercall for ACRN guest

 arch/x86/Kconfig  | 16 +++
 arch/x86/entry/entry_64.S |  5 +++
 arch/x86/include/asm/acrn.h   | 11 +
 arch/x86/include/asm/acrn_hypercall.h | 81 +++
 arch/x86/include/asm/hardirq.h|  2 +-
 arch/x86/include/asm/hypervisor.h |  1 +
 arch/x86/kernel/cpu/Makefile  |  1 +
 arch/x86/kernel/cpu/acrn.c| 61 ++
 arch/x86/kernel/cpu/hypervisor.c  |  4 ++
 arch/x86/kernel/irq.c |  2 +-
 arch/x86/xen/Kconfig  |  1 +
 drivers/hv/Kconfig|  1 +
 12 files changed, 184 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/include/asm/acrn.h
 create mode 100644 arch/x86/include/asm/acrn_hypercall.h
 create mode 100644 arch/x86/kernel/cpu/acrn.c

-- 
2.7.4



[RFC PATCH v4 1/4] x86/Kconfig: Add new config symbol to unify conditional definition of hv_irq_callback_count

2019-04-14 Thread Zhao Yakui
Add a special Kconfig symbol X86_HV_CALLBACK_VECTOR so that the guests
using the hypervisor interrupt callback counter can select and thus
enable that counter. Select it when xen or hyperv support is enabled.
No functional changes.

Signed-off-by: Zhao Yakui 
Reviewed-by: Borislav Petkov 
---
v3->v4: Follow the comments to refine the commit log.
---
 arch/x86/Kconfig   | 3 +++
 arch/x86/include/asm/hardirq.h | 2 +-
 arch/x86/kernel/irq.c  | 2 +-
 arch/x86/xen/Kconfig   | 1 +
 drivers/hv/Kconfig | 1 +
 5 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5ad9241..54d1fbc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,9 @@ config QUEUED_LOCK_STAT
  behavior of paravirtualized queued spinlocks and report
  them on debugfs.
 
+config X86_HV_CALLBACK_VECTOR
+   def_bool n
+
 source "arch/x86/xen/Kconfig"
 
 config KVM_GUEST
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index d9069bb..0753379 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -37,7 +37,7 @@ typedef struct {
 #ifdef CONFIG_X86_MCE_AMD
unsigned int irq_deferred_error_count;
 #endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
unsigned int irq_hv_callback_count;
 #endif
 #if IS_ENABLED(CONFIG_HYPERV)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 59b5f2e..a147826 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -134,7 +134,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, "%10u ", per_cpu(mce_poll_count, j));
seq_puts(p, "  Machine check polls\n");
 #endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
if (test_bit(HYPERVISOR_CALLBACK_VECTOR, system_vectors)) {
seq_printf(p, "%*s: ", prec, "HYP");
for_each_online_cpu(j)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index e07abef..ba5a418 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -7,6 +7,7 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
+   select X86_HV_CALLBACK_VECTOR
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 1c1a251..cafcb97 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on X86 && ACPI && X86_LOCAL_APIC && HYPERVISOR_GUEST
select PARAVIRT
+   select X86_HV_CALLBACK_VECTOR
help
  Select this option to run Linux as a Hyper-V client operating
  system.
-- 
2.7.4



linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2019-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the wireless-drivers-next tree got a conflict
in:

  drivers/net/wireless/intel/iwlwifi/iwl-trans.h

between commit:

  07d35b4270ef ("iwlwifi: use sync nmi in case of init flow failure")

from the wireless-drivers tree and commit:

  4b1831e48974 ("iwlwifi: dbg_ini: support HW error trigger")

from the wireless-drivers-next 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index d8690acee40c,2235978adf70..
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@@ -830,6 -831,8 +830,7 @@@ struct iwl_trans 
u32 lmac_error_event_table[2];
u32 umac_error_event_table;
unsigned int error_event_table_tlv_status;
 -  wait_queue_head_t fw_halt_waitq;
+   bool hw_error;
  
/* pointer to trans specific struct */
/*Ensure that this pointer will always be aligned to sizeof pointer */


pgpOqaMQ_PJcU.pgp
Description: OpenPGP digital signature


RE: [PATCH] MAINTAINERS: normalize Woojung Huh's email address

2019-04-14 Thread Woojung.Huh
> MAINTAINERS contains a lower-case and upper-case variant of
> Woojung Huh' s email address.
> 
> Only keep the lower-case variant in MAINTAINERS.
> 
> Signed-off-by: Lukas Bulwahn 

Acked-by: Woojung Huh 


[PATCH v2 1/4] power: supply: max17040: Add IRQ handler for low SOC alert

2019-04-14 Thread Matheus Castello
According datasheet max17040 has a pin for alert host for low SOC.
This pin can be used as external interrupt, so we need to check for
interrupts assigned for device and handle it.

In hadler we are checking and storing fuel gauge registers values
and send an uevent to notificate user space, so user space can decide
save work or turn off since the alert demonstrate that the battery may
no have the power to keep the system turned on for much longer.

Signed-off-by: Matheus Castello 
---
 drivers/power/supply/max17040_battery.c | 69 +++--
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/drivers/power/supply/max17040_battery.c 
b/drivers/power/supply/max17040_battery.c
index 91cafc7bed30..8d2f8ed3f44c 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -160,21 +161,40 @@ static void max17040_get_status(struct i2c_client *client)
chip->status = POWER_SUPPLY_STATUS_FULL;
 }
 
+static void max17040_check_changes(struct i2c_client *client)
+{
+   max17040_get_vcell(client);
+   max17040_get_soc(client);
+   max17040_get_online(client);
+   max17040_get_status(client);
+}
+
 static void max17040_work(struct work_struct *work)
 {
struct max17040_chip *chip;
 
chip = container_of(work, struct max17040_chip, work.work);
-
-   max17040_get_vcell(chip->client);
-   max17040_get_soc(chip->client);
-   max17040_get_online(chip->client);
-   max17040_get_status(chip->client);
+   max17040_check_changes(chip->client);
 
queue_delayed_work(system_power_efficient_wq, >work,
   MAX17040_DELAY);
 }
 
+static irqreturn_t max17040_thread_handler(int id, void *dev)
+{
+   struct max17040_chip *chip = dev;
+   struct i2c_client *client = chip->client;
+
+   dev_warn(>dev, "IRQ: Alert battery low level");
+   /* read registers */
+   max17040_check_changes(chip->client);
+
+   /* send uevent */
+   power_supply_changed(chip->battery);
+
+   return IRQ_HANDLED;
+}
+
 static enum power_supply_property max17040_battery_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
@@ -217,6 +237,27 @@ static int max17040_probe(struct i2c_client *client,
return PTR_ERR(chip->battery);
}
 
+   /* check interrupt */
+   if (client->irq) {
+   int ret;
+   unsigned int flags;
+
+   dev_info(>dev, "IRQ: enabled\n");
+   flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
+
+   ret = devm_request_threaded_irq(>dev, client->irq, NULL,
+   max17040_thread_handler, flags,
+   chip->battery->desc->name,
+   chip);
+
+   if (ret) {
+   client->irq = 0;
+   if (ret != -EBUSY)
+   dev_warn(>dev,
+   "Failed to get IRQ err %d\n", ret);
+   }
+   }
+
max17040_reset(client);
max17040_get_version(client);
 
@@ -224,6 +265,8 @@ static int max17040_probe(struct i2c_client *client,
queue_delayed_work(system_power_efficient_wq, >work,
   MAX17040_DELAY);
 
+   device_init_wakeup(>dev, 1);
+
return 0;
 }
 
@@ -244,6 +287,14 @@ static int max17040_suspend(struct device *dev)
struct max17040_chip *chip = i2c_get_clientdata(client);
 
cancel_delayed_work(>work);
+
+   if (client->irq) {
+   if (device_may_wakeup(dev))
+   enable_irq_wake(client->irq);
+   else
+   disable_irq_wake(client->irq);
+   }
+
return 0;
 }
 
@@ -254,6 +305,14 @@ static int max17040_resume(struct device *dev)
 
queue_delayed_work(system_power_efficient_wq, >work,
   MAX17040_DELAY);
+
+   if (client->irq) {
+   if (device_may_wakeup(dev))
+   disable_irq_wake(client->irq);
+   else
+   enable_irq_wake(client->irq);
+   }
+
return 0;
 }
 
-- 
2.17.0



[PATCH v2 2/4] dt-bindings: power: supply: Max17040: Add low level SOC alert threshold

2019-04-14 Thread Matheus Castello
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.

Signed-off-by: Matheus Castello 
---
 .../power/supply/max17040_battery.txt | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/supply/max17040_battery.txt

diff --git 
a/Documentation/devicetree/bindings/power/supply/max17040_battery.txt 
b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt
new file mode 100644
index ..9b2cc67d556f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt
@@ -0,0 +1,24 @@
+max17040_battery
+
+
+Required properties :
+ - compatible : "maxim,max17040" or "maxim,max77836-battery"
+
+Optional properties :
+- maxim,alert-soc-level :  The alert threshold that sets the state of
+   charge level where an interrupt is generated.
+   Can be configured from 1 up to 32. If skipped
+   the power up default value of 4 will be used.
+- interrupt-parent :   The GPIO bank from the interrupt line.
+- interrupts : Interrupt line see 
Documentation/devicetree/
+   bindings/interrupt-controller/interrupts.txt
+
+Example:
+
+   battery-charger@36 {
+   compatible = "maxim,max17040";
+   reg = <0x36>;
+   maxim,alert-soc-level = <10>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   };
-- 
2.17.0



[PATCH v2 3/4] power: supply: max17040: Config alert SOC low level threshold from FDT

2019-04-14 Thread Matheus Castello
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device tree node.

Now we can use "maxim,alert-soc-level" property with the values from
1 up to 32 to configure alert interrupt threshold.

Signed-off-by: Matheus Castello 
---
 drivers/power/supply/max17040_battery.c | 56 ++---
 1 file changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/power/supply/max17040_battery.c 
b/drivers/power/supply/max17040_battery.c
index 8d2f8ed3f44c..f036f272d52f 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -29,6 +29,9 @@
 #define MAX17040_DELAY 1000
 #define MAX17040_BATTERY_FULL  95
 
+#define MAX17040_ATHD_MASK 0xFFE0
+#define MAX17040_ATHD_DEFAULT_POWER_UP 4
+
 struct max17040_chip {
struct i2c_client   *client;
struct delayed_work work;
@@ -43,6 +46,8 @@ struct max17040_chip {
int soc;
/* State Of Charge */
int status;
+   /* Alert threshold from 32% to 1% of the State of Charge */
+   u32 alert_threshold;
 };
 
 static int max17040_get_property(struct power_supply *psy,
@@ -119,6 +124,27 @@ static void max17040_get_soc(struct i2c_client *client)
chip->soc = (soc >> 8);
 }
 
+static int max17040_set_soc_threshold(struct i2c_client *client, u32 level)
+{
+   int ret;
+   u16 data;
+
+   /* check if level is between 1% and 32% */
+   if (level > 0 && level < 33) {
+   /* alert threshold use LSb 5 bits from RCOMP */
+   level = 32 - level;
+   data = max17040_read_reg(client, MAX17040_RCOMP);
+   data &= MAX17040_ATHD_MASK;
+   data |= level;
+   max17040_write_reg(client, MAX17040_RCOMP, data);
+   ret = 0;
+   } else {
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
 static void max17040_get_version(struct i2c_client *client)
 {
u16 version;
@@ -161,6 +187,16 @@ static void max17040_get_status(struct i2c_client *client)
chip->status = POWER_SUPPLY_STATUS_FULL;
 }
 
+static void max17040_get_of_data(struct max17040_chip *chip)
+{
+   struct device *dev = >client->dev;
+   struct device_node *np = dev->of_node;
+
+   if (of_property_read_u32(np, "maxim,alert-soc-level",
+   >alert_threshold))
+   chip->alert_threshold = MAX17040_ATHD_DEFAULT_POWER_UP;
+}
+
 static void max17040_check_changes(struct i2c_client *client)
 {
max17040_get_vcell(client);
@@ -226,6 +262,7 @@ static int max17040_probe(struct i2c_client *client,
 
chip->client = client;
chip->pdata = client->dev.platform_data;
+   max17040_get_of_data(chip);
 
i2c_set_clientdata(client, chip);
psy_cfg.drv_data = chip;
@@ -237,16 +274,26 @@ static int max17040_probe(struct i2c_client *client,
return PTR_ERR(chip->battery);
}
 
+   max17040_reset(client);
+   max17040_get_version(client);
+
/* check interrupt */
if (client->irq) {
int ret;
-   unsigned int flags;
+
+   ret = max17040_set_soc_threshold(client, chip->alert_threshold);
+   if (ret) {
+   dev_err(>dev,
+   "Failed to set SOC alert threshold: err %d\n",
+   ret);
+   return ret;
+   }
 
dev_info(>dev, "IRQ: enabled\n");
-   flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
 
ret = devm_request_threaded_irq(>dev, client->irq, NULL,
-   max17040_thread_handler, flags,
+   max17040_thread_handler,
+   (client->flags | IRQF_ONESHOT),
chip->battery->desc->name,
chip);
 
@@ -258,9 +305,6 @@ static int max17040_probe(struct i2c_client *client,
}
}
 
-   max17040_reset(client);
-   max17040_get_version(client);
-
INIT_DEFERRABLE_WORK(>work, max17040_work);
queue_delayed_work(system_power_efficient_wq, >work,
   MAX17040_DELAY);
-- 
2.17.0



[PATCH v2 4/4] power: supply: max17040: Send uevent in SOC changes

2019-04-14 Thread Matheus Castello
Notify core through power_supply_changed() in case of changes in state
of charge. This is useful for user-space to efficiently update current
battery level.

Signed-off-by: Matheus Castello 
---
 drivers/power/supply/max17040_battery.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/power/supply/max17040_battery.c 
b/drivers/power/supply/max17040_battery.c
index f036f272d52f..db901ebf495d 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -208,10 +208,17 @@ static void max17040_check_changes(struct i2c_client 
*client)
 static void max17040_work(struct work_struct *work)
 {
struct max17040_chip *chip;
+   int last_soc;
 
chip = container_of(work, struct max17040_chip, work.work);
+   /* store SOC for check change */
+   last_soc = chip->soc;
max17040_check_changes(chip->client);
 
+   /* check changes and send uevent */
+   if (last_soc != chip->soc)
+   power_supply_changed(chip->battery);
+
queue_delayed_work(system_power_efficient_wq, >work,
   MAX17040_DELAY);
 }
-- 
2.17.0



Re: [PATCH] PCI: rockchip: fix bitwise operations on status and ROCKCHIP_PCIE_EP_CMD_STATUS_IS

2019-04-14 Thread Shawn Lin



On 2019/4/12 17:51, Lorenzo Pieralisi wrote:

On Sat, Mar 30, 2019 at 03:09:10PM +, Colin King wrote:

From: Colin Ian King 

Currently the bitwise operations on the u16 variable 'status' with
the setting ROCKCHIP_PCIE_EP_CMD_STATUS_IS are incorrect because
ROCKCHIP_PCIE_EP_CMD_STATUS_IS is 1UL<<19 which is wider than the
u16 variable.  Fix this by making status a u32.  (Not tested).

Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe 
controller")
Signed-off-by: Colin Ian King 
---
  drivers/pci/controller/pcie-rockchip-ep.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Shawn,

I need your ACK on this patch, thanks.


Acked-by: Shawn Lin 



Lorenzo


diff --git a/drivers/pci/controller/pcie-rockchip-ep.c 
b/drivers/pci/controller/pcie-rockchip-ep.c
index a5d799e2dff2..d743b0a48988 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -350,7 +350,7 @@ static void rockchip_pcie_ep_assert_intx(struct 
rockchip_pcie_ep *ep, u8 fn,
struct rockchip_pcie *rockchip = >rockchip;
u32 r = ep->max_regions - 1;
u32 offset;
-   u16 status;
+   u32 status;
u8 msg_code;
  
  	if (unlikely(ep->irq_pci_addr != ROCKCHIP_PCIE_EP_PCI_LEGACY_IRQ_ADDR ||

--
2.20.1










[PATCH v2 0/4] power: supply: MAX17040: Add IRQ for low level and alert SOC changes

2019-04-14 Thread Matheus Castello
This series add IRQ handler for low level SOC alert, define a devicetree 
binding attribute to configure the alert level threshold and check for
changes in SOC for send uevents.

Max17040 have a pin for alert host about low level state of charge and
this alert can be configured in a threshold from 1% up to 32% of SOC.

Tested on Toradex Colibri iMX7D, with a SparkFun Lipo Fuel Gauge module
based on MAXIM MAX17043.

Thanks Krzysztof Kozlowski for your time reviewing it, and forgive me for
the delay in working on it, now I'm back to the patchs. Let me know what
you think about the fixes and I'm open to maintainers suggestions.

Changes since v1:
(Suggested by Krzysztof Kozlowski)
- Put common code from max17040_work and max17040_thread_handler in a function
- Code style fixes
- Define mask and low level threshold alert default
- Check return value from max17040_set_soc_threshold
- Set low level state of charge threshold before IRQ
- CC maintainers from drivers/mfd/max14577
- Use flags from FDT client->flags instead hard coded it
- Mention interrupts on DT Documentation
- Fix "maxim,max77836-battery" missed from DT Documentation
- Fix commit description

Matheus Castello (4):
  power: supply: max17040: Add IRQ handler for low SOC alert
  dt-bindings: power: supply: Max17040: Add low level SOC alert
threshold
  power: supply: max17040: Config alert SOC low level threshold from FDT
  power: supply: max17040: Send uevent in SOC changes

 .../power/supply/max17040_battery.txt |  24 
 drivers/power/supply/max17040_battery.c   | 118 +-
 2 files changed, 138 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/supply/max17040_battery.txt

-- 
2.17.0



63c35ea6b8 ("x86/stacktrace: Use common infrastructure"): BUG: kernel hang in early-boot stage, last printk: early console in setup code

2019-04-14 Thread kernel test robot
Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/stacktrace

commit 63c35ea6b829a0f98d307a8dec038095681ecd13
Author: Thomas Gleixner 
AuthorDate: Thu Apr 11 12:52:04 2019 +0200
Commit: Thomas Gleixner 
CommitDate: Sun Apr 14 22:44:04 2019 +0200

x86/stacktrace: Use common infrastructure

Replace the stack_trace_save*() functions with the new arch_stack_walk()
interfaces.

Signed-off-by: Thomas Gleixner 

0245694164  stacktrace: Provide common infrastructure
63c35ea6b8  x86/stacktrace: Use common infrastructure
13adc4ee15  Merge branch 'WIP.locking/core'
+-++++
| | 
0245694164 | 63c35ea6b8 | 13adc4ee15 |
+-++++
| boot_successes  | 
32 | 0  | 11 |
| boot_failures   | 
1  | 13 ||
| BUG:kernel_reboot-without-warning_in_test_stage | 
1  |||
| BUG:kernel_hang_in_early-boot_stage,last_printk:early_console_in_setup_code | 
0  | 13 ||
+-++++

If you fix the issue, kindly add following tag
Reported-by: kernel test robot 

early console in setup code
BUG: kernel hang in early-boot stage, last printk: early console in setup code
Linux version 5.1.0-rc4-00302-g63c35ea #39
Command line: root=/dev/ram0 hung_task_panic=1 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 
printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic 
load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err 
ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 
vga=normal rw 
link=/cephfs/kbuild/run-queue/kvm/i386-randconfig-n3-201915/tip:WIP.core:stacktrace:63c35ea6b829a0f98d307a8dec038095681ecd13/.vmlinuz-63c35ea6b829a0f98d307a8dec038095681ecd13-20190415064514-2:yocto-vm-yocto-219
 branch=tip/WIP.core/stacktrace 
BOOT_IMAGE=/pkg/linux/i386-randconfig-n3-201915/gcc-7/63c35ea6b829a0f98d307a8dec038095681ecd13/vmlinuz-5.1.0-rc4-00302-g63c35ea
 drbd.minor_count=8 rcuperf.shutdown=0


  # HH:MM RESULT GOOD 
BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start 63c35ea6b829a0f98d307a8dec038095681ecd13 
4443f8e6ac7755cd775c70d08be8042dc2f936cb --
git bisect good 9da0899ac5cf06270762b0b530e7cd49e1a97759  # 08:27  G 10 
00   0  latency_top: Simplify stack trace handling
git bisect good 6f9fad69e30495d9b3c62cf696b7abf68192a400  # 08:33  G 10 
00   0  lockdep: Remove unused trace argument from print_circular_bug()
git bisect good c6b01c6ce59d329cd1f749faec3034809792d4c4  # 08:40  G 10 
00   0  tracing: Simplify stack trace retrieval
git bisect good 150bf3fe05c88b76bea37253b9993dd89e58dc2f  # 08:47  G 11 
00   0  stacktrace: Remove obsolete functions
git bisect good 5468565682413ae5a788b1875bbd7e762c910cf9  # 08:53  G 10 
01   1  lib/stackdepot: Remove obsolete functions
git bisect good 0245694164748e86f0ca565c2d519db1c968dcb1  # 09:06  G 11 
00   0  stacktrace: Provide common infrastructure
# first bad commit: [63c35ea6b829a0f98d307a8dec038095681ecd13] x86/stacktrace: 
Use common infrastructure
git bisect good 0245694164748e86f0ca565c2d519db1c968dcb1  # 09:12  G 31 
00   1  stacktrace: Provide common infrastructure
# extra tests with debug options
# extra tests on HEAD of tip/WIP.core/stacktrace
git bisect  bad 63c35ea6b829a0f98d307a8dec038095681ecd13  # 09:15  B  0
13   30   0  x86/stacktrace: Use common infrastructure
# extra tests on tree/branch tip/WIP.core/stacktrace
git bisect  bad 63c35ea6b829a0f98d307a8dec038095681ecd13  # 09:15  B  0
13   30   0  x86/stacktrace: Use common infrastructure
# extra tests with first bad commit reverted
git bisect good 0d34fc29df83b253f1289f69a8cea220358f651b  # 09:23  G 11 
00   0  Revert "x86/stacktrace: Use common infrastructure"
# extra tests on tree/branch tip/master
git bisect good 13adc4ee15853b456b55c061aa081df482a90fc1  # 09:27  G 10 
00   0  Merge branch 'WIP.locking/core'

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


dmesg-yocto-vm-yocto-219:20190415075307:i386-randconfig-n3-201915:5.1.0-rc4-00302-g63c35ea:39.gz
Description: 

[tip:WIP.core/stacktrace 34/47] drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 'stack_trace_snprintf'

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 6476291d5b823a05b9c903a65a5f6e6026a02606 [34/47] drm: Simplify 
stacktrace handling
config: i386-randconfig-a1-201915 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 6476291d5b823a05b9c903a65a5f6e6026a02606
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_mm.c: In function 'show_leaks':
>> drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 
>> 'stack_trace_snprintf' [-Werror=implicit-function-declaration]
  stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 0);
  ^
   cc1: some warnings being treated as errors

vim +/stack_trace_snprintf +136 drivers/gpu/drm/drm_mm.c

   116  
   117  static void show_leaks(struct drm_mm *mm)
   118  {
   119  struct drm_mm_node *node;
   120  unsigned long *entries;
   121  unsigned int nr_entries;
   122  char *buf;
   123  
   124  buf = kmalloc(BUFSZ, GFP_KERNEL);
   125  if (!buf)
   126  return;
   127  
   128  list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
   129  if (!node->stack) {
   130  DRM_ERROR("node [%08llx + %08llx]: unknown 
owner\n",
   131node->start, node->size);
   132  continue;
   133  }
   134  
   135  nr_entries = stack_depot_fetch(node->stack, );
 > 136  stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 
 > 0);
   137  DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
   138node->start, node->size, buf);
   139  }
   140  
   141  kfree(buf);
   142  }
   143  

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 24/47] mm/slab.c:1490:11: error: 'trace' undeclared

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: c79cc35c00e9f15a9a32a08569036cb8365c8816 [24/47] mm/slab: Simplify 
stack trace handling
config: i386-randconfig-a1-201915 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout c79cc35c00e9f15a9a32a08569036cb8365c8816
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1490:11: error: 'trace' undeclared (first use in this function)
  addr += trace.nr_entries;
  ^
   mm/slab.c:1490:11: note: each undeclared identifier is reported only once 
for each function it appears in

vim +/trace +1490 mm/slab.c

^1da177e Linus Torvalds  2005-04-16  1468  
^1da177e Linus Torvalds  2005-04-16  1469  #ifdef CONFIG_DEBUG_PAGEALLOC
343e0d7a Pekka Enberg2006-02-01  1470  static void store_stackinfo(struct 
kmem_cache *cachep, unsigned long *addr,
^1da177e Linus Torvalds  2005-04-16  1471   unsigned 
long caller)
^1da177e Linus Torvalds  2005-04-16  1472  {
b8623975 Thomas Gleixner 2019-04-08  1473   int size = cachep->object_size 
/ sizeof(unsigned long);
^1da177e Linus Torvalds  2005-04-16  1474  
3dafccf2 Manfred Spraul  2006-02-01  1475   addr = (unsigned long *)&((char 
*)addr)[obj_offset(cachep)];
^1da177e Linus Torvalds  2005-04-16  1476  
b8623975 Thomas Gleixner 2019-04-08  1477   if (size < 5)
^1da177e Linus Torvalds  2005-04-16  1478   return;
^1da177e Linus Torvalds  2005-04-16  1479  
^1da177e Linus Torvalds  2005-04-16  1480   *addr++ = 0x12345678;
^1da177e Linus Torvalds  2005-04-16  1481   *addr++ = caller;
^1da177e Linus Torvalds  2005-04-16  1482   *addr++ = smp_processor_id();
b8623975 Thomas Gleixner 2019-04-08  1483   size -= 3;
b8623975 Thomas Gleixner 2019-04-08  1484  #ifdef CONFIG_STACKTRACE
^1da177e Linus Torvalds  2005-04-16  1485   {
c79cc35c Thomas Gleixner 2019-04-14  1486   unsigned int nr_entries;
^1da177e Linus Torvalds  2005-04-16  1487  
c79cc35c Thomas Gleixner 2019-04-14  1488   /* Leave one for the 
end marker below */
c79cc35c Thomas Gleixner 2019-04-14  1489   nr_entries = 
stack_trace_save(addr, size - 1, 3);
b8623975 Thomas Gleixner 2019-04-08 @1490   addr += 
trace.nr_entries;
^1da177e Linus Torvalds  2005-04-16  1491   }
b8623975 Thomas Gleixner 2019-04-08  1492  #endif
b8623975 Thomas Gleixner 2019-04-08  1493   *addr = 0x87654321;
^1da177e Linus Torvalds  2005-04-16  1494  }
40b44137 Joonsoo Kim 2016-03-15  1495  

:: The code at line 1490 was first introduced by commit
:: b86239751f8c4d6fc43f6a9eca29e77b0319f5d7 mm/slab: Fix broken stack trace 
storage

:: TO: Thomas Gleixner 
:: CC: Thomas Gleixner 

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


.config.gz
Description: application/gzip


[PATCH v4 02/11] PCI: imx6: Drop imx6_pcie_wait_for_link()

2019-04-14 Thread Andrey Smirnov
All calls to imx6_pcie_wait_for_link() share the same error path and
the state of PHY debug registers will already be printed there, so
there's no real reason we can't just use dw_pcie_wait_for_link(). Drop
imx6_pcie_wait_for_link() and replace it with dw_pcie_wait_for_link().

Signed-off-by: Andrey Smirnov 
Suggested-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index ea2617712a3b..bb3dcfdbf697 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -723,21 +723,6 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
return 0;
 }
 
-static int imx6_pcie_wait_for_link(struct imx6_pcie *imx6_pcie)
-{
-   struct dw_pcie *pci = imx6_pcie->pci;
-   struct device *dev = pci->dev;
-
-   /* check if the link is up or not */
-   if (!dw_pcie_wait_for_link(pci))
-   return 0;
-
-   dev_dbg(dev, "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
-   return -ETIMEDOUT;
-}
-
 static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 {
struct dw_pcie *pci = imx6_pcie->pci;
@@ -796,7 +781,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
/* Start LTSSM. */
imx6_pcie_ltssm_enable(dev);
 
-   ret = imx6_pcie_wait_for_link(imx6_pcie);
+   ret = dw_pcie_wait_for_link(pci);
if (ret)
goto err_reset_phy;
 
@@ -834,7 +819,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
}
 
/* Make sure link training is finished as well! */
-   ret = imx6_pcie_wait_for_link(imx6_pcie);
+   ret = dw_pcie_wait_for_link(pci);
if (ret) {
dev_err(dev, "Failed to bring link up!\n");
goto err_reset_phy;
-- 
2.20.1



[PATCH v4 05/11] PCI: dwc: imx6: Share PHY debug register definitions

2019-04-14 Thread Andrey Smirnov
Both pcie-designware.c and pci-imx6.c contain custom definitions for
PHY debug registers R0/R1 and on top of that there's already a
definition for R0 in pcie-designware.h. Move all of the definitions to
pcie-designware.h. No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c|  6 ++
 drivers/pci/controller/dwc/pcie-designware.c | 12 +++-
 drivers/pci/controller/dwc/pcie-designware.h |  3 +++
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c0867df090f5..eeacdebd9b50 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -103,8 +103,6 @@ struct imx6_pcie {
 
 /* PCIe Port Logic registers (memory-mapped) */
 #define PL_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
-#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
 
 #define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
 #define PCIE_PHY_CTRL_DATA_LOC 0
@@ -831,8 +829,8 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
 
 err_reset_phy:
dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n",
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
+   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0),
+   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1));
imx6_pcie_reset_phy(imx6_pcie);
return ret;
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 31f6331ca46f..086e87a40316 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -14,12 +14,6 @@
 
 #include "pcie-designware.h"
 
-/* PCIe Port Logic registers */
-#define PLR_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R1  (PLR_OFFSET + 0x2c)
-#define PCIE_PHY_DEBUG_R1_LINK_UP  (0x1 << 4)
-#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
-
 int dw_pcie_read(void __iomem *addr, int size, u32 *val)
 {
if (!IS_ALIGNED((uintptr_t)addr, size)) {
@@ -334,9 +328,9 @@ int dw_pcie_link_up(struct dw_pcie *pci)
if (pci->ops->link_up)
return pci->ops->link_up(pci);
 
-   val = readl(pci->dbi_base + PCIE_PHY_DEBUG_R1);
-   return ((val & PCIE_PHY_DEBUG_R1_LINK_UP) &&
-   (!(val & PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING)));
+   val = readl(pci->dbi_base + PCIE_PORT_DEBUG1);
+   return ((val & PCIE_PORT_DEBUG1_LINK_UP) &&
+   (!(val & PCIE_PORT_DEBUG1_LINK_IN_TRAINING)));
 }
 
 void dw_pcie_setup(struct dw_pcie *pci)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 377f4c0b52da..b33ae13194be 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -41,6 +41,9 @@
 #define PCIE_PORT_DEBUG0   0x728
 #define PORT_LOGIC_LTSSM_STATE_MASK0x1f
 #define PORT_LOGIC_LTSSM_STATE_L0  0x11
+#define PCIE_PORT_DEBUG1   0x72C
+#define PCIE_PORT_DEBUG1_LINK_UP   BIT(4)
+#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING  BIT(29)
 
 #define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
 #define PORT_LOGIC_SPEED_CHANGEBIT(17)
-- 
2.20.1



[PATCH v4 03/11] PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change()

2019-04-14 Thread Andrey Smirnov
Change error code from EINVAL to ETIMEDOUT in
imx6_pcie_wait_for_speed_change() since that error code seems more
appropriate.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index bb3dcfdbf697..021ef121a058 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -739,7 +739,7 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie 
*imx6_pcie)
}
 
dev_err(dev, "Speed change timeout\n");
-   return -EINVAL;
+   return -ETIMEDOUT;
 }
 
 static void imx6_pcie_ltssm_enable(struct device *dev)
-- 
2.20.1



[PATCH v4 08/11] PCI: imx6: Simplify pcie_phy_poll_ack()

2019-04-14 Thread Andrey Smirnov
Simplify pcie_phy_poll_ack() by incorporating shifting into constant
definition and convert the code to use 'bool'. No functional change
intended.

Signed-off-by: Andrey Smirnov 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 669e01353026..3fd084357488 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -112,7 +112,7 @@ struct imx6_pcie {
 #define PCIE_PHY_CTRL_RD   BIT(19)
 
 #define PCIE_PHY_STAT (PL_OFFSET + 0x110)
-#define PCIE_PHY_STAT_ACK_LOC 16
+#define PCIE_PHY_STAT_ACK  BIT(16)
 
 #define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
 
@@ -151,16 +151,16 @@ struct imx6_pcie {
 #define PHY_RX_OVRD_IN_LO_RX_DATA_EN   BIT(5)
 #define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
 
-static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
+static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   u32 val;
+   bool val;
u32 max_iterations = 10;
u32 wait_counter = 0;
 
do {
-   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
-   val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
+   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT) &
+   PCIE_PHY_STAT_ACK;
wait_counter++;
 
if (val == exp_val)
@@ -184,14 +184,14 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
val |= PCIE_PHY_CTRL_CAP_ADR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
-   ret = pcie_phy_poll_ack(imx6_pcie, 1);
+   ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
 
val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
-   return pcie_phy_poll_ack(imx6_pcie, 0);
+   return pcie_phy_poll_ack(imx6_pcie, false);
 }
 
 /* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
@@ -209,7 +209,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
phy_ctl = PCIE_PHY_CTRL_RD;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
 
-   ret = pcie_phy_poll_ack(imx6_pcie, 1);
+   ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
 
@@ -219,7 +219,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
/* deassert Read signal */
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, 0x00);
 
-   return pcie_phy_poll_ack(imx6_pcie, 0);
+   return pcie_phy_poll_ack(imx6_pcie, false);
 }
 
 static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, int data)
@@ -241,7 +241,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
var |= PCIE_PHY_CTRL_CAP_DAT;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
-   ret = pcie_phy_poll_ack(imx6_pcie, 1);
+   ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
 
@@ -250,7 +250,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
-   ret = pcie_phy_poll_ack(imx6_pcie, 0);
+   ret = pcie_phy_poll_ack(imx6_pcie, false);
if (ret)
return ret;
 
@@ -259,7 +259,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack */
-   ret = pcie_phy_poll_ack(imx6_pcie, 1);
+   ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
 
@@ -268,7 +268,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
-   ret = pcie_phy_poll_ack(imx6_pcie, 0);
+   ret = pcie_phy_poll_ack(imx6_pcie, false);
if (ret)
return ret;
 
-- 
2.20.1



[PATCH v4 06/11] PCI: imx6: Make use of BIT() in constant definitions

2019-04-14 Thread Andrey Smirnov
Avoid using explicit left shifts and convert various definitions to
use BIT() instead. No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index eeacdebd9b50..5650642ab248 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -118,14 +118,14 @@ struct imx6_pcie {
 
 /* PHY registers (not memory-mapped) */
 #define PCIE_PHY_ATEOVRD   0x10
-#define  PCIE_PHY_ATEOVRD_EN   (0x1 << 2)
+#define  PCIE_PHY_ATEOVRD_EN   BIT(2)
 #define  PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT 0
 #define  PCIE_PHY_ATEOVRD_REF_CLKDIV_MASK  0x1
 
 #define PCIE_PHY_MPLL_OVRD_IN_LO   0x11
 #define  PCIE_PHY_MPLL_MULTIPLIER_SHIFT2
 #define  PCIE_PHY_MPLL_MULTIPLIER_MASK 0x7f
-#define  PCIE_PHY_MPLL_MULTIPLIER_OVRD (0x1 << 9)
+#define  PCIE_PHY_MPLL_MULTIPLIER_OVRD BIT(9)
 
 #define PCIE_PHY_RX_ASIC_OUT 0x100D
 #define PCIE_PHY_RX_ASIC_OUT_VALID (1 << 0)
@@ -148,8 +148,8 @@ struct imx6_pcie {
 #define PCIE_PHY_CMN_REG26_ATT_MODE0xBC
 
 #define PHY_RX_OVRD_IN_LO 0x1005
-#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
-#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
+#define PHY_RX_OVRD_IN_LO_RX_DATA_EN   BIT(5)
+#define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
 {
-- 
2.20.1



[PATCH v4 09/11] PCI: imx6: Restrict PHY register data to 16-bit

2019-04-14 Thread Andrey Smirnov
PHY registers on i.MX6 are 16-bit wide, so we can get rid of explicit
masking if we restrict pcie_phy_read/pcie_phy_write to use 'u16'
instead of 'int'. No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 3fd084357488..30e764b6cbcc 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -195,10 +195,10 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
 }
 
 /* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
-static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, int *data)
+static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, u16 *data)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   u32 val, phy_ctl;
+   u32 phy_ctl;
int ret;
 
ret = pcie_phy_wait_ack(imx6_pcie, addr);
@@ -213,8 +213,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
if (ret)
return ret;
 
-   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
-   *data = val & 0x;
+   *data = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
 
/* deassert Read signal */
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, 0x00);
@@ -222,7 +221,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
return pcie_phy_poll_ack(imx6_pcie, false);
 }
 
-static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, int data)
+static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 {
struct dw_pcie *pci = imx6_pcie->pci;
u32 var;
@@ -279,7 +278,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
 
 static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
-   u32 tmp;
+   u16 tmp;
 
if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
return;
@@ -675,7 +674,7 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
int mult, div;
-   u32 val;
+   u16 val;
 
if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
return 0;
-- 
2.20.1



[PATCH v4 04/11] PCI: imx6: Remove PCIE_PL_PFLR_* constants

2019-04-14 Thread Andrey Smirnov
Code using these constants was removed in commit a71280722eeb ("PCI:
imx6: Remove LTSSM disable workaround"). No functional change
intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 021ef121a058..c0867df090f5 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -103,9 +103,6 @@ struct imx6_pcie {
 
 /* PCIe Port Logic registers (memory-mapped) */
 #define PL_OFFSET 0x700
-#define PCIE_PL_PFLR (PL_OFFSET + 0x08)
-#define PCIE_PL_PFLR_LINK_STATE_MASK   (0x3f << 16)
-#define PCIE_PL_PFLR_FORCE_LINK(1 << 15)
 #define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
 #define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
 
-- 
2.20.1



[PATCH v4 01/11] PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock()

2019-04-14 Thread Andrey Smirnov
Make use of regmap_read_poll_timeout() to simplify
imx7d_pcie_wait_for_phy_pll_lock(). No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 3d627f94a166..ea2617712a3b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -89,9 +89,8 @@ struct imx6_pcie {
 };
 
 /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
-#define PHY_PLL_LOCK_WAIT_MAX_RETRIES  2000
-#define PHY_PLL_LOCK_WAIT_USLEEP_MIN   50
 #define PHY_PLL_LOCK_WAIT_USLEEP_MAX   200
+#define PHY_PLL_LOCK_WAIT_TIMEOUT  (2000 * PHY_PLL_LOCK_WAIT_USLEEP_MAX)
 
 /* PCIe Root Complex registers (memory-mapped) */
 #define PCIE_RC_IMX6_MSI_CAP   0x50
@@ -488,20 +487,14 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 {
u32 val;
-   unsigned int retries;
struct device *dev = imx6_pcie->pci->dev;
 
-   for (retries = 0; retries < PHY_PLL_LOCK_WAIT_MAX_RETRIES; retries++) {
-   regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR22, );
-
-   if (val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED)
-   return;
-
-   usleep_range(PHY_PLL_LOCK_WAIT_USLEEP_MIN,
-PHY_PLL_LOCK_WAIT_USLEEP_MAX);
-   }
-
-   dev_err(dev, "PCIe PLL lock timeout\n");
+   if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+IOMUXC_GPR22, val,
+val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED,
+PHY_PLL_LOCK_WAIT_USLEEP_MAX,
+PHY_PLL_LOCK_WAIT_TIMEOUT))
+   dev_err(dev, "PCIe PLL lock timeout\n");
 }
 
 static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
-- 
2.20.1



[PATCH v4 07/11] PCI: imx6: Simplify bit operations in PHY functions

2019-04-14 Thread Andrey Smirnov
Simplify the code by incorporating left shifts into constant
defnitions as well as using FIELD_PREP/GENMASK. No functional change
intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 28 +--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 5650642ab248..669e01353026 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -105,11 +105,11 @@ struct imx6_pcie {
 #define PL_OFFSET 0x700
 
 #define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
-#define PCIE_PHY_CTRL_DATA_LOC 0
-#define PCIE_PHY_CTRL_CAP_ADR_LOC 16
-#define PCIE_PHY_CTRL_CAP_DAT_LOC 17
-#define PCIE_PHY_CTRL_WR_LOC 18
-#define PCIE_PHY_CTRL_RD_LOC 19
+#define PCIE_PHY_CTRL_DATA(x)  FIELD_PREP(GENMASK(15, 0), (x))
+#define PCIE_PHY_CTRL_CAP_ADR  BIT(16)
+#define PCIE_PHY_CTRL_CAP_DAT  BIT(17)
+#define PCIE_PHY_CTRL_WR   BIT(18)
+#define PCIE_PHY_CTRL_RD   BIT(19)
 
 #define PCIE_PHY_STAT (PL_OFFSET + 0x110)
 #define PCIE_PHY_STAT_ACK_LOC 16
@@ -178,17 +178,17 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
u32 val;
int ret;
 
-   val = addr << PCIE_PHY_CTRL_DATA_LOC;
+   val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
-   val |= (0x1 << PCIE_PHY_CTRL_CAP_ADR_LOC);
+   val |= PCIE_PHY_CTRL_CAP_ADR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
if (ret)
return ret;
 
-   val = addr << PCIE_PHY_CTRL_DATA_LOC;
+   val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
return pcie_phy_poll_ack(imx6_pcie, 0);
@@ -206,7 +206,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
return ret;
 
/* assert Read signal */
-   phy_ctl = 0x1 << PCIE_PHY_CTRL_RD_LOC;
+   phy_ctl = PCIE_PHY_CTRL_RD;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -234,11 +234,11 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, 
int addr, int data)
if (ret)
return ret;
 
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* capture data */
-   var |= (0x1 << PCIE_PHY_CTRL_CAP_DAT_LOC);
+   var |= PCIE_PHY_CTRL_CAP_DAT;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -246,7 +246,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* deassert cap data */
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
@@ -255,7 +255,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* assert wr signal */
-   var = 0x1 << PCIE_PHY_CTRL_WR_LOC;
+   var = PCIE_PHY_CTRL_WR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack */
@@ -264,7 +264,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* deassert wr signal */
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
-- 
2.20.1



[PATCH v4 11/11] PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk()

2019-04-14 Thread Andrey Smirnov
imx6_pcie_enable_ref_clk() is never called in atomic context, so
there's no need to use udelay(). Replace it with usleep_range().

Signed-off-by: Andrey Smirnov 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 3e45f49b8a4f..c6d6bde4d860 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -449,7 +449,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
 * reset time is too short, cannot meet the requirement.
 * add one ~10us delay here.
 */
-   udelay(10);
+   usleep_range(10, 100);
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
break;
-- 
2.20.1



[PATCH v4 10/11] PCI: imx6: Use flags to indicate support for suspend

2019-04-14 Thread Andrey Smirnov
Now that driver data has flags variable that can be used to indicate
quirks/features supported we can switch the code to use it instead of
having a special function that does so based on variant alone. No
functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 30e764b6cbcc..3e45f49b8a4f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -52,6 +52,7 @@ enum imx6_pcie_variants {
 
 #define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE   BIT(1)
+#define IMX6_PCIE_FLAG_SUPPORTS_SUSPENDBIT(2)
 
 struct imx6_pcie_drvdata {
enum imx6_pcie_variants variant;
@@ -965,17 +966,11 @@ static void imx6_pcie_clk_disable(struct imx6_pcie 
*imx6_pcie)
}
 }
 
-static inline bool imx6_pcie_supports_suspend(struct imx6_pcie *imx6_pcie)
-{
-   return (imx6_pcie->drvdata->variant == IMX7D ||
-   imx6_pcie->drvdata->variant == IMX6SX);
-}
-
 static int imx6_pcie_suspend_noirq(struct device *dev)
 {
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
 
-   if (!imx6_pcie_supports_suspend(imx6_pcie))
+   if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
 
imx6_pcie_pm_turnoff(imx6_pcie);
@@ -991,7 +986,7 @@ static int imx6_pcie_resume_noirq(struct device *dev)
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
struct pcie_port *pp = _pcie->pci->pp;
 
-   if (!imx6_pcie_supports_suspend(imx6_pcie))
+   if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
 
imx6_pcie_assert_core_reset(imx6_pcie);
@@ -1221,7 +1216,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
[IMX6SX] = {
.variant = IMX6SX,
.flags = IMX6_PCIE_FLAG_IMX6_PHY |
-IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
+IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
+IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
},
[IMX6QP] = {
.variant = IMX6QP,
@@ -1230,6 +1226,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
},
[IMX7D] = {
.variant = IMX7D,
+   .flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
},
[IMX8MQ] = {
.variant = IMX8MQ,
-- 
2.20.1



[PATCH v4 00/11] i.MX6, DesignWare PCI improvements

2019-04-14 Thread Andrey Smirnov
Everyone:

This is the series containing various small improvements that I made
while reading the code and researching commit history of pci-imx6.c
and pcie-designware*.c files. All changes are optional, so commits
that don't seem like an improvement can be easily dropped. Hopefully
each patch is self-explanatory.

I tested this series on i.MX6Q, i.MX7D and i.MX8MQ.

Feedback is welcome!

Thanks,
Andrey Smirnov

Chagnes since [v3]:

- Collected Reviewed-by from Lucas for most of the patches

- Converted "PCI: imx6: Replace calls to udelay() with
  usleep_range()" to "PCI: imx6: Use usleep_range() in
  imx6_pcie_enable_ref_clk()"
  
- Converted "PCI: imx6: Remove redundant debug tracing" to "PCI:
  imx6: Drop imx6_pcie_wait_for_link()"
  
- Converted all of the callers of pcie_phy_poll_ack() to use
  true/false in "PCI: imx6: Simplify pcie_phy_poll_ack()"

Changes since [v2]:

- All non i.MX6 patches dropped, since they were accepted as a
  seprarte series
  
- Series rebased on latest 'dwc-pci' branch of PCI tree

- Patches "PCI: imx6: Use flags to indicate support for suspend"
  and "PCI: imx6: Replace calls to udelay() with usleep_range()"
  added to the series

Changes since [v1]:

  - Dropped "PCI: imx6: Drop imx6_pcie_link_up()" due to the matter
already having been addressed by "PCI: imx6: Fix link training
status detection in link up check" from Trent Piepho

  - Changed "designware" -> "dwc" for all subject lines

  - Collected Acked-by's from Gustavo Pimentel

[v3] lkml.kernel.org/r/20190401042547.14067-1-andrew.smir...@gmail.com
[v2] lkml.kernel.org/r/20190104174925.17153-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20181221072716.29017-1-andrew.smir...@gmail.com

Andrey Smirnov (11):
  PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock()
  PCI: imx6: Drop imx6_pcie_wait_for_link()
  PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change()
  PCI: imx6: Remove PCIE_PL_PFLR_* constants
  PCI: dwc: imx6: Share PHY debug register definitions
  PCI: imx6: Make use of BIT() in constant definitions
  PCI: imx6: Simplify bit operations in PHY functions
  PCI: imx6: Simplify pcie_phy_poll_ack()
  PCI: imx6: Restrict PHY register data to 16-bit
  PCI: imx6: Use flags to indicate support for suspend
  PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk()

 drivers/pci/controller/dwc/pci-imx6.c| 143 ---
 drivers/pci/controller/dwc/pcie-designware.c |  12 +-
 drivers/pci/controller/dwc/pcie-designware.h |   3 +
 3 files changed, 62 insertions(+), 96 deletions(-)

-- 
2.20.1



Re: Kconfig dependency issue on function-graph tracer and frame pointer on arm

2019-04-14 Thread Masami Hiramatsu
On Sun, 14 Apr 2019 16:37:04 +0100
Russell King - ARM Linux admin  wrote:

> On Sun, Apr 14, 2019 at 11:52:38PM +0900, Masami Hiramatsu wrote:
> > On Sun, 14 Apr 2019 14:34:58 +0100
> > Russell King - ARM Linux admin  wrote:
> > 
> > > On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> > > > Hello,
> > > > 
> > > > Recently, Naresh reported that the function-graph tracer on the latest
> > > > kernel crashes on arm. I could reproduce it and bisected. I finally 
> > > > found
> > > > the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> > > > was the first bad commit.
> > > 
> > > I don't think that littering the rest of the kernel Kconfig with ARM
> > > specific stuff is really a viable solution to this.
> > > 
> > > If we examine the current situation, we have:
> > > 
> > > - THUMB2_KERNEL selecting ARM_UNWIND when enabled.
> > > - UNWINDER_FRAME_POINTER disabled if THUMB2_KERNEL is enabled, provided
> > >   we're not using Clang.  This leaves UNWINDER_ARM as the only choice,
> > >   which also selects ARM_UNWIND.
> > > - The default choice is dependent on the settings of AEABI and
> > >   FUNCTION_GRAPH_TRACER.
> > > - HAVE_FUNCTION_GRAPH_TRACER is disabled if THUMB2_KERNEL is enabled.
> > > 
> > > which seems to be _way_ too messy.
> > > 
> > > Looking back before this commit, the function graph tracer never had a
> > > strong dependence on frame pointers being enabled in the kernel, but it
> > > seems the code relies upon them (see ftrace_return_to_handler() in
> > > kernel/trace/ and return_to_handler in arch/arm/kernel/entry-frace.S).
> > > There is also the __ftrace_graph_caller macro which seems to rely on it.
> > 
> > Yes, so I think similar bug is hiding in other LTS kernels. It should
> > have a dependency to FRAME_POINTER on arm.
> > 
> > > Since Clang does not support frame pointers, we shouldn't even offer
> > > the function graph tracer for Clang compilers, so let's do that with
> > > the first hunk of the patch below.
> > > 
> > > The subsequent hunks remove the defaulting of the choice according to
> > > the function graph tracer - this is not a "hint" where the user can
> > > still choose either option irrespective of the state of the function
> > > graph tracer.  They should only be able to select the frame pointer
> > > option in that case.
> > 
> > Agreed. Using default for making dependency is wrong.
> > 
> > > 
> > > Another way forward would be for someone to put the work in to making
> > > the function graph tracer work without frame pointers.
> > 
> > Yes, we eventually need that. But for fixing current released kernel
> > (this bug is in v5.0 series), I think Kconfig fix is needed.
> > 
> > > 
> > > So, how about this:
> > > 
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 850b4805e2d1..9aed25a6019b 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -73,7 +73,7 @@ config ARM
> > >   select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) 
> > > && MMU
> > >   select HAVE_EXIT_THREAD
> > >   select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > > - select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
> > > + select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > >   select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > >   select HAVE_GCC_PLUGINS
> > >   select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || 
> > > CPU_V7)
> > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > > index 6d6e0330930b..e388af4594a6 100644
> > > --- a/arch/arm/Kconfig.debug
> > > +++ b/arch/arm/Kconfig.debug
> > > @@ -47,8 +47,8 @@ config DEBUG_WX
> > >  
> > >  choice
> > >   prompt "Choose kernel unwinder"
> > > - default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
> > > - default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
> > > + default UNWINDER_ARM if AEABI
> > > + default UNWINDER_FRAME_POINTER if !AEABI
> > 
> > If UNWINDER_ARM depends on ARM EABI, would we really need this "if !AEABI"?
> > (I doubt we need these default...)
> > 
> > >   help
> > > This determines which method will be used for unwinding kernel stack
> > > traces for panics, oopses, bugs, warnings, perf, /proc//stack,
> > > @@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
> > >  
> > >  config UNWINDER_ARM
> > >   bool "ARM EABI stack unwinder"
> > > - depends on AEABI
> > > + depends on AEABI && !FUNCTION_GRAPH_TRACER
> > 
> > Hmm, AFAIK, FUNCTION_GRAPH_TRACER only depends on FRAME_POINTER, but not
> > UNWINDER_FRAME_POINTER. So can user still choose UNWINDER_ARM even if
> > FUNCTION_GRAPH_TRACER=y ? (Of course that may not be a meaningful option)
> 
> The UNWINDER_* options do not control anything except whether
> FRAME_POINTER is enabled or not.  FRAME_POINTER controls not only
> whether we build with frame pointers, but also how we unwind.
> If both ARM_UNWIND and FRAME_POINTER are set, the kernel will
> fail to link due to a multiple definition of unwind_frame().

Thank 

Re: [PATCH 1/3 RFC] ARM: mvebu: at least warn on kzalloc failure

2019-04-14 Thread Nicholas Mc Guire
On Sun, Apr 14, 2019 at 06:26:02PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Apr 14, 2019 at 06:49:49AM +0200, Nicholas Mc Guire wrote:
> > Although it is very unlikely that the allocation during init would
> > fail any such failure should point to the original cause rather
> > than waiting for a null-pointer dereference to splat.
> > 
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > 
> > Problem located with experimental coccinelle script
> > 
> > While this will not really help much - but kzalloc failures should not
> > go unhandled. 
> 
> Sorry, no, not like this.
>

ok - well I wsa not sure about it either - it just seems wrong
to leave a possible allocation failure without any response.

The issue of generating excessive outout make sense - so will fix
it up to a pr_err() and resend.

thx!
hofrat
 
> With this patch, rather than getting an oops and a stacktrace which
> people can capture and email, we instead end up getting a warning
> line, a stack trace, followed by an oops containing another stack
> trace.
> 
> We _already_ have problems getting people to send us kernel message
> debug information without editing out what they deem to be "unnecessary
> verbage", like all those numbers and function names that comprise a
> stack trace.  We don't need yet more of that stuff, especially when it
> is redundant.
> 
> So, I think throwing WARN_ON() at this case is way too excessive, and
> will only have a detrimental effect on the reports we receive - and
> that is extremely important.
> 
> IMHO, A better solution would be to just print a warning, rather than
> causing the kernel to print several kB of needless messages.
> 
>   if (!new_compat)
>   pr_err("new_compat allocation failure in %s()\n",
>  __func__);
> 
> > 
> > Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
> > (with some unrelated sparse warnings about missing syscalls)
> > 
> > Patch is against 5.1-rc4 (localversion-next is 20190412)
> > 
> >  arch/arm/mach-mvebu/board-v7.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> > index 0b10acd..37f8cb6 100644
> > --- a/arch/arm/mach-mvebu/board-v7.c
> > +++ b/arch/arm/mach-mvebu/board-v7.c
> > @@ -128,6 +128,7 @@ static void __init i2c_quirk(void)
> > struct property *new_compat;
> >  
> > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> > +   WARN_ON(!new_compat);
> >  
> > new_compat->name = kstrdup("compatible", GFP_KERNEL);
> > new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> > -- 
> > 2.1.4
> > 
> > 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up


Re: [PATCH 3/3] ARM: mvebu: add SPDX license identifier

2019-04-14 Thread Nicholas Mc Guire
On Sun, Apr 14, 2019 at 06:22:10PM +0200, Andrew Lunn wrote:
> On Sun, Apr 14, 2019 at 06:49:51AM +0200, Nicholas Mc Guire wrote:
> > The license is clearly identified as GPL V2 - so just add in the
> > appropriate SPDX license identifier.
> > 
> > Signed-off-by: Nicholas Mc Guire 
> 
> Hi Nicholas
> 
> Adding a SPDX line makes the license text redundant, so you should
> remove it in the same patch as adding the SPDX line.
>
So remove that first line from this paragraph

 * This file is licensed under the terms of the GNU General Public
 * License version 2.  This program is licensed "as is" without any
 * warranty of any kind, whether express or implied.

reducing it to:

 * This program is licensed "as is" without any warranty of any kind,
 * whether express or implied.

Is that what you are proposing ?

The GPL does state that there is no warranty but using a different 
wording that may not be legally equivalent.

thx!
hofrat


Re: [PATCH 1/1] pinctrl: Add alternative way for specifying register bases

2019-04-14 Thread Sean Wang
Hi, Light

On Thu, Apr 11, 2019 at 8:15 PM Light Hsieh  wrote:
>
> The orginal PINCTRL_MTK_PARIS/PINCTRL_MTK_MOORE need more effort for
> specifying register bases when porting platform driver:
> 1. Write mt_pinctrl_register_base_name[] array in pinctrl-mt.c
>to specify names of register bases, for exmaple:
>
> static const char * const mt6765_pinctrl_register_base_names[] = {
> "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", "iocfg5",
> "iocfg6", "iocfg7",
> };
> 2. Write reg = <...>, ..., <...>; in mt.dts to specify register
>bases. Each member of reg contain address range cloned from
>pre-generated devicetree node.
> 3. Write reg-names = "...", ..., "..."; in mt.dts to specify
>names of register bases. The sequence of names in reg-names shall match
>sequence of names that specified in pinctrl-mt.c.
>Besides, the seqeunce of names in reg-names shall also match sequence of
>address range in reg, for exmaple:
>
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg = <0 0x10005000 0 0x1000>,
>   <0 0x10002C00 0 0x200>,
>   <0 0x10002800 0 0x200>,
>   <0 0x10002A00 0 0x200>,
>   <0 0x10002000 0 0x200>,
>   <0 0x10002200 0 0x200>,
>   <0 0x10002400 0 0x200>,
>   <0 0x10002600 0 0x200>,
>   <0 0x1000b000 0 0x1000>;
> reg-names = "iocfg0", "iocfg1", "iocfg2", "iocfg3",
> "iocfg4", "iocfg5", "iocfg6", "iocfg7",
> "eint";
>
> To reduce porting effort, this patch add an alternative way for specifying
> register bases:
> 1. Write reg_bases = <...>, ..., <...>; and reg_base_eint = <>;
>in mt.dtsi where members in reg_bases and  are labels for
>pre-generated devicetree nodes, for example:
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg_bases = <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>,
> <>;
> reg_base_eint = <>;

reg and reg-names both are generic properties used in all of DT-based
device and driver, described in
Documentation/devicetree/bindings/resource-names.txt, but reg_based
and reg_base_eint aren't.

If these properties are not hardware specific related, I personally
will encourage reusing those generic properties and relevant helpers
because those generic properties handling in the base driver are
almost bug-free, well maintained and even keep be extended in the
future. This way can help driver people put more concentration on
hardware specific stuff in the driver.

>
>Since this pre-generated nodes had already specify address range,
>it is not necessary to specify address range again in pinctrl node.
>
> Using this way, porting effort is reduced and therefore typo can occur with
> less chance.
>
> Change-Id: I55f5e328919f4f736ca4b9f8d1593e069f179637
> ---
>  drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +---
>  drivers/pinctrl/mediatek/pinctrl-paris.c | 62 
> 
>  2 files changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index b1c3684..16b4863 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "mtk-eint.h"
>  #include "pinctrl-mtk-common-v2.h"
> @@ -310,7 +311,7 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned 
> long eint_n)
>
>  int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
>  {
> -   struct device_node *np = pdev->dev.of_node;
> +   struct device_node *np = pdev->dev.of_node, *node;
> struct resource *res;
>
> if (!IS_ENABLED(CONFIG_EINT_MTK))
> @@ -323,13 +324,19 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct 
> platform_device *pdev)
> if (!hw->eint)
> return -ENOMEM;
>
> -   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "eint");
> -   if (!res) {
> -   dev_err(>dev, "Unable to get eint resource\n");
> -   return -ENODEV;
> +   node = of_parse_phandle(np, "reg_base_eint", 0);
> +   if (node) {
> +   hw->eint->base = of_iomap(node, 0);
> +   } else {
> +   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +   "eint");
> +   if (!res) {
> +   dev_err(>dev, "Unable to get eint 

Linux 5.1-rc5

2019-04-14 Thread Linus Torvalds
Here we go again.. It's Sunday afternoon, must mean another rc kernel.

We have changes all over, but not unseasonably many of them, and most
of the ones here are very small. Looking at the stats, the sound
driver updates kind of stand out, being almost a third of the patch
(and about a third of the commits too, so it's not because of some
single big patch). But none of it looks all that scary.

Outside of the sound fixes, another third is other drivers (gpu, rdma,
nvme, mmc, block layer..) and the last third is "misc". That includes
arch updates, tooling, and various core fixes (networking, filesystem,
security modules, and core kernel/mm).

Nothing in here makes me feel uncomfortable about this release cycle
so far. Knock wood.

Shortlog appended with an overview of the details, as usual.

Linus

---

Alex Deucher (1):
  drm/amdkfd: Add picasso pci id

Alexander Potapenko (1):
  x86/asm: Use stricter assembly constraints in bitops

Anand Jain (2):
  btrfs: prop: fix zstd compression parameter validation
  btrfs: prop: fix vanished compression property after failed set

Andre Przywara (1):
  PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller

Andrei Vagin (1):
  alarmtimer: Return correct remaining time

Annaliese McDermond (2):
  ASoC: tlv320aic32x4: Fix Common Pins
  ASoC: tlv320aic32x4: Change author's name

Ard Biesheuvel (1):
  arm64/ftrace: fix inadvertent BUG() in trampoline check

Arnaud Pouliquen (1):
  ASoC: stm32: fix sai driver name initialisation

Bart Van Assche (1):
  locking/lockdep: Zap lock classes even with lock debugging disabled

Brian Norris (1):
  Bluetooth: btusb: request wake pin with NOAUTOEN

CK Hu (2):
  drm/mediatek: Implement gem prime vmap/vunmap function
  drm/mediatek: Add Mediatek framebuffer device

Charles Keepax (6):
  ASoC: wm_adsp: Correct handling of compressed streams that restart
  ASoC: wm_adsp: Correct error messages in wm_adsp_buffer_get_error
  ASoC: wm_adsp: Add locking to wm_adsp2_bus_error
  ASoC: wm_adsp: Shutdown any compressed streams on DSP watchdog timeout
  ASoC: wm_adsp: Check for buffer in trigger stop
  ASoC: cs35l35: Disable regulators on driver removal

Chong Qiao (1):
  MIPS: KGDB: fix kgdb support for SMP platforms.

Chris Wilson (2):
  drm/i915/gvt: Annotate iomem usage
  drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt()

Christoph Hellwig (1):
  sparc64/pci_sun4v: fix ATU checks for large DMA masks

Christophe Leroy (2):
  powerpc/32: Fix early boot failure with RTAS built-in
  powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64

Chuck Lever (2):
  NFS: Fix handling of reply page vector
  xprtrdma: Fix helper that drains the transport

Cornelia Huck (1):
  virtio: Honour 'may_reduce_num' in vring_create_virtqueue

Dan Carpenter (5):
  drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata()
  aio: Fix an error code in __io_submit_one()
  irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init()
  NFC: nci: Add some bounds checking in nci_hci_cmd_received()
  nfc: nci: Potential off by one in ->pipes[] array

Daniel Drake (1):
  mmc: alcor: don't write data before command has completed

Daniel Mack (1):
  ASoC: cs4270: Set auto-increment bit for register writes

Daniel Mentz (1):
  ALSA: uapi: #include  in asound.h

Dave Airlie (1):
  drm/udl: add a release method and delay modeset teardown

David Müller (1):
  clk: x86: Add system specific quirk to mark clocks as critical

Dongli Zhang (2):
  virtio-blk: limit number of hw queues by nr_cpu_ids
  scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids

Erik Schmauss (1):
  ACPICA: Namespace: remove address node from global list after
method termination

Faiz Abbas (1):
  mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning

Filipe Manana (1):
  Btrfs: do not allow trimming when a fs is mounted with the
nologreplay option

Guenter Roeck (1):
  ASoC: intel: Fix crash at suspend/resume after failed codec registration

Gustavo A. R. Silva (1):
  ASoC: ab8500: Mark expected switch fall-through

Hans Holmberg (1):
  lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage bvecs

Hans de Goede (1):
  ASoC: Intel: cht_bsw_max98090_ti: Enable codec clock once and
keep it enabled

Heiner Kallweit (1):
  r8169: disable ASPM again

Horatiu Vultur (1):
  MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig

Hui Wang (1):
  ALSA: hda - Add two more machines to the power_save_blacklist

Imre Deak (1):
  drm/i915: Get power refs in encoder->get_power_domains()

Iuliana Prodan (1):
  crypto: caam - fix copy of next buffer for xcbc and cmac

James Smart (1):
  nvme-fc: correct csn initialization and increments on error

Jani Nikula (1):
  drm/i915/dp: revert back to max link rate and lane count on eDP

Jann Horn 

[tip:WIP.x86/stackguards 1/32] mm/slab.c:1486:27: error: expected '}' before ';' token

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.x86/stackguards
head:   310a7f5b0b42c6a8edeb74ae3289a98896e0e5c9
commit: 7552063baa017438f2bfd6060e0b949808acc812 [1/32] mm/slab: Fix broken 
stack trace storage
config: x86_64-randconfig-x003-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 7552063baa017438f2bfd6060e0b949808acc812
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1486:27: error: expected '}' before ';' token
   .max_entries = size - 4;
  ^

vim +1486 mm/slab.c

  1468  
  1469  #ifdef CONFIG_DEBUG_PAGEALLOC
  1470  static void store_stackinfo(struct kmem_cache *cachep, unsigned long 
*addr,
  1471  unsigned long caller)
  1472  {
  1473  int size = cachep->object_size / sizeof(unsigned long);
  1474  
  1475  addr = (unsigned long *)&((char *)addr)[obj_offset(cachep)];
  1476  
  1477  if (size < 5)
  1478  return;
  1479  
  1480  *addr++ = 0x12345678;
  1481  *addr++ = caller;
  1482  *addr++ = smp_processor_id();
  1483  #ifdef CONFIG_STACKTRACE
  1484  {
  1485  struct stack_trace trace = {
> 1486  .max_entries= size - 4;
  1487  .entries= addr;
  1488  .skip   = 3;
  1489  };
  1490  
  1491  save_stack_trace();
  1492  addr += trace.nr_entries;
  1493  }
  1494  #endif
  1495  *addr = 0x87654321;
  1496  }
  1497  

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 37/47] kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 'print_lock_trace'

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 88e5708cae1e9cb0cca97bb0af5866ac54532ceb [37/47] lockdep: Simplify 
stack trace handling
config: x86_64-randconfig-l2-201915 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout 88e5708cae1e9cb0cca97bb0af5866ac54532ceb
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   kernel/locking/lockdep.c: In function 'print_usage_bug':
>> kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 
>> 'print_lock_trace' [-Werror=implicit-function-declaration]
 print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
 ^
   cc1: some warnings being treated as errors

vim +/print_lock_trace +2806 kernel/locking/lockdep.c

  2780  
  2781  static int
  2782  print_usage_bug(struct task_struct *curr, struct held_lock *this,
  2783  enum lock_usage_bit prev_bit, enum lock_usage_bit 
new_bit)
  2784  {
  2785  if (!debug_locks_off_graph_unlock() || debug_locks_silent)
  2786  return 0;
  2787  
  2788  pr_warn("\n");
  2789  pr_warn("\n");
  2790  pr_warn("WARNING: inconsistent lock state\n");
  2791  print_kernel_ident();
  2792  pr_warn("\n");
  2793  
  2794  pr_warn("inconsistent {%s} -> {%s} usage.\n",
  2795  usage_str[prev_bit], usage_str[new_bit]);
  2796  
  2797  pr_warn("%s/%d [HC%u[%lu]:SC%u[%lu]:HE%u:SE%u] takes:\n",
  2798  curr->comm, task_pid_nr(curr),
  2799  trace_hardirq_context(curr), hardirq_count() >> 
HARDIRQ_SHIFT,
  2800  trace_softirq_context(curr), softirq_count() >> 
SOFTIRQ_SHIFT,
  2801  trace_hardirqs_enabled(curr),
  2802  trace_softirqs_enabled(curr));
  2803  print_lock(this);
  2804  
  2805  pr_warn("{%s} state was registered at:\n", usage_str[prev_bit]);
> 2806  print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
  2807  
  2808  print_irqtrace_events(curr);
  2809  pr_warn("\nother info that might help us debug this:\n");
  2810  print_usage_bug_scenario(this);
  2811  
  2812  lockdep_print_held_locks(curr);
  2813  
  2814  pr_warn("\nstack backtrace:\n");
  2815  dump_stack();
  2816  
  2817  return 0;
  2818  }
  2819  

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


.config.gz
Description: application/gzip


BUG: Internal error: Oops: 17 [#1] SMP / _raw_spin_lock()

2019-04-14 Thread U.Mutlu

Hi,

while issuing the command "dd if=/dev/zero of=test2 bs=8k count=64k conv=sync"
in /tmp3 on the rootfs (/dev/sda1; a SSD drive), the system
sometime crashes (maybe in 5% of the cases)

The device is a Banana Pi using Allwinner A20 SoC (sunxi/sun7i/ARM),
the kernel in use is the stock 5.0.5 kernel w/o any modifications, but 
compiled by myself.


Could a kind kernel developer/tester please briefly check the following
serial output whether the bug is in the SATA driver (ahci-sunxi[1c18000.sata]) 
or is it perhaps a kernel bug?

That driver is linked into the kernel. A coredump was not generated.

I'm new to kernel debugging. Is this a problem with _raw_spin_lock()
(--> https://lwn.net/Articles/14473/ ), or a NULL pointer issue?


Here's the serial debug output, interrupt list and iomem list:

[  262.990731] random: crng init done
[  262.994158] random: 7 urandom warning(s) missed due to ratelimiting
[  263.720319] Unable to handle kernel NULL pointer dereference at virtual 
address 

[  263.728442] pgd = aaea8072
[  263.731161] [] *pgd=7f213835
[  263.734762] Internal error: Oops: 17 [#1] SMP THUMB2
[  263.739730] Modules linked in: b53_mdio b53_common dsa_core phylink devlink 
bridge nvmem_sunxi_sid sun4i_ts input_leds sun4i_ss cpufreq_dt uio_pdrv_genirq 
uio evdev

[  263.754491] CPU: 1 PID: 568 Comm: dd Not tainted 5.0.5-my11 #1
[  263.760327] Hardware name: Allwinner sun7i (A20) Family
[  263.765582] PC is at _raw_spin_lock+0x4/0x30
[  263.769869] LR is at __queue_work+0x133/0x2c8
[  263.774234] pc : []lr : []psr: 000701b3
[  263.780506] sp : ee27fad0  ip : c0c10748  fp : ef10ab00
[  263.785736] r10: c0b51324  r9 : ee27e000  r8 : c0c6fcf8
[  263.790970] r7 : ef6b2f80  r6 : 0004  r5 : ee5ac840  r4 : ef6b7b00
[  263.797503] r3 : 12c1  r2 : 12c0  r1 :   r0 : 
[  263.804039] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment 
none

[  263.811442] Control: 50c5387d  Table: 6e29c06a  DAC: 0051
[  263.817196] Process dd (pid: 568, stack limit = 0xe5362e05)
[  263.822776] Stack: (0xee27fad0 to 0xee28)
[  263.827150] fac0: 03024100 c056a955 
0001 0014
[  263.835345] fae0: ee27fad0 c0b51324 0001  ee5ac840 0004 
ef10ab00 
[  263.843540] fb00:  ee27fbe0 c0c03080 c0129e2d 20070113 c0c08d48 
c0ca6cc8 ee5ac840
[  263.851736] fb20: 0001 eeba0588 eeba09d4 c049c67f 3335 ee5ac800 
0001 c04a33fb
[  263.859930] fb40: eeba0588    eeba0588 c04a3497 
ee5ceb00 
[  263.868125] fb60: eead8800 c056b6bf  ffe1 ee5cebb8 ee5ceb00 
 
[  263.876322] fb80: 0100 c056b7d5 ee5cebb8 0010 ee4ef418 ef05d800 
ee27e000 c0c08d48
[  263.884498] fba0: ee27fbe0 ee27fbc4 ee5ceb38 0004 c0c03090 ee27e000 
0100 c04a1b2b
[  263.892666] fbc0: ee27fc00 ee27fbc4 ee27fbc4 c0c08d48 0025 4004 
 c0102263
[  263.900835] fbe0: 0001 ef134a00 ef134a64 c0c03080 c0b51380 000a 
c0b58d40 c0b58d40
[  263.909003] fc00: c0b51310 f1d4 c0c03d00 0044 c0c091f0 c0b58cfc 
 
[  263.917171] fc20: 0001 ef00c000 f0803000 efb8fc74  c011c17b 
008a c01506c7
[  263.925340] fc40: 0048 c0c091f0 ee27fc78 f080200c f0802000 c04f7c15 
ecac9a00 c01efaca
[  263.933509] fc60: 00070033  ee27fcac c39e ee27e000 c0101a65 
c39f ee27fcc8
[  263.941677] fc80: ef6b6b84 ef6b6b80 ef003a80 ecac99c0 00708840 2eb5a000 
c39e 
[  263.949846] fca0: efb8fc74  a0070013 ee27fcc8 ecac9a00 c01efaca 
00070033 
[  263.958014] fcc0: 0051 bf00   1000 00700840 
 c0224429
[  263.966182] fce0:  c02244f3  ef058800 ef058800 efb8fc74 
 efb8fc74
[  263.974350] fd00: ed482330 1000  ed48242c 1000 c02245c9 
 
[  263.982518] fd20: efb8fc74 c026f839  c0c08d48  eed430a0 
ee5ba000 c0270899
[  263.990686] fd40: ed482330 1000 c0ca02ac ed48242c 1000 c02981d3 
00600040 ee5b9400
[  263.998854] fd60: 0001 0c12 0002 c0c08d48  efb8fc74 
 eed430a0
[  264.007022] fd80: ed482330 176ca000  ed48242c 1000 c0275787 
1000 c0270899
[  264.015190] fda0: efb8fc50  176cb000  ee27fe0c 000176ca 
 c0c08d48
[  264.023358] fdc0: 0656d5cd ee27fef8 ed48242c ee1fb480 c02756ad  
c081276c 1000
[  264.031526] fde0: 1000 c01b8941 1000  ee27fe0c ee27fe10 
176ca000 
[  264.039695] fe00:  ee27e000 5cb39559   c0c08d48 
ef39db80 
[  264.047863] fe20: ee27ff10  ed48242c ed482330  ee1fb480 
ee27fef8 c01b9959
[  264.056031] fe40: ed482330  0004 c01b65ff ee27fe58 c0b59180 
2000 ee27ff10
[  264.064200] fe60: ed482330 ee27fef8 ed4823b0 ed482330  2000 
 c0267475
[  264.072368] fe80:  c0760167 1000 c04bdc43 ee5cd380 

[tip:WIP.core/stacktrace 24/47] mm/slab.c:1490:11: error: 'trace' undeclared; did you mean 'true'?

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: c79cc35c00e9f15a9a32a08569036cb8365c8816 [24/47] mm/slab: Simplify 
stack trace handling
config: x86_64-randconfig-x003-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout c79cc35c00e9f15a9a32a08569036cb8365c8816
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1490:11: error: 'trace' undeclared (first use in this function); 
>> did you mean 'true'?
  addr += trace.nr_entries;
  ^
  true
   mm/slab.c:1490:11: note: each undeclared identifier is reported only once 
for each function it appears in

vim +1490 mm/slab.c

^1da177e Linus Torvalds  2005-04-16  1468  
^1da177e Linus Torvalds  2005-04-16  1469  #ifdef CONFIG_DEBUG_PAGEALLOC
343e0d7a Pekka Enberg2006-02-01  1470  static void store_stackinfo(struct 
kmem_cache *cachep, unsigned long *addr,
^1da177e Linus Torvalds  2005-04-16  1471   unsigned 
long caller)
^1da177e Linus Torvalds  2005-04-16  1472  {
b8623975 Thomas Gleixner 2019-04-08  1473   int size = cachep->object_size 
/ sizeof(unsigned long);
^1da177e Linus Torvalds  2005-04-16  1474  
3dafccf2 Manfred Spraul  2006-02-01  1475   addr = (unsigned long *)&((char 
*)addr)[obj_offset(cachep)];
^1da177e Linus Torvalds  2005-04-16  1476  
b8623975 Thomas Gleixner 2019-04-08  1477   if (size < 5)
^1da177e Linus Torvalds  2005-04-16  1478   return;
^1da177e Linus Torvalds  2005-04-16  1479  
^1da177e Linus Torvalds  2005-04-16  1480   *addr++ = 0x12345678;
^1da177e Linus Torvalds  2005-04-16  1481   *addr++ = caller;
^1da177e Linus Torvalds  2005-04-16  1482   *addr++ = smp_processor_id();
b8623975 Thomas Gleixner 2019-04-08  1483   size -= 3;
b8623975 Thomas Gleixner 2019-04-08  1484  #ifdef CONFIG_STACKTRACE
^1da177e Linus Torvalds  2005-04-16  1485   {
c79cc35c Thomas Gleixner 2019-04-14  1486   unsigned int nr_entries;
^1da177e Linus Torvalds  2005-04-16  1487  
c79cc35c Thomas Gleixner 2019-04-14  1488   /* Leave one for the 
end marker below */
c79cc35c Thomas Gleixner 2019-04-14  1489   nr_entries = 
stack_trace_save(addr, size - 1, 3);
b8623975 Thomas Gleixner 2019-04-08 @1490   addr += 
trace.nr_entries;
^1da177e Linus Torvalds  2005-04-16  1491   }
b8623975 Thomas Gleixner 2019-04-08  1492  #endif
b8623975 Thomas Gleixner 2019-04-08  1493   *addr = 0x87654321;
^1da177e Linus Torvalds  2005-04-16  1494  }
40b44137 Joonsoo Kim 2016-03-15  1495  

:: The code at line 1490 was first introduced by commit
:: b86239751f8c4d6fc43f6a9eca29e77b0319f5d7 mm/slab: Fix broken stack trace 
storage

:: TO: Thomas Gleixner 
:: CC: Thomas Gleixner 

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 37/47] kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 'print_lock_trace'; did you mean 'print_lock_name'?

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 88e5708cae1e9cb0cca97bb0af5866ac54532ceb [37/47] lockdep: Simplify 
stack trace handling
config: i386-randconfig-x018-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 88e5708cae1e9cb0cca97bb0af5866ac54532ceb
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/locking/lockdep.c: In function 'print_usage_bug':
>> kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 
>> 'print_lock_trace'; did you mean 'print_lock_name'? 
>> [-Werror=implicit-function-declaration]
 print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
 ^~~~
 print_lock_name
   cc1: some warnings being treated as errors

vim +2806 kernel/locking/lockdep.c

  2780  
  2781  static int
  2782  print_usage_bug(struct task_struct *curr, struct held_lock *this,
  2783  enum lock_usage_bit prev_bit, enum lock_usage_bit 
new_bit)
  2784  {
  2785  if (!debug_locks_off_graph_unlock() || debug_locks_silent)
  2786  return 0;
  2787  
  2788  pr_warn("\n");
  2789  pr_warn("\n");
  2790  pr_warn("WARNING: inconsistent lock state\n");
  2791  print_kernel_ident();
  2792  pr_warn("\n");
  2793  
  2794  pr_warn("inconsistent {%s} -> {%s} usage.\n",
  2795  usage_str[prev_bit], usage_str[new_bit]);
  2796  
  2797  pr_warn("%s/%d [HC%u[%lu]:SC%u[%lu]:HE%u:SE%u] takes:\n",
  2798  curr->comm, task_pid_nr(curr),
  2799  trace_hardirq_context(curr), hardirq_count() >> 
HARDIRQ_SHIFT,
  2800  trace_softirq_context(curr), softirq_count() >> 
SOFTIRQ_SHIFT,
  2801  trace_hardirqs_enabled(curr),
  2802  trace_softirqs_enabled(curr));
  2803  print_lock(this);
  2804  
  2805  pr_warn("{%s} state was registered at:\n", usage_str[prev_bit]);
> 2806  print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
  2807  
  2808  print_irqtrace_events(curr);
  2809  pr_warn("\nother info that might help us debug this:\n");
  2810  print_usage_bug_scenario(this);
  2811  
  2812  lockdep_print_held_locks(curr);
  2813  
  2814  pr_warn("\nstack backtrace:\n");
  2815  dump_stack();
  2816  
  2817  return 0;
  2818  }
  2819  

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 47/47] kernel//trace/trace_stack.c:263:26: error: invalid use of undefined type 'struct stack_trace'

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 63c35ea6b829a0f98d307a8dec038095681ecd13 [47/47] x86/stacktrace: Use 
common infrastructure
config: i386-randconfig-x010-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 63c35ea6b829a0f98d307a8dec038095681ecd13
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel//trace/trace_stack.c:24:17: error: static declaration of 
'stack_trace_index' follows non-static declaration
static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
^
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:248:17: note: previous declaration of 
'stack_trace_index' was here
extern unsigned stack_trace_index[];
^
   kernel//trace/trace_stack.c:27:22: error: static declaration of 
'stack_trace_max_size' follows non-static declaration
static unsigned long stack_trace_max_size;
 ^~~~
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:250:22: note: previous declaration of 
'stack_trace_max_size' was here
extern unsigned long stack_trace_max_size;
 ^~~~
   kernel//trace/trace_stack.c:28:24: error: static declaration of 
'stack_trace_max_lock' follows non-static declaration
static arch_spinlock_t stack_trace_max_lock =
   ^~~~
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:251:24: note: previous declaration of 
'stack_trace_max_lock' was here
extern arch_spinlock_t stack_trace_max_lock;
   ^~~~
   kernel//trace/trace_stack.c: In function '__next':
>> kernel//trace/trace_stack.c:263:26: error: invalid use of undefined type 
>> 'struct stack_trace'
 if (n >= stack_trace_max.nr_entries)
 ^
   kernel//trace/trace_stack.c: In function 't_show':
   kernel//trace/trace_stack.c:327:22: error: invalid use of undefined type 
'struct stack_trace'
  stack_trace_max.nr_entries);
 ^
   kernel//trace/trace_stack.c:337:26: error: invalid use of undefined type 
'struct stack_trace'
 if (i >= stack_trace_max.nr_entries)
 ^
   kernel//trace/trace_stack.c:340:30: error: invalid use of undefined type 
'struct stack_trace'
 if (i + 1 == stack_trace_max.nr_entries)
 ^

vim +263 kernel//trace/trace_stack.c

e5a81b62 Steven Rostedt  2008-08-27  257  
e5a81b62 Steven Rostedt  2008-08-27  258  static void *
2fc5f0cf Li Zefan2009-08-17  259  __next(struct seq_file *m, loff_t 
*pos)
e5a81b62 Steven Rostedt  2008-08-27  260  {
2fc5f0cf Li Zefan2009-08-17  261long n = *pos - 1;
e5a81b62 Steven Rostedt  2008-08-27  262  
4285f2fc Thomas Gleixner 2019-04-10 @263if (n >= 
stack_trace_max.nr_entries)
e5a81b62 Steven Rostedt  2008-08-27  264return NULL;
e5a81b62 Steven Rostedt  2008-08-27  265  
2fc5f0cf Li Zefan2009-08-17  266m->private = (void *)n;
1b6cced6 Steven Rostedt  2008-08-29  267return >private;
e5a81b62 Steven Rostedt  2008-08-27  268  }
e5a81b62 Steven Rostedt  2008-08-27  269  

:: The code at line 263 was first introduced by commit
:: 4285f2fcef8001ead0f1c9315ba50302cab68cda tracing: Remove the ULONG_MAX 
stack trace hackery

:: TO: Thomas Gleixner 
:: CC: Thomas Gleixner 

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 34/47] drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 'stack_trace_snprintf'; did you mean 'stack_trace_snprint'?

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 6476291d5b823a05b9c903a65a5f6e6026a02606 [34/47] drm: Simplify 
stacktrace handling
config: i386-randconfig-x019-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6476291d5b823a05b9c903a65a5f6e6026a02606
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_mm.c: In function 'show_leaks':
>> drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 
>> 'stack_trace_snprintf'; did you mean 'stack_trace_snprint'? 
>> [-Werror=implicit-function-declaration]
  stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 0);
  ^~~~
  stack_trace_snprint
   cc1: some warnings being treated as errors

vim +136 drivers/gpu/drm/drm_mm.c

   116  
   117  static void show_leaks(struct drm_mm *mm)
   118  {
   119  struct drm_mm_node *node;
   120  unsigned long *entries;
   121  unsigned int nr_entries;
   122  char *buf;
   123  
   124  buf = kmalloc(BUFSZ, GFP_KERNEL);
   125  if (!buf)
   126  return;
   127  
   128  list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
   129  if (!node->stack) {
   130  DRM_ERROR("node [%08llx + %08llx]: unknown 
owner\n",
   131node->start, node->size);
   132  continue;
   133  }
   134  
   135  nr_entries = stack_depot_fetch(node->stack, );
 > 136  stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 
 > 0);
   137  DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
   138node->start, node->size, buf);
   139  }
   140  
   141  kfree(buf);
   142  }
   143  

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


.config.gz
Description: application/gzip


[tip:WIP.core/stacktrace 18/47] kernel//trace/trace_stack.c:24:17: error: static declaration of 'stack_trace_index' follows non-static declaration

2019-04-14 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.core/stacktrace
head:   63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 4a934c54305ab50cf2d4b0afb915feee0dbb487e [18/47] tracing: Cleanup stack 
trace code
config: i386-randconfig-x010-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 4a934c54305ab50cf2d4b0afb915feee0dbb487e
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> kernel//trace/trace_stack.c:24:17: error: static declaration of 
>> 'stack_trace_index' follows non-static declaration
static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
^
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:248:17: note: previous declaration of 
'stack_trace_index' was here
extern unsigned stack_trace_index[];
^
>> kernel//trace/trace_stack.c:36:22: error: static declaration of 
>> 'stack_trace_max_size' follows non-static declaration
static unsigned long stack_trace_max_size;
 ^~~~
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:250:22: note: previous declaration of 
'stack_trace_max_size' was here
extern unsigned long stack_trace_max_size;
 ^~~~
>> kernel//trace/trace_stack.c:37:24: error: static declaration of 
>> 'stack_trace_max_lock' follows non-static declaration
static arch_spinlock_t stack_trace_max_lock =
   ^~~~
   In file included from kernel//trace/trace_stack.c:12:0:
   include/linux/ftrace.h:251:24: note: previous declaration of 
'stack_trace_max_lock' was here
extern arch_spinlock_t stack_trace_max_lock;
   ^~~~

vim +/stack_trace_index +24 kernel//trace/trace_stack.c

22  
23  static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES];
  > 24  static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
25  
26  /*
27   * Reserve one entry for the passed in ip. This will allow
28   * us to remove most or all of the stack size overhead
29   * added by the stack tracer itself.
30   */
31  struct stack_trace stack_trace_max = {
32  .max_entries= STACK_TRACE_ENTRIES - 1,
33  .entries= _dump_trace[0],
34  };
35  
  > 36  static unsigned long stack_trace_max_size;
  > 37  static arch_spinlock_t stack_trace_max_lock =
38  (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
39  

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


.config.gz
Description: application/gzip


Re: bug disabling NX (noexec=off)

2019-04-14 Thread Xose Vazquez Perez
On 4/14/19 11:59 AM, Thomas Gleixner wrote:
> On Sat, 13 Apr 2019, Xose Vazquez Perez wrote:
>> [0.00] NX (Execute Disable) protection: disabled by kernel command 
>> line option
>> [0.00] [ cut here ]
>> [0.00] attempted to set unsupported pgprot: 8163 bits: 
>> 8000 supported: 7fff
> 
> Does the below patch fix it for you?
> 
> Thanks,
> 
>   tglx
> 
> 8<
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 0029604af8a4..dd73d5d74393 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -825,7 +825,7 @@ void __init __early_set_fixmap(enum fixed_addresses idx,
>   pte = early_ioremap_pte(addr);
>  
>   /* Sanitize 'prot' against any unsupported bits: */
> - pgprot_val(flags) &= __default_kernel_pte_mask;
> + pgprot_val(flags) &= __supported_pte_mask;
>  
>   if (pgprot_val(flags))
>   set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
> 

Yes, it fixed it.


But there is another bug that I did not see before, but it was there:

---cut dmesg---
Freeing unused kernel image memory: 76K
[ cut here ]
x86/mm: Found insecure W+X mapping at address 0x9df5
WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:262 
note_page+0x2ae/0x650
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.0.7-300.fc30.x86_64 #1
Hardware name: Hewlett-Packard p6-2004es/2ABF, BIOS 7.16 03/23/2012
RIP: 0010:note_page+0x2ae/0x650
Code: 29 f0 48 c1 e8 0c 48 01 43 40 80 3d 54 15 2c 01 00 0f 85 07 ff ff ff 48 
c7 c7 a0 d9 0a b7 c6 05 40 15 2c 01 01 e8 41 2d 06 00 <0f> 0b 4c 8b 4b 20 e9 e9 
fe ff ff 48 29 d6 84 c9 0f 85 71 09 00 00
RSP: 0018:b35940c63e18 EFLAGS: 00010286
RAX:  RBX: b35940c63ec8 RCX: 0050
RDX: 0001 RSI: 0092 RDI: 0247
RBP: 0161 R08: 0001 R09: 02ca
R10: e844 R11: 0003 R12: 
R13: 0005 R14:  R15: 
FS:  () GS:9df73728() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f2e235a8a88 CR3: 00012b20e002 CR4: 000606e0
Call Trace:
 ? vprintk_emit+0x1ec/0x250
 ptdump_walk_pgd_level_core+0x46a/0x4c0
 ? rest_init+0xaa/0xaa
 kernel_init+0x2c/0x106
 ret_from_fork+0x1f/0x40
---[ end trace 3288a26b9a3da7ee ]---
x86/mm: Checked W+X mappings: FAILED, 2175454 W+X pages found.
rodata_test: all tests were successful
Run /init as init process
---cut dmesg---


Thank you.


[tip:x86/urgent] x86/speculation: Prevent deadlock on ssb_state::lock

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  2f5fb19341883bb6e37da351bc3700489d8506a7
Gitweb: https://git.kernel.org/tip/2f5fb19341883bb6e37da351bc3700489d8506a7
Author: Thomas Gleixner 
AuthorDate: Sun, 14 Apr 2019 19:51:06 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 23:05:52 +0200

x86/speculation: Prevent deadlock on ssb_state::lock

Mikhail reported a lockdep splat related to the AMD specific ssb_state
lock:

  CPU0   CPU1
  lock(>lock);
 local_irq_disable();
 lock(&(>siglock)->rlock);
 lock(>lock);
  
 lock(&(>siglock)->rlock);

  *** DEADLOCK ***

The connection between sighand->siglock and st->lock comes through seccomp,
which takes st->lock while holding sighand->siglock.

Make sure interrupts are disabled when __speculation_ctrl_update() is
invoked via prctl() -> speculation_ctrl_update(). Add a lockdep assert to
catch future offenders.

Fixes: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
Reported-by: Mikhail Gavrilov 
Signed-off-by: Thomas Gleixner 
Tested-by: Mikhail Gavrilov 
Cc: Thomas Lendacky 
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/alpine.deb.2.21.1904141948200.4...@nanos.tec.linutronix.de

---
 arch/x86/kernel/process.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 58ac7be52c7a..957eae13b370 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -426,6 +426,8 @@ static __always_inline void 
__speculation_ctrl_update(unsigned long tifp,
u64 msr = x86_spec_ctrl_base;
bool updmsr = false;
 
+   lockdep_assert_irqs_disabled();
+
/*
 * If TIF_SSBD is different, select the proper mitigation
 * method. Note that if SSBD mitigation is disabled or permanentely
@@ -477,10 +479,12 @@ static unsigned long speculation_ctrl_update_tif(struct 
task_struct *tsk)
 
 void speculation_ctrl_update(unsigned long tif)
 {
+   unsigned long flags;
+
/* Forced update. Make sure all relevant TIF flags are different */
-   preempt_disable();
+   local_irq_save(flags);
__speculation_ctrl_update(~tif, tif);
-   preempt_enable();
+   local_irq_restore(flags);
 }
 
 /* Called from seccomp/prctl update */


[tip:core/stacktrace] tracing: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  4285f2fcef8001ead0f1c9315ba50302cab68cda
Gitweb: https://git.kernel.org/tip/4285f2fcef8001ead0f1c9315ba50302cab68cda
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:10 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:32 +0200

tracing: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. As the
code checks the number of entries stored anyway there is no point in
keeping all that ULONG_MAX magic around.

The histogram code zeroes the storage before saving the stack, so if the
trace is shorter than the maximum number of entries it can terminate the
print loop if a zero entry is detected.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Link: https://lkml.kernel.org/r/20190410103645.048761...@linutronix.de

---
 kernel/trace/trace_events_hist.c |  2 +-
 kernel/trace/trace_stack.c   | 20 +---
 2 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 795aa2038377..21ceae299f7e 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -5246,7 +5246,7 @@ static void hist_trigger_stacktrace_print(struct seq_file 
*m,
unsigned int i;
 
for (i = 0; i < max_entries; i++) {
-   if (stacktrace_entries[i] == ULONG_MAX)
+   if (!stacktrace_entries[i])
return;
 
seq_printf(m, "%*c", 1 + spaces, ' ');
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index eec648a0d673..c6e54ff25cae 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -18,8 +18,7 @@
 
 #include "trace.h"
 
-static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
-{ [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
+static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES + 1];
 unsigned stack_trace_index[STACK_TRACE_ENTRIES];
 
 /*
@@ -52,10 +51,7 @@ void stack_trace_print(void)
   stack_trace_max.nr_entries);
 
for (i = 0; i < stack_trace_max.nr_entries; i++) {
-   if (stack_dump_trace[i] == ULONG_MAX)
-   break;
-   if (i+1 == stack_trace_max.nr_entries ||
-   stack_dump_trace[i+1] == ULONG_MAX)
+   if (i + 1 == stack_trace_max.nr_entries)
size = stack_trace_index[i];
else
size = stack_trace_index[i] - stack_trace_index[i+1];
@@ -150,8 +146,6 @@ check_stack(unsigned long ip, unsigned long *stack)
p = start;
 
for (; p < top && i < stack_trace_max.nr_entries; p++) {
-   if (stack_dump_trace[i] == ULONG_MAX)
-   break;
/*
 * The READ_ONCE_NOCHECK is used to let KASAN know that
 * this is not a stack-out-of-bounds error.
@@ -183,8 +177,6 @@ check_stack(unsigned long ip, unsigned long *stack)
}
 
stack_trace_max.nr_entries = x;
-   for (; x < i; x++)
-   stack_dump_trace[x] = ULONG_MAX;
 
if (task_stack_end_corrupted(current)) {
stack_trace_print();
@@ -286,7 +278,7 @@ __next(struct seq_file *m, loff_t *pos)
 {
long n = *pos - 1;
 
-   if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
+   if (n >= stack_trace_max.nr_entries)
return NULL;
 
m->private = (void *)n;
@@ -360,12 +352,10 @@ static int t_show(struct seq_file *m, void *v)
 
i = *(long *)v;
 
-   if (i >= stack_trace_max.nr_entries ||
-   stack_dump_trace[i] == ULONG_MAX)
+   if (i >= stack_trace_max.nr_entries)
return 0;
 
-   if (i+1 == stack_trace_max.nr_entries ||
-   stack_dump_trace[i+1] == ULONG_MAX)
+   if (i + 1 == stack_trace_max.nr_entries)
size = stack_trace_index[i];
else
size = stack_trace_index[i] - stack_trace_index[i+1];


[tip:core/stacktrace] drm: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  fa49e2eac9aa8259e1ea540d1bd301448d5b735d
Gitweb: https://git.kernel.org/tip/fa49e2eac9aa8259e1ea540d1bd301448d5b735d
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:09 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:32 +0200

drm: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: intel-...@lists.freedesktop.org
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
Cc: dri-de...@lists.freedesktop.org
Cc: David Airlie 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Link: https://lkml.kernel.org/r/20190410103644.945059...@linutronix.de

---
 drivers/gpu/drm/drm_mm.c| 3 ---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
 2 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 2b4f373736c7..69552777e13a 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -113,9 +113,6 @@ static noinline void save_stack(struct drm_mm_node *node)
};
 
save_stack_trace();
-   if (trace.nr_entries != 0 &&
-   trace.entries[trace.nr_entries-1] == ULONG_MAX)
-   trace.nr_entries--;
 
/* May be called under spinlock, so avoid sleeping */
node->stack = depot_save_stack(, GFP_NOWAIT);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a017a4232c0f..1f8acbb332c9 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -67,10 +67,6 @@ static noinline depot_stack_handle_t __save_depot_stack(void)
};
 
save_stack_trace();
-   if (trace.nr_entries &&
-   trace.entries[trace.nr_entries - 1] == ULONG_MAX)
-   trace.nr_entries--;
-
return depot_save_stack(, GFP_NOWAIT | __GFP_NOWARN);
 }
 


[tip:core/stacktrace] latency_top: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  accddc41b96915ab4e5d37796c6d17d70805999c
Gitweb: https://git.kernel.org/tip/accddc41b96915ab4e5d37796c6d17d70805999c
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:08 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:31 +0200

latency_top: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. The
consumer terminates on the first zero entry or at the number of entries, so
no functional change.

Remove the cruft.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Link: https://lkml.kernel.org/r/20190410103644.853527...@linutronix.de

---
 fs/proc/base.c  |  3 +--
 kernel/latencytop.c | 12 ++--
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 6a803a0b75df..5569f215fc54 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -489,10 +489,9 @@ static int lstats_show_proc(struct seq_file *m, void *v)
   lr->count, lr->time, lr->max);
for (q = 0; q < LT_BACKTRACEDEPTH; q++) {
unsigned long bt = lr->backtrace[q];
+
if (!bt)
break;
-   if (bt == ULONG_MAX)
-   break;
seq_printf(m, " %ps", (void *)bt);
}
seq_putc(m, '\n');
diff --git a/kernel/latencytop.c b/kernel/latencytop.c
index 96b4179cee6a..f5a90ab3c6b9 100644
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -120,8 +120,8 @@ account_global_scheduler_latency(struct task_struct *tsk,
break;
}
 
-   /* 0 and ULONG_MAX entries mean end of backtrace: */
-   if (record == 0 || record == ULONG_MAX)
+   /* 0 entry marks end of backtrace: */
+   if (!record)
break;
}
if (same) {
@@ -210,8 +210,8 @@ __account_scheduler_latency(struct task_struct *tsk, int 
usecs, int inter)
break;
}
 
-   /* 0 and ULONG_MAX entries mean end of backtrace: */
-   if (record == 0 || record == ULONG_MAX)
+   /* 0 entry is end of backtrace */
+   if (!record)
break;
}
if (same) {
@@ -252,10 +252,10 @@ static int lstats_show(struct seq_file *m, void *v)
   lr->count, lr->time, lr->max);
for (q = 0; q < LT_BACKTRACEDEPTH; q++) {
unsigned long bt = lr->backtrace[q];
+
if (!bt)
break;
-   if (bt == ULONG_MAX)
-   break;
+
seq_printf(m, " %ps", (void *)bt);
}
seq_puts(m, "\n");


[tip:core/stacktrace] mm/kasan: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  ead97a49ec3a3cb9b5133acbfed9a49b91ebf37c
Gitweb: https://git.kernel.org/tip/ead97a49ec3a3cb9b5133acbfed9a49b91ebf37c
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:07 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:31 +0200

mm/kasan: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.

Signed-off-by: Thomas Gleixner 
Acked-by: Dmitry Vyukov 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
Link: https://lkml.kernel.org/r/20190410103644.750219...@linutronix.de

---
 mm/kasan/common.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 80bbe62b16cd..38e5f20a775a 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -74,9 +74,6 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
 
save_stack_trace();
filter_irq_stacks();
-   if (trace.nr_entries != 0 &&
-   trace.entries[trace.nr_entries-1] == ULONG_MAX)
-   trace.nr_entries--;
 
return depot_save_stack(, flags);
 }


[tip:core/stacktrace] mm/page_owner: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  4621c9858f05ab08434221e3a15cc8098645ef2a
Gitweb: https://git.kernel.org/tip/4621c9858f05ab08434221e3a15cc8098645ef2a
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:06 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:30 +0200

mm/page_owner: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Michal Hocko 
Cc: linux...@kvack.org
Cc: Mike Rapoport 
Cc: Andrew Morton 
Link: https://lkml.kernel.org/r/20190410103644.661974...@linutronix.de

---
 mm/page_owner.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/page_owner.c b/mm/page_owner.c
index 925b6f44a444..df277e6bc3c6 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -148,9 +148,6 @@ static noinline depot_stack_handle_t save_stack(gfp_t flags)
depot_stack_handle_t handle;
 
save_stack_trace();
-   if (trace.nr_entries != 0 &&
-   trace.entries[trace.nr_entries-1] == ULONG_MAX)
-   trace.nr_entries--;
 
/*
 * We need to check recursion here because our request to stackdepot


[tip:core/stacktrace] mm/slub: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  b8ca7ff7731f57b256fcc13a9b7d4913f5282e5c
Gitweb: https://git.kernel.org/tip/b8ca7ff7731f57b256fcc13a9b7d4913f5282e5c
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:05 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:30 +0200

mm/slub: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.

While at it remove the pointless loop of clearing the stack array
completely. It's sufficient to clear the last entry as the consumers break
out on the first zeroed entry anyway.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Andrew Morton 
Cc: Pekka Enberg 
Cc: linux...@kvack.org
Cc: David Rientjes 
Cc: Christoph Lameter 
Link: https://lkml.kernel.org/r/20190410103644.574058...@linutronix.de

---
 mm/slub.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index d30ede89f4a6..e2ccd12b6faa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -553,7 +553,6 @@ static void set_track(struct kmem_cache *s, void *object,
if (addr) {
 #ifdef CONFIG_STACKTRACE
struct stack_trace trace;
-   int i;
 
trace.nr_entries = 0;
trace.max_entries = TRACK_ADDRS_COUNT;
@@ -563,20 +562,16 @@ static void set_track(struct kmem_cache *s, void *object,
save_stack_trace();
metadata_access_disable();
 
-   /* See rant in lockdep.c */
-   if (trace.nr_entries != 0 &&
-   trace.entries[trace.nr_entries - 1] == ULONG_MAX)
-   trace.nr_entries--;
-
-   for (i = trace.nr_entries; i < TRACK_ADDRS_COUNT; i++)
-   p->addrs[i] = 0;
+   if (trace.nr_entries < TRACK_ADDRS_COUNT)
+   p->addrs[trace.nr_entries] = 0;
 #endif
p->addr = addr;
p->cpu = smp_processor_id();
p->pid = current->pid;
p->when = jiffies;
-   } else
+   } else {
memset(p, 0, sizeof(struct track));
+   }
 }
 
 static void init_tracking(struct kmem_cache *s, void *object)


[tip:core/stacktrace] s390/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  6a28b4c2d93b812512d8d2e5179e61a14f578560
Gitweb: https://git.kernel.org/tip/6a28b4c2d93b812512d8d2e5179e61a14f578560
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:03 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:29 +0200

s390/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Martin Schwidefsky 
Cc: linux-s...@vger.kernel.org
Cc: Heiko Carstens 
Link: https://lkml.kernel.org/r/20190410103644.396788...@linutronix.de

---
 arch/s390/kernel/stacktrace.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/s390/kernel/stacktrace.c b/arch/s390/kernel/stacktrace.c
index 460dcfba7d4e..cc9ed9787068 100644
--- a/arch/s390/kernel/stacktrace.c
+++ b/arch/s390/kernel/stacktrace.c
@@ -45,8 +45,6 @@ void save_stack_trace(struct stack_trace *trace)
 
sp = current_stack_pointer();
dump_trace(save_address, trace, NULL, sp);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace);
 
@@ -58,8 +56,6 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
if (tsk == current)
sp = current_stack_pointer();
dump_trace(save_address_nosched, trace, tsk, sp);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
 
@@ -69,7 +65,5 @@ void save_stack_trace_regs(struct pt_regs *regs, struct 
stack_trace *trace)
 
sp = kernel_stack_pointer(regs);
dump_trace(save_address, trace, NULL, sp);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_regs);


[tip:core/stacktrace] parisc/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  4f3bd6ca310b594df09c8f1e319cda9baf502ec8
Gitweb: https://git.kernel.org/tip/4f3bd6ca310b594df09c8f1e319cda9baf502ec8
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:02 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:29 +0200

parisc/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: linux-par...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190410103644.308534...@linutronix.de

---
 arch/parisc/kernel/stacktrace.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/parisc/kernel/stacktrace.c b/arch/parisc/kernel/stacktrace.c
index ec5835e83a7a..6f0b9c8d8052 100644
--- a/arch/parisc/kernel/stacktrace.c
+++ b/arch/parisc/kernel/stacktrace.c
@@ -29,22 +29,17 @@ static void dump_trace(struct task_struct *task, struct 
stack_trace *trace)
}
 }
 
-
 /*
  * Save stack-backtrace addresses into a stack_trace buffer.
  */
 void save_stack_trace(struct stack_trace *trace)
 {
dump_trace(current, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace);
 
 void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
 {
dump_trace(tsk, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);


[tip:core/stacktrace] lockdep: Remove the ULONG_MAX stack trace hackery

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  2dfed4565afe263751d2451ad22336ad806c25a6
Gitweb: https://git.kernel.org/tip/2dfed4565afe263751d2451ad22336ad806c25a6
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:04 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:30 +0200

lockdep: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Will Deacon 
Link: https://lkml.kernel.org/r/20190410103644.485737...@linutronix.de

---
 kernel/locking/lockdep.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index e16766ff184b..2edf9501d906 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -444,17 +444,6 @@ static int save_trace(struct stack_trace *trace)
 
save_stack_trace(trace);
 
-   /*
-* Some daft arches put -1 at the end to indicate its a full trace.
-*
-*  this is buggy anyway, since it takes a whole extra entry so a
-* complete trace that maxes out the entries provided will be reported
-* as incomplete, friggin useless 
-*/
-   if (trace->nr_entries != 0 &&
-   trace->entries[trace->nr_entries-1] == ULONG_MAX)
-   trace->nr_entries--;
-
trace->max_entries = trace->nr_entries;
 
nr_stack_trace_entries += trace->nr_entries;


[tip:core/stacktrace] arm64/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  7b2c7b6233497bfab8826ece574bc1c26e97478d
Gitweb: https://git.kernel.org/tip/7b2c7b6233497bfab8826ece574bc1c26e97478d
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:01 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:29 +0200

arm64/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Link: https://lkml.kernel.org/r/20190410103644.220247...@linutronix.de

---
 arch/arm64/kernel/stacktrace.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d908b5e9e949..b00ec7d483d1 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -140,8 +140,6 @@ void save_stack_trace_regs(struct pt_regs *regs, struct 
stack_trace *trace)
 #endif
 
walk_stackframe(current, , save_trace, );
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_regs);
 
@@ -172,8 +170,6 @@ static noinline void __save_stack_trace(struct task_struct 
*tsk,
 #endif
 
walk_stackframe(tsk, , save_trace, );
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 
put_task_stack(tsk);
 }


[tip:core/stacktrace] riscv/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  fa9833992d5ff3c0d6e81d708bec363bce2fb54c
Gitweb: https://git.kernel.org/tip/fa9833992d5ff3c0d6e81d708bec363bce2fb54c
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:28:00 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:28 +0200

riscv/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: linux-ri...@lists.infradead.org
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Link: https://lkml.kernel.org/r/20190410103644.131061...@linutronix.de

---
 arch/riscv/kernel/stacktrace.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index a4b1d94371a0..4d403274c2e8 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -169,8 +169,6 @@ static bool save_trace(unsigned long pc, void *arg)
 void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
 {
walk_stackframe(tsk, NULL, save_trace, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
 


[tip:core/stacktrace] sh/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  b01f6d368d296cac099383a3eb200e135420f885
Gitweb: https://git.kernel.org/tip/b01f6d368d296cac099383a3eb200e135420f885
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:27:58 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:28 +0200

sh/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Rich Felker 
Cc: Yoshinori Sato 
Cc: Kuninori Morimoto 
Cc: linux...@vger.kernel.org
Cc: Simon Horman 
Link: https://lkml.kernel.org/r/20190410103643.932464...@linutronix.de

---
 arch/sh/kernel/stacktrace.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/sh/kernel/stacktrace.c b/arch/sh/kernel/stacktrace.c
index f3cb2cccb262..2950b19ad077 100644
--- a/arch/sh/kernel/stacktrace.c
+++ b/arch/sh/kernel/stacktrace.c
@@ -49,8 +49,6 @@ void save_stack_trace(struct stack_trace *trace)
unsigned long *sp = (unsigned long *)current_stack_pointer;
 
unwind_stack(current, NULL, sp,  _stack_ops, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace);
 
@@ -84,7 +82,5 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
unsigned long *sp = (unsigned long *)tsk->thread.sp;
 
unwind_stack(current, NULL, sp,  _stack_ops_nosched, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);


[tip:core/stacktrace] unicore32/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  f8a9a269c28ddd5d741e747ceca753af01c828f2
Gitweb: https://git.kernel.org/tip/f8a9a269c28ddd5d741e747ceca753af01c828f2
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:27:59 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:28 +0200

unicore32/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Guan Xuetao 
Link: https://lkml.kernel.org/r/20190410103644.036077...@linutronix.de

---
 arch/unicore32/kernel/stacktrace.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/unicore32/kernel/stacktrace.c 
b/arch/unicore32/kernel/stacktrace.c
index 9976e767d51c..e37da8c6837b 100644
--- a/arch/unicore32/kernel/stacktrace.c
+++ b/arch/unicore32/kernel/stacktrace.c
@@ -120,8 +120,6 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
}
 
walk_stackframe(, save_trace, );
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
 void save_stack_trace(struct stack_trace *trace)


[tip:core/stacktrace] arm/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  2a2bcfa0c94d8bc4770676a6799928036296c037
Gitweb: https://git.kernel.org/tip/2a2bcfa0c94d8bc4770676a6799928036296c037
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:27:57 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:27 +0200

arm/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Link: https://lkml.kernel.org/r/20190410103643.843075...@linutronix.de

---
 arch/arm/kernel/stacktrace.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index a56e7c856ab5..86870f40f9a0 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -115,8 +115,6 @@ static noinline void __save_stack_trace(struct task_struct 
*tsk,
 * running on another CPU?  For now, ignore it as we
 * can't guarantee we won't explode.
 */
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
return;
 #else
frame.fp = thread_saved_fp(tsk);
@@ -134,8 +132,6 @@ static noinline void __save_stack_trace(struct task_struct 
*tsk,
}
 
walk_stackframe(, save_trace, );
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
 void save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace)
@@ -153,8 +149,6 @@ void save_stack_trace_regs(struct pt_regs *regs, struct 
stack_trace *trace)
frame.pc = regs->ARM_pc;
 
walk_stackframe(, save_trace, );
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
 void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)


[tip:core/stacktrace] um/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  fdc7833964d83b7f7f39a03e2ee48a229ba0291f
Gitweb: https://git.kernel.org/tip/fdc7833964d83b7f7f39a03e2ee48a229ba0291f
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:27:55 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:27 +0200

um/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Cc: Richard Weinberger 
Cc: linux...@lists.infradead.org
Link: https://lkml.kernel.org/r/20190410103643.662853...@linutronix.de

---
 arch/um/kernel/stacktrace.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/um/kernel/stacktrace.c b/arch/um/kernel/stacktrace.c
index ebe7bcf62684..bd95e020d509 100644
--- a/arch/um/kernel/stacktrace.c
+++ b/arch/um/kernel/stacktrace.c
@@ -63,8 +63,6 @@ static const struct stacktrace_ops dump_ops = {
 static void __save_stack_trace(struct task_struct *tsk, struct stack_trace 
*trace)
 {
dump_trace(tsk, _ops, trace);
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
 void save_stack_trace(struct stack_trace *trace)


[tip:core/stacktrace] x86/stacktrace: Remove the pointless ULONG_MAX marker

2019-04-14 Thread tip-bot for Thomas Gleixner
Commit-ID:  c5c27a0a583844c69a433039e4fd6396ba23551b
Gitweb: https://git.kernel.org/tip/c5c27a0a583844c69a433039e4fd6396ba23551b
Author: Thomas Gleixner 
AuthorDate: Wed, 10 Apr 2019 12:27:56 +0200
Committer:  Thomas Gleixner 
CommitDate: Sun, 14 Apr 2019 19:58:27 +0200

x86/stacktrace: Remove the pointless ULONG_MAX marker

Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Cc: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Steven Rostedt 
Cc: Alexander Potapenko 
Link: https://lkml.kernel.org/r/20190410103643.750954...@linutronix.de

---
 arch/x86/kernel/stacktrace.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 5c2d71a1dc06..b2f706f1e0b7 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -46,9 +46,6 @@ static void noinline __save_stack_trace(struct stack_trace 
*trace,
if (!addr || save_stack_address(trace, addr, nosched))
break;
}
-
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
 /*
@@ -97,7 +94,7 @@ __save_stack_trace_reliable(struct stack_trace *trace,
if (regs) {
/* Success path for user tasks */
if (user_mode(regs))
-   goto success;
+   return 0;
 
/*
 * Kernel mode registers on the stack indicate an
@@ -132,10 +129,6 @@ __save_stack_trace_reliable(struct stack_trace *trace,
if (!(task->flags & (PF_KTHREAD | PF_IDLE)))
return -EINVAL;
 
-success:
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
-
return 0;
 }
 
@@ -221,9 +214,6 @@ void save_stack_trace_user(struct stack_trace *trace)
/*
 * Trace user stack if we are not a kernel thread
 */
-   if (current->mm) {
+   if (current->mm)
__save_stack_trace_user(trace);
-   }
-   if (trace->nr_entries < trace->max_entries)
-   trace->entries[trace->nr_entries++] = ULONG_MAX;
 }


Re: [PATCH] MIPS: scall64-o32: Fix indirect syscall number load

2019-04-14 Thread Philippe Mathieu-Daudé
On 4/9/19 4:53 PM, Aurelien Jarno wrote:
> Commit 4c21b8fd8f14 (MIPS: seccomp: Handle indirect system calls (o32))
> added indirect syscall detection for O32 processes running on MIPS64,
> but it did not work correctly for big endian kernel/processes. The
> reason is that the syscall number is loaded from ARG1 using the lw
> instruction while this is a 64-bit value, so zero is loaded instead of
> the syscall number.
> 
> Fix the code by using the ld instruction instead. When running a 32-bit
> processes on a 64 bit CPU, the values are properly sign-extended, so it
> ensures the value passed to syscall_trace_enter is correct.
> 
> Recent systemd versions with seccomp enabled whitelist the getpid
> syscall for their internal  processes (e.g. systemd-journald), but call
> it through syscall(SYS_getpid). This fix therefore allows O32 big endian
> systems with a 64-bit kernel to run recent systemd versions.
> 
> Signed-off-by: Aurelien Jarno 
> Cc:  # v3.15+
> ---
>  arch/mips/kernel/scall64-o32.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/kernel/scall64-o32.S b/arch/mips/kernel/scall64-o32.S
> index f158c5894a9a..feb2653490df 100644
> --- a/arch/mips/kernel/scall64-o32.S
> +++ b/arch/mips/kernel/scall64-o32.S
> @@ -125,7 +125,7 @@ trace_a_syscall:
>   subut1, v0,  __NR_O32_Linux
>   movea1, v0
>   bnezt1, 1f /* __NR_syscall at offset 0 */
> - lw  a1, PT_R4(sp) /* Arg1 for __NR_syscall case */
> + ld  a1, PT_R4(sp) /* Arg1 for __NR_syscall case */
>   .setpop
>  
>  1:   jal syscall_trace_enter
> 
> 

Reviewed-by: Philippe Mathieu-Daudé 


[PATCH v2 4/4] ARM: dts: tegra30: Add External Memory Controller node

2019-04-14 Thread Dmitry Osipenko
Add External Memory Controller node to the device-tree.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index e074258d4518..92c4aeafab29 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -732,6 +732,17 @@
#reset-cells = <1>;
};
 
+   memory-controller@7000f400 {
+   compatible = "nvidia,tegra30-emc";
+   reg = <0x7000f400 0x400>;
+   interrupts = ;
+   clocks = <_car TEGRA30_CLK_EMC>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nvidia,memory-controller = <>;
+   };
+
fuse@7000f800 {
compatible = "nvidia,tegra30-efuse";
reg = <0x7000f800 0x400>;
-- 
2.21.0



[PATCH v2 3/4] memory: tegra: Introduce Tegra30 EMC driver

2019-04-14 Thread Dmitry Osipenko
Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |   10 +
 drivers/memory/tegra/Makefile  |1 +
 drivers/memory/tegra/mc.c  |3 -
 drivers/memory/tegra/mc.h  |   30 +-
 drivers/memory/tegra/tegra30-emc.c | 1159 
 drivers/memory/tegra/tegra30.c |   44 ++
 6 files changed, 1235 insertions(+), 12 deletions(-)
 create mode 100644 drivers/memory/tegra/tegra30-emc.c

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 34e0b70f5c5f..89c02a368c65 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -16,6 +16,16 @@ config TEGRA20_EMC
  This driver is required to change memory timings / clock rate for
  external memory.
 
+config TEGRA30_EMC
+   bool "NVIDIA Tegra30 External Memory Controller driver"
+   default y
+   depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
+   help
+ This driver is for the External Memory Controller (EMC) found on
+ Tegra30 chips. The EMC controls the external DRAM on the board.
+ This driver is required to change memory timings / clock rate for
+ external memory.
+
 config TEGRA124_EMC
bool "NVIDIA Tegra124 External Memory Controller driver"
default y
diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 3971a6b7c487..3d23c4261104 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -11,5 +11,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
 obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
 
 obj-$(CONFIG_TEGRA20_EMC)  += tegra20-emc.o
+obj-$(CONFIG_TEGRA30_EMC)  += tegra30-emc.o
 obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
 obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 31b47459c84d..52ede43f1e07 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -51,9 +51,6 @@
 #define MC_EMEM_ADR_CFG 0x54
 #define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
 
-#define MC_TIMING_CONTROL  0xfc
-#define MC_TIMING_UPDATE   BIT(0)
-
 static const struct of_device_id tegra_mc_of_match[] = {
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
{ .compatible = "nvidia,tegra20-mc-gart", .data = _mc_soc },
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 887a3b07334f..90da9f62ce2b 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -9,20 +9,32 @@
 #ifndef MEMORY_TEGRA_MC_H
 #define MEMORY_TEGRA_MC_H
 
+#include 
 #include 
 #include 
 
 #include 
 
-#define MC_INT_DECERR_MTS (1 << 16)
-#define MC_INT_SECERR_SEC (1 << 13)
-#define MC_INT_DECERR_VPR (1 << 12)
-#define MC_INT_INVALID_APB_ASID_UPDATE (1 << 11)
-#define MC_INT_INVALID_SMMU_PAGE (1 << 10)
-#define MC_INT_ARBITRATION_EMEM (1 << 9)
-#define MC_INT_SECURITY_VIOLATION (1 << 8)
-#define MC_INT_INVALID_GART_PAGE (1 << 7)
-#define MC_INT_DECERR_EMEM (1 << 6)
+#define MC_INT_DECERR_MTS  BIT(16)
+#define MC_INT_SECERR_SEC  BIT(13)
+#define MC_INT_DECERR_VPR  BIT(12)
+#define MC_INT_INVALID_APB_ASID_UPDATE BIT(11)
+#define MC_INT_INVALID_SMMU_PAGE   BIT(10)
+#define MC_INT_ARBITRATION_EMEMBIT(9)
+#define MC_INT_SECURITY_VIOLATION  BIT(8)
+#define MC_INT_INVALID_GART_PAGE   BIT(7)
+#define MC_INT_DECERR_EMEM BIT(6)
+
+#define MC_EMEM_ARB_OUTSTANDING_REQ0x94
+#define MC_EMEM_ARB_OUTSTANDING_REQ_MAX_MASK   0x1ff
+#define MC_EMEM_ARB_OUTSTANDING_REQ_HOLDOFF_OVERRIDE   BIT(30)
+#define MC_EMEM_ARB_OUTSTANDING_REQ_LIMIT_ENABLE   BIT(31)
+
+#define MC_EMEM_ARB_OVERRIDE   0xe8
+#define MC_EMEM_ARB_OVERRIDE_EACK_MASK 0x3
+
+#define MC_TIMING_CONTROL  0xfc
+#define MC_TIMING_UPDATE   BIT(0)
 
 static inline u32 mc_readl(struct tegra_mc *mc, unsigned long offset)
 {
diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
new file mode 100644
index ..09817a3d6a44
--- /dev/null
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -0,0 +1,1159 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Tegra30 External Memory Controller driver
+ *
+ * Author: Dmitry Osipenko 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "mc.h"
+
+#define EMC_INTSTATUS  0x000
+#define EMC_INTMASK0x004
+#define 

[PATCH v2 2/4] dt-bindings: memory: Add binding for NVIDIA Tegra30 External Memory Controller

2019-04-14 Thread Dmitry Osipenko
Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
The binding is based on the Tegra124 EMC binding since hardware is
similar, although there are couple significant differences.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra30-emc.txt | 257 ++
 1 file changed, 257 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
new file mode 100644
index ..dffe396c5d79
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
@@ -0,0 +1,257 @@
+NVIDIA Tegra30 SoC EMC (external memory controller)
+
+
+Required properties :
+- compatible : Should be "nvidia,tegra30-emc".
+- reg : physical base address and length of the controller's registers.
+- #address-cells : Should be 1
+- #size-cells : Should be 0
+- interrupts : Should contain EMC General interrupt.
+- clocks : Should contain EMC clock.
+- nvidia,memory-controller : phandle of the MC driver.
+
+The node should contain a "emc-timings" subnode for each supported RAM type
+(see field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address
+being its RAM_CODE.
+
+Required properties for "emc-timings" nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is
+used for.
+
+Each "emc-timings" node should contain a "timing" subnode for every supported
+EMC clock rate. The "timing" subnodes should have the clock rate in Hz as
+their unit address.
+
+Required properties for "timing" nodes :
+- clock-frequency : Should contain the memory clock rate in Hz.
+- The following properties contain EMC timing characterization values
+(specified in the board documentation) :
+  - nvidia,emc-auto-cal-interval : EMC_AUTO_CAL_INTERVAL
+  - nvidia,emc-mode-1 : Mode Register 1
+  - nvidia,emc-mode-2 : Mode Register 2
+  - nvidia,emc-mode-reset : Mode Register 0
+  - nvidia,emc-zcal-cnt-long : EMC_ZCAL_WAIT_CNT after clock change
+  - nvidia,emc-cfg-dyn-self-ref : dynamic self-refresh enabled
+  - nvidia,emc-cfg-periodic-qrst : FBIO "read" FIFO periodic resetting enabled
+- nvidia,emc-configuration : EMC timing characterization data. These are the
+registers (see section "18.13.2 EMC Registers" in the TRM) whose values need to
+be specified, according to the board documentation:
+
+   EMC_RC
+   EMC_RFC
+   EMC_RAS
+   EMC_RP
+   EMC_R2W
+   EMC_W2R
+   EMC_R2P
+   EMC_W2P
+   EMC_RD_RCD
+   EMC_WR_RCD
+   EMC_RRD
+   EMC_REXT
+   EMC_WEXT
+   EMC_WDV
+   EMC_QUSE
+   EMC_QRST
+   EMC_QSAFE
+   EMC_RDV
+   EMC_REFRESH
+   EMC_BURST_REFRESH_NUM
+   EMC_PRE_REFRESH_REQ_CNT
+   EMC_PDEX2WR
+   EMC_PDEX2RD
+   EMC_PCHG2PDEN
+   EMC_ACT2PDEN
+   EMC_AR2PDEN
+   EMC_RW2PDEN
+   EMC_TXSR
+   EMC_TXSRDLL
+   EMC_TCKE
+   EMC_TFAW
+   EMC_TRPAB
+   EMC_TCLKSTABLE
+   EMC_TCLKSTOP
+   EMC_TREFBW
+   EMC_QUSE_EXTRA
+   EMC_FBIO_CFG6
+   EMC_ODT_WRITE
+   EMC_ODT_READ
+   EMC_FBIO_CFG5
+   EMC_CFG_DIG_DLL
+   EMC_CFG_DIG_DLL_PERIOD
+   EMC_DLL_XFORM_DQS0
+   EMC_DLL_XFORM_DQS1
+   EMC_DLL_XFORM_DQS2
+   EMC_DLL_XFORM_DQS3
+   EMC_DLL_XFORM_DQS4
+   EMC_DLL_XFORM_DQS5
+   EMC_DLL_XFORM_DQS6
+   EMC_DLL_XFORM_DQS7
+   EMC_DLL_XFORM_QUSE0
+   EMC_DLL_XFORM_QUSE1
+   EMC_DLL_XFORM_QUSE2
+   EMC_DLL_XFORM_QUSE3
+   EMC_DLL_XFORM_QUSE4
+   EMC_DLL_XFORM_QUSE5
+   EMC_DLL_XFORM_QUSE6
+   EMC_DLL_XFORM_QUSE7
+   EMC_DLI_TRIM_TXDQS0
+   EMC_DLI_TRIM_TXDQS1
+   EMC_DLI_TRIM_TXDQS2
+   EMC_DLI_TRIM_TXDQS3
+   EMC_DLI_TRIM_TXDQS4
+   EMC_DLI_TRIM_TXDQS5
+   EMC_DLI_TRIM_TXDQS6
+   EMC_DLI_TRIM_TXDQS7
+   EMC_DLL_XFORM_DQ0
+   EMC_DLL_XFORM_DQ1
+   EMC_DLL_XFORM_DQ2
+   EMC_DLL_XFORM_DQ3
+   EMC_XM2CMDPADCTRL
+   EMC_XM2DQSPADCTRL2
+   EMC_XM2DQPADCTRL2
+   EMC_XM2CLKPADCTRL
+   EMC_XM2COMPPADCTRL
+   EMC_XM2VTTGENPADCTRL
+   EMC_XM2VTTGENPADCTRL2
+   EMC_XM2QUSEPADCTRL
+   EMC_XM2DQSPADCTRL3
+   EMC_CTT_TERM_CTRL
+   EMC_ZCAL_INTERVAL
+   EMC_ZCAL_WAIT_CNT
+   EMC_MRS_WAIT_CNT
+   EMC_AUTO_CAL_CONFIG
+   EMC_CTT
+   EMC_CTT_DURATION
+   EMC_DYN_SELF_REF_CONTROL
+   EMC_FBIO_SPARE
+   EMC_CFG_RSV
+
+Example SoC include file:
+
+/ {
+   emc@7000f400 {
+   compatible = "nvidia,tegra30-emc";
+   reg = <0x7000f400 0x400>;
+   interrupts = ;
+   clocks = <_car TEGRA30_CLK_EMC>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nvidia,memory-controller = 

[PATCH v2 0/4] memory: tegra: Introduce Tegra30 EMC driver

2019-04-14 Thread Dmitry Osipenko
Hello,

This series introduces driver for the External Memory Controller (EMC)
found on Tegra30 chips, it controls the external DRAM on the board. The
purpose of this driver is to program memory timing for external memory on
the EMC clock rate change. The driver was tested using the ACTMON devfreq
driver that performs memory frequency scaling based on memory-usage load.

Please also note that this patchset is based on this series:

https://www.spinics.net/lists/linux-tegra/msg39687.html

Changelog:

v2: - Added support for changing MC clock diver configuration based on
  Memory Controller (MC) configuration which is part of the memory
  timing.

- Merged the "Add custom EMC clock implementation" patch into this
  series because the "Introduce Tegra30 EMC driver" patch directly
  depends on it. Please note that Tegra20 EMC driver will need to be
  adapted for the clock changes as well, I'll send out the Tegra20
  patches after this series will be applied because of some other
  dependencies (devfreq) and because the temporary breakage won't
  be critical (driver will just error out on probe).

- EMC driver now performs MC configuration validation by checking
  that the number of MC / EMC timings matches and that the timings
  rate is the same.

- EMC driver now supports timings that want to change the MC clock
  configuration.

- Other minor prettifying changes of the code.

Dmitry Osipenko (4):
  clk: tegra20/30: Add custom EMC clock implementation
  dt-bindings: memory: Add binding for NVIDIA Tegra30 External Memory
Controller
  memory: tegra: Introduce Tegra30 EMC driver
  ARM: dts: tegra30: Add External Memory Controller node

 .../memory-controllers/nvidia,tegra30-emc.txt |  257 
 arch/arm/boot/dts/tegra30.dtsi|   11 +
 drivers/clk/tegra/Makefile|2 +
 drivers/clk/tegra/clk-tegra20-emc.c   |  307 +
 drivers/clk/tegra/clk-tegra20.c   |   51 +-
 drivers/clk/tegra/clk-tegra30.c   |   35 +-
 drivers/clk/tegra/clk.h   |6 +
 drivers/memory/tegra/Kconfig  |   10 +
 drivers/memory/tegra/Makefile |1 +
 drivers/memory/tegra/mc.c |3 -
 drivers/memory/tegra/mc.h |   30 +-
 drivers/memory/tegra/tegra30-emc.c| 1159 +
 drivers/memory/tegra/tegra30.c|   44 +
 include/linux/clk/tegra.h |6 +
 14 files changed, 1860 insertions(+), 62 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
 create mode 100644 drivers/clk/tegra/clk-tegra20-emc.c
 create mode 100644 drivers/memory/tegra/tegra30-emc.c

-- 
2.21.0



[PATCH v2 1/4] clk: tegra20/30: Add custom EMC clock implementation

2019-04-14 Thread Dmitry Osipenko
A proper External Memory Controller clock rounding and parent selection
functionality is required by the EMC drivers. It is not available using
the generic clock implementation, hence add a custom one. The clock rate
rounding shall be done by the EMC drivers because they have information
about available memory timings, so the drivers will have to register a
callback that will round the requested rate. EMC clock users won't be able
to request EMC clock by getting -EPROBE_DEFER until EMC driver is probed
and the callback is set up. The functionality is somewhat similar to the
clk-emc.c which serves Tegra124+ SoC's, the later HW generations support
more parent clock sources and the HW configuration and integration with
the EMC drivers differs a tad from the older gens, hence it's not really
worth to try to squash everything into a single source file.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/Makefile  |   2 +
 drivers/clk/tegra/clk-tegra20-emc.c | 307 
 drivers/clk/tegra/clk-tegra20.c |  51 ++---
 drivers/clk/tegra/clk-tegra30.c |  35 +++-
 drivers/clk/tegra/clk.h |   6 +
 include/linux/clk/tegra.h   |   6 +
 6 files changed, 357 insertions(+), 50 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra20-emc.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 4812e45c2214..df966ca06788 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -17,7 +17,9 @@ obj-y += clk-tegra-fixed.o
 obj-y  += clk-tegra-super-gen4.o
 obj-$(CONFIG_TEGRA_CLK_EMC)+= clk-emc.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
+obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= clk-tegra20-emc.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= clk-tegra20-emc.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
 obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124.o
 obj-$(CONFIG_TEGRA_CLK_DFLL)   += clk-tegra124-dfll-fcpu.o
diff --git a/drivers/clk/tegra/clk-tegra20-emc.c 
b/drivers/clk/tegra/clk-tegra20-emc.c
new file mode 100644
index ..35b67a9989c8
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra20-emc.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK GENMASK(7, 0)
+#define CLK_SOURCE_EMC_2X_CLK_SRC_MASK GENMASK(31, 30)
+#define CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT30
+
+#define MC_EMC_SAME_FREQ   BIT(16)
+#define USE_PLLM_UDBIT(29)
+
+#define EMC_SRC_PLL_M  0
+#define EMC_SRC_PLL_C  1
+#define EMC_SRC_PLL_P  2
+#define EMC_SRC_CLK_M  3
+
+static const char * const emc_parent_clk_names[] = {
+   "pll_m", "pll_c", "pll_p", "clk_m",
+};
+
+struct tegra_clk_emc {
+   struct clk_hw hw;
+   void __iomem *reg;
+   bool mc_same_freq;
+   bool want_low_jitter;
+
+   long (*round_cb)(ulong rate, ulong rate_min, ulong rate_max, void *arg);
+   void *arg_cb;
+};
+
+static inline struct tegra_clk_emc *to_tegra_clk_emc(struct clk_hw *hw)
+{
+   return container_of(hw, struct tegra_clk_emc, hw);
+}
+
+static unsigned long emc_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   u32 val, div;
+
+   val = readl_relaxed(emc->reg);
+   div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+
+   return DIV_ROUND_UP(parent_rate * 2, div + 2);
+}
+
+static u8 emc_get_parent(struct clk_hw *hw)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+
+   return readl_relaxed(emc->reg) >> CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+}
+
+static int emc_set_parent(struct clk_hw *hw, u8 index)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   u32 val, div;
+
+   val = readl_relaxed(emc->reg);
+   val &= ~CLK_SOURCE_EMC_2X_CLK_SRC_MASK;
+   val |= index << CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+
+   div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+
+   if (index == EMC_SRC_PLL_M && div == 0 && emc->want_low_jitter)
+   val |= USE_PLLM_UD;
+   else
+   val &= ~USE_PLLM_UD;
+
+   if (emc->mc_same_freq)
+   val |= MC_EMC_SAME_FREQ;
+   else
+   val &= ~MC_EMC_SAME_FREQ;
+
+   writel_relaxed(val, emc->reg);
+
+   return 0;
+}
+
+static int emc_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   unsigned int index;
+   u32 val, div;
+
+   div = div_frac_get(rate, parent_rate, 8, 1, 0);
+
+   val = readl_relaxed(emc->reg);
+   val &= ~CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+   val 

Re: [PATCH] [PATCHv1] drivers: edac: This patch fix the following checkpatch warning.

2019-04-14 Thread Borislav Petkov
On Sun, Apr 14, 2019 at 10:09:49PM +0300, mohan kumar wrote:
> Ok Thanks, I will do that.

Good.

One more thing: please do not top-post when replying on public mailing
lists.

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


[PATCH 0/4] clone: add CLONE_PIDFD

2019-04-14 Thread Christian Brauner
Hey Linus,

This patchset makes it possible to retrieve pid file descriptors at
process creation time by introducing the new flag CLONE_PIDFD to the
clone() system call as previously discussed.

As decided last week [1] Jann and I have refined the implementation of
pidfds as anonymous inodes. Based on last weeks RFC we have only tweaked
documentation and naming, as well as making the sample program how to
get easy metadata access from a pidfd a little cleaner and more paranoid
when checking for errors.
The sample program can also serve as a test for the patchset.

When clone is called with CLONE_PIDFD a pidfd instead of a pid will be
returned. To make it possible for users of CLONE_PIDFD to apply standard
error checking that is common all across userspace, file descriptor
numbering for pidfds starts at 1 and not 0. This has the major advantage
that users can do:

int pidfd = clone(CLONE_PIDFD);
if (pidfd < 0) {
   /* handle error */
   exit(EXIT_FAILURE):
}

if (pidfd == 0) {
   /* child */
   exit(EXIT_SUCCESS);
}

/* parent */
exit(EXIT_SUCCESS);

We have also taken care that pidfds are created *after* the fd table has
been unshared to not leak pidfds into child processes.
pidfd creation during clone is split into two distinct steps:
1. preparing both an fd and a file referencing struct pid for fd_install()
2. fd_install()ing the pidfd
Step 1. is performed before clone's point of no return and especially
before write_lock_irq(_lock) is taken.
Performing 1. before clone's point of no return ensures that we don't
need to fail a process that is already visible to userspace when pidfd
creation fails. Step 2. happens after attach_pid() is performed and the
process is visible to userspace.
Technically, we could have also performed step 1. and 2. together before
clone's point of no return and then calling close on the file descriptor
on failure. This would slightly increase code-locality but it is
semantically more correct and clean to bring the pidfd into existence
once the process is fully attached and not before.

The actual code for CLONE_PIDFD in patch 2 is completely confined to
fork.c (apart from the CLONE_PIDFD definition of course) and is rather
small and hopefully good to review. 

The additional changes listed under David's name in the diffstat below
are here to make anon_inodes available unconditionally. They are needed
for the new mount api and thus for core vfs code in addition to pidfds.
David knows this and he has informed Al that this patch is sent out
here. The changes themselves are rather automatic.

As promised I have also contacted Joel who has sent a patchset to make
pidfds pollable. He has been informed and is happy to port his patchset
once we have moved forward [2].
Jann and I currently plan to target this patchset for inclusion in the 5.2
merge window.

Thanks!
Jann & Christian

[1]: 
https://lore.kernel.org/lkml/CAHk-=wifyY+XGNW=zc4mythd14w81f8jjqnh-gagam2rxz_...@mail.gmail.com/
[2]: https://lore.kernel.org/lkml/20190411200059.ga75...@google.com/

Christian Brauner (3):
  clone: add CLONE_PIDFD
  signal: support CLONE_PIDFD with pidfd_send_signal
  samples: show race-free pidfd metadata access

David Howells (1):
  Make anon_inodes unconditional

 arch/arm/kvm/Kconfig   |   1 -
 arch/arm64/kvm/Kconfig |   1 -
 arch/mips/kvm/Kconfig  |   1 -
 arch/powerpc/kvm/Kconfig   |   1 -
 arch/s390/kvm/Kconfig  |   1 -
 arch/x86/Kconfig   |   1 -
 arch/x86/kvm/Kconfig   |   1 -
 drivers/base/Kconfig   |   1 -
 drivers/char/tpm/Kconfig   |   1 -
 drivers/dma-buf/Kconfig|   1 -
 drivers/gpio/Kconfig   |   1 -
 drivers/iio/Kconfig|   1 -
 drivers/infiniband/Kconfig |   1 -
 drivers/vfio/Kconfig   |   1 -
 fs/Makefile|   2 +-
 fs/notify/fanotify/Kconfig |   1 -
 fs/notify/inotify/Kconfig  |   1 -
 include/linux/pid.h|   2 +
 include/uapi/linux/sched.h |   1 +
 init/Kconfig   |  10 --
 kernel/fork.c  | 117 +-
 kernel/signal.c|  14 ++-
 kernel/sys_ni.c|   3 -
 samples/Makefile   |   2 +-
 samples/pidfd/Makefile |   6 ++
 samples/pidfd/pidfd-metadata.c | 172 +
 26 files changed, 305 insertions(+), 40 deletions(-)
 create mode 100644 samples/pidfd/Makefile
 create mode 100644 samples/pidfd/pidfd-metadata.c

-- 
2.21.0



[PATCH 2/4] clone: add CLONE_PIDFD

2019-04-14 Thread Christian Brauner
As discussed this patchset makes it possible to retrieve pid file
descriptors at process creation time by introducing the new flag
CLONE_PIDFD to the clone() system call. Linus originally suggested to
implement this as a new flag to clone() instead of making it a separate
system call. As spotted by Linus, there is exactly one bit for clone()
left.

CLONE_PIDFD returns file descriptors based on the anonymous inode
implementation in the kernel that will also be used to implement the new
mount api. They serve as a simple opaque handle on pids. Logically, this
makes it possible to interpret a pidfd differently, narrowing or widening
the scope of various operations (e.g. signal sending). Thus, a pidfd cannot
just refer to a tgid, but also a tid, or in theory - given appropriate flag
arguments in relevant syscalls - a process group or session. A pidfd does
not represent a privilege. This does not imply it cannot ever be that way
but for now this is not the case.

A pidfd comes with additional information in fdinfo if the kernel supports
procfs. The fdinfo file contains the pid of the process in the callers pid
namespace in the same format as the procfs status file, i.e. "Pid:\t%d".

To remove worries about missing metadata access this patchset comes with a
sample program that illustrates how a combination of CLONE_PIDFD, fdinfo,
and pidfd_send_signal() can be used to gain race-free access to process
metadata through /proc/. The sample program can easily be translated
into a helper that would be suitable for inclusion in libc so that users
don't have to worry about writing it themselves.

Suggested-by: Linus Torvalds 
Signed-off-by: Christian Brauner 
Signed-off-by: Jann Horn 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: David Howells 
Cc: "Michael Kerrisk (man-pages)" 
Cc: Andy Lutomirsky 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Cc: Aleksa Sarai 
Cc: Linus Torvalds 
Cc: Al Viro 
---
 include/linux/pid.h|   2 +
 include/uapi/linux/sched.h |   1 +
 kernel/fork.c  | 117 +++--
 3 files changed, 115 insertions(+), 5 deletions(-)

diff --git a/include/linux/pid.h b/include/linux/pid.h
index b6f4ba16065a..3c8ef5a199ca 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -66,6 +66,8 @@ struct pid
 
 extern struct pid init_struct_pid;
 
+extern const struct file_operations pidfd_fops;
+
 static inline struct pid *get_pid(struct pid *pid)
 {
if (pid)
diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index 22627f80063e..06fa224d2c48 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -10,6 +10,7 @@
 #define CLONE_FS   0x0200  /* set if fs info shared between 
processes */
 #define CLONE_FILES0x0400  /* set if open files shared between 
processes */
 #define CLONE_SIGHAND  0x0800  /* set if signal handlers and blocked 
signals shared */
+#define CLONE_PIDFD0x1000  /* set if a pidfd instead of a pid 
should be returned */
 #define CLONE_PTRACE   0x2000  /* set if we want to let tracing 
continue on the child too */
 #define CLONE_VFORK0x4000  /* set if the parent wants the child to 
wake it up on mm_release */
 #define CLONE_PARENT   0x8000  /* set if we want to have the same 
parent as the cloner */
diff --git a/kernel/fork.c b/kernel/fork.c
index 9dcd18aa210b..4825d5205604 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -11,6 +11,7 @@
  * management can be a bitch. See 'mm/memory.c': 'copy_page_range()'
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -21,8 +22,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1662,6 +1665,87 @@ static inline void rcu_copy_process(struct task_struct 
*p)
 #endif /* #ifdef CONFIG_TASKS_RCU */
 }
 
+static int pidfd_release(struct inode *inode, struct file *file)
+{
+   struct pid *pid = file->private_data;
+
+   file->private_data = NULL;
+   put_pid(pid);
+   return 0;
+}
+
+#ifdef CONFIG_PROC_FS
+static void pidfd_show_fdinfo(struct seq_file *m, struct file *f)
+{
+   struct pid_namespace *ns = proc_pid_ns(file_inode(m->file));
+   struct pid *pid = f->private_data;
+
+   seq_put_decimal_ull(m, "Pid:\t", pid_nr_ns(pid, ns));
+   seq_putc(m, '\n');
+}
+#endif
+
+const struct file_operations pidfd_fops = {
+   .release = pidfd_release,
+#ifdef CONFIG_PROC_FS
+   .show_fdinfo = pidfd_show_fdinfo,
+#endif
+};
+
+/**
+ * pidfd_create() - Create a new pid file descriptor.
+ *
+ * @pid:  struct pid that the pidfd will reference
+ * @file: struct file referencing @pid to return to caller
+ *
+ * This creates a new pid file descriptor with the O_CLOEXEC flag set.
+ *
+ * Note, that this function can only be called after the fd table has
+ * potentially been shared to avoid leaking the pidfd to the new process.
+ *
+ * File descriptor numbering for pidfds starts at 

[PATCH 3/4] signal: support CLONE_PIDFD with pidfd_send_signal

2019-04-14 Thread Christian Brauner
Let pidfd_send_signal() use pidfds retrieved via CLONE_PIDFD. With this
patch pidfd_send_signal() becomes independent of procfs. This fullfils the
request made when we merged the pidfd_send_signal() patchset. The
pidfd_send_signal() syscall is now always available allowing for it to be
used by users without procfs mounted or even users without procfs support
compiled into the kernel.

Signed-off-by: Christian Brauner 
Signed-off-by: Jann Horn 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: David Howells 
Cc: "Michael Kerrisk (man-pages)" 
Cc: Andy Lutomirsky 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Cc: Aleksa Sarai 
Cc: Linus Torvalds 
Cc: Al Viro 
---
 kernel/signal.c | 14 ++
 kernel/sys_ni.c |  3 ---
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index f98448cf2def..cd83cc376767 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3513,7 +3513,6 @@ SYSCALL_DEFINE2(kill, pid_t, pid, int, sig)
return kill_something_info(sig, , pid);
 }
 
-#ifdef CONFIG_PROC_FS
 /*
  * Verify that the signaler and signalee either are in the same pid namespace
  * or that the signaler's pid namespace is an ancestor of the signalee's pid
@@ -3550,6 +3549,14 @@ static int copy_siginfo_from_user_any(kernel_siginfo_t 
*kinfo, siginfo_t *info)
return copy_siginfo_from_user(kinfo, info);
 }
 
+static struct pid *pidfd_to_pid(const struct file *file)
+{
+   if (file->f_op == _fops)
+   return file->private_data;
+
+   return tgid_pidfd_to_pid(file);
+}
+
 /**
  * sys_pidfd_send_signal - send a signal to a process through a task file
  *  descriptor
@@ -3581,12 +3588,12 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
if (flags)
return -EINVAL;
 
-   f = fdget_raw(pidfd);
+   f = fdget(pidfd);
if (!f.file)
return -EBADF;
 
/* Is this a pidfd? */
-   pid = tgid_pidfd_to_pid(f.file);
+   pid = pidfd_to_pid(f.file);
if (IS_ERR(pid)) {
ret = PTR_ERR(pid);
goto err;
@@ -3620,7 +3627,6 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
fdput(f);
return ret;
 }
-#endif /* CONFIG_PROC_FS */
 
 static int
 do_send_specific(pid_t tgid, pid_t pid, int sig, struct kernel_siginfo *info)
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index d21f4befaea4..4d9ae5ea6caf 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -167,9 +167,6 @@ COND_SYSCALL(syslog);
 
 /* kernel/sched/core.c */
 
-/* kernel/signal.c */
-COND_SYSCALL(pidfd_send_signal);
-
 /* kernel/sys.c */
 COND_SYSCALL(setregid);
 COND_SYSCALL(setgid);
-- 
2.21.0



[PATCH 4/4] samples: show race-free pidfd metadata access

2019-04-14 Thread Christian Brauner
This is a sample program showing userspace how to get race-free access to
process metadata from a pidfd. It is rather easy to do and userspace can
actually simply reuse code that currently parses a process's status file in
procfs.
The program can easily be extended into a generic helper suitable for
inclusion in a libc to make it even easier for userspace to gain metadata
access.

Signed-off-by: Christian Brauner 
Signed-off-by: Jann Horn 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: David Howells 
Cc: "Michael Kerrisk (man-pages)" 
Cc: Andy Lutomirsky 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Cc: Aleksa Sarai 
Cc: Linus Torvalds 
Cc: Al Viro 
---
 samples/Makefile   |   2 +-
 samples/pidfd/Makefile |   6 ++
 samples/pidfd/pidfd-metadata.c | 172 +
 3 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 samples/pidfd/Makefile
 create mode 100644 samples/pidfd/pidfd-metadata.c

diff --git a/samples/Makefile b/samples/Makefile
index b1142a958811..fadadb1c3b05 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -3,4 +3,4 @@
 obj-$(CONFIG_SAMPLES)  += kobject/ kprobes/ trace_events/ livepatch/ \
   hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
   configfs/ connector/ v4l/ trace_printk/ \
-  vfio-mdev/ statx/ qmi/ binderfs/
+  vfio-mdev/ statx/ qmi/ binderfs/ pidfd/
diff --git a/samples/pidfd/Makefile b/samples/pidfd/Makefile
new file mode 100644
index ..0ff97784177a
--- /dev/null
+++ b/samples/pidfd/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+
+hostprogs-y := pidfd-metadata
+always := $(hostprogs-y)
+HOSTCFLAGS_pidfd-metadata.o += -I$(objtree)/usr/include
+all: pidfd-metadata
diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
new file mode 100644
index ..23a44e582ccb
--- /dev/null
+++ b/samples/pidfd/pidfd-metadata.c
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CLONE_PIDFD
+#define CLONE_PIDFD 0x1000
+#endif
+
+static int raw_clone_pidfd(void)
+{
+   unsigned long flags = CLONE_PIDFD | SIGCHLD;
+
+#if defined(__s390x__) || defined(__s390__) || defined(__CRIS__)
+   /*
+* On s390/s390x and cris the order of the first and second arguments
+* of the system call is reversed.
+*/
+   return (int)syscall(__NR_clone, NULL, flags);
+#elif defined(__sparc__) && defined(__arch64__)
+   {
+   /*
+* sparc64 always returns the other process id in %o0, and a
+* boolean flag whether this is the child or the parent in %o1.
+* Inline assembly is needed to get the flag returned in %o1.
+*/
+   int child_pid, in_child;
+
+   asm volatile("mov %2, %%g1\n\t"
+"mov %3, %%o0\n\t"
+"mov 0 , %%o1\n\t"
+"t 0x6d\n\t"
+"mov %%o1, %0\n\t"
+"mov %%o0, %1"
+: "=r"(in_child), "=r"(child_pid)
+: "i"(__NR_clone), "r"(flags)
+: "%o1", "%o0", "%g1");
+
+   if (in_child)
+   return 0;
+   else
+   return child_pid;
+   }
+#elif defined(__ia64__)
+   /* On ia64 stack and stack size are passed as separate arguments. */
+   return (int)syscall(__NR_clone, flags, NULL, 0UL);
+#else
+   return (int)syscall(__NR_clone, flags, NULL);
+#endif
+}
+
+static inline int sys_pidfd_send_signal(int pidfd, int sig, siginfo_t *info,
+   unsigned int flags)
+{
+   return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags);
+}
+
+static int pidfd_metadata_fd(int pidfd)
+{
+   int procfd, ret;
+   char path[100];
+   FILE *f;
+   size_t n = 0;
+   char *line = NULL;
+
+   snprintf(path, sizeof(path), "/proc/self/fdinfo/%d", pidfd);
+
+   f = fopen(path, "re");
+   if (!f)
+   return -1;
+
+   ret = 0;
+   while (getline(, , f) != -1) {
+   char *numstr;
+   size_t len;
+
+   if (strncmp(line, "Pid:\t", 5))
+   continue;
+
+   numstr = line + 5;
+   len = strlen(numstr);
+   if (len > 0 && numstr[len - 1] == '\n')
+   numstr[len - 1] = '\0';
+   ret = snprintf(path, sizeof(path), "/proc/%s", numstr);
+   break;
+   }
+   free(line);
+   fclose(f);
+
+   if (!ret) {
+   errno = ENOENT;
+ 

[PATCH 1/4] Make anon_inodes unconditional

2019-04-14 Thread Christian Brauner
From: David Howells 

Make the anon_inodes facility unconditional so that it can be used by core
VFS code and pidfd code.

Signed-off-by: David Howells 
Signed-off-by: Al Viro 
[christ...@brauner.io: adapt commit message to mention pidfds]
Signed-off-by: Christian Brauner 
---
 arch/arm/kvm/Kconfig   |  1 -
 arch/arm64/kvm/Kconfig |  1 -
 arch/mips/kvm/Kconfig  |  1 -
 arch/powerpc/kvm/Kconfig   |  1 -
 arch/s390/kvm/Kconfig  |  1 -
 arch/x86/Kconfig   |  1 -
 arch/x86/kvm/Kconfig   |  1 -
 drivers/base/Kconfig   |  1 -
 drivers/char/tpm/Kconfig   |  1 -
 drivers/dma-buf/Kconfig|  1 -
 drivers/gpio/Kconfig   |  1 -
 drivers/iio/Kconfig|  1 -
 drivers/infiniband/Kconfig |  1 -
 drivers/vfio/Kconfig   |  1 -
 fs/Makefile|  2 +-
 fs/notify/fanotify/Kconfig |  1 -
 fs/notify/inotify/Kconfig  |  1 -
 init/Kconfig   | 10 --
 18 files changed, 1 insertion(+), 27 deletions(-)

diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 3f5320f46de2..f591026347a5 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -22,7 +22,6 @@ config KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on MMU && OF
select PREEMPT_NOTIFIERS
-   select ANON_INODES
select ARM_GIC
select ARM_GIC_V3
select ARM_GIC_V3_ITS
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a3f85624313e..a67121d419a2 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -23,7 +23,6 @@ config KVM
depends on OF
select MMU_NOTIFIER
select PREEMPT_NOTIFIERS
-   select ANON_INODES
select HAVE_KVM_CPU_RELAX_INTERCEPT
select HAVE_KVM_ARCH_TLB_FLUSH_ALL
select KVM_MMIO
diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig
index 4528bc9c3cb1..eac25aef21e0 100644
--- a/arch/mips/kvm/Kconfig
+++ b/arch/mips/kvm/Kconfig
@@ -21,7 +21,6 @@ config KVM
depends on MIPS_FP_SUPPORT
select EXPORT_UASM
select PREEMPT_NOTIFIERS
-   select ANON_INODES
select KVM_GENERIC_DIRTYLOG_READ_PROTECT
select HAVE_KVM_VCPU_ASYNC_IOCTL
select KVM_MMIO
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index bfdde04e4905..f53997a8ca62 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -20,7 +20,6 @@ if VIRTUALIZATION
 config KVM
bool
select PREEMPT_NOTIFIERS
-   select ANON_INODES
select HAVE_KVM_EVENTFD
select HAVE_KVM_VCPU_ASYNC_IOCTL
select SRCU
diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
index 767453faacfc..1816ee48eadd 100644
--- a/arch/s390/kvm/Kconfig
+++ b/arch/s390/kvm/Kconfig
@@ -21,7 +21,6 @@ config KVM
prompt "Kernel-based Virtual Machine (KVM) support"
depends on HAVE_KVM
select PREEMPT_NOTIFIERS
-   select ANON_INODES
select HAVE_KVM_CPU_RELAX_INTERCEPT
select HAVE_KVM_VCPU_ASYNC_IOCTL
select HAVE_KVM_EVENTFD
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5ad92419be19..7a70fb58b2d0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -44,7 +44,6 @@ config X86
#
select ACPI_LEGACY_TABLES_LOOKUPif ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
-   select ANON_INODES
select ARCH_32BIT_OFF_T if X86_32
select ARCH_CLOCKSOURCE_DATA
select ARCH_CLOCKSOURCE_INIT
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 72fa955f4a15..fc042419e670 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -27,7 +27,6 @@ config KVM
depends on X86_LOCAL_APIC
select PREEMPT_NOTIFIERS
select MMU_NOTIFIER
-   select ANON_INODES
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQFD
select IRQ_BYPASS_MANAGER
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 059700ea3521..03f067da12ee 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,7 +174,6 @@ source "drivers/base/regmap/Kconfig"
 config DMA_SHARED_BUFFER
bool
default n
-   select ANON_INODES
select IRQ_WORK
help
  This option enables the framework for buffer-sharing between
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 536e55d3919f..f3e4bc490cf0 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -157,7 +157,6 @@ config TCG_CRB
 config TCG_VTPM_PROXY
tristate "VTPM Proxy Interface"
depends on TCG_TPM
-   select ANON_INODES
---help---
  This driver proxies for an emulated TPM (vTPM) running in userspace.
  A device /dev/vtpmx is provided that creates a device pair
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 2e5a0faa2cb1..3fc9c2efc583 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -3,7 +3,6 @@ menu "DMABUF options"
 config SYNC_FILE
bool 

  1   2   3   >