Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

[Vinod Koul]

On Wed, Jun 01, 2016 at 12:53:59PM +0530, Kedareswara rao Appana wrote:
> +config XILINX_ZYNQMP_DMA
> + tristate "Xilinx ZynqMP DMA Engine"
> + depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
> + select DMA_ENGINE
> + help
> +   Enable support for Xilinx ZynqMP DMA controller.

Kconfig and makefile is sorted alphabetically, pls update this

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

do you really need so many headers?

> +static inline void zynqmp_dma_writeq(struct zynqmp_dma_chan *chan, u32 reg,
> +  u64 value)
> +{
> +#if defined(CONFIG_PHYS_ADDR_T_64BIT)
> + writeq(value, chan->regs + reg);
> +#else
> + lo_hi_writeq(value, chan->regs + reg);
> +#endif

why do you need this? can you explain..

> +static inline bool zynqmp_dma_chan_is_idle(struct zynqmp_dma_chan *chan)
> +{
> + return chan->idle;
> +

empty line not required


> +static void zynqmp_dma_desc_config_eod(struct zynqmp_dma_chan *chan, void 
> *desc)

eod? 80 line?


> + val = 0;
> + if (chan->config.has_sg)
> + val |= ZYNQMP_DMA_POINT_TYPE_SG;

why not val = and get rid of assign to 0 above

> + writel(val, chan->regs + ZYNQMP_DMA_CTRL0);

okay why write 0 for no sg mode?

> +
> + val = 0;
> + if (chan->is_dmacoherent) {
> + val |= ZYNQMP_DMA_AXCOHRNT;
> + val = (val & ~ZYNQMP_DMA_AXCACHE) |
> + (ZYNQMP_DMA_AXCACHE_VAL << ZYNQMP_DMA_AXCACHE_OFST);
> + }
> + writel(val, chan->regs + ZYNQMP_DMA_DSCR_ATTR);

same comments here too

> + spin_lock_bh(&chan->lock);
> + desc = list_first_entry(&chan->free_list, struct zynqmp_dma_desc_sw,
> +  node);

how about:

desc = list_first_entry(&chan->free_list,
struct zynqmp_dma_desc_sw, node);

> + chan->desc_free_cnt++;
> + list_add_tail(&sdesc->node, &chan->free_list);
> + list_for_each_entry_safe(child, next, &sdesc->tx_list, node) {
> + chan->desc_free_cnt++;
> + INIT_LIST_HEAD(&child->tx_list);
> + list_move_tail(&child->node, &chan->free_list);
> + }
> + INIT_LIST_HEAD(&sdesc->tx_list);

why are you initializing list in free?

> +static int zynqmp_dma_alloc_chan_resources(struct dma_chan *dchan)
> +{
> + struct zynqmp_dma_chan *chan = to_chan(dchan);
> + struct zynqmp_dma_desc_sw *desc;
> + int i;
> +
> + chan->sw_desc_pool = kzalloc(sizeof(*desc) * ZYNQMP_DMA_NUM_DESCS,
> +  GFP_KERNEL);
> + if (!chan->sw_desc_pool)
> + return -ENOMEM;

empty line here pls

> +static enum dma_status zynqmp_dma_tx_status(struct dma_chan *dchan,
> +   dma_cookie_t cookie,
> +   struct dma_tx_state *txstate)
> +{
> + return dma_cookie_status(dchan, cookie, txstate);

why do you need this wrapper, assign dma_cookie_status as your status
callback.

> +int zynqmp_dma_channel_set_config(struct dma_chan *dchan,
> +   struct zynqmp_dma_config *cfg)
> +{
> + struct zynqmp_dma_chan *chan = to_chan(dchan);
> +
> + chan->config.ovrfetch = cfg->ovrfetch;
> + chan->config.has_sg = cfg->has_sg;

is this HW capability? if so why would anyone not like to use it!

> + chan->config.ratectrl = cfg->ratectrl;
> + chan->config.src_issue = cfg->src_issue;
> + chan->config.src_burst_len = cfg->src_burst_len;
> + chan->config.dst_burst_len = cfg->dst_burst_len;

can you describe these parameters?

How would a client know how to configure them?
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(zynqmp_dma_channel_set_config);

Not _GPL?

> + chan->bus_width = ZYNQMP_DMA_BUS_WIDTH_64;
> + chan->config.src_issue = ZYNQMP_DMA_SRC_ISSUE_RST_VAL;
> + chan->config.dst_burst_len = ZYNQMP_DMA_AWLEN_RST_VAL;
> + chan->config.src_burst_len = ZYNQMP_DMA_ARLEN_RST_VAL;
> + err = of_property_read_u32(node, "xlnx,bus-width", &chan->bus_width);
> + if ((err < 0) && ((chan->bus_width != ZYNQMP_DMA_BUS_WIDTH_64) ||
> +   (chan->bus_width != ZYNQMP_DMA_BUS_WIDTH_128))) {
> + dev_err(zdev->dev, "invalid bus-width value");
> + return err;
> + }
> +
> + chan->bus_width = chan->bus_width / 8;

?

why not update it once?

-- 
~Vinod

Re: [Linaro-mm-sig] [RFC][PATCH 0/6] ion: improved ABI

[Chen Feng]

The idea is good, define the heap ids in header file is inconvenient.

But if we query the heaps information from user-space.

It need to maintain this ids and name userspace one by one. The code may
be complicated in different module user-space.

In android, the gralloc and other lib will all use ion to alloc memory.

This will make it more difficult to maintain user-space code.


But beyond this, The new alloc2 with not-handle flag is good.
And the pull out of ioctl interface is also a good cleanup.

On 2016/6/7 2:23, Laura Abbott wrote:
> 
> The ABI for Ion's ioctl interface are a pain to work with. The heap IDs
> are a 32-bit non-discoverable namespace that form part of the ABI. There's
> no way to determine what ABI version is in use which leads to problems
> if the ABI changes or needs to be updated.
> 
> This series is a first approach to give a better ABI for Ion. This includes:
> 
> - Following the advice in botching-up-ioctls.txt
> - Ioctl for ABI version
> - Dynamic assignment of heap ids
> - queryable heap ids
> - Runtime mapping of heap ids, including fallbacks. This avoids the need to
>   encode the fallbacks as an ABI.
> 
> I'm most interested in feedback if this ABI is actually an improvement and
> usable. The heap id map/query interface seems error prone but I didn't have
> a cleaner solution. There aren't any kernel APIs for the new features as the
> focus was on a userspace API but I anticipate that following easily once
> the userspace API is established.
> 
> 
> Thanks,
> Laura
> 
> P.S. Not to turn this into a bike shedding session but if you have suggestions
> for a name for this framework other than Ion I would be interested to hear
> them. Too many other things are already named Ion.
> 
> Laura Abbott (6):
>   staging: android: ion: return error value for ion_device_add_heap
>   staging: android: ion: Switch to using an idr to manage heaps
>   staging: android: ion: Drop heap type masks
>   staging: android: ion: Pull out ion ioctls to a separate file
>   staging: android: ion: Add an ioctl for ABI checking
>   staging: android: ion: Introduce new ioctls for dynamic heaps
> 
>  drivers/staging/android/ion/Makefile|   3 +-
>  drivers/staging/android/ion/ion-ioctl.c | 243 ++
>  drivers/staging/android/ion/ion.c   | 438 
> 
>  drivers/staging/android/ion/ion_priv.h  | 109 +++-
>  drivers/staging/android/uapi/ion.h  | 164 +++-
>  5 files changed, 728 insertions(+), 229 deletions(-)
>  create mode 100644 drivers/staging/android/ion/ion-ioctl.c
> 

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

[Krzysztof Kozlowski]

On 06/06/2016 07:56 PM, Marc Zyngier wrote:
> The ARM architected timer specification mandates that the interrupt
> associated with each timer is level triggered (which corresponds to
> the "counter >= comparator" condition).
> 
> A number of DTs are being remarkably creative, declaring the interrupt
> to be edge triggered. A quick look at the TRM for the corresponding ARM
> CPUs clearly shows that this is wrong, and I've corrected those.
> For non-ARM designs (and in the absence of a publicly available TRM),
> I've made them active low as well, which can't be completely wrong
> as the GIC cannot disinguish between level low and level high.
> 
> The respective maintainers are of course welcome to prove me wrong.
> 
> While I was at it, I took the liberty to fix a couple of related issue,
> such as some spurious affinity bits on ThunderX, and their complete
> absence on ls1043a (both of which seem to be related to copy-pasting
> from other DTs).
> 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
>  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
>  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
>  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
>  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi   | 8 
>  10 files changed, 40 insertions(+), 40 deletions(-)
> 

(...)

> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index ca663df..1628315 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -473,10 +473,10 @@
>  
>   timer {
>   compatible = "arm,armv8-timer";
> - interrupts = <1 13 0xff01>,
> -  <1 14 0xff01>,
> -  <1 11 0xff01>,
> -  <1 10 0xff01>;
> + interrupts = <1 13 0xff08>,
> +  <1 14 0xff08>,
> +  <1 11 0xff08>,
> +  <1 10 0xff08>;
>   };
>  
>   pmu_system_controller: system-controller@105c {

Acked-by: Krzysztof Kozlowski 

I got a conflicting patch in my tree so it would be nice if your fix
went to current release cycle:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/commit/?h=next/dt64&id=8b77005c40376816885b100bcd358887d29e323f

Best regards,
Krzysztof

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi Baolu

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, June 07, 2016 2:27 PM
> To: Jun Li ; Roger Quadros ; Peter Chen
> 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi Jun,
> 
> On 06/07/2016 11:03 AM, Jun Li wrote:
> > Hi Roger
> >
> >>
> >> For Mux devices implementing dual-role, the mux device driver _must_
> >> use OTG/dual-role core API so that a common ABI is presented to user
> >> space for OTG/dual-role.
> > That's the only point we have concern, do dual role switch through
> > OTG/dual-role core, not do it by itself.
> 
> That really depends on how do you define "dual role". Can you please
> provide an unambiguous definition of "dual role" used in OTG/dual-role
> framework?

Host and peripheral.

> 
> Best regards,
> Lu Baolu
> 
> >
> >> I haven't yet looked at the mux framework but if we take care of the
> >> above point then we are not introducing any redundancy.
> >>
> > Roger, actually this is my worry on OTG core: those dual role switch
> > users just tends to do it simply by itself(straightforward and easy),
> > not through the OTG core(some complicated in first look), this is just
> > an example for us to convince people to select a better
> > way:)
> >
> > Li Jun
> >

Re: [PATCH BUGFIX V4] block: add missing group association in bio-cloning functions

[Paolo]

Jens,
are you picking this fix?

Thanks,
Paolo

Il 13/05/2016 22:42, Jeff Moyer ha scritto:

Paolo Valente  writes:


When a bio is cloned, the newly created bio must be associated with
the same blkcg as the original bio (if BLK_CGROUP is enabled). If
this operation is not performed, then the new bio is not associated
with any group, and the group of the current task is returned when
the group of the bio is requested.

Depending on the cloning frequency, this may cause a large
percentage of the bios belonging to a given group to be treated
as if belonging to other groups (in most cases as if belonging to
the root group). The expected group isolation may thereby be broken.

This commit adds the missing association in bio-cloning functions.

Signed-off-by: Paolo Valente 
Reviewed-by: Nikolay Borisov 


I think this one's golden!  Thanks, Paolo!

Reviewed-by: Jeff Moyer 



---
Tejun: I didn't add also your Ack, just because this version is slightly
different from the one you acked.
---
  block/bio.c  | 15 +++
  fs/btrfs/extent_io.c |  6 --
  include/linux/bio.h  |  3 +++
  3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 807d25e..89f517c 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -590,6 +590,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio->bi_rw = bio_src->bi_rw;
bio->bi_iter = bio_src->bi_iter;
bio->bi_io_vec = bio_src->bi_io_vec;
+
+   bio_clone_blkcg_association(bio, bio_src);
  }
  EXPORT_SYMBOL(__bio_clone_fast);

@@ -695,6 +697,8 @@ integrity_clone:
}
}

+   bio_clone_blkcg_association(bio, bio_src);
+
return bio;
  }
  EXPORT_SYMBOL(bio_clone_bioset);
@@ -2016,6 +2020,17 @@ void bio_disassociate_task(struct bio *bio)
}
  }

+/**
+ * bio_clone_blkcg_association - clone blkcg association from src to dst bio
+ * @dst: destination bio
+ * @src: source bio
+ */
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src)
+{
+   if (src->bi_css)
+   WARN_ON(bio_associate_blkcg(dst, src->bi_css));
+}
+
  #endif /* CONFIG_BLK_CGROUP */

  static void __init biovec_init_slabs(void)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index d247fc0..19f6739 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2686,12 +2686,6 @@ struct bio *btrfs_bio_clone(struct bio *bio, gfp_t 
gfp_mask)
btrfs_bio->csum = NULL;
btrfs_bio->csum_allocated = NULL;
btrfs_bio->end_io = NULL;
-
-#ifdef CONFIG_BLK_CGROUP
-   /* FIXME, put this into bio_clone_bioset */
-   if (bio->bi_css)
-   bio_associate_blkcg(new, bio->bi_css);
-#endif
}
return new;
  }
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 6b7481f..16cbe59 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -527,11 +527,14 @@ extern unsigned int bvec_nr_vecs(unsigned short idx);
  int bio_associate_blkcg(struct bio *bio, struct cgroup_subsys_state 
*blkcg_css);
  int bio_associate_current(struct bio *bio);
  void bio_disassociate_task(struct bio *bio);
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src);
  #else /* CONFIG_BLK_CGROUP */
  static inline int bio_associate_blkcg(struct bio *bio,
struct cgroup_subsys_state *blkcg_css) { return 0; }
  static inline int bio_associate_current(struct bio *bio) { return -ENOENT; }
  static inline void bio_disassociate_task(struct bio *bio) { }
+static inline void bio_clone_blkcg_association(struct bio *dst,
+   struct bio *src) { return 0; }
  #endif/* CONFIG_BLK_CGROUP */

  #ifdef CONFIG_HIGHMEM

[PATCHv2] device tree description for AD5820 camera auto-focus coil

[Pavel Machek]

Add documentation for ad5820 device tree binding.

Signed-off-by: Pavel Machek 
Acked-by: Sakari Ailus 
Acked-by: Rob Herring 

---

v2: Fixed nit in example, added acks.

diff --git a/Documentation/devicetree/bindings/media/i2c/ad5820.txt 
b/Documentation/devicetree/bindings/media/i2c/ad5820.txt
new file mode 100644
index 000..fb70ca5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ad5820.txt
@@ -0,0 +1,19 @@
+* Analog Devices AD5820 autofocus coil
+
+Required Properties:
+
+  - compatible: Must contain "adi,ad5820"
+
+  - reg: I2C slave address
+
+  - VANA-supply: supply of voltage for VANA pin
+
+Example:
+
+   ad5820: coil@c {
+   compatible = "adi,ad5820";
+   reg = <0x0c>;
+
+   VANA-supply = <&vaux4>;
+   };
+


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

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

[Dong Aisheng]

On Mon, Jun 06, 2016 at 03:20:03PM +0200, Thomas Gleixner wrote:
> On Thu, 2 Jun 2016, Dong Aisheng wrote:
> > On Wed, Apr 27, 2016 at 12:15:00PM +0200, Thomas Gleixner wrote:
> > > Calling a function which might sleep _BEFORE_ kernel_init() is wrong. 
> > > Don't
> > > try to work around such an issue by doing magic irq_disabled() checks and 
> > > busy
> > > loops. Fix the call site and be done with it.
> > > 
> > 
> > IRQ chip and clocksource are also initialised before kernel_init()
> > which may call clk APIs like clk_prepare_enable().
> > We may not be able to guarantee those clocks are unsleepable.
> > 
> > e.g.
> > For IRQ chip, the arm,gic documents the optional clocks property in
> > Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt.
> > Although there seems no user currently, not sure there might be
> > a exception in the future.
> > 
> > For clocksource driver, it's quite common to call clk APIs to
> > enable and get clock rate which may also cause sleep.
> > e.g. ARM twd clock in arch/arm/kernel/smp_twd.c.
> > 
> > If we have to avoid the possible sleep caused by these clocks,
> > we may need to manually check it and change the related clocks
> > (e.g PLLs) from sleepable to busy loops.
> > But that is not a good solution and may also not stable when
> > clock varies.
> > 
> > It looks like not easy to find a generic solution for them.
> > What's your suggestion?
> 
> I think we should split the prepare callbacks up and move the handling logic
> into the core.
> 
> clk_ops.prepare() Legacy callback
> clk_ops.prepare_hw()  Callback which writes to the hardware
> clk_ops.prepare_done()Callback which checks whether the prepare is 
> completed
> 
> So now the core can do:
> 
> clk_prepare()
> {
>   /* Legacy code should go away */
>   if (ops->prepare) {
> ops->prepare();
> return;
>   }
> 
>   if (ops->prepare_hw)
> ops->prepare_hw();
> 
>   if (!ops->prepare_done())
>   return;
> 
>   if (early_boot_or_suspend_resume()) {
>   /*
>* Busy loop when we can't schedule in early boot,
>* suspend and resume.
>*/
>   while (!ops->prepare_done())
> ;
>   } else {
>   while (!ops->prepare_done())
> usleep(clk->prepare_delay);
>   }
> }
> 
> As a side effect that allows us to remove the gazillion of
> 
>   while (!hw_ready)
> usleep();
> 
> copies all over the place and we have a single point of control where we allow
> the clocks to busy loop.
> 
> Toughts?
> 

Great, that looks like a possible solution.
If we doing this way there's one more question that
should we do it for other clk APIs hold by prepare_lock which
all may sleep too in theory?
e.g. clk_{set|get}_rate/clk_{set|get}_parent. (possible more)
(clk_recalc_rate/clk_round_rate may also need be considered due to
it may be called within above function.)

And it seems many exist platforms doing that work in
CLK_OF_DECLARE init function in time_init().
e.g.
drivers/clk/imx/clk-imx6ul.c
drivers/clk/rockchip/clk-rk3188.c
drivers/clk/ti/clk-44xx.c
...

Then it may need introduce a lot changes and increase many new core APIs.
Is that a problem?

> Thanks,
> 
>   tglx

Regards
Dong Aisheng

Re: [tip:locking/core] locking/barriers: Validate lockless_dereference() is used on a pointer type

[Peter Zijlstra]

On Mon, Jun 06, 2016 at 11:31:39PM +0200, Mateusz Guzik wrote:
> The reason is that leaf_walk_rcu does get_child_rcu(pn, cindex++), which
> ends up in lockless_dereference as pn[cindex++], which is now evaluated
> twice. 

Indeed, bad that; yes I think the below will work, will you send a
proper patch so I can apply?

> The simplest fix I see does the assignment later, that is:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index e9c6417..06f27fd 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -551,8 +551,8 @@ static __always_inline void __write_once_size(volatile 
> void *p, void *res, int s
>   */
>  #define lockless_dereference(p) \
>  ({ \
> -   __maybe_unused const void * const _p2 = p; \
> typeof(p) _p1 = READ_ONCE(p); \
> +   __maybe_unused const void * const _p2 = _p1; \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_p1); \
>  })
> 
> -- 
> Mateusz Guzik

Re: [RFC PATCH 1/2] sched: encapsulate priority changes in a sched_set_prio static function

[Peter Zijlstra]

On Mon, Jun 06, 2016 at 09:47:52PM +, Mathieu Desnoyers wrote:
> >> +++ b/kernel/sched/core.c
> >> @@ -2230,6 +2230,11 @@ int sysctl_schedstats(struct ctl_table *table, int 
> >> write,
> >> #endif
> >> #endif
> >> 
> >> +static void sched_set_prio(struct task_struct *p, int prio)
> >> +{
> >> +  p->prio = prio;
> >> +}

Urgh; so there's a bunch of patches to the PI code that I've been
ignoring that'll completely break all this.

Let me dig them up and get this all sorted.

Basically, looking at @prio is broken.

Re: [PATCH] dmaengine: bcm2835: Fix polling for completion of DMA with interrupts masked.

[Vinod Koul]

On Mon, Jun 06, 2016 at 11:10:38PM -0700, Eric Anholt wrote:
> >> >> -   if (ret == DMA_COMPLETE || !txstate)
> >> >> +   if (ret == DMA_COMPLETE)
> >> >
> >> > Why do you change this? txstate can be NULL, so no point calculating 
> >> > reside
> >> > for those cases
> >> 
> >> The point was to go into the "Calculate where we're at in our current
> >> DMA (if the current DMA is the one we're asking about status for)" path,
> >> so that we could note when the DMA is complete even when there's no
> >> txstate passed in.
> >
> > Can you explain what you mean by current DMA!
> >
> > The claulation is always done for 'descriptor' represnted by the cookie. So
> > it doesnt not matter...!
> 
> By current I mean the current descriptor that has been submitted to the
> hardware, in bcm2835_chan->desc.

As I said, you calculate for the descriptor respresnted by cookie and
not the one getting processed!

-- 
~Vinod


signature.asc
Description: Digital signature

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

[Peter Zijlstra]

On Mon, Jun 06, 2016 at 10:28:24AM -0700, Paul E. McKenney wrote:
> commit 43672d15aeb69b1a196c06cbc071cbade8d247fd
> Author: Paul E. McKenney 
> Date:   Mon Jun 6 10:19:42 2016 -0700
> 
> documentation: Clarify limited control-dependency scope
> 
> Nothing in the control-dependencies section of memory-barriers.txt
> says that control dependencies don't extend beyond the end of the
> if-statement containing the control dependency.  Worse yet, in many
> situations, they do extend beyond that if-statement.  In particular,
> the compiler cannot destroy the control dependency given proper use of
> READ_ONCE() and WRITE_ONCE().  However, a weakly ordered system having
> a conditional-move instruction provides the control-dependency guarantee
> only to code within the scope of the if-statement itself.
> 
> This commit therefore adds words and an example demonstrating this
> limitation of control dependencies.
> 
> Reported-by: Will Deacon 
> Signed-off-by: Paul E. McKenney 

Acked-by: Peter Zijlstra (Intel) 

> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 147ae8ec836f..a4d0a99de04d 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -806,6 +806,41 @@ out-guess your code.  More generally, although 
> READ_ONCE() does force
>  the compiler to actually emit code for a given load, it does not force
>  the compiler to use the results.
>  
> +In addition, control dependencies apply only to the then-clause and
> +else-clause of the if-statement in question.  In particular, it does
> +not necessarily apply to code following the if-statement:
> +
> + q = READ_ONCE(a);
> + if (q) {
> + WRITE_ONCE(b, p);
> + } else {
> + WRITE_ONCE(b, r);
> + }
> + WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from "a". */
> +
> +It is tempting to argue that there in fact is ordering because the
> +compiler cannot reorder volatile accesses and also cannot reorder
> +the writes to "b" with the condition.  Unfortunately for this line
> +of reasoning, the compiler might compile the two writes to "b" as
> +conditional-move instructions, as in this fanciful pseudo-assembly
> +language:
> +
> + ld r1,a
> + ld r2,p
> + ld r3,r
> + cmp r1,$0
> + cmov,ne r4,r2
> + cmov,eq r4,r3
> + st r4,b
> + st $1,c
> +
> +A weakly ordered CPU would have no dependency of any sort between the load
> +from "a" and the store to "c".  The control dependencies would extend
> +only to the pair of cmov instructions and the store depending on them.
> +In short, control dependencies apply only to the stores in the then-clause
> +and else-clause of the if-statement in question (including functions
> +invoked by those two clauses), not to code following that if-statement.
> +
>  Finally, control dependencies do -not- provide transitivity.  This is
>  demonstrated by two related examples, with the initial values of
>  x and y both being zero:
> @@ -869,6 +904,12 @@ In summary:
>atomic{,64}_read() can help to preserve your control dependency.
>Please see the COMPILER BARRIER section for more information.
>  
> +  (*) Control dependencies apply only to the then-clause and else-clause
> +  of the if-statement containing the control dependency, including
> +  any functions that these two clauses call.  Control dependencies
> +  do -not- apply to code following the if-statement containing the
> +  control dependency.
> +
>(*) Control dependencies pair normally with other types of barriers.
>  
>(*) Control dependencies do -not- provide transitivity.  If you
> 

[PATCH v4 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Songjun Wu]

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

Changes in v4:
- Remove the isc clock nodes.

Changes in v3:
- Remove the 'atmel,sensor-preferred'.
- Modify the isc clock node according to the Rob's remarks.

Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of 'atmel,sensor-preferred'.
- Add the description for the ISC internal clock.

 .../devicetree/bindings/media/atmel-isc.txt| 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..3f83524
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,69 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties for ISC:
+- compatible
+   Must be "atmel,sama5d2-isc".
+- reg
+   Physical base address and length of the registers set for the device.
+- interrupts
+   Should contain IRQ line for the ISC.
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock".
+- #clock-cells
+   Should be 0.
+- clock-output-names
+   Should contain the name of the clock driving the sensor master clock.
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+
+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
+   clock-names = "hclock";
+   #clock-cells = <0>;
+   clock-output-names = "isc-mck";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_0: endpoint {
+   remote-endpoint = <&ov7740_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+
+
+};
+
+i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+
+   clocks = <&isc>;
+   clock-names = "xvclk";
+   assigned-clocks = <&isc>;
+   assigned-clock-rates = <2400>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <&isc_0>;
+   };
+   };
+};
-- 
2.7.4

[PATCH v4 1/2] [media] atmel-isc: add the Image Sensor Controller code

[Songjun Wu]

Add driver for the Image Sensor Controller. It manages
incoming data from a parallel based CMOS/CCD sensor.
It has an internal image processor, also integrates a
triple channel direct memory access controller master
interface.

Signed-off-by: Songjun Wu 
---

Changes in v4:
- Modify the isc clock code since the dt is changed.

Changes in v3:
- Add pm runtime feature.
- Modify the isc clock code since the dt is changed.

Changes in v2:
- Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API"
  in Kconfig file.
- Correct typos and coding style according to Laurent's remarks
- Delete the loop while in 'isc_clk_enable' function.
- Add the code to support VIDIOC_CREATE_BUFS in
  'isc_queue_setup' function.
- Invoke isc_config to configure register in
  'isc_start_streaming' function.
- Add the struct completion 'comp' to synchronize with
  the frame end interrupt in 'isc_stop_streaming' function.
- Check the return value of the clk_prepare_enable
  in 'isc_open' function.
- Set the default format in 'isc_open' function.
- Add an exit condition in the loop while in 'isc_config'.
- Delete the hardware setup operation in 'isc_set_format'.
- Refuse format modification during streaming
  in 'isc_s_fmt_vid_cap' function.
- Invoke v4l2_subdev_alloc_pad_config to allocate and
  initialize the pad config in 'isc_async_complete' function.
