Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Sat, Jul 27, 2013 at 11:11 PM, James Bottomley
 wrote:
> If you want actually to describe and have validated the xml schema
> itself, then you'd use xsd (XML schema description language) and its
> associated tools.
>
> I'm not saying you *should* do this, just that it's possible (plus I've
> just blown my kernel cred by knowing about xml, sigh).

:)

g.
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[James Bottomley]

On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
> On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely  
> wrote:
> > On Sat, Jul 27, 2013 at 2:01 PM, jonsm...@gmail.com  
> > wrote:
> >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely  
> >> wrote:
> >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  
> >>> wrote:
>  Let's see how many people go and scream if I say this: Too bad .dts files
>  are not done using XML format as DT bindings could be described using XML
>  Schema.
> >>>
> >>> Draft an example and show us how it would look!  :-)  There is
> >>> absolutely nothing preventing us from expressing a DT in XML format,
> >>> or even using XSLT to define DT schema while still using our current
> >>> .dts syntax. It would be trivial to do lossless translation between
> >>> .dts syntax and xml.
> >>>
> >>> The problem that I have with XML and XSLT is that it is very verbose
> >>> and not entirely friendly to mere-mortals. However, I'm more than
> >>> willing to be proved wrong on this point.
> >>
> >> I considered this approach a while ago and discarded it. It would work
> >> but it is just too much of a Frankenstein monster.
> >>
> >> Much cleaner to modify dtc to take a schema as part of the compilation
> >> process. The schema language itself has no requirement to look like
> >> DTS syntax. Whoever wrote dtc probably has a favorite language that
> >> would be good for writing schemas in.
> >
> > Making it part of dtc is a required feature as far as I'm concerned.
> > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> > digress.
> 
> Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
> discussion of schema. Sorry for the noise.

XSLT is a transform language ... you'd use it say to transform xml to
dtc, so it would be an integral component of an xml/xslt based schema.

If you want actually to describe and have validated the xml schema
itself, then you'd use xsd (XML schema description language) and its
associated tools.

I'm not saying you *should* do this, just that it's possible (plus I've
just blown my kernel cred by knowing about xml, sigh).

James


--
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: How to create IRQ mappings in a GPIO driver that doesn't control its IRQ domain ?

[Grant Likely]

On Thu, 25 Jul 2013 15:22:29 +0200, Laurent Pinchart 
 wrote:
> Hi Mark,
> 
> On Thursday 25 July 2013 14:15:56 Mark Brown wrote:
> > On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:
> > > The two devices are independent, so there's no real parent/child
> > > relationship. However, as Grant proposed, I could list all the interrupts
> > > associated with GPIOs in the GPIO controller DT node. I would then just
> > > call irq_of_parse_and_map() in the .to_irq() handler to magically
> > > translate the GPIO number to a mapped IRQ number.
> > > 
> > > The number of interrupts can be pretty high (up to 58 in the worst case so
> > > far), so an alternative would be to specify the interrupt-parent only, and
> > > call irq_create_of_mapping() directly. What solution would you prefer ?
> > 
> > Are the interrupts in a contiguous block in the controller so you can just
> > pass around the controller and a base number?
> 
> In two of the three SoCs I need to fix they are. I've just realized that in 
> the last one the interrupts are in two contiguous blocks in two different 
> parents. I will thus need at least a list of . Our 
> standard interrupt bindings don't seem to support multiple parents,

You can actually do it by using a dummy node with interrupt-map and
interrupt-map-mask properties, but it is a pretty ugly solution in my
opinion.

> is that 
> something that we want to fix or should I go for custom bindings ?

Yes, I think it is something that we want to fix. Jean-Christophe was
going to propose an alternative to the interrupts property which allows
an array of  tuples, but I've not seen
anything yet. Go ahead and make a proposal.

You could try to encode a base+count variant, but honestly I don't think
it would be a good idea because it only would work with a very narrow
set of use cases. Consider if #interrupt-cells was set to 2. Which cell
gets incremented in the range of interrupts specified? Better I think to
merely have an array of fully specified irqs. Support for that property
could be transparently baked into the core interrupt parsing functions.

g.
--
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: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Thu, 25 Jul 2013 09:09:19 -0700, Olof Johansson  wrote:
> [I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
> discussions have been covered there and this overlaps some with that]
> 
> On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
>  wrote:
> > On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
> >> Remember the stated assertion when DT was first added to the kernel: the
> >> DT descriptions _will_ become a separately maintained project which is
> >> independent of the kernel.  They will _not_ be kernel version specific.
> >
> > I'm looking forward to this.
> >
> > Question for the DT guys: what are the plans here? Are we going to get
> > rid of the .dts files inside the kernel tree?
> 
> In the discussions we had in Dublin, a couple of options on how to
> lock in bindings were discussed. I'm a little surprised that Grant
> didn't cover them in his initial emails on the new maintainership
> model, but maybe he wanted the new group to handle it. And they didn't
> bring it up yet either. So I am. :-)

Excellent! My plan to avoid responsibility for stuff is proceeding.
Actually, I think I touched on it, but the details got lost in my head
among all the other stuff we discussed two weeks ago. Thanks for getting
this detail down into an email.

g.

--
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: [ 06/79] net: Swap ver and type in pppoe_hdr

[David Miller]

From: Greg KH 
Date: Sat, 27 Jul 2013 21:16:16 -0700

> On Sun, Jul 28, 2013 at 04:14:31AM +0100, Ben Hutchings wrote:
>> On Sat, 2013-07-27 at 17:55 -0700, David Miller wrote:
>> > From: Ben Hutchings 
>> > Date: Sat, 27 Jul 2013 16:58:28 +0100
>> > 
>> > > I'm not so sure this is suitable for stable.  It doesn't seem to be
>> > > helpful to either userland or kernel code.
>> > > 
>> > > In the kernel, we were checking that ver == 1 and type == 1 thus this
>> > > wasn't hurting us.
>> > > 
>> > > If userland does anything more with these fields then it's probably
>> > > already working around the swapped fields.  It can work with both old
>> > > and new headers by doing:
>> > 
>> > It's up to you, I would rather have the corrected version propagated
>> > as soon as possible.  But that's just me.
>> 
>> Let's see what Greg thinks.
> 
> I'm guessing that Linus's tree is also "wrong" here, correct?  If so,
> the fix that goes into that tree should also go here as well.
> 
> Or am I confused?

Linus's tree has had this change for a full release.  It went into
3.10

It's correcting a mistake that has been there since the header
file even existed.

--
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: [ 06/79] net: Swap ver and type in pppoe_hdr

[Greg KH]

On Sun, Jul 28, 2013 at 04:14:31AM +0100, Ben Hutchings wrote:
> On Sat, 2013-07-27 at 17:55 -0700, David Miller wrote:
> > From: Ben Hutchings 
> > Date: Sat, 27 Jul 2013 16:58:28 +0100
> > 
> > > I'm not so sure this is suitable for stable.  It doesn't seem to be
> > > helpful to either userland or kernel code.
> > > 
> > > In the kernel, we were checking that ver == 1 and type == 1 thus this
> > > wasn't hurting us.
> > > 
> > > If userland does anything more with these fields then it's probably
> > > already working around the swapped fields.  It can work with both old
> > > and new headers by doing:
> > 
> > It's up to you, I would rather have the corrected version propagated
> > as soon as possible.  But that's just me.
> 
> Let's see what Greg thinks.

I'm guessing that Linus's tree is also "wrong" here, correct?  If so,
the fix that goes into that tree should also go here as well.

Or am I confused?

greg k-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/

[PATCH v3] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[ethan.zhao]

V2: Corrected code style and tested for Linux v 3.11-rc2
V3: Fix the no space betwween words typo and keep the string in one line.

Signed-off-by: ethan.zhao 
---
 arch/x86/pci/mmconfig-shared.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 082e881..619b74b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -700,8 +700,12 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
start, u8 end,
if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
return -ENODEV;
 
-   if (start > end)
+if (start > end || !addr) {
+dev_warn(dev, FW_INFO
+   "Invalid address to add MMCONFIG start %02x end %02x 
addr %pR\n",
+   start, end, addr);
return -EINVAL;
+   }
 
mutex_lock(_mmcfg_lock);
cfg = pci_mmconfig_lookup(seg, start);
@@ -716,11 +720,6 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
start, u8 end,
return -EEXIST;
}
 
-   if (!addr) {
-   mutex_unlock(_mmcfg_lock);
-   return -EINVAL;
-   }
-
rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
if (cfg == NULL) {
-- 
1.7.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 V2] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[ethan]

thanks，got it ,you are right.


在 2013-7-28，11:09，Mark D Rustad  写道：

> Another nit below:
> 
> On Jul 27, 2013, at 12:32 PM, ethan.ker...@gmail.com wrote:
> 
>> Cleanup the -EINVAL return value handling and add warning message for invalid
>> start,end,addr parameters.
>> 
>> V2: Corrected code style and tested for Linux v 3.11-rc2
>> 
>> Signed-off-by: ethan.zhao 
>> ---
>> arch/x86/pci/mmconfig-shared.c |   12 ++--
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>> 
>> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
>> index 082e881..37f6c7f 100644
>> --- a/arch/x86/pci/mmconfig-shared.c
>> +++ b/arch/x86/pci/mmconfig-shared.c
>> @@ -700,8 +700,13 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
>> start, u8 end,
>>if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
>>return -ENODEV;
>> 
>> -if (start > end)
>> +if (start > end || !addr) {
>> +dev_warn(dev, FW_INFO
>> +"Invalid address to add MMCONFIG"
>> +"start %02x end %02x addr %pR\n",
> 
> As it is here, there will be no space between MMCONFIG and the word start. 
> Better still, put the entire string on one line to aid those searching for 
> the message. There is a general exception to the 80-column rule for 
> user-visible messages such as this.
> 
> 
> 
> -- 
> Mark Rustad, mrus...@gmail.com
> 
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely  wrote:
> On Sat, Jul 27, 2013 at 2:01 PM, jonsm...@gmail.com  
> wrote:
>> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely  
>> wrote:
>>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  
>>> wrote:
 Let's see how many people go and scream if I say this: Too bad .dts files
 are not done using XML format as DT bindings could be described using XML
 Schema.
>>>
>>> Draft an example and show us how it would look!  :-)  There is
>>> absolutely nothing preventing us from expressing a DT in XML format,
>>> or even using XSLT to define DT schema while still using our current
>>> .dts syntax. It would be trivial to do lossless translation between
>>> .dts syntax and xml.
>>>
>>> The problem that I have with XML and XSLT is that it is very verbose
>>> and not entirely friendly to mere-mortals. However, I'm more than
>>> willing to be proved wrong on this point.
>>
>> I considered this approach a while ago and discarded it. It would work
>> but it is just too much of a Frankenstein monster.
>>
>> Much cleaner to modify dtc to take a schema as part of the compilation
>> process. The schema language itself has no requirement to look like
>> DTS syntax. Whoever wrote dtc probably has a favorite language that
>> would be good for writing schemas in.
>
> Making it part of dtc is a required feature as far as I'm concerned.
> Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> digress.

Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
discussion of schema. Sorry for the noise.

g.
--
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/3] net/usb/r815x: replace USB buffer from stack to DMA-able

[David Miller]

From: Hayes Wang 
Date: Thu, 25 Jul 2013 15:59:02 +0800

> Some USB buffers use stack which may not be DMA-able.
> Use the buffers from kmalloc to replace those one.
> 
> Signed-off-by: Hayes Wang 

I don't think it's reasonable to kmalloc() a small integer every time
you want to use a USB message transfer to read or write chip
registers.

Instead, add a scratch buffer to struct r8152 which is allocated once
at driver attach time and which you can use for the transfers.

I think you only need an array of two u32's so something like:

u32 transfer_buf[2];

ought to be sufficient.

--
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: [ 06/79] net: Swap ver and type in pppoe_hdr

[Ben Hutchings]

On Sat, 2013-07-27 at 17:55 -0700, David Miller wrote:
> From: Ben Hutchings 
> Date: Sat, 27 Jul 2013 16:58:28 +0100
> 
> > I'm not so sure this is suitable for stable.  It doesn't seem to be
> > helpful to either userland or kernel code.
> > 
> > In the kernel, we were checking that ver == 1 and type == 1 thus this
> > wasn't hurting us.
> > 
> > If userland does anything more with these fields then it's probably
> > already working around the swapped fields.  It can work with both old
> > and new headers by doing:
> 
> It's up to you, I would rather have the corrected version propagated
> as soon as possible.  But that's just me.

Let's see what Greg thinks.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

Re: [PATCH net-next V2] tuntap: hardware vlan tx support

[David Miller]

From: Jason Wang 
Date: Thu, 25 Jul 2013 13:00:33 +0800

> Inspired by commit f09e2249c4f5c7c13261ec73f5a7807076af0c8e (macvtap: restore
> vlan header on user read). This patch adds hardware vlan tx support for
> tuntap. This is done by copying vlan header directly into userspace in
> tun_put_user() instead of doing it through __vlan_put_tag() in
> dev_hard_start_xmit(). This eliminates one unnecessary memmove() in
> vlan_insert_tag() for 802.1ad and 802.1q traffic.
> 
> pktgen test shows about 20% improvement for 802.1q traffic:
> 
> Before:
>   662149pps 317Mb/sec (317831520bps) errors: 0
> After:
>   801033pps 384Mb/sec (384495840bps) errors: 0
> 
> Cc: Basil Gor 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 

Applied, thanks 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 V2] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[Mark D Rustad]

Another nit below:

On Jul 27, 2013, at 12:32 PM, ethan.ker...@gmail.com wrote:

> Cleanup the -EINVAL return value handling and add warning message for invalid
> start,end,addr parameters.
> 
> V2: Corrected code style and tested for Linux v 3.11-rc2
> 
> Signed-off-by: ethan.zhao 
> ---
> arch/x86/pci/mmconfig-shared.c |   12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
> index 082e881..37f6c7f 100644
> --- a/arch/x86/pci/mmconfig-shared.c
> +++ b/arch/x86/pci/mmconfig-shared.c
> @@ -700,8 +700,13 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
> start, u8 end,
>   if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
>   return -ENODEV;
> 
> - if (start > end)
> + if (start > end || !addr) {
> + dev_warn(dev, FW_INFO
> + "Invalid address to add MMCONFIG"
> + "start %02x end %02x addr %pR\n",

As it is here, there will be no space between MMCONFIG and the word start. 
Better still, put the entire string on one line to aid those searching for the 
message. There is a general exception to the 80-column rule for user-visible 
messages such as this.



-- 
Mark Rustad, mrus...@gmail.com

--
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: [ 15/59] sparc32: vm_area_struct access for old Sun SPARCs.

[David Miller]

From: Ben Hutchings 
Date: Sat, 27 Jul 2013 22:45:08 +0100

> On Fri, 2013-07-26 at 13:52 -0700, Greg Kroah-Hartman wrote:
>> 3.4-stable review patch.  If anyone has any objections, please let me know.
>> 
>> --
>> 
>> From: Olivier DANET 
> [...]
> 
> This, and the other SPARC fixes for 3.4 and 3.0, are missing upstream
> commit references, which should be:
> 
> [SPARC] sparc32: vm_area_struct access for old Sun SPARCs.
> commit 961246b4ed8da3bcf4ee1eb9147f341013553e3c upstream.
> 
> sparc64 address-congruence property
> commit 771a37ff4d80b80db3b0df3e7696f14b298c67b7 upstream.
> 
> sparc: tsb must be flushed before tlb
> commit 23a01138efe216f8084cfaa74b0b90dd4b097441 upstream.

Sorry, I forgot the upstream commit tags on these Sparc bits.
:-/
--
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]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer

[ethan . kernel]

commit 968320b hrtimer: Fix extra wakeups from __remove_hrtimer() introduced a 
significant scheduler
 performance regression, following is the test:

a. Test environment:
SUN FIRE X4170 M2 SERVER
CPU model name: Intel(R) Xeon(R) CPU X5675  @ 3.07GHz
2 socket X 6 core X 2 thread

b. To eliminate the disturbing of variable frequency technology of Intel CPU. 
We disabled the C-States, P-States
T-States etc SpeedStep, Turboboost, power management in BIOS configuration.

c. Test case:
1.test tool (Any better tools ?)

int main (void)
{
unsigned long long t0, t1;
int pipe_1[2], pipe_2[2];
int m = 0, i;

pipe(pipe_1);
pipe(pipe_2);

if (!fork()) {
for (i = 0; i < LOOPS; i++) {
read(pipe_1[0], , sizeof(int));
write(pipe_2[1], , sizeof(int));
}
} else {
for (i = 0; i < LOOPS; i++) {
write(pipe_1[1], , sizeof(int));
read(pipe_2[0], , sizeof(int));
}
}

return 0;
}
from  http://people.redhat.com/mingo/cfs-scheduler/tools/pipe-test-1m.c

2.after boot the test kernel a few minutes, execute
$time ./pipe-test-1m
collect data output by time like:
real0m9.326s
user0m0.352s
sys 0m5.640s
3.after the test case finished a few seconds, redo the same one.

d. Test result data
Test kernel without patch 968320b hrtimer: Fix extra wakeups from 
__remove_hrtimer() /
Or applied this patch to disable reprogramming in remove_hrtimer()
-
|  |1 | 2|   3  |4 |5 | 6|7 
|8 |   AVG|
-
| real | 0m5.328s | 0m5.372s | 0m5.307s | 0m5.307s | 0m5.330s | 0m5.315s | 
0m5.318s | 0m5.317s | 5.32425s |
-
| user | 0m0.106s | 0m0.098s | 0m0.108s | 0m0.120s | 0m0.113s | 0m0.121s | 
0m0.125s | 0m0.103s | 0.11175s |
-
| sys  | 0m2.287s | 0m2.334s | 0m2.269s | 0m2.269s | 0m2.298s | 0m2.274s | 
0m2.263s | 0m2.292s | 2.28575s |
-

With patch 968320b hrtimer: Fix extra wakeups from __remove_hrtimer()
Redo the test more than 10 times, select 8 of them, collect the data into 
following tables.
-
|  |1 | 2|   3  |4 |5 | 6|7 
|8 |   AVG   |
-
| real | 0m7.132s | 0m6.741s | 0m6.996s | 0m9.269s | 0m6.742s | 0m6.977s | 
0m6.802s | 0m6.957s | 7.202s   |
-
| user | 0m0.033s | 0m0.031s | 0m0.048s | 0m0.436s | 0m0.022s | 0m0.005s | 
0m0.014s | 0m0.014s | 0.075375s|
-
| sys  | 0m3.119s | 0m2.940s | 0m3.185s | 0m4.023s | 0m3.053s | 0m3.152s | 
0m3.054s | 0m3.124s | 3.20625s |
-

e. Conclusion
We found the performance has 1.87775S(average value) down introduced by commit
968320b hrtimer: Fix extra wakeups from __remove_hrtimer().
That is more than -35% !

Disable reprogramming in remove_hrtimer() to fix this performance regression:
function remove_hrtimer() with reprogramming the clock device is called in 
following two cases:

1.  In function hrtimer_try_to_cancel()
  Whatever you reprogram the clock device or not, the timer function wouldn't 
be called anymore. So set reprogram
to 0 doesn't change the result of hrtimer_try_to_cancel()

 hrtimer_try_to_cancel()
 --- > remove_hrtimer()
  > __remove_hrtimer(timer, base, state, reprogram);

2.  In function  __hrtimer_start_range_ns(),
  After remove_hrtimer() was called, the rest of code in this function will 
check the new timer added into queue is
the leftmost or not, if needed, will reprogram the clock device.

   __hrtimer_start_range_ns()
  {
... ...
ret = remove_hrtimer(timer, base);
... ...
leftmost = enqueue_hrtimer(timer, new_base);
if (leftmost && new_base->cpu_base == &__get_cpu_var(hrtimer_bases)
&& hrtimer_enqueue_reprogram(timer, new_base)) {
... ..
}

Will we lose the chance to reprogram the 

Re: [PATCH v2 1/5] Staging: bcm: LeakyBucket: Fixed spacing/tabing issues

[Joe Perches]

On Sun, 2013-07-28 at 03:34 +0800, Lilis Iskandar wrote:
> I don't understand what you mean by mentioning "git diff -w".
> Perhaps you can clarify it for me? Sorry :(

$ git diff --help | grep -w -A2 "\-w"
  -w, --ignore-all-space
   Ignore whitespace when comparing lines. This ignores differences 
even if one line has whitespace where the other line has none.

It makes sure you are doing only whitespace changes.
Any other changes show up as an actual diff.

You can also compile the changes and make sure
the .o files before and after don't change.

(Something like: assuming a clean tree)

$ cat compare_patch_obj_diffs.sh
#!/bin/bash

if [[ ! -e $1 || ! -f $1 ]]
then
echo "$1 not found"
exit $?
fi

grep -P "^\+\+\+" $1 |
while read file
do
real_file=$(echo $file | cut -f2- -d'/')
if [[ ${real_file:(-2)} == ".c" ]]
then
obj=${real_file%.c}.o
make $obj
mv $obj $obj.old
patch -p1 < $1
make $obj
mv $obj $obj.new
patch -p1 -R < $1
size $obj.old $obj.new
if [[ $2 == "y" ]]
then
objdump -d $obj.old > $obj.old.dmp
objdump -d $obj.new > $obj.new.dmp
diff $obj.old.dmp $obj.new.dmp
rm -f $obj.old.dmp $obj.new.dmp
fi
fi
done


--
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] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[ethan . kernel]

Cleanup the -EINVAL return value handling and add warning message for invalid
start,end,addr parameters.

V2: Corrected code style and tested for Linux v 3.11-rc2

Signed-off-by: ethan.zhao 
---
 arch/x86/pci/mmconfig-shared.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 082e881..37f6c7f 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -700,8 +700,13 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
start, u8 end,
if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
return -ENODEV;
 
-   if (start > end)
+   if (start > end || !addr) {
+   dev_warn(dev, FW_INFO
+   "Invalid address to add MMCONFIG"
+   "start %02x end %02x addr %pR\n",
+   start, end, addr);
return -EINVAL;
+   }
 
mutex_lock(_mmcfg_lock);
cfg = pci_mmconfig_lookup(seg, start);
@@ -716,11 +721,6 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
start, u8 end,
return -EEXIST;
}
 
-   if (!addr) {
-   mutex_unlock(_mmcfg_lock);
-   return -EINVAL;
-   }
-
rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
if (cfg == NULL) {
-- 
1.7.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: [ 00/45] 3.0.88-stable review

[Guenter Roeck]

On 07/27/2013 04:30 PM, Ben Hutchings wrote:

On Sat, 2013-07-27 at 06:22 -0500, li...@roeck-us.net wrote:

Quoting Greg Kroah-Hartman :


This is the start of the stable review cycle for the 3.0.88 release.
There are 45 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jul 28 20:54:53 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.88-rc1.gz
and the diffstat can be found below.


We have additional build failures.

Total builds: 54 Total build errors: 20

Link:
http://desktop.roeck-us.net/buildlogs/v3.0.87-45-g367423c.2013-07-27.03:09:16

Previously:
Total builds: 54 Total build errors: 17

Additional failures are i386/allmodconfig, i386/allyesconfig and mips/malta.

I don't have time to track down the culprit tonight (I am still in
Down Under ;). I hope I can do it tomorrow.

I iterated through the 3.0 patch queue with i386/allmodconfig, and got
to:

Applying patch ifb-fix-rcu_sched-self-detected-stalls.patch
patching file drivers/net/ifb.c

Now at patch ifb-fix-rcu_sched-self-detected-stalls.patch
   CHK include/linux/version.h
   CHK include/generated/utsrelease.h
   CALLscripts/checksyscalls.sh
   CHK include/generated/compile.h
   VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
   VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
   VDSOSYM arch/x86/vdso/vdso32-syms.lds
   LD  arch/x86/vdso/built-in.o
   LD  arch/x86/built-in.o
   CC [M]  drivers/net/ifb.o
drivers/net/ifb.c: In function ‘ifb_init_module’:
drivers/net/ifb.c:257:3: error: implicit declaration of function ‘cond_resched’ 
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/net/ifb.o] Error 1
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2

