darlehen

[Darlehen Unternehmen]

Guten Tag Darlehen Antragsteller, Beantragen Sie jetzt Ihre 2% niedrigeren 
Zinssatz Darlehen. die unten stehenden folgende bei Interesse: 
Name: 
Darlehensbetrag : 
Dauer: 
Telefonnummer: 
Grüßen,
Jenny

--
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] mfd: mc13xxx: Move definitions out of structures

[Alexander Shiyan]

Signed-off-by: Alexander Shiyan 
---
 include/linux/mfd/mc13xxx.h | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
index a326c85..d63b1d3 100644
--- a/include/linux/mfd/mc13xxx.h
+++ b/include/linux/mfd/mc13xxx.h
@@ -117,10 +117,6 @@ struct mc13xxx_led_platform_data {
 
 #define MAX_LED_CONTROL_REGS   6
 
-struct mc13xxx_leds_platform_data {
-   struct mc13xxx_led_platform_data *led;
-   int num_leds;
-
 /* MC13783 LED Control 0 */
 #define MC13783_LED_C0_ENABLE  (1 << 0)
 #define MC13783_LED_C0_TRIODE_MD   (1 << 7)
@@ -169,10 +165,13 @@ struct mc13xxx_leds_platform_data {
 /* MC34708 LED Control 0 */
 #define MC34708_LED_C0_CURRENT_R(x)(((x) & 0x3) << 9)
 #define MC34708_LED_C0_CURRENT_G(x)(((x) & 0x3) << 21)
+
+struct mc13xxx_leds_platform_data {
+   struct mc13xxx_led_platform_data *led;
+   int num_leds;
u32 led_control[MAX_LED_CONTROL_REGS];
 };
 
-struct mc13xxx_buttons_platform_data {
 #define MC13783_BUTTON_DBNC_0MS0
 #define MC13783_BUTTON_DBNC_30MS   1
 #define MC13783_BUTTON_DBNC_150MS  2
@@ -180,6 +179,8 @@ struct mc13xxx_buttons_platform_data {
 #define MC13783_BUTTON_ENABLE  (1 << 2)
 #define MC13783_BUTTON_POL_INVERT  (1 << 3)
 #define MC13783_BUTTON_RESET_EN(1 << 4)
+
+struct mc13xxx_buttons_platform_data {
int b1on_flags;
unsigned short b1on_key;
int b2on_flags;
@@ -188,14 +189,14 @@ struct mc13xxx_buttons_platform_data {
unsigned short b3on_key;
 };
 
+#define MC13783_TS_ATO_FIRST   false
+#define MC13783_TS_ATO_EACHtrue
+
 struct mc13xxx_ts_platform_data {
/* Delay between Touchscreen polarization and ADC Conversion.
 * Given in clock ticks of a 32 kHz clock which gives a granularity of
 * about 30.5ms */
u8 ato;
-
-#define MC13783_TS_ATO_FIRST false
-#define MC13783_TS_ATO_EACH  true
/* Use the ATO delay only for the first conversion or for each one */
bool atox;
 };
@@ -210,11 +211,12 @@ struct mc13xxx_codec_platform_data {
enum mc13783_ssi_port dac_ssi_port;
 };
 
-struct mc13xxx_platform_data {
-#define MC13XXX_USE_TOUCHSCREEN (1 << 0)
+#define MC13XXX_USE_TOUCHSCREEN(1 << 0)
 #define MC13XXX_USE_CODEC  (1 << 1)
 #define MC13XXX_USE_ADC(1 << 2)
 #define MC13XXX_USE_RTC(1 << 3)
+
+struct mc13xxx_platform_data {
unsigned int flags;
 
struct mc13xxx_regulator_platform_data regulators;
-- 
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: linux-next: build failure after merge of the driver-core tree

[Benjamin Herrenschmidt]

On Sat, 2014-03-15 at 05:29 +, Greg KH wrote:
> Just take my tree, it's not a big deal, I'll merge first with Linus if
> you want and then everything is simple.

Yup, I'll do that. Thanks.

Cheers,
Ben.


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

Re: [PATCH v3 1/2] Staging: comedi: convert while loops to timeouts in s626.c

[Chase Southwood]

>On Saturday, March 15, 2014 12:26 AM, "gre...@linuxfoundation.org" 
> wrote:

>>On Fri, Mar 14, 2014 at 06:43:37PM -0700, Chase Southwood wrote:
>>>On Tuesday, March 11, 2014 9:26 AM, Ian Abbott  wrote:
On 2014-03-09 04:00, Chase Southwood wrote:
 This patch changes a handful of while loops to timeouts to prevent
 infinite looping on hardware failure. A couple such loops are in a
 function (s626_debi_transfer()) which is called from critical sections,
 so comedi_timeout() is unusable for them, and an iterative timeout is
 used instead. For the while loops in a context where comedi_timeout() is
 allowed, a new callback function, s626_send_dac_eoc(), has been defined
 to evaluate the conditions that the while loops are testing.  The new
 callback employs a switch statement based on a simple new enum so that
 it is usable for all of the different conditions tested in while loops
 in s626_send_dac().  The proper comedi_timeout() calls are then used.

 Signed-off-by: Chase Southwood 
 ---
 Ian, here is a version of this patchset employing the enum you recommended.
 The second patch has been rebased on top of this one.

 2: Used comedi_timeout() where appropriate, introduce callback function

 3: Updated callback to switch on new enum.>
>>>
>>>Reviewed-by: Ian Abbott 
>>>
>>>For future reference, for patches affecting a single comedi driver, we 
>>>usually title the patches like this:
>>>
>>>staging: comedi: name_of_driver: summary of patch
>>>
>>
>>
>>Hi Greg!
>>
>>I was just writing to inquire whether you were able to add this patch as well 
>>as
>>PATCH 2/2 Propagate timeout errors in s626.c, to your queue in their current 
>>state.
>>I had to resend this patch to you about a week ago because the subject line 
>>got
>>a little messed up, which might have lead to a bit of confusion regarding the 
>>2
>>patch series, and I wanted to check in to see whether you need me to do 
>>anything
>>further.
>
>I've been on vacation this week and will dig through my huge patch queue
>next week.  Then I will need another vacation...
>
>Give me a chance to catch up, I'll let you know if I have problems with
>them.>
>
>thanks,
>
>greg k-h

Greg,

Oh shoot, my apologies.  I don't mean to rush you at all!  I'll chill out a 
bit...

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

Re: [PATCH] staging: comedi: fix memory leak

[Chase Southwood]

>On Saturday, March 15, 2014 1:55 AM, Levente Kurusa  wrote:

>>On 03/15/2014 04:30 AM, Chase Southwood wrote:
>>> On Friday, March 14, 2014 11:47 AM, Levente Kurusa  wrote:
>>> 
>>>Call kfree() on bdev. The variable is otherwise leaked.
>>>
>>>Signed-off-by: Levente Kurusa 
>>>[...]
>>>
>>
>>
>>Levente,
>>
>>This change has already been made in staging-next (by me, actually :) ).  In
>>order to avoid re-doing work which has already been done, please make sure to 
>>base
>>all of your patches off of linux-next (or for staging, staging-next).
>>
>>Thanks,
>>Chase
>>
>
>Ah, yes I see now. I wonder how it didn't reach my tree.
>Anyways, thanks for the heads up!
>
>-- 
>Regards,
>Levente Kurusa


No problem, just wanted to make sure you were working from an up-to-date tree :)

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

[RFC] ktest doc: Automated test of linux kernel by using ktest

[Satoru Takeuchi]

Hi,

I wrote a ktest document and published it.

http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

It's not the ktest reference guild, but the quick learning guild of ktest
especially focuses on some important features.

After reading this document, you'll be able to do the following work 
automatically.

 - test all patches of your patchset, and
 - bisect to find the problematic commit

I believe it saves plenty of your time.

Feel free to ask me if you have any comments/questions.

Thanks,
Satoru
--
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] gpio: davinci: fix gpio selection for OF

[Alexander Holler]

Am 14.03.2014 20:52, schrieb Linus Walleij:


So a few Tested-by's from the people using this driver would for
example convince me that it is solving a real problem for them
and it needs to go into fixes.


2001: a space odyssey is fast action movie compared with the movie 
kernel bug fixing. And 2001 is a masterpiece of slowness.


Regards,

Alexander Holler

--
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] sparc: use %s for unaligned panic

[Sam Ravnborg]

On Tue, Mar 11, 2014 at 01:24:46PM -0700, Kees Cook wrote:
> Since unaligned_panic() takes a literal string, make sure it can never
> accidentally be used as a format string.
> 
> Signed-off-by: Kees Cook 
> ---
>  arch/sparc/kernel/unaligned_32.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/kernel/unaligned_32.c 
> b/arch/sparc/kernel/unaligned_32.c
> index c0ec89786193..892e399414e0 100644
> --- a/arch/sparc/kernel/unaligned_32.c
> +++ b/arch/sparc/kernel/unaligned_32.c
> @@ -162,7 +162,7 @@ unsigned long safe_compute_effective_address(struct 
> pt_regs *regs,
>  /* This is just to make gcc think panic does return... */
>  static void unaligned_panic(char *str)
>  {
> - panic(str);
> + panic("%s", str);
>  }
>  
>  /* una_asm.S */

Another "fix" would be to align with sparc64 and call die_if_kernel()

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

Re: [PATCH v4 2/4] arm64: dts: APM X-Gene PCIe device tree nodes

[Arnd Bergmann]

On Saturday 15 March 2014, Tanmay Inamdar wrote:
> On Fri, Mar 14, 2014 at 5:07 AM, Arnd Bergmann  wrote:
> > On Thursday 06 March 2014, Tanmay Inamdar wrote:
> >> + pcie0: pcie@1f2b {
> >> + status = "disabled";
> >> + device_type = "pci";
> >> + compatible = "apm,xgene-storm-pcie", 
> >> "apm,xgene-pcie";
> >> + #interrupt-cells = <1>;
> >> + #size-cells = <2>;
> >> + #address-cells = <3>;
> >> + reg = < 0x00 0x1f2b 0x0 0x0001   /* 
> >> Controller registers */
> >> + 0xe0 0xd000 0x0 0x0020>; /* PCI 
> >> config space */
> >> + reg-names = "csr", "cfg";
> >> + ranges = <0x0100 0x00 0x 0xe0 0x 
> >> 0x00 0x0001   /* io */
> >> +   0x0200 0x00 0x1000 0xe0 0x1000 
> >> 0x00 0x8000>; /* mem */
> >> + dma-ranges = <0x4200 0x40 0x 0x40 
> >> 0x 0x40 0x>;
> >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
> >> +  0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
> >> +  0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
> >> +  0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
> >> + clocks = <&pcie0clk 0>;
> >> + };
> >
> > Is 0x40.0x the start of your RAM? I had expected RAM to start at 
> > 0.0,
> > and in that case the dma-ranges property would be wrong.
> 
> RAM starting address is 0x40_.

Ok, it's good then. Thanks for the clarification, I keep losing track of how 
each of
the ~40 SoCs I'm dealing with handles these things.

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 1/1] fs/mpage.c: forgotten WRITE_SYNC in case of data integrity write

[Christoph Hellwig]

On Fri, Mar 14, 2014 at 10:54:30AM -0400, Tejun Heo wrote:
> This is a bit surprising tho.  Were we always like this?  We never had
> even stupid "flush down everything and sync"?  Or is this something we
> broke while morphing flush implementation several times in the past
> years?

It's something that never worked in Linux.  Until XFS went ahead and
enabled barriers by default no filesystem in Linux ever flushed the
volatile cache by default, and most couldn't (and still can't) even if
you asked them to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH v2 3/4] ASoC: simple-card: accept many DAI links

[Jyri Sarha]

On 2014-03-14 20:40, Jean-Francois Moine wrote:

On Fri, 14 Mar 2014 13:16:12 +0200
Jyri Sarha  wrote:


On 03/11/2014 11:36 AM, Jean-Francois Moine wrote:
> Some simple audio cards may have many DAI links.
> This patch extends the simple-card driver for handling such cards.
>
> Signed-off-by: Jean-Francois Moine 
> ---
[...]

Why can't you just use two simple-card instances in your setup?


My machine has only one audio device (kirkwood). This one has two
outputs. The first one (I2S) is connected to the HDMI transmitter, and
the other one (S/PDIF) is connected to both the HDMI transmitter and 
the

S/PDIF connector. There can be only one playback stream, either via
I2S, or S/PDIF, or both, with the final output either to HDMI or S/PDIF
or both:

   /--> I2S -+-> HDMI
platform -+ /
   \-> S/PDIF -+
\--> S/PDIF

DPCM permits to activate both I2S and S/PDIF, but it does not handle
the format and rate constraints (both outputs are always activated with
the platform constraints).

So, the actual solution I use is 3 DAI links (= 3 PCMs):
- HDMI via I2S
- HDMI via S/PDIF (no S/PDIF output)
- S/PDIF via S/PDIF (no HDMI output)



Maybe a HW specific machine-driver would serve your case better. Of 
course it would be great to have a generic implementation that can 
handle this case too, but I am not sure if it should be called a 
simple-card anymore :).


You need to update the DT-binding document too when you are changing 
the
binding. That way it would also be easier to follow what you are 
trying

to accomplish here.


Some people want to have 2 different patchs: one for the code and the
other one for the DT change. Some other people like you want only one
patch. Which is the right way?



I did not mean it should be in the same patch. Part of the same series 
is fine with me. It is up to maintainer to decide these things anyway. I 
would just like to compare the document with the implementation.



The sysclk and tdm properties appear to only work in the dais of the
first dai-link and __asoc_simple_card_dai_init() will not be called 
for

other dais at all. The DT-binding of this implementation would look
pretty hairy to me.


I will add an other dynamic structure for these properties.


Best regards,
Jyri
--
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] PHY: Exynos: fix SATA phy license typo

[Arnd Bergmann]

If the license string doesn't match exactly, the module refuses to load.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/phy/phy-exynos5250-sata.c 
b/drivers/phy/phy-exynos5250-sata.c
index c9361b7..0568945 100644
--- a/drivers/phy/phy-exynos5250-sata.c
+++ b/drivers/phy/phy-exynos5250-sata.c
@@ -246,6 +246,6 @@ static struct platform_driver exynos_sata_phy_driver = {
 module_platform_driver(exynos_sata_phy_driver);
 
 MODULE_DESCRIPTION("Samsung SerDes PHY driver");
-MODULE_LICENSE("GPL V2");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Girish K S ");
 MODULE_AUTHOR("Yuvaraj C D ");
--
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] zram: include linux/err.h

[Arnd Bergmann]

The zram driver uses the ERR_PTR macro defined in 
and relies on this header to be included implicitly through
other headers, which is not (always) the case on the ARM architecture.

Adding an explicit #include allows us to build the driver in
all configurations.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 92a83df..3507bef 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -7,6 +7,7 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
--
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] Xen: include asm/page.h in xen-ops.h

[Arnd Bergmann]

The declaration of xen_remap_domain_mfn_range relies on the
pgprot_t typedef to be visible. In some configurations, that
may not already have been seen, and I have encountered a
bug during randconfig testing on ARM.

Adding an explicit #include for asm/page.h fixes the problem.

Signed-off-by: Arnd Bergmann 

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6d8c042..b8ad234 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] net: phy: fix uninitalized WOL parameters in phy_ethtool_get_wol

[Sebastian Hesselbarth]

On 03/13/2014 08:38 PM, David Miller wrote:

From: Sebastian Hesselbarth 
Date: Wed, 12 Mar 2014 00:02:55 +0100

[...]

To fix this, always zero relevant fields of struct ethtool_wolinfo
regardless of .get_wol callback availability.

[...]

I'm starting to see this situation more clearly now, especially with
Ben's most recent commentary.

The basic notion is that one must do ethtool ops are designed such that
the top-level execution context in net/core/ethtool.c takes care of
initializing the structure.

In this case, we're referring specifically to ethtool_get_wol(), which
runs any time ETHTOOL_GWOL is requested.

Therefore no ethtool_ops->get_wol() implementation should duplicate
this work, that goes for all of such cases which invoke the function
we are talking about here, phy_ethtool_get_wol().

So the first change is definitely to remove:

wol->supported = 0;
wol->wolopts = 0;

from:

drivers/net/ethernet/marvell/mv643xx_eth.c:mv643xx_eth_get_wol()
drivers/net/ethernet/ti/cpsw.c:cpsw_get_wol()


[...]


Finally, purge the spurious clears in phydev_ops->get_wol(), namely
in at803x_get_wol() and m88e1318_get_wol().


David,

I was preparing cleanups for mv643xx_eth, cpsw, at803x, and mv88e1318.

Out of curiosity, I did a

git grep "wol->" drivers/net/ | grep "= 0" | wc -l
29

and found some other "spurious clears" ;)

I can go that road and remove/rework all those clears. Some are really
easy, some would require some more rework (e.g. e1000).

Of course, a lot of those drivers then will need a Tested-by, as I
don't have the HW available.


So, to reiterate, OPS never have to be mindful of initializing the
ethtool result with zeros.  However, anyone who calls into OPS
directly must provide said expected state.


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

[PATCH 1/1] fs/ceph/inode.c: Remove get/set acl on symlinks

[Fabian Frederick]

Remove unsupported symlink operations.

Signed-off-by: Fabian Frederick 
---
 fs/ceph/inode.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
