Applied "ASoC: dwc: Add irq parameter to DOCUMENTATION" to the asoc tree

[Mark Brown]

The patch

   ASoC: dwc: Add irq parameter to DOCUMENTATION

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5aa1418defb0e88fb7f70c5b112d531cfcede851 Mon Sep 17 00:00:00 2001
From: Jose Abreu 
Date: Thu, 9 Jun 2016 12:47:06 +0100
Subject: [PATCH] ASoC: dwc: Add irq parameter to DOCUMENTATION

A parameter description for the interruptions of the
I2S controller was added.

Signed-off-by: Jose Abreu 
Acked-by: Rob Herring 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb54247f8e8..6a536d570e29 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -12,6 +12,10 @@ Required properties:
one for receive.
  - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
 
+Optional properties:
+ - interrupts: The interrupt line number for the I2S controller. Add this
+   parameter if the I2S controller that you are using does not support DMA.
+
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
* resource-names.txt
-- 
2.8.1

Applied "ASoC: cs53l30: Correct clock inversion check" to the asoc tree

[Mark Brown]

The patch

   ASoC: cs53l30: Correct clock inversion check

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 88b1c01fb42e3d637c7e7f36cd4a30ce39a2add4 Mon Sep 17 00:00:00 2001
From: Nicolin Chen 
Date: Wed, 8 Jun 2016 16:10:05 -0700
Subject: [PATCH] ASoC: cs53l30: Correct clock inversion check

SND_SOC_DAIFMT_IB_NF = 0x3 (11b) | SND_SOC_DAIFMT_IB_IF = 0x4 (100b)
creates a mask 0x7 (111b) which also includes SND_SOC_DAIFMT_NB_IF
= 0x2 (10b).

So this patch uses the traditional way to check the clock inversion.

Signed-off-by: Nicolin Chen 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/cs53l30.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
index aa511e70099e..384a3f79f1c5 100644
--- a/sound/soc/codecs/cs53l30.c
+++ b/sound/soc/codecs/cs53l30.c
@@ -599,8 +599,14 @@ static int cs53l30_set_dai_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
}
 
/* Check to see if the SCLK is inverted */
-   if (fmt & (SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_IB_IF))
+   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+   case SND_SOC_DAIFMT_IB_NF:
+   case SND_SOC_DAIFMT_IB_IF:
aspcfg ^= CS53L30_ASP_SCLK_INV;
+   break;
+   default:
+   break;
+   }
 
regmap_update_bits(priv->regmap, CS53L30_ASPCFG_CTL,
   CS53L30_ASP_MS | CS53L30_ASP_SCLK_INV, aspcfg);
-- 
2.8.1

Re: [PATCH -next] rcutorture: Fix error return code in rcu_perf_init()

[Paul E. McKenney]

On Mon, Jun 13, 2016 at 03:20:39PM +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> Fix to return a negative error code -ENOMEM from kcalloc() error
> handling case instead of 0, as done elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun 

Good eyes!  Queued for review and testing.

Thanx, Paul

> ---
>  kernel/rcu/rcuperf.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index 7b2dbdf..d38ab08 100644
> --- a/kernel/rcu/rcuperf.c
> +++ b/kernel/rcu/rcuperf.c
> @@ -638,8 +638,10 @@ rcu_perf_init(void)
>   writer_durations[i] =
>   kcalloc(MAX_MEAS, sizeof(*writer_durations[i]),
>   GFP_KERNEL);
> - if (!writer_durations[i])
> + if (!writer_durations[i]) {
> + firsterr = -ENOMEM;
>   goto unwind;
> + }
>   firsterr = torture_create_kthread(rcu_perf_writer, (void *)i,
> writer_tasks[i]);
>   if (firsterr)
> 
> 

[GIT PULL] regulator fixes for v4.7

[Mark Brown]

The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5:

  Linux 4.7-rc3 (2016-06-12 07:20:35 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
tags/regulator-fix-v4.7-rc2

for you to fetch changes up to 0d2a8ef4395e84aa9623ac1e282417c75a73490c:

  Merge remote-tracking branches 'regulator/fix/qcom-smd' and 
'regulator/fix/tps51632' into regulator-linus (2016-06-13 16:51:57 +0100)


regulator: Fixes for v4.7

Some driver specific fixes for the regulator subsystem:

 - Some of the changes to the core that were merged in the last merge
   window exposed the fact that the qcom-smd driver hadn't implemented
   the voltage enumeration interfaces like it should.  Since it's a
   simple driver specific fix to implement them do that.
 - Fix the ramp delay configuration for tps51632.

(there are two patches adding list_voltage to two different regulators
in the same driver with the same patch title).


Axel Lin (1):
  regulator: tps51632: Fix setting ramp delay

Mark Brown (1):
  Merge remote-tracking branches 'regulator/fix/qcom-smd' and 
'regulator/fix/tps51632' into regulator-linus

Srinivas Kandagatla (3):
  regulator: qcom_smd: add list_voltage callback
  regulator: qcom_smd: add regulator ops for pm8941 lnldo
  regulator: qcom_smd: add list_voltage callback

 drivers/regulator/qcom_smd-regulator.c | 15 ++-
 drivers/regulator/tps51632-regulator.c |  9 ++---
 2 files changed, 20 insertions(+), 4 deletions(-)


signature.asc
Description: PGP signature

linux-4.7-rc3/drivers/net/wireless/ath/ath9k/htc_drv_main.c: 2 * strange tests ?

[David Binderman]

Hello there,

1.

linux-4.7-rc3/drivers/net/wireless/ath/ath9k/htc_drv_main.c:798]:
(warning) Comparison of a boolean expression with an integer other
than 0 or 1.

Source code is

   if (common->ani.caldone <= 0) {

but

drivers/net/wireless/ath/ath.h:bool caldone;

Maybe better code

  if (!(common->ani.caldone)) {

2.

linux-4.7-rc3/drivers/net/wireless/ath/ath9k/htc_drv_main.c:851]:
(warning) Comparison of a boolean expression with an integer other
than 0 or 1.

   if (common->ani.caldone <= 0)

Duplicate. Also in the same file:

drivers/net/wireless/ath/ath9k/htc_drv_main.c:228]: (style) Variable
'ret' is assigned a value that is never used.

This might be a case where a function return value is not checked.

Regards

David Binderman

Re: [PATCH v3 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

[Nick Dyer]

On 02/06/2016 16:14, Nick Dyer wrote:
> On 01/06/2016 19:17, Dmitry Torokhov wrote:
>> On Wed, Jun 01, 2016 at 05:39:44PM +0100, Nick Dyer wrote:
>>> This is a series of patches to add diagnostic data support to the Atmel
>>> maXTouch driver. It's a rewrite of the previous implementation which output 
>>> via
>>> debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
>>
>> I do not have any objections other than some nits form the input side;
>> majority of the review should come from V4L2 side here...
> 
> Thanks for the review. I've hopefully fixed the issues you raised and
> pushed it to
> https://github.com/ndyer/linux/commits/diagnostic-v4l-20160602
> 
> I will wait for the V4L2 folks to comment before posting a [PATCH v4]

Hi Hans-

I've done a bit of further work on this now, so unless you have any
conerns, I'm going to post an update to the patch set in the next couple of
days.

cheers

Nick

Re: [PATCH 10/10] drm/radeon: use crtc directly in drm_crtc_vblank_put()

[Daniel Vetter]

On Tue, Jun 07, 2016 at 11:08:02AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> We don't need to use &radeon_crtc->base there as crtc is available
> in the function.
> 
> Signed-off-by: Gustavo Padovan 

All expect patch 5 merged, thanks.
-Daniel

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 2fb18f1..fb461f9 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -625,7 +625,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
>   return 0;
>  
>  vblank_cleanup:
> - drm_crtc_vblank_put(&radeon_crtc->base);
> + drm_crtc_vblank_put(crtc);
>  
>  pflip_cleanup:
>   if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) {
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

hi

[sgtmonicabrow...@gmail.com]

hello

[PATCH] sched: Do not release current rq lock on non contended double_lock_balance()

[Steven Rostedt]

Back in 2008 Gregory Haskins noticed that there was unfair locking when
dealing with double_lock_balance(). The old code (which still exists
when CONFIG_PREEMPT is disabled), on contention, will check the
ordering of the run-queue locks (by address) to determine if it should
release the current lock before taking the second lock.

if (!spin_trylock(busiest->lock)) {
if (busiest < this_rq) {
spin_unlock(&this_rq->lock);
spin_lock(&busiest->lock);
spin_lock(&this_rq->lock);
} else
spin_lock(&busiest->lock);
}

This gives unfair access for higher CPUs who are trying to take a
contended lock. For lower numbered CPUs (with lower address of their rq
structure), it wont release its lock when trying to take the next lock.
This can cause an escalation of latency in locking if there's a waiter
on the current 'this_rq->lock', which now must also wait for the
'busiest->lock' to be taken.

The solution was to simply release the current (this_rq) lock and then
take both locks.

spin_unlock(&this_rq->lock);
double_rq_lock(this_rq, busiest);

Where double_rq_lock() takes the locks in order of the rq's address.
This way, if there was a waiter on the rq lock, due to the ticket
spinlocks, it would grab the lock immediately, and the current owner
will have to wait for it now that it released the lock.

What I found while testing an 80 CPU core was a large "ping-pong"ing
around of the locks.

Let's say that an RT task on a CPU is woken up from another CPU, and
the CPU that the task was woken on is also running an RT task and tries
to push:


CPU 0   CPU 1
-   -
[ wake up ]
 spin_lock(cpu1_rq->lock);
spin_lock(cpu1_rq->lock)
double_lock_balance()
[ release cpu1_rq->lock ]
spin_lock(cpu1_rq->lock)
[due to ticket, now acquires
 cpu1_rq->lock ]

[goes to push task]
double_lock_balance()
[ release cpu1_rq->lock ]
   [ acquires lock ]
   spin_lock(cpu2_rq->lock)
   [ blocks as cpu2 is using it ]

And then CPU2 would call double_lock_balance() and the ping pong
continues.

What I could not understand about Gregory's patch is that regardless of
contention, the currently held lock is always released, opening up a
window for this ping ponging to occur. When I changed the code to only
release on contention of the second lock, things improved tremendously.

The problem that Gregory was facing was that there was an unfair access
when there was contention. But what his solution did was to always
release the lock even when there was no contention on the second lock,
which happened to cause more contention later on.

I talked with Peter Zijlstra about this, and he pointed me to the
thread where this patch was discussed back in 2008. As I read the
thread, Nick Piggin brought up this very issue. After the little
discussion, it was determined to let the waiting task have the lock
even when there was no contention to be even more "fair". The problem
though, Nick's suggestion was never tested. If it had been back then,
I'm sure that Gregory would have decided to only release the lock if
there was contention on the second lock.

Link: http://lkml.kernel.org/r/20080825201534.23217.14936.st...@dev.haskins.net

Suggested-by: Nick Piggin 
Signed-off-by: Steven Rostedt 
---
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ec2e8d23527e..3ed9ef770085 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1548,10 +1548,15 @@ static inline int _double_lock_balance(struct rq 
*this_rq, struct rq *busiest)
__acquires(busiest->lock)
__acquires(this_rq->lock)
 {
-   raw_spin_unlock(&this_rq->lock);
-   double_rq_lock(this_rq, busiest);
+   int ret = 0;
+
+   if (unlikely(!raw_spin_trylock(&busiest->lock))) {
+   raw_spin_unlock(&this_rq->lock);
+   double_rq_lock(this_rq, busiest);
+   ret = 1;
+   }
 
-   return 1;
+   return ret;
 }
 
 #else

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

[Robert Richter]

Heiko,

On 09.06.16 11:00:56, Heiko Carstens wrote:
> However I'm wondering if we shouldn't simply remove at least the s390
> specific hwswampler code from the oprofile module. This would still leave
> the common code timer based sampling mode for oprofile working on s390.
> 
> It looks like the oprofile user space utility nowadays (since 2012) uses
> the kernel perf interface instead of the oprofile interface anyway, if
> present. So the oprofile module itself doesn't seem to have too many users
> left.
> 
> Any opinions?

yes, the kernel driver is not necessary for oprofile userland for a
while now. There is no ongoing development any longer, most patches
are due to changes in the kernel apis.

So if there is code that needs a larger rework due to other kernel
changes and there is no user anymore, I am fine with removing the code
instead of reworking it. I still would just keep existing code as long
as we can keep it unchanged (some like the lightwight of oprofile,
esp. in the embedded space). If there is a user of the code, a
Tested-by would be good for new code changes.

If there are users of the hwswampler, speak up now. Else, let's just
remove it.

-Robert

Re: [PATCH v5 4/5] arm64: add support for ACPI Low Power Idle(LPI)

[Daniel Lezcano]

On Fri, Jun 10, 2016 at 01:50:28PM +0100, Lorenzo Pieralisi wrote:
> [+ Daniel, Kevin]
> 
> On Wed, May 11, 2016 at 04:37:41PM +0100, Sudeep Holla wrote:
> > This patch adds appropriate callbacks to support ACPI Low Power Idle
> > (LPI) on ARM64.
> > 
> > Cc: Lorenzo Pieralisi 
> > Cc: Mark Rutland 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Sudeep Holla 
> > ---

[ ... ]

> > +#define ACPI_FFH_LPI_ARM_FLAGS_CORE_CONTEXTBIT(0)
> > +#define ACPI_FFH_LPI_ARM_FLAGS_TRACE_CONTEXT   BIT(1)
> > +#define ACPI_FFH_LPI_ARM_FLAGS_GICR_CONTEXTBIT(2)
> > +#define ACPI_FFH_LPI_ARM_FLAGS_GICD_CONTEXTBIT(3)
> > +#define ACPI_FFH_LPI_ARM_FLAGS_ALL_CONTEXT \
> > +   (ACPI_FFH_LPI_ARM_FLAGS_CORE_CONTEXT |  \
> > +ACPI_FFH_LPI_ARM_FLAGS_TRACE_CONTEXT | \
> > +ACPI_FFH_LPI_ARM_FLAGS_GICR_CONTEXT |  \
> > +ACPI_FFH_LPI_ARM_FLAGS_GICD_CONTEXT)
> > +
> > +struct acpi_lpi_state *lpi;
> > +int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi, int idx)
> > +{
> > +   int ret = 0;
> > +   bool save_ctx = lpi->arch_flags & ACPI_FFH_LPI_ARM_FLAGS_ALL_CONTEXT;
> 
> I am not really that keen on this, as you know. Those flags are
> there to say "save these components registers". I see the CPU PM
> notifiers as a way to save/restore CPU peripheral state, but
> they should *not* carry out any action that affects the power
> state itself, that's down to the suspend finisher (eg PSCI),
> because that's where the specific idle states are managed.
> 
> I agree we have no clue whatsoever on what we *really* need
> to save/restore, but that's orthogonal to what you are solving
> here.
> 
> See eg gic_cpu_if_down(). Do we call it from the GIC CPU PM notifier ?
> No. We should not handle the same problem differently.
> 
> On top of that, we have no way to solve this problem for DT,
> all I am saying is that it is ill-defined and given that LPI
> is new I'd rather we got it right from the beginning.
> 
> I am open to suggestions here.

There is a part of the idle state flags integer which is reserved for the 
arch specific flag and can be masked with:

CPUIDLE_DRIVER_FLAGS_MASK()

May be these context flags can be added in the generic cpuidle driver and 
reused.

Concerning the DT, why not use the power domains to tell which context to 
save ? yeah, probably mentionned n-th times :)

> > +
> > +   if (!idx) {
> > +   cpu_do_idle();
> > +   return idx;
> > +   }
> > +
> > +   /* TODO cpu_pm_{enter,exit} can be done in generic code ? */
> > +   if (save_ctx)
> > +   ret = cpu_pm_enter();
> > +   if (!ret) {
> > +   /*
> > +* Pass idle state index to cpu_suspend which in turn will
> > +* call the CPU ops suspend protocol with idle index as a
> > +* parameter.
> > +*/
> > +   ret = arm_cpuidle_suspend(idx);
> > +
> > +   if (save_ctx)
> > +   cpu_pm_exit();
> > +   }
> > +
> > +   return ret ? -1 : idx;
> 
> The body of this function (if we remove save_ctx) is identical
> to arm_enter_idle_state(), it would be nice if we found a way
> where to put this code and share it with the ARM CPUidle driver,

+1

We don't want to redo another unmaintable acpi idle driver.

  -- Daniel

Re: Using irq-crossbar.c

[Marc Zyngier]

On 13/06/16 16:15, Sebastian Frias wrote:

>>> The base file he was referring to is:
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-common.dtsi
>>
>> I know which file that is, it is mentioned in the diff. I was merely
>> trying to point out the glaring mistakes that could be enough for a
>> interrupt controller hierarchy to be completely non-functional:
>>
>> - Your crossbar doesn't have a #interrupt-cells property. How do you
>>   expect the interrupt specifiers to be interpreted?
> 
> Thanks for the pointer, actually, after adding "#interrupt-cells =
> <3>;" I can see the driver getting requests for domain maps and
> xlates :-)

OK, we're getting somewhere.

>> - You've changed the default interrupt controller to be your crossbar.
>>   Which means that all the sub-nodes are inheriting it. Have you
>>   checked that this was valid for all of these nodes?
> 
> What do you mean with "valid for all these nodes"? All HW irq lines go to the 
> crossbar.

All the interrupt lines *in the system*? Or just those that are in the
nodes below the "soc" section?

Thanks,

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

Re: Using irq-crossbar.c

[Marc Zyngier]

Sebastian,

On 13/06/16 16:46, Sebastian Frias wrote:
> Hi Marc,
> 
> Thanks for your reply, please find my comments below.
> 
> On 06/10/2016 06:05 PM, Marc Zyngier wrote:
>> On 10/06/16 16:37, Sebastian Frias wrote:
>>> Hi,
>>>
>>> We are trying to write a driver for an interrupt controller (actually
>>> more of a crossbar) for an ARM-based SoC. This IRQ crossbar has 128
>>> inputs and 24 outputs, the outputs are connected directly to the
>>> GIC. The idea is that the GIC handles everything, and just request a
>>> mapping from an IRQ number (0...127, from a device's DT entry) into
>>> one of its 24 input lines.
>>
>> "Just request a mapping...".
>>
>>> By looking at current code (4.7-rc1) there seems to be a driver
>>> (drivers/irqchip/irq-crossbar.c) that provides similar
>>> functionality. The driver uses hierarchical irq domains (since commit
>>> 783d31863fb8 "irqchip: crossbar: Convert dra7 crossbar to stacked
>>> domains") which we believe we don't need because the only controller
>>> is the GIC.
>>
>> So you need it, but you don't need it? The GIC may be the only interrupt
>> controller with which software interacts when the interrupt occurs, but
>> the crossbar does play a major role in *routing* the interrupt to the
>> right GIC pin.
> 
> My understanding of "hierarchical irq domains" is that it is useful
> when there are multiple stacked interrupt controllers. Also, the
> documentation says "the majority of drivers should use the linear
> map" (as opposed to the hierarchical one).

The "linear map" to be opposed to the "tree", not to the hierarchy.
Hierarchies themselves can be built out most domain type (only the
underlying data structure changes).

> Maybe the definition of "interrupt controller" could benefit from
> some clarification, but my understanding is that, in our case, the
> GIC is the only interrupt controller (that's where the interrupt type
> must be set active_high/active_low/edge, etc.), in front of it, it
> happens to be a crossbar, that happens to be programmable, and that
> can be used to map any 128 line into any of 24 lines of the GIC
> (actually it is a many-to-many router, without any latching nor edge
> detection functionality)

An interrupt controller is absolutely *anything* that is on the
interrupt path, unless it is absolutely transparent, invisible to
software, and doesn't require any form of configuration. Your own
definition of an interrupt controller is way too restrictive.

> Obviously, when the DT says that ethernet driver uses IRQ=120 (for
> example), the crossbar must be setup to route line 120 to one of the
> 24 lines going to the GIC. So a minimum of interaction between the
> GIC driver (and/or the Linux IRQ framework) and the driver
> programming the crossbar is required, and that's what we are trying
> to achieve.
>
> Does that makes sense?

Maybe you and Mason should get together and decide what you want to
support. Because you seem to have diverging requirements (Mason
suggesting the exact opposite over the weekend).

> 
>>
>>> However the API used previously, register_routable_domain_ops(), was
>>> removed with commit a5561c3e845c "irqchip: gic: Get rid of routable
>>> domain".
>>
>> And every day, I thank $DEITY for having delivered us from this evil.
>> Really. And it wasn't much of an API. It was the son of a hack, bolted
>> on the side of another hack. Unmaintainable, getting in the way. I had
>> much fun slaughtering it! ;-)
>>
>>> Trying to use the driver with hierarchical domains (after
>>> modifications for our SoC), results on the kernel being blocked at
>>> some point:
>>>
>>> [0.041524] ThumbEE CPU extension supported.
>>> [0.041589] Registering SWP/SWPB emulation handler
>>> [0.052022] Freeing unused kernel memory: 12364K (c029b000 - c0eae000)
>>> [0.074084] random: dbus-uuidgen urandom read with 0 bits of entropy 
>>> available
>>
>> Sorry, but that's not much of a log. Anything related to interrupts, maybe?
> 
> That's the last log (it's stuck there) and I was asking how/where to enable 
> more logs to be able to debug this.
> 
> Or there are no standardised logs and every person has to come up
> with its own debug logs?

We have basic tracing in the irqdomain layer, and you can then
instrument your own driver.

>>
>>> We've put logs on the different domain_ops calls (alloc, free,
>>> translate) but they are not called, even if the DT is supposed to
>>> tell devices to take interrupts from this controller (*).
>>
>> At all? Nobody is talking to the GIC?
>>
>>> Do you have suggestions on what APIs should be used, further
>>> reading/examples and/or pointers on how debug this (logs to enable,
>>> things to look for, etc.)?
>>
>> You could start with posting actual logs of an interrupt being
>> requested, as well as perform some basic tracing of the various
>> callbacks into the irqdomain and irqchip layers, all the way down to the
>> interrupt controllers (note the plural). 
> 
> Ok, thanks.
> 
> In the meanwhile, and in cas

Re: [lkp] [sctp] d46e416c11: WARNING: CPU: 2 PID: 727 at net/ipv4/af_inet.c:685 inet_accept+0x10d/0x110

[Marcelo Ricardo Leitner]

Em 11-06-2016 22:58, kernel test robot escreveu:



FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
master
commit d46e416c11c88ef1deb5c7f19271806a5be597fe ("sctp: sctp should change socket 
state when shutdown is received")

in testcase: ltp
with following parameters: test=sctp

on test machine: nhm-white2: 8 threads Nehalem with 4G memory

caused below changes:


Hi,

Xin and I are working on a fix for this. Using SCTP_SS_CLOSING for 
sctp_sock_migrate() wasn't a good move. That's what is causing this.
Probably should have just moved to SCTP_SS_CLOSED already as the asoc is 
already closed.


Thanks,
Marcelo

Re: [PATCH v2 2/2] ARM: dts: sd_600eval: Fix eMMC lockup issue

[Srinivas Kandagatla]

On 12/06/16 05:47, Bjorn Andersson wrote:

On Fri 10 Jun 11:19 PDT 2016, Srinivas Kandagatla wrote:


From: Parth Pancholi 

This board locks up if we stress test the eMMC, as the regulator s4 is
unable to supply enough current for all the peripherials attached to it.
As this supply is wired up to most of the peripherials including DDR,
it resulted in such lockup.

This patch fixes this issue by setting s4 regulator correctly with
Auto power mode.

Reported-by: Srinivas Kandagatla 
[Srinivas Kandagatla: rewrote the change log]
Tested-by: Girish Sharma 
Signed-off-by: Parth Pancholi 


If I read the msm-3.4 tree correctly most (perhaps all) 8064 devices
should have this setup.


I agree, we should patch other boards as well with the same value.



Acked-by: Bjorn Andersson 


thanks,
srini


Regards,
Bjorn


---
  arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts 
b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
index 7df0108..39ae2bc 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
@@ -1,6 +1,7 @@
  #include "qcom-apq8064-v2.0.dtsi"
  #include "qcom-apq8064-arrow-sd-600eval-pins.dtsi"
  #include 
+#include 

  / {
model = "Arrow Electronics, APQ8064 SD_600eval";
@@ -82,7 +83,8 @@
s4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-   qcom,switch-mode-frequency = <320>;
+   qcom,switch-mode-frequency = <160>;
+   qcom,force-mode = 
;
bias-pull-down;
regulator-always-on;
};
--
2.8.3

Re: [patch 00/20] timer: Refactor the timer wheel

[Paul E. McKenney]

On Mon, Jun 13, 2016 at 08:40:50AM -, Thomas Gleixner wrote:
> The current timer wheel has some drawbacks:
> 
> 1) Cascading
> 
>Cascading can be an unbound operation and is completely pointless in most
>cases because the vast majority of the timer wheel timers are canceled or
>rearmed before expiration.
> 
> 2) No fast lookup of the next expiring timer
> 
>In NOHZ scenarios the first timer soft interrupt after a long NOHZ period
>must fast forward the base time to current jiffies. As we have no way to
>find the next expiring timer fast, the code loops and increments the base
>time by one and checks for expired timers in each step. I've observed loops
>lasting 1 ms!
> 
> There are some other issues caused by the above, but they are minor compare to
> those.

For SMP configurations, this passes light rcutorture testing.  For UP
builds, it complains about undefined symbols.  Builds succeed with
the following kneejerk patch.  Am retesting rcutorture.

Thanx, Paul



commit 87dbd35cf4034f2b664b6e9d60decd2bdbfc416f
Author: Paul E. McKenney 
Date:   Mon Jun 13 09:11:41 2016 -0700

Fix undefined get_nohz_timer_target() in non-SMP builds

Signed-off-by: Paul E. McKenney 

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e42ada26345..322e52415a29 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -348,6 +348,10 @@ extern int get_nohz_timer_target(void);
 #else
 static inline void nohz_balance_enter_idle(int cpu) { }
 static inline void set_cpu_sd_state_idle(void) { }
+static inline int get_nohz_timer_target(void)
+{
+   return raw_smp_processor_id();
+}
 #endif
 
 /*

Re: [PATCH v2 4/4] dynamic_debug: add jump label support

[Arnd Bergmann]

On Friday, June 10, 2016 11:33:07 AM CEST Jason Baron wrote:
> On 06/10/2016 05:54 AM, Arnd Bergmann wrote:
> > On Friday, May 20, 2016 5:16:36 PM CEST Jason Baron wrote:
> >> Although dynamic debug is often only used for debug builds, sometimes its
> >> enabled for production builds as well. Minimize its impact by using jump
> >> labels. This reduces the text section by 7000+ bytes in the kernel image
> >> below. It does increase data, but this should only be referenced when
> >> changing the direction of the branches, and hence usually not in cache.
> >>
> >>text data bss dec hex filename
> >> 8194852  4879776  925696 14000324 d5a0c4 vmlinux.pre
> >> 8187337  4960224  925696 14073257 d6bda9 vmlinux.post
> >>
> >> Signed-off-by: Jason Baron 
> >> ---
> > 
> > This causes problems for some of my randconfig builds, when a dynamic
> > debug call is used inside of an __exit function:
> > 
> > `.exit.text' referenced in section `__jump_table' of drivers/built-in.o: 
> > defined in discarded section `.exit.text' of drivers/built-in.o
> > `.exit.text' referenced in section `__jump_table' of drivers/built-in.o: 
> > defined in discarded section `.exit.text' of drivers/built-in.o
> > 
> 
> I stuck pr_debug() in a few functions marked with __exit, but did not
> reproduce yet. Can you share your .config and gcc --version.
> 

I found these on ARM randconfig builds e.g. this one
http://pastebin.com/raw/KjWHxnwU

I also have some other patches applied that could have interacted with your
change, so if you can't reproduce it easily, let me try it on a plain linux-next
kernel.

The compiler I use is  arm-linux-gnueabi-gcc (GCC) 6.0.0 20160323 (experimental)

Arnd

Re: [PATCH v8 02/12] kthread: Kthread worker API cleanup

[Steven Rostedt]

On Mon, 13 Jun 2016 17:13:53 +0200
Petr Mladek  wrote:

> OK, all wants to keep DEFINE stuff as is:
> 
>   DEFINE_KTHREAD_WORKER() stay
>   DEFINE_KTHREAD_WORK()   stay
>   DEFINE_KTHREAD_WORKER_ONSTACK() stay
>   DEFINE_KTHREAD_WORKER_ONSTACK() stay
> 
> 
> Nobody was against renaming the non-init functions:
> 
>   insert_kthread_work()   -> kthread_insert_work()
>   queue_kthread_work()-> kthread_queue_work()
>   flush_kthread_work()-> kthread_flush_work()
>   flush_kthread_worker()  -> kthread_flush_worker()

Yep.

> 
> 
> 
> Now, the question seem to be the init() functions.
> Andrew would prefer:
> 
>   __init_kthread_worker() -> __kthread_worker_init()
>   init_kthread_worker()   -> kthread_worker_init()
>   init_kthread_work() -> kthread_work_init()
> 
> AFAIK, Steven would prefer to keep it
> 
>   __init_kthread_worker() stay as is
>   init_kthread_worker()   stay as is
>   init_kthread_work() stay as is
> 
> I would personally prefer the way from this patch:
> 
>   __init_kthread_worker() -> __kthread_init_worker()
>   init_kthread_worker()   -> kthread_init_worker()
>   init_kthread_work() -> kthread_init_work()
> 
> 
> I have several reasons:
> 
> 1. The init functions will be used close to the other functions in
>the code. It will be easier if all functions use the same
>naming scheme. Here are some snippets:
> 
>   kthread_init_work(&w_data->balancing_work, clamp_balancing_func);
>   kthread_init_delayed_work(&w_data->idle_injection_work,
> clamp_idle_injection_func);
>   kthread_queue_work(w_data->worker, &w_data->balancing_work);
> 
>or
> 
>   kthread_init_delayed_work(&kmemleak_scan_work, kmemleak_scan_func);
>   kmemleak_scan_worker = kthread_create_worker(0, "kmemleak");
> 
> 
> 2. We are going to add kthread_destroy_worker() which would need
>to be another exception. Also this function will be used together
>with the others, for example:
> 
>   kthread_cancel_delayed_work_sync(&rb_producer_hammer_work);
>   kthread_destroy_worker(rb_producer_worker);
> 
>Also here the same naming scheme will help.
> 
> 
> 3. It is closer to the workqueues API, so it reduces confusion.

Using workqueues as an example of "reduces confusion" is not the most
convincing argument ;-)

> 
> 4. Note that there are already several precedents, for example:
> 
>   amd_iommu_init_device()
>   free_area_init_node()
>   jump_label_init_type()
>   regmap_init_mmio_clk()
> 
> 
> Andrew, Steven, are you really so strongly against my version
> of the init functions, please?
> 
> 

I don't really have that strong opinion on the "init" part. I was much
more concerned about the DEFINE/DECLARE macros.

-- Steve

Re: [PATCH 2/9] mm: implement new pkey_mprotect() system call

[Dave Hansen]

On 06/11/2016 02:47 AM, Thomas Gleixner wrote:
> On Wed, 8 Jun 2016, Dave Hansen wrote:
>> > Proposed semantics:
>> > 1. protection key 0 is special and represents the default,
>> >unassigned protection key.  It is always allocated.
>> > 2. mprotect() never affects a mapping's pkey_mprotect()-assigned
>> >protection key. A protection key of 0 (even if set explicitly)
>> >represents an unassigned protection key.
>> >2a. mprotect(PROT_EXEC) on a mapping with an assigned protection
>> >key may or may not result in a mapping with execute-only
>> >properties.  pkey_mprotect() plus pkey_set() on all threads
>> >should be used to _guarantee_ execute-only semantics.
>> > 3. mprotect(PROT_EXEC) may result in an "execute-only" mapping. The
>> >kernel will internally attempt to allocate and dedicate a
>> >protection key for the purpose of execute-only mappings.  This
>> >may not be possible in cases where there are no free protection
>> >keys available.
> Shouldn't we just reserve a protection key for PROT_EXEC unconditionally?

Normal userspace does not do PROT_EXEC today.  So, today, we'd
effectively lose one of our keys by reserving it.  Of the folks I've
talked to who really want this feature, and *will* actually use it, one
of the most common complaints is that there are too few keys.

Folks who actively *want* true PROT_EXEC semantics can use the explicit
pkey interfaces.

Re: [PATCH v4 01/44] dma-mapping: Use unsigned long for dma_attrs

[Christoph Hellwig]

On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote:
> Do we not expect the number of argument to grow ? This "cleanup" would
> do away with such possibilities, and then require adding the API later,
> and this requiring a full set of collateral evolutions again when this
> is needed. What was the original motivation for using this instead of
> the approach you are suggesting ?

We still got plenty of space for attrs.  If you're worried about running
out of 32 flags we could do a dma_attrs_t typedef that we could swich
to a u64.  That would have another advantage in that we could add a
__bitwise sparse annotation to avoid people passing the wrong kind of
flags.

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Jeffrey Hugo]

On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote:

On 2016-06-13 10:29, Gabriele Paoloni wrote:

Hi Sinan


-Original Message-
From: Sinan Kaya [mailto:ok...@codeaurora.org]
Sent: 13 June 2016 15:03
To: Gabriele Paoloni; liudongdong (C); helg...@kernel.org;
a...@arndb.de; will.dea...@arm.com; catalin.mari...@arm.com;
raf...@kernel.org; hanjun@linaro.org; lorenzo.pieral...@arm.com;
jchan...@broadcom.com; t...@semihalf.com
Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing;
suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org;
dhd...@apm.com; jeremy.lin...@arm.com; c...@codeaurora.org; Chenxin
(Charles); Linuxarm
Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
accessors against platfrom specific ECAM quirks

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
>
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
>
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW
update.
>
> Can these vendors confirm this?
>
> Tomasz do you think this can work for Cavium Thunder?
>
> Thanks
>
> Gab

Why not have all three of them?

The initial approach was OEM id and revision id.

Jeff Hugo indicated that addition (not removing any other fields) of
table id
would make more sense.


Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
PCI config space accessors against platfrom specific ECAM quirks."

I quote:

 "Using the OEM revision
 field does not seem to be appropriate since these are different
 platforms and the revision field appears to be for the purpose of
 tracking differences within a single platform.  Therefore, Cov is
 proposing using the OEM table id as a mechanism to distinguish
 platform A (needs quirk applied) vs platform B (no quirks) from the
 same OEM."

So it looks to me that he pointed out that using the OEM revision field
is wrong...and this is why I have asked if replacing it with the table
id can work for other vendors

Thanks

Gab



I had an internal discussion with jeff and cov before posting on the
maillist.

I think there is missing info in the email.

Usage of oem id + table id + revision is ok.

Usage of oem id + revision is not ok as one oem can build multiple chips
with the same oem id and revision id but different table id. Otherwise,
we can run out of revisions very quickly.


Agreed.

I'm sorry for the confusion.  My intent was to point out that revision 
alone appeared insufficient to address all the identified problems, but 
I believe there is still a case for using revision. Table id is useful 
for differentiating between platforms/chips.  Revision is useful for 
differentiation between different versions of a single platform/chip 
assuming the silicon is respun or some other fix is applied.  Both solve 
different scenarios, and I'm not aware of a reason why they could not be 
used together to solve all currently identified cases.








--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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



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

Re: [PATCH v3 2/3] x86/platform/p2sb: New Primary to Sideband bridge support driver for Intel SOC's

[Mika Westerberg]

On Mon, Jun 13, 2016 at 06:19:12PM +0300, Andy Shevchenko wrote:
> On Mon, 2016-06-13 at 17:25 +0300, Mika Westerberg wrote:
> > On Mon, Jun 13, 2016 at 04:54:31PM +0300, Andy Shevchenko wrote:
> > > Would work to me, though still the same question: is it possible to
> > > avoid building it on even most of Intel platforms, since there, I
> > > assume, will be not many users of the module?
> > 
> > Well, even if you make it configurable via Kconfig, I guess distros
> > will
> > have to enable it in order to support as wide range of CPUs as
> > possible
> > in a single binary.
> 
> Good point.
> 
> Then perhaps the following we can do:
>  - add a static boolean flag
>  - add __init function where we check either PCI root bridge ID or CPU
> ID (I don't know which one is better, I suppose second one, though it
> will require an update of arch/x86/include/asm/intel-family.h)
>  - add a check into the function.
> 
> What do you think?

Maybe, or make it modular and use MODULE_DEVICE_TABLE(x86cpu, ...) to
match the corresponding CPUs.

Re: Using irq-crossbar.c

[Marc Zyngier]

On 13/06/16 16:49, Mason wrote:
> On 13/06/2016 17:42, Lennart Sorensen wrote:
>> On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
>>> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to 
>>> the GIC.
>>> The HW block is a many-to-many router.
>>> There are 128 32bit registers which specify, for each of the corresponding 
>>> 128 inputs, to which of the 24 outputs it would be routed to.
>>>
>>> There are 4 32bit registers that can show the RAW status of the 128 inputs, 
>>> but they do not latch on the inputs.
>>> That's why our understanding is that on Linux terms it is not an interrupt 
>>> controller, but just a many-to-many mux, the only real interrupt-controller 
>>> (where one can set if the line is active high or low for example) is the 
>>> GIC.
>>
>> Well that does just sound like a mux.  But that does mean you either
>> can't use more than 24 inputs at once, or you will be sharing interrupts.
>>
>> I really hate shared interrupts so I would never design something that
>> way, but it is simpler.
> 
> If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.

Up to 224 SPIs actually, plus 16 PPIs.

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

Re: [very-RFC 0/8] TSN driver for the kernel

[John Fastabend]

On 16-06-13 04:47 AM, Richard Cochran wrote:
> Henrik,
> 
> On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote:
>> There are at least one AVB-driver (the AV-part of TSN) in the kernel
>> already,
> 
> Which driver is that?
> 
>> however this driver aims to solve a wider scope as TSN can do
>> much more than just audio. A very basic ALSA-driver is added to the end
>> that allows you to play music between 2 machines using aplay in one end
>> and arecord | aplay on the other (some fiddling required) We have plans
>> for doing the same for v4l2 eventually (but there are other fishes to
>> fry first). The same goes for a TSN_SOCK type approach as well.
> 
> Please, no new socket type for this.
>  
>> What remains
>> - tie to (g)PTP properly, currently using ktime_get() for presentation
>>   time
>> - get time from shim into TSN and vice versa
> 
> ... and a whole lot more, see below.
> 
>> - let shim create/manage buffer
> 
> (BTW, shim is a terrible name for that.)
> 
> [sigh]
> 
> People have been asking me about TSN and Linux, and we've made some
> thoughts about it.  The interest is there, and so I am glad to see
> discussion on this topic.
> 
> Having said that, your series does not even begin to address the real
> issues.  I did not review the patches too carefully (because the
> important stuff is missing), but surely configfs is the wrong
> interface for this.  In the end, we will be able to support TSN using
> the existing networking and audio interfaces, adding appropriate
> extensions.
> 
> Your patch features a buffer shared by networking and audio.  This
> isn't strictly necessary for TSN, and it may be harmful.  The
> Listeners are supposed to calculate the delay from frame reception to
> the DA conversion.  They can easily include the time needed for a user
> space program to parse the frames, copy (and combine/convert) the
> data, and re-start the audio transfer.  A flexible TSN implementation
> will leave all of the format and encoding task to the userland.  After
> all, TSN will some include more that just AV data, as you know.
> 
> Lets take a look at the big picture.  One aspect of TSN is already
> fully supported, namely the gPTP.  Using the linuxptp user stack and a
> modern kernel, you have a complete 802.1AS-2011 solution.
> 
> Here is what is missing to support audio TSN:
> 
> * User Space
> 
> 1. A proper userland stack for AVDECC, MAAP, FQTSS, and so on.  The
>OpenAVB project does not offer much beyond simple examples.
> 
> 2. A user space audio application that puts it all together, making
>use of the services in #1, the linuxptp gPTP service, the ALSA
>services, and the network connections.  This program will have all
>the knowledge about packet formats, AV encodings, and the local HW
>capabilities.  This program cannot yet be written, as we still need
>some kernel work in the audio and networking subsystems.
> 
> * Kernel Space
> 
> 1. Providing frames with a future transmit time.  For normal sockets,
>this can be in the CMESG data.  For mmap'ed buffers, we will need a
>new format.  (I think Arnd is working on a new layout.)
> 
> 2. Time based qdisc for transmitted frames.  For MACs that support
>this (like the i210), we only have to place the frame into the
>correct queue.  For normal HW, we want to be able to reserve a time
>window in which non-TSN frames are blocked.  This is some work, but
>in the end it should be a generic solution that not only works
>"perfectly" with TSN HW but also provides best effort service using
>any NIC.
> 

When I looked at this awhile ago I convinced myself that it could fit
fairly well into the DCB stack (DCB is also part of 802.1Q). A lot of
the traffic class to queue mappings and priories could be handled here.
It might be worth taking a look at ./net/sched/mqprio.c and ./net/dcb/.

Unfortunately I didn't get too far along but we probably don't want
another mechanism to map hw queues/tcs/etc if the existing interfaces
work or can be extended to support this.

> 3. ALSA support for tunable AD/DA clocks.  The rate of the Listener's
>DA clock must match that of the Talker and the other Listeners.
>Either you adjust it in HW using a VCO or similar, or you do
>adaptive sample rate conversion in the application. (And that is
>another reason for *not* having a shared kernel buffer.)  For the
>Talker, either you adjust the AD clock to match the PTP time, or
>you measure the frequency offset.
> 
> 4. ALSA support for time triggered playback.  The patch series
>completely ignore the critical issue of media clock recovery.  The
>Listener must buffer the stream in order to play it exactly at a
>specified time.  It cannot simply send the stream ASAP to the audio
>HW, because some other Listener might need longer.  AFAICT, there
>is nothing in ALSA that allows you to say, sample X should be
>played at time Y.
> 
> These are some ideas about impleme

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

[Liviu . Dudau]

On Mon, Jun 13, 2016 at 11:40:05AM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote:
> > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code
> > > should include ACPI specific callbacks that parse and set-up the
> > > device IRQ number, equivalent to the DT boot path. Owing to the current
> > > ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings
> > > cannot be parsed at device add time, since that would trigger ACPI scan
> > > handlers ordering issues depending on how the ACPI tables are defined.
> > 
> > Uh, OK :)  I can't figure out exactly what the problem is here -- I
> > don't know where to look if I wanted to fix the scan handler ordering
> > issues, and I don't know how I could tell if it would ever be safe to
> > move this from driver probe-time back to device add-time.
> 
> Right, the commit log could have been more informative.
> 
> pcibios_add_device() was added in:
> 
> commit d1e6dc91b532 ("arm64: Add architectural support for PCI")
> 
> whose commit log does not specify why legacy IRQ parsing should
> be done at pcibios_add_device() either, so honestly we had to
> do with the information we have at hand.

Because at that time (September 2014) there was no pcibios_alloc_irq() (added
June 2015 by commit 890e4847587fcf) and after that nobody bothered to update
the arm64 code to make use of the new API.

Best regards,
Liviu

> 
> > I also notice that x86 and ia64 call acpi_pci_irq_enable() even later,
> > when the driver *enables* the device.  Is there a reason you didn't do
> > it at the same time as x86 and ia64?  This is another of those pcibios
> > hooks that really don't do anything arch-specific, so I can imagine
> > refactoring this somehow, someday.
> 
> Yes, with [1], that was the goal, that stopped because [1] does not
> work on x86.
> 
> Only DT platform(s) affected by this change are all platforms relying on
> drivers/pci/host/pci-xgene.c (others rely on pci_fixup_irqs() that
> should be removed too), if on those platforms probing IRQs at device
> enable time works ok I can update this patch (it can be done through [1]
> once we figure out what to do with it on x86) and move the IRQ set-up at
> pcibios_enable_device() time.
> 
> @Duc: any feedback on this ?
> 
> Thanks,
> Lorenzo
> 
> [1] http://www.spinics.net/lists/linux-pci/msg45950.html
> 
> > Did we have this conversation before?  It seems vaguely familiar, so I
> > apologize if you already explained this once.
> > 
> > > To solve this problem and consolidate FW PCI legacy IRQs parsing in
> > > one single pcibios callback (pending final removal), this patch moves
> > > DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by
> > > PCI core code at device probe time) and adds ACPI PCI legacy IRQs
> > > parsing to the same callback too, so that FW PCI legacy IRQs parsing
> > > is confined in one single arch callback that can be easily removed
> > > when code parsing PCI legacy IRQs is consolidated and moved to core
> > > PCI code.
> > > 
> > > Signed-off-by: Tomasz Nowicki 
> > > Suggested-by: Lorenzo Pieralisi 
> > > ---
> > >  arch/arm64/kernel/pci.c | 11 ---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > index d5d3d26..b3b8a2c 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -51,11 +51,16 @@ int pcibios_enable_device(struct pci_dev *dev, int 
> > > mask)
> > >  }
> > >  
> > >  /*
> > > - * Try to assign the IRQ number from DT when adding a new device
> > > + * Try to assign the IRQ number when probing a new device
> > >   */
> > > -int pcibios_add_device(struct pci_dev *dev)
> > > +int pcibios_alloc_irq(struct pci_dev *dev)
> > >  {
> > > - dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > + if (acpi_disabled)
> > > + dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +#ifdef CONFIG_ACPI
> > > + else
> > > + return acpi_pci_irq_enable(dev);
> > > +#endif
> > >  
> > >   return 0;
> > >  }
> > > -- 
> > > 1.9.1
> > > 
> > 
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH 10/10] mm: balance LRU lists based on relative thrashing

[Johannes Weiner]

On Fri, Jun 10, 2016 at 11:19:35AM +0900, Minchan Kim wrote:
> On Mon, Jun 06, 2016 at 03:48:36PM -0400, Johannes Weiner wrote:
> > @@ -79,6 +79,7 @@ enum pageflags {
> > PG_dirty,
> > PG_lru,
> > PG_active,
> > +   PG_workingset,
> 
> I think PG_workingset might be a good flag in the future, core MM might
> utilize it to optimize something so I hope it supports for 32bit, too.
> 
> A usecase with PG_workingset in old was cleancache. A few year ago,
> Dan tried it to only cache activated page from page cache to cleancache,
> IIRC. As well, many system using zram(i.e., fast swap) are still 32 bit
> architecture.
> 
> Just an idea. we might be able to move less important flag(i.e., enabled
> in specific configuration, for example, PG_hwpoison or PG_uncached) in 32bit
> to page_extra to avoid allocate extra memory space and charge the bit as
> PG_workingset. :)

Yeah, I do think it should be a core flag. We have the space for it.