- Remove the '.owner  = THIS_MODULE,' in atmel_isc_driver.
- Replace the module_platform_driver_probe() with
  module_platform_driver().

 drivers/media/platform/Kconfig|1 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/atmel/Kconfig  |9 +
 drivers/media/platform/atmel/Makefile |1 +
 drivers/media/platform/atmel/atmel-isc-regs.h |  276 +
 drivers/media/platform/atmel/atmel-isc.c  | 1580 +
 6 files changed, 1869 insertions(+)
 create mode 100644 drivers/media/platform/atmel/Kconfig
 create mode 100644 drivers/media/platform/atmel/Makefile
 create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h
 create mode 100644 drivers/media/platform/atmel/atmel-isc.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c..91d7aea 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -110,6 +110,7 @@ source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
+source "drivers/media/platform/atmel/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..ad8f471 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -55,4 +55,6 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)   += am437x/
 
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
+obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
diff --git a/drivers/media/platform/atmel/Kconfig 
b/drivers/media/platform/atmel/Kconfig
new file mode 100644
index 000..867dca2
--- /dev/null
+++ b/drivers/media/platform/atmel/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_ATMEL_ISC
+   tristate "ATMEL Image Sensor Controller (ISC) support"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_AT91 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   help
+  This module makes the ATMEL Image Sensor Controller available
+  as a v4l2 device.
\ No newline at end of file
diff --git a/drivers/media/platform/atmel/Makefile 
b/drivers/media/platform/atmel/Makefile
new file mode 100644
index 000..9d7c999
--- /dev/null
+++ b/drivers/media/platform/atmel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h 
b/drivers/media/platform/atmel/atmel-isc-regs.h
new file mode 100644
index 000..dda9396
--- /dev/null
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -0,0 +1,276 @@
+#ifndef __ATMEL_ISC_REGS_H
+#define __ATMEL_ISC_REGS_H
+
+#include 
+
+/* ISC Control Enable Register 0 */
+#define ISC_CTRLEN  0x
+
+#define ISC_CTRLEN_CAPTURE  BIT(0)
+#define ISC_CTRLEN_CAPTURE_MASK BIT(0)
+
+#define ISC_CTRLEN_UPPROBIT(1)
+#define ISC_CTRLEN_UPPRO_MASK   BIT(1)
+
+#define ISC_CTRLEN_HISREQ   BIT(2)
+#define ISC_CTRLEN_HISREQ_MASK  BIT(2)
+
+#define ISC_CTRLEN_HISCLR   BIT(3)
+#define ISC_CTRLEN_HISCLR_MASK  BIT(3)
+
+/* ISC Control Disable Register 0 */
+#define ISC_CTRLDIS 0x0004
+
+#define ISC_CTRLDIS_DISABLE BIT(0)
+#define ISC_CTRLDIS_DISABLE_MASKBIT(0)
+
+#define ISC_CTRLDIS_SWRST   BIT(8)
+#define ISC_CTRLDIS_SWRST_MASK  BIT(8)
+
+/* ISC 

[PATCH v4 0/2] [media] atmel-isc: add driver for Atmel ISC

[Songjun Wu]

The Image Sensor Controller driver includes two parts.
1) Driver code to implement the ISC function.
2) Device tree binding documentation, it describes how
   to add the ISC in device tree.

Changes in v4:
- Modify the isc clock code since the dt is changed.
- Remove the isc clock nodes.

Changes in v3:
- Add pm runtime feature.
- Modify the isc clock code since the dt is changed.
- Remove the 'atmel,sensor-preferred'.
- Modify the isc clock node according to the Rob's remarks.

Changes in v2:
- Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API"
  in Kconfig file.
- Correct typos and coding style according to Laurent's remarks
- Delete the loop while in 'isc_clk_enable' function.
- Add the code to support VIDIOC_CREATE_BUFS in
  'isc_queue_setup' function.
- Invoke isc_config to configure register in
  'isc_start_streaming' function.
- Add the struct completion 'comp' to synchronize with
  the frame end interrupt in 'isc_stop_streaming' function.
- Check the return value of the clk_prepare_enable
  in 'isc_open' function.
- Set the default format in 'isc_open' function.
- Add an exit condition in the loop while in 'isc_config'.
- Delete the hardware setup operation in 'isc_set_format'.
- Refuse format modification during streaming
  in 'isc_s_fmt_vid_cap' function.
- Invoke v4l2_subdev_alloc_pad_config to allocate and
  initialize the pad config in 'isc_async_complete' function.
- Remove the '.owner  = THIS_MODULE,' in atmel_isc_driver.
- Replace the module_platform_driver_probe() with
  module_platform_driver().
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of 'atmel,sensor-preferred'.
- Add the description for the ISC internal clock.

Songjun Wu (2):
  [media] atmel-isc: add the Image Sensor Controller code
  [media] atmel-isc: DT binding for Image Sensor Controller driver

 .../devicetree/bindings/media/atmel-isc.txt|   69 +
 drivers/media/platform/Kconfig |1 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/atmel/Kconfig   |9 +
 drivers/media/platform/atmel/Makefile  |1 +
 drivers/media/platform/atmel/atmel-isc-regs.h  |  276 
 drivers/media/platform/atmel/atmel-isc.c   | 1580 
 7 files changed, 1938 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
 create mode 100644 drivers/media/platform/atmel/Kconfig
 create mode 100644 drivers/media/platform/atmel/Makefile
 create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h
 create mode 100644 drivers/media/platform/atmel/atmel-isc.c

-- 
2.7.4

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

[Krzysztof Kozlowski]

On 06/06/2016 06:56 PM, Rhyland Klein wrote:
> Add check to power_supply_read_temp() to only use the power_supply
> get_property() callback if the use_cnt is > 0. The use_cnt will
> be incremented at the end of __power_supply_register, so this will
> block to case where get_property can be called before the supply
> is fully registered. This fixes the issue show in the stack below:
> 
> [1.452598] power_supply_read_temp+0x78/0x80
> [1.458680] thermal_zone_get_temp+0x5c/0x11c
> [1.464765] thermal_zone_device_update+0x34/0xb4
> [1.471195] thermal_zone_device_register+0x87c/0x8cc
> [1.477974] __power_supply_register+0x364/0x424
> [1.484317] power_supply_register_no_ws+0x10/0x18
> [1.490833] bq27xxx_battery_setup+0x10c/0x164
> [1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0
> [1.503435] i2c_device_probe+0x174/0x240
> [1.509172] driver_probe_device+0x1fc/0x29c
> [1.515167] __driver_attach+0xa4/0xa8
> [1.520643] bus_for_each_dev+0x58/0x98
> [1.526204] driver_attach+0x20/0x28
> [1.531505] bus_add_driver+0x1c8/0x22c
> [1.537067] driver_register+0x68/0x108
> [1.542630] i2c_register_driver+0x38/0x7c
> [1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20
> [1.555321] do_one_initcall+0x38/0x12c
> [1.560886] kernel_init_freeable+0x148/0x1ec
> [1.566972] kernel_init+0x10/0xfc
> [1.572101] ret_from_fork+0x10/0x40
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rhyland Klein 

And maybe:
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")


> ---
> v2:
>  - Added cc stable
>  - changed return to -EAGAIN in case of use_cnt < 1
>  - Removed WARNING
>  - return value check added in additional patch:
>   "thermal: helpers: Check return value of get_temp"
> 
>  drivers/power/power_supply_core.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/power_supply_core.c 
> b/drivers/power/power_supply_core.c
> index 456987c88baa..bbd80631f31e 100644
> --- a/drivers/power/power_supply_core.c
> +++ b/drivers/power/power_supply_core.c
> @@ -561,11 +561,15 @@ static int power_supply_read_temp(struct 
> thermal_zone_device *tzd,
>  {
>   struct power_supply *psy;
>   union power_supply_propval val;
> - int ret;
> + int ret = -EAGAIN;
>  
>   WARN_ON(tzd == NULL);
> +
>   psy = tzd->devdata;
> - ret = psy->desc->get_property(psy, POWER_SUPPLY_PROP_TEMP, &val);
> +
> + if (atomic_read(&psy->use_cnt) > 0)
> + ret = psy->desc->get_property(psy, POWER_SUPPLY_PROP_TEMP,
> +   &val);

How about using just power_supply_get_property() and convert return
value to EAGAIN?

Anyway probably such check should be present also on other
get_property() calls, like thermal cooling path.

Best regards,
Krzysztof

Re: [PATCH] net: stmmac: dwmac-rk: keep PHY up for WoL

[Giuseppe CAVALLARO]

Hello

On 6/3/2016 7:29 PM, Vincent Palatin wrote:

Do not shutdown the PHY if Wake-on-Lan is enabled, else it cannot wake
us up.



I do not understand why you need that.
This is done inside the PHY layer and it is tested on our platforms
he idea is: If the parent wants to Wake the system then the PHY should
not power-down.

Peppe


Signed-off-by: Vincent Palatin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 0cd3ecf..2e45e75 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -534,6 +534,10 @@ static int rk_gmac_init(struct platform_device *pdev, void 
*priv)
struct rk_priv_data *bsp_priv = priv;
int ret;

+   /* Keep the PHY up if we use Wake-on-Lan. */
+   if (device_may_wakeup(&pdev->dev))
+   return 0;
+
ret = phy_power_on(bsp_priv, true);
if (ret)
return ret;
@@ -549,6 +553,10 @@ static void rk_gmac_exit(struct platform_device *pdev, 
void *priv)
 {
struct rk_priv_data *gmac = priv;

+   /* The PHY was up for Wake-on-Lan. */
+   if (device_may_wakeup(&pdev->dev))
+   return;
+
phy_power_on(gmac, false);
gmac_clk_enable(gmac, false);
 }

Re: [PATCH v2 2/3] tracing: expose current->comm to [ku]probe events

[Masami Hiramatsu]

On Thu,  2 Jun 2016 18:11:02 -0700
Omar Sandoval  wrote:

> From: Omar Sandoval 
> 
> ftrace is very quick to give up on saving the task command line (see
> `trace_save_cmdline()`). The workaround for events which really care
> about the command line is to explicitly assign it as part of the entry.
> However, this doesn't work for kprobe events, as there's no
> straightforward way to get access to current->comm. Add a kprobe/uprobe
> event variable $comm which provides exactly that.
> 
> Signed-off-by: Omar Sandoval 
> ---
>  Documentation/trace/kprobetrace.txt  |  4 
>  Documentation/trace/uprobetracer.txt |  4 
>  kernel/trace/trace_kprobe.c  |  1 +
>  kernel/trace/trace_probe.c   | 27 +++
>  kernel/trace/trace_probe.h   | 10 ++
>  5 files changed, 46 insertions(+)
> 
> diff --git a/Documentation/trace/kprobetrace.txt 
> b/Documentation/trace/kprobetrace.txt
> index 4b3f5293b7bf..0bf746656d06 100644
> --- a/Documentation/trace/kprobetrace.txt
> +++ b/Documentation/trace/kprobetrace.txt
> @@ -40,6 +40,7 @@ Synopsis of kprobe_events
>$stackN: Fetch Nth entry of stack (N >= 0)
>$stack : Fetch stack address.
>$retval: Fetch return value.(*)
> +  $comm  : Fetch current task comm.(***)
>+|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
>NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
>FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
> @@ -48,6 +49,7 @@ Synopsis of kprobe_events
>  
>(*) only for return probe.
>(**) this is useful for fetching a field of data structures.
> +  (***) you probably want this as a string, i.e., $comm:string
>  
>  Types
>  -
> @@ -63,6 +65,8 @@ offset, and container-size (usually 32). The syntax is;
>  
>   b@/
>  
> +For $comm, the type must be either "string" or "string_size".

Please remove string_size, which is an internal type.

> +
>  
>  Per-Probe Event Filtering
>  -
> diff --git a/Documentation/trace/uprobetracer.txt 
> b/Documentation/trace/uprobetracer.txt
> index 7e0480263c2f..34754da46860 100644
> --- a/Documentation/trace/uprobetracer.txt
> +++ b/Documentation/trace/uprobetracer.txt
> @@ -36,6 +36,7 @@ Synopsis of uprobe_tracer
> $stackN   : Fetch Nth entry of stack (N >= 0)
> $stack: Fetch stack address.
> $retval   : Fetch return value.(*)
> +   $comm : Fetch current task comm.(***)
> +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
> NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
> FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic 
> types
> @@ -44,6 +45,7 @@ Synopsis of uprobe_tracer
>  
>(*) only for return probe.
>(**) this is useful for fetching a field of data structures.
> +  (***) you probably want this as a string, i.e., $comm:string

Ditto.

Other part looks OK for me :)

Acked-by: Masami Hiramatsu 

Thank you,

>  
>  Types
>  -
> @@ -58,6 +60,8 @@ offset, and container-size (usually 32). The syntax is;
>  
>   b@/
>  
> +For $comm, the type must be either "string" or "string_size".
> +
>  
>  Event Profiling
>  ---
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 5546eec0505f..9aedb0b06683 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -587,6 +587,7 @@ static int create_trace_kprobe(int argc, char **argv)
>*  $retval : fetch return value
>*  $stack  : fetch stack address
>*  $stackN : fetch Nth of stack (N:0-)
> +  *  $comm   : fetch current task comm
>*  @ADDR   : fetch memory at ADDR (ADDR should be in kernel)
>*  @SYM[+|-offs] : fetch memory at SYM +|- offs (SYM is a data symbol)
>*  %REG: fetch register REG
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 1d372fa6fefb..3900b6e4a05d 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -218,6 +218,28 @@ free_bitfield_fetch_param(struct bitfield_fetch_param 
> *data)
>   kfree(data);
>  }
>  
> +void FETCH_FUNC_NAME(comm, string)(struct pt_regs *regs,
> +   void *data, void *dest)
> +{
> + int maxlen = get_rloc_len(*(u32 *)dest);
> + u8 *dst = get_rloc_data(dest);
> + long ret;
> +
> + if (!maxlen)
> + return;
> +
> + ret = strlcpy(dst, current->comm, maxlen);
> + *(u32 *)dest = make_data_rloc(ret, get_rloc_offs(*(u32 *)dest));
> +}
> +NOKPROBE_SYMBOL(FETCH_FUNC_NAME(comm, string));
> +
> +void FETCH_FUNC_NAME(comm, string_size)(struct pt_regs *regs,
> +void *data, void *dest)
> +{
> + *(u32 *)dest = strlen(current->comm) + 1;
> +}
> +NOKPROBE_SYMBOL(FETCH_FUNC_NAME(comm, string_size));
> +
>  static const struct fetch_type *find_fetch_type(const char *type,
>  

Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug

[Paolo Bonzini]

On 07/06/2016 03:24, Rik van Riel wrote:
> On Mon, 2016-06-06 at 15:40 +0200, Paolo Bonzini wrote:
>>
>> On 02/06/2016 15:59, Rik van Riel wrote:
>>>
>>> If a guest is saved to disk and later restored (eg. after
>>> a host reboot), or live migrated to another host, I would
>>> expect to get totally disjoint steal time statistics from
>>> the "new run" of the guest (which is the same run of the
>>> guest OS).
>> Why?  The preexisting guest steal time is always added to by
>> KVM, so the time won't restart from zero.
>>
>> Continuing the previous count on CPU hot-unplug followed by hot-plug
>> is less obvious, but I think it's overall the right thing to do.
>>
>> In fact, I was going to test a patch this week as simple as this:
>>
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index eea2a6f72b31..1ef5e48b3a36 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
>>  if (!has_steal_clock)
>>  return;
>>  
>> -memset(st, 0, sizeof(*st));
>> -
>>  wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) |
>> KVM_MSR_ENABLED));
> 
> By removing the memset from initial bootup allocation,
> can't that cause the steal time to "increase by a ludicrous
> amount" the very first time it is compared with the arch
> independent value in the scheduler code?
> 
> In other words, would removal of the memset result in still
> requiring Wanpeng's patch?

The percpu area is initialized to zero, isn't it?

Paolo

> What am I overlooking?
> 
> Is there something preventing a non-zero value right at
> the beginning?
> 
> Also, is there a chance of ending up with a non-zero bit
> in the seqcount if the memset is removed?
> 