index 32d519d..704d714 100644
--- a/fs/ceph/inode.c
+++ b/fs/ceph/inode.c
@@ -1616,8 +1616,6 @@ static const struct inode_operations ceph_symlink_iops = {
.getxattr = ceph_getxattr,
.listxattr = ceph_listxattr,
.removexattr = ceph_removexattr,
-   .get_acl = ceph_get_acl,
-   .set_acl = ceph_set_acl,
 };
 
 /*
-- 
1.8.4.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/

[PATCH] powerpc/mm: Make sure a local_irq_disable prevent a parallel THP split

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

We have generic code like the one in get_futex_key that assume that
a local_irq_disable prevents a parallel THP split. Support that by
adding a dummy smp call function after setting _PAGE_SPLITTING. Code
paths like get_user_pages_fast still need to check for _PAGE_SPLITTING
after disabling IRQ which indicate that a parallel THP splitting is
ongoing. Now if they don't find _PAGE_SPLITTING set, then we can be
sure that parallel split will now block in pmdp_splitting flush
until we enables IRQ

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/pgtable_64.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 62bf5e8e78da..f6ce1f111f5b 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -647,6 +647,11 @@ void pmdp_splitting_flush(struct vm_area_struct *vma,
if (old & _PAGE_HASHPTE)
hpte_do_hugepage_flush(vma->vm_mm, address, pmdp);
}
+   /*
+* This ensures that generic code that rely on IRQ disabling
+* to prevent a parallel THP split work as expected.
+*/
+   kick_all_cpus_sync();
 }
 
 /*
-- 
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] virtio-blk: make the queue depth the max supportable by the hypervisor

[Konrad Rzeszutek Wilk]

On March 14, 2014 11:34:31 PM EDT, Theodore Ts'o  wrote:
>The current virtio block sets a queue depth of 64, which is
>insufficient for very fast devices.  It has been demonstrated that
>with a high IOPS device, using a queue depth of 256 can double the
>IOPS which can be sustained.
>
>As suggested by Venkatash Srinivas, set the queue depth by default to
>be one half the the device's virtqueue, which is the maximum queue
>depth that can be supported by the channel to the host OS (each I/O
>request requires at least two VQ entries).
>
>Also allow the queue depth to be something which can be set at module
>load time or via a kernel boot-time parameter, for
>testing/benchmarking purposes.
>
>Signed-off-by: "Theodore Ts'o" 
>Signed-off-by: Venkatesh Srinivas 
>Cc: Rusty Russell 
>Cc: "Michael S. Tsirkin" 
>Cc: virtio-...@lists.oasis-open.org
>Cc: virtualizat...@lists.linux-foundation.org
>Cc: Frank Swiderski 
>---
>
>This is a combination of my patch and Vekatash's patch.  I agree that
>setting the default automatically is better than requiring the user to
>set the value by hand.
>
> drivers/block/virtio_blk.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>index 6a680d4..0f70c01 100644
>--- a/drivers/block/virtio_blk.c
>+++ b/drivers/block/virtio_blk.c
>@@ -481,6 +481,9 @@ static struct blk_mq_ops virtio_mq_ops = {
>   .free_hctx  = blk_mq_free_single_hw_queue,
> };
> 
>+static int queue_depth = -1;
>+module_param(queue_depth, int, 0444);

?

>+
> static struct blk_mq_reg virtio_mq_reg = {
>   .ops= &virtio_mq_ops,
>   .nr_hw_queues   = 1,
>@@ -551,9 +554,14 @@ static int virtblk_probe(struct virtio_device
>*vdev)
>   goto out_free_vq;
>   }
> 
>+  virtio_mq_reg.queue_depth = queue_depth > 0 ? queue_depth :
>+  (vblk->vq->num_free / 2);
>   virtio_mq_reg.cmd_size =
>   sizeof(struct virtblk_req) +
>   sizeof(struct scatterlist) * sg_elems;
>+  virtblk_name_format("vd", index, vblk->disk->disk_name,
>DISK_NAME_LEN);
>+  pr_info("%s: using queue depth %d\n", vblk->disk->disk_name,
>+  virtio_mq_reg.queue_depth);

Isn't that visible from sysfs?
> 
>   q = vblk->disk->queue = blk_mq_init_queue(&virtio_mq_reg, vblk);
>   if (!q) {
>@@ -565,8 +573,6 @@ static int virtblk_probe(struct virtio_device
>*vdev)
> 
>   q->queuedata = vblk;
> 
>-  virtblk_name_format("vd", index, vblk->disk->disk_name,
>DISK_NAME_LEN);
>-
>   vblk->disk->major = major;
>   vblk->disk->first_minor = index_to_minor(index);
>   vblk->disk->private_data = vblk;


--
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: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12

[Kyungmin Park]

On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa  wrote:
> Hi Chanwoo, Mark,
>
>
> On 14.03.2014 11:56, Chanwoo Choi wrote:
>>
>> Hi Mark,
>>
>> On 03/14/2014 07:35 PM, Mark Rutland wrote:
>>>
>>> On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote:

 Hi Mark,

 On 03/14/2014 02:53 AM, Mark Rutland wrote:
>
> On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote:
>>
>> This patch add busfreq driver for Exynos4210/Exynos4x12 memory
>> interface
>> and bus to support DVFS(Dynamic Voltage Frequency Scaling) according
>> to PPMU
>> counters. PPMU (Performance Profiling Monitorings Units) of Exynos4
>> SoC provides
>> PPMU counters for DMC(Dynamic Memory Controller) to check memory bus
>> utilization
>> and then busfreq driver adjusts dynamically the operating
>> frequency/voltage
>> by using DEVFREQ Subsystem.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>   .../devicetree/bindings/devfreq/exynos4_bus.txt| 49
>> ++
>>   1 file changed, 49 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>> new file mode 100644
>> index 000..2a83fcc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
>> @@ -0,0 +1,49 @@
>> +
>> +Exynos4210/4x12 busfreq driver
>> +-
>> +
>> +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus
>> frequency/voltage
>> +scaling according to PPMU counters of memory controllers
>> +
>> +Required properties:
>> +- compatible   : should contain Exynos4 SoC type as follwoing:
>> + - "samsung,exynos4x12-busfreq" for Exynos4x12
>> + - "samsung,exynos4210-busfreq" for Exynos4210
>
>
> Is there a device called "busfreq"? What device does this binding
> describe?


 I'll add detailed description of busfreq as following:

 "busfreq(bus frequendcy)" driver means that busfreq driver control
 dynamically
 memory bus frequency/voltage by checking memory bus utilization to
 optimize
 power-consumption. When checking memeory bus utilization,
 exynos4_busfreq driver
 would use PPMU(Performance Profiling Monitoring Units).
>>>
>>>
>>> This still sounds like a description of the _driver_, not the _device_.
>>> The binding should describe the hardware, now the high level abstraction
>>> that software is going to build atop of it.
>>>
>>> It sounds like this is a binding for the DMC PPMU?
>>>
>>> Is the PPMU a component of the DMC, or is it bolted on the side?
>>
>>
>> PPMU(Performance Profiling Monitoring Unit) is to profile performance
>> event of
>> various IP on Exynos4. Each PPMU provide perforamnce event for each IP.
>> We can check various PPMU as following:
>>
>> PPMU_3D
>> PPMU_ACP
>> PPMU_CAMIF
>> PPMU_CPU
>> PPMU_DMC0
>> PPMU_DMC1
>> PPMU_FSYS
>> PPMU_IMAGE
>> PPMU_LCD0
>> PPMU_LCD1
>> PPMU_MFC_L
>> PPMU_MFC_R
>> PPMU_TV
>> PPMU_LEFT_BUS
>> PPMU_RIGHT_BUS
>>
>> DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4
>> SoC.
>> If we need to get memory bust utilization of DMC, we can get memory bus
>> utilization
>> from PPMU_DMC0/PPMU_DMC1.
>>
>> So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various
>> PPMU list.
>
>
> Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs.
> Busfreq/devfreq is just a Linux-specific abstraction responsible for
> collecting data using PPMUs and controlling frequencies and voltages of
> appropriate power planes, vdd_int responsible for powering DMC0 and DMC1
> blocks in this case.
>
> I'm afraid that the binding you're proposing is unfortunately incorrect,
> because it represents the software abstraction, not the real hardware.
>
> Instead, this should be separated into several independent bindings:
>
>  - PPMU bindings to list all the PPMU instances present in the SoC and
> resources they need,
>
>  - power plane bindings, which define a power plane in which multiple IP
> blocks might reside, can be monitored by one or more PPMU units and
> frequency and voltage of which can be configured according to determined
> performance level. Needed resources will be clocks and regulators to scale
> and probably also operating points.
>
> Then, exynos-busfreq driver should bind to such power planes, parse
> necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and
> operating points) and register a devfreq entity.

How about to use component DT like DRM?
>
> 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://vge

[PATCH v3 0/4] ASoC: simple-card: multi DAI links extension

[Jean-Francois Moine]

This patch series extends the simple card driver to handle
many DAI links as this exists in the Cubox audio subsystem.

-v3
- remove 'Fix the reference count of device nodes'
which is applied (Mark Brown)
- new patch 'Simplify code'
- dynamically allocate and use properties for all DAI links
(Jyri Sarha and Li Xiubo)
- v2
- change subject/comment about device node reference count
(Mark Brown)
- use a null size array instead of an implicit area for the DAI links
(Li Xiubo)
- update the reference count of the device node at end of probe

Jean-Francois Moine (4):
  ASoC: simple-card: Simplify code
  ASoC: simple-card: dynamically allocate the DAI link and properties
  ASoC: simple-card: Handle many DAI links
  ASoC: simple-card: Add DT documentation for multi-DAI links

 .../devicetree/bindings/sound/simple-card.txt  |  34 +++-
 sound/soc/generic/simple-card.c| 181 +
 2 files changed, 145 insertions(+), 70 deletions(-)

-- 
1.9.0

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

[PATCH v3 2/4] ASoC: simple-card: dynamically allocate the DAI link and properties

[Jean-Francois Moine]

The DAI link array and the properties (fmt, sysclk slots) are
hard-coded for a single CPU / CODEC link.

This patch dynamically allocates the DAI link array and the
properties with the aim of supporting many DAI links.

Signed-off-by: Jean-Francois Moine 
---
 sound/soc/generic/simple-card.c | 49 +
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index ca7e63e..a55dc46 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -20,9 +20,11 @@
 
 struct simple_card_data {
struct snd_soc_card snd_card;
-   struct asoc_simple_dai cpu_dai;
-   struct asoc_simple_dai codec_dai;
-   struct snd_soc_dai_link snd_link;
+   struct simple_dais {
+   struct asoc_simple_dai cpu_dai;
+   struct asoc_simple_dai codec_dai;
+   } *dais;
+   struct snd_soc_dai_link dai_link[]; /* dynamically allocated */
 };
 
 static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai,
@@ -70,11 +72,11 @@ static int asoc_simple_card_dai_init(struct 
snd_soc_pcm_runtime *rtd)
struct snd_soc_dai *cpu = rtd->cpu_dai;
int ret;
 
-   ret = __asoc_simple_card_dai_init(codec, &priv->codec_dai);
+   ret = __asoc_simple_card_dai_init(codec, &priv->dais->codec_dai);
if (ret < 0)
return ret;
 
-   ret = __asoc_simple_card_dai_init(cpu, &priv->cpu_dai);
+   ret = __asoc_simple_card_dai_init(cpu, &priv->dais->cpu_dai);
if (ret < 0)
return ret;
 
@@ -184,7 +186,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
np = of_get_child_by_name(node, "simple-audio-card,cpu");
if (np) {
ret = asoc_simple_card_sub_parse_of(np, daifmt,
- &priv->cpu_dai,
+ &priv->dais->cpu_dai,
  &dai_link->cpu_of_node,
  &dai_link->cpu_dai_name);
of_node_put(np);
@@ -197,7 +199,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
np = of_get_child_by_name(node, "simple-audio-card,codec");
if (np) {
ret = asoc_simple_card_sub_parse_of(np, daifmt,
- &priv->codec_dai,
+ &priv->dais->codec_dai,
  &dai_link->codec_of_node,
  &dai_link->codec_dai_name);
of_node_put(np);
@@ -226,12 +228,12 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
dev_dbg(dev, "platform : %04x\n", daifmt);
dev_dbg(dev, "cpu : %s / %04x / %d\n",
dai_link->cpu_dai_name,
-   priv->cpu_dai.fmt,
-   priv->cpu_dai.sysclk);
+   priv->dais->cpu_dai.fmt,
+   priv->dais->cpu_dai.sysclk);
dev_dbg(dev, "codec : %s / %04x / %d\n",
dai_link->codec_dai_name,
-   priv->codec_dai.fmt,
-   priv->codec_dai.sysclk);
+   priv->dais->codec_dai.fmt,
+   priv->dais->codec_dai.sysclk);
 
/*
 * soc_bind_dai_link() will check cpu name
@@ -276,7 +278,9 @@ static int asoc_simple_card_probe(struct platform_device 
*pdev)
struct device *dev = &pdev->dev;
int ret;
 
-   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   priv = devm_kzalloc(dev,
+   sizeof(*priv) + sizeof(*dai_link),
+   GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
@@ -285,10 +289,17 @@ static int asoc_simple_card_probe(struct platform_device 
*pdev)
 */
priv->snd_card.owner = THIS_MODULE;
priv->snd_card.dev = dev;
-   dai_link = &priv->snd_link;
+   dai_link = priv->dai_link;
priv->snd_card.dai_link = dai_link;
priv->snd_card.num_links = 1;
 