> Other concern about PG_workingset is naming. For file-backed pages, it's
> good because file-backed pages started from inactive's head and promoted
> active LRU once two touch so it's likely to be workingset. However,
> for anonymous page, it starts from active list so every anonymous page
> has PG_workingset while mlocked pages cannot have a chance to have it.
> It wouldn't matter in eclaim POV but if we would use PG_workingset as
> indicator to identify real workingset page, it might be confused.
> Maybe, We could mark mlocked pages as workingset unconditionally.

Hm I'm not sure it matters. Technically we don't have to set it on
anon, but since it's otherwise unused anyway, it's nice to set it to
reinforce the notion that anon is currently always workingset.

> > @@ -544,6 +544,8 @@ void migrate_page_copy(struct page *newpage, struct 
> > page *page)
> > SetPageActive(newpage);
> > } else if (TestClearPageUnevictable(page))
> > SetPageUnevictable(newpage);
> > +   if (PageWorkingset(page))
> > +   SetPageWorkingset(newpage);
> 
> When I see this, popped thought is how we handle PG_workingset
> when split/collapsing THP and then, I can't find any logic. :(
> Every anonymous page is PG_workingset by birth so you ignore it
> intentionally?

Good catch. __split_huge_page_tail() should copy it over, will fix that.

> > @@ -1809,6 +1811,8 @@ fail_putback:
> > mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> >  
> > /* Reverse changes made by migrate_page_copy() */
> > +   if (TestClearPageWorkingset(new_page))
> > +   ClearPageWorkingset(page);
> > if (TestClearPageActive(new_page))
> > SetPageActive(page);
> > if (TestClearPageUnevictable(new_page))
> > diff --git a/mm/swap.c b/mm/swap.c
> > index ae07b469ddca..cb6773e1424e 100644
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -249,8 +249,28 @@ void rotate_reclaimable_page(struct page *page)
> > }
> >  }
> >  
> > -void lru_note_cost(struct lruvec *lruvec, bool file, unsigned int nr_pages)
> > +void lru_note_cost(struct lruvec *lruvec, enum lru_cost_type cost,
> > +  bool file, unsigned int nr_pages)
> >  {
> > +   if (cost == COST_IO) {
> > +   /*
> > +* Reflect the relative reclaim cost between incurring
> > +* IO from refaults on one hand, and incurring CPU
> > +* cost from rotating scanned pages on the other.
> > +*
> > +* XXX: For now, the relative cost factor for IO is
> > +* set statically to outweigh the cost of rotating
> > +* referenced pages. This might change with ultra-fast
> > +* IO devices, or with secondary memory devices that
> > +* allow users continued access of swapped out pages.
> > +*
> > +* Until then, the value is chosen simply such that we
> > +* balance for IO cost first and optimize for CPU only
> > +* once the thrashing subsides.
> > +*/
> > +   nr_pages *= SWAP_CLUSTER_MAX;
> > +   }
> > +
> > lruvec->balance.numer[file] += nr_pages;
> > lruvec->balance.denom += nr_pages;
> 
> So, lru_cost_type is binary. COST_IO and COST_CPU. 'bool' is enough to
> represent it if you doesn't have further plan to expand it.
> But if you did to make it readable, I'm not against. Just trivial.

Yeah, it's meant for readability. "true" and "false" make for fairly
cryptic arguments when they are a static property of the callsite:

  lru_note_cost(lruvec, false, page_is_file_cache(page), hpage_nr_pages(page))

???

So I'd rather name these things and leave bool for things that are
based on predicate functions.

> > @@ -821,13 +842,28 @@ void lru_add_page_tail(struct page *page, struct page 
> > *page_tail,
> >  static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
> >  void *arg)
> >  {
> > +   unsigned int nr_pages = hpag

Re: [PATCH] ARM: bcm2835: remove unused __packet

[Arnd Bergmann]

On Tuesday, June 7, 2016 6:49:33 PM CEST Ben Dooks wrote:
> The driver defines a variable called __packet but then never
> uses it, and does not export it for others to use either. Fix
> the warning about undeclared variable by removing it.
> 
> drivers/soc/bcm/raspberrypi-power.c:48:3: warning: symbol '__packet' was not 
> declared. Should it be static?
> 
> Signed-off-by: Ben Dooks 
> ---

The patch looks good, but it's probably worth mentioning here that
this was intended to be the '__packed' attribute instead of a local
variable. The attribute is useless here, as the variables both
still get the default stack alignment, even if rpi_firmware_property
only requires byte-aligned data.

Arnd

> diff --git a/drivers/soc/bcm/raspberrypi-power.c 
> b/drivers/soc/bcm/raspberrypi-power.c
> index fe96a8b..f7ed118 100644
> --- a/drivers/soc/bcm/raspberrypi-power.c
> +++ b/drivers/soc/bcm/raspberrypi-power.c
> @@ -45,7 +45,7 @@ struct rpi_power_domains {
>  struct rpi_power_domain_packet {
> u32 domain;
> u32 on;
> -} __packet;
> +};
> 

[PATCH 3/7] random: add interrupt callback to VMBus IRQ handler

[Theodore Ts'o]

From: Stephan Mueller 

The Hyper-V Linux Integration Services use the VMBus implementation for
communication with the Hypervisor. VMBus registers its own interrupt
handler that completely bypasses the common Linux interrupt handling.
This implies that the interrupt entropy collector is not triggered.

This patch adds the interrupt entropy collection callback into the VMBus
interrupt handler function.

Cc: sta...@kernel.org
Signed-off-by: Stephan Mueller 
Signed-off-by: Stephan Mueller 
Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c  | 1 +
 drivers/hv/vmbus_drv.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 74596d3..64e35a4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -946,6 +946,7 @@ void add_interrupt_randomness(int irq, int irq_flags)
/* award one bit for the contents of the fast pool */
credit_entropy_bits(r, credit + 1);
 }
+EXPORT_SYMBOL_GPL(add_interrupt_randomness);
 
 #ifdef CONFIG_BLOCK
 void add_disk_randomness(struct gendisk *disk)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 952f20f..e82f7e1 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "hyperv_vmbus.h"
 
 static struct acpi_device  *hv_acpi_dev;
@@ -806,6 +807,8 @@ static void vmbus_isr(void)
else
tasklet_schedule(hv_context.msg_dpc[cpu]);
}
+
+   add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0);
 }
 
 
-- 
2.5.0

[PATCH 2/7] random: print a warning for the first ten uninitialized random users

[Theodore Ts'o]

Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot.  So print the first ten such
complaints instead.

Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 4e2627a..74596d3 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1458,12 +1458,16 @@ random_read(struct file *file, char __user *buf, size_t 
nbytes, loff_t *ppos)
 static ssize_t
 urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 {
+   static int maxwarn = 10;
int ret;
 
-   if (unlikely(nonblocking_pool.initialized == 0))
-   printk_once(KERN_NOTICE "random: %s urandom read "
-   "with %d bits of entropy available\n",
-   current->comm, nonblocking_pool.entropy_total);
+   if (unlikely(nonblocking_pool.initialized == 0) &&
+   maxwarn > 0) {
+   maxwarn--;
+   printk(KERN_NOTICE "random: %s: uninitialized urandom read "
+  "(%d bytes read, %d bits of entropy available)\n",
+  current->comm, nbytes, nonblocking_pool.entropy_total);
+   }
 
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
ret = extract_entropy_user(&nonblocking_pool, buf, nbytes);
-- 
2.5.0

[PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs

[Theodore Ts'o]

On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock.  The application should have used its own
PRNG, but let's try to help it from running, lemming-like, straight
over the locking cliff.

Reported-by: Andi Kleen 
Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c | 62 +++
 1 file changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 841f9a8..d640865 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -434,6 +434,8 @@ struct crng_state primary_crng = {
  */
 static int crng_init = 0;
 #define crng_ready() (likely(crng_init > 0))
+static void _extract_crng(struct crng_state *crng,
+ __u8 out[CHACHA20_BLOCK_SIZE]);
 static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE]);
 static void process_random_ready_list(void);
 
@@ -754,6 +756,16 @@ static void credit_entropy_bits_safe(struct entropy_store 
*r, int nbits)
 
 static DECLARE_WAIT_QUEUE_HEAD(crng_init_wait);
 
+#ifdef CONFIG_NUMA
+/*
+ * Hack to deal with crazy userspace progams when they are all trying
+ * to access /dev/urandom in parallel.  The programs are almost
+ * certainly doing something terribly wrong, but we'll work around
+ * their brain damage.
+ */
+static struct crng_state **crng_node_pool __read_mostly;
+#endif
+
 static void crng_initialize(struct crng_state *crng)
 {
int i;
@@ -815,7 +827,7 @@ static void crng_reseed(struct crng_state *crng, struct 
entropy_store *r)
if (num == 0)
return;
} else
-   extract_crng(buf.block);
+   _extract_crng(&primary_crng, buf.block);
spin_lock_irqsave(&primary_crng.lock, flags);
for (i = 0; i < 8; i++) {
unsigned long   rv;
@@ -835,19 +847,26 @@ static void crng_reseed(struct crng_state *crng, struct 
entropy_store *r)
spin_unlock_irqrestore(&primary_crng.lock, flags);
 }
 
+static inline void maybe_reseed_primary_crng(void)
+{
+   if (crng_init > 2 &&
+   time_after(jiffies, primary_crng.init_time + CRNG_RESEED_INTERVAL))
+   crng_reseed(&primary_crng, &input_pool);
+}
+
 static inline void crng_wait_ready(void)
 {
wait_event_interruptible(crng_init_wait, crng_ready());
 }
 
-static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE])
+static void _extract_crng(struct crng_state *crng,
+ __u8 out[CHACHA20_BLOCK_SIZE])
 {
unsigned long v, flags;
-   struct crng_state *crng = &primary_crng;
 
if (crng_init > 1 &&
time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL))
-   crng_reseed(crng, &input_pool);
+   crng_reseed(crng, crng == &primary_crng ? &input_pool : NULL);
spin_lock_irqsave(&crng->lock, flags);
if (arch_get_random_long(&v))
crng->state[14] ^= v;
@@ -857,6 +876,19 @@ static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE])
spin_unlock_irqrestore(&crng->lock, flags);
 }
 
+static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE])
+{
+   struct crng_state *crng = NULL;
+
+#ifdef CONFIG_NUMA
+   if (crng_node_pool)
+   crng = crng_node_pool[numa_node_id()];
+   if (crng == NULL)
+#endif
+   crng = &primary_crng;
+   _extract_crng(crng, out);
+}
+
 static ssize_t extract_crng_user(void __user *buf, size_t nbytes)
 {
ssize_t ret = 0, i;
@@ -1575,9 +1607,31 @@ static void init_std_data(struct entropy_store *r)
  */
 static int rand_initialize(void)
 {
+#ifdef CONFIG_NUMA
+   int i;
+   int num_nodes = num_possible_nodes();
+   struct crng_state *crng;
+   struct crng_state **pool;
+#endif
+
init_std_data(&input_pool);
init_std_data(&blocking_pool);
crng_initialize(&primary_crng);
+
+#ifdef CONFIG_NUMA
+   pool = kmalloc(num_nodes * sizeof(void *),
+  GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
+   for (i=0; i < num_nodes; i++) {
+   crng = kmalloc_node(sizeof(struct crng_state),
+   GFP_KERNEL | __GFP_NOFAIL, i);
+   spin_lock_init(&crng->lock);
+   crng_initialize(crng);
+   pool[i] = crng;
+
+   }
+   mb();
+   crng_node_pool = pool;
+#endif
return 0;
 }
 early_initcall(rand_initialize);
-- 
2.5.0

[PATCH 4/7] random: properly align get_random_int_hash

[Theodore Ts'o]

From: Eric Biggers 

get_random_long() reads from the get_random_int_hash array using an
unsigned long pointer.  For this code to be guaranteed correct on all
architectures, the array must be aligned to an unsigned long boundary.

Cc: sta...@kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 64e35a4..83f5cd0 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1778,13 +1778,15 @@ int random_int_secret_init(void)
return 0;
 }
 
+static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash)
+   __aligned(sizeof(unsigned long));
+
 /*
  * Get a random word for internal kernel use only. Similar to urandom but
  * with the goal of minimal entropy pool depletion. As a result, the random
  * value is not cryptographically secure but for several uses the cost of
  * depleting entropy is too high
  */
-static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
 unsigned int get_random_int(void)
 {
__u32 *hash;
-- 
2.5.0

Re: Using irq-crossbar.c

[Mason]

On 13/06/2016 17:42, Lennart Sorensen wrote:
> On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
>> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to 
>> the GIC.
>> The HW block is a many-to-many router.
>> There are 128 32bit registers which specify, for each of the corresponding 
>> 128 inputs, to which of the 24 outputs it would be routed to.
>>
>> There are 4 32bit registers that can show the RAW status of the 128 inputs, 
>> but they do not latch on the inputs.
>> That's why our understanding is that on Linux terms it is not an interrupt 
>> controller, but just a many-to-many mux, the only real interrupt-controller 
>> (where one can set if the line is active high or low for example) is the GIC.
> 
> Well that does just sound like a mux.  But that does mean you either
> can't use more than 24 inputs at once, or you will be sharing interrupts.
> 
> I really hate shared interrupts so I would never design something that
> way, but it is simpler.

If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.

So any SoC with more than 32 devices capable of generating IRQs
would have to share interrupts, right?

Regards.

[GIT PULL] drm/arcpgu: Make ARC PGU usable on sim platforms

[Alexey Brodkin]

Hi Dave,

Please pull this mini-series that allows ARC PGU to be used on simulation
platforms like nSIM OSCI (AKA Linux Virtual Platform) or ARC VDK.

The series was published for review here
https://lists.freedesktop.org/archives/dri-devel/2016-June/110647.html

It is based on today's "drm-next" branch.

Best regards,
Alexey

The following changes since commit 3c85f20a289d044f303f473ee6ab7502303fc3b0:

  Merge tag 'omapdrm-4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
(2016-06-09
12:20:11 +1000)

are available in the git repository at:

  https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
topic-arcpgu-sim

for you to fetch changes up to 830c6578481e3b8649261062dfc5b0ac3c9374f8:

  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms (2016-06-13 
17:45:18 +0200)


Alexey Brodkin (2):
  ARCv2: [vdk] Enable ARC PGU on HS38 VDK
  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

Ruud Derwig (1):
  drm/arcpgu: Make ARC PGU usable on simulation platforms

 arch/arc/boot/dts/nsimosci.dts |  14 +++---
 arch/arc/boot/dts/nsimosci_hs.dts  |  14 +++---
 arch/arc/boot/dts/nsimosci_hs_idu.dts  |  14 +++---
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi   |  13 +
 arch/arc/boot/dts/vdk_hs38_smp.dts |   2 +-
 arch/arc/configs/nsimosci_defconfig|   3 ++-
 arch/arc/configs/nsimosci_hs_defconfig |   3 ++-
 arch/arc/configs/nsimosci_hs_smp_defconfig |   3 ++-
 arch/arc/configs/vdk_hs38_smp_defconfig|   7 ++-
 drivers/gpu/drm/arc/Makefile   |   2 +-
 drivers/gpu/drm/arc/arcpgu.h   |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c   |  15 ---
 drivers/gpu/drm/arc/arcpgu_sim.c   | 128


 13 files changed, 189 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c

[PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

[Theodore Ts'o]

The CRNG is faster, and we don't pretend to track entropy usage in the
CRNG any more.

Signed-off-by: Theodore Ts'o 
---
 crypto/chacha20_generic.c |  61 
 drivers/char/random.c | 374 +-
 include/crypto/chacha20.h |   1 +
 lib/Makefile  |   2 +-
 lib/chacha20.c|  79 ++
 5 files changed, 353 insertions(+), 164 deletions(-)
 create mode 100644 lib/chacha20.c

diff --git a/crypto/chacha20_generic.c b/crypto/chacha20_generic.c
index da9c899..1cab831 100644
--- a/crypto/chacha20_generic.c
+++ b/crypto/chacha20_generic.c
@@ -15,72 +15,11 @@
 #include 
 #include 
 
-static inline u32 rotl32(u32 v, u8 n)
-{
-   return (v << n) | (v >> (sizeof(v) * 8 - n));
-}
-
 static inline u32 le32_to_cpuvp(const void *p)
 {
return le32_to_cpup(p);
 }
 
-static void chacha20_block(u32 *state, void *stream)
-{
-   u32 x[16], *out = stream;
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(x); i++)
-   x[i] = state[i];
-
-   for (i = 0; i < 20; i += 2) {
-   x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],  16);
-   x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],  16);
-   x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],  16);
-   x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],  16);
-
-   x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],  12);
-   x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],  12);
-   x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10], 12);
-   x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11], 12);
-
-   x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],   8);
-   x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],   8);
-   x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],   8);
-   x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],   8);
-
-   x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],   7);
-   x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],   7);
-   x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10],  7);
-   x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11],  7);
-
-   x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],  16);
-   x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],  16);
-   x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],  16);
-   x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],  16);
-
-   x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10], 12);
-   x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11], 12);
-   x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],  12);
-   x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],  12);
-
-   x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],   8);
-   x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],   8);
-   x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],   8);
-   x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],   8);
-
-   x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10],  7);
-   x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11],  7);
-   x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],   7);
-   x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],   7);
-   }
-
-   for (i = 0; i < ARRAY_SIZE(x); i++)
-   out[i] = cpu_to_le32(x[i] + state[i]);
-
-   state[12]++;
-}
-
 static void chacha20_docrypt(u32 *state, u8 *dst, const u8 *src,
 unsigned int bytes)
 {
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 83f5cd0..841f9a8 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -261,6 +261,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -413,6 +414,29 @@ static struct fasync_struct *fasync;
 static DEFINE_SPINLOCK(random_ready_list_lock);
 static LIST_HEAD(random_ready_list);
 
+struct crng_state {
+   __u32   state[16];
+   unsigned long   init_time;
+   spinlock_t  lock;
+};
+
+struct crng_state primary_crng = {
+   .lock = __SPIN_LOCK_UNLOCKED(primary_crng.lock),
+};
+
+/*
+ * crng_init =  0 --> Uninitialized
+ * 1 --> Initialized
+ * 2 --> Initialized from input_pool
+ *
+ * crng_init is protected by primary_crng->lock, and only increases
+ * its value (from 0->1->2).
+ */
+static int crng_init = 0;
+#define crng_ready() (likely(crng_init > 0))
+static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE]);
+static void process_random_ready_list(void);
+
 /**
  *
  * OS independent entropy store.   Here are the functions which handle
@@ -442,10 +466,15 @@ struct entropy_store {
__u8 last_data[EXTRACT_SIZE];
 };
 
+static ssize_t extract_entropy(struct entropy_store *r, void *buf,
+  size_t nbytes, int min, int rsvd);
+static ssize_t _extract_entropy(struct entropy_store *r, void 

[PATCH-v4 0/7] random: replace urandom pool with a CRNG

[Theodore Ts'o]

I plan to push this set of changes in the next merge window.  Last
call for comments

By using a CRNG to replace the urandom pool, we can more quickly
initialized the random number generator used for getrandom(2) and
/dev/urandom.  On bare metal hardware this tends to get initialized
before the devices are finished being probed.  We use a more
aggressive accounting for entropy accounting initially, and then fall
back to the original slower/more conservative entropy accounting
scheme.

We will also use a hardware rng (such as virtio-rng), if available to
initialize the getrandom(2) / /dev/urandom entropy pool.

In addition, on NUMA systems we make the CRNG state per-NUMA socket, to
address the NUMA locking contention problem which Andi Kleen has been
complaining about.  I'm not entirely sure this will work well on the
crazy big SGI systems, but they are rare.  Whether they are rarer than
abusive userspace programs that are continuously pounding /dev/urandom
is unclear.  If necessary we can make a config option to turn off the
per-NUMA socket hack if it proves to be problematic.

Eric Biggers (1):
  random: properly align get_random_int_hash

Stephan Mueller (1):
  random: add interrupt callback to VMBus IRQ handler

Theodore Ts'o (5):
  random: initialize the non-blocking pool via
add_hwgenerator_randomness()
  random: print a warning for the first ten uninitialized random users
  random: replace non-blocking pool with a Chacha20-based CRNG
  random: make /dev/urandom scalable for silly userspace programs
  random: add backtracking protection to the CRNG

Changes since -v3:
 * Use a hardware rng (e.g., virtio-rng) if possible to initialize the
   getrandom/urandom pool if available
 * Print up to 10 warnings for uninitialized /dev/urandom reads, not just one
 * Back out experiment to block /dev/urandom reads, since this will
   break too many distributions or other user space setups (including
   Python 3.5.2 and Debian Stretch's systemd-crontab-generator)
 * Mark bug fixes for stable kernel backports

Changes since -v2:
  * Rebased to v4.7-rc1
  * Improved/reworked CRNG reseeding and backtracking protection
  * Preseed the CRNG state from system data
  * Added fix to properly align the get_random_int_hash[] array

 crypto/chacha20_generic.c |  61 --
 drivers/char/random.c | 465 +-
 drivers/hv/vmbus_drv.c|   3 +
 include/crypto/chacha20.h |   1 +
 lib/Makefile  |   2 +-
 lib/chacha20.c|  79 
 6 files changed, 457 insertions(+), 154 deletions(-)
 create mode 100644 lib/chacha20.c

git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git  1d6e2eda6f60

-- 
2.5.0

[PATCH 1/7] random: initialize the non-blocking pool via add_hwgenerator_randomness()

[Theodore Ts'o]

If we have a hardware RNG and are using the in-kernel rngd, we should
use this to initialize the non-blocking pool so that getrandom(2)
doesn't block unnecessarily.

Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0158d3b..4e2627a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1849,12 +1849,18 @@ void add_hwgenerator_randomness(const char *buffer, 
size_t count,
 {
struct entropy_store *poolp = &input_pool;
 
-   /* Suspend writing if we're above the trickle threshold.
-* We'll be woken up again once below random_write_wakeup_thresh,
-* or when the calling thread is about to terminate.
-*/
-   wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+   if (unlikely(nonblocking_pool.initialized == 0))
+   poolp = &nonblocking_pool;
+   else {
+   /* Suspend writing if we're above the trickle
+* threshold.  We'll be woken up again once below
+* random_write_wakeup_thresh, or when the calling
+* thread is about to terminate.
+*/
+   wait_event_interruptible(random_write_wait,
+kthread_should_stop() ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
+   }
mix_pool_bytes(poolp, buffer, count);
credit_entropy_bits(poolp, entropy);
 }
-- 
2.5.0

[PATCH 7/7] random: add backtracking protection to the CRNG

[Theodore Ts'o]

Signed-off-by: Theodore Ts'o 
---
 drivers/char/random.c | 54 ++-
 1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index d640865..963a6a9 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -436,7 +436,8 @@ static int crng_init = 0;
 #define crng_ready() (likely(crng_init > 0))
 static void _extract_crng(struct crng_state *crng,
  __u8 out[CHACHA20_BLOCK_SIZE]);
-static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE]);
+static void _crng_backtrack_protect(struct crng_state *crng,
+   __u8 tmp[CHACHA20_BLOCK_SIZE], int used);
 static void process_random_ready_list(void);
 
 /**
@@ -826,8 +827,11 @@ static void crng_reseed(struct crng_state *crng, struct 
entropy_store *r)
num = extract_entropy(r, &buf, 32, 16, 0);
if (num == 0)
return;
-   } else
+   } else {
_extract_crng(&primary_crng, buf.block);
+   _crng_backtrack_protect(&primary_crng, buf.block,
+   CHACHA20_KEY_SIZE);
+   }
spin_lock_irqsave(&primary_crng.lock, flags);
for (i = 0; i < 8; i++) {
unsigned long   rv;
@@ -889,9 +893,46 @@ static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE])
_extract_crng(crng, out);
 }
 
+/*
+ * Use the leftover bytes from the CRNG block output (if there is
+ * enough) to mutate the CRNG key to provide backtracking protection.
+ */
+static void _crng_backtrack_protect(struct crng_state *crng,
+   __u8 tmp[CHACHA20_BLOCK_SIZE], int used)
+{
+   unsigned long   flags;
+   __u32   *s, *d;
+   int i;
+
+   used = round_up(used, sizeof(__u32));
+   if (used + CHACHA20_KEY_SIZE > CHACHA20_BLOCK_SIZE) {
+   extract_crng(tmp);
+   used = 0;
+   }
+   spin_lock_irqsave(&crng->lock, flags);
+   s = (__u32 *) &tmp[used];
+   d = &crng->state[4];
+   for (i=0; i < 8; i++)
+   *d++ ^= *s++;
+   spin_unlock_irqrestore(&crng->lock, flags);
+}
+
+static void crng_backtrack_protect(__u8 tmp[CHACHA20_BLOCK_SIZE], int used)
+{
+   struct crng_state *crng = NULL;
+
+#ifdef CONFIG_NUMA
+   if (crng_node_pool)
+   crng = crng_node_pool[numa_node_id()];
+   if (crng == NULL)
+#endif
+   crng = &primary_crng;
+   _crng_backtrack_protect(crng, tmp, used);
+}
+
 static ssize_t extract_crng_user(void __user *buf, size_t nbytes)
 {
-   ssize_t ret = 0, i;
+   ssize_t ret = 0, i = CHACHA20_BLOCK_SIZE;
__u8 tmp[CHACHA20_BLOCK_SIZE];
int large_request = (nbytes > 256);
 
@@ -916,6 +957,7 @@ static ssize_t extract_crng_user(void __user *buf, size_t 
nbytes)
buf += i;
ret += i;
}
+   crng_backtrack_protect(tmp, i);
 
/* Wipe data just written to memory */
memzero_explicit(tmp, sizeof(tmp));
@@ -1473,8 +1515,10 @@ void get_random_bytes(void *buf, int nbytes)
if (nbytes > 0) {
extract_crng(tmp);
memcpy(buf, tmp, nbytes);
-   memzero_explicit(tmp, nbytes);
-   }
+   crng_backtrack_protect(tmp, nbytes);
+   } else
+   crng_backtrack_protect(tmp, CHACHA20_BLOCK_SIZE);
+   memzero_explicit(tmp, sizeof(tmp));
 }
 EXPORT_SYMBOL(get_random_bytes);
 
-- 
2.5.0

Applied "ASoC: sti: fix return value check in uni_player_parse_dt_audio_glue()" to the asoc tree

[Mark Brown]

The patch

   ASoC: sti: fix return value check in uni_player_parse_dt_audio_glue()

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7d267ddfd560da3232f4deed3427839dd0126a4a Mon Sep 17 00:00:00 2001
From: Wei Yongjun 
Date: Mon, 13 Jun 2016 14:39:57 +
Subject: [PATCH] ASoC: sti: fix return value check in
 uni_player_parse_dt_audio_glue()

In case of error, the function syscon_regmap_lookup_by_phandle() returns
ERR_PTR() and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
Signed-off-by: Mark Brown 
---
 sound/soc/sti/uniperif_player.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sti/uniperif_player.c b/sound/soc/sti/uniperif_player.c
index ee1c7c245bc7..1ac2db205a0d 100644
--- a/sound/soc/sti/uniperif_player.c
+++ b/sound/soc/sti/uniperif_player.c
@@ -1029,9 +1029,9 @@ static int uni_player_parse_dt_audio_glue(struct 
platform_device *pdev,
 
regmap = syscon_regmap_lookup_by_phandle(node, "st,syscfg");
 
-   if (!regmap) {
+   if (IS_ERR(regmap)) {
dev_err(&pdev->dev, "sti-audio-clk-glue syscf not found\n");
-   return -EINVAL;
+   return PTR_ERR(regmap);
}
 
player->clk_sel = regmap_field_alloc(regmap, regfield[0]);
-- 
2.8.1

Applied "regulator: qcom_smd: add list_voltage callback" to the regulator tree

[Mark Brown]

The patch

   regulator: qcom_smd: add list_voltage callback

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3bfbb4d1a480cc17f6ccfce13b76eb6c0dbeaf8c Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla 
Date: Thu, 2 Jun 2016 11:23:15 +0100
Subject: [PATCH] regulator: qcom_smd: add list_voltage callback

This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.

Without this patch there is no way for mmc core to know this voltage range.

Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Mark Brown 
---
 drivers/regulator/qcom_smd-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/qcom_smd-regulator.c 
b/drivers/regulator/qcom_smd-regulator.c
index 6c7fe4778793..526bf23dcb49 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -152,6 +152,7 @@ static const struct regulator_ops rpm_smps_ldo_ops_fixed = {
.enable = rpm_reg_enable,
.disable = rpm_reg_disable,
.is_enabled = rpm_reg_is_enabled,
+   .list_voltage = regulator_list_voltage_linear_range,
 
.get_voltage = rpm_reg_get_voltage,
.set_voltage = rpm_reg_set_voltage,
-- 
2.8.1

Re: [PATCH] staging: gdm724x: Replace semaphore netlink with mutex

[Arnd Bergmann]

On Monday, June 13, 2016 7:59:20 PM CEST Binoy Jayan wrote:
> 
> -#if defined(DEFINE_MUTEX)
> -static DEFINE_MUTEX(netlink_mutex);
> -#else
> -static struct semaphore netlink_mutex;
> -#define mutex_lock(x)  down(x)
> -#define mutex_unlock(x)up(x)
> -#endif
> +static struct mutex netlink_mutex;
> 

Good catch! I think the patch is correct, but the DEFINE_MUTEX
here seems preferable over the runtime mutex_init() call.

Arnd

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Christopher Covington]

Hi Dongdong,

On 06/13/2016 09:02 AM, Dongdong Liu wrote:
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index d3c3e85..49612b3 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -22,6 +22,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +/* Root pointer to the mapped MCFG table */
> +static struct acpi_table_mcfg *mcfg_table;
>  
>  /* Structure to hold entries from the MCFG table */
>  struct mcfg_entry {
> @@ -35,6 +39,38 @@ struct mcfg_entry {
>  /* List to save mcfg entries */
>  static LIST_HEAD(pci_mcfg_list);
>  
> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
> +
> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> + int bus_num = root->secondary.start;
> + int domain = root->segment;
> + struct pci_cfg_fixup *f;
> +
> + if (!mcfg_table)
> + return &pci_generic_ecam_ops;
> +
> + /*
> +  * Match against platform specific quirks and return corresponding
> +  * CAM ops.
> +  *
> +  * First match against PCI topology  then use OEM ID and
> +  * OEM revision from MCFG table standard header.
> +  */
> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
> + if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
> + (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
> + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
> +   ACPI_OEM_ID_SIZE)) &&
> + (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
> +   ACPI_OEM_TABLE_ID_SIZE)))

This would just be a small convenience, but if the character count used here 
were

min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)

then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
wouldn't need to be padded out to the full length.

> + return f->ops;
> + }
> + /* No quirks, use ECAM */
> + return &pci_generic_ecam_ops;
> +}

> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7d63a66..088a1da 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -25,6 +25,7 @@ static inline acpi_status 
> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>  
>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>  
>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>  {
> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>   int (*prepare_resources)(struct acpi_pci_root_info *info);
>  };
>  
> +struct pci_cfg_fixup {
> + struct pci_ecam_ops *ops;
> + char *oem_id;
> + char *oem_table_id;
> + int domain;
> + int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY  -1
> +#define PCI_MCFG_BUS_ANY -1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
> + static const struct pci_cfg_fixup   \
> + __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I'm not entirely sure that this is the right fix--I'm pretty blindly
following a GCC documentation suggestion [1]--but removing the first two
preprocessor concatenation operators "##" solved the following build error
for me.

include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" does 
not give a valid preprocessing token
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
  ^
arch/arm64/kernel/pci.c:225:1: note: in expansion of macro 
‘DECLARE_ACPI_MCFG_FIXUP’
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
 ^
arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does 
not give a valid preprocessing token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
^
include/linux/pci-acpi.h:90:17: note: in definition of macro 
‘DECLARE_ACPI_MCFG_FIXUP’
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
 ^
arch/arm64/kernel/pci.c:225:52: error: pasting ""QDF2432"" and 
"PCI_MCFG_DOMAIN_ANY" does not give a valid preprocessi
ng token
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
^
include/linux/pci-acpi.h:90:25: note: in definition of macro 
‘DECLARE_ACPI_MCFG_FIXUP’
  __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
 ^
arch/arm64/kernel/pci.c:225:44: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before string constant
 DECLARE_ACPI_MCFG_FIXUP(&pci_32b_ecam_ops, "QCOM", "QDF2432", 
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_

Re: [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs

[Christoph Hellwig]

On Fri, Jun 10, 2016 at 01:37:17PM +0200, Hannes Reinecke wrote:
> Hmm. So everybody is suffering because someone _might_ be using bio_clone?
> Why can't we fixup bio_clone() (or the callers of which) to correctly
> set the queue limits?

The only one suffering is bcache.  Everyone else uses bios below the
block layer arbitrary max size.  The fixup to allow bio_clone support
a larger size is the same one as to allow everyone else submitting
larger bios:  increase BIO_MAX_PAGES and create the required mempools
to back that new larger size.  Or just go for multipage biovecs..

Re: Using irq-crossbar.c

[Sebastian Frias]

Hi Marc,

Thanks for your reply, please find my comments below.

On 06/10/2016 06:05 PM, Marc Zyngier wrote:
> On 10/06/16 16:37, Sebastian Frias wrote:
>> Hi,
>>
>> We are trying to write a driver for an interrupt controller (actually
>> more of a crossbar) for an ARM-based SoC. This IRQ crossbar has 128
>> inputs and 24 outputs, the outputs are connected directly to the
>> GIC. The idea is that the GIC handles everything, and just request a
>> mapping from an IRQ number (0...127, from a device's DT entry) into
>> one of its 24 input lines.
> 
> "Just request a mapping...".
> 
>> By looking at current code (4.7-rc1) there seems to be a driver
>> (drivers/irqchip/irq-crossbar.c) that provides similar
>> functionality. The driver uses hierarchical irq domains (since commit
>> 783d31863fb8 "irqchip: crossbar: Convert dra7 crossbar to stacked
>> domains") which we believe we don't need because the only controller
>> is the GIC.
> 
> So you need it, but you don't need it? The GIC may be the only interrupt
> controller with which software interacts when the interrupt occurs, but
> the crossbar does play a major role in *routing* the interrupt to the
> right GIC pin.

My understanding of "hierarchical irq domains" is that it is useful when there 
are multiple stacked interrupt controllers.
Also, the documentation says "the majority of drivers should use the linear 
map" (as opposed to the hierarchical one).

Maybe the definition of "interrupt controller" could benefit from some 
clarification, but my understanding is that, in our case, the GIC is the only 
interrupt controller (that's where the interrupt type must be set 
active_high/active_low/edge, etc.), in front of it, it happens to be a 
crossbar, that happens to be programmable, and that can be used to map any 128 
line into any of 24 lines of the GIC (actually it is a many-to-many router, 
without any latching nor edge detection functionality)

Obviously, when the DT says that ethernet driver uses IRQ=120 (for example), 
the crossbar must be setup to route line 120 to one of the 24 lines going to 
the GIC.
So a minimum of interaction between the GIC driver (and/or the Linux IRQ 
framework) and the driver programming the crossbar is required, and that's what 
we are trying to achieve.

Does that makes sense?

> 
>> However the API used previously, register_routable_domain_ops(), was
>> removed with commit a5561c3e845c "irqchip: gic: Get rid of routable
>> domain".
> 
> And every day, I thank $DEITY for having delivered us from this evil.
> Really. And it wasn't much of an API. It was the son of a hack, bolted
> on the side of another hack. Unmaintainable, getting in the way. I had
> much fun slaughtering it! ;-)
> 
>> Trying to use the driver with hierarchical domains (after
>> modifications for our SoC), results on the kernel being blocked at
>> some point:
>>
>> [0.041524] ThumbEE CPU extension supported.
>> [0.041589] Registering SWP/SWPB emulation handler
>> [0.052022] Freeing unused kernel memory: 12364K (c029b000 - c0eae000)
>> [0.074084] random: dbus-uuidgen urandom read with 0 bits of entropy 
>> available
> 
> Sorry, but that's not much of a log. Anything related to interrupts, maybe?

That's the last log (it's stuck there) and I was asking how/where to enable 
more logs to be able to debug this.

Or there are no standardised logs and every person has to come up with its own 
debug logs?

> 
>> We've put logs on the different domain_ops calls (alloc, free,
>> translate) but they are not called, even if the DT is supposed to
>> tell devices to take interrupts from this controller (*).
> 
> At all? Nobody is talking to the GIC?
> 
>> Do you have suggestions on what APIs should be used, further
>> reading/examples and/or pointers on how debug this (logs to enable,
>> things to look for, etc.)?
> 
> You could start with posting actual logs of an interrupt being
> requested, as well as perform some basic tracing of the various
> callbacks into the irqdomain and irqchip layers, all the way down to the
> interrupt controllers (note the plural). 

Ok, thanks.

In the meanwhile, and in case irq-crossbar is not the good example for our 
case, would it be possible to get some guidance, examples, tips, on how to 
write a driver like the one described? ie:

[0..127] IRQ inputs => BIG_MUX => [0..23] outputs => [0..23] GIC inputs

BIG_MUX is a many-to-many router:
- 128x32bit registers to setup a route between any of the 128 input (IRQ_dev) 
and any of the 24 outputs (IRQ_gic)
-   4x32bit registers that read the RAW status of each of the 128 lines (no 
latching nor edge detection)
not sure how useful is to read such RAW status, because (naive hypothesis 
follows) Linux's IRQ framework could remember which IRQ_dev lines are routed to 
which IRQ_gic, and thus when handling IRQ_gic(x), Linux could just ask the 
drivers tied to it to check for interruptions.


>Also, without seeing the code,
> it is pretty difficult to make any meaningful comment...

Re: Using irq-crossbar.c

[Lennart Sorensen]

On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the 
> GIC.
> The HW block is a many-to-many router.
> There are 128 32bit registers which specify, for each of the corresponding 
> 128 inputs, to which of the 24 outputs it would be routed to.
> 
> There are 4 32bit registers that can show the RAW status of the 128 inputs, 
> but they do not latch on the inputs.
> That's why our understanding is that on Linux terms it is not an interrupt 
> controller, but just a many-to-many mux, the only real interrupt-controller 
> (where one can set if the line is active high or low for example) is the GIC.

Well that does just sound like a mux.  But that does mean you either
can't use more than 24 inputs at once, or you will be sharing interrupts.

I really hate shared interrutps so I would never design something that
way, but it is simpler.

> Thanks for the background on the i8259 and the cascaded interrupts.
> However, our understanding is that it would only be required if more than 24 
> devices request IRQ lines, in which case, some of them would have to share a 
> single GIC IRQ line, right?
> Shall we worry about that now?

Well if you are sure you never need more than 24 devices registered at
once, then it shouldn't be a problem.

> This is interesting.
> We have one interrupt controller already upstream, 
> drivers/irqchip/irq-tango.c, and our understanding is that it dispatches one 
> IRQ at the time, see tangox_dispatch_irqs() function, is that what you are 
> discussing?

That does look like a proper interrupt controller that could be cascaded
of another one if needed.

-- 
Len Sorensen

[PATCH] ASoC: rcar: fix 'const static' variables

[Arnd Bergmann]

When building with 'make W=1', we get a harmless warning about
slightly incorrect prototypes in the rcar audio driver:

sound/soc/sh/rcar/gen.c: In function 'rsnd_gen2_probe':
sound/soc/sh/rcar/gen.c:209:2: error: 'static' is not at beginning of 
declaration [-Werror=old-style-declaration]

This changes the 'const static' to 'static const' as it should be.

Signed-off-by: Arnd Bergmann 
---
 sound/soc/sh/rcar/gen.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c
index 46c0ba7b6414..7d2fdf8dd188 100644
--- a/sound/soc/sh/rcar/gen.c
+++ b/sound/soc/sh/rcar/gen.c
@@ -206,7 +206,7 @@ static int _rsnd_gen_regmap_init(struct rsnd_priv *priv,
  */
 static int rsnd_gen2_probe(struct rsnd_priv *priv)
 {
-   const static struct rsnd_regmap_field_conf conf_ssiu[] = {
+   static const struct rsnd_regmap_field_conf conf_ssiu[] = {
RSND_GEN_S_REG(SSI_MODE0,   0x800),
RSND_GEN_S_REG(SSI_MODE1,   0x804),
RSND_GEN_S_REG(SSI_MODE2,   0x808),
@@ -221,7 +221,7 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
RSND_GEN_M_REG(SSI_INT_ENABLE,  0x18,   0x80),
};
 
-   const static struct rsnd_regmap_field_conf conf_scu[] = {
+   static const struct rsnd_regmap_field_conf conf_scu[] = {
RSND_GEN_M_REG(SRC_I_BUSIF_MODE,0x0,0x20),
RSND_GEN_M_REG(SRC_O_BUSIF_MODE,0x4,0x20),
RSND_GEN_M_REG(SRC_BUSIF_DALIGN,0x8,0x20),
@@ -308,7 +308,7 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
RSND_GEN_M_REG(DVC_VOL7R,   0xe44,  0x100),
RSND_GEN_M_REG(DVC_DVUER,   0xe48,  0x100),
};
-   const static struct rsnd_regmap_field_conf conf_adg[] = {
+   static const struct rsnd_regmap_field_conf conf_adg[] = {
RSND_GEN_S_REG(BRRA,0x00),
RSND_GEN_S_REG(BRRB,0x04),
RSND_GEN_S_REG(SSICKR,  0x08),
@@ -328,7 +328,7 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
RSND_GEN_S_REG(SRCOUT_TIMSEL4,  0x58),
RSND_GEN_S_REG(CMDOUT_TIMSEL,   0x5c),
};
-   const static struct rsnd_regmap_field_conf conf_ssi[] = {
+   static const struct rsnd_regmap_field_conf conf_ssi[] = {
RSND_GEN_M_REG(SSICR,   0x00,   0x40),
RSND_GEN_M_REG(SSISR,   0x04,   0x40),
RSND_GEN_M_REG(SSITDR,  0x08,   0x40),
@@ -359,14 +359,14 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
 
 static int rsnd_gen1_probe(struct rsnd_priv *priv)
 {
-   const static struct rsnd_regmap_field_conf conf_adg[] = {
+   static const struct rsnd_regmap_field_conf conf_adg[] = {
RSND_GEN_S_REG(BRRA,0x00),
RSND_GEN_S_REG(BRRB,0x04),
RSND_GEN_S_REG(SSICKR,  0x08),
RSND_GEN_S_REG(AUDIO_CLK_SEL0,  0x0c),
RSND_GEN_S_REG(AUDIO_CLK_SEL1,  0x10),
};
-   const static struct rsnd_regmap_field_conf conf_ssi[] = {
+   static const struct rsnd_regmap_field_conf conf_ssi[] = {
RSND_GEN_M_REG(SSICR,   0x00,   0x40),
RSND_GEN_M_REG(SSISR,   0x04,   0x40),
RSND_GEN_M_REG(SSITDR,  0x08,   0x40),
-- 
2.7.0

Re: kern_path() returns error in kernel 4.4

[Al Viro]

On Mon, Jun 13, 2016 at 05:12:27PM +0800, dongke di wrote:
> struct path path;
> int r = kern_path( "/tmp/abc.txt", LOOKUP_FOLLOW | LOOKUP_PARENT, &path );
> 
> The file abc.txt does not exist.
> 
> On Ubuntu 14.04 ( kernel 3.13 ), r is zero (succed).
> On Ubuntu 16.04 ( kernel 4.4 ), r is -2 ( fail).
> 
> Is it a bug or other else ?

It is - in the code that passes LOOKUP_PARENT to kern_path().  What are
is it trying to do there?  Need more context...

[PATCH] ASoC: pcm1681/pcm1791: fix typo in declaration

[Arnd Bergmann]

gcc -Wextra warns about an obvious but harmless typo in the
pcm1681_writeable_reg function, which has an extra 'register
keyword', and in pcm179x, which has a second copy of that
declaration:

sound/soc/codecs/pcm1681.c:76:42: error: 'register' is not at beginning of 
declaration [-Werror=old-style-declaration]
sound/soc/codecs/pcm179x.c:62:42: error: 'register' is not at beginning of 
declaration [-Werror=old-style-declaration]

For consistency with the rest of the file, I'm changing this from
'unsigned register' to 'unsigned int', which has the same meaning
but causes no warning.

Signed-off-by: Arnd Bergmann 
---
 sound/soc/codecs/pcm1681.c | 2 +-
 sound/soc/codecs/pcm179x.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/pcm1681.c b/sound/soc/codecs/pcm1681.c
index 58325234285c..33e1fc2d1598 100644
--- a/sound/soc/codecs/pcm1681.c
+++ b/sound/soc/codecs/pcm1681.c
@@ -73,7 +73,7 @@ static bool pcm1681_accessible_reg(struct device *dev, 
unsigned int reg)
return !((reg == 0x00) || (reg == 0x0f));
 }
 
-static bool pcm1681_writeable_reg(struct device *dev, unsigned register reg)
+static bool pcm1681_writeable_reg(struct device *dev, unsigned int reg)
 {
return pcm1681_accessible_reg(dev, reg) &&
(reg != PCM1681_ZERO_DETECT_STATUS);
diff --git a/sound/soc/codecs/pcm179x.c b/sound/soc/codecs/pcm179x.c
index 06a66579ca6d..88fbdd184aa0 100644
--- a/sound/soc/codecs/pcm179x.c
+++ b/sound/soc/codecs/pcm179x.c
@@ -59,7 +59,7 @@ static bool pcm179x_accessible_reg(struct device *dev, 
unsigned int reg)
return reg >= 0x10 && reg <= 0x17;
 }
 
-static bool pcm179x_writeable_reg(struct device *dev, unsigned register reg)
+static bool pcm179x_writeable_reg(struct device *dev, unsigned int reg)
 {
bool accessible;
 
-- 
2.7.0

[PATCH] ASoC: fix ABE_TWL6040 dependency

[Arnd Bergmann]

The TWL6040 ASoC support has recently started turning on CLK_TWL6040,
but that fails to build when CONFIG_COMMON_CLK is disabled:

warning: (SND_OMAP_SOC_OMAP_ABE_TWL6040) selects CLK_TWL6040 which has unmet 
direct dependencies (COMMON_CLK && TWL6040_CORE)
0xF18E38F6 Thu Jun 9 18:57:32 CEST 2016 failed
In file included from ../include/linux/clocksource.h:18:0,
 from ../drivers/clocksource/timer-nps.c:34:
../include/linux/of.h:1005:20: error: comparison of distinct pointer types 
lacks a cast [-Werror]
.data = (fn == (fn_type)NULL) ? fn : fn  }
^

This adds a dependency to avoid the invalid configuration.

Signed-off-by: Arnd Bergmann 
Fixes: 443500a3927a ("ASoC: omap: Kconfig: SND_OMAP_SOC_OMAP_ABE_TWL6040 to 
select CLK_TWL6040")
---
 sound/soc/omap/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 5c471d920898..f5451c78ede5 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -100,7 +100,7 @@ config SND_OMAP_SOC_OMAP_TWL4030
 
 config SND_OMAP_SOC_OMAP_ABE_TWL6040
tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec"
-   depends on TWL6040_CORE && SND_OMAP_SOC
+   depends on TWL6040_CORE && SND_OMAP_SOC && COMMON_CLK
depends on ARCH_OMAP4 || (SOC_OMAP5 && MFD_PALMAS) || COMPILE_TEST
select SND_OMAP_SOC_DMIC
select SND_OMAP_SOC_MCPDM
-- 
2.7.0

[PATCH] ASoC: cs53l30: include gpio/consumer.h

[Arnd Bergmann]

When GPIOLIB is disabled, we don't see the declarations from
gpio/consumer.h, so we have to include the header explicitly
to avoid this build error:

sound/soc/codecs/cs53l30.c: In function 'cs53l30_i2c_probe':
sound/soc/codecs/cs53l30.c:931:24: error: implicit declaration of function 
'devm_gpiod_get_optional' [-Werror=implicit-function-declaration]
  cs53l30->reset_gpio = devm_gpiod_get_optional(dev, reset,
^~~
sound/soc/codecs/cs53l30.c:932:13: error: 'GPIOD_OUT_LOW' undeclared (first use 
in this function)
 GPIOD_OUT_LOW);
 ^
sound/soc/codecs/cs53l30.c:932:13: note: each undeclared identifier is reported 
only once for each function it appears in
sound/soc/codecs/cs53l30.c:939:3: error: implicit declaration of function 
'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
   gpiod_set_value_cansleep(cs53l30->reset_gpio, 1);

Signed-off-by: Arnd Bergmann 
---
 sound/soc/codecs/cs53l30.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
index ac90dd79857e..aa511e70099e 100644
--- a/sound/soc/codecs/cs53l30.c
+++ b/sound/soc/codecs/cs53l30.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.0

Re: [PATCH] media: s5p-mfc fix memory leak in s5p_mfc_remove()

[Shuah Khan]

On 06/13/2016 07:42 AM, Javier Martinez Canillas wrote:
> Hello Shuah,
> 
> On Wed, Jun 8, 2016 at 9:35 PM, Shuah Khan  wrote:
>> s5p_mfc_remove() fails to release encoder and decoder video devices.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index 274b4f1..af61f54 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -1317,7 +1317,9 @@ static int s5p_mfc_remove(struct platform_device *pdev)
>> destroy_workqueue(dev->watchdog_workqueue);
>>
>> video_unregister_device(dev->vfd_enc);
>> +   video_device_release(dev->vfd_enc);
>> video_unregister_device(dev->vfd_dec);
>> +   video_device_release(dev->vfd_dec);
>> v4l2_device_unregister(&dev->v4l2_dev);
>> s5p_mfc_release_firmware(dev);
>> vb2_dma_contig_cleanup_ctx(dev->alloc_ctx[0]);
>> --
> 
> Can you please do the remove operations in the inverse order of their
> counterparts? IOW to do the release for both encoder and decoder after
> their unregistration.
> 

I considered that. No problem. I will move both release after the
video_unregister_device(dev->vfd_dec), releasing enc first and then
the dec

> 
> Reviewed-by: Javier Martinez Canillas 
> 

thanks,
-- Shuah

[PATCH] ASoC: wm8985: add i2c dependency

[Arnd Bergmann]

The wm8985 driver is now user-selectable, but building it with
I2C disabled results in a link failure:

sound/built-in.o: In function `wm8985_i2c_probe':
:(.text+0x44914): undefined reference to `__devm_regmap_init_i2c'
sound/built-in.o: In function `wm8985_exit':
:(.exit.text+0x3d8): undefined reference to `i2c_del_driver'
sound/built-in.o: In function `wm8985_modinit':
:(.init.text+0x1454): undefined reference to `i2c_register_driver'

This adds a Kconfig dependency the way that the other codec
drivers have it.

Signed-off-by: Arnd Bergmann 
Fixes: 811e66de2241 ("ASoC: wm8985: add support for WM8758")
---
 sound/soc/codecs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index cb57f8fe2690..f555a5a004f7 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -986,6 +986,7 @@ config SND_SOC_WM8983
 
 config SND_SOC_WM8985
tristate "Wolfson Microelectronics WM8985 and WM8758 codec driver"
+   depends on I2C
 
 config SND_SOC_WM8988
tristate
-- 
2.7.0

Re: [PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states

[Daniel Lezcano]

On Wed, Jun 08, 2016 at 11:54:30AM -0500, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added.
>  b) new per thread SPR named PSSCR is added which controls the behavior
>   of stop instruction.
> 
> Supported idle states and value to be written to PSSCR register to enter
> any idle state is exposed via ibm,cpu-idle-state-names and
> ibm,cpu-idle-state-psscr respectively. To enter an idle state,
> platform provided power_stop() needs to be invoked with the appropriate
> PSSCR value.
> 
> This patch adds support for this new mechanism in cpuidle powernv driver.
> 
> Cc: Rafael J. Wysocki 
> Cc: Daniel Lezcano 
> Cc: Rob Herring 
> Cc: Lorenzo Pieralisi 
> Cc: linux...@vger.kernel.org
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: linuxppc-...@lists.ozlabs.org
> Reviewed-by: Gautham R. Shenoy 
> Signed-off-by: Shreyas B. Prabhu 
> ---

[ ... ]

> + rc = of_property_read_string_array(power_mgt,
> +"ibm,cpu-idle-state-names", names,
> +dt_idle_states);
> + if (rc < 0) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in 
> DT\n");
> + goto out_free_latency;
> + }
> +
> + /*
> +  * If the idle states use stop instruction, probe for psscr values
> +  * which are necessary to specify required stop level.
> +  */
> + if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP)) {
> + psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
> + GFP_KERNEL);

if (!psscr_val) check missing.

> + rc = of_property_read_u64_array(power_mgt,
> + "ibm,cpu-idle-state-psscr",
> + psscr_val, dt_idle_states);
> + if (rc) {
> + pr_warn("cpuidle-powernv: missing 
> ibm,cpu-idle-states-psscr in DT\n");
> + goto out_free_psscr;
> + }
> + }
>   residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states, 
> GFP_KERNEL);

if (!residency_ns) check missing.

I suppose the code is relying on 'of_property_read_u32_array' to check it, 
right ?


  -- Daniel

Re: [PATCH 3/3] infiniband: rxe: fix 32-bit build warnings

[Moni Shoua]

thanks. will be applied to next series.

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The new rxe infinband driver passes around pointers that have been
> converted to 64-bit integers. This is valid, but causes compile-time
> warnings on all 32-bit architectures:
>
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_single':
> infiniband/hw/rxe/rxe_dma.c:49:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>   return (u64)cpu_addr;
>  ^
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_map_page':
> infiniband/hw/rxe/rxe_dma.c:73:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_map_sg':
> infiniband/hw/rxe/rxe_dma.c:99:10: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> infiniband/hw/rxe/rxe_dma.c: In function 'rxe_dma_alloc_coherent':
> infiniband/hw/rxe/rxe_dma.c:143:17: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
>
> This changes the cast to use 'uintptr_t', which can always be
> cast to and from pointer, and can be assigned to and from 64-bit
> integers.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/rxe_dma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/rxe/rxe_dma.c 
> b/drivers/infiniband/hw/rxe/rxe_dma.c
> index f080bc5bda43..7634c1a81b2b 100644
> --- a/drivers/infiniband/hw/rxe/rxe_dma.c
> +++ b/drivers/infiniband/hw/rxe/rxe_dma.c
> @@ -46,7 +46,7 @@ static u64 rxe_dma_map_single(struct ib_device *dev,
>   enum dma_data_direction direction)
>  {
> WARN_ON(!valid_dma_direction(direction));
> -   return (u64)cpu_addr;
> +   return (uintptr_t)cpu_addr;
>  }
>
>  static void rxe_dma_unmap_single(struct ib_device *dev,
> @@ -70,7 +70,7 @@ static u64 rxe_dma_map_page(struct ib_device *dev,
> goto done;
> }
>
> -   addr = (u64)page_address(page);
> +   addr = (uintptr_t)page_address(page);
> if (addr)
> addr += offset;
>
> @@ -96,7 +96,7 @@ static int rxe_map_sg(struct ib_device *dev, struct 
> scatterlist *sgl,
> WARN_ON(!valid_dma_direction(direction));
>
> for_each_sg(sgl, sg, nents, i) {
> -   addr = (u64)page_address(sg_page(sg));
> +   addr = (uintptr_t)page_address(sg_page(sg));
> if (!addr) {
> ret = 0;
> break;
> @@ -140,7 +140,7 @@ static void *rxe_dma_alloc_coherent(struct ib_device 
> *dev, size_t size,
> addr = page_address(p);
>
> if (dma_handle)
> -   *dma_handle = (u64)addr;
> +   *dma_handle = (uintptr_t)addr;
>
> return addr;
>  }
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cpufreq: conservative: Do not use transition notifications

[Viresh Kumar]

On 13-06-16, 15:36, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> Subject: [PATCH v2] cpufreq: conservative: Do not use transition notifications
> 
> The conservative governor registers a transition notifier so it
> can update its internal requested_freq value if it falls out of the
> policy->min...policy->max range, but requested_freq is not really
> necessary.
> 
> That value is used to track the frequency requested by the governor
> previously, but policy->cur can be used instead of it and then the
> governor will not have to worry about updating the tracked value when
> the current frequency changes independently (for example, as a result
> of min or max changes).
> 
> Accodringly, drop requested_freq from struct cs_policy_dbs_info
> and modify cs_dbs_timer() to use policy->cur instead of it.
> While at it, notice that __cpufreq_driver_target() clamps its
> target_freq argument between policy->min and policy->max, so
> the callers of it don't have to do that and make additional
> changes in cs_dbs_timer() in accordance with that.
> 
> After these changes the transition notifier used by the conservative
> governor is not necessary any more, so drop it, which also makes it
> possible to drop the struct cs_governor definition and simplify the
> code accordingly.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_conservative.c |  103 
> ++---
>  1 file changed, 21 insertions(+), 82 deletions(-)
> 

Acked-by: Viresh Kumar 

> -static struct cs_governor cs_gov = {
> - .dbs_gov = {
> - .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"),
> - .kobj_type = { .default_attrs = cs_attributes },
> - .gov_dbs_timer = cs_dbs_timer,
> - .alloc = cs_alloc,
> - .free = cs_free,
> - .init = cs_init,
> - .exit = cs_exit,
> - .start = cs_start,
> - },
> +static struct dbs_governor cs_governor = {
> + .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"),
> + .kobj_type = { .default_attrs = cs_attributes },
> + .gov_dbs_timer = cs_dbs_timer,
> + .alloc = cs_alloc,
> + .free = cs_free,
> + .init = cs_init,
> + .exit = cs_exit,
> + .start = cs_start,
>  };

Though, I am not sure why this change was required :)

-- 
viresh

Re: [PATCH 1/3] infiniband: rxe: avoid 64-bit division

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 4:18 PM, Leon Romanovsky  wrote:
> On Mon, Jun 13, 2016 at 02:54:53PM +0200, Arnd Bergmann wrote:
>> The rxe driver fails to build on 32-bit because of a 64-bit division:
>>
>> In function `rxe_qp_from_attr':
>> :(.text+0x53158): undefined reference to `__aeabi_uldivmod'
>>
>> We can easily avoid this division by converting the nanosecond value
>> into jiffies directly rather than converting to microseconds first.
>>
>> Signed-off-by: Arnd Bergmann 
>
> Thanks Arnd,
> All three patches are applied on topic/rxe now.

RE: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger
> framework
> 
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but that
> requires a system with suitable hardware.
> 
> The basic conception of the usb charger is that, when one usb charger is
> added or removed by reporting from the usb gadget state change or the
> extcon device state change, the usb charger will report to power user to
> set the current limitation.
> 
> The usb charger will register notifiees on the usb gadget or the extcon
> device to get notified the usb charger state. It also supplies the
> notification mechanism to userspace When the usb charger state is changed.
> 
> Power user will register a notifiee on the usb charger to get notified by
> status changes from the usb charger. It will report to power user to set
> the current limitation when detecting the usb charger is added or removed
> from extcon device state or usb gadget state.
> 
> This patch doesn't yet integrate with the gadget code, so some functions
> which rely on the 'gadget' are not completed, that will be implemented in
> the following patches.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/Kconfig   |7 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  770
> ++
>  include/linux/usb/charger.h  |  191 ++
>  include/uapi/linux/usb/charger.h |   31 ++
>  5 files changed, 1000 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c  create mode 100644
> include/linux/usb/charger.h  create mode 100644
> include/uapi/linux/usb/charger.h

Re: [PATCH 2/3] infiniband: rxe: add UDP_TUNNEL dependency

[Moni Shoua]

thanks. will be applied to next series

On Mon, Jun 13, 2016 at 3:54 PM, Arnd Bergmann  wrote:
> The newly added rxe driver links against the UDP tunneling code,
> which causes build errors when CONFIG_UDP_TUNNEL is disabled:
>
> ERROR: "setup_udp_tunnel_sock" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_tunnel_sock_release" [drivers/infiniband/hw/rxe/ib_rxe.ko] 
> undefined!
> ERROR: "udp_sock_create4" [drivers/infiniband/hw/rxe/ib_rxe.ko] undefined!
>
> This adds a Kconfig dependency to prevent the invalid configuration.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/hw/rxe/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/hw/rxe/Kconfig 
> b/drivers/infiniband/hw/rxe/Kconfig
> index 649b7be11eb8..a199d0df31d0 100644
> --- a/drivers/infiniband/hw/rxe/Kconfig
> +++ b/drivers/infiniband/hw/rxe/Kconfig
> @@ -1,6 +1,7 @@
>  config INFINIBAND_RXE
> tristate "Software RDMA over Ethernet (RoCE) driver"
> depends on INET && PCI && INFINIBAND
> +   depends on NET_UDP_TUNNEL
> ---help---
> This driver implements the InfiniBand RDMA transport over
> the Linux network stack. It enables a system with a
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c: 2 * pointless tests ?

[Rob Clark]

yup, looks like we can drop the two pipe<0 checks.  Care to send a patch?

BR,
-R

On Mon, Jun 13, 2016 at 10:51 AM, David Binderman
 wrote:
> Hello there,
>
> 1.
>
> linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:545]: (style)
> Checking if unsigned variable 'pipe' is less than zero.
>
> Source code is
>
> if (pipe < 0 || pipe >= priv->num_crtcs) {
>
> 2.
>
> linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:567]: (style)
> Checking if unsigned variable 'pipe' is less than zero.
>
> Duplicate a few lines further down.
>
>
> Regards
>
> David Binderman

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[João Paulo Rechi Vita]

On 9 June 2016 at 08:43, Johannes Berg  wrote:
> On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote:
>

(...)

>> LED
>> subsystem seems to use suffix of LED name to do that. So if we
>> standartize, lets say "::rfkill" suffix for this, it should work and
>> follow existing practice.
> [...]
>> There is one -- suffix in the LED name.
>
> I don't really think that's a good way, and it doesn't seem to be used
> universally, but I suppose it's good enough.
>

The main practical drawback of this approach IMO is that we can't
guarantee that userspace processes will not step on each other's toes
trying to control the LED concurrently. But I guess that is something
that userspace will have to solve for now, I rather get this moving
without the trigger than not moving at all.

> João, that means you should send a patch to add the ::rfkill suffix.
>

IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
reflects the label on the machine's chassis. I'll name it
"asus-wireless::airplane" and send this through platform-drivers-x86,
as this is now contained in the platform-drivers-x86 subsystem. Thanks
Johannes for your patience and help designing and reviewing the rfkill
changes, even if not all of them made it through in the end. And
thanks everyone else involved for the feedback.

Best regards,

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

Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls

[Alexandre Belloni]

On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :
> On Saturday, June 11, 2016 12:03:04 AM CEST Alexandre Belloni wrote:
> > From: Cyrille Pitchen 
> > 
> > Fix the main and slow clock .prepare() implementations which used to call
> > usleep() when the scheduler wasn't ready yet.
> > 
> 
> Does this have to be called that early? It seems wasteful to always
> call udelay() here, when these are functions that are normally
> allowed to sleep.
> 

So I've tested it and something like that would work:

if (system_state < SYSTEM_RUNNING)
udelay(osc->startup_usec);
else
usleep_range(osc->startup_usec, osc->startup_usec + 1);

But I'm afraid it would be the first driver to actually do something
like that (however, it is already the only driver trying to sleep). 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v2 12/17] sh: Add PCI host bridge driver for SH7751

[Yoshinori Sato]

On Mon, 13 Jun 2016 17:38:28 +0900,
Arnd Bergmann wrote:
> 
> On Sunday, June 12, 2016 3:54:30 PM CEST Yoshinori Sato wrote:
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/sh7751-pci.txt
> > +   ranges = <0x0200 0x 0xfd00 0xfd00 
> > 0x 0x0100>,
> > +<0x0100 0x 0xfe24 0x 
> > 0x 0x0004>;
> > +   reg = <0xfe20 0x0400>,
> > + <0x0c00 0x0400>,
> > + <0xff80 0x0030>;
> > +   #interrupt-cells = <1>;
> > +   interrupt-map-mask = <0x1800 0 7>;
> > +   interrupt-map = <0x 0 1 &cpldintc evt2irq(0x2a0) 0
> > +0x 0 2 &cpldintc evt2irq(0x2c0) 0
> > +0x 0 3 &cpldintc evt2irq(0x2e0) 0
> > +0x 0 4 &cpldintc evt2irq(0x300) 0
> > +
> > +0x0800 0 1 &cpldintc evt2irq(0x2c0) 0
> > +0x0800 0 2 &cpldintc evt2irq(0x2e0) 0
> > +0x0800 0 3 &cpldintc evt2irq(0x300) 0
> > +0x0800 0 4 &cpldintc evt2irq(0x2a0) 0
> 
> Is this not the default swizzling? I would guess that you can just
> list the interrupt once.
> 
> The formatting is slightly inconsistent here, my recommendation is
> to always enclose each entry in '< >' so you have a comma-separated
> list.

OK.
I'll fix this.

> > +
> > +#define pcic_writel(val, reg) __raw_writel(val, pci_reg_base + (reg))
> > +#define pcic_readl(reg) __raw_readl(pci_reg_base + (reg))
> 
> We generally try not to use __raw_*() accessors in drivers, because
> they are not portable, lack barriers and atomicity, and don't work
> when you change endianess.

OK.
It cpied old style driver.
Update ioread/write.

> > +unsigned long PCIBIOS_MIN_IO;
> > +unsigned long PCIBIOS_MIN_MEM;
> 
> These should probably be in architecture code, otherwise you cannot
> build more than one such driver into the kernel.
> 
> > +DEFINE_RAW_SPINLOCK(pci_config_lock);
> 
> This seems unnecessary, the config operations are always called
> under a spinlock already.

OK.
remove it.

> > +static __initconst const struct fixups {
> > +   char *compatible;
> > +   void (*fixup)(void __iomem *, void __iomem *);
> > +} fixup_list[] = {
> > +   {
> > +   .compatible = "iodata,landisk",
> > +   .fixup = landisk_fixup,
> > +   },
> > +};
> 
> Just move the fixup pointer into the existing of match table
> as the .data pointer, or add a structure to which .data
> points.

OK.

> > +/*
> > + * Functions for accessing PCI configuration space with type 1 accesses
> > + */
> > +static int sh4_pci_read(struct pci_bus *bus, unsigned int devfn,
> > +  int where, int size, u32 *val)
> > +{
> > +   struct gen_pci *pci = bus->sysdata;
> > +   void __iomem *pci_reg_base;
> > +   unsigned long flags;
> > +   u32 data;
> > +
> > +   pci_reg_base = ioremap(pci->cfg.res.start,
> > +  pci->cfg.res.end - pci->cfg.res.start);
> 
> You cannot call normally ioremap from pci_read, because it
> gets called under a spinlock and ioremap can normally sleep
> (that might be architecture specific).
> 
> Better map it a probe time, or use fixmap.

OK.

> > +   /*
> > +* PCIPDR may only be accessed as 32 bit words,
> > +* so we must do byte alignment by hand
> > +*/
> > +   raw_spin_lock_irqsave(&pci_config_lock, flags);
> > +   pcic_writel(CONFIG_CMD(bus, devfn, where), SH4_PCIPAR);
> > +   data = pcic_readl(SH4_PCIPDR);
> > +   raw_spin_unlock_irqrestore(&pci_config_lock, flags);
> 
> This is shorter to express this using a 'map' function
> in pci_ops combined with pci_generic_config_read32
> and pci_generic_config_write32.

OK.

> > +/*
> > + * Called after each bus is probed, but before its children
> > + * are examined.
> > + */
> > +void pcibios_fixup_bus(struct pci_bus *bus)
> > +{
> > +}
> 
> This doesn't really belong into the driver.

OK.

> > +/*
> > + * We need to avoid collisions with `mirrored' VGA ports
> > + * and other strange ISA hardware, so we always want the
> > + * addresses to be allocated in the 0x000-0x0ff region
> > + * modulo 0x400.
> > + */
> > +resource_size_t pcibios_align_resource(void *data,
> > +  const struct resource *res,
> > +  resource_size_t size,
> > +  resource_size_t align)
> > +{
> > +   resource_size_t start = res->start;
> > +
> > +   return start;
> > +}
> 
> The comment does not match what the function does, you should
> change one or the other. Also move it to the same file as
> pcibios_fixup_bus.

OK.
This part copied old driver.
I will cleanup.

> > +int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> > +   enum pci_mmap_state mmap_state, int write_combine)
> > +{
> > +   /*
> > +* I/O space can be accessed via no

[PATCH] drm: bridge/dw-hdmi: Add support for DWC Phy

[Jose Abreu]

This patch adds support for the Synopsys HDMI TX Phy in
bridge dw-hdmi.

The init flow is the same as the Rockchip Phy so we
only need to add one define and one if statement.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
 include/drm/bridge/dw_hdmi.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index c9d9412..13e33ea 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -833,7 +833,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   if (hdmi->dev_type == RK3288_HDMI)
+   if ((hdmi->dev_type == RK3288_HDMI) || (hdmi->dev_type == DWC_HDMI))
dw_hdmi_phy_enable_spare(hdmi, 1);
 
/*Wait for PHY PLL lock */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3..6e4fb2e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -25,6 +25,7 @@ enum dw_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
RK3288_HDMI,
+   DWC_HDMI,
 };
 
 struct dw_hdmi_mpll_config {
-- 
2.1.4

Re: [PATCH v13 05/10] arm64: Kprobes with single stepping support

[David Long]

On 06/13/2016 02:50 AM, Masami Hiramatsu wrote:

On Mon, 13 Jun 2016 00:10:29 -0400
David Long  wrote:


---
   arch/arm64/Kconfig  |   1 +
   arch/arm64/include/asm/debug-monitors.h |   5 +
   arch/arm64/include/asm/insn.h   |   4 +-
   arch/arm64/include/asm/kprobes.h|  60 
   arch/arm64/include/asm/probes.h |  44 +++
   arch/arm64/kernel/Makefile  |   1 +
   arch/arm64/kernel/debug-monitors.c  |  18 +-
   arch/arm64/kernel/kprobes-arm64.c   | 144 +
   arch/arm64/kernel/kprobes-arm64.h   |  35 +++
   arch/arm64/kernel/kprobes.c | 526 



Not sure why kprobes.c and kprobes-arm64.c are splitted.




This comes from the model of the arm32 kprobes code where handling of
the low-level instruction simulation is implemented in separate files
for 32-bit vs. thumb instructions.  It should make a little more sense
in the future when additional instruction simulation code will hopefully
be added for those instructions we cannot currently single-step
out-of-line.  It also probably *could* be merged into one file.


Hmm, at least the name of arch/arm64/kernel/kprobes-arm64.c is
meaningless. As we've done in x86, I think we can make it
arch/arm64/kernel/kprobes/decode-insn.{c,h}



I've changed the name to kprobe-decode-insn.[hc], or do you feel 
strongly the three kprobes source files in arch/arm64/kernel need their 
own subdirectory?




[..]

+
+/* Return:
+ *   INSN_REJECTED If instruction is one not allowed to kprobe,
+ *   INSN_GOOD If instruction is supported and uses instruction slot,
+ *   INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.


Is there any chance to return INSN_GOOD_NO_SLOT?



Ah, that gets used later when simulation support is added.  I've removed
this enum value from this commit and will add it to the later one.
Please no one complain about using an enum instead of a bool, it will
eventually have three possible values.


OK :)

[..]

+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
+{
+   enum kprobe_insn decoded;
+   kprobe_opcode_t insn = le32_to_cpu(*addr);
+   kprobe_opcode_t *scan_start = addr - 1;
+   kprobe_opcode_t *scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+   struct module *mod;
+#endif
+
+   if (addr >= (kprobe_opcode_t *)_text &&
+   scan_end < (kprobe_opcode_t *)_text)
+   scan_end = (kprobe_opcode_t *)_text;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+   else {
+   preempt_disable();
+   mod = __module_address((unsigned long)addr);
+   if (mod && within_module_init((unsigned long)addr, mod) &&
+   !within_module_init((unsigned long)scan_end, mod))
+   scan_end = (kprobe_opcode_t *)mod->init_layout.base;
+   else if (mod && within_module_core((unsigned long)addr, mod) &&
+   !within_module_core((unsigned long)scan_end, mod))
+   scan_end = (kprobe_opcode_t *)mod->core_layout.base;


What happen if mod == NULL? it should be return error, isn't it?



No, it should be fine.  It just means it didn't have to do either of the
extra checks to limit the end of the search through the code to the
boundary of one of the corresponding module text sections. It means the
instruction is in the regular kernel (non-module) text segment.


Ah, I see. It is OK then. :)

Thank you,




Thanks,
-dl

[PATCH 1/2] pinctrl: fix incorrect inline keyword in multiple drivers

[Arnd Bergmann]

When building with 'make W=1', we get harmless warnings about
five drivers in drivers/pinctrl, which all contain a copy of
the same line:

drivers/pinctrl/freescale/pinctrl-imx1-core.c:160:1: error: 'inline' is not at 
beginning of declaration [-Werror=old-style-declaration]

This replaces the somewhat nonstandard 'static const inline'
with 'static inline const', which has the same meaning but
does not cause this warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/pinctrl/freescale/pinctrl-imx.c   | 2 +-
 drivers/pinctrl/freescale/pinctrl-imx1-core.c | 2 +-
 drivers/pinctrl/pinctrl-at91.c| 2 +-
 drivers/pinctrl/pinctrl-rockchip.c| 2 +-
 drivers/pinctrl/pinctrl-st.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index 309d31d61390..491d2d244f56 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -46,7 +46,7 @@ struct imx_pinctrl {
const struct imx_pinctrl_soc_info *info;
 };
 
-static const inline struct imx_pin_group *imx_pinctrl_find_group_by_name(
+static inline const struct imx_pin_group *imx_pinctrl_find_group_by_name(
const struct imx_pinctrl_soc_info *info,
const char *name)
 {
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c 
b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
index b4400cb19b61..38d39388d7a4 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
@@ -157,7 +157,7 @@ static int imx1_read_bit(struct imx1_pinctrl *ipctl, 
unsigned int pin_id,
return !!(readl(reg) & BIT(offset));
 }
 
-static const inline struct imx1_pin_group *imx1_pinctrl_find_group_by_name(
+static inline const struct imx1_pin_group *imx1_pinctrl_find_group_by_name(
const struct imx1_pinctrl_soc_info *info,
const char *name)
 {
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index b7c0d6f7c046..2ce429cf41e6 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -189,7 +189,7 @@ struct at91_pinctrl {
struct at91_pinctrl_mux_ops *ops;
 };
 
-static const inline struct at91_pin_group *at91_pinctrl_find_group_by_name(
+static inline const struct at91_pin_group *at91_pinctrl_find_group_by_name(
const struct at91_pinctrl *info,
const char *name)
 {
diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index a91026e8cd7c..a2337b7dfc41 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -360,7 +360,7 @@ static struct regmap_config rockchip_regmap_config = {
.reg_stride = 4,
 };
 
-static const inline struct rockchip_pin_group *pinctrl_name_to_group(
+static inline const struct rockchip_pin_group *pinctrl_name_to_group(
const struct rockchip_pinctrl *info,
const char *name)
 {
diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index d0ba968af5bb..0de1c67dfb94 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -844,7 +844,7 @@ static int st_pctl_get_group_pins(struct pinctrl_dev 
*pctldev,
return 0;
 }
 
-static const inline struct st_pctl_group *st_pctl_find_group_by_name(
+static inline const struct st_pctl_group *st_pctl_find_group_by_name(
const struct st_pinctrl *info, const char *name)
 {
int i;
-- 
2.7.0

[PATCH -next] rcutorture: Fix error return code in rcu_perf_init()

[weiyj_lk]

From: Wei Yongjun 

Fix to return a negative error code -ENOMEM from kcalloc() error
handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 kernel/rcu/rcuperf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 7b2dbdf..d38ab08 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -638,8 +638,10 @@ rcu_perf_init(void)
writer_durations[i] =
kcalloc(MAX_MEAS, sizeof(*writer_durations[i]),
GFP_KERNEL);
-   if (!writer_durations[i])
+   if (!writer_durations[i]) {
+   firsterr = -ENOMEM;
goto unwind;
+   }
firsterr = torture_create_kthread(rcu_perf_writer, (void *)i,
  writer_tasks[i]);
if (firsterr)

Re: [patch 18/20] timer: Forward wheel clock whenever possible

[Thomas Gleixner]

On Mon, 13 Jun 2016, Richard Cochran wrote:
> On Mon, Jun 13, 2016 at 08:41:04AM -, Thomas Gleixner wrote:
> > @@ -498,23 +500,27 @@ static void internal_add_timer(struct ti
> > __internal_add_timer(base, timer);
> >  
> > /*
> > -* Check whether the other CPU is in dynticks mode and needs
> > -* to be triggered to reevaluate the timer wheel.  We are
> > -* protected against the other CPU fiddling with the timer by
> > -* holding the timer base lock. This also makes sure that a
> > -* CPU on the way to stop its tick can not evaluate the timer
> > -* wheel.
> > -*
> > -* Spare the IPI for deferrable timers on idle targets though.
> > -* The next busy ticks will take care of it. Except full dynticks
> > -* require special care against races with idle_cpu(), lets deal
> > -* with that later.
> > -*/
> > -   if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active) {
> > -   if (!(timer->flags & TIMER_DEFERRABLE) ||
> > -   tick_nohz_full_cpu(base->cpu))
> > -   wake_up_nohz_cpu(base->cpu);
> > -   }
> > +* We might have to IPI the remote CPU if the base is idle and the
> > +* timer is not deferrable. If the other cpu is on the way to idle
> > +* then it can't set base->is_idle as we hold base lock.
> > +*/
> > +   if (!IS_ENABLED(CONFIG_NO_HZ_COMMON) || !base->is_idle ||
> > +   (timer->flags & TIMER_DEFERRABLE))
> > +   return;
> 
> The tests for is_idle and TIMER_DEFERRABLE are actually checking the
> same thing.  I was looking at the usage of base.is_idle, and it is
> only ever set for BASE_STD.
> 
> So the TIMER_DEFERRABLE test is redundant, but maybe this is on
> purpose?  Anyhow, it did leave me scratching my head.

You're right. is_idle makes the deferrable check obsolete. We can remove it,
but it needs a big fat comment 

Thanks

tglx

[PATCH 2/2] pinctrl: max77620: select PINMUX

[Arnd Bergmann]

The recently added max77620 driver fails to build when CONFIG_PINMUX
is not set:

pinctrl/pinctrl-max77620.c:272:21: error: variable 'max77620_pinmux_ops' has 
initializer but incomplete type
 static const struct pinmux_ops max77620_pinmux_ops = {
 ^~
pinctrl/pinctrl-max77620.c:273:2: error: unknown field 'get_functions_count' 
specified in initializer

This adds the Kconfig 'select' statement that was clearly meant
to be there and is used in all other pinmux drivers.

Signed-off-by: Arnd Bergmann 
---
 drivers/pinctrl/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ea25eeeceef1..78c9ed277a77 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -210,6 +210,7 @@ config PINCTRL_COH901
 config PINCTRL_MAX77620
tristate "MAX77620/MAX20024 Pincontrol support"
depends on MFD_MAX77620
+   select PINMUX
select GENERIC_PINCONF
help
  Say Yes here to enable Pin control support for Maxim PMIC MAX77620.
-- 
2.7.0

Re: [patch 18/20] timer: Forward wheel clock whenever possible

[Richard Cochran]

Thomas,

On Mon, Jun 13, 2016 at 08:41:04AM -, Thomas Gleixner wrote:
> @@ -498,23 +500,27 @@ static void internal_add_timer(struct ti
>   __internal_add_timer(base, timer);
>  
>   /*
> -  * Check whether the other CPU is in dynticks mode and needs
> -  * to be triggered to reevaluate the timer wheel.  We are
> -  * protected against the other CPU fiddling with the timer by
> -  * holding the timer base lock. This also makes sure that a
> -  * CPU on the way to stop its tick can not evaluate the timer
> -  * wheel.
> -  *
> -  * Spare the IPI for deferrable timers on idle targets though.
> -  * The next busy ticks will take care of it. Except full dynticks
> -  * require special care against races with idle_cpu(), lets deal
> -  * with that later.
> -  */
> - if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active) {
> - if (!(timer->flags & TIMER_DEFERRABLE) ||
> - tick_nohz_full_cpu(base->cpu))
> - wake_up_nohz_cpu(base->cpu);
> - }
> +  * We might have to IPI the remote CPU if the base is idle and the
> +  * timer is not deferrable. If the other cpu is on the way to idle
> +  * then it can't set base->is_idle as we hold base lock.
> +  */
> + if (!IS_ENABLED(CONFIG_NO_HZ_COMMON) || !base->is_idle ||
> + (timer->flags & TIMER_DEFERRABLE))
> + return;

The tests for is_idle and TIMER_DEFERRABLE are actually checking the
same thing.  I was looking at the usage of base.is_idle, and it is
only ever set for BASE_STD.

So the TIMER_DEFERRABLE test is redundant, but maybe this is on
purpose?  Anyhow, it did leave me scratching my head.

Thanks,
Richard

Re: [PATCH v3 2/3] x86/platform/p2sb: New Primary to Sideband bridge support driver for Intel SOC's

[Andy Shevchenko]

On Mon, 2016-06-13 at 17:25 +0300, Mika Westerberg wrote:
> On Mon, Jun 13, 2016 at 04:54:31PM +0300, Andy Shevchenko wrote:
> > Would work to me, though still the same question: is it possible to
> > avoid building it on even most of Intel platforms, since there, I
> > assume, will be not many users of the module?
> 
> Well, even if you make it configurable via Kconfig, I guess distros
> will
> have to enable it in order to support as wide range of CPUs as
> possible
> in a single binary.

Good point.

Then perhaps the following we can do:
 - add a static boolean flag
 - add __init function where we check either PCI root bridge ID or CPU
ID (I don't know which one is better, I suppose second one, though it
will require an update of arch/x86/include/asm/intel-family.h)
 - add a check into the function.

What do you think?

-- 

Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v2 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Andrew F. Davis]

On 06/13/2016 03:22 AM, Mugunthan V N wrote:
> On Saturday 11 June 2016 04:34 AM, Schuyler Patton wrote:
>>
>>
>> On 06/08/2016 07:03 PM, Ivan Khoronzhuk wrote:
>>>
>>>
>>> On 09.06.16 02:11, Schuyler Patton wrote:


 On 06/08/2016 09:06 AM, Ivan Khoronzhuk wrote:
>
>
> On 08.06.16 17:01, Ivan Khoronzhuk wrote:
>> Hi Schuyer,
>>
>> On 07.06.16 18:26, Schuyler Patton wrote:
>>> Hi,
>>>
>>> On 06/07/2016 08:59 AM, Ivan Khoronzhuk wrote:
 There is no reason in rx_descs property because davinici_cpdma
 driver splits pool of descriptors equally between tx and rx
 channels.
 So, this patch series makes driver to use available number of
 descriptors for rx channels.
>>>
>>> I agree with the idea of consolidating how the descriptors are
>>> defined because of
>>> the two variable components, number and size of the pool can be
>>> confusing to
>>> end users. I would like to request to change how it is being
>>> proposed here.
>>>
>>> I think the number of descriptors should be left in the device
>>> tree source file as
>>> is and remove the BD size variable and have the driver calculate
>>> the size of the
>>> pool necessary to support the descriptor request. From an user
>>> perspective it is
>>> easier I think to be able to list the number of descriptors
>>> necessary vs. the size
>>> of the pool.
>>>
>>> Since the patch series points out how it is used so in the driver
>>> so to make that
>>> consistent is perhaps change rx_descs to total_descs.
>>>
>>> Regards,
>>> Schuyler
>>
>> The DT entry for cpsw doesn't have property for size of the pool.
>> It contains only BD ram size, if you mean this. The size of the
>> pool is
>> software decision. Current version of DT entry contain only rx desc
>> number.
>> That is not correct, as it depends on the size of the descriptor,
>> which is also
>> h/w parameter. The DT entry has to describe only h/w part and
>> shouldn't contain
>> driver implementation details, and I'm looking on it from this
>> perspective.
>>
>> Besides, rx_descs describes only rx number of descriptors, that are
>> taken from
>> the same pool as tx descriptors, and setting rx desc to some new
>> value doesn't
>> mean that rest of them are freed for tx. Also, I'm going to send
>> series that
>> adds multi channel support to the driver, and in this case,
>> splitting of the
>> pool will be more sophisticated than now, after what setting those
>> parameters
>> for user (he should do this via device tree) can be even more
>> confusing. But,
> should -> shouldn't
>
>> as it's supposed, it's software decision that shouldn't leak to the
>> DT.

 If this rx-desc field is removed how will the number of descriptors
 be set?

 This field has been used to increase the number of descriptors so high
 volume short packets are not dropped due to descriptor exhaustion.
 The current
 default number of 64 rx descriptors is too low for gigabit networks.
 Some users
 have a strong requirement for zero loss of UDP packets setting this
 field to a
 larger number and setting the descriptors off-chip was a means to solve
 the problem.
>>> The current implementation of cpdma driver splits descs num on 2 parts
>>> equally.
>>> Total number = 256, then 128 reserved for rx and 128 for tx, but
>>> setting this to
>>> 64, simply limits usage of reserved rx descriptors to 64, so that:
>>> 64 rx descs, 128 tx descs and 64 are always present in the pool but
>>> cannot be used,
>>> (as new rx descriptor is allocated only after previous was freed).
>>> That means, 64 rx descs are unused. In case of rx descriptor
>>> exhaustion, an user can
>>> set rx_descs to 128, for instance, in this case all descriptors will
>>> be in use, but then question,
>>> why intentionally limit number of rx descs, anyway rest 64 descs
>>> cannot be used for other
>>> purposes. In case of this patch, all rx descs are in use, and no need
>>> to correct number
>>> of rx descs anymore, use all of themand it doesn't have impact on
>>> performance, as
>>> anyway, bunch of rx descs were simply limited by DT and unused. So,
>>> probably, there is no
>>> reason to worry about that.
>>
>> When we see this issue we set the descriptors to DDR and put a large number
>> in the desc count. unfortunately I wish I could provide a number,
>> usually the issue
>> is a volume burst of short UDP packets.
>>
>>>
>>> PS:
>>> It doesn't concern this patch, but, which PPS makes rx descs to be
>>> exhausted?...
>>> (In this case "desc_alloc_fail" counter contains some value for rx
>>> channel,
>>> and can be read with "ethtool -S eth0". Also, the user will be WARNed
>>> ON by the driver)
>>>
>>> it's interesting to test it, I'm worryi

RE: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget
> supporting for usb charger
> 
> When the usb gadget supporting for usb charger is ready, the usb charger
> can implement the usb_charger_plug_by_gadget() function and
> usb_charger_exit() function by getting 'struct usb_charger' from 'struct
> gadget'.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/charger.c |   39
> +-
>  1 file changed, 38 insertions(+), 1 deletion(-)

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

[Tom Lendacky]

On 06/13/2016 07:03 AM, Matt Fleming wrote:
> On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote:
>>
>> So maybe something along the lines of an enum that would have entries
>> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could
>> be added later as needed.
>  
> Sure, that works for me, though maybe BOOT_DATA would be more
> applicable considering the devicetree case too.
> 
>> Would you then want to allow the protection attributes to be updated
>> by architecture specific code through something like a __weak function?
>> In the x86 case I can add this function as a non-SME specific function
>> that would initially just have the SME-related mask modification in it.
> 
> Would we need a new function? Couldn't we just have a new
> FIXMAP_PAGE_* constant? e.g. would something like this work?

Looking forward to the virtualization support (SEV), the VM will be
completely encrypted from the time it is started. In this case all of
the UEFI data will be encrypted and I would need to insure that the
mapping reflects that. When I do the SEV patches, I can change the
FIXMAP #define to add some logic to return a value, so I think the
FIXMAP_PAGE_ idea can work.

Thanks,
Tom

> 
> ---
> 
> enum memremap_owner {
>   KERNEL_DATA = 0,
>   BOOT_DATA,
> };
> 
> void __init *
> early_memremap(resource_size_t phys_addr, unsigned long size,
>  enum memremap_owner owner)
> {
>   pgprot_t prot;
> 
>   switch (owner) {
>   case BOOT_DATA:
>   prot = FIXMAP_PAGE_BOOT;
>   break;
>   case KERNEL_DATA:   /* FALLTHROUGH */
>   default:
>   prot = FIXMAP_PAGE_NORMAL;
>   
>   }
> 
>   return (__force void *)__early_ioremap(phys_addr, size, prot);
> }
> 

Re: [PATCH v1 1/1] ipv4: Prevent malformed UFO fragments in ip_append_page

[Eric Dumazet]

On Mon, 2016-06-13 at 14:01 +, Steven Caron wrote:
> As  the ip fragment offset field counts 8-byte chunks, non-final ip
> fragments must be multiples of 8 bytes of payload. Depending  on the
> mtu and ip option sizes, ip_append_page wasn't respecting this,
> notably when running NFS under UDP.
> 
> Signed-off-by: Steven Caron 
> ---

Acked-by: Eric Dumazet 

Re: [RFC PATCH 1/2] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_HARD with more useful semantic

[Michal Hocko]

On Mon 13-06-16 23:54:13, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Sat 11-06-16 23:35:49, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Tue 07-06-16 21:11:03, Tetsuo Handa wrote:
> > > > > Remaining __GFP_REPEAT users are not always doing costly allocations.
> > > > 
> > > > Yes but...
> > > > 
> > > > > Sometimes they pass __GFP_REPEAT because the size is given from 
> > > > > userspace.
> > > > > Thus, unconditional s/__GFP_REPEAT/__GFP_RETRY_HARD/g is not good.
> > > > 
> > > > Would that be a regression though? Strictly speaking the __GFP_REPEAT
> > > > documentation was explicit to not loop for ever. So nobody should have
> > > > expected nofail semantic pretty much by definition. The fact that our
> > > > previous implementation was not fully conforming to the documentation is
> > > > just an implementation detail.  All the remaining users of __GFP_REPEAT
> > > > _have_ to be prepared for the allocation failure. So what exactly is the
> > > > problem with them?
> > > 
> > > A !costly allocation becomes weaker than now if __GFP_RETRY_HARD is 
> > > passed.
> > 
> > That is true. But it is not weaker than the __GFP_REPEAT actually ever
> > promissed. __GFP_REPEAT explicitly said to not retry _for_ever_. The
> > fact that we have ignored it is sad but that is what I am trying to
> > address here.
> 
> Whatever you rename __GFP_REPEAT to, it sounds strange to me that !costly
> __GFP_REPEAT allocations are weaker than !costly !__GFP_REPEAT allocations.
> Are you planning to make !costly !__GFP_REPEAT allocations to behave like
> __GFP_NORETRY?

The patch description tries to explain the difference:
__GFP_NORETRY doesn't retry at all
__GFP_RETRY_HARD retries as hard as feasible
__GFP_NOFAIL tells the retry for ever

all of them regardless of the order. This is the way how to tell the
allocator to change its default behavior which might be, and actually
is, different depending on the order.

[...]
> > > That _somebody_ might release oom_lock without invoking the OOM killer 
> > > (e.g.
> > > doing !__GFP_FS allocation), which means that we have reached the OOM 
> > > condition
> > > and nobody is actually handling the OOM on our behalf. __GFP_RETRY_HARD 
> > > becomes
> > > as weak as __GFP_NORETRY. I think this is a regression.
> > 
> > I really fail to see your point. We are talking about a gfp flag which
> > tells the allocator to retry as much as it is feasible. Getting through
> > all the reclaim attempts two times without any progress sounds like a
> > fair criterion. Well, we could try $NUM times but that wouldn't make too
> > much difference to what you are writing above. The fact whether somebody
> > has been killed or not is not really that important IMHO.
> 
> If all the reclaim attempt first time made no progress, all the reclaim
> attempt second time unlikely make progress unless the OOM killer kills
> something. Thus, doing all the reclaim attempts two times without any progress
> without killing somebody sounds almost equivalent to doing all the reclaim
> attempt only once.

Yes, that is possible. You might have a GFP_NOFS only load where nothing
really invokes the OOM killer. Does that actually matter, though? The
semantic of the flag is to retry hard while the page allocator believes
it can make a forward progress. But not for ever. We never know whether
a progress is possible at all. We have certain heuristics when to give
up, try to invoke OOM killer and try again hoping things have changed.
This is not much different except we declare that no hope to getting to
the OOM point again without being able to succeed. Are you suggesting
a more precise heuristic? Or do you claim that we do not need a flag
which would put a middle ground between __GFP_NORETRY and __GFP_NOFAIL
which are on the extreme sides?

-- 
Michal Hocko
SUSE Labs

Re: Using irq-crossbar.c

[Sebastian Frias]

Hi Marc,

Thanks for your input, please find my comments below.

On 06/11/2016 11:58 AM, Marc Zyngier wrote:
>> I think Sebastian is even more baffled by the DT mess
>> (sorry, intricacies) than I am.
> 
> This mess is what has saved us from the apocalypse 5 years ago, and
> describing a complex system is not easy (what a surprise...). If you
> just want to apply recipes without understanding the underlying
> constraints, you're in for a lot of pain.

Nobody said we wanted a recipe, but it would help to have examples of each of 
the configurations supported.
Indeed, there is effort in writing the DT bindings and even 
Documentation/IRQ-domain.txt yet I did not see example drivers for the 
different configurations.
Also, it is difficult to know what is the recommended way, since old APIs are 
kept for a while.

APIs are usually extended/designed around specific cases, so there must be 
examples, but they are not easy to find.

> 
>> The base file he was referring to is:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-common.dtsi
> 
> I know which file that is, it is mentioned in the diff. I was merely
> trying to point out the glaring mistakes that could be enough for a
> interrupt controller hierarchy to be completely non-functional:
> 
> - Your crossbar doesn't have a #interrupt-cells property. How do you
>   expect the interrupt specifiers to be interpreted?

Thanks for the pointer, actually, after adding "#interrupt-cells = <3>;" I can 
see the driver getting requests for domain maps and xlates :-)

> - You've changed the default interrupt controller to be your crossbar.
>   Which means that all the sub-nodes are inheriting it. Have you
>   checked that this was valid for all of these nodes?

What do you mean with "valid for all these nodes"? All HW irq lines go to the 
crossbar.

> 
> And as it has been pointed out before, you seem to be reusing an
> existing driver. Do you know for sure that the usage constraints are
> similar?

It is not being reused as is, I just thought (incorrectly apparently) that it 
was a good example for our case.

Best regards,

Sebastian

[PATCH 1/2] arm64: defconfig: enable SENSORS_ARM_SCPI

[Javi Merino]

ARM SCPI Sensors were merged for v4.4 and they are defined in the Juno
dts.  Enable it in the defconfig to get them registered automatically in
Juno by default.

Signed-off-by: Javi Merino 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index fd2d74d0491e..1152c6d9f6e6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -197,6 +197,7 @@ CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_SENSORS_LM90=m
 CONFIG_SENSORS_INA2XX=m
+CONFIG_SENSORS_ARM_SCPI=y
 CONFIG_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_EXYNOS_THERMAL=y
-- 
1.9.1

[PATCH 2/2] arm64: dts: juno: add thermal zones for scpi sensors

[Javi Merino]

The juno dts have entries for the hwmon scpi, let's create thermal zones
for the temperature sensors described in the Juno ARM Development
Platform Implementation Details.

Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Javi Merino 
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 42 ++
 arch/arm64/boot/dts/arm/juno-r1.dts| 16 +
 arch/arm64/boot/dts/arm/juno-r2.dts| 16 +
 3 files changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi 
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index dee2386d3b9b..61ec045125ce 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -125,6 +125,48 @@
};
};
 
+   thermal-zones {
+   pmic {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 0>;
+   };
+
+   soc {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 3>;
+   };
+
+   big_cluster_thermal_zone: big_cluster {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 21>;
+   status = "disabled";
+   };
+
+   little_cluster_thermal_zone: little_cluster {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 22>;
+   status = "disabled";
+   };
+
+   gpu0_thermal_zone: gpu0 {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 23>;
+   status = "disabled";
+   };
+
+   gpu1_thermal_zone: gpu1 {
+   polling-delay = <1000>;
+   polling-delay-passive = <100>;
+   thermal-sensors = <&scpi_sensors0 24>;
+   status = "disabled";
+   };
+   };
+
/include/ "juno-clocks.dtsi"
 
dma@7ff0 {
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts 
b/arch/arm64/boot/dts/arm/juno-r1.dts
index d95d9e7e2dc0..0f9c32ae1ce9 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -181,3 +181,19 @@
 &pcie_ctlr {
status = "okay";
 };
+
+&big_cluster_thermal_zone {
+   status = "okay";
+};
+
+&little_cluster_thermal_zone {
+   status = "okay";
+};
+
+&gpu0_thermal_zone {
+   status = "okay";
+};
+
+&gpu1_thermal_zone {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts 
b/arch/arm64/boot/dts/arm/juno-r2.dts
index 88ecd6182b67..f20cf5654cca 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -181,3 +181,19 @@
 &pcie_ctlr {
status = "okay";
 };
+
+&big_cluster_thermal_zone {
+   status = "okay";
+};
+
+&little_cluster_thermal_zone {
+   status = "okay";
+};
+
+&gpu0_thermal_zone {
+   status = "okay";
+};
+
+&gpu1_thermal_zone {
+   status = "okay";
+};
-- 
1.9.1

[PATCH 0/2] Enable SCPI sensors for Juno

[Javi Merino]

Enable the ARM SCPI sensors in arm64 defconfig and add thermal zones
for the thermal scpi sensors on Juno.  The hwmon support for SCPI
sensors was merged for v4.4, this just enables it by default.

Javi Merino (2):
  arm64: defconfig: enable SENSORS_ARM_SCPI
  arm64: dts: juno: add thermal zones for scpi sensors

 arch/arm64/boot/dts/arm/juno-base.dtsi | 42 ++
 arch/arm64/boot/dts/arm/juno-r1.dts| 16 +
 arch/arm64/boot/dts/arm/juno-r2.dts| 16 +
 arch/arm64/configs/defconfig   |  1 +
 4 files changed, 75 insertions(+)

-- 
1.9.1

RE: [RESEND PATCH v11 2/4] gadget: Support for the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 2/4] gadget: Support for the usb charger
> framework
> 
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
> 
> It will report to the usb charger when the gadget state is changed, then
> the usb charger can do the power things.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/udc-core.c |   11 +++
>  include/linux/usb/gadget.h|   11 +++
>  2 files changed, 22 insertions(+)

Re: [PATCH 1/1] btrfs: Use correct format specifier

[David Sterba]

On Sat, Jun 11, 2016 at 06:11:10PM +0200, Heinrich Schuchardt wrote:
> Component mirror_num of struct btrfsic_block is defined
> as unsigned int. Use %u as format specifier.
> 
> Signed-off-by: Heinrich Schuchardt 
Reviewed-by: David Sterba 

RE: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[okaya]

On 2016-06-13 10:29, Gabriele Paoloni wrote:

Hi Sinan


-Original Message-
From: Sinan Kaya [mailto:ok...@codeaurora.org]
Sent: 13 June 2016 15:03
To: Gabriele Paoloni; liudongdong (C); helg...@kernel.org;
a...@arndb.de; will.dea...@arm.com; catalin.mari...@arm.com;
raf...@kernel.org; hanjun@linaro.org; lorenzo.pieral...@arm.com;
jchan...@broadcom.com; t...@semihalf.com
Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing;
suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org;
dhd...@apm.com; jeremy.lin...@arm.com; c...@codeaurora.org; Chenxin
(Charles); Linuxarm
Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
accessors against platfrom specific ECAM quirks

On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
> As you can see here Liudongdong has replaced oem_revision with
> oem_table_id.
>
> Now it seems that there are some platforms that have already shipped
> using a matching based on the oem_revision (right Jon?)
>
> However I guess that if in FW they have defined oem_table_id properly
> they should be able to use this mechanism without needing to a FW
update.
>
> Can these vendors confirm this?
>
> Tomasz do you think this can work for Cavium Thunder?
>
> Thanks
>
> Gab

Why not have all three of them?

The initial approach was OEM id and revision id.

Jeff Hugo indicated that addition (not removing any other fields) of
table id
would make more sense.


Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
PCI config space accessors against platfrom specific ECAM quirks."

I quote:

 "Using the OEM revision
 field does not seem to be appropriate since these are different
 platforms and the revision field appears to be for the purpose of
 tracking differences within a single platform.  Therefore, Cov is
 proposing using the OEM table id as a mechanism to distinguish
 platform A (needs quirk applied) vs platform B (no quirks) from the
 same OEM."

So it looks to me that he pointed out that using the OEM revision field
is wrong...and this is why I have asked if replacing it with the table
id can work for other vendors

Thanks

Gab



I had an internal discussion with jeff and cov before posting on the 
maillist.


I think there is missing info in the email.

Usage of oem id + table id + revision is ok.

Usage of oem id + revision is not ok as one oem can build multiple chips 
with the same oem id and revision id but different table id. Otherwise, 
we can run out of revisions very quickly.






--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

Re: [PATCH v8 02/12] kthread: Kthread worker API cleanup

[Petr Mladek]

On Fri 2016-06-10 15:29:05, Andrew Morton wrote:
> On Thu, 9 Jun 2016 11:07:10 -0400 Steven Rostedt  wrote:
> 
> > On Thu,  9 Jun 2016 15:51:56 +0200
> > Petr Mladek  wrote:
> > 
> > > A good practice is to prefix the names of functions and macros
> > > by the name of the subsystem.
> > > 
> > > The kthread worker API is a mix of classic kthreads and workqueues.
> > > Each worker has a dedicated kthread. It runs a generic function
> > > that process queued works. It is implemented as part of
> > > the kthread subsystem.
> > > 
> > > This patch renames the existing kthread worker API to use
> > > the corresponding name from the workqueues API prefixed by
> > > kthread_/KTHREAD_:
> > > 
> > > DEFINE_KTHREAD_WORKER()   -> KTHREAD_DECLARE_WORKER()
> > > DEFINE_KTHREAD_WORK() -> KTHREAD_DECLARE_WORK()
> > > DEFINE_KTHREAD_WORKER_ONSTACK()   -> KTHREAD_DECLARE_WORKER_ONSTACK()
> > > DEFINE_KTHREAD_WORKER_ONSTACK()   -> KTHREAD_DECLARE_WORKER_ONSTACK()
> > > __init_kthread_worker()   -> __kthread_init_worker()
> > > init_kthread_worker() -> kthread_init_worker()
> > > init_kthread_work()   -> kthread_init_work()
> > > insert_kthread_work() -> kthread_insert_work()
> > > queue_kthread_work()  -> kthread_queue_work()
> > > flush_kthread_work()  -> kthread_flush_work()
> > > flush_kthread_worker()-> kthread_flush_worker()
> > > 
> > 
> > I know that Andrew suggested this, but I didn't get a chance to respond
> > to his email due to traveling.
> > 
> > Does this mean we are going to change all APIs like this? Because we
> > pretty much use this type of naming everywhere. That is, we start with
> > "DEFINE_*" and "DECLARE_*" commonly. As well as "init_*".
> > 
> > For example DEFINE_PER_CPU(), DEFINE_SPINLOCK(), DEFINE_LGLOCK(),
> > DEFINE_MUTEX(), DEFINE_RES_MEME(), DEFINE_TIMER(), DEFINE_IDA(),
> > DEFINE_NFS4_*(), and the list goes on. Just do a grep in
> > include/linux/*.h for DEFINE_ and DECLARE_.
> 
> Yes, there's so much precedence that DEFINE_KTHREAD_WORKER() and
> friends can/should be left as-is.
> 
> But I do think that init_kthread_worker() is a sore thumb and should
> become kthread_worker_init() (not kthread_worker_init())

OK, all wants to keep DEFINE stuff as is:

  DEFINE_KTHREAD_WORKER()   stay
  DEFINE_KTHREAD_WORK() stay
  DEFINE_KTHREAD_WORKER_ONSTACK()   stay
  DEFINE_KTHREAD_WORKER_ONSTACK()   stay


Nobody was against renaming the non-init functions:

  insert_kthread_work() -> kthread_insert_work()
  queue_kthread_work()  -> kthread_queue_work()
  flush_kthread_work()  -> kthread_flush_work()
  flush_kthread_worker()-> kthread_flush_worker()



Now, the question seem to be the init() functions.
Andrew would prefer:

  __init_kthread_worker()   -> __kthread_worker_init()
  init_kthread_worker() -> kthread_worker_init()
  init_kthread_work()   -> kthread_work_init()

AFAIK, Steven would prefer to keep it

  __init_kthread_worker()   stay as is
  init_kthread_worker() stay as is
  init_kthread_work()   stay as is

I would personally prefer the way from this patch:

  __init_kthread_worker()   -> __kthread_init_worker()
  init_kthread_worker() -> kthread_init_worker()
  init_kthread_work()   -> kthread_init_work()


I have several reasons:

1. The init functions will be used close to the other functions in
   the code. It will be easier if all functions use the same
   naming scheme. Here are some snippets:

kthread_init_work(&w_data->balancing_work, clamp_balancing_func);
kthread_init_delayed_work(&w_data->idle_injection_work,
  clamp_idle_injection_func);
kthread_queue_work(w_data->worker, &w_data->balancing_work);

   or

kthread_init_delayed_work(&kmemleak_scan_work, kmemleak_scan_func);
kmemleak_scan_worker = kthread_create_worker(0, "kmemleak");


2. We are going to add kthread_destroy_worker() which would need
   to be another exception. Also this function will be used together
   with the others, for example:

kthread_cancel_delayed_work_sync(&rb_producer_hammer_work);
kthread_destroy_worker(rb_producer_worker);

   Also here the same naming scheme will help.


3. It is closer to the workqueues API, so it reduces confusion.

4. Note that there are already several precedents, for example:

amd_iommu_init_device()
free_area_init_node()
jump_label_init_type()
regmap_init_mmio_clk()


Andrew, Steven, are you really so strongly against my version
of the init functions, please?


> > Also, are you sure that we should change the DEFINE to a DECLARE,
> > because DEFINE is used to create the object in question, DECLARE is for
> > header files:
> 
> Yes2, these macros expand to definitions, not to declarations.

Shame on me. I played with many variants, loo

Re: [PATCH 00/30] DRBD updates

[Jens Axboe]

On 06/13/2016 08:08 AM, Philipp Reisner wrote:

Hi Jens,

I have sent this already on April 25, I guess it was too late in the cycle
at that time. Apart from the usual maintenance and bug fixes this time comes
support for WRITE_SAME and lots of improvements for DISCARD.

At that time we had a discussion about (1) the all_zero() heuristic introduced
with [PATCH 04/30] drbd: Implement handling of thinly provisioned storage...
not being efficient, and about the (2) rs-discard-granularity configuration
parameter.

Regarding (1): I intend to work on block-devices being able to export their
allocation map by either FIEMAP or SEEK_HOLE/SEEK_DATA or both for the next
cycle. The I will change DRBD to use that as well.

Regarding (2): We need to announce the discard granularity when we create the
device/minor. At might it might be that there is no connection to the peer
node. So we are left with information about the discard granularity of the
local backing device only. Therefore we decided to delegate it to the
user/admin to provide the discard granularity for the resync process.


Please add it to your for-4.8/drivers branch.


If you want me to add it to that branch (which is where it should go), 
then why aren't the patches against that branch? I get rejects on 
several of the patches, mainly because they are not done on top of this 
particular branch.


We can do two things here. I can skip patches, I don't like doing that. 
Or you can respin against the proper branch, as it should have been from 
the beginning. What do you want to do?


--
Jens Axboe

[PATCH 1/2] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver

[Cyrille Pitchen]

This patch documents the DT bindings for the driver of the Atmel QSPI
controller embedded inside sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen 
Acked-by: Rob Herring 
Acked-by: Nicolas Ferre 
---
 .../devicetree/bindings/mtd/atmel-quadspi.txt  | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
new file mode 100644
index ..489807005eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
@@ -0,0 +1,32 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible: Should be "atmel,sama5d2-qspi".
+- reg:Should contain the locations and lengths of the base 
registers
+  and the mapped memory.
+- reg-names:  Should contain the resource reg names:
+  - qspi_base: configuration register address space
+  - qspi_mmap: memory mapped address space
+- interrupts: Should contain the interrupt for the device.
+- clocks: The phandle of the clock needed by the QSPI controller.
+- #address-cells: Should be <1>.
+- #size-cells:Should be <0>.
+
+Example:
+
+spi@f002 {
+   compatible = "atmel,sama5d2-qspi";
+   reg = <0xf002 0x100>, <0xd000 0x800>;
+   reg-names = "qspi_base", "qspi_mmap";
+   interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = <&spi0_clk>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spi0_default>;
+   status = "okay";
+
+   m25p80@0 {
+   ...
+   };
+};
-- 
1.8.2.2

[PATCH 2/2] mtd: atmel-quadspi: add driver for Atmel QSPI controller

[Cyrille Pitchen]

This driver add support to the new Atmel QSPI controller embedded into
sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
controller.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
---
 drivers/mtd/spi-nor/Kconfig |   9 +
 drivers/mtd/spi-nor/Makefile|   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c | 741 
 3 files changed, 751 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index d42c98e1f581..c546efd1357b 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -38,6 +38,15 @@ config SPI_FSL_QUADSPI
  This controller does not support generic SPI. It only supports
  SPI NOR.
 
+config SPI_ATMEL_QUADSPI
+   tristate "Atmel Quad SPI Controller"
+   depends on ARCH_AT91 || (ARM && COMPILE_TEST)
+   depends on OF && HAS_IOMEM
+   help
+ This enables support for the Quad SPI controller in master mode.
+ This driver does not support generic SPI. The implementation only
+ supports SPI NOR.
+
 config SPI_NXP_SPIFI
tristate "NXP SPI Flash Interface (SPIFI)"
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 0bf3a7f81675..1525913698ad 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_MTD_SPI_NOR)   += spi-nor.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
 obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
+obj-$(CONFIG_SPI_ATMEL_QUADSPI)+= atmel-quadspi.o
diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c 
b/drivers/mtd/spi-nor/atmel-quadspi.c
new file mode 100644
index ..06d1bf276dd0
--- /dev/null
+++ b/drivers/mtd/spi-nor/atmel-quadspi.c
@@ -0,0 +1,741 @@
+/*
+ * Driver for Atmel QSPI Controller
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* QSPI register offsets */
+#define QSPI_CR  0x  /* Control Register */
+#define QSPI_MR  0x0004  /* Mode Register */
+#define QSPI_RD  0x0008  /* Receive Data Register */
+#define QSPI_TD  0x000c  /* Transmit Data Register */
+#define QSPI_SR  0x0010  /* Status Register */
+#define QSPI_IER 0x0014  /* Interrupt Enable Register */
+#define QSPI_IDR 0x0018  /* Interrupt Disable Register */
+#define QSPI_IMR 0x001c  /* Interrupt Mask Register */
+#define QSPI_SCR 0x0020  /* Serial Clock Register */
+
+#define QSPI_IAR 0x0030  /* Instruction Address Register */
+#define QSPI_ICR 0x0034  /* Instruction Code Register */
+#define QSPI_IFR 0x0038  /* Instruction Frame Register */
+
+#define QSPI_SMR 0x0040  /* Scrambling Mode Register */
+#define QSPI_SKR 0x0044  /* Scrambling Key Register */
+
+#define QSPI_WPMR0x00E4  /* Write Protection Mode Register */
+#define QSPI_WPSR0x00E8  /* Write Protection Status Register */
+
+#define QSPI_VERSION 0x00FC  /* Version Register */
+
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN  BIT(0)
+#define QSPI_CR_QSPIDIS BIT(1)
+#define QSPI_CR_SWRST   BIT(7)
+#define QSPI_CR_LASTXFERBIT(24)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SSM BIT(0)
+#define QSPI_MR_LLB BIT(1)
+#define QSPI_MR_WDRBT   BIT(2)
+#define QSPI_MR_SMRMBIT(3)
+#define QSPI_MR_CSMODE_MASK GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY   (2 << 4)
+#define QSPI_MR_NBBITS_MASK GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n)   n) - 8) << 8) & 
QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n)   (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK  GENMASK(31, 24)
+#define QSPI_MR_DL

Re: [PATCH v1 3/3] mm: per-process reclaim

[Johannes Weiner]

Hi Minchan,

On Mon, Jun 13, 2016 at 04:50:58PM +0900, Minchan Kim wrote:
> These day, there are many platforms available in the embedded market
> and sometime, they has more hints about workingset than kernel so
> they want to involve memory management more heavily like android's
> lowmemory killer and ashmem or user-daemon with lowmemory notifier.
> 
> This patch adds add new method for userspace to manage memory
> efficiently via knob "/proc//reclaim" so platform can reclaim
> any process anytime.

Cgroups are our canonical way to control system resources on a per
process or group-of-processes level. I don't like the idea of adding
ad-hoc interfaces for single-use cases like this.

For this particular case, you can already stick each app into its own
cgroup and use memory.force_empty to target-reclaim them.

Or better yet, set the soft limits / memory.low to guide physical
memory pressure, once it actually occurs, toward the least-important
apps? We usually prefer doing work on-demand rather than proactively.

The one-cgroup-per-app model would give Android much more control and
would also remove a *lot* of overhead during task switches, see this:
https://lkml.org/lkml/2014/12/19/358

[PATCH v3 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG

[Andrew F. Davis]

The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter.
Add MFD core support.

Signed-off-by: Andrew F. Davis 
---
Changes from v2:
 - Add missing dependency on USB, thanks kbuild test robot

 drivers/mfd/Kconfig |   9 +++
 drivers/mfd/Makefile|   2 +
 drivers/mfd/ti-smusbdig.c   | 138 
 include/linux/mfd/ti-smusbdig.h |  75 ++
 4 files changed, 224 insertions(+)
 create mode 100644 drivers/mfd/ti-smusbdig.c
 create mode 100644 include/linux/mfd/ti-smusbdig.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1bcf601..af50230 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1373,6 +1373,15 @@ config MFD_LM3533
  additional drivers must be enabled in order to use the LED,
  backlight or ambient-light-sensor functionality of the device.
 
+config MFD_TI_SMUSBDIG
+   tristate "Texas Instruments SM-USB-DIG interface adapter"
+   depends on USB
+   select MFD_CORE
+   help
+ Support for the TI SM-USB-DIG USB to SPI/I2C/1Wire/GPIO adapter.
+ Additional drivers such as SPI_TI_SMUSBDIG, I2C_TI_SMUSBDIG, etc. must
+ be enabled in order to use the functionality of the device.
+
 config MFD_TIMBERDALE
tristate "Timberdale FPGA"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 42a66e1..4533b95 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -68,6 +68,8 @@ obj-$(CONFIG_MFD_WM8350_I2C)  += wm8350-i2c.o
 wm8994-objs:= wm8994-core.o wm8994-irq.o wm8994-regmap.o
 obj-$(CONFIG_MFD_WM8994)   += wm8994.o
 
+obj-$(CONFIG_MFD_TI_SMUSBDIG)  += ti-smusbdig.o
+
 obj-$(CONFIG_TPS6105X) += tps6105x.o
 obj-$(CONFIG_TPS65010) += tps65010.o
 obj-$(CONFIG_TPS6507X) += tps6507x.o
diff --git a/drivers/mfd/ti-smusbdig.c b/drivers/mfd/ti-smusbdig.c
new file mode 100644
index 000..19f48c6
--- /dev/null
+++ b/drivers/mfd/ti-smusbdig.c
@@ -0,0 +1,138 @@
+/*
+ * MFD Core driver for TI SM-USB-DIG
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define TI_USB_VENDOR_ID0x0451
+#define TI_USB_DEVICE_ID_SM_USB_DIG 0x2f90
+
+#define TI_SMUSBDIG_USB_TIMEOUT_MS  1000
+
+struct ti_smusbdig_device {
+   struct usb_device *usb_dev;
+   struct usb_interface *interface;
+};
+
+int ti_smusbdig_xfer(struct ti_smusbdig_device *ti_smusbdig,
+u8 *buffer, int size)
+{
+   struct device *dev = &ti_smusbdig->interface->dev;
+   int actual_length, ret;
+
+   if (!ti_smusbdig || !buffer || size <= 0)
+   return -EINVAL;
+
+   ret = usb_interrupt_msg(ti_smusbdig->usb_dev,
+   usb_sndctrlpipe(ti_smusbdig->usb_dev, 1),
+   buffer, size, &actual_length,
+   TI_SMUSBDIG_USB_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dev, "USB transaction failed\n");
+   return ret;
+   }
+
+   ret = usb_interrupt_msg(ti_smusbdig->usb_dev,
+   usb_rcvctrlpipe(ti_smusbdig->usb_dev, 1),
+   buffer, TI_SMUSBDIG_PACKET_SIZE, &actual_length,
+   TI_SMUSBDIG_USB_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dev, "USB transaction failed\n");
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ti_smusbdig_xfer);
+
+static const struct mfd_cell ti_smusbdig_mfd_cells[] = {
+   { .name = "ti-sm-usb-dig-gpio", },
+   { .name = "ti-sm-usb-dig-i2c", },
+   { .name = "ti-sm-usb-dig-spi", },
+   { .name = "ti-sm-usb-dig-w1", },
+};
+
+static int ti_smusbdig_probe(struct usb_interface *interface,
+const struct usb_device_id *usb_id)
+{
+   struct usb_host_interface *hostif = interface->cur_altsetting;
+   struct device *dev = &interface->dev;
+   struct ti_smusbdig_device *ti_smusbdig;
+   u8 buffer[TI_SMUSBDIG_PACKET_SIZE];
+   int ret;
+
+   if (hostif->desc.bInterfaceNumber != 0 ||
+   hostif->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
+   ti_smusbdig = devm_kzalloc(dev, sizeof(*ti_smusbdig), GFP_KERNEL);
+   if (!ti_smusbdig)
+   return -ENOMEM;
+
+   ti_smusbdig->usb_dev = usb_get_dev(interface_to_usbdev(interface));
+   ti_s

[PATCH 0/2] mtd: spi-nor: add driver for Atmel QSPI controller

[Cyrille Pitchen]

Hi all,

this series of patches adds support to the Atmel QSPI controller.
It was tested on a sama5d2 xplained board + Macronix mx25l25673g QSPI
memory.

The driver limits its support of Quad SPI memories to the SPI 1-1-4
protocol for Fast Read operations and SPI 1-1-1 protocol for all other
commands.

The series is based on next-20160609

Best regards,

Cyrille

Cyrille Pitchen (2):
  Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
  mtd: atmel-quadspi: add driver for Atmel QSPI controller

 .../devicetree/bindings/mtd/atmel-quadspi.txt  |  32 +
 drivers/mtd/spi-nor/Kconfig|   9 +
 drivers/mtd/spi-nor/Makefile   |   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c| 741 +
 4 files changed, 783 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

-- 
1.8.2.2

[PATCH] dma: xilinx-vdma: add some sanity checks

[Arnd Bergmann]

The newly added xilinx_dma_prep_dma_cyclic function sometimes causes
a gcc warning about the use of the segment function in case
we never run into the inner loop of the function:

dma/xilinx/xilinx_vdma.c: In function 'xilinx_dma_prep_dma_cyclic':
dma/xilinx/xilinx_vdma.c:1808:23: error: 'segment' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
   segment->hw.control |= XILINX_DMA_BD_SOP;

This can only happen if the period len is zero (which would cause other
problems earlier), or if the buffer is shorter than a period. Neither
of them should ever happen, but by adding an explicit check for these two
cases, we can abort in a more controlled way, and the compiler is
able to see that we never use uninitialized data.

Signed-off-by: Arnd Bergmann 
---
 drivers/dma/xilinx/xilinx_vdma.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 0f5b38a0e46f..2ac3253bc823 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -1745,8 +1745,14 @@ static struct dma_async_tx_descriptor 
*xilinx_dma_prep_dma_cyclic(
int i;
u32 reg;
 
+   if (!period_len)
+   return NULL;
+
num_periods = buf_len / period_len;
 
+   if (!num_periods)
+   return NULL;
+
if (!is_slave_direction(direction))
return NULL;
 
-- 
2.7.0

[PATCH v3 2/2] i2c: ti-smusbdig: add TI SM-USB-DIG I2C bus driver

[Andrew F. Davis]

Add support for the I2C bus functionality of the TI SM-USB-DIG.

Signed-off-by: Andrew F. Davis 
---
 drivers/i2c/busses/Kconfig   |  10 ++
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-ti-smusbdig.c | 189 +++
 3 files changed, 200 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-ti-smusbdig.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f167021..82be651 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1076,6 +1076,16 @@ config I2C_ROBOTFUZZ_OSIF
  This driver can also be built as a module.  If so, the module
  will be called i2c-osif.
 
+config I2C_TI_SMUSBDIG
+   tristate "Texas Instruments SM-USB-DIG I2C interface"
+   depends on MFD_TI_SMUSBDIG
+   help
+ This adds support for the I2C bus functionality of the
+ TI SM-USB-DIG USB interface adapter.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-ti-smusbdig.
+
 config I2C_TAOS_EVM
tristate "TAOS evaluation module"
depends on TTY
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 37f2819..38c0d87 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_I2C_DLN2)  += i2c-dln2.o
 obj-$(CONFIG_I2C_PARPORT)  += i2c-parport.o
 obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
 obj-$(CONFIG_I2C_ROBOTFUZZ_OSIF)   += i2c-robotfuzz-osif.o
+obj-$(CONFIG_I2C_TI_SMUSBDIG)  += i2c-ti-smusbdig.o
 obj-$(CONFIG_I2C_TAOS_EVM) += i2c-taos-evm.o
 obj-$(CONFIG_I2C_TINY_USB) += i2c-tiny-usb.o
 obj-$(CONFIG_I2C_VIPERBOARD)   += i2c-viperboard.o
diff --git a/drivers/i2c/busses/i2c-ti-smusbdig.c 
b/drivers/i2c/busses/i2c-ti-smusbdig.c
new file mode 100644
index 000..dfd3ca0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-ti-smusbdig.c
@@ -0,0 +1,189 @@
+/*
+ * I2C bus driver for TI SM-USB-DIG
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* (data size - start condition - address - ACK) / ACK after data byte */
+#define TI_SMUSBDIG_I2C_MAX_MSG ((TI_SMUSBDIG_DATA_SIZE - 3) / 2)
+
+struct ti_smusbdig_i2c {
+   struct device *dev;
+   struct ti_smusbdig_device *ti_smusbdig;
+   struct i2c_adapter adapter;
+};
+
+enum ti_smusbdig_i2c_command {
+   TI_SMUSBDIG_I2C_START = 0x3,
+   TI_SMUSBDIG_I2C_STOP = 0x4,
+   TI_SMUSBDIG_I2C_ACKM = 0x5,
+   TI_SMUSBDIG_I2C_ACKS = 0x6,
+};
+
+static void ti_smusbdig_i2c_packet_init(struct ti_smusbdig_packet *packet)
+{
+   memset(packet, 0, sizeof(*packet));
+   packet->function = TI_SMUSBDIG_I2C;
+   packet->channel = 0x1;
+}
+
+static int ti_smusbdig_i2c_xfer(struct i2c_adapter *adapter,
+   struct i2c_msg *msgs, int num)
+{
+   struct ti_smusbdig_i2c *ti_smusbdig_i2c = i2c_get_adapdata(adapter);
+   struct ti_smusbdig_packet packet;
+   int i, j, k, ret;
+
+   for (i = 0; i < num; i++) {
+   ti_smusbdig_i2c_packet_init(&packet);
+   ti_smusbdig_packet_add_command(&packet, TI_SMUSBDIG_I2C_START);
+   /* add read bit to address if needed */
+   msgs[i].addr <<= 1;
+   if (msgs[i].flags & I2C_M_RD)
+   msgs[i].addr |= BIT(0);
+   ti_smusbdig_packet_add_data(&packet, msgs[i].addr);
+   ti_smusbdig_packet_add_command(&packet, TI_SMUSBDIG_I2C_ACKS);
+   if (msgs[i].flags & I2C_M_RD) {
+   for (j = 0; j < msgs[i].len; j++) {
+   ti_smusbdig_packet_add_data(&packet, 0xff);
+   ti_smusbdig_packet_add_command(&packet, 
TI_SMUSBDIG_I2C_ACKM);
+   }
+   } else {
+   for (j = 0; j < msgs[i].len; j++) {
+   ti_smusbdig_packet_add_data(&packet, 
msgs[i].buf[j]);
+   ti_smusbdig_packet_add_command(&packet, 
TI_SMUSBDIG_I2C_ACKS);
+   }
+   }
+
+   ret = ti_smusbdig_xfer(ti_smusbdig_i2c->ti_smusbdig,
+  (u8 *)&packet, sizeof(packet));
+   if (ret)
+   return ret;
+
+   /*
+* now we read in any data we got during read MSGs
+ 

Re: [PATCH v4 16/44] infiniband: dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On Fri, Jun 10, 2016 at 11:18:31AM -0700, Bart Van Assche wrote:
> On 06/10/2016 03:11 AM, Krzysztof Kozlowski wrote:
> >Split out subsystem specific changes for easier reviews. This will be
> >squashed with main commit.
> 
> Please rename 'attrs' into 'dma_attrs' in this patch such that it remains
> clear that that variable refers to DMA attributes.

Good point, thanks.

Best regards,
Krzysztof

[GIT PULL] ARM: dts: exynos: Fixes for v4.7

[Krzysztof Kozlowski]

Hi,

Two fixes for current release cycle (regressions).

Best regards,
Krzysztof


The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-fixes-4.7-2

for you to fetch changes up to a7d7865fecd83adb98b20eca5eddef7efc94831d:

  ARM: dts: exynos: Fix port nodes names for Exynos5420 Peach Pit board 
(2016-06-07 11:00:39 +0200)


Fixes for Exynos-based Snow and Peach Pit boards for regressions introduced in
4.7-rc1 because OF graph logic expects specific names of child nodes.


Javier Martinez Canillas (2):
  ARM: dts: exynos: Fix port nodes names for Exynos5250 Snow board
  ARM: dts: exynos: Fix port nodes names for Exynos5420 Peach Pit board

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 13 ++---
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 13 ++---
 2 files changed, 20 insertions(+), 6 deletions(-)

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

[kbuild test robot]

Hi,

[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.7-rc3 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160613-165523
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
>> undefined!
>> ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/libcomposite.ko] undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/legacy/gadgetfs.ko] undefined!

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


.config.gz
Description: Binary data

Re: [alsa-devel] [PATCH] ASoC: intel: fix build when ACPI is not enabled

[Randy Dunlap]

On 06/12/16 21:22, Vinod Koul wrote:
> On Thu, Jun 09, 2016 at 05:01:38PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> kconfig tools generate the following warning when CONFIG_ACPI is not
>> enabled:
>>
>> warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH && SND_SOC_INTEL_BYTCR_RT5651_MACH 
>> && SND_SOC_INTEL_CHT_BSW_RT5672_MACH && SND_SOC_INTEL_CHT_BSW_RT5645_MACH && 
>> SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH) selects SND_SST_IPC_ACPI which has 
>> unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && ACPI)
>>
>> causing these build errors:
>>
>> In file included from ../sound/soc/intel/atom/sst/sst_acpi.c:40:0:
>> ../include/acpi/acpi_bus.h:65:20: error: conflicting types for 
>> 'acpi_evaluate_dsm'
>>  union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const u8 *uuid,
>> In file included from ../sound/soc/intel/atom/sst/sst_acpi.c:31:0:
>> ../include/linux/acpi.h:676:34: note: previous definition of 
>> 'acpi_evaluate_dsm' was here
>>  static inline union acpi_object *acpi_evaluate_dsm(acpi_handle handle,
>>
>> I am told that ACPI is a requirement for these drivers, so make that
>> explicit. Also end help text sentences with a period.
>>
>> Signed-off-by: Randy Dunlap 
>> Cc:  Jie Yang 
>> Cc:  Pierre-Louis Bossart 
>> Cc:  alsa-de...@alsa-project.org
>> ---
>>  sound/soc/intel/Kconfig |   12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> Should SND_SOC_INTEL_SST and possibly other similar drivers get this
>> same change?
> 
> The SND_SST_IPC_ACPI has depends on ACPI.
> 
> Can you send me your config for this.

Attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.7.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SY

Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES

[Daniel Lezcano]

On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote:
> Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific
> MAX_POWERNV_IDLE_STATES.
> 
> Cc: Rafael J. Wysocki 
> Cc: Daniel Lezcano 
> Cc: linux...@vger.kernel.org
> Suggested-by: Daniel Lezcano 
> Signed-off-by: Shreyas B. Prabhu 
> ---

Acked-by: Daniel Lezcano 

Re: [PATCH] ceph: fix symbol versioning for ceph_monc_do_statfs

[Arnd Bergmann]

On Monday, June 13, 2016 3:19:12 PM CEST Ilya Dryomov wrote:
> > diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> > index 690985daad1c..6b79a6ba39ca 100644
> > --- a/include/linux/ceph/libceph.h
> > +++ b/include/linux/ceph/libceph.h
> > @@ -214,8 +214,9 @@ static void erase_##name(struct rb_root *root, type *t) 
> > \
> >  }
> >
> >  #define DEFINE_RB_LOOKUP_FUNC(name, type, keyfld, nodefld) \
> > +extern type __lookup_##name##_key; \
> >  static type *lookup_##name(struct rb_root *root,   \
> > -  typeof(((type *)0)->keyfld) key) \
> > +  typeof(__lookup_##name##_key.keyfld) key)\
> >  {  \
> > struct rb_node *n = root->rb_node;  \
> > \
> 
> Out of curiosity, did you figure out why is it that only
> ceph_monc_do_statfs() is affected and not the other exports in
> net/ceph/osd_client.c?

No, I did not investigate it further at that point. My guess is that
something resets the state of the genksyms parser when it encounters
some tokens (like the semicolon I added earlier, or an EXPORT_SYMBOL
statement), and that this happens in one file but not the other.

Arnd

Re: Using irq-crossbar.c

[Sebastian Frias]

Hi Lennart,

Thanks for your input, please find my comments below.

On 06/13/2016 04:04 PM, Lennart Sorensen wrote:
> On Sat, Jun 11, 2016 at 05:37:51PM +0200, Mason wrote:
>> Only the name of the file was provided, not the path. I was not aware
>> that you already knew where to find it. I made no claim whatsoever on
>> the implementation. In fact, I agree with everything Lennart wrote.
> 
> The way the TI irq crossbar works is:
> 
> You have say 200 interrupt sources in the system.  You have some
> coprocessor (say PRU0) that you want to handle UART7, so you tell the
> crossbar: Please map the IRQ from UART7 (which might be input 146 on the
> crossbar) to IRQ 10 on the PRU0 processor.  Now whenever the interrupt
> from UART7 fires, PRU0 will see it as IRQ10.  There are no interrupt
> registers to check in the crossbar, it is purely virtual wires for
> routing interrupts.  It just happens to be an enourmouse and very very
> flexible set of wires.
> 

Ok, thanks for the information.

> If on the other hand you have 128 inputs and 24 outputs and you want
> all 128 inputs to work, and you have 24 128bit registers in the device
> to tell you which of the inputs fired to cause a given output to fire,
> then you in fact have an interrupt controller, not a crossbar. 

Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the 
GIC.
The HW block is a many-to-many router.
There are 128 32bit registers which specify, for each of the corresponding 128 
inputs, to which of the 24 outputs it would be routed to.

There are 4 32bit registers that can show the RAW status of the 128 inputs, but 
they do not latch on the inputs.
That's why our understanding is that on Linux terms it is not an interrupt 
controller, but just a many-to-many mux, the only real interrupt-controller 
(where one can set if the line is active high or low for example) is the GIC.

> This would
> be much more similar to how the original x86 design has an i8259 connected
> with 8 inputs and 1 output to an input on a second i8259 (the output of
> the secondary chip connects to IRQ2 on the primary).  You actually need
> an irq controller driver to go read the registers to determine which
> external interrupt fired and to assign a virtual IRQ number so that
> drivers can register for a given externel pin.  Cascaded interrupt
> controllers like this is perfectly common on lots of systems.

Thanks for the background on the i8259 and the cascaded interrupts.
However, our understanding is that it would only be required if more than 24 
devices request IRQ lines, in which case, some of them would have to share a 
single GIC IRQ line, right?
Shall we worry about that now?

> 
> Now of course you could cheat and simply declare that all the inputs
> that are mixed to a single output are in fact sharing a single interrupt
> (fine if they are level triggered, could be problematic if edge triggered,
> depending on how it works exactly).  Of course then when an interrupt
> happens, every driver that handles some device on a given shared interrupt
> will have the handler called in turn until everyone has had a change
> to handle the interrupt, at which point everyone should have stopped
> triggering it and it will clear itself, unless of course another event
> happened on one of the devices in which case another loop through everyone
> happens to handle the new events.  The loop will continue until the
> interrupt clears, as long as some of the handlers return that they in fact
> did do some work to handle the interrupt event.  If no one claims to have
> done something and the interrupt stays, you get the kernel killing the
> interrupt with a message about "Interrupt foo happened and nobody cared".

This is interesting.
We have one interrupt controller already upstream, drivers/irqchip/irq-tango.c, 
and our understanding is that it dispatches one IRQ at the time, see 
tangox_dispatch_irqs() function, is that what you are discussing?

Best regards,

Sebastian

Re: [RFC PATCH 1/2] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_HARD with more useful semantic

[Tetsuo Handa]

Michal Hocko wrote:
> On Sat 11-06-16 23:35:49, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 07-06-16 21:11:03, Tetsuo Handa wrote:
> > > > Remaining __GFP_REPEAT users are not always doing costly allocations.
> > > 
> > > Yes but...
> > > 
> > > > Sometimes they pass __GFP_REPEAT because the size is given from 
> > > > userspace.
> > > > Thus, unconditional s/__GFP_REPEAT/__GFP_RETRY_HARD/g is not good.
> > > 
> > > Would that be a regression though? Strictly speaking the __GFP_REPEAT
> > > documentation was explicit to not loop for ever. So nobody should have
> > > expected nofail semantic pretty much by definition. The fact that our
> > > previous implementation was not fully conforming to the documentation is
> > > just an implementation detail.  All the remaining users of __GFP_REPEAT
> > > _have_ to be prepared for the allocation failure. So what exactly is the
> > > problem with them?
> > 
> > A !costly allocation becomes weaker than now if __GFP_RETRY_HARD is passed.
> 
> That is true. But it is not weaker than the __GFP_REPEAT actually ever
> promissed. __GFP_REPEAT explicitly said to not retry _for_ever_. The
> fact that we have ignored it is sad but that is what I am trying to
> address here.

Whatever you rename __GFP_REPEAT to, it sounds strange to me that !costly
__GFP_REPEAT allocations are weaker than !costly !__GFP_REPEAT allocations.
Are you planning to make !costly !__GFP_REPEAT allocations to behave like
__GFP_NORETRY?

> 
> > > > >   /* Reclaim has failed us, start killing things */
> > > > >   page = __alloc_pages_may_oom(gfp_mask, order, ac, 
> > > > > &did_some_progress);
> > > > >   if (page)
> > > > > @@ -3719,6 +3731,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned 
> > > > > int order,
> > > > >   /* Retry as long as the OOM killer is making progress */
> > > > >   if (did_some_progress) {
> > > > >   no_progress_loops = 0;
> > > > > + passed_oom = true;
> > > > 
> > > > This is too premature. did_some_progress != 0 after returning from
> > > > __alloc_pages_may_oom() does not mean the OOM killer was invoked. It 
> > > > only means
> > > > that mutex_trylock(&oom_lock) was attempted.
> > > 
> > > which means that we have reached the OOM condition and _somebody_ is
> > > actaully handling the OOM on our behalf.
> > 
> > That _somebody_ might release oom_lock without invoking the OOM killer (e.g.
> > doing !__GFP_FS allocation), which means that we have reached the OOM 
> > condition
> > and nobody is actually handling the OOM on our behalf. __GFP_RETRY_HARD 
> > becomes
> > as weak as __GFP_NORETRY. I think this is a regression.
> 
> I really fail to see your point. We are talking about a gfp flag which
> tells the allocator to retry as much as it is feasible. Getting through
> all the reclaim attempts two times without any progress sounds like a
> fair criterion. Well, we could try $NUM times but that wouldn't make too
> much difference to what you are writing above. The fact whether somebody
> has been killed or not is not really that important IMHO.

If all the reclaim attempt first time made no progress, all the reclaim
attempt second time unlikely make progress unless the OOM killer kills
something. Thus, doing all the reclaim attempts two times without any progress
without killing somebody sounds almost equivalent to doing all the reclaim
attempt only once.

[PATCH 1/2] ARM: pxa: ssp: Drop unnecessary freeing functions

[Amitoj Kaur Chawla]

Drop clk_put, kfree, release_mem_region and iounmap for
devm_ allocated data in the remove function of the driver.

Some of these changes were made with the help of the following
Coccinelle semantic patch:
@r@
expression x;
@@

(
 x = devm_kzalloc(...)
|
 x = devm_request_irq(...)
|
 x = devm_ioremap(...)
|
 x = devm_ioremap_nocache(...)
)

@@
expression r.x;
@@

(
* kfree(x)
|
* free_irq(x)
|
* iounmap(x)
)

Signed-off-by: Amitoj Kaur Chawla 
---
 arch/arm/plat-pxa/ssp.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/plat-pxa/ssp.c b/arch/arm/plat-pxa/ssp.c
index ba13f79..97bd43c 100644
--- a/arch/arm/plat-pxa/ssp.c
+++ b/arch/arm/plat-pxa/ssp.c
@@ -230,25 +230,16 @@ static int pxa_ssp_probe(struct platform_device *pdev)
 
 static int pxa_ssp_remove(struct platform_device *pdev)
 {
-   struct resource *res;
struct ssp_device *ssp;
 
ssp = platform_get_drvdata(pdev);
if (ssp == NULL)
return -ENODEV;
 
-   iounmap(ssp->mmio_base);
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   release_mem_region(res->start, resource_size(res));
-
-   clk_put(ssp->clk);
-
mutex_lock(&ssp_lock);
list_del(&ssp->node);
mutex_unlock(&ssp_lock);
 
-   kfree(ssp);
return 0;
 }
 
-- 
1.9.1

[PATCH 2/2] ARM: pxa: ssp: Switch to devm_ioremap_resource

[Amitoj Kaur Chawla]

Replace calls to devm_request_mem_region and devm_ioremap with a
single call to devm_ioremap_resource instead and modify error
handling.

Move the call to devm_ioremap_resource adjacent to the call to
platform_get_resource and the assignment ssp->phys_base below the 
call to devm_ioremap_resource to take advantage of the null check 
on res by devm_ioremap_resource.

Signed-off-by: Amitoj Kaur Chawla 
---
 arch/arm/plat-pxa/ssp.c | 20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/arch/arm/plat-pxa/ssp.c b/arch/arm/plat-pxa/ssp.c
index 97bd43c..aecc8d5 100644
--- a/arch/arm/plat-pxa/ssp.c
+++ b/arch/arm/plat-pxa/ssp.c
@@ -175,26 +175,12 @@ static int pxa_ssp_probe(struct platform_device *pdev)
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (res == NULL) {
-   dev_err(dev, "no memory resource defined\n");
-   return -ENODEV;
-   }
-
-   res = devm_request_mem_region(dev, res->start, resource_size(res),
- pdev->name);
-   if (res == NULL) {
-   dev_err(dev, "failed to request memory resource\n");
-   return -EBUSY;
-   }
+   ssp->mmio_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ssp->mmio_base))
+   return PTR_ERR(ssp->mmio_base);
 
ssp->phys_base = res->start;
 
-   ssp->mmio_base = devm_ioremap(dev, res->start, resource_size(res));
-   if (ssp->mmio_base == NULL) {
-   dev_err(dev, "failed to ioremap() registers\n");
-   return -ENODEV;
-   }
-
ssp->irq = platform_get_irq(pdev, 0);
if (ssp->irq < 0) {
dev_err(dev, "no IRQ resource defined\n");
-- 
1.9.1