Re: [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support

[Geert Uytterhoeven]

Hi Magnus,

On Tue, Jun 7, 2016 at 5:39 AM, Magnus Damm  wrote:
> iommu/ipmmu-vmsa: Initial r8a7796 support
>
> [PATCH 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
>
> This series adds r8a7796 support to the IPMMU driver. The DT binding
> gets updated, maximum number of micro-TLBs are increased and the
> driver is adjusted to match on the new DT binding.

Thanks for your series!

For your convenience, I've queued it up in topic/r8a7796-ipmmu-v1 at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git, and
will include it in next renesas-drivers release.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] IB/core: remove dead code

[Leon Romanovsky]

On Mon, Jun 06, 2016 at 10:15:06PM +0100, Sudip Mukherjee wrote:
> prot_sg_cnt has been assigned with the value of ret which we have
> already checked to be non-zero so prot_sg_cnt can never be zero at this
> point of the code and hence the else part can never execute.
> And since we know prot_sg_cnt is non zero there is no use for the
> if condition also.
> 
> Signed-off-by: Sudip Mukherjee 

And what about other places?

428 if (prot_sg_cnt)
429 ctx->sig->sig_wr.prot = &ctx->sig->prot.sge;




455 if (prot_sg_cnt)
456 ib_mr_pool_put(qp, &qp->rdma_mrs, ctx->sig->prot.mr);




> ---
>  drivers/infiniband/core/rw.c | 24 ++--
>  1 file changed, 10 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
> index 1eb9b12..a829a14 100644
> --- a/drivers/infiniband/core/rw.c
> +++ b/drivers/infiniband/core/rw.c
> @@ -386,21 +386,17 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, 
> struct ib_qp *qp,
>   count += ret;
>   prev_wr = &ctx->sig->data.reg_wr.wr;
>  
> - if (prot_sg_cnt) {
> - ret = rdma_rw_init_one_mr(qp, port_num, &ctx->sig->prot,
> - prot_sg, prot_sg_cnt, 0);
> - if (ret < 0)
> - goto out_destroy_data_mr;
> - count += ret;
> + ret = rdma_rw_init_one_mr(qp, port_num, &ctx->sig->prot,
> +   prot_sg, prot_sg_cnt, 0);
> + if (ret < 0)
> + goto out_destroy_data_mr;
> + count += ret;
>  
> - if (ctx->sig->prot.inv_wr.next)
> - prev_wr->next = &ctx->sig->prot.inv_wr;
> - else
> - prev_wr->next = &ctx->sig->prot.reg_wr.wr;
> - prev_wr = &ctx->sig->prot.reg_wr.wr;
> - } else {
> - ctx->sig->prot.mr = NULL;
> - }
> + if (ctx->sig->prot.inv_wr.next)
> + prev_wr->next = &ctx->sig->prot.inv_wr;
> + else
> + prev_wr->next = &ctx->sig->prot.reg_wr.wr;
> + prev_wr = &ctx->sig->prot.reg_wr.wr;
>  
>   ctx->sig->sig_mr = ib_mr_pool_get(qp, &qp->sig_mrs);
>   if (!ctx->sig->sig_mr) {
> -- 
> 1.9.1
> 


signature.asc
Description: Digital signature

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

[Michal Hocko]

On Fri 03-06-16 17:10:01, Andrea Arcangeli wrote:
> Hello Michal,
> 
> CC'ed Hugh,
> 
> On Fri, Jun 03, 2016 at 04:46:00PM +0200, Michal Hocko wrote:
> > What do you think about the external dependencies mentioned above. Do
> > you think this is a sufficient argument wrt. occasional higher
> > latencies?
> 
> It's a tradeoff and both latencies would be short and uncommon so it's
> hard to tell.
> 
> There's also mmput_async for paths that may care about mmput
> latencies. Exit itself cannot use it, it's mostly for people taking
> the mm_users pin that may not want to wait for mmput to run. It also
> shouldn't happen that often, it's a slow path.
> 
> The whole model inherited from KSM is to deliberately depend only on
> the mmap_sem + test_exit + mm_count, and never on mm_users, which to
> me in principle doesn't sound bad.

I do agree that this model is quite clever (albeit convoluted). It just
assumes that all other mmap_sem users are behaving the same. Now most
in-kernel users will do get_task_mm() and then lock mmap_sem, but I
haven't checked all of them and it is quite possible that some of those
would like to optimize in a similar way and only increment mm_count.
I might be too pessimistic about the out of mm code but I would feel
much better if the exit path didn't depend on them.

Anyway, if the current model sounds better I will definitely not insist
on my patch. It is more of an idea for simplification than a fix for
anything I have seen happening in the real life.
-- 
Michal Hocko
SUSE Labs

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

[Michal Simek]

On 6.6.2016 19:56, Marc Zyngier wrote:
> The ARM architected timer specification mandates that the interrupt
> associated with each timer is level triggered (which corresponds to
> the "counter >= comparator" condition).
> 
> A number of DTs are being remarkably creative, declaring the interrupt
> to be edge triggered. A quick look at the TRM for the corresponding ARM
> CPUs clearly shows that this is wrong, and I've corrected those.
> For non-ARM designs (and in the absence of a publicly available TRM),
> I've made them active low as well, which can't be completely wrong
> as the GIC cannot disinguish between level low and level high.
> 
> The respective maintainers are of course welcome to prove me wrong.
> 
> While I was at it, I took the liberty to fix a couple of related issue,
> such as some spurious affinity bits on ThunderX, and their complete
> absence on ls1043a (both of which seem to be related to copy-pasting
> from other DTs).
> 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
>  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
>  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
>  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
>  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi   | 8 
>  10 files changed, 40 insertions(+), 40 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
> b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> index 445aa67..c2b9bcb 100644
> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> @@ -255,10 +255,10 @@
>   /* Local timer */
>   timer {
>   compatible = "arm,armv8-timer";
> - interrupts = <1 13 0xf01>,
> -  <1 14 0xf01>,
> -  <1 11 0xf01>,
> -  <1 10 0xf01>;
> + interrupts = <1 13 0xf08>,
> +  <1 14 0xf08>,
> +  <1 11 0xf08>,
> +  <1 10 0xf08>;
>   };
>  
>   timer0: timer0@ffc03000 {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 832815d..4d9d144 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -100,13 +100,13 @@
>   timer {
>   compatible = "arm,armv8-timer";
>   interrupts =  - (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> + (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
> - (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> + (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
> - (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> + (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
> - (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
> + (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
>   };
>  
>   xtal: xtal-clk {
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index 5147d76..1c4193f 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -110,10 +110,10 @@
>  
>   timer {
>   compatible = "arm,armv8-timer";
> - interrupts = <1 0 0xff01>,  /* Secure Phys IRQ */
> -  <1 13 0xff01>, /* Non-secure Phys IRQ */
> -  <1 14 0xff01>, /* Virt IRQ */
> -  <1 15 0xff01>; /* Hyp IRQ */
> + interrupts = <1 0 0xff08>,  /* Secure Phys IRQ */
> +  <1 13 0xff08>, /* Non-secure Phys IRQ */
> +  <1 14 0xff08>, /* Virt IRQ */
> +  <1 15 0xff08>; /* Hyp IRQ */
>   clock-frequency = <5000>;
>   };
>  
> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> index ec68ec1..9c2d8a7 100644
> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> @@ -88,13 +88,13 @@
>   timer {
>   compatible = "arm,armv8-timer";
>   interrupts =  -   IRQ_TYPE_EDGE_RISING)>,
> +

Re: [PATCH v3] sched: fix first task of a task group is attached twice

[Vincent Guittot]

Hi Dietmar,

On 6 June 2016 at 21:32, Dietmar Eggemann  wrote:
> On 01/06/16 16:54, Vincent Guittot wrote:
>> On 1 June 2016 at 17:31, Dietmar Eggemann  wrote:
>>> On 30/05/16 16:52, Vincent Guittot wrote:
 The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
 that the 1st sched_entity that will be attached, will keep its
>>>
>>> attached in .task_move_group ?
>>>
>>> I'm not sure if we can have a .switched_to() directly followed by a
>>> .enqueue_task() into a cfs_rq with avg.last_update_time = 0.
>>
>> I think it can happen as well if the task is not queued during the
>> change of scheduling class because when we attach the task in
>> switched_to, the task->se.avg.last_update_time will stay to 0. So when
>> the task will be enqueued, it will be attached one more time
>
> You're right.
>
> So I started msc_test as an rt task in task group tg_1 (css.id=2) (1) and 
> when it slept
> I changed it to become a cfs task (2).
>
>
> (1) # chrt -r 99 ./cg.sh /tg_1 ./msc_test
>
> (2) # chrt -o -p 0 2093
>
> ...
> ---> busy
> [   84.336570] dequeue_task_rt: cpu=2 comm=msc_test pid=2093 tg_css_id=2
> [   84.342948] enqueue_task_rt: cpu=1 comm=msc_test pid=2093 tg_css_id=2
> ---> sleep
> [   86.548655] dequeue_task_rt: cpu=1 comm=msc_test pid=2093 tg_css_id=2
> [   91.008457] switched_from_rt: cpu=1 comm=msc_test pid=2093
> [   91.013896] switched_to_fair: cpu=1 comm=msc_test pid=2093
> [   91.019336] attach_entity_load_avg: cpu=1 comm=msc_test pid=2093 
> last_update_time=0 tg->css.id=2
> [   91.028499] do_sched_setscheduler comm=msc_test pid=2093 policy=0 rv=0
> [   91.548807] enqueue_task_fair: cpu=1 comm=msc_test pid=2093 tg_css_id=2
> [   91.555363] attach_entity_load_avg: cpu=1 comm=msc_test pid=2093 
> last_update_time=91548795220 tg->css.id=2
> ---> busy
> ...

Thanks for testing the sequence

Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug

[Wanpeng Li]

2016-06-07 15:31 GMT+08:00 Paolo Bonzini :
>
>
> On 07/06/2016 03:24, Rik van Riel wrote:
>> On Mon, 2016-06-06 at 15:40 +0200, Paolo Bonzini wrote:
>>>
>>> On 02/06/2016 15:59, Rik van Riel wrote:

 If a guest is saved to disk and later restored (eg. after
 a host reboot), or live migrated to another host, I would
 expect to get totally disjoint steal time statistics from
 the "new run" of the guest (which is the same run of the
 guest OS).
>>> Why?  The preexisting guest steal time is always added to by
>>> KVM, so the time won't restart from zero.
>>>
>>> Continuing the previous count on CPU hot-unplug followed by hot-plug
>>> is less obvious, but I think it's overall the right thing to do.
>>>
>>> In fact, I was going to test a patch this week as simple as this:
>>>
>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>>> index eea2a6f72b31..1ef5e48b3a36 100644
>>> --- a/arch/x86/kernel/kvm.c
>>> +++ b/arch/x86/kernel/kvm.c
>>> @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
>>>  if (!has_steal_clock)
>>>  return;
>>>
>>> -memset(st, 0, sizeof(*st));
>>> -
>>>  wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) |
>>> KVM_MSR_ENABLED));
>>
>> By removing the memset from initial bootup allocation,
>> can't that cause the steal time to "increase by a ludicrous
>> amount" the very first time it is compared with the arch
>> independent value in the scheduler code?
>>
>> In other words, would removal of the memset result in still
>> requiring Wanpeng's patch?
>
> The percpu area is initialized to zero, isn't it?

Your proposal can fix the steal clock warp during guest cpu hotplug, I
will send out a new version later.

Regards,
Wanpeng Li

RE: [BUG] Possible silent data corruption in filesystems/page cache

[Barczak, Mariusz]

Hi Ted,
Thanks for your explanation which convinced me.
Regards,
Mariusz.

-Original Message-
From: Theodore Ts'o [mailto:ty...@mit.edu] 
Sent: Monday, June 6, 2016 15:36
To: Barczak, Mariusz 
Cc: Andreas Dilger ; Andrew Morton 
; Jens Axboe ; Alexander Viro 
; linux...@kvack.org; linux-bl...@vger.kernel.org; 
linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; Wysoczanski, 
Michal ; Baldyga, Robert 
; Roman, Agnieszka 
Subject: Re: [BUG] Possible silent data corruption in filesystems/page cache

On Mon, Jun 06, 2016 at 07:29:42AM +, Barczak, Mariusz wrote:
> Hi, Let me elaborate problem in detail. 
> 
> For buffered IO data are copied into memory pages. For this case, the 
> write IO is not submitted (generally). In the background opportunistic 
> cleaning of dirty pages takes place and IO is generated to the device. 
> An IO error is observed on this path and application is not informed 
> about this. Summarizing flushing of dirty page fails.
> And probably, this page is dropped but in fact it should not be.
> So if above situation happens between application write and sync then 
> no error is reported. In addition after some time, when the 
> application reads the same LBA on which IO error occurred, old data 
> content is fetched.

The application will be informed about it if it asks --- if it calls fsync(), 
the I/O will be forced and if there is an error it will be returned to the 
user.  But if the user has not asked, there is no way for the user space to 
know that there is a problem --- for that matter, it may have exited already by 
the time we do the buffered writeback, so there may be nobody to inform.

If the error hapepns between the write and sync, then the address space 
mapping's AS_EIO bit will be set.  (See filemap_check_errors() and do a git 
grep on AS_EIO.)  So the user will be informed when they call fsync(2).

The problem with simply not dropping the page is that if we do that, the page 
will never be cleaned, and in the worst case, this can lead to memory 
exhaustion.  Consider the case where a user is writing huge numbers of pages, 
(e.g., dd if=/dev/zero
of=/dev/device-that-will-go-away) if the page is never dropped, then the memory 
will never go away.

In other words, the current behavior was carefully considered, and deliberately 
chosen as the best design.

The fact that you need to call fsync(2), and then check the error returns of 
both fsync(2) *and* close(2) if you want to know for sure whether or not there 
was an I/O error is a known, docmented part of Unix/Linux and has been true for 
literally decades.  (With Emacs learning and fixing this back in the 
late-1980's to avoid losing user data if the user goes over quota on their 
Andrew File System on a BSD
4.3 system, for example.  If you're using some editor that comes with some 
desktop package or some whizzy IDE, all bets are off, of course.
But if you're using such tools, you probably care about eye candy way more than 
you care about your data; certainly the authors of such programs seem to have 
this tendency, anyway.  :-)

Cheers,

- Ted


Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: [PATCH] MAINTAINERS: s5p-dev-mfc.c moved to arch/arm/mach-exynos

[Krzysztof Kozlowski]

On 06/06/2016 06:35 PM, Ben Dooks wrote:
> Fix the path for s5p-dev-mfc.c to arch/arm/mach-exynos
> (Moved in b93b315d444faa1505b6a5e001c30f3024849e46)
> 
> Signed-off-by: Ben Dooks 
> ---
> Cc: Krzysztof Kozlowski 
> Cc: Kukjin Kim 
> Cc: linux-kernel@vger.kernel.org
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed42cb6..8fd2b26 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1631,7 +1631,7 @@ M:  Jeongtae Park 
>  L:   linux-arm-ker...@lists.infradead.org
>  L:   linux-me...@vger.kernel.org
>  S:   Maintained
> -F:   arch/arm/plat-samsung/s5p-dev-mfc.c
> +F:   arch/arm/mach-exynos/s5p-dev-mfc.c
>  F:   drivers/media/platform/s5p-mfc/
>  
>  ARM/SAMSUNG S5P SERIES TV SUBSYSTEM SUPPORT

Thanks, till few days before the patch was okay... However recently the
arch/arm/mach-exynos/s5p-dev-mfc.c was removed [1] so I think this file
entry should be removed leaving only drivers/media/platform/s5p-mfc.

Could you resend with just removal of arch/arm/plat-... (and cc-ing
linux-samsung-...@vger.kernel.org, I am using patchwork on this list for
applying)?

Best regards,
Krzysztof

[1]
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/commit/?h=for-v4.8/exynos-mfc&id=b9bacc1e503e6ed893c8642f4de1b27ff98e5365

[PATCH 2/2] x86/ioapic: Fix wrong pointers in ioapic_setup_resources()

[Rui Wang]

On a 4-socket brickland, hot-removing one ioapic is fine. Hot-removing
the 2nd one causes panic:

[  453.422259] BUG: unable to handle kernel NULL pointer dereference at
0030
[  453.431059] IP: [] release_resource+0x22/0x80
[  453.437713] PGD 0
[  453.439976] Oops:  [#1] SMP
[  453.443610] Modules linked in: fuse btrfs xor raid6_pq msdos ext4
mbcache jbd2 binfmt_misc xt_CHECKSUM ipt_MAS
QUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrac
k ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw
ip6table_filter ip6_tables iptable_nat nf_conntrack_i
pv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
iptable_security iptable_raw iptable_filter vfa
t fat x86_pkg_temp_thermal intel_powerclamp coretemp kvm sb_edac
irqbypass edac_core aesni_intel ipmi_ssif iTCO_w
dt iTCO_vendor_support lpc_ich glue_helper ipmi_si ablk_helper sg shpchp
pcspkr mfd_core i2c_i801 ipmi_msghandler
 wmi acpi_pad nfsd
[  453.523040]  auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs
libcrc32c sr_mod cdrom sd_mod mgag200 drm_km
s_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ixgbe igb
ahci libahci libata mdio i2c_algo_bit pt
p i2c_core megaraid_sas pps_core dca dm_mirror dm_region_hash dm_log
dm_mod
[  453.551438] CPU: 34 PID: 1146 Comm: kworker/u288:1 Not tainted
4.5.0-rc1+ #69
[  453.559418] Hardware name: Intel Corporation BRICKLAND/BRICKLAND,
BIOS BRHSXSD1.86B.0063.R00.1503261059 03/26/
2015
[  453.570994] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[  453.577041] task: 880463325800 ti: 88046267c000 task.ti:
88046267c000
[  453.585415] RIP: 0010:[]  []
release_resource+0x22/0x80
[  453.594768] RSP: 0018:88046267fcc8  EFLAGS: 00010246
[  453.600706] RAX: ffea RBX: 88087fffde00 RCX:

[  453.608684] RDX: 00ff RSI: ea0011b72180 RDI:
81e3c0f8
[  453.616663] RBP: 88046267fcd0 R08: 88046dc86fc0 R09:
0001802a0028
[  453.624641] R10: 6dc86f01 R11: ea0011b72180 R12:
0003
[  453.632619] R13: 81e1d450 R14: 00d8 R15:
0003
[  453.640598] FS:  () GS:88086f00()
knlGS:
[  453.649645] CS:  0010 DS:  ES:  CR0: 80050033
[  453.656069] CR2: 0030 CR3: 01a6e000 CR4:
001406e0
[  453.664047] DR0:  DR1:  DR2:

[  453.672027] DR3:  DR6: fffe0ff0 DR7:
0400
[  453.680005] Stack:
[  453.682251]  00d8 88046267fd08 81057965
0048
[  453.690567]  81b43bd8 88086b125358 88086b783ea0
88086b125300
[  453.698876]  88046267fd20 8104e3ff 
88046267fd58
[  453.707195] Call Trace:
[  453.709935]  [] mp_unregister_ioapic+0x125/0x180
[  453.716846]  [] acpi_unregister_ioapic+0x1f/0x40
[  453.723759]  [] acpi_ioapic_remove+0x5f/0xf0
[  453.730283]  [] acpi_pci_root_remove+0x2c/0x80
[  453.737002]  [] acpi_bus_trim+0x5a/0x8d
[  453.743039]  [] acpi_device_hotplug+0x1b7/0x418
[  453.749851]  [] acpi_hotplug_work_fn+0x1e/0x29
[  453.756570]  [] process_one_work+0x14f/0x3d0
[  453.763092]  [] worker_thread+0x125/0x4b0
[  453.769325]  [] ? __schedule+0x2b1/0x700
[  453.775459]  [] ? rescuer_thread+0x370/0x370
[  453.781981]  [] kthread+0xd8/0xf0
[  453.787435]  [] ? kthread_park+0x60/0x60
[  453.793570]  [] ret_from_fork+0x3f/0x70
[  453.800203]  [] ? kthread_park+0x60/0x60
[  453.806914] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89
e5 53 48 89 fb 48 c7 c7 f8 c0 e3 81 e8 87 69 66 00 48 8b 4b 20 b8 ea ff
ff ff <48> 8b 51 30 48 85 d2 74 1d 48 39 d3 75 0a eb 3f 48 39 c3 74 1b
[  453.829861] RIP  [] release_resource+0x22/0x80
[  453.837188]  RSP 
[  453.841673] CR2: 0030

Fix it by assigning the correct pointers to ioapics[i].iomem_res in
ioapic_setup_resources(). Also simplify the function by removing
the redundant 'num' variable.

Signed-off-by: Rui Wang 
---
 arch/x86/kernel/apic/io_apic.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index f253218..a90b131 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2563,29 +2563,25 @@ static struct resource * __init 
ioapic_setup_resources(void)
unsigned long n;
struct resource *res;
char *mem;
-   int i, num = 0;
+   int i;
 
-   for_each_ioapic(i)
-   num++;
-   if (num == 0)
+   if (nr_ioapics == 0)
return NULL;
 
n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
-   n *= num;
+   n *= nr_ioapics;
 
mem = alloc_bootmem(n);
res = (void *)mem;
 
-  

[PATCH 0/2] ioapic hot-removal bugs

[Rui Wang]

Hi All,

While testing ioapic hotplug, two bugs were found.

1) acpi_ioapic_add() is only called during hotadd of ioapics. Those
already present during system boot are not added, and thus cannot be
hot-removed.

2) ioapics[i].iomem_res were assigned the wrong pointers, causing panic
while hot-removing ioapics.

On a 4-socket brickland, hot-removal of the 3 sockets can be done
only after applying these two patches.

Regards,
Rui

Rui Wang (2):
  Support hot-removal of IOAPICs present during boot
  x86/ioapic: Fix wrong pointers in ioapic_setup_resources()

 arch/x86/kernel/apic/io_apic.c | 18 +++---
 drivers/acpi/internal.h|  2 --
 drivers/acpi/ioapic.c  |  7 ---
 drivers/acpi/pci_root.c|  2 +-
 drivers/pci/setup-bus.c|  5 -
 include/linux/acpi.h   |  3 +++
 6 files changed, 19 insertions(+), 18 deletions(-)

-- 
1.8.3.1

[PATCH 1/2] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Rui Wang]

IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.

Signed-off-by: Rui Wang 
---
 drivers/acpi/internal.h | 2 --
 drivers/acpi/ioapic.c   | 7 ---
 drivers/acpi/pci_root.c | 2 +-
 drivers/pci/setup-bus.c | 5 -
 include/linux/acpi.h| 3 +++
 5 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 1e6833a..898f314 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,10 +33,8 @@ int acpi_sysfs_init(void);
 void acpi_container_init(void);
 void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
-int acpi_ioapic_add(struct acpi_pci_root *root);
 int acpi_ioapic_remove(struct acpi_pci_root *root);
 #else
-static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
 static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; }
 #endif
 #ifdef CONFIG_ACPI_DOCK
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ccdc8db..0f272e2 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -189,16 +189,17 @@ exit:
return AE_OK;
 }
 
-int acpi_ioapic_add(struct acpi_pci_root *root)
+int acpi_ioapic_add(acpi_handle root_handle)
 {
acpi_status status, retval = AE_OK;
 
-   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle,
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
 UINT_MAX, handle_ioapic_add, NULL,
-root->device->handle, (void **)&retval);
+root_handle, (void **)&retval);
 
return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV;
 }
+EXPORT_SYMBOL_GPL(acpi_ioapic_add);
 
 int acpi_ioapic_remove(struct acpi_pci_root *root)
 {
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..53f5965 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -614,7 +614,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
-   acpi_ioapic_add(root);
+   acpi_ioapic_add(root->device->handle);
}
 
pci_lock_rescan_remove();
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..2f71167 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 unsigned int pci_flags;
@@ -1780,8 +1781,10 @@ void __init pci_assign_unassigned_resources(void)
 {
struct pci_bus *root_bus;
 
-   list_for_each_entry(root_bus, &pci_root_buses, node)
+   list_for_each_entry(root_bus, &pci_root_buses, node) {
pci_assign_unassigned_root_bus_resources(root_bus);
+   acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
+   }
 }
 
 void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..ca4d22f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -269,6 +269,9 @@ int acpi_unmap_cpu(int cpu);
 
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
 int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
+int acpi_ioapic_add(acpi_handle root);
+#else
+static inline int acpi_ioapic_add(acpi_handle root) { return 0; }
 #endif
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
-- 
1.8.3.1

GRSecurity, RMS, discussion excerpts

[concernedfossdev]

>From soylentnews:
https://soylentnews.org/comments.pl?threshold=-1&highlightthresh=-1&mode=improvedthreaded&commentsort=5&op=Change&sid=13849#post_comment
>Re:Playing lawyer (Score:2)
>by darkfeline (1030) on Sunday >June 05, @06:30AM (#355471) >Homepage
>
>But you didn't even address my argument. In fact, your long tirade affirms 
>half of my argument.
>
>GRsec didn't violate the terms of the GPL license. The GPL license requires 
>them to distribute their source code to their clients under the GPL license, 
>which they do.
>
>The GPL does not require one to continue doing business with one's clients. If 
>that were true, for example, Google would be legally bound to keep doing 
>business with all Android vendors perpetually. GRsec is perfectly free to stop 
>doing business with anyone who redistributes their GPL licensed source code.

-- 

Keep telling yourself that.

You are not studied in the law. Accept this.

You don't have the slightest clue how the law of agreements works (AKA: 
contracts etc)
which is why you say "you haven't addressed my point!"
I have. You are just too ignorant to realize that.

Similar to how most western peoples are too ignorant to realize men should be 
free to take as brides cute young girls, as once they were prior to feminism.

The fact of the matter is that GRSecurity is using the threat of an action or 
inaction to prevent sublicensees from enacting a privilege they have been given 
by the _original_ licensor to who's terms GRSecurity agreed, and to who's terms 
are the only thing _allowing_ GRSecurity to modify the kernel source code to 
create the derivative work and distribute it in the first place.

Obviously once you frustrate that agreement you lose your privileges under it. 
This is a basic point of the law of agreements. 

You cannot say "I get what I want, but fk the rest of your terms", even if you 
are "clever" about it.
The linux licensors said that any distributed derivative work shall be freely 
re-distributable.
When you come to that license and think to yourself "haha, I shall 
circumnavagate that clause and cause my derivative work to NOT be 
redistributable in the real world" you have committed bad faith vis-a-vis the 
agreement and the court will not, when the licensor sues you for copyright 
infringement, recognize the clauses that would protect you (they will give them 
no effect, that is your reward for making sure that other clauses 
(redistribution) would be ineffectual).

The linux licensors want to eventually have changes "come back" to them. They 
adopted the GPL for this purpose. You frustrate the use of one term, you cannot 
hide behind another.

Very simple, I don't understand why you don't get this, they teach this in the 
first month or two.

[PATCH v3 2/6] NVMe: Use pci_(request|release)_mem_regions

[Johannes Thumshirn]

Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
hand, use it in the NVMe driver.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Reviewed-by: Christoph Hellwig 
Cc: Christoph Hellwig 
Cc: Keith Busch 
Cc: Jens Axboe 
Cc: linux-n...@lists.infradead.org
---
 drivers/nvme/host/pci.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 4fd733f..e7d17ae 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1756,7 +1756,7 @@ static void nvme_dev_unmap(struct nvme_dev *dev)
 {
if (dev->bar)
iounmap(dev->bar);
-   pci_release_regions(to_pci_dev(dev->dev));
+   pci_release_mem_regions(to_pci_dev(dev->dev));
 }
 
 static void nvme_pci_disable(struct nvme_dev *dev)
@@ -1979,13 +1979,9 @@ static const struct nvme_ctrl_ops nvme_pci_ctrl_ops = {
 
 static int nvme_dev_map(struct nvme_dev *dev)
 {
-   int bars;
struct pci_dev *pdev = to_pci_dev(dev->dev);
 
-   bars = pci_select_bars(pdev, IORESOURCE_MEM);
-   if (!bars)
-   return -ENODEV;
-   if (pci_request_selected_regions(pdev, bars, "nvme"))
+   if (pci_request_mem_regions(pdev, "nvme"))
return -ENODEV;
 
dev->bar = ioremap(pci_resource_start(pdev, 0), 8192);
@@ -1994,7 +1990,7 @@ static int nvme_dev_map(struct nvme_dev *dev)
 
return 0;
   release:
-   pci_release_regions(pdev);
+   pci_release_mem_regions(pdev);
return -ENODEV;
 }
 
-- 
1.8.5.6

[PATCH v3 1/6] PCI: Add helpers to request/release memory and I/O regions

[Johannes Thumshirn]

Add helpers to request and release a device's memory or I/O regions.

With these helpers in place, one does not need to select a device's memory or
I/O regions with pci_select_bars() prior to requesting or releasing them.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Reviewed-by: Christoph Hellwig 
Cc: Christoph Hellwig 
---
 include/linux/pci.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 932ec74..9ee6569 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1401,6 +1401,34 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev 
*pdev, bool decode,
  unsigned int command_bits, u32 flags);
 void pci_register_set_vga_state(arch_set_vga_state_t func);
 
+static inline int
+pci_request_io_regions(struct pci_dev *pdev, const char *name)
+{
+   return pci_request_selected_regions(pdev,
+   pci_select_bars(pdev, IORESOURCE_IO), name);
+}
+
+static inline void
+pci_release_io_regions(struct pci_dev *pdev)
+{
+   return pci_release_selected_regions(pdev,
+   pci_select_bars(pdev, IORESOURCE_IO));
+}
+
+static inline int
+pci_request_mem_regions(struct pci_dev *pdev, const char *name)
+{
+   return pci_request_selected_regions(pdev,
+   pci_select_bars(pdev, IORESOURCE_MEM), name);
+}
+
+static inline void
+pci_release_mem_regions(struct pci_dev *pdev)
+{
+   return pci_release_selected_regions(pdev,
+   pci_select_bars(pdev, IORESOURCE_MEM));
+}
+
 #else /* CONFIG_PCI is not enabled */
 
 static inline void pci_set_flags(int flags) { }
-- 
1.8.5.6

[PATCH v3 5/6] ethernet/intel: Use pci_(request|release)_mem_regions

[Johannes Thumshirn]

Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
hand, use it in the Intel ethernet drivers.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Cc: Jeff Kirsher 
Cc: David S. Miller 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
Acked-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/e1000e/netdev.c|  6 ++
 drivers/net/ethernet/intel/fm10k/fm10k_pci.c  | 11 +++
 drivers/net/ethernet/intel/i40e/i40e_main.c   |  9 +++--
 drivers/net/ethernet/intel/igb/igb_main.c | 10 +++---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  9 +++--
 5 files changed, 14 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9b4ec13..ecd8d15 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7284,8 +7284,7 @@ err_flashmap:
 err_ioremap:
free_netdev(netdev);
 err_alloc_etherdev:
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 err_pci_reg:
 err_dma:
pci_disable_device(pdev);
@@ -7352,8 +7351,7 @@ static void e1000_remove(struct pci_dev *pdev)
if ((adapter->hw.flash_address) &&
(adapter->hw.mac.type < e1000_pch_spt))
iounmap(adapter->hw.flash_address);
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 
free_netdev(netdev);
 
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c 
b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index 4eb7a6f..ad28e87 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1940,10 +1940,7 @@ static int fm10k_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
goto err_dma;
}
 
-   err = pci_request_selected_regions(pdev,
-  pci_select_bars(pdev,
-  IORESOURCE_MEM),
-  fm10k_driver_name);
+   err = pci_request_mem_regions(pdev, fm10k_driver_name);
if (err) {
dev_err(&pdev->dev,
"pci_request_selected_regions failed: %d\n", err);
@@ -2034,8 +2031,7 @@ err_sw_init:
 err_ioremap:
free_netdev(netdev);
 err_alloc_netdev:
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 err_pci_reg:
 err_dma:
pci_disable_device(pdev);
@@ -2086,8 +2082,7 @@ static void fm10k_remove(struct pci_dev *pdev)
 
free_netdev(netdev);
 
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 
pci_disable_pcie_error_reporting(pdev);
 
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 3449129..37592b1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10779,8 +10779,7 @@ static int i40e_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
}
 
/* set up pci connections */
-   err = pci_request_selected_regions(pdev, pci_select_bars(pdev,
-  IORESOURCE_MEM), i40e_driver_name);
+   err = pci_request_mem_regions(pdev, i40e_driver_name);
if (err) {
dev_info(&pdev->dev,
 "pci_request_selected_regions failed %d\n", err);
@@ -11277,8 +11276,7 @@ err_ioremap:
kfree(pf);
 err_pf_alloc:
pci_disable_pcie_error_reporting(pdev);
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 err_pci_reg:
 err_dma:
pci_disable_device(pdev);
@@ -11387,8 +11385,7 @@ static void i40e_remove(struct pci_dev *pdev)
 
iounmap(hw->hw_addr);
kfree(pf);
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index 55a1405c..466087f 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2288,9 +2288,7 @@ static int igb_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
}
 
-   err = pci_request_selected_regions(pdev, pci_select_bars(pdev,
-

Re: [PATCH 0/5] Add suspend-to-idle validation for Intel SoCs

[Pavel Machek]

On Wed 2016-06-01 21:33:24, dbaseh...@chromium.org wrote:
> From: Derek Basehore 
> 
> This patch set adds support for catching errors when entering freeze
> on Intel Skylake SoCs. Support for this can be added to newer SoCs in
> later patches.
> 
> Verification is done by waking up the CPU once every X (default 10)
> seconds to check the residency of S0ix. This can't be verified before
> attempting to enter S0ix through mwait, so we have to repeatedly
> verify entry into that state. Successfully entering S0ix is no
> guarantee that it will be entered on the next attempt, so we have to
> schedule another check. This has a minimal power impact of <1% of the
> total system power on our systems.

Dunno. Should this be protected with something like CONFIG_TEST_SLEEP?
People probably don't want this for production...

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

[PATCH v3] drm/dsi: Implement set tear scanline

[Vinay Simha BN]

Provide a small convenience wrapper that transmits
a set_tear_scanline command.

Cc: Archit Taneja 
Cc: John Stultz 
Cc: Thierry Reding 
Cc: Sumit Semwal 
Cc: Jani Nikula 
Signed-off-by: Vinay Simha BN 

--
v1:
  * helper function suggested by Thierry
for set_tear_scanline
  * Also includes small build fixes from Sumit Semwal.

v2:
  * one scanline parameter suggested by jani

v3:
  * passing the payload properly as suggested by jani
--
---
 drivers/gpu/drm/drm_mipi_dsi.c | 22 ++
 include/drm/drm_mipi_dsi.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..7938ce7 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,28 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
 
 /**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param: STS[10:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u16 param)
+{
+   u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param >> 8,
+ param & 0xff };
+   ssize_t err;
+
+   err = mipi_dsi_generic_write(dsi, payload, sizeof(payload));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
  * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
  *data used by the interface
  * @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..ec55285 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,7 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device 
*dsi, u16 start,
u16 end);
 int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
  u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u16 param);
 int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
 int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 enum mipi_dsi_dcs_tear_mode mode);
-- 
2.1.2

[PATCH v3 4/6] GenWQE: Use pci_(request|release)_mem_regions

[Johannes Thumshirn]

Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
hand, use it in the genwqe driver.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Cc: Frank Haverkamp 
Cc: Greg Kroah-Hartman 
---
 drivers/misc/genwqe/card_base.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/genwqe/card_base.c b/drivers/misc/genwqe/card_base.c
index 4cf8f82..cb398be 100644
--- a/drivers/misc/genwqe/card_base.c
+++ b/drivers/misc/genwqe/card_base.c
@@ -182,7 +182,7 @@ static void genwqe_dev_free(struct genwqe_dev *cd)
  */
 static int genwqe_bus_reset(struct genwqe_dev *cd)
 {
-   int bars, rc = 0;
+   int rc = 0;
struct pci_dev *pci_dev = cd->pci_dev;
void __iomem *mmio;
 
@@ -193,8 +193,7 @@ static int genwqe_bus_reset(struct genwqe_dev *cd)
cd->mmio = NULL;
pci_iounmap(pci_dev, mmio);
 
-   bars = pci_select_bars(pci_dev, IORESOURCE_MEM);
-   pci_release_selected_regions(pci_dev, bars);
+   pci_release_mem_regions(pci_dev);
 
/*
 * Firmware/BIOS might change memory mapping during bus reset.
@@ -218,7 +217,7 @@ static int genwqe_bus_reset(struct genwqe_dev *cd)
GENWQE_INJECT_GFIR_FATAL |
GENWQE_INJECT_GFIR_INFO);
 
-   rc = pci_request_selected_regions(pci_dev, bars, genwqe_driver_name);
+   rc = pci_request_mem_regions(pci_dev, genwqe_driver_name);
if (rc) {
dev_err(&pci_dev->dev,
"[%s] err: request bars failed (%d)\n", __func__, rc);
@@ -1071,7 +1070,6 @@ static int genwqe_pci_setup(struct genwqe_dev *cd)
int err, bars;
struct pci_dev *pci_dev = cd->pci_dev;
 
-   bars = pci_select_bars(pci_dev, IORESOURCE_MEM);
err = pci_enable_device_mem(pci_dev);
if (err) {
dev_err(&pci_dev->dev,
@@ -1080,7 +1078,7 @@ static int genwqe_pci_setup(struct genwqe_dev *cd)
}
 
/* Reserve PCI I/O and memory resources */
-   err = pci_request_selected_regions(pci_dev, bars, genwqe_driver_name);
+   err = pci_request_mem_regions(pci_dev, genwqe_driver_name);
if (err) {
dev_err(&pci_dev->dev,
"[%s] err: request bars failed (%d)\n", __func__, err);
@@ -1160,8 +1158,7 @@ static void genwqe_pci_remove(struct genwqe_dev *cd)
if (cd->mmio)
pci_iounmap(pci_dev, cd->mmio);
 
-   bars = pci_select_bars(pci_dev, IORESOURCE_MEM);
-   pci_release_selected_regions(pci_dev, bars);
+   pci_release_mem_regions(pci_dev);
pci_disable_device(pci_dev);
 }
 
-- 
1.8.5.6

Re: [BUGFIX][PATCH v6 2/9] perf config: If collect_config() is failed, finally free a config set after it is done

[Taeung Song]

On 06/07/2016 06:37 AM, Taeung Song wrote:



On 06/07/2016 05:23 AM, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 06, 2016 at 07:52:53PM +0900, Taeung Song escreveu:

Because of die() at perf_parse_file() a config set was freed
in collect_config(), if failed.
But it is natural to free a config set after collect_config() is done
when some problems happened.

So, in case of failure, lastly free a config set at
perf_config_set__new()
instead of freeing the config set in collect_config().

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
  tools/perf/util/config.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index b500737..d013f90 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -639,7 +639,6 @@ static int collect_config(const char *var, const
char *value,

  out_free:
  free(key);
-perf_config_set__delete(set);
  return -1;
  }

@@ -649,7 +648,8 @@ struct perf_config_set *perf_config_set__new(void)

  if (set) {
  INIT_LIST_HEAD(&set->sections);
-perf_config(collect_config, set);
+if (perf_config(collect_config, set) < 0)
+perf_config_set__delete(set);
  }

  return set;


You can't do that, there is something missing, without looking at the
code I think you need:

  if (set) {
  INIT_LIST_HEAD(&set->sections);
-perf_config(collect_config, set);
+if (perf_config(collect_config, set) < 0) {
+perf_config_set__delete(set);
+set = NULL;
+}
  }

  return set;

No?



Granted
Sorry for missing above..

I modified using 'return NULL;' instead of 'set = NULL;' as below

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index c73f1c4..cb749d3 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -643,7 +643,6 @@ static int collect_config(const char *var, const
char *value,

  out_free:
  free(key);
-perf_config_set__delete(set);
  return -1;
  }

@@ -653,7 +652,10 @@ struct perf_config_set *perf_config_set__new(void)

  if (set) {
  INIT_LIST_HEAD(&set->sections);
-perf_config(collect_config, set);
+if (perf_config(collect_config, set) < 0) {
+perf_config_set__delete(set);
+return NULL;
+}
  }

  return set;

Because in near future, perf_config_set__delete() will use zfree().

will send changed this patch soon !
Thank you for your review :)



Hum.. my answer was stupid.
There isn't difference between 'return NULL;' and 'set = NULL;'
as a result at perf_config_set__new().
And zfree() at perf_config_set__delete() aren't related to this situation..

Anyway.. I'll send v7 with changed this patch as you said!!

Thanks,
Taeung

[PATCH v3 3/6] lpfc: Use pci_(request|release)_mem_regions

[Johannes Thumshirn]

Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
hand, use it in the lpfc driver.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Acked-by: Dick Kennedy 
Cc: James Smart 
Cc: Dick Kennedy 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/scsi/lpfc/lpfc_init.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index f57d02c..a8735f7 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -4775,20 +4775,17 @@ static int
 lpfc_enable_pci_dev(struct lpfc_hba *phba)
 {
struct pci_dev *pdev;
-   int bars = 0;
 
/* Obtain PCI device reference */
if (!phba->pcidev)
goto out_error;
else
pdev = phba->pcidev;
-   /* Select PCI BARs */
-   bars = pci_select_bars(pdev, IORESOURCE_MEM);
/* Enable PCI device */
if (pci_enable_device_mem(pdev))
goto out_error;
/* Request PCI resource for the device */
-   if (pci_request_selected_regions(pdev, bars, LPFC_DRIVER_NAME))
+   if (pci_request_mem_regions(pdev, LPFC_DRIVER_NAME))
goto out_disable_device;
/* Set up device as PCI master and save state for EEH */
pci_set_master(pdev);
@@ -4805,7 +4802,7 @@ out_disable_device:
pci_disable_device(pdev);
 out_error:
lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
-   "1401 Failed to enable pci device, bars:x%x\n", bars);
+   "1401 Failed to enable pci device\n");
return -ENODEV;
 }
 
@@ -4820,17 +4817,14 @@ static void
 lpfc_disable_pci_dev(struct lpfc_hba *phba)
 {
struct pci_dev *pdev;
-   int bars;
 
/* Obtain PCI device reference */
if (!phba->pcidev)
return;
else
pdev = phba->pcidev;
-   /* Select PCI BARs */
-   bars = pci_select_bars(pdev, IORESOURCE_MEM);
/* Release PCI resource and disable PCI device */
-   pci_release_selected_regions(pdev, bars);
+   pci_release_mem_regions(pdev);
pci_disable_device(pdev);
 
return;
@@ -9705,7 +9699,6 @@ lpfc_pci_remove_one_s3(struct pci_dev *pdev)
struct lpfc_vport **vports;
struct lpfc_hba   *phba = vport->phba;
int i;
-   int bars = pci_select_bars(pdev, IORESOURCE_MEM);
 
spin_lock_irq(&phba->hbalock);
vport->load_flag |= FC_UNLOADING;
@@ -9780,7 +9773,7 @@ lpfc_pci_remove_one_s3(struct pci_dev *pdev)
 
lpfc_hba_free(phba);
 
-   pci_release_selected_regions(pdev, bars);
+   pci_release_mem_regions(pdev);
pci_disable_device(pdev);
 }
 
-- 
1.8.5.6

Re: [PATCH v2 00/11] pwm: Add support for PWM Capture

[Lee Jones]

On Mon, 06 Jun 2016, Boris Brezillon wrote:

> On Mon, 6 Jun 2016 16:32:31 +0100
> Lee Jones  wrote:
> 
> > On Fri, 29 Apr 2016, Boris Brezillon wrote:
> > 
> > > Hi Lee,
> > > 
> > > On Fri, 22 Apr 2016 11:18:04 +0100
> > > Lee Jones  wrote:
> > >   
> > > > The first part of this set extends the current PWM API to allow external
> > > > code to request a PWM Capture.  Subsequent patches then make use of the
> > > > new API by providing a userspace offering via /sysfs.  The final part of
> > > > the set supplies PWM Capture functionality into the already existing STi
> > > > PWM driver.  
> > > 
> > > Is there a reason you decided to not put this driver in IIO? IMHO, it
> > > would be more appropriate to make your PWM device an MFD that can either
> > > bind to the PWM or the capture driver.
> > > And BTW, IIO already has a sysfs interface (you may have to extend the
> > > API to support your type of capture though).  
> > 
> > Multi-Function Device drivers can only be justified if the IP
> > contained does not and can not live in a single subsystem.  The IP
> > which controls both PWM-in and PWM-out in this device is the same.  I
> > can't fathom a sane reason why you would wish to separate this
> > functionality over multiple subsystems.
> > 
> 
> Well, I still think what you describe as PWM-in is actually a capture
> device that would perfectly fit in the IIO subsystem, and I guess you
> can't use the PWM IP as a capture and waveform generator device as the
> same time, which is why I suggested the MFD approach to select the mode.

We only tend to place devices in IIO if they do not fit anywhere
else.  There are lots of unidirectional and bidirectional capture
devices that belong in other subsystems.

This is a PWM device through and through, and the API fits in
perfectly with the remainder of the subsystem.  To attempt to manage
and maintain similar functionality spread over more than one subsystem
when there is no clear requirement (like there is with a chip
containing a GPIO, Regulator and HWMON components for inistance),
would be unnecessarily over-complicating matters.

> Anyway, I'm not the PWM or the IIO maintainer, so I'm just sharing my
> opinion here.
> 
> Regards,
> 
> Boris
> 

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

[PATCH v3 6/6] alx: Use pci_(request|release)_mem_regions

[Johannes Thumshirn]

Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
hand, use it in the ethernet drivers.

Suggested-by: Christoph Hellwig 
Signed-off-by: Johannes Thumshirn 
Cc: Jay Cliburn 
Cc: Chris Snook 
Cc: David S. Miller 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
---
 drivers/net/ethernet/atheros/alx/main.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 55b118e..d2363de 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1238,7 +1238,7 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
struct alx_priv *alx;
struct alx_hw *hw;
bool phy_configured;
-   int bars, err;
+   int err;
 
err = pci_enable_device_mem(pdev);
if (err)
@@ -1258,11 +1258,10 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
}
 