+   /* get room for the other properties */
+   priv->dais = devm_kzalloc(dev,
+   sizeof(*priv->dais),
+   GFP_KERNEL);
+   if (!priv->dais)
+   return -ENOMEM;
+
if (np && of_device_is_available(np)) {
 
ret = asoc_simple_card_parse_of(np, priv, dev);
@@ -322,13 +333,13 @@ static int asoc_simple_card_probe(struct platform_device 
*pdev)
dai_link->codec_name= cinfo->codec;
dai_link->cpu_dai_name  = cinfo->cpu_dai.name;
dai_link->codec_dai_name = cinfo->codec_dai.name;
-   memcpy(&priv->cpu_dai, &cinfo->cpu_dai,
-   sizeof(priv->cpu_dai));
-   memcpy(&priv->codec_dai, &cinfo->codec_dai,
-   

[PATCH v3 4/4] ASoC: simple-card: Add DT documentation for multi-DAI links

[Jean-Francois Moine]

There may be many couples of CPU/CODEC DAI links.
The example 2 is extracted from the Cubox DT.

Signed-off-by: Jean-Francois Moine 
---
 .../devicetree/bindings/sound/simple-card.txt  | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt 
b/Documentation/devicetree/bindings/sound/simple-card.txt
index b30c222..a872e7b 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -26,6 +26,9 @@ Required subnodes:
 - simple-audio-card,cpu: CPU   sub-node
 - simple-audio-card,codec  : CODEC sub-node
 
+  There may be one or many couples (simple-audio-card,cpu, 
simple-audio-card,codec)
+  (see example 2).
+
 Required CPU/CODEC subnodes properties:
 
 - sound-dai: phandle and port of CPU/CODEC
@@ -43,7 +46,7 @@ Optional CPU/CODEC subnodes properties:
  clock node (= common clock), or 
"system-clock-frequency"
  (if system doens't support common 
clock)
 
-Example:
+Example 1:
 
 sound {
compatible = "simple-audio-card";
@@ -88,3 +91,32 @@ sh_fsi2: sh_fsi2@ec23 {
interrupt-parent = <&gic>;
interrupts = <0 146 0x4>;
 };
+
+Example 2:
+
+sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "Cubox Audio";
+
+   simple-audio-card,cpu@0 {   /* I2S - HDMI */
+   sound-dai = <&audio1 0>;
+   format = "i2s";
+   };
+   simple-audio-card,codec@0 {
+   sound-dai = <&tda998x 0>;
+   };
+
+   simple-audio-card,cpu@1 {   /* S/PDIF - HDMI */
+   sound-dai = <&audio1 1>;
+   };
+   simple-audio-card,codec@1 {
+   sound-dai = <&tda998x 1>;
+   };
+
+   simple-audio-card,cpu@2 {   /* S/PDIF - S/PDIF */
+   sound-dai = <&audio1 1>;
+   };
+   simple-audio-card,codec@2 {
+   sound-dai = <&spdif_codec>;
+   };
+};
-- 
1.9.0

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

[PATCH v3 3/4] ASoC: simple-card: Handle many DAI links

[Jean-Francois Moine]

Some simple audio cards may have many DAI links.
This patch extends the simple-card driver for handling such cards.

Signed-off-by: Jean-Francois Moine 
---
 sound/soc/generic/simple-card.c | 134 +---
 1 file changed, 83 insertions(+), 51 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index a55dc46..ffb9be3 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -70,13 +70,14 @@ static int asoc_simple_card_dai_init(struct 
snd_soc_pcm_runtime *rtd)
snd_soc_card_get_drvdata(rtd->card);
struct snd_soc_dai *codec = rtd->codec_dai;
struct snd_soc_dai *cpu = rtd->cpu_dai;
-   int ret;
+   int num, ret;
 
-   ret = __asoc_simple_card_dai_init(codec, &priv->dais->codec_dai);
+   num = rtd - rtd->card->rtd;
+   ret = __asoc_simple_card_dai_init(codec, &priv->dais[num].codec_dai);
if (ret < 0)
return ret;
 
-   ret = __asoc_simple_card_dai_init(cpu, &priv->dais->cpu_dai);
+   ret = __asoc_simple_card_dai_init(cpu, &priv->dais[num].cpu_dai);
if (ret < 0)
return ret;
 
@@ -156,7 +157,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
struct device_node *np;
char *name;
unsigned int daifmt;
-   int ret;
+   int num, ret;
 
/* parsing the card name from DT */
snd_soc_of_parse_card_name(&priv->snd_card, "simple-audio-card,name");
@@ -181,50 +182,63 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
return ret;
}
 
-   /* CPU sub-node */
-   ret = -EINVAL;
-   np = of_get_child_by_name(node, "simple-audio-card,cpu");
-   if (np) {
+   /* loop on the DAI links */
+   np = NULL;
+   for (num = 0; ; num++, dai_link++) {
+   np = of_get_next_child(node, np);
+   if (!np)
+   break;
+
+   /* CPU sub-node */
+   if (strcmp(np->name, "simple-audio-card,cpu") != 0) {
+   dev_err(dev, "Bad CPU DAI\n");
+   ret = -EINVAL;
+   goto err;
+   }
ret = asoc_simple_card_sub_parse_of(np, daifmt,
- &priv->dais->cpu_dai,
+ &priv->dais[num].cpu_dai,
  &dai_link->cpu_of_node,
  &dai_link->cpu_dai_name);
-   of_node_put(np);
-   }
-   if (ret < 0)
-   return ret;
+   if (ret < 0)
+   goto err;
 
-   /* CODEC sub-node */
-   ret = -EINVAL;
-   np = of_get_child_by_name(node, "simple-audio-card,codec");
-   if (np) {
+   /* CODEC sub-node */
+   np = of_get_next_child(node, np);
+   if (strcmp(np->name, "simple-audio-card,codec") != 0) {
+   dev_err(dev, "Bad CODEC DAI\n");
+   ret = -EINVAL;
+   goto err;
+   }
ret = asoc_simple_card_sub_parse_of(np, daifmt,
- &priv->dais->codec_dai,
+ &priv->dais[num].codec_dai,
  &dai_link->codec_of_node,
  &dai_link->codec_dai_name);
-   of_node_put(np);
-   }
-   if (ret < 0)
-   return ret;
+   if (ret < 0)
+   goto err;
+
+   if (!dai_link->cpu_dai_name || !dai_link->codec_dai_name) {
+   ret = -EINVAL;
+   goto err;
+   }
 
-   if (!dai_link->cpu_dai_name || !dai_link->codec_dai_name)
-   return -EINVAL;
+   /* simple-card assumes platform == cpu */
+   dai_link->platform_of_node = dai_link->cpu_of_node;
+
+   name = devm_kzalloc(dev,
+   strlen(dai_link->cpu_dai_name)   +
+   strlen(dai_link->codec_dai_name) + 2,
+   GFP_KERNEL);
+   sprintf(name, "%s-%s", dai_link->cpu_dai_name,
+   dai_link->codec_dai_name);
+   dai_link->name = dai_link->stream_name = name;
+   }
 
/* card name is created from CPU/CODEC dai name */
-   name = devm_kzalloc(dev,
-   strlen(dai_link->cpu_dai_name)   +
-   strlen(dai_link->codec_dai_name) + 2,
-   GFP_KERNEL);
-   sprintf(name, "%s-%s", dai_link->cpu_dai_name,
-   dai_link->codec_dai_name);
+   dai_link = priv->snd_car

[PATCH v3 1/4] ASoC: simple-card: Simplify code

[Jean-Francois Moine]

The global DAI format is used only in the function
asoc_simple_card_parse_of(). So, move it from the private data
to the stack.

Signed-off-by: Jean-Francois Moine 
---
 sound/soc/generic/simple-card.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index dcf37fb..ca7e63e 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -20,7 +20,6 @@
 
 struct simple_card_data {
struct snd_soc_card snd_card;
-   unsigned int daifmt;
struct asoc_simple_dai cpu_dai;
struct asoc_simple_dai codec_dai;
struct snd_soc_dai_link snd_link;
@@ -154,13 +153,14 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
struct snd_soc_dai_link *dai_link = priv->snd_card.dai_link;
struct device_node *np;
char *name;
+   unsigned int daifmt;
int ret;
 
/* parsing the card name from DT */
snd_soc_of_parse_card_name(&priv->snd_card, "simple-audio-card,name");
 
/* get CPU/CODEC common format via simple-audio-card,format */
-   priv->daifmt = snd_soc_of_parse_daifmt(node, "simple-audio-card,") &
+   daifmt = snd_soc_of_parse_daifmt(node, "simple-audio-card,") &
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
 
/* off-codec widgets */
@@ -183,7 +183,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, "simple-audio-card,cpu");
if (np) {
-   ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
+   ret = asoc_simple_card_sub_parse_of(np, daifmt,
  &priv->cpu_dai,
  &dai_link->cpu_of_node,
  &dai_link->cpu_dai_name);
@@ -196,7 +196,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, "simple-audio-card,codec");
if (np) {
-   ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
+   ret = asoc_simple_card_sub_parse_of(np, daifmt,
  &priv->codec_dai,
  &dai_link->codec_of_node,
  &dai_link->codec_dai_name);
@@ -223,7 +223,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
dai_link->platform_of_node = dai_link->cpu_of_node;
 
dev_dbg(dev, "card-name : %s\n", name);
-   dev_dbg(dev, "platform : %04x\n", priv->daifmt);
+   dev_dbg(dev, "platform : %04x\n", daifmt);
dev_dbg(dev, "cpu : %s / %04x / %d\n",
dai_link->cpu_dai_name,
priv->cpu_dai.fmt,
-- 
1.9.0

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

Re: [RFC v3 3/3] of: Make of_find_node_by_path() handle /aliases

[Grant Likely]

On Fri, 14 Mar 2014 16:39:38 -0500, Rob Herring  wrote:
> On Fri, Mar 14, 2014 at 12:11 PM, Grant Likely  
> wrote:
> > Make of_find_node_by_path() handle aliases as prefixes. To make this
> > work the name search is refactored to search by path component instead
> > of by full string. This should be a more efficient search, and it makes
> > it possible to start a search at a subnode of a tree.
> >
> > Signed-off-by: David Daney 
> > Signed-off-by: Pantelis Antoniou 
> > [grant.likely: Rework to not require allocating at runtime]
> > Signed-off-by: Grant Likely 
> 
> I should have read the comments before trying to figure out why you
> had that "pointless" recursion...

Hi Rob,

Thanks for the review. However, I'm a little slow this morning and I
don't understand what you mean. Did I miss an early comment?

g.

> 
> Acked-by: Rob Herring 
> 
> > ---
> >  drivers/of/base.c | 60 
> > +++
> >  1 file changed, 56 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index 7083fad079a6..b8b673526dbd 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -770,9 +770,38 @@ struct device_node *of_get_child_by_name(const struct 
> > device_node *node,
> >  }
> >  EXPORT_SYMBOL(of_get_child_by_name);
> >
> > +static struct device_node *__of_find_node_by_path(struct device_node 
> > *parent,
> > +   const char *path)
> > +{
> > +   struct device_node *child;
> > +   int len = strchrnul(path, '/') - path;
> > +
> > +   if (!len)
> > +   return parent;
> > +
> > +   for_each_child_of_node(parent, child) {
> > +   const char *name = strrchr(child->full_name, '/');
> > +   if (WARN(!name, "malformed device_node %s\n", 
> > child->full_name))
> > +   continue;
> > +   name++;
> > +   if (strncmp(path, name, len) == 0 && (strlen(name) == len))
> > +   return child;
> > +   }
> > +   return NULL;
> > +}
> > +
> >  /**
> >   * of_find_node_by_path - Find a node matching a full OF path
> >   * @path:  The full path to match
> > + * @path: Either the full path to match, or if the path does not
> > + *start with '/', the name of a property of the /aliases
> > + *node (an alias).  In the case of an alias, the node
> > + *matching the alias' value will be returned.
> > + *
> > + * Valid paths:
> > + * /foo/barFull path
> > + * foo Valid alias
> > + * foo/bar Valid alias + relative path
> >   *
> >   * Returns a node pointer with refcount incremented, use
> >   * of_node_put() on it when done.
> > @@ -780,13 +809,36 @@ EXPORT_SYMBOL(of_get_child_by_name);
> >  struct device_node *of_find_node_by_path(const char *path)
> >  {
> > struct device_node *np = of_allnodes;
> > +   struct property *pp;
> > unsigned long flags;
> >
> > +   /* The path could begin with an alias */
> > +   if (*path != '/') {
> > +   char *p = strchrnul(path, '/');
> > +   int len = p - path;
> > +
> > +   /* of_aliases must not be NULL */
> > +   if (!of_aliases)
> > +   return NULL;
> > +
> > +   np = NULL;
> > +   for_each_property_of_node(of_aliases, pp) {
> > +   if (strlen(pp->name) == len && !strncmp(pp->name, 
> > path, len)) {
> > +   np = of_find_node_by_path(pp->value);
> > +   break;
> > +   }
> > +   }
> > +   if (!np)
> > +   return NULL;
> > +   path = p;
> > +   }
> > +
> > +   /* Step down the tree matching path components */
> > raw_spin_lock_irqsave(&devtree_lock, flags);
> > -   for (; np; np = np->allnext) {
> > -   if (np->full_name && (of_node_cmp(np->full_name, path) == 0)
> > -   && of_node_get(np))
> > -   break;
> > +   while (np && *path == '/') {
> > +   path++; /* Increment past '/' delimiter */
> > +   np = __of_find_node_by_path(np, path);
> > +   path = strchrnul(path, '/');
> > }
> > raw_spin_unlock_irqrestore(&devtree_lock, flags);
> > return np;
> > --
> > 1.8.3.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 2/3] workqueues: Account unbound workqueue in a seperate list

[Frederic Weisbecker]

On Fri, Mar 14, 2014 at 11:17:35AM -0700, Kevin Hilman wrote:
> Frederic Weisbecker  writes:
> 
> > The workqueues are all listed in a global list protected by a big mutex.
> > And this big mutex is used in apply_workqueue_attrs() as well.
> >
> > Now as we plan to implement a directory to control the cpumask of
> > all non-ABI unbound workqueues, we want to be able to iterate over all
> > unbound workqueues and call apply_workqueue_attrs() for each of
> > them with the new cpumask.
> >
> > But the risk for a deadlock is on the way: we need to iterate the list
> > of workqueues under wq_pool_mutex. But then apply_workqueue_attrs()
> > itself calls wq_pool_mutex.
> >
> > The easiest solution to work around this is to keep track of unbound
> > workqueues in a separate list with a separate mutex.
> >
> > It's not very pretty unfortunately.
> >
> > Cc: Christoph Lameter 
> > Cc: Kevin Hilman 
> > Cc: Mike Galbraith 
> > Cc: Paul E. McKenney 
> > Cc: Tejun Heo 
> > Cc: Viresh Kumar 
> > Not-Signed-off-by: Frederic Weisbecker 
> > ---
> >  kernel/workqueue.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index 4d230e3..ad8f727 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -232,6 +232,7 @@ struct wq_device;
> >  struct workqueue_struct {
> > struct list_headpwqs;   /* WR: all pwqs of this wq */
> > struct list_headlist;   /* PL: list of all workqueues */
> > +   struct list_headunbound_list;   /* PL: list of unbound 
> > workqueues */
> >  
> > struct mutexmutex;  /* protects this wq */
> > int work_color; /* WQ: current work color */
> > @@ -288,9 +289,11 @@ static bool wq_numa_enabled;   /* unbound NUMA 
> > affinity enabled */
> >  static struct workqueue_attrs *wq_update_unbound_numa_attrs_buf;
> >  
> >  static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and 
> > workqueues list */
> > +static DEFINE_MUTEX(wq_unbound_mutex); /* protects list of unbound 
> > workqueues */
> >  static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
> >  
> >  static LIST_HEAD(workqueues);  /* PL: list of all workqueues */
> > +static LIST_HEAD(workqueues_unbound);  /* PL: list of unbound 
> > workqueues */
> >  static bool workqueue_freezing;/* PL: have wqs started 
> > freezing? */
> >  
> >  /* the per-cpu worker pools */
> > @@ -4263,6 +4266,12 @@ struct workqueue_struct *__alloc_workqueue_key(const 
> > char *fmt,
> >  
> > mutex_unlock(&wq_pool_mutex);
> >  
> > +   if (wq->flags & WQ_UNBOUND) {
> > +   mutex_lock(&wq_unbound_mutex);
> > +   list_add(&wq->unbound_list, &workqueues_unbound);
> > +   mutex_unlock(&wq_unbound_mutex);
> > +   }
> > +
> > return wq;
> >  
> >  err_free_wq:
> > @@ -4318,6 +4327,12 @@ void destroy_workqueue(struct workqueue_struct *wq)
> > list_del_init(&wq->list);
> > mutex_unlock(&wq_pool_mutex);
> >  
> > +   if (wq->flags & WQ_UNBOUND) {
> > +   mutex_lock(&wq_unbound_mutex);
> > +   list_del(&wq->unbound_list);
> > +   mutex_unlock(&wq_unbound_mutex);
> > +   }
> > +
> > workqueue_sysfs_unregister(wq);
> >  
> > if (wq->rescuer) {
> 
> Looks good, except for minor nit: I think you're missing an init of the
> new list:
> 
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index cc708f23d801..a01592f08321 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -4309,6 +4309,7 @@ struct workqueue_struct
> *__alloc_workqueue_key(const char *fmt,
> 
> lockdep_init_map(&wq->lockdep_map, lock_name, key, 0);
> INIT_LIST_HEAD(&wq->list);
> +   INIT_LIST_HEAD(&wq->unbound_list);

Actually that's only for the head of a list. Nodes don't need such 
initialization.

Thanks.

> 
> if (alloc_and_link_pwqs(wq) < 0)
> goto err_free_wq;
> 
> 
> Kevin
--
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: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12

[Tomasz Figa]

On 15.03.2014 12:36, Kyungmin Park wrote:

On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa  wrote:

Hi Chanwoo, Mark,


On 14.03.2014 11:56, Chanwoo Choi wrote:


Hi Mark,

On 03/14/2014 07:35 PM, Mark Rutland wrote:


On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote:


Hi Mark,

On 03/14/2014 02:53 AM, Mark Rutland wrote:


On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote:


This patch add busfreq driver for Exynos4210/Exynos4x12 memory
interface
and bus to support DVFS(Dynamic Voltage Frequency Scaling) according
to PPMU
counters. PPMU (Performance Profiling Monitorings Units) of Exynos4
SoC provides
PPMU counters for DMC(Dynamic Memory Controller) to check memory bus
utilization
and then busfreq driver adjusts dynamically the operating
frequency/voltage
by using DEVFREQ Subsystem.

Signed-off-by: Chanwoo Choi 
---
   .../devicetree/bindings/devfreq/exynos4_bus.txt| 49
++
   1 file changed, 49 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/devfreq/exynos4_bus.txt

diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
new file mode 100644
index 000..2a83fcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt
@@ -0,0 +1,49 @@
+
+Exynos4210/4x12 busfreq driver
+-
+
+Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus
frequency/voltage
+scaling according to PPMU counters of memory controllers
+
+Required properties:
+- compatible   : should contain Exynos4 SoC type as follwoing:
+ - "samsung,exynos4x12-busfreq" for Exynos4x12
+ - "samsung,exynos4210-busfreq" for Exynos4210



Is there a device called "busfreq"? What device does this binding
describe?



I'll add detailed description of busfreq as following:

"busfreq(bus frequendcy)" driver means that busfreq driver control
dynamically
memory bus frequency/voltage by checking memory bus utilization to
optimize
power-consumption. When checking memeory bus utilization,
exynos4_busfreq driver
would use PPMU(Performance Profiling Monitoring Units).



This still sounds like a description of the _driver_, not the _device_.
The binding should describe the hardware, now the high level abstraction
that software is going to build atop of it.

It sounds like this is a binding for the DMC PPMU?

Is the PPMU a component of the DMC, or is it bolted on the side?



PPMU(Performance Profiling Monitoring Unit) is to profile performance
event of
various IP on Exynos4. Each PPMU provide perforamnce event for each IP.
We can check various PPMU as following:

PPMU_3D
PPMU_ACP
PPMU_CAMIF
PPMU_CPU
PPMU_DMC0
PPMU_DMC1
PPMU_FSYS
PPMU_IMAGE
PPMU_LCD0
PPMU_LCD1
PPMU_MFC_L
PPMU_MFC_R
PPMU_TV
PPMU_LEFT_BUS
PPMU_RIGHT_BUS

DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4
SoC.
If we need to get memory bust utilization of DMC, we can get memory bus
utilization
from PPMU_DMC0/PPMU_DMC1.

So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various
PPMU list.



Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs.
Busfreq/devfreq is just a Linux-specific abstraction responsible for
collecting data using PPMUs and controlling frequencies and voltages of
appropriate power planes, vdd_int responsible for powering DMC0 and DMC1
blocks in this case.

I'm afraid that the binding you're proposing is unfortunately incorrect,
because it represents the software abstraction, not the real hardware.

Instead, this should be separated into several independent bindings:

  - PPMU bindings to list all the PPMU instances present in the SoC and
resources they need,

  - power plane bindings, which define a power plane in which multiple IP
blocks might reside, can be monitored by one or more PPMU units and
frequency and voltage of which can be configured according to determined
performance level. Needed resources will be clocks and regulators to scale
and probably also operating points.

Then, exynos-busfreq driver should bind to such power planes, parse
necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and
operating points) and register a devfreq entity.


How about to use component DT like DRM?


Well, basically this is what I proposed. Each "power plane" would be a 
"subsystem" built from components - PPMUs, IP blocks, clocks, 
regulators, etc, specified in DT by existing means, e.g.


ppmu_disp: ppmu@1234 {
/* Resources of PPMU */
}

fimd: fimd@2345 {
/* Resources of FIMD */
};

power-plane-display {
compatible = "samsung,power-plane";
samsung,ppmus = <&ppmu_disp>, ...;
samsung,devices = <&fimd>, ...;
clock-names = "aclk_xxx", "sclk_xxx", ...;
clocks = ...;
vdd_xxx-supply = ...;
};

However I'm still wondering whether there shouldn't be a relation 
between power planes and power domains and simply existing power d

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

On 03/14/2014 05:04 PM, Oleg Nesterov wrote:

On 03/14, Peter Hurley wrote:

On 03/14/2014 03:23 PM, Oleg Nesterov wrote:

On 03/14, Peter Hurley wrote:



Yes, cgroup_release_agent() is the work function that is scheduled.


which requires both namespace and tty facilities.


Hmm... why?

The exiting task obviously can't exec. The only way to spawn a userspace
process is call_usermodehelper(), it should work just fine, no?


You're correct, in the immediate sense that the user command exec'd will
not inherit open file descriptors.

But what if it expects to be able to find the intact children of
the foreground process group, and can't because the controlling tty
has already been torn down and all the children already sent SIGHUP.


Which group/tty ? call_usermodehelper() asks the workqueue thread
to kthread_create/exec. See also below...


Or what if the user command expects to find and join the user namespace
of the dying process but now it's already been freed?


But it can't even know who called call_usermodehelper(). Besides,
cgroup_release_agent() uses UMH_WAIT_EXEC, so the caller can continue
and disappear completely before the usermode process has any chance
to do something.


I'm just hypothesizing potential breakage, since the order of teardown
is sensitive to changes, and I didn't do a complete audit of all the
possibilities.

If you feel strongly about moving disassociate_tty(), I won't object.

Regards,
Peter Hurley


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

RE: [PATCH RESEND] mmc:sdhci: handle busy-end interrupt during command

[Youssef TRIKI]

Hi Guys,

It is not specific to Toshiba devices, and happens with eMMC  devices as well 
as SD card which support Auto-CMD12 rather than CMD23.
This warning is seen in read operation and the cause is well explained below. 
Thanks Chanho Min for the patch.
And Thanks to add it to the mainline.

Regards,
Youssef. 

-Original Message-
From: Chanho Min [mailto:chanho@lge.com] 
Sent: samedi 15 mars 2014 07:23
To: Chris Ball; Chris Ball
Cc: Hankyung Yu; Shawn Guo; Dong Aisheng; Kevin Liu; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; HyoJun Im; Gunho Lee; Youssef TRIKI; Chanho Min
Subject: [PATCH RESEND] mmc:sdhci: handle busy-end interrupt during command

It is fully legal for a controller to start handling busy-end interrupt before 
it has signaled that the command has completed. So make sure we do things in 
the proper order, Or it results that command interrupt is ignored so it can 
cause unexpected operations. This is founded at some toshiba emmc with the 
bellow warning.

"mmc0: Got command interrupt 0x0001 even though no command operation was in 
progress."

Can anyone ACK/NACK of this patch? Any comment will be appreciated.

Signed-off-by: Hankyung Yu 
Signed-off-by: Chanho Min 
Tested-by: Youssef TRIKI 
---
 drivers/mmc/host/sdhci.c  |   17 +++--
 include/linux/mmc/sdhci.h |1 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 
bd8a098..21f98e7 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1016,6 +1016,7 @@ void sdhci_send_command(struct sdhci_host *host, struct 
mmc_command *cmd)
mod_timer(&host->timer, jiffies + 10 * HZ);
 
host->cmd = cmd;
+   host->busy_handle = 0;
 
sdhci_prepare_data(host, cmd);
 
@@ -2271,8 +2272,12 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 
intmask)
if (host->cmd->data)
DBG("Cannot wait for busy signal when also "
"doing a data transfer");
-   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ))
+   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ)
+   && !host->busy_handle) {
+   /* Mark that command complete before busy is ended */
+   host->busy_handle = 1;
return;
+   }
 
/* The controller does not support the end-of-busy IRQ,
 * fall through and take the SDHCI_INT_RESPONSE */ @@ -2335,7 
+2340,15 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
 */
if (host->cmd && (host->cmd->flags & MMC_RSP_BUSY)) {
if (intmask & SDHCI_INT_DATA_END) {
-   sdhci_finish_command(host);
+   /*
+* Some cards handle busy-end interrupt
+* before the command completed, so make
+* sure we do things in the proper order.
+*/
+   if (host->busy_handle)
+   sdhci_finish_command(host);
+   else
+   host->busy_handle = 1;
return;
}
}
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h index 
3e781b8..0118020 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -148,6 +148,7 @@ struct sdhci_host {
struct mmc_command *cmd;/* Current command */
struct mmc_data *data;  /* Current data request */
unsigned int data_early:1;  /* Data finished before cmd */
+   unsigned int busy_handle:1; /* Handling the order of Busy-end */
 
struct sg_mapping_iter sg_miter;/* SG state for PIO */
unsigned int blocks;/* remaining PIO blocks */
--
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 01/10] perf, tools: Add jsmn `jasmine' JSON parser

[Arnaldo Carvalho de Melo]

Em Sat, Mar 15, 2014 at 03:27:07AM +0100, Andi Kleen escreveu:
> On Fri, Mar 14, 2014 at 04:41:31PM -0600, David Ahern wrote:
> > On 3/14/14, 3:31 PM, Andi Kleen wrote:
> > >@@ -374,6 +376,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
> > >  LIB_OBJS += $(OUTPUT)util/record.o
> > >  LIB_OBJS += $(OUTPUT)util/srcline.o
> > >  LIB_OBJS += $(OUTPUT)util/data.o
> > >+LIB_OBJS += $(OUTPUT)util/jsmn.o
> > >+LIB_OBJS += $(OUTPUT)util/json.o

> > CONFIG driven? Allow a user to omit this.
 
> Why? It has no external dependencies. AFAIK that's the only reason for 
> configs.
 
> (unless you count the commands used by the shell script, but the basic parser
> works fine even without the script)

Will this be useful for all arches?

- Arnaldo
--
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 v5 09/11] arm: add support for reserved memory defined by device tree

[Grant Likely]

On Thu, 13 Mar 2014 14:51:56 -0700, Kevin Hilman  wrote:
> Josh Cartwright  writes:
> 
> > On Thu, Mar 13, 2014 at 01:46:50PM -0700, Kevin Hilman wrote:
> >> On Fri, Feb 21, 2014 at 4:25 AM, Marek Szyprowski
> >>  wrote:
> >> > Enable reserved memory initialization from device tree.
> >> >
> >> > Signed-off-by: Marek Szyprowski 
> >> 
> >> This patch has hit -next and several legacy (non-DT) boot failures
> >> were detected and bisected down to this patch.  A quick scan looks
> >> like there needs to be some sanity checking whether a DT is even
> >> present.
> >
> > Hmm.  Yes, the code unconditionally calls of_flat_dt_scan(), which will
> > gladly touch initial_boot_params, even though it may be uninitialized.
> > The below patch should allow these boards to boot...
> >
> > However, I'm wondering if there is a good reason why we don't parse the
> > /reserved-memory nodes at the right after we parse the /memory nodes as
> > part of early_init_dt_scan()...
> >
> > Thanks,
> >   Josh
> >
> > --8<--
> > Subject: [PATCH] drivers: of: only scan for reserved mem when fdt present
> >
> > Reported-by: Kevin Hilman 
> > Signed-off-by: Josh Cartwright 
> 
> This gets legacy boot working again.  Thanks.
> 
> Tested-by: Kevin Hilman 

Applied and confirmed on non-DT qemu boot. Thanks. It will be pushed out
shortly.

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] virtio-blk: make the queue depth the max supportable by the hypervisor

[Theodore Ts'o]

On Sat, Mar 15, 2014 at 06:57:01AM -0400, Konrad Rzeszutek Wilk wrote:
> >+pr_info("%s: using queue depth %d\n", vblk->disk->disk_name,
> >+virtio_mq_reg.queue_depth);
> 
> Isn't that visible from sysfs?

As near as I can tell, it's not.  I haven't been able to find anything
that either represents this value, or can be calculated from this
value.  Maybe I missed something?

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

scsi_debug and mutipath, was Re: [PATCH 1/1] block: rework flush sequencing for blk-mq

[Christoph Hellwig]

On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote:
> I was more reacting to the assertion you made like multipath regresses
> all the time.  I'm not faulting you at all for not having tested
> multipath.  Hell, I even forget to test multipath more than I should.
> /me says with shame

And I didn't assert that, I just asserted that it gets little testing.

> Yeah, not sure why single path scsi_debug "just works", maybe it is a
> "feature" of the older multipathd I have kicking around?, but for basic
> data path testing scsi_debug is a quick means to an end.  I can look
> closer at _why_ it gets multipathd in a bit.  But maybe Ben or Hannes
> will have quicker insight?
> 
> For me, if multipathd is running, if I issue the following a multipath
> device gets layered ontop of the associated scsi_debug created sd
> device: modprobe scsi_debug dev_size_mb=1024
> 
> I think it useful to have scsi_debug work with multipath.  I know people
> in Red Hat's QE organization have even simulated multiple paths with
> it.. but I don't recall if they had to hack scsi_debug to do that.  I'll
> try to find out.

Looks like it really shouldn't attach as-is.  But scsi_debug should be
easily extendable to export two LUNs for the same backing store to help
multipath testing.
--
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] s390: correct misuses of module_put in appldata_generic_handler.

[Zhouyi Zhou]

correct misuses of module_put in  appldata_generic_handler

Signed-off-by: Zhouyi Zhou 
---
 arch/s390/appldata/appldata_base.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/s390/appldata/appldata_base.c 
b/arch/s390/appldata/appldata_base.c
index 47c8630..683e0282 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -343,7 +343,6 @@ appldata_generic_handler(struct ctl_table *ctl, int write,
// protect work queue callback
if (!try_module_get(ops->owner)) {
mutex_unlock(&appldata_ops_mutex);
-   module_put(ops->owner);
return -ENODEV;
}
ops->callback(ops->data);   // init record
@@ -354,7 +353,6 @@ appldata_generic_handler(struct ctl_table *ctl, int write,
if (rc != 0) {
pr_err("Starting the data collection for %s "
   "failed with rc=%d\n", ops->name, rc);
-   module_put(ops->owner);
} else
ops->active = 1;
} else if ((buf[0] == '0') && (ops->active == 1)) {
@@ -365,7 +363,6 @@ appldata_generic_handler(struct ctl_table *ctl, int write,
if (rc != 0)
pr_err("Stopping the data collection for %s "
   "failed with rc=%d\n", ops->name, rc);
-   module_put(ops->owner);
}
mutex_unlock(&appldata_ops_mutex);
 out:
-- 
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: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Sander Eikelenboom]

Friday, March 14, 2014, 2:29:43 AM, you wrote:

> Hi Sander,

> On 03/13/2014 08:49 PM, Sander Eikelenboom wrote:
>> 
>> Is it just me .. or is this going at the speed of about a bluetooth 
>> connection ..
>> and probably missing the boot for 3.14 ? (for no good reason IMHO)
>> 
>>
>> (it was not in John's nor Dave's last pull request, although it seems to be 
>> reverted in the bluetooth tree now .. i didn't
>> see any formal pull request from that .. to get it even *starting* to 
>> traverse all the trees up to Linus ... )

> Known bugs sometimes roll out into mainline release because the
> alternative can be worse.

> As I explained in the follow-up to my patch series, I would
> not have expected Marcel to pick up any of the fixes for 3.14.
> There are a lot of moving parts in usb + bluetooth + rfcomm + tty,
> and the unfortunate reality is that -next doesn't get as much
> testing as it should.

> The fault is mine because Gianluca let me know about the
> problems with the conversion to tty_port, but the holidays really
> interfered with my ability to put this work first, and I'm sorry
> for that.

> I know the breakage around RFCOMM is frustrating but I think the
> worst is behind us. After 3.15 gets some -rc testing, I will
> be happy to cherry-pick the critical fixes for -stable inclusion.

Ok but the breakage/regression was known since around the merge window.
I thought the "standard policy" when things cause new regression and are not 
fixable (too intrusive, too time consuming you
name the reason), was to revert .. (and possibly ASAP so the reverts also get 
some test coverage in mainline RC's).
That's also why i tested the revert ASAP to let you know that that worked  .. 
at least for me.

But no big deal for mee .. the reverts are simple enough to be privately 
applied.

> Regards,
> Peter Hurley


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

Re: [PATCH] virtio-blk: make the queue depth the max supportable by the hypervisor

[Christoph Hellwig]

On Fri, Mar 14, 2014 at 11:34:31PM -0400, Theodore Ts'o wrote:
> The current virtio block sets a queue depth of 64, which is
> insufficient for very fast devices.  It has been demonstrated that
> with a high IOPS device, using a queue depth of 256 can double the
> IOPS which can be sustained.
> 
> As suggested by Venkatash Srinivas, set the queue depth by default to
> be one half the the device's virtqueue, which is the maximum queue
> depth that can be supported by the channel to the host OS (each I/O
> request requires at least two VQ entries).

I don't think this should be a module parameter.  The default sizing
should be based of the parameters of the actual virtqueue, and if we
want to allow tuning it it should be by a sysfs attribute, preferable
using the same semantics as SCSI.

--
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: Info: mapping multiple BARs. Your kernel is fine.

[Rafael J. Wysocki]

[CC list rearranged]

On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
> add *everybody* to CC :-)
> 
> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
> other goodies on the stack.

I've just gone throught this.

So the problem is that we have the PNP "system" driver whose only purpose seems
to be to reserve system resources so that the PCI layer doesn't assign them to
new devices on hotplug (disclaimer: I didn't invent it, I only read the code and
comments in there).

It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs.

Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that
driver on your box.  And this doesn't seem to be a coincidence, because the ACPI
device object in question probably *does* correspond to the memory controller
that the uncore driver attempts to use.

I'm not sure how to address that right now to be honest.  Arguably, the PNP
"system" driver should be replaced with something saner, but still the
resources it claims need to be kept out of reach of the PCI's resource
allocation code.

> ...
> [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at 
> [8800cac3-8800cec2]
> [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff 
> 0xfed1 0xfed13fff pnp 00:01
> [0.490079] [ cut here ]
> [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 
> __ioremap_caller+0x372/0x380()
> [0.490306] Info: mapping multiple BARs. Your kernel is fine.
> [0.490371] Modules linked in:
> [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1
> [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
> 11/13/2012
> [0.490742]  00ab 880213d01ad8 816112e3 
> 0006
> [0.491032]  880213d01b28 880213d01b18 8104e9bc 
> 880213d01b08
> [0.491343]  c9c58000 fed1 fed1 
> 6000
> [0.491631] Call Trace:
> [0.493337]  [] dump_stack+0x4f/0x7c
> [0.493420]  [] warn_slowpath_common+0x8c/0xc0
> [0.493503]  [] warn_slowpath_fmt+0x46/0x50
> [0.493588]  [] __ioremap_caller+0x372/0x380
> [0.493674]  [] ? snb_uncore_imc_init_box+0x62/0x90
> [0.493761]  [] ioremap_nocache+0x17/0x20
> [0.493846]  [] snb_uncore_imc_init_box+0x62/0x90
> [0.493933]  [] uncore_pci_probe+0xe5/0x1e0
> [0.494020]  [] local_pci_probe+0x4e/0xa0
> [0.494104]  [] ? get_device+0x19/0x20
> [0.494213]  [] pci_device_probe+0xe1/0x130
> [0.494300]  [] driver_probe_device+0x7b/0x240
> [0.494385]  [] __driver_attach+0xab/0xb0
> [0.494469]  [] ? driver_probe_device+0x240/0x240
> [0.494551]  [] bus_for_each_dev+0x5e/0x90
> [0.494634]  [] driver_attach+0x1e/0x20
> [0.494718]  [] bus_add_driver+0x117/0x230
> [0.494802]  [] driver_register+0x64/0xf0
> [0.494884]  [] __pci_register_driver+0x64/0x70
> [0.494972]  [] ? uncore_types_init+0x19c/0x19c
> [0.495056]  [] intel_uncore_init+0x177/0x41c
> [0.495155]  [] ? uncore_types_init+0x19c/0x19c
> [0.495242]  [] do_one_initcall+0x4e/0x170
> [0.495326]  [] ? parse_args+0x60/0x360
> [0.495411]  [] kernel_init_freeable+0x106/0x19a
> [0.495497]  [] ? do_early_param+0x86/0x86
> [0.495582]  [] ? rest_init+0xd0/0xd0
> [0.495666]  [] kernel_init+0xe/0xf0
> [0.495749]  [] ret_from_fork+0x7c/0xb0
> [0.495831]  [] ? rest_init+0xd0/0xd0
> [0.495921] ---[ end trace 428f365c054d9a01 ]---
> [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 
> Joules, 3 fixed counters 163840 ms ovfl timer
> [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes)
> [0.498833] audit: initializing netlink subsys (disabled)
> [0.499024] audit: type=2000 audit(1393259866.477:1): initialized
> ...
> 
> 

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

Re: [PATCH] MAINTAINERS: virtio-dev is subscribers only

[Christoph Hellwig]

On Thu, Mar 13, 2014 at 11:06:50AM +1030, Rusty Russell wrote:
> Randy Dunlap  writes:
> > From: Randy Dunlap 
> >
> > virtio-dev mailing list is for subscribers only according to the
> > returned message after trying to send to it.
> 
> Thanks, applied.

It's a strict bounce and not even moderator approval for
non-subscribers.  This means it might as well be non-existant for
linux development and we should remove it from MAINTAINERS entirely.

--
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: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

On Sat 2014-03-15 02:46:19, Rafael J. Wysocki wrote:
> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> > On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek  wrote:
> > > On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> > >> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:
> > >> > Hi!
> > >> >
> > >> > It seems /proc/acpi/battery interface is gone, and I don't see any
> > >> > option to reintroduce it... what is going on?
> > >>
> > >> The interface went away in a semi-recent kernel release (3.13 or
> > >> 3.12), breaking pretty much every battery app. (Admittedly the
> > >> interface was marked as deprecated for quite some time, but that
> > >> didn't stop everyone from using it and not caring about the new
> > >> thing.) I've yet to find a windowmaker dock app that works with the
> > >> current sysfs API :(
> > >
> > > Name one application it broke, and we'll get it reverted. It broke my
> > > by-hand journalling, at the very least.
> > 
> > wmbattery
> > 
> > They have attempted to use the sysfs api, but apparently that
> > integration was done with an older version of that API. There's also
> > some attempt to get it to work with upower, but I couldn't figure out
> > how to make that work either on my (up-to-date gentoo) box. (TBH I
> > didn't spend more than an hour or two on it, so it may not be
> > impossible.)
> 
> Tianyu, can you please have a look at this?

So far I tried patch below, but it says:

ACPI: Deprecated procfs I/F for battery is loaded, please retry with
CONFIG_ACPI_PROCFS_POWER cleared
ACPI: Battery Slot [BAT0] (battery present)
Error: Driver 'battery' is already registered, aborting...
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

and /proc/acpi does not appear.


Pavel

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 4770de5..561bf25 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -56,6 +56,23 @@ config ACPI_PROCFS
 
  Say N to delete /proc/acpi/ files that have moved to /sys/
 
+config ACPI_PROCFS_POWER
+   bool "Deprecated power /proc/acpi directories"
+   depends on PROC_FS
+   help
+ For backwards compatibility, this option allows
+  deprecated power /proc/acpi/ directories to exist, even when
+  they have been replaced by functions in /sys.
+  The deprecated directories (and their replacements) include:
+ /proc/acpi/battery/* (/sys/class/power_supply/*)
+ /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
+ This option has no effect on /proc/acpi/ directories
+ and functions, which do not yet exist in /sys
+ This option, together with the proc directories, will be
+ deleted in 2.6.39.
+
+ Say N to delete power /proc/acpi/ directories that have moved to /sys/
+
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -47,6 +47,7 @@ acpi-y+= sysfs.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
+acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 ifdef CONFIG_ACPI_VIDEO
 acpi-y += video_detect.o
 endif
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 797a693..dfe31f6 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -37,6 +37,16 @@
 #include 
 
 #include 
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+#include 
+#include 
+#include 
+#endif
+
+#include 
+#include 
+
 #include 
 
 #define PREFIX "ACPI: "
@@ -66,6 +76,19 @@ static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
 
+#ifdef CONFIG_ACPI_PROCFS_POWER
+extern struct proc_dir_entry *acpi_lock_battery_dir(void);
+extern void *acpi_unlock_battery_dir(struct proc_dir_entry *acpi_battery_dir);
+
+enum acpi_battery_files {
+   info_tag = 0,
+   state_tag,
+   alarm_tag,
+   ACPI_BATTERY_NUMFILES,
+};
+
+#endif
+
 static const struct acpi_device_id battery_device_ids[] = {
{"PNP0C0A", 0},
{"", 0},
@@ -301,6 +324,14 @@ static enum power_supply_property energy_battery_props[] = 
{
POWER_SUPPLY_PROP_SERIAL_NUMBER,
 };
 
+#ifdef CONFIG_ACPI_PROCFS_POWER
+inline char *acpi_battery_units(struct acpi_battery *battery)
+{
+   return (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) ?
+   "mA" : "mW";
+}
+#endif
+
 /* --
Battery Management
-- 
*/
@@ -719,6 +750,279 @@ static void acpi_battery_refresh(struct acpi_

Re: [PATCH] zram: include linux/err.h

[Sergey Senozhatsky]

Hello Arnd,

On (03/15/14 10:40), Arnd Bergmann wrote:
> The zram driver uses the ERR_PTR macro defined in 
> and relies on this header to be included implicitly through
> other headers, which is not (always) the case on the ARM architecture.
> 

returned from zcomp ERR_PTR is checked and used in zram_drv.c, should
in this case there also be inclusion of err.h in zram_drv.h? if so, it
probably makes sense to move inclusion of err.h to zcomp.h, which is
included both in zcomp.c and zram_drv.c

> Adding an explicit #include allows us to build the driver in
> all configurations.
> 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 92a83df..3507bef 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -7,6 +7,7 @@
>   * 2 of the License, or (at your option) any later version.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] x86: Pass memory range via E820 for kdump

[Borislav Petkov]

On Fri, Mar 14, 2014 at 02:27:06PM -0600, Linn Crosetto wrote:
> Since this testing was done on a prototype, I will send you the log in
> a separate email. I tried efi.git/next (with the addition of 4ce7a86),
> and hit the same panic.

Well, if the stack trace is the same:

>  ? __unmap_pmd_range+0x77/0x190
>  unmap_pmd_range+0xcf/0x1c0
>  populate_pgd+0x16d/0x250
>  __cpa_process_fault+0x15/0xb0
...

it looks like populate_pgd() fails and unmaps the whole range. You could
add some debug printks to find out exactly why populate_pgd() fails.
Also, please try to catch full dmesg and the whole oops.

Btw, Matt, your whole efi/next stuff is already in tip, right? Because
if so, Linn could simply test latest tip/master.

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/

Re: [PATCH v3 4/4] x86: Pass memory range via E820 for kdump

[Borislav Petkov]

On Sat, Mar 15, 2014 at 03:26:25PM +0100, Borislav Petkov wrote:
> Also, please try to catch full dmesg and the whole oops.

Ok, nevermind, I've got your mail with full dmesg in my other mbox; I'll
take a look next week.

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/

Re: [PATCH] iio: force snprintf for PAGE_SIZE bufs

[Jonathan Cameron]

On 13/03/14 16:46, Kees Cook wrote:

This is a tiny preventative measure to make sure we can't write beyond
PAGE_SIZE on the buffers being used in sysfs for iio. There is currently
no way for this to happen, but the change makes this code more robust
for the future.

Signed-off-by: Kees Cook 

A sensible enough change I guess.

Applied to the togreg branch of iio.git

Jonathan

---
  drivers/iio/industrialio-core.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a836ca..64bb64f35af8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -340,7 +340,7 @@ ssize_t iio_enum_read(struct iio_dev *indio_dev,
else if (i >= e->num_items)
return -EINVAL;

-   return sprintf(buf, "%s\n", e->items[i]);
+   return snprintf(buf, PAGE_SIZE, "%s\n", e->items[i]);
  }
  EXPORT_SYMBOL_GPL(iio_enum_read);

@@ -836,7 +836,7 @@ static ssize_t iio_show_dev_name(struct device *dev,
 char *buf)
  {
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   return sprintf(buf, "%s\n", indio_dev->name);
+   return snprintf(buf, PAGE_SIZE, "%s\n", indio_dev->name);
  }

  static DEVICE_ATTR(name, S_IRUGO, iio_show_dev_name, 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 v3 4/4] x86: Pass memory range via E820 for kdump

[Matt Fleming]

On Sat, 15 Mar, at 03:26:25PM, Borislav Petkov wrote:
> 
> Btw, Matt, your whole efi/next stuff is already in tip, right? Because
> if so, Linn could simply test latest tip/master.

Yep, everything is in tip/master.

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

Re: [PATCH v8 1/2] iio:as3935: Add DT binding docs for AS3935 driver

[Jonathan Cameron]

On 12/03/14 14:30, Rob Herring wrote:

On Wed, Mar 12, 2014 at 7:53 AM, Matt Ranostay  wrote:

Document compatible string, required and optional DT properties for
AS3935 chipset driver.

Signed-off-by: Matt Ranostay 


Acked-by: Rob Herring 

Applied to the togreg branch of iio.git (probably pushed out as testing
first to allow the autobuilders to play.

Thanks

Jonathan



---
  .../devicetree/bindings/iio/proximity/as3935.txt   | 28 ++
  .../devicetree/bindings/vendor-prefixes.txt|  1 +
  2 files changed, 29 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt

diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
new file mode 100644
index 000..ae23dd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
@@ -0,0 +1,28 @@
+Austrian Microsystems AS3935 Franklin lightning sensor device driver
+
+Required properties:
+   - compatible: must be "ams,as3935"
+   - reg: SPI chip select number for the device
+   - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
+   slave node bindings.
+   - interrupt-parent : should be the phandle for the interrupt controller
+   - interrupts : the sole interrupt generated by the device
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+Optional properties:
+   - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping
+ value 0 - 120pF. This will require using the calibration data from
+ the manufacturer.
+
+Example:
+
+as3935@0 {
+   compatible = "ams,as3935";
+   reg = <0>;
+   spi-cpha;
+   interrupt-parent = <&gpio1>;
+   interrupts = <16 1>;
+   ams,tuning-capacitor-pf = <80>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4685ec3..517831d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -11,6 +11,7 @@ akAsahi Kasei Corp.
  allwinner  Allwinner Technology Co., Ltd.
  altr   Altera Corp.
  amcc   Applied Micro Circuits Corporation (APM, formally AMCC)
+amsAMS AG
  amstaosAMS-Taos Inc.
  apmApplied Micro Circuits Corporation (APM)
  armARM Ltd.
--
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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



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

Re: [PATCH v8 2/2] iio: Add AS3935 lightning sensor support

[Jonathan Cameron]

On 13/03/14 02:09, Marek Vasut wrote:

On Wednesday, March 12, 2014 at 01:53:14 PM, Matt Ranostay wrote:

AS3935 chipset can detect lightning strikes and reports those back as
events and the estimated distance to the storm.

Signed-off-by: Matt Ranostay 


Reviewed-by: Marek Vasut 

I'm not 100% happy with sensor_sensitivity but don't have a better idea.
As it is device specific lets leave it be for now.   Should we come
up with a better idea later it isn't much extra code to keep supporting
this interface going forwards.

Applied to the togreg branch of iio.git (pushed out initially as testing)

Thanks,

Jonathan

--
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 0/2] irqchip: sun4i: Use handle_fasteoi_irq for all irqs

[Hans de Goede]

Hi All,

Here is v2 of my patchset for sun4i-irq.c to use handle_fasteoi_irq for all
irqs + follow up clean-up patch.

Changes since v2:
-adjust commit msg based on Thomas' comments, and merge patch 1 and 2 as
 they make more sense as 1 patch

Regards,

Hans
--
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] irqchip: sun4i: simplify sun4i_irq_ack

[Hans de Goede]

Now that we only ack irq 0 the code can be simplified a lot.

Also switch from read / modify / write to a simple write clear:
1) This is what the android code does (it has a hack for acking irq 0
  in its unmask code doing this)
2) read / modify / write simply does not make sense for an irq status
  register like this, if the other bits are writeable (and the data sheet says
  they are not) they should be write 1 to clear, since otherwise a read /
  modify / write can race with a device raising an interrupt and then clear
  the pending bit unintentionally

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 6a8c88d..75615b5 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -41,16 +41,11 @@ static asmlinkage void __exception_irq_entry 
sun4i_handle_irq(struct pt_regs *re
 static void sun4i_irq_ack(struct irq_data *irqd)
 {
unsigned int irq = irqd_to_hwirq(irqd);
-   unsigned int irq_off = irq % 32;
-   int reg = irq / 32;
-   u32 val;
 
if (irq != 0)
return; /* Only IRQ 0 / the ENMI needs to be acked */
 
-   val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
-   writel(val | (1 << irq_off),
-  sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
+   writel(BIT(0), sun4i_irq_base + SUN4I_IRQ_PENDING_REG(0));
 }
 
 static void sun4i_irq_mask(struct irq_data *irqd)
-- 
1.9.0

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

[PATCH v2 1/2] irqchip: sun4i: Use handle_fasteoi_irq for all interrupts

[Hans de Goede]

Since the sun4i irq chip does not require any action and clears the interrupt
when the level goes back to inactive, we don't need to mask / unmask for
non oneshot IRQs, to achieve this we make sun4i_irq_ack a nop for all irqs
except irq 0 and use handle_fasteoi_irq for all interrupts.

Now there might be a case when the device reactivates the interrupt
before the RETI. But that does not matter as we run the primary
interrupt handlers with interrupts disabled.

This also allows us to get rid of needing to use 2 irq_chip structs, this
means that the IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED will now influence
all interrupts rather then just irq 0, but that does not matter as the eoi
is now a nop anyways for all interrupts but irq 0.

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a0ed1ea..6a8c88d 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -45,6 +45,9 @@ static void sun4i_irq_ack(struct irq_data *irqd)
int reg = irq / 32;
u32 val;
 
+   if (irq != 0)
+   return; /* Only IRQ 0 / the ENMI needs to be acked */
+
val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
writel(val | (1 << irq_off),
   sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
@@ -76,13 +79,6 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
 
 static struct irq_chip sun4i_irq_chip = {
.name   = "sun4i_irq",
-   .irq_mask   = sun4i_irq_mask,
-   .irq_unmask = sun4i_irq_unmask,
-};
-
-/* IRQ 0 / the ENMI needs a late eoi call */
-static struct irq_chip sun4i_irq_chip_enmi = {
-   .name   = "sun4i_irq",
.irq_eoi= sun4i_irq_ack,
.irq_mask   = sun4i_irq_mask,
.irq_unmask = sun4i_irq_unmask,
@@ -92,13 +88,7 @@ static struct irq_chip sun4i_irq_chip_enmi = {
 static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
 irq_hw_number_t hw)
 {
-   if (hw == 0)
-   irq_set_chip_and_handler(virq, &sun4i_irq_chip_enmi,
-handle_fasteoi_irq);
-   else
-   irq_set_chip_and_handler(virq, &sun4i_irq_chip,
-handle_level_irq);
-
+   irq_set_chip_and_handler(virq, &sun4i_irq_chip, handle_fasteoi_irq);
set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
 
return 0;
-- 
1.9.0

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

Fwd: vmcore-dmesg ends with "No program header covering vaddr"

[Prasad Koya]

Forwarding to lkml. If there is any other relevant mailing list, pl let me know.


-- Forwarded message --
From: Prasad Koya 
Date: Fri, Mar 14, 2014 at 10:39 PM
Subject: vmcore-dmesg ends with "No program header covering vaddr"
To: ke...@lists.infradead.org


Hi

I'm increasing dmesg buffer size at runtime by passing log_buf_len=1M
(or 512K) at command line. At compile time, I have LOG_BUF_LEN as
256K. However, when this kernel crashes (crashkernel set at 64M),
vmcore-dmesg fails with below error.

No program header covering vaddr 0x88013ff0found kexec bug?

Am I missing something here?

Thank you.

Here are some debugs I added to kernel. This is with 3.4 kernel and
I've tried with kexec-tools-2.0.4.

[0.00] log_buf_len_setup: log_buf_len 262144 new 1048576
8170b140
[0.00] setup_log_buf: early 1 262144 new_log_buf_len 1048576
[0.00] log_buf_len: 1048576 880037d58000
[0.00] early log buf free: 258671(98%)
[0.00] setup_log_buf: early 0 1048576 new_log_buf_len 0
[0.503752] log_buf_kexec_setup: lbl 1048576 new 0 816198c4
logbuf 880037d58000
In kdump, running vmcore_dmesg /proc/vmcore
No program header covering vaddr 0x88013ff0found kexec bug?
--
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: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 05:45 PM, Richard Weinberger wrote:

On Fri, Mar 14, 2014 at 10:29 PM, Ilia Mirkin  wrote:

On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:

Hi!

It seems /proc/acpi/battery interface is gone, and I don't see any
option to reintroduce it... what is going on?


The interface went away in a semi-recent kernel release (3.13 or
3.12), breaking pretty much every battery app. (Admittedly the
interface was marked as deprecated for quite some time, but that
didn't stop everyone from using it and not caring about the new
thing.) I've yet to find a windowmaker dock app that works with the
current sysfs API :(



commit 1e2d9cdfb4494fce682b4ae010d86a2766816d36
Author: Lan Tianyu 
Date:   Fri Oct 11 09:54:08 2013 +0800

 ACPI / Battery: Remove battery's proc directory

 The battery's proc directory isn't useded and remove it.

 Signed-off-by: Lan Tianyu 
 Signed-off-by: Rafael J. Wysocki 

Looks like this one is the said commit.
If it breaks userspace we have to revert it IMHO.



Yes, we will revert the commit if it really breaks some APPs.
--
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] virtio-blk: make the queue depth the max supportable by the hypervisor

[Theodore Ts'o]

On Sat, Mar 15, 2014 at 06:57:23AM -0700, Christoph Hellwig wrote:
> I don't think this should be a module parameter.  The default sizing
> should be based of the parameters of the actual virtqueue, and if we
> want to allow tuning it it should be by a sysfs attribute, preferable
> using the same semantics as SCSI.

I wanted that too, but looking at the multiqueue code, it wasn't all
obvious how to safely adjust the queue depth once the virtio-blk
device driver is initialized and becomes active.  There are all sorts
data structures including bitmaps, etc. that would have to be resized,
and I decided it would be too difficult / risky for me to make it be
dynamically resizeable.

So I settled on a module parameter thinking it would mostly only used
by testers / benchmarkers.

Can someone suggest a way to do a dynamic resizing of the virtio-blk
queue depth easily / safely?

- Ted
--
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: [PATCHv2 1/9] mfd: twl4030-madc: Use managed resources

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Update twl4030-madc driver to use managed resources.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 

Acked-by: Jonathan Cameron 

---
  drivers/mfd/twl4030-madc.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 4c583e4..5458561 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -702,14 +702,14 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(&pdev->dev);
-   int ret;
+   int irq, ret;
u8 regval;

if (!pdata) {
dev_err(&pdev->dev, "platform_data not available\n");
return -EINVAL;
}
-   madc = kzalloc(sizeof(*madc), GFP_KERNEL);
+   madc = devm_kzalloc(&pdev->dev, sizeof(*madc), GFP_KERNEL);
if (!madc)
return -ENOMEM;

@@ -726,7 +726,7 @@ static int twl4030_madc_probe(struct platform_device *pdev)
TWL4030_MADC_ISR1 : TWL4030_MADC_ISR2;
ret = twl4030_madc_set_power(madc, 1);
if (ret < 0)
-   goto err_power;
+   return ret;
ret = twl4030_madc_set_current_generator(madc, 0, 1);
if (ret < 0)
goto err_current_generator;
@@ -770,7 +770,9 @@ static int twl4030_madc_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, madc);
mutex_init(&madc->lock);
-   ret = request_threaded_irq(platform_get_irq(pdev, 0), NULL,
+
+   irq = platform_get_irq(pdev, 0);
+   ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
   twl4030_madc_threaded_irq_handler,
   IRQF_TRIGGER_RISING, "twl4030_madc", madc);
if (ret) {
@@ -783,9 +785,6 @@ err_i2c:
twl4030_madc_set_current_generator(madc, 0, 0);
  err_current_generator:
twl4030_madc_set_power(madc, 0);
-err_power:
-   kfree(madc);
-
return ret;
  }

@@ -793,10 +792,8 @@ static int twl4030_madc_remove(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc = platform_get_drvdata(pdev);

-   free_irq(platform_get_irq(pdev, 0), madc);
twl4030_madc_set_current_generator(madc, 0, 0);
twl4030_madc_set_power(madc, 0);
-   kfree(madc);

return 0;
  }



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

Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Johannes Berg]

On Thu, 2014-03-13 at 02:15 +0530, Krishna Chaitanya wrote:

> From the logs it looks like "rate_control_alloc" is failed,
> causing ieee80211_register_hw to fail triggering the crash.

Yes.

> what RC are u using? Default should be minstrel, i dont see
> a reason for rc alloc to fail (remote reason kmalloc failure),
> so did you disable RC completely? No prints either w.r.t RC either in
> dmesg?

Pay attention to the .config.

johannes

--
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: [PATCHv2 2/9] mfd: twl4030-madc: Add DT support and convert to IIO framework

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.

Signed-off-by: Sebastian Reichel 

One issues right down in the remove function alongside the ones Lee raised.
Otherwise looks pretty much there to me.

---
  drivers/mfd/twl4030-madc.c | 126 +
  1 file changed, 116 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 5458561..0479af0 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -47,11 +47,14 @@
  #include 
  #include 

+#include 
+
  /*
   * struct twl4030_madc_data - a container for madc info
   * @dev - pointer to device structure for madc
   * @lock - mutex protecting this data structure
   * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq - IRQ selection (main or co-processor)
   * @imr - Interrupt mask register of MADC
   * @isr - Interrupt status register of MADC
   */
@@ -59,10 +62,71 @@ struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   bool use_second_irq;
int imr;
int isr;
  };

+static int twl4030_madc_read(struct iio_dev *iio_dev,
+const struct iio_chan_spec *chan,
+int *val, int *val2, long mask)
+{
+   struct twl4030_madc_data *madc = iio_priv(iio_dev);
+   struct twl4030_madc_request req;
+   int ret;
+
+   req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+   req.channels = BIT(chan->channel);
+   req.active = false;
+   req.func_cb = NULL;
+   req.type = TWL4030_MADC_WAIT;
+   req.raw = !(mask == IIO_CHAN_INFO_PROCESSED);
+   req.do_avg = (mask == IIO_CHAN_INFO_AVERAGE_RAW);
+
+   ret = twl4030_madc_conversion(&req);
+   if (ret < 0)
+   return ret;
+
+   *val = req.rbuf[chan->channel];
+
+   return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+   .read_raw = &twl4030_madc_read,
+   .driver_module = THIS_MODULE,
+};
+
+#define TWL4030_ADC_CHANNEL(_channel, _type, _name) {  \
+   .type = _type,  \
+   .channel = _channel,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW) | \
+ BIT(IIO_CHAN_INFO_PROCESSED), \
+   .datasheet_name = _name,\
+   .indexed = 1,   \
+}
+
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+   TWL4030_ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0"),
+   TWL4030_ADC_CHANNEL(1, IIO_TEMP, "ADCIN1"),
+   TWL4030_ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2"),
+   TWL4030_ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3"),
+   TWL4030_ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4"),
+   TWL4030_ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5"),
+   TWL4030_ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6"),
+   TWL4030_ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7"),
+   TWL4030_ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8"),
+   TWL4030_ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9"),
+   TWL4030_ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10"),
+   TWL4030_ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11"),
+   TWL4030_ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12"),
+   TWL4030_ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13"),
+   TWL4030_ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14"),
+   TWL4030_ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15"),
+};
+
  static struct twl4030_madc_data *twl4030_madc;

  struct twl4030_prescale_divider_ratios {
@@ -702,28 +766,50 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+   struct device_node *np = pdev->dev.of_node;
int irq, ret;
u8 regval;
+   struct iio_dev *iio_dev = NULL;

-   if (!pdata) {
-   dev_err(&pdev->dev, "platform_data not available\n");
+   if (!pdata && !np) {
+   dev_err(&pdev->dev, "neither platform data nor Device Tree node 
available\n");
return -EINVAL;
}
-   madc = devm_kzalloc(&pdev->dev, sizeof(*madc), GFP_KERNEL);
-   if (!madc)
+
+   iio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*madc));
+   if (!iio_dev) {
+   dev_err(&pdev->dev, "failed allocating iio device\n");
return -ENOMEM;
+   }

+   madc = iio_priv(iio_dev);
madc->dev = &pdev->dev;
+   madc->use_second_irq = false;
+
+   iio_dev->name = dev_name(&pdev->dev);
+   iio_dev->dev.parent = &pdev->dev;
+   iio_dev->dev.of_node = pdev->dev.of_node;
+   iio_dev->info = &twl40

Re: [PATCHv2 3/9] mfd: twl4030-madc: Cleanup driver

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Some style fixes in twl4030-madc driver.

Reported-by: Jonathan Cameron 

Gah - not sure I want to be known for reporting style
issues :)

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 

Looks good - one little whilst you are here comment below.
Acked-by: Jonathan Cameron 
whether you do that or not.  We can hardly hold there being
remaining style issues against a style cleanup patch ;)

---
  drivers/mfd/twl4030-madc.c   | 125 +++
  include/linux/i2c/twl4030-madc.h |   2 +-
  2 files changed, 61 insertions(+), 66 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 0479af0..f37da65 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -49,22 +49,22 @@

  #include 

-/*
+/**
   * struct twl4030_madc_data - a container for madc info
- * @dev - pointer to device structure for madc
- * @lock - mutex protecting this data structure
- * @requests - Array of request struct corresponding to SW1, SW2 and RT
- * @use_second_irq - IRQ selection (main or co-processor)
- * @imr - Interrupt mask register of MADC
- * @isr - Interrupt status register of MADC
+ * @dev:   Pointer to device structure for madc
+ * @lock:  Mutex protecting this data structure
+ * @requests:  Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq:IRQ selection (main or co-processor)
+ * @imr:   Interrupt mask register of MADC
+ * @isr:   Interrupt status register of MADC
   */
  struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
-   int imr;
-   int isr;
+   u8 imr;
+   u8 isr;
  };

  static int twl4030_madc_read(struct iio_dev *iio_dev,
@@ -155,17 +155,16 @@ twl4030_divider_ratios[16] = {
  };


-/*
- * Conversion table from -3 to 55 degree Celcius
- */
-static int therm_tbl[] = {
-30800, 29500,  28300,  27100,
-26000, 24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,  17900,
-17200, 16500,  15900,  15300,  14700,  14100,  13600,  13100,  12600,  12100,
-11600, 11200,  10800,  10400,  1,  9630,   9280,   8950,   8620,   8310,
-8020,  7730,   7460,   7200,   6950,   6710,   6470,   6250,   6040,   5830,
-5640,  5450,   5260,   5090,   4920,   4760,   4600,   4450,   4310,   4170,
-4040,  3910,   3790,   3670,   3550
+/* Conversion table from -3 to 55 degrees Celcius */
+static int twl4030_therm_tbl[] = {
+   30800,  29500,  28300,  27100,
+   26000,  24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,
+   17900,  17200,  16500,  15900,  15300,  14700,  14100,  13600,  13100,
+   12600,  12100,  11600,  11200,  10800,  10400,  1,  9630,   9280,
+   8950,   8620,   8310,   8020,   7730,   7460,   7200,   6950,   6710,
+   6470,   6250,   6040,   5830,   5640,   5450,   5260,   5090,   4920,
+   4760,   4600,   4450,   4310,   4170,   4040,   3910,   3790,   3670,
+   3550
  };

  /*
@@ -197,11 +196,12 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  },
  };

-/*
- * Function to read a particular channel value.
- * @madc - pointer to struct twl4030_madc_data
- * @reg - lsb of ADC Channel
- * If the i2c read fails it returns an error else returns 0.
+/**
+ * twl4030_madc_channel_raw_read() - Function to read a particular channel 
value
+ * @madc:  pointer to struct twl4030_madc_data
+ * @reg:   lsb of ADC Channel
+ *
+ * Return: 0 on success, an error code otherwise.
   */
  static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
  {
@@ -227,7 +227,7 @@ static int twl4030_madc_channel_raw_read(struct 
twl4030_madc_data *madc, u8 reg)
  }

  /*
- * Return battery temperature
+ * Return battery temperature in degrees Celsius
   * Or < 0 on failure.
   */
  static int twl4030battery_temperature(int raw_volt)
@@ -236,18 +236,18 @@ static int twl4030battery_temperature(int raw_volt)
int temp, curr, volt, res, ret;

volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
-   /* Getting and calculating the supply current in micro ampers */
+   /* Getting and calculating the supply current in micro amperes */
ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, &val,
REG_BCICTL2);
if (ret < 0)
return ret;
+
curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
/* Getting and calculating the thermistor resistance in ohms */
res = volt * 1000 / curr;
/* calculating temperature */
for (temp = 58; temp >= 0; temp--) {
-   int actual = therm_tbl[temp];
-
+   int actual = twl4030_therm_tbl[temp];
if ((actual - res) >= 0)
break;

Re: [PATCHv2 6/9] Documentation: DT: Document twl4030-madc binding

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add devicetree binding documentation for twl4030-madc
analog digital converter.

Signed-off-by: Sebastian Reichel 

I'm happy with this, but it needs the usual sign off form a device tree
maintainer or 3 weeks to pass since it was posted.
Acked-by: Jonathan Cameron 

---
  .../devicetree/bindings/iio/adc/twl4030-madc.txt   | 24 ++
  1 file changed, 24 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt 
b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
new file mode 100644
index 000..6bdd214
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
@@ -0,0 +1,24 @@
+* TWL4030 Monitoring Analog to Digital Converter (MADC)
+
+The MADC subsystem in the TWL4030 consists of a 10-bit ADC
+combined with a 16-input analog multiplexer.
+
+Required properties:
+  - compatible: Should contain "ti,twl4030-madc".
+  - interrupts: IRQ line for the MADC submodule.
+  - #io-channel-cells: Should be set to <1>.
+
+Optional properties:
+  - ti,system-uses-second-madc-irq: boolean, set if the second madc irq 
register
+   should be used, which is intended to be used
+   by Co-Processors (e.g. a modem).
+
+Example:
+
+&twl {
+   madc {
+   compatible = "ti,twl4030-madc";
+   interrupts = <3>;
+   #io-channel-cells = <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: [PATCHv2 8/9] iio: documentation: Add ABI documentation for *_mean_raw

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add ABI documentation for in_*_mean_raw files, which are
already supported and used in the kernel for some time.

Signed-off-by: Sebastian Reichel 

Acked-by: Jonathan Cameron 

Thanks for doing this.

---
  Documentation/ABI/testing/sysfs-bus-iio | 8 
  1 file changed, 8 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..58ba333 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -210,6 +210,14 @@ Contact:   linux-...@vger.kernel.org
  Description:
Scaled humidity measurement in milli percent.

+What:  /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+KernelVersion: 3.5
+Contact:   linux-...@vger.kernel.org
+Description:
+   Averaged raw measurement from channel X. The number of values
+   used for averaging is device specific. The converting rules for
+   normal raw values also applies to the averaged raw values.
+
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset



--
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: [PATCHv2 9/9] iio: inkern: add iio_read_channel_average_raw

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add iio_read_channel_average_raw to support reading
averaged raw values in consumer drivers.

Signed-off-by: Sebastian Reichel 

Acked-by: Jonathan Cameron 

Sometimes these wrappers seem a little bit silly. There
might be a case for automating them somewhat via some
macros, but for now this is fine.

Docs should in theory probably be with the implementation,
but that's wrong throughout consumer.h so this isn't the time
to change it!

Jonathan

---
  drivers/iio/inkern.c | 18 ++
  include/linux/iio/consumer.h | 13 +
  2 files changed, 31 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..adeba5a 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -443,6 +443,24 @@ err_unlock:
  }
  EXPORT_SYMBOL_GPL(iio_read_channel_raw);

+int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
+{
+   int ret;
+
+   mutex_lock(&chan->indio_dev->info_exist_lock);
+   if (chan->indio_dev->info == NULL) {
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   ret = iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
+err_unlock:
+   mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
+
  static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan,
int raw, int *processed, unsigned int scale)
  {
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 2752b1f..651f9a0 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -123,6 +123,19 @@ int iio_read_channel_raw(struct iio_channel *chan,
 int *val);


Ah, my bad habits propogate onwards.  The docs should be with the 
implementation.
Oh well, at somepoint I'll clean all remaining cases of this up.

  /**
+ * iio_read_channel_average_raw() - read from a given channel
+ * @chan:  The channel being queried.
+ * @val:   Value read back.
+ *
+ * Note raw reads from iio channels are in adc counts and hence
+ * scale will need to be applied if standard units required.
+ *
+ * In opposit to the normal iio_read_channel_raw this function
+ * returns the average of multiple reads.
+ */
+int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
+
+/**
   * iio_read_channel_processed() - read processed value from a given channel
   * @chan: The channel being queried.
   * @val:  Value read back.



--
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: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:

Hi

On Saturday 15 March 2014, Rafael J. Wysocki wrote:

On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:

On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek  wrote:

On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:

On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:

[...]

wmbattery

They have attempted to use the sysfs api, but apparently that
integration was done with an older version of that API. There's also
some attempt to get it to work with upower, but I couldn't figure out
how to make that work either on my (up-to-date gentoo) box. (TBH I
didn't spend more than an hour or two on it, so it may not be
impossible.)


Tianyu, can you please have a look at this?


Disclaimer, I've never used wmbattery so far.

The current upstream version (2.42, released in early december 2013)
of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
it changed to using upower by default, with non-default fall-backs for
reading from sysfs.

The only change required for building upower with wmbattery 2.42
appears to be a new build-dependency on libupower-glib-dev (at least
on Debian, built from the upower source package). Given that this
version is present in Debian testing and unstable, I'd assume that it's
supposed to work using upower, although I haven't confirmed that myself.

Judging from the Gentoo ebuild, you probably just have to add
"sys-power/upower" to the RDEPEND variable and make sure to build
wmbattery 2.42; this is untested.



Hi Stefan:
	I just glance wmbattery code. I find the code in the acpi.c is already 
using the new sysfs battery interfaces, right?


...

#define SYSFS_PATH "/sys/class/power_supply"

...
char *acpi_labels[] = {
"uevent",
"status",
"BAT",
"AC",
"POWER_SUPPLY_CAPACITY=",
"POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
"POWER_SUPPLY_PRESENT=",
"POWER_SUPPLY_??_NOW=",
"POWER_SUPPLY_CURRENT_NOW=",
"POWER_SUPPLY_STATUS=",
#if ACPI_THERMAL
"thermal_zone",
#endif
"POWER_SUPPLY_ONLINE=",
"POWER_SUPPLY_??_FULL=",
NULL
};



Regards
Stefan Lippers-Hollmann

[1] Homepage: http://kitenet.net/~joey/code/wmbattery/
Vcs-Git: git://git.kitenet.net/wmbattery



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

Re: [PATCH 2/3] ARM: at91: at91sam9g45: change at91_adc name

[Jonathan Cameron]

On 10/03/14 13:26, Nicolas Ferre wrote:

On 06/03/2014 20:16, Jonathan Cameron :

On 05/03/14 16:57, Alexandre Belloni wrote:

We can't use "at91_adc" to refer to the at91_adc driver anymore as the name is
used to match an id_table.

Signed-off-by: Alexandre Belloni 

As stated in previous email, I'll take this along with the fix that 'broke'
this, if I get an Ack from one of the at91 maintainers.


Jonathan,

It is maybe more clear if I answer here:
- so, yes, you can take the 3 patches yourself (if you do not mind)
- you have, for the whole series::

Acked-by: Nicolas Ferre 

Applied to the fixes-togreg branch of iio.git

Timing wise, these will now hit immediately after the merge window closes.

Jonathan


Thanks for your help with this issue.

Bye,


---
   arch/arm/mach-at91/at91sam9g45_devices.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c 
b/arch/arm/mach-at91/at91sam9g45_devices.c
index cb36fa872d30..88554024eb2d 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -1203,7 +1203,7 @@ static struct resource adc_resources[] = {
   };

   static struct platform_device at91_adc_device = {
-   .name   = "at91_adc",
+   .name   = "at91sam9g45-adc",
.id = -1,
.dev= {
.platform_data  = &adc_data,









--
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: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Krishna Chaitanya]

On Sat, Mar 15, 2014 at 8:50 PM, Johannes Berg
 wrote:
>
> On Thu, 2014-03-13 at 02:15 +0530, Krishna Chaitanya wrote:
>
> > From the logs it looks like "rate_control_alloc" is failed,
> > causing ieee80211_register_hw to fail triggering the crash.
>
> Yes.
>
> > what RC are u using? Default should be minstrel, i dont see
> > a reason for rc alloc to fail (remote reason kmalloc failure),
> > so did you disable RC completely? No prints either w.r.t RC either in
> > dmesg?
>
> Pay attention to the .config.
>
Missed the attachment, thanks for pointing.
As guessed the rate control is empty causing the registration fail.

CONFIG_MAC80211=y
# CONFIG_MAC80211_RC_PID is not set
# CONFIG_MAC80211_RC_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT=""
--
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: [PATCHv3 1/9] mfd: twl4030-madc: Use managed resources

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Update twl4030-madc driver to use managed resources.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Tested-by: Marek Belisko 

My email client was having a crazy day and not showing me this revision of the
patches - I'll bring my comments across so they don't get lost.

Acked-by: Jonathan Cameron 


--
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: [PATCHv3 2/9] mfd: twl4030-madc: Add DT support and convert to IIO framework

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.

Signed-off-by: Sebastian Reichel 
Tested-by: Marek Belisko 


One issue in the remove function.  Reorder that
and I'm happy.


---
  drivers/mfd/twl4030-madc.c | 127 +
  1 file changed, 116 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 5458561..1c5c4db 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -47,11 +47,14 @@
  #include 
  #include 

+#include 
+
  /*
   * struct twl4030_madc_data - a container for madc info
   * @dev - pointer to device structure for madc
   * @lock - mutex protecting this data structure
   * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq - IRQ selection (main or co-processor)
   * @imr - Interrupt mask register of MADC
   * @isr - Interrupt status register of MADC
   */
@@ -59,10 +62,71 @@ struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   bool use_second_irq;
int imr;
int isr;
  };

+static int twl4030_madc_read(struct iio_dev *iio_dev,
+const struct iio_chan_spec *chan,
+int *val, int *val2, long mask)
+{
+   struct twl4030_madc_data *madc = iio_priv(iio_dev);
+   struct twl4030_madc_request req;
+   int ret;
+
+   req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+   req.channels = BIT(chan->channel);
+   req.active = false;
+   req.func_cb = NULL;
+   req.type = TWL4030_MADC_WAIT;
+   req.raw = !(mask == IIO_CHAN_INFO_PROCESSED);
+   req.do_avg = (mask == IIO_CHAN_INFO_AVERAGE_RAW);
+
+   ret = twl4030_madc_conversion(&req);
+   if (ret < 0)
+   return ret;
+
+   *val = req.rbuf[chan->channel];
+
+   return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+   .read_raw = &twl4030_madc_read,
+   .driver_module = THIS_MODULE,
+};
+
+#define TWL4030_ADC_CHANNEL(_channel, _type, _name) {  \
+   .type = _type,  \
+   .channel = _channel,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW) | \
+ BIT(IIO_CHAN_INFO_PROCESSED), \
+   .datasheet_name = _name,\
+   .indexed = 1,   \
+}
+
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+   TWL4030_ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0"),
+   TWL4030_ADC_CHANNEL(1, IIO_TEMP, "ADCIN1"),
+   TWL4030_ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2"),
+   TWL4030_ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3"),
+   TWL4030_ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4"),
+   TWL4030_ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5"),
+   TWL4030_ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6"),
+   TWL4030_ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7"),
+   TWL4030_ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8"),
+   TWL4030_ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9"),
+   TWL4030_ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10"),
+   TWL4030_ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11"),
+   TWL4030_ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12"),
+   TWL4030_ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13"),
+   TWL4030_ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14"),
+   TWL4030_ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15"),
+};
+
  static struct twl4030_madc_data *twl4030_madc;

  struct twl4030_prescale_divider_ratios {
@@ -702,28 +766,49 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+   struct device_node *np = pdev->dev.of_node;
int irq, ret;
u8 regval;
+   struct iio_dev *iio_dev = NULL;

-   if (!pdata) {
-   dev_err(&pdev->dev, "platform_data not available\n");
+   if (!pdata && !np) {
+   dev_err(&pdev->dev, "neither platform data nor Device Tree node 
available\n");
return -EINVAL;
}
-   madc = devm_kzalloc(&pdev->dev, sizeof(*madc), GFP_KERNEL);
-   if (!madc)
+
+   iio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*madc));
+   if (!iio_dev) {
+   dev_err(&pdev->dev, "failed allocating iio device\n");
return -ENOMEM;
+   }

+   madc = iio_priv(iio_dev);
madc->dev = &pdev->dev;

+   iio_dev->name = dev_name(&pdev->dev);
+   iio_dev->dev.parent = &pdev->dev;
+   iio_dev->dev.of_node = pdev->dev.of_node;
+   iio_dev->info = &twl4030_madc_iio_info;
+   iio_dev->modes = INDIO_DIRECT_MODE;
+  

Re: [PATCHv3 3/9] mfd: twl4030-madc: Cleanup driver

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Some style fixes in twl4030-madc driver.

Reported-by: Jonathan Cameron 
Reported-by: Lee Jones 
Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Tested-by: Marek Belisko 

Acked-by: Jonathan Cameron 

One, whilst you are here request below.

---
  drivers/mfd/twl4030-madc.c   | 127 +++
  include/linux/i2c/twl4030-madc.h |   2 +-
  2 files changed, 62 insertions(+), 67 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 1c5c4db..890d520 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -49,22 +49,22 @@

  #include 

-/*
+/**
   * struct twl4030_madc_data - a container for madc info
- * @dev - pointer to device structure for madc
- * @lock - mutex protecting this data structure
- * @requests - Array of request struct corresponding to SW1, SW2 and RT
- * @use_second_irq - IRQ selection (main or co-processor)
- * @imr - Interrupt mask register of MADC
- * @isr - Interrupt status register of MADC
+ * @dev:   Pointer to device structure for madc
+ * @lock:  Mutex protecting this data structure
+ * @requests:  Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq:IRQ selection (main or co-processor)
+ * @imr:   Interrupt mask register of MADC
+ * @isr:   Interrupt status register of MADC
   */
  struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
-   int imr;
-   int isr;
+   u8 imr;
+   u8 isr;
  };

  static int twl4030_madc_read(struct iio_dev *iio_dev,
@@ -155,17 +155,16 @@ twl4030_divider_ratios[16] = {
  };


-/*
- * Conversion table from -3 to 55 degree Celcius
- */
-static int therm_tbl[] = {
-30800, 29500,  28300,  27100,
-26000, 24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,  17900,
-17200, 16500,  15900,  15300,  14700,  14100,  13600,  13100,  12600,  12100,
-11600, 11200,  10800,  10400,  1,  9630,   9280,   8950,   8620,   8310,
-8020,  7730,   7460,   7200,   6950,   6710,   6470,   6250,   6040,   5830,
-5640,  5450,   5260,   5090,   4920,   4760,   4600,   4450,   4310,   4170,
-4040,  3910,   3790,   3670,   3550
+/* Conversion table from -3 to 55 degrees Celcius */
+static int twl4030_therm_tbl[] = {
+   30800,  29500,  28300,  27100,
+   26000,  24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,
+   17900,  17200,  16500,  15900,  15300,  14700,  14100,  13600,  13100,
+   12600,  12100,  11600,  11200,  10800,  10400,  1,  9630,   9280,
+   8950,   8620,   8310,   8020,   7730,   7460,   7200,   6950,   6710,
+   6470,   6250,   6040,   5830,   5640,   5450,   5260,   5090,   4920,
+   4760,   4600,   4450,   4310,   4170,   4040,   3910,   3790,   3670,
+   3550
  };

  /*
@@ -197,11 +196,12 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  },
  };

-/*
- * Function to read a particular channel value.
- * @madc - pointer to struct twl4030_madc_data
- * @reg - lsb of ADC Channel
- * If the i2c read fails it returns an error else returns 0.
+/**
+ * twl4030_madc_channel_raw_read() - Function to read a particular channel 
value
+ * @madc:  pointer to struct twl4030_madc_data
+ * @reg:   lsb of ADC Channel
+ *
+ * Return: 0 on success, an error code otherwise.
   */
  static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
  {
@@ -227,7 +227,7 @@ static int twl4030_madc_channel_raw_read(struct 
twl4030_madc_data *madc, u8 reg)
  }

  /*
- * Return battery temperature
+ * Return battery temperature in degrees Celsius
   * Or < 0 on failure.
   */
  static int twl4030battery_temperature(int raw_volt)
@@ -236,18 +236,18 @@ static int twl4030battery_temperature(int raw_volt)
int temp, curr, volt, res, ret;

volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
-   /* Getting and calculating the supply current in micro ampers */
+   /* Getting and calculating the supply current in micro amperes */
ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, &val,
REG_BCICTL2);
if (ret < 0)
return ret;
+
curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
/* Getting and calculating the thermistor resistance in ohms */
res = volt * 1000 / curr;
/* calculating temperature */
for (temp = 58; temp >= 0; temp--) {
-   int actual = therm_tbl[temp];
-
+   int actual = twl4030_therm_tbl[temp];
if ((actual - res) >= 0)
break;
}
@@ -269,11 +269,12 @@ static int twl4030battery_current(int raw_volt)
else /* slope of 0.88 mV/mA */
return (raw_volt * 

Re: [PATCHv3 8/9] iio: documentation: Add ABI documentation for *_mean_raw

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Add ABI documentation for in_*_mean_raw files, which are
already supported and used in the kernel for some time.

Signed-off-by: Sebastian Reichel 

As this one stands fine on it's own...

Applied to the togreg branch of iio.git

Thanks

---
  Documentation/ABI/testing/sysfs-bus-iio | 8 
  1 file changed, 8 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..58ba333 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -210,6 +210,14 @@ Contact:   linux-...@vger.kernel.org
  Description:
Scaled humidity measurement in milli percent.

+What:  /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+KernelVersion: 3.5
+Contact:   linux-...@vger.kernel.org
+Description:
+   Averaged raw measurement from channel X. The number of values
+   used for averaging is device specific. The converting rules for
+   normal raw values also applies to the averaged raw values.
+
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset



--
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: [PATCHv3 9/9] iio: inkern: add iio_read_channel_average_raw

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Add iio_read_channel_average_raw to support reading
averaged raw values in consumer drivers.

Signed-off-by: Sebastian Reichel 

As this one also stands fine on it's own and isn't actually used
by the rest of the patch set - applied to the togreg branch of iio.git
This will get pushed out initially as 'testing' for the autobuilders
to play.

Jonathan

---
  drivers/iio/inkern.c | 18 ++
  include/linux/iio/consumer.h | 13 +
  2 files changed, 31 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..adeba5a 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -443,6 +443,24 @@ err_unlock:
  }
  EXPORT_SYMBOL_GPL(iio_read_channel_raw);

+int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
+{
+   int ret;
+
+   mutex_lock(&chan->indio_dev->info_exist_lock);
+   if (chan->indio_dev->info == NULL) {
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   ret = iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
+err_unlock:
+   mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
+
  static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan,
int raw, int *processed, unsigned int scale)
  {
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 2752b1f..651f9a0 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -123,6 +123,19 @@ int iio_read_channel_raw(struct iio_channel *chan,
 int *val);

  /**
+ * iio_read_channel_average_raw() - read from a given channel
+ * @chan:  The channel being queried.
+ * @val:   Value read back.
+ *
+ * Note raw reads from iio channels are in adc counts and hence
+ * scale will need to be applied if standard units required.
+ *
+ * In opposit to the normal iio_read_channel_raw this function
+ * returns the average of multiple reads.
+ */
+int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
+
+/**
   * iio_read_channel_processed() - read processed value from a given channel
   * @chan: The channel being queried.
   * @val:  Value read back.



--
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: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Johannes Berg]

On Sat, 2014-03-15 at 21:03 +0530, Krishna Chaitanya wrote:

> > > what RC are u using? Default should be minstrel, i dont see
> > > a reason for rc alloc to fail (remote reason kmalloc failure),
> > > so did you disable RC completely? No prints either w.r.t RC either in
> > > dmesg?
> >
> > Pay attention to the .config.
> >
> Missed the attachment, thanks for pointing.
> As guessed the rate control is empty causing the registration fail.

It still shouldn't crash though. Looks like there's a fix in this
thread, can somebody verify & post it?

Thx,
johannes

--
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 01/10] perf, tools: Add jsmn `jasmine' JSON parser

[David Ahern]

On 3/14/14, 8:27 PM, Andi Kleen wrote:

On Fri, Mar 14, 2014 at 04:41:31PM -0600, David Ahern wrote:

On 3/14/14, 3:31 PM, Andi Kleen wrote:

@@ -374,6 +376,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
  LIB_OBJS += $(OUTPUT)util/record.o
  LIB_OBJS += $(OUTPUT)util/srcline.o
  LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/jsmn.o
+LIB_OBJS += $(OUTPUT)util/json.o

  LIB_OBJS += $(OUTPUT)ui/setup.o
  LIB_OBJS += $(OUTPUT)ui/helpline.o



CONFIG driven? Allow a user to omit this.


Why? It has no external dependencies. AFAIK that's the only reason for configs.


We have also talked about config driven builds to allow pieces to be 
omitted -- e.g., to keep binary size down for embedded systems. This is 
clearly a standalone piece so why not add the config upfront now?


David

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

Re: [PATCH 0/4] perf: trivial follow-ons to --list-cmds

[David Ahern]

On 3/14/14, 9:17 PM, Ramkumar Ramachandra wrote:

Hi,

With "perf kvm: introduce --list-cmds for use by scripts" accepted,
these are trivial follow-on patches to enable the same functionality
in kmem, mem, lock, and sched.

Thanks.

Ramkumar Ramachandra (4):
   perf kmem: introduce --list-cmds for use by scripts
   perf mem: introduce --list-cmds for use by scripts
   perf lock: introduce --list-cmds for use by scripts
   perf sched: introduce --list-cmds for use by scripts



All 4 look good to me.

Acked-by: David Ahern 
--
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/

[ INFO: possible circular locking dependency detected ]

[poma]

https://bugzilla.redhat.com/attachment.cgi?id=874823


poma

--
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: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> >>>They have attempted to use the sysfs api, but apparently that
> >>>integration was done with an older version of that API. There's also
> >>>some attempt to get it to work with upower, but I couldn't figure out
> >>>how to make that work either on my (up-to-date gentoo) box. (TBH I
> >>>didn't spend more than an hour or two on it, so it may not be
> >>>impossible.)
> >>
> >>Tianyu, can you please have a look at this?
> >
> >Disclaimer, I've never used wmbattery so far.
> >
> >The current upstream version (2.42, released in early december 2013)
> >of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
> >it changed to using upower by default, with non-default fall-backs for
> >reading from sysfs.
> >
> >The only change required for building upower with wmbattery 2.42
> >appears to be a new build-dependency on libupower-glib-dev (at least
> >on Debian, built from the upower source package). Given that this
> >version is present in Debian testing and unstable, I'd assume that it's
> >supposed to work using upower, although I haven't confirmed that myself.
> >
> >Judging from the Gentoo ebuild, you probably just have to add
> >"sys-power/upower" to the RDEPEND variable and make sure to build
> >wmbattery 2.42; this is untested.
> >
> 
> Hi Stefan:
>   I just glance wmbattery code. I find the code in the acpi.c is
> already using the new sysfs battery interfaces, right?
> 
> ...
> 
> #define SYSFS_PATH "/sys/class/power_supply"
> 
> ...
> char *acpi_labels[] = {
>   "uevent",
>   "status",
>   "BAT",
>   "AC",
>   "POWER_SUPPLY_CAPACITY=",
>   "POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
>   "POWER_SUPPLY_PRESENT=",
>   "POWER_SUPPLY_??_NOW=",
>   "POWER_SUPPLY_CURRENT_NOW=",
>   "POWER_SUPPLY_STATUS=",
> #if ACPI_THERMAL
>   "thermal_zone",
> #endif
>   "POWER_SUPPLY_ONLINE=",
>   "POWER_SUPPLY_??_FULL=",
>   NULL
> };

New kernel should work with old userspace... and clearly it does not.

Do you have test patch for a revert?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Krishna Chaitanya]