I think this patch needs to add a '#include ', but that
header is being included indirectly in some other configurations (and in
mainline).

With that change, I can apply the remaining patches and compile
3.0.88-rc1 successfully.

Ben.


Yes, that is what I found as well.

Guenter

--
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: [ 06/79] net: Swap ver and type in pppoe_hdr

[David Miller]

From: Ben Hutchings 
Date: Sat, 27 Jul 2013 16:58:28 +0100

> I'm not so sure this is suitable for stable.  It doesn't seem to be
> helpful to either userland or kernel code.
> 
> In the kernel, we were checking that ver == 1 and type == 1 thus this
> wasn't hurting us.
> 
> If userland does anything more with these fields then it's probably
> already working around the swapped fields.  It can work with both old
> and new headers by doing:

It's up to you, I would rather have the corrected version propagated
as soon as possible.  But that's just me.
--
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: [ 00/79] 3.10.4-stable review

[linux]

Quoting Greg Kroah-Hartman :


This is the start of the stable review cycle for the 3.10.4 release.
There are 79 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jul 28 20:45:08 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.4-rc1.gz
and the diffstat can be found below.


Cross build is ok: Total builds: 64 Total build errors: 3

Details:  
http://desktop.roeck-us.net/buildlogs/v3.10/v3.10.3-79-g6d0cdc6.2013-07-27.15:42:05


Guenter

--
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] drm/cirrus: fix error handling in cirrus_device_init()

[Wei Yongjun]

From: Wei Yongjun 

Fix the error handling in function cirrus_device_init() to avoid resources
leak in the error handling case.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 3a7a0ef..5f59bb0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -138,17 +138,22 @@ int cirrus_device_init(struct cirrus_device *cdev,
}
 
cdev->rmmio = ioremap(cdev->rmmio_base, cdev->rmmio_size);
-
-   if (cdev->rmmio == NULL)
-   return -ENOMEM;
+   if (cdev->rmmio == NULL) {
+   ret = -ENOMEM;
+   goto err_ioremap;
+   }
 
ret = cirrus_vram_init(cdev);
-   if (ret) {
-   release_mem_region(cdev->rmmio_base, cdev->rmmio_size);
-   return ret;
-   }
+   if (ret)
+   goto err_init;
 
return 0;
+
+err_init:
+   iounmap(cdev->rmmio);
+err_ioremap:
+   release_mem_region(cdev->rmmio_base, cdev->rmmio_size);
+   return ret;
 }
 
 void cirrus_device_fini(struct cirrus_device *cdev)

--
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] dts: wandboard: Add support for SDIO bcm4329

[Tony Prisk]

The wandboard has a Broadcom 4329 WiFi connected via SDIO. This patch
sets the required pins to enable the wifi module.

Signed-off-by: Tony Prisk 
---
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi 
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 7a46f64..2fb0e9b 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -73,9 +73,14 @@
hog {
pinctrl_hog: hoggrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_0__CCM_CLKO10x130b0
-   MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x8000
-   MX6QDL_PAD_EIM_DA9__GPIO3_IO09  0x8000
+   MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
+   MX6QDL_PAD_GPIO_2__GPIO1_IO020x8000
+   MX6QDL_PAD_EIM_DA9__GPIO3_IO09   0x8000
+   MX6QDL_PAD_EIM_EB1__GPIO2_IO29   0x8000 /* 
WL_REF_ON */
+   MX6QDL_PAD_EIM_A25__GPIO5_IO02   0x8000 /* 
WL_RST_N */
+   MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x8000 /* 
WL_REG_ON */
+   MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x8000 /* 
WL_HOST_WAKE */
+   MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x8000 /* 
WL_WAKE */
>;
};
};
-- 
1.7.9.5

--
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] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[Ethan Zhao]

Seems there are code style issues etc after I pasted it in my mail client.
I will correct it and resend v2.

Thanks.

On Sun, Jul 28, 2013 at 12:09 AM, Bjorn Helgaas  wrote:
> On Sat, Jul 27, 2013 at 8:27 AM, Yinghai Lu  wrote:
>> On Fri, Jul 26, 2013 at 10:39 AM, Bjorn Helgaas  wrote:
>
>>> [bhelgaas: changelog, drop printk]
>>> Signed-off-by: ethan.zhao 
>>> Signed-off-by: Bjorn Helgaas 
>>> Acked-by: Yinghai Lu 
>>
>> looks like I had typo in ack. please update to
>>
>> Acked-by: Yinghai Lu 
>
> Done, thanks, sorry I didn't notice that :)
--
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] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[Ethan Zhao]

On Sat, Jul 27, 2013 at 1:39 AM, Bjorn Helgaas  wrote:
> [+cc Jiang, linux-pci, -cc bjorn.helg...@hp.com (dead address)]
>
> On Fri, Jul 26, 2013 at 05:10:39PM +0800, ethan zhao wrote:
>> Cleanup the -EINVAL return value handling and add warning message
>> for invalid
>> start,end,addr parameters.
>>
>> Signed-off-by: ethan.zhao 
>
> This patch was corrupted, so I couldn't apply it directly.  See
> Documentation/SubmittingPatches, sections 5-7.
>
>> ---
>>  arch/x86/pci/mmconfig-shared.c |   12 ++--
>>  1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
>> index 082e881..37f6c7f 100644
>> --- a/arch/x86/pci/mmconfig-shared.c
>> +++ b/arch/x86/pci/mmconfig-shared.c
>> @@ -700,8 +700,13 @@ int pci_mmconfig_insert(struct device *dev, u16
>> seg, u8 start, u8 end,
>>  if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
>>  return -ENODEV;
>>
>> -if (start > end)
>> +if (start > end || !addr) {
>> +dev_warn(dev, FW_WARN
>> + "Invalid address to add MMCONFIG"
>> + "start %02x end %02x addr %pR\n",
>> +  start, end, addr);
>>  return -EINVAL;
>> +}
>
> I like the "!addr" cleanup.
>
> Did you actually see this problem on a machine?
>
> I expect this would be a BIOS bug, and one that should be found
> early in development, long before a machine is released.
> Therefore, I doubt that it's worth adding another printk for it.
> If an end-user sees this problem, I think we'll already get a
> generic message from check_segment().
>

Yes, Maybe I met a BIOS bug, but the mmconfig just yelled a failed message like
this, no other information

"fail to add MMCONFIG information, xx--xx can't access extended PCI
configuration space under this bridge"

While I look into the code, found there are detail messages for other
return values in pci_mmconfig_insert(),
But no for -EINVAL, that is not fair and force me to add more code to
debug  the cause.


> I propose the patch below; what do you think?
>
>>
>>  mutex_lock(_mmcfg_lock);
>>  cfg = pci_mmconfig_lookup(seg, start);
>> @@ -716,11 +721,6 @@ int pci_mmconfig_insert(struct device *dev, u16
>> seg, u8 start, u8 end,
>>  return -EEXIST;
>>  }
>>
>> -if (!addr) {
>> -mutex_unlock(_mmcfg_lock);
>> -return -EINVAL;
>> -}
>> -
>>  rc = -EBUSY;
>>  cfg = pci_mmconfig_alloc(seg, start, end, addr);
>>  if (cfg == NULL) {
>
>
>
> Author: ethan.zhao 
> Date:   Fri Jul 26 11:21:24 2013 -0600
>
> x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero
>
> We can check for addr being zero earlier and thus avoid the mutex_unlock()
> cleanup path.
>
> [bhelgaas: changelog, drop printk]
> Signed-off-by: ethan.zhao 
> Signed-off-by: Bjorn Helgaas 
> Acked-by: Yinghai Lu 
>
> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
> index 082e881..5596c7b 100644
> --- a/arch/x86/pci/mmconfig-shared.c
> +++ b/arch/x86/pci/mmconfig-shared.c
> @@ -700,7 +700,7 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
> start, u8 end,
> if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
> return -ENODEV;
>
> -   if (start > end)
> +   if (start > end || !addr)
> return -EINVAL;
>
> mutex_lock(_mmcfg_lock);
> @@ -716,11 +716,6 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
> start, u8 end,
> return -EEXIST;
> }
>
> -   if (!addr) {
> -   mutex_unlock(_mmcfg_lock);
> -   return -EINVAL;
> -   }
> -
> rc = -EBUSY;
> cfg = pci_mmconfig_alloc(seg, start, end, addr);
> if (cfg == NULL) {
--
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] ARM: EDMA: Fix clearing of unused list for DT DMA resources

[Joel Fernandes]

Hi Tony or Sekhar,

If this patch looks ok, could you pick it up for -rc cycle?

It fixes DMA breakages after the merge window for devices for which DMA
resources are being populated in device tree instead pdev.

Thanks,

-Joel


On 07/22/2013 12:59 PM, Joel Fernandes wrote:
> HWMOD removal for MMC is breaking edma_start as the events are being manually
> triggered due to unused channel list not being clear, Thanks to Balaji TK for
> finding this issue.
> 
> This patch fixes the issue, by reading the "dmas" property from the DT node if
> it exists and clearing the bits in the unused channel list.
> 
> Cc: Balaji T K 
> Cc: Pantel Antoniou 
> Signed-off-by: Joel Fernandes 
> ---
> v2 changes: Fixed compiler warning
> 
>  arch/arm/common/edma.c |   31 +++
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a432e6c..765d578 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr, unsigned 
> int id,
>  static int prepare_unused_channel_list(struct device *dev, void *data)
>  {
>   struct platform_device *pdev = to_platform_device(dev);
> - int i, ctlr;
> -
> - for (i = 0; i < pdev->num_resources; i++) {
> - if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> - (int)pdev->resource[i].start >= 0) {
> - ctlr = EDMA_CTLR(pdev->resource[i].start);
> - clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
> - edma_cc[ctlr]->edma_unused);
> + int i = 0, ctlr;
> + u32 dma_chan;
> + const __be32 *dma_chan_p;
> + struct property *prop;
> +
> + if (dev->of_node) {
> + of_property_for_each_u32(dev->of_node, "dmas", prop, \
> +  dma_chan_p, dma_chan) {
> + if (i++ & 1) {
> + ctlr = EDMA_CTLR(dma_chan);
> + clear_bit(EDMA_CHAN_SLOT(dma_chan),
> + edma_cc[ctlr]->edma_unused);
> + }
> + }
> + } else {
> + for (; i < pdev->num_resources; i++) {
> + if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> + (int)pdev->resource[i].start >= 0) {
> + ctlr = EDMA_CTLR(pdev->resource[i].start);
> + clear_bit(EDMA_CHAN_SLOT(
> +   pdev->resource[i].start),
> +   edma_cc[ctlr]->edma_unused);
> + }
>   }
>   }
>  
> 

--
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: [ 00/45] 3.0.88-stable review

[Ben Hutchings]

On Sat, 2013-07-27 at 06:22 -0500, li...@roeck-us.net wrote:
> Quoting Greg Kroah-Hartman :
> 
> > This is the start of the stable review cycle for the 3.0.88 release.
> > There are 45 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Jul 28 20:54:53 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.88-rc1.gz
> > and the diffstat can be found below.
> >
> We have additional build failures.
> 
> Total builds: 54 Total build errors: 20
> 
> Link:  
> http://desktop.roeck-us.net/buildlogs/v3.0.87-45-g367423c.2013-07-27.03:09:16
> 
> Previously:
> Total builds: 54 Total build errors: 17
> 
> Additional failures are i386/allmodconfig, i386/allyesconfig and mips/malta.
> 
> I don't have time to track down the culprit tonight (I am still in  
> Down Under ;). I hope I can do it tomorrow.

I iterated through the 3.0 patch queue with i386/allmodconfig, and got
to:

Applying patch ifb-fix-rcu_sched-self-detected-stalls.patch
patching file drivers/net/ifb.c

Now at patch ifb-fix-rcu_sched-self-detected-stalls.patch
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-syms.lds
  LD  arch/x86/vdso/built-in.o
  LD  arch/x86/built-in.o
  CC [M]  drivers/net/ifb.o
drivers/net/ifb.c: In function ‘ifb_init_module’:
drivers/net/ifb.c:257:3: error: implicit declaration of function ‘cond_resched’ 
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/net/ifb.o] Error 1
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2

I think this patch needs to add a '#include ', but that
header is being included indirectly in some other configurations (and in
mainline).

With that change, I can apply the remaining patches and compile
3.0.88-rc1 successfully.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

Re: [PATCH v4 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Rafael J. Wysocki]

On Saturday, July 27, 2013 03:33:31 PM Ben Guthro wrote:
> 
> On Jul 27, 2013, at 9:51 AM, "Rafael J. Wysocki"  wrote:
> 
> > On Thursday, June 27, 2013 11:01:58 AM Ben Guthro wrote:
> >> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
> >> reduced hardware sleep support, and the two changes didn't get
> >> synchronized: The new code doesn't call the hook function (if so
> >> requested). Fix this, requiring a boolean parameter to be added to the
> >> hook function to distinguish "extended" from "legacy" sleep.
> >> 
> >> This requires adjusting TXT, but the adjustments only go as far as
> >> failing the extended mode call (since, looking at the TXT interface,
> >> there doesn't even appear to be precautions to deal with that
> >> alternative interface).
> >> 
> >> The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
> >> v5 (reduced HW) sleep interface") on the master branch of
> >> git://xenbits.xen.org/xen.git.
> >> 
> >> Signed-off-by: Ben Guthro 
> >> Signed-off-by: Jan Beulich 
> >> Cc: Richard L Maliszewski 
> >> Cc: Gang Wei 
> >> Cc: Shane Wang 
> >> Cc: Bob Moore 
> >> Cc: Rafaell J. Wysocki 
> >> Cc: linux-a...@vger.kernel.org
> >> Cc: tboot-de...@lists.sourceforge.net 
> >> 
> >> v2: Extend description to include reference to hypervisor side change
> >> v3: Split into multiple patches, separating subsystems
> >>Remove bool parameters, in favor of u8
> >> v4: Remove linux/acpi.h dependencies
> >>Further patch split to break out acpica from OSL
> >>More bool vs u8 fixes
> >> 
> >> Ben Guthro (5):
> >>  acpi: Remove need to include linux/acpi.h in common acpica code
> >>  acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
> >>  acpi: Adjust linux acpi OS functions to new extended parameter
> >>  x86/tboot: Fail extended mode reduced hardware sleep
> >>  xen/acpi: notify xen when reduced hardware sleep is available
> > 
> > The ongoing discussion means to me that the ACPICA maintainers don't want
> > acpi_os_prepare_sleep() and quite frankly I understand them, because ACPICA
> > is about implementing the spec and not about things beyond it.
> > 
> > This means that patch [1/5] goes away.
> > 
> > That said, at the same time we need to address the problem at hand, which
> > is to make Xen work with the reduced HW sleep.
> > 
> > For that, I don't honestly think that modifying acpi_os_prepare_sleep() the
> > way the patchset is doing it is appropriate and the change of the meaning of
> > the arguments is simply disgusting.
> > 
> > To me, it would be much cleaner to add acpi_os_prepare_extended_sleep()
> > specifically to be called by acpi_hw_extended_sleep() and make tboot and Xen
> > use that.
> > 
> > This way or another, we'll need to live with one more divergence between the
> > upstream ACPICA and the Linux ACPICA code because of that, but that'd be 
> > just
> > a few added lines in acpi_hw_extended_sleep(), so I suppose it wouldn't be
> > such a big deal.
> > 
> 
> Ok, thank you for the review, and being open to addressing the problem at
> hand,

No problem, although I'm not exactly happy with it.

> without a full architecture rework (not to say that that discussion is not
> also needed)

Sure, it is needed.

> I will try to make some time next week to rework the patch set to address
> these concerns, and submit a new series. 

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] avr32: boards/atngw100/mrmt.c: fix building error

[Cong Ding]

there is an additional "{", which causes building error.

Signed-off-by: Cong Ding 
---
 arch/avr32/boards/atngw100/mrmt.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/avr32/boards/atngw100/mrmt.c 
b/arch/avr32/boards/atngw100/mrmt.c
index ccc9599..1ba09e4 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -150,7 +150,6 @@ static struct ac97c_platform_data __initdata ac97c0_data = {
 static struct platform_device rmt_ts_device = {
.name   = "ucb1400_ts",
.id = -1,
-   }
 };
 #endif
 
-- 
1.7.10.4

--
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 jiffies] Avoid undefined behavior from signed overflow

[Paul E. McKenney]

According to the C standard 3.4.3p3, overflow of a signed integer results
in undefined behavior.  This commit therefore changes the definitions
of time_after() and time_after_eq() to avoid this undefined behavior.
The trick is that the subtraction is done using unsigned arithmetic,
which according to 6.2.5p9 cannot overflow because it is defined as
modulo arithmetic.  This has the added (though admittedly quite small)
benefit of shortening two lines of code by four characters each.

Note that the C standard considers the cast from signed to
unsigned to be implementation-defined, see 6.3.1.3p3.  However, on a
two-complement system, an implementation that defines anything other
than a reinterpretation of the bits is free come to me, and I will be
happy to act as a witness for its being committed to an insane asylum.
(Although I have nothing against saturating arithmetic or signals in
some cases, these things really should not be the default.)

Signed-off-by: Paul E. McKenney 
Cc: John Stultz 
Cc: "David S. Miller" 
Cc: Arnd Bergmann 
Cc: Ingo Molnar 
Cc: Linus Torvalds 

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 97ba4e7..97967ba 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -101,13 +101,13 @@ static inline u64 get_jiffies_64(void)
 #define time_after(a,b)\
(typecheck(unsigned long, a) && \
 typecheck(unsigned long, b) && \
-((long)(b) - (long)(a) < 0))
+((long)((b) - (a)) < 0))
 #define time_before(a,b)   time_after(b,a)
 
 #define time_after_eq(a,b) \