-   bars = pci_select_bars(pdev, IORESOURCE_MEM);
-   err = pci_request_selected_regions(pdev, bars, alx_drv_name);
+   err = pci_request_mem_regions(pdev, alx_drv_name);
if (err) {
dev_err(&pdev->dev,
-   "pci_request_selected_regions failed(bars:%d)\n", bars);
+   "pci_request_mem_regions failed\n");
goto out_pci_disable;
}
 
@@ -1388,7 +1387,7 @@ out_unmap:
 out_free_netdev:
free_netdev(netdev);
 out_pci_release:
-   pci_release_selected_regions(pdev, bars);
+   pci_release_mem_regions(pdev);
 out_pci_disable:
pci_disable_device(pdev);
return err;
@@ -1407,8 +1406,7 @@ static void alx_remove(struct pci_dev *pdev)
 
unregister_netdev(alx->dev);
iounmap(hw->hw_addr);
-   pci_release_selected_regions(pdev,
-pci_select_bars(pdev, IORESOURCE_MEM));
+   pci_release_mem_regions(pdev);
 
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
-- 
1.8.5.6

Re: [PATCH V3 1/2] thermal: max77620: Add DT binding doc for thermal driver

[Keerthy]

On Tuesday 07 June 2016 12:08 PM, Laxman Dewangan wrote:


On Tuesday 07 June 2016 09:25 AM, Keerthy wrote:



On Monday 06 June 2016 05:14 PM, Laxman Dewangan wrote:

Maxim Semiconductor MAX77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add DT binding document to details out the DT property related
to MAX77620 thermal functionality.

Signed-off-by: Laxman Dewangan 
---
  .../bindings/thermal/thermal-max77620.txt  | 64
++
  1 file changed, 64 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/thermal/thermal-max77620.txt

diff --git
a/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
new file mode 100644
index 000..5a500d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
@@ -0,0 +1,64 @@
+Thermal driver for MAX77620 Power management IC from Maxim
Semiconductor.
+
+Maxim Semiconductor MAX77620 supports alarm interrupts when its
+die temperature crosses 120C and 140C. These threshold temperatures
+are not configurable. Device does not provide the real temperature
+of die other than just indicating whether temperature is above or
+below threshold level.
+
+Required properties:
+---
+#thermal-sensor-cells:Please refer

+for more details.
+The value must be 0.
+
+For more details, please refer generic thermal DT binding document
+.
+
+Please refer  for mfd DT binding
+document for the MAX77620.
+
+Example:
+
+#include 
+#include 
+...
+
+i2c@7000d000 {
+spmic: max77620@3c {
+compatible = "maxim,max77620";
+:
+#thermal-sensor-cells = <0>;
+:::
+};
+};
+
+cool_dev: cool-dev {
+compatible = "cooling-dev";
+#cooling-cells = <2>;
+};
+
+thermal-zones {
+PMIC-Die {
+polling-delay = <0>;
+polling-delay-passive = <0>;
+thermal-sensors = <&spmic>;
+
+trips {
+die_temp_thresh: hot-die {
+temperature = <12>;
+type = "active";
+hysteresis = <0>;
+};
+};


What about 140C? Isn't that a critical trip point?


Yes, it is there and it can be populated/extended on the same way and
handled.

This is just an example.


Yes i understand that. My question was more w.r.t different types of 
critical points. As i can see 120C is an active trip point.


140C will be a critical trip point and system will have to be shutdown 
right? IMHO you can add that to the example as well since its pretty 
different than the above active trip point.


- Keerthy







+
+cooling-maps {
+map0 {
+trip = <&die_temp_thresh>;
+cooling-device = <&cool_dev THERMAL_NO_LIMIT
+  THERMAL_NO_LIMIT>;
+contribution = <100>;
+};
+};
+};
+};

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

[Kishon Vijay Abraham I]

Hi,

On Tuesday 07 June 2016 09:01 AM, Frank Wang wrote:
> Hi Heiko,
> 
> On 2016/6/7 10:59, Frank Wang wrote:
>> Hi Heiko & Mark,
>>
>> On 2016/6/6 20:33, Heiko Stübner wrote:
>>> Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
 On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
> Signed-off-by: Frank Wang 
> ---
>
> Changes in v3:
>   - Added 'clocks' and 'clock-names' optional properties.
>   - Specified 'otg-port' and 'host-port' as the sub-node name.
>
> Changes in v2:
>   - Changed vbus_host optional property from gpio to regulator.
>   - Specified vbus_otg-supply optional property.
>   - Specified otg_id and otg_bvalid property.
> .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
>    1 file changed, 60 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
> diff --git
> a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
> file mode 100644
> index 000..0b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> @@ -0,0 +1,60 @@
> +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
> +
> +Required properties (phy (parent) node):
> + - compatible : should be one of the listed compatibles:
> +* "rockchip,rk3366-usb2phy"
> +* "rockchip,rk3399-usb2phy"
> + - #clock-cells : should be 0.
> + - clock-output-names : specify the 480m output clock name.
> +
> +Optional properties:
> + - clocks : phandle + phy specifier pair, for the input clock of phy.
> + - clock-names : input clock name of phy, must be "phyclk".
> + - vbus_host-supply : phandle to a regulator that supplies host vbus.
> + - vbus_otg-supply : phandle to a regulator that supplies otg vbus.
 Nit: s/_/-/ here.
>>> Something I only stumbled over yesterday for the first time on my rk3288-
>>> popmetal: The phy subnodes seem to be able to use a generic phy-supply
>>> property from inside the phy-core itself, see:
>>>
>>> https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aaf6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597
>>>
>>>
>>> for my WIP code for that other board.
>>>
>>
>> Ah, good comments! I will try later, if it is practicable, I shall correct it
>> into the next patches (patch v4).
>>
> 
> I am sorry to tell you that seems unworkable, because we have two sub-nodes
> (phy-ports) in one parent-node (phy),
> what is more, the 'phy-supply' property can only put into parent-node, I
> believe it can not be differentiated types of ports.

'phy-supply' is a property of the phy node and not the 'phy-provider' node. So
IMO this should work. What problem do you see?

Thanks
Kishon

[PATCH v3 0/6] Introduce pci_(request|release)_(mem|io)_regions

[Johannes Thumshirn]

The first patch in this series introduces the following 4 helper functions to
the PCI core:

* pci_request_mem_regions()
* pci_request_io_regions()
* pci_release_mem_regions()
* pci_release_io_regions()

which encapsulate the request and release of a PCI device's memory or I/O
bars.

The subsequent patches convert the drivers, which use the
pci_request_selected_regions(pdev, 
pci_select_bars(pdev, IORESOURCE_MEM), name); 
and similar pattern to use the new interface.

This was suggested by Christoph Hellwig in
http://lists.infradead.org/pipermail/linux-nvme/2016-May/004570.html and
tested on kernel v4.6 with NVMe.

The conversion of the drivers has been performed by the following coccinelle
spatch:
// IORESOURCE_MEM
@@
expression err, pdev, name;
@@

- err = pci_request_selected_regions(pdev, pci_select_bars(pdev, 
IORESOURCE_MEM), name);
+ err = pci_request_mem_regions(pdev, name);

@@
expression pdev;
@@
- pci_release_selected_regions(pdev, pci_select_bars(pdev, IORESOURCE_MEM));
+ pci_release_mem_regions(pdev);

@@
expression err, pdev, name;
identifier bars;
@@
- bars = pci_select_bars(pdev, IORESOURCE_MEM);
...
- err = pci_request_selected_regions(pdev, bars, name);
+ err = pci_request_mem_regions(pdev, name);

@@
expression pdev;
identifier bars;
@@
- bars = pci_select_bars(pdev, IORESOURCE_MEM);
...
- pci_release_selected_regions(pdev, bars);
+ pci_release_mem_regions(pdev);

// IORESOURCE_IO
@@
expression err, pdev, name;
@@

- err = pci_request_selected_regions(pdev, pci_select_bars(pdev,
IORESOURCE_IO), name);
+ err = pci_request_io_regions(pdev, name);

@@
expression pdev;
@@
- pci_release_selected_regions(pdev, pci_select_bars(pdev, IORESOURCE_IO));
+ pci_release_io_regions(pdev);

@@
expression err, pdev, name;
identifier bars;
@@
- bars = pci_select_bars(pdev, IORESOURCE_IO);
...
- err = pci_request_selected_regions(pdev, bars, name);
+ err = pci_request_io_regions(pdev, name);

@@
expression pdev;
identifier bars;
@@
- bars = pci_select_bars(pdev, IORESOURCE_IO);
...
- pci_release_selected_regions(pdev, bars);
+ pci_release_io_regions(pdev);

Changes since v2:
* Fixed compilation error on platforms with CONFIG_PCI=n
* Added Jeff's Acked-by on the Intel ethernet patch
* Added Dick's Acked-by on the lpfc patch

Changes since v1:
* Fixed indendatoin in pci.h patch to not cross the 80 chars boundary.
* Split Ethernet patches into two, one for Atheros and one for Intel drivers.
* Correctly named lpfc patch.
* Converted init-path of lpfc driver as well.
* Added Reviewed-by tags were appropriate.

Johannes Thumshirn (6):
  PCI: Add helpers to request/release memory and I/O regions
  NVMe: Use pci_(request|release)_mem_regions
  lpfc: Use pci_(request|release)_mem_regions
  GenWQE: Use pci_(request|release)_mem_regions
  ethernet/intel: Use pci_(request|release)_mem_regions
  alx: Use pci_(request|release)_mem_regions

 drivers/misc/genwqe/card_base.c   | 13 +
 drivers/net/ethernet/atheros/alx/main.c   | 12 +---
 drivers/net/ethernet/intel/e1000e/netdev.c|  6 ++
 drivers/net/ethernet/intel/fm10k/fm10k_pci.c  | 11 +++
 drivers/net/ethernet/intel/i40e/i40e_main.c   |  9 +++--
 drivers/net/ethernet/intel/igb/igb_main.c | 10 +++---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  9 +++--
 drivers/nvme/host/pci.c   | 10 +++---
 drivers/scsi/lpfc/lpfc_init.c | 15 --
 include/linux/pci.h   | 28 +++
 10 files changed, 59 insertions(+), 64 deletions(-)

Cc: Christoph Hellwig 
Cc: Keith Busch 
Cc: Jens Axboe 
Cc: linux-n...@lists.infradead.org
Cc: James Smart 
Cc: Dick Kennedy 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Frank Haverkamp 
Cc: Greg Kroah-Hartman 
Cc: Jay Cliburn 
Cc: Chris Snook 
Cc: Jeff Kirsher 
Cc: David S. Miller 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
-- 
1.8.5.6

Re: [PATCH 7/9] pinctrl: zynq: make it explicitly non-modular

[Michal Simek]

On 7.6.2016 04:43, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> config PINCTRL_ZYNQ
> bool "Pinctrl driver for Xilinx Zynq"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Linus Walleij 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---
>  drivers/pinctrl/pinctrl-zynq.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
> index 8fdc60c5aeaf..7afdbede6823 100644
> --- a/drivers/pinctrl/pinctrl-zynq.c
> +++ b/drivers/pinctrl/pinctrl-zynq.c
> @@ -20,7 +20,7 @@
>   */
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1210,7 +1210,6 @@ static const struct of_device_id 
> zynq_pinctrl_of_match[] = {
>   { .compatible = "xlnx,pinctrl-zynq" },
>   { }
>  };
> -MODULE_DEVICE_TABLE(of, zynq_pinctrl_of_match);
>  
>  static struct platform_driver zynq_pinctrl_driver = {
>   .driver = {
> @@ -1225,13 +1224,3 @@ static int __init zynq_pinctrl_init(void)
>   return platform_driver_register(&zynq_pinctrl_driver);
>  }
>  arch_initcall(zynq_pinctrl_init);
> -
> -static void __exit zynq_pinctrl_exit(void)
> -{
> - platform_driver_unregister(&zynq_pinctrl_driver);
> -}
> -module_exit(zynq_pinctrl_exit);
> -
> -MODULE_AUTHOR("Sören Brinkmann ");
> -MODULE_DESCRIPTION("Xilinx Zynq pinctrl driver");
> -MODULE_LICENSE("GPL");
> 

Acked-by: Michal Simek 

Thanks,
Michal

Re: [PATCH 0/7] add reST/sphinx-doc to linux documentation

[Daniel Vetter]

On Mon, Jun 6, 2016 at 6:32 PM, Markus Heiser  wrote:
> From: "Heiser, Markus" 
>
> Hi Jonathan, Jani, all -
>
> I merged the work from sphkerneldoc POC [1], into branch (on v4.7-rc2)
>
> git://github.com/return42/linux.git linux-doc-reST
>
> The specification of the implementation is the (new) kernel-doc-HOWTO book 
> which
> is a part of the patch series (also online avaliable at [2]).
>
> The kernel-doc-HOWTO book is a rewrite of the kernel-doc-nano-HOWTO.txt,
> taking reST extension into account. It serves several purposes:
>
> * user guide for kernel developers
> * specification of the kernel-doc parser
> * test case
>
> The kernel_doc.py parser is a python implementation of the kernel-doc-HOWTO, 
> the
> kernel-doc perl script is not needed for reST builds.  The python variant of 
> the
> kernel-doc parser supports the markup modes:
>
>  * kernel-doc (vintage)
>  * reST
>
> This series also includes the reST directives describe in the 
> kernel-doc-HOWTO:
>
> * kernel-doc (uses/imports the parser from kernel_doc.py)
> * flat-table (table notation with meaningfull diffs)
>
> The Python/Sphinx extensions placed in the scripts/site-packages folder. With
> this folder a minimal python infrastructure is provided.
>
> The basic sphinx-build infrastructure consists of:
>
> * Documentation/Makefile.reST & Documentation/conf.py
>
>   Makefile and basic 'sphinx config' file to build the various reST
>   documents and output formats. Provides the basic sphinx-doc build
>   infrastructure including the *sphinx-subprojects* feature. With this
>   feature each book can be build and distributed stand-alone.
>
> * Documentation/books
>
>   In this folder, the books with reST markup are placed. To
>   provide *sphinx-subprojects*, each book has its one folder and
>   a (optional) Documentation/books/{book-name}.conf file
>   which *overwrites* the basic configuration from Documentation/conf.py
>
> Any comments are welcome, but please read [2] first.

I think getting the flat-table directive landed would be great. We
have a similarly annoying table in gpu.tmpl where the ascii-art tables
fall short and are annoying. We want to split it up, but that's not a
short-term solution suitable for conversion. Atm it's licensed under
gplv3, which is incompatible with the kernel, so need to fix that.

I'm still not sold on the vintage-kerneldoc idea. At least in my
experience (after first converting to asciidoc and now to sphinx) this
is a non-issue. Yes, there's the oddball misrendering, but that's no
worse than the oddball typo. And a really good way for
drive-by-contributors and newbies to send in a few useful patches.
Personally I'm totally happy to have that bit of ugliness, same way I
don't reject patches just because they trip over checkpatch.pl in some
minor detail. The downside otoh means we'll have to forever maintain 2
versions of kernel-doc, and I don't want that. Jani&me have already
ripped out some of the more bonghits features of kernel-doc (like
anything with a \w: is a heading and other nonsense like that). The
only thing we really need to keep as special is the overall kerneldoc
layout, and the special referencing using &, %, @ and friends.

Reimplementing kernel-doc in python is also something Jani&I
discussed. But I think it only makes sense if we go ahead and also
modernize the parser, i.e. use something like python-clang to parse C,
and build a modern parser-combinators thing for the kernel-doc itself.
The regex state machinery is a horror show, whether it's written in
cargo-culted perl or python.

I agree that we need to update the kernel-doc howto (and Jani's
working on that already too), but I think there's no need to split up
that finely. Maybe that's a bit against sphinx best practices, but
right now we have rather large documents (both plain text and
docbook). Splitting definitely makes sense in some cases (e.g.
gpu.tmpl is only this large because we couldn't do cross-template
referencing), but by-and-large I think the current splitting is mostly
reasonable. A better demonstration vehicle is imo converting all
existing .tmpl to .rst. And also making sure the new kernel-doc is
still able to parse all existing kernel-doc comments, even when
they're not pulled into .tmpl files. Jani has done that (using
hacked-up versions of the sphinx-lint script) for his tree, making
sure there's no unexpected changes anywhere.

I think next steps would be:
- rebase flat-table onto Jani's work and relicense under gplv2
- look into rewriting kernel-doc in python more as a long-term project
- start converting docs instead - I really want to start reaping
benefits of all this work as soon as possible.

Thanks, Daniel


>
> With regards
>
>   -- Markus --
>
> [1] https://return42.github.io/sphkerneldoc
> [2] https://return42.github.io/sphkerneldoc/books/kernel-doc-HOWTO
>
>
>
> Heiser, Markus (7):
>   python: add scripts/site-packages
>   sphinx-doc: add basic sphinx-build infrastructure
>   kernel-doc-HOWTO: add kernel

Re: Article on GRSecurity, RMS, etc.

[concernedfossdev]

> My own life in the Linux world is constant opposition.
> 
> Every idea you bring to the table, gets shot down.
> 
> You get no support for anything you want to do. If it doesn't agree with
> them, you've already lost.

I have encountered the same thing.
It is known as "design by committee" in other fields.

The solution I found is to just fork the FOSS games and never look back.

It's so much easier to get things done when you're the only one, at-least
once the original code-base has what you want from it. No months long
discussions for each new game feature, no meeting half way, etc.

> They want the code you have yet to produce, but they will try to prevent
> you from producing it.
> 
> Then if you do manage to produce it on your own, they want it, and if
> they like it after all, they will take it.
> 
> And that is the issue I have with Linux.

The Techies have been saying this: "grsecurity sucks, but they can do this, GPL 
is the BSD license
aslong as you have the presence of mind to draft an NDA"

The other side of the legal debate has been saying this: "grsecurity is vital, 
we don't want it to
go closed, if it is closed it is useless to us, it is sad to see free software 
become unfree, it is
like the end of a dream and the GPL was _supposed_ to prevent this. We do NOT 
want to return to the
shareware days and the good thing about free / opensource software, the magic, 
was that is _was_
fully featured software that was fully open and was of no cost: the only cost 
was the labor we all
contributed and was contributed back".

You aren't supposed to make money with libre software really: the whole point 
is that I hack on it,
and give it away, you hack on it, and give it away (and back), etc etc etc.

It was NOT supposed to be shareware, or a "preview". If someone wants that: 
just do not base your
derivative work on opensource "copylefted" works.

It would be better if GRSecurity, and any other important opensource software, 
were abandoned by
it's author than for it to become closed source but still be developed:

If it were abandoned there would be a _chance_ that some other dev would pick 
it up.
If it just goes closed source, that chance is diminished because the original 
dev can always out
code any new devs and the new guys on the open-fork would become dejected and 
fail and we would be
left with no grsecurity (as the closed one would be the only one) and a 
worthless kernel because it
cannot be secured.

This debate's goal, from the beginning, is to head off the closing of 
grsecurity, to plead with
Spender to not leave the FreeSoftware reservation, to not contribute to the 
sharewareization of
libre software.

Re: [PATCH v4] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Pali Rohár]

Hi! Below are my comments, all about coding style.

On Monday 06 June 2016 12:19:29 Mario Limonciello wrote:
> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under _SB\AMAC in the DSDT at runtime.

For consistency it would be great to use same ACPI name in whole patch: 
\_SB.AMAC

> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 
> ---
> Changes from v3:
>  * Add additional comments about functions and what they're doing
>  * Adjust warning calls to use netif instead
>  * Rename function
> 
>  drivers/net/usb/r8152.c | 70 
> +++--
>  1 file changed, 68 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 3f9f6ed..b2339d3 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Information for net-next */
>  #define NETNEXT_VERSION  "08"
> @@ -455,6 +456,11 @@
>  /* SRAM_IMPEDANCE */
>  #define RX_DRIVING_MASK  0x6000
>  
> +/* MAC PASSTHRU */
> +#define AD_MASK  0xfee0
> +#define EFUSE0xcfdb
> +#define PASS_THRU_MASK   0x1
> +
>  enum rtl_register_content {
>   _1000bps= 0x10,
>   _100bps = 0x08,
> @@ -1030,6 +1036,59 @@ out1:
>   return ret;
>  }
>  
> +/* Devices containing RTL8153-AD can support a persistent
> + * host system provided MAC address.
> + * Examples of this are Dell TB15 and Dell WD15 docks
> + */
> +static int get_vendor_mac_passthru_addr(struct r8152 *tp, struct sockaddr 
> *sa)
> +{
> + acpi_status status;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *obj;
> + int ret = -EINVAL;
> + u32 ocp_data;
> + unsigned char buf[6];
> +
> + /* test for -AD variant of RTL8153 */
> + ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
> + if ((ocp_data & AD_MASK) != 0x1000)
> + return -ENODEV;
> +
> + /* test for MAC address pass-through bit */
> + ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
> + if ((ocp_data & PASS_THRU_MASK) != 1)
> + return -ENODEV;
> +
> + /* returns _AUXMAC_#AABBCCDDEEFF# */
> + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);

What about?

if (!ACPI_SUCCESS(status))
return -ENODEV;

You will save one level of indentation.

> + obj = (union acpi_object *)buffer.pointer;
> + if (ACPI_SUCCESS(status)) {
> + if (obj->type != ACPI_TYPE_BUFFER ||
> + obj->string.length != 0x17) {
> + netif_warn(tp, probe, tp->netdev, "Invalid buffer\n");

I would suggest more specific warning messages. These are very general
and if I would see them in dmesg log I would have no idea what that
means.

> + goto amacout;
> + }
> + if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0) {
> + netif_warn(tp, probe, tp->netdev, "Invalid header\n");
> + goto amacout;
> + }

If your specification state that last character is '#' then I think you
should check it too.

> + ret = hex2bin(buf, obj->string.pointer + 9, 6);
> + if (ret < 0 || !is_valid_ether_addr(buf)) {
> + netif_warn(tp, probe, tp->netdev, "Invalid MAC\n");
> + goto amacout;
> + }
> + memcpy(sa->sa_data, buf, 6);
> + ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
> + netif_info(tp, probe, tp->netdev,
> +"Using pass-through MAC addr %pM\n", sa->sa_data);
> + ret = 0;
> + }
> +
> +amacout:
> + kfree(obj);
> + return ret;
> +}
> +
>  static int set_ethernet_addr(struct r8152 *tp)
>  {
>   struct net_device *dev = tp->netdev;
> @@ -1038,8 +1097,15 @@ static int set_ethernet_addr(struct r8152 *tp)
>  
>   if (tp->version == RTL_VER_01)
>   ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
> - else
> - ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
> + else {
> + /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
> +  * or system doesn't provide valid _SB.AMAC this will be
> +  * be expected to non-zero
> +  */
> + ret = get_vendor_mac_passthru_addr(tp, &sa);

You do not "get" (return) any mac address. Personally I would use "read"
word

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

[Heiko Stübner]

Hi Frank,

Am Dienstag, 7. Juni 2016, 11:31:59 schrieb Frank Wang:
> On 2016/6/7 10:59, Frank Wang wrote:
> > On 2016/6/6 20:33, Heiko Stübner wrote:
> >> Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
> >>> On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
>  Signed-off-by: Frank Wang 
>  ---
>  
>  Changes in v3:
>    - Added 'clocks' and 'clock-names' optional properties.
>    - Specified 'otg-port' and 'host-port' as the sub-node name.
>  
>  Changes in v2:
>    - Changed vbus_host optional property from gpio to regulator.
>    - Specified vbus_otg-supply optional property.
>    - Specified otg_id and otg_bvalid property.
>    
>  .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
>    
>     1 file changed, 60 insertions(+)
>    create mode 100644
>  
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
>  diff --git
>  a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>  b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
>  file mode 100644
>  index 000..0b4
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>  @@ -0,0 +1,60 @@
>  +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
>  +
>  +Required properties (phy (parent) node):
>  + - compatible : should be one of the listed compatibles:
>  +* "rockchip,rk3366-usb2phy"
>  +* "rockchip,rk3399-usb2phy"
>  + - #clock-cells : should be 0.
>  + - clock-output-names : specify the 480m output clock name.
>  +
>  +Optional properties:
>  + - clocks : phandle + phy specifier pair, for the input clock of phy.
>  + - clock-names : input clock name of phy, must be "phyclk".
>  + - vbus_host-supply : phandle to a regulator that supplies host vbus.
>  + - vbus_otg-supply : phandle to a regulator that supplies otg vbus.
> >>> 
> >>> Nit: s/_/-/ here.
> >> 
> >> Something I only stumbled over yesterday for the first time on my
> >> rk3288-
> >> popmetal: The phy subnodes seem to be able to use a generic phy-supply
> >> property from inside the phy-core itself, see:
> >> 
> >> https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aa
> >> f6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597
> >> 
> >> 
> >> for my WIP code for that other board.
> > 
> > Ah, good comments! I will try later, if it is practicable, I shall
> > correct it into the next patches (patch v4).
> 
> I am sorry to tell you that seems unworkable, because we have two
> sub-nodes (phy-ports) in one parent-node (phy),
> what is more, the 'phy-supply' property can only put into parent-node, I
> believe it can not be differentiated types of ports.
> I mean vbus for host and otg are separately.

I would disagree ;-)

If you look in phy-core.c phy_create(), you can see that the struct phy that
gets created, contains its own struct device instance, which then gets the
phys of_node (the host+otg subnodes in this context) attached to it.

The regulator_get_optional then runs on this struct device, thus making lookup
on the subnode. And that works just nicely on my rk3288-popmetal, with its 3
phy subnodes and debugfs/regulator/regulator_summary prints that nicely:

 vcc_sys  0   12  0  5000mV 0mA  5000mV  5000mV 
vcc_host_5v   11  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.20mV 0mV
vcc_otg_5v11  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.00mV 0mV
vcc_sata_5v   21  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.10mV 0mV


Heiko

Re: [PATCH v2 3/3] tracing: make "string" the default type for [ku]probe event $comm

[Masami Hiramatsu]

On Thu,  2 Jun 2016 18:11:03 -0700
Omar Sandoval  wrote:

> From: Omar Sandoval 
> 
> You'd only ever want $comm as a string, but the default is still u64.
> Push the type parsing later so we can decide based on the actual
> fetcharg and make "string" the default for $comm.

Hmm, at this moment, I'd rather like a small hack in 
traceprobe_parse_probe_arg() as like below:

--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -522,6 +522,12 @@ int traceprobe_parse_probe_arg(char *arg, ssize_t *size,
arg[t - parg->comm] = '\0';
t++;
}
+   /*
+* The default type of "$comm" should be a string, and it must not
+* be dereferred
+*/
+   if (!t && strcmp("$comm", arg))
+   t = "string";
parg->type = find_fetch_type(t, ftbl);
if (!parg->type) {
pr_info("Unsupported type: %s\n", t);

This is not general, but easy to review :)

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH][RFC] x86, hotplug: Use zero page for monitor when resuming from hibernation

[Pavel Machek]

On Mon 2016-06-06 22:19:09, Chen Yu wrote:
> Stress test from Varun Koyyalagunta reports that, the
> nonboot CPU would hang occasionally, when resuming from
> hibernation. Further investigation shows that, the precise
> phase when nonboot CPU hangs, is the time when the nonboot
> CPU been woken up incorrectly, and tries to monitor the
> mwait_ptr for the second time, then an exception is
> triggered due to illegal vaddr access, say, something like,
> 'Unable to handler kernel address of 0x8800ba800010...'
> 
> One of the possible scenarios for this issue is illustrated below,
> when the boot CPU tries to resume from hibernation:
> 1. puts the nonboot CPUs offline, so the nonboot CPUs are monitoring
>at the address of the task_struct.flags.
> 2. boot CPU copies pages to their original address, which includes
>task_struct.flags, thus wakes up one of the nonboot CPUs.
> 3. nonboot CPU tries to monitor the task_struct.flags again, but since
>the page table for task_struct.flags has been overwritten by
>boot CPU, and there is probably a changed across hibernation
>(because of inconsistence of e820 memory map), an exception is
>triggered.

If memory map changes between suspend and resume, there'll be fun. If
that's suspected, should we attach md5 sum of e820 to the hibernation
image?

I doubt mwait fix is enough to catch everything in that case...

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

Re: [PATCH v12 01/15] PCI: Let pci_mmap_page_range() take extra resource pointer

[Jesper Nilsson]

On Fri, Jun 03, 2016 at 05:06:28PM -0700, Yinghai Lu wrote:
> This one is preparing patch for next one:
>   PCI: Let pci_mmap_page_range() take resource addr
> 
> We need to pass extra resource pointer to avoid searching that again
> for powerpc and microblaze prot set operation.
> 
> Signed-off-by: Yinghai Lu 
> Cc: linux-arm-ker...@lists.infradead.org

For the CRIS part:

Acked-by: Jesper Nilsson 

> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c 
> b/arch/cris/arch-v32/drivers/pci/bios.c
> index 64a5fb9..082efb9 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -14,7 +14,8 @@ void pcibios_set_master(struct pci_dev *dev)
>   pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
>  }
>  
> -int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> +int pci_mmap_page_range(struct pci_dev *dev, struct resource *res,
> + struct vm_area_struct *vma,
>   enum pci_mmap_state mmap_state, int write_combine)
>  {
>   unsigned long prot;
> diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
> index b1b289d..65198cb 100644
> --- a/arch/cris/include/asm/pci.h
> +++ b/arch/cris/include/asm/pci.h
> @@ -42,9 +42,6 @@ struct pci_dev;
>  #define PCI_DMA_BUS_IS_PHYS  (1)
>  
>  #define HAVE_PCI_MMAP
> -extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct 
> *vma,
> -enum pci_mmap_state mmap_state, int 
> write_combine);
> -
>  
>  #endif /* __KERNEL__ */

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

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

[Tomi Valkeinen]

On 07/06/16 09:49, Lothar Waßmann wrote:
> Hi,
> 
> On Mon, 6 Jun 2016 15:02:21 +0300 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 06/06/16 13:44, Lothar Waßmann wrote:
>>> 'brightness' is usually an index into a table of duty_cycle values,
>>> where the value at index 0 may well be non-zero
>>> (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life
>>> examples).
>>> Thus brightness == 0 does not necessarily mean that the PWM output
>>> will be inactive.
>>> Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide
>>> whether to disable the PWM.
>>
>> The binding doc does say:
>>
>>   - brightness-levels: Array of distinct brightness levels. Typically these
>>   are in the range from 0 to 255, but any range starting at 0 will do.
>>   The actual brightness level (PWM duty cycle) will be interpolated
>>   from these values. 0 means a 0% duty cycle (darkest/off), while the
>>   last value in the array represents a 100% duty cycle (brightest).
>>
> So, what should I do, when I need a range of levels that doesn't start
> at 0? E.g. if the brightness is inverse proportional to the PWM duty
> cycle.

That's a question to the PWM/backlight maintainers, but I think in the
addition of your patch, the binding doc needs to be changed, as it
doesn't hold true after your patch.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] mfd: max77620: Fix FPS switch statements

[Lee Jones]

On Thu, 12 May 2016, Rhyland Klein wrote:

> When configuring FPS during probe, assuming a DT node is present for
> FPS, the code can run into a problem with the switch statements in
> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely,
> in the case of chip->chip_id == MAX77620, it will set
> fps_[mix|max]_period but then fall through to the default switch case
> and return -EINVAL. Returning this from max77620_config_fps() will
> cause probe to fail.
> 
> Signed-off-by: Rhyland Klein 
> ---
>  drivers/mfd/max77620.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied to -fixes with Thierry and Laxman's Acks.

> diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
> index 199d261990be..f32fbb8e8129 100644
> --- a/drivers/mfd/max77620.c
> +++ b/drivers/mfd/max77620.c
> @@ -203,6 +203,7 @@ static int max77620_get_fps_period_reg_value(struct 
> max77620_chip *chip,
>   break;
>   case MAX77620:
>   fps_min_period = MAX77620_FPS_PERIOD_MIN_US;
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -236,6 +237,7 @@ static int max77620_config_fps(struct max77620_chip *chip,
>   break;
>   case MAX77620:
>   fps_max_period = MAX77620_FPS_PERIOD_MAX_US;
> + break;
>   default:
>   return -EINVAL;
>   }

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

[PATCH v4 07/14] of_numa: Use pr_fmt()

[Zhen Lei]

From: Kefeng Wang 

Use pr_fmt to prefix kernel output.

Signed-off-by: Kefeng Wang 
---
 drivers/of/of_numa.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index ed7bd22..019738f 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -16,6 +16,8 @@
  * along with this program.  If not, see .
  */

+#define pr_fmt(fmt) "OF: NUMA: " fmt
+
 #include 
 #include 
 #include 
@@ -49,10 +51,9 @@ static void __init of_numa_parse_cpu_nodes(void)
if (r)
continue;

-   pr_debug("NUMA: CPU on %u\n", nid);
+   pr_debug("CPU on %u\n", nid);
if (nid >= MAX_NUMNODES)
-   pr_warn("NUMA: Node id %u exceeds maximum value\n",
-   nid);
+   pr_warn("Node id %u exceeds maximum value\n", nid);
else
node_set(nid, numa_nodes_parsed);
}
@@ -80,7 +81,7 @@ static int __init of_numa_parse_memory_nodes(void)

if (!i || r) {
of_node_put(np);
-   pr_err("NUMA: bad property in memory node\n");
+   pr_err("bad property in memory node\n");
return r ? : -EINVAL;
}
}
@@ -94,17 +95,17 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
int entry_count;
int i;

-   pr_info("NUMA: parsing numa-distance-map-v1\n");
+   pr_info("parsing numa-distance-map-v1\n");

matrix = of_get_property(map, "distance-matrix", NULL);
if (!matrix) {
-   pr_err("NUMA: No distance-matrix property in distance-map\n");
+   pr_err("No distance-matrix property in distance-map\n");
return -EINVAL;
}

entry_count = of_property_count_u32_elems(map, "distance-matrix");
if (entry_count <= 0) {
-   pr_err("NUMA: Invalid distance-matrix\n");
+   pr_err("Invalid distance-matrix\n");
return -EINVAL;
}

@@ -119,7 +120,7 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
matrix++;

numa_set_distance(nodea, nodeb, distance);
-   pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
+   pr_debug("distance[node%d -> node%d] = %d\n",
 nodea, nodeb, distance);

/* Set default distance of node B->A same as A->B */
@@ -166,7 +167,7 @@ int of_node_to_nid(struct device_node *device)
np = of_get_next_parent(np);
}
if (np && r)
-   pr_warn("NUMA: Invalid \"numa-node-id\" property in node %s\n",
+   pr_warn("Invalid \"numa-node-id\" property in node %s\n",
np->name);
of_node_put(np);

--
2.5.0

[PATCH v4 13/14] of/numa: remove the constraint on the distances of node pairs

[Zhen Lei]

At present, the distances must equal in both direction for each node
pairs. For example: the distance of node B->A must the same to A->B.
But we really don't have to do this.

End up fill default distances as below:
1. If both direction specified, keep no change.
2. If only one direction specified, assign it to the other direction.
3. If none of the two direction specified, both are assigned to
   REMOTE_DISTANCE.

Signed-off-by: Zhen Lei 
---
 drivers/of/of_numa.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 019738f..ce782f9 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -122,15 +122,25 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
numa_set_distance(nodea, nodeb, distance);
pr_debug("distance[node%d -> node%d] = %d\n",
 nodea, nodeb, distance);
-
-   /* Set default distance of node B->A same as A->B */
-   if (nodeb > nodea)
-   numa_set_distance(nodeb, nodea, distance);
}

return 0;
 }

+static void __init fill_default_distances(void)
+{
+   int i, j;
+
+   for (i = 0; i < nr_node_ids; i++)
+   for (j = 0; j < nr_node_ids; j++)
+   if (i == j)
+   numa_set_distance(i, j, LOCAL_DISTANCE);
+   else if (!node_distance(i, j))
+   numa_set_distance(i, j,
+   node_distance(j, i) ? : REMOTE_DISTANCE);
+
+}
+
 static int __init of_numa_parse_distance_map(void)
 {
int ret = 0;
@@ -140,8 +150,10 @@ static int __init of_numa_parse_distance_map(void)
 "numa-distance-map-v1");
if (np)
ret = of_numa_parse_distance_map_v1(np);
-
of_node_put(np);
+
+   fill_default_distances();
+
return ret;
 }

--
2.5.0

Re: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features

[Arnd Bergmann]

On Monday, June 6, 2016 9:28:54 PM CEST Tony Lindgren wrote:
> * Nishanth Menon  [160601 15:51]:
> > On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> > >>
> > >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 
> > >> 8d9166b519fd
> > >> ("omap2/3/4: Add Kconfig option to compile in typical omap features")
> > >> that can be enabled for most boards keystone platforms
> > >> without needing to rediscover these in defconfig all over again -
> > >> examples include multi_v7_defconfig base and optimizations done on top
> > >> of them for keystone platform.
> > > 
> > > I'd rather remove the option for OMAP as well, it doesn't really fit in 
> > > with
> > > how we do things for other platforms, and selecting a lot of other Kconfig
> > > symbols tends to cause circular dependencies.
> > 
> > Hmm, fair enough -> adding Tony as well if he sees an problem with
> > dropping ARCH_OMAP2PLUS_TYPICAL.
> 
> Yes there's a problem. Removing that is going to make all the custom
> .config files unbootable almost certainly. Just search around on
> issues related to not having REGULATOR_FIXED_VOLTAGE selected.
> 
> I agree we should not force select things though. And the I2C selection
> at least is wrong, we can have PMICs that are not on I2C bus.
> 
> Anybody got better ideas what we should do to make the configuration
> options more intuitive?

Let's have a look at what we actually select:

config ARCH_OMAP2PLUS_TYPICAL
bool "Typical OMAP configuration"
default y
select AEABI
select HIGHMEM
select I2C
select I2C_OMAP
select MENELAUS if ARCH_OMAP2
select NEON if CPU_V7
select PM
select REGULATOR
select REGULATOR_FIXED_VOLTAGE
select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
select VFP
help
  Compile a kernel suitable for booting most boards

A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
PM, REGULATOR and VFP are things that we probably want to default to enabled
whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just
need to come up with a good way to do that while (probably for most of
them) still allowing them to be disabled with CONFIG_EXPERT. I would
feel more comfortable with having an ARCH_MULTIPLATFORM_TYPICAL
Kconfig symbol than with the ARCH_OMAP2PLUS_TYPICAL one that ends up
turning things on unconditionally whenever you add ARCH_OMAP2PLUS
to some other configuration.

For I2C_OMAP, MENELAUS and TWL4030, we could just add a
'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for
each of them. I assume we want to handle TWL6040 the same way, though
we currently don't do that. MENELAUS seems to be only needed for
omap2420-n8x0.

REGULATOR_FIXED_VOLTAGE is needed by a lot of platforms that usually
don't select it, so it might be good to add a 'default y' to its Kconfig
symbol, or we could add 'select REGULATOR_FIXED_VOLTAGE if REGULATOR'
to all platforms that need it. The driver is about 1.5KB in size, compared
to about 50KB for the regulator core.

HIGHMEM is a bit odd here, because there are a couple of boards that
really really want it to access all of their memory, while most other
boards (anything with <=768MB RAM) are better off not enabling it,
so I can't see a good strategy for when to enable it or not across
multiplatform builds. If we wanted to apply crude heuristics, we could
make it default-enabled for SMP configurations, and default-disabled
for UP, or we could default-enable it for ARMv7VE (Cortex-A7/A15/A17,
Krait-400, PJ4B-MP) and default-disable for ARMv7 (Cortex-A5/A8/A9,
Scorpion, Krait, PJ4, PJ4B) and older. This would get us the right
setting in most cases, but it would also be rather confusing as it gets
flipped based on options that it doesn't really have anything to
do with in the strict sense.

Arnd

Re: [PATCH v4 2/5] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group

[Vincent Guittot]

On 6 June 2016 at 21:05, Yuyang Du  wrote:
> Hi Vincent,
>
> On Mon, Jun 06, 2016 at 02:32:39PM +0200, Vincent Guittot wrote:
>> > Unlike the switch to fair class case, if the task is on_rq, it will be
>> > enqueued after we move task groups, so the simplest solution is to reset
>> > the task's last_update_time when we do task_move_group(), but not to
>> > attach sched avgs in task_move_group(), and then let enqueue_task() do
>> > the sched avgs attachment.
>>
>> According to the review of the previous version
>> http://www.gossamer-threads.com/lists/linux/kernel/2450678#2450678,
>> only the use case switch to fair with a task that has never been
>> queued as a CFS task before, can have the issue and this will not
>> happen for other use cases described above.
>> So can you limit the description in the commit message to just this
>> use case unless you have discovered new use cases and in this case
>> please add the description.
>
> I assure you that I will, :)
>
>> Then, the problem with this use case, comes that last_update_time == 0
>> has a special meaning ( task has migrated ) and we initialize
>> last_update_time with this value.
>
> In general, the meaning of last_update_time == 0 is: not yet attached to
> any cfs queue.
>
>> A much more simple solution would be
>> to prevent last_update_time to be initialized with this special value.
>> We can initialize the last_update_time of a sched_entity to 1 as an
>> example which is easier than these changes.
>
> Then at least, we must differentiate CONFIG_FAIR_GROUP_SCHED and
> !CONFIG_FAIR_GROUP_SCHED. And I am not sure whether this is a simpler

Why do you want to differentiate ? we already have
sa->last_update_time = 0; in init_entity_runnable_average. We just
have to change it by sa->last_update_time = 1;

> solution, as I haven't sorted out the whole thing. IMO, this solution
> seems a little too hacky and I'd prefer not if we have alternative.

[PATCH v4 14/14] Documentation: remove the constraint on the distances of node pairs

[Zhen Lei]

Update documentation. This limit is unneccessary.

Signed-off-by: Zhen Lei 
---
 Documentation/devicetree/bindings/numa.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/numa.txt 
b/Documentation/devicetree/bindings/numa.txt
index 21b3505..c0ea4a7 100644
--- a/Documentation/devicetree/bindings/numa.txt
+++ b/Documentation/devicetree/bindings/numa.txt
@@ -48,7 +48,6 @@ distance (memory latency) between all numa nodes.

   Note:
1. Each entry represents distance from first node to second node.
-   The distances are equal in either direction.
2. The distance from a node to self (local distance) is represented
with value 10 and all internode distance should be represented with
a value greater than 10.
--
2.5.0

Re: [PATCH net-next 2/3] arm64: bpf: optimize JMP_CALL

[Will Deacon]

On Mon, Jun 06, 2016 at 09:36:03PM -0700, Z Lim wrote:
> On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon  wrote:
> > On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
> >> Remove superfluous stack frame, saving us 3 instructions for
> >> every JMP_CALL.
> >>
> >> Signed-off-by: Zi Shen Lim 
> >> ---
> >>  arch/arm64/net/bpf_jit_comp.c | 3 ---
> >>  1 file changed, 3 deletions(-)
> >>
> >> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> >> index 51abc97..7ae304e 100644
> >> --- a/arch/arm64/net/bpf_jit_comp.c
> >> +++ b/arch/arm64/net/bpf_jit_comp.c
> >> @@ -578,11 +578,8 @@ emit_cond_jmp:
> >>   const u64 func = (u64)__bpf_call_base + imm;
> >>
> >>   emit_a64_mov_i64(tmp, func, ctx);
> >> - emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
> >> - emit(A64_MOV(1, A64_FP, A64_SP), ctx);
> >>   emit(A64_BLR(tmp), ctx);
> >>   emit(A64_MOV(1, r0, A64_R(0)), ctx);
> >> - emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
> >>   break;
> >>   }
> >
> > Is the jitted code intended to be unwindable by standard tools?
> 
> Before this patch:
> bpf_prologue => push stack frame
> ...
> jmp_call => push stack frame, call bpf_helper*, pop stack frame
> ...
> bpf_epilogue => pop stack frame, ret
> 
> Now:
> bpf_prologue => push stack frame
> ...
> jmp_call => call bpf_helper*
> ...
> bpf_epilogue => pop stack frame, ret
> 
> *Note: bpf_helpers in kernel/bpf/helper.c
> 
> So yes, it's still unwindable.

Sure, I'm not disputing that. I just wondered whether or not it needs to
be unwindable at all...

Will

Re: [PATCH 01/10] nvme.h: add RTD3R, RTD3E and OAES fields

[Johannes Thumshirn]