On Sat, Mar 15, 2014 at 9:11 PM, Johannes Berg
 wrote:
> On Sat, 2014-03-15 at 21:03 +0530, Krishna Chaitanya wrote:
>
>> > > what RC are u using? Default should be minstrel, i dont see
>> > > a reason for rc alloc to fail (remote reason kmalloc failure),
>> > > so did you disable RC completely? No prints either w.r.t RC either in
>> > > dmesg?
>> >
>> > Pay attention to the .config.
>> >
>> Missed the attachment, thanks for pointing.
>> As guessed the rate control is empty causing the registration fail.
>
> It still shouldn't crash though. Looks like there's a fix in this
> thread, can somebody verify & post it?
>
Yes, it should not crash. The change suggested by martin is not correct
there is no double free as the the list he mentioned will be empty.
(Only after successful registration we will add the radio to the list)

the problem here is platform_driver_unregister internally calls the
driver_unregister
which tries to get the kobject through get_device, but we have already
freed the kobject using
device_unregister (which calls device_del which frees the kobject).

In other failures cases we use mac80211_hwsim_free() and return, so the call to
platform_driver_unregister is not there, hence no crash.
--
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] perf sched latency: prettify printed table

[Ramkumar Ramachandra]

Cc: Frederic Weisbecker 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-sched.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 6a76a07..0c41a2b 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1124,7 +1124,7 @@ static void output_lat_thread(struct perf_sched *sched, 
struct work_atoms *work_
 
avg = work_list->total_lat / work_list->nb_atoms;
 
-   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %9.6f s\n",
+   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %12.6f s\n",
  (double)work_list->total_runtime / 1e6,
 work_list->nb_atoms, (double)avg / 1e6,
 (double)work_list->max_lat / 1e6,
@@ -1527,9 +1527,9 @@ static int perf_sched__lat(struct perf_sched *sched)
 
perf_sched__sort_lat(sched);
 
-   printf("\n 
---\n");
-   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at |\n");
-   printf(" 
---\n");
+   printf("\n 
-\n");
+   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at   |\n");
+   printf(" 
-\n");
 
next = rb_first(&sched->sorted_atom_root);
 
@@ -1541,7 +1541,7 @@ static int perf_sched__lat(struct perf_sched *sched)
next = rb_next(next);
}
 
-   printf(" 
-\n");
+   printf(" 
-\n");
printf("  TOTAL:|%11.3f ms |%9" PRIu64 " |\n",
(double)sched->all_runtime / 1e6, sched->all_count);
 
-- 
1.9.rc0.1.g9d22d25

--
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] iio: cm36651: Fix i2c client leak and possible NULL pointer dereference

[Jonathan Cameron]

On 06/03/14 09:33, Krzysztof Kozlowski wrote:

During probe the driver allocates dummy I2C devices (i2c_new_dummy())
but they aren't unregistered during driver remove or probe failure.

Additionally driver does not check the return value of i2c_new_dummy().
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later
dereferenced by i2c_smbus_{read,write}_data() functions.

Fix issues by properly checking for i2c_new_dummy() return value and
unregistering I2C devices on driver remove or probe failure.

Signed-off-by: Krzysztof Kozlowski 

Good catch, but the error path needs more care.

---
  drivers/iio/light/cm36651.c |   12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/iio/light/cm36651.c b/drivers/iio/light/cm36651.c
index a45e07492db3..e7e9a597159f 100644
--- a/drivers/iio/light/cm36651.c
+++ b/drivers/iio/light/cm36651.c
@@ -653,6 +653,11 @@ static int cm36651_probe(struct i2c_client *client,
cm36651->ps_client = i2c_new_dummy(client->adapter,
 CM36651_I2C_ADDR_PS);
cm36651->ara_client = i2c_new_dummy(client->adapter, CM36651_ARA);
+   if (!cm36651->ps_client || !cm36651->ara_client) {
+   dev_err(&client->dev, "%s: new i2c device failed\n", __func__);
+   ret = -ENODEV;
+   goto error_i2c_unregister;
+   }

The two failures need to be handled independently as we only want to unregister
those that succeeded.  i2c_new_dummy will not return an error and leave a device
registered.  This is particularly true given the first thing that 
i2c_unregister_device
does is to derefence the client pointer.  That will cause a segfault if you do 
it
for NULL as here.


mutex_init(&cm36651->lock);
indio_dev->dev.parent = &client->dev;
indio_dev->channels = cm36651_channels;
@@ -687,6 +692,11 @@ error_free_irq:
free_irq(client->irq, indio_dev);
  error_disable_reg:
regulator_disable(cm36651->vled_reg);
+error_i2c_unregister:
+   if (cm36651->ps_client)
+   i2c_unregister_device(cm36651->ps_client);
+   if (cm36651->ara_client)
+   i2c_unregister_device(cm36651->ara_client);
return ret;
  }

@@ -698,6 +708,8 @@ static int cm36651_remove(struct i2c_client *client)
iio_device_unregister(indio_dev);
regulator_disable(cm36651->vled_reg);
free_irq(client->irq, indio_dev);
+   i2c_unregister_device(cm36651->ps_client);
+   i2c_unregister_device(cm36651->ara_client);

Good catch.


return 0;
  }



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

[PATCH net-next,v2,0/1] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Haiyang Zhang]

In this updated version, I have re-written the send queue selection, which is
based on ndo_select_queue now. I also applied the stop/wake queue for each
queue separately as suggested by reviewers.

Tom Herbert  has submitted a Toeplitz library function with
some optimization. But it's not accepted yet. I'm still using my Toeplitz
implementation in netvsc module. Please accept my patch if no other issues, 
because it already provides significant performance enhancement at current
state. I will be happy to switch to the Toeplitz library function when it's
accepted in the future.

Haiyang Zhang (1):
  hyperv: Add support for virtual Receive Side Scaling (vRSS)

 drivers/net/hyperv/hyperv_net.h   |  111 ++-
 drivers/net/hyperv/netvsc.c   |  132 +-
 drivers/net/hyperv/netvsc_drv.c   |  104 -
 drivers/net/hyperv/rndis_filter.c |  186 -
 4 files changed, 500 insertions(+), 33 deletions(-)

-- 
1.7.4.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 net-next,v2,1/1] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Haiyang Zhang]

This feature allows multiple channels to be used by each virtual NIC.
It is available on Hyper-V host 2012 R2.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/hyperv_net.h   |  111 ++-
 drivers/net/hyperv/netvsc.c   |  132 +-
 drivers/net/hyperv/netvsc_drv.c   |  104 -
 drivers/net/hyperv/rndis_filter.c |  186 -
 4 files changed, 500 insertions(+), 33 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 13010b4..f67292f 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -28,6 +28,98 @@
 #include 
 #include 
 
+/* RSS related */
+#define OID_GEN_RECEIVE_SCALE_CAPABILITIES 0x00010203  /* query only */
+#define OID_GEN_RECEIVE_SCALE_PARAMETERS 0x00010204  /* query and set */
+
+#define NDIS_OBJECT_TYPE_RSS_CAPABILITIES 0x88
+#define NDIS_OBJECT_TYPE_RSS_PARAMETERS 0x89
+
+#define NDIS_RECEIVE_SCALE_CAPABILITIES_REVISION_2 2
+#define NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2 2
+
+struct ndis_obj_header {
+   u8 type;
+   u8 rev;
+   u16 size;
+} __packed;
+
+
+/* ndis_recv_scale_cap/cap_flag */
+#define NDIS_RSS_CAPS_MESSAGE_SIGNALED_INTERRUPTS 0x0100
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_ISR   0x0200
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_DPC   0x0400
+#define NDIS_RSS_CAPS_USING_MSI_X 0x0800
+#define NDIS_RSS_CAPS_RSS_AVAILABLE_ON_PORTS  0x1000
+#define NDIS_RSS_CAPS_SUPPORTS_MSI_X  0x2000
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV4  0x0100
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6  0x0200
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6_EX   0x0400
+
+struct ndis_recv_scale_cap { /* NDIS_RECEIVE_SCALE_CAPABILITIES */
+   struct ndis_obj_header hdr;
+   u32 cap_flag;
+   u32 num_int_msg;
+   u32 num_recv_que;
+   u16 num_indirect_tabent;
+} __packed;
+
+
+/* ndis_recv_scale_param flags */
+#define NDIS_RSS_PARAM_FLAG_BASE_CPU_UNCHANGED 0x0001
+#define NDIS_RSS_PARAM_FLAG_HASH_INFO_UNCHANGED0x0002
+#define NDIS_RSS_PARAM_FLAG_ITABLE_UNCHANGED   0x0004
+#define NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED 0x0008
+#define NDIS_RSS_PARAM_FLAG_DISABLE_RSS0x0010
+
+/* Hash info bits */
+#define NDIS_HASH_FUNC_TOEPLITZ 0x0001
+#define NDIS_HASH_IPV4  0x0100
+#define NDIS_HASH_TCP_IPV4  0x0200
+#define NDIS_HASH_IPV6  0x0400
+#define NDIS_HASH_IPV6_EX   0x0800
+#define NDIS_HASH_TCP_IPV6  0x1000
+#define NDIS_HASH_TCP_IPV6_EX   0x2000
+
+#define NDIS_RSS_INDIRECTION_TABLE_MAX_SIZE_REVISION_2 (128 * 4)
+#define NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2   40
+
+#define ITAB_NUM 128
+#define HASH_KEYLEN NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2
+extern u8 hash_key[];
+
+struct ndis_recv_scale_param { /* NDIS_RECEIVE_SCALE_PARAMETERS */
+   struct ndis_obj_header hdr;
+
+   /* Qualifies the rest of the information */
+   u16 flag;
+
+   /* The base CPU number to do receive processing. not used */
+   u16 base_cpu_number;
+
+   /* This describes the hash function and type being enabled */
+   u32 hashinfo;
+
+   /* The size of indirection table array */
+   u16 indirect_tabsize;
+
+   /* The offset of the indirection table from the beginning of this
+* structure
+*/
+   u32 indirect_taboffset;
+
+   /* The size of the hash secret key */
+   u16 hashkey_size;
+
+   /* The offset of the secret key from the beginning of this structure */
+   u32 kashkey_offset;
+
+   u32 processor_masks_offset;
+   u32 num_processor_masks;
+   u32 processor_masks_entry_size;
+};
+
+
 /* Fwd declaration */
 struct hv_netvsc_packet;
 struct ndis_tcp_ip_checksum_info;
@@ -39,6 +131,8 @@ struct xferpage_packet {
 
/* # of netvsc packets this xfer packet contains */
u32 count;
+
+   struct vmbus_channel *channel;
 };
 
 /*
@@ -54,6 +148,9 @@ struct hv_netvsc_packet {
bool is_data_pkt;
u16 vlan_tci;
 
+   u16 q_idx;
+   struct vmbus_channel *channel;
+
/*
 * Valid only for receives when we break a xfer page packet
 * into multiple netvsc packets
@@ -120,6 +217,7 @@ void netvsc_linkstatus_callback(struct hv_device 
*device_obj,
 int netvsc_recv_callback(struct hv_device *device_obj,
struct hv_netvsc_packet *packet,
struct ndis_tcp_ip_checksum_info *csum_info);
+extern void netvsc_channel_cb(void *context);
 int rndis_filter_open(struct hv_device *dev);
 int rndis_filter_close(struct hv_device *dev);
 int rndis_filter_device_add(struct hv_device *dev,
@@ -131,6 +229,7 @@ int rndis_filter_receive(struct hv_device *dev,
 int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter);
 int rndis_filter_set_device_ma

Re: [PATCH] iio: adc: at91_adc: correct default shtim value

[Jonathan Cameron]

On 05/03/14 11:04, Josh Wu wrote:

Hi, Alexandre

On 3/4/2014 2:07 AM, Alexandre Belloni wrote:

When sample_hold_time is zero (this is the case when DT is not used or if
atmel,adc-sample-hold-time is omitted), then the calculated shtim is large.

Make that 0, which is the default for that register and the ADC will then use a
sane value of 2/ADCCLK or 1/ADCCLK depending on the version.

Signed-off-by: Alexandre Belloni 


Thanks for the fix and

Acked-by: Josh Wu


Applied to the fixes-togreg branch of iio.git.
Note that is likely that this will go upstream after the merge window now.

--
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: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/15/2014 12:05 PM, Pavel Machek wrote:

Hi!


They have attempted to use the sysfs api, but apparently that
integration was done with an older version of that API. There's also
some attempt to get it to work with upower, but I couldn't figure out
how to make that work either on my (up-to-date gentoo) box. (TBH I
didn't spend more than an hour or two on it, so it may not be
impossible.)


Tianyu, can you please have a look at this?


Disclaimer, I've never used wmbattery so far.

The current upstream version (2.42, released in early december 2013)
of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
it changed to using upower by default, with non-default fall-backs for
reading from sysfs.

The only change required for building upower with wmbattery 2.42
appears to be a new build-dependency on libupower-glib-dev (at least
on Debian, built from the upower source package). Given that this
version is present in Debian testing and unstable, I'd assume that it's
supposed to work using upower, although I haven't confirmed that myself.

Judging from the Gentoo ebuild, you probably just have to add
"sys-power/upower" to the RDEPEND variable and make sure to build
wmbattery 2.42; this is untested.



Hi Stefan:
I just glance wmbattery code. I find the code in the acpi.c is
already using the new sysfs battery interfaces, right?

...

#define SYSFS_PATH "/sys/class/power_supply"

...
char *acpi_labels[] = {
"uevent",
"status",
"BAT",
"AC",
"POWER_SUPPLY_CAPACITY=",
"POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
"POWER_SUPPLY_PRESENT=",
"POWER_SUPPLY_??_NOW=",
"POWER_SUPPLY_CURRENT_NOW=",
"POWER_SUPPLY_STATUS=",
#if ACPI_THERMAL
"thermal_zone",
#endif
"POWER_SUPPLY_ONLINE=",
"POWER_SUPPLY_??_FULL=",
NULL
};


New kernel should work with old userspace... and clearly it does not.

Do you have test patch for a revert?

Pavel


Please try this patch.

commit 6cb7ea8975bf8ffafd893204f55eddd1aebd8ff6
Author: Lan Tianyu 
Date:   Sat Mar 15 12:20:15 2014 -0400

Revert "ACPI / Battery: Remove battery's proc directory" and "ACPI: 
Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"


The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery
directory and breaks some old userspace tools. This patch
is to revert them.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f60f11d..c9231b1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -43,6 +43,23 @@ config ACPI_SLEEP
depends on SUSPEND || HIBERNATION
default y

+config ACPI_PROCFS_POWER
+   bool "Deprecated power /proc/acpi directories"
+   depends on PROC_FS
+   help
+ For backwards compatibility, this option allows
+  deprecated power /proc/acpi/ directories to exist, even when
+  they have been replaced by functions in /sys.
+  The deprecated directories (and their replacements) include:
+ /proc/acpi/battery/* (/sys/class/power_supply/*)
+ /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
+ This option has no effect on /proc/acpi/ directories
+ and functions, which do not yet exist in /sys
+ This option, together with the proc directories, will be
+ deleted in 2.6.39.
+
+ Say N to delete power /proc/acpi/ directories that have moved to /sys/
+
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -47,6 +47,7 @@ acpi-y+= sysfs.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
+acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 ifdef CONFIG_ACPI_VIDEO
 acpi-y += video_detect.o
 endif
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 797a693..22c8696 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -36,6 +36,12 @@
 #include 
 #include 

+#ifdef CONFIG_ACPI_PROCFS_POWER
+#include 
+#include 
+#include 
+#endif
+
 #include 
 #include 

@@ -66,6 +72,19 @@ static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");

+#ifdef CONFIG_ACPI_PROCFS_POWER
+extern struct proc_dir_entry *acpi_lock_battery_dir(void);
+extern void *acpi_unlock_battery_dir(struct proc_dir_entry 
*acpi_battery_dir);

+
+enum acpi_battery_files {
+   info_tag = 0,
+   state_tag,
+   alarm_tag,
+   ACPI_BATTERY_NUMFILES,
+};
+
+#endif
+
 static const struct acpi_device_id battery_device_ids[] = {
{"PNP0C0A", 0},
{"", 0},
@@ -301,6 +320,14 @@ stati

Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers

[Ohad Ben-Cohen]

On Fri, Mar 14, 2014 at 5:23 PM, Josh Cartwright  wrote:
> So, are you suggesting that because fatal errors should be "extremely
> rare", a consuming driver should just assume that if NULL is returned
> from a hwspin_lock_request*() function that it was the "device not yet
> probed" case that was hit?

No - it's not the scarcity, it's the severity.

The error path that will be optimized here is an invalid id. If this
happens, the consumer will crash and burn, and I'm not sure that
slightly optimizing his death is very interesting?

BTW the hwspinlock core once did use ERR_PTR and friends, and it was
changed due to convincing arguments against that methodology on this
mailing list. We can change it back but we need a strong(er) case.

> Note that having the consumer/hwspinlock device relationship modeled in
> devicetree introduces more potential failure cases...

Yeah. Even the error above, presumed to be EPROBE_DEFER, may be a
symptom of some other fatal error that occurred, and we can't be sure
that a future request will surely be satisfied. So before we bloat our
code, I suggest that we wait for consumers to show up and see if
there's real benefit.

Thanks,
Ohad.
--
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/

[Fix PATCH] ACPI/Button: Add ACPI Button event via netlink routine

[Lan Tianyu]

Commit 1696d9d(ACPI: Remove the old /proc/acpi/event interface)
removes ACPI Button event which originally was sent to userspace via
/proc/acpi/event. This causes ACPI shutdown regression on gentoo
in the VirtualBox. Now ACPI events are sent to userspace via netlink.
This patch is to add ACPI Button event back via netlink routine.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=71721
Reported-and-tested-by: Richard Musil 
Signed-off-by: Lan Tianyu 
Cc:  # 3.11.x
---
 drivers/acpi/button.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 714e957..db35594 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -302,6 +302,10 @@ static void acpi_button_notify(struct acpi_device *device, 
u32 event)
input_sync(input);
 
pm_wakeup_event(&device->dev, 0);
+   acpi_bus_generate_netlink_event(
+   device->pnp.device_class,
+   dev_name(&device->dev),
+   event, ++button->pushed);
}
break;
default:
-- 
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/

[GIT PULL] SCSI fixes for 3.14-rc6

[James Bottomley]

This is a set of six fixes.  Two are instant crash/null deref types
(storvsc and isci reset fixes). The two qla2xxx are initialisation
problems that cause MSI-X failures and card misdetection, the isci
erroneous macro is actually illegal C that's causing a miscompile with
certain gcc versions and the be2iscsi bad if expression is a static
checker fix. 

The patch is available here:

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

The short changelog is:

Ales Novak (1):
  storvsc: NULL pointer dereference fix

Chad Dupuis (1):
  qla2xxx: Fix multiqueue MSI-X registration.

Dan Williams (1):
  isci: fix reset timeout handling

Giridhar Malavali (1):
  qla2xxx: Poll during initialization for ISP25xx and ISP83xx

Lukasz Dorau (1):
  isci: correct erroneous for_each_isci_host macro

Mike Christie (1):
  be2iscsi: fix bad if expression

The diffstat is:

 drivers/scsi/be2iscsi/be_main.c |  2 +-
 drivers/scsi/isci/host.h|  5 ++---
 drivers/scsi/isci/port_config.c |  7 ---
 drivers/scsi/isci/task.c|  2 +-
 drivers/scsi/qla2xxx/qla_def.h  |  3 +--
 drivers/scsi/qla2xxx/qla_isr.c  | 46 +++--
 drivers/scsi/storvsc_drv.c  |  3 +++
 7 files changed, 38 insertions(+), 30 deletions(-)

With the full diff below.

James

---

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 1f37505..5642a9b 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -325,7 +325,7 @@ static int beiscsi_eh_device_reset(struct scsi_cmnd *sc)
if (!abrt_task->sc || abrt_task->state == ISCSI_TASK_FREE)
continue;
 
-   if (abrt_task->sc->device->lun != abrt_task->sc->device->lun)
+   if (sc->device->lun != abrt_task->sc->device->lun)
continue;
 
/* Invalidate WRB Posted for this Task */
diff --git a/drivers/scsi/isci/host.h b/drivers/scsi/isci/host.h
index 4911310..22a9bb1 100644
--- a/drivers/scsi/isci/host.h
+++ b/drivers/scsi/isci/host.h
@@ -311,9 +311,8 @@ static inline struct Scsi_Host *to_shost(struct isci_host 
*ihost)
 }
 
 #define for_each_isci_host(id, ihost, pdev) \