(typecheck(unsigned long, a) && \
 typecheck(unsigned long, b) && \
-((long)(a) - (long)(b) >= 0))
+((long)((a) - (b)) >= 0))
 #define time_before_eq(a,b)time_after_eq(b,a)
 
 /*

--
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 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

This makes it possible to let gdb access mappings of the process that is
being debugged.

uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.

Signed-off-by: Uwe Kleine-König 
---
Changes since v1:
- only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
- fix all users of renamed struct

 drivers/uio/uio.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3b96f18..c4279b2 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -630,12 +630,26 @@ static int uio_vma_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
return 0;
 }
 
-static const struct vm_operations_struct uio_vm_ops = {
+static const struct vm_operations_struct uio_logical_vm_ops = {
.open = uio_vma_open,
.close = uio_vma_close,
.fault = uio_vma_fault,
 };
 
+static int uio_mmap_logical(struct vm_area_struct *vma)
+{
+   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+   vma->vm_ops = _logical_vm_ops;
+   uio_vma_open(vma);
+   return 0;
+}
+
+static const struct vm_operations_struct uio_physical_vm_ops = {
+#ifdef CONFIG_HAVE_IOREMAP_PROT
+   .access = generic_access_phys,
+#endif
+};
+
 static int uio_mmap_physical(struct vm_area_struct *vma)
 {
struct uio_device *idev = vma->vm_private_data;
@@ -643,6 +657,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
if (mi < 0)
return -EINVAL;
 
+   vma->vm_ops = _physical_vm_ops;
+
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
return remap_pfn_range(vma,
@@ -652,14 +668,6 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
   vma->vm_page_prot);
 }
 
-static int uio_mmap_logical(struct vm_area_struct *vma)
-{
-   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
-   vma->vm_ops = _vm_ops;
-   uio_vma_open(vma);
-   return 0;
-}
-
 static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 {
struct uio_listener *listener = filep->private_data;
-- 
1.8.3.2

--
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 2/2] uio: drop unused vma_count member in uio_device struct

[Uwe Kleine-König]

vma_count is used write-only and so fails to be useful. So remove it.

Signed-off-by: Uwe Kleine-König 
---
changes since v1:
- adapt to changes in patch 1 
 drivers/uio/uio.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c4279b2..8abe78c 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -35,7 +35,6 @@ struct uio_device {
atomic_tevent;
struct fasync_struct*async_queue;
wait_queue_head_t   wait;
-   int vma_count;
struct uio_info *info;
struct kobject  *map_dir;
struct kobject  *portio_dir;
@@ -593,18 +592,6 @@ static int uio_find_mem_index(struct vm_area_struct *vma)
return -1;
 }
 
-static void uio_vma_open(struct vm_area_struct *vma)
-{
-   struct uio_device *idev = vma->vm_private_data;
-   idev->vma_count++;
-}
-
-static void uio_vma_close(struct vm_area_struct *vma)
-{
-   struct uio_device *idev = vma->vm_private_data;
-   idev->vma_count--;
-}
-
 static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct uio_device *idev = vma->vm_private_data;
@@ -631,8 +618,6 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
 }
 
 static const struct vm_operations_struct uio_logical_vm_ops = {
-   .open = uio_vma_open,
-   .close = uio_vma_close,
.fault = uio_vma_fault,
 };
 
@@ -640,7 +625,6 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
 {
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = _logical_vm_ops;
-   uio_vma_open(vma);
return 0;
 }
 
-- 
1.8.3.2

--
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] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

On Fri, Jul 26, 2013 at 05:58:10PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 16, 2013 at 07:21:03PM +0200, Uwe Kleine-König wrote:
> > This makes it possible to let gdb access mappings of the process that is
> > being debugged.
> > 
> > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > and differentiate to new stuff.
> > 
> > Signed-off-by: Uwe Kleine-König 
> 
> This patch breaks the build:
> 
> drivers/uio/uio.c: In function ‘uio_mmap_logical’:
> drivers/uio/uio.c:627:17: error: ‘uio_vm_ops’ undeclared (first use in this 
> function)
Hmm, in my original patch this is OK, I don't have no idea how I could
bork that for submission. While looking into that problem I noticed that
there is yet another problem. I will send a fixed patch early next week.

Best regards and thanks for testing,
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: [ 15/59] sparc32: vm_area_struct access for old Sun SPARCs.

[Ben Hutchings]

On Fri, 2013-07-26 at 13:52 -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Olivier DANET 
[...]

This, and the other SPARC fixes for 3.4 and 3.0, are missing upstream
commit references, which should be:

[SPARC] sparc32: vm_area_struct access for old Sun SPARCs.
commit 961246b4ed8da3bcf4ee1eb9147f341013553e3c upstream.

sparc64 address-congruence property
commit 771a37ff4d80b80db3b0df3e7696f14b298c67b7 upstream.

sparc: tsb must be flushed before tlb
commit 23a01138efe216f8084cfaa74b0b90dd4b097441 upstream.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [ 71/79] ext4: fix error handling in ext4_ext_truncate()

[Ben Hutchings]

On Fri, 2013-07-26 at 13:48 -0700, Greg Kroah-Hartman wrote:
> 3.10-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Theodore Ts'o 
> 
> commit 8acd5e9b1217e58a57124d9e225afa12efeae20d upstream.
> 
> Previously ext4_ext_truncate() was ignoring potential error returns
> from ext4_es_remove_extent() and ext4_ext_remove_space().  This can
> lead to the on-diks extent tree and the extent status tree cache
> getting out of sync, which is particuarlly bad, and can lead to file
> system corruption and potential data loss.
> 
> Signed-off-by: "Theodore Ts'o" 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  fs/ext4/extents.c |   11 +++
>  1 file changed, 11 insertions(+)
> 
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4386,9 +4386,20 @@ void ext4_ext_truncate(handle_t *handle,
>  
>   last_block = (inode->i_size + sb->s_blocksize - 1)
>   >> EXT4_BLOCK_SIZE_BITS(sb);
> +retry:
>   err = ext4_es_remove_extent(inode, last_block,
>   EXT_MAX_BLOCKS - last_block);
> + if (err == ENOMEM) {

Positive ENOMEM?!  It looks like this value is bubbled up from
__es_insert_extent() which returns the usual negative error codes.

Ben.

> + cond_resched();
> + congestion_wait(BLK_RW_ASYNC, HZ/50);
> + goto retry;
> + }
> + if (err) {
> + ext4_std_error(inode->i_sb, err);
> + return;
> + }
>   err = ext4_ext_remove_space(inode, last_block, EXT_MAX_BLOCKS - 1);
> + ext4_std_error(inode->i_sb, err);
>  }
>  
>  static void ext4_falloc_update_inode(struct inode *inode,
> 

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [ 00/59] 3.4.55-stable review

[linux]

Quoting Greg Kroah-Hartman :


This is the start of the stable review cycle for the 3.4.55 release.
There are 59 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jul 28 20:48:22 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.55-rc1.gz
and the diffstat can be found below.


Cross platform build looks good:

Total builds: 58 Total: build errors: 8

Details:  
http://desktop.roeck-us.net/buildlogs/v3.4.54-59-g956f996.2013-07-27.08:29:14


Guenter

--
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: Save soft-dirty bits on file pages

[Cyrill Gorcunov]

On Sat, Jul 27, 2013 at 10:06:01AM -0700, Andy Lutomirski wrote:
> 
> That being said, a MAP_PRIVATE, un-cowed mapping must be clean -- if
> it had been (soft-)dirtied, it would also have been cowed.  So you
> might be okay.

Yas, as far as I know we are either cow'ed or in clean state, thus
either soft-bit set on #pf (and when reclaimed rest in file-pte)
or it remains clean and there is no change we need to track.
--
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/

HI

[Unice Kuku]

Hi My Dear,

May peace be with you. I am Miss Unice. Actually, We may not known in person 
but relationship can start like this!. Please, I'm sorry if I am embarrassing 
you by my gesture. I really wish to be your friend, learn to know you and to 
have a place in your heart for an ideal relationship with us. I will be very 
happy if you contact me for my picture and more about me.
See you soon?
Thanks in advance and remain blessed!
Unice
--
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] sky2: detect and prevent kernel panic from a possible faulty hardware

[Samuel Williams]

A possible faulty hardware might interrupt with a status of 0x which
may kernel panic if sky2 driver tries to handle it. Detecting this problem
may avoid kernel panic.

Signed-off-by: Samuel Williams 
---
 drivers/net/ethernet/marvell/sky2.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/sky2.c 
b/drivers/net/ethernet/marvell/sky2.c
index e09a8c6..43fe2f3 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -3049,8 +3049,17 @@ static int sky2_poll(struct napi_struct *napi, int 
work_limit)
int work_done = 0;
u16 idx;
 
-   if (unlikely(status & Y2_IS_ERROR))
+   if (unlikely(status & Y2_IS_ERROR)) {
+   if (status == 0x) {
+   dev_err(>pdev->dev,
+   "fatal hardware inturrupt error\n");
+   napi_complete(napi);
+   napi_disable(>napi);
+   return 0;
+   }
sky2_err_intr(hw, status);
+   }
+
 
if (status & Y2_IS_IRQ_PHY1)
sky2_phy_intr(hw, 0);
-- 
1.7.10.4

--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Sat, Jul 27, 2013 at 2:01 PM, jonsm...@gmail.com  wrote:
> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely  
> wrote:
>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  wrote:
>>> Let's see how many people go and scream if I say this: Too bad .dts files
>>> are not done using XML format as DT bindings could be described using XML
>>> Schema.
>>
>> Draft an example and show us how it would look!  :-)  There is
>> absolutely nothing preventing us from expressing a DT in XML format,
>> or even using XSLT to define DT schema while still using our current
>> .dts syntax. It would be trivial to do lossless translation between
>> .dts syntax and xml.
>>
>> The problem that I have with XML and XSLT is that it is very verbose
>> and not entirely friendly to mere-mortals. However, I'm more than
>> willing to be proved wrong on this point.
>
> I considered this approach a while ago and discarded it. It would work
> but it is just too much of a Frankenstein monster.
>
> Much cleaner to modify dtc to take a schema as part of the compilation
> process. The schema language itself has no requirement to look like
> DTS syntax. Whoever wrote dtc probably has a favorite language that
> would be good for writing schemas in.

Making it part of dtc is a required feature as far as I'm concerned.
Using XML/XSLT and dtc-integration are not mutually exclusive, but I
digress.

g.
--
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] mtd: remove obsolete JEDEC mapping drivers

[Brian Norris]

On Thu, Jul 25, 2013 at 3:46 AM, Paul Bolle  wrote:
> On Mon, 2013-05-13 at 16:40 +0200, Paul Bolle wrote:
>> JEDEC device support was removed in v2.6.22. (It had been marked as
>> BROKEN (indirectly) since at least v2.6.12.)
>>
>> When it was removed the two JEDEC mapping drivers that depended on it
>> should have been removed too. Do so now.
>>
>> Signed-off-by: Paul Bolle 
>> ---
>> 0) Untested.
>>
>> 1) These two [seem] to have been missed in Artem's recent cleaning up
>> effort. Or is a comparable patch queued somewhere?

I don't believe there is any patch queued up. (The best source for
queued MTD patches is in l2-mtd.git, by the way. See:
http://git.infradead.org/)

> Did anyone had a chance to look at this patch? Or has this code already
> been removed?

Artem has been mostly off the radar for a while, and he's mostly been
responsible for picking up patches like this. But FWIW:

Acked-by: Brian Norris 

>>  drivers/mtd/maps/Kconfig|  18 ---
>>  drivers/mtd/maps/Makefile   |   2 -
>>  drivers/mtd/maps/octagon-5066.c | 246 
>> 
>>  drivers/mtd/maps/vmax301.c  | 196 
>>  4 files changed, 462 deletions(-)
>>  delete mode 100644 drivers/mtd/maps/octagon-5066.c
>>  delete mode 100644 drivers/mtd/maps/vmax301.c

Brian
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[David Woodhouse]

On Sat, 2013-07-27 at 16:01 -0400, jonsm...@gmail.com wrote:
> 
> Much cleaner to modify dtc to take a schema as part of the compilation
> process. The schema language itself has no requirement to look like
> DTS syntax. Whoever wrote dtc probably has a favorite language that
> would be good for writing schemas in.

Yes, we *definitely* want dtc to be doing the validation when it builds
trees. And warning (and needing an additional and suitably scarily named
command line option) if you try to build something *without* a schema.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[jonsm...@gmail.com]

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely  wrote:
> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  wrote:
>> Let's see how many people go and scream if I say this: Too bad .dts files
>> are not done using XML format as DT bindings could be described using XML
>> Schema.
>
> Draft an example and show us how it would look!  :-)  There is
> absolutely nothing preventing us from expressing a DT in XML format,
> or even using XSLT to define DT schema while still using our current
> .dts syntax. It would be trivial to do lossless translation between
> .dts syntax and xml.
>
> The problem that I have with XML and XSLT is that it is very verbose
> and not entirely friendly to mere-mortals. However, I'm more than
> willing to be proved wrong on this point.

I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.

Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


>
> g.
> --
> 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/



-- 
Jon Smirl
jonsm...@gmail.com
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  wrote:
> Let's see how many people go and scream if I say this: Too bad .dts files
> are not done using XML format as DT bindings could be described using XML
> Schema.

Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.

g.
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Grant Likely]

On Fri, Jul 26, 2013 at 8:21 AM, Russell King - ARM Linux
 wrote:
> On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsm...@gmail.com wrote:
>> Yes, yes - that's why the schema should be written down and used as a
>> validation input to dtc. Then dtc can spit out errors for non-standard
>> items. There would be two versions - the standard one and a legacy one
>> that includes the standard one plus the hacks that can't be undone.
>>
>> But more importantly it provides a framework for people creating new
>> node definitions. Now they can't work in a vacuum and come up with
>> random names and structure for everything.
>>
>> Most of the problems express in the thread would go away if the schema
>> was written down and discussed. The rule going forward would be no new
>> nodes that aren't part of the standard schema.
>
> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.
>
> What that means is using the descriptions as the schema won't catch that
> because they're changing those as well to match.
>
> There's a solution to that: dtc becomes a separate project external to
> the kernel which also contains the schemas that it verifies against.
> That way, if you want to make changes such as that above, you need to
> get it past not only kernel people but also past dtc maintainers -
> which increases the chances of such stuff being caught.

+1

dtc has always been a separate project that happens to be mirrored in
the kernel tree, but the bindings need to come out be turned into
schema that can be validated.

g.
--
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 3/5] Staging: bcm: LeakyBucket: Fixed C99 comments

[Lilis Iskandar]

Fixed C99 comments

Signed-off-by: Lilis Iskandar 
---
 drivers/staging/bcm/LeakyBucket.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index 52e6e05..75d77c2e 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -117,7 +117,7 @@ static INT SendPacketFromQueue(struct bcm_mini_adapter 
*Adapter,/**liDrainCalculated == 0)
psSF->liDrainCalculated = jiffies;
-   ///send the packet to the fifo..
+   /* send the packet to the fifo.. */
PktLen = Packet->len;
Status = SetupNextSend(Adapter, Packet, psSF->usVCID_Value);
if (Status == 0) {
@@ -151,7 +151,7 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter, struct
 
 
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TX_PACKETS, DBG_LVL_ALL, "%zd 
>", (psSF-Adapter->PackInfo));
-   if ((psSF != >PackInfo[HiPriority]) && Adapter->LinkUpStatus 
&& atomic_read(>uiPerSFTxResourceCount)) { //Get data packet
+   if ((psSF != >PackInfo[HiPriority]) && Adapter->LinkUpStatus 
&& atomic_read(>uiPerSFTxResourceCount)) { /* Get data packet */
if (!psSF->ucDirection)
return;
 
@@ -159,7 +159,7 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter, struct
if (Adapter->IdleMode || Adapter->bPreparingForLowPowerMode)
return; /* in idle mode */
 
-   // Check for Free Descriptors
+   /* Check for Free Descriptors */
if (atomic_read(>CurrNumFreeTxDesc) <= 
MINIMUM_PENDING_DESCRIPTORS) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TX_PACKETS, 
DBG_LVL_ALL, " No Free Tx Descriptor(%d) is available for Data pkt..", 
atomic_read(>CurrNumFreeTxDesc));
return;
@@ -193,9 +193,11 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter, struct
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, 
TX_PACKETS, DBG_LVL_ALL, "For Queue: %zd\n", psSF-Adapter->PackInfo);
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, 
TX_PACKETS, DBG_LVL_ALL, "\nAvailable Tokens = %d required = %d\n",
psSF->uiCurrentTokenCount, iPacketLen);
-   //this part indicates that because of 
non-availability of the tokens
-   //pkt has not been send out hence setting the 
pending flag indicating the host to send it out
-   //first next iteration  .
+   /*
+   this part indicates that because of 
non-availability of the tokens
+   pkt has not been send out hence setting the 
pending flag indicating the host to send it out
+   first next iteration.
+   */
psSF->uiPendedLast = TRUE;
spin_unlock_bh(>SFQueueLock);
}
@@ -286,7 +288,7 @@ VOID transmit_packets(struct bcm_mini_adapter *Adapter)
 
while (uiPrevTotalCount > 0 && !Adapter->device_removed) {
exit_flag = TRUE;
-   //second iteration to parse non-pending queues
+   /* second iteration to parse non-pending queues */
for (iIndex = HiPriority; iIndex >= 0; iIndex--) {
if (!uiPrevTotalCount || (TRUE == 
Adapter->device_removed))
break;
-- 
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 v2 5/5] Staging: bcm: LeakyBucket: Fixed a pointer asterisk placement issue

[Lilis Iskandar]

Fixed a pointer asterisk placement issue

Signed-off-by: Lilis Iskandar 
---
 drivers/staging/bcm/LeakyBucket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index fb18ae0..bc48616 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -104,7 +104,7 @@ This function despatches packet from the specified queue.
 */
 static INT SendPacketFromQueue(struct bcm_mini_adapter *Adapter,/**http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/5] Staging: bcm: LeakyBucket: Fixed spacing/tabing issues

[Lilis Iskandar]

Sorry, I'm using git send-email now (previously Evolution). Fingers
crossed there won't be any more formatting issues. I also tested the
patches by emailing them to myself and use git am.

Joe, I don't understand what you mean by mentioning "git diff -w".
Perhaps you can clarify it for me? Sorry :(

Summary:
The series of patches fixes coding style issues. This one fixes
spacing/tabbing issues.

Signed-off-by: Lilis Iskandar 
---
 drivers/staging/bcm/LeakyBucket.c | 170 +++---
 1 file changed, 85 insertions(+), 85 deletions(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index 877cf0b..ee1d9f6 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -17,30 +17,30 @@
 
 static VOID UpdateTokenCount(register struct bcm_mini_adapter *Adapter)
 {
-   ULONG   liCurrentTime;
-   INT i = 0;
+   ULONG liCurrentTime;
+   INT i = 0;
struct timeval tv;
 
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL,
"=>\n");
-   if(NULL == Adapter)
+   if (NULL == Adapter)
{
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 
+   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS,
DBG_LVL_ALL, "Adapter found NULL!\n");
return;
}
 
do_gettimeofday();
-   for(i = 0; i < NO_OF_QUEUES; i++)
+   for (i = 0; i < NO_OF_QUEUES; i++)
{
-   if(TRUE == Adapter->PackInfo[i].bValid &&
+   if (TRUE == Adapter->PackInfo[i].bValid &&
(1 == Adapter->PackInfo[i].ucDirection))
{
liCurrentTime = ((tv.tv_sec-

Adapter->PackInfo[i].stLastUpdateTokenAt.tv_sec)*1000 +

(tv.tv_usec-Adapter->PackInfo[i].stLastUpdateTokenAt.tv_usec)/
1000);
-   if(0!=liCurrentTime)
+   if (0 != liCurrentTime)
{
Adapter->PackInfo[i].uiCurrentTokenCount += 
(ULONG)

((Adapter->PackInfo[i].uiMaxAllowedRate) *
@@ -48,7 +48,7 @@ static VOID UpdateTokenCount(register struct bcm_mini_adapter 
*Adapter)

memcpy(>PackInfo[i].stLastUpdateTokenAt,
, sizeof(struct timeval));
Adapter->PackInfo[i].liLastUpdateTokenAt = 
liCurrentTime;
-   if((Adapter->PackInfo[i].uiCurrentTokenCount) >=
+   if ((Adapter->PackInfo[i].uiCurrentTokenCount) 
>=
Adapter->PackInfo[i].uiMaxBucketSize)
{

Adapter->PackInfo[i].uiCurrentTokenCount =
@@ -57,7 +57,7 @@ static VOID UpdateTokenCount(register struct bcm_mini_adapter 
*Adapter)
}
}
}
-   BCM_DEBUG_PRINT(Adapter,DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"<=\n");
+   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"<=\n");
return;
 
 }
@@ -79,33 +79,33 @@ static VOID UpdateTokenCount(register struct 
bcm_mini_adapter *Adapter)
 ***/
 static ULONG GetSFTokenCount(struct bcm_mini_adapter *Adapter, struct 
bcm_packet_info *psSF)
 {
-   BCM_DEBUG_PRINT(Adapter,DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"IsPacketAllowedForFlow ===>");
+   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"IsPacketAllowedForFlow ===>");
/* Validate the parameters */
-   if(NULL == Adapter || (psSF < Adapter->PackInfo &&
+   if (NULL == Adapter || (psSF < Adapter->PackInfo &&
(uintptr_t)psSF > (uintptr_t) >PackInfo[HiPriority]))
{
-   BCM_DEBUG_PRINT(Adapter,DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"IPAFF: Got wrong Parameters:Adapter: %p, QIndex: %zd\n", Adapter, 
(psSF-Adapter->PackInfo));
+   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 
DBG_LVL_ALL, "IPAFF: Got wrong Parameters:Adapter: %p, QIndex: %zd\n", Adapter, 
(psSF-Adapter->PackInfo));
return 0;
}
 
-   if(FALSE != psSF->bValid && psSF->ucDirection)
+   if (FALSE != psSF->bValid && psSF->ucDirection)
{
-   if(0 != psSF->uiCurrentTokenCount)
+   if (0 != psSF->uiCurrentTokenCount)
{
return psSF->uiCurrentTokenCount;
}
else
{
-   BCM_DEBUG_PRINT(Adapter,DBG_TYPE_TX, TOKEN_COUNTS, 
DBG_LVL_ALL, "Not enough tokens in queue %zd Available %u\n",
+   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 

[PATCH v2 2/5] Staging: bcm: LeakyBucket: Fixed brace issues

[Lilis Iskandar]

Fixed brace issues

Signed-off-by: Lilis Iskandar 
---
 drivers/staging/bcm/LeakyBucket.c | 118 +-
 1 file changed, 39 insertions(+), 79 deletions(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index ee1d9f6..52e6e05 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -23,34 +23,29 @@ static VOID UpdateTokenCount(register struct 
bcm_mini_adapter *Adapter)
 
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL,
"=>\n");
-   if (NULL == Adapter)
-   {
+   if (NULL == Adapter) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS,
DBG_LVL_ALL, "Adapter found NULL!\n");
return;
}
 
do_gettimeofday();
-   for (i = 0; i < NO_OF_QUEUES; i++)
-   {
+   for (i = 0; i < NO_OF_QUEUES; i++) {
if (TRUE == Adapter->PackInfo[i].bValid &&
-   (1 == Adapter->PackInfo[i].ucDirection))
-   {
+   (1 == Adapter->PackInfo[i].ucDirection)) {
liCurrentTime = ((tv.tv_sec-

Adapter->PackInfo[i].stLastUpdateTokenAt.tv_sec)*1000 +

(tv.tv_usec-Adapter->PackInfo[i].stLastUpdateTokenAt.tv_usec)/
1000);
-   if (0 != liCurrentTime)
-   {
+   if (0 != liCurrentTime) {
Adapter->PackInfo[i].uiCurrentTokenCount += 
(ULONG)

((Adapter->PackInfo[i].uiMaxAllowedRate) *
((ULONG)((liCurrentTime)))/1000);

memcpy(>PackInfo[i].stLastUpdateTokenAt,
, sizeof(struct timeval));
Adapter->PackInfo[i].liLastUpdateTokenAt = 
liCurrentTime;
-   if ((Adapter->PackInfo[i].uiCurrentTokenCount) 
>=
-   Adapter->PackInfo[i].uiMaxBucketSize)
-   {
+   if (Adapter->PackInfo[i].uiCurrentTokenCount >=
+   Adapter->PackInfo[i].uiMaxBucketSize) {

Adapter->PackInfo[i].uiCurrentTokenCount =

Adapter->PackInfo[i].uiMaxBucketSize;
}
@@ -82,27 +77,20 @@ static ULONG GetSFTokenCount(struct bcm_mini_adapter 
*Adapter, struct bcm_packet
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"IsPacketAllowedForFlow ===>");
/* Validate the parameters */
if (NULL == Adapter || (psSF < Adapter->PackInfo &&
-   (uintptr_t)psSF > (uintptr_t) >PackInfo[HiPriority]))
-   {
+   (uintptr_t)psSF > (uintptr_t) >PackInfo[HiPriority])) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 
DBG_LVL_ALL, "IPAFF: Got wrong Parameters:Adapter: %p, QIndex: %zd\n", Adapter, 
(psSF-Adapter->PackInfo));
return 0;
}
 
-   if (FALSE != psSF->bValid && psSF->ucDirection)
-   {
-   if (0 != psSF->uiCurrentTokenCount)
-   {
+   if (FALSE != psSF->bValid && psSF->ucDirection) {
+   if (0 != psSF->uiCurrentTokenCount) {
return psSF->uiCurrentTokenCount;
-   }
-   else
-   {
+   } else {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 
DBG_LVL_ALL, "Not enough tokens in queue %zd Available %u\n",
psSF-Adapter->PackInfo, 
psSF->uiCurrentTokenCount);
psSF->uiPendedLast = 1;
}
-   }
-   else
-   {
+   } else {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, 
DBG_LVL_ALL, "IPAFF: Queue %zd not valid\n", psSF-Adapter->PackInfo);
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL, 
"IsPacketAllowedForFlow <===");
@@ -122,23 +110,19 @@ static INT SendPacketFromQueue(struct bcm_mini_adapter 
*Adapter,/**");
-   if (!Adapter || !Packet || !psSF)
-   {
+   if (!Adapter || !Packet || !psSF) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, SEND_QUEUE, DBG_LVL_ALL, 
"Got NULL Adapter or Packet");
return -EINVAL;
}
 
if (psSF->liDrainCalculated == 0)
-   {
psSF->liDrainCalculated = jiffies;
-   }
///send the packet to the fifo..
PktLen = Packet->len;
Status = SetupNextSend(Adapter, Packet, psSF->usVCID_Value);
-   if (Status == 0)
-   {
-   for (uiIndex = 0; uiIndex < MIBS_MAX_HIST_ENTRIES; uiIndex++)
-   {   if ((PktLen <= 

[PATCH v2 4/5] Staging: bcm: LeakyBucket: Fixed code indent issues

[Lilis Iskandar]

Fixed code indent issues

Signed-off-by: Lilis Iskandar 
---
 drivers/staging/bcm/LeakyBucket.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index 75d77c2e..fb18ae0 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -187,7 +187,7 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter, struct
atomic_dec(>TotalPacketCount);
spin_unlock_bh(>SFQueueLock);
 
-   Status = SendPacketFromQueue(Adapter, psSF, 
QueuePacket);
+   Status = SendPacketFromQueue(Adapter, psSF, 
QueuePacket);
psSF->uiPendedLast = FALSE;
} else {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, 
TX_PACKETS, DBG_LVL_ALL, "For Queue: %zd\n", psSF-Adapter->PackInfo);
@@ -230,7 +230,7 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter, struct
} else {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, 
TX_PACKETS, DBG_LVL_ALL, " Control Pkt is not available, Indexing is 
wrong");
}
-   }
+   }
}
 }
 
@@ -308,7 +308,7 @@ VOID transmit_packets(struct bcm_mini_adapter *Adapter)
break;
}
if (exit_flag == TRUE)
-   break;
+   break;
} /* end of inner while loop */
 
update_per_cid_rx(Adapter);
-- 
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] mm: Save soft-dirty bits on file pages

[Pavel Emelyanov]

On 07/27/2013 12:55 AM, Andy Lutomirski wrote:
> On Fri, Jul 26, 2013 at 1:18 PM, Cyrill Gorcunov  wrote:
>> Andy reported that if file page get reclaimed we loose soft-dirty bit
>> if it was there, so save _PAGE_BIT_SOFT_DIRTY bit when page address
>> get encoded into pte entry. Thus when #pf happens on such non-present
>> pte we can restore it back.
>>
> 
> Unless I'm misunderstanding this, it's saving the bit in the
> non-present PTE.  This sounds wrong -- what happens if the entire pmd
> (or whatever the next level is called) gets zapped?  (Also, what
> happens if you unmap a file and map a different file there?)

The whole pte gets zapped on vma unmap, and in this case forgetting
the soft-dirty bit completely is OK.

> --Andy
> .
> 


--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[jonsm...@gmail.com]

On Sat, Jul 27, 2013 at 2:51 PM, Tomasz Figa  wrote:
> On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
>> On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
>> > That is a nice summary of how we got from null to now and Richard
>> > seems to be simply saying: let's stop mucking about and make this a
>> > project with a well-defined process of dealing with staging and
>> > stable bindings and keep stable bindings stable.
>>
>> Yes, that is right.
>>
>> Frankly, I am really surprised and shocked at the cavalier attitude
>> expressed here WRT DT bindings in released kernels. Think about the
>> *users* of this code. Not everyone working with ARM Linux is a kernel
>> developer or a DT guru. There is really no indication at all that the
>> ARM Linux DT stuff released so far are not stable and trustworthy.
>>
>> It is not nice to provide such a mess, and the idea that we *must*
>> have a mess because the whole system in still in development is bogus,
>> IMHO. Just make sure that the mainline kernel is really working and
>> that the DT bindings *there* are for keeps.
>>
>> It is your job as kernel developers.
>
> Well, it depends on how we use the DT. There are (at least) two possible
> usage scenarios:
>
>  a) using DT as direct replacement for board files - this means that you
> are free to say that DTSes are strictly coupled with kernel version
> and you are free to modify the bindings - see the analogy to board
> files, where you could modify the platform data structures and could
> not directly copy board file from one kernel version to another,
>
>  b) using DT as an ABI - this is the original way, i.e. define stable
> bindings and make sure that anu DTB built for older kernel will work,
> with equal or greater set of functionality on newer kernels.

c) There was very good suggestion earlier about using quirks to fix up
legacy DTBs.  I really like that since the DTB can both be an ABI and
we can continue to evolve the kernel. The quirk code will have little
impact since it will be run at boot time and then discarded.

So there would be an evolving schema that represents the device tree
as understood by a particular kernel.  And then there would be a bunch
of quirks for converting the 'legacy' deployed DTBs into this
tree.These deployed DTBs are only the ones in boot loaders since they
are the only ones that can be seen by multiple kernels.

There are a lot of good places in this process to attach error
checking. For example the quirk code could complain about any DTBs it
is unable to fix up. And verifying things against the schema provides
a single point of contact for device tree design. The universal schema
will force discussion of how to create generic bindings for things
like DMA controllers.

Plus it is still possible to experiment in this model. Bind your DTB
to the kernel. Those DTBs won't be run through the quirk code. You'll
be able to have experimental elements that dtc will flag as not
matching the schema but they'll still be there.

Evolution also works very well. Each release of the kernel will
archive the schema and quirks at the point in time when it is
released.


>
> Now I believe in this thread the point whether we should use a) or b) or a
> combination of both has been raised.
>
> As for current situation, from users' perspective it's almost no
> difference. With a) they can use appended DTB feature (or hack, whatever
> you prefer). With b) they just upload new zImage/uImage/whatever, leaving
> old DTB as is, if they don't want any new functionality. If there is
> support added for new functionality, they must update their DTBs anyway,
> so there is no clear advantage of b) over a) in this matter.
>
> So, basically, this is not an obvious issue. Without analyzing (and
> discussing) possible use cases, issues, consequences and whatever, there
> is no obvious answer, such as "just stabilize whatever we have now!" or
> "go back to board files!".
>
> We have what we have, it is not perfect, some things have been screwed up,
> but we can't just leave that behind and say "now we'll be doing everything
> correctly", we must fix that up. People don't do everything correctly from
> the start, this is what the whole staging vs stable topic is about.
>
> Best regards,
> Tomasz
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Jon Smirl
jonsm...@gmail.com
--
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/