On Mon, Jun 06, 2016 at 11:20:43PM +0200, Christoph Hellwig wrote:
> These have been added in NVMe 1.2 and we'll need at least oaes for the
> NVMe target driver.
> 
> Reviewed-by: Sagi Grimberg 
> Reviewed-by: Jay Freyensee 
> Signed-off-by: Christoph Hellwig 
> ---
>  include/linux/nvme.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
> index 7d51b29..ff5ebc3 100644
> --- a/include/linux/nvme.h
> +++ b/include/linux/nvme.h
> @@ -107,7 +107,10 @@ struct nvme_id_ctrl {
>   __u8mdts;
>   __le16  cntlid;
>   __le32  ver;
> - __u8rsvd84[172];
> + __le32  rtd3r;
> + __le32  rtd3e;
> + __le32  oaes;

Just out of curiosity, why not CTRATT as well?

> + __u8rsvd96[160];
>   __le16  oacs;
>   __u8acl;
>   __u8aerl;
> -- 
> 2.1.4
> 
> 
> ___
> Linux-nvme mailing list
> linux-n...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

[Zhen Lei]

v3 -> v4:
1. Packed three patches of Kefeng Wang, patch6-8.
2. Add 6 new patches(9-15) to enhance the numa on arm64.

v2 -> v3:
1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make the
   patches looks more well. The final code have no change. 

v1 -> v2:
1. Base on https://lkml.org/lkml/2016/5/24/679
2. Rewrote of_numa_parse_memory_nodes according to Rob Herring's advice. So 
that it looks more clear.
3. Rewrote patch 5 because some scenes were not considered before.

Kefeng Wang (3):
  of_numa: Use of_get_next_parent to simplify code
  of_numa: Use pr_fmt()
  arm64: numa: Use pr_fmt()

Zhen Lei (11):
  of/numa: remove a duplicated pr_debug information
  of/numa: fix a memory@ node can only contains one memory block
  arm64/numa: add nid check for memory block
  of/numa: remove a duplicated warning
  arm64/numa: avoid inconsistent information to be printed
  arm64/numa: support HAVE_SETUP_PER_CPU_AREA
  arm64/numa: define numa_distance as array to simplify code
  arm64/numa: support HAVE_MEMORYLESS_NODES
  arm64/numa: remove some useless code
  of/numa: remove the constraint on the distances of node pairs
  Documentation: remove the constraint on the distances of node pairs

 Documentation/devicetree/bindings/numa.txt |   1 -
 arch/arm64/Kconfig |  12 ++
 arch/arm64/include/asm/numa.h  |   1 -
 arch/arm64/kernel/smp.c|   1 +
 arch/arm64/mm/numa.c   | 228 -
 drivers/of/of_numa.c   |  87 +--
 6 files changed, 180 insertions(+), 150 deletions(-)

--
2.5.0

[PATCH v4 12/14] arm64/numa: remove some useless code

[Zhen Lei]

1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not
   been initialized.
2. No reason to limit cpu0 must belongs to node0.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/numa.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index d73b0a0..92b1692 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -93,7 +93,6 @@ void numa_clear_node(unsigned int cpu)
  */
 static void __init setup_node_to_cpumask_map(void)
 {
-   unsigned int cpu;
int node;

/* setup nr_node_ids if not done yet */
@@ -106,9 +105,6 @@ static void __init setup_node_to_cpumask_map(void)
cpumask_clear(node_to_cpumask_map[node]);
}

-   for_each_possible_cpu(cpu)
-   set_cpu_numa_node(cpu, NUMA_NO_NODE);
-
/* cpumask_of_node() will now work */
pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
 }
@@ -379,10 +375,6 @@ static int __init numa_init(int (*init_func)(void))

setup_node_to_cpumask_map();

-   /* init boot processor */
-   cpu_to_node_map[0] = 0;
-   map_cpu_to_node(0, 0);
-
return 0;
 }

--
2.5.0

[PATCH v4 04/14] of/numa: remove a duplicated warning

[Zhen Lei]

This warning has been printed in of_numa_parse_cpu_nodes before.

Signed-off-by: Zhen Lei 
---
 drivers/of/of_numa.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 7b3fbdc..3157130 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -174,13 +174,8 @@ int of_node_to_nid(struct device_node *device)
np->name);
of_node_put(np);

-   if (!r) {
-   if (nid >= MAX_NUMNODES)
-   pr_warn("NUMA: Node id %u exceeds maximum value\n",
-   nid);
-   else
-   return nid;
-   }
+   if (!r)
+   return nid;

return NUMA_NO_NODE;
 }
--
2.5.0

[PATCH v4 01/14] of/numa: remove a duplicated pr_debug information

[Zhen Lei]

This information will be printed in the subfunction numa_add_memblk.
They are not the same, but very similar.

Signed-off-by: Zhen Lei 
---
 drivers/of/of_numa.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index ed5a097..fb71b4e 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -88,10 +88,6 @@ static int __init of_numa_parse_memory_nodes(void)
break;
}

-   pr_debug("NUMA:  base = %llx len = %llx, node = %u\n",
-rsrc.start, rsrc.end - rsrc.start + 1, nid);
-
-
r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
if (r)
break;
--
2.5.0

[PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

[Zhen Lei]

Some numa nodes may have no memory. For example:
1. cpu0 on node0
2. cpu1 on node1
3. device0 access the momory from node0 and node1 take the same time.

So, we can not simply classify device0 to node0 or node1, but we can
define a node2 which distances to node0 and node1 are the same.

Signed-off-by: Zhen Lei 
---
 arch/arm64/Kconfig  |  4 
 arch/arm64/kernel/smp.c |  1 +
 arch/arm64/mm/numa.c| 43 +--
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 05c1bf1..5904a62 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -581,6 +581,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y
depends on NUMA

+config HAVE_MEMORYLESS_NODES
+   def_bool y
+   depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d099306..9e15297 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -620,6 +620,7 @@ static void __init of_parse_and_init_cpus(void)
}

bootcpu_valid = true;
+   early_map_cpu_to_node(0, of_node_to_nid(dn));

/*
 * cpu_logical_map has already been
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index df5c842..d73b0a0 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -128,6 +128,14 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
nid)
nid = 0;

cpu_to_node_map[cpu] = nid;
+
+   /*
+* We should set the numa node of cpu0 as soon as possible, because it
+* has already been set up online before. cpu_to_node(0) will soon be
+* called.
+*/
+   if (!cpu)
+   set_cpu_numa_node(cpu, nid);
 }

 #ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
@@ -215,6 +223,35 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
return ret;
 }

+static u64 __init alloc_node_data_from_nearest_node(int nid, const size_t size)
+{
+   int i, best_nid, distance;
+   u64 pa;
+   DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
+
+   bitmap_zero(nodes_map, MAX_NUMNODES);
+   bitmap_set(nodes_map, nid, 1);
+
+find_nearest_node:
+   best_nid = NUMA_NO_NODE;
+   distance = INT_MAX;
+
+   for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
+   if (numa_distance[nid][i] < distance) {
+   best_nid = i;
+   distance = numa_distance[nid][i];
+   }
+
+   pa = memblock_alloc_nid(size, SMP_CACHE_BYTES, best_nid);
+   if (!pa) {
+   BUG_ON(best_nid == NUMA_NO_NODE);
+   bitmap_set(nodes_map, best_nid, 1);
+   goto find_nearest_node;
+   }
+
+   return pa;
+}
+
 /**
  * Initialize NODE_DATA for a node on the local memory
  */
@@ -228,7 +265,9 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);

-   nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+   nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
+   if (!nd_pa)
+   nd_pa = alloc_node_data_from_nearest_node(nid, nd_size);
nd = __va(nd_pa);

/* report and initialize */
@@ -238,7 +277,7 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
if (tnid != nid)
pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);

-   node_data[nid] = nd;
+   NODE_DATA(nid) = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
NODE_DATA(nid)->node_id = nid;
NODE_DATA(nid)->node_start_pfn = start_pfn;
--
2.5.0

Re: [STLinux Kernel] [[PATCH v2] 07/11] pwm: sti: Supply PWM Capture clock handling

[Peter Griffin]

Hi Lee,

On Fri, 22 Apr 2016, Lee Jones wrote:

> ST's PWM IP is supplied by 2 different clocks.  One for PWM
> Output and the other for Capture.  This patch provides clock
> handling for the latter.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/pwm/pwm-sti.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
> index 2f61e1e..78979d0 100644
> --- a/drivers/pwm/pwm-sti.c
> +++ b/drivers/pwm/pwm-sti.c
> @@ -74,6 +74,7 @@ struct sti_pwm_compat_data {
>  struct sti_pwm_chip {
>   struct device *dev;
>   struct clk *pwm_clk;
> + struct clk *cpt_clk;
>   struct regmap *regmap;
>   struct sti_pwm_compat_data *cdata;
>   struct regmap_field *prescale_low;
> @@ -183,6 +184,10 @@ static int sti_pwm_config(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   if (ret)
>   return ret;
>  
> + ret = clk_enable(pc->cpt_clk);
> + if (ret)
> + return ret;
> +
>   if (!period_same) {
>   ret = sti_pwm_get_prescale(pc, period_ns, &prescale);
>   if (ret)
> @@ -227,6 +232,7 @@ static int sti_pwm_config(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>  
>  clk_dis:
>   clk_disable(pc->pwm_clk);
> + clk_disable(pc->cpt_clk);
>   return ret;
>  }
>  
> @@ -246,6 +252,10 @@ static int sti_pwm_enable(struct pwm_chip *chip, struct 
> pwm_device *pwm)
>   if (ret)
>   goto out;
>  
> + ret = clk_enable(pc->cpt_clk);
> + if (ret)
> + goto out;
> +
>   ret = regmap_field_write(pc->pwm_out_en, 1);
>   if (ret) {
>   dev_err(dev, "failed to enable PWM device:%d\n",
> @@ -271,6 +281,7 @@ static void sti_pwm_disable(struct pwm_chip *chip, struct 
> pwm_device *pwm)
>   regmap_field_write(pc->pwm_out_en, 0);
>  
>   clk_disable(pc->pwm_clk);
> + clk_disable(pc->cpt_clk);
>   mutex_unlock(&pc->sti_pwm_lock);
>  }
>  
> @@ -390,6 +401,18 @@ static int sti_pwm_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + pc->cpt_clk = of_clk_get_by_name(dev->of_node, "capture");
> + if (IS_ERR(pc->cpt_clk)) {
> + dev_err(dev, "failed to get PWM capture clock\n");
> + return PTR_ERR(pc->cpt_clk);
> + }

The dt binding document pwm-st.txt also needs updating for this extra clock.

regards,

Peter.

Re: [PATCH 1/3] pci: introduce read_bridge/write_bridge pci ops

[Arnd Bergmann]

On Monday, June 6, 2016 7:28:22 PM CEST Bjorn Helgaas wrote:
> The caller is performing one abstract operation: reading or writing
> config space of a PCI device.  In the caller's context, it makes no
> difference whether it's a type0 or type1 access.
> 
> Moving the test from the host bridge driver to pci_read_config_byte()
> does move a little code from the callee to the caller, and there are
> more callees than callers, so in that sense it does remove code
> overall.  If you consider a single driver by itself, I'm not sure it
> makes much difference.
> 
> The pcie-designware.c patch is a net removal of 17 lines, but that's
> not all from moving the type0/type1 test: restructuring along the same
> lines but keeping the original type0/type1 test removes about 9 lines.
> 
> Anyway, I think I'd rather work first on your RFC patches to make
> pci_host_bridge the primary structure for probing PCI.  I think
> there will be a *lot* of benefit there.

Fair enough. This series started from the review of the Rockchip
driver, and the idea was to make that one simpler, but given that
we already have several dozen drivers doing the same thing, adding
one more isn't going to have a significant impact now.

Arnd

[PATCH v4 08/14] arm64: numa: Use pr_fmt()

[Zhen Lei]

From: Kefeng Wang 

Use pr_fmt to prefix kernel output, and remove duplicated msg
of NUMA turned off.

Signed-off-by: Kefeng Wang 
---
 arch/arm64/mm/numa.c | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 1b9622c..8be5ba3 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,8 @@
  * along with this program.  If not, see .
  */

+#define pr_fmt(fmt) "numa: " fmt
+
 #include 
 #include 
 #include 
@@ -36,10 +38,9 @@ static __init int numa_parse_early_param(char *opt)
 {
if (!opt)
return -EINVAL;
-   if (!strncmp(opt, "off", 3)) {
-   pr_info("%s\n", "NUMA turned off");
+   if (!strncmp(opt, "off", 3))
numa_off = true;
-   }
+
return 0;
 }
 early_param("numa", numa_parse_early_param);
@@ -108,7 +109,7 @@ static void __init setup_node_to_cpumask_map(void)
set_cpu_numa_node(cpu, NUMA_NO_NODE);

/* cpumask_of_node() will now work */
-   pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
+   pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
 }

 /*
@@ -142,19 +143,19 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
int ret;

if (nid >= MAX_NUMNODES) {
-   pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
+   pr_warn("Node id %u exceeds maximum value\n", nid);
return -EINVAL;
}

ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
-   pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
%d\n",
+   pr_err("memblock [0x%llx - 0x%llx] failed to add on node %d\n",
start, (end - 1), nid);
return ret;
}

node_set(nid, numa_nodes_parsed);
-   pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
+   pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
start, (end - 1), nid);
return ret;
 }
@@ -169,19 +170,18 @@ static void __init setup_node_data(int nid, u64 
start_pfn, u64 end_pfn)
void *nd;
int tnid;

-   pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
-   nid, start_pfn << PAGE_SHIFT,
-   (end_pfn << PAGE_SHIFT) - 1);
+   pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
+   nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);

nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
nd = __va(nd_pa);

/* report and initialize */
-   pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
+   pr_info("  NODE_DATA [mem %#010Lx-%#010Lx]\n",
nd_pa, nd_pa + nd_size - 1);
tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
if (tnid != nid)
-   pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
+   pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);

node_data[nid] = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
@@ -238,8 +238,7 @@ static int __init numa_alloc_distance(void)
numa_distance[i * numa_distance_cnt + j] = i == j ?
LOCAL_DISTANCE : REMOTE_DISTANCE;

-   pr_debug("NUMA: Initialized distance table, cnt=%d\n",
-   numa_distance_cnt);
+   pr_debug("Initialized distance table, cnt=%d\n", numa_distance_cnt);

return 0;
 }
@@ -260,20 +259,20 @@ static int __init numa_alloc_distance(void)
 void __init numa_set_distance(int from, int to, int distance)
 {
if (!numa_distance) {
-   pr_warn_once("NUMA: Warning: distance table not allocated 
yet\n");
+   pr_warn_once("Warning: distance table not allocated yet\n");
return;
}

if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
from < 0 || to < 0) {
-   pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d 
to=%d distance=%d\n",
+   pr_warn_once("Warning: node ids are out of bound, from=%d to=%d 
distance=%d\n",
from, to, distance);
return;
}

if ((u8)distance != distance ||
(from == to && distance != LOCAL_DISTANCE)) {
-   pr_warn_once("NUMA: Warning: invalid distance parameter, 
from=%d to=%d distance=%d\n",
+   pr_warn_once("Warning: invalid distance parameter, from=%d 
to=%d distance=%d\n",
 from, to, distance);
return;
}
@@ -300,7 +299,7 @@ static int __init numa_register_nodes(void)
/* Check that valid nid is set to memblks */
for_each_memblock(memory, mblk)
if (mblk->nid == NUMA_NO_NODE || mblk->nid >= M

[PATCH v4 03/14] arm64/numa: add nid check for memory block

[Zhen Lei]

Use the same tactic to cpu and numa-distance nodes.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/numa.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index c7fe3ec..2601660 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -141,6 +141,11 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 {
int ret;

+   if (nid >= MAX_NUMNODES) {
+   pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
+   return -EINVAL;
+   }
+
ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
%d\n",
--
2.5.0

[PATCH v4 02/14] of/numa: fix a memory@ node can only contains one memory block

[Zhen Lei]

For a normal memory@ devicetree node, its reg property can contains more
memory blocks.

Because we don't known how many memory blocks maybe contained, so we try
from index=0, increase 1 until error returned(the end).

Signed-off-by: Zhen Lei 
---
 drivers/of/of_numa.c | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index fb71b4e..7b3fbdc 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -63,13 +63,9 @@ static int __init of_numa_parse_memory_nodes(void)
struct device_node *np = NULL;
struct resource rsrc;
u32 nid;
-   int r = 0;
-
-   for (;;) {
-   np = of_find_node_by_type(np, "memory");
-   if (!np)
-   break;
+   int i, r;

+   for_each_node_by_type(np, "memory") {
r = of_property_read_u32(np, "numa-node-id", &nid);
if (r == -EINVAL)
/*
@@ -78,23 +74,18 @@ static int __init of_numa_parse_memory_nodes(void)
 * "numa-node-id" property
 */
continue;
-   else if (r)
-   /* some other error */
-   break;

-   r = of_address_to_resource(np, 0, &rsrc);
-   if (r) {
-   pr_err("NUMA: bad reg property in memory node\n");
-   break;
-   }
+   for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++)
+   r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);

-   r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
-   if (r)
-   break;
+   if (!i || r) {
+   of_node_put(np);
+   pr_err("NUMA: bad property in memory node\n");
+   return r ? : -EINVAL;
+   }
}
-   of_node_put(np);

-   return r;
+   return 0;
 }

 static int __init of_numa_parse_distance_map_v1(struct device_node *map)
--
2.5.0

[PATCH v4 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA

[Zhen Lei]

To make each percpu area allocated from its local numa node. Without this
patch, all percpu areas will be allocated from the node which cpu0 belongs
to.

Signed-off-by: Zhen Lei 
---
 arch/arm64/Kconfig   |  8 
 arch/arm64/mm/numa.c | 56 
 2 files changed, 64 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 76747d9..05c1bf1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -573,6 +573,14 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA

+config HAVE_SETUP_PER_CPU_AREA
+   def_bool y
+   depends on NUMA
+
+config NEED_PER_CPU_EMBED_FIRST_CHUNK
+   def_bool y
+   depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 8be5ba3..99401aa 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -25,6 +25,8 @@
 #include 
 #include 

+#include 
+
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
 EXPORT_SYMBOL(node_data);
 nodemask_t numa_nodes_parsed __initdata;
@@ -129,6 +131,60 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
nid)
cpu_to_node_map[cpu] = nid;
 }

+#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
+unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
+EXPORT_SYMBOL(__per_cpu_offset);
+
+static int __init early_cpu_to_node(int cpu)
+{
+   return cpu_to_node_map[cpu];
+}
+
+static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
+{
+   if (early_cpu_to_node(from) == early_cpu_to_node(to))
+   return LOCAL_DISTANCE;
+   else
+   return REMOTE_DISTANCE;
+}
+
+static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size,
+  size_t align)
+{
+   int nid = early_cpu_to_node(cpu);
+
+   return  memblock_virt_alloc_try_nid(size, align,
+   __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+}
+
+static void __init pcpu_fc_free(void *ptr, size_t size)
+{
+   memblock_free_early(__pa(ptr), size);
+}
+
+void __init setup_per_cpu_areas(void)
+{
+   unsigned long delta;
+   unsigned int cpu;
+   int rc;
+
+   /*
+* Always reserve area for module percpu variables.  That's
+* what the legacy allocator did.
+*/
+   rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
+   PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
+   pcpu_cpu_distance,
+   pcpu_fc_alloc, pcpu_fc_free);
+   if (rc < 0)
+   panic("Failed to initialize percpu areas.");
+
+   delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
+   for_each_possible_cpu(cpu)
+   __per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
+}
+#endif
+
 /**
  * numa_add_memblk - Set node id to memblk
  * @nid: NUMA node ID of the new memblk
--
2.5.0

Re: [STLinux Kernel] [[PATCH v2] 09/11] pwm: sti: Add support for PWM Capture IRQs

[Peter Griffin]

Hi Lee,

On Fri, 22 Apr 2016, Lee Jones wrote:

> Here we're requesting the PWM Capture IRQ and supplying the
> handler which will be called in the event of an IRQ fire to
> handle it.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/pwm/pwm-sti.c | 92 
> ++-
>  1 file changed, 91 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
> index 9d597bb..2230afb 100644
> --- a/drivers/pwm/pwm-sti.c
> +++ b/drivers/pwm/pwm-sti.c
> @@ -91,7 +91,9 @@ struct sti_pwm_chip {
>   struct regmap_field *prescale_low;
>   struct regmap_field *prescale_high;
>   struct regmap_field *pwm_out_en;
> + struct regmap_field *pwm_cpt_en;
>   struct regmap_field *pwm_cpt_int_en;
> + struct regmap_field *pwm_cpt_int_stat;
>   struct pwm_chip chip;
>   struct pwm_device *cur;
>   unsigned long configured;
> @@ -311,6 +313,76 @@ static const struct pwm_ops sti_pwm_ops = {
>   .owner = THIS_MODULE,
>  };
>  
> +static irqreturn_t sti_pwm_interrupt(int irq, void *data)
> +{
> + struct sti_pwm_chip *pc = data;
> + struct device *dev = pc->dev;
> + struct sti_cpt_ddata *ddata;
> + int devicenum;
> + unsigned int cpt_int_stat;
> + unsigned int reg;
> + int ret = IRQ_NONE;
> +
> + ret = regmap_field_read(pc->pwm_cpt_int_stat, &cpt_int_stat);
> + if (ret)
> + return ret;
> +
> + while (cpt_int_stat) {
> + devicenum = ffs(cpt_int_stat) - 1;
> +
> + ddata = pwm_get_chip_data(&pc->chip.pwms[devicenum]);
> +
> + /*
> +  * Capture input:
> +  *___   ___
> +  *   |   | |   |
> +  * __|   |_|   |
> +  *   ^0  ^1^2
> +  *
> +  * Capture start by the first available rising edge
> +  * When a capture event occurs, capture value (CPT_VALx)
> +  * is stored, index incremented, capture edge changed.
> +  *
> +  * After the capture, if the index > 1, we have collected
> +  * the necessary data so we signal the thread waiting for it
> +  * and disable the capture by setting capture edge to none
> +  *
> +  */
> +
> + regmap_read(pc->regmap,
> + PWM_CPT_VAL(devicenum),
> + &ddata->snapshot[ddata->index]);
> +
> + switch (ddata->index) {
> + case 0:
> + case 1:
> + regmap_read(pc->regmap, PWM_CPT_EDGE(devicenum), ®);
> + reg ^= PWM_CPT_EDGE_MASK;
> + regmap_write(pc->regmap, PWM_CPT_EDGE(devicenum), reg);
> +
> + ddata->index++;
> + break;
> + case 2:
> + regmap_write(pc->regmap,
> +  PWM_CPT_EDGE(devicenum),
> +  CPT_EDGE_DISABLED);
> + wake_up(&ddata->wait);
> + break;
> + default:
> + dev_err(dev, "Internal error\n");
> + }
> +
> + cpt_int_stat &= ~BIT_MASK(devicenum);
> +
> + ret = IRQ_HANDLED;
> + }
> +
> + /* Just ACK everything */
> + regmap_write(pc->regmap, PWM_INT_ACK, PWM_INT_ACK_MASK);
> +
> + return ret;
> +}
> +
>  static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
>  {
>   struct device *dev = pc->dev;
> @@ -351,6 +423,11 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
>   if (IS_ERR(pc->pwm_cpt_int_en))
>   return PTR_ERR(pc->pwm_cpt_int_en);
>  
> + pc->pwm_cpt_int_stat = devm_regmap_field_alloc(dev, pc->regmap,
> + reg_fields[PWM_CPT_INT_STAT]);
> + if (PTR_ERR_OR_ZERO(pc->pwm_cpt_int_stat))
> + return PTR_ERR(pc->pwm_cpt_int_stat);
> +
>   return 0;
>  }
>  
> @@ -367,7 +444,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
>   struct sti_pwm_chip *pc;
>   struct resource *res;
>   unsigned int devnum;
> - int ret;
> + int irq, ret;
>  
>   pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
>   if (!pc)
> @@ -388,6 +465,19 @@ static int sti_pwm_probe(struct platform_device *pdev)
>   if (IS_ERR(pc->regmap))
>   return PTR_ERR(pc->regmap);
>  
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(&pdev->dev, "Failed to obtain IRQ\n");
> + return irq;
> + }
> +
> + ret = devm_request_irq(&pdev->dev, irq, sti_pwm_interrupt,
> +0, pdev->name, pc);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to request IRQ\n");
> + return ret;
> + }
> +
>   /*
>* Setup PWM data with de

[PATCH v4 05/14] arm64/numa: avoid inconsistent information to be printed

[Zhen Lei]

numa_init(of_numa_init) may returned error because of numa configuration
error. So "No NUMA configuration found" is inaccurate. In fact, specific
configuration error information should be immediately printed by the
testing branch.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/numa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 2601660..1b9622c 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -338,8 +338,10 @@ static int __init numa_init(int (*init_func)(void))
if (ret < 0)
return ret;

-   if (nodes_empty(numa_nodes_parsed))
+   if (nodes_empty(numa_nodes_parsed)) {
+   pr_info("No NUMA configuration found\n");
return -EINVAL;
+   }

ret = numa_register_nodes();
if (ret < 0)
@@ -370,8 +372,6 @@ static int __init dummy_numa_init(void)

if (numa_off)
pr_info("NUMA disabled\n"); /* Forced off on command line. */
-   else
-   pr_info("No NUMA configuration found\n");
pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
   0LLU, PFN_PHYS(max_pfn) - 1);

--
2.5.0

[PATCH v4 10/14] arm64/numa: define numa_distance as array to simplify code

[Zhen Lei]

1. MAX_NUMNODES is base on CONFIG_NODES_SHIFT, the default value of the
   latter is very small now.
2. Suppose the default value of MAX_NUMNODES is enlarged to 64, so the
   size of numa_distance is 4K, it's still acceptable if run the Image
   on other processors.
3. It will make function __node_distance quicker than before.

Signed-off-by: Zhen Lei 
---
 arch/arm64/include/asm/numa.h |  1 -
 arch/arm64/mm/numa.c  | 74 +++
 2 files changed, 5 insertions(+), 70 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..9b6cc38 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -32,7 +32,6 @@ static inline const struct cpumask *cpumask_of_node(int node)
 void __init arm64_numa_init(void);
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 void __init numa_set_distance(int from, int to, int distance);
-void __init numa_free_distance(void);
 void __init early_map_cpu_to_node(unsigned int cpu, int nid);
 void numa_store_cpu_info(unsigned int cpu);

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 99401aa..df5c842 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -32,8 +32,7 @@ EXPORT_SYMBOL(node_data);
 nodemask_t numa_nodes_parsed __initdata;
 static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };

-static int numa_distance_cnt;
-static u8 *numa_distance;
+static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];
 static bool numa_off;

 static __init int numa_parse_early_param(char *opt)