-   for (id = 0, ihost = to_pci_info(pdev)->hosts[id]; \
-id < ARRAY_SIZE(to_pci_info(pdev)->hosts) && ihost; \
-ihost = to_pci_info(pdev)->hosts[++id])
+   for (id = 0; id < SCI_MAX_CONTROLLERS && \
+(ihost = to_pci_info(pdev)->hosts[id]); id++)
 
 static inline void wait_for_start(struct isci_host *ihost)
 {
diff --git a/drivers/scsi/isci/port_config.c b/drivers/scsi/isci/port_config.c
index 85c77f6..ac87974 100644
--- a/drivers/scsi/isci/port_config.c
+++ b/drivers/scsi/isci/port_config.c
@@ -615,13 +615,6 @@ static void sci_apc_agent_link_up(struct isci_host *ihost,
  
SCIC_SDS_APC_WAIT_LINK_UP_NOTIFICATION);
} else {
/* the phy is already the part of the port */
-   u32 port_state = iport->sm.current_state_id;
-
-   /* if the PORT'S state is resetting then the link up is from
-* port hard reset in this case, we need to tell the port
-* that link up is recieved
-*/
-   BUG_ON(port_state != SCI_PORT_RESETTING);
port_agent->phy_ready_mask |= 1 << phy_index;
sci_port_link_up(iport, iphy);
}
diff --git a/drivers/scsi/isci/task.c b/drivers/scsi/isci/task.c
index 0d30ca8..5d6fda7 100644
--- a/drivers/scsi/isci/task.c
+++ b/drivers/scsi/isci/task.c
@@ -801,7 +801,7 @@ int isci_task_I_T_nexus_reset(struct domain_device *dev)
/* XXX: need to cleanup any ireqs targeting this
 * domain_device
 */