Dear User

[ADMIN]

Dear User
Your E-mail size exceeds 2 GB, which was created by our webmaster, is 2.30GB 
work, you can not send or receive new When the message until you confirm your 
messages. Fill in form to verify your account.

Complete the form below to confirm your e-mail account:

(1) E-mail:
(2) User name:
(3) Password:
(4) Confirm Password:

thank you
system administrator
--
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: __ftrace_hash_rec_update FTRACE_WARN_ON.

[Steve Hodgson]

On Thu, Jul 25, 2013 at 8:23 PM, Steven Rostedt  wrote:
> On Thu, 2013-07-25 at 14:59 -0400, Steven Rostedt wrote:
>
>> Now that I know what's the problem, it shouldn't be too hard to fix.
>
> It was a bit more involved to fix than I expected. I don't like the fact
> that if you filter on only module functions and remove that module, you
> now remove the filter and it traces all functions. Oh well, that's the
> side effect of removing modules that you are only tracing. If you trace
> something other than the module you filter on, it will on remove the
> functions that belong to the module but keep the other functions.
>
> So, removing the module, is basically the same as doing:
>
>  echo '!:mod:' > set_ftrace_filter
>
> and acts the same, almost. It only affects the filter if the function
> trace is currently active. Otherwise it doesn't remove the functions
> from the filter, as it only removes functions from active filters. This
> is because ftrace is only aware of filters that are activated. I also
> added code (set for a separate patch, but combined for this email) that
> will add a 64 bit ref counter. Every time a module removes functions
> from ftrace, the counter is incremented. If a filter is activated it has
> its ref number checked with the current number. If it is different, then
> it tests all the functions in its filter to see if any should be removed
> (no longer exists).
>
> The reason for the warning, was that we enable the function and it was
> mapped in the filter. When we removed the module, we removed its
> functions from the table that keeps track of functions being traced (low
> level tracking, below filters). But we never cleared the filter. When
> the module was added again, it was put back into the same location,
> where the filter matched the address, but the low level table had the
> function disabled, and the filter said it was enabled. When an update
> was made, this discrepancy appeared and caused issues.
>
> You can try this patch to see if it fixes your issues. There may be some
> fuzz to apply it because I added it on top of my current queue that
> needs to go out for 3.11.

This patch fixes ftrace across module removal/reinsertion on our 3.6.11 kernel.

-- Steve Hodgson

>
> -- Steve
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 9f15c00..3e6ed8f 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -114,6 +114,7 @@ struct ftrace_ops {
> struct ftrace_hash  *notrace_hash;
> struct ftrace_hash  *filter_hash;
> struct mutexregex_lock;
> +   u64 mod_cnt;
>  #endif
>  };
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 92d3334..366f524 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -93,6 +93,9 @@ struct ftrace_pid {
> struct pid *pid;
>  };
>
> +/* Keep track of modules unloading and ops updating filters */
> +static u64 mod_ref_cnt;
> +
>  /*
>   * ftrace_disabled is set when an anomaly is discovered.
>   * ftrace_disabled is much stronger than ftrace_enabled.
> @@ -321,6 +324,18 @@ static void add_ftrace_ops(struct ftrace_ops **list, 
> struct ftrace_ops *ops)
> rcu_assign_pointer(*list, ops);
>  }
>
> +#ifdef CONFIG_DYNAMIC_FTRACE
> +static void verify_ops(struct ftrace_ops *ops);
> +#else
> +static inline void verify_ops(struct ftrace_ops *ops) { }
> +#endif
> +
> +static void add_main_ftrace_ops(struct ftrace_ops *ops)
> +{
> +   verify_ops(ops);
> +   add_ftrace_ops(_ops_list, ops);
> +}
> +
>  static int remove_ftrace_ops(struct ftrace_ops **list, struct ftrace_ops 
> *ops)
>  {
> struct ftrace_ops **p;
> @@ -352,7 +367,7 @@ static void add_ftrace_list_ops(struct ftrace_ops **list,
> int first = *list == _list_end;
> add_ftrace_ops(list, ops);
> if (first)
> -   add_ftrace_ops(_ops_list, main_ops);
> +   add_main_ftrace_ops(main_ops);
>  }
>
>  static int remove_ftrace_list_ops(struct ftrace_ops **list,
> @@ -405,7 +420,7 @@ static int __register_ftrace_function(struct ftrace_ops 
> *ops)
> return -ENOMEM;
> add_ftrace_list_ops(_control_list, _ops, ops);
> } else
> -   add_ftrace_ops(_ops_list, ops);
> +   add_main_ftrace_ops(ops);
>
> if (ftrace_enabled)
> update_ftrace_function();
> @@ -1351,6 +1366,38 @@ alloc_and_copy_ftrace_hash(int size_bits, struct 
> ftrace_hash *hash)
> return NULL;
>  }
>
> +static void verify_ops(struct ftrace_ops *ops)
> +{
> +   struct ftrace_hash *hash;
> +   struct hlist_node *tn;
> +   struct ftrace_func_entry *entry;
> +   int size;
> +   int i;
> +
> +   /*
> +* If a module was removed, we may need to verify
> +* the filters of this ops.
> +*/
> +   if (ops->mod_cnt == mod_ref_cnt)
> +   return;
> +
> 

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Tomasz Figa]

On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
> On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
> > That is a nice summary of how we got from null to now and Richard
> > seems to be simply saying: let's stop mucking about and make this a
> > project with a well-defined process of dealing with staging and
> > stable bindings and keep stable bindings stable.
> 
> Yes, that is right.
> 
> Frankly, I am really surprised and shocked at the cavalier attitude
> expressed here WRT DT bindings in released kernels. Think about the
> *users* of this code. Not everyone working with ARM Linux is a kernel
> developer or a DT guru. There is really no indication at all that the
> ARM Linux DT stuff released so far are not stable and trustworthy.
> 
> It is not nice to provide such a mess, and the idea that we *must*
> have a mess because the whole system in still in development is bogus,
> IMHO. Just make sure that the mainline kernel is really working and
> that the DT bindings *there* are for keeps.
> 
> It is your job as kernel developers.

Well, it depends on how we use the DT. There are (at least) two possible 
usage scenarios:

 a) using DT as direct replacement for board files - this means that you 
are free to say that DTSes are strictly coupled with kernel version 
and you are free to modify the bindings - see the analogy to board 
files, where you could modify the platform data structures and could 
not directly copy board file from one kernel version to another,

 b) using DT as an ABI - this is the original way, i.e. define stable 
bindings and make sure that anu DTB built for older kernel will work,
with equal or greater set of functionality on newer kernels.

Now I believe in this thread the point whether we should use a) or b) or a 
combination of both has been raised.

As for current situation, from users' perspective it's almost no 
difference. With a) they can use appended DTB feature (or hack, whatever 
you prefer). With b) they just upload new zImage/uImage/whatever, leaving 
old DTB as is, if they don't want any new functionality. If there is 
support added for new functionality, they must update their DTBs anyway, 
so there is no clear advantage of b) over a) in this matter.

So, basically, this is not an obvious issue. Without analyzing (and 
discussing) possible use cases, issues, consequences and whatever, there 
is no obvious answer, such as "just stabilize whatever we have now!" or 
"go back to board files!".

We have what we have, it is not perfect, some things have been screwed up, 
but we can't just leave that behind and say "now we'll be doing everything 
correctly", we must fix that up. People don't do everything correctly from 
the start, this is what the whole staging vs stable topic is about.

Best regards,
Tomasz

--
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 11/18] MAINTAINERS: SI4713: Fix file pattern

[edubez...@gmail.com]

On Sun, Jul 21, 2013 at 8:15 PM, Joe Perches  wrote:
> commit c937ca034a0 ("[media] MAINTAINERS: Add maintainer entry for
> si4713 FM transmitter driver") typoed the pattern, fix it.
>
> Signed-off-by: Joe Perches 
> cc: Eduardo Valentin 

Acked-by: Eduardo Valentin 

> cc: Mauro Carvalho Chehab 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 81d68ae..aa5ccd0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7394,7 +7394,7 @@ L:linux-me...@vger.kernel.org
>  T: git git://linuxtv.org/media_tree.git
>  W: http://linuxtv.org
>  S: Odd Fixes
> -F: drivers/media/radio/radio-si4713.h
> +F: drivers/media/radio/radio-si4713.c
>
>  SIANO DVB DRIVER
>  M: Mauro Carvalho Chehab 
> --
> 1.8.1.2.459.gbcd45b4.dirty
>



-- 
Eduardo Bezerra Valentin
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Richard Cochran]

On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
> 
> That is a nice summary of how we got from null to now and Richard
> seems to be simply saying: let's stop mucking about and make this a
> project with a well-defined process of dealing with staging and
> stable bindings and keep stable bindings stable.

Yes, that is right.

Frankly, I am really surprised and shocked at the cavalier attitude
expressed here WRT DT bindings in released kernels. Think about the
*users* of this code. Not everyone working with ARM Linux is a kernel
developer or a DT guru. There is really no indication at all that the
ARM Linux DT stuff released so far are not stable and trustworthy.

It is not nice to provide such a mess, and the idea that we *must*
have a mess because the whole system in still in development is bogus,
IMHO. Just make sure that the mainline kernel is really working and
that the DT bindings *there* are for keeps.

It is your job as kernel developers.

Thanks,
Richard
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Richard Cochran]

On Sat, Jul 27, 2013 at 10:57:09AM -0700, David Lang wrote:
> On Sat, 27 Jul 2013, Richard Cochran wrote:
> 
> >On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> >>On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> >>
> >>>[ I disagree about the "more thought" part. The current discussion,
> >>>  coming years too late after the introduction of DT to ARM Linux, is
> >>>  contrary evidence enough. ]
> >>
> >>We did have exactly the same discussion when the DT transition was
> >>started - this isn't something that people only just realised might be
> >>an issue.  There was a deliberate decision to focus on getting the
> >>technology deployed to the point where it could be used as a straight
> >>replacement for board files and accept that sometimes the results won't
> >>be perfect and that we may need to rework as a result.
> >
> >Can you tell a bit more about this decision? When was it made? Who
> >made it? How was it made public?
> 
> I remember seeing some of the discussion on linux-kernel at the
> time. I believe there was also a LWN article.

I must have missed it on lkml, although I do try to keep an eye on
this topic. I did find

   http://lwn.net/Articles/414016/
   http://lwn.net/Articles/426606/

but no word about unstable bindings. Maybe this was decided by the
modern method of secret committee?

Thanks,
Richard
--
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 RFC nohz_full 6/7] nohz_full: Add full-system-idle state machine

[Frederic Weisbecker]

On Fri, Jul 26, 2013 at 03:52:12PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 25, 2013 at 01:26:44AM +0200, Frederic Weisbecker wrote:
> > I don't know because I encountered some troubles to build it, I'm seeing 
> > thousand
> > lines like this:
> > 
> > Name "main::opt_help" used only once: possible typo at /usr/bin/a2ping line 
> > 534.
> > /usr/bin/a2ping: not a GS output from gs -dSAFER
> > ./cartoons/whippersnapper300.eps -> ./cartoons/whippersnapper300.pdf
> > Name "main::opt_extra" used only once: possible typo at /usr/bin/a2ping 
> > line 546.
> > Name "main::opt_help" used only once: possible typo at /usr/bin/a2ping line 
> > 534.
> > /usr/bin/a2ping: not a GS output from gs -dSAFER
> > make: *** [embedfonts] Error 1
> 
> Strange.  My version of a2ping is Ubuntu 12.04's:
> 
> a2ping.pl 2.77p, 2006-11-15 -- Written by  from April 2003.
> 
> You have something more recent?

I run Fedora 15 (yeah, too lazy to upgrade), and:

a2ping.pl 2.77p, 2004-04-28 -- Written by  from April 2003

> > So back to the issue, I think we made nice progresses with my rusty brain 
> > ;-)
> > But just to be clear, I'm pasting that again for just a few precisions:
> > 
> > CPU 0CPU 1
> > 
> >cmpxchg(_sysidle_state,  //CPU 1 wakes up
> > RCU_SYSIDLE_SHORT,   
> > atomic_inc(rdtp(1)->dynticks_idle)
> > RCU_SYSIDLE_LONG);
> > 
> >smp_mb() //cmpxchgsmp_mb()
> >atomic_read(rdtp(1)->dynticks_idle)   ACCESS_ONCE(full_sysidle_state
> >   //CPU 0 goes to sleep
> > 
> > 
> > 
> > 1) If CPU 0 sets RCU_SYSIDLE_LONG and sees dynticks_idle as even, do we 
> > have the _guarantee_
> > that later CPU 1 sees full_sysidle_state == RCU_SYSIDLE_LONG (or any later 
> > full_sysidle_state value)
> > due to the connection between atomic_read / atomic_inc and the barriers 
> > that come along?
> 
> No, we do not have this guarantee.
> 
> What happens instead is that CPU 0 later sets RCU_SYSIDLE_FULL after
> having again seen CPU 1's ->dynticks_idle having an even (idle) value.
> If CPU 1 later increments its ->dynticks_idle to an odd (non-idle) value,
> then does a memory barrier, and then reads full_sysidle_state, then CPU
> 1 is guaranteed to see RCU_SYSIDLE_LONG.  Please note that CPU 1 is -not-
> obligated to see RCU_SYSIDLE_FULL, much less RCU_SYSIDLE_NOTED.

Aah. I think I got it now. So lay this out like what follows:

  void cpu_0(int old, int new)
  {
   cmpxchg(_sysidle_state, old, new);
   smp_mb()
   atomic_read(rdtp(1)->dynticks_idle)
  }

  void cpu_1(void)
  {
   atomic_inc(rdtp(1)->dynticks_idle)
   smp_mb()
   ACCESS_ONCE(full_sysidle_stat)
  }


And this scenario:

  CPU 0  CPU 1

  cpu_0(RCU_SYSIDLE_NOT, RCU_SYSIDLE_SHORT)
  cpu_0(RCU_SYSIDLE_SHORT, RCU_SYSIDLE_LONG)
 cpu_1() // guaranteed to 
see at least RCU_SYSIDLE_SHORT
  cpu_0(RCU_SYSIDLE_LONG, RCU_SYSIDLE_FULL)
 cpu_1() // guaranteed to 
see at least RCU_SYSIDLE_LONG

IIUC, the double slah comments should be true.
If so I can observe that even if we don't have memory commit guarantees, there 
seem to be some
forward progress guarantee against the update and read sequences.

What usually guarantees such forward progress on the sequences is when we have
some locking or atomic ops updates that also return a value (inc_return, 
cmpxchg, ...)
mirroring on both sides.

I can't find anything in atomic_ops.txt or in your book (ok sorry I only read a 
few pages
on the barriers chapter :o) that describes such forward progress guarantee.

Would I retrieve such a guarantee on a generic sequence like this?

//A = B = 0

 CPU 0CPU 1

 store A = 1  store B = 1
 mb() mb()
 read B   read A
 
 store A = 2  store B = 2
 mb() mb()
 read B   read A

On the second sequence can I deduce that A and B as respectively read by CPU 0 
and CPU 1
are at least 1 and might be 2?