@@ -247,59 +246,6 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
 }

 /**
- * numa_free_distance
- *
- * The current table is freed.
- */
-void __init numa_free_distance(void)
-{
-   size_t size;
-
-   if (!numa_distance)
-   return;
-
-   size = numa_distance_cnt * numa_distance_cnt *
-   sizeof(numa_distance[0]);
-
-   memblock_free(__pa(numa_distance), size);
-   numa_distance_cnt = 0;
-   numa_distance = NULL;
-}
-
-/**
- *
- * Create a new NUMA distance table.
- *
- */
-static int __init numa_alloc_distance(void)
-{
-   size_t size;
-   u64 phys;
-   int i, j;
-
-   size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
-   phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
- size, PAGE_SIZE);
-   if (WARN_ON(!phys))
-   return -ENOMEM;
-
-   memblock_reserve(phys, size);
-
-   numa_distance = __va(phys);
-   numa_distance_cnt = nr_node_ids;
-
-   /* fill with the default distances */
-   for (i = 0; i < numa_distance_cnt; i++)
-   for (j = 0; j < numa_distance_cnt; j++)
-   numa_distance[i * numa_distance_cnt + j] = i == j ?
-   LOCAL_DISTANCE : REMOTE_DISTANCE;
-
-   pr_debug("Initialized distance table, cnt=%d\n", numa_distance_cnt);
-
-   return 0;
-}
-
-/**
  * numa_set_distance - Set inter node NUMA distance from node to node.
  * @from: the 'from' node to set distance
  * @to: the 'to'  node to set distance
@@ -314,12 +260,7 @@ static int __init numa_alloc_distance(void)
  */
 void __init numa_set_distance(int from, int to, int distance)
 {
-   if (!numa_distance) {
-   pr_warn_once("Warning: distance table not allocated yet\n");
-   return;
-   }
-
-   if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
+   if (from >= MAX_NUMNODES || to >= MAX_NUMNODES ||
from < 0 || to < 0) {
pr_warn_once("Warning: node ids are out of bound, from=%d to=%d 
distance=%d\n",
from, to, distance);
@@ -333,7 +274,7 @@ void __init numa_set_distance(int from, int to, int 
distance)
return;
}

-   numa_distance[from * numa_distance_cnt + to] = distance;
+   numa_distance[from][to] = distance;
 }

 /**
@@ -341,9 +282,9 @@ void __init numa_set_distance(int from, int to, int 
distance)
  */
 int __node_distance(int from, int to)
 {
-   if (from >= numa_distance_cnt || to >= numa_distance_cnt)
+   if (from >= MAX_NUMNODES || to >= MAX_NUMNODES)
return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
-   return numa_distance[from * numa_distance_cnt + to];
+   return numa_distance[from][to];
 }
 EXPORT_SYMBOL(__node_distance);

@@ -383,11 +324,6 @@ static int __init numa_init(int (*init_func)(void))
nodes_clear(numa_nodes_parsed);
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
-   numa_free_distance();
-
-   ret = numa_alloc_distance();
-   if (ret < 0)
-   return ret;

ret = init_func();
if (ret < 0)
--
2.5.0

[PATCH v4 06/14] of_numa: Use of_get_next_parent to simplify code

[Zhen Lei]

From: Kefeng Wang 

Use of_get_next_parent() instead of open-code.

Signed-off-by: Kefeng Wang 
---
 drivers/of/of_numa.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 3157130..ed7bd22 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -153,8 +153,6 @@ int of_node_to_nid(struct device_node *device)
np = of_node_get(device);