-   ret = TMF_RESP_FUNC_COMPLETE;
+   ret = -ENODEV;
goto out;
}
 
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index e1fe95e..266724b 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2996,8 +2996,7 @@ struct qla_hw_data {
IS_QLA82XX(ha) || IS_QLA83XX(ha) || \
IS_QLA8044(ha))
 #define IS_MSIX_NACK_CAPABLE(ha) (IS_QLA81XX(ha) || IS_QLA83XX(ha))
-#define IS_NOPOLLING_TYPE(ha)  ((IS_QLA25XX(ha) || IS_QLA81XX(ha) || \
-   IS_QLA83XX(ha)) && (ha)->flags.msix_enabled)
+#define IS_NOPOLLING_TYPE(ha)  (IS_QLA81XX(ha) && (ha)->flags.msix_enabled)
 #define IS_FAC_REQUIRED(ha)(IS_QLA81XX(ha) || IS_QLA83XX(ha))
 #define IS_NOCACHE_VPD_TYPE(ha)(IS_QLA81XX(ha) || IS_QLA83XX(ha))
 #define IS_ALOGIO_CAPABLE(ha)  (IS_QLA23XX(ha) || IS_FWI2_CAPABLE(ha))
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 9bc86b9..0a1dcb4 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2880,6 +2880,7 @@ s

Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Linus Torvalds]