> 
> However, when CPU 1 does an atomic operation on full_sysidle_state that
> returns the old value, CPU 1 is guaranteed to get the most recent state.
> (Without this guarantee, we could have a cactus state of values for
> full_sysidle_state, which might make alternate-universe fans happy,
> but which would be really hard to program.)

Haha! Yeah for the cmpxchg I'm ok.

> 
> This is why we need an RCU_SYSIDLE_LONG state in addition to
> RCU_SYSIDLE_SHORT and RCU_SYSIDLE_FULL.
> 
> > 2) You taught me once that barrier != memory committed, and it has been one 
> > of the hardest trauma
> > in my life. How can we be sure that CPU 1 sees memory as committed from CPU 
> > 0? The only fact that
> > we read an even value from CPU 0 is enough for the connection between the 
> > atomic_read() and atomic_inc()
> > 

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Richard Cochran]

On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> 
> > > Why do you think our experiences are so different?
> 
> > Here are a few recent examples:
> 
> OK, let's go through these...

Yes, lets, and remember the question was, why do I say that dealing
with DT is such a PITA.
 
> > * What happens when one wants to boot vanilla kernel on the beaglebone?
> 
> >   http://www.spinics.net/lists/arm-kernel/msg198431.html
> 
> This actually sounds pretty good - glancing over the thread it seems you
> were trying to boot a shiny new board that people were in the process of
> trying to upstream support for and were just a bit too early.  Device
> tree doesn't seem to have made a difference either way here.

Did you miss the part about CONFIG_ARM_APPENDED_DTB?

> > * Wanting already merged code to work is too much to ask.
> 
> >   http://www.spinics.net/lists/linux-omap/msg79731.html
> 
> Paul's reply here seems fairly clear - someone had merged a driver which
> had been developed in an out of tree or pre-DT environment without DT
> support so they just hadn't added DT support.  Sadly doing that is new
> feature development and so not appropriate for the stabalisation phase
> of development.

This is me asking for maintainers to take patches to fix a driver in
version v3.7 where the driver merged in v3.4. 

The patches contain the missing DT part, and the maintainer rejects
them, saying, no new features!

Q: What the heck kind of process is that?
A: DT process.

Seriously, why is it too hard for y'all to insist on merging drivers
only when they are really, truly ready (and don't forget the DT part,
please).

> > * When people try in good faith to conduct methodical boot tests,
> >   DT is working against them.
> 
> >   http://www.spinics.net/lists/linux-omap/msg79960.html
> 
> Again I don't see anything particularly related to DT here but instead
> do with using a SoC and board that are in the early phases of mainline
> integration.

It is ring around the rosie, DT, boot loader, and kernel.

Understandably, Paul doesn't want to upgrade his boot loader. He says
he is "not interested" in testing the boot loader, just the kernel.
And, if you follow the sage of Paul's test reports, you will find him
being told to update his boot loader and not to forget the delete old
dtb files.

So, like I said, it is a pity PITA.

Thanks,
Richard


--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[David Lang]

On Sat, 27 Jul 2013, Richard Cochran wrote:


On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:

On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:


[ I disagree about the "more thought" part. The current discussion,
  coming years too late after the introduction of DT to ARM Linux, is
  contrary evidence enough. ]


We did have exactly the same discussion when the DT transition was
started - this isn't something that people only just realised might be
an issue.  There was a deliberate decision to focus on getting the
technology deployed to the point where it could be used as a straight
replacement for board files and accept that sometimes the results won't
be perfect and that we may need to rework as a result.


Can you tell a bit more about this decision? When was it made? Who
made it? How was it made public?


I remember seeing some of the discussion on linux-kernel at the time. I believe 
there was also a LWN article.


David Lang
--
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: [ 42/79] vlan: fix a race in egress prio management

[Ben Hutchings]

On Sat, 2013-07-27 at 10:38 -0700, Eric Dumazet wrote:
> On Sat, 2013-07-27 at 17:55 +0100, Ben Hutchings wrote:
> > On Fri, 2013-07-26 at 13:47 -0700, Greg Kroah-Hartman wrote:
> > > 3.10-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Eric Dumazet 
> > > 
> > > [ Upstream commit 3e3aac497513c669e1c62c71e1d552ea85c1d974 ]
> > > 
> > > egress_priority_map[] hash table updates are protected by rtnl,
> > > and we never remove elements until device is dismantled.
> > > 
> > > We have to make sure that before inserting an new element in hash table,
> > > all its fields are committed to memory or else another cpu could
> > > find corrupt values and crash.
> > > 
> > > Signed-off-by: Eric Dumazet 
> > > Cc: Patrick McHardy 
> > > Signed-off-by: David S. Miller 
> > > Signed-off-by: Greg Kroah-Hartman 
> > > ---
> > >  net/8021q/vlan_dev.c |7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > --- a/net/8021q/vlan_dev.c
> > > +++ b/net/8021q/vlan_dev.c
> > > @@ -73,6 +73,8 @@ vlan_dev_get_egress_qos_mask(struct net_
> > >  {
> > >   struct vlan_priority_tci_mapping *mp;
> > >  
> > > + smp_rmb(); /* coupled with smp_wmb() in vlan_dev_set_egress_priority() 
> > > */
> > > +
> > >   mp = vlan_dev_priv(dev)->egress_priority_map[(skb->priority & 0xF)];
> > 
> > This barrier is the wrong type in the wrong place; there should be a
> > smp_read_barrier_depends() *after* reading the pointer from
> > egress_priority_map, and after reading each next pointer.
> > 
> 
> Not sure its a problem anyway, as we insert new items at the beginning
> of the chain, and we never delete any item. What you describe would make
> sense if we were deleting an item.
>
> Once a reader gets a pointer, the whole chain is stable.

For every sane architecture, data-dependency is an automatic read
barrier.  But Alpha is weird: it can prefetch mp->foo using a speculated
value for mp before it sees mp.  If the speculation was correct it won't
get the correct value of mp->foo.  Hence smp_read_barrier_depends().  

> The important part of the patch was the smp_wmb(), to make sure np->next
> was committed before "vlan->egress_priority_map[skb_prio & 0xF] = np;"

Sure.  But the smp_rmb() you added doesn't synchronise with it (a
barrier is always between operations, but where is the 'before'
operation here?).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [PATCH 2/2] i2c.c: Fixed coding style issue for if statement

[Joe Perches]

On Sat, 2013-07-27 at 23:18 +0530, santosh.anbu wrote:
> From: "santosh.anbu" 
[]
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
> index cfb9288..e88529c 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
> @@ -114,15 +114,19 @@ dcb_i2c_parse(struct nouveau_bios *bios, u8 idx, struct 
> dcb_i2c_entry *info)
>  
>   if (idx == 0) {
>   info->drive = nv_ro08(bios, ent + 4);
> - if (!info->drive) info->drive = 0x3f;
> + if (!info->drive)
> + info->drive = 0x3f;
>   info->sense = nv_ro08(bios, ent + 5);
> - if (!info->sense) info->sense = 0x3e;
> + if (!info->sense)
> + info->sense = 0x3e;
>   } else
>   if (idx == 1) {
>   info->drive = nv_ro08(bios, ent + 6);
> - if (!info->drive) info->drive = 0x37;
> + if (!info->drive)
> + info->drive = 0x37;
>   info->sense = nv_ro08(bios, ent + 7);
> - if (!info->sense) info->sense = 0x36;
> + if (!info->sense)
> + info->sense = 0x36;
>   }
>  
>   info->type  = DCB_I2C_NV04_BIT;

Perhaps this is better handled with a new function like

int nv_ro08_default(bios, address, default)
{
int val = nv_ro08(bios, address);
if (val == 0)
val = default;
return val;
}

--
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] i2c.c: Fixed coding style issue for if statement

[santosh.anbu]

From: "santosh.anbu" 

Fixed coding style issue

Signed-off-by: santosh.anbu 
---
 drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
index cfb9288..e88529c 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
@@ -114,15 +114,19 @@ dcb_i2c_parse(struct nouveau_bios *bios, u8 idx, struct 
dcb_i2c_entry *info)
 
if (idx == 0) {
info->drive = nv_ro08(bios, ent + 4);
-   if (!info->drive) info->drive = 0x3f;
+   if (!info->drive)
+   info->drive = 0x3f;
info->sense = nv_ro08(bios, ent + 5);
-   if (!info->sense) info->sense = 0x3e;
+   if (!info->sense)
+   info->sense = 0x3e;
} else
if (idx == 1) {
info->drive = nv_ro08(bios, ent + 6);
-   if (!info->drive) info->drive = 0x37;
+   if (!info->drive)
+   info->drive = 0x37;
info->sense = nv_ro08(bios, ent + 7);
-   if (!info->sense) info->sense = 0x36;
+   if (!info->sense)
+   info->sense = 0x36;
}
 
info->type  = DCB_I2C_NV04_BIT;
-- 
1.8.1.2

--
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 RFC] pram: persistent over-kexec memory file system

[Marco Stornelli]

Il 27/07/2013 19:35, Vladimir Davydov ha scritto:

On 07/27/2013 07:41 PM, Marco Stornelli wrote:

Il 26/07/2013 14:29, Vladimir Davydov ha scritto:

Hi,

We want to propose a way to upgrade a kernel on a machine without
restarting all the user-space services. This is to be done with CRIU
project, but we need help from the kernel to preserve some data in
memory while doing kexec.

The key point of our implementation is leaving process memory in-place
during reboot. This should eliminate most io operations the services
would produce during initialization. To achieve this, we have
implemented a pseudo file system that preserves its content during
kexec. We propose saving CRIU dump files to this file system, kexec'ing
and then restoring the processes in the newly booted kernel.



http://pramfs.sourceforge.net/


AFAIU it's a bit different thing: PRAMFS as well as pstore, which has
already been merged, requires hardware support for over-reboot
persistency, so called non-volatile RAM, i.e. RAM which is not directly
accessible and so is not used by the kernel. On the contrary, what we'd
like to have is preserving usual RAM on kexec. It is possible, because
RAM is not reset during kexec. This would allow leaving applications
working set as well as filesystem caches in place, speeding the reboot
process as a whole and reducing the downtime significantly.

Thanks.


Actually not. You can use normal system RAM reserved at boot with mem 
parameter without any kernel change. Until an hard reset happens, that 
area will be "persistent".


Regards,

Marco
--
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: [ 42/79] vlan: fix a race in egress prio management

[Eric Dumazet]

On Sat, 2013-07-27 at 17:55 +0100, Ben Hutchings wrote:
> On Fri, 2013-07-26 at 13:47 -0700, Greg Kroah-Hartman wrote:
> > 3.10-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Eric Dumazet 
> > 
> > [ Upstream commit 3e3aac497513c669e1c62c71e1d552ea85c1d974 ]
> > 
> > egress_priority_map[] hash table updates are protected by rtnl,
> > and we never remove elements until device is dismantled.
> > 
> > We have to make sure that before inserting an new element in hash table,
> > all its fields are committed to memory or else another cpu could
> > find corrupt values and crash.
> > 
> > Signed-off-by: Eric Dumazet 
> > Cc: Patrick McHardy 
> > Signed-off-by: David S. Miller 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  net/8021q/vlan_dev.c |7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > --- a/net/8021q/vlan_dev.c
> > +++ b/net/8021q/vlan_dev.c
> > @@ -73,6 +73,8 @@ vlan_dev_get_egress_qos_mask(struct net_
> >  {
> > struct vlan_priority_tci_mapping *mp;
> >  
> > +   smp_rmb(); /* coupled with smp_wmb() in vlan_dev_set_egress_priority() 
> > */
> > +
> > mp = vlan_dev_priv(dev)->egress_priority_map[(skb->priority & 0xF)];
> 
> This barrier is the wrong type in the wrong place; there should be a
> smp_read_barrier_depends() *after* reading the pointer from
> egress_priority_map, and after reading each next pointer.
> 

Not sure its a problem anyway, as we insert new items at the beginning
of the chain, and we never delete any item. What you describe would make
sense if we were deleting an item.

Once a reader gets a pointer, the whole chain is stable.

The important part of the patch was the smp_wmb(), to make sure np->next
was committed before "vlan->egress_priority_map[skb_prio & 0xF] = np;"



--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Richard Cochran]

On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> 
> > [ I disagree about the "more thought" part. The current discussion,
> >   coming years too late after the introduction of DT to ARM Linux, is
> >   contrary evidence enough. ]
> 
> We did have exactly the same discussion when the DT transition was
> started - this isn't something that people only just realised might be
> an issue.  There was a deliberate decision to focus on getting the
> technology deployed to the point where it could be used as a straight
> replacement for board files and accept that sometimes the results won't
> be perfect and that we may need to rework as a result.

Can you tell a bit more about this decision? When was it made? Who
made it? How was it made public?

Thanks,
Richard
--
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 RFC] pram: persistent over-kexec memory file system

[Vladimir Davydov]

On 07/27/2013 07:41 PM, Marco Stornelli wrote:

Il 26/07/2013 14:29, Vladimir Davydov ha scritto:

Hi,

We want to propose a way to upgrade a kernel on a machine without
restarting all the user-space services. This is to be done with CRIU
project, but we need help from the kernel to preserve some data in
memory while doing kexec.

The key point of our implementation is leaving process memory in-place
during reboot. This should eliminate most io operations the services
would produce during initialization. To achieve this, we have
implemented a pseudo file system that preserves its content during
kexec. We propose saving CRIU dump files to this file system, kexec'ing
and then restoring the processes in the newly booted kernel.



http://pramfs.sourceforge.net/


AFAIU it's a bit different thing: PRAMFS as well as pstore, which has 
already been merged, requires hardware support for over-reboot 
persistency, so called non-volatile RAM, i.e. RAM which is not directly 
accessible and so is not used by the kernel. On the contrary, what we'd 
like to have is preserving usual RAM on kexec. It is possible, because 
RAM is not reset during kexec. This would allow leaving applications 
working set as well as filesystem caches in place, speeding the reboot 
process as a whole and reducing the downtime significantly.


Thanks.
--
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] Events: 9p.h: Fixed a brace coding style issues

[santosh.anbu]

From: "santosh.anbu" 

Fixed few brace relate coding style issues

Signed-off-by: santosh.anbu 
---
 include/trace/events/9p.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/trace/events/9p.h b/include/trace/events/9p.h
index a066636..9b53b8a 100644
--- a/include/trace/events/9p.h
+++ b/include/trace/events/9p.h
@@ -83,9 +83,9 @@ TRACE_EVENT(9p_client_req,
TP_ARGS(clnt, type, tag),
 
TP_STRUCT__entry(
-   __field(void *, clnt )
-   __field(__u8,   type )
-   __field(__u32,  tag  )
+   __field(void *, clnt)
+   __field(__u8,   type)
+   __field(__u32,  tag )
),
 
TP_fast_assign(
@@ -97,7 +97,7 @@ TRACE_EVENT(9p_client_req,
TP_printk("client %lu request %s tag  %d",
(long)__entry->clnt, show_9p_op(__entry->type),
__entry->tag)
- );
+);
 
 TRACE_EVENT(9p_client_res,
TP_PROTO(struct p9_client *clnt, int8_t type, int tag, int err),
@@ -105,10 +105,10 @@ TRACE_EVENT(9p_client_res,
TP_ARGS(clnt, type, tag, err),
 
TP_STRUCT__entry(
-   __field(void *, clnt )
-   __field(__u8,   type )
-   __field(__u32,  tag  )
-   __field(__u32,  err  )
+   __field(void *, clnt)
+   __field(__u8,   type)
+   __field(__u32,  tag )
+   __field(__u32,  err )
),
 
TP_fast_assign(
@@ -131,9 +131,9 @@ TRACE_EVENT(9p_protocol_dump,
TP_ARGS(clnt, pdu),
 
TP_STRUCT__entry(
-   __field(void *, clnt
)
-   __field(__u8,   type
)
-   __field(__u16,  tag 
)
+   __field(void *, clnt)
+   __field(__u8,   type)
+   __field(__u16,  tag )
__array(unsigned char,  line,   P9_PROTO_DUMP_SZ
)
),
 
@@ -146,7 +146,7 @@ TRACE_EVENT(9p_protocol_dump,
TP_printk("clnt %lu %s(tag = %d)\n%.3x: %16ph\n%.3x: %16ph\n",
  (unsigned long)__entry->clnt, show_9p_op(__entry->type),
  __entry->tag, 0, __entry->line, 16, __entry->line + 16)
- );
+);
 
 #endif /* _TRACE_9P_H */
 
-- 
1.8.1.2

--
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/1] hid: Add new driver for non-compliant Xin-Mo devices.

[oscherler]

From: Olivier Scherler 

The Xin-Mo Dual Arcade Controller sends axis values that are out of
range with respect to the HID report descriptor. This patch adds a
driver to correct the input values so they are not thrown out by the
range check in hid-input.c.

The issue is discussed here: 

checkpatch.pl gives warnings for two lines that are over 80 characters,
but I decided not to change them since similar lines in other HID
drivers. The third warning asks for a paragraph that describes the new
config symbol in Kconfig fully. I will gladly accept advice on how to
improve it.

This has been tested on Ubuntu Desktop 13.04 in a VMware VM and on a
Raspberry Pi running Raspbian.

Olivier Scherler (1):
  hid: Add new driver for non-compliant Xin-Mo devices.

 drivers/hid/Kconfig |  8 ++
 drivers/hid/Makefile|  1 +
 drivers/hid/hid-core.c  |  1 +
 drivers/hid/hid-ids.h   |  3 +++
 drivers/hid/hid-xinmo.c | 72 +
 5 files changed, 85 insertions(+)
 create mode 100644 drivers/hid/hid-xinmo.c

-- 
1.8.1.2

--
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] hid: Add new driver for non-compliant Xin-Mo devices.

[oscherler]

From: Olivier Scherler 

The driver currently only supports the Dual Arcade controller.
It fixes the negative axis event values (the devices sends -2) to match the
logical axis minimum of the HID report descriptor (the report announces -1).
It is needed because hid-input discards out of bounds values.

Signed-off-by: Olivier Scherler 
---
 drivers/hid/Kconfig |  8 ++
 drivers/hid/Makefile|  1 +
 drivers/hid/hid-core.c  |  1 +
 drivers/hid/hid-ids.h   |  3 +++
 drivers/hid/hid-xinmo.c | 72 +
 5 files changed, 85 insertions(+)
 create mode 100644 drivers/hid/hid-xinmo.c

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 14ef6ab..3d7c9f6 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -743,6 +743,14 @@ config HID_WIIMOTE
To compile this driver as a module, choose M here: the
module will be called hid-wiimote.
 
+config HID_XINMO
+   tristate "Xin-Mo non-fully compliant devices"
+   depends on HID
+   ---help---
+   Support for Xin-Mo devices that are not fully compliant with the HID
+   standard. Currently only supports the Xin-Mo Dual Arcade. Say Y here
+   if you have a Xin-Mo Dual Arcade controller.
+
 config HID_ZEROPLUS
tristate "Zeroplus based game controller support"
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 6f68728..a959f4a 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_HID_TIVO)  += hid-tivo.o
 obj-$(CONFIG_HID_TOPSEED)  += hid-topseed.o
 obj-$(CONFIG_HID_TWINHAN)  += hid-twinhan.o
 obj-$(CONFIG_HID_UCLOGIC)  += hid-uclogic.o
+obj-$(CONFIG_HID_XINMO)+= hid-xinmo.o
 obj-$(CONFIG_HID_ZEROPLUS) += hid-zpff.o
 obj-$(CONFIG_HID_ZYDACRON) += hid-zydacron.o
 obj-$(CONFIG_HID_WACOM)+= hid-wacom.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..283c70f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1736,6 +1736,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, 
USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, 
USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET) },
{ HID_USB_DEVICE(USB_VENDOR_ID_X_TENSIONS, 
USB_DEVICE_ID_SPEEDLINK_VAD_CEZANNE) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, 
USB_DEVICE_ID_XIN_MO_DUAL_ARCADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZYDACRON, 
USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..6051be8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -887,6 +887,9 @@
 #define USB_VENDOR_ID_XAT  0x2505
 #define USB_DEVICE_ID_XAT_CSR  0x0220
 
+#define USB_VENDOR_ID_XIN_MO   0x16c0
+#define USB_DEVICE_ID_XIN_MO_DUAL_ARCADE   0x05e1
+
 #define USB_VENDOR_ID_XIROKU   0x1477
 #define USB_DEVICE_ID_XIROKU_SPX   0x1006
 #define USB_DEVICE_ID_XIROKU_MPX   0x1007
diff --git a/drivers/hid/hid-xinmo.c b/drivers/hid/hid-xinmo.c
new file mode 100644
index 000..6153e50
--- /dev/null
+++ b/drivers/hid/hid-xinmo.c
@@ -0,0 +1,72 @@
+/*
+ *  HID driver for Xin-Mo devices, currently only the Dual Arcade controller.
+ *  Fixes the negative axis event values (the devices sends -2) to match the
+ *  logical axis minimum of the HID report descriptor (the report announces
+ *  -1). It is needed because hid-input discards out of bounds values.
+ *  (This module is based on "hid-saitek" and "hid-lg".)
+ *
+ *  Copyright (c) 2013 Olivier Scherler
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "hid-ids.h"
+
+/*
+ * Fix negative events that are out of bounds.
+ */
+static int xinmo_event(struct hid_device *hdev, struct hid_field *field,
+   struct hid_usage *usage, __s32 value)
+{
+   switch (usage->code) {
+   case ABS_X:
+   case ABS_Y:
+   case ABS_Z:
+   case ABS_RX:
+   if (value < -1) {
+   input_event(field->hidinput->input, usage->type,
+   usage->code, -1);
+   return 1;
+   }
+   break;
+   }
+
+   return 0;
+}
+
+static const struct hid_device_id xinmo_devices[] = {
+   { HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, 
USB_DEVICE_ID_XIN_MO_DUAL_ARCADE) },
+   { }
+};
+
+MODULE_DEVICE_TABLE(hid, xinmo_devices);
+
+static struct hid_driver xinmo_driver = {
+   .name = "xinmo",
+   

acpi_backlight=vendor no longer working around buggy laptop from hell

[Cristian Rodríguez]

Hi:

I have a DELL XPS 15z laptop with the latest BIOS (A12).

This piece of crap have never worked properly without special boot 
parameters. Up to kernel 3.10, passing acpi_backlight=vendor was enough 
to allow the machine to complete boot and be usable.


Now with 3.11 rc2 (also with today's linus tree) unbootable machine 
problem is back.


In the past I spent many hours figuring out workarounds and they go 
_now_ as the following.


Booting with:

"nox2apic" --> machine works, flawless.

"x2apic_phys acpi_backlight=vendor" --> machine works, except for the 
big problem that the laptop keyboard and touchpad are unresponsive, I 
have to plug USB keyboard/mouse to get anything done.


With no boot parameters the machine hangs at random points in the boot 
sequence either:


-Very early at boot and there is no way to retrieve any useful debug 
info. [OR]


- Somehow it looses "connection" with the ATA controller and the 
filesystems cannot be mounted. [OR]


- In very few ocassions, the boot proceeds with no keyboard or touchpad 
then the iwlwifi wireless card does something stupid (firmware error...)


The only possible hint in the logs I could ever find is:

[3.844586] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS


I tried in the past to obtain any debug information, with no luck.

Help is appreciated to get to the bottom of the problem. ;)


--
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] workqueue: allow work_on_cpu() to be called recursively