while (np) {
-   struct device_node *parent;
-
r = of_property_read_u32(np, "numa-node-id", &nid);
/*
 * -EINVAL indicates the property was not found, and
@@ -165,9 +163,7 @@ int of_node_to_nid(struct device_node *device)
if (r != -EINVAL)
break;

-   parent = of_get_parent(np);
-   of_node_put(np);
-   np = parent;
+   np = of_get_next_parent(np);
}
if (np && r)
pr_warn("NUMA: Invalid \"numa-node-id\" property in node %s\n",
--
2.5.0

[PATCH v3 2/2] spi: spi-ti-qspi: Add DMA support for QSPI mmap read

[Vignesh R]

Use mem-to-mem DMA to read from flash when reading in mmap mode. This
gives improved read performance and reduces CPU load.

With this patch the raw-read throughput is ~16MB/s on DRA74 EVM. And CPU
load is <20%. UBIFS read ~13 MB/s.

Signed-off-by: Vignesh R 
---

v3: Cleanup code based on review comments for v2.
v2: Handle kmap'd buffers of JFFS2 FS.

 drivers/spi/spi-ti-qspi.c | 189 ++
 1 file changed, 176 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 29ea8d2f9824..1f6c59c29157 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -41,6 +42,8 @@ struct ti_qspi_regs {
 };
 
 struct ti_qspi {
+   struct completion   transfer_complete;
+
/* list synchronization */
struct mutexlist_lock;
 
@@ -54,6 +57,9 @@ struct ti_qspi {
 
struct ti_qspi_regs ctx_reg;
 
+   dma_addr_t  mmap_phys_base;
+   struct dma_chan *rx_chan;
+
u32 spi_max_frequency;
u32 cmd;
u32 dc;
@@ -379,6 +385,72 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct 
spi_transfer *t,
return 0;
 }
 
+static void ti_qspi_dma_callback(void *param)
+{
+   struct ti_qspi *qspi = param;
+
+   complete(&qspi->transfer_complete);
+}
+
+static int ti_qspi_dma_xfer(struct ti_qspi *qspi, dma_addr_t dma_dst,
+   dma_addr_t dma_src, size_t len)
+{
+   struct dma_chan *chan = qspi->rx_chan;
+   struct dma_device *dma_dev = chan->device;
+   dma_cookie_t cookie;
+   enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+   struct dma_async_tx_descriptor *tx;
+   int ret;
+
+   tx = dma_dev->device_prep_dma_memcpy(chan, dma_dst, dma_src,
+len, flags);
+   if (!tx) {
+   dev_err(qspi->dev, "device_prep_dma_memcpy error\n");
+   return -EIO;
+   }
+
+   tx->callback = ti_qspi_dma_callback;
+   tx->callback_param = qspi;
+   cookie = tx->tx_submit(tx);
+
+   ret = dma_submit_error(cookie);
+   if (ret) {
+   dev_err(qspi->dev, "dma_submit_error %d\n", cookie);
+   return -EIO;
+   }
+
+   dma_async_issue_pending(chan);
+   ret = wait_for_completion_timeout(&qspi->transfer_complete,
+ msecs_to_jiffies(len));
+   if (ret <= 0) {
+   dmaengine_terminate_sync(chan);
+   dev_err(qspi->dev, "DMA wait_for_completion_timeout\n");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
+static int ti_qspi_dma_xfer_sg(struct ti_qspi *qspi, struct sg_table rx_sg,
+  loff_t from)
+{
+   struct scatterlist *sg;
+   dma_addr_t dma_src = qspi->mmap_phys_base + from;
+   dma_addr_t dma_dst;
+   int i, len, ret;
+
+   for_each_sg(rx_sg.sgl, sg, rx_sg.nents, i) {
+   dma_dst = sg_dma_address(sg);
+   len = sg_dma_len(sg);
+   ret = ti_qspi_dma_xfer(qspi, dma_dst, dma_src, len);
+   if (ret)
+   return ret;
+   dma_src += len;
+   }
+
+   return 0;
+}
+
 static void ti_qspi_enable_memory_map(struct spi_device *spi)
 {
struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
@@ -426,7 +498,40 @@ static void ti_qspi_setup_mmap_read(struct spi_device *spi,
  QSPI_SPI_SETUP_REG(spi->chip_select));
 }
 
-static int ti_qspi_spi_flash_read(struct  spi_device *spi,
+#ifdef CONFIG_HIGHMEM
+static int ti_qspi_map_buf(struct ti_qspi *qspi, void *buf,
+  unsigned int len, struct sg_table *sgt)
+{
+   unsigned int max_seg_size =
+   dma_get_max_seg_size(qspi->rx_chan->device->dev);
+   unsigned int desc_len = min_t(int, max_seg_size, PAGE_SIZE);
+   int sgs = DIV_ROUND_UP(len + offset_in_page(buf), desc_len);
+   struct page *vm_page;
+   size_t min;
+   int i, ret;
+
+   ret = sg_alloc_table(sgt, sgs, GFP_KERNEL);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < sgs; i++) {
+   min = min_t(size_t, len, desc_len -
+   offset_in_page(buf));
+   vm_page = kmap_to_page(buf);
+   if (!vm_page) {
+   sg_free_table(sgt);
+   return -ENOMEM;
+   }
+   sg_set_page(&sgt->sgl[i], vm_page, min,
+   offset_in_page(buf));
+   buf += min;
+   len -= min;
+   }
+   return 0;
+}
+#endif
+
+static int ti_qspi_spi_flash_read(struct spi_device *spi,
  struct spi_flash_read_message *msg)
 {
struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
@@ -437,9 +542

[PATCH v3 0/2] spi: Add DMA support for ti-qspi

[Vignesh R]

This series adds support for DMA during QSPI flash read using memory
mapped mode.

Tested on DRA74 EVM, DRA72 EVM and AM437x SK on linux-next.

v2: https://lkml.org/lkml/2016/4/25/187
v1: https://lkml.org/lkml/2016/4/4/855


Vignesh R (2):
  spi: Add DMA support for spi_flash_read()
  spi: spi-ti-qspi: Add DMA support for QSPI mmap read

 drivers/spi/spi-ti-qspi.c | 189 ++
 drivers/spi/spi.c |  14 
 include/linux/spi/spi.h   |   4 +
 3 files changed, 194 insertions(+), 13 deletions(-)

-- 
2.8.3

[PATCH v3 1/2] spi: Add DMA support for spi_flash_read()

[Vignesh R]

Few SPI devices provide accelerated read interfaces to read from
SPI-NOR flash devices. These hardwares also support DMA to transfer data
from flash to memory either via mem-to-mem DMA or dedicated slave DMA
channels. Hence, add support for DMA in order to improve throughput and
reduce CPU load.
Use spi_map_buf() to get sg table for the buffer and pass it to SPI
driver.

Signed-off-by: Vignesh R 
---

v3: No changes.
v2: use cur_msg_mapped flag to indicate success/failure of spi_map_buf()


 drivers/spi/spi.c   | 14 ++
 include/linux/spi/spi.h |  4 
 2 files changed, 18 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 77e6e45951f4..da2cbe205654 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2725,6 +2725,7 @@ int spi_flash_read(struct spi_device *spi,
 
 {
struct spi_master *master = spi->master;
+   struct device *rx_dev = NULL;
int ret;
 
if ((msg->opcode_nbits == SPI_NBITS_DUAL ||
@@ -2750,9 +2751,22 @@ int spi_flash_read(struct spi_device *spi,
return ret;
}
}
+
mutex_lock(&master->bus_lock_mutex);
+   if (master->dma_rx) {
+   rx_dev = master->dma_rx->device->dev;
+   ret = spi_map_buf(master, rx_dev, &msg->rx_sg,
+ msg->buf, msg->len,
+ DMA_FROM_DEVICE);
+   if (!ret)
+   msg->cur_msg_mapped = true;
+   }
ret = master->spi_flash_read(spi, msg);
+   if (msg->cur_msg_mapped)
+   spi_unmap_buf(master, rx_dev, &msg->rx_sg,
+ DMA_FROM_DEVICE);
mutex_unlock(&master->bus_lock_mutex);
+
if (master->auto_runtime_pm)
pm_runtime_put(master->dev.parent);
 
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 1f03483f61e5..7b53af4ba5f8 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -1143,6 +1143,8 @@ static inline ssize_t spi_w8r16be(struct spi_device *spi, 
u8 cmd)
  * @opcode_nbits: number of lines to send opcode
  * @addr_nbits: number of lines to send address
  * @data_nbits: number of lines for data
+ * @rx_sg: Scatterlist for receive data read from flash
+ * @cur_msg_mapped: message has been mapped for DMA
  */
 struct spi_flash_read_message {
void *buf;
@@ -1155,6 +1157,8 @@ struct spi_flash_read_message {
u8 opcode_nbits;
u8 addr_nbits;
u8 data_nbits;
+   struct sg_table rx_sg;
+   bool cur_msg_mapped;
 };
 
 /* SPI core interface for flash read support */
-- 
2.8.3

[PATCH] dmaengine: edma: Use early completion for intermediate paRAM set in slave_sg

[Peter Ujfalusi]

The driver limits the physical number of paRAM slots to be used by channels.
If the transfer needs more slots (more SGs) then the transfer is broken up
to smaller chunks. When the chunk is finished the driver will rewrite the
physical slots and continues the transfer. This set up time can take some
time and we might miss DMA events. If the intermediate set completion is
using early completion (the interrupt will happen when the last slot is
issued to the TPTC and not when the transfer is finished by the TPTC) we
will have a bit more time to update the paRAM slots and less likely to have
missed events.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 8181ed131386..7c76b558cf82 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1114,14 +1114,17 @@ static struct dma_async_tx_descriptor 
*edma_prep_slave_sg(
edesc->absync = ret;
edesc->residue += sg_dma_len(sg);
 
-   /* If this is the last in a current SG set of transactions,
-  enable interrupts so that next set is processed */
-   if (!((i+1) % MAX_NR_SG))
-   edesc->pset[i].param.opt |= TCINTEN;
-
-   /* If this is the last set, enable completion interrupt flag */
if (i == sg_len - 1)
+   /* Enable completion interrupt */
edesc->pset[i].param.opt |= TCINTEN;
+   else if (!((i+1) % MAX_NR_SG))
+   /*
+* Enable early completion interrupt for the
+* intermediateset. In this case the driver will be
+* notified when the paRAM set is submitted to TC. This
+* will allow more time to set up the next set of slots.
+*/
+   edesc->pset[i].param.opt |= (TCINTEN | TCCMODE);
}
edesc->residue_stat = edesc->residue;
 
-- 
2.8.3

Re: [PATCH] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions

[Minchan Kim]

On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote:
> On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote:
> > 
> > Hi Tim,
> > 
> > To me, this reorganization is too limited and not good for me,
> > frankly speaking. It works for only your goal which allocate batch
> > swap slot, I guess. :)
> > 
> > My goal is to make them work with batch page_check_references,
> > batch try_to_unmap and batch __remove_mapping where we can avoid frequent
> > mapping->lock(e.g., anon_vma or i_mmap_lock with hoping such batch locking
> > help system performance) if batch pages has same inode or anon.
> 
> This is also my goal to group pages that are either under the same
> mapping or are anonymous pages together so we can reduce the i_mmap_lock
> acquisition.  One logic that's yet to be implemented in your patch
> is the grouping of similar pages together so we only need one i_mmap_lock
> acquisition.  Doing this efficiently is non-trivial.  

Hmm, my assumption is based on same inode pages are likely to order
in LRU so no need to group them. If successive page in page_list comes
from different inode, we can drop the lock and get new lock from new
inode. That sounds strange?

> 
> I punted the problem somewhat in my patch and elected to defer the processing
> of the anonymous pages at the end so they are naturally grouped without
> having to traverse the page_list more than once.  So I'm batching the
> anonymous pages but the file mapped pages were not grouped.
> 
> In your implementation, you may need to traverse the page_list in two pass, 
> where the
> first one is to categorize the pages and grouping them and the second one
> is the actual processing.  Then the lock batching can be implemented
> for the pages.  Otherwise the locking is still done page by page in
> your patch, and can only be batched if the next page on page_list happens
> to have the same mapping.  Your idea of using a spl_batch_pages is pretty

Yes. as I said above, I expect pages in LRU would be likely to order per
inode normally. If it's not, yeb, we need grouping but such overhead would
mitigate the benefit of lock batch as SWAP_CLUSTER_MAX get bigger.

> neat.  It may need some enhancement so it is known whether some locks
> are already held for lock batching purpose.
> 
> 
> Thanks.
> 
> Tim

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

[Frank Wang]

Hi Kishon & Heiko,

On 2016/6/7 15:45, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 07 June 2016 09:01 AM, Frank Wang wrote:

Hi Heiko,

On 2016/6/7 10:59, Frank Wang wrote:

Hi Heiko & Mark,

On 2016/6/6 20:33, Heiko Stübner wrote:

Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:

On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:

Signed-off-by: Frank Wang 
---

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

Changes in v2:
   - Changed vbus_host optional property from gpio to regulator.
   - Specified vbus_otg-supply optional property.
   - Specified otg_id and otg_bvalid property.
 .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
    1 file changed, 60 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
diff --git
a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
file mode 100644
index 000..0b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,60 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+* "rockchip,rk3366-usb2phy"
+* "rockchip,rk3399-usb2phy"
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+ - vbus_host-supply : phandle to a regulator that supplies host vbus.
+ - vbus_otg-supply : phandle to a regulator that supplies otg vbus.

Nit: s/_/-/ here.

Something I only stumbled over yesterday for the first time on my rk3288-
popmetal: The phy subnodes seem to be able to use a generic phy-supply
property from inside the phy-core itself, see:

https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aaf6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597


for my WIP code for that other board.


Ah, good comments! I will try later, if it is practicable, I shall correct it
into the next patches (patch v4).


I am sorry to tell you that seems unworkable, because we have two sub-nodes
(phy-ports) in one parent-node (phy),
what is more, the 'phy-supply' property can only put into parent-node, I
believe it can not be differentiated types of ports.

'phy-supply' is a property of the phy node and not the 'phy-provider' node. So
IMO this should work. What problem do you see?


Sorry, I think I must have made a wrong phandle of phy-port name in 
*.dts before.

Yes, It works now, thanks for your reminding.

@Heiko,
I have just received your another mail, thanks again for your detail 
explanation.


I will correct it in the next patches (patch v4).

BR.
Frank

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

[Heikki Krogerus]

On Mon, Jun 06, 2016 at 03:35:35PM +0200, Oliver Neukum wrote:
> On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote:
> 
> > I would prefer lower case letters. I don't know the SIDs there are at
> > them moment, other then Display Port. Do you know them?
> > 
> > I don't think we can ever guarantee that in every case we will be able
> > to provide a human readable name for the alternate modes if they are
> > vendor defined. We will then potentially still have the names in two
> > different forms: "usbc0.displayport" and "usbc0.svid:". Is that
> > something acceptable to everybody?
> > 
> > I guess if it's not, then to only way to go forward would be to always
> > just use the svid in the name.
> 
> Yes, that is better. It makes more sense to use the number.
> We'd get into versioning problems if we use names.

OK, so we'll always use the svid in the name.

Thanks,

-- 
heikki

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

[Heikki Krogerus]

On Mon, Jun 06, 2016 at 07:41:28AM -0700, Greg KH wrote:
> On Mon, Jun 06, 2016 at 04:45:09PM +0300, Heikki Krogerus wrote:
> > > For consistency, should this be either type-c/type-c.c or
> > > typec/typec.c?
> > 
> > For some reason I like to have the dash in the folder name, but I
> > don't like the idea that the port driver would be in form
> > type-c_something. I would prefer them to be named typec_something. Or
> > maybe just "something" and also name the typec.c maybe class.c or
> > core.c.
> > 
> > Is this a big problem? I guess we could just name the folder "typec".
> > Guenter, whats your opinion?
> 
> "typec" please.

OK, typec it is.


Thanks,

-- 
heikki

Re: [PATCH v4 12/14] arm64/numa: remove some useless code

[Ganapatrao Kulkarni]

On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei  wrote:
> 1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not
>been initialized.
> 2. No reason to limit cpu0 must belongs to node0.

even smp init assumes cpu0/boot processor.
is this patch tested on any hardware?
can you describe your testing hardware?
>
> Signed-off-by: Zhen Lei 
> ---
>  arch/arm64/mm/numa.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index d73b0a0..92b1692 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -93,7 +93,6 @@ void numa_clear_node(unsigned int cpu)
>   */
>  static void __init setup_node_to_cpumask_map(void)
>  {
> -   unsigned int cpu;
> int node;
>
> /* setup nr_node_ids if not done yet */
> @@ -106,9 +105,6 @@ static void __init setup_node_to_cpumask_map(void)
> cpumask_clear(node_to_cpumask_map[node]);
> }
>
> -   for_each_possible_cpu(cpu)
> -   set_cpu_numa_node(cpu, NUMA_NO_NODE);
> -

do you see this init of setting node id to NUMA_NO_NODE  for each cpu
happening any where else?
otherwise, better to have initialised node id/NUMA_NO_NODE to every
cpu otherwise default  node id will be shown as zero
which is not correct.

> /* cpumask_of_node() will now work */
> pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
>  }
> @@ -379,10 +375,6 @@ static int __init numa_init(int (*init_func)(void))
>
> setup_node_to_cpumask_map();
>
> -   /* init boot processor */
> -   cpu_to_node_map[0] = 0;
> -   map_cpu_to_node(0, 0);
> -

otherwise, how you set numa info for cpu0/boot-processor?

thanks
Ganapat
> return 0;
>  }
>
> --
> 2.5.0
>
>
>

thanks
ganapat

> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [STLinux Kernel] [[PATCH v2] 08/11] pwm: sti: Initialise PWM Capture device data

[Peter Griffin]

Hi Lee,

On Fri, 22 Apr 2016, Lee Jones wrote:

> Each PWM Capture device is allocated a structure to hold its own
> state.  During a capture the device may be partaking in one of 3
> phases.  Initial (rising) phase change, a subsequent (falling)
> phase change indicating end of the duty-cycle phase and finally
> a final (rising) phase change indicating the end of the period.
> The timer value snapshot each event is held in a variable of the
> same name, and the phase number (0, 1, 2) is contained in the
> index variable.  Other device specific information, such as GPIO
> pin, the IRQ wait queue and locking is also contained in the
> structure.  This patch initialises this structure for each of
> the available devices.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/pwm/pwm-sti.c | 45 ++---
>  1 file changed, 38 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
> index 78979d0..9d597bb 100644
> --- a/drivers/pwm/pwm-sti.c
> +++ b/drivers/pwm/pwm-sti.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,8 +19,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #define PWM_OUT_VAL(x)   (0x00 + (4 * (x))) /* Device's Duty Cycle 
> register */
>  #define PWM_CPT_VAL(x)   (0x10 + (4 * (x))) /* Capture value */
> @@ -64,9 +67,17 @@ enum sti_cpt_edge {
>   CPT_EDGE_BOTH,
>  };
>  
> +struct sti_cpt_ddata {
> + u32 snapshot[3];
> + int index;
> + struct mutex lock;
> + wait_queue_head_t wait;
> +};
> +
>  struct sti_pwm_compat_data {
>   const struct reg_field *reg_fields;
> - unsigned int num_devs;
> + unsigned int pwm_num_devs;
> + unsigned int cpt_num_devs;
>   unsigned int max_pwm_cnt;
>   unsigned int max_prescale;
>  };
> @@ -307,10 +318,15 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
>   struct device_node *np = dev->of_node;
>   struct sti_pwm_compat_data *cdata = pc->cdata;
>   u32 num_devs;
> + int ret;
>  
> - of_property_read_u32(np, "st,pwm-num-devs", &num_devs);
> - if (num_devs)
> - cdata->num_devs = num_devs;
> + ret = of_property_read_u32(np, "st,pwm-num-devs", &num_devs);
> + if (!ret)
> + cdata->pwm_num_devs = num_devs;

dt binding document documents this as st,pwm-num-chan currently. Why do you need
this  binding anyway? Why can't you determine how many channels you have based 
on
the number of pinctrl groups you are given?

Also with this series I don't currently understand how the driver is configured 
to be
pwm-in or pwm-out. Can you explain how that decision is made?

For example at the moment I can't see any code in this series for handling the 
different
pinctrl groups which presumably are required to have this working.

If I look at pinctrl_pwm1_chan0_default and friends declared in
stih407-pinctrl.dtsi all are currently named pwm-out, and declared as outputs. 
For
pwm-in functionality I was expecting to see another set of pinctrl definitions,
declaring these pins as inputs, and something in the driver selecting the
correct pin config depending on how the device has been configured?

Maybe an updated dt example / bindings would make this clearer.

regards,

Peter

[PATCH] arm64: Implement arch_setup_pdev_archdata hook

[Baolin Wang]

Now on ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if
it did not call 'arch_setup_dma_ops' at device creation time by issuing
platform_device_alloc() function, that will cause failure when setting
the dma mask for device.

Hence We need to hook the archdata to setup proper dma_ops for these devices.

Signed-off-by: Baolin Wang 
---
 arch/arm64/mm/dma-mapping.c |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c566ec8..04e057b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -961,3 +962,23 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
 }
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+   if (!pdev->dev.archdata.dma_ops)
+   pdev->dev.archdata.dma_ops = &swiotlb_dma_ops;
+
+   /*
+* Set default coherent_dma_mask to 32 bit. Drivers are expected to
+* setup the correct supported mask.
+*/
+   if (!pdev->dev.coherent_dma_mask)
+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+   /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+   if (!pdev->dev.dma_mask)
+   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
+}
-- 
1.7.9.5

Re: [PATCH v3 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

[Giuseppe CAVALLARO]

Hello

On 6/7/2016 5:01 AM, th...@altera.com wrote:

From: Tien Hock Loh 

This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
the dwmac is set to sgmii

Signed-off-by: Tien Hock Loh 

---
v2:
- Refactored the TSE PCS out from the dwmac-socfpga.c file
- Added binding documentation for TSE PCS sgmii adapter
v3:
- Added missing license header for new source files
- Updated tse_pcs.h include headers
- Standardize if statements
---
 .../devicetree/bindings/net/socfpga-dwmac.txt  |   4 +
 drivers/net/ethernet/stmicro/stmmac/Makefile   |   2 +-
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 140 +--
 drivers/net/ethernet/stmicro/stmmac/tse_pcs.c  | 261 +
 drivers/net/ethernet/stmicro/stmmac/tse_pcs.h  |  36 +++
 5 files changed, 419 insertions(+), 24 deletions(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/tse_pcs.c
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/tse_pcs.h


I just wonder if it could make sense to rename the
tse_pcs.[hc] files or creating a sub-directory for altera devel.
It seems that tse_pcs.[hc] are common files but this support
is for Altera.
Anyway, I let you decide and I also ask you to update the stmmac.txt
file.


diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt 
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 3a9d679..2bc39f1 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -15,6 +15,8 @@ Required properties:
 Optional properties:
 altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
DWMAC controller is connected emac splitter.
+phy-mode: The phy mode the ethernet operates in
+altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter

 Example:

@@ -28,4 +30,6 @@ gmac0: ethernet@ff70 {
mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
clocks = <&emac_0_clk>;
clock-names = "stmmaceth";
+   phy-mode = "sgmii";
+   altr,gmii_to_sgmii_converter = <&sgmii_1_gmii_to_sgmii_converter_0>;
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 73c2715..29c1dee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o 
ring_mode.o  \

 obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
 stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o dwmac-sunxi.o   \
-  dwmac-sti.o dwmac-socfpga.o dwmac-rk.o
+  dwmac-sti.o dwmac-socfpga.o dwmac-rk.o tse_pcs.o

 obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
 stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 3f9588e..88fba4e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -27,6 +27,8 @@
 #include "stmmac.h"
 #include "stmmac_platform.h"

+#include "tse_pcs.h"
+
 #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
 #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
 #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
@@ -47,48 +49,60 @@ struct socfpga_dwmac {
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
+   struct tse_pcs pcs;
 };

 static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
 {
struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)priv;
void __iomem *splitter_base = dwmac->splitter_base;
+   void __iomem *tse_pcs_base = dwmac->pcs.tse_pcs_base;
+   void __iomem *sgmii_adapter_base = dwmac->pcs.sgmii_adapter_base;
+   struct device *dev = dwmac->dev;
+   struct net_device *ndev = dev_get_drvdata(dev);
+   struct phy_device *phy_dev = ndev->phydev;
u32 val;

-   if (!splitter_base)
-   return;
-
-   val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
-   val &= ~EMAC_SPLITTER_CTRL_SPEED_MASK;
-
-   switch (speed) {
-   case 1000:
-   val |= EMAC_SPLITTER_CTRL_SPEED_1000;
-   break;
-   case 100:
-   val |= EMAC_SPLITTER_CTRL_SPEED_100;
-   break;
-   case 10:
-   val |= EMAC_SPLITTER_CTRL_SPEED_10;
-   break;
-   default:
-   return;
+   if (splitter_base) {
+   val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
+   val &= ~EMAC_SPLITTER_CTRL_SPEED_MASK;
+
+   switch (speed) {
+   case 1000:
+   val |= EMAC_SPLITTER_CTRL_SPEED_1000;
+   break;
+   case 100:
+   val |= EMAC_SPLITTER_CTRL_SPEED_100;
+   break;
+   case 10:
+  

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

[Ganapatrao Kulkarni]

On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei  wrote:
> Some numa nodes may have no memory. For example:
> 1. cpu0 on node0
> 2. cpu1 on node1
> 3. device0 access the momory from node0 and node1 take the same time.

i am wondering, if access to both nodes is same, then why you need numa.
the example you are quoting is against the basic principle of "numa"
what is device0 here? cpu?
>
> So, we can not simply classify device0 to node0 or node1, but we can
> define a node2 which distances to node0 and node1 are the same.
>
> Signed-off-by: Zhen Lei 
> ---
>  arch/arm64/Kconfig  |  4 
>  arch/arm64/kernel/smp.c |  1 +
>  arch/arm64/mm/numa.c| 43 +--
>  3 files changed, 46 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 05c1bf1..5904a62 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -581,6 +581,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> def_bool y
> depends on NUMA
>
> +config HAVE_MEMORYLESS_NODES
> +   def_bool y
> +   depends on NUMA
> +
>  source kernel/Kconfig.preempt
>  source kernel/Kconfig.hz
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d099306..9e15297 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -620,6 +620,7 @@ static void __init of_parse_and_init_cpus(void)
> }
>
> bootcpu_valid = true;
> +   early_map_cpu_to_node(0, of_node_to_nid(dn));
>
> /*
>  * cpu_logical_map has already been
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index df5c842..d73b0a0 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -128,6 +128,14 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
> nid)
> nid = 0;
>
> cpu_to_node_map[cpu] = nid;
> +
> +   /*
> +* We should set the numa node of cpu0 as soon as possible, because it
> +* has already been set up online before. cpu_to_node(0) will soon be
> +* called.
> +*/
> +   if (!cpu)
> +   set_cpu_numa_node(cpu, nid);
>  }
>
>  #ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
> @@ -215,6 +223,35 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> return ret;
>  }
>
> +static u64 __init alloc_node_data_from_nearest_node(int nid, const size_t 
> size)
> +{
> +   int i, best_nid, distance;
> +   u64 pa;
> +   DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
> +
> +   bitmap_zero(nodes_map, MAX_NUMNODES);
> +   bitmap_set(nodes_map, nid, 1);
> +
> +find_nearest_node:
> +   best_nid = NUMA_NO_NODE;
> +   distance = INT_MAX;
> +
> +   for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
> +   if (numa_distance[nid][i] < distance) {
> +   best_nid = i;
> +   distance = numa_distance[nid][i];
> +   }
> +
> +   pa = memblock_alloc_nid(size, SMP_CACHE_BYTES, best_nid);
> +   if (!pa) {
> +   BUG_ON(best_nid == NUMA_NO_NODE);
> +   bitmap_set(nodes_map, best_nid, 1);
> +   goto find_nearest_node;
> +   }
> +
> +   return pa;
> +}
> +
>  /**
>   * Initialize NODE_DATA for a node on the local memory
>   */
> @@ -228,7 +265,9 @@ static void __init setup_node_data(int nid, u64 
> start_pfn, u64 end_pfn)
> pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
> nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
>
> -   nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> +   nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
> +   if (!nd_pa)
> +   nd_pa = alloc_node_data_from_nearest_node(nid, nd_size);
> nd = __va(nd_pa);
>
> /* report and initialize */
> @@ -238,7 +277,7 @@ static void __init setup_node_data(int nid, u64 
> start_pfn, u64 end_pfn)
> if (tnid != nid)
> pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);
>
> -   node_data[nid] = nd;
> +   NODE_DATA(nid) = nd;
> memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
> NODE_DATA(nid)->node_id = nid;
> NODE_DATA(nid)->node_start_pfn = start_pfn;
> --
> 2.5.0
>
>
Ganapat
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 2/3] sched/cputime: Fix prev steal time accouting during cpu hotplug

[Wanpeng Li]

From: Wanpeng Li 

Commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug") 
set rq->prev_* to 0 after a cpu hotplug comes back in order to fix the scenario:

| steal is smaller than rq->prev_steal_time we end up with an insane large
| value which then gets added to rq->prev_steal_time, resulting in a permanent
| wreckage of the accounting.

However, it is still buggy.

rq->prev_steal_time = 0:

As Rik pointed out:

| setting rq->prev_irq_time to 0 in the guest, and then getting a giant value 
from 
| the host, could result in a very large of steal_jiffies.

rq->prev_steal_time_rq = 0:

| steal = paravirt_steal_clock(cpu_of(rq));
| steal -= rq->prev_steal_time_rq;
|
| if (unlikely(steal > delta))
|steal = delta;
|
| rq->prev_steal_time_rq += steal;
| delta -= steal;
|
| rq->clock_task += delta;

steal is a giant value and rq->prev_steal_time_rq is 0, rq->prev_steal_time_rq 
grows in delta granularity, rq->clock_task can't ramp up until 
rq->prev_steal_time_rq 
catches up steal clock since delta value will be 0 after reducing steal time 
from 
normal execution time. That's why I obersved that cpuhg/1-12 continue running 
until rq->prev_steal_time_rq catches up steal clock timestamp.

I believe rq->prev_irq_time has similar issue. So this patch fix it by setting 
rq->prev_* to current irq time and steal clock timestamp after a cpu hotplug 
comes back.

Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug")'
Acked-by: Rik van Riel 
Cc: Ingo Molnar 
Cc: Peter Zijlstra (Intel) 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 kernel/sched/sched.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 72f1f30..e6758af 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1813,12 +1813,12 @@ static inline void cpufreq_trigger_update(u64 time) {}
 static inline void account_reset_rq(struct rq *rq)
 {
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
-   rq->prev_irq_time = 0;
+   rq->prev_irq_time = irq_time_read(cpu_of(rq));
 #endif
 #ifdef CONFIG_PARAVIRT
-   rq->prev_steal_time = 0;
+   rq->prev_steal_time = paravirt_steal_clock(cpu_of(rq));
 #endif
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-   rq->prev_steal_time_rq = 0;
+   rq->prev_steal_time_rq = paravirt_steal_clock(cpu_of(rq));
 #endif
 }
-- 
1.9.1

[PATCH v4 1/3] KVM: fix steal clock warp during guest cpu hotplug

[Wanpeng Li]

From: Wanpeng Li 

I observed that sometimes st is 100% instantaneous, then idle is 100% 
even if there is a cpu hog on the guest cpu after the cpu hotplug comes 
back(N.B. this can not always be readily reproduced). I add trace to 
capture it as below:

cpuhp/1-12[001] d.h1   167.461657: account_process_tick: steal = 
1291385514, prev_steal_time = 0 
cpuhp/1-12[001] d.h1   167.461659: account_process_tick: steal_jiffies = 
1291  
-0 [001] d.h1   167.462663: account_process_tick: steal = 18732255, 
prev_steal_time = 129100  
-0 [001] d.h1   167.462664: account_process_tick: steal_jiffies = 
18446744072437

The steal clock warp and then steal_jiffies underflow.

Rik also pointed out to me:
 
| I have seen stuff like that with live migration too, in the past 

The root cause of steal clock warp during hotplug is kvm_steal_time reset 
to 0 after cpu hotplug comes back which should be preexiting guest value. 
This patch fix it by don't reset kvm_steal_time during guest cpu hotplug.

Suggested-by: Paolo Bonzini 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Ingo Molnar 
Cc: Peter Zijlstra (Intel) 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Signed-off-by: Wanpeng Li 
---
v2 -> v3:
 * fix the root cause
v1 -> v2:
 * update patch subject, description and comments
 * deal with the case where steal time suddenly increases by a ludicrous amount

 arch/x86/kernel/kvm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index eea2a6f..1ef5e48 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
if (!has_steal_clock)
return;
 
-   memset(st, 0, sizeof(*st));
-
wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
pr_info("kvm-stealtime: cpu %d, msr %llx\n",
cpu, (unsigned long long) slow_virt_to_phys(st));
-- 
1.9.1

[PATCH v4 3/3] sched/cputime: Add steal time support to full dynticks CPU time accounting

[Wanpeng Li]

From: Wanpeng Li 

This patch adds guest steal-time support to full dynticks CPU
time accounting. After the following commit:

ff9a9b4c4334 ("sched, time: Switch VIRT_CPU_ACCOUNTING_GEN to jiffy 
granularity")

... time sampling became jiffy based, even if it's still listened
to ring boundaries, so steal_account_process_tick() is reused
to account how many 'ticks' are stolen-time, after the last accumulation.

Suggested-and-Reviewed-by: Rik van Riel 
Cc: Ingo Molnar 
Cc: Peter Zijlstra (Intel) 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
v3 -> v4:
 * fix grammar errors, thanks Ingo
 * cleanup fragile codes, thanks Ingo
v2 -> v3:
 * convert steal time jiffies to cputime
v1 -> v2:
 * fix divide zero bug, thanks Rik

 kernel/sched/cputime.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 75f98c5..9ff036b 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -257,7 +257,7 @@ void account_idle_time(cputime_t cputime)
cpustat[CPUTIME_IDLE] += (__force u64) cputime;
 }
 
-static __always_inline bool steal_account_process_tick(void)
+static __always_inline unsigned long steal_account_process_tick(void)
 {
 #ifdef CONFIG_PARAVIRT
if (static_key_false(¶virt_steal_enabled)) {
@@ -279,7 +279,7 @@ static __always_inline bool steal_account_process_tick(void)
return steal_jiffies;
}
 #endif
-   return false;
+   return 0;
 }
 
 /*
@@ -691,9 +691,13 @@ static cputime_t get_vtime_delta(struct task_struct *tsk)
 
 static void __vtime_account_system(struct task_struct *tsk)
 {
-   cputime_t delta_cpu = get_vtime_delta(tsk);
+   cputime_t delta_time = get_vtime_delta(tsk);
+   cputime_t steal_time = jiffies_to_cputime(steal_account_process_tick());
 
-   account_system_time(tsk, irq_count(), delta_cpu, 
cputime_to_scaled(delta_cpu));
+   if (steal_time < delta_time) {
+   delta_time -= steal_time;
+   account_system_time(tsk, irq_count(), delta_time, 
cputime_to_scaled(delta_time));
+   }
 }
 
 void vtime_account_system(struct task_struct *tsk)
@@ -718,13 +722,18 @@ void vtime_gen_account_irq_exit(struct task_struct *tsk)
 
 void vtime_account_user(struct task_struct *tsk)
 {
-   cputime_t delta_cpu;
+   cputime_t delta_time, steal_time;
 
write_seqcount_begin(&tsk->vtime_seqcount);
tsk->vtime_snap_whence = VTIME_SYS;
if (vtime_delta(tsk)) {
-   delta_cpu = get_vtime_delta(tsk);
-   account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
+   delta_time = get_vtime_delta(tsk);
+   steal_time = jiffies_to_cputime(steal_account_process_tick());
+
+   if (steal_time < delta_time) {
+   delta_time -= steal_time;
+   account_user_time(tsk, delta_time, 
cputime_to_scaled(delta_time));
+   }
}
write_seqcount_end(&tsk->vtime_seqcount);
 }
-- 
1.9.1

[PATCH v4 2/3] firmware: Provide infrastructure to make fw caching optional

[Stephen Boyd]

From: Vikram Mulukutla 

Some low memory systems with complex peripherals cannot afford to
have the relatively large firmware images taking up valuable
memory during suspend and resume. Change the internal
implementation of firmware_class to disallow caching based on a
configurable option. In the near future, variants of
request_firmware will take advantage of this feature.

Signed-off-by: Vikram Mulukutla 
[stephen.b...@linaro.org: Drop firmware_desc design and use flags]
Signed-off-by: Stephen Boyd 
---
 drivers/base/firmware_class.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 01d55723d82c..45ed20cefa10 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -112,6 +112,7 @@ static inline long firmware_loading_timeout(void)
 #define FW_OPT_FALLBACK0
 #endif
 #define FW_OPT_NO_WARN (1U << 3)
+#define FW_OPT_NOCACHE (1U << 4)
 
 struct firmware_cache {
/* firmware_buf instance will be added into the below list */
@@ -1065,14 +1066,16 @@ static int assign_firmware_buf(struct firmware *fw, 
struct device *device,
 * should be fixed in devres or driver core.
 */
/* don't cache firmware handled without uevent */
-   if (device && (opt_flags & FW_OPT_UEVENT))
+   if (device && (opt_flags & FW_OPT_UEVENT) &&
+   !(opt_flags & FW_OPT_NOCACHE))
fw_add_devm_name(device, buf->fw_id);
 
/*
 * After caching firmware image is started, let it piggyback
 * on request firmware.
 */
-   if (buf->fwc->state == FW_LOADER_START_CACHE) {
+   if (!(opt_flags & FW_OPT_NOCACHE) &&
+   buf->fwc->state == FW_LOADER_START_CACHE) {
if (fw_cache_piggyback_on_request(buf->fw_id))
kref_get(&buf->ref);
}
-- 
2.9.0-rc1

[PATCH v4 1/3] firmware: Consolidate kmap/read/write logic

[Stephen Boyd]

We use similar structured code to read and write the kmapped
firmware pages. The only difference is read copies from the kmap
region and write copies to it. Consolidate this into one function
to reduce duplication.

Cc: Vikram Mulukutla 
Signed-off-by: Stephen Boyd 
---
 drivers/base/firmware_class.c | 57 ---
 1 file changed, 26 insertions(+), 31 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc3099769..01d55723d82c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -691,6 +691,29 @@ out:
 
 static DEVICE_ATTR(loading, 0644, firmware_loading_show, 
firmware_loading_store);
 
+static void firmware_rw(struct firmware_buf *buf, char *buffer,
+   loff_t offset, size_t count, bool read)
+{
+   while (count) {
+   void *page_data;
+   int page_nr = offset >> PAGE_SHIFT;
+   int page_ofs = offset & (PAGE_SIZE-1);
+   int page_cnt = min_t(size_t, PAGE_SIZE - page_ofs, count);
+
+   page_data = kmap(buf->pages[page_nr]);
+
+   if (read)
+   memcpy(buffer, page_data + page_ofs, page_cnt);
+   else
+   memcpy(page_data + page_ofs, buffer, page_cnt);
+
+   kunmap(buf->pages[page_nr]);
+   buffer += page_cnt;
+   offset += page_cnt;
+   count -= page_cnt;
+   }
+}
+
 static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj,
  struct bin_attribute *bin_attr,
  char *buffer, loff_t offset, size_t count)
@@ -715,21 +738,8 @@ static ssize_t firmware_data_read(struct file *filp, 
struct kobject *kobj,
 
ret_count = count;
 
-   while (count) {
-   void *page_data;
-   int page_nr = offset >> PAGE_SHIFT;
-   int page_ofs = offset & (PAGE_SIZE-1);
-   int page_cnt = min_t(size_t, PAGE_SIZE - page_ofs, count);
-
-   page_data = kmap(buf->pages[page_nr]);
-
-   memcpy(buffer, page_data + page_ofs, page_cnt);
+   firmware_rw(buf, buffer, offset, count, true);
 
-   kunmap(buf->pages[page_nr]);
-   buffer += page_cnt;
-   offset += page_cnt;
-   count -= page_cnt;
-   }
 out:
mutex_unlock(&fw_lock);
return ret_count;
@@ -809,24 +819,9 @@ static ssize_t firmware_data_write(struct file *filp, 
struct kobject *kobj,
goto out;
 
retval = count;
+   firmware_rw(buf, buffer, offset, count, false);
 
-   while (count) {
-   void *page_data;
-   int page_nr = offset >> PAGE_SHIFT;
-   int page_ofs = offset & (PAGE_SIZE - 1);
-   int page_cnt = min_t(size_t, PAGE_SIZE - page_ofs, count);
-
-   page_data = kmap(buf->pages[page_nr]);
-
-   memcpy(page_data + page_ofs, buffer, page_cnt);
-
-   kunmap(buf->pages[page_nr]);
-   buffer += page_cnt;
-   offset += page_cnt;
-   count -= page_cnt;
-   }
-
-   buf->size = max_t(size_t, offset, buf->size);
+   buf->size = max_t(size_t, offset + count, buf->size);
 out:
mutex_unlock(&fw_lock);
return retval;
-- 
2.9.0-rc1

[PATCH v4 3/3] firmware: Support loading into a pre-allocated buffer

[Stephen Boyd]

Some systems are memory constrained but they need to load very
large firmwares. The firmware subsystem allows drivers to request
this firmware be loaded from the filesystem, but this requires
that the entire firmware be loaded into kernel memory first
before it's provided to the driver. This can lead to a situation
where we map the firmware twice, once to load the firmware into
kernel memory and once to copy the firmware into the final
resting place.

This creates needless memory pressure and delays loading because
we have to copy from kernel memory to somewhere else. Let's add a
request_firmware_into_buf() API that allows drivers to request
firmware be loaded directly into a pre-allocated buffer. This
skips the intermediate step of allocating a buffer in kernel
memory to hold the firmware image while it's read from the
filesystem. It also requires that drivers know how much memory
they'll require before requesting the firmware and negates any
benefits of firmware caching because the firmware layer doesn't
manage the buffer lifetime.

For a 16MB buffer, about half the time is spent performing a
memcpy from the buffer to the final resting place. I see loading
times go from 0.081171 seconds to 0.047696 seconds after applying
this patch. Plus the vmalloc pressure is reduced.

This is based on a patch from Vikram Mulukutla on
codeaurora.org[1].

[1] 
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.18/commit/drivers/base/firmware_class.c?h=rel/msm-3.18&id=0a328c5f6cd999f5c591f172216835636f39bcb5
Cc: Mimi Zohar 
Cc: Vikram Mulukutla 
Signed-off-by: Stephen Boyd 
---
 drivers/base/firmware_class.c | 125 +-
 fs/exec.c |   9 ++-
 include/linux/firmware.h  |   8 +++
 include/linux/fs.h|   1 +
 4 files changed, 114 insertions(+), 29 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 45ed20cefa10..22d1760a4278 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -46,7 +46,8 @@ MODULE_LICENSE("GPL");
 extern struct builtin_fw __start_builtin_fw[];
 extern struct builtin_fw __end_builtin_fw[];
 
-static bool fw_get_builtin_firmware(struct firmware *fw, const char *name)
+static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
+   void *buf, size_t size)
 {
struct builtin_fw *b_fw;
 
@@ -54,6 +55,9 @@ static bool fw_get_builtin_firmware(struct firmware *fw, 
const char *name)
if (strcmp(name, b_fw->name) == 0) {
fw->size = b_fw->size;
fw->data = b_fw->data;
+
+   if (buf && fw->size <= size)
+   memcpy(buf, fw->data, fw->size);
return true;
}
}
@@ -74,7 +78,9 @@ static bool fw_is_builtin_firmware(const struct firmware *fw)
 
 #else /* Module case - no builtin firmware support */
 
-static inline bool fw_get_builtin_firmware(struct firmware *fw, const char 
*name)
+static inline bool fw_get_builtin_firmware(struct firmware *fw,
+  const char *name, void *buf,
+  size_t size)
 {
return false;
 }
@@ -144,6 +150,7 @@ struct firmware_buf {
unsigned long status;
void *data;
size_t size;
+   size_t allocated_size;
 #ifdef CONFIG_FW_LOADER_USER_HELPER
bool is_paged_buf;
bool need_uevent;
@@ -179,7 +186,8 @@ static DEFINE_MUTEX(fw_lock);
 static struct firmware_cache fw_cache;
 
 static struct firmware_buf *__allocate_fw_buf(const char *fw_name,
- struct firmware_cache *fwc)
+ struct firmware_cache *fwc,
+ void *dbuf, size_t size)
 {
struct firmware_buf *buf;
 
@@ -195,6 +203,8 @@ static struct firmware_buf *__allocate_fw_buf(const char 
*fw_name,
 
kref_init(&buf->ref);
buf->fwc = fwc;
+   buf->data = dbuf;
+   buf->allocated_size = size;
init_completion(&buf->completion);
 #ifdef CONFIG_FW_LOADER_USER_HELPER
INIT_LIST_HEAD(&buf->pending_list);
@@ -218,7 +228,8 @@ static struct firmware_buf *__fw_lookup_buf(const char 
*fw_name)
 
 static int fw_lookup_and_allocate_buf(const char *fw_name,
  struct firmware_cache *fwc,
- struct firmware_buf **buf)
+ struct firmware_buf **buf, void *dbuf,
+ size_t size)
 {
struct firmware_buf *tmp;
 
@@ -230,7 +241,7 @@ static int fw_lookup_and_allocate_buf(const char *fw_name,
*buf = tmp;
return 1;
}
-   tmp = __allocate_fw_buf(fw_name, fwc);
+   tmp = __allocate_fw_buf(fw_name, fwc, dbuf, size);
if (tmp)
  

Re: [PATCH 2/2] powerpc/mm: check for irq disabled() only if DEBUG_VM is enabled.

[Balbir Singh]

On 31/05/16 21:04, Aneesh Kumar K.V wrote:
> We don't need to check this always. The idea here is to capture the
> wrong usage of find_linux_pte_or_hugepte and we can do that by
> occasionally running with DEBUG_VM enabled.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/pgtable.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index ee09e99097f0..9bd87f269d6d 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -71,10 +71,8 @@ pte_t *__find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned 
> long ea,
>  static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long 
> ea,
>  bool *is_thp, unsigned *shift)
>  {
> - if (!arch_irqs_disabled()) {
> - pr_info("%s called with irq enabled\n", __func__);
> - dump_stack();
> - }
> + VM_WARN(!arch_irqs_disabled(),
> + "%s called with irq enabled\n", __func__);
>   return __find_linux_pte_or_hugepte(pgdir, ea, is_thp, shift);
>  }

Agreed! Honestly, I think it should be a VM_BUG_ON() since we have a large 
reliance
on this elsewhere in the code.

Balbir Singh.

Re: [STLinux Kernel] [PATCH 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the ports on the Generic PHY
> share their reset lines with each other.  New functionality in the
> reset subsystems forces consumers to be explicit when requesting
> shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 

Acked-by: Peter Griffin 

Re: [PATCH][RFC] x86, hotplug: Use zero page for monitor when resuming from hibernation

[Chen Yu]

Hi Pavel,

On 2016年06月07日 16:03, Pavel Machek wrote:

On Mon 2016-06-06 22:19:09, Chen Yu wrote:

Stress test from Varun Koyyalagunta reports that, the
nonboot CPU would hang occasionally, when resuming from
hibernation. Further investigation shows that, the precise
phase when nonboot CPU hangs, is the time when the nonboot
CPU been woken up incorrectly, and tries to monitor the
mwait_ptr for the second time, then an exception is
triggered due to illegal vaddr access, say, something like,
'Unable to handler kernel address of 0x8800ba800010...'

One of the possible scenarios for this issue is illustrated below,
when the boot CPU tries to resume from hibernation:
1. puts the nonboot CPUs offline, so the nonboot CPUs are monitoring
at the address of the task_struct.flags.
2. boot CPU copies pages to their original address, which includes
task_struct.flags, thus wakes up one of the nonboot CPUs.
3. nonboot CPU tries to monitor the task_struct.flags again, but since
the page table for task_struct.flags has been overwritten by
boot CPU, and there is probably a changed across hibernation
(because of inconsistence of e820 memory map), an exception is
triggered.

If memory map changes between suspend and resume, there'll be fun. If
that's suspected, should we attach md5 sum of e820 to the hibernation
image?

Actually what I described  in the  scenario might be not so accurate,
it might not be related to inconsistence of e820 map,
because there is no guarantee that boot kernel and resume kernel
have the same memory layout(page table).

I've re-checked the logs from reporter, it seems that, the fault
access is caused by accessing a page without PRESENT flag,
and the pte entry for this vaddr is zero:

   // DATA ADDRESS TRANSLATION, virtual address = 0x8800BA803E88
   //   DATA TABLE WALK, virtual address = 0x8800BA803E88
   pml4read   0x0001C128800x01FD2067; // pgd
   pdptread   0x0001FD20100x9BEBF063; // pud
   pderead0x009BEBFEA00x2D9D9063; // pmd
   pteread0x002D9D90180x; // pte

The last line above is a pte entry located at physical address 0x2d9d9018,
with value zero, thus access to this vaddr results in a page-not-present 
exception.


Since some of the pud/pde/pte are allocated dynamically during bootup
(kernel_physical_mapping_init),
it is possible that, when the boot cpu writes to this vaddr,
the page table(especially for pud/pmd/pte) for this vaddr
are not the same as it is before hibernation,  thus an exception would be
triggered due to incorrect page table, even e820 is consistent.

I'm doing more test to verify this.

thanks,
Yu

Re: [STLinux Kernel] [PATCH 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the MiPHY28lp shares its reset
> line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> (DRD).  New functionality in the reset subsystems forces consumers to
> be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/phy/phy-miphy28lp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Peter Griffin 

[PATCH] bitmap_equal memcmp optimization for s390

[Martin Schwidefsky]

Servus,

while working on an improved TLB flush logic for s390 I noticed that
for s390 cpumask_equal() alias bitmap_equal() can be improved for the
special case "(nbits % BITS_PER_LONG) == 0". The memcmp function can
be used in this case and we have an instruction for that ..

Trouble is that the default memcmp implementation uses a byte loop
while the __bitmap_equal function uses a loop over unsigned long.
For x86 the __bitmap_equal function is faster than memcmp, using
memcmp for the special case for all architectures is not correct.
Right now the patches uses a '#ifdef CONFIG_S390' to guard the
memcmp special case.

I hesitate to put another CONFIG_S390 into common code, alternatively
__HAVE_ARCH_MEMCMP could be used. There are 7 architectures with the
define: arc, arm64, blackfin, frv, powerpc, s390 and sparc.
Of those I guess only powerpc, s390 and sparc will have configs with
(NR_CPUS > BITS_PER_LONG). For (NR_CPUS <= BITS_PER_LONG) the xor
optimization is used.

powerpc, s390 and sparc do have optimized memcmp code, the question
is if it is faster then __bitmap_equal.

Now, CONFIG_S390 or __HAVE_ARCH_MEMCMP ?

blue skies,
  Martin

Re: [STLinux Kernel] [PATCH 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the ST EHCI IP shares its reset
> line with the OHCI IP.  New functionality in the reset subsystems forces
> consumers to be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/usb/host/ehci-st.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Peter Griffin