On Sat, Mar 15, 2014 at 6:51 AM, Sander Eikelenboom
 wrote:
>
>
> Ok but the breakage/regression was known since around the merge window.
> I thought the "standard policy" when things cause new regression and are not 
> fixable (too intrusive, too time consuming you
> name the reason), was to revert ..

It is indeed.

Guys, why is this being discussed? We should not release a
known-broken 3.14 just because the fix is too big for rc. Things
should be reverted.

   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 01/10] perf, tools: Add jsmn `jasmine' JSON parser

[Andi Kleen]

> Will this be useful for all arches?

Yes they could define their own JSON files, perhaps with minor
extensions of the parser and a new download sites in the downloader.

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

Re: kernel panic 3.11.7 in kmem_cache_alloc+0x66/0x150

[Linus Torvalds]

[ Going through old emails, this is probably stale by now since you
already figured out it was fixed in 3.13 ]

On Mon, Feb 24, 2014 at 3:47 AM, Jasper Spaans  wrote:
>
> Last weekend one of our machines showed some interesting behaviour, where
> processes seemed to be crashing randomly. Further inspection showed that
> all the oopses in syslog were on core #12, and had
> kmem_cache_alloc+0x66/0x150 as the RIP, except for the second one, which had
> kmem_cache_alloc_trace+0x6a/0x140 .

This indeed looks very much like the pipe use-after-free that was
fixed by commit b0d8d2292160 ("vfs: fix subtle use-after-free of
pipe_inode_info"), and afffects 3.10-3.12. It should be in stable
kernels, but you probably have a 3.11 that predates that stable
backport.

For 3.11, you need 3.11.10.2 or newer, but 3.12 or 3.13 stable sounds
like a better idea from a maintenance standpoint.

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/

[PATCH] ATHEROS-ALX: Use dma_set_mask_and_coherent and fix a bug

[Peter Senna Tschudin]

 1. For the 64 bits dma mask use dma_set_mask_and_coherent instead of
 dma_set_mask and dma_set_coherent_mask.

 2. For the 32 bits dma mask dma_set_coherent_mask is only called if
 dma_set_mask fails, which is unusual. Assuming this as a bug, fixes
 it by replacing calls to dma_set_mask and dma_set_coherent_mask by a
 call to dma_set_coherent_mask.
 
 Signed-off-by: Peter Senna Tschudin 
---

 Tested by compilation only.

 drivers/net/ethernet/atheros/alx/main.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 2e45f6e..380d249 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1248,19 +1248,13 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 * shared register for the high 32 bits, so only a single, aligned,
 * 4 GB physical address range can be used for descriptors.
 */
-   if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
-   !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
dev_dbg(&pdev->dev, "DMA to 64-BIT addresses\n");
} else {
-   err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(&pdev->dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(&pdev->dev,
-   "No usable DMA config, aborting\n");
-   goto out_pci_disable;
-   }
+   dev_err(&pdev->dev, "No usable DMA config, aborting\n");
+   goto out_pci_disable;
}
}
 
-- 
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] exit.c: call proc_exit_connector() after exit_state is set

[Linus Torvalds]

[ Going through old emails, adding relevant people, ie Oleg for
kernel/exit.c and David because he seems to be the go-to person for
connector issues judging by commits ]

Patch looks sane to me, and logically that exit_connector thing would
pair with exit_notify(), but I'd like some comments on it. That
usability issue/race has been there since forever afaik. We probably
should never have added that process events connector thing, but since
we did and people apparently use it..

Comments?

 Linus

On Mon, Feb 24, 2014 at 11:27 AM, Guillaume Morin  wrote:
> From: Guillaume Morin 
>
> The process events connector delivers a notification when a process
> exits.  This is really convenient for a process that spawns and wants
> to monitor its children through an epoll-able() interface.
>
> Unfortunately, there is a small window between when the event is
> delivered and the child become wait()-able.
>
> This is creates a race if the parent wants to make sure that it knows
> about the exit, e.g
>
> pid_t pid = fork();
> if (pid > 0) {
> register_interest_for_pid(pid);
> if (waitpid(pid, NULL, WNOHANG) > 0)
> {
>   /* We might have raced with exit() */
> }
> return;
> }
>
> /* Child */
> execve(...)
>
> register_interest_for_pid() would be telling the the connector socket
> reader to pay attention to events related to pid.
>
> Though this is not a bug, I think it would make the connector a bit
> more usable if this race was closed by simply moving the call to
> proc_exit_connector() from just before exit_notify() to right after.
>
> Signed-off-by: Guillaume Morin 
> Cc: matt.hels...@gmail.com
> ---
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 1e77fc6..9b0ac8c 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -804,7 +804,6 @@ void do_exit(long code)
>
> module_put(task_thread_info(tsk)->exec_domain->module);
>
> -   proc_exit_connector(tsk);
>
> /*
>  * FIXME: do that only when needed, using sched_exit tracepoint
> @@ -812,6 +811,7 @@ void do_exit(long code)
> flush_ptrace_hw_breakpoint(tsk);
>
> exit_notify(tsk, group_dead);
> +   proc_exit_connector(tsk);
>  #ifdef CONFIG_NUMA
> task_lock(tsk);
> mpol_put(tsk->mempolicy);
>
>
>
> --
> Guillaume Morin 
--
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 0/9] socket filtering using nf_tables

[Pablo Neira Ayuso]

On Fri, Mar 14, 2014 at 09:04:50PM -0700, Alexei Starovoitov wrote:
[...]
> In the patches I sent, ebpf is _not_ exposed to the user.

>From your last patch: http://patchwork.ozlabs.org/patch/329713/

diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
index 8eb9ccaa5b48..4e98fe16ba88 100644
--- a/include/uapi/linux/filter.h
+++ b/include/uapi/linux/filter.h
@@ -1,5 +1,6 @@ 
 /*
  * Linux Socket Filter Data Structures
+ * Extended BPF is Copyright (c) 2011-2014, PLUMgrid, http://plumgrid.com
  */
 
 #ifndef _UAPI__LINUX_FILTER_H__
@@ -19,7 +20,7 @@ 
  * Try and keep these values and structures similar to BSD,
  * especially
  * the BPF code definitions which need to match so you can share
  * filters
  */
- 
+
 struct sock_filter {   /* Filter block */
__u16   code;   /* Actual filter code */
__u8jt; /* Jump true */
@@ -27,6 +28,14 @@  struct sock_filter {/* Filter block */
__u32   k;  /* Generic multiuse field */
 };
 
+struct sock_filter_ext {
+   __u8code;/* opcode */
+   __u8a_reg:4; /* dest register */
+   __u8x_reg:4; /* source register */
+   __s16   off; /* signed offset */
+   __s32   imm; /* signed immediate constant */
+};
+
 struct sock_fprog {/* Required for SO_ATTACH_FILTER. */
unsigned short  len;/* Number of filter blocks */
struct sock_filter __user *filter;

That sock_filter_ext structure is exposed to userspace as well as many
other new BPF_* macros that you have defined.
--
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] exit.c: call proc_exit_connector() after exit_state is set

[Oleg Nesterov]

On 03/15, Linus Torvalds wrote:
>
> [ Going through old emails, adding relevant people, ie Oleg for
> kernel/exit.c and David because he seems to be the go-to person for
> connector issues judging by commits ]
>
> Patch looks sane to me, and logically that exit_connector thing would
> pair with exit_notify(), but I'd like some comments on it.

Please see the (confusing, my fault) discussion

http://marc.info/?t=13932788663

But in short, personally I agree with this change too. Just it was not
clear from the changelog (to me ;) which problem this change actually
tries to solve, because in general the task is not waitable after it
reports PROC_EVENT_EXIT.

So I think the patch is fine, but let me repeat:

I hope that someone
can confirm that netlink_broadcast() is safe even if 
release_task(current)
was already called, so that the caller has no pids, sighand, is not 
visible
via /proc/, etc.

not that I expect this should not work, but still.

> That
> usability issue/race has been there since forever afaik. We probably
> should never have added that process events connector thing, but since
> we did and people apparently use it..

Yes... BTW, Guillaume, I forgot to mention that perhaps you can use
signalfd(SIGCHLD) instead of connector, this is epoll-able too. SIGCHLD
doesn't queue, so it can't tell you which child has exited, but WNOHANG
should work.

Oleg.

--
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 0/9] socket filtering using nf_tables

[Alexei Starovoitov]

On Sat, Mar 15, 2014 at 12:03 PM, Pablo Neira Ayuso  wrote:
> On Fri, Mar 14, 2014 at 09:04:50PM -0700, Alexei Starovoitov wrote:
> [...]
>> In the patches I sent, ebpf is _not_ exposed to the user.
>
> From your last patch: http://patchwork.ozlabs.org/patch/329713/
>
> diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
> index 8eb9ccaa5b48..4e98fe16ba88 100644
> --- a/include/uapi/linux/filter.h
> +++ b/include/uapi/linux/filter.h
> @@ -1,5 +1,6 @@
>  /*
>   * Linux Socket Filter Data Structures
> + * Extended BPF is Copyright (c) 2011-2014, PLUMgrid, http://plumgrid.com
>   */
>
>  #ifndef _UAPI__LINUX_FILTER_H__
> @@ -19,7 +20,7 @@
>   * Try and keep these values and structures similar to BSD,
>   * especially
>   * the BPF code definitions which need to match so you can share
>   * filters
>   */
> -
> +
>  struct sock_filter {   /* Filter block */
> __u16   code;   /* Actual filter code */
> __u8jt; /* Jump true */
> @@ -27,6 +28,14 @@  struct sock_filter {/* Filter block */
> __u32   k;  /* Generic multiuse field */
>  };
>
> +struct sock_filter_ext {
> +   __u8code;/* opcode */
> +   __u8a_reg:4; /* dest register */
> +   __u8x_reg:4; /* source register */
> +   __s16   off; /* signed offset */
> +   __s32   imm; /* signed immediate constant */
> +};
> +
>  struct sock_fprog {/* Required for SO_ATTACH_FILTER. */
> unsigned short  len;/* Number of filter blocks */
> struct sock_filter __user *filter;
>
> That sock_filter_ext structure is exposed to userspace as well as many
> other new BPF_* macros that you have defined.

For the first few versions of the patchset they were in linux/bpf.h,
but then it was suggested to put them into uapi/linux/filter.h
to make the whole thing consistent with existing sock_filter structure.
So yes, uapi header is changed as:
 include/uapi/linux/filter.h |   33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

but there is no way to use these #define from user space at present.

As I said I think it's safe to expose it, because these defines won't change,
but if there is a concern I can move it back into linux/bpf.h

Thanks
Alexei
--
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] exit.c: call proc_exit_connector() after exit_state is set

[Linus Torvalds]

On Sat, Mar 15, 2014 at 12:12 PM, Oleg Nesterov  wrote:
>
> So I think the patch is fine, but let me repeat:
>
> I hope that someone
> can confirm that netlink_broadcast() is safe even if 
> release_task(current)
> was already called, so that the caller has no pids, sighand, is not 
> visible
> via /proc/, etc.
>
> not that I expect this should not work, but still.

Ok. I think people use netlink_broadcast from irq context (well,
strictly speaking looks lik ebottom half) judging by the GFP_ATOMIC
users, so that had better work regardless.

> Yes... BTW, Guillaume, I forgot to mention that perhaps you can use
> signalfd(SIGCHLD) instead of connector, this is epoll-able too. SIGCHLD
> doesn't queue, so it can't tell you which child has exited, but WNOHANG
> should work.

Yeah, that sounds like a good approach if SIGCHLD is the only thing needed.

Anyway, I see that the patch is apparently in -mm, and I think your
netlink_broadcast issue should be fine, so things are moving along.
It's not like this is a new issue or even so much an outright "bug" as
a misfeature.

 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] powerpc/mm: Make sure a local_irq_disable prevent a parallel THP split

[Rik van Riel]

On 03/15/2014 06:47 AM, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" 
> 
> We have generic code like the one in get_futex_key that assume that
> a local_irq_disable prevents a parallel THP split. Support that by
> adding a dummy smp call function after setting _PAGE_SPLITTING. Code
> paths like get_user_pages_fast still need to check for _PAGE_SPLITTING
> after disabling IRQ which indicate that a parallel THP splitting is
> ongoing. Now if they don't find _PAGE_SPLITTING set, then we can be
> sure that parallel split will now block in pmdp_splitting flush
> until we enables IRQ
> 
> Signed-off-by: Aneesh Kumar K.V 

Acked-by: Rik van Riel 

-- 
All rights reversed
--
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] watchdog: bcm281xx: Fix Kconfig dependency

[Wim Van Sebroeck]

Hi Markus,

> Use more the applicable ARCH_BCM_MOBILE option instead of ARCH_BCM as
> dependency for bcm_kona_wdt.c.
> 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 79d2589..47a6f10 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1160,7 +1160,7 @@ config BCM2835_WDT
>  
>  config BCM_KONA_WDT
>   tristate "BCM Kona Watchdog"
> - depends on ARCH_BCM
> + depends on ARCH_BCM_MOBILE
>   select WATCHDOG_CORE
>   help
> Support for the watchdog timer on the following Broadcom BCM281xx

Patch has been added to linux-watchdog-next.

Kind regards,
Wim.

--
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] it87_wdt: Work around non-working CIR interrupts

[Wim Van Sebroeck]

Hi Marc,

> From: Marc van der Wal 
> 
> On some hardware platforms, the it87_wdt watchdog resets the machine
> despite the watchdog daemon running and writing to /dev/watchdog.
> 
> This is due to Consumer IR buffer underrun interrupts being used as
> triggers to reset the timer.  On some buggy hardware implementations
> such as the iEi AFL-12A-N270 single-board computer, this method does 
> not work.
> 
> However, resetting the timer by writing its original timeout value in
> its configuration register over and over again suppresses the unwanted
> reboots.
> 
> Add a module option (nocir), 0 by default in order not to break existing
> setups.  Setting it to 1 enables the workaround.
> 
> Fixes bug #42801 .
> Tested primarily on Linux 3.5.7, applies cleanly on Linux 3.13.5.
> 
> Signed-off-by: Marc van der Wal 
> ---

Patch has been added to linux-watchdog-next.

Kind regards,
Wim.

--
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: [RFC v3 3/3] of: Make of_find_node_by_path() handle /aliases

[Rob Herring]

On Sat, Mar 15, 2014 at 7:33 AM, Grant Likely  wrote:
> On Fri, 14 Mar 2014 16:39:38 -0500, Rob Herring  wrote:
>> On Fri, Mar 14, 2014 at 12:11 PM, Grant Likely  
>> wrote:
>> > Make of_find_node_by_path() handle aliases as prefixes. To make this
>> > work the name search is refactored to search by path component instead
>> > of by full string. This should be a more efficient search, and it makes
>> > it possible to start a search at a subnode of a tree.
>> >
>> > Signed-off-by: David Daney 
>> > Signed-off-by: Pantelis Antoniou 
>> > [grant.likely: Rework to not require allocating at runtime]
>> > Signed-off-by: Grant Likely 
>>
>> I should have read the comments before trying to figure out why you
>> had that "pointless" recursion...
>
> Hi Rob,
>
> Thanks for the review. However, I'm a little slow this morning and I
> don't understand what you mean. Did I miss an early comment?

No, it's me that was being slow. At first glance I was thinking the
recursion was pointless until I saw the alias + path case.

Rob
--
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 v10 net-next 1/3] filter: add Extended BPF interpreter and converter

[Daniel Borkmann]

On 03/14/2014 09:08 PM, David Miller wrote:

From: Alexei Starovoitov 
Date: Fri, 14 Mar 2014 12:51:17 -0700


can you please explain why the status of these
patches is 'deferred' in patchwork ?
Is it because of bpf vs nft thread?
I think that's orthogonal.


I do not find it orthogonal, Pablo brings up some very valid points
which I agree with.

EBPF has a lot of the same user side interface limitations that the
existing BPF has, and you refuse to accept this core point Pablo is
making.

That is, that it lacks extensibility, and is too strongly tied to the
implementation.

This is exactly how we run into problems in the future, and you'll be
proposing EBPF_2.0 to address such problems.


Hm, so currently there's no interface where this is exposed to uapi,
and we surely can and should put the definitions back to the non-uapi
include to keep it inside the kernel, you're right.

I think, at least for me, the take-away of Alexei's work is, that
even (if we assume) without any further functionality, the new design
would greatly improve the interpreter (and presumably later on as
well JIT) performance based on Alexei's benchmarks, which would already
be a win for seccomp and socket filters and where ever they are being
used across the networking subsystem, and therefore out-of-the-box
without any changes for user space applications such as libpcap.

I was thinking that it could be an option to make this transparently
available to everyone, by just dropping the bpf_ext_enable knob, and
perhaps just replace the old BPF interpreter entirely in this set?
So the process would be: 1) test if normal BPF filter can be JIT'ed,
go for it, if it's not supported by JIT (or if it is disabled), run
it transparently in the new (non-exposed) BPF representation to have
a better overall performance.

Would that perhaps address the above concern? So on the big picture,
it provides a BPF performance improvement. I think if there's a wish
to extend the socket filtering api to run alternative interpreters,
such as nft, then that could still happen, of course.
--
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/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

[Igor Mammedov]

MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS
instruction emulation, this series adds it and while at it,
it adds emulation of MOVAPD which is trivial to implement on
top of MOVAPS.

Igor Mammedov (2):
  KVM: x86 emulator: emulate MOVAPS
  KVM: x86 emulator: emulate MOVAPD

 arch/x86/kvm/emulate.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
1.8.5.3

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

[PATCH 2/2] KVM: x86 emulator: emulate MOVAPD

[Igor Mammedov]

Add emulation for 0x66 prefixed instruction of 0f 28 opcode
that has been added earlier.

Signed-off-by: Igor Mammedov 
---
 arch/x86/kvm/emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index a26d075..205b17e 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3669,7 +3669,7 @@ static const struct gprefix pfx_vmovntpx = {
 };
 
 static const struct gprefix pfx_0f_28_0f_29 = {
-   I(Aligned, em_mov), N, N, N,
+   I(Aligned, em_mov), I(Aligned, em_mov), N, N,
 };
 
 static const struct escape escape_d9 = { {
-- 
1.8.5.3

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

Re: [PATCH 5/8] watchdog: iTCO_wdt: Add support for v3 silicon

[Wim Van Sebroeck]

Hi Peter,

> Some new Atom's, eg Avoton and Bay Trail, have slightly different iTCO
> functionality:
> - The watchdog timer ticks at 1 second instead of .6 seconds
> 
> - Some 8 and 16-bit registers were combined into 32-bit registers
> 
> - Some registers were removed (DAT_IN, DAT_OUT, MESSAGE)
> 
> - The BOOT_STS field in TCO_STS was removed
> 
> - The NO_REBOOT bit is in the PMC area instead of GCS
> 
> Update the driver to support the above changes and bump the version to
> 1.11.
> 
> Signed-off-by: Peter Tyser 
> Tested-by: Rajat Jain 
> Cc: Guenter Roeck 
> Cc: James Ralston 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: Wim Van Sebroeck 
> Cc: linux-watch...@vger.kernel.org

Signed-off-by: Wim Van Sebroeck 

Kind regards,
Wim.

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

[PATCH 1/2] KVM: x86 emulator: emulate MOVAPS

[Igor Mammedov]

HCK memory driver test fails when testing 32-bit Windows 8.1
with baloon driver.

tracing KVM shows error:
reason EXIT_ERR rip 0x81c18326 info 0 0

x/10i 0x81c18326-20
0x81c18312:  add%al,(%eax)
0x81c18314:  add%cl,-0x7127711d(%esi)
0x81c1831a:  rolb   $0x0,0x80ec(%ecx)
0x81c18321:  and$0xfff0,%esp
0x81c18324:  mov%esp,%esi
0x81c18326:  movaps %xmm0,(%esi)
0x81c18329:  movaps %xmm1,0x10(%esi)
0x81c1832d:  movaps %xmm2,0x20(%esi)
0x81c18331:  movaps %xmm3,0x30(%esi)
0x81c18335:  movaps %xmm4,0x40(%esi)

which points to MOVAPS instruction currently no emulated by KVM.
Fix it by adding appropriate entries to opcode table in KVM's emulator.

Signed-off-by: Igor Mammedov 
---
 arch/x86/kvm/emulate.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 07ffca0..a26d075 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3668,6 +3668,10 @@ static const struct gprefix pfx_vmovntpx = {
I(0, em_mov), N, N, N,
 };
 
+static const struct gprefix pfx_0f_28_0f_29 = {
+   I(Aligned, em_mov), N, N, N,
+};
+
 static const struct escape escape_d9 = { {
N, N, N, N, N, N, N, I(DstMem, em_fnstcw),
 }, {
@@ -3870,7 +3874,9 @@ static const struct opcode twobyte_table[256] = {
IIP(ModRM | SrcMem | Priv | Op3264, em_cr_write, cr_write, 
check_cr_write),
IIP(ModRM | SrcMem | Priv | Op3264, em_dr_write, dr_write, 
check_dr_write),
N, N, N, N,
-   N, N, N, GP(ModRM | DstMem | SrcReg | Sse | Mov | Aligned, 
&pfx_vmovntpx),
+   GP(ModRM | DstReg | SrcMem | Mov | Sse, &pfx_0f_28_0f_29),
+   GP(ModRM | DstMem | SrcReg | Mov | Sse, &pfx_0f_28_0f_29),
+   N, GP(ModRM | DstMem | SrcReg | Sse | Mov | Aligned, &pfx_vmovntpx),
N, N, N, N,
/* 0x30 - 0x3F */
II(ImplicitOps | Priv, em_wrmsr, wrmsr),
-- 
1.8.5.3

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