Re: [PATCH 0/2] alpha: fix build failure

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 07:26:34AM -0700, Guenter Roeck wrote:
> On 09/15/2015 06:50 AM, Sudip Mukherjee wrote:
> >On Tue, Sep 15, 2015 at 06:28:40AM -0700, Guenter Roeck wrote:
> >>On 09/15/2015 01:21 AM, Sudip Mukherjee wrote:
> >>>On Mon, Sep 14, 2015 at 02:22:08PM -0700, Guenter Roeck wrote:
> On Mon, Sep 14, 2015 at 05:19:27PM +0530, Sudip Mukherjee wrote:
> >>
> >>I am not building m32r:allmodconfig or openrisc:allmodconfig.
> >>
> >>You can always check http://server.roeck-us.net:8010/builders to see
> >>what is covered by my builds and tests.
> >ok, openrisc:defconfig and allnoconfig.
> >
> >Well, the first error on allmodconfig is:
> >drivers/vhost/vhost.c: In function 'vhost_vring_ioctl':
> >drivers/vhost/vhost.c:818:3: error: call to '__compiletime_assert_818' 
> >declared with attribute error: BUILD_BUG_ON failed: __alignof__
> >*vq->avail > VRING_AVAIL_ALIGN_SIZE
> >
> >Any hint about this one?
> >
> 
> No idea, sorry. Is that a new problem ?
I think no. Not sure though, as I have started testing these just
recently.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] ARM: sun8i: Fix A23 and A33 clock gates indices

[Chen-Yu Tsai]

On Fri, Sep 11, 2015 at 9:26 PM, Maxime Ripard
 wrote:
> Hi everyone,
>
> Here is a patch set that adds the missing clocks for the message box
> in the A33 and A23 SoCs.
>
> In order to support that properly, the addition of a new clock driver
> for the A33 has been needed, and we split the gates definition that
> was previously shared to each DTSI.
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (4):
>   clk: sunxi: Add A33 gates support
>   ARM: sun8i: Add the A33 AHB1 gates clock driver
>   ARM: sun8i: Move A23 AHB1 gates out of common DTSI
>   ARM: sun8i: A23: Add missing msgbox gate
>
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi | 25 -
>  arch/arm/boot/dts/sun8i-a23.dtsi | 25 +
>  arch/arm/boot/dts/sun8i-a33.dtsi | 27 +++
>  drivers/clk/sunxi/clk-simple-gates.c |  2 ++
>  4 files changed, 54 insertions(+), 25 deletions(-)

Apart from the small issue with the second patch's commit message,
this series looks good.

Reviewed-by: Chen-Yu Tsai 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/19] staging/lustre: Remove IS_SERVER and all users

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 08:30:41PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> Since the client can never be server, this is all dead code.
> 
> Signed-off-by: Oleg Drokin 
> ---
OOPS.. build fails with error:
error: ‘lsi’ undeclared (first use in this function)

reegards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery

[Willy Tarreau]

Hi Olga,

On Tue, Sep 15, 2015 at 02:36:06PM +, Kornievskaia, Olga wrote:
> 
> Hi Willy,
> 
> After checking with the list, I believe the course of action will be to
> correct the patch with the patch below instead of reverting it.

OK but as far as I can tell, mainline is still not fixed regarding this
issue. I can't introduce in a stable branch a fix which is not yet in
mainline. Thus I'll simply remove the patch from this series and will
merge both patches in a future series once your fix reaches mainline.

Note that I picked this fix from 3.2 (commit ef8500b18fc4bb) so my
understanding is that this patch needs to be reverted from 3.2 as well
for the time being ?

Thanks very much for the detailed investigations!

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: slab: convert slab_is_available to boolean

[Pekka Enberg]

On 9/15/15 8:50 PM, Denis Kirjanov wrote:

A good one candidate to return a boolean result

Signed-off-by: Denis Kirjanov 


Reviewed-by: Pekka Enberg 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/5] dt/bindings: bcm2835: add binding documentation for bcm2835-aux

[Martin Sperl]

> On 16.09.2015, at 06:12, Stephen Warren  wrote:
> 
> On 09/04/2015 01:26 AM, Martin Sperl wrote:
>> 
>>> On 26.08.2015, at 03:44, Stephen Warren  wrote:
>>> 
>>> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>>> 
 +Example:
 +
 +aux_enable: aux_enable@0x7e215004 {
 +  compatible = "bcrm,bcm2835-aux";
 +  reg = <0x7e215004 0x04>;
>>> 
>>> I'd expect that to be <0x7e215000 0x8>;
>> 
>> The reason is that we just handle enable with this driver,
>> which just requires access to the 0x7e215004 register.
>> 
>> The 0x7e215000 register (interrupt mask) could be used by a
>> cascaded interrupt-controller, but as the spi and uart drivers
>> can run with shared interrupts this is not a necessity.
> 
> The DT is supposed to describe the HW, not any particular SW's use of
> the HW. If the HW block has 2 registers, so must the DT reg property.

Please look at V6 of the patch-series, that uses Erics clock-patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review

[Willy Tarreau]

On Tue, Sep 15, 2015 at 01:06:31PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > This is the start of the longterm review cycle for the 2.6.32.68 release.
> > All patches will be posted as a response to this one. If anyone has any
> > issue with these being applied, please let me know. If anyone is a
> > maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> > to the patch, please respond with it. If anyone thinks some important
> > patches are missing and should be added prior to the release, please
> > report them quickly with their respective mainline commit IDs.
> > 
> > Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> > Anything received after that time might be too late. If someone
> > wants a bit more time for a deeper review, please let me know.
> > 
> > NOTE: 2.6.32 is approaching end of support. There will probably be one
> > or maybe two other versions issued in the next 3-6 months, and that will
> > be all, at least for me. Adding to this the time it can take to validate
> > and deploy in some environments, it probably makes sense to start to
> > think about switching to another longterm branch. 3.2 and 3.4 are good
> > candidates for those seeking rock-solid versions. Longterm branches and
> > their projected EOLs are listed here :
> > 
> >  https://www.kernel.org/category/releases.html
> > 
> > The whole patch series can be found in one patch at :
> >  
> > https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
> > 
> > The shortlog and diffstat are appended below.
> [...]
> 
> Patches 3 "crypto: testmgr - update LZO compression test vectors",
> 58 "dccp: fix auto-loading of dccp(_probe)",
> 60 "dccp: catch failed request_module call in dccp_probe init",
> 61 "dmaengine: fix missing cnt in ?: in dmatest" and
> 62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
> line in the commit mesage rather than the usual "commit xxx upstream."

Yes indeed, I cherry-picked them after the first build attempts when I
discovered build warnings. I'll add the line by hand.

> Patches 10 and 59 didn't reach me at all, though I can guess from its
> neighbours that 59 is cherry-picked from commit
> d984e6197ecd2babc1537f42dc1e676133005cda upstream.

Yep. Sorry for this, I'm attaching both of them to this e-mail, and
will add the upstream commit line to 59 as well.

Thanks,
Willy

>From 3f3fe288bb34818096135a93062ab588acbda269 Mon Sep 17 00:00:00 2001
From: Jan Kara 
Date: Mon, 12 Dec 2011 15:13:50 +0100
Subject: udf: Treat symlink component of type 2 as /
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit

From: Jan Kara 

commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.

Currently, we ignore symlink component of type 2. But mkisofs and other OS'
seem to treat it as / so do the same for compatibility.

Reported-by: "Gábor S." 
Signed-off-by: Jan Kara 
[bwh: Needed for the following fix]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau 
---
 fs/udf/symlink.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index e28a902..2d60484 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -43,10 +43,16 @@ static void udf_pc_to_char(struct super_block *sb, char 
*from, int fromlen,
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
case 1:
-   if (pc->lengthComponentIdent == 0) {
-   p = to;
-   *p++ = '/';
-   }
+   /*
+* Symlink points to some place which should be agreed
+* upon between originator and receiver of the media. 
Ignore.
+*/
+   if (pc->lengthComponentIdent > 0)
+   break;
+   /* Fall through */
+   case 2:
+   p = to;
+   *p++ = '/';
break;
case 3:
memcpy(p, "../", 3);
-- 
1.7.12.2.21.g234cd45.dirty

>From 361fb30bc6abac898b3815bef9e9a56a95f46059 Mon Sep 17 00:00:00 2001
From: "David S. Miller" 
Date: Thu, 1 Dec 2011 14:45:49 -0500
Subject: dccp: Fix compile warning in probe code.
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit

From: "David S. Miller" 

Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix
auto-loading of dccp(_probe)") fixed a bug but created a new
compiler warning:

net/dccp/probe.c: In function ‘dccpprobe_init’:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always 
be ‘true’, suggest explicit middle operand [-Wparentheses]

try_then_request_module() is built for situations where the
"existence" test is some lookup 

Re: [PATCH] KVM: nVMX: nested VPID emulation

[Jan Kiszka]

On 2015-09-16 04:36, Wanpeng Li wrote:
> On 9/16/15 1:32 AM, Jan Kiszka wrote:
>> On 2015-09-15 12:14, Wanpeng Li wrote:
>>> On 9/14/15 10:54 PM, Jan Kiszka wrote:
 Last but not least: the guest can now easily exhaust the host's pool of
 vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
 or should there be some limit?
>>> I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
>>> and the scenario which you pointed out can be avoid.
>> I cannot yet follow why there is no chance for L1 to consume all vpids
>> that the host manages in that single, global bitmap by simply spawning a
>> lot of nested VCPUs for some L2. What is enforcing L1 to call nested
>> vmclear - apparently the only way, besides destructing nested VCPUs, to
>> release such vpids again?
> 
> In v2, there is no direct mapping between vpid02 and vpid12, the vpid02
> is per-vCPU for L0 and reused while the value of vpid12 is changed w/
> one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2,
> so it will not influence global bitmap(for vpid01 and vpid02 allocation)
> even if spawn a lot of nested vCPUs.

Ah, I see, you limit allocation to one additional host-side vpid per
VCPU, for nesting. That looks better. That also means all vpids for L2
will be folded on that single vpid in hardware, right? So the major
benefit comes from having separate vpids when switching between L1 and
L2, in fact.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.

[Willy Tarreau]

On Tue, Sep 15, 2015 at 12:37:21PM +0100, Ben Hutchings wrote:
> > From: Ralf Baechle 
> > 
> > commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.
> > 
> > This is no longer needed with the fixed, new and improved definition
> > of cpu_has_mips_r2_exec_hazard in .
> [...]
> 
> This needs to be dropped along with the previous patch.

Good catch indeed. Done.
Thanks,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] ARM:dts:sun7i: Add keypad clk node

[Maxime Ripard]

On Wed, Sep 16, 2015 at 12:05:54AM +1000, yassinjaf...@gmail.com wrote:
> From: Yassin Jaffer 
> 
> This patch add support to the keypad clock on sun7i
> 
> Signed-off-by: Yassin Jaffer 

Applied, thanks!

Maxime

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


signature.asc
Description: Digital signature

Re: [Bugfix 0/3] Convert eata driver to a normal PCI device driver

[Jiang Liu]

On 2015/9/15 15:19, Arthur Marsh wrote:
> 
> 
> Jiang Liu wrote on 15/09/15 12:01:
> 
>> HI Arthur,
>> Really appreciate your help to test the patches. That's
>> a good sign we have moved forward a bit:)
>> For kexec, it's always challenging to me. So could you
>> please help to provide full dmesg logs with working kernels
>> so I could try to figure out the order among scsi and PCI devices.
>> It may be shutdown order related.
>> Thanks!
>> Gerry
> 
> OK, attached is the dmesg output from the 4.2.0 kernel where kexec worked.
Hi Arthur,
Could you please also help to capture the log messages
of kexec, I need to those log messages to figure out the order
to shutdown PCI devices and scsi devices during kexec.
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: wlan-ng: prism2fw: coding style: Fixed too long lines.

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 08:09:54PM -0300, Marcos Canán wrote:
> This is a patch to the prism2fw.c file that fixes
> too long lines.
> 
> Signed-off-by: Marcos Canán 
> ---
This will not apply because of cfa6954ced97 ("staging: wlan-ng: fix long line").
Which tree you have used?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the tip tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

[Parav Pandit]

Hi Jason, Sean, Tejun,

I am in process of defining new approach, design based on the feedback
given here for new RDMA cgroup from all of you.
I have also collected feedback from Liran yesterday and ORNL folks too.

Soon I will post the new approach, high level APIs and functionality
for review before submitting actual implementation.

Regards,
Parav Pandit

On Tue, Sep 15, 2015 at 9:15 AM, Jason Gunthorpe
 wrote:
> On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote:
>
>> As you precisely described, about wild ratio,
>> we are asking vendor driver (bottom most layer) to statically define
>> what the resource pool is, without telling him which application are
>> we going to run to use those pool.
>> Therefore vendor layer cannot ever define "right" resource pool.
>
> No, I'm saying the resource pool is *well defined* and *fixed* by each
> hardware.
>
> The only question is how do we expose the N resource limits, the list
> of which is totally vendor specific.
>


>> rdma cgroup will allow us to run post 512 or 1024 containers without
>> using PCIe SR-IOV, without creating any vendor specific resource
>> pools.
>
> If you ignore any vendor specific resource limits then you've just
> left open a hole, a wayward container can exhaust all others - so what
> was the point of doing all this work?
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: wilc1000: Removed curly braces

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 07:24:00PM +0530, Aparna Karuthodi wrote:
> Removed the curly braces of a single statement if block to remove a
> coding style warning detected by checkpatch.
> The warning is given below:
> WARNING: braces {} are not necessary for single statement blocks
> 
> Signed-off-by: Aparna Karuthodi 
> ---
This will not apply any more due to recent modification to this file.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm

[Paul E. McKenney]

On Tue, Sep 15, 2015 at 09:24:15PM -0400, Tejun Heo wrote:
> Hello, Paul.
> 
> On Tue, Sep 15, 2015 at 04:38:18PM -0700, Paul E. McKenney wrote:
> > Well, the decision as to what is too big for -stable is owned by the
> > -stable maintainers, not by me.
> 
> Is it tho?  Usually the subsystem maintainer knows the best and has
> most say in it.  I was mostly curious whether you'd think that the
> changes would be too risky.  If not, great.

I do hope that they would listen to what I thought about it, but at
the end of the day, it is the -stable maintainers who pull a given
patch, or don't.

> > I am suggesting trying the options and seeing what works best, then
> > working to convince people as needed.
> 
> Yeah, sure thing.  Let's wait for Christian.

Indeed.  Is there enough benefit to risk jamming this thing into 4.3?
I believe that 4.4 should be a no-brainer.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Viresh Kumar]

On 10-09-15, 09:31, Lee Jones wrote:
> I think you answered your own question.
> 
> No users == !ABI == Strip it out.

Okay, as I have delayed things enough for you, didn't wanted to do
that anymore. And so worked on it despite very tight schedule :)

Below is the refreshed binding changes (I have split that into 3
patches, but kept the diff here for simplicity).

Other than that, all code changes you need to test your driver are
pushed here:

https://git.linaro.org/people/viresh.kumar/linux.git 
opp/supported-hw-prop-name-v1

I am not gonna post the patches to the lists, until the time existing
patches get reviewed.

-- 
viresh

-8<-
diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 719603b87353..b652d0403e93 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their 
"operating-points-v2" property with
 phandle to a OPP table in their DT node. The OPP core will use this phandle to
 find the operating points for the device.
 
-Devices may want to choose OPP tables at runtime and so can provide a list of
-phandles here. But only *one* of them should be chosen at runtime. This must be
-accompanied by a corresponding "operating-points-names" property, to uniquely
-identify the OPP tables.
-
 If required, this can be extended for SoC vendor specfic bindings. Such 
bindings
 should be documented as 
Documentation/devicetree/bindings/power/-opp.txt
 and should have a compatible description like: "operating-points-v2-".
 
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
-  tables are present), to uniquely identify them. The same list must be present
-  for all the CPUs which are sharing clock/voltage rails and hence the OPP
-  tables.
-
 * OPP Table Node
 
 This describes the OPPs belonging to a device. This node can have following
@@ -117,6 +106,14 @@ properties.
   Entries for multiple regulators must be present in the same order as their
   names are present in 'supply-names' property of the opp-table.
 
+- opp-microvolt-: Named opp-microvolt property. This is exactly similar 
to
+  the above opp-microvolt property, but allows multiple voltage ranges to be
+  provided for the same OPP. At runtime, the platform can pick a  and
+  matching opp-microvolt- property will be enabled for all OPPs. If the
+  platform doesn't pick a specific  or the  doesn't match with any
+  opp-microvolt- properties, then opp-microvolt property shall be used, 
if
+  present.
+
 - opp-microamp: The maximum current drawn by the device in microamperes
   considering system specific parameters (such as transients, process, aging,
   maximum operating temperature range etc.) as necessary. This may be used to
@@ -131,6 +128,9 @@ properties.
   as zero for them. If it isn't required for any regulator, then this property
   need not be present.
 
+- opp-microamp-: Named opp-microamp property. Similar to
+  opp-microvolt- property, but for microamp instead.
+
 - clock-latency-ns: Specifies the maximum possible transition latency (in
   nanoseconds) for switching to this OPP from any other OPP.
 
@@ -139,9 +139,27 @@ properties.
   frequency for a short duration of time limited by the device's power, current
   and thermal limits.
 
+- turbo-mode-: Named turbo-mode property. Similar to opp-microvolt-
+  property, but for turbo mode instead.
+
 - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
   the table should have this.
 
+- opp-suspend-: Named opp-suspend property. Similar to
+  opp-microvolt- property, but for suspend opp instead.
+
+- opp-supported-hw: User defined array containing a hierarchy of hardware
+  version numbers, supported by the OPP. For example: a platform with hierarchy
+  of three levels of versions (A, B and C), this field should be like ,
+  where X corresponds to Version hierarchy A, Y corresponds to version 
hierarchy
+  B and Z corresponds to version hierarchy C.
+
+  Each level of hierarchy is represented by a 32 bit value, and so there can be
+  only 32 different supported version per hierarchy. i.e. 1 bit per version. A
+  value of 0x will enable the OPP for all versions for that hierarchy
+  level. And a value of 0x will disable the OPP completely, and so we
+  never want that to happen.
+
 - status: Marks the node enabled/disabled.
 
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -443,7 +461,8 @@ Example 4: Handling multiple regulators
};
 };
 
-Example 5: Multiple OPP tables
+Example 5: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process)
 
 / {
cpus {
@@ -452,40 +471,84 @@ Example 5: Multiple OPP tables
...
 
cpu-supply = <_supply>
-   

[PATCH] PCI: Relax function 0 VPD test and relocate

[Alex Williamson]

When we quirk a device with PCI_DEV_FLAGS_VPD_REF_F0 we're expecting
to find a device where all the functions are identical.  If we don't
find that, we don't make VPD accessible through pci_vpd_ops.  That
means that if we quirk devices we shouldn't, we filter them out by
hiding VPD entirely rather than allowing default access.  Instead, we
can flip this around to only quirk devices that match a slightly more
rigorous test in the quirk, allowing regular access for anything else.

Tests for the multifunction flag are removed since a) function 0 and
the function under test are clearly a multifunction device if we're
scanning a non-zero function in the same slot and b) at this point the
flag is only set in the device under test if the multifunction bit is
set in the PCI HEADER, which is a point of interpretation for the PCI
spec.

Signed-off-by: Alex Williamson 
---

This is potentially another stable candiate since we're continuing to
iterate on 932c435caba8, but since we don't actually know of a device
where VPD is blocked (we don't think my Skylake example actually
supports VPD), I'm not including it.  I would support it if requested
though.

 drivers/pci/access.c |   22 --
 drivers/pci/quirks.c |   20 ++--
 2 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 5a5f0a7..59ac36f 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -475,23 +475,6 @@ static const struct pci_vpd_ops pci_vpd_f0_ops = {
.release = pci_vpd_pci22_release,
 };
 
-static int pci_vpd_f0_dev_check(struct pci_dev *dev)
-{
-   struct pci_dev *tdev = pci_get_slot(dev->bus,
-   PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
-   int ret = 0;
-
-   if (!tdev)
-   return -ENODEV;
-   if (!tdev->vpd || !tdev->multifunction ||
-   dev->class != tdev->class || dev->vendor != tdev->vendor ||
-   dev->device != tdev->device)
-   ret = -ENODEV;
-
-   pci_dev_put(tdev);
-   return ret;
-}
-
 int pci_vpd_pci22_init(struct pci_dev *dev)
 {
struct pci_vpd_pci22 *vpd;
@@ -500,12 +483,7 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
if (!cap)
return -ENODEV;
-   if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
-   int ret = pci_vpd_f0_dev_check(dev);
 
-   if (ret)
-   return ret;
-   }
vpd = kzalloc(sizeof(*vpd), GFP_ATOMIC);
if (!vpd)
return -ENOMEM;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6a30252..b03373f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1907,11 +1907,27 @@ static void quirk_netmos(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID,
 PCI_CLASS_COMMUNICATION_SERIAL, 8, quirk_netmos);
 
+/*
+ * Quirk non-zero PCI functions to route VPD access through function 0 for
+ * devices that share VPD resources between functions.  The functions are
+ * expected to be identical devices.
+ */
 static void quirk_f0_vpd_link(struct pci_dev *dev)
 {
-   if (!dev->multifunction || !PCI_FUNC(dev->devfn))
+   struct pci_dev *f0;
+
+   if (!PCI_FUNC(dev->devfn))
return;
-   dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0;
+
+   f0 = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
+   if (!f0)
+   return;
+
+   if (f0->vpd && dev->class == f0->class &&
+   dev->vendor == f0->vendor && dev->device == f0->device)
+   dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0;
+
+   pci_dev_put(f0);
 }
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
  PCI_CLASS_NETWORK_ETHERNET, 8, quirk_f0_vpd_link);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 3/3] arm/arm64: fix a migrating irq bug when hotplug cpu

[Yang Yingliang]

When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value. Fix it by
using irq_do_set_affinity.

And migrating interrupts is a core code matter, so move the code to
kernel/irq/migration.c and select CONFIG_GENERIC_IRQ_MIGRATION when
CONFIG_HOTPLUG_CPU and CONFIG_SMP is enabled.

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/arm/Kconfig |  1 +
 arch/arm/include/asm/irq.h   |  1 -
 arch/arm/kernel/irq.c| 62 -
 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/irq.h |  1 -
 arch/arm64/kernel/irq.c  | 62 -
 include/linux/irq.h  |  4 +++
 kernel/irq/migration.c   | 66 
 8 files changed, 72 insertions(+), 126 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..d70ddd5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
+   select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index be1d07d..882bf98 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -24,7 +24,6 @@
 #ifndef __ASSEMBLY__
 struct irqaction;
 struct pt_regs;
-extern void migrate_irqs(void);
 
 extern void asm_do_IRQ(unsigned int, struct pt_regs *);
 void handle_IRQ(unsigned int, struct pt_regs *);
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 5ff4826..78abea8 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -136,64 +135,3 @@ int __init arch_probe_nr_irqs(void)
return nr_irqs;
 }
 #endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static bool migrate_one_irq(struct irq_desc *desc)
-{
-   struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
-   struct irq_chip *c;
-   bool ret = false;
-
-   /*
-* If this is a per-CPU interrupt, or the affinity does not
-* include this CPU, then we have nothing to do.
-*/
-   if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(), 
affinity))
-   return false;
-
-   if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
-   affinity = cpu_online_mask;
-   ret = true;
-   }
-
-   c = irq_data_get_irq_chip(d);
-   if (!c->irq_set_affinity)
-   pr_debug("IRQ%u: unable to set affinity\n", d->irq);
-   else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
-
-   return ret;
-}
-
-/*
- * The current CPU has been marked offline.  Migrate IRQs off this CPU.
- * If the affinity settings do not allow other CPUs, force them onto any
- * available CPU.
- *
- * Note: we must iterate over all IRQs, whether they have an attached
- * action structure or not, as we need to get chained interrupts too.
- */
-void migrate_irqs(void)
-{
-   unsigned int i;
-   struct irq_desc *desc;
-   unsigned long flags;
-
-   local_irq_save(flags);
-
-   for_each_irq_desc(i, desc) {
-   bool affinity_broken;
-
-   raw_spin_lock(>lock);
-   affinity_broken = migrate_one_irq(desc);
-   raw_spin_unlock(>lock);
-
-   if (affinity_broken)
-   pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
-   i, smp_processor_id());
-   }
-
-   local_irq_restore(flags);
-}
-#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7d95663..70d5b23 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -33,6 +33,7 @@ config ARM64
select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IRQ_PROBE
+   select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index bbb251b..0916929 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -7,7 +7,6 @@
 
 struct pt_regs;
 
-extern void migrate_irqs(void);
 extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
 static inline void 

Re: [PATCH v4 3/5] dt/bindings: bcm2835: add binding documentation for bcm2835-aux

[Stephen Warren]

On 09/04/2015 01:26 AM, Martin Sperl wrote:
> 
>> On 26.08.2015, at 03:44, Stephen Warren  wrote:
>>
>> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>>
>>> +Example:
>>> +
>>> +aux_enable: aux_enable@0x7e215004 {
>>> +   compatible = "bcrm,bcm2835-aux";
>>> +   reg = <0x7e215004 0x04>;
>>
>> I'd expect that to be <0x7e215000 0x8>;
> 
> The reason is that we just handle enable with this driver,
> which just requires access to the 0x7e215004 register.
> 
> The 0x7e215000 register (interrupt mask) could be used by a
> cascaded interrupt-controller, but as the spi and uart drivers
> can run with shared interrupts this is not a necessity.

The DT is supposed to describe the HW, not any particular SW's use of
the HW. If the HW block has 2 registers, so must the DT reg property.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 2/3] ia64: rename migrate_irqs() to avoid compiling error

[Yang Yingliang]

To avoid multi-declaration error after adding migrate_irqs into
kernel/irq/migration.c, rename migrate_irqs() to move_irqs().

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/ia64/kernel/irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
index de4fc00..005f339 100644
--- a/arch/ia64/kernel/irq.c
+++ b/arch/ia64/kernel/irq.c
@@ -98,7 +98,7 @@ unsigned int vectors_in_migration[NR_IRQS];
  * Since cpu_online_mask is already updated, we just need to check for
  * affinity that has zeros
  */
-static void migrate_irqs(void)
+static void move_irqs(void)
 {
int irq, new_cpu;
 
@@ -167,7 +167,7 @@ void fixup_irqs(void)
 * Phase 1: Locate IRQs bound to this cpu and
 * relocate them for cpu removal.
 */
-   migrate_irqs();
+   move_irqs();
 
/*
 * Phase 2: Perform interrupt processing for all entries reported in
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 0/3] arm/arm64: fix a migrating irq bug when hotplug cpu

[Yang Yingliang]

Changes in v3:
 - introduce config GENERIC_IRQ_MIGRATION for compiling migration.c
 - rename migrate_irqs in arch/ia64/kernel/irq.c to avoid compiling error

Changes in v2:
 - use the exiting helper to set IRQD_MOVE_PCNTXT flag
 - use for_each_active_irq() instead of for_each_irq_desc()
 - add some warn messages when affinity is null or do set affinity failed


Hi All,

There is a bug:

When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value.



As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts
code and fix the migrating irq bug while cpu is offline.

I'm trying let the core code do the migrating interrupts matter. 
kernel/irq/migration.c
depends on CONFIG_GENERIC_PENDING_IRQ, so I introduce config 
GENERIC_IRQ_MIGRATION for
compiling migration.c. On ia64, there is a migrate_irqs() in 
arch/ia64/kernel/irq.c,
rename it to avoid compiling error.

With the above preparation, move the migrating interrupts code into 
kernel/irq/migration.c
and fix the bug by using irq_do_set_affinity().

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 

Yang Yingliang (3):
  genirq: introduce CONFIG_GENERIC_IRQ_MIGRATION
  ia64: rename migrate_irqs() to avoid compiling error
  arm/arm64: fix a migrating irq bug when hotplug cpu

 arch/arc/Kconfig |  1 +
 arch/arm/Kconfig |  1 +
 arch/arm/include/asm/irq.h   |  1 -
 arch/arm/kernel/irq.c| 62 
 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/irq.h |  1 -
 arch/arm64/kernel/irq.c  | 62 
 arch/hexagon/Kconfig |  1 +
 arch/ia64/Kconfig|  1 +
 arch/ia64/kernel/irq.c   |  4 +--
 arch/tile/Kconfig|  1 +
 arch/x86/Kconfig |  1 +
 include/linux/irq.h  |  4 +++
 kernel/irq/Kconfig   |  4 +++
 kernel/irq/Makefile  |  2 +-
 kernel/irq/migration.c   | 68 
 16 files changed, 86 insertions(+), 129 deletions(-)

-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 1/3] genirq: introduce CONFIG_GENERIC_IRQ_MIGRATION

[Yang Yingliang]

Introduce a more general config for compile kernel/irq/migration.c.
Move the CONFIG_GENERIC_PENDING_IRQ into migration.c. So we can
move other migration interrupts code into migration.c without
select CONFIG_GENERIC_PENDING_IRQ.

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/arc/Kconfig   | 1 +
 arch/hexagon/Kconfig   | 1 +
 arch/ia64/Kconfig  | 1 +
 arch/tile/Kconfig  | 1 +
 arch/x86/Kconfig   | 1 +
 kernel/irq/Kconfig | 4 
 kernel/irq/Makefile| 2 +-
 kernel/irq/migration.c | 2 ++
 8 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 78c0621..4133070 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -20,6 +20,7 @@ config ARC
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_SMP_IDLE_THREAD
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 4dc89d1..18d3255 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -12,6 +12,7 @@ config HEXAGON
# select ARCH_REQUIRE_GPIOLIB
# select HAVE_CLK
# select GENERIC_PENDING_IRQ if SMP
+   # select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_ATOMIC64
select HAVE_PERF_EVENTS
# GENERIC_ALLOCATOR is used by dma_alloc_coherent()
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e..e48c2c8 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -37,6 +37,7 @@ config IA64
select ARCH_DISCARD_MEMBLOCK
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_LEGACY
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 106c21b..bf8b059 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -14,6 +14,7 @@ config TILE
select HAVE_DEBUG_KMEMLEAK
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_IRQ_SHOW
select HAVE_DEBUG_BUGVERBOSE
select VIRT_TO_BUS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7aef2d5..a217a23 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -68,6 +68,7 @@ config X86
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_PENDING_IRQ  if SMP
+   select GENERIC_IRQ_MIGRATIONif SMP
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 9a76e3b..530c54a 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -30,6 +30,10 @@ config GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
 config GENERIC_PENDING_IRQ
bool
 
+# Support for generic irq migration
+config GENERIC_IRQ_MIGRATION
+   bool
+
 # Alpha specific irq affinity mechanism
 config AUTO_IRQ_AFFINITY
bool
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index d121235..bdd31b7 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -4,6 +4,6 @@ obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o
 obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o
 obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
 obj-$(CONFIG_PROC_FS) += proc.o
-obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o
+obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += migration.o
 obj-$(CONFIG_PM_SLEEP) += pm.o
 obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c
index 37ddb7b..1ff2b77 100644
--- a/kernel/irq/migration.c
+++ b/kernel/irq/migration.c
@@ -4,6 +4,7 @@
 
 #include "internals.h"
 
+#ifdef CONFIG_GENERIC_PENDING_IRQ
 void irq_move_masked_irq(struct irq_data *idata)
 {
struct irq_desc *desc = irq_data_to_desc(idata);
@@ -77,3 +78,4 @@ void irq_move_irq(struct irq_data *idata)
if (!masked)
idata->chip->irq_unmask(idata);
 }
+#endif
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Wanpeng Li]

On 9/15/15 8:54 PM, Paolo Bonzini wrote:


On 15/09/2015 12:30, Wanpeng Li wrote:

+   if (!nested) {
+   vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
+   if (vpid < VMX_NR_VPIDS) {
vmx->vpid = vpid;
__set_bit(vpid, vmx_vpid_bitmap);
+   }
+   } else {
+   vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
+   if (vpid < VMX_NR_VPIDS) {
+   vmx->nested.vpid02 = vpid;
+   __set_bit(vpid, vmx_vpid_bitmap);
+   }

Messy indentation, and a lot of duplicate code.  Can you instead have
(which I think was Jan's suggestion too):

static int allocate_vpid(void);
static void free_vpid(int vpid);


I see, done in v3.



That said, I like the simple solution to the "too many VPIDs for each L1
VCPU" processor.


Thanks. :-)

Regards,
Wanpeng Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

On 08/28/2015 11:27 AM, Simon Glass wrote:
> Hi Rob,
> 
> On 25 August 2015 at 10:22, Rob Herring  wrote:
>> On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass  wrote:
>>> Hi Rob,
>>>
>>> On 14 August 2015 at 14:29, Rob Herring  wrote:
 On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass  wrote:
> -linux-tegra
>
> Hi,
>
> On 12 August 2015 at 07:21, Simon Glass  wrote:
>> Hi Lucas,
>>
>> On 11 August 2015 at 11:05, Lucas Stach  wrote:
>>> Hi Simon,
>>>
>>> why did you send this to the Tegra ML?
>>>
>>> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
 This updates the device tree from the kernel version to something 
 suitable
 for U-Boot:

 - Add stdout-path alias for console
 - Mark the /soc node to be available pre-relocation so that the early
 serial console works (we need the 'ranges' property to be available)

[... discussion of u-boot,dm-pre-reloc property]
 Can't the need for that property change over time? Either as more
 drivers are converted to DM you need to add this or you add some
 feature that depends on a driver (e.g. get a board rev or boot mode
 from GPIO). You would have backwards compatibility issues with this.
 I'm somewhat less worried about that for u-boot as we should be
 bundling the dtb and bootloader rather than kernel and dtb. For the
 UART, you can just get which UART to initialize early from
 stdout-path. But for other cases, couldn't you just have the platform
 provide the list of needed drivers. Then when u-boot needs change, you
 just change u-boot.
>>>
>>> Yes U-Boot and its device tree are normally built from the same tree
>>> at the same time. We don't expect to have to support an older or newer
>>> device tree with the same U-Boot binary. So I don't see a problem
>>> here.
>>
>> My point is that if I had to pick how bootloader+dtb+kernel are
>> bundled or not, I would rather see the dtb in sync with the bootloader
>> rather than the kernel. But I can't decide that for everyone and
>> neither can you. You still have a compatibility problem and that has
>> to be addressed.
> 
> What are you getting at here? If I move to a new kernel and still use
> an old device tree I may be missing features, or fail to boot. Don't
> do that!

One of the central points of DT is that it is an ABI. As such, moving to
a new kernel and continuing to use the same old DTB *MUST NOT* break
anything. Of course, you won't get any features enabled/described in any
new DT if you don't use it.

...
> After reading your email I am none the wiser about what you are suggesting.
> 
> This is not a screwy case. Every board will have a console. In some
> cases it is inside a 'soc {' node and in some cases it is not. The
> pure solution would be to mark every UART node with
> u-boot,dm-pre-reloc and we can do that if you prefer. It isn't
> necessary though for the reasons I previously explained.
> 
> It seems reasonable that U-Boot should be able to add private
> properties to the device tree, intended for U-Boot, just as Linux
> does. What is the problem here?

Why is that reasonable? DT is intended to describe the HW. It is
supposed to be OS-agnostic. Having U-Boot-specific properties completely
goes against that.

What Linux-specific properties are you referring to? The only one I
recall you mentioning (although I'm missing a lot of sleep right now) is
the keycodes in the input binding. While the DT property name for those
is linux,... and the values happen to match internal Linux numbering,
there's absolutely nothing Linux specific about the /concept/ of a
keycode, and some numbering scheme had to be picked. There's nothing
practical or conceptual stopping any other OS/SW-stack from translating
those Linux IDs into something internally meaningful. Conversely, the
concept of e.g. "u-boot,dm-pre-reloc" is not something that translates
at all to any other OS/WW-stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/2] KVM: nested VPID emulation

[Wanpeng Li]

v2 -> v3:
 * enhance allocate/free_vpid as Jan's suggestion
 * add more comments to 2/2

v1 -> v2:
 * enhance allocate/free_vpid to handle shadow vpid
 * drop empty space
 * allocate shadow vpid during initialization
 * For each nested vmentry, if vpid12 is changed, reuse shadow vpid w/ an 
   invvpid.

VPID is used to tag address space and avoid a TLB flush. Currently L0 use 
the same VPID to run L1 and all its guests. KVM flushes VPID when switching 
between L1 and L2. 

This patch advertises VPID to the L1 hypervisor, then address space of L1 and 
L2 can be separately treated and avoid TLB flush when swithing between L1 and 
L2.

Performance: 

run lmbench on L2 w/ 3.5 kernel.

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
kernelLinux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.6 2.88000  
nested VPID 
kernelLinux 3.5.0-1 1.2600 1.4300 1.5600   12.7   12.9 3.49000 7.46000  
vanilla

Wanpeng Li (2):
  KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid
  KVM: nVMX: nested VPID emulation

 arch/x86/kvm/vmx.c | 61 +-
 1 file changed, 42 insertions(+), 19 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Wanpeng Li]

Enhance allocate/free_vid to handle shadow vpid.

Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9ff6a3f..4956081 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4155,29 +4155,27 @@ static int alloc_identity_pagetable(struct kvm *kvm)
return r;
 }
 
-static void allocate_vpid(struct vcpu_vmx *vmx)
+static int allocate_vpid(void)
 {
-   int vpid;
+   int vpid = 0;
 
-   vmx->vpid = 0;
if (!enable_vpid)
-   return;
+   return 0;
spin_lock(_vpid_lock);
vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
-   if (vpid < VMX_NR_VPIDS) {
-   vmx->vpid = vpid;
+   if (vpid < VMX_NR_VPIDS)
__set_bit(vpid, vmx_vpid_bitmap);
-   }
spin_unlock(_vpid_lock);
+   return vpid;
 }
 
-static void free_vpid(struct vcpu_vmx *vmx)
+static void free_vpid(int vpid)
 {
if (!enable_vpid)
return;
spin_lock(_vpid_lock);
-   if (vmx->vpid != 0)
-   __clear_bit(vmx->vpid, vmx_vpid_bitmap);
+   if (vpid != 0)
+   __clear_bit(vpid, vmx_vpid_bitmap);
spin_unlock(_vpid_lock);
 }
 
@@ -8482,7 +8480,7 @@ static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
 
if (enable_pml)
vmx_disable_pml(vmx);
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
leave_guest_mode(vcpu);
vmx_load_vmcs01(vcpu);
free_nested(vmx);
@@ -8501,7 +8499,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
if (!vmx)
return ERR_PTR(-ENOMEM);
 
-   allocate_vpid(vmx);
+   vmx->vpid = allocate_vpid();
 
err = kvm_vcpu_init(>vcpu, kvm, id);
if (err)
@@ -8577,7 +8575,7 @@ free_msrs:
 uninit_vcpu:
kvm_vcpu_uninit(>vcpu);
 free_vcpu:
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
kmem_cache_free(kvm_vcpu_cache, vmx);
return ERR_PTR(err);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] KVM: nVMX: nested VPID emulation

[Wanpeng Li]

VPID is used to tag address space and avoid a TLB flush. Currently L0 use 
the same VPID to run L1 and all its guests. KVM flushes VPID when switching 
between L1 and L2. 

This patch advertises VPID to the L1 hypervisor, then address space of L1 and 
L2 can be separately treated and avoid TLB flush when swithing between L1 and 
L2. For each nested vmentry, if vpid12 is changed, reuse shadow vpid w/ an 
invvpid.

Performance: 

run lmbench on L2 w/ 3.5 kernel.

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
kernelLinux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.6 2.88000  
nested VPID 
kernelLinux 3.5.0-1 1.2600 1.4300 1.5600   12.7   12.9 3.49000 7.46000  
vanilla

Suggested-by: Wincy Van 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4956081..2fd5b5e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -424,6 +424,9 @@ struct nested_vmx {
/* to migrate it to L2 if VM_ENTRY_LOAD_DEBUG_CONTROLS is off */
u64 vmcs01_debugctl;
 
+   u16 vpid02;
+   u16 last_vpid;
+
u32 nested_vmx_procbased_ctls_low;
u32 nested_vmx_procbased_ctls_high;
u32 nested_vmx_true_procbased_ctls_low;
@@ -1155,6 +1158,11 @@ static inline bool 
nested_cpu_has_virt_x2apic_mode(struct vmcs12 *vmcs12)
return nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
 }
 
+static inline bool nested_cpu_has_vpid(struct vmcs12 *vmcs12)
+{
+   return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_VPID);
+}
+
 static inline bool nested_cpu_has_apic_reg_virt(struct vmcs12 *vmcs12)
 {
return nested_cpu_has2(vmcs12, SECONDARY_EXEC_APIC_REGISTER_VIRT);
@@ -2469,6 +2477,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
SECONDARY_EXEC_RDTSCP |
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
+   SECONDARY_EXEC_ENABLE_VPID |
SECONDARY_EXEC_APIC_REGISTER_VIRT |
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_WBINVD_EXITING |
@@ -6662,6 +6671,7 @@ static void free_nested(struct vcpu_vmx *vmx)
return;
 
vmx->nested.vmxon = false;
+   free_vpid(vmx->nested.vpid02);
nested_release_vmcs12(vmx);
if (enable_shadow_vmcs)
free_vmcs(vmx->nested.current_shadow_vmcs);
@@ -8547,8 +8557,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
goto free_vmcs;
}
 
-   if (nested)
+   if (nested) {
nested_vmx_setup_ctls_msrs(vmx);
+   vmx->nested.vpid02 = allocate_vpid();
+   }
 
vmx->nested.posted_intr_nv = -1;
vmx->nested.current_vmptr = -1ull;
@@ -8569,6 +8581,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
return >vcpu;
 
 free_vmcs:
+   free_vpid(vmx->nested.vpid02);
free_loaded_vmcs(vmx->loaded_vmcs);
 free_msrs:
kfree(vmx->guest_msrs);
@@ -9444,12 +9457,24 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, 
struct vmcs12 *vmcs12)
 
if (enable_vpid) {
/*
-* Trivially support vpid by letting L2s share their parent
-* L1's vpid. TODO: move to a more elaborate solution, giving
-* each L2 its own vpid and exposing the vpid feature to L1.
+* There is no direct mapping between vpid02 and vpid12, the
+* vpid02 is per-vCPU for L0 and reused while the value of
+* vpid12 is changed w/ one invvpid during nested vmentry.
+* The vpid12 is allocated by L1 for L2, so it will not
+* influence global bitmap(for vpid01 and vpid02 allocation)
+* even if spawn a lot of nested vCPUs.
 */
-   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
-   vmx_flush_tlb(vcpu);
+   if (nested_cpu_has_vpid(vmcs12)) {
+   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->nested.vpid02);
+   if (vmcs12->virtual_processor_id != 
vmx->nested.last_vpid) {
+   vmx->nested.last_vpid = 
vmcs12->virtual_processor_id;
+   vmx_flush_tlb(vcpu);
+   }
+   } else {
+   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
+   vmx_flush_tlb(vcpu);
+   }
+
}
 
if 

Re: [PATCH RFC 6/8] drm: hisilicon: Add support for fbdev

[Xinwei Kong]

hi rob

On 2015/9/16 2:25, Rob Herring wrote:
> On 09/15/2015 04:37 AM, Xinwei Kong wrote:
>> If you config DRM_HISI_FBDEV optional, this patch will only support fbdev
>> mode while also supporting double buffer.
> 
> This is a lot of duplicated code from CMA fbdev. Is double buffering the
> only reason why CMA fbdev can't be used or are there some other
> constraints? Double buffering in fbdev has always been a hack, so I'm
> guessing that is not a feature that should be added here.
> 
I will drop it.

xinwei
> Rob
> 
>> Signed-off-by: Xinliang Liu 
>> Signed-off-by: Xinwei Kong 
>> Signed-off-by: Andy Green 
>> Signed-off-by: Jiwen Qi 
>> Signed-off-by: Yu Gong 
>> ---
>>  drivers/gpu/drm/hisilicon/Kconfig  |  13 +
>>  drivers/gpu/drm/hisilicon/Makefile |   3 +-
>>  drivers/gpu/drm/hisilicon/hisi_drm_connector.c |   4 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_drv.c   |   9 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c   |  15 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fb.h|   5 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c | 395 
>> +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h |  24 ++
>>  8 files changed, 467 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c
>>  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h
> 
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Company Payment Agent Needed!!!

[Shougang Group Co., Ltd.]

--
Shougang Group Co., Ltd.
11th Floor, Huaxingge,
Donghua Building, Jiangmen,
GuangDong, China.

Greetings,

This is an official request for Professional/consultants who will  
stand as our regional representative to run logistics on behalf of  
Shougang Group.We are looking for a payment collection agent in USA,  
Canada, Mexico and Europe. Salary is 10% of every payment you receive  
from our customers. Get back to us for more details if interested.


Kindly send us the following information for more details

(1)Your Full names:
(2)Your Complete Address:
a. City:
b. State:
c. Zip code:
d. Country:
(3)Tele/cell numbers:
(4)Occupation:
(5)Gender:
(6)Age:
(7)Email:

Respectfully
Mr Sun Xiao Lan (Human Resources)
Shougang Group

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Sep 16

[Stephen Rothwell]

Hi all,

Changes since 20150915:

Dropped tree: akpm-current (build conflict)

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The net-next tree gained a build failure for which I applied a fix patch.

The bluetooth tree still had its build failure.

The tip tree gained a build failure so I used the version from
next-20150915.

The akpm-current tree still had its build failure so I dropped it again
for today.

Non-merge commits (relative to Linus' tree): 1179
 978 files changed, 65094 insertions(+), 13956 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (09a77a885233 modsign: Fix GPL/OpenSSL licence 
incompatibility)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (c2172ce23030 Merge branch 'uaccess' into fixes)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (e297c939b745 powerpc/MSI: Fix race condition in 
tearing down MSI interrupts)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (892aa01df2ad net: stmmac: Use msleep rather then udelay for 
reset delay)
Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in 
_decode_session6)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (d5da9d99d4d7 PCI: Revert "PCI: Call 
pci_read_bridge_bases() from core instead of arch code")
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging tty.current/tty-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb.current/usb-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb-gadget-fixes/fixes (762982db33b2 usb: phy: phy-generic: Fix reset 
behaviour on legacy boot)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (8b5081c876bd staging: unisys: visornic: 
handle error return from device registration)
Merging char-misc.current/char-misc-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging input-current/for-linus (53431d0a3534 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (84cba178a3b8 crypto: testmgr - don't copy from 
source IV too much)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit rule)
Merging backlight-fixes/for-backlight-fixe

Gelten Sie für dringende Darlehen bieten1.1%

[BancoPosta Online Loans]

--
BancoPosta Loans
Viale Europa,
175-00144 Roma,
Italy.

Email: bancopost...@gmail.com

Guten Tag meine Damen und Herren,

Brauchen Sie ein Darlehen für einen bestimmten Zweck?

BancoPosta Bank in Italien haben einen günstigen Kredit für Sie. Wir 
bieten gesicherten und ungesicherten persönlichen Darlehen Kunden für 
jeden Zweck, ob ein neues Unternehmen, Privatpersonen und Unternehmen zu 
starten, oder Sie haben ein großes Projekt im Auge. Ein persönliches 
Darlehen, das Sie überall für alles verwenden können, sollten Sie die 
Freiheit, die BancoPosta Bank Darlehen Programm anbieten kann. Mit einer 
vereinfachten Kreditantrag erhalten Sie Ihr BancoPosta Darlehen 
genehmigt und am selben Tag, die Sie anwenden, mit der niedrigen Rate 
von 1.1% der flexiblen Kreditkonditionen aus (1 Jahr auf 20 Jahre), 
Borrow (10,000.00 Euro/Chf bis 100,000,000.00 Euro/Chf) für einen 
bestimmten Zweck ausgestellt. Wenn Sie benötigen ein Darlehen, füllen 
Sie das Antragsformular aus, um loszulegen.


Ihr vollständiger Name: ___
Ihre Adresse: ___
Ihr Darlehensbetrag: ___
Miet-Zweck: ___
Darlehen-Dauer: ___

Bewerben Sie sich jetzt und überlassen Sie uns den Rest!

Vielen Dank für Ihre Schirmherrschaft.

Unser Ziel ist die Erfüllung Ihrer finanziellen Bedürfnisse!

Alles Gute
Massimo Sarmi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] iov: restore NumVFs register to 0 before return from virtfn_max_buses()

[Ethan Zhao]

After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was left to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch restore the NumVFs register to zero after the
calculation of max_VF_buses was done and before return from
virtfn_max_buses().

Tested on stable 4.1 and passed building on stable 4.3-rc1

Signed-off-by: Ethan Zhao 
Tested-by: Sriharsha Yadagudde 
---
v1..v2:
 -Suggestions from Bjorn Helgaas (move the restoration of NumVFs register
  to virtfn_max_buses())
---
 drivers/pci/iov.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..92cee06 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -71,6 +71,8 @@ static inline u8 virtfn_max_buses(struct pci_dev *dev)
max = busnr;
}
 
+   /* restore NumVFs register to 0 */
+   pci_iov_set_numvfs(dev, 0);
return max;
 }
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 41811223e5be..8e79252b1e7c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
 DCDC3  : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
-DC1SW  : On/Off Switch : dcdc1-supply  : DCDC1 secondary output
-DC5LDO : LDO   : dcdc5-supply  : input from DCDC5
+DC1SW  : On/Off Switch : dc1sw-supply  : DCDC1 secondary output
+DC5LDO : LDO   : dc5ldo-supply : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply names

[Chen-Yu Tsai]

"dcdc1-supply" and "dcdc5-supply" are renamed to "dc1sw-supply" and
"dc5ldo-supply" respectively. Update the dts to reflect the new supply
names for the regulators.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..144f563a3d6d 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -178,8 +178,8 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
-   dcdc1-supply = <_3v0>;
-   dcdc5-supply = <_dram>;
+   dc1sw-supply = <_3v0>;
+   dc5ldo-supply = <_dram>;
 
regulators {
x-powers,dcdc-freq = <3000>;
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 01bf3476a791..27ebee8e224c 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -196,10 +196,10 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(4)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dc1sw", 1600, 3400, 100,
AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
/* LDO regulator internally chained to DCDC5 */
-   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dcdc5", 700, 1400, 100,
+   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dc5ldo", 700, 1400, 100,
 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
AXP_DESC(AXP22X, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply names

[Chen-Yu Tsai]

Hi everyone,

This series renames regulator supply names for DC1SW and DC5LDO for
the AXP221. These 2 are secondary outputs for DCDC1 and DCDC5 buck
regulators, respectively, so they are connected to them internally.
There's no external input pin to name the supplies after.

When I originally did the support, I used the parent regulator's name
for the supply name. However this results in a misleading dts:

axp221: pmic@68 {
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

...
};

At first glance, one might interpret it as "DCDC1 supplies itself".
Indeed, Maxime raised this issue.

This series renames the supply names to the regulator names themselves,
or "dc1sw-supply" and "dc5ldo-supply" respectively:

axp221: pmic@68 {
dc1sw-supply = <>;
dc5ldo-supply = <>;
...
};

Renaming these shouldn't result in any problems in the real world.
All the board designs we've seen have DCDC1 supplying a common 3/3.3V
rail, and DCDC5 supplying 1.5V for DDR3 SDRAM. These 2 would have
"always-on" set, so even if the rename results in the secondary
regulator outputs being decoupled from the primary in the software
implementation, it would just be a representation issue. Function-wise,
it would function as before. On the Linux side, no one is actually
using the secondary outputs yet.

Patch 1 renames the supply names in the axp20x DT bindings.

Patch 2 updates the axp20x regulator driver.

Patch 3 updates the only dts, the Hummingbird A31, that uses these
bindings.

If everything's ok, could we merge the first 2 patches through the
regulator tree, and the 3rd through the sunxi tree?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
regulators
  regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
  ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply
names

 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts  | 4 ++--
 drivers/regulator/axp20x-regulator.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Gelten Sie für dringende Darlehen bieten1.1%

[BancoPosta Online Loans]

--
BancoPosta Loans
Viale Europa,
175-00144 Roma,
Italy.

Email: bancopost...@gmail.com

Guten Tag meine Damen und Herren,

Brauchen Sie ein Darlehen für einen bestimmten Zweck?

BancoPosta Bank in Italien haben einen günstigen Kredit für Sie. Wir 
bieten gesicherten und ungesicherten persönlichen Darlehen Kunden für 
jeden Zweck, ob ein neues Unternehmen, Privatpersonen und Unternehmen zu 
starten, oder Sie haben ein großes Projekt im Auge. Ein persönliches 
Darlehen, das Sie überall für alles verwenden können, sollten Sie die 
Freiheit, die BancoPosta Bank Darlehen Programm anbieten kann. Mit einer 
vereinfachten Kreditantrag erhalten Sie Ihr BancoPosta Darlehen 
genehmigt und am selben Tag, die Sie anwenden, mit der niedrigen Rate 
von 1.1% der flexiblen Kreditkonditionen aus (1 Jahr auf 20 Jahre), 
Borrow (10,000.00 Euro/Chf bis 100,000,000.00 Euro/Chf) für einen 
bestimmten Zweck ausgestellt. Wenn Sie benötigen ein Darlehen, füllen 
Sie das Antragsformular aus, um loszulegen.


Ihr vollständiger Name: ___
Ihre Adresse: ___
Ihr Darlehensbetrag: ___
Miet-Zweck: ___
Darlehen-Dauer: ___

Bewerben Sie sich jetzt und überlassen Sie uns den Rest!

Vielen Dank für Ihre Schirmherrschaft.

Unser Ziel ist die Erfüllung Ihrer finanziellen Bedürfnisse!

Alles Gute
Massimo Sarmi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

[yanjiang.jin]

From: Yanjiang Jin 

Function parse_crash_elf_headers() reads e_ident[EI_CLASS] then decides to
call parse_crash_elf64_headers() or parse_crash_elf32_headers().
But this happens in run time, not compile time. So compiler will report
the below warning:

In file included from include/linux/elf.h:4:0,
 from fs/proc/vmcore.c:13:
fs/proc/vmcore.c: In function 'parse_crash_elf32_headers':
arch/mips/include/asm/elf.h:258:23: warning: initializatio
n from incompatible pointer type
  struct elfhdr *__h = (hdr); \
   ^
fs/proc/vmcore.c:1071:4: note: in expansion of macro 'elf_
check_arch'
   !elf_check_arch() ||
^

Signed-off-by: Yanjiang Jin 
---
 fs/proc/vmcore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 4e61388..576bb26 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -999,7 +999,7 @@ static void free_elfcorebuf(void)
 static int __init parse_crash_elf64_headers(void)
 {
int rc=0;
-   Elf64_Ehdr ehdr;
+   struct elfhdr ehdr;
u64 addr;
 
addr = elfcorehdr_addr;
@@ -1055,7 +1055,7 @@ fail:
 static int __init parse_crash_elf32_headers(void)
 {
int rc=0;
-   Elf32_Ehdr ehdr;
+   struct elfhdr ehdr;
u64 addr;
 
addr = elfcorehdr_addr;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

[yanjiang.jin]

From: Yanjiang Jin 

Already verified this patch on a MIPS64 cavium octeon board: CN78XX.

This patch is to eliminate the compile warning only, has no side effect in 
run-time.

Yanjiang Jin (1):
  vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

 fs/proc/vmcore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1] mm: migrate: hugetlb: putback destination hugepage to active list

[Naoya Horiguchi]

my bad, this patch is totally unrelated to the thread the previous email
replied to. I just mishandled my script wrapping git-send-email, sorry.

But just resending patch seems to be noisy, so I want this to be reviewed
on this email.
If it's inconvenient or uncommon way of submission, please let me know and
I'll resend in a new thread.

Thanks,
Naoya Horiguchi

On Wed, Sep 16, 2015 at 12:21:04AM +, Naoya Horiguchi wrote:
> Since commit bcc54222309c ("mm: hugetlb: introduce page_huge_active")
> each hugetlb page maintains its active flag to avoid a race condition between
> multiple calls of isolate_huge_page(), but current kernel doesn't set the flag
> on a hugepage allocated by migration because the proper putback routine isn't
> called. This means that users could still encounter the race referred to by
> bcc54222309c in this special case, so this patch fixes it.
> 
> Fixes: bcc54222309c ("mm: hugetlb: introduce page_huge_active")
> Signed-off-by: Naoya Horiguchi 
> Cc:   #4.1
> ---
>  mm/migrate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git v4.3-rc1/mm/migrate.c v4.3-rc1_patched/mm/migrate.c
> index c3cb566af3e2..7452a00bbb50 100644
> --- v4.3-rc1/mm/migrate.c
> +++ v4.3-rc1_patched/mm/migrate.c
> @@ -1075,7 +1075,7 @@ static int unmap_and_move_huge_page(new_page_t 
> get_new_page,
>   if (rc != MIGRATEPAGE_SUCCESS && put_new_page)
>   put_new_page(new_hpage, private);
>   else
> - put_page(new_hpage);
> + putback_active_hugepage(new_hpage);
>  
>   if (result) {
>   if (rc)
> -- 
> 2.4.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andi Kleen]

> Under what circumstances will the compiler (or linker?) do this? 

Compiler.

> LTO enabled?

Yes it's for LTO.  The optimization allows the compiler to drop unused
functions, which is very popular with users (a lot use it to get smaller
kernel images)

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: fix data race in flush_to_ldisc

[Peter Hurley]

On 09/04/2015 03:28 PM, Dmitry Vyukov wrote:
> On Thu, Sep 3, 2015 at 2:50 AM, Peter Hurley  wrote:
>> On 09/02/2015 01:53 PM, Dmitry Vyukov wrote:
>>> The data race is found with KernelThreadSanitizer (on rev 21bdb584af8c):
>>>
>>> ThreadSanitizer: data-race in release_tty
>>> Write of size 8 by thread T325 (K2579):
>>>   release_tty+0xf3/0x1c0 drivers/tty/tty_io.c:1688
>>>   tty_release+0x698/0x7c0 drivers/tty/tty_io.c:1920
>>>   __fput+0x15f/0x310 fs/file_table.c:207
>>>   fput+0x1d/0x30 fs/file_table.c:243
>>>   task_work_run+0x115/0x130 kernel/task_work.c:123
>>>   do_notify_resume+0x73/0x80
>>> tracehook_notify_resume include/linux/tracehook.h:190
>>>   do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:757
>>>   int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326
>>> Previous read of size 8 by thread T19 (K16):
>>>   flush_to_ldisc+0x29/0x300 drivers/tty/tty_buffer.c:472
>>>   process_one_work+0x47e/0x930 kernel/workqueue.c:2036
>>>   worker_thread+0xb0/0x900 kernel/workqueue.c:2170
>>>   kthread+0x150/0x170 kernel/kthread.c:207
>>
>> The stack traces are not really helpful in describing how the race
>> occurs; I would leave it out of the changelog.
>
> ok

Just to clarify; my comment is only wrt this particular patch.
You may have other patches in the future with unclear execution paths
that may require the call stacks. It's just that this particular
race has invariant call stacks (for the relevant parts).


>>> flush_to_ldisc reads port->itty and checks that it is not NULL,
>>> concurrently release_tty sets port->itty to NULL. It is possible
>>> that flush_to_ldisc loads port->itty once, ensures that it is
>>> not NULL, but then reloads it again and uses. The second load
>>> can already return NULL, which will cause a crash.
>>>
>>> Use READ_ONCE/WRITE_ONCE to read/update port->itty.
>>
>> See below.
>>
>>> Signed-off-by: Dmitry Vyukov 
>>> ---
>>>  drivers/tty/tty_buffer.c | 2 +-
>>>  drivers/tty/tty_io.c | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>>> index 4cf263d..1f1031d 100644
>>> --- a/drivers/tty/tty_buffer.c
>>> +++ b/drivers/tty/tty_buffer.c
>>> @@ -469,7 +469,7 @@ static void flush_to_ldisc(struct work_struct *work)
>>>   struct tty_struct *tty;
>>>   struct tty_ldisc *disc;
>>>
>>> - tty = port->itty;
>>> + tty = READ_ONCE(port->itty);
>>
>> This is fine.
>>
>>>   if (tty == NULL)
>>>   return;
>>>
>>> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
>>> index 57fc6ee..aad47df 100644
>>> --- a/drivers/tty/tty_io.c
>>> +++ b/drivers/tty/tty_io.c
>>> @@ -1685,7 +1685,7 @@ static void release_tty(struct tty_struct *tty, int 
>>> idx)
>>>   tty_driver_remove_tty(tty->driver, tty);
>>>   tty->port->itty = NULL;
>>>   if (tty->link)
>>> - tty->link->port->itty = NULL;
>>> + WRITE_ONCE(tty->link->port->itty, NULL);
>>
>> This isn't doing anything useful.
>>
>> 1. The compiler can't push the store past the cancel_work_sync() (because the
>>compiler has no visibility into cancel_work_sync()), and,
>> 2. There's no effect if the compiler hoists the store higher in the 
>> release_tty()
>>because the line discipline has already been closed and killed (so the
>>tty_ldisc_ref() in flush_to_ldisc() returns NULL anyway).
>
> OK, let me do one try at convincing you that WRITE_ONCE here is a good
> idea. If you are not convinced then I will remove it.

FWIW, I'm not the gatekeeper wrt tree-wide code/best-practices changes;
iow, convincing me is not a useful goal.  But I think this would be a
good topic/
presentation for either Kernel Summit or Linux Plumbers.

That said, I'll make some observations below that you should expect to read
from other contributors/maintainers regarding your point-of-view.

> WRITE_ONCE/READ_ONCE for all shared memory accesses:
> 1. Make the code more readable but highlighting important aspects.

Most would argue the additional macros detract from readability.

> 2. Required by relevant standards and relieve you, me and everybody
> else reading this code from spending time on proving that it cannot
> break (think of multi-file compilation mode, store tearing which
> compilers indeed known to do in some contexts, and compiler
> transformations that we don't know of).

Multi-file compilation and the compiler memory model are inherently
incompatible with kernel code. Instrumenting code rather than specializing
the tool (compiler) is progress in the wrong direction, imho.

Same with store tearing of primitive types.

Compiler "transforms" are an occasional hazard of kernel development,
as are straight-up compiler bugs; in my limited experience, each occurs
with equal frequency.

> 3. Allow tooling that finds undoubtedly harmful bugs, like this one,

While the READ_ONCE() fix improves robustness, I wouldn't categorize
this as a 'harmful' bug. I seriously doubt any compiler has generated
a 

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andrew Morton]

On Wed, 16 Sep 2015 04:32:19 +0200 Andi Kleen  wrote:

> > __iowrite32_copy() is marked __visible.  I don't actually know what
> > that does and Andi's d47d5c8194579bc changelog (which sucks the big
> > one) didn't explain it.  Apparently it has something to do with being
> > implemented in assembly, but zillions of functions are implemented in
> > assembly, so why are only two functions marked this way?  Anyway,
> > __ioread32_copy() is implemented in C so I guess __visible isn't needed
> > there.
> 
> __visible is needed for C functions that are called from assembler.
> Otherwise the compiler may optimize them away.

Under what circumstances will the compiler (or linker?) do this? 
LTO enabled?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] arm: Fix backtrace generation when IPI is masked

[Hillf Danton]

> 
> Currently on ARM when  is triggered from an interrupt handler
> (e.g. a SysRq issued using UART or kbd) the main CPU will wedge for ten
> seconds with interrupts masked before issuing a backtrace for every CPU
> except itself.
> 
> The new backtrace code introduced by commit 96f0e00378d4 ("ARM: add
> basic support for on-demand backtrace of other CPUs") does not work
> correctly when run from an interrupt handler because IPI_CPU_BACKTRACE
> is used to generate the backtrace on all CPUs but cannot preempt the
> current calling context.
> 
> This can be fixed by detecting that the calling context cannot be
> preempted and issuing the backtrace directly in this case. Issuing
> directly leaves us without any pt_regs to pass to nmi_cpu_backtrace()
> so we also modify the generic code to call dump_stack() when its
> argument is NULL.
> 
> Signed-off-by: Daniel Thompson 
> ---

Acked-by: Hillf Danton 
> 
> Notes:
> Changes in v3:
> 
> * Added comments to describe how raise_nmi() and nmi_cpu_backtrace()
>   interact with backtrace_mask (Russell King).
> 
> Changes in v2:
> 
> * Improved commit message to better describe the changes to the generic
>   code (Hillf Danton).
> 
>  arch/arm/kernel/smp.c |  9 +
>  lib/nmi_backtrace.c   | 11 ++-
>  2 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 48185a773852..0c4e7fdb9636 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -748,6 +748,15 @@ core_initcall(register_cpufreq_notifier);
> 
>  static void raise_nmi(cpumask_t *mask)
>  {
> + /*
> +  * Generate the backtrace directly if we are running in a calling
> +  * context that is not preemptible by the backtrace IPI. Note
> +  * that nmi_cpu_backtrace() automatically removes the current cpu
> +  * from mask.
> +  */
> + if (cpumask_test_cpu(smp_processor_id(), mask) && irqs_disabled())
> + nmi_cpu_backtrace(NULL);
> +
>   smp_cross_call(mask, IPI_CPU_BACKTRACE);
>  }
> 
> diff --git a/lib/nmi_backtrace.c b/lib/nmi_backtrace.c
> index 88d3d32e5923..6019c53c669e 100644
> --- a/lib/nmi_backtrace.c
> +++ b/lib/nmi_backtrace.c
> @@ -43,6 +43,12 @@ static void print_seq_line(struct nmi_seq_buf *s, int 
> start, int end)
>   printk("%.*s", (end - start) + 1, buf);
>  }
> 
> +/*
> + * When raise() is called it will be is passed a pointer to the
> + * backtrace_mask. Architectures that call nmi_cpu_backtrace()
> + * directly from their raise() functions may rely on the mask
> + * they are passed being updated as a side effect of this call.
> + */
>  void nmi_trigger_all_cpu_backtrace(bool include_self,
>  void (*raise)(cpumask_t *mask))
>  {
> @@ -149,7 +155,10 @@ bool nmi_cpu_backtrace(struct pt_regs *regs)
>   /* Replace printk to write into the NMI seq */
>   this_cpu_write(printk_func, nmi_vprintk);
>   pr_warn("NMI backtrace for cpu %d\n", cpu);
> - show_regs(regs);
> + if (regs)
> + show_regs(regs);
> + else
> + dump_stack();
>   this_cpu_write(printk_func, printk_func_save);
> 
>   cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
> --
> 2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: nVMX: nested VPID emulation

[Wanpeng Li]

On 9/16/15 1:32 AM, Jan Kiszka wrote:

On 2015-09-15 12:14, Wanpeng Li wrote:

On 9/14/15 10:54 PM, Jan Kiszka wrote:

Last but not least: the guest can now easily exhaust the host's pool of
vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
or should there be some limit?

I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
and the scenario which you pointed out can be avoid.

I cannot yet follow why there is no chance for L1 to consume all vpids
that the host manages in that single, global bitmap by simply spawning a
lot of nested VCPUs for some L2. What is enforcing L1 to call nested
vmclear - apparently the only way, besides destructing nested VCPUs, to
release such vpids again?


In v2, there is no direct mapping between vpid02 and vpid12, the vpid02 
is per-vCPU for L0 and reused while the value of vpid12 is changed w/ 
one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2, 
so it will not influence global bitmap(for vpid01 and vpid02 allocation) 
even if spawn a lot of nested vCPUs.


Regards,
Wanpeng Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andi Kleen]

> __iowrite32_copy() is marked __visible.  I don't actually know what
> that does and Andi's d47d5c8194579bc changelog (which sucks the big
> one) didn't explain it.  Apparently it has something to do with being
> implemented in assembly, but zillions of functions are implemented in
> assembly, so why are only two functions marked this way?  Anyway,
> __ioread32_copy() is implemented in C so I guess __visible isn't needed
> there.

__visible is needed for C functions that are called from assembler.
Otherwise the compiler may optimize them away.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/8] mmc: dw_mmc: Generic MMC tuning with the clock phase framework

[Jaehoon Chung]

Hi,

On 09/16/2015 07:09 AM, Heiko Stübner wrote:
> Hi,
> 
> Am Dienstag, 15. September 2015, 17:25:38 schrieb Jaehoon Chung:
>> On 09/01/2015 03:24 AM, Heiko Stuebner wrote:
>>> From: Alexandru M Stan 
>>>
>>> This algorithm will try 1 degree increments, since there's no way to tell
>>> what resolution the underlying phase code uses. As an added bonus, doing
>>> many tunings yields better results since some tests are run more than once
>>> (ex: if the underlying driver uses 45 degree increments, the tuning code
>>> will try the same angle more than once).
>>>
>>> It will then construct a list of good phase ranges (even ranges that cross
>>> 360/0), will pick the biggest range then it will set the sample_clk to the
>>> middle of that range.
>>>
>>> We do not touch ciu_drive (and by extension define default-drive-phase).
>>> Drive phase is mostly used to define minimum hold times, while one could
>>> write some code to determine what phase meets the minimum hold time (ex 10
>>> degrees) this will not work with the current clock phase framework (which
>>> floors angles, so we'll get 0 deg, and there's no way to know what
>>> resolution the floors happen at). We assume that the default drive angles
>>> set by the hardware are good enough.
>>>
>>> If a device has device specific code (like exynos) then that will still
>>> take precedence, otherwise this new code will execute. If the device wants
>>> to tune, but has no sample_clk defined we'll return EIO with an error
>>> message.
>>
>> Which point is "_generic_"? I don't find the code that control the register
>> relevant to CLK_DRV/SMPL PHASE. It seems that posted the similar patches at
>> u-boot mailing list..
> 
> The "generic" part is that it uses the clk phase API for dw_mmc 
> implementations where the clkgen controlling interface is outside the dw_mmc 
> IP itself. So it's open for other implementations as well.

Designware IP also has the CLK phase register(UHS_REG_EXT register)...
if this code is related with it, it should be located into dw-mmc.c.

> 
> But if you are more comfortable with it, I can also move it into the dw_mmc-
> rockchip variant for the time being, until another user comes along.

I think more better that this code is located into dw_mmc-rockchip. how about?

Best Regards,
Jaehoon Chung

> 
> 
> Heiko
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Viresh Kumar]

On 16-09-15, 04:54, Rafael J. Wysocki wrote:
> > Yes, it was slightly messed up.  Should be better now, though.

Yeah, its fine now.

> And as a side note, for patches that are in bleeding-edge only and not in
> something like linux-next, you don't need to bother anyone with fixes except
> for me (and maybe the patch author for their education mostly).
> 
> And I either drop patches that cause build problems to happen in bleeding-edge
> or fix them.  That's what bleeding-edge is for.

Okay, will keep that in mind.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig

[Yuyang Du]

On Tue, Sep 15, 2015 at 10:11:41AM -0700, bseg...@google.com wrote:
> >
> > I guess you are saying we are conflating NICE_0 with NICE_0_LOAD. But to me,
> > they are just integer metrics, needing a resolution respectively. That is 
> > it.
> 
> Yes this would change nothing at the moment post-expansion, that's not
> the point. SLR being 10 bits and the nice-0 being 1024 are completely
> and utterly unrelated and the headers should not pretend they need to be
> the same value,

I never said they are related, why should they be related. And they need or
need not to be the same value, fine.

However, the SLR has to be a value. It is because it mighe be 10 or 20 (LOAD),
therefore I make SCHED_RESOLUTION_SHIFT 10 (kind of a denominator). Not the
other way around.

We can define SCHED_RESOLUTION_SHIFT 1, and then define SLR = x * 
SCHED_RESOLUTION_SHIFT
with x being a random number, if you must.

And by the way, with SCHED_RESOLUTION_SHIFT, there will not be SLR anymore, we 
only
need SCHED_LOAD_SHIFT, which has a low resolution 1*SCHED_RESOLUTION_SHIFT or a 
high
one 2*SCHED_RESOLUTION_SHIFT. The scale_load*() is the conversion between the 
resolutions of NICE_0 and NICE_0_LOAD.

> any more than there should be a #define that is shared
> with every other use of 1024 in the kernel.

The point really is, metrics (if not many ) need resolution, not just 
NICE_0_LOAD does. 
You can choose to either hardcode a number, like SCHED_CAPACITY_SHIFT now,
or you can use SCHED_RESOLUTION_SHIFT, which is even as simple as a sign to say 
what
the defined is (the scaled one with a better resolution vs. the original one).
I guess this is to say we now have a (no-big-deal) resolution system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers: of: check input parameter name for __of_find_property

[Rob Herring]

On 09/15/2015 07:16 PM, Peng Fan wrote:
> Hi Rob,
> 
> On Tue, Sep 15, 2015 at 10:56:28AM -0500, Rob Herring wrote:
>> On 09/11/2015 08:44 AM, Peng Fan wrote:
>>> Check input parameter 'name' for __of_find_property. If name is NULL,
>>> of_prop_cmp->strcasecmp may trigger panic.
>>
>> Arguably that could be a feature. Do you have a usecase where name being
>> NULL is valid and panicking is a problem?
> 
> In drivers/pinctrl/devicetree.c
> 
> 195 propname = kasprintf(GFP_KERNEL, "pinctrl-%d", state);
> 196 prop = of_find_property(np, propname, );
> 197 kfree(propname);
> 198 if (!prop)
> 199 break;
> 
> If propname is NULL, of_find_property may trigger panic. Anyway propname 
> should be checked
> before passing to of_find_property.

propname will only be NULL if the memory allocation failed which gives
you a big warning message. I don't think you would want to continue on
in this case.

So I'm inclined to leave this as is with passing NULL to
of_find_property to always be an error and fatal.

Rob

> I did not met panic message. I wrote this patch when I was reading the piece 
> code.
> I think the name parameter should be checked before doing string compare.
> 
> Regards,
> Peng.
> 
>>
>> Rob
>>
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: Rob Herring 
>>> Cc: Frank Rowand 
>>> Cc: Grant Likely 
>>> ---
>>>  drivers/of/base.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index 8b5a187..e41436d 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -215,7 +215,7 @@ static struct property *__of_find_property(const struct 
>>> device_node *np,
>>>  {
>>> struct property *pp;
>>>  
>>> -   if (!np)
>>> +   if (!np || !name)
>>> return NULL;
>>>  
>>> for (pp = np->properties; pp; pp = pp->next) {
>>>
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 04:48:37 AM Rafael J. Wysocki wrote:
> On Wednesday, September 16, 2015 07:30:23 AM Viresh Kumar wrote:
> > On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> > > On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > > > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > > > and used outside of it. And that breaks kernel build:
> > > > 
> > > > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference 
> > > > to `wakeup_irq'
> > > > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > > > `wakeup_irq'
> > > > 
> > > > Fix it by defining the variable outside of the ifdef.
> > > > 
> > > > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > > > wakeup")
> > > > Signed-off-by: Viresh Kumar 
> > > 
> > > I've applied the v11 of the Alexandra's patch that doesn't have this 
> > > problem AFAICS.
> > 
> > For the record, as we have talked on IRC, even the v11 patch suffers
> > from this problem and you will be fixing it.
> 
> Yes, it was slightly messed up.  Should be better now, though.

And as a side note, for patches that are in bleeding-edge only and not in
something like linux-next, you don't need to bother anyone with fixes except
for me (and maybe the patch author for their education mostly).

And I either drop patches that cause build problems to happen in bleeding-edge
or fix them.  That's what bleeding-edge is for.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] arm64: mediatek: enable MTK_TIMER

[Yingjoe Chen]

On Wed, 2015-09-16 at 10:04 +0800, Yingjoe Chen wrote:
> Enable MTK_TIMER for MediaTek plaform, which will be used as
> schedule clock.

Sorry, sending this series too early without cover letter and removing
Change-Id. Here's the cover letter:


This is actually v3 of "add GPT timer support for mt8173" series. This
is based on v4.3-rc1 + clockevents-4.4[1] and James's mediatek-clk
tree[2].

Changes compare to previous version[3]:
- the first two mtk_timer related changes are removed because they are
replaced/accepted in clockevents tree.
- Remove 'add 13mhz clock for MT8173' because it is accepted in
mediatek-clk tree.
- Kconfig.platforms path change.

So we only have 2 patches left here.
Matthias, can you take these and help to remove the Change-Id?


Daniel Kurtz (1):
  arm64: dts: mt8173: add timer node

Yingjoe Chen (1):
  arm64: mediatek: enable MTK_TIMER



[1]
https://git.linaro.org/people/daniel.lezcano/linux.git clockevents/4.4
[2]
http://lists.infradead.org/pipermail/linux-mediatek/2015-August/002069.html
[3]
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001544.html




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 07:30:23 AM Viresh Kumar wrote:
> On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> > On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > > and used outside of it. And that breaks kernel build:
> > > 
> > > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference 
> > > to `wakeup_irq'
> > > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > > `wakeup_irq'
> > > 
> > > Fix it by defining the variable outside of the ifdef.
> > > 
> > > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > > wakeup")
> > > Signed-off-by: Viresh Kumar 
> > 
> > I've applied the v11 of the Alexandra's patch that doesn't have this 
> > problem AFAICS.
> 
> For the record, as we have talked on IRC, even the v11 patch suffers
> from this problem and you will be fixing it.

Yes, it was slightly messed up.  Should be better now, though.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPOST PATCH] ftrace: Remove the unused variant ftrace_update_time

[Minfei Huang]

On 09/15/15 at 01:01pm, Steven Rostedt wrote:
> On Wed, 16 Sep 2015 00:32:02 +0800
> Minfei Huang  wrote:
>  
> > There is one more confusion. Is it valuable to export such info to
> > userspace? What does user do, if kernel exports this?
> 
> Nothing. The dyn_ftrace_total_info is purely for debugging ftrace. It's
> something I use.
> 

hmmm...

Thanks. I don't insist for this patch, if you want to export this
variant to userspace.

Thanks
Minfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/5] ACPI: Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 03:13:12 PM Al Stone wrote:
> On 09/09/2015 03:09 PM, Al Stone wrote:
> > Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity
> > check on the various subtables that are defined for the MADT.  The check
> > compares the size of the subtable data structure as defined by ACPICA to
> > the length entry in the subtable.  If they are not the same, the assumption
> > is that the subtable is incorrect.
> > 
> > Over time, the ACPI spec has allowed for MADT subtables where this can
> > never be true (the local SAPIC subtable, for example).  Or, more recently,
> > the spec has accumulated some minor flaws where there are three possible 
> > sizes for a subtable, all of which are valid, but only for specific versions
> > of the spec (the GICC subtable).  In both cases, BAD_MADT_ENTRY reports 
> > these
> > subtables as bad when they are not.  In order to retain some sanity check
> > on the MADT subtables, we now have to special case these subtables.  Of
> > necessity, these special cases have ended up in arch-dependent code (arm64)
> > or an arch has simply decided to forgo the check (ia64).
> > 
> > This patch set replaces the BAD_MADT_ENTRY macro with a function called
> > bad_madt_entry().  This function uses a data set of details about the
> > subtables to provide more sanity checking than before:
> > 
> > -- is the subtable legal for the version given in the FADT?
> > 
> > -- is the subtable legal for the revision of the MADT in use?
> > 
> > -- is the subtable of the proper length (including checking
> >on the one variable length subtable that is currently ignored),
> >given the FADT version and the MADT revision?
> > 
> > Further, this patch set adds in the call to bad_madt_entry() from the 
> > acpi_table_parse_madt() function, allowing it to be used consistently
> > by all architectures, for all subtables, and removing the need for each
> > of the subtable traversal callback functions to use BAD_MADT_ENTRY.
> > 
> > In theory, as the ACPI specification changes, we would only have to add
> > additional information to the data set describing the MADT subtables in
> > order to continue providing sanity checks, even when new subtables are
> > added.
> > 
> > These patches have been tested on an APM Mustang (arm64) and are known to
> > work there.  They have also been cross-compiled for x86 and ia64 with no
> > known failures.
> > 
> > Changes for v3:
> >-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts
> >-- Clearer language in error messages (Graeme Gregory, Timur Tabi)
> >-- Double checked that inserting call to bad_madt_entry() into the
> >   function acpi_parse_entries() does not impact current behavior
> >   (Sudeep Holla)
> >
> > Changes for v2:
> >-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM
> >-- Correct faulty end of loop test found by Timur Tabi
> > 
> > 
> > Al Stone (5):
> >   ACPI: add in a bad_madt_entry() function to eventually replace the
> > macro
> >   ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
> >   ACPI / IA64: remove usage of BAD_MADT_ENTRY
> >   ACPI / X86: remove usage of BAD_MADT_ENTRY
> >   ACPI: remove definition of BAD_MADT_ENTRY macro
> > 
> >  arch/arm64/include/asm/acpi.h |   8 --
> >  arch/arm64/kernel/smp.c   |   2 -
> >  arch/ia64/kernel/acpi.c   |  20 
> >  arch/x86/kernel/acpi/boot.c   |  27 -
> >  drivers/acpi/tables.c | 245 
> > +-
> >  drivers/irqchip/irq-gic.c |   6 --
> >  include/linux/acpi.h  |   4 -
> >  7 files changed, 244 insertions(+), 68 deletions(-)
> > 
> 
> Ping?  Any additional comments on this version?  I have only received
> feedback from arm64 reviewers so far, over three revisions, even though
> everyone that needs to be (ACPI, ia64, x86) has also been CCd.
> 
> Anyone else before I fix a couple of things for v4 that the arm64 folks
> found?  ACKs?  NAKs?  Please don't bother me, I'm in the merge window :)?

The merge window is actually over, so why would you expect anything like that?

I'm going to apply this series if people have no problems with it.  I do think
it is slightly overkill, but then as long as it works ...

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] arm64: dts: mt8173: add timer node

[Yingjoe Chen]

From: Daniel Kurtz 

Add device node to enable GPT timer. This timer will be
used as sched clock source.

Change-Id: Idc4e3f0ee80b5c36cae6f0f2328f94aafcca1253
Signed-off-by: Daniel Kurtz 
Signed-off-by: Eddie Huang 
Signed-off-by: Yingjoe Chen 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..d763803 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -238,6 +238,15 @@
reg = <0 0x10007000 0 0x100>;
};
 
+   timer: timer@10008000 {
+   compatible = "mediatek,mt8173-timer",
+"mediatek,mt6577-timer";
+   reg = <0 0x10008000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_CLK_13M>,
+< CLK_TOP_RTC_SEL>;
+   };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt8173-pwrap";
reg = <0 0x1000d000 0 0x1000>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm64: mediatek: enable MTK_TIMER

[Yingjoe Chen]

Enable MTK_TIMER for MediaTek plaform, which will be used as
schedule clock.

Change-Id: Ib77a0bf01193102c755077b6e72e73e477b18e5f
Signed-off-by: Yingjoe Chen 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..8176455 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -42,6 +42,7 @@ config ARCH_MEDIATEK
bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
select ARM_GIC
select PINCTRL
+   select MTK_TIMER
help
  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Viresh Kumar]

On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > and used outside of it. And that breaks kernel build:
> > 
> > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference to 
> > `wakeup_irq'
> > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > `wakeup_irq'
> > 
> > Fix it by defining the variable outside of the ifdef.
> > 
> > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > wakeup")
> > Signed-off-by: Viresh Kumar 
> 
> I've applied the v11 of the Alexandra's patch that doesn't have this problem 
> AFAICS.

For the record, as we have talked on IRC, even the v11 patch suffers
from this problem and you will be fixing it.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

On 16-09-15, 04:06, Rafael J. Wysocki wrote:
> In any case, please just split the EC-related changes off from your second
> patch and send them separately.

That !! change isn't required anymore, will be dropping it completely.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

[Dave Young]

> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> >> new file mode 100644
> >> index 000..7ae45cc
> >> --- /dev/null
> >> +++ b/drivers/watchdog/sbsa_gwdt.c
> >> @@ -0,0 +1,459 @@
> >> +/*
> >> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> >> + *
> >> + * Copyright (c) 2015, Linaro Ltd.
> >> + * Author: Fu Wei 
> >> + * Suravee Suthikulpanit 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License 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.
> >> + *
> >> + * The SBSA Generic watchdog driver is compatible with the pretimeout
> >> + * concept of Linux kernel.
> >> + * The timeout and pretimeout are determined by WCV or WOR.
> >> + * The first watch period is set by writing WCV directly, that can
> >> + * support more than 10s timeout at the maximum system counter
> >> + * frequency (400MHz).
> >> + * When WS0 is triggered, the second watch period (pretimeout) is
> >> + * determined by one of these registers:
> >> + * (1)WOR: 32bit register, this gives a maximum watch period of
> >> + * around 10s at the maximum system counter frequency. It's loaded
> >> + * automatically by hardware.
> >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout",
> >> + * it will be loaded in WS0 interrupt routine. If system is in
> >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled
> >> + * and WS0 == true), the ping operation will only reload WCV.
> >
> > Below is the field comment about ws0_mode, it says ws0_mode is only
> > for rebooting in second stage timeout, but kexec/kdump can reboot in
> > either first or second stage
> 
> Great thanks for your feedback.
> 
> yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be set.
> in this case, if WS0 is triggered during the reboot(AFAIK, panic will
> disable irq, and in the early boot stage of system, irq is disabled,
> too.), ws0_mode will be set at the next "open" in kdump kernel
> if WS0 haven't triggered until the watchdog is opened again in kdump
> kernel , ws0_mode won't  be set.
> 
> ws0_mode doesn't indicate if the system is in the kdump kernel, it
> indicates that if WS0 is triggered, when the watchdog is initialized.
> 
> Do I answer your question?

Yes, thanks for explanation. So it sounds better to change the comment like 
below?
from
(reboot by kexec/kdump in panic with watchdog enabled and WS0 == true)
to
(reboot in the pre-timeout stage and WS0 == true)

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] jump_label: make static_key_enabled() work on static_key_true/false types too

[Tejun Heo]

static_key_enabled() can be used on struct static_key but not on its
wrapper types static_key_true and static_key_false.  The function is
useful for debugging and management of static keys.  Update it so that
it can be used for the wrapper types too.

Signed-off-by: Tejun Heo 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
---
Hello,

If this patch is acceptable, please let me know how it should be
routed.

Thanks.

 include/linux/jump_label.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8..c9ca050 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -216,11 +216,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
-static inline bool static_key_enabled(struct static_key *key)
-{
-   return static_key_count(key) > 0;
-}
-
 static inline void static_key_enable(struct static_key *key)
 {
int count = static_key_count(key);
@@ -267,6 +262,17 @@ struct static_key_false {
 #define DEFINE_STATIC_KEY_FALSE(name)  \
struct static_key_false name = STATIC_KEY_FALSE_INIT
 
+extern bool wrong_branch_error(void);
+
+#define static_key_enabled(x)  
\
+({ 
\
+   if (!__builtin_types_compatible_p(typeof(*x), struct static_key) && 
\
+   !__builtin_types_compatible_p(typeof(*x), struct static_key_true) 
&&\
+   !__builtin_types_compatible_p(typeof(*x), struct static_key_false)) 
\
+   wrong_branch_error();   
\
+   static_key_count((struct static_key *)x) > 0;   
\
+})
+
 #ifdef HAVE_JUMP_LABEL
 
 /*
@@ -325,8 +331,6 @@ struct static_key_false {
  * See jump_label_type() / jump_label_init_type().
  */
 
-extern bool wrong_branch_error(void);
-
 #define static_branch_likely(x)
\
 ({ 
\
bool branch;
\
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] cgroup: replace cgroup_subsys->disabled tests with cgroup_subsys_enabled()

[Tejun Heo]

Replace cgroup_subsys->disabled tests in controllers with
cgroup_subsys_enabled().  cgroup_subsys_enabled() requires literal
subsys name as its parameter and thus can't be used for cgroup core
which iterates through controllers.  For cgroup core, introduce and
use cgroup_ssid_enabled() which uses slower static_key_enabled() test
and can be indexed by subsys ID.

This leaves cgroup_subsys->disabled unused.  Removed.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 include/linux/cgroup-defs.h|  1 -
 include/linux/hugetlb_cgroup.h |  4 +---
 include/linux/memcontrol.h |  4 +---
 kernel/cgroup.c| 28 +---
 4 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 4d8fcf2..c5d41c3 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -419,7 +419,6 @@ struct cgroup_subsys {
 struct task_struct *task);
void (*bind)(struct cgroup_subsys_state *root_css);
 
-   int disabled;
int early_init;
 
/*
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index bcc853e..7edd305 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -48,9 +48,7 @@ int set_hugetlb_cgroup(struct page *page, struct 
hugetlb_cgroup *h_cg)
 
 static inline bool hugetlb_cgroup_disabled(void)
 {
-   if (hugetlb_cgrp_subsys.disabled)
-   return true;
-   return false;
+   return !cgroup_subsys_enabled(hugetlb_cgrp_subsys);
 }
 
 extern int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index ad800e6..9aa7820 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -347,9 +347,7 @@ ino_t page_cgroup_ino(struct page *page);
 
 static inline bool mem_cgroup_disabled(void)
 {
-   if (memory_cgrp_subsys.disabled)
-   return true;
-   return false;
+   return !cgroup_subsys_enabled(memory_cgrp_subsys);
 }
 
 /*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3619389..5703ba7 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -224,6 +224,19 @@ static void kill_css(struct cgroup_subsys_state *css);
 static int cgroup_addrm_files(struct cgroup *cgrp, struct cftype cfts[],
  bool is_add);
 
+/**
+ * cgroup_ssid_enabled - cgroup subsys enabled test by subsys ID
+ * @ssid: subsys ID of interest
+ *
+ * cgroup_subsys_enabled() can only be used with literal subsys names which
+ * is fine for individual subsystems but unsuitable for cgroup core.  This
+ * is slower static_key_enabled() based test indexed by @ssid.
+ */
+static bool cgroup_ssid_enabled(int ssid)
+{
+   return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
+}
+
 /* IDR wrappers which synchronize using cgroup_idr_lock */
 static int cgroup_idr_alloc(struct idr *idr, void *ptr, int start, int end,
gfp_t gfp_mask)
@@ -1482,7 +1495,7 @@ static int parse_cgroupfs_options(char *data, struct 
cgroup_sb_opts *opts)
for_each_subsys(ss, i) {
if (strcmp(token, ss->legacy_name))
continue;
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(i))
continue;
 
/* Mutually exclusive option 'all' + subsystem name */
@@ -1513,7 +1526,7 @@ static int parse_cgroupfs_options(char *data, struct 
cgroup_sb_opts *opts)
 */
if (all_ss || (!one_ss && !opts->none && !opts->name))
for_each_subsys(ss, i)
-   if (!ss->disabled)
+   if (cgroup_ssid_enabled(i))
opts->subsys_mask |= (1 << i);
 
/*
@@ -2762,7 +2775,8 @@ static ssize_t cgroup_subtree_control_write(struct 
kernfs_open_file *of,
if (tok[0] == '\0')
continue;
for_each_subsys_which(ss, ssid, _ss_mask) {
-   if (ss->disabled || strcmp(tok + 1, ss->name))
+   if (!cgroup_ssid_enabled(ssid) ||
+   strcmp(tok + 1, ss->name))
continue;
 
if (*tok == '+') {
@@ -3320,7 +3334,7 @@ static int cgroup_add_cftypes(struct cgroup_subsys *ss, 
struct cftype *cfts)
 {
int ret;
 
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(ss->id))
return 0;
 
if (!cfts || cfts[0].name[0] == '\0')
@@ -5082,7 +5096,7 @@ int __init cgroup_init(void)
 * disabled flag and cftype registration needs kmalloc,
 * both of which aren't available during early_init.
 */
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(ssid))

[PATCH 4/4] cgroup: replace cgroup_on_dfl() tests in controllers with cgroup_subsys_on_dfl()

[Tejun Heo]

cgroup_on_dfl() tests whether the cgroup's root is the default
hierarchy; however, an individual controller is only interested in
whether the controller is attached to the default hierarchy and never
tests a cgroup which doesn't belong to the hierarchy that the
controller is attached to.

This patch replaces cgroup_on_dfl() tests in controllers with faster
static_key based cgroup_subsys_on_dfl().  This leaves cgroup core as
the only user of cgroup_on_dfl() and the function is moved from the
header file to cgroup.c.

Signed-off-by: Tejun Heo 
Cc: Vivek Goyal 
Cc: Jens Axboe 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 block/blk-throttle.c   |  2 +-
 block/cfq-iosched.c|  4 ++--
 include/linux/cgroup.h | 58 --
 kernel/cgroup.c| 58 ++
 kernel/cpuset.c| 23 +++-
 mm/memcontrol.c|  4 ++--
 6 files changed, 76 insertions(+), 73 deletions(-)

diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index c75a263..2149a1d 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -369,7 +369,7 @@ static void throtl_pd_init(struct blkg_policy_data *pd)
 * regardless of the position of the group in the hierarchy.
 */
sq->parent_sq = >service_queue;
-   if (cgroup_on_dfl(blkg->blkcg->css.cgroup) && blkg->parent)
+   if (cgroup_subsys_on_dfl(io_cgrp_subsys) && blkg->parent)
sq->parent_sq = _to_tg(blkg->parent)->service_queue;
tg->td = td;
 }
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 04de884..1f9093e 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1581,7 +1581,7 @@ static struct blkcg_policy_data *cfq_cpd_alloc(gfp_t gfp)
 static void cfq_cpd_init(struct blkcg_policy_data *cpd)
 {
struct cfq_group_data *cgd = cpd_to_cfqgd(cpd);
-   unsigned int weight = cgroup_on_dfl(blkcg_root.css.cgroup) ?
+   unsigned int weight = cgroup_subsys_on_dfl(io_cgrp_subsys) ?
  CGROUP_WEIGHT_DFL : CFQ_WEIGHT_LEGACY_DFL;
 
if (cpd_to_blkcg(cpd) == _root)
@@ -1599,7 +1599,7 @@ static void cfq_cpd_free(struct blkcg_policy_data *cpd)
 static void cfq_cpd_bind(struct blkcg_policy_data *cpd)
 {
struct blkcg *blkcg = cpd_to_blkcg(cpd);
-   bool on_dfl = cgroup_on_dfl(blkcg_root.css.cgroup);
+   bool on_dfl = cgroup_subsys_on_dfl(io_cgrp_subsys);
unsigned int weight = on_dfl ? CGROUP_WEIGHT_DFL : 
CFQ_WEIGHT_LEGACY_DFL;
 
if (blkcg == _root)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index c3a9f1e..355bf2e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -433,64 +433,6 @@ static inline struct cgroup *task_cgroup(struct 
task_struct *task,
return task_css(task, subsys_id)->cgroup;
 }
 
-/**
- * cgroup_on_dfl - test whether a cgroup is on the default hierarchy
- * @cgrp: the cgroup of interest
- *
- * The default hierarchy is the v2 interface of cgroup and this function
- * can be used to test whether a cgroup is on the default hierarchy for
- * cases where a subsystem should behave differnetly depending on the
- * interface version.
- *
- * The set of behaviors which change on the default hierarchy are still
- * being determined and the mount option is prefixed with __DEVEL__.
- *
- * List of changed behaviors:
- *
- * - Mount options "noprefix", "xattr", "clone_children", "release_agent"
- *   and "name" are disallowed.
- *
- * - When mounting an existing superblock, mount options should match.
- *
- * - Remount is disallowed.
- *
- * - rename(2) is disallowed.
- *
- * - "tasks" is removed.  Everything should be at process granularity.  Use
- *   "cgroup.procs" instead.
- *
- * - "cgroup.procs" is not sorted.  pids will be unique unless they got
- *   recycled inbetween reads.
- *
- * - "release_agent" and "notify_on_release" are removed.  Replacement
- *   notification mechanism will be implemented.
- *
- * - "cgroup.clone_children" is removed.
- *
- * - "cgroup.subtree_populated" is available.  Its value is 0 if the cgroup
- *   and its descendants contain no task; otherwise, 1.  The file also
- *   generates kernfs notification which can be monitored through poll and
- *   [di]notify when the value of the file changes.
- *
- * - cpuset: tasks will be kept in empty cpusets when hotplug happens and
- *   take masks of ancestors with non-empty cpus/mems, instead of being
- *   moved to an ancestor.
- *
- * - cpuset: a task can be moved into an empty cpuset, and again it takes
- *   masks of ancestors.
- *
- * - memcg: use_hierarchy is on by default and the cgroup file for the flag
- *   is not created.
- *
- * - blkcg: blk-throttle becomes properly hierarchical.
- *
- * - debug: disallowed on the default hierarchy.
- */
-static inline bool cgroup_on_dfl(const struct cgroup *cgrp)
-{
-   return cgrp->root == _dfl_root;
-}
-
 /* no synchronization, the result can only be 

[PATCH 2/4] cgroup: implement static_key based cgroup_subsys_enabled() and cgroup_subsys_on_dfl()

[Tejun Heo]

Whether a subsys is enabled and attached to the default hierarchy
seldom changes and may be tested in the hot paths.  This patch
implements static_key based cgroup_subsys_enabled() and
cgroup_subsys_on_dfl() tests.

The following patches will update the users and remove duplicate
mechanisms.

Signed-off-by: Tejun Heo 
---
 include/linux/cgroup.h | 21 +
 kernel/cgroup.c| 27 ++-
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index eb7ca55..c3a9f1e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -50,6 +51,26 @@ extern struct css_set init_css_set;
 #include 
 #undef SUBSYS
 
+#define SUBSYS(_x) 
\
+   extern struct static_key_true _x ## _cgrp_subsys_enabled_key;   
\
+   extern struct static_key_true _x ## _cgrp_subsys_on_dfl_key;
+#include 
+#undef SUBSYS
+
+/**
+ * cgroup_subsys_enabled - fast test on whether a subsys is enabled
+ * @ss: subsystem in question
+ */
+#define cgroup_subsys_enabled(ss)  
\
+   static_branch_likely( ## _enabled_key)
+
+/**
+ * cgroup_subsys_on_dfl - fast test on whether a subsys is on default hierarchy
+ * @ss: subsystem in question
+ */
+#define cgroup_subsys_on_dfl(ss)   
\
+   static_branch_likely( ## _on_dfl_key)
+
 bool css_has_online_children(struct cgroup_subsys_state *css);
 struct cgroup_subsys_state *css_from_id(int id, struct cgroup_subsys *ss);
 struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup *cgroup,
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2cf0f79..3619389 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -139,6 +139,27 @@ static const char *cgroup_subsys_name[] = {
 };
 #undef SUBSYS
 
+/* array of static_keys for cgroup_subsys_enabled() and cgroup_subsys_on_dfl() 
*/
+#define SUBSYS(_x) 
\
+   DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key); 
\
+   DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key);  
\
+   EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key);  
\
+   EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key);
+#include 
+#undef SUBSYS
+
+#define SUBSYS(_x) [_x ## _cgrp_id] = &_x ## _cgrp_subsys_enabled_key,
+static struct static_key_true *cgroup_subsys_enabled_key[] = {
+#include 
+};
+#undef SUBSYS
+
+#define SUBSYS(_x) [_x ## _cgrp_id] = &_x ## _cgrp_subsys_on_dfl_key,
+static struct static_key_true *cgroup_subsys_on_dfl_key[] = {
+#include 
+};
+#undef SUBSYS
+
 /*
  * The default hierarchy, reserved for the subsystems that are otherwise
  * unattached - it never has more than a single cgroup, and all tasks are
@@ -1319,9 +1340,12 @@ static int rebind_subsystems(struct cgroup_root 
*dst_root,
 
/* default hierarchy doesn't enable controllers by default */
dst_root->subsys_mask |= 1 << ssid;
-   if (dst_root != _dfl_root) {
+   if (dst_root == _dfl_root) {
+   static_branch_enable(cgroup_subsys_on_dfl_key[ssid]);
+   } else {
dst_root->cgrp.subtree_control |= 1 << ssid;
cgroup_refresh_child_subsys_mask(_root->cgrp);
+   static_branch_disable(cgroup_subsys_on_dfl_key[ssid]);
}
 
if (ss->bind)
@@ -5483,6 +5507,7 @@ static int __init cgroup_disable(char *str)
strcmp(token, ss->legacy_name))
continue;
 
+   static_branch_disable(cgroup_subsys_enabled_key[i]);
ss->disabled = 1;
printk(KERN_INFO "Disabling %s control group 
subsystem\n",
   ss->name);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHSET] cgroup: use static_keys for subsystem enabled and on_dfl tests

[Tejun Heo]

cgroup_subsys->disabled and cgroup_on_dfl() tests are likely to be
used in hot paths and seldom change.  The former is set once during
boot and the latter only when a controller is migrated between the
default hierarchy and traditional ones.

This patchset makes these tests static_key based and contains the
following four patches.

 0001-jump_label-make-static_key_enabled-work-on-static_ke.patch
 0002-cgroup-implement-static_key-based-cgroup_subsys_enab.patch
 0003-cgroup-replace-cgroup_subsys-disabled-tests-with-cgr.patch
 0004-cgroup-replace-cgroup_on_dfl-tests-in-controllers-wi.patch

0001 is a prep patch in jump_label.  0002 adds the needed static_keys.
0003-0004 convert the existing usages and drop the old tests.

This patchset is on top of v4.3-rc1 and is availalbe in the following
git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-jump-labels

diffstat follows.  Thanks.

 block/blk-throttle.c   |2 
 block/cfq-iosched.c|4 -
 include/linux/cgroup-defs.h|1 
 include/linux/cgroup.h |   79 +++-
 include/linux/hugetlb_cgroup.h |4 -
 include/linux/jump_label.h |   18 +++---
 include/linux/memcontrol.h |4 -
 kernel/cgroup.c|  113 ++---
 kernel/cpuset.c|   23 
 mm/memcontrol.c|4 -
 10 files changed, 157 insertions(+), 95 deletions(-)

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: fix data race on tty_buffer.commit

[Peter Hurley]

On Tue, Sep 8, 2015 at 9:03 AM, Dmitry Vyukov  wrote:
> Race on buffer data happens when newly committed data is
> picked up by an old flush work in the following scenario:
> __tty_buffer_request_room does a plain write of tail->commit,
> no barriers were executed before that.
> At this point flush_to_ldisc reads this new value of commit,
> and reads buffer data, no barriers in between.
> The committed buffer data is not necessary visible to flush_to_ldisc.
>
> Similar bug happens when tty_schedule_flip commits data.
>
> Update commit with smp_store_release and read commit with
> smp_load_acquire, as it is commit that signals data readiness.
> This is orthogonal to the existing synchronization on tty_buffer.next,
> which is required to not dismiss a buffer with unconsumed data.
>
> The data race was found with KernelThreadSanitizer (KTSAN).

Looks good.

Same comments as the other patch; needs changelog revision
information.

Thanks for your work on this; really good stuff.

Regards,
Peter Hurley

> Signed-off-by: Dmitry Vyukov 
> ---
>  drivers/tty/tty_buffer.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 5a3fa89..7ed2006 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -290,7 +290,10 @@ static int __tty_buffer_request_room(struct tty_port 
> *port, size_t size,
> if (n != NULL) {
> n->flags = flags;
> buf->tail = n;
> -   b->commit = b->used;
> +   /* paired w/ acquire in flush_to_ldisc(); ensures
> +* flush_to_ldisc() sees buffer data.
> +*/
> +   smp_store_release(>commit, b->used);
> /* paired w/ acquire in flush_to_ldisc(); ensures the
>  * latest commit value can be read before the head is
>  * advanced to the next buffer
> @@ -393,7 +396,10 @@ void tty_schedule_flip(struct tty_port *port)
>  {
> struct tty_bufhead *buf = >buf;
>
> -   buf->tail->commit = buf->tail->used;
> +   /* paired w/ acquire in flush_to_ldisc(); ensures
> +* flush_to_ldisc() sees buffer data.
> +*/
> +   smp_store_release(>tail->commit, buf->tail->used);
> schedule_work(>work);
>  }
>  EXPORT_SYMBOL(tty_schedule_flip);
> @@ -491,7 +497,10 @@ static void flush_to_ldisc(struct work_struct *work)
>  * is advancing to the next buffer
>  */
> next = smp_load_acquire(>next);
> -   count = head->commit - head->read;
> +   /* paired w/ release in __tty_buffer_request_room() or in
> +* tty_buffer_flush(); ensures we see the committed buffer 
> data
> +*/
> +   count = smp_load_acquire(>commit) - head->read;
> if (!count) {
> if (next == NULL) {
> check_other_closed(tty);
> --
> 2.5.0.457.gab17608
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH 1/2] dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF

[Kuninori Morimoto]

Hi Vinod, again

> > > > 5fa422c ("dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c")
> > > > moved OF base DMAEngine code to of-dma.c, then it based on 
> > > > CONFIG_DMA_OF.
> > > > But, OF base DMAEngine API on of_dma.h still based on CONFIG_OF now.
> > > > So, current kernel can't find OF base DMAEngine API if .config has 
> > > > CONFIG_OF,
> > > > but not have CONFIG_DMA_OF. This patch tidyup it.
> > > 
> > > I did a quick build with arm config, but didn't see any failures. But 
> > > still
> > > am worried about random config and other builds may find.
> > > 
> > > So I think it would be safer to merge this patch after merge window so 
> > > that
> > > we have ample time to fix any issue
> 
> Which branch can I find this patch ?

I still can't find this patch.
Where can I find ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: fix data race in tty_buffer_flush

[Peter Hurley]

On Tue, Sep 8, 2015 at 8:48 AM, Dmitry Vyukov  wrote:
> tty_buffer_flush frees not acquired buffers.
> As the result, for example, read of b->size in tty_buffer_free
> can return garbage value which will lead to a huge buffer
> hanging in the freelist. This is just the benignest
> manifestation of freeing of a not acquired object.
> If the object is passed to kfree, heap can be corrupted.
>
> Acquire visibility over the buffer before freeing it.
>
> The data race was found with KernelThreadSanitizer (KTSAN).

Dmitry,

Looks good. Thanks for splitting this from the other fix.

Like Greg said, the patch needs revision info to help maintainers, et al
track which is most current/relevant/etc.

Typical format for $subject is something like:

[PATCH v4] tty: fix data race in tty_buffer_flush


Notes re: changes from other patch versions are added below the
git changelog separator (example below).

> Signed-off-by: Dmitry Vyukov 
> ---

v4: Corrected commit log and patch revision notes

v3: Added code comment re: paired smp barrier

v2: Split from 'tty: fix data races on tty_buffer.commit'

>  drivers/tty/tty_buffer.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 5a3fa89..a2a8cd0 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -242,7 +242,10 @@ void tty_buffer_flush(struct tty_struct *tty, struct 
> tty_ldisc *ld)
> atomic_inc(>priority);
>
> mutex_lock(>lock);
> -   while ((next = buf->head->next) != NULL) {
> +   /* paired w/ release in __tty_buffer_request_room; ensures there are
> +* no pending memory accesses to the freed buffer
> +*/
> +   while ((next = smp_load_acquire(>head->next)) != NULL) {
> tty_buffer_free(port, buf->head);
> buf->head = next;
> }
> --
> 2.5.0.457.gab17608
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 03:57:05 AM Rafael J. Wysocki wrote:
> On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems.
> > 
> > Fix that by making global_lock an u32 instead.
> > 
> > Cc:   # v4.1+
> > Signed-off-by: Viresh Kumar 
> > 
> > ---
> > Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> > platform with ACPI. And ACPI support for that is mainlined recently
> > only (Arnd Bergmann).
> 
> OK
> 
> So are you aware of any ARM platform implementing the ACPI EC?
> 
> I am not.  Moreover, I'm not aware of any plans in that area.

In any case, please just split the EC-related changes off from your second
patch and send them separately.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm64: mt8173.dtsi: correct i2c node names

[Yingjoe Chen]

Node name in device tree should describe general class of the
device. Correct incorrect i2c node names.

Signed-off-by: Yingjoe Chen 
---
This is based on v4.3-rc1.
All the other i2c node names are correct.
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..7f360b7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -365,7 +365,7 @@
status = "disabled";
};
 
-   i2c3: i2c3@1101 {
+   i2c3: i2c@1101 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x1101 0 0x70>,
  <0 0x11000280 0 0x80>;
@@ -381,7 +381,7 @@
status = "disabled";
};
 
-   i2c4: i2c4@11011000 {
+   i2c4: i2c@11011000 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x11011000 0 0x70>,
  <0 0x11000300 0 0x80>;
@@ -397,7 +397,7 @@
status = "disabled";
};
 
-   i2c6: i2c6@11013000 {
+   i2c6: i2c@11013000 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x11013000 0 0x70>,
  <0 0x1180 0 0x80>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the next-20150915 version of the tip tree, today's
linux-next build (x86_64 allmodconfig) failed like this:

In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^

Caused by commit

  c40a2c8817e4 ("CDC: common parser for extra headers")

from the net-next tree that added include/linux/usb/cdc.h with no
reinclusion guards.

I am not sure why I did not see this failure when building after
merging the net-next tree.  Maybe it is exposed by some config change
in the tip tree?

I have added the following fix patch for today:

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:10:16 +1000
Subject: [PATCH] cdc: add header guards

Signed-off-by: Stephen Rothwell 
---
 include/linux/usb/cdc.h  | 4 
 include/uapi/linux/usb/cdc.h | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 959d0c838113..b5706f94ee9e 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -7,6 +7,8 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  */
+#ifndef __LINUX_USB_CDC_H
+#define __LINUX_USB_CDC_H
 
 #include 
 
@@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
struct usb_interface *intf,
u8 *buffer,
int buflen);
+
+#endif /* __LINUX_USB_CDC_H */
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index b6a9cdd6e096..e2bc417b243b 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -6,8 +6,8 @@
  * firmware based USB peripherals.
  */
 
-#ifndef __LINUX_USB_CDC_H
-#define __LINUX_USB_CDC_H
+#ifndef __UAPI_LINUX_USB_CDC_H
+#define __UAPI_LINUX_USB_CDC_H
 
 #include 
 
@@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size {
 #define USB_CDC_NCM_CRC_NOT_APPENDED   0x00
 #define USB_CDC_NCM_CRC_APPENDED   0x01
 
-#endif /* __LINUX_USB_CDC_H */
+#endif /* __UAPI_LINUX_USB_CDC_H */
-- 
2.5.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] of: Check for overlap in reserved memory regions

[Mitchel Humpherys]

Any overlap in the reserved memory regions (those specified in the
reserved-memory DT node) is a bug.  These bugs might go undetected as
long as the contested region isn't used simultaneously by multiple
software agents, which makes such bugs hard to debug.  Fix this by
printing a scary warning during boot if overlap is detected.

Signed-off-by: Mitchel Humpherys 
---
v1..v2:
  - Suggestions from Rob Herring (remove superfluous array and
print statement)
---
 drivers/of/of_reserved_mem.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 726ebe792813..62f467b8ccae 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -1,7 +1,7 @@
 /*
  * Device tree based initialization code for reserved memory.
  *
- * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
+ * Copyright (c) 2013, 2015 The Linux Foundation. All Rights Reserved.
  * Copyright (c) 2013,2014 Samsung Electronics Co., Ltd.
  * http://www.samsung.com
  * Author: Marek Szyprowski 
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_RESERVED_REGIONS   16
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
reserved_mem *rmem)
return -ENOENT;
 }
 
+static int __init __rmem_cmp(const void *a, const void *b)
+{
+   const struct reserved_mem *ra = a, *rb = b;
+
+   return ra->base - rb->base;
+}
+
+static void __init __rmem_check_for_overlap(void)
+{
+   int i;
+
+   if (reserved_mem_count < 2)
+   return;
+
+   sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
+__rmem_cmp, NULL);
+   for (i = 0; i < reserved_mem_count - 1; i++) {
+   struct reserved_mem *this, *next;
+
+   this = _mem[i];
+   next = _mem[i + 1];
+   if (!(this->base && next->base))
+   continue;
+   if (this->base + this->size > next->base) {
+   phys_addr_t this_end, next_end;
+
+   this_end = this->base + this->size;
+   next_end = next->base + next->size;
+   WARN(1,
+"Reserved memory: OVERLAP DETECTED!\n%s (%pa--%pa) 
overlaps with %s (%pa--%pa)\n",
+this->name, >base, _end,
+next->name, >base, _end);
+   }
+   }
+}
+
 /**
  * fdt_init_reserved_mem - allocate and init all saved reserved memory regions
  */
 void __init fdt_init_reserved_mem(void)
 {
int i;
+
+   /* check for overlapping reserved regions */
+   __rmem_check_for_overlap();
+
for (i = 0; i < reserved_mem_count; i++) {
struct reserved_mem *rmem = _mem[i];
unsigned long node = rmem->fdt_node;
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems.
> 
> Fix that by making global_lock an u32 instead.
> 
> Cc:   # v4.1+
> Signed-off-by: Viresh Kumar 
> 
> ---
> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> platform with ACPI. And ACPI support for that is mainlined recently
> only (Arnd Bergmann).

OK

So are you aware of any ARM platform implementing the ACPI EC?

I am not.  Moreover, I'm not aware of any plans in that area.

> Another thing worth noticing is that, global_lock is getting an unsigned
> long long value assigned to it in ec_parse_device() and this is what
> Arnd had to say about that:
> 
> "I think that's fine, it does this because the _GLP variable in ACPI is
> defined as an u64. And that's what happens on 32-bit architectures
> anyway."
> 
> This patch should go via GregKH, as the second patch has dependency on
> it.
> 
> V2->V3:
> - Moved this out in a separate patch, so that it can be backported.

Lv, can you have a look at this, please?

> ---
>  drivers/acpi/ec_sys.c   | 2 +-
>  drivers/acpi/internal.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, 
> unsigned int ec_device_count)
>   if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
>   goto error;
>   if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> -  (u32 *)_ec->global_lock))
> +  _ec->global_lock))
>   goto error;
>  
>   if (write_support)
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 9e426210c2a8..9db196de003c 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -138,7 +138,7 @@ struct acpi_ec {
>   unsigned long gpe;
>   unsigned long command_addr;
>   unsigned long data_addr;
> - unsigned long global_lock;
> + u32 global_lock;
>   unsigned long flags;
>   unsigned long reference_count;
>   struct mutex mutex;
> 

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/8] genirq: irqdomain: Remove irqdomain dependency on struct device_node

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 10:18:32 AM Marc Zyngier wrote:
> On 15/09/15 00:15, Rafael J. Wysocki wrote:
> > On Monday, September 14, 2015 05:44:01 PM Marc Zyngier wrote:
> >> struct device_node is very much DT specific, and the original authors
> >> of the irqdomain subsystem recognized that tie, and went as far as
> >> mentionning that this could be replaced by some "void *token",
> >> should another firmware infrastructure be using it.
> >>
> >> As we move ACPI on arm64 towards this model too, it makes a lot of sense
> >> to perform that particular move.
> >>
> >> We replace "struct device_node *of_node" with "void *domain_token", which
> >> is a benign enough transformation. A non DT user of irqdomain can now
> >> identify its domains using this pointer.
> >>
> >> Also, in order to prevent the introduction of sideband type information,
> >> only DT is allowed to store a valid kernel pointer in domain_token
> >> (a pointer that passes the virt_addr_valid() test will be considered
> >> as a valid device_node).
> >>
> >> non-DT users that wish to store valid pointers in domain_token are
> >> required to use another structure such as an IDR.
> >>
> >> Signed-off-by: Marc Zyngier 
> >> ---
> >>  include/linux/irqdomain.h | 68 +++-
> >>  kernel/irq/irqdomain.c| 89 
> >> ++-
> >>  2 files changed, 101 insertions(+), 56 deletions(-)
> >>
> >> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> >> index f644fdb..ac7041b 100644
> >> --- a/include/linux/irqdomain.h
> >> +++ b/include/linux/irqdomain.h
> >> @@ -17,16 +17,14 @@
> >>   * model). It's the domain callbacks that are responsible for setting the
> >>   * irq_chip on a given irq_desc after it's been mapped.
> >>   *
> >> - * The host code and data structures are agnostic to whether or not
> >> - * we use an open firmware device-tree. We do have references to struct
> >> - * device_node in two places: in irq_find_host() to find the host matching
> >> - * a given interrupt controller node, and of course as an argument to its
> >> - * counterpart domain->ops->match() callback. However, those are treated 
> >> as
> >> - * generic pointers by the core and the fact that it's actually a 
> >> device-node
> >> - * pointer is purely a convention between callers and implementation. This
> >> - * code could thus be used on other architectures by replacing those two
> >> - * by some sort of arch-specific void * "token" used to identify interrupt
> >> - * controllers.
> >> + * The host code and data structures are agnostic to whether or not we
> >> + * use an open firmware device-tree. Domains can be assigned a
> >> + * "void *domain_token" identifier, which is assumed to represent a
> >> + * "struct device_node" if the pointer is a valid virtual address.
> >> + *
> >> + * Otherwise, the value is assumed to be an opaque identifier. Should
> >> + * a pointer to a non "struct device_node" be required, another data
> >> + * structure should be used to indirect it (an IDR for example).
> >>   */
> >>  
> >>  #ifndef _LINUX_IRQDOMAIN_H
> >> @@ -108,8 +106,8 @@ struct irq_domain_chip_generic;
> >>   * @flags: host per irq_domain flags
> >>   *
> >>   * Optional elements
> >> - * @of_node: Pointer to device tree nodes associated with the irq_domain. 
> >> Used
> >> - *   when decoding device tree interrupt specifiers.
> >> + * @domain_token: optional firmware-specific identifier for
> >> + *the interrupt controller
> >>   * @gc: Pointer to a list of generic chips. There is a helper function for
> >>   *  setting up one or more generic chips for interrupt controllers
> >>   *  drivers using the generic chip library which uses this pointer.
> >> @@ -130,7 +128,7 @@ struct irq_domain {
> >>unsigned int flags;
> >>  
> >>/* Optional data */
> >> -  struct device_node *of_node;
> >> +  void *domain_token;
> > 
> > I'm wondering if that may be something which isn't (void *), but a specific
> > pointer type, so the compiler warns us when something suspicious is assigned
> > to it?
> > 
> > [Somewhat along the lines struct fwnode_handle is used elsewehere.]
> 
> Yeah, I'm obviously being lazy ;-).
> 
> More seriously, I'm trying hard to avoid anything that will require an
> additional memory allocation. Going from a device_node to a
> fwnode_handle-like structure requires such an allocation which is going
> to be a massive pain to retrofit - not impossible, but painful.
> 
> What I'm currently aiming for is tagged pointers, where the two bottom
> bits indicate the type of the pointed object (see patch #3):
> - 00 indicates a device node
> - 01 indicates an IDR entry (shifted left by two bits)
> - 10 and 11 are currently unallocated, and one of them could be used to
> encode a fwnode_handle.
> 
> It would be slightly easier to replace the (void *) with a union of the
> above types:
> 
>   union domain_token {
>   struct 

Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm

[Tejun Heo]

Hello, Paul.

On Tue, Sep 15, 2015 at 04:38:18PM -0700, Paul E. McKenney wrote:
> Well, the decision as to what is too big for -stable is owned by the
> -stable maintainers, not by me.

Is it tho?  Usually the subsystem maintainer knows the best and has
most say in it.  I was mostly curious whether you'd think that the
changes would be too risky.  If not, great.

> I am suggesting trying the options and seeing what works best, then
> working to convince people as needed.

Yeah, sure thing.  Let's wait for Christian.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Peter Hurley]

On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt  wrote:
> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby > > wrote:
>>
>> From: Tilman Schmidt 
>>
>> 3.12-stable review patch.  If anyone has any objections, please let
>> me know.
>>
>> ===
>>
>> [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>
>> Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>> first merged in kernel release 3.10, caused the following regression
>> in the Gigaset M101 driver:
>>
>>
>> Again, I'll just note my objection to this commit log.
>>
>> This driver was always broken because it never initialized
>> tty->receive_room,
>> but rather relied on common but not guaranteed circumstances to
>> function.
>>
>> The commit noted simply made the underlying bug more evident, but the
>> root cause was from the original merge commit of this driver.
>
> I must admit I still don't understand that objection. The meaning of the
> term "regression" is simply that something which previously worked
> stopped working. It doesn't imply any statement about the root cause.
>
> The ser-gigaset driver worked before the introduction of commit
> 79901317ce80. It didn't work anymore after the introduction of that
> commit. So it is correct, and does not contradict your statements above
> in any way, to state that commit introduced the described regression.

By asserting that commit 79901317ce80 caused the regression, you're
claiming that this fix is unnecessary for kernel versions prior to 3.10

Are you certain that no other sequence of state leads to the same
condition (and thus requiring the same fix) in earlier kernel versions?

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> and used outside of it. And that breaks kernel build:
> 
> /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference to 
> `wakeup_irq'
> /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> `wakeup_irq'
> 
> Fix it by defining the variable outside of the ifdef.
> 
> Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system wakeup")
> Signed-off-by: Viresh Kumar 

I've applied the v11 of the Alexandra's patch that doesn't have this problem 
AFAICS.

> ---
>  kernel/power/main.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 9880bf888a5b..f97a188f4ccc 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -235,6 +235,9 @@ late_initcall(pm_debugfs_init);
>  
>  #endif /* CONFIG_PM_SLEEP */
>  
> +/* IRQ number which causes system wakeup */
> +unsigned int wakeup_irq;
> +
>  #ifdef CONFIG_PM_SLEEP_DEBUG
>  /*
>   * pm_print_times: print time taken by devices to suspend and resume.
> @@ -273,7 +276,6 @@ static inline void pm_print_times_init(void)
>   pm_print_times_enabled = !!initcall_debug;
>  }
>  
> -unsigned int wakeup_irq;
>  static ssize_t pm_wakeup_irq_show(struct kobject *kobj,
>   struct kobj_attribute *attr,
>   char *buf)
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 01:24:31 PM Viresh Kumar wrote:
> On 10-09-15, 23:59, Rafael J. Wysocki wrote:
> > Adding Mark and Srinivas who may be interested in this to CC.
> 
>  Mike ? :)
> 
> > Why don't we start with listing all of the cpufreq's shortcomings we'd like
> > to address, then try to sort out conflicting items and come up with a list
> > of tasks to complete?
> 
> Yeah, sounds like a good plan.
> 
> > To me, the most painful thing ATM is that cpufreq cannot use timer functions
> > to carry out state transitions even if the underlying driver could request
> > state to be changed from interrupt context.  IMO, we should utilize the
> > capabilities of the hardware where possible and only add overhead where it
> > is necessary.
> 
> Absolutely right.
> 
> > Speaking of which I'm concerned that we're adding overhead for systems that
> > don't need software synchronization of state transitions (the "one CPU per
> > policy" case).  I'm not sure how much of that is really happening, but it
> > would be review the code from that angle and streamline things where
> > policy objects are not shared.
> 
> Maybe, maybe not.. Probably we need to look at exact code paths for
> that and then decide.. But we should get this simplified if we can.
> 
> > The locking is overdesigned and overkill (and you know that already), but
> > if we do the above, it'll be more strarightforward to simplify it IMO.
> 
> Locking is really bad today.. I wrote lots of patches for that, but
> never got them upstreamed. I should try doing that after pushing the
> remaining govenor patches ..
> 
> > Finally, the initialization is questionable and in particular the fact that 
> > we
> > need to call the driver's ->init at least once to get policy->cpus 
> > populated.
> > This shouldn't be necessary, as that information reflects the topology of
> > the system and shouldn't depend on which driver is in use really.
> 
> I am not sure how feasible it will be get the topology information in
> a generic way, but if we can, we should.

That depends on what you mean by "generic".  I don't think there's one that
will work for all platforms, but I don't see a reason why it should depend
on the cpufreq driver.

cpufreq drivers can use DT or ACPI or OPPs provided by the platform for
that and all of those things can be accessed by the cpufreq core itself
just as well.

> > Please let me know what your pain points are. :-)
> 
> There were few minor things as well, I already have some code for
> them:
> - Dividing the really large cpufreq.[h|c] files into better, more
>   readable blocks. For example, one file for sysfs stuff alone..

Yeah, that's worth doing, but maybe in the process of re-working things
to avoid making significant changes depend on cleanups.

Speaking of sysfs, that's one more item for my list.  The structure of
the sysfs interface used by cpufreq today is confusing to put it lightly.

For example, we need to make the information that multiple CPUs share the
same cpufreq settings more explicit and I really don't think we should
fail sysfs accesses for offline CPUs when it is not necessary.  At least,
we should fail it for all of them or for none of them, but we don't do
that.

> - Some sort of test suite for cpufreq. I wrote one, which contains
>   most of the cases, which helped us fixing governor races:
> 
>   https://git.linaro.org/people/viresh.kumar/cpufreq-tests.git
> 
>   But, these are plain bash scripts. Not really tied to any kernel
>   internal test suite. Which suite should I adapt them for ?

kselftest seems to be a reasonable target to me.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: pass policy to ->get() driver callback

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 01:09:21 PM Viresh Kumar wrote:
> On 11-09-15, 21:48, Viresh Kumar wrote:
> > > -/* Only for cpufreq core internal use */
> > >  struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> > >  {
> > >   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> > >  
> > >   return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
> > >  }
> > > +EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
> 
> This routine was recently marked as static and now with your patch it
> results in compilation error. You just need to remove the 'static'
> part from the routine.
> 
> I would have sent a patch for this, but I thought you would like to
> edit the original patch itself to not break git bisect.

I even tried to do that previously, but I made a mistake then.

It should be fixed in my bleeding-edge branch now.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iov: initialize NumVFs register to 0 at the end of sriov_init()

[ethan zhao]

On 2015/9/16 0:10, Bjorn Helgaas wrote:

On Fri, Aug 21, 2015 at 06:51:25PM +0900, Ethan Zhao wrote:

After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was set to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch initialize the NumVFs register to zero after the
calculation of max_VF_buses was done.

Tested on stable 4.1 and passed building on stable 4.2-rc7

Signed-off-by: Ethan Zhao 
Tested-by: Sriharsha Yadagudde 
---
  drivers/pci/iov.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..6969084 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -476,6 +476,7 @@ found:
dev->is_physfn = 1;
iov->max_VF_buses = virtfn_max_buses(dev);
  
+	pci_iov_set_numvfs(dev, 0);

I think it would be better to put this in virtfn_max_buses(), where we
clobbered numVFs in the first place.  I'd also read the original value and
restore it, e.g.,

 pci_read_config_word(dev, iov->pos + PCI_SRIOV_NUM_VF, );
 for (nr_virtfn = 1; nr_virtfn <= iov->total_VFs; nr_virtfn++) {
   ...
 }
 pci_iov_set_numvfs(dev, numvfs);
 return max;

I know sriov_init() sets numVFs to zero before it calls virtfn_max_buses(),
but why rely on that extra knowledge?
 Yes, I think also virtfn_max_buses() should restore the register 
before it returns.

 Will revise it and resend.

 Thanks,
 Ethan

return 0;
  
  failed:

--
1.8.3.1



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: Ensure proper suspend/resume ordering

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 03:18:19 PM Alan Stern wrote:
> On Tue, 15 Sep 2015, Thierry Reding wrote:
> 
> > > There are a few things to watch out for.  Since the dpm_list gets
> > > modified during system sleep transitions, we would have to make sure
> > > that nothing gets probed during those times.  In principle, that's what
> > > the "prepare" stage is meant for, but there's still a race.  As long as
> > > no other kernel thread (such as the deferred probing mechanism) tries
> > > to probe a device once everything has been frozen, we should be okay.
> > > But if not, there will be trouble -- after the ->prepare callback runs, 
> > > the device is no longer on the dpm_list and so we don't want this patch 
> > > to put it back on that list.
> > 
> > Perhaps moving to the end of the list needs to be a little smarter. That
> > is it could check whether the device has been prepared for suspension or
> > not and only move when it hasn't?
> 
> Maybe.  But doesn't that mean it won't solve your problem completely?
> 
> > Then again, shouldn't the core even prohibit new probes once the suspend
> > has been triggered? Sounds like asking for a lot of trouble if it didn't
> > ...
> 
> The core prohibits new devices from being registered.  It does not 
> prohibit probes of existing devices, because they currently do not 
> affect the dpm_list.

Which may be a mistake, because it does affect callbacks executed during
suspend/resume (after successful probe the device potentially has a different
set of PM callbacks than before).

> In general, we rely on subsystems not to do any probing once a device 
> is suspended.  It's probably reasonable to ask them not to do any 
> probing once a device has gone through the "prepare" stage.

Right.

Question is when it should be allowed to probe again.  I guess at the same
time we allow registrations to to take place again?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] fs: global sync to not clear error status of individual inodes

[Junichi Nomura]

On 09/16/15 00:20, Tejun Heo wrote:
>> @@ -2121,7 +2121,13 @@ static void wait_sb_inodes(struct super_block *sb)
>>  iput(old_inode);
>>  old_inode = inode;
>>  
>> -filemap_fdatawait(mapping);
>> +/*
>> + * Wait for on-going writeback to complete
>> + * but not consume error status on this mapping.
>^don't
> 
>> + * Otherwise application may fail to catch writeback error
> 
>mapping; otherwise,
> 
>> + * using fsync(2).
>> + */
> 
> Can you please re-flow the comment so that it's filling up to, say, 72
> or 76 or whatever column?

I'll fix them.

>> -filemap_fdatawait(bdev->bd_inode->i_mapping);
>> +filemap_fdatawait_keep_errors(bdev->bd_inode->i_mapping);
> 
> Maybe it'd be better to describe what's going on in detail in the
> function comment of filemat_fdatawait_keep_errors() and refer to that
> from its callers?

Thanks, that seems better.
I'll also extend function comments of filemap_fdatawait so that the
difference becomes clear.

-- 
Jun'ichi Nomura, NEC Corporation--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] fs: global sync to not clear error status of individual inodes

[Junichi Nomura]

On 09/16/15 07:02, Andrew Morton wrote:
> It would be nice to capture the test case(s) somewhere permanent. 
> Possibly in tools/testing/selftests, but selftests is more for peculiar
> linux-specific things.  LTP or xfstests would be a better place.

I'll check xfstests if I can adapt the test case for its framework.

-- 
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Stephen Boyd]

On 09/15, Andrew Morton wrote:
> On Tue, 15 Sep 2015 12:41:26 -0700 Stephen Boyd  wrote:
> 
> > The SMD driver is reading and writing chunks of data to iomem,
> > and there's an __iowrite32_copy() function for the writing part, but
> > no __ioread32_copy() function for the reading part. This series
> > adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
> > case this should go through the -mm tree. Otherwise the target
> > of this patch series is SMD, so I've sent it to Andy.
> 
> "soc: qcom: smd: Use __ioread32_copy() instead of open-coding it" no
> longer applies, because smd_copy_from_fifo() has switched to
> readl_relaxed().

Yes. There are some other patches in flight on the mailing list
to this file from me[1]. Those would need to be applied first to
avoid conflicts.

> 
> Let's use the __weak macro rather than open-coding it (and convert
> __iowrite32_copy() while we're in there).

Yep, I converted the __iowrite32_copy() open-code in there too in
the patch series I mentioned above. See [2].

> 
> It's unclear why __iowrite32_copy() is a weak function - nothing
> overrides it.  Perhaps we should just take that away rather than
> copying it into __ioread32_copy().

Huh? I see that x86 has an implementation in arch/x86/lib/iomap_copy_64.S

> 
> __iowrite32_copy() is marked __visible.  I don't actually know what
> that does and Andi's d47d5c8194579bc changelog (which sucks the big
> one) didn't explain it.  Apparently it has something to do with being
> implemented in assembly, but zillions of functions are implemented in
> assembly, so why are only two functions marked this way?  Anyway,
> __ioread32_copy() is implemented in C so I guess __visible isn't needed
> there.

Yeah, I didn't add visible because there isn't an assembly
version of __ioread32_copy() so far. I can remove __weak if
desired. I left it there to match __iowrite32_copy() in case
x86 wanted to override it but we can do that later or never.

[1] 
http://lkml.kernel.org/g/1441234011-4259-7-git-send-email-sb...@codeaurora.org
[2] 
http://lkml.kernel.org/g/1441234011-4259-5-git-send-email-sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: Ensure proper suspend/resume ordering

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 05:53:02 PM Thierry Reding wrote:
> On Sat, Sep 12, 2015 at 12:38:19AM +0200, Rafael J. Wysocki wrote:
> > On Friday, September 11, 2015 02:03:46 PM Thierry Reding wrote:
> > > On Fri, Sep 11, 2015 at 12:08:02AM +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, September 10, 2015 12:19:03 PM Thierry Reding wrote:
> > > > > From: Thierry Reding 
> > > > >=3D20
> > > > > Deferred probe can lead to strange situations where a device that i=
> s a
> > > > > dependency for others will be moved to the end of the dpm_list. At =
> the
> > > > > same time the dependers may not be moved because at the time they w=
> ill
> > > > > be probed the dependee may already have been successfully reprobed =
> and
> > > > > they will not have to defer the probe themselves.
> > > >=3D20
> > > > So there's a bug in the implementation of deferred probing IMO.
> > >=20
> > > Well, yeah. The root problem here is that we don't have dependency
> > > information and deferred probing is supposed to fix that. It does so
> > > fairly well, but it breaks in this particular case.
> > >=20
> > > > > One example where this happens is the Jetson TK1 board (Tegra124). =
> The
> > > > > gpio-keys driver exposes the power key of the board as an input dev=
> ice
> > > > > that can also be used as a wakeup source. Commit 17cdddf0fb68 ("ARM:
> > > > > tegra: Add gpio-ranges property") results in the gpio-tegra driver
> > > > > deferring probe because one of its dependencies, the pinctrl-tegra
> > > > > driver, has not successfully completed probing. Currently the defer=
> red
> > > > > probe code will move the corresponding gpio-tegra device to the end=
>  of
> > > > > the dpm_list, but by the time the gpio-keys device, depending on the
> > > > > gpio-tegra device, is probed, gpio-tegra has already been reprobed,=
>  so
> > > > > the gpio-keys device is not moved to the end of dpm_list itself.
> >=20
> > At this point, when checking its dependencies, gpio-keys should also check
> > if their ordering with respect to it in dpm_list is correct and move itse=
> lf
> > to the end of it otherwise.
> >=20
> > There might be a helper for that I suppose.
> 
> But that's essentially the same thing as what this patch proposes,
> except that every driver now needs to call this helper, rather than
> having the core take care of it.

Well, not quite.  Not "every driver", but "every driver with dependencies
the driver core doesn't know about".  That's quite a difference in my view.
 
[...]

> > I'm always cautious about changes that make the core do something for eve=
> ry
> > device/driver, because they are very likely to step on corner cases that =
> we
> > don't need to worry about otherwise.
> 
> To me this seems more like a fundamental issue that should be fixed at
> the root rather than be fixed up case by case as we find them. Keeping
> the suspend/resume order the same as probe order sounds like the most
> logical thing to do. I grant you that there could be cases where this
> might break, but then I'd consider those cases to be broken rather than
> the other way around.

We have to disagree, then.

> With the current situation potentially every user of GPIOs (and the same
> is true for other types of resources) is broken, though we may not
> notice (immediately). In fact it was mostly by coincidence that I
> noticed in this case. The GPIO key works perfectly fine for regular use,
> it just doesn't work as a wakeup source anymore. That's not something
> that people test very frequently, hence could've gone unnoticed for much
> longer.
> 
> Of course reordering the dpm_list to follow the probe order has the
> potential to break other setups in similarily subtle ways, so I do
> understand your reluctance.
> 
> Perhaps it would help if we put this patch into some boot farm to get
> more coverage, maybe that would give us a better picture for how
> invasive the change is, or how bad the fallout could be?

I'd actually prefer to have a patch that I don't have to worry about
even in theory.

What about an opt-in mechanism for things that are likely to need this
stuff instead of imposing it on everybody unconditionally?

> I can of course go and come up with a more ad-hoc solution that fixes
> the issue for this particular use-case, but I'd like to avoid a
> situation where we end up having to patch up drivers one by one, when
> we could have a solution that works in the general case.
> 
> Also note that a recent commit (52cdbdd49853 "driver core: correct
> device's shutdown order") patch already made an equivalent change to the
> shutdown order. I'd expect that most devices would fail with that patch
> already if ordering is a real problem. Of course shutdown is a one-way
> ticket, so failure might not be as relevant as for suspend/resume.

Did you forget about the other Alan's concerns regarding probing devices
during suspend/resume?

> Grygorii, Greg: have you heard of any fallout caused by the above patch
> yet?

Did that 

[PATCH 1/8] PCI: iproc: Fix code comment

[Ray Jui]

Fix code comment in pcie-iproc.h so it matches the code

Signed-off-by: Ray Jui 
---
 drivers/pci/host/pcie-iproc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index c9e4c10..4880b09 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -20,11 +20,11 @@
  * iProc PCIe device
  * @dev: pointer to device data structure
  * @base: PCIe host controller I/O register base
- * @resources: linked list of all PCI resources
  * @sysdata: Per PCI controller data (ARM-specific)
  * @root_bus: pointer to root bus
  * @phy: optional PHY device that controls the Serdes
  * @irqs: interrupt IDs
+ * @map_irq: function callback to map interrupts
  */
 struct iproc_pcie {
struct device *dev;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/8] PCI: iproc: Remove unused code

[Ray Jui]

Remove unused struct iproc_pcie member irqs and #define
IPROC_PCIE_MAX_NUM_IRQS

Signed-off-by: Ray Jui 
---
 drivers/pci/host/pcie-iproc.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 4880b09..ecaad57 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -14,8 +14,6 @@
 #ifndef _PCIE_IPROC_H
 #define _PCIE_IPROC_H
 
-#define IPROC_PCIE_MAX_NUM_IRQS 6
-
 /**
  * iProc PCIe device
  * @dev: pointer to device data structure
@@ -34,7 +32,6 @@ struct iproc_pcie {
 #endif
struct pci_bus *root_bus;
struct phy *phy;
-   int irqs[IPROC_PCIE_MAX_NUM_IRQS];
int (*map_irq)(const struct pci_dev *, u8, u8);
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/8] PCI: iproc: Update iProc PCIe device tree bindings

[Ray Jui]

This patch updates the iProc PCIe device tree bindings with added
support for outbound mapping configurations

Signed-off-by: Ray Jui 
---
 .../devicetree/bindings/pci/brcm,iproc-pcie.txt  | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index f7ce50e..45c2a80 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -17,6 +17,21 @@ Optional properties:
 - phys: phandle of the PCIe PHY device
 - phy-names: must be "pcie-phy"
 
+- brcm,pcie-ob: Some iProc SoCs do not have the outbound address mapping done
+by the ASIC after power on reset. In this case, SW needs to configure it
+
+If the brcm,pcie-ob property is present, the following properties become
+effective:
+
+Required:
+- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
+address used by the iProc PCIe core (not the PCIe address)
+- brcm,pcie-ob-window-size: The outbound address mapping window size (in MB)
+
+Optional:
+- brcm,pcie-ob-oarr-size: Some iProc SoCs need the OARR size bit to be set to
+increase the outbound window size
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
@@ -38,6 +53,11 @@ Example:
 
phys = < 0 5>;
phy-names = "pcie-phy";
+
+   brcm,pcie-ob;
+   brcm,pcie-ob-oarr-size;
+   brcm,pcie-ob-axi-offset = <0x>;
+   brcm,pcie-ob-window-size = <256>;
};
 
pcie1: pcie@18013000 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] Broadcom iProc PCIe fixes and outbound mapping support

[Ray Jui]

This patch series contains various fixes and outbound mapping support for
the Broadcom iProc PCIe driver. Some of the critical fixes include 1) fix of
PCIe core reset logic and therefore remove its dependency on the bootloader;
2) improved link detection logic that works for more iProc based SoCs.

This patch series also adds the outbound address mapping support. While
outbound address mapping support is not required on chips like North Star,
Cygnus, and etc., some of the newer iProc based chips like North Star 2 require
this support to properly map the AXI address into the address used in the iProc
PCIe core

This patch series is constructed based on Linux v4.3-rc1 (with workaround to
disable calls to pci_read_bridge_bases in pci/probe.c that breaks some of the
ARM based PCIe devices including iProc)

This patch series is tested on the following platforms with an Intel e1000e
based PCIe x1 NIC card:
- ARM32 based Cygnus BCM958305K Wireless Audio board
- ARM64 based North Star 2 SVK board

code available at GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/iproc-pcie-fix-v1

Ray Jui (8):
  PCI: iproc: Fix code comment
  PCI: iproc: Remove unused code
  PCI: iproc: Remove ARCH specific flag
  PCI: iproc: Fix PCIe reset logic
  PCI: iproc: Improve link detection logic
  PCI: iproc: Update iProc PCIe device tree bindings
  PCI: iproc: Add outbound mapping support
  PCI: iproc: Fix compile warnings

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  20 +++
 drivers/pci/host/pcie-iproc-platform.c |  27 
 drivers/pci/host/pcie-iproc.c  | 159 +++--
 drivers/pci/host/pcie-iproc.h  |  20 ++-
 4 files changed, 210 insertions(+), 16 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/8] PCI: iproc: Add outbound mapping support

[Ray Jui]

Certain iProc SoCs require the PCIe outbound mapping to be configured in
SW. This patch adds support for those chips

Signed-off-by: Ray Jui 
---
 drivers/pci/host/pcie-iproc-platform.c |  27 
 drivers/pci/host/pcie-iproc.c  | 113 +
 drivers/pci/host/pcie-iproc.h  |  17 +
 3 files changed, 157 insertions(+)

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 9aedc8e..c9550dc 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -54,6 +54,33 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
+   if (of_property_read_bool(np, "brcm,pcie-ob")) {
+   u32 val;
+
+   ret = of_property_read_u32(np, "brcm,pcie-ob-axi-offset",
+  );
+   if (ret) {
+   dev_err(pcie->dev,
+   "missing brcm,pcie-ob-axi-offset property\n");
+   return ret;
+   }
+   pcie->ob.axi_offset = val;
+
+   ret = of_property_read_u32(np, "brcm,pcie-ob-window-size",
+  );
+   if (ret) {
+   dev_err(pcie->dev,
+   "missing brcm,pcie-ob-window-size property\n");
+   return ret;
+   }
+   pcie->ob.window_size = (resource_size_t)val * SZ_1M;
+
+   if (of_property_read_bool(np, "brcm,pcie-ob-oarr-size"))
+   pcie->ob.set_oarr_size = true;
+
+   pcie->need_ob_cfg = true;
+   }
+
/* PHY use is optional */
pcie->phy = devm_phy_get(>dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 62e8085..2ba3c4b 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -66,6 +66,18 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define OARR_VALID_SHIFT 0
+#define OARR_VALID   BIT(OARR_VALID_SHIFT)
+#define OARR_SIZE_CFG_SHIFT  1
+#define OARR_SIZE_CFGBIT(OARR_SIZE_CFG_SHIFT)
+
+#define OARR_LO(window)  (0xd20 + (window) * 8)
+#define OARR_HI(window)  (0xd24 + (window) * 8)
+#define OMAP_LO(window)  (0xd40 + (window) * 8)
+#define OMAP_HI(window)  (0xd44 + (window) * 8)
+
+#define MAX_NUM_OB_WINDOWS   2
+
 static inline struct iproc_pcie *iproc_data(struct pci_bus *bus)
 {
struct iproc_pcie *pcie;
@@ -212,6 +224,99 @@ static void iproc_pcie_enable(struct iproc_pcie *pcie)
writel(SYS_RC_INTX_MASK, pcie->base + SYS_RC_INTX_EN);
 }
 
+/**
+ * Some iProc SoCs require the SW to configure the outbound address mapping
+ *
+ * Outbound address translation:
+ *
+ * iproc_pcie_address = axi_address - axi_offset
+ * OARR = iproc_pcie_address
+ * OMAP = pci_addr
+ *
+ * axi_addr -> iproc_pcie_address -> OARR -> OMAP -> pci_address
+ */
+static int iproc_pcie_setup_ob(struct iproc_pcie *pcie, u64 axi_addr,
+  u64 pci_addr, resource_size_t size)
+{
+   struct iproc_pcie_ob *ob = >ob;
+   unsigned i;
+   u64 max_size = (u64)ob->window_size * MAX_NUM_OB_WINDOWS;
+
+   if (size > max_size) {
+   dev_err(pcie->dev,
+   "res size 0x%llx exceeds max supported size 0x%llx\n",
+   (u64)size, max_size);
+   return -EINVAL;
+   }
+
+   if (size % ob->window_size) {
+   dev_err(pcie->dev,
+   "res size 0x%llx needs to be multiple of "
+   "window size 0x%llx\n", (u64)size, ob->window_size);
+   return -EINVAL;
+   }
+
+   if (axi_addr < ob->axi_offset) {
+   dev_err(pcie->dev,
+   "axi address %pap less than offset %pap\n",
+   _addr, >axi_offset);
+   return -EINVAL;
+   }
+
+   /*
+* Translate the AXI address to the internal address used by the iProc
+* PCIe core before programming the OARR
+*/
+   axi_addr -= ob->axi_offset;
+
+   for (i = 0; i < MAX_NUM_OB_WINDOWS; i++) {
+   writel(lower_32_bits(axi_addr) | OARR_VALID |
+  (ob->set_oarr_size ? 1 : 0), pcie->base + OARR_LO(i));
+   writel(upper_32_bits(axi_addr), pcie->base + OARR_HI(i));
+   writel(lower_32_bits(pci_addr), pcie->base + OMAP_LO(i));
+   writel(upper_32_bits(pci_addr), pcie->base + OMAP_HI(i));
+
+   size -= ob->window_size;
+   if (size == 0)
+   break;
+
+   axi_addr += ob->window_size;
+   pci_addr += 

[PATCH 3/8] PCI: iproc: Remove ARCH specific flag

[Ray Jui]

Now setup-irq.o is built for arm64, in 'commit 459a07721c11
("PCI: Build setup-irq.o for arm64")' by Jayachandran, pci_fixup_irqs
can be referenced. We no longer need the CONFIG_ARM flag to wrap
around call to pci_fixup_irqs

Signed-off-by: Ray Jui 
---
 drivers/pci/host/pcie-iproc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index fe2efb1..52e7ff2 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -238,9 +238,7 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
 
pci_scan_child_bus(bus);
pci_assign_unassigned_bus_resources(bus);
-#ifdef CONFIG_ARM
pci_fixup_irqs(pci_common_swizzle, pcie->map_irq);
-#endif
pci_bus_add_devices(bus);
 
return 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] PCI: iproc: Fix compile warnings

[Ray Jui]

There are several compile warnings in pcie-iproc.c related to the
printing of a size_t value.  This is a 32bit value on arm, and 64bit on
arm64.  However, the printks are for 64bit values (thus the warning).
Using the %pap printk for these values (per
Documentation/printk-formats.txt) corrects the issue.

Signed-off-by: Jon Mason 
---
 drivers/pci/host/pcie-iproc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 2ba3c4b..f3481dd 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -244,15 +244,15 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie, 
u64 axi_addr,
 
if (size > max_size) {
dev_err(pcie->dev,
-   "res size 0x%llx exceeds max supported size 0x%llx\n",
-   (u64)size, max_size);
+   "res size 0x%pap exceeds max supported size 0x%llx\n",
+   , max_size);
return -EINVAL;
}
 
if (size % ob->window_size) {
dev_err(pcie->dev,
-   "res size 0x%llx needs to be multiple of "
-   "window size 0x%llx\n", (u64)size, ob->window_size);
+   "res size %pap needs to be multiple of window size 
%pap\n",
+   , >window_size);
return -EINVAL;
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: readd refcounting for struct clk instances

[Stephen Boyd]

On 09/15, Heiko Stübner wrote:
> With the split into struct clk and struct clk_core, clocks lost the
> ability for nested __clk_get clkdev calls. While it stays possible to
> call __clk_get, the first call to (__)clk_put will clear the struct clk,
> making subsequent clk_put calls run into a NULL pointer dereference.
> 
> One prime example of this sits in the generic power domain code, where it
> is possible to add the clocks both by name and by passing in a struct clk
> via pm_clk_add_clk(). __pm_clk_add() in turn then calls __clk_get to
> increase the refcount, so that the original code can put the clock again.
> 
> A possible call-path looks like
> clk = of_clk_get();
> pm_clk_add_clk(dev, clk);
> clk_put(clk);
> 
> with pm_clk_add_clk() => __pm_clk_add() then calling __clk_get on the clk
> and later clk_put when the pm clock list gets destroyed, thus creating
> a NULL pointer deref, as the struct clk doesn't exist anymore.
> 
> So add a separate refcounting for struct clk instances and only clean up
> once the refcount reaches zero.
> 
> Signed-off-by: Heiko Stuebner 
> ---
> I stumbled upon this while applying the new Rockchip power-domain driver,
> but I guess the underlying issue is universal and probably present since
> the original clk/clk_core split, so this probably counts as fix.

Ok. The fix makes sense, but I wonder why we do this. Perhaps we
should stop exporting __clk_get() and __clk_put() to everything
that uses clkdev in the kernel. They're called per-user clks for
a reason. There's one user. Now we have two users of the same
struct clk instance, so we have to refcount it too? I hope the
shared clk instance isn't being used to set rates in two pieces
of code.

And this only affects pm_clk_add_clk() callers right? So the only
caller in the kernel (drivers/clk/shmobile/clk-mstp.c) doesn't
seem to have this problem right now because it never calls
clk_put() on the pointer it passes to pm_clk_add_clk().

So what if we did the patch below? This would rely on callers not
calling clk_put() before calling pm_clk_remove() or
pm_clk_destroy(), and the life cycle would be clear, but the
sharing is still there. Or we could say that after a clk is given
to pm_clk_add_clk() that the caller shouldn't touch it anymore,
like shmobile is doing right now. Then there's nothing to do
besides remove the extra __clk_get() call in the pm layer.

> 
> @@ -2606,6 +2607,18 @@ static void __clk_release(struct kref *ref)
>   kfree(core);
>  }
>  
> +static void __clk_release(struct kref *ref)
> +{
> + struct clk *clk = container_of(ref, struct clk, ref);
> +
> + hlist_del(>clks_node);
> + if ((clk->min_rate > clk->core->req_rate ||
> +  clk->max_rate < clk->core->req_rate))

Why did we grow a pair of parenthesis?

> + clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
> +
> + kfree(clk);
> +}
> +
>  /*
>   * Empty clk_ops for unregistered clocks. These are used temporarily
>   * after clk_unregister() was called on a clock and until last clock


diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..ef62bb3d7b26 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -31,6 +31,7 @@ struct pm_clock_entry {
char *con_id;
struct clk *clk;
enum pce_status status;
+   bool needs_clk_put;
 };
 
 /**
@@ -59,8 +60,10 @@ static inline void __pm_clk_enable(struct device *dev, 
struct pm_clock_entry *ce
  */
 static void pm_clk_acquire(struct device *dev, struct pm_clock_entry *ce)
 {
-   if (!ce->clk)
+   if (!ce->clk) {
ce->clk = clk_get(dev, ce->con_id);
+   ce->needs_clk_put = true;
+   }
if (IS_ERR(ce->clk)) {
ce->status = PCE_STATUS_ERROR;
} else {
@@ -93,7 +96,7 @@ static int __pm_clk_add(struct device *dev, const char 
*con_id,
return -ENOMEM;
}
} else {
-   if (IS_ERR(clk) || !__clk_get(clk)) {
+   if (IS_ERR(clk)) {
kfree(ce);
return -ENOENT;
}
@@ -149,7 +152,8 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)
 
if (ce->status >= PCE_STATUS_ACQUIRED) {
clk_unprepare(ce->clk);
-   clk_put(ce->clk);
+   if (ce->needs_clk_put)
+   clk_put(ce->clk);
}
}
 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/8] PCI: iproc: Improve link detection logic

[Ray Jui]

This patch further improves the iProc PCIe link detection logic by
explicitly querying the link status register to ensure link is active

It also forces class to PCI_CLASS_BRIDGE_PCI (0x0604) through the host
configuration space register

Signed-off-by: Ray Jui 
Reviewed-by: Anup Patel 
Reviewed-by: Scott Branden 
---
 drivers/pci/host/pcie-iproc.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 80e0541..62e8085 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -60,6 +60,12 @@
 #define SYS_RC_INTX_EN   0x330
 #define SYS_RC_INTX_MASK 0xf
 
+#define PCIE_LINK_STATUS_OFFSET  0xf0c
+#define PCIE_PHYLINKUP_SHIFT 3
+#define PCIE_PHYLINKUP   BIT(PCIE_PHYLINKUP_SHIFT)
+#define PCIE_DL_ACTIVE_SHIFT 2
+#define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
+
 static inline struct iproc_pcie *iproc_data(struct pci_bus *bus)
 {
struct iproc_pcie *pcie;
@@ -138,9 +144,15 @@ static void iproc_pcie_reset(struct iproc_pcie *pcie)
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
 {
u8 hdr_type;
-   u32 link_ctrl;
+   u32 link_ctrl, class, val;
u16 pos, link_status;
-   int link_is_active = 0;
+   bool link_is_active = false;
+
+   val = readl(pcie->base + PCIE_LINK_STATUS_OFFSET);
+   if (!(val & PCIE_PHYLINKUP) || !(val & PCIE_DL_ACTIVE)) {
+   dev_err(pcie->dev, "PHY or data link is INACTIVE!\n");
+   return -ENODEV;
+   }
 
/* make sure we are not in EP mode */
pci_bus_read_config_byte(bus, 0, PCI_HEADER_TYPE, _type);
@@ -150,14 +162,19 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie, 
struct pci_bus *bus)
}
 
/* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
-   pci_bus_write_config_word(bus, 0, PCI_CLASS_DEVICE,
- PCI_CLASS_BRIDGE_PCI);
+#define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
+#define PCI_CLASS_BRIDGE_MASK  0x00
+#define PCI_CLASS_BRIDGE_SHIFT 8
+   pci_bus_read_config_dword(bus, 0, PCI_BRIDGE_CTRL_REG_OFFSET, );
+   class &= ~PCI_CLASS_BRIDGE_MASK;
+   class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
+   pci_bus_write_config_dword(bus, 0, PCI_BRIDGE_CTRL_REG_OFFSET, class);
 
/* check link status to see if link is active */
pos = pci_bus_find_capability(bus, 0, PCI_CAP_ID_EXP);
pci_bus_read_config_word(bus, 0, pos + PCI_EXP_LNKSTA, _status);
if (link_status & PCI_EXP_LNKSTA_NLW)
-   link_is_active = 1;
+   link_is_active = true;
 
if (!link_is_active) {
/* try GEN 1 link speed */
@@ -181,7 +198,7 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie, 
struct pci_bus *bus)
pci_bus_read_config_word(bus, 0, pos + PCI_EXP_LNKSTA,
 _status);
if (link_status & PCI_EXP_LNKSTA_NLW)
-   link_is_active = 1;
+   link_is_active = true;
}
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] PCI: iproc: Fix PCIe reset logic

[Ray Jui]

The current iProc PCIe reset logic does not always properly reset the
device. For example, in the case when the perst_b signal is already
de-asserted in the bootloader, the current reset logic fails to trigger
a proper asssert -> de-assert reset sequence. This patch fixes the issue
by always triggering the proper reset sequence

This patch also explicitly selects the desired reset source, i.e.,
perst_b and reduces the wait time after the device comes out of reset
from 250 ms to 100 ms, based on recommendation from the ASIC team

Signed-off-by: Ray Jui 
Reviewed-by: Vladimir Dreizin 
Reviewed-by: Trac Hoang 
Reviewed-by: Scott Branden 
Tested-by: Vladimir Dreizin 
Tested-by: Darren Edamura 
---
 drivers/pci/host/pcie-iproc.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 52e7ff2..80e0541 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -31,6 +31,8 @@
 #include "pcie-iproc.h"
 
 #define CLK_CONTROL_OFFSET   0x000
+#define EP_PERST_SOURCE_SELECT_SHIFT 2
+#define EP_PERST_SOURCE_SELECT   BIT(EP_PERST_SOURCE_SELECT_SHIFT)
 #define EP_MODE_SURVIVE_PERST_SHIFT  1
 #define EP_MODE_SURVIVE_PERSTBIT(EP_MODE_SURVIVE_PERST_SHIFT)
 #define RC_PCIE_RST_OUTPUT_SHIFT 0
@@ -119,15 +121,18 @@ static void iproc_pcie_reset(struct iproc_pcie *pcie)
u32 val;
 
/*
-* Configure the PCIe controller as root complex and send a downstream
-* reset
+* Select perst_b signal as reset source. Put the device into reset,
+* and then bring it out of reset
 */
-   val = EP_MODE_SURVIVE_PERST | RC_PCIE_RST_OUTPUT;
+   val = readl(pcie->base + CLK_CONTROL_OFFSET);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
writel(val, pcie->base + CLK_CONTROL_OFFSET);
udelay(250);
-   val &= ~EP_MODE_SURVIVE_PERST;
+
+   val |= RC_PCIE_RST_OUTPUT;
writel(val, pcie->base + CLK_CONTROL_OFFSET);
-   msleep(250);
+   msleep(100);
 }
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Tilman Schmidt]

Am 16.09.2015 um 01:08 schrieb Peter Hurley:
> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby  > wrote:
> 
> From: Tilman Schmidt 
> 
> 3.12-stable review patch.  If anyone has any objections, please let
> me know.
> 
> ===
> 
> [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
> 
> Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
> first merged in kernel release 3.10, caused the following regression
> in the Gigaset M101 driver:
> 
> 
> Again, I'll just note my objection to this commit log.
> 
> This driver was always broken because it never initialized
> tty->receive_room,
> but rather relied on common but not guaranteed circumstances to
> function.
> 
> The commit noted simply made the underlying bug more evident, but the
> root cause was from the original merge commit of this driver.

I must admit I still don't understand that objection. The meaning of the
term "regression" is simply that something which previously worked
stopped working. It doesn't imply any statement about the root cause.

The ser-gigaset driver worked before the introduction of commit
79901317ce80. It didn't work anymore after the introduction of that
commit. So it is correct, and does not contradict your statements above
in any way, to state that commit introduced the described regression.

-- 
Tilman Schmidt  E-Mail: til...@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

[PATCH 00/19] Lustre cleanups

[green]

From: Oleg Drokin 

This bunch of patches removes significant chunks of
Lustre specific allocators which is possible thanks to prior patches
from Julia Lawall.
Also removed are some server-only bits of code that make no sense
to retain in a client.

Please consider.

Oleg Drokin (19):
  staging/lustre: Remove OBD_CPT_ALLOC_LARGE
  staging/lustre: Remove unused OBD_VMALLOC
  staging/lustre: Remove unused OBD_CPT_ALLOC* macros
  staging/lustre: Remove users of OBD_ALLOC/FREE_PTR lu_object.h
  staging/lustre/llite: Get rid of OBD_ALLOC/FREE_PTR
  staging/lustre/obdclass: replace OBD_ALLOC_GFP with kzalloc
  staging/lustre: Remove references to OBD_ALLOC/FREE* in comments
  staging/lustre/fld: Replace OBD_ALLOC_GFP with kzalloc
  staging/lustre: Convert lustre_cfg_new/free to use kzalloc/kfree
  staging/lustre/ptlrpc: Replace OBD_FREE_PTR with kfree
  staging/lustre: Replace last users of OBD_ALLOC/FREE_LARGE
  staging/lustre: Remove stray bit of userland utils code
  staging/lustre: Remove unused OBD_ALLOC* and OBD_FREE macros
  staging/lustre: Remove memory allocation fault injection framework
  staging/lustre: Remove lustre used memory tracking framework
  staging/lustre: remove obd_memory stats counter
  staging/lustre: Remove IS_SERVER and all users
  staging/lustre: remove IS_MDS|IS_OST|IS_MGS defines and users
  staging/lustre: Remove server defines from lustre_disk.h

 drivers/staging/lustre/lustre/fld/fld_cache.c  |   2 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |   4 +-
 drivers/staging/lustre/lustre/include/lustre_cfg.h |   6 +-
 .../staging/lustre/lustre/include/lustre_disk.h| 142 ---
 drivers/staging/lustre/lustre/include/lustre_lib.h |   4 +-
 drivers/staging/lustre/lustre/include/lustre_net.h |   2 +-
 drivers/staging/lustre/lustre/include/obd.h|  12 +-
 .../staging/lustre/lustre/include/obd_support.h| 198 +
 drivers/staging/lustre/lustre/llite/file.c |   2 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|   2 +-
 drivers/staging/lustre/lustre/mgc/mgc_request.c|  44 +
 drivers/staging/lustre/lustre/obdclass/cl_page.c   |   3 +-
 drivers/staging/lustre/lustre/obdclass/class_obd.c | 103 ---
 .../staging/lustre/lustre/obdclass/llog_internal.h |   8 -
 .../lustre/lustre/obdclass/lprocfs_counters.c  |   9 -
 .../lustre/lustre/obdclass/lprocfs_status.c|   2 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |  91 ++
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|   2 +-
 drivers/staging/lustre/lustre/ptlrpc/pinger.c  |   2 -
 .../staging/lustre/lustre/ptlrpc/ptlrpc_internal.h |   2 +-
 drivers/staging/lustre/lustre/ptlrpc/service.c |   6 +-
 21 files changed, 46 insertions(+), 600 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver core: Ensure proper suspend/resume ordering

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 10:23:07 AM Alan Stern wrote:
> On Tue, 15 Sep 2015, Rafael J. Wysocki wrote:
> 
> > Hi Alan,
> 
> Hi.
> 
> > On Sat, Sep 12, 2015 at 7:40 PM, Alan Stern  
> > wrote:
> > > On Sat, 12 Sep 2015, Rafael J. Wysocki wrote:
> > >
> > >> On Friday, September 11, 2015 03:01:14 PM Alan Stern wrote:
> > >
> > >> > There's also an issue about other types of dependencies.  For instance,
> > >> > it's conceivable that device B might be discovered and depend on device
> > >> > A, even before A has been bound to a driver.  (B might be discovered by
> > >> > A's subsystem rather than A's driver.)  In that case, moving A to the
> > >> > end of the list would cause B to come before A even though B depends on
> > >> > A.  Of course, deferred probing already has this problem.
> > >>
> > >> That may actually happen for PCIe ports and devices below them AFAICS.
> > >>
> > >> Devices below PCIe ports are discovered by the PCI subsystem and the PCIe
> > >> ports need not be probed before those devices are probed.
> > >
> > > Is it possible to change this?  Make it so that devices below PCIe
> > > ports are discovered by the port driver rather than by the PCI
> > > subsystem?  Or would that be far too difficult?
> > 
> > I don't think it would be really useful.
> > 
> > PCIe ports are PCI bridges from the resource allocation and basic
> > functionality perspective, so they are handled accordingly.
> > 
> > The PCIe port driver provides additional services (such as PME/hotplug
> > interrupt handling and advanced error reporting) that aren't necessary
> > for probing devices below the ports.
> > 
> > I guess the ordering of PCIe ports probing might be changed to happen
> > at the "right" time, but care needs to be taken in that case too.
> 
> Does suspending a PCIe port do anything significant?  In particular, 
> does it cut off normal communication with anything attached through 
> the port?

No, it doesn't.

> If it does then we better not move the port device to the end of the 
> dpm_list after any descendant devices have been probed.
> 
> > >> > An easy way to check for this sort of thing would be to verify that a
> > >> > device about to be probed doesn't have any children.  This wouldn't
> > >> > catch all the potential dependencies, but it would be a reasonable
> > >> > start.
> > >>
> > >> That would address the PCIe ports issue.
> > >
> > > Well, it would _detect_ the PCIe ports issue.
> > 
> > That's what I meant. :-)
> > 
> > >  It might also detect other things.
> > 
> > Right.
> 
> All right, I'll try writing a test patch to report these things.

OK, thanks!

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/19] staging/lustre: Remove unused OBD_CPT_ALLOC* macros

[green]

From: Oleg Drokin 

OBD_CPT_ALLOC and friends are no longer used, so remove them.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/obd_support.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_support.h 
b/drivers/staging/lustre/lustre/include/obd_support.h
index f58d142..5ae35fa 100644
--- a/drivers/staging/lustre/lustre/include/obd_support.h
+++ b/drivers/staging/lustre/lustre/include/obd_support.h
@@ -599,15 +599,6 @@ do {   
  \
 #define OBD_ALLOC_PTR(ptr) OBD_ALLOC(ptr, sizeof(*(ptr)))
 #define OBD_ALLOC_PTR_WAIT(ptr) OBD_ALLOC_WAIT(ptr, sizeof(*(ptr)))
 
-#define OBD_CPT_ALLOC_GFP(ptr, cptab, cpt, size, gfp_mask)   \
-   __OBD_MALLOC_VERBOSE(ptr, cptab, cpt, size, gfp_mask)
-
-#define OBD_CPT_ALLOC(ptr, cptab, cpt, size) \
-   OBD_CPT_ALLOC_GFP(ptr, cptab, cpt, size, GFP_NOFS)
-
-#define OBD_CPT_ALLOC_PTR(ptr, cptab, cpt)   \
-   OBD_CPT_ALLOC(ptr, cptab, cpt, sizeof(*(ptr)))
-
 #define OBD_ALLOC_LARGE(ptr, size) \
 do { \
ptr = libcfs_kvzalloc(size, GFP_NOFS);\
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/