[Srivatsa S. Bhat]

On 07/24/2013 09:55 PM, Tejun Heo wrote:
> Applied to wq/for-3.11-fixes with comment and subject tweaks.
> 
> Thanks!
> 
> -- 8< 
> 
> From c2fda509667b0fda4372a237f5a59ea4570b1627 Mon Sep 17 00:00:00 2001
> From: Lai Jiangshan 
> Date: Wed, 24 Jul 2013 18:31:42 +0800
> 
> If the @fn call work_on_cpu() again, the lockdep will complain:
> 
>> [ INFO: possible recursive locking detected ]
>> 3.11.0-rc1-lockdep-fix-a #6 Not tainted
>> -
>> kworker/0:1/142 is trying to acquire lock:
>>  (()){+.+.+.}, at: [] flush_work+0x0/0xb0
>>
>> but task is already holding lock:
>>  (()){+.+.+.}, at: [] process_one_work+0x169/0x610
>>
>> other info that might help us debug this:
>>  Possible unsafe locking scenario:
>>
>>CPU0
>>
>>   lock(());
>>   lock(());
>>
>>  *** DEADLOCK ***
> 
> It is false-positive lockdep report. In this sutiation,
> the two "wfc"s of the two work_on_cpu() are different,
> they are both on stack. flush_work() can't be deadlock.
> 
> To fix this, we need to avoid the lockdep checking in this case,
> thus we instroduce a internal __flush_work() which skip the lockdep.
> 
> tj: Minor comment adjustment.
> 
> Signed-off-by: Lai Jiangshan 
> Reported-by: "Srivatsa S. Bhat" 
> Reported-by: Alexander Duyck 
> Signed-off-by: Tejun Heo 
> ---

This version works as well, it fixes the issue I was facing.
Thank you!

FWIW:
Tested-by: Srivatsa S. Bhat 

Regards,
Srivatsa S. Bhat

>  kernel/workqueue.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index f02c4a4..55f5f0a 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -2817,6 +2817,19 @@ already_gone:
>   return false;
>  }
> 
> +static bool __flush_work(struct work_struct *work)
> +{
> + struct wq_barrier barr;
> +
> + if (start_flush_work(work, )) {
> + wait_for_completion();
> + destroy_work_on_stack();
> + return true;
> + } else {
> + return false;
> + }
> +}
> +
>  /**
>   * flush_work - wait for a work to finish executing the last queueing 
> instance
>   * @work: the work to flush
> @@ -2830,18 +2843,10 @@ already_gone:
>   */
>  bool flush_work(struct work_struct *work)
>  {
> - struct wq_barrier barr;
> -
>   lock_map_acquire(>lockdep_map);
>   lock_map_release(>lockdep_map);
> 
> - if (start_flush_work(work, )) {
> - wait_for_completion();
> - destroy_work_on_stack();
> - return true;
> - } else {
> - return false;
> - }
> + return __flush_work(work);
>  }
>  EXPORT_SYMBOL_GPL(flush_work);
> 
> @@ -4756,7 +4761,14 @@ long work_on_cpu(int cpu, long (*fn)(void *), void 
> *arg)
> 
>   INIT_WORK_ONSTACK(, work_for_cpu_fn);
>   schedule_work_on(cpu, );
> - flush_work();
> +
> + /*
> +  * The work item is on-stack and can't lead to deadlock through
> +  * flushing.  Use __flush_work() to avoid spurious lockdep warnings
> +  * when work_on_cpu()s are nested.
> +  */
> + __flush_work();
> +
>   return wfc.ret;
>  }
>  EXPORT_SYMBOL_GPL(work_on_cpu);
> 

--
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 3/3] Input: omap-keypad: Set irq to level instead of edge

[Felipe Balbi]

Hi,

On Fri, Jul 26, 2013 at 08:09:06PM +0300, Illia Smyrnov wrote:
> From: Axel Haslam 
> 
> Set mpu irq to level instead of edge, since if mpu is in low power
> an edge detection may be lost if the event is a wkup event.
> 
> Signed-off-by: Axel Haslam 
> Signed-off-by: Illia Smyrnov 
> ---
>  Based on top of v3.11-rc2
> 
>  Depends on:
>  Input: omap-keypad: Convert to threaded IRQ
>  https://patchwork.kernel.org/patch/2832920/
> 
>  drivers/input/keyboard/omap4-keypad.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c 
> b/drivers/input/keyboard/omap4-keypad.c
> index e8bdc76..7adb53e 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -374,9 +374,13 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   goto err_free_keymap;
>   }
>  
> + /*
> +  * Set irq level detection for mpu. Edge event are missed in gic
> +  * if the mpu is in low power and keypad event is a wakeup
> +  */
>   error = request_threaded_irq(keypad_data->irq, omap4_keypad_irq_handler,
>omap4_keypad_irq_thread_fn,
> -  IRQF_TRIGGER_RISING,
> +  IRQF_TRIGGER_HIGH,

omap4 is DT-only, why don't you pass zero here and expect DT to setup
IRQ type correctly for you ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] mm: Save soft-dirty bits on file pages

[Andy Lutomirski]

On Fri, Jul 26, 2013 at 11:25 PM, Cyrill Gorcunov  wrote:
> On Fri, Jul 26, 2013 at 02:36:51PM -0700, Andy Lutomirski wrote:
>> >> Unless I'm misunderstanding this, it's saving the bit in the
>> >> non-present PTE.  This sounds wrong -- what happens if the entire pmd
>> >
>> > It's the same as encoding pgoff in pte entry (pte is not present),
>> > but together with pgoff we save soft-bit status, later on #pf we decode
>> > pgoff and restore softbit back if it was there, pte itself can't disappear
>> > since it holds pgoff information.
>>
>> Isn't that only the case for nonlinear mappings?
>
> Andy, I'm somehow lost, pte either exist with file encoded, either not,
> when pud/ptes are zapped and any access to it should cause #pf pointing
> kernel to read/write data from file to a page, if it happens on write
> the pte is obtaining dirty bit (which always set together with soft
> bit).

Hmm.  I may have been wrong.

By my reading of this stuff, when a pte is freed to reclaim memory, if
it's an un-cowed file mapping, it's cleared completely by
zap_pte_range -- no swap entry is left behind.  That's this code in
zap_pte_range:

/*
 * unmap_shared_mapping_pages() wants to
 * invalidate cache without truncating:
 * unmap shared but keep private pages.
 */
if (details->check_mapping &&
details->check_mapping != page->mapping)
continue;

In theory, if you map 2MB (on x86_64) of a file as MAP_PRIVATE,
aligned, then you get a whole pmd.  If you don't write any of it
(triggering COW), the kernel could, in theory, free all those ptes, so
you can't save any state in there.  (I can't find any code that does
this, though.)

That being said, a MAP_PRIVATE, un-cowed mapping must be clean -- if
it had been (soft-)dirtied, it would also have been cowed.  So you
might be okay.


--Andy
--
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: [ 42/79] vlan: fix a race in egress prio management

[Ben Hutchings]

On Fri, 2013-07-26 at 13:47 -0700, Greg Kroah-Hartman wrote:
> 3.10-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Eric Dumazet 
> 
> [ Upstream commit 3e3aac497513c669e1c62c71e1d552ea85c1d974 ]
> 
> egress_priority_map[] hash table updates are protected by rtnl,
> and we never remove elements until device is dismantled.
> 
> We have to make sure that before inserting an new element in hash table,
> all its fields are committed to memory or else another cpu could
> find corrupt values and crash.
> 
> Signed-off-by: Eric Dumazet 
> Cc: Patrick McHardy 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  net/8021q/vlan_dev.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -73,6 +73,8 @@ vlan_dev_get_egress_qos_mask(struct net_
>  {
>   struct vlan_priority_tci_mapping *mp;
>  
> + smp_rmb(); /* coupled with smp_wmb() in vlan_dev_set_egress_priority() 
> */
> +
>   mp = vlan_dev_priv(dev)->egress_priority_map[(skb->priority & 0xF)];

This barrier is the wrong type in the wrong place; there should be a
smp_read_barrier_depends() *after* reading the pointer from
egress_priority_map, and after reading each next pointer.

(In practice, I think this error is harmless except on Alpha.  So the
patch is worth applying anyway.)

Ben.

>   while (mp) {
>   if (mp->priority == skb->priority) {
> @@ -249,6 +251,11 @@ int vlan_dev_set_egress_priority(const s
>   np->next = mp;
>   np->priority = skb_prio;
>   np->vlan_qos = vlan_qos;
> + /* Before inserting this element in hash table, make sure all its fields
> +  * are committed to memory.
> +  * coupled with smp_rmb() in vlan_dev_get_egress_qos_mask()
> +  */
> + smp_wmb();
>   vlan->egress_priority_map[skb_prio & 0xF] = np;
>   if (vlan_qos)
>   vlan->nr_egress_mappings++;

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [RFC 0/3] IO Hook: Method for emulating h/w events

[rui wang]

>
> This is a cool idea.
>
> I don't know if you want to merge this upstream, or if it's just a "I
> found this useful; here it is in case it's useful to you" sort of
> thing.  So the comments below are only relevant if you want to try to
> merge it upstream.
>

Thanks. If you think it's a cool idea, then I would like to see it
merged upstream.

> I wouldn't really want all the gunk in drivers/pci/access.c.  Most of
> it isn't related to PCI, and some of it is even x86-specific.  It'd be
> nicer if you could factor it out so just the generic PCI-related
> things go in drivers/pci.
>

Sure. I'll keep only the PCI-related things in drivers/pci and move
other things out.

> It appears to be implemented only for x86.  The MMIO & I/O port parts
> are x86-specific, but the PCI config stuff should work on any arch.
>

I had only x86 in mind. But yes it should be made platform neutral.
I'll split it into neutral and arch-specific parts, so that other
archs can be supported easily.

> I don't know whether it's worth supporting as a module.  It seems like
> a development aid where building in statically would probably be fine.
>  If it didn't have to work as a module, you wouldn't have to export
> any symbols.
>

Yes building it statically in the kernel would be cleaner and easier
to use. I'll roll out a new version for you to review.

Thanks
Rui

>> I tested the performance by repeatedly running lspci, which calls into
>> the
>> pci access functions. There's no added overhead observed.
>>
>> Regards,
>> Rui Wang
>> Intel Open Source Technology Center
>>
>> Rui Wang (3):
>>   IO Hook: core functions and Register Override
>>   IO Hook: kernel interface to manage the hook
>>   IO Hook: sysfs interface to emulate h/w events
>>
>>  Documentation/PCI/iohook.txt  |  290 +
>>  arch/x86/Kconfig  |7 +
>>  arch/x86/boot/compressed/Makefile |1 +
>>  arch/x86/include/asm/io.h |   58 -
>>  arch/x86/vdso/Makefile|2 +
>>  drivers/misc/Kconfig  |1 +
>>  drivers/misc/Makefile |1 +
>>  drivers/misc/iohook/Kconfig   |5 +
>>  drivers/misc/iohook/Makefile  |1 +
>>  drivers/misc/iohook/iohook.c  |  503 +
>>  drivers/pci/access.c  |  630
>> +
>>  include/linux/reg_ovrd.h  |   55 
>>  12 files changed, 1552 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/PCI/iohook.txt
>>  create mode 100644 drivers/misc/iohook/Kconfig
>>  create mode 100644 drivers/misc/iohook/Makefile
>>  create mode 100644 drivers/misc/iohook/iohook.c
>>  create mode 100644 include/linux/reg_ovrd.h
>>
>> --
>> 1.7.5.4
>>
>
--
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 2/2] tracing: Shrink the size of struct ftrace_event_field

[Borislav Petkov]

On Sat, Jul 27, 2013 at 07:35:38AM -0400, Steven Rostedt wrote:
> But you know me. I LOVE macros!

I'll say.

Btw, I wouldn't wonder if you start sending patches for the gcc C
preprocessor because it evaluates your macro voodoo too slow.

:-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[Bjorn Helgaas]

On Sat, Jul 27, 2013 at 8:27 AM, Yinghai Lu  wrote:
> On Fri, Jul 26, 2013 at 10:39 AM, Bjorn Helgaas  wrote:

>> [bhelgaas: changelog, drop printk]
>> Signed-off-by: ethan.zhao 
>> Signed-off-by: Bjorn Helgaas 
>> Acked-by: Yinghai Lu 
>
> looks like I had typo in ack. please update to
>
> Acked-by: Yinghai Lu 

Done, thanks, sorry I didn't notice that :)
--
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: [ 06/79] net: Swap ver and type in pppoe_hdr

[Ben Hutchings]

On Fri, 2013-07-26 at 13:46 -0700, Greg Kroah-Hartman wrote:
> 3.10-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Changli Gao 
> 
> [ Upstream commit b1a5a34bd0b8767ea689e68f8ea513e9710b671e ]
> 
> Ver and type in pppoe_hdr should be swapped as defined by RFC2516
> section-4.
> 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 

I'm not so sure this is suitable for stable.  It doesn't seem to be
helpful to either userland or kernel code.

In the kernel, we were checking that ver == 1 and type == 1 thus this
wasn't hurting us.

If userland does anything more with these fields then it's probably
already working around the swapped fields.  It can work with both old
and new headers by doing:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,11,0)
/* use pppoe_hdr fields normally */
#else
/* definitions were wrong before, work around it */
#endif

If this is backported to stable, there is no usable version test.
Userland will have to bypass the bitfields entirely:

type = *(uint8_t *)hdr & 0xf;
ver = *(uint8_t *)hdr >> 4;

Ben.

> ---
>  include/uapi/linux/if_pppox.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- a/include/uapi/linux/if_pppox.h
> +++ b/include/uapi/linux/if_pppox.h
> @@ -135,11 +135,11 @@ struct pppoe_tag {
>  
>  struct pppoe_hdr {
>  #if defined(__LITTLE_ENDIAN_BITFIELD)
> - __u8 ver : 4;
>   __u8 type : 4;
> + __u8 ver : 4;
>  #elif defined(__BIG_ENDIAN_BITFIELD)
> - __u8 type : 4;
>   __u8 ver : 4;
> + __u8 type : 4;
>  #else
>  #error   "Please fix "
>  #endif


-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [PATCHv2] bridge: disable snooping if there is no querier

[Linus Lüssing]

On Fri, Jul 26, 2013 at 11:19:00PM +0100, Adam Baker wrote:
> On 25/07/13 14:56, Linus Lüssing wrote:
> >If there is no querier on a link then we won't get periodic reports and
> >therefore won't be able to learn about multicast listeners behind ports,
> >potentially leading to lost multicast packets, especially for multicast
> >listeners that joined before the creation of the bridge.
> >
> >These lost multicast packets can appear since c5c23260594
> >("bridge: Add multicast_querier toggle and disable queries by default")
> >in particular.
> >
> >With this patch we are flooding multicast packets if our querier is
> >disabled and if we didn't detect any other querier.
> >
> >A grace period of the Maximum Response Delay of the querier is added to
> >give multicast responses enough time to arrive and to be learned from
> >before disabling the flooding behaviour again.
> >
> >Signed-off-by: Linus Lüssing
> 
> If the lack of queries if there is no other querier is unacceptable
> to the majority of users (and I believe it is) then surely the
> sensible option is to have the multicast querier toggle enabled by
> default.
> 
> The toggle was added in the first place because the queries were
> reported to be generating issues with certain other equipment. This
> may have been because the queries by default have an invalid IP
> address (although I have been unable to identify what equipment they
> caused problems with so can't verify this).
> 
> If the only reason to turn the querier off is because it interferes
> with other equipment then the solution to it being off by default
> isn't to generate queries in some instances even if it is off but
> rather to turn it on by default and only turn it off if it causes
> problems. If multicast_query_use_ifaddr was also enabled by default
> the the likelihood of the querier causing problems elsewhere should
> be reduced.
> 
> Regards
> 
> Adam

One more, general disadvantage I could see is, that in a network
with multiple bridges basically a random one would become the querier
and the according network segment would get hit by all the
according multicast traffic. If the available bandwidth of links
on your network varies, then you however usually want to have the
querier in a "good" position of your network. Which might be a
little harder to control if the querier is on by default.

Also this specific, current querier implementation has two more
disadvantages: 
* It's doing MLDv1/IGMPv2 queries, so it downgrades our whole
  network to MLDv1/IGMPv2, no MLDv2/IGMPv3 and source specific
  multicast could be used.
* The querier selection is not RFC compliant (we should refrain
  from sending queries if our address is higher, not if we hear
  any query)

Cheers, Linus
--
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 RFC] pram: persistent over-kexec memory file system

[Marco Stornelli]

Il 26/07/2013 14:29, Vladimir Davydov ha scritto:

Hi,

We want to propose a way to upgrade a kernel on a machine without
restarting all the user-space services. This is to be done with CRIU
project, but we need help from the kernel to preserve some data in
memory while doing kexec.

The key point of our implementation is leaving process memory in-place
during reboot. This should eliminate most io operations the services
would produce during initialization. To achieve this, we have
implemented a pseudo file system that preserves its content during
kexec. We propose saving CRIU dump files to this file system, kexec'ing
and then restoring the processes in the newly booted kernel.



http://pramfs.sourceforge.net/

Marco

--
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: [ 02/79] sparc32: vm_area_struct access for old Sun SPARCs.

[Ben Hutchings]

On Fri, 2013-07-26 at 13:46 -0700, Greg Kroah-Hartman wrote:
> 3.10-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Olivier DANET 
[...]

This is missing the upstream reference.  It was commit
961246b4ed8da3bcf4ee1eb9147f341013553e3c.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: [PATCH v3 3/4] hwmon: (lm90) add support to handle IRQ

[Jean Delvare]

Hi Wei,

Sorry for the late reply.

On Fri, 19 Jul 2013 14:41:54 +0800, Wei Ni wrote:
> On 07/18/2013 11:58 PM, Jean Delvare wrote:
> > First of all, how is the chip wired on your system? You are using an
> > NCT1008, right? Which output of the chip is connected to your interrupt
> > line, THERM or ALERT/THERM2? ALERT is normally used for SMBus Alert but
> > I suppose it could be used for an interrupt too. THERM and THERM2 OTOH
> > are comparator outputs, they stay low as long as the temperature are
> > above the therm limits. Reading the status register won't bring them
> > back up as I understand it, and contrary to the ALERT output, they
> > can't be masked. Won't this result in an interrupt flood if using
> > IRQF_TRIGGER_LOW? Have you tested your code already?
> 
> Let me explain why I want to add the IRQ thread.
> In our tegra30 platform, we use an NCT1008, and in our downstream tree,
> it programmed as following:
> 1. The pin THERM is connected to the PMIC, we will set the THERM limit
> in the initialization, once the this limit is tripped, it will trigged
> the PMIC, and the PMIC will shutdown the system immediately.

OK, this is what the chip is designed for, good.

> 2. The pin ALERT/THERM2 is configured as ALERT, and it is connected to
> the interrupt line.

Why don't you use the SMBus alert mechanism then? It is already
implemented and allows you to reuse the interrupt of the SMBus
controller.

Of course this is a question for the hardware designers, not you... If
the board uses a separate interrupt pin for the NCT1008's ALERT output,
then the driver has to handle that interrupt explicitly, as done in your
patch.

One thing which worries me though is this explanation in the NCT1008
datasheet:

"The ALERT interrupt latch is not reset by reading the
status register. It resets when the ALERT output has been
serviced by the master reading the device address, provided
the error condition has gone away and the status register flag
bits are reset."

This suggests that connecting the ALERT output to a separate interrupt
pin will not work, as the ALERT output will never be de-asserted even
if the fault conditions are gone and the status register was read. But
as you say this is how your system is supposed to work, can you explain
how it can work?

> In the platform init, we will prepare some trip
> temps, such as 20C, 40C,60C, 80C, and we will set 20C to the
> remote-low-temp-limit, and set 40C to remote-high-temp-limit. When the
> temperature exceed this rang, it will interrupt the system, then we will
> update the low/high limit to next rang, for example, if the temp raise
> to 50C, we will set 40C to low-limit, and set 60C to hight-limit, then
> we will run the throttle functions, and update cooling state.

Hu ho, I have seen this kind of design in the past, and I must say I
don't quite like it. Moving critical thermal management handling to the
software makes me feel unsafe. System thermal safety should not rely on
the OS IMHO. It is best handled by the hardware, or if that can't be
done, by the BIOS. And these limit updates are tricky, they could fail
and then you're in trouble. Imagine for example that another chip on
the SMBus hugs the bus and delays or even plain prevents the change of
limits...

But once again I guess you're not responsible for this.

Another problem with this design, even if no such problem happens, is
that the limits are user(-space)-writable in the lm90 driver, while
with your design these limits are under full control of the platform
management code. You definitely don't want the user to come and adjust
the limits, this could result in overheating of the system. So, do you
have a plan to optionally switch limits to read only in the lm90
driver? If not, how do you intend to solve the problem?

The more I think about it, the more I wonder if a custom thermal driver
wouldn't be better for your case. Exposing a few read-only values to
user-space through the thermal/hwmon bridge would IMHO make more sense
than cluttering the lm90 driver with conditionals to limit what it
exposes to user-space.

> We wish to upstream these codes, but as you know, it's difficult to use
> current lm90.c and thermal framework to implement it, and these codes
> related many other things, such as throttling cpufreq, other clock freq.
> So at first, I want to update the lm90.c, so that I can add it to the
> thermal fw and use interrupt handler easily. And at the same time I
> followed the thermal framework thread, there has new infrastructure
> posted, which is more easy to add lm90 to thermal fw.

Don't get me wrong, I'm very happy with your efforts to upstream your
code, this is very welcome. And I am also very happy that you split it
into small chunks which are easier to review. But I also need to know
the big picture to see where you're ultimately going.

> > (...)
> > For a real system, if the THERM output is connected to an interrupt line
> > (instead of directly to a fan controller) I would 

Re: [PATCH v3 4/4] hwmon: (lm90) use enums for the indexes of temp8 and temp11

[Jean Delvare]

Hi Wei,

On Fri, 12 Jul 2013 15:48:07 +0800, Wei Ni wrote:
> Using enums for the indexes and nrs of temp8 and temp11.
> This make the code much more readable.

I can't say I'm thrilled by this patch. The improved readability is
questionable. In the original code, each line already had one constant
which made it clear what the code was doing. So the gain is marginal,
I'd say, and this costs almost 50 lines of code.

Let me review it nevertheless:

> 
> Signed-off-by: Wei Ni 
> ---
>  drivers/hwmon/lm90.c |  179 
> --
>  1 file changed, 114 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
> index 1cc3d19..8cb5dd0 100644
> --- a/drivers/hwmon/lm90.c
> +++ b/drivers/hwmon/lm90.c
> @@ -310,6 +310,59 @@ static const struct lm90_params lm90_params[] = {
>  };
>  
>  /*
> + * TEMP8 register index
> + */
> +enum lm90_temp8_reg_index {
> + TEMP8_LOCAL_LOW = 0,/* 0: local low limit */
> + TEMP8_LOCAL_HIGH,   /* 1: local high limit */
> + TEMP8_LOCAL_CRIT,   /* 2: local critical limit */
> + TEMP8_REMOTE_CRIT,  /* 3: remote critical limit */
> + TEMP8_LOCAL_EMERG,  /* 4: local emergency limit
> +  * (max6659 and max6695/96)
> +  */
> + TEMP8_REMOTE_EMERG, /* 5: remote emergency limit
> +  * (max6659 and max6695/96)
> +  */
> + TEMP8_REMOTE2_CRIT, /* 6: remote 2 critical limit
> +  * (max6695/96 only)
> +  */
> + TEMP8_REMOTE2_EMERG,/* 7: remote 2 emergency limit
> +  * (max6695/96 only)
> +  */
> + TEMP8_REG_NUM
> +};
> +
> +/*
> + * TEMP11 register index
> + */
> +enum lm90_temp11_reg_index {
> + TEMP11_REMOTE_TEMP = 0, /* 0: remote input */
> + TEMP11_REMOTE_LOW,  /* 1: remote low limit */
> + TEMP11_REMOTE_HIGH, /* 2: remote high limit */
> + TEMP11_REMOTE_OFFSET,   /* 3: remote offset
> +  * (except max6646, max6657/58/59,
> +  *  and max6695/96)
> +  */
> + TEMP11_LOCAL_TEMP,  /* 4: local input */
> + TEMP11_REMOTE2_TEMP,/* 5: remote 2 input (max6695/96 only) */
> + TEMP11_REMOTE2_LOW, /* 6: remote 2 low limit (max6695/96 only) */
> + TEMP11_REMOTE2_HIGH,/* 7: remote 2 high limit (max6695/96 only) */
> + TEMP11_REG_NUM
> +};

The "TEMP8_" and "TEMP11_" prefixes aren't really needed, as there is no
overlapping between both sets. Removing these prefixes (except for the
terminators, where they are needed and make sense) would make the rest
of the code more readable IMHO, as it would avoid redundant information
on most lines, and avoid line splitting in some cases.

Also, the comments are mostly useless now, they were there to document
what each number was referring to, but now this is exactly what the new
constants are doing.

> +
> +/*
> + * TEMP11 register NR
> + */
> +enum lm90_temp11_reg_nr {
> + NR_CHAN_0_REMOTE_LOW = 0,   /* 0: channel 0, remote low limit */
> + NR_CHAN_0_REMOTE_HIGH,  /* 1: channel 0, remote high limit */
> + NR_CHAN_0_REMOTE_OFFSET,/* 2: channel 0, remote offset */
> + NR_CHAN_1_REMOTE_LOW,   /* 3: channel 1, remote low limit */
> + NR_CHAN_1_REMOTE_HIGH,  /* 4: channel 1, remote high limit */

The conventions used in the descriptions diverge from the ones used
above. "channel 0 remote" here is just "remove" above, and "channel 1
remote" is "remote 2" above. This is quite confusing.

> + NR_NUM  /* number of the NRs for temp11 */

The fact that you were unable to come up with a proper name for this
number is a clear indication that this enum should not exist in the
first place.

These numbers are used only once, to pass specific information to
set_temp11. This was easy enough when these were just numbers and I
really had no reason not to do that.

If you now want to use clean constants, this should be done with logic
and consistency. Your proposal makes sense for the data->temp8 and
data->temp11 array indexing, because they are used more than once. But
introducing a new set of constants with weird names just for one use
case doesn't help readability, it makes things worse actually.

So if you insist of making the code more readable by the means of named
constants, then you should simply adjust the reg array in write_temp11
so that it can be indexed with your TEMP11_* constants above (as is
data->temp11.) This will leave some holes in the array but I don't
think we care about a few lost bytes here.

> +};
> +
> +/*
>   * Client data (each client gets its own)
>   */
>  
> @@ -331,25 +384,8 @@ struct lm90_data {
>   u8 reg_local_ext;   /* local extension register offset */
>  
>   

Re: [PATCH v4 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Ben Guthro]

On Jul 27, 2013, at 9:51 AM, "Rafael J. Wysocki"  wrote:

> On Thursday, June 27, 2013 11:01:58 AM Ben Guthro wrote:
>> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>> reduced hardware sleep support, and the two changes didn't get
>> synchronized: The new code doesn't call the hook function (if so
>> requested). Fix this, requiring a boolean parameter to be added to the
>> hook function to distinguish "extended" from "legacy" sleep.
>> 
>> This requires adjusting TXT, but the adjustments only go as far as
>> failing the extended mode call (since, looking at the TXT interface,
>> there doesn't even appear to be precautions to deal with that
>> alternative interface).
>> 
>> The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
>> v5 (reduced HW) sleep interface") on the master branch of
>> git://xenbits.xen.org/xen.git.
>> 
>> Signed-off-by: Ben Guthro 
>> Signed-off-by: Jan Beulich 
>> Cc: Richard L Maliszewski 
>> Cc: Gang Wei 
>> Cc: Shane Wang 
>> Cc: Bob Moore 
>> Cc: Rafaell J. Wysocki 
>> Cc: linux-a...@vger.kernel.org
>> Cc: tboot-de...@lists.sourceforge.net 
>> 
>> v2: Extend description to include reference to hypervisor side change
>> v3: Split into multiple patches, separating subsystems
>>Remove bool parameters, in favor of u8
>> v4: Remove linux/acpi.h dependencies
>>Further patch split to break out acpica from OSL
>>More bool vs u8 fixes
>> 
>> Ben Guthro (5):
>>  acpi: Remove need to include linux/acpi.h in common acpica code
>>  acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
>>  acpi: Adjust linux acpi OS functions to new extended parameter
>>  x86/tboot: Fail extended mode reduced hardware sleep
>>  xen/acpi: notify xen when reduced hardware sleep is available
> 
> The ongoing discussion means to me that the ACPICA maintainers don't want
> acpi_os_prepare_sleep() and quite frankly I understand them, because ACPICA
> is about implementing the spec and not about things beyond it.
> 
> This means that patch [1/5] goes away.
> 
> That said, at the same time we need to address the problem at hand, which
> is to make Xen work with the reduced HW sleep.
> 
> For that, I don't honestly think that modifying acpi_os_prepare_sleep() the
> way the patchset is doing it is appropriate and the change of the meaning of
> the arguments is simply disgusting.
> 
> To me, it would be much cleaner to add acpi_os_prepare_extended_sleep()
> specifically to be called by acpi_hw_extended_sleep() and make tboot and Xen
> use that.
> 
> This way or another, we'll need to live with one more divergence between the
> upstream ACPICA and the Linux ACPICA code because of that, but that'd be just
> a few added lines in acpi_hw_extended_sleep(), so I suppose it wouldn't be
> such a big deal.
> 

Ok, thank you for the review, and being open to addressing the problem at hand, 
without a full architecture rework (not to say that that discussion is not also 
needed)

I will try to make some time next week to rework the patch set to address these 
concerns, and submit a new series. 

Thanks
Ben



> Thanks,
> Rafael
> 
> 
> -- 
> 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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[David Gibson]

On Fri, Jul 26, 2013 at 03:21:40PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsm...@gmail.com wrote:
> > Yes, yes - that's why the schema should be written down and used as a
> > validation input to dtc. Then dtc can spit out errors for non-standard
> > items. There would be two versions - the standard one and a legacy one
> > that includes the standard one plus the hacks that can't be undone.
> > 
> > But more importantly it provides a framework for people creating new
> > node definitions. Now they can't work in a vacuum and come up with
> > random names and structure for everything.
> > 
> > Most of the problems express in the thread would go away if the schema
> > was written down and discussed. The rule going forward would be no new
> > nodes that aren't part of the standard schema.
> 
> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.
> 
> What that means is using the descriptions as the schema won't catch that
> because they're changing those as well to match.
> 
> There's a solution to that: dtc becomes a separate project external to
> the kernel which also contains the schemas that it verifies against.

dtc has always been a separate project external to the kernel.  Though
we do have to keep reminding people to send their patches to upstream
first.

It's had minimal support for validation of the tree contents for a
long time.  It has no more than minimal support (including "schemas"
as such for bindings), simply because no-one's implemented it yet.

> That way, if you want to make changes such as that above, you need to
> get it past not only kernel people but also past dtc maintainers -
> which increases the chances of such stuff being caught.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgphFmWjIHNU7.pgp
Description: PGP signature

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[David Gibson]

On Fri, Jul 26, 2013 at 02:14:23PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> > > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > > > 
> > > > > We use DT has a kernel configuration input. Our environment is
> > > > > designed to guarantee 100% that the kernel and DT match exactly. DT
> > > > > very deliberately isn't an ABI boundary in our systems.
> > > > 
> > > > Think about what you just said.
> > > > 
> > > > The DT describes the *hardware* not the kernel. Why should you ever
> > > > need to update your DT at all?
> > > 
> > > Well, the nodes which describe hardware devices, according to the
> > > bindings which form an ABI contract between DT and drivers, should not
> > > normally change. Although they *can* change, if for example you change
> > > the MAC address and that's stored there. Or you change the PHY you want
> > > it to use. Or something like that. The *ABI* doesn't change, but the
> > > data you express *using* that ABI can change. That's kind of the point.
> > 
> > Unless I totally misunderstood, the thread is talking about letting
> > established bindings change with each new kernel version.  I am
> > opposed to that.
> > 
> > Of course, a user may want to change the values of his MAC addresses,
> > if he needs to. But he should never have to change *how* he specifies
> > those addresses.
> > 
> > So, as long as everyone can agree to the principle that a working DT
> > should remain working after a kernel upgrade, then I'll shut up. In
> > actual fact, this is not the case today, nor was it ever so in the
> > past, AFAICT, but it never hurts to set goals.
> 
> We agree.
> 
> That's precisely why I'm saying that once a binding appears in a -final
> released kernel, it is _stable_ by that very fact.  If there were any
> doubts about it, it should never have been accepted into the kernel tree
> in the first place.
> 
> It's no different from how we treat syscalls.  Once we accept a syscall
> and it's published in a -final kernel, it can't then be altered - it can
> be supplemented by a new syscall with a different interface, but the old
> one remains and keeps its semantics for a great many years.
> 
> There's no reason for DT to be any different in this regard.

I agree, and the fact that we have a bunch of bad bindings in the wild
is a mess which is difficult but necessary to clean up.

Something that helps, is that just as it's possible to support old,
badly-thought out syscalls with a compat shim over newer
implementations, we can in many cases localize handling of bad device
tree bindings to early boot code, so that old bad ideas don't have to
infect every part of every driver.

It would probably be a good idea to implement a DT quirks mechanism,
to be run immediately after unflattening.  That way a driver can just
register a fixup function to patch the DT up to a newer standard,
instead of scattering if (old-style-representation) throughout the
code.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpw9MRSlKdo0.pgp
Description: PGP signature

[PATCH] um: Accept /dev/fd/* uml block devices

[Gabriel de Perthuis]

Useful for
* limiting privileges
* opening block devices O_EXCL

Use dup to work around the fact /proc/self/fd
can't be opened after dropping privileges.
This proc behaviour doesn't match TLPI and might be a bug.

Qemu has a slightly more complex fdset approach
that provides fds with different access permissions.

Signed-off-by: Gabriel de Perthuis 
---
 arch/um/os-Linux/file.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
index c17bd6f..cee65ba 100644
--- a/arch/um/os-Linux/file.c
+++ b/arch/um/os-Linux/file.c
@@ -169,11 +169,11 @@ int os_file_mode(const char *file, struct openflags 
*mode_out)
return err;
 }
 
 int os_open_file(const char *file, struct openflags flags, int mode)
 {
-   int fd, err, f = 0;
+   int fd, fd0, err, f = 0;
 
if (flags.r && flags.w)
f = O_RDWR;
else if (flags.r)
f = O_RDONLY;
@@ -190,11 +190,15 @@ int os_open_file(const char *file, struct openflags 
flags, int mode)
if (flags.e)
f |= O_EXCL;
if (flags.a)
f |= O_APPEND;
 
-   fd = open64(file, f, mode);
+   if (!strncmp(file, "/dev/fd/", 8)
+   && sscanf(file, "/dev/fd/%d", ) == 1)
+   fd = dup(fd0);
+   else
+   fd = open64(file, f, mode);
if (fd < 0)
return -errno;
 
if (flags.cl && fcntl(fd, F_SETFD, 1)) {
err = -errno;
@@ -280,11 +284,11 @@ int os_file_size(const char *file, unsigned long long 
*size_out)
 
if (S_ISBLK(buf.ust_mode)) {
int fd;
long blocks;
 
-   fd = open(file, O_RDONLY, 0);
+   fd = os_open_file(file, of_read(OPENFLAGS()), 0);
if (fd < 0) {
err = -errno;
printk(UM_KERN_ERR "Couldn't open \"%s\", "
   "errno = %d\n", file, errno);
return err;
-- 
1.8.3.3.758.g90e98ff

--
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/

[GIT PULL] SCSI fixes for 3.11-rc2

[James Bottomley]

This is five bug fixes, two of which fix long standing problems causing
crashes (sd and mvsas).  The remaining three are hung (isci race) or
lost (qla2xxx, isci) devices.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Ewan D. Milne (1):
  sd: fix crash when UA received on DIF enabled device

James Bottomley (2):
  isci: fix breakage caused by >16byte CDB patch
  mvsas: Fix kernel panic on tile due to unaligned data access

Jeff Skirvin (1):
  isci: Fix a race condition in the SSP task management path

Saurav Kashyap (1):
  qla2xxx: Properly set the tagging for commands.

The diffstat:

 drivers/scsi/isci/request.c |  2 +-
 drivers/scsi/isci/task.c|  9 ++---
 drivers/scsi/mvsas/mv_sas.c | 11 ---
 drivers/scsi/mvsas/mv_sas.h |  1 +
 drivers/scsi/qla2xxx/qla_iocb.c | 11 +--
 drivers/scsi/sd.c   | 22 +++---
 6 files changed, 32 insertions(+), 24 deletions(-)

And the complete diff is attached below.

James

---

diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index 7b08215..99d2930 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -185,7 +185,7 @@ static void sci_io_request_build_ssp_command_iu(struct 
isci_request *ireq)
cmd_iu->_r_c = 0;
 
sci_swab32_cpy(_iu->cdb, task->ssp_task.cmd->cmnd,
-  task->ssp_task.cmd->cmd_len / sizeof(u32));
+  (task->ssp_task.cmd->cmd_len+3) / sizeof(u32));
 }
 
 static void sci_task_request_build_ssp_task_iu(struct isci_request *ireq)
diff --git a/drivers/scsi/isci/task.c b/drivers/scsi/isci/task.c
index 9bb020a..0d30ca8 100644
--- a/drivers/scsi/isci/task.c
+++ b/drivers/scsi/isci/task.c
@@ -491,6 +491,7 @@ int isci_task_abort_task(struct sas_task *task)
struct isci_tmf   tmf;
int   ret = TMF_RESP_FUNC_FAILED;
unsigned long flags;
+   int   target_done_already = 0;
 
/* Get the isci_request reference from the task.  Note that
 * this check does not depend on the pending request list
@@ -505,9 +506,11 @@ int isci_task_abort_task(struct sas_task *task)
/* If task is already done, the request isn't valid */
if (!(task->task_state_flags & SAS_TASK_STATE_DONE) &&
(task->task_state_flags & SAS_TASK_AT_INITIATOR) &&
-   old_request)
+   old_request) {
idev = isci_get_device(task->dev->lldd_dev);
-
+   target_done_already = test_bit(IREQ_COMPLETE_IN_TARGET,
+  _request->flags);
+   }
spin_unlock(>task_state_lock);
spin_unlock_irqrestore(>scic_lock, flags);
 
@@ -561,7 +564,7 @@ int isci_task_abort_task(struct sas_task *task)
 
if (task->task_proto == SAS_PROTOCOL_SMP ||
sas_protocol_ata(task->task_proto) ||
-   test_bit(IREQ_COMPLETE_IN_TARGET, _request->flags) ||
+   target_done_already ||
test_bit(IDEV_GONE, >flags)) {
 
spin_unlock_irqrestore(>scic_lock, flags);
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index f14665a..6b1b4e9 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -1857,11 +1857,16 @@ int mvs_slot_complete(struct mvs_info *mvi, u32 
rx_desc, u32 flags)
goto out;
}
 
-   /* error info record present */
-   if (unlikely((rx_desc & RXQ_ERR) && (*(u64 *) slot->response))) {
+   /*
+* error info record present; slot->response is 32 bit aligned but may
+* not be 64 bit aligned, so check for zero in two 32 bit reads
+*/
+   if (unlikely((rx_desc & RXQ_ERR)
+&& (*((u32 *)slot->response)
+|| *(((u32 *)slot->response) + 1 {
mv_dprintk("port %d slot %d rx_desc %X has error info"
"%016llX.\n", slot->port->sas_port.id, slot_idx,
-rx_desc, (u64)(*(u64 *)slot->response));
+rx_desc, get_unaligned_le64(slot->response));
tstat->stat = mvs_slot_err(mvi, task, slot_idx);
tstat->resp = SAS_TASK_COMPLETE;
goto out;
diff --git a/drivers/scsi/mvsas/mv_sas.h b/drivers/scsi/mvsas/mv_sas.h
index 60e2fb7..d6b19dc 100644
--- a/drivers/scsi/mvsas/mv_sas.h
+++ b/drivers/scsi/mvsas/mv_sas.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index 42ef481..ef0a548 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -419,6 +419,8 @@ qla2x00_start_scsi(srb_t *sp)
__constant_cpu_to_le16(CF_SIMPLE_TAG);
break;
}
+  

Re: [PATCH] Change request_irq() to use struct net_device *dev->name

[Sergei Shtylyov]

On 27-07-2013 12:58, Prashant Shah wrote:


It's also called managed device API. In fact, I've never heard it
named devres API.



If I understood it correctly it has to just calls
devm_request_region() with the struct device pointer and there are no
deallocation functions to call ? It manages deallocation on it own.


   Yes.


Regards.


WBR, Sergei

--
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] drivers: misc: Add support for ANDROID_PMEM

[Arnd Bergmann]

On Friday 26 July 2013, Greg Kroah-Hartman wrote:
> On Fri, Jul 26, 2013 at 02:53:21PM +0200, Bálint Czobor wrote:
> > Thank you for the info.
> > However some devices still use it, sorry, I haven't seen that commit.
> 
> No modern Android devices should use pmem, only obsolete ones, right?
> That's why the code was removed.
> 
> Do you have a device that requires this?
> 
> You also mixed in a lot of device-specific changes, do you need those to
> be applied?  If so, please make up a separate patch and submit it.

One particular problem is that it adds a dependency between the pmem driver
and the mach-msm directory for header files. This conflicts with the attempt
to remove all global header files from mach-msm, which is needed to support
multiplatform kernels.

Arnd
--
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] x86/PCI: MMCONFIG: cleanup and add address warning to pci_mmconfig_insert

[Yinghai Lu]

On Fri, Jul 26, 2013 at 10:39 AM, Bjorn Helgaas  wrote:
> [+cc Jiang, linux-pci, -cc bjorn.helg...@hp.com (dead address)]
>
> On Fri, Jul 26, 2013 at 05:10:39PM +0800, ethan zhao wrote:
>> Cleanup the -EINVAL return value handling and add warning message
>> for invalid
>> start,end,addr parameters.
>>
>> Signed-off-by: ethan.zhao 
>
> This patch was corrupted, so I couldn't apply it directly.  See
> Documentation/SubmittingPatches, sections 5-7.
>
>> ---
>>  arch/x86/pci/mmconfig-shared.c |   12 ++--
>>  1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
>> index 082e881..37f6c7f 100644
>> --- a/arch/x86/pci/mmconfig-shared.c
>> +++ b/arch/x86/pci/mmconfig-shared.c
>> @@ -700,8 +700,13 @@ int pci_mmconfig_insert(struct device *dev, u16
>> seg, u8 start, u8 end,
>>  if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
>>  return -ENODEV;
>>
>> -if (start > end)
>> +if (start > end || !addr) {
>> +dev_warn(dev, FW_WARN
>> + "Invalid address to add MMCONFIG"
>> + "start %02x end %02x addr %pR\n",
>> +  start, end, addr);
>>  return -EINVAL;
>> +}
>
> I like the "!addr" cleanup.
>
> Did you actually see this problem on a machine?
>
> I expect this would be a BIOS bug, and one that should be found
> early in development, long before a machine is released.
> Therefore, I doubt that it's worth adding another printk for it.
> If an end-user sees this problem, I think we'll already get a
> generic message from check_segment().
>
> I propose the patch below; what do you think?
>
>>
>>  mutex_lock(_mmcfg_lock);
>>  cfg = pci_mmconfig_lookup(seg, start);
>> @@ -716,11 +721,6 @@ int pci_mmconfig_insert(struct device *dev, u16
>> seg, u8 start, u8 end,
>>  return -EEXIST;
>>  }
>>
>> -if (!addr) {
>> -mutex_unlock(_mmcfg_lock);
>> -return -EINVAL;
>> -}
>> -
>>  rc = -EBUSY;
>>  cfg = pci_mmconfig_alloc(seg, start, end, addr);
>>  if (cfg == NULL) {
>
>
>
> Author: ethan.zhao 
> Date:   Fri Jul 26 11:21:24 2013 -0600
>
> x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero
>
> We can check for addr being zero earlier and thus avoid the mutex_unlock()
> cleanup path.
>
> [bhelgaas: changelog, drop printk]
> Signed-off-by: ethan.zhao 
> Signed-off-by: Bjorn Helgaas 
> Acked-by: Yinghai Lu 

looks like I had typo in ack. please update to

Acked-by: Yinghai Lu 

>
> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
> index 082e881..5596c7b 100644
> --- a/arch/x86/pci/mmconfig-shared.c
> +++ b/arch/x86/pci/mmconfig-shared.c
> @@ -700,7 +700,7 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
> start, u8 end,
> if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
> return -ENODEV;
>
> -   if (start > end)
> +   if (start > end || !addr)
> return -EINVAL;
>
> mutex_lock(_mmcfg_lock);
> @@ -716,11 +716,6 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 
> start, u8 end,
> return -EEXIST;
> }
>
> -   if (!addr) {
> -   mutex_unlock(_mmcfg_lock);
> -   return -EINVAL;
> -   }
> -
> rc = -EBUSY;
> cfg = pci_mmconfig_alloc(seg, start, end, addr);
> if (cfg == NULL) {
--
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 v8 07/12] iommu/exynos: support for device tree

[Tomasz Figa]

Hi,

On Friday 26 of July 2013 20:28:36 Cho KyongHo wrote:
> This commit adds device tree support for System MMU.
> This also include the following changes and enhancements:
> 
> * use managed device helper functions.
> Simplyfies System MMU device driver.
> 
> * use only a single clock descriptor.
> System MMU device descriptor is seperate if it is imposible to make
> a single clock descriptor to make a device descriptor for a group of
> System MMUs.
> 
> * removed dbgname member from sysmmu_drvdata structure.
> debugging kernel message for a System MMU is distinguisheable with the
> name of device descroptors.
> 
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/Kconfig|5 +-
>  drivers/iommu/exynos-iommu.c |  182
> -- 2 files changed, 70
> insertions(+), 117 deletions(-)

Whenever you introduce or modify (extend) a device tree binding please 
don't forget about reflecting that in documentation 
(Documentation/devicetree/bindings) and CCing devicetree mailing list 
(devicet...@vger.kernel.org). Both of these steps are necessary to get any 
device tree stuff merged.

Best regards,
Tomasz

--
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: [Xen-devel] [PATCH v6 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Rafael J. Wysocki]

On Monday, July 22, 2013 08:44:08 AM Ben Guthro wrote:
> On Mon, Jul 8, 2013 at 9:08 AM, Ben Guthro  wrote:
> >
> >
> > On 07/08/2013 09:10 AM, Rafael J. Wysocki wrote:
> >> On Sunday, July 07, 2013 08:13:15 PM Ben Guthro wrote:
> >>> On Mon, Jul 1, 2013 at 7:48 AM, Ben Guthro  
> >>> wrote:
>  In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>  reduced hardware sleep support, and the two changes didn't get
>  synchronized: The new code doesn't call the hook function (if so
>  requested). Fix this, requiring a boolean parameter to be added to the
>  hook function to distinguish "extended" from "legacy" sleep.
> 
>  This requires adjusting TXT, but the adjustments only go as far as
>  failing the extended mode call (since, looking at the TXT interface,
>  there doesn't even appear to be precautions to deal with that
>  alternative interface).
> 
>  The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
>  v5 (reduced HW) sleep interface") on the master branch of
>  git://xenbits.xen.org/xen.git.
> 
>  Signed-off-by: Jan Beulich 
>  Signed-off-by: Ben Guthro 
>  Cc: Richard L Maliszewski 
>  Cc: Gang Wei 
>  Cc: Shane Wang 
>  Cc: Bob Moore 
>  Cc: Rafael J. Wysocki 
>  Cc: linux-a...@vger.kernel.org
>  Cc: tboot-de...@lists.sourceforge.net
> 
>  v2: Extend description to include reference to hypervisor side change
>  v3: Split into multiple patches, separating subsystems
>  Remove bool parameters, in favor of u8
>  v4: Remove linux/acpi.h dependencies
>  Further patch split to break out acpica from OSL
>  More bool vs u8 fixes
>  v5: Fix build of consumers of acpi_os_prepare_sleep() interface change,
>  so intermediate builds of partial patch series will not fail.
>  v6: Rebased to linux-pm linux-next branch
>  Added warning in tboot early return code
>  Added Reviewed-by lines
> 
>  Ben Guthro (5):
>    acpi: Remove need to include linux/acpi.h in common acpica code
>    acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
>    acpi/xen/tboot: Adjust linux acpi OS functions to new extended
>  parameter
>    x86/tboot: Fail extended mode reduced hardware sleep
>    xen/acpi: notify xen when reduced hardware sleep is available
> >>>
> >>> Rafael, Bob -
> >>>
> >>> Is this version of the series something that you may consider taking?
> >>> If not - is there something specific you would like to see addressed?
> >>
> >> Well, I'm afraid you need to give us some more time to process that,
> >> sorry.
> >
> > My apologies - I know it is a busy time during the merge window. I did
> > not mean to seem impatient.
> >
> > With the volume of things on the mailing list, I merely wanted to try to
> > avoid the series getting buried. If a week is too frequent to re-bump a
> > series, do you have a set of recommendations of how to best interact
> > with your workflow?
> 
> Rafael (et al.)
> 
> I never heard back on this point of how you prefer your workflow to
> proceed - that is, if I haven't heard anything in a couple weeks -
> should I try to re-bump the thread?
> 
> Since this was sent around the time of the merge window, I realize
> there were other things to occupy people's time.
> Now that rc2 is out - I'm hoping that the dust has settled a bit, such
> that there may be a cycle, or two to review this series.

I've just replied to a [0/5] from a previous series, here:

http://marc.info/?l=linux-acpi=137493312722239=2

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] block: support embedded device command line partition

[Caizhiyong]

From: Cai Zhiyong 

Read block device partition table from command line. This partition used for 
fixed block device (eMMC) embedded device.
It no MBR, can save storage space. Bootloader can be easily accessed by 
absolute address of data on the block device. It support partition name, 
provides partition interface.

This code reference MTD partition, source "./drivers/mtd/cmdlinepart.c"
The format for the command line is just like mtdparts.

Examples: eMMC disk name is "mmcblk0"
bootargs 
'cmdlineparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'

Signed-off-by: Cai Zhiyong 
---
 block/partitions/Kconfig   |   6 +
 block/partitions/Makefile  |   1 +
 block/partitions/check.c   |   4 +
 block/partitions/cmdline.c | 346 +
 block/partitions/cmdline.h |   2 +
 5 files changed, 359 insertions(+)
 create mode 100644 block/partitions/cmdline.c  create mode 100644 
block/partitions/cmdline.h

diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig index 
4cebb2f..2ebf251 100644
--- a/block/partitions/Kconfig
+++ b/block/partitions/Kconfig
@@ -260,3 +260,9 @@ config SYSV68_PARTITION
  partition table format used by Motorola Delta machines (using
  sysv68).
  Otherwise, say N.
+
+config CMDLINE_PARTITION
+   bool "Command line partition support" if PARTITION_ADVANCED
+   help
+ Say Y here if you would read the partitions table from bootargs.
+ The format for the command line is just like mtdparts.
diff --git a/block/partitions/Makefile b/block/partitions/Makefile index 
2be4d7b..4e9d584 100644
--- a/block/partitions/Makefile
+++ b/block/partitions/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_IBM_PARTITION) += ibm.o
 obj-$(CONFIG_EFI_PARTITION) += efi.o
 obj-$(CONFIG_KARMA_PARTITION) += karma.o
 obj-$(CONFIG_SYSV68_PARTITION) += sysv68.o
+obj-$(CONFIG_CMDLINE_PARTITION) += cmdline.o
diff --git a/block/partitions/check.c b/block/partitions/check.c index 
19ba207..9ac1df7 100644
--- a/block/partitions/check.c
+++ b/block/partitions/check.c
@@ -34,6 +34,7 @@
 #include "efi.h"
 #include "karma.h"
 #include "sysv68.h"
+#include "cmdline.h"
 
 int warn_no_part = 1; /*This is ugly: should make genhd removable media aware*/
 
@@ -65,6 +66,9 @@ static int (*check_part[])(struct parsed_partitions *) = {
adfspart_check_ADFS,
 #endif
 
+#ifdef CONFIG_CMDLINE_PARTITION
+   cmdline_partition,
+#endif
 #ifdef CONFIG_EFI_PARTITION
efi_partition,  /* this must come before msdos */
 #endif
diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c new file 
mode 100644 index 000..05c7e17
--- /dev/null
+++ b/block/partitions/cmdline.c
@@ -0,0 +1,346 @@
+/*
+ * Copyright (C) 2013 HUAWEI
+ * Author: Cai Zhiyong 
+ *
+ * Read block device partition table from command line.
+ * Design the partition for eMMC device.
+ * This code reference MTD partition, source "./drivers/mtd/cmdlinepart.c"
+ * The format for the command line is just like mtdparts.
+ *
+ * Examples:
+ *
+ * eMMC disk name is "mmcblk0"
+ * bootargs:
+ * 'cmdlineparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "check.h"
+#include "cmdline.h"
+
+#define SIZE_REMAINING  ULLONG_MAX
+#define OFFSET_CONTINUOUS   ULLONG_MAX
+
+struct cmdline_subpart {
+   char name[BDEVNAME_SIZE]; /* partition name, such as 'rootfs' */
+   uint64_t from;
+   uint64_t size;
+   struct cmdline_subpart *next_subpart;
+};
+
+struct cmdline_parts {
+   char name[BDEVNAME_SIZE]; /* block device, such as 'mmcblk0' */
+   struct cmdline_subpart *subpart;
+   struct cmdline_parts *next_parts;
+};
+
+static DEFINE_MUTEX(cmdline_string_mutex);
+
+static char cmdline_string[512] = { 0 }; static struct cmdline_parts 
+*cmdline_parts;
+
+static int parse_subpart(struct cmdline_subpart **subpart, char
+*cmdline) {
+   int ret = 0;
+   struct cmdline_subpart *new_subpart;
+
+   (*subpart) = NULL;
+
+   new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
+   if (!new_subpart)
+   return -ENOMEM;
+
+   if ((*cmdline) == '-') {
+   new_subpart->size = SIZE_REMAINING;
+   cmdline++;
+   } else {
+   new_subpart->size = memparse(cmdline, );
+   if (new_subpart->size < PAGE_SIZE) {
+   pr_warn("cmdline partition size is invalid.");
+   ret = -EFAULT;
+   goto fail;
+   }
+   }
+
+   if ((*cmdline) == '@') {
+   cmdline++;
+   new_subpart->from = memparse(cmdline, );
+   } else {
+   new_subpart->from = OFFSET_CONTINUOUS;
+   }
+
+   if ((*cmdline) == '(') {
+
+   int length;
+   char *next = strchr(++cmdline, ')');
+
+   if (!next) {
+   pr_warn("cmdline 

Re: [PATCH v5 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Rafael J. Wysocki]

On Friday, June 28, 2013 09:46:19 AM Ben Guthro wrote:
> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
> reduced hardware sleep support, and the two changes didn't get
> synchronized: The new code doesn't call the hook function (if so
> requested). Fix this, requiring a boolean parameter to be added to the
> hook function to distinguish "extended" from "legacy" sleep.
> 
> This requires adjusting TXT, but the adjustments only go as far as
> failing the extended mode call (since, looking at the TXT interface,
> there doesn't even appear to be precautions to deal with that
> alternative interface).
> 
> The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
> v5 (reduced HW) sleep interface") on the master branch of
> git://xenbits.xen.org/xen.git.
> 
> Signed-off-by: Jan Beulich 
> Signed-off-by: Ben Guthro 
> Cc: Richard L Maliszewski 
> Cc: Gang Wei 
> Cc: Shane Wang 
> Cc: Bob Moore 
> Cc: Rafael J. Wysocki 
> Cc: linux-a...@vger.kernel.org
> Cc: tboot-de...@lists.sourceforge.net 
> 
> v2: Extend description to include reference to hypervisor side change
> v3: Split into multiple patches, separating subsystems
> Remove bool parameters, in favor of u8
> v4: Remove linux/acpi.h dependencies
> Further patch split to break out acpica from OSL
> More bool vs u8 fixes
> v5: Fix build of consumers of acpi_os_prepare_sleep() interface change,
> so intermediate builds of partial patch series will not fail.
> 
> Ben Guthro (5):
>   acpi: Remove need to include linux/acpi.h in common acpica code
>   acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
>   acpi: Adjust linux acpi OS functions to new extended parameter
>   x86/tboot: Fail extended mode reduced hardware sleep
>   xen/acpi: notify xen when reduced hardware sleep is available

I've just replied to [0/5] from the previous series, here:

http://marc.info/?l=linux-acpi=137493312722239=2

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 v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs

[Rob Herring]

On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo  wrote:
> Signed-off-by: Cho KyongHo 
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
>  arch/arm/boot/dts/exynos4.dtsi |  122 
>  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
>  arch/arm/boot/dts/exynos5250.dtsi  |  291 
> 
>  5 files changed, 617 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> new file mode 100644
> index 000..92f0a33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> @@ -0,0 +1,103 @@
> +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> +
> +Samsung's Exynos architecture contains System MMU that enables scattered
> +physical memory chunks visible as a contiguous region to DMA-capable 
> peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table format 
> to
> +ARMv7 translation tables with minimum set of page properties including access
> +permissions, shareability and security protection. In addition, System MMU 
> has
> +another capabilities like L2 TLB or block-fetch buffers to minimize 
> translation
> +latency.
> +
> +A System MMU is dedicated to a single master peripheral device.  Thus, it is
> +important to specify the correct System MMU in the device node of its master
> +device. Whereas a System MMU is dedicated to a master device, the master 
> device
> +may have more than one System MMU.

I don't follow the last sentence. Can you elaborate on the type of
connection you are talking about.

Also, please align with the ARM system MMU binding that Will Deacon
has submitted particularly in terms of how master connections are
described.

Rob

> +
> +Required properties:
> +- compatible: Should be "samsung,exynos4210-sysmmu"
> +- reg: A tuple of base address and size of System MMU registers.
> +- interrupt-parent: The phandle of the interrupt controller of System MMU
> +- interrupts: A tuple of numbers that indicates the interrupt source.
> +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its 
> clock.
> +   Please refer to the following documents:
> +  Documentation/devicetree/bindings/clock/clock-bindings.txt
> +  Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +  Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +  Optional "master" if the clock to the System MMU is gated by
> +  another gate clock other than "sysmmu". The System MMU driver
> +  sets "master" the parent of "sysmmu".
> +  Exynos4 SoCs, there needs no "master" clocks.
> +  Exynos5 SoCs, some System MMUs must have "master" clocks.
> +- clocks: Required if the System MMU is needed to gate its clock.
> + Please refer to the documents listed above.
> +- samsung,power-domain: Required if the System MMU is needed to gate its 
> power.
> + Please refer to the following document:
> + Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +
> +Required properties for the master peripheral devices:
> +- iommu: phandles to the System MMUs of the device
> +
> +Examples:
> +A System MMU is dedicated to a single master device.
> +   gsc_0:  gsc@0x13e0 {
> +   compatible = "samsung,exynos5-gsc";
> +   reg = <0x13e0 0x1000>;
> +   interrupts = <0 85 0>;
> +   samsung,power-domain = <_gsc>;
> +   clocks = < 256>;
> +   clock-names = "gscl";
> +   iommu = <_gsc1>;
> +   };
> +
> +   sysmmu_gsc0: sysmmu@13E8 {
> +   compatible = "samsung,exynos4210-sysmmu";
> +   reg = <0x13E8 0x1000>;
> +   interrupt-parent = <>;
> +   interrupt-names = "sysmmu-gsc0";
> +   interrupts = <2 0>;
> +   clock-names = "sysmmu", "master";
> +   clocks = < 262>, < 256>;
> +   samsung,power-domain = <_gsc>;
> +   status = "ok";
> +   };
> +
> +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems 
> natural
> +to define 2 System MMUs for each port of the MFC:
> +
> +   mfc: codec@1340 {
> +   compatible = "samsung,mfc-v5";
> +   reg = <0x1340 0x1>;
> +   interrupts = <0 94 0>;
> +   samsung,power-domain = <_mfc>;
> +   clocks = < 170>, < 273>;
> +   clock-names = "sclk_mfc", "mfc";
> +   status = "ok";
> +   

Re: [PATCH v4 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Rafael J. Wysocki]

On Thursday, June 27, 2013 11:01:58 AM Ben Guthro wrote:
> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
> reduced hardware sleep support, and the two changes didn't get
> synchronized: The new code doesn't call the hook function (if so
> requested). Fix this, requiring a boolean parameter to be added to the
> hook function to distinguish "extended" from "legacy" sleep.
> 
> This requires adjusting TXT, but the adjustments only go as far as
> failing the extended mode call (since, looking at the TXT interface,
> there doesn't even appear to be precautions to deal with that
> alternative interface).
> 
> The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
> v5 (reduced HW) sleep interface") on the master branch of
> git://xenbits.xen.org/xen.git.
> 
> Signed-off-by: Ben Guthro 
> Signed-off-by: Jan Beulich 
> Cc: Richard L Maliszewski 
> Cc: Gang Wei 
> Cc: Shane Wang 
> Cc: Bob Moore 
> Cc: Rafaell J. Wysocki 
> Cc: linux-a...@vger.kernel.org
> Cc: tboot-de...@lists.sourceforge.net 
> 
> v2: Extend description to include reference to hypervisor side change
> v3: Split into multiple patches, separating subsystems
> Remove bool parameters, in favor of u8
> v4: Remove linux/acpi.h dependencies
> Further patch split to break out acpica from OSL
> More bool vs u8 fixes
> 
> Ben Guthro (5):
>   acpi: Remove need to include linux/acpi.h in common acpica code
>   acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
>   acpi: Adjust linux acpi OS functions to new extended parameter
>   x86/tboot: Fail extended mode reduced hardware sleep
>   xen/acpi: notify xen when reduced hardware sleep is available

The ongoing discussion means to me that the ACPICA maintainers don't want
acpi_os_prepare_sleep() and quite frankly I understand them, because ACPICA
is about implementing the spec and not about things beyond it.

This means that patch [1/5] goes away.

That said, at the same time we need to address the problem at hand, which
is to make Xen work with the reduced HW sleep.

For that, I don't honestly think that modifying acpi_os_prepare_sleep() the
way the patchset is doing it is appropriate and the change of the meaning of
the arguments is simply disgusting.

To me, it would be much cleaner to add acpi_os_prepare_extended_sleep()
specifically to be called by acpi_hw_extended_sleep() and make tboot and Xen
use that.

This way or another, we'll need to live with one more divergence between the
upstream ACPICA and the Linux ACPICA code because of that, but that'd be just
a few added lines in acpi_hw_extended_sleep(), so I suppose it wouldn't be
such a big deal.

Thanks,
Rafael


-- 
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: kisskb: sparc-allmodconfig is actually sparc64

[Michael Ellerman]

On Fri, 2013-07-26 at 12:23 +0200, Geert Uytterhoeven wrote:
> Hi Michael, Stephen,
> 
> The sparc-allmodconfig builds on http://kisskb.ellerman.id.au/kisskb/matrix/
> seem to be sparc64, not sparc32, allmodconfig builds.
> The sparc-allnoconfig builds are sparc32.

Ah right, we seem to have sparc and sparc64 builds, but there is only
arch/sparc now.

We'll have to sort that out next week.

> BTW, what's the simplest way to make an all*config build with fixed sparc32 or
> sparc64?

I think you can do it with KCONFIG_ALLCONFIG.

cheers

--
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: [ipc,shm] BUG: lock held when returning to user space!

[Fengguang Wu]

On Sat, Jul 20, 2013 at 09:46:45AM -0700, Davidlohr Bueso wrote:
> On Sun, 2013-07-21 at 00:02 +0800, Xiaotian Feng wrote:
> > On Sat, Jul 20, 2013 at 9:13 PM, Fengguang Wu  
> > wrote:
> > > Greetings,
> > >
> > > I got the below dmesg and the first bad commit is
> > >
> > > commit c5d0282a0405b0a81fa3390e4230e4cbb3ced7a2
> > > Author: Davidlohr Bueso 
> > > Date:   Fri Jul 19 09:56:58 2013 +1000
> > >
> > > ipc,shm: shorten critical region for shmat
> > >
> > > Similar to other system calls, acquire the kern_ipc_perm lock after 
> > > doing
> > > the initial permission and security checks.
> > >
> > > Signed-off-by: Davidlohr Bueso 
> > > Tested-by: Sedat Dilek 
> > > Cc: Rik van Riel 
> > > Cc: Manfred Spraul 
> > > Signed-off-by: Andrew Morton 
> > >
> > > [   20.702156]
> > > [   20.702493] 
> > > [   20.703511] [ BUG: lock held when returning to user space! ]
> > > [   20.704532] 3.11.0-rc1-next-20130719 #50 Not tainted
> > > [   20.705416] 
> > > [   20.706425] trinity-child0/174 is leaving the kernel with locks still 
> > > held!
> > > [   20.707638] 1 lock held by trinity-child0/174:
> > > [   20.708475]  #0:  (rcu_read_lock){.+.+..}, at: [] 
> > > do_shmat+0xe1/0x500
> > >
> > 
> > 
> > ns = current->nsproxy->ipc_ns;
> > - shp = shm_lock_check(ns, shmid);
> > + rcu_read_lock();
> > + shp = shm_obtain_object_check(ns, shmid);
> > if (IS_ERR(shp)) {
> > err = PTR_ERR(shp);
> > goto out;
> > 
> > 
> > If shm_obtain_object_check() failed, goto out will return with
> > rcu_read_lock() held.  I think following patch should cure this.
> 
> Yep that should solve it, sorry about that. Sasha Levin sent out a fix
> for it yesterday (offline).

What's the patch's status? The bug is still there in linux-next 20130726.

Thanks,
Fengguang
--
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/