Re: [alsa-devel] [PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.

[Lars-Peter Clausen]

On 03/10/2014 04:51 AM, li.xi...@freescale.com wrote:

Subject: Re: [PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.

On Mon, Mar 03, 2014 at 07:24:36AM +, li.xi...@freescale.com wrote:


/* Default to using ALC auto offset calibration mode. */
snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
DA7213_ALC_CALIB_MODE_MAN, 0);



This one will fail.



Sorry, I'm not very understand why will this fail ? Before the ASoC probe,
the ASoC core will set the I/O.
:)


OK, that's now been refactored.


@Mark, @Lars,

Has there any other problems about this patch series? And this I had tested on
our Vybrid-Twr board based on SGTL5000 codec and SAI drivers. If not, I can
continue with my second patches series about " Remove set_cache_io entirely from
ASoC probe".

Thanks very much.




It looks good to me.

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

Re: [PATCH] i2c-davinci: Implement a bus recovery that actually works

[Mike Looijmans]

On 03/09/2014 09:28 PM, Wolfram Sang wrote:

On Fri, Feb 28, 2014 at 11:32:05AM +0100, mike.looijm...@topic.nl wrote:

From: Mike Looijmans 

Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards, because on regular boards, this will only toggle GPIO
lines that aren't muxed to the actual pins.

The I2C controller has the built-in capability to bit-bang its lines.
Use this to implement a generic recovery routine that puts the
controller in GPIO mode and pulse the clk lines until both SDA and
SCL return to a high state.

Because the controller must be held in reset while doing so, the
recovery routine must re-init the controller. Since this was already
being done after each call to i2c_recover_bus, move that call into
the recovery routine as well.

Tested on a custom board with OMAP-L138, and after this change, the
board can recover from chips keeping SDA low.

Note: This is an adapted port from 2.6.37 code, and was only tested
with that kernel.


What about using struct i2c_bus_recovery_info, so the actual recovery
logic is taken from the core?


I never knew such a thing existed, but it sounds like a sensible thing to do.

In addition, one could also remove the "sda_pin" and "scl_pin" members from 
the platform data struct, as they no longer serve any purpose after this patch.


I won't be doing those changes though. My sponsor's budget is limited, so I'm 
just having to do the minimum I can get away with. Maybe someone from TI can 
take it further?


Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

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

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

[Tomi Valkeinen]

On 08/03/14 14:25, Grant Likely wrote:

> Sure. If endpoints are logical, then only create the ones actually
> hooked up. No problem there. But nor do I see any issue with having
> empty connections if the board author things it makes sense to have them
> in the dtsi.

I don't think they are usually logical, although they probably might be
in some cases.

As I see it, a "port" is a group of pins in a hardware component, and
two endpoints define a connection between two ports, which on the HW
level are the wires between the ports.

So a port with two endpoints is a group of pins, with wires that go from
the same pins to two different components.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

[Tomi Valkeinen]

On 08/03/14 14:23, Grant Likely wrote:

>>> That's fine. In that case the driver would specifically require the
>>> endpoint to be that one node although the above looks a little weird
>>
>> The driver can't require that. It's up to the board designer to decide
>> how many endpoints are used. A driver may say that it has a single input
>> port. But the number of endpoints for that port is up to the use case.
> 
> Come now, when you're writing a driver you know if it will ever be
> possible to have more than one port. If that is the case then the
> binding should be specifically laid out for that. If there will never be
> multiple ports and the binding is unambiguous, then, and only then,
> should the shortcut be used, and only the shortcut should be accepted.

I was talking about endpoints, not ports. There's no unclarity about the
number of ports, that comes directly from the hardware for that specific
component. The number of endpoints, however, come from the board
hardware. The driver writer cannot know that.

>>> to me. I would recommend that if there are other non-port child nodes
>>> then the ports should still be encapsulated by a ports node.  The device
>>> binding should not be ambiguous about which nodes are ports.
>>
>> Hmm, ambiguous in what way?
> 
> Parsing the binding now consists of a ladder of 'ifs' that gives three
> distinct different behaviours for no benefit. You don't want that in

It considerably lessens the amount of text in the DT for many use cases,
making it easier to write and maintain the dts files.

> bindings because it makes it more difficult to get the parsing right in
> the first place, and to make sure that all users parse it in the same
> way (Linux, U-Boot, BSD, etc). Bindings should be as absolutely simple
> as possible.

Well, yes, I agree there. This is not the simplest of bindings. I'd be
more than happy if we would come up with simpler version of this, which
would still allow us to have the same descriptive power.

> Just to be clear, I have no problem with having the option in the
> pattern, but the driver needs to be specific about what layout it
> expects.

If we forget the shortened endpoint format, I think it can be quite
specific.

A device has either one port, in which case it should require the
'ports' node to be omitted, or the device has more than one port, in
which case it should require 'ports' node.

Note that the original v4l2 binding doc says that 'ports' is always
optional.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] mm: warning message for vm_map_ram about vm size

[Zhang Yanfei]

On 03/10/2014 01:47 PM, Minchan Kim wrote:
> Hi Giho,
> 
> On Mon, Mar 10, 2014 at 01:57:07PM +0900, Gioh Kim wrote:
>> Hi,
>>
>> I have a failure of allocation of virtual memory on ARMv7 based platform.
>>
>> I called alloc_page()/vm_map_ram() for allocation/mapping pages.
>> Virtual memory space exhausting problem occurred.
>> I checked virtual memory space and found that there are too many 4MB chunks.
>>
>> I thought that if just one page in the 4MB chunk lives long, 
>> the entire chunk cannot be freed. Therefore new chunk is created again and 
>> again.
>>
>> In my opinion, the vm_map_ram() function should be used for temporary mapping
>> and/or short term memory mapping. Otherwise virtual memory is wasted.
>>
>> I am not sure if my opinion is correct. If it is, please add some warning 
>> message
>> about the vm_map_ram().
>>
>>
>>
>> ---8<---
>>
>> Subject: [PATCH] mm: warning comment for vm_map_ram
>>
>> vm_map_ram can occur locking of virtual memory space
>> because if only one page lives long in one vmap_block,
>> it takes 4MB (1024-times more than one page) space.
> 
> For clarification, vm_map_ram has fragment problem because it
> couldn't purge a chunk(ie, 4M address space) if there is a pinning
> object in that addresss space so it could consume all VMALLOC
> address space easily.
> 
> We can fix the fragementaion problem with using vmap instead of
> vm_map_ram but it wouldn't a good solution because vmap is much
> slower than vm_map_ram for VMAP_MAX_ALLOC below. In my x86 machine,
> vm_map_ram is 5 times faster than vmap.
> 
> AFAICR, some proprietary GPU driver uses that function heavily so
> performance would be really important so I want to stick to use
> vm_map_ram.
> 
> Another option is that caller should separate long-life and short-life
> object and use vmap for long-life but vm_map_ram for short-life.
> But it's not a good solution because it's hard for allocator layer
> to detect it that how customer lives with the object.

Indeed. So at least the note comment should be added.

> 
> So I thought to fix that problem with revert [1] and adding more
> logic to solve fragmentation problem and make bitmap search
> operation more efficient by caching the hole. It might handle
> fragmentation at the moment but it would make more IPI storm for
> TLB flushing as time goes by so that it would mitigate API itself
> so using for only temporal object is too limited but it's best at the
> moment. I am supporting your opinion.
> 
> Let's add some notice message to user.
> 
> [1] [3fcd76e8028, mm/vmalloc.c: remove dead code in vb_alloc]
> 
>>
>> Change-Id: I6f5919848cf03788b5846b7d850d66e4d93ac39a
>> Signed-off-by: Gioh Kim 
>> ---
>>  mm/vmalloc.c |4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 0fdf968..2de1d1b 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1083,6 +1083,10 @@ EXPORT_SYMBOL(vm_unmap_ram);
>>   * @node: prefer to allocate data structures on this node
>>   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
>>   *
>> + * This function should be used for TEMPORARY mapping. If just one page 
>> lives i
>> + * long, it would occupy 4MB vm size permamently. 100 pages (just 400KB) 
>> could
>> + * takes 400MB with bad luck.
>> + *
> 
> If you use this function for below VMAP_MAX_ALLOC pages, it could be 
> faster
> than vmap so it's good but if you mix long-life and short-life object
> with vm_map_ram, it could consume lots of address space by fragmentation(
> expecially, 32bit machine) so you could see failure in the end.
> So, please use this function for short-life object.

Minchan's is better. So I suggest Giho post another patch with this comment
and take what Minchan said above to the commit log. And you can feel free to
add:

Reviewed-by: Zhang Yanfei 

Thanks.

> 
>>   * Returns: a pointer to the address that has been mapped, or %NULL on 
>> failure
>>   */
>>  void *vm_map_ram(struct page **pages, unsigned int count, int node, 
>> pgprot_t prot)
>> --
>> 1.7.9.5
>>
>> Gioh Kim / 김 기 오
>> Research Engineer
>> Advanced OS Technology Team
>> Software Platform R&D Lab.
>> Mobile: 82-10-7322-5548  
>> E-mail: gioh@lge.com 
>> 19, Yangjae-daero 11gil
>> Seocho-gu, Seoul 137-130, Korea
>>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
> 


-- 
Thanks.
Zhang Yanfei
--
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] RFC: WIP: sc16is7xx [v0.4]

[jon]

From: Jon Ringle 

I started over and rewrote this driver patternized on sccnxp.c

However, I am still experiencing major latency problems with this driver at
19200 speeds.

The method that I'm testing is simply transferring a small file just over
4k in size.

On the target platform I do:
$ socat /dev/ttySC0,raw,echo=0,b19200 - > rx-file

On my development machine, I do:
$ socat /dev/ttyUSB1,echo=0,raw,time=1,min=255,b19200 FILE:./tx-file

When the socat running on the development machine returns to the prompt,
it has transmitted all the bytes in tx-file. I then kill the socat running
on the target platform. Success is defined as rx-file being identical to
tx-file. However, I find that even at only 19200, this driver fails to
receive all bytes sent.

I welcome any and all comments.

Thank you,
Jon

Signed-off-by: Jon Ringle 
---
 drivers/tty/serial/Kconfig   |   7 +
 drivers/tty/serial/Makefile  |   1 +
 drivers/tty/serial/sc16is7xx.c   | 730 +++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 741 insertions(+)
 create mode 100644 drivers/tty/serial/sc16is7xx.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index febd45c..1dfaeec 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1179,6 +1179,13 @@ config SERIAL_SCCNXP_CONSOLE
help
  Support for console on SCCNXP serial ports.
 
+config SERIAL_SC16IS7XX
+   tristate "SC16IS7xx RS485 serial support"
+ select SERIAL_CORE
+ default n
+ help
+ This selects support for SC16IS7xx for use as a RS485 serial port
+
 config SERIAL_BFIN_SPORT
tristate "Blackfin SPORT emulate UART"
depends on BLACKFIN
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 3068c77..c3bac45 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_SERIAL_SB1250_DUART) += sb1250-duart.o
 obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o
 obj-$(CONFIG_SERIAL_SC26XX) += sc26xx.o
 obj-$(CONFIG_SERIAL_SCCNXP) += sccnxp.o
+obj-$(CONFIG_SERIAL_SC16IS7XX) += sc16is7xx.o
 obj-$(CONFIG_SERIAL_JSM) += jsm/
 obj-$(CONFIG_SERIAL_TXX9) += serial_txx9.o
 obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
new file mode 100644
index 000..26268fa7
--- /dev/null
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -0,0 +1,730 @@
+/*
+ * SC16IS740/750/760 tty serial driver - Copyright (C) 2014 GridPoint
+ *
+ *  Based on sccnxp.c, by Alexander Shiyan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * The SC16IS740/750/760 is a slave I2C-bus/SPI interface to a single-channel
+ * high performance UART. The SC16IS740/750/760’s internal register set is
+ * backward-compatible with the widely used and widely popular 16C450.
+ *
+ * The SC16IS740/750/760 also provides additional advanced features such as
+ * auto hardware and software flow control, automatic RS-485 support, and
+ * software reset.
+ *
+ * Notes:
+ *
+ * The sc16is740 driver is used for the GPEC RS485 Half duplex communication.
+ *
+ * In the EC1K board the sc16is740 RTS line is connected to a SN65HVD1780DR
+ * chip which is used to signal the RS485 direction.
+ * When RTS is low, the RS485 direction is set to output from the CPU.
+ *
+ * To set the RS485 direction we use the sc16is740 internal RS485 feature
+ * where the chip drives the RTS line when the data is written to the TX FIFO
+ * (see the spec note for the EFCR[4] bit configuration).
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "sc16is7xx"
+#define DRV_VERSION"0.4"
+#define SC16IS7XX_MAJOR204
+#define SC16IS7XX_MINOR8
+
+#define SC16IS7XX_HAVE_IO  0x0001
+
+/* General registers set */
+#define SC16IS7XX_TCR  0x06
+#define SC16IS7XX_TLR  0x07
+#define SC16IS7XX_TXLVL0x08
+#define SC16IS7XX_RXLVL0x09
+#define SC16IS7XX_EFCR 0x0F
+
+struct sc16is7xx_chip {
+   const char  *name;
+   unsigned intnr;
+   unsigned intflags;
+   unsigned intfifosize;
+};
+
+struct sc16is7xx_port {
+   struct uart_driver  uart;
+   struct uart_portport[SC16IS7XX_MAX_UARTS];
+   boolopened[SC16IS7XX_MAX_UARTS];
+
+   struct i2c_client   *client;
+
+   int irq;
+   u8  ier;
+
+   struct sc16is7xx_chip   *chip;
+
+   spinlock_t  lock;

[PATCH net-next] r8152: add skb_cow_head

[Hayes Wang]

Call skb_cow_head() before editing the tx packet header. The header
would be reallocated if it is shared.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c7ef30d..faad39b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1376,6 +1376,11 @@ static int msdn_giant_send_check(struct sk_buff *skb)
 {
const struct ipv6hdr *ipv6h;
struct tcphdr *th;
+   int ret;
+
+   ret = skb_cow_head(skb, 0);
+   if (ret)
+   goto out1;
 
ipv6h = ipv6_hdr(skb);
th = tcp_hdr(skb);
@@ -1383,7 +1388,8 @@ static int msdn_giant_send_check(struct sk_buff *skb)
th->check = 0;
th->check = ~tcp_v6_check(0, &ipv6h->saddr, &ipv6h->daddr, 0);
 
-   return 0;
+out1:
+   return ret;
 }
 
 static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
@@ -1412,8 +1418,11 @@ static int r8152_tx_csum(struct r8152 *tp, struct 
tx_desc *desc,
break;
 
case htons(ETH_P_IPV6):
+   if (msdn_giant_send_check(skb)) {
+   ret = TX_CSUM_TSO;
+   goto unavailable;
+   }
opts1 |= GTSENDV6;
-   msdn_giant_send_check(skb);
break;
 
default:
-- 
1.8.4.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: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary slightly

[Chao Yu]

Hi,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, March 10, 2014 1:38 PM
> To: Chao Yu
> Cc: 'Gu Zheng'; 'linux-kernel'; 'f2fs'
> Subject: RE: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary 
> slightly
> 
> Hi,
> 
> 2014-03-10 (월), 13:13 +0800, Chao Yu:
> > Hi Gu, Kim:
> >
> > One more comment.
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> > > Sent: Monday, March 10, 2014 12:46 PM
> > > To: Gu Zheng
> > > Cc: linux-kernel; f2fs
> > > Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary 
> > > slightly
> > >
> > > Hi Gu,
> > >
> > > 2014-03-07 (금), 18:43 +0800, Gu Zheng:
> > > > Previously, we ra_sum_pages to pre-read contiguous pages as more
> > > > as possible, and if we fail to alloc more pages, an ENOMEM error
> > > > will be reported upstream, even though we have alloced some pages
> > > > yet. In fact, we can use the available pages to do the job partly,
> > > > and continue the rest in the following circle. Only reporting ENOMEM
> > > > upstream if we really can not alloc any available page.
> > > >
> > > > And another fix is ignoring dealing with the following pages if an
> > > > EIO occurs when reading page from page_list.
> > > >
> > > > Signed-off-by: Gu Zheng 
> >
> > Reviewed-by: Chao Yu 
> >
> > > > ---
> > > >  fs/f2fs/node.c|   44 
> > > >  fs/f2fs/segment.c |7 +--
> > > >  2 files changed, 25 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > > > index 8787469..4b7861d 100644
> > > > --- a/fs/f2fs/node.c
> > > > +++ b/fs/f2fs/node.c
> > > > @@ -1588,15 +1588,8 @@ static int ra_sum_pages(struct f2fs_sb_info 
> > > > *sbi, struct list_head
> > > *pages,
> > > > for (; page_idx < start + nrpages; page_idx++) {
> > > > /* alloc temporal page for read node summary info*/
> > > > page = alloc_page(GFP_F2FS_ZERO);
> > > > -   if (!page) {
> > > > -   struct page *tmp;
> > > > -   list_for_each_entry_safe(page, tmp, pages, lru) 
> > > > {
> > > > -   list_del(&page->lru);
> > > > -   unlock_page(page);
> > > > -   __free_pages(page, 0);
> > > > -   }
> > > > -   return -ENOMEM;
> > > > -   }
> > > > +   if (!page)
> > > > +   break;
> > > >
> > > > lock_page(page);
> > > > page->index = page_idx;
> > > > @@ -1607,7 +1600,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> > > > struct list_head
> > > *pages,
> > > > f2fs_submit_page_mbio(sbi, page, page->index, &fio);
> > > >
> > > > f2fs_submit_merged_bio(sbi, META, READ);
> > > > -   return 0;
> > > > +
> > > > +   return page_idx - start;
> > > >  }
> > > >
> > > >  int restore_node_summary(struct f2fs_sb_info *sbi,
> > > > @@ -1630,28 +1624,30 @@ int restore_node_summary(struct f2fs_sb_info 
> > > > *sbi,
> > > > nrpages = min(last_offset - i, bio_blocks);
> > > >
> > > > /* read ahead node pages */
> > > > -   err = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > > > -   if (err)
> > > > -   return err;
> > > > +   nrpages = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > > > +   if (!nrpages)
> > > > +   return -ENOMEM;
> > > >
> > > > list_for_each_entry_safe(page, tmp, &page_list, lru) {
> > > > -
> > >
> > > Here we can just add:
> > >   if (err)
> > >   goto skip;
> > >   lock_page();
> > >   ...
> > >   unlock_page();
> > >   skip:
> > >   list_del();
> > >   __free_pages();
> > >
> > > IMO, it's more neat, so if you have any objection, let me know.
> > > Otherwise, I'll handle this by myself. :)
> > > Thanks,
> > >
> > > > -   lock_page(page);
> > > > -   if (unlikely(!PageUptodate(page))) {
> > > > -   err = -EIO;
> > > > -   } else {
> > > > -   rn = F2FS_NODE(page);
> > > > -   sum_entry->nid = rn->footer.nid;
> > > > -   sum_entry->version = 0;
> > > > -   sum_entry->ofs_in_node = 0;
> > > > -   sum_entry++;
> > > > +   if (!err) {
> >
> > If we skip here, next round we will fill these summary page entries with
> > wrong info because we skip the code 'sum_entry++;'.
> 
> There is no next round. Once err = -EIO, there's no route to make err =
> 0.

Ah, you're right. Only ol

[PATCH v8 net-next 3/3] doc: filter: add Extended BPF documentation

[Alexei Starovoitov]

Signed-off-by: Alexei Starovoitov 
Reviewed-by: Daniel Borkmann 
---
 Documentation/networking/filter.txt |  181 +++
 1 file changed, 181 insertions(+)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index a06b48d2f5cc..6a0e29583a30 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -546,6 +546,186 @@ a0069c8f + :
 For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful
 toolchain for developing and testing the kernel's JIT compiler.
 
+Extended BPF
+
+Extended BPF extends BPF in the following ways:
+- from 2 to 10 registers
+  Original BPF has two registers (A and X) and hidden frame pointer.
+  Extended BPF has ten registers and read-only frame pointer.
+- from 32-bit registers to 64-bit registers
+  semantics of old 32-bit ALU operations are preserved via 32-bit
+  subregisters
+- if (cond) jump_true; else jump_false;
+  old BPF insns are replaced with:
+  if (cond) jump_true; /* else fallthrough */
+- adds signed > and >= insns
+- 16 4-byte stack slots for register spill-fill replaced with
+  up to 512 bytes of multi-use stack space
+- introduces bpf_call insn and register passing convention for zero
+  overhead calls from/to other kernel functions (not part of this patch)
+- adds arithmetic right shift insn
+- adds swab32/swab64 insns
+- adds atomic_add insn
+- old tax/txa insns are replaced with 'mov dst,src' insn
+
+Extended BPF is designed to be JITed with one to one mapping, which
+allows GCC/LLVM compilers to generate optimized BPF code that performs
+almost as fast as natively compiled code
+
+sysctl net.core.bpf_ext_enable=1
+controls whether filters attached to sockets will be automatically
+converted to extended BPF or not.
+
+BPF is safe dynamically loadable program that can call fixed set
+of kernel functions and takes a pointer to data as an input,
+where data is skb, seccomp_data, kprobe function arguments or else.
+
+Extended Instruction Set was designed with these goals:
+- write programs in restricted C and compile into BPF with GCC/LLVM
+- just-in-time map to modern 64-bit CPU with minimal performance overhead
+  over two steps: C -> BPF -> native code
+- guarantee termination and safety of BPF program in kernel
+  with simple algorithm
+
+GCC/LLVM-bpf backend is optional.
+Extended BPF can be coded with macroses from filter.h just like original BPF,
+though the same filter done in C is easier to understand.
+sk_convert_filter() remaps original BPF insns into extended.
+
+Minimal performance overhead is achieved by having one to one mapping
+between BPF insns and native insns, and one to one mapping between BPF
+registers and native registers on 64-bit CPUs
+
+Extended BPF may allow jump forward and backward for two reasons:
+to reduce branch mispredict penalty compiler moves cold basic blocks out of
+fall-through path and to reduce code duplication that would be hard to avoid
+if only jump forward was available.
+To guarantee termination simple non-recursive depth-first-search verifies
+that there are no back-edges (no loops in the program), program is a DAG
+with root at the first insn, all branches end at the last RET insn and
+all instructions are reachable.
+Original BPF actually allows unreachable insns. Though it's safe, it will be
+fixed when extended BPF replaces BPF completely.
+
+Original BPF has two registers (A and X) and hidden frame pointer.
+Extended BPF has ten registers and read-only frame pointer.
+Since 64-bit CPUs are passing arguments to the functions via registers
+the number of args from BPF program to in-kernel function is restricted to 5
+and one register is used to accept return value from in-kernel function.
+x86_64 passes first 6 arguments in registers.
+aarch64/sparcv9/mips64 have 7-8 registers for arguments.
+x86_64 has 6 callee saved registers.
+aarch64/sparcv9/mips64 have 11 or more callee saved registers.
+
+Therefore extended BPF calling convention is defined as:
+R0 - return value from in-kernel function
+R1-R5 - arguments from BPF program to in-kernel function
+R6-R9 - callee saved registers that in-kernel function will preserve
+R10 - read-only frame pointer to access stack
+
+so that all BPF registers map one to one to HW registers on x86_64,aarch64,etc
+and BPF calling convention maps directly to ABIs used by kernel on 64-bit
+architectures.
+On 32-bit architectures JIT may map programs that use only 32-bit arithmetic
+and let more complex programs to be interpreted.
+
+R0-R5 are scratch registers and BPF program needs spill/fill them if necessary
+across calls.
+Note that there is only one BPF program == one BPF function and it cannot call
+other BPF functions. It can only call predefined in-kernel functions.
+
+All BPF registers are 64-bit with 32-bit lower subregister that zero-extends
+into 64-bit if written to. That behavior maps directly to x86_64 and arm64
+subregister defintion, but

[PATCH v8 net-next 2/3] seccomp: convert seccomp to use extended BPF

[Alexei Starovoitov]

use sk_convert_filter() to convert seccomp BPF into extended BPF

05-sim-long_jumps.c of libseccomp was used as micro-benchmark:
  seccomp_rule_add_exact(ctx,...
  seccomp_rule_add_exact(ctx,...
  rc = seccomp_load(ctx);
  for (i = 0; i < 1000; i++)
 syscall(199, 100);

'short filter' has 2 rules
'large filter' has 200 rules

'short filter' performance is slightly better on x86_64,i386,arm32
'large filter' is much faster on x86_64 and i386
and shows no difference on arm32

--x86_64-- short filter
old BPF: 2.7 sec
 39.12%  bench  libc-2.15.so   [.] syscall
  8.10%  bench  [kernel.kallsyms]  [k] sk_run_filter
  6.31%  bench  [kernel.kallsyms]  [k] system_call
  5.59%  bench  [kernel.kallsyms]  [k] trace_hardirqs_on_caller
  4.37%  bench  [kernel.kallsyms]  [k] trace_hardirqs_off_caller
  3.70%  bench  [kernel.kallsyms]  [k] __secure_computing
  3.67%  bench  [kernel.kallsyms]  [k] lock_is_held
  3.03%  bench  [kernel.kallsyms]  [k] seccomp_bpf_load
new BPF: 2.58 sec
 42.05%  bench  libc-2.15.so   [.] syscall
  6.91%  bench  [kernel.kallsyms]  [k] system_call
  6.25%  bench  [kernel.kallsyms]  [k] trace_hardirqs_on_caller
  6.07%  bench  [kernel.kallsyms]  [k] __secure_computing
  5.08%  bench  [kernel.kallsyms]  [k] sk_run_filter_ext

--arm32-- short filter
old BPF: 4.0 sec
 39.92%  bench  [kernel.kallsyms]  [k] vector_swi
 16.60%  bench  [kernel.kallsyms]  [k] sk_run_filter
 14.66%  bench  libc-2.17.so   [.] syscall
  5.42%  bench  [kernel.kallsyms]  [k] seccomp_bpf_load
  5.10%  bench  [kernel.kallsyms]  [k] __secure_computing
new BPF: 3.7 sec
 35.93%  bench  [kernel.kallsyms]  [k] vector_swi
 21.89%  bench  libc-2.17.so   [.] syscall
 13.45%  bench  [kernel.kallsyms]  [k] sk_run_filter_ext
  6.25%  bench  [kernel.kallsyms]  [k] __secure_computing
  3.96%  bench  [kernel.kallsyms]  [k] syscall_trace_exit

--x86_64-- large filter
old BPF: 8.6 seconds
73.38%bench  [kernel.kallsyms]  [k] sk_run_filter
10.70%bench  libc-2.15.so   [.] syscall
 5.09%bench  [kernel.kallsyms]  [k] seccomp_bpf_load
 1.97%bench  [kernel.kallsyms]  [k] system_call
ext BPF: 5.7 seconds
66.20%bench  [kernel.kallsyms]  [k] sk_run_filter_ext
16.75%bench  libc-2.15.so   [.] syscall
 3.31%bench  [kernel.kallsyms]  [k] system_call
 2.88%bench  [kernel.kallsyms]  [k] __secure_computing

--i386-- large filter
old BPF: 5.4 sec
ext BPF: 3.8 sec

--arm32-- large filter
old BPF: 13.5 sec
 73.88%  bench  [kernel.kallsyms]  [k] sk_run_filter
 10.29%  bench  [kernel.kallsyms]  [k] vector_swi
  6.46%  bench  libc-2.17.so   [.] syscall
  2.94%  bench  [kernel.kallsyms]  [k] seccomp_bpf_load
  1.19%  bench  [kernel.kallsyms]  [k] __secure_computing
  0.87%  bench  [kernel.kallsyms]  [k] sys_getuid
new BPF: 13.5 sec
 76.08%  bench  [kernel.kallsyms]  [k] sk_run_filter_ext
 10.98%  bench  [kernel.kallsyms]  [k] vector_swi
  5.87%  bench  libc-2.17.so   [.] syscall
  1.77%  bench  [kernel.kallsyms]  [k] __secure_computing
  0.93%  bench  [kernel.kallsyms]  [k] sys_getuid

BPF filters generated by seccomp are very branchy, so ext BPF
performance is better than old BPF.

Performance gains will be even higher when extended BPF JIT
is committed.

Signed-off-by: Alexei Starovoitov 
Reviewed-by: Kees Cook 
---
 include/linux/seccomp.h |1 -
 kernel/seccomp.c|  118 ++-
 net/core/filter.c   |5 --
 3 files changed, 56 insertions(+), 68 deletions(-)

diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd1840e..4054b0994071 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -76,7 +76,6 @@ static inline int seccomp_mode(struct seccomp *s)
 #ifdef CONFIG_SECCOMP_FILTER
 extern void put_seccomp_filter(struct task_struct *tsk);
 extern void get_seccomp_filter(struct task_struct *tsk);
-extern u32 seccomp_bpf_load(int off);
 #else  /* CONFIG_SECCOMP_FILTER */
 static inline void put_seccomp_filter(struct task_struct *tsk)
 {
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index b7a10048a32c..2a18f43acbd6 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -55,60 +55,31 @@ struct seccomp_filter {
atomic_t usage;
struct seccomp_filter *prev;
unsigned short len;  /* Instruction count */
-   struct sock_filter insns[];
+   struct sock_filter_ext insns[];
 };
 
 /* Limit any path through the tree to 256KB worth of instructions. */
 #define MAX_INSNS_PER_PATH ((1 << 18) / sizeof(struct sock_filter))
 
-/**
- * get_u32 - returns a u32 offset into data
- * @data: a unsigned 64 bit value
- * @index: 0 or 1 to return the first or second 32-bits
- *
- * This inline exists to hide the length of unsigned long.  If a 32-bit
- * unsigned long is passed in, it will be extended and the top 32-bits will be
- * 0. If it is a 64-bit unsigned long, then whatever data is resident will be
- * properly returned.
- *
+/*
  * Endianness is explicitly ignor

[PATCH v8 net-next 0/3] filter: add Extended BPF interpreter and converter, seccomp

[Alexei Starovoitov]

Hi All,

V1 patches:
http://thread.gmane.org/gmane.linux.kernel/1605783
V2 patches:
http://thread.gmane.org/gmane.linux.kernel/1642325
V3 patches:
http://thread.gmane.org/gmane.linux.kernel/1656538

V4 summary:
- addressed Daniel comments
- RFC for seccomp with extended BPF
- added extended BPF design doc

V5 summary:
- fixed commit one-liner, removed empty line
- added Hagen's ack

V6 summary:
- unrolled loop in populate_seccomp_data() to help gcc on arm
- removed empty line at the end of the file
- removed redundant (u32) cast in JSET
- fixed BPF_RVAL instead of BPF_SRC for BPF_RET in sk_convert_filter()
- updated commit log
- added Daniel's Reviewed-by
- added Kees's Reviewed-by

V7 summary:
1/3:
- addressed Dave's feedback regarding typecasting:
  added 'jited' flag to sk_filter and union for bpf_func/bpf_func_ext
- added a comment to sk_run_filter_ext() about ctx<->skb relation
- removed CPU specific code from sk_run_filter() and sk_run_filter_ext()
  because of that revised arm32 cache-hit bpf micro-bench numbers slightly
  slower, but seccomp and cache-miss arm32 numbers stayed the same
2/3 and 3/3: no changes

V8 summary:
1/3:
- fixed sk_get_filter() issue caught by Daniel:
  need to save old filter, so it can be returned via sk_get_filter()
  count memory out of socket optmem budget
- addressed Eric's feedback:
  removed 'notrace'
  replaced integer registers constants and stack size with #define
- retested with my own bpf/ebpf testuite, seccomp and Pavel's
  so_get_filter test from crtools/test/zdtm/live/static/
- trimmed cc list, since it looks too big
2/3 and 3/3: no changes

x86_64, i386 and arm32 look clean.

Thanks!

Alexei Starovoitov (3):
  filter: add Extended BPF interpreter and converter
  seccomp: convert seccomp to use extended BPF
  doc: filter: add Extended BPF documentation

 Documentation/networking/filter.txt |  181 
 arch/arm/net/bpf_jit_32.c   |3 +-
 arch/powerpc/net/bpf_jit_comp.c |3 +-
 arch/s390/net/bpf_jit_comp.c|3 +-
 arch/sparc/net/bpf_jit_comp.c   |3 +-
 arch/x86/net/bpf_jit_comp.c |3 +-
 include/linux/filter.h  |   43 +-
 include/linux/netdevice.h   |1 +
 include/linux/seccomp.h |1 -
 include/net/sock.h  |4 +-
 include/uapi/linux/filter.h |   33 +-
 kernel/seccomp.c|  118 +++--
 net/core/filter.c   |  855 ++-
 net/core/sysctl_net_core.c  |7 +
 14 files changed, 1148 insertions(+), 110 deletions(-)

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

[PATCH v8 net-next 1/3] filter: add Extended BPF interpreter and converter

[Alexei Starovoitov]

Extended BPF extends old BPF in the following ways:
- from 2 to 10 registers
  Original BPF has two registers (A and X) and hidden frame pointer.
  Extended BPF has ten registers and read-only frame pointer.
- from 32-bit registers to 64-bit registers
  semantics of old 32-bit ALU operations are preserved via 32-bit
  subregisters
- if (cond) jump_true; else jump_false;
  old BPF insns are replaced with:
  if (cond) jump_true; /* else fallthrough */
- adds signed > and >= insns
- 16 4-byte stack slots for register spill-fill replaced with
  up to 512 bytes of multi-use stack space
- introduces bpf_call insn and register passing convention for zero
  overhead calls from/to other kernel functions (not part of this patch)
- adds arithmetic right shift insn
- adds swab32/swab64 insns
- adds atomic_add insn
- old tax/txa insns are replaced with 'mov dst,src' insn

Extended BPF is designed to be JITed with one to one mapping, which
allows GCC/LLVM backends to generate optimized BPF code that performs
almost as fast as natively compiled code

sk_convert_filter() remaps old style insns into extended:
'sock_filter' instructions are remapped on the fly to
'sock_filter_ext' extended instructions when
sysctl net.core.bpf_ext_enable=1

Old filter comes through sk_attach_filter() or sk_unattached_filter_create()
 if (bpf_ext_enable) {
convert to new
sk_chk_filter() - check old bpf
use sk_run_filter_ext() - new interpreter
 } else {
sk_chk_filter() - check old bpf
if (bpf_jit_enable)
use old jit
else
use sk_run_filter() - old interpreter
 }

sk_run_filter_ext() interpreter is noticeably faster
than sk_run_filter() for two reasons:

1.fall-through jumps
  Old BPF jump instructions are forced to go either 'true' or 'false'
  branch which causes branch-miss penalty.
  Extended BPF jump instructions have one branch and fall-through,
  which fit CPU branch predictor logic better.
  'perf stat' shows drastic difference for branch-misses.

2.jump-threaded implementation of interpreter vs switch statement
  Instead of single tablejump at the top of 'switch' statement, GCC will
  generate multiple tablejump instructions, which helps CPU branch predictor

Performance of two BPF filters generated by libpcap was measured
on x86_64, i386 and arm32.

fprog #1 is taken from Documentation/networking/filter.txt:
tcpdump -i eth0 port 22 -dd

fprog #2 is taken from 'man tcpdump':
tcpdump -i eth0 'tcp port 22 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
   ((tcp[12]&0xf0)>>2)) != 0)' -dd

Other libpcap programs have similar performance differences.

Raw performance data from BPF micro-benchmark:
SK_RUN_FILTER on same SKB (cache-hit) or 10k SKBs (cache-miss)
time in nsec per call, smaller is better
--x86_64--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF 90   101   192   202
ext BPF 3171   47 97
old BPF jit 1234   17 44
ext BPF jit TBD

--i386--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF107136  227   252
ext BPF 40119   69   172

--arm32--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF202300  475   540
ext BPF180270  330   470
old BPF jit 26182   37   202
new BPF jit TBD

Tested with trinify BPF fuzzer

Future work:

0. add bpf/ebpf testsuite to tools/testing/selftests/net/bpf

1. add extended BPF JIT for x86_64

2. add inband old/new demux and extended BPF verifier, so that new programs
   can be loaded through old sk_attach_filter() and 
sk_unattached_filter_create()
   interfaces

3. tracing filters systemtap-like with extended BPF

4. OVS with extended BPF

5. nftables with extended BPF

Signed-off-by: Alexei Starovoitov 
Acked-by: Hagen Paul Pfeifer 
Reviewed-by: Daniel Borkmann 
---
Daniel,
sk_get_filter() fixes are no longer minor, but I kept your
reviewed-by to credit your great help in creation of these patches.
Hope it's ok with you.

 arch/arm/net/bpf_jit_32.c   |3 +-
 arch/powerpc/net/bpf_jit_comp.c |3 +-
 arch/s390/net/bpf_jit_comp.c|3 +-
 arch/sparc/net/bpf_jit_comp.c   |3 +-
 arch/x86/net/bpf_jit_comp.c |3 +-
 include/linux/filter.h  |   43 +-
 include/linux/netdevice.h   |1 +
 include/net/sock.h  |4 +-
 include/uapi/linux/filter.h |   33 +-
 net/core/filter.c   |  850 ++-
 net/core/sysctl_net_core.c  |7 +
 11 files changed, 911 insertions(+), 42 deletions(-)

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 271b5e971568..e72ff51f4561 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -925,6 +925,7 @@ void bpf_jit_compile(struct sk_filter *fp)
bpf_jit_dump(fp->len, alloc_siz

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

[Tomi Valkeinen]

On 08/03/14 17:54, Laurent Pinchart wrote:

>> Sylwester suggested as an alternative, if I understood correctly, to
>> drop the endpoint node and instead keep the port:
>>
>> device-a {
>> implicit_output_ep: port {
>> remote-endpoint = <&explicit_input_ep>;
>> };
>> };
>>
>> device-b {
>> port {
>> explicit_input_ep: endpoint {
>> remote-endpoint = <&implicit_output_ep>;
>> };
>> };
>> };
>>
>> This would have the advantage to reduce verbosity for devices with multiple
>> ports that are only connected via one endport each, and you'd always have
>> the connected ports in the device tree as 'port' nodes.
> 
> I like that idea. I would prefer making the 'port' nodes mandatory and the 
> 'ports' and 'endpoint' nodes optional. Leaving the 'port' node out slightly 
> decreases readability in my opinion, but making the 'endpoint' node optional 
> increases it. That's just my point of view though.

I, on the other hand, don't like it =). With that format, the
remote-endpoint doesn't point to an EP, but a port. And you'll have
endpoint's properties in a port node, among the port's properties.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] mm: warning message for vm_map_ram about vm size

[Minchan Kim]

Hi Giho,

On Mon, Mar 10, 2014 at 01:57:07PM +0900, Gioh Kim wrote:
> Hi,
> 
> I have a failure of allocation of virtual memory on ARMv7 based platform.
> 
> I called alloc_page()/vm_map_ram() for allocation/mapping pages.
> Virtual memory space exhausting problem occurred.
> I checked virtual memory space and found that there are too many 4MB chunks.
> 
> I thought that if just one page in the 4MB chunk lives long, 
> the entire chunk cannot be freed. Therefore new chunk is created again and 
> again.
> 
> In my opinion, the vm_map_ram() function should be used for temporary mapping
> and/or short term memory mapping. Otherwise virtual memory is wasted.
> 
> I am not sure if my opinion is correct. If it is, please add some warning 
> message
> about the vm_map_ram().
> 
> 
> 
> ---8<---
> 
> Subject: [PATCH] mm: warning comment for vm_map_ram
> 
> vm_map_ram can occur locking of virtual memory space
> because if only one page lives long in one vmap_block,
> it takes 4MB (1024-times more than one page) space.

For clarification, vm_map_ram has fragment problem because it
couldn't purge a chunk(ie, 4M address space) if there is a pinning
object in that addresss space so it could consume all VMALLOC
address space easily.

We can fix the fragementaion problem with using vmap instead of
vm_map_ram but it wouldn't a good solution because vmap is much
slower than vm_map_ram for VMAP_MAX_ALLOC below. In my x86 machine,
vm_map_ram is 5 times faster than vmap.

AFAICR, some proprietary GPU driver uses that function heavily so
performance would be really important so I want to stick to use
vm_map_ram.

Another option is that caller should separate long-life and short-life
object and use vmap for long-life but vm_map_ram for short-life.
But it's not a good solution because it's hard for allocator layer
to detect it that how customer lives with the object.

So I thought to fix that problem with revert [1] and adding more
logic to solve fragmentation problem and make bitmap search
operation more efficient by caching the hole. It might handle
fragmentation at the moment but it would make more IPI storm for
TLB flushing as time goes by so that it would mitigate API itself
so using for only temporal object is too limited but it's best at the
moment. I am supporting your opinion.

Let's add some notice message to user.

[1] [3fcd76e8028, mm/vmalloc.c: remove dead code in vb_alloc]

> 
> Change-Id: I6f5919848cf03788b5846b7d850d66e4d93ac39a
> Signed-off-by: Gioh Kim 
> ---
>  mm/vmalloc.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 0fdf968..2de1d1b 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1083,6 +1083,10 @@ EXPORT_SYMBOL(vm_unmap_ram);
>   * @node: prefer to allocate data structures on this node
>   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
>   *
> + * This function should be used for TEMPORARY mapping. If just one page 
> lives i
> + * long, it would occupy 4MB vm size permamently. 100 pages (just 400KB) 
> could
> + * takes 400MB with bad luck.
> + *

If you use this function for below VMAP_MAX_ALLOC pages, it could be faster
than vmap so it's good but if you mix long-life and short-life object
with vm_map_ram, it could consume lots of address space by fragmentation(
expecially, 32bit machine) so you could see failure in the end.
So, please use this function for short-life object.

>   * Returns: a pointer to the address that has been mapped, or %NULL on 
> failure
>   */
>  void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t 
> prot)
> --
> 1.7.9.5
> 
> Gioh Kim / 김 기 오
> Research Engineer
> Advanced OS Technology Team
> Software Platform R&D Lab.
> Mobile: 82-10-7322-5548  
> E-mail: gioh@lge.com 
> 19, Yangjae-daero 11gil
> Seocho-gu, Seoul 137-130, Korea
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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 4/5] f2fs: optimize restore_node_summary slightly

[Gu Zheng]

Hi Kim,
On 03/10/2014 12:45 PM, Jaegeuk Kim wrote:

> Hi Gu,
> 
> 2014-03-07 (금), 18:43 +0800, Gu Zheng:
>> Previously, we ra_sum_pages to pre-read contiguous pages as more
>> as possible, and if we fail to alloc more pages, an ENOMEM error
>> will be reported upstream, even though we have alloced some pages
>> yet. In fact, we can use the available pages to do the job partly,
>> and continue the rest in the following circle. Only reporting ENOMEM
>> upstream if we really can not alloc any available page.
>>
>> And another fix is ignoring dealing with the following pages if an
>> EIO occurs when reading page from page_list.
>>
>> Signed-off-by: Gu Zheng 
>> ---
>>  fs/f2fs/node.c|   44 
>>  fs/f2fs/segment.c |7 +--
>>  2 files changed, 25 insertions(+), 26 deletions(-)
>>
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 8787469..4b7861d 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1588,15 +1588,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
>> struct list_head *pages,
>>  for (; page_idx < start + nrpages; page_idx++) {
>>  /* alloc temporal page for read node summary info*/
>>  page = alloc_page(GFP_F2FS_ZERO);
>> -if (!page) {
>> -struct page *tmp;
>> -list_for_each_entry_safe(page, tmp, pages, lru) {
>> -list_del(&page->lru);
>> -unlock_page(page);
>> -__free_pages(page, 0);
>> -}
>> -return -ENOMEM;
>> -}
>> +if (!page)
>> +break;
>>  
>>  lock_page(page);
>>  page->index = page_idx;
>> @@ -1607,7 +1600,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
>> struct list_head *pages,
>>  f2fs_submit_page_mbio(sbi, page, page->index, &fio);
>>  
>>  f2fs_submit_merged_bio(sbi, META, READ);
>> -return 0;
>> +
>> +return page_idx - start;
>>  }
>>  
>>  int restore_node_summary(struct f2fs_sb_info *sbi,
>> @@ -1630,28 +1624,30 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
>>  nrpages = min(last_offset - i, bio_blocks);
>>  
>>  /* read ahead node pages */
>> -err = ra_sum_pages(sbi, &page_list, addr, nrpages);
>> -if (err)
>> -return err;
>> +nrpages = ra_sum_pages(sbi, &page_list, addr, nrpages);
>> +if (!nrpages)
>> +return -ENOMEM;
>>  
>>  list_for_each_entry_safe(page, tmp, &page_list, lru) {
>> -
> 
> Here we can just add:
>   if (err)
>   goto skip;
>   lock_page();
>   ...
>   unlock_page();
>   skip:
>   list_del();
>   __free_pages();
> 
> IMO, it's more neat, so if you have any objection, let me know.
> Otherwise, I'll handle this by myself. :)

Thanks very much.

Regards,
Gu

> Thanks,
> 
>> -lock_page(page);
>> -if (unlikely(!PageUptodate(page))) {
>> -err = -EIO;
>> -} else {
>> -rn = F2FS_NODE(page);
>> -sum_entry->nid = rn->footer.nid;
>> -sum_entry->version = 0;
>> -sum_entry->ofs_in_node = 0;
>> -sum_entry++;
>> +if (!err) {
>> +lock_page(page);
>> +if (unlikely(!PageUptodate(page))) {
>> +err = -EIO;
>> +} else {
>> +rn = F2FS_NODE(page);
>> +sum_entry->nid = rn->footer.nid;
>> +sum_entry->version = 0;
>> +sum_entry->ofs_in_node = 0;
>> +sum_entry++;
>> +}
>> +unlock_page(page);
>>  }
>>  
>>  list_del(&page->lru);
>> -unlock_page(page);
>>  __free_pages(page, 0);
>>  }
>>  }
>> +
>>  return err;
>>  }
>>  
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 199c964..b3f8431 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -1160,9 +1160,12 @@ static int read_normal_summaries(struct f2fs_sb_info 
>> *sbi, int type)
>>  ns->ofs_in_node = 0;
>>  }
>>  } else {
>> -if (restore_node_summary(sbi, segno, sum)) {
>> +int err;
>> +
>> +err = restore_node_summary(sbi, segno, sum);
>> +

Re: [PATCH 5/5] f2fs: add a wait queue to avoid unnecessary, build_free_nid

[Gu Zheng]

Hi Kim,
On 03/10/2014 12:50 PM, Jaegeuk Kim wrote:

> Hi Gu,
> 
> 2014-03-07 (금), 18:43 +0800, Gu Zheng:
>> Previously, when we try to alloc free nid while the build free nid
>> is going, the allocer will be run into the flow that waiting for
>> "nm_i->build_lock", see following:
>>  /* We should not use stale free nids created by build_free_nids */
>> >if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>>  f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>>  list_for_each(this, &nm_i->free_nid_list) {
>>  i = list_entry(this, struct free_nid, list);
>>  if (i->state == NID_NEW)
>>  break;
>>  }
>>
>>  f2fs_bug_on(i->state != NID_NEW);
>>  *nid = i->nid;
>>  i->state = NID_ALLOC;
>>  nm_i->fcnt--;
>>  spin_unlock(&nm_i->free_nid_list_lock);
>>  return true;
>>  }
>>  spin_unlock(&nm_i->free_nid_list_lock);
>>
>>  /* Let's scan nat pages and its caches to get free nids */
>> >mutex_lock(&nm_i->build_lock);
>>  build_free_nids(sbi);
>>  mutex_unlock(&nm_i->build_lock);
>> and this will cause another unnecessary building free nid if the current
>> building free nid job is done.
> 
> Could you support any performance number for this?

I just run some common test via fio with simulated ssd(via loop).

> Since, IMO, the contended building processes will be released right away
> because of the following condition check inside build_free_nids().
> 
> if (nm_i->fcnt > NAT_ENTRY_PER_BLOCK)
>   return;

It does. But, IMO, we can not promise nm_i->fcnt > NAT_ENTRY_PER_BLOCK when the
contended building process entering, especially in high concurrency condition.

> 
> So, I don't think this gives us any high latency.
> Can the wakeup_all() become another overhead all the time?

Yeah, maybe we must test whether it can also cause the performance regression,
because the wakeup_all also introduce overhand as you said.
But what is bad is that I do not have a production environment to test it, as 
you
know the simulated environment is not strict.

cc Yu,
Could you please help to test it?

Regards,
Gu

> Thanks,
> 
>> So here we introduce a wait_queue to avoid this issue.
>>
>> Signed-off-by: Gu Zheng 
>> ---
>>  fs/f2fs/f2fs.h |1 +
>>  fs/f2fs/node.c |   10 +-
>>  2 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index f845e92..7ae193e 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -256,6 +256,7 @@ struct f2fs_nm_info {
>>  spinlock_t free_nid_list_lock;  /* protect free nid list */
>>  unsigned int fcnt;  /* the number of free node id */
>>  struct mutex build_lock;/* lock for build free nids */
>> +wait_queue_head_t build_wq; /* wait queue for build free nids */
>>  
>>  /* for checkpoint */
>>  char *nat_bitmap;   /* NAT bitmap pointer */
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 4b7861d..ab44711 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1422,7 +1422,13 @@ retry:
>>  spin_lock(&nm_i->free_nid_list_lock);
>>  
>>  /* We should not use stale free nids created by build_free_nids */
>> -if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>> +if (on_build_free_nids(nm_i)) {
>> +spin_unlock(&nm_i->free_nid_list_lock);
>> +wait_event(nm_i->build_wq, !on_build_free_nids(nm_i));
>> +goto retry;
>> +}
>> +
>> +if (nm_i->fcnt) {
>>  f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>>  list_for_each(this, &nm_i->free_nid_list) {
>>  i = list_entry(this, struct free_nid, list);
>> @@ -1443,6 +1449,7 @@ retry:
>>  mutex_lock(&nm_i->build_lock);
>>  build_free_nids(sbi);
>>  mutex_unlock(&nm_i->build_lock);
>> +wake_up_all(&nm_i->build_wq);
>>  goto retry;
>>  }
>>  
>> @@ -1813,6 +1820,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
>>  INIT_LIST_HEAD(&nm_i->dirty_nat_entries);
>>  
>>  mutex_init(&nm_i->build_lock);
>> +init_waitqueue_head(&nm_i->build_wq);
>>  spin_lock_init(&nm_i->free_nid_list_lock);
>>  rwlock_init(&nm_i->nat_tree_lock);
>>  
> 


--
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: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary slightly

[Jaegeuk Kim]

Hi,

2014-03-10 (월), 13:13 +0800, Chao Yu:
> Hi Gu, Kim:
> 
> One more comment.
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> > Sent: Monday, March 10, 2014 12:46 PM
> > To: Gu Zheng
> > Cc: linux-kernel; f2fs
> > Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary 
> > slightly
> > 
> > Hi Gu,
> > 
> > 2014-03-07 (금), 18:43 +0800, Gu Zheng:
> > > Previously, we ra_sum_pages to pre-read contiguous pages as more
> > > as possible, and if we fail to alloc more pages, an ENOMEM error
> > > will be reported upstream, even though we have alloced some pages
> > > yet. In fact, we can use the available pages to do the job partly,
> > > and continue the rest in the following circle. Only reporting ENOMEM
> > > upstream if we really can not alloc any available page.
> > >
> > > And another fix is ignoring dealing with the following pages if an
> > > EIO occurs when reading page from page_list.
> > >
> > > Signed-off-by: Gu Zheng 
> 
> Reviewed-by: Chao Yu 
> 
> > > ---
> > >  fs/f2fs/node.c|   44 
> > >  fs/f2fs/segment.c |7 +--
> > >  2 files changed, 25 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > > index 8787469..4b7861d 100644
> > > --- a/fs/f2fs/node.c
> > > +++ b/fs/f2fs/node.c
> > > @@ -1588,15 +1588,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> > > struct list_head
> > *pages,
> > >   for (; page_idx < start + nrpages; page_idx++) {
> > >   /* alloc temporal page for read node summary info*/
> > >   page = alloc_page(GFP_F2FS_ZERO);
> > > - if (!page) {
> > > - struct page *tmp;
> > > - list_for_each_entry_safe(page, tmp, pages, lru) {
> > > - list_del(&page->lru);
> > > - unlock_page(page);
> > > - __free_pages(page, 0);
> > > - }
> > > - return -ENOMEM;
> > > - }
> > > + if (!page)
> > > + break;
> > >
> > >   lock_page(page);
> > >   page->index = page_idx;
> > > @@ -1607,7 +1600,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> > > struct list_head
> > *pages,
> > >   f2fs_submit_page_mbio(sbi, page, page->index, &fio);
> > >
> > >   f2fs_submit_merged_bio(sbi, META, READ);
> > > - return 0;
> > > +
> > > + return page_idx - start;
> > >  }
> > >
> > >  int restore_node_summary(struct f2fs_sb_info *sbi,
> > > @@ -1630,28 +1624,30 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > >   nrpages = min(last_offset - i, bio_blocks);
> > >
> > >   /* read ahead node pages */
> > > - err = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > > - if (err)
> > > - return err;
> > > + nrpages = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > > + if (!nrpages)
> > > + return -ENOMEM;
> > >
> > >   list_for_each_entry_safe(page, tmp, &page_list, lru) {
> > > -
> > 
> > Here we can just add:
> > if (err)
> > goto skip;
> > lock_page();
> > ...
> > unlock_page();
> > skip:
> > list_del();
> > __free_pages();
> > 
> > IMO, it's more neat, so if you have any objection, let me know.
> > Otherwise, I'll handle this by myself. :)
> > Thanks,
> > 
> > > - lock_page(page);
> > > - if (unlikely(!PageUptodate(page))) {
> > > - err = -EIO;
> > > - } else {
> > > - rn = F2FS_NODE(page);
> > > - sum_entry->nid = rn->footer.nid;
> > > - sum_entry->version = 0;
> > > - sum_entry->ofs_in_node = 0;
> > > - sum_entry++;
> > > + if (!err) {
> 
> If we skip here, next round we will fill these summary page entries with
> wrong info because we skip the code 'sum_entry++;'.

There is no next round. Once err = -EIO, there's no route to make err =
0.

> 
> > > + lock_page(page);
> > > + if (unlikely(!PageUptodate(page))) {
> > > + err = -EIO;
> > > + } else {
> > > + rn = F2FS_NODE(page);
> > > + sum_entry->nid = rn->footer.nid;
> > > + sum_entry->version = 0;
> > > + sum_entry->ofs_in_node = 0;
> > > + sum_entry++;
> > > + }
> > > + unlock_page(page);
> > >   }
> > >
> > >   list_del(&page->lru);
> > > - unlock_page(page);
> > >  

Re: [PATCH 1/2] cpufreq: Return error if ->get() failed in cpufreq_update_policy()

[Viresh Kumar]

On 26 February 2014 13:15, Viresh Kumar  wrote:
> On 26 February 2014 03:59, Rafael J. Wysocki  wrote:
>> Yes, what exactly do we need it for in the core?
>
> Its probably there to make things faster. We cache the value so that we
> don't go to the hardware to read/calculate that again. Isn't it?
>
> And we need to know current freq on many occasions. One of that is that
> many drivers need to know the relation between current and new freq before
> they can make the change. As they might need to play with volt regulators
> before or after the freq change. Also it is used mainly in our 
> loops_per_jiffiy
> calculations.

Ping!!
--
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: [f2fs-dev] [PATCH 5/5] f2fs: add a wait queue to avoid unnecessary, build_free_nid

[Gu Zheng]

Hi Changman,
On 03/10/2014 12:09 PM, Changman Lee wrote:

> On 금, 2014-03-07 at 18:43 +0800, Gu Zheng wrote:
>> Previously, when we try to alloc free nid while the build free nid
>> is going, the allocer will be run into the flow that waiting for
>> "nm_i->build_lock", see following:
>>  /* We should not use stale free nids created by build_free_nids */
>> >if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>>  f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>>  list_for_each(this, &nm_i->free_nid_list) {
>>  i = list_entry(this, struct free_nid, list);
>>  if (i->state == NID_NEW)
>>  break;
>>  }
>>
>>  f2fs_bug_on(i->state != NID_NEW);
>>  *nid = i->nid;
>>  i->state = NID_ALLOC;
>>  nm_i->fcnt--;
>>  spin_unlock(&nm_i->free_nid_list_lock);
>>  return true;
>>  }
>>  spin_unlock(&nm_i->free_nid_list_lock);
>>
>>  /* Let's scan nat pages and its caches to get free nids */
>> >mutex_lock(&nm_i->build_lock);
>>  build_free_nids(sbi);
>>  mutex_unlock(&nm_i->build_lock);
>> and this will cause another unnecessary building free nid if the current
>> building free nid job is done.
>> So here we introduce a wait_queue to avoid this issue.
>>
>> Signed-off-by: Gu Zheng 
>> ---
>>  fs/f2fs/f2fs.h |1 +
>>  fs/f2fs/node.c |   10 +-
>>  2 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index f845e92..7ae193e 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -256,6 +256,7 @@ struct f2fs_nm_info {
>>  spinlock_t free_nid_list_lock;  /* protect free nid list */
>>  unsigned int fcnt;  /* the number of free node id */
>>  struct mutex build_lock;/* lock for build free nids */
>> +wait_queue_head_t build_wq; /* wait queue for build free nids */
>>  
>>  /* for checkpoint */
>>  char *nat_bitmap;   /* NAT bitmap pointer */
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 4b7861d..ab44711 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1422,7 +1422,13 @@ retry:
>>  spin_lock(&nm_i->free_nid_list_lock);
>>  
>>  /* We should not use stale free nids created by build_free_nids */
>> -if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>> +if (on_build_free_nids(nm_i)) {
>> +spin_unlock(&nm_i->free_nid_list_lock);
>> +wait_event(nm_i->build_wq, !on_build_free_nids(nm_i));
>> +goto retry;
>> +}
>> +
> 
> It would be better moving spin_lock(free_nid_list_lock) here after
> removing above spin_unlock().

Agree. It's better to place spin_lock here to avoid needless lock protection.

Regards,
Gu

> 
>> +if (nm_i->fcnt) {
>>  f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>>  list_for_each(this, &nm_i->free_nid_list) {
>>  i = list_entry(this, struct free_nid, list);
>> @@ -1443,6 +1449,7 @@ retry:
>>  mutex_lock(&nm_i->build_lock);
>>  build_free_nids(sbi);
>>  mutex_unlock(&nm_i->build_lock);
>> +wake_up_all(&nm_i->build_wq);
>>  goto retry;
>>  }
>>  
>> @@ -1813,6 +1820,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
>>  INIT_LIST_HEAD(&nm_i->dirty_nat_entries);
>>  
>>  mutex_init(&nm_i->build_lock);
>> +init_waitqueue_head(&nm_i->build_wq);
>>  spin_lock_init(&nm_i->free_nid_list_lock);
>>  rwlock_init(&nm_i->nat_tree_lock);
>>  
> 
> 
> 


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

[V2 PATCH 0/2] Bug fix in aio ring page migration

[Tang Chen]

This patch-set fixes the following two problems:

1. Need to use ctx->completion_lock to protect ring pages
   from being mis-written while migration.

2. Need memory barrier to ensure memory copy is done before
   ctx->ring_pages[] is updated.

NOTE: AIO ring page migration was implemented since Linux 3.12.
  So we need to merge these two patches into 3.12 stable tree.

Tang Chen (2):
  aio, memory-hotplug: Fix confliction when migrating and accessing
ring pages.
  aio, mem-hotplug: Add memory barrier to aio ring page migration.

 fs/aio.c |   42 ++
 1 files changed, 42 insertions(+), 0 deletions(-)

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

[V2 PATCH 2/2] aio, mem-hotplug: Add memory barrier to aio ring page migration.

[Tang Chen]

When doing aio ring page migration, we migrated the page, and update
ctx->ring_pages[]. Like the following:

aio_migratepage()
 |-> migrate_page_copy(new, old)
 |   .. /* Need barrier here */
 |-> ctx->ring_pages[idx] = new

Actually, we need a memory barrier between these two operations.
Otherwise, if ctx->ring_pages[] is updated before memory copy due to
the compiler optimization, other processes may have an opportunity
to access to the not fully initialized new ring page.

So add a wmb and rmb to synchronize them.

v2:
  change smp_rmb() to smp_read_barrier_depends(). Thanks Miao.

Signed-off-by: Yasuaki Ishimatsu 
Signed-off-by: Tang Chen 
---
 fs/aio.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index dc70246..4133ba9 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -327,6 +327,14 @@ static int aio_migratepage(struct address_space 
*mapping, struct page *new,

pgoff_t idx;
spin_lock_irqsave(&ctx->completion_lock, flags);
migrate_page_copy(new, old);
+
+   /*
+* Ensure memory copy is finished before updating
+* ctx->ring_pages[]. Otherwise other processes may access to
+* new ring pages which are not fully initialized.
+*/
+   smp_wmb();
+
idx = old->index;
if (idx < (pgoff_t)ctx->nr_pages) {
/* And only do the move if things haven't changed */
@@ -1069,6 +1077,12 @@ static long aio_read_events_ring(struct kioctx *ctx,
page = ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE];
pos %= AIO_EVENTS_PER_PAGE;

+   /*
+* Ensure that the page's data was copied from old one by
+* aio_migratepage().
+*/
+   smp_read_barrier_depends();
+
ev = kmap(page);
copy_ret = copy_to_user(event + ret, ev + pos,
sizeof(*ev) * avail);
--
1.7.7


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

[V2 PATCH 1/2] aio, memory-hotplug: Fix confliction when migrating and, accessing ring pages

[Tang Chen]

AIO ring page migration has been implemented by the following patch:


https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/aio.c?id=36bc08cc01709b4a9bb563b35aa530241ddc63e3

In this patch, ctx->completion_lock is used to prevent other processes
from accessing the ring page being migrated.

But in aio_setup_ring(), ioctx_add_table() and aio_read_events_ring(),
when writing to the ring page, they didn't take ctx->completion_lock.

As a result, for example, we have the following problem:

thread 1  |  thread 2
  |
aio_migratepage() |
 |-> take ctx->completion_lock|
 |-> migrate_page_copy(new, old)  |
 |   *NOW*, ctx->ring_pages[idx] == old   |
  |
  |*NOW*, 
ctx->ring_pages[idx] == old

  |aio_read_events_ring()
  | |-> ring = 
kmap_atomic(ctx->ring_pages[0])
  | |-> ring->head = head; 
 *HERE, write to the old ring page*

  | |-> kunmap_atomic(ring);
  |
 |-> ctx->ring_pages[idx] = new   |
 |   *BUT NOW*, the content of|
 |ring_pages[idx] is old. |
 |-> release ctx->completion_lock |

As above, the new ring page will not be updated.

The solution is taking ctx->completion_lock in thread 2, which means,
in aio_setup_ring(), ioctx_add_table() and aio_read_events_ring() when
writing to ring pages.

v2:
  Use spin_lock_irq rather than spin_lock_irqsave as Jeff suggested.

Reported-by: Yasuaki Ishimatsu 
Reviewed-by: Jeff Moyer 
Signed-off-by: Tang Chen 
---
 fs/aio.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 062a5f6..dc70246 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -437,6 +437,14 @@ static int aio_setup_ring(struct kioctx *ctx)
ctx->user_id = ctx->mmap_base;
ctx->nr_events = nr_events; /* trusted copy */

+   /*
+* The aio ring pages are user space pages, so they can be migrated.
+* When writing to an aio ring page, we should ensure the page is not
+* being migrated. Aio page migration procedure is protected by
+* ctx->completion_lock, so we add this lock here.
+*/
+   spin_lock_irq(&ctx->completion_lock);
+
ring = kmap_atomic(ctx->ring_pages[0]);
ring->nr = nr_events;/* user copy */
ring->id = ~0U;
@@ -448,6 +456,8 @@ static int aio_setup_ring(struct kioctx *ctx)
kunmap_atomic(ring);
flush_dcache_page(ctx->ring_pages[0]);

+   spin_unlock_irq(&ctx->completion_lock);
+
return 0;
 }

@@ -556,9 +566,17 @@ static int ioctx_add_table(struct kioctx *ctx, 
struct mm_struct *mm)

rcu_read_unlock();
spin_unlock(&mm->ioctx_lock);

+   /*
+* Accessing ring pages must be done
+* holding ctx->completion_lock to
+* prevent aio ring page migration
+* procedure from migrating ring pages.
+*/
+   spin_lock_irq(&ctx->completion_lock);
ring = kmap_atomic(ctx->ring_pages[0]);
ring->id = ctx->id;
kunmap_atomic(ring);
+   spin_unlock_irq(&ctx->completion_lock);
return 0;
}

@@ -1066,11 +1084,21 @@ static long aio_read_events_ring(struct kioctx *ctx,
head %= ctx->nr_events;
}

+   /*
+* The aio ring pages are user space pages, so they can be migrated.
+* When writing to an aio ring page, we should ensure the page is not
+* being migrated. Aio page migration procedure is protected by
+* ctx->completion_lock, so we add this lock here.
+*/
+   spin_lock_irq(&ctx->completion_lock);
+
ring = kmap_atomic(ctx->ring_pages[0]);
ring->head = head;
kunmap_atomic(ring);
flush_dcache_page(ctx->ring_pages[0]);

+   spin_unlock_irq(&ctx->completion_lock);
+
pr_debug("%li  h%u t%u\n", ret, head, tail);

put_reqs_available(ctx, ret);
--
1.7.7


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

Re: [PATCH net V2] vhost: net: switch to use data copy if pending DMAs exceed the limit

[Jason Wang]

On 03/08/2014 05:39 AM, David Miller wrote:
> From: Jason Wang 
> Date: Fri,  7 Mar 2014 13:28:27 +0800
>
>> This is because the delay added by htb may lead the delay the finish
>> of DMAs and cause the pending DMAs for tap0 exceeds the limit
>> (VHOST_MAX_PEND). In this case vhost stop handling tx request until
>> htb send some packets. The problem here is all of the packets
>> transmission were blocked even if it does not go to VM2.
> Isn't this essentially head of line blocking?

Yes it is.
>> We can solve this issue by relaxing it a little bit: switching to use
>> data copy instead of stopping tx when the number of pending DMAs
>> exceed half of the vq size. This is safe because:
>>
>> - The number of pending DMAs were still limited (half of the vq size)
>> - The out of order completion during mode switch can make sure that
>>   most of the tx buffers were freed in time in guest.
>>
>> So even if about 50% packets were delayed in zero-copy case, vhost
>> could continue to do the transmission through data copy in this case.
>>
>> Test result:
>>
>> Before this patch:
>> VM1 to VM2 throughput is 9.3Mbit/s
>> VM1 to External throughput is 40Mbit/s
>> CPU utilization is 7%
>>
>> After this patch:
>> VM1 to VM2 throughput is 9.3Mbit/s
>> Vm1 to External throughput is 93Mbit/s
>> CPU utilization is 16%
>>
>> Completed performance test on 40gbe shows no obvious changes in both
>> throughput and cpu utilization with this patch.
>>
>> The patch only solve this issue when unlimited sndbuf. We still need a
>> solution for limited sndbuf.
>>
>> Cc: Michael S. Tsirkin 
>> Cc: Qin Chuanyu 
>> Signed-off-by: Jason Wang 
> I'd like some vhost experts reviewing this before I apply it.

Sure.
--
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: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary slightly

[Chao Yu]

Hi Gu, Kim:

One more comment.

> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, March 10, 2014 12:46 PM
> To: Gu Zheng
> Cc: linux-kernel; f2fs
> Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: optimize restore_node_summary 
> slightly
> 
> Hi Gu,
> 
> 2014-03-07 (금), 18:43 +0800, Gu Zheng:
> > Previously, we ra_sum_pages to pre-read contiguous pages as more
> > as possible, and if we fail to alloc more pages, an ENOMEM error
> > will be reported upstream, even though we have alloced some pages
> > yet. In fact, we can use the available pages to do the job partly,
> > and continue the rest in the following circle. Only reporting ENOMEM
> > upstream if we really can not alloc any available page.
> >
> > And another fix is ignoring dealing with the following pages if an
> > EIO occurs when reading page from page_list.
> >
> > Signed-off-by: Gu Zheng 

Reviewed-by: Chao Yu 

> > ---
> >  fs/f2fs/node.c|   44 
> >  fs/f2fs/segment.c |7 +--
> >  2 files changed, 25 insertions(+), 26 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 8787469..4b7861d 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1588,15 +1588,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> > struct list_head
> *pages,
> > for (; page_idx < start + nrpages; page_idx++) {
> > /* alloc temporal page for read node summary info*/
> > page = alloc_page(GFP_F2FS_ZERO);
> > -   if (!page) {
> > -   struct page *tmp;
> > -   list_for_each_entry_safe(page, tmp, pages, lru) {
> > -   list_del(&page->lru);
> > -   unlock_page(page);
> > -   __free_pages(page, 0);
> > -   }
> > -   return -ENOMEM;
> > -   }
> > +   if (!page)
> > +   break;
> >
> > lock_page(page);
> > page->index = page_idx;
> > @@ -1607,7 +1600,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> > struct list_head
> *pages,
> > f2fs_submit_page_mbio(sbi, page, page->index, &fio);
> >
> > f2fs_submit_merged_bio(sbi, META, READ);
> > -   return 0;
> > +
> > +   return page_idx - start;
> >  }
> >
> >  int restore_node_summary(struct f2fs_sb_info *sbi,
> > @@ -1630,28 +1624,30 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > nrpages = min(last_offset - i, bio_blocks);
> >
> > /* read ahead node pages */
> > -   err = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > -   if (err)
> > -   return err;
> > +   nrpages = ra_sum_pages(sbi, &page_list, addr, nrpages);
> > +   if (!nrpages)
> > +   return -ENOMEM;
> >
> > list_for_each_entry_safe(page, tmp, &page_list, lru) {
> > -
> 
> Here we can just add:
>   if (err)
>   goto skip;
>   lock_page();
>   ...
>   unlock_page();
>   skip:
>   list_del();
>   __free_pages();
> 
> IMO, it's more neat, so if you have any objection, let me know.
> Otherwise, I'll handle this by myself. :)
> Thanks,
> 
> > -   lock_page(page);
> > -   if (unlikely(!PageUptodate(page))) {
> > -   err = -EIO;
> > -   } else {
> > -   rn = F2FS_NODE(page);
> > -   sum_entry->nid = rn->footer.nid;
> > -   sum_entry->version = 0;
> > -   sum_entry->ofs_in_node = 0;
> > -   sum_entry++;
> > +   if (!err) {

If we skip here, next round we will fill these summary page entries with
wrong info because we skip the code 'sum_entry++;'.

> > +   lock_page(page);
> > +   if (unlikely(!PageUptodate(page))) {
> > +   err = -EIO;
> > +   } else {
> > +   rn = F2FS_NODE(page);
> > +   sum_entry->nid = rn->footer.nid;
> > +   sum_entry->version = 0;
> > +   sum_entry->ofs_in_node = 0;
> > +   sum_entry++;
> > +   }
> > +   unlock_page(page);
> > }
> >
> > list_del(&page->lru);
> > -   unlock_page(page);
> > __free_pages(page, 0);
> > }

Maybe we should add code here.
if (err)
return err;

> > }
> > +
> > return err;
> >  }
> >
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/

[PATCH][RFC] mm: warning message for vm_map_ram about vm size

[Gioh Kim]

Hi,

I have a failure of allocation of virtual memory on ARMv7 based platform.

I called alloc_page()/vm_map_ram() for allocation/mapping pages.
Virtual memory space exhausting problem occurred.
I checked virtual memory space and found that there are too many 4MB chunks.

I thought that if just one page in the 4MB chunk lives long, 
the entire chunk cannot be freed. Therefore new chunk is created again and 
again.

In my opinion, the vm_map_ram() function should be used for temporary mapping
and/or short term memory mapping. Otherwise virtual memory is wasted.

I am not sure if my opinion is correct. If it is, please add some warning 
message
about the vm_map_ram().



---8<---

Subject: [PATCH] mm: warning comment for vm_map_ram

vm_map_ram can occur locking of virtual memory space
because if only one page lives long in one vmap_block,
it takes 4MB (1024-times more than one page) space.

Change-Id: I6f5919848cf03788b5846b7d850d66e4d93ac39a
Signed-off-by: Gioh Kim 
---
 mm/vmalloc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0fdf968..2de1d1b 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1083,6 +1083,10 @@ EXPORT_SYMBOL(vm_unmap_ram);
  * @node: prefer to allocate data structures on this node
  * @prot: memory protection to use. PAGE_KERNEL for regular RAM
  *
+ * This function should be used for TEMPORARY mapping. If just one page lives i
+ * long, it would occupy 4MB vm size permamently. 100 pages (just 400KB) could
+ * takes 400MB with bad luck.
+ *
  * Returns: a pointer to the address that has been mapped, or %NULL on failure
  */
 void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t 
prot)
--
1.7.9.5

Gioh Kim / 김 기 오
Research Engineer
Advanced OS Technology Team
Software Platform R&D Lab.
Mobile: 82-10-7322-5548  
E-mail: gioh@lge.com 
19, Yangjae-daero 11gil
Seocho-gu, Seoul 137-130, Korea


--
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/5] f2fs: add a wait queue to avoid unnecessary, build_free_nid

[Jaegeuk Kim]

Hi Gu,

2014-03-07 (금), 18:43 +0800, Gu Zheng:
> Previously, when we try to alloc free nid while the build free nid
> is going, the allocer will be run into the flow that waiting for
> "nm_i->build_lock", see following:
>   /* We should not use stale free nids created by build_free_nids */
> > if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>   f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>   list_for_each(this, &nm_i->free_nid_list) {
>   i = list_entry(this, struct free_nid, list);
>   if (i->state == NID_NEW)
>   break;
>   }
> 
>   f2fs_bug_on(i->state != NID_NEW);
>   *nid = i->nid;
>   i->state = NID_ALLOC;
>   nm_i->fcnt--;
>   spin_unlock(&nm_i->free_nid_list_lock);
>   return true;
>   }
>   spin_unlock(&nm_i->free_nid_list_lock);
> 
>   /* Let's scan nat pages and its caches to get free nids */
> > mutex_lock(&nm_i->build_lock);
>   build_free_nids(sbi);
>   mutex_unlock(&nm_i->build_lock);
> and this will cause another unnecessary building free nid if the current
> building free nid job is done.

Could you support any performance number for this?
Since, IMO, the contended building processes will be released right away
because of the following condition check inside build_free_nids().

if (nm_i->fcnt > NAT_ENTRY_PER_BLOCK)
return;

So, I don't think this gives us any high latency.
Can the wakeup_all() become another overhead all the time?
Thanks,

> So here we introduce a wait_queue to avoid this issue.
> 
> Signed-off-by: Gu Zheng 
> ---
>  fs/f2fs/f2fs.h |1 +
>  fs/f2fs/node.c |   10 +-
>  2 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index f845e92..7ae193e 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -256,6 +256,7 @@ struct f2fs_nm_info {
>   spinlock_t free_nid_list_lock;  /* protect free nid list */
>   unsigned int fcnt;  /* the number of free node id */
>   struct mutex build_lock;/* lock for build free nids */
> + wait_queue_head_t build_wq; /* wait queue for build free nids */
>  
>   /* for checkpoint */
>   char *nat_bitmap;   /* NAT bitmap pointer */
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 4b7861d..ab44711 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1422,7 +1422,13 @@ retry:
>   spin_lock(&nm_i->free_nid_list_lock);
>  
>   /* We should not use stale free nids created by build_free_nids */
> - if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
> + if (on_build_free_nids(nm_i)) {
> + spin_unlock(&nm_i->free_nid_list_lock);
> + wait_event(nm_i->build_wq, !on_build_free_nids(nm_i));
> + goto retry;
> + }
> +
> + if (nm_i->fcnt) {
>   f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>   list_for_each(this, &nm_i->free_nid_list) {
>   i = list_entry(this, struct free_nid, list);
> @@ -1443,6 +1449,7 @@ retry:
>   mutex_lock(&nm_i->build_lock);
>   build_free_nids(sbi);
>   mutex_unlock(&nm_i->build_lock);
> + wake_up_all(&nm_i->build_wq);
>   goto retry;
>  }
>  
> @@ -1813,6 +1820,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
>   INIT_LIST_HEAD(&nm_i->dirty_nat_entries);
>  
>   mutex_init(&nm_i->build_lock);
> + init_waitqueue_head(&nm_i->build_wq);
>   spin_lock_init(&nm_i->free_nid_list_lock);
>   rwlock_init(&nm_i->nat_tree_lock);
>  

-- 
Jaegeuk Kim
Samsung

--
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 4/5] f2fs: optimize restore_node_summary slightly

[Jaegeuk Kim]

Hi Gu,

2014-03-07 (금), 18:43 +0800, Gu Zheng:
> Previously, we ra_sum_pages to pre-read contiguous pages as more
> as possible, and if we fail to alloc more pages, an ENOMEM error
> will be reported upstream, even though we have alloced some pages
> yet. In fact, we can use the available pages to do the job partly,
> and continue the rest in the following circle. Only reporting ENOMEM
> upstream if we really can not alloc any available page.
> 
> And another fix is ignoring dealing with the following pages if an
> EIO occurs when reading page from page_list.
> 
> Signed-off-by: Gu Zheng 
> ---
>  fs/f2fs/node.c|   44 
>  fs/f2fs/segment.c |7 +--
>  2 files changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 8787469..4b7861d 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1588,15 +1588,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> struct list_head *pages,
>   for (; page_idx < start + nrpages; page_idx++) {
>   /* alloc temporal page for read node summary info*/
>   page = alloc_page(GFP_F2FS_ZERO);
> - if (!page) {
> - struct page *tmp;
> - list_for_each_entry_safe(page, tmp, pages, lru) {
> - list_del(&page->lru);
> - unlock_page(page);
> - __free_pages(page, 0);
> - }
> - return -ENOMEM;
> - }
> + if (!page)
> + break;
>  
>   lock_page(page);
>   page->index = page_idx;
> @@ -1607,7 +1600,8 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi, 
> struct list_head *pages,
>   f2fs_submit_page_mbio(sbi, page, page->index, &fio);
>  
>   f2fs_submit_merged_bio(sbi, META, READ);
> - return 0;
> +
> + return page_idx - start;
>  }
>  
>  int restore_node_summary(struct f2fs_sb_info *sbi,
> @@ -1630,28 +1624,30 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
>   nrpages = min(last_offset - i, bio_blocks);
>  
>   /* read ahead node pages */
> - err = ra_sum_pages(sbi, &page_list, addr, nrpages);
> - if (err)
> - return err;
> + nrpages = ra_sum_pages(sbi, &page_list, addr, nrpages);
> + if (!nrpages)
> + return -ENOMEM;
>  
>   list_for_each_entry_safe(page, tmp, &page_list, lru) {
> -

Here we can just add:
if (err)
goto skip;
lock_page();
...
unlock_page();
skip:
list_del();
__free_pages();

IMO, it's more neat, so if you have any objection, let me know.
Otherwise, I'll handle this by myself. :)
Thanks,

> - lock_page(page);
> - if (unlikely(!PageUptodate(page))) {
> - err = -EIO;
> - } else {
> - rn = F2FS_NODE(page);
> - sum_entry->nid = rn->footer.nid;
> - sum_entry->version = 0;
> - sum_entry->ofs_in_node = 0;
> - sum_entry++;
> + if (!err) {
> + lock_page(page);
> + if (unlikely(!PageUptodate(page))) {
> + err = -EIO;
> + } else {
> + rn = F2FS_NODE(page);
> + sum_entry->nid = rn->footer.nid;
> + sum_entry->version = 0;
> + sum_entry->ofs_in_node = 0;
> + sum_entry++;
> + }
> + unlock_page(page);
>   }
>  
>   list_del(&page->lru);
> - unlock_page(page);
>   __free_pages(page, 0);
>   }
>   }
> +
>   return err;
>  }
>  
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 199c964..b3f8431 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1160,9 +1160,12 @@ static int read_normal_summaries(struct f2fs_sb_info 
> *sbi, int type)
>   ns->ofs_in_node = 0;
>   }
>   } else {
> - if (restore_node_summary(sbi, segno, sum)) {
> + int err;
> +
> + err = restore_node_summary(sbi, segno, sum);
> + if (err) {
>   f2fs_put_page(new, 1);
> - return -EINVAL;
> +  

Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[Andy Lutomirski]

On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski  wrote:
> (Of course, I haven't the faintest idea what l_addr in glibc means.
> If there was a way to arrange for l_addr to be zero, then maybe none
> of this would matter.  Hmm, I wonder if just not relocating the vdso
> at all would have the desired effect.  Anyone out there understand
> glibc?)

No, that won't work.  The bug is that glibc expects PT_DYNAMIC's vaddr
to be the virtual address of the dynamic table.  This can only be true
if the vdso is mapped at the address that the kernel relocated it to.

I also learned that glibc's code is really hideous.  Wow.

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

Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver

[Jenny Tc]

On Fri, Mar 07, 2014 at 09:25:20PM +0100, Pavel Machek wrote:

Hi,

> > The Power Supply charging driver connects multiple subsystems
> > to do charging in a generic way. The subsystems involves power_supply,
> > thermal and battery communication subsystems (1wire).With this the charging 
> > is
> > handled in a generic way.
> 
> " " after ".", please.

Will fix in next patch set

> > +
> > +The Power Supply charging driver connects multiple subsystems
> > +to do charging in a generic way. The subsystems involves power_supply,
> > +thermal and battery communication subsystems (1wire).With this the 
> > charging is
> 
> Here too.

Same here
> 
> 
> 
> > +
> > +The driver introduces different new features - Battery Identification
> > +interfaces, pluggable charging algorithms, charger cable arbitrations etc.
> > +
> > +In existing driver implementations the charging is done based on the static
> > +battery characteristics. This is done at the boot time by passing the 
> > battery
> > +properties (max_voltage, capacity) etc. as a platform data to the
> 
> -> (max_voltage, capacity, etc.)

Same here
> 
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -14,6 +14,14 @@ config POWER_SUPPLY_DEBUG
> >   Say Y here to enable debugging messages for power supply class
> >   and drivers.
> >  
> > +config POWER_SUPPLY_CHARGER
> > +   bool "Power Supply Charger"
> > +   help
> > + Say Y here to enable the power supply charging control driver. 
> > Charging
> > + control supports charging in a generic way. This allows the charger
> > + drivers to keep the charging logic outside and the charger driver
> > + just need to abstract the charger hardware.
> > +
> 
> Umm. This is not too helpful for our users.

Will add more text to help users.
> 
> > +struct psy_charger_context {
> > +   bool is_usb_cable_evt_reg;
> > +   int psyc_cnt;
> > +   int batt_status;
> > +   /* cache battery and charger properties */
> > +   struct list_head chrgr_cache_lst;
> > +   struct list_head batt_cache_lst;
> > +   struct mutex event_lock;
> > +   struct list_head event_queue;
> > +   struct psy_batt_chrg_prof batt_property;
> > +   wait_queue_head_t wait_chrg_enable;
> > +   spinlock_t battid_spinlock;
> > +   spinlock_t event_queue_lock;
> > +   struct work_struct event_work;
> > +};
> > +
> > +struct charger_cable {
> > +   struct psy_cable_props cable_props;
> > +   enum psy_charger_cable_type psy_cable_type;
> > +};
> > +
> > +static struct psy_charger_context psy_chrgr;
> 
> You still miss some wovels here. Sometimes it imakes it unlear: 
> chrg is charge? charger?

chrgr means charger, chrg means charge. Isn't it used consistently?. Can fix it 
if
it's really annoying. Please suggest.
> 
> 
> > +static inline bool psy_is_charger_prop_changed(struct psy_charger_props 
> > prop,
> > +   struct psy_charger_props cache_prop)
> > +{
> > +   /* if online/prsent/health/is_charging is changed, then return true */
> 
> Typo - present.

Will fix in next patch set
> 
> > +static inline void cache_chrgr_prop(struct psy_charger_props 
> > *chrgr_prop_new)
> > +{
> > +   struct psy_charger_props *chrgr_cache;
> > +
> > +   list_for_each_entry(chrgr_cache, &psy_chrgr.chrgr_cache_lst, node) {
> > +   if (!strcmp(chrgr_cache->name, chrgr_prop_new->name))
> > +   goto update_props;
> > +   }
> 
> Interesting use of goto. Maybe update_properties should be separate function?

I feel, having a function just for few assignments may not be a good idea.
What about having memcpy?
> 
> > +update_props:
> > +   chrgr_cache->is_charging = chrgr_prop_new->is_charging;
> > +   chrgr_cache->online = chrgr_prop_new->online;
> > +   chrgr_cache->health = chrgr_prop_new->health;
> > +   chrgr_cache->present = chrgr_prop_new->present;
> > +   chrgr_cache->cable = chrgr_prop_new->cable;
> > +   chrgr_cache->tstamp = chrgr_prop_new->tstamp;
> > +   chrgr_cache->psyc = chrgr_prop_new->psyc;
> > +}
> > +
> > +   chrgr_prop.psyc = chrgr_prop_cache.psyc;
> > +   cache_chrgr_prop(&chrgr_prop);
> > +   return true;
> > +}
> > +static void cache_successive_samples(long *sample_array, long new_sample)
> > +{
> 
> Add empty line between the functions.

Ok..Will fix in next patch set
> 
> > +static inline void cache_bat_prop(struct psy_batt_props *bat_prop_new)
> > +{
> > +   struct psy_batt_props *bat_cache;
> > +
> > +   /*
> > +   *  Find entry in cache list. If an entry is located update
> > +   *  the existing entry else create new entry in the list
> > +   */
> > +   list_for_each_entry(bat_cache, &psy_chrgr.batt_cache_lst, node) {
> > +   if (!strcmp(bat_cache->name, bat_prop_new->name))
> > +   goto update_props;
> > +   }
> > +
> > +   bat_cache = kzalloc(sizeof(*bat_cache), GFP_KERNEL);
> 
> What is it with all the caching? Is it good idea to have caches
> indexed by strings? Can't you go without caching, or attach caches to
> some structure? Interesting goto again.

Cache

Re: [PATCH] cpufreq: use cpufreq_cpu_get to avoid cpufreq_get race conditions

[Viresh Kumar]

On 6 March 2014 09:23, Rafael J. Wysocki  wrote:
> On Tuesday, March 04, 2014 12:42:15 PM Aaron Plattner wrote:
>> If a module calls cpufreq_get while cpufreq is initializing, it's possible 
>> for
>> it to be called after cpufreq_driver is set but before cpufreq_cpu_data is
>> written during subsys_interface_register.  This happens because cpufreq_get
>> doesn't take the cpufreq_driver_lock around its use of cpufreq_cpu_data.
>
> Is this a theoretical race, or can you actually reproduce it?  If so, on what
> system/driver?  Or are there any bug reports related to this you can point me
> to?
>
>> Fix this by using cpufreq_cpu_get(cpu) to look up the policy rather than 
>> reading
>> it out of cpufreq_cpu_data directly.  cpufreq_cpu_get takes the appropriate
>> locks to prevent this race from happening.
>>
>> Since it's possible for policy to be NULL if the caller passes in an invalid 
>> CPU
>> number or calls the function before cpufreq is initialized, delete the
>> BUG_ON(!policy) and simply return 0.  Don't try to return -ENOENT because 
>> that's
>> negative and the function returns an unsigned integer.
>>
>> Signed-off-by: Aaron Plattner 
>
> Viresh, have you seen this?

Sorry for being late. Though I see you have already applied this one,
I will still add this for records :)

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

Linux 3.14-rc6

[Linus Torvalds]

We're getting closer to the end of the rc cycle, and I have to admit
that I would have wished for a less bumpy ride.

There haven't been any huge problems, but there's been quite a few
small bumps that shouldn't happen this late in the release cycle. And
rc6 is noticeably bigger than rc5 was, as well.

So I'm really hoping that the upcoming week will be calmer, because
otherwise I'll start thing rc8 and even rc9..

That said, there's nothing really fundamentally scary here. Small
stupid mistakes, and a few late reverts of commits that turned out to
not be so great, but the bulk is trivial fixes. So I'm still
reasonably optimistic.

 Linus

---

Aaron Plattner (1):
  cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions

Akash Goel (1):
  drm/i915: Resolving the memory region conflict for Stolen area

Alex Deucher (4):
  drm/radeon: resume old pm late
  drm/radeon/cik: fix typo in documentation
  drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters
  drm/radeon/atom: select the proper number of lanes in transmitter setup

Alexander Stein (2):
  spi/topcliff-pch: Fix DMA channel
  spi-topcliff-pch: Fix probing when DMA mode is used

Alexandre Bounine (1):
  rapidio/tsi721: fix tasklet termination in dma channel release

Amir Vadai (1):
  net,IB/mlx: Bump all Mellanox driver versions

Amitkumar Karwar (3):
  mwifiex: add NULL check for PCIe Rx skb
  mwifiex: fix cmd and Tx data timeout issue for PCIe cards
  NFC: NCI: Fix NULL pointer dereference

Andrew Bresticker (3):
  clk: tegra: fix sdmmc clks on Tegra1x4
  clk: tegra: cclk_lp has a pllx/2 divider
  clk: tegra: use max divider if divider overflows

Andy Adamson (1):
  NFSv4.1 Fail data server I/O if stateid represents a lost lock

Andy Honig (1):
  kallsyms: fix absolute addresses for kASLR

Anton Blanchard (1):
  powerpc: Align p_dyn, p_rela and p_st symbols

Arend van Spriel (1):
  brcmfmac: fix txglomming scatter-gather packet transfers

Arik Nemtsov (1):
  mac80211: fix sched_scan restart on recovery

Asai Thambi S P (1):
  mtip32xx: Reduce the number of unaligned writes to 2

Avinash Patil (1):
  mwifiex: clean pcie ring only when device is present

Axel Lin (2):
  spi: fsl-dspi: Fix getting correct address for master
  spi: coldfire-qspi: Fix getting correct address for *mcfqspi

Barry Song (1):
  pinctrl: sirf: fix kernel panic in gpio_lock_as_irq

Benoit Cousson (1):
  clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change

Bing Zhao (2):
  mwifiex: rename usb driver name registerring to usb core
  mwifiex: do not advertise usb autosuspend support

Borislav Petkov (2):
  MAINTAINERS: EDAC: add Mauro and Borislav as interim patch collectors
  x86/efi: Quirk out SGI UV

Chen-Yu Tsai (1):
  pinctrl: sunxi: use chained_irq_{enter, exit} for GIC compatibility

Christian Daudt (1):
  pinctrl: refer to updated dt binding string.

Christoph Hellwig (3):
  blk-mq: remove blk_mq_alloc_rq
  blk-mq: merge blk_mq_insert_request and blk_mq_run_request
  blk-mq: support partial I/O completions

Chuansheng Liu (1):
  genirq: Remove racy waitqueue_active check

Cristian Bercaru (1):
  phy: unmask link partner capabilities

Dan Carpenter (2):
  hsr: off by one sanity check in hsr_register_frame_in()
  qlcnic: dcb: a couple off by one bugs

Dan Williams (1):
  dma debug: account for cachelines and read-only mappings in
overlap tracking

Daniel Borkmann (2):
  net: sctp: rework multihoming retransmission path selection to rfc4960
  net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable

Daniel M. Weeks (1):
  scripts/gen_initramfs_list.sh: fix flags for initramfs LZ4 compression

Dave Airlie (1):
  MAINTAINERS: update AGP tree to point at drm tree

David A. Long (1):
  ARM: 7964/1: Detect section mismatches in thumb relocations

David Howells (1):
  KEYS: Make the keyring cycle detector ignore other keyrings of
the same name

David Rientjes (1):
  mm: close PageTail race

David S. Miller (1):
  ip_tunnel: Move ip_tunnel_get_stats64 into ip_tunnel_core.c

David Ung (1):
  clk: tegra: PLLD2 fixes for hdmi

Ditang Chen (1):
  SUNRPC: Fix oops when trace sunrpc_task events in nfs client

Duan Fugang-B38611 (1):
  net: fec: fix potential issue to avoid fec interrupt lost and crc error

Duan Jiong (1):
  neigh: recompute reachabletime before returning from neigh_periodic_work()

Edward Cree (1):
  sfc: check for NULL efx->ptp_data in efx_ptp_event

Emmanuel Grumbach (2):
  mac80211: fix AP powersave TX vs. wakeup race
  iwlwifi: dvm: clear IWL_STA_UCODE_INPROGRESS when assoc fails

Eric Dumazet (3):
  net-tcp: fastopen: fix high order allocations
  tcp: reduce the bloat caused by tcp_is_cwnd_limited()
  net: tcp: use NET_INC_STATS()

Eytan Lifshitz (1):
  m

Re: [PATCH] cpufreq: Reformat printk() statement

[Viresh Kumar]

On 10 March 2014 12:07, Joe Perches  wrote:
> On Mon, 2014-03-10 at 11:53 +0800, Viresh Kumar wrote:
>> On 7 March 2014 01:34, Soren Brinkmann  wrote:
>> > Reformat a printk statement to:
>> >  - use pr_warn
>> >  - bring the whole string into a single line in favor of being able to
>> >grep for the message (ignoring the 80 char limit)
>> >
>> > Signed-off-by: Soren Brinkmann 
> []
>> Acked-by: Viresh Kumar 
>
> A more comprehensive patch would be to:
>
> Add missing newlines
> Coalesce format fragments
> Convert printks to pr_
> Align arguments
> ---
>  drivers/cpufreq/cpufreq.c | 85 
> ++-
>  1 file changed, 40 insertions(+), 45 deletions(-)

Thanks..

Acked-by: Viresh Kumar 
--
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: [f2fs-dev] [PATCH 5/5] f2fs: add a wait queue to avoid unnecessary, build_free_nid

[Changman Lee]

On 금, 2014-03-07 at 18:43 +0800, Gu Zheng wrote:
> Previously, when we try to alloc free nid while the build free nid
> is going, the allocer will be run into the flow that waiting for
> "nm_i->build_lock", see following:
>   /* We should not use stale free nids created by build_free_nids */
> > if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
>   f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>   list_for_each(this, &nm_i->free_nid_list) {
>   i = list_entry(this, struct free_nid, list);
>   if (i->state == NID_NEW)
>   break;
>   }
> 
>   f2fs_bug_on(i->state != NID_NEW);
>   *nid = i->nid;
>   i->state = NID_ALLOC;
>   nm_i->fcnt--;
>   spin_unlock(&nm_i->free_nid_list_lock);
>   return true;
>   }
>   spin_unlock(&nm_i->free_nid_list_lock);
> 
>   /* Let's scan nat pages and its caches to get free nids */
> > mutex_lock(&nm_i->build_lock);
>   build_free_nids(sbi);
>   mutex_unlock(&nm_i->build_lock);
> and this will cause another unnecessary building free nid if the current
> building free nid job is done.
> So here we introduce a wait_queue to avoid this issue.
> 
> Signed-off-by: Gu Zheng 
> ---
>  fs/f2fs/f2fs.h |1 +
>  fs/f2fs/node.c |   10 +-
>  2 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index f845e92..7ae193e 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -256,6 +256,7 @@ struct f2fs_nm_info {
>   spinlock_t free_nid_list_lock;  /* protect free nid list */
>   unsigned int fcnt;  /* the number of free node id */
>   struct mutex build_lock;/* lock for build free nids */
> + wait_queue_head_t build_wq; /* wait queue for build free nids */
>  
>   /* for checkpoint */
>   char *nat_bitmap;   /* NAT bitmap pointer */
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 4b7861d..ab44711 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1422,7 +1422,13 @@ retry:
>   spin_lock(&nm_i->free_nid_list_lock);
>  
>   /* We should not use stale free nids created by build_free_nids */
> - if (nm_i->fcnt && !on_build_free_nids(nm_i)) {
> + if (on_build_free_nids(nm_i)) {
> + spin_unlock(&nm_i->free_nid_list_lock);
> + wait_event(nm_i->build_wq, !on_build_free_nids(nm_i));
> + goto retry;
> + }
> +

It would be better moving spin_lock(free_nid_list_lock) here after
removing above spin_unlock().

> + if (nm_i->fcnt) {
>   f2fs_bug_on(list_empty(&nm_i->free_nid_list));
>   list_for_each(this, &nm_i->free_nid_list) {
>   i = list_entry(this, struct free_nid, list);
> @@ -1443,6 +1449,7 @@ retry:
>   mutex_lock(&nm_i->build_lock);
>   build_free_nids(sbi);
>   mutex_unlock(&nm_i->build_lock);
> + wake_up_all(&nm_i->build_wq);
>   goto retry;
>  }
>  
> @@ -1813,6 +1820,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
>   INIT_LIST_HEAD(&nm_i->dirty_nat_entries);
>  
>   mutex_init(&nm_i->build_lock);
> + init_waitqueue_head(&nm_i->build_wq);
>   spin_lock_init(&nm_i->free_nid_list_lock);
>   rwlock_init(&nm_i->nat_tree_lock);
>  


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

Re: [PATCH] cpufreq: Reformat printk() statement

[Joe Perches]

On Mon, 2014-03-10 at 11:53 +0800, Viresh Kumar wrote:
> On 7 March 2014 01:34, Soren Brinkmann  wrote:
> > Reformat a printk statement to:
> >  - use pr_warn
> >  - bring the whole string into a single line in favor of being able to
> >grep for the message (ignoring the 80 char limit)
> >
> > Signed-off-by: Soren Brinkmann 
[]
> Acked-by: Viresh Kumar 

A more comprehensive patch would be to:

Add missing newlines
Coalesce format fragments
Convert printks to pr_
Align arguments
---
 drivers/cpufreq/cpufreq.c | 85 ++-
 1 file changed, 40 insertions(+), 45 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 56b7b1b..c2d06e9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -181,8 +181,8 @@ unsigned int cpufreq_generic_get(unsigned int cpu)
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
 
if (!policy || IS_ERR(policy->clk)) {
-   pr_err("%s: No %s associated to cpu: %d\n", __func__,
-   policy ? "clk" : "policy", cpu);
+   pr_err("%s: No %s associated to cpu: %d\n",
+  __func__, policy ? "clk" : "policy", cpu);
return 0;
}
 
@@ -254,15 +254,15 @@ static void adjust_jiffies(unsigned long val, struct 
cpufreq_freqs *ci)
if (!l_p_j_ref_freq) {
l_p_j_ref = loops_per_jiffy;
l_p_j_ref_freq = ci->old;
-   pr_debug("saving %lu as reference value for loops_per_jiffy; "
-   "freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
+   pr_debug("saving %lu as reference value for loops_per_jiffy; 
freq is %u kHz\n",
+l_p_j_ref, l_p_j_ref_freq);
}
if ((val == CPUFREQ_POSTCHANGE && ci->old != ci->new) ||
(val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
ci->new);
-   pr_debug("scaling loops_per_jiffy to %lu "
-   "for frequency %u kHz\n", loops_per_jiffy, ci->new);
+   pr_debug("scaling loops_per_jiffy to %lu for frequency %u 
kHz\n",
+loops_per_jiffy, ci->new);
}
 }
 #else
@@ -282,7 +282,7 @@ static void __cpufreq_notify_transition(struct 
cpufreq_policy *policy,
 
freqs->flags = cpufreq_driver->flags;
pr_debug("notification %u of frequency transition to %u kHz\n",
-   state, freqs->new);
+state, freqs->new);
 
switch (state) {
 
@@ -294,9 +294,8 @@ static void __cpufreq_notify_transition(struct 
cpufreq_policy *policy,
if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
if ((policy) && (policy->cpu == freqs->cpu) &&
(policy->cur) && (policy->cur != freqs->old)) {
-   pr_debug("Warning: CPU frequency is"
-   " %u, cpufreq assumed %u kHz.\n",
-   freqs->old, policy->cur);
+   pr_debug("Warning: CPU frequency is %u, cpufreq 
assumed %u kHz\n",
+freqs->old, policy->cur);
freqs->old = policy->cur;
}
}
@@ -307,8 +306,8 @@ static void __cpufreq_notify_transition(struct 
cpufreq_policy *policy,
 
case CPUFREQ_POSTCHANGE:
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
-   pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
-   (unsigned long)freqs->cpu);
+   pr_debug("FREQ: %lu - CPU: %lu\n",
+(unsigned long)freqs->new, (unsigned long)freqs->cpu);
trace_cpu_frequency(freqs->new, freqs->cpu);
srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
@@ -368,13 +367,13 @@ static ssize_t store_boost(struct kobject *kobj, struct 
attribute *attr,
return -EINVAL;
 
if (cpufreq_boost_trigger_state(enable)) {
-   pr_err("%s: Cannot %s BOOST!\n", __func__,
-  enable ? "enable" : "disable");
+   pr_err("%s: Cannot %s BOOST!\n",
+  __func__, enable ? "enable" : "disable");
return -EINVAL;
}
 
-   pr_debug("%s: cpufreq BOOST %s\n", __func__,
-enable ? "enabled" : "disabled");
+   pr_debug("%s: cpufreq BOOST %s\n",
+__func__, enable ? "enabled" : "disabled");
 
return count;
 }
@@ -1184,7 +1183,7 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
if (gov) {
policy->governor = gov;
pr_debug("

Re: [PATCH] cpufreq: Reformat printk() statement

[Viresh Kumar]

On 7 March 2014 01:34, Soren Brinkmann  wrote:
> Reformat a printk statement to:
>  - use pr_warn
>  - bring the whole string into a single line in favor of being able to
>grep for the message (ignoring the 80 char limit)
>
> Signed-off-by: Soren Brinkmann 
> ---
>  drivers/cpufreq/cpufreq.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index cb003a6b72c8..534c2df608ed 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1874,11 +1874,8 @@ static int __cpufreq_governor(struct cpufreq_policy 
> *policy,
> if (!gov)
> return -EINVAL;
> else {
> -   printk(KERN_WARNING "%s governor failed, too long"
> -  " transition latency of HW, fallback"
> -  " to %s governor\n",
> -  policy->governor->name,
> -  gov->name);
> +   pr_warn("%s governor failed, too long transition 
> latency of HW, fallback to %s governor\n",
> +   policy->governor->name, gov->name);
> policy->governor = gov;
> }
> }

Acked-by: Viresh Kumar 
--
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] [TRIVIAL] ARM: spear: clean up editing mistake

[Viresh Kumar]

On 10 March 2014 05:41, Paul Bolle  wrote:
> Clean up an obvious editing mistake introduced by commit 4b6effb6ff38
> ("ARM: spear: merge Kconfig files").
>
> Signed-off-by: Paul Bolle 
> ---
>  arch/arm/mach-spear/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-spear/Kconfig b/arch/arm/mach-spear/Kconfig
> index 1595776..596e990 100644
> --- a/arch/arm/mach-spear/Kconfig
> +++ b/arch/arm/mach-spear/Kconfig
> @@ -91,7 +91,7 @@ config MACH_SPEAR600
> depends on ARCH_SPEAR6XX
> select USE_OF
> help
> - Supports ST SPEAr600 boards configured via the device-treesource 
> "arch/arm/mach-spear6xx/Kconfig"
> + Supports ST SPEAr600 boards configured via the device-tree
>
>  config ARCH_SPEAR_AUTO
> depends on !ARCH_SPEAR13XX && !ARCH_SPEAR6XX

Acked-by: Viresh Kumar 
--
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/3] ASoC: codec: Simplify ASoC probe code.

[li.xi...@freescale.com]

> Subject: Re: [PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.
> 
> On Mon, Mar 03, 2014 at 07:24:36AM +, li.xi...@freescale.com wrote:
> 
> > > > /* Default to using ALC auto offset calibration mode. */
> > > > snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
> > > > DA7213_ALC_CALIB_MODE_MAN, 0);
> 
> > > This one will fail.
> 
> > Sorry, I'm not very understand why will this fail ? Before the ASoC probe,
> > the ASoC core will set the I/O.
> > :)
> 
> OK, that's now been refactored.

@Mark, @Lars,

Has there any other problems about this patch series? And this I had tested on
our Vybrid-Twr board based on SGTL5000 codec and SAI drivers. If not, I can
continue with my second patches series about " Remove set_cache_io entirely from
ASoC probe".

Thanks very much.

--
Best Regards,
Xiubo
--
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 net-next 0/7] r8152: tx/rx improvement

[hayeswang]

 David Miller [mailto:da...@davemloft.net] 
> Sent: Saturday, March 08, 2014 5:28 AM
> To: hayesw...@realtek.com
> Cc: net...@vger.kernel.org; nic_s...@realtek.com; 
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH net-next 0/7] r8152: tx/rx improvement
[...]
> Note that if you ever add ->ndo_poll_controller support to 
> this driver,
> you will have to revert your spin_lock_irq{save,restore}() changes to
> your ->ndo_start_xmit.
> 
> Because the transmit function can indeed be invoked from hard IRQ
> context once you support netpoll.

Thank you for your reminder. I would notice that.

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

[PATCH 2/2] bridge: multicast: enable snooping on general queries only

[Linus Lüssing]

Without this check someone could easily create a denial of service
by injecting multicast-specific queries to enable the bridge
snooping part if no real querier issuing periodic general queries
is present on the link which would result in the bridge wrongly
shutting down ports for multicast traffic as the bridge did not learn
about these listeners.

With this patch the snooping code is enabled upon receiving valid,
general queries only.

Signed-off-by: Linus Lüssing 
---
 net/bridge/br_multicast.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index c77f073..5dd4fec 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1127,9 +1127,10 @@ static void br_multicast_query_received(struct 
net_bridge *br,
struct net_bridge_port *port,
struct bridge_mcast_querier *querier,
int saddr,
+   bool is_general_query,
unsigned long max_delay)
 {
-   if (saddr)
+   if (saddr && is_general_query)
br_multicast_update_querier_timer(br, querier, max_delay);
else if (timer_pending(&querier->timer))
return;
@@ -1190,7 +1191,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
}
 
br_multicast_query_received(br, port, &br->ip4_querier, !!iph->saddr,
-   max_delay);
+   !group, max_delay);
 
if (!group)
goto out;
@@ -1282,7 +1283,8 @@ static int br_ip6_multicast_query(struct net_bridge *br,
}
 
br_multicast_query_received(br, port, &br->ip6_querier,
-   !ipv6_addr_any(&ip6h->saddr), max_delay);
+   !ipv6_addr_any(&ip6h->saddr),
+   is_general_query, max_delay);
 
if (!group)
goto out;
-- 
1.7.10.4

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

Re: [PATCHv8 1/4] power_supply: Add inlmt,iterm, min/max temp props

[Jenny Tc]

On Fri, Mar 07, 2014 at 09:12:40PM +0100, Pavel Machek wrote:
> On Fri 2014-03-07 10:59:31, Jenny TC wrote:
> > Add new power supply properties for input current, charge termination
> > current, min and max temperature
> > 
> > POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
> > POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature
> > 
> > POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. 
> > Indicates
> > the input current for a charging source.
> > 
> > POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to 
> > detect
> > the end of charge condition
> > 
> > Signed-off-by: Jenny TC 
> 
> The patch no longer matches the description, otherwise it looks good.

Will fix it in next patch set
--
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] net: phy: Add sysfs attribute to prevent PHY suspend

[David Miller]

From: Sebastian Hesselbarth 
Date: Mon, 10 Mar 2014 01:53:33 +0100

> On 03/10/2014 01:41 AM, David Miller wrote:
>> From: Sebastian Hesselbarth 
>> Date: Mon, 10 Mar 2014 01:37:32 +0100
>>
>>> The mechanism is manual, no automatic way to determine it.
>>
>> We recognize BIOS and ACPI bugs and work around them, by looking at
>> version information and whatnot, so you really can't convince me that
>> something similar can't be done here perhaps in the platform code.
> 
> Hmm, if the is a way to determine the version of that particual u-boot
> I'd be happy to exploit that information. But I honestly doubt that.
> Compared to u-boot bootloader and kernel interaction, BIOS and ACPI
> are well-defined protocols.
> 
> I personally, would prefer everybody should update his broken
> bootloaders, but that will just not happen.

What you can do is have a test that _perhaps_ covers a "broader than
reality" list of broken bootloader cases.

Then you have something the bootloader can provide which indicates
that it has been fixed.
--
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] bridge: multicast: add sanity check for general query destination

[Linus Lüssing]

General IGMP and MLD queries are supposed to have the multicast
link-local all-nodes address as their destination according to RFC2236
section 9, RFC3376 section 4.1.12/9.1, RFC2710 section 8 and RFC3810
section 5.1.15.

Without this check, such malformed IGMP/MLD queries can result in a
denial of service: The queries are ignored by most IGMP/MLD listeners
therefore they will not respond with an IGMP/MLD report. However,
without this patch these malformed MLD queries would enable the
snooping part in the bridge code, potentially shutting down the
according ports towards these hosts for multicast traffic as the
bridge did not learn about these listeners.

Reported-by: Jan Stancek 
Signed-off-by: Linus Lüssing 
---
 net/bridge/br_multicast.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index fb0e36f..c77f073 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1181,6 +1181,14 @@ static int br_ip4_multicast_query(struct net_bridge *br,
IGMPV3_MRC(ih3->code) * (HZ / IGMP_TIMER_SCALE) : 1;
}
 
+   /* RFC2236+RFC3376 (IGMPv2+IGMPv3) require the multicast link layer
+* all-systems destination addresses (224.0.0.1) for general queries
+*/
+   if (!group && iph->daddr != htonl(INADDR_ALLHOSTS_GROUP)) {
+   err = -EINVAL;
+   goto out;
+   }
+
br_multicast_query_received(br, port, &br->ip4_querier, !!iph->saddr,
max_delay);
 
@@ -1228,6 +1236,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
unsigned long max_delay;
unsigned long now = jiffies;
const struct in6_addr *group = NULL;
+   bool is_general_query;
int err = 0;
 
spin_lock(&br->multicast_lock);
@@ -1262,6 +1271,16 @@ static int br_ip6_multicast_query(struct net_bridge *br,
max_delay = max(msecs_to_jiffies(mldv2_mrc(mld2q)), 1UL);
}
 
+   is_general_query = group && ipv6_addr_any(group) ? true : false;
+
+   /* RFC2710+RFC3810 (MLDv1+MLDv2) require the multicast link layer
+* all-nodes destination address (ff02::1) for general queries
+*/
+   if (is_general_query && !ipv6_addr_is_ll_all_nodes(&ip6h->daddr)) {
+   err = -EINVAL;
+   goto out;
+   }
+
br_multicast_query_received(br, port, &br->ip6_querier,
!ipv6_addr_any(&ip6h->saddr), max_delay);
 
-- 
1.7.10.4

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

Re: [PATCH] hung_task : check the value of "sysctl_hung_task_timeout_sec"

[Liu hua]

on 2014/3/6 23:35, Paul Gortmaker wrote:
> On 14-03-06 02:19 AM, Liu hua wrote:
>> As sysctl_hung_task_timeout_sec is unsigned long, when this value is
>> larger then LONG_MAX, the function schedule_timeout_interruptible in
>> watchdog will return immediately without sleep :
>>
>> for example (in x86_64 platform):
>>
>> linux# echo 0x > /proc/sys/kernel/hung_task_timeout_secs
>>
>> [   66.798350] schedule_timeout: wrong timeout value ff06
>> [   66.800064] schedule_timeout: wrong timeout value ff06
>> [   66.801774] schedule_timeout: wrong timeout value ff06
>> [   66.803488] schedule_timeout: wrong timeout value ff06
>> [   66.805225] schedule_timeout: wrong timeout value ff06
>>
>> The screen was filled with "schedule_timeout: wrong timeout value
>> ff06" and the system stalled.
>>
>> So I do some check and correction in timeout_jiffies, to let the function
>> schedule_timeout_interruptible allways get the valid parameter.
>>
>> Signed-off-by: Liu Hua 
>> ---
>>  kernel/hung_task.c | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
>> index 06bb141..ef96650 100644
>> --- a/kernel/hung_task.c
>> +++ b/kernel/hung_task.c
>> @@ -186,7 +186,16 @@ static void check_hung_uninterruptible_tasks(unsigned 
>> long timeout)
>>  static unsigned long timeout_jiffies(unsigned long timeout)
>>  {
>>  /* timeout of 0 will disable the watchdog */
> 
> 
> You are breaking the above functionality/feature by declaring
> zero invalid.
> 
> Paul.
> --
> 
Actually the patch will disable the watchdog if the timeout is illegal(except 
0) for
schedule_timeout_interruptible.
I will make a new patch that disables the watchdog when the timeout is 0 or 
above
LONG_MAX without printing errors ?

What do you think?

Liu Hua
>> -return timeout ? timeout * HZ : MAX_SCHEDULE_TIMEOUT;
>> +if ((timeout == 0) || (timeout > MAX_SCHEDULE_TIMEOUT)) {
>> +pr_err("%s : wrong timeout value %lx\n",
>> +__func__, timeout);
>> +pr_err("Timeout value is set to MAX_SCHEDULE_TIMEOUT(%lx) 
>> now.\n",
>> +MAX_SCHEDULE_TIMEOUT);
>> +return MAX_SCHEDULE_TIMEOUT;
>> +}
>> +
>> +return (timeout * HZ) < MAX_SCHEDULE_TIMEOUT ?
>> +timeout * HZ : MAX_SCHEDULE_TIMEOUT;
>>  }
>>
>>  /*
>>
> 
> .
> 


--
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: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[Andy Lutomirski]

On Sun, Mar 9, 2014 at 5:16 PM, H. Peter Anvin  wrote:
> On 03/09/2014 12:47 AM, Stefani Seibold wrote:
>>
>> But let me ask an other question: Is the compat mode still needed
>> anymore?
>>
>> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
>> the __FIXADDR_TOP, there is no fix place for the VDSO page. Also in the
>> 32 bit emulation layer the address is not fix.
>>
>> So all applications can fail when try directly access the VDSO page with
>> a hard coded address 0xe000.
>>
>> IMHO this is broken. So an other solution is to remove the whole VDSO
>> compat code.
>>
>
> Lguest, Xen, OLPC and reservetop are corner cases.  My understanding is
> that at least one widely used distro actually cared about this, and
> Linus especially is adamant that "we don't break userspace."

OK, I did some research.  I think that the commit that fixed the glibc bug was:

commit 49ad572a70b8aeb91e57483a11dd1b77e31c4468
Author: Ulrich Drepper 
Date:   Sat Feb 28 17:56:22 2004 +

Update.

* elf/rtld.c (dl_main): Adjust l->l_ld of the vDSO by l->l_addr.
* sysdeps/generic/dl-sysdep.c (_dl_sysdep_start): Only set
GL(dl_sysinfo) if non-zero.

I don't think that the actual load address of the VDSO matters at all.
 Here's what I think is going on:

When the kernel is built, vdso32-int80.so looks like this (excerpted
from objdump -T):

DYNAMIC SYMBOL TABLE:
0420 gDF .text  0003  LINUX_2.5   __kernel_vsyscall
 gDO *ABS*    LINUX_2.5   LINUX_2.5
0410 gDF .text  0008  LINUX_2.5   __kernel_rt_sigreturn
0400 gDF .text  0009  LINUX_2.5   __kernel_sigreturn

When the kernel is run, the kernel "relocates" the vdso, generating
something more like:

DYNAMIC SYMBOL TABLE:
e420 gDF .text  0014  LINUX_2.5   __kernel_vsyscall
 gDO *ABS*    LINUX_2.5   LINUX_2.5
e410 gDF .text  0008  LINUX_2.5   __kernel_rt_sigreturn
e400 gDF .text  0009  LINUX_2.5   __kernel_sigreturn

That magic 0xe000 offset comes from VDSO_HIGH_BASE - VDSO_PRELINK,
and VDSO_PRELINK seems like an amazingly complicated way to say
"zero".

Before the fix, it looks like glibc couldn't handle a vdso that was
mapped in such a way that its ELF headers didn't match its actual
location.  Now it can.  This is borne out by this message:

commit d4f7a2c18e59e0304a1c733589ce14fc02fec1bd
Author: Jeremy Fitzhardinge 
Date:   Wed May 2 19:27:12 2007 +0200

[PATCH] i386: Relocate VDSO ELF headers to match mapped location with COMPAT

Some versions of libc can't deal with a VDSO which doesn't have its
ELF headers matching its mapped address.  COMPAT_VDSO maps the VDSO at
a specific system-wide fixed address.  Previously this was all done at
build time, on the grounds that the fixed VDSO address is always at
the top of the address space.  However, a hypervisor may reserve some
of that address space, pushing the fixmap address down.

I suspect that it's entirely safe to map the 32-bit vdso wherever the
hell we want, so long as it's relocated to match the actual mapping
address.  In principle it could even live outside the fixmap, as long
as the actual binary that gets run doesn't end up on top of it.

So... I propose that we get rid of all the madness.  Fix the vdso32
setup code to stop being insane.  That means: stop memcpying the vdso
image anywhere and get rid of all references to the magical and wrong
number "3".  Just map it wherever it needs to be mapped and relocate
the damn think *in place*.  If some RODATA crud gets in the way,
twiddle the protection bits as needed.  That means that all this
"vvars before vdso" nonsense can go away.

(Of course, I haven't the faintest idea what l_addr in glibc means.
If there was a way to arrange for l_addr to be zero, then maybe none
of this would matter.  Hmm, I wonder if just not relocating the vdso
at all would have the desired effect.  Anyone out there understand
glibc?)

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

[GIT PULL] namespaces fixes for 3.14-rcX

[Eric W. Biederman]

Linus,

Please pull the for-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-linus

   HEAD: d211f177b28ec070c25b3d0b960aa55f352f731f audit: Update kdoc for 
audit_send_reply and audit_list_rules_send

Starting with 3.14-rc1 the audit code is faulty (think oopses and races)
with respect to how it computes the network namespace of which socket to
reply to, and I happened to notice by chance when reading through the
code.

My efforts to get these fixes noticed by people who care about audit
seem to have landed on deaf ears, so since these are namespace related I
have put them in my tree.

My testing and the automated build bots don't find any problems with
these fixes.

Eric W. Biederman (3):
  audit: Use struct net not pid_t to remember the network namespce to reply 
in
  audit: Send replies in the proper network namespace.
  audit: Update kdoc for audit_send_reply and audit_list_rules_send

 include/linux/audit.h |3 ++-
 kernel/audit.c|   31 ---
 kernel/audit.h|2 +-
 kernel/auditfilter.c  |   10 +++---
 4 files changed, 26 insertions(+), 20 deletions(-)

Eric
--
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:

[inforbonus]

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixas...@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)
--
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:

[inforbonus]

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixas...@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)
--
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 net V2] vhost: net: switch to use data copy if pending DMAs exceed the limit

[Qin Chuanyu]

On 2014/3/7 13:28, Jason Wang wrote:

We used to stop the handling of tx when the number of pending DMAs
exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation
of both host and guest. But it was too aggressive in some cases, since
any delay or blocking of a single packet may delay or block the guest
transmission. Consider the following setup:

 +-++-+
 | VM1 || VM2 |
 +--+--++--+--+
|  |
 +--+--++--+--+
 | tap0|| tap1|
 +--+--++--+--+
|  |
 pfifo_fast   htb(10Mbit/s)
|  |
 +--+--+---+
 | bridge  |
 +--+--+
|
 pfifo_fast
|
 +-+
 | eth0|(100Mbit/s)
 +-+

- start two VMs and connect them to a bridge
- add an physical card (100Mbit/s) to that bridge
- setup htb on tap1 and limit its throughput to 10Mbit/s
- run two netperfs in the same time, one is from VM1 to VM2. Another is
   from VM1 to an external host through eth0.
- result shows that not only the VM1 to VM2 traffic were throttled but
   also the VM1 to external host through eth0 is also throttled somehow.

This is because the delay added by htb may lead the delay the finish
of DMAs and cause the pending DMAs for tap0 exceeds the limit
(VHOST_MAX_PEND). In this case vhost stop handling tx request until
htb send some packets. The problem here is all of the packets
transmission were blocked even if it does not go to VM2.

We can solve this issue by relaxing it a little bit: switching to use
data copy instead of stopping tx when the number of pending DMAs
exceed half of the vq size. This is safe because:

- The number of pending DMAs were still limited (half of the vq size)
- The out of order completion during mode switch can make sure that
   most of the tx buffers were freed in time in guest.

So even if about 50% packets were delayed in zero-copy case, vhost
could continue to do the transmission through data copy in this case.

Test result:

Before this patch:
VM1 to VM2 throughput is 9.3Mbit/s
VM1 to External throughput is 40Mbit/s
CPU utilization is 7%

After this patch:
VM1 to VM2 throughput is 9.3Mbit/s
Vm1 to External throughput is 93Mbit/s
CPU utilization is 16%

Completed performance test on 40gbe shows no obvious changes in both
throughput and cpu utilization with this patch.

The patch only solve this issue when unlimited sndbuf. We still need a
solution for limited sndbuf.

Cc: Michael S. Tsirkin 
Cc: Qin Chuanyu 
Signed-off-by: Jason Wang 
---
Changes from V1:
- Remove VHOST_MAX_PEND and switch to use half of the vq size as the limit
- Add cpu utilization in commit log
---
  drivers/vhost/net.c | 19 +++
  1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index a0fa5de..2925e9a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -38,8 +38,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
   * Using this limit prevents one virtqueue from starving others. */
  #define VHOST_NET_WEIGHT 0x8

-/* MAX number of TX used buffers for outstanding zerocopy */
-#define VHOST_MAX_PEND 128
  #define VHOST_GOODCOPY_LEN 256

  /*
@@ -345,7 +343,7 @@ static void handle_tx(struct vhost_net *net)
.msg_flags = MSG_DONTWAIT,
};
size_t len, total_len = 0;
-   int err;
+   int err, num_pends;
size_t hdr_size;
struct socket *sock;
struct vhost_net_ubuf_ref *uninitialized_var(ubufs);
@@ -366,13 +364,6 @@ static void handle_tx(struct vhost_net *net)
if (zcopy)
vhost_zerocopy_signal_used(net, vq);

-   /* If more outstanding DMAs, queue the work.
-* Handle upend_idx wrap around
-*/
-   if (unlikely((nvq->upend_idx + vq->num - VHOST_MAX_PEND)
- % UIO_MAXIOV == nvq->done_idx))
-   break;
-
head = vhost_get_vq_desc(&net->dev, vq, vq->iov,
 ARRAY_SIZE(vq->iov),
 &out, &in,
@@ -405,9 +396,13 @@ static void handle_tx(struct vhost_net *net)
break;
}

+   num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
+   (nvq->upend_idx - nvq->done_idx) :
+   (nvq->upend_idx + UIO_MAXIOV -
+nvq->done_idx);
+
zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
-  && (nvq->upend_idx + 1) % UIO_MAXIOV !=
- nvq->done_idx
+  && num_pends <= vq->num >> 1
   && vhost_net_tx_select_zcopy(net);

/* use msg_control to pass vhost zerocopy ubuf info to skb */


Reviewed-by

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

[Ben Hutchings]

On Mon, 2014-03-10 at 02:01 +0100, Sebastian Hesselbarth wrote:
> phy_ethtool_get_wol is a helper to get current WOL settings from
> a phy device. When using this helper on a PHY without .get_wol
> callback, struct ethtool_wolinfo is never set-up correctly and
> may contain misleading information about WOL status.
> 
> To fix this, always zero relevant fields of struct ethtool_wolinfo
> regardless of .get_wol callback availability.

I think it's the caller's responsibility to zero out struct
ethtool_wolinfo.  That is what ethtool_get_wol() does.

Maybe you could split ethtool_get_wol() like we did
ethtool_get_settings(), to support in-kernel invocation of ETHTOOL_GWOL?

Ben.

> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: David Miller 
> Cc: Florian Fainelli 
> Cc: net...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/net/phy/phy.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 19c9eca0ef26..62a7cd401e1c 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1092,6 +1092,7 @@ EXPORT_SYMBOL(phy_ethtool_set_wol);
>  
>  void phy_ethtool_get_wol(struct phy_device *phydev, struct ethtool_wolinfo 
> *wol)
>  {
> + wol->supported = wol->wolopts = 0;
>   if (phydev->drv->get_wol)
>   phydev->drv->get_wol(phydev, wol);
>  }

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Re: [RFC PATCH 6/8] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

On Sun, 2014-03-09 at 19:04 +0100, Rafael J. Wysocki wrote:
> On Sunday, March 09, 2014 11:50:37 PM Zhang Rui wrote:
> > On Wed, 2014-02-26 at 17:11 +0800, Zhang Rui wrote:
> > > Because of the growing demand for enumerating ACPI devices to platform 
> > > bus,
> > > this patch changes the code to enumerate ACPI devices with _HID/_CID to
> > > platform bus by default, unless the device already has a scan handler 
> > > attached.
> > > 
> > > Signed-off-by: Zhang Rui 
> > > ---
> > >  drivers/acpi/acpi_platform.c |   28 
> > >  drivers/acpi/scan.c  |   12 ++--
> > >  2 files changed, 6 insertions(+), 34 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> > > index dbfe49e..33376a9 100644
> > > --- a/drivers/acpi/acpi_platform.c
> > > +++ b/drivers/acpi/acpi_platform.c
> > > @@ -22,24 +22,6 @@
> > >  
> > >  ACPI_MODULE_NAME("platform");
> > >  
> > > -/*
> > > - * The following ACPI IDs are known to be suitable for representing as
> > > - * platform devices.
> > > - */
> > > -static const struct acpi_device_id acpi_platform_device_ids[] = {
> > > -
> > > - { "PNP0D40" },
> > > - { "ACPI0003" },
> > > - { "VPC2004" },
> > > - { "BCM4752" },
> > > -
> > > - /* Intel Smart Sound Technology */
> > > - { "INT33C8" },
> > > - { "80860F28" },
> > > -
> > > - { }
> > > -};
> > > -
> > >  /**
> > >   * acpi_create_platform_device - Create platform device for ACPI device 
> > > node
> > >   * @adev: ACPI device node to create a platform device for.
> > > @@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device 
> > > *adev,
> > >   kfree(resources);
> > >   return 1;
> > >  }
> > > -
> > > -static struct acpi_scan_handler platform_handler = {
> > > - .ids = acpi_platform_device_ids,
> > > - .attach = acpi_create_platform_device,
> > > -};
> > > -
> > > -void __init acpi_platform_init(void)
> > > -{
> > > - acpi_scan_add_handler(&platform_handler);
> > > -}
> > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > > index 5967338..61af32e 100644
> > > --- a/drivers/acpi/scan.c
> > > +++ b/drivers/acpi/scan.c
> > > @@ -2022,14 +2022,15 @@ static int acpi_scan_attach_handler(struct 
> > > acpi_device *device)
> > >   handler = acpi_scan_match_handler(hwid->id, &devid);
> > >   if (handler) {
> > >   ret = handler->attach(device, devid);
> > > - if (ret > 0) {
> > > + if (ret > 0)
> > >   device->handler = handler;
> > > - break;
> > > - } else if (ret < 0) {
> > > - break;
> > > - }
> > > + if (ret)
> > > + goto end;
> > >   }
> > >   }
> > > +end:
> > > + if (!list_empty(&device->pnp.ids) && !device->handler)
> > > + acpi_create_platform_device(device, NULL);
> > 
> > I just found a big problem in this proposal, which affects all the
> > optional scan handlers.
> 
> What do you mean by "optional"?  Such that can be compiled out?
> 
yes.

> > The problem is that, if we disable a scan handler, platform device nodes
> > would be created instead by the code above, because there is no scan
> > handler attached for those ACPI nodes.
> 
> If "we disable a scan handled" means "we compile it out", I'm not sure
> why creating platform devices for the device objects in question will
> be incorrect?
> 
take lpss scan handler and 80860F0A device for example,
acpi_lpss_create_device() would invoke lpss_uart_setup() first and then
register 80860F0A as a platform device.
if the lpss scan handler is compiled out, we would do nothing but
register a platform device directly, thus the dw8250_platform_driver
driver is still loaded, but probably breaks.

IMO, we should either have a full functional platform device (if the
scan handler is compiled in) or nothing (if the scan handler is compiled
out).

thanks,
rui
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [RFC PATCH 6/8] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

On Sun, 2014-03-09 at 19:04 +0100, Rafael J. Wysocki wrote:
> On Sunday, March 09, 2014 11:50:37 PM Zhang Rui wrote:
> > On Wed, 2014-02-26 at 17:11 +0800, Zhang Rui wrote:
> > > Because of the growing demand for enumerating ACPI devices to platform 
> > > bus,
> > > this patch changes the code to enumerate ACPI devices with _HID/_CID to
> > > platform bus by default, unless the device already has a scan handler 
> > > attached.
> > > 
> > > Signed-off-by: Zhang Rui 
> > > ---
> > >  drivers/acpi/acpi_platform.c |   28 
> > >  drivers/acpi/scan.c  |   12 ++--
> > >  2 files changed, 6 insertions(+), 34 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> > > index dbfe49e..33376a9 100644
> > > --- a/drivers/acpi/acpi_platform.c
> > > +++ b/drivers/acpi/acpi_platform.c
> > > @@ -22,24 +22,6 @@
> > >  
> > >  ACPI_MODULE_NAME("platform");
> > >  
> > > -/*
> > > - * The following ACPI IDs are known to be suitable for representing as
> > > - * platform devices.
> > > - */
> > > -static const struct acpi_device_id acpi_platform_device_ids[] = {
> > > -
> > > - { "PNP0D40" },
> > > - { "ACPI0003" },
> > > - { "VPC2004" },
> > > - { "BCM4752" },
> > > -
> > > - /* Intel Smart Sound Technology */
> > > - { "INT33C8" },
> > > - { "80860F28" },
> > > -
> > > - { }
> > > -};
> > > -
> > >  /**
> > >   * acpi_create_platform_device - Create platform device for ACPI device 
> > > node
> > >   * @adev: ACPI device node to create a platform device for.
> > > @@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device 
> > > *adev,
> > >   kfree(resources);
> > >   return 1;
> > >  }
> > > -
> > > -static struct acpi_scan_handler platform_handler = {
> > > - .ids = acpi_platform_device_ids,
> > > - .attach = acpi_create_platform_device,
> > > -};
> > > -
> > > -void __init acpi_platform_init(void)
> > > -{
> > > - acpi_scan_add_handler(&platform_handler);
> > > -}
> > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > > index 5967338..61af32e 100644
> > > --- a/drivers/acpi/scan.c
> > > +++ b/drivers/acpi/scan.c
> > > @@ -2022,14 +2022,15 @@ static int acpi_scan_attach_handler(struct 
> > > acpi_device *device)
> > >   handler = acpi_scan_match_handler(hwid->id, &devid);
> > >   if (handler) {
> > >   ret = handler->attach(device, devid);
> > > - if (ret > 0) {
> > > + if (ret > 0)
> > >   device->handler = handler;
> > > - break;
> > > - } else if (ret < 0) {
> > > - break;
> > > - }
> > > + if (ret)
> > > + goto end;
> > >   }
> > >   }
> > > +end:
> > > + if (!list_empty(&device->pnp.ids) && !device->handler)
> > > + acpi_create_platform_device(device, NULL);
> > 
> > I just found a big problem in this proposal, which affects all the
> > optional scan handlers.
> 
> What do you mean by "optional"?  Such that can be compiled out?
> 
yes.

> > The problem is that, if we disable a scan handler, platform device nodes
> > would be created instead by the code above, because there is no scan
> > handler attached for those ACPI nodes.
> 
> If "we disable a scan handled" means "we compile it out", I'm not sure
> why creating platform devices for the device objects in question will
> be incorrect?
> 
take lpss scan handler and 80860F0A device for example,
acpi_lpss_create_device() would invoke lpss_uart_setup() first and then
register 80860F0A as a platform device.
if the lpss scan handler is compiled out, we would do nothing but
register a platform device directly, thus the dw8250_platform_driver
driver is still loaded, but probably breaks.

IMO, we should either have a full functional platform device (if the
scan handler is compiled in) or nothing (if the scan handler is compiled
out).

thanks,
rui
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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/

[PATCH v2] drm/fb-helper: Do the 'max_conn_count' zero check

[Xiubo Li]

Since we cannot make sure the 'max_conn_count' will always be none
zero from the users, and then if max_conn_count equals to zero, the
kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the 'max_conn_count' zero check
in the front of drm_fb_helper_init().

Signed-off-by: Xiubo Li 
CC: Jani Nikula 
---
 drivers/gpu/drm/drm_fb_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3d13ca6e2..a0d286c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -514,6 +514,9 @@ int drm_fb_helper_init(struct drm_device *dev,
struct drm_crtc *crtc;
int i;
 
+   if (!max_conn_count)
+   return -EINVAL;
+
fb_helper->dev = dev;
 
INIT_LIST_HEAD(&fb_helper->kernel_fb_list);
-- 
1.8.4


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

Re: [GIT PULL] x86 fixes for v3.14-rc6 - bad patch dropped

[H. Peter Anvin]

On 03/09/2014 06:51 PM, Linus Torvalds wrote:
> On Sun, Mar 9, 2014 at 5:15 PM, H. Peter Anvin  wrote:
>>
>> The same collection of fixes except the broken NMI patch dropped.  I
>> will send a fixed version of that plus Suresh' FPU fix in a few days,
>> to get them some testing, plus I will be on a trip (part of why I got
>> unduly rushed this past Friday.  Sorry again for that.)
> 
> I already pulled the broken one, and had actually pushed it out in
> that broken format, which was so upsetting. Normally I tend to delay
> pushing things out until I've done my compile tests, but I had
> stupidly thought I didn't need to that time.
> 

So I see.  Thanks and sorry again.

-hpa


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

[Guenter Roeck]

On 03/06/2014 01:36 AM, Marc van der Wal wrote:

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 


Reviewed-by: Guenter Roeck 


--
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: [f2fs-dev] [PATCH 1/5] f2fs: update start nid only once each circle

[Jaegeuk Kim]

Hi all,

I'll handle them all by myself.
Thank you for the contribution. :)

2014-03-10 (월), 09:32 +0800, Gu Zheng:
> On 03/08/2014 07:46 PM, Chao Yu wrote:
> 
> > Hi Gu,
> > 
> >> -Original Message-
> >> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> >> Sent: Friday, March 07, 2014 6:43 PM
> >> To: Kim
> >> Cc: linux-kernel; f2fs
> >> Subject: [f2fs-dev] [PATCH 1/5] f2fs: update start nid only once each 
> >> circle
> >>
> >>
> >> Signed-off-by: Gu Zheng 
> > 
> > Reviewed-by: Chao Yu 
> > 
> >> ---
> >>  fs/f2fs/node.c |6 +-
> >>  1 files changed, 5 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> >> index 8c14110..9653096 100644
> >> --- a/fs/f2fs/node.c
> >> +++ b/fs/f2fs/node.c
> >> @@ -1875,11 +1875,15 @@ void destroy_node_manager(struct f2fs_sb_info *sbi)
> >>while ((found = __gang_lookup_nat_cache(nm_i,
> >>nid, NATVEC_SIZE, natvec))) {
> >>unsigned idx;
> >> +
> >> +  nid = nat_get_nid(natvec[found - 1]) + 1;
> >> +
> >>for (idx = 0; idx < found; idx++) {
> >>struct nat_entry *e = natvec[idx];
> > 
> > Could we replace argument 'e' with 'natvec[idx]'? then we could remove 'e' 
> > and
> > brace here.
> 
> Agree. More neat with this cleanup.
> 
> Regards,
> Gu
> 
> > 
> > Thanks.
> > 
> >> -  nid = nat_get_nid(e) + 1;
> >> +
> >>__del_from_nat_cache(nm_i, e);
> >>}
> >> +
> >>}
> >>f2fs_bug_on(nm_i->nat_cnt);
> >>write_unlock(&nm_i->nat_tree_lock);
> >> --
> >> 1.7.7
> >>
> >>
> >> --
> >> Subversion Kills Productivity. Get off Subversion & Make the Move to 
> >> Perforce.
> >> With Perforce, you get hassle-free workflows. Merge that actually works.
> >> Faster operations. Version large binaries.  Built-in WAN optimization and 
> >> the
> >> freedom to use Git, Perforce or both. Make the move to Perforce.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> >> ___
> >> Linux-f2fs-devel mailing list
> >> linux-f2fs-de...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> > 
> > 
> 
> 
> --
> 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/

-- 
Jaegeuk Kim
Samsung

--
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] shdma: add R-Car Audio DMAC peri peri driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

Add support Audio DMAC peri peri driver
for Renesas R-Car Gen2 SoC, using 'shdma-base'
DMA driver framework.

Signed-off-by: Kuninori Morimoto 
---
v2 -> v3

 - remove error message when devm_kzalloc() was failed

 drivers/dma/sh/Kconfig |6 +
 drivers/dma/sh/Makefile|1 +
 drivers/dma/sh/rcar-audmapp.c  |  321 
 include/linux/platform_data/dma-rcar-audmapp.h |   34 +++
 4 files changed, 362 insertions(+)
 create mode 100644 drivers/dma/sh/rcar-audmapp.c
 create mode 100644 include/linux/platform_data/dma-rcar-audmapp.h

diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index dadd9e01..b4c8138 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -29,6 +29,12 @@ config RCAR_HPB_DMAE
help
  Enable support for the Renesas R-Car series DMA controllers.
 
+config RCAR_AUDMAC_PP
+   tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support"
+   depends on SH_DMAE_BASE
+   help
+ Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral 
controllers.
+
 config SHDMA_R8A73A4
def_bool y
depends on ARCH_R8A73A4 && SH_DMAE != n
diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
index e856af2..1ce88b2 100644
--- a/drivers/dma/sh/Makefile
+++ b/drivers/dma/sh/Makefile
@@ -7,3 +7,4 @@ endif
 shdma-objs := $(shdma-y)
 obj-$(CONFIG_SUDMAC) += sudmac.o
 obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
+obj-$(CONFIG_RCAR_AUDMAC_PP) += rcar-audmapp.o
diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
new file mode 100644
index 000..884ad3b80
--- /dev/null
+++ b/drivers/dma/sh/rcar-audmapp.c
@@ -0,0 +1,321 @@
+/*
+ * drivers/dma/sh/rcar-audmapp.c
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Kuninori Morimoto 
+ *
+ * based on the drivers/dma/sh/shdma.c
+ *
+ * Copyright (C) 2011-2012 Guennadi Liakhovetski 
+ * Copyright (C) 2009 Nobuhiro Iwamatsu 
+ * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * DMA register
+ */
+#define PDMASAR0x00
+#define PDMADAR0x04
+#define PDMACHCR   0x0c
+
+/* PDMACHCR */
+#define PDMACHCR_DE(1 << 0)
+
+#define AUDMAPP_MAX_CHANNELS   29
+
+/* Default MEMCPY transfer size = 2^2 = 4 bytes */
+#define LOG2_DEFAULT_XFER_SIZE 2
+#define AUDMAPP_SLAVE_NUMBER   256
+#define AUDMAPP_LEN_MAX(16 * 1024 * 1024)
+
+struct audmapp_chan {
+   struct shdma_chan shdma_chan;
+   struct audmapp_slave_config *config;
+   void __iomem *base;
+};
+
+struct audmapp_device {
+   struct shdma_dev shdma_dev;
+   struct audmapp_pdata *pdata;
+   struct device *dev;
+   void __iomem *chan_reg;
+};
+
+#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan)
+#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device,\
+ struct audmapp_device, shdma_dev.dma_dev)
+
+static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg)
+{
+   struct audmapp_device *audev = to_dev(auchan);
+   struct device *dev = audev->dev;
+
+   dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data);
+
+   iowrite32(data, auchan->base + reg);
+}
+
+static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg)
+{
+   return ioread32(auchan->base + reg);
+}
+
+static void audmapp_halt(struct shdma_chan *schan)
+{
+   struct audmapp_chan *auchan = to_chan(schan);
+   int i;
+
+   audmapp_write(auchan, 0, PDMACHCR);
+
+   for(i = 0; i < 1024; i++) {
+   if (0 == audmapp_read(auchan, PDMACHCR))
+   return;
+   udelay(1);
+   }
+}
+
+static void audmapp_start_xfer(struct shdma_chan *schan,
+  struct shdma_desc *sdecs)
+{
+   struct audmapp_chan *auchan = to_chan(schan);
+   struct audmapp_device *audev = to_dev(auchan);
+   struct audmapp_slave_config *cfg = auchan->config;
+   struct device *dev = audev->dev;
+   u32 chcr = cfg->chcr | PDMACHCR_DE;
+
+   dev_dbg(dev, "src/dst/chcr = %x/%x/%x\n",
+   cfg->src, cfg->dst, cfg->chcr);
+
+   audmapp_write(auchan, cfg->src, PDMASAR);
+   audmapp_write(auchan, cfg->dst, PDMADAR);
+   audmapp_write(auchan, chcr, PDMACHCR);
+}
+
+static struct audmapp_slave_config *
+audmapp_find_slave(struct audmapp_chan *auchan, int slave_id)
+{
+   struct audmapp_device *audev

Re: [RFC PATCH 2/8] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

On Sun, 2014-03-09 at 18:49 +0100, Rafael J. Wysocki wrote:
> On Sunday, March 09, 2014 01:29:30 PM Zhang Rui wrote:
> > On Fri, 2014-03-07 at 02:44 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, February 26, 2014 05:11:08 PM Zhang Rui wrote:
> > > > +
> > > > +static int __init acpi_pnp_scan_handler_attach(struct acpi_device 
> > > > *adev,
> > > 
> > > This can't be __init.
> > > 
> > > > +   const struct acpi_device_id *id)
> > > > +{
> > > > +   return 1;
> > > > +}
> > > > +
> > > > +static int __init acpi_pnp_scan_handler_match(char *devid, char 
> > > > *handlerid)
> > > 
> > > And this too.
> > > 
> > > > +{
> > > > +   int i;
> > > > +
> > > > +   if (!ispnpidacpi(devid))
> > > > +   return 0;
> > > > +
> > > > +   if (memcmp(devid, handlerid, 3))
> > > > +   return 0;
> > > > +
> > > > +for (i = 3; i < 7; i++) {
> > > > +if (handlerid[i] != 'X' &&
> > > > +   toupper(devid[i]) != toupper(handlerid[i]))
> > > > +return 0;
> > > > +}
> > > > +   return 1;
> > > > +}
> > > > +
> > > > +static struct acpi_scan_handler pnpacpi_handler __initdata = {
> > > 
> > > And this cannot be __initdata, because the list of ACPI scan handlers is
> > > walked during hotplug.
> > > 
> > right. will update it in next version.
> > 
> > > > +   .ids = acpi_pnp_device_ids,
> > > > +   .match = acpi_pnp_scan_handler_match,
> > > > +   .attach = acpi_pnp_scan_handler_attach,
> > > > +};
> > > > +
> > > > +void __init acpi_pnp_init(void)
> > > > +{
> > > > +   acpi_scan_add_handler(&pnpacpi_handler);
> > > > +}
> > > > +
> > > > +static acpi_status __init pnpacpi_add_device_handler(acpi_handle 
> > > > handle,
> > > > +u32 lvl, void 
> > > > *context,
> > > > +void **rv)
> > > > +{
> > > > +   struct acpi_device *device;
> > > > +
> > > > +   if (acpi_bus_get_device(handle, &device))
> > > > +   return AE_CTRL_DEPTH;
> > > > +   if (device->handler == &pnpacpi_handler)
> > > > +   pnpacpi_add_device(device);
> > > 
> > > Why don't you do that in acpi_pnp_scan_handler_attach() ?
> > > 
> > because the PNP bus is not ready at that time.
> 
> Do you mean it hasn't been initialized yet?
> 
right.
both acpi_init() and pnp_init() are subsys_initcall, but pnp_init() is
invoked later because of the link order.

> But we can initialize it before the scan handler initialization, can't we?
> 
well, I'm not sure, here is what I get from drivers/Makefile
obj-$(CONFIG_ACPI)  += acpi/
obj-$(CONFIG_SFI)   += sfi/
# PnP must come after ACPI since it will eventually need to check ifacpi
# was used and do nothing if so
obj-$(CONFIG_PNP)   += pnp/

this comment was added long time ago and I do not know the background of
it, maybe Len knows the reason of this?

thanks,
rui

--
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][RESENT] dma: add R-Car Audio DMAC peri peri driver

[Kuninori Morimoto]

Hi Joe

> > diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
> []
> > +static int audmapp_chan_probe(struct platform_device *pdev,
> > + struct audmapp_device *audev, int id)
> > +{
> []
> > +   auchan = devm_kzalloc(dev, sizeof(struct audmapp_chan), GFP_KERNEL);
> > +   if (!auchan) {
> > +   dev_err(dev, "No free memory for allocating dma channels!\n");
> 
> Unnecessary OOM as the alloc has a generic OOM
> and a dump_stack()
> 
> []
> > +static int audmapp_probe(struct platform_device *pdev)
> > +{
> []
> > +   audev = devm_kzalloc(&pdev->dev, sizeof(struct audmapp_device),
> > +GFP_KERNEL);
> > +   if (!audev) {
> > +   dev_err(&pdev->dev, "Not enough memory\n");
> 
> here too

Thank you.
will fix in v3
--
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

[Guenter Roeck]

On 03/05/2014 02:57 AM, Markus Mayer wrote:

Use more the applicable ARCH_BCM_MOBILE option instead of ARCH_BCM as
dependency for bcm_kona_wdt.c.

Signed-off-by: Markus Mayer 


Acked-by: Guenter Roeck 


--
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] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR check

[li.xi...@freescale.com]

> Subject: Re: [PATCH] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR
> check
> 
> On Thu, 06 Mar 2014, Xiubo Li  wrote:
> > Since we cannot make sure the 'max_conn_count' will always be none
> > zero from the users, and then if max_conn_count equals to zero, the
> > kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16).
> >
> > So this patch fix this via doing the zero pionter check of it.
> 
> Please just add a check for max_conn_count == 0 up front and handle it.
> 
> BR,
> Jani.
> 

Yes, that's one better choice.
See the next version please.

Thanks very much!

--
Best Regards,
Xiubo 

> 
> >
> > Signed-off-by: Xiubo Li 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> > index 3d13ca6e2..c6680ef 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -536,7 +536,7 @@ int drm_fb_helper_init(struct drm_device *dev,
> > sizeof(struct drm_connector *),
> > GFP_KERNEL);
> >
> > -   if (!fb_helper->crtc_info[i].mode_set.connectors)
> > +   if 
> > (ZERO_OR_NULL_PTR(fb_helper->crtc_info[i].mode_set.connectors))
> > goto out_free;
> > fb_helper->crtc_info[i].mode_set.num_connectors = 0;
> > }
> > --
> > 1.8.4
> >
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Jani Nikula, 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] zram: use scnprintf() in attrs show() methods

[Minchan Kim]

On Sun, Mar 09, 2014 at 10:27:08PM +0300, Sergey Senozhatsky wrote:
> sysfs.txt documentation lists the following requirements:
> 
>  - The buffer will always be PAGE_SIZE bytes in length. On i386, this
>is 4096.
> 
>  - show() methods should return the number of bytes printed into the
>buffer. This is the return value of scnprintf().
> 
>  - show() should always use scnprintf().
> 
> Use scnprintf() in show() functions.
> 
> Signed-off-by: Sergey Senozhatsky 

Acked-by: Minchan Kim 

> ---
>  drivers/block/zram/zcomp.c|  8 +---
>  drivers/block/zram/zram_drv.c | 12 ++--
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 92a83df..ffcaff7 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -274,12 +274,14 @@ ssize_t zcomp_available_show(const char *comp, char 
> *buf)
>  
>   while (backends[i]) {
>   if (sysfs_streq(comp, backends[i]->name))
> - sz += sprintf(buf + sz, "[%s] ", backends[i]->name);
> + sz += scnprintf(buf + sz, PAGE_SIZE - sz - 2,
> + "[%s] ", backends[i]->name);
>   else
> - sz += sprintf(buf + sz, "%s ", backends[i]->name);
> + sz += scnprintf(buf + sz, PAGE_SIZE - sz - 2,
> + "%s ", backends[i]->name);
>   i++;
>   }
> - sz += sprintf(buf + sz, "\n");
> + sz += scnprintf(buf + sz, PAGE_SIZE - sz, "\n");
>   return sz;
>  }
>  
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 7631ef0..e6ff420 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -47,7 +47,7 @@ static ssize_t zram_attr_##name##_show(struct device *d,
> \
>   struct device_attribute *attr, char *b) \
>  {\
>   struct zram *zram = dev_to_zram(d); \
> - return sprintf(b, "%llu\n", \
> + return scnprintf(b, PAGE_SIZE, "%llu\n",\
>   (u64)atomic64_read(&zram->stats.name)); \
>  }\
>  static struct device_attribute dev_attr_##name = \
> @@ -68,7 +68,7 @@ static ssize_t disksize_show(struct device *dev,
>  {
>   struct zram *zram = dev_to_zram(dev);
>  
> - return sprintf(buf, "%llu\n", zram->disksize);
> + return scnprintf(buf, PAGE_SIZE, "%llu\n", zram->disksize);
>  }
>  
>  static ssize_t initstate_show(struct device *dev,
> @@ -81,7 +81,7 @@ static ssize_t initstate_show(struct device *dev,
>   val = init_done(zram);
>   up_read(&zram->init_lock);
>  
> - return sprintf(buf, "%u\n", val);
> + return scnprintf(buf, PAGE_SIZE, "%u\n", val);
>  }
>  
>  static ssize_t orig_data_size_show(struct device *dev,
> @@ -89,7 +89,7 @@ static ssize_t orig_data_size_show(struct device *dev,
>  {
>   struct zram *zram = dev_to_zram(dev);
>  
> - return sprintf(buf, "%llu\n",
> + return scnprintf(buf, PAGE_SIZE, "%llu\n",
>   (u64)(atomic64_read(&zram->stats.pages_stored)) << PAGE_SHIFT);
>  }
>  
> @@ -105,7 +105,7 @@ static ssize_t mem_used_total_show(struct device *dev,
>   val = zs_get_total_size_bytes(meta->mem_pool);
>   up_read(&zram->init_lock);
>  
> - return sprintf(buf, "%llu\n", val);
> + return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
>  }
>  
>  static ssize_t max_comp_streams_show(struct device *dev,
> @@ -118,7 +118,7 @@ static ssize_t max_comp_streams_show(struct device *dev,
>   val = zram->max_comp_streams;
>   up_read(&zram->init_lock);
>  
> - return sprintf(buf, "%d\n", val);
> + return scnprintf(buf, PAGE_SIZE, "%d\n", val);
>  }
>  
>  static ssize_t max_comp_streams_store(struct device *dev,
> -- 
> 1.9.0.477.g83111a0
> 
> --
> 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/

-- 
Kind regards,
Minchan Kim
--
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: add a pre-check of net_ns in sk_change_net()

[Gu Zheng]

We do not need to switch the net_ns if the target net_ns the same
as the current one, so here we add a pre-check of net_ns to avoid
this as David suggested.

Signed-off-by: Gu Zheng 
---
 include/net/sock.h |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 5c3f7c3..9678569 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2252,8 +2252,12 @@ void sock_net_set(struct sock *sk, struct net *net)
  */
 static inline void sk_change_net(struct sock *sk, struct net *net)
 {
-   put_net(sock_net(sk));
-   sock_net_set(sk, hold_net(net));
+   struct net *current_net = sock_net(sk);
+
+   if (!net_eq(current_net, net)) {
+   put_net(current_net);
+   sock_net_set(sk, hold_net(net));
+   }
 }
 
 static inline struct sock *skb_steal_sock(struct sk_buff *skb)
-- 
1.7.7


--
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] zram: propagate error to user

[Minchan Kim]

Hello Sergey,

On Sun, Mar 09, 2014 at 07:58:51PM +0300, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> On (03/07/14 18:51), Minchan Kim wrote:
> > Hello Sergey!
> > 
> > On Fri, Mar 07, 2014 at 12:20:45PM +0300, Sergey Senozhatsky wrote:
> > > On (03/07/14 10:56), Minchan Kim wrote:
> > > > When we initialized zcomp with single, we couldn't change
> > > > max_comp_streams without zram reset but current interface doesn't
> > > > show any error to user and even it changes max_comp_streams's value
> > > > without any effect so it would make user very confusing.
> > > > 
> > > > This patch prevents max_comp_streams's change when zcomp was
> > > > initialized as single zcomp and emit the error to user(ex, echo).
> > > > 
> > > > Signed-off-by: Minchan Kim 
> > > > ---
> > > >  Documentation/blockdev/zram.txt |  9 +
> > > >  drivers/block/zram/zcomp.c  | 10 +-
> > > >  drivers/block/zram/zcomp.h  |  4 ++--
> > > >  drivers/block/zram/zram_drv.c   | 15 +++
> > > >  4 files changed, 23 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/Documentation/blockdev/zram.txt 
> > > > b/Documentation/blockdev/zram.txt
> > > > index 2604ffed51db..0595c3f56ccf 100644
> > > > --- a/Documentation/blockdev/zram.txt
> > > > +++ b/Documentation/blockdev/zram.txt
> > > > @@ -37,10 +37,11 @@ Note:
> > > >  In order to enable compression backend's multi stream support 
> > > > max_comp_streams
> > > >  must be initially set to desired concurrency level before ZRAM device
> > > >  initialisation. Once the device initialised as a single stream 
> > > > compression
> > > > -backend (max_comp_streams equals to 0) changing the value of 
> > > > max_comp_streams
> > > > -will not take any effect, because single stream compression backend 
> > > > implemented
> > > > -as a special case and does not support dynamic max_comp_streams. Only 
> > > > multi
> > > > -stream backend supports dynamic max_comp_streams adjustment.
> > > > +backend (max_comp_streams equals to 1), you will see error if you try 
> > > > to change
> > > > +the value of max_comp_streams because single stream compression backend
> > > > +implemented as a special case by lock overhead issue and does not 
> > > > support
> > > > +dynamic max_comp_streams. Only multi stream backend supports dynamic
> > > > +max_comp_streams adjustment.
> > > >  
> > > >  3) Select compression algorithm
> > > > Using comp_algorithm device attribute one can see available and
> > > > diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> > > > index 92a83df40a27..15fe6a27781b 100644
> > > > --- a/drivers/block/zram/zcomp.c
> > > > +++ b/drivers/block/zram/zcomp.c
> > > > @@ -152,7 +152,7 @@ static void zcomp_strm_multi_release(struct zcomp 
> > > > *comp, struct zcomp_strm *zstr
> > > >  }
> > > >  
> > > >  /* change max_strm limit */
> > > > -static int zcomp_strm_multi_set_max_streams(struct zcomp *comp, int 
> > > > num_strm)
> > > > +static bool zcomp_strm_multi_set_max_streams(struct zcomp *comp, int 
> > > > num_strm)
> > > >  {
> > > > struct zcomp_strm_multi *zs = comp->stream;
> > > > struct zcomp_strm *zstrm;
> > > > @@ -171,7 +171,7 @@ static int zcomp_strm_multi_set_max_streams(struct 
> > > > zcomp *comp, int num_strm)
> > > > zs->avail_strm--;
> > > > }
> > > > spin_unlock(&zs->strm_lock);
> > > > -   return 0;
> > > > +   return true;
> > > >  }
> > > >  
> > > >  static void zcomp_strm_multi_destroy(struct zcomp *comp)
> > > > @@ -231,10 +231,10 @@ static void zcomp_strm_single_release(struct 
> > > > zcomp *comp,
> > > > mutex_unlock(&zs->strm_lock);
> > > >  }
> > > >  
> > > > -static int zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
> > > > num_strm)
> > > > +static bool zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
> > > > num_strm)
> > > >  {
> > > > /* zcomp_strm_single support only max_comp_streams == 1 */
> > > > -   return -ENOTSUPP;
> > > > +   return 0;
> > > >  }
> > > 
> > > IMHO, -ENOTSUPP for unsupported operation fits better than `false'.
> > > yes, currently there are only two possible returns:
> > >   0 -- success
> > >   -ENOTSUPP - not supported operation
> > > 
> > > though, we can extend functions later and return additional codes, other
> > > than `false' and `true'.
> > 
> > Thing to expose to user isn't true and false but EINVAL.
> > 
> 
> sure. I mean we can return actual zcomp_set_max_streams() error (if any)
> back to user from max_comp_streams_store():
> 
>   [..]
>   ret = zcomp_set_max_streams(...);
>   [..]
>   return ret;
> 
> > > 
> > > for example, -E2BIG if user requested extremly large number of streams,
> > > like 5000 streams.
> > 
> > I'm not sure it's right example for E2BIG.
> > When I read the comment, it says "argument list too long".
> > Anyway, when I tried ENOTSUPP, echo doesn't show meaningful error to user
> > and I dont' know it's casual 

Re: [PATCH v2 1/2] i2c: add DMA support for freescale i2c driver

[Shawn Guo]

On Thu, Mar 06, 2014 at 12:57:42PM +0100, Marek Vasut wrote:
> On Thursday, March 06, 2014 at 06:02:03 AM, Yao Yuan wrote:
> > On Thu, March 06, 2014 at 12:44:14 PM, Marek Vasut wrote:
> > > On Thursday, March 06, 2014 at 05:36:14 AM, Yao Yuan wrote:
> > > > On Thu, March 06, 2014 at 11:23:50 AM, Marek Vasut wrote:
> > > > > On Wednesday, March 05, 2014 at 07:52:31 AM, Yuan Yao wrote:
> > > > > > Add dma support for i2c. This function depend on DMA driver.
> > > > > > You can turn on it by write both the dmas and dma-name properties
> > > > > > in dts node.
> > > > > > 
> > > > > > Signed-off-by: Yuan Yao 
> > > > > > ---
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > @@ -601,6 +826,7 @@ static int i2c_imx_probe(struct
> > > > > > platform_device
> > > > > 
> > > > > *pdev)
> > > > > 
> > > > > > void __iomem *base;
> > > > > > int irq, ret;
> > > > > > u32 bitrate;
> > > > > > 
> > > > > > +   u32 phy_addr;
> > > > > > 
> > > > > > dev_dbg(&pdev->dev, "<%s>\n", __func__);
> > > > > > 
> > > > > > @@ -611,6 +837,7 @@ static int i2c_imx_probe(struct
> > > > > > platform_device
> > > > > 
> > > > > *pdev)
> > > > > 
> > > > > > }
> > > > > > 
> > > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > > > 
> > > > > > +   phy_addr = res->start;
> > > > > 
> > > > > Uh ... Shawn, I really think I am lost here. Don't you need to map
> > > > > this memory before you can use it for DMA ? The DMA mapping function
> > > > > should give you the physical address and is the right way to go
> > > > > about this instead of pulling the address from here, no ?
> > > > > 
> > > > > I might be wrong here, I am rather uncertain, so please help me out.
> > > > > Thanks!
> > > > 
> > > > Hi, Marek, Thanks for your suggestion.
> > > > Here you can review the code in include/linux/ioport.h The
> > > > resource->start describes the entity on the CPU bus as a starting
> > > > physical address. So I thinks it can used for dma directly.
> > > 
> > > This doesn't feel right for some reason. If this is a register area, you
> > > should
> > > ioremap() it. If it's a memory area you do DMA to/from, you need to make
> > > sure you correctly flush/invalidate caches and properly handle the
> > > effects the write buffer might have. But I have a feeling you actually do
> > > DMA to/from register space here ?
> > 
> > Yes, It's a register area. But I don't know why I should ioremap() it? It's
> > a bus address and DMA can use it directly. Is there some problem for my
> > understanding ?
> 
> I am not too sure here, thus I am poking someone who can clearly answer this.

There is already a devm_ioremap_resource() call in the existing code for
CPU to access registers in virtual address.  And my understanding on
Yuan's patch is that he needs the physical address of I2C DATA register
for DMA from/to the controller.

Shawn

--
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: [GIT PULL] x86 fixes for v3.14-rc6 - bad patch dropped

[Linus Torvalds]

On Sun, Mar 9, 2014 at 5:15 PM, H. Peter Anvin  wrote:
>
> The same collection of fixes except the broken NMI patch dropped.  I
> will send a fixed version of that plus Suresh' FPU fix in a few days,
> to get them some testing, plus I will be on a trip (part of why I got
> unduly rushed this past Friday.  Sorry again for that.)

I already pulled the broken one, and had actually pushed it out in
that broken format, which was so upsetting. Normally I tend to delay
pushing things out until I've done my compile tests, but I had
stupidly thought I didn't need to that time.

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: 3.13.?: Strange / dangerous fan policy...

[Manuel Krause]

nks 
to -> ../../devices/virtual/thermal/


I've listed the directories in sections of cooling_devices and 
thermal_zones separately for each bad/good kernel. For Emailing 
purposes only. You can merge them into a spreadsheet for your 
evaluation on your own. I've left out reporting some subdirs and 
subdir's values that _really_ didn't seem to need attention.


Also, I've had collected the #sensors output for each readout, 
having reproduced nearly the same workload, represented by the 
"Fan speed" (thermal_zone4==FDTZ).


And I've done my very best to not produce typos or c&p errors.


 3.13.5 -- 20140309 -- 20:52 -- bad
=
dir |-
 /type   /cur_state  /max_state
cooling_device0  Processor0  10
cooling_device1  Processor0  10
cooling_device2  Fan  0   1
cooling_device3  Fan  1   1
cooling_device4  Fan  0   1
cooling_device5  Fan  0   1
cooling_device6  Fan  0   1
cooling_device7  LCD  0  24

 3.12.13 -- 20140310 -- 00:26 -- good
==
dir |-
 /type   /cur_state  /max_state
cooling_device0  Processor0  10
cooling_device1  Processor0  10
cooling_device2  Fan  0   1
cooling_device3  Fan  1   1
cooling_device4  Fan  1   1
cooling_device5  Fan  1   1
cooling_device6  Fan  1   1
cooling_device7  LCD  0  24


 3.13.5 -- 20140309 -- 20:52 -- bad
=
dir  |-
  /passive /temp  |- /cdev?_  /trip_   /trip_
  trip_point_   point_
  point?_temp   ?_type
thermal_zone0  068000   ?=0n.a.   256000   critical
thermal_zone1   n.a.7 |-
?=0   6   11   critical
?=1   5   107000   passive
?=2   49   active
?=3   375000   active
?=4   255000   active
?=5   145000   active
?=6   13   active
thermal_zone2   n.a.54000 |-
?=0   1   105000   critical
?=1   195000   passive
thermal_zone3   n.a.25800 |-
?=0   1   11   critical
?=1   16   passive
thermal_zone4  058000   ?=0n.a.   11   critical


 3.12.13 -- 20140310 -- 00:26 -- good
==
dir  |-
  /passive /temp  |- /cdev?_  /trip_   /trip_
  trip_point_   point_
  point?_temp   ?_type
thermal_zone0  05   ?=0n.a.   256000   critical
thermal_zone1   n.a.7 |-
?=0   1   11   critical
?=1   1   107000   passive
?=2   29   active
?=3   367000   active
?=4   455000   active
?=5   545000   active
?=6   63   active
thermal_zone2   n.a.53000 |-
?=0   1   105000   critical
?=1   195000   passive
thermal_zone3   n.a.25600 |-
?=0   1   11   critical
?=1   16   passive
thermal_zone4  058000   ?=0n.a.   11   critical

---
Legend here:
   /type  is always  acpitz
   /mode enabled
   /policy   step_wise

  - from kernel ACPI initialisation: thermal_zone0==DTSZ,
 thermal_zone1==CPUZ, thermal_zone2==SKNZ,
 thermal_zone3==BATZ, thermal_zone4==FDTZ
  - n.a. means  file or value is not available
___
Legend in general:
 /power/control  is always  auto
     /power/runtime_status  unsupported
 /uevent''==empty



 3.13.5 -- 20140309 -- 20:52 -- bad
=
# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:+68.0°C  (crit = +256.0°C)
temp2:+70.0°C  (crit = +110.0°C)
temp3:+54.0°C  (crit = +105.0°C)
temp4:+25.8°C  (crit = +110.0°C)
temp5:+58.0°C  (crit = +110.0°C)

coretemp-isa-
Adapter: ISA adapter
Core 0:   +66.0°C  

Re: [PATCH v2][RESENT] dma: add R-Car Audio DMAC peri peri driver

[Joe Perches]

On Sun, 2014-03-09 at 18:34 -0700, Kuninori Morimoto wrote:
> Add support Audio DMAC peri peri driver
> for Renesas R-Car Gen2 SoC, using 'shdma-base'
> DMA driver framework.

Trivial notes:

> diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
[]
> +static int audmapp_chan_probe(struct platform_device *pdev,
> +   struct audmapp_device *audev, int id)
> +{
[]
> + auchan = devm_kzalloc(dev, sizeof(struct audmapp_chan), GFP_KERNEL);
> + if (!auchan) {
> + dev_err(dev, "No free memory for allocating dma channels!\n");

Unnecessary OOM as the alloc has a generic OOM
and a dump_stack()

[]
> +static int audmapp_probe(struct platform_device *pdev)
> +{
[]
> + audev = devm_kzalloc(&pdev->dev, sizeof(struct audmapp_device),
> +  GFP_KERNEL);
> + if (!audev) {
> + dev_err(&pdev->dev, "Not enough memory\n");

here too


--
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][r8188eu]: memory leak in rtw_free_cmd_obj if command is (_Set_Drv_Extra)

[Liu, Chuansheng]

Hi,

> -Original Message-
> From: Wang, Xiaoming
> Sent: Monday, March 10, 2014 11:38 PM
> To: gre...@linuxfoundation.org; valentina.mane...@gmail.com;
> dan.carpen...@oracle.com; standby2...@gmail.com
> Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Zhang,
> Dongxing; Wang, Xiaoming; Liu, Chuansheng
> Subject: [PATCH] [staging][r8188eu]: memory leak in rtw_free_cmd_obj if
> command is (_Set_Drv_Extra)
> 
> pcmd->parmbuf->pbuf has been allocated if command is
> GEN_CMD_CODE(_Set_Drv_Extra),
> and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by
> rtw_dequeue_cmd.
> The memory leak happened on this branch "if( _FAIL ==
> rtw_cmd_filter(pcmdpriv, pcmd) )"
> which goto post_process directly against freeing pcmd->parmbuf->pbuf in
> rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
> This patch free pcmd->parmbuf->pbuf on the forgotten branch to avoid memory
> leak.
> 
> Signed-off-by: Zhang Dongxing 
> Signed-off-by: xiaoming wang 
> 
> diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> index c0a0a52..1c7f505 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> @@ -288,7 +288,7 @@ int rtw_cmd_thread(void *context)
> void (*pcmd_callback)(struct adapter *dev, struct cmd_obj *pcmd);
> struct adapter *padapter = (struct adapter *)context;
> struct cmd_priv *pcmdpriv = &(padapter->cmdpriv);
> -
> +   struct drvextra_cmd_parm *extra_parm = NULL;
> 
> thread_enter("RTW_CMD_THREAD");
> 
> @@ -323,6 +323,11 @@ _next:
> 
> if (_FAIL == rtw_cmd_filter(pcmdpriv, pcmd)) {
> pcmd->res = H2C_DROPPED;
> +   if (pcmd->cmdcode ==
> GEN_CMD_CODE(_Set_Drv_Extra)) {
> +   extra_parm = (struct
> drvextra_cmd_parm *)pcmd->parmbuf;
> +   if (extra_parm && extra_parm->pbuf
> && extra_parm->size > 0)
> +   rtw_mfree(extra_parm->pbuf,
> extra_parm->size);
> +   }
> goto post_process;
> }
> 

Reviewed-by: Chuansheng Liu 

Thanks.

Best Regards
Chuansheng

Re: [f2fs-dev] [PATCH 1/5] f2fs: update start nid only once each circle

[Gu Zheng]

On 03/08/2014 07:46 PM, Chao Yu wrote:

> Hi Gu,
> 
>> -Original Message-
>> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
>> Sent: Friday, March 07, 2014 6:43 PM
>> To: Kim
>> Cc: linux-kernel; f2fs
>> Subject: [f2fs-dev] [PATCH 1/5] f2fs: update start nid only once each circle
>>
>>
>> Signed-off-by: Gu Zheng 
> 
> Reviewed-by: Chao Yu 
> 
>> ---
>>  fs/f2fs/node.c |6 +-
>>  1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 8c14110..9653096 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1875,11 +1875,15 @@ void destroy_node_manager(struct f2fs_sb_info *sbi)
>>  while ((found = __gang_lookup_nat_cache(nm_i,
>>  nid, NATVEC_SIZE, natvec))) {
>>  unsigned idx;
>> +
>> +nid = nat_get_nid(natvec[found - 1]) + 1;
>> +
>>  for (idx = 0; idx < found; idx++) {
>>  struct nat_entry *e = natvec[idx];
> 
> Could we replace argument 'e' with 'natvec[idx]'? then we could remove 'e' and
> brace here.

Agree. More neat with this cleanup.

Regards,
Gu

> 
> Thanks.
> 
>> -nid = nat_get_nid(e) + 1;
>> +
>>  __del_from_nat_cache(nm_i, e);
>>  }
>> +
>>  }
>>  f2fs_bug_on(nm_i->nat_cnt);
>>  write_unlock(&nm_i->nat_tree_lock);
>> --
>> 1.7.7
>>
>>
>> --
>> Subversion Kills Productivity. Get off Subversion & Make the Move to 
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> ___
>> Linux-f2fs-devel mailing list
>> linux-f2fs-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 
> 


--
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][RESENT] dma: add R-Car Audio DMAC peri peri driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

Add support Audio DMAC peri peri driver
for Renesas R-Car Gen2 SoC, using 'shdma-base'
DMA driver framework.

Signed-off-by: Kuninori Morimoto 
---
resent

 - add missing "dmaeng...@vger.kernel.org"

v1 -> v2

 - run scripts/checkpatch.pl
 - ecchange length settings on audmapp_desc_setup()
 - exchange slave_id check on audmapp_find_slave()

 drivers/dma/sh/Kconfig |6 +
 drivers/dma/sh/Makefile|1 +
 drivers/dma/sh/rcar-audmapp.c  |  325 
 include/linux/platform_data/dma-rcar-audmapp.h |   34 +++
 4 files changed, 366 insertions(+)
 create mode 100644 drivers/dma/sh/rcar-audmapp.c
 create mode 100644 include/linux/platform_data/dma-rcar-audmapp.h

diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index dadd9e01..b4c8138 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -29,6 +29,12 @@ config RCAR_HPB_DMAE
help
  Enable support for the Renesas R-Car series DMA controllers.
 
+config RCAR_AUDMAC_PP
+   tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support"
+   depends on SH_DMAE_BASE
+   help
+ Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral 
controllers.
+
 config SHDMA_R8A73A4
def_bool y
depends on ARCH_R8A73A4 && SH_DMAE != n
diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
index e856af2..1ce88b2 100644
--- a/drivers/dma/sh/Makefile
+++ b/drivers/dma/sh/Makefile
@@ -7,3 +7,4 @@ endif
 shdma-objs := $(shdma-y)
 obj-$(CONFIG_SUDMAC) += sudmac.o
 obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
+obj-$(CONFIG_RCAR_AUDMAC_PP) += rcar-audmapp.o
diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
new file mode 100644
index 000..cd3c237
--- /dev/null
+++ b/drivers/dma/sh/rcar-audmapp.c
@@ -0,0 +1,325 @@
+/*
+ * drivers/dma/sh/rcar-audmapp.c
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Kuninori Morimoto 
+ *
+ * based on the drivers/dma/sh/shdma.c
+ *
+ * Copyright (C) 2011-2012 Guennadi Liakhovetski 
+ * Copyright (C) 2009 Nobuhiro Iwamatsu 
+ * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * DMA register
+ */
+#define PDMASAR0x00
+#define PDMADAR0x04
+#define PDMACHCR   0x0c
+
+/* PDMACHCR */
+#define PDMACHCR_DE(1 << 0)
+
+#define AUDMAPP_MAX_CHANNELS   29
+
+/* Default MEMCPY transfer size = 2^2 = 4 bytes */
+#define LOG2_DEFAULT_XFER_SIZE 2
+#define AUDMAPP_SLAVE_NUMBER   256
+#define AUDMAPP_LEN_MAX(16 * 1024 * 1024)
+
+struct audmapp_chan {
+   struct shdma_chan shdma_chan;
+   struct audmapp_slave_config *config;
+   void __iomem *base;
+};
+
+struct audmapp_device {
+   struct shdma_dev shdma_dev;
+   struct audmapp_pdata *pdata;
+   struct device *dev;
+   void __iomem *chan_reg;
+};
+
+#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan)
+#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device,\
+ struct audmapp_device, shdma_dev.dma_dev)
+
+static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg)
+{
+   struct audmapp_device *audev = to_dev(auchan);
+   struct device *dev = audev->dev;
+
+   dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data);
+
+   iowrite32(data, auchan->base + reg);
+}
+
+static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg)
+{
+   return ioread32(auchan->base + reg);
+}
+
+static void audmapp_halt(struct shdma_chan *schan)
+{
+   struct audmapp_chan *auchan = to_chan(schan);
+   int i;
+
+   audmapp_write(auchan, 0, PDMACHCR);
+
+   for (i = 0; i < 1024; i++) {
+   if (0 == audmapp_read(auchan, PDMACHCR))
+   return;
+   udelay(1);
+   }
+}
+
+static void audmapp_start_xfer(struct shdma_chan *schan,
+  struct shdma_desc *sdecs)
+{
+   struct audmapp_chan *auchan = to_chan(schan);
+   struct audmapp_device *audev = to_dev(auchan);
+   struct audmapp_slave_config *cfg = auchan->config;
+   struct device *dev = audev->dev;
+   u32 chcr = cfg->chcr | PDMACHCR_DE;
+
+   dev_dbg(dev, "src/dst/chcr = %x/%x/%x\n",
+   cfg->src, cfg->dst, cfg->chcr);
+
+   audmapp_write(auchan, cfg->src, PDMASAR);
+   audmapp_write(auchan, cfg->dst, PDMADAR);
+   audmapp_write(auchan, chcr, PDMACHCR);
+}
+
+static stru

[PATCH] [staging][r8188eu]: memory leak in rtw_free_cmd_obj if command is (_Set_Drv_Extra)

[Wang, Xiaoming]

pcmd->parmbuf->pbuf has been allocated if command is 
GEN_CMD_CODE(_Set_Drv_Extra),
and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by 
rtw_dequeue_cmd.
The memory leak happened on this branch "if( _FAIL == rtw_cmd_filter(pcmdpriv, 
pcmd) )"
which goto post_process directly against freeing pcmd->parmbuf->pbuf in
rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
This patch free pcmd->parmbuf->pbuf on the forgotten branch to avoid memory 
leak.

Signed-off-by: Zhang Dongxing 
Signed-off-by: xiaoming wang 

diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c 
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index c0a0a52..1c7f505 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -288,7 +288,7 @@ int rtw_cmd_thread(void *context)
void (*pcmd_callback)(struct adapter *dev, struct cmd_obj *pcmd);
struct adapter *padapter = (struct adapter *)context;
struct cmd_priv *pcmdpriv = &(padapter->cmdpriv);
-
+   struct drvextra_cmd_parm *extra_parm = NULL;

thread_enter("RTW_CMD_THREAD");

@@ -323,6 +323,11 @@ _next:

if (_FAIL == rtw_cmd_filter(pcmdpriv, pcmd)) {
pcmd->res = H2C_DROPPED;
+   if (pcmd->cmdcode == GEN_CMD_CODE(_Set_Drv_Extra)) {
+   extra_parm = (struct drvextra_cmd_parm 
*)pcmd->parmbuf;
+   if (extra_parm && extra_parm->pbuf && 
extra_parm->size > 0)
+   rtw_mfree(extra_parm->pbuf, 
extra_parm->size);
+   }
goto post_process;
}


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

LK bug with SGH-T999V (d2tmo)

[Pierre-Yves Tremblay]

1. LK v9.2 and higher won't work at all on d2tmo nightlies&stable
(CM11) and on d2lte nightlies (CM11) for SGH-T999V

2. The phone just can't run with this kernel anymore since version 9.2
(d2att) with cm11's d2tmo and version 9.4 (d2) with cm11's d2lte.
Phone app crashes repetitively with v9.4 of d2 with CM11's latest
nightlies of d2lte. With v9.1 of d2att and cm11's nightlies of d2tmo,
lk has always worked very well, same for previous versions of lk's
d2att combined with cm10's d2tmo nightlies. 9.2 and higher just
totally fail at boot with my phone. I don't remember exactly if it was
a phone app crash or something else, but it was a major fail at boot
just like it is now with the repetitive phone app crash caused by lk
9.4 (d2) with cm11's d2lte.

3. Repetitive phone app crash at boot

4.1 root@d2tmo:/ # cat /proc/version
Linux version 3.4.82-cyanogenmod-g5d45d15 (build03@cyanogenmod) (gcc
version 4.7 (GCC) ) #1 SMP PREEMPT Sat Mar 8 16:53:43 PST 2014

4.2 leankernel can't run on d2lte for my phone

5. v9.1 from d2att with cm11's d2tmo

8. SGH-T999V Canadian Galaxy S3 provided by Videotron running CM11.
The bug has been happening on both nightly&stable versions of CM11's
d2tmo and nightly versions of d2lte.

I'm unable to run leankernel anymore since I have upgraded from d2tmo
to d2lte nightlies on CM11. I had been trying lk 9.2 (d2att) for a
while but it always failed. I can't use version 9.1 from d2att with
d2lte nightlies, so now i'm running without leankernel and I miss it.

1|root@d2tmo:/ # cat /proc/cpuinfo
cat /proc/cpuinfo
Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
BogoMIPS: 13.50

processor   : 1
BogoMIPS: 13.50

Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva id
ivt
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x1
CPU part: 0x04d
CPU revision: 0

Hardware: SAMSUNG M2
Revision: 0010
Serial  : a107aa56
root@d2tmo:/ # cat /proc/modules
cat /proc/modules
dhd 324767 0 - Live 0x
root@d2tmo:/ # cat /proc/ioports
cat /proc/ioports
0008-0008 : i2c_sda
0009-0009 : i2c_clk
000a-000a : gpio_host_wake
000c-000c : a2220_sda
000d-000d : a2220_sck
0026-0026 : spi_mosi
0027-0027 : spi_miso
0028-0028 : spi_cs
0029-0029 : spi_clk
004f-004f : gpio_ext_wake
0054-0058 : wcnss_gpios_5wire
011d-011d : pmic_rtc_base
root@d2tmo:/ # cat /proc/iomem
cat /proc/iomem
0050-00500fff : msm_ssbi.0
0070-007060ff : hdmi_msm_qfprom_addr
0080207c-0080207f : slimbus_slew_reg
0300-0327 : wcnss_mmio
  03204000-032040ff : pil_riva
0410-04100fff : kgsl_2d0_reg_memory
  0410-04100fff : kgsl-2d0
0420-04200fff : kgsl_2d1_reg_memory
  0420-04200fff : kgsl-2d1
0430-0431 : kgsl_3d0_reg_memory
  0430-0431 : kgsl-3d0
0440-044f : msm_vidc.0
0450-045f : vfe32
  0450-045f : msm_vfe
0460-046f : msm_gemini.0
0470-047e : mipi_dsi
0480-048003ff : csid
  0480-048003ff : msm_csid
04800400-048007ff : csid
  04800400-048007ff : msm_csid
04800800-04800bff : ispif
  04800800-04800bff : msm_ispif
04800c00-04800fff : csiphy
  04800c00-04800fff : msm_csiphy
04801000-048013ff : csiphy
  04801000-048013ff : msm_csiphy
04a0-04a00fff : hdmi_msm_hdmi_addr
04e0-04ef : msm_rotator.0
0510-051e : mdp
0530-053f : vpe
  0530-053f : msm_vpe
0730-073f : physbase
  0730-073f : physbase
0740-074f : physbase
  0740-074f : physbase
0750-075f : physbase
  0750-075f : physbase
0760-076f : physbase
  0760-076f : physbase
0770-077f : physbase
  0770-077f : physbase
0780-078f : physbase
  0780-078f : physbase
0790-079f : physbase
  0790-079f : physbase
07a0-07af : physbase
  07a0-07af : physbase
07b0-07bf : physbase
  07b0-07bf : physbase
07c0-07cf : physbase
  07c0-07cf : physbase
07d0-07df : physbase
  07d0-07df : physbase
07e0-07ef : physbase
  07e0-07ef : physbase
0880-088000ff : pil_qdsp6v4.1
0890-089000ff : pil_qdsp6v4.2
08b0-08b3 : pil_qdsp6v4.1
  08b0-08b3 : pil_qdsp6v4.2
1218-121807ff : core_mem
12180800-12181fff : dml_mem
12182000-12183fff : bam_mem
121c-121c07ff : core_mem
121c0800-121c1fff : dml_mem
121c2000-121c3fff : bam_mem
1224-12240fff : bamdma_dma
12244000-12247fff : bamdma_bam
1240-124007ff : core_mem
12400800-12401fff : dml_mem
12402000-12403fff : bam_mem
1244-12440003 : gsbi_base
  1244-12440003 : spi_qsd
1246-12460fff : spi_base
  1246-12460fff : spi_qsd
1248-12480003 : gsbi_qup_i2c_addr
  1248-12480003 : qup_i2c
124a-124a0fff : qup_phys_addr
  124a-124a0fff : qup_i2c
1250-12501000 : msm_hsusb
  1250-12501000 : msm_otg
1250

Re: [PATCH] netlink: switch net_ns only if net is not init_net

[Gu Zheng]

On 03/10/2014 07:09 AM, David Miller wrote:

> From: Gu Zheng 
> Date: Fri, 07 Mar 2014 18:47:30 +0800
> 
>> Many netlink users create netlink sock in the init_net, and the
>> switching nes_ns(init_net-->net) is needless in this case. So here
>> we add a pre-check to avoid this.
>>
>> Signed-off-by: Gu Zheng 
> 
> This check is more appropriately placed into sk_change_net() itself.

Agree. I'll update it soon.

Regards,
Gu

> 


--
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 5/5] x86: Always define BUG() and HAVE_ARCH_BUG, even with !CONFIG_BUG

[Josh Triplett]

This ensures that BUG() always has a definition that causes a trap (via
an undefined instruction), and that the compiler still recognizes the
code following BUG() as unreachable, avoiding warnings that would
otherwise appear (such as on non-void functions that don't return a
value after BUG()).

In addition to saving a few bytes over the generic infinite-loop
implementation, this implementation traps rather than looping, which
potentially allows for better error-recovery behavior (such as by
rebooting).

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Triplett 
---
v3: New patch for x86-optimized implementation of a simple bug for
!CONFIG_BUG, based on Arnd Bergmann's proposal.

 arch/x86/include/asm/bug.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {  
\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include 
 
 #endif /* _ASM_X86_BUG_H */
-- 
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 4/5] bug: Make BUG() always stop the machine

[Josh Triplett]

When !CONFIG_BUG and !HAVE_ARCH_BUG, define the generic BUG() as an
infinite loop rather than a no-op.  This avoids undefined behavior if
execution ever actually reaches BUG(), and avoids warnings about code
after BUG() (such as on non-void functions calling BUG() and then
not returning).

bloat-o-meter results:

add/remove: 0/0 grow/shrink: 43/10 up/down: 235/-98 (137)
function old new   delta
umount_collect   119 138 +19
notify_change306 324 +18
xstate_enable_boot_cpu   252 269 +17
kunmap54  70 +16
balloon_page_dequeue 112 126 +14
mm_take_all_locks223 233 +10
list_lru_walk_node   143 152  +9
vma_adjust  10591067  +8
pcpu_setup_first_chunk  11301138  +8
mm_drop_all_locks143 151  +8
ns_capable55  62  +7
anon_transport_class_unregister8  15  +7
srcu_init_notifier_head   35  41  +6
shrink_dcache_for_umount 174 180  +6
kunmap_high   99 105  +6
end_page_writeback43  49  +6
do_exit 13391345  +6
__kfifo_dma_out_prepare_r 86  92  +6
__kfifo_dma_in_prepare_r  90  96  +6
fixup_user_fault 120 125  +5
repair_env_string 73  77  +4
read_cache_pages_invalidate_page  56  60  +4
isolate_lru_pages.isra   142 146  +4
do_notify_parent_cldstop 255 259  +4
cpu_init 370 374  +4
utimes_common270 272  +2
tasklet_hi_action 91  93  +2
tasklet_action91  93  +2
set_pte_vaddr 46  48  +2
find_get_pages_tag   202 204  +2
early_iounmap185 187  +2
__native_set_fixmap   36  38  +2
__get_user_pages 822 824  +2
__early_ioremap  299 301  +2
yield_task_stop1   2  +1
tick_resume   37  38  +1
switched_to_stop   1   2  +1
switched_to_idle   1   2  +1
prio_changed_stop  1   2  +1
prio_changed_idle  1   2  +1
pm_qos_power_read111 112  +1
arch_cpu_idle_dead 1   2  +1
__insert_vmap_area   140 141  +1
sys_renameat 614 612  -2
mm_fault_error   297 295  -2
SyS_renameat 614 612  -2
sys_linkat   416 413  -3
SyS_linkat   416 413  -3
chmod_common 129 122  -7
proc_cap_handler 240 225 -15
__schedule   849 831 -18
sys_madvise 10771054 -23
SyS_madvise 10771054 -23

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Triplett 
---
v3: New patch in this series, incorporating Arnd's suggestion to make BUG()
always stop execution.  This eliminates the new warnings currently appearing in
allnoconfig due to !CONFIG_BUG; unlike v2, this avoids using unreachable(), and
thus avoids the possibility of undefined behvior if execution actually reaches
a call to BUG().

 include/asm-generic/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index a97fa11..630dd23 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -138,7 +138,7 @@ extern void warn_slowpath_null(const char *file, const int 
line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while (0)
+#define BUG() do {} while (1)
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-- 
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.

[PATCH v3 3/5] bug: When !CONFIG_BUG, make WARN call no_printk to check format and args

[Josh Triplett]

The stub version of WARN for !CONFIG_BUG completely ignored its format
string and subsequent arguments; make it check them instead, using
no_printk.

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Triplett 
---
v3: Patch unchanged from v2.
 include/asm-generic/bug.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 2d54d8d..a97fa11 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -155,6 +155,7 @@ extern void warn_slowpath_null(const char *file, const int 
line);
 #ifndef WARN
 #define WARN(condition, format...) ({  \
int __ret_warn_on = !!(condition);  \
+   no_printk(format);  \
unlikely(__ret_warn_on);\
 })
 #endif
-- 
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/5] include/asm-generic/bug.h: Style fix: s/while(0)/while (0)/

[Josh Triplett]

Reported-by: Randy Dunlap 
Signed-off-by: Josh Triplett 
---
v3: Patch unchanged from v2.
 include/asm-generic/bug.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7ecd398..2d54d8d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -52,7 +52,7 @@ struct bug_entry {
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
 #endif
 
 /*
@@ -138,11 +138,11 @@ extern void warn_slowpath_null(const char *file, const 
int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() do {} while (0)
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) ; } while (0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
-- 
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: [PATCH] regulator: act8865: Remove unnecessary *rdev[] from struct act8865

[Yang, Wenyou]

> -Original Message-
> From: Axel Lin [mailto:axel@ingics.com]
> Sent: Saturday, March 08, 2014 9:19 PM
> To: Mark Brown
> Cc: Yang, Wenyou; Liam Girdwood; linux-kernel@vger.kernel.org
> Subject: [PATCH] regulator: act8865: Remove unnecessary *rdev[] from
> struct act8865
> 
> Now we are using devm_regulator_register(), so we don't need the *rdev[]
> array to store return value of devm_regulator_register. Use a *rdev
> variable is enough for checking return status.
> 
> Signed-off-by: Axel Lin 
Acked-by: Wenyou Yang 
> ---
>  drivers/regulator/act8865-regulator.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/regulator/act8865-regulator.c
> b/drivers/regulator/act8865-regulator.c
> index a5ff30c..b92d7dd 100644
> --- a/drivers/regulator/act8865-regulator.c
> +++ b/drivers/regulator/act8865-regulator.c
> @@ -62,7 +62,6 @@
>  #define  ACT8865_VOLTAGE_NUM 64
> 
>  struct act8865 {
> - struct regulator_dev *rdev[ACT8865_REG_NUM];
>   struct regmap *regmap;
>  };
> 
> @@ -256,7 +255,7 @@ static inline int act8865_pdata_from_dt(struct
> device *dev,  static int act8865_pmic_probe(struct i2c_client *client,
>  const struct i2c_device_id *i2c_id)  {
> - struct regulator_dev **rdev;
> + struct regulator_dev *rdev;
>   struct device *dev = &client->dev;
>   struct act8865_platform_data *pdata = dev_get_platdata(dev);
>   struct regulator_config config = { };
> @@ -290,8 +289,6 @@ static int act8865_pmic_probe(struct i2c_client
> *client,
>   if (!act8865)
>   return -ENOMEM;
> 
> - rdev = act8865->rdev;
> -
>   act8865->regmap = devm_regmap_init_i2c(client,
> &act8865_regmap_config);
>   if (IS_ERR(act8865->regmap)) {
>   error = PTR_ERR(act8865->regmap);
> @@ -311,12 +308,12 @@ static int act8865_pmic_probe(struct i2c_client
> *client,
>   config.driver_data = act8865;
>   config.regmap = act8865->regmap;
> 
> - rdev[i] = devm_regulator_register(&client->dev,
> - &act8865_reg[i], &config);
> - if (IS_ERR(rdev[i])) {
> + rdev = devm_regulator_register(&client->dev, &act8865_reg[i],
> +&config);
> + if (IS_ERR(rdev)) {
>   dev_err(dev, "failed to register %s\n",
>   act8865_reg[id].name);
> - return PTR_ERR(rdev[i]);
> + return PTR_ERR(rdev);
>   }
>   }
> 
> --
> 1.8.1.2
> 
> 

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

[Sebastian Hesselbarth]

phy_ethtool_get_wol is a helper to get current WOL settings from
a phy device. When using this helper on a PHY without .get_wol
callback, struct ethtool_wolinfo is never set-up correctly and
may contain misleading information about WOL status.

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

Signed-off-by: Sebastian Hesselbarth 
---
Cc: David Miller 
Cc: Florian Fainelli 
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/phy/phy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 19c9eca0ef26..62a7cd401e1c 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1092,6 +1092,7 @@ EXPORT_SYMBOL(phy_ethtool_set_wol);
 
 void phy_ethtool_get_wol(struct phy_device *phydev, struct ethtool_wolinfo 
*wol)
 {
+   wol->supported = wol->wolopts = 0;
if (phydev->drv->get_wol)
phydev->drv->get_wol(phydev, wol);
 }
-- 
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 v3 1/5] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family

[Josh Triplett]

When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
condition argument; however, WARN_ON_ONCE and family still have
conditions and a boolean to detect one-time invocation, even though the
warning they'd emit doesn't exist.  Make the existing definitions
conditional on CONFIG_BUG, and add definitions for !CONFIG_BUG that map
to the passthrough versions of WARN and WARN_ON.

This saves 4.4k on a minimized configuration (smaller than
allnoconfig), and 20.6k with defconfig plus CONFIG_BUG=n.

Signed-off-by: Josh Triplett 
---
v3: Patch unchanged from v2.

Andrew, can you please replace the entire v2 series currently in -mm
with this new series?

 include/asm-generic/bug.h | 57 +--
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..7ecd398 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -106,33 +106,6 @@ extern void warn_slowpath_null(const char *file, const int 
line);
unlikely(__ret_warn_on);\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({  \
-   int __ret_warn_on = !!(condition);  \
-   unlikely(__ret_warn_on);\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({  \
-   int __ret_warn_on = !!(condition);  \
-   unlikely(__ret_warn_on);\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)({  \
static bool __section(.data.unlikely) __warned; \
int __ret_warn_once = !!(condition);\
@@ -163,6 +136,36 @@ extern void warn_slowpath_null(const char *file, const int 
line);
unlikely(__ret_warn_once);  \
 })
 
+#else /* !CONFIG_BUG */
+#ifndef HAVE_ARCH_BUG
+#define BUG() do {} while(0)
+#endif
+
+#ifndef HAVE_ARCH_BUG_ON
+#define BUG_ON(condition) do { if (condition) ; } while(0)
+#endif
+
+#ifndef HAVE_ARCH_WARN_ON
+#define WARN_ON(condition) ({  \
+   int __ret_warn_on = !!(condition);  \
+   unlikely(__ret_warn_on);\
+})
+#endif
+
+#ifndef WARN
+#define WARN(condition, format...) ({  \
+   int __ret_warn_on = !!(condition);  \
+   unlikely(__ret_warn_on);\
+})
+#endif
+
+#define WARN_ON_ONCE(condition) WARN_ON(condition)
+#define WARN_ONCE(condition, format...) WARN(condition, format)
+#define WARN_TAINT(condition, taint, format...) WARN(condition, format)
+#define WARN_TAINT_ONCE(condition, taint, format...) WARN(condition, format)
+
+#endif
+
 /*
  * WARN_ON_SMP() is for cases that the warning is either
  * meaningless for !SMP or may even cause failures.
-- 
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: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

[Sebastian Hesselbarth]

On 03/10/2014 01:41 AM, David Miller wrote:

From: Sebastian Hesselbarth 
Date: Mon, 10 Mar 2014 01:37:32 +0100


The mechanism is manual, no automatic way to determine it.


We recognize BIOS and ACPI bugs and work around them, by looking at
version information and whatnot, so you really can't convince me that
something similar can't be done here perhaps in the platform code.


Hmm, if the is a way to determine the version of that particual u-boot
I'd be happy to exploit that information. But I honestly doubt that.
Compared to u-boot bootloader and kernel interaction, BIOS and ACPI
are well-defined protocols.

I personally, would prefer everybody should update his broken
bootloaders, but that will just not happen.

Anyway, at least for the two boards in question, we know a bootloader
workaround. The version does support user commands to re-enable the PHY
by writing the corresponding registers.

Unfortunately, the is a bug in phy_ethtool_get_wol that up to now,
prevents most PHYs (without .wol callbacks) from being suspended.
I wanted to get in a way to disable suspend before sending a fix.

If you are that against a sysfs knob, I guess, we will just see how
many more bootloaders are broken and some will not have a way to write
PHY registers.

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/

Re: [PATCH v7 net-next 1/3] filter: add Extended BPF interpreter and converter

[Alexei Starovoitov]

On Sun, Mar 9, 2014 at 3:00 PM, Daniel Borkmann  wrote:
> On 03/09/2014 06:08 PM, Alexei Starovoitov wrote:
>>
>> On Sun, Mar 9, 2014 at 5:29 AM, Daniel Borkmann 
>> wrote:
>>>
>>> On 03/09/2014 12:15 AM, Alexei Starovoitov wrote:


 Extended BPF extends old BPF in the following ways:
 - from 2 to 10 registers
 Original BPF has two registers (A and X) and hidden frame pointer.
 Extended BPF has ten registers and read-only frame pointer.
 - from 32-bit registers to 64-bit registers
 semantics of old 32-bit ALU operations are preserved via 32-bit
 subregisters
 - if (cond) jump_true; else jump_false;
 old BPF insns are replaced with:
 if (cond) jump_true; /* else fallthrough */
 - adds signed > and >= insns
 - 16 4-byte stack slots for register spill-fill replaced with
 up to 512 bytes of multi-use stack space
 - introduces bpf_call insn and register passing convention for zero
 overhead calls from/to other kernel functions (not part of this
 patch)
 - adds arithmetic right shift insn
 - adds swab32/swab64 insns
 - adds atomic_add insn
 - old tax/txa insns are replaced with 'mov dst,src' insn

 Extended BPF is designed to be JITed with one to one mapping, which
 allows GCC/LLVM backends to generate optimized BPF code that performs
 almost as fast as natively compiled code

 sk_convert_filter() remaps old style insns into extended:
 'sock_filter' instructions are remapped on the fly to
 'sock_filter_ext' extended instructions when
 sysctl net.core.bpf_ext_enable=1

 Old filter comes through sk_attach_filter() or
 sk_unattached_filter_create()
if (bpf_ext_enable) {
   convert to new
   sk_chk_filter() - check old bpf
   use sk_run_filter_ext() - new interpreter
} else {
   sk_chk_filter() - check old bpf
   if (bpf_jit_enable)
   use old jit
   else
   use sk_run_filter() - old interpreter
}

 sk_run_filter_ext() interpreter is noticeably faster
 than sk_run_filter() for two reasons:

 1.fall-through jumps
 Old BPF jump instructions are forced to go either 'true' or 'false'
 branch which causes branch-miss penalty.
 Extended BPF jump instructions have one branch and fall-through,
 which fit CPU branch predictor logic better.
 'perf stat' shows drastic difference for branch-misses.

 2.jump-threaded implementation of interpreter vs switch statement
 Instead of single tablejump at the top of 'switch' statement, GCC
 will
 generate multiple tablejump instructions, which helps CPU branch
 predictor

 Performance of two BPF filters generated by libpcap was measured
 on x86_64, i386 and arm32.

 fprog #1 is taken from Documentation/networking/filter.txt:
 tcpdump -i eth0 port 22 -dd

 fprog #2 is taken from 'man tcpdump':
 tcpdump -i eth0 'tcp port 22 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
  ((tcp[12]&0xf0)>>2)) != 0)' -dd

 Other libpcap programs have similar performance differences.

 Raw performance data from BPF micro-benchmark:
 SK_RUN_FILTER on same SKB (cache-hit) or 10k SKBs (cache-miss)
 time in nsec per call, smaller is better
 --x86_64--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
 old BPF 90   101   192   202
 ext BPF 3171   47 97
 old BPF jit 1234   17 44
 ext BPF jit TBD

 --i386--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
 old BPF107136  227   252
 ext BPF 40119   69   172

 --arm32--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
 old BPF202300  475   540
 ext BPF180270  330   470
 old BPF jit 26182   37   202
 new BPF jit TBD

 Tested with trinify BPF fuzzer

 Future work:

 0. add bpf/ebpf testsuite to tools/testing/selftests/net/bpf

 1. add extended BPF JIT for x86_64

 2. add inband old/new demux and extended BPF verifier, so that new
 programs
  can be loaded through old sk_attach_filter() and
 sk_unattached_filter_create()
  interfaces

 3. tracing filters systemtap-like with extended BPF

 4. OVS with extended BPF

 5. nftables with extended BPF

 Signed-off-by: Alexei Starovoitov 
 Acked-by: Hagen Paul Pfeifer 
 Reviewed-by: Daniel Borkmann 
>>>
>>>
>>>
>>> One more question or possible issue that came through my mind: When
>>> someone attaches a socket filte

Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

[David Miller]

From: Sebastian Hesselbarth 
Date: Mon, 10 Mar 2014 01:37:32 +0100

> The mechanism is manual, no automatic way to determine it.

We recognize BIOS and ACPI bugs and work around them, by looking at
version information and whatnot, so you really can't convince me that
something similar can't be done here perhaps in the platform code.


--
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] net: phy: Add sysfs attribute to prevent PHY suspend

[Sebastian Hesselbarth]

On 03/10/2014 01:30 AM, David Miller wrote:

From: Sebastian Hesselbarth 
Date: Mon, 10 Mar 2014 00:25:24 +0100


There is no way to determine if a bootloader is broken or not. The
sysfs knob allows to provide a use case based decision. Of course,
we can invent some freaky device tree property but that the DT
maintainers will not like either.


My point is that whatever mechanism is used to "decide" that the sysfs
knob gets set, can also be used to "decide" that a DT property is
instantiated in the device tree.


The mechanism is manual, no automatic way to determine it. I understand
your point, but DT maintainers will argue here that DT is to describe HW
not SW. And a badly written bootloader initialization routine for a PHY
is SW.

Also, this will force us to maintain two sets of DT files for each
affected board: one for those with broken bootloader and one for those
with an updated, fixed bootloader. And of course, the broken bootloaders
are from pre-DT times and cannot even set that property but require the
user to pick the right DT.

If you are still against a sysfs knob, I see no way to provide a user
accessible way to prevent the PHY to be suspended. And the user is the
only reliable instance to decide not to suspend it.

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/

Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

[David Miller]

From: Sebastian Hesselbarth 
Date: Mon, 10 Mar 2014 00:25:24 +0100

> There is no way to determine if a bootloader is broken or not. The
> sysfs knob allows to provide a use case based decision. Of course,
> we can invent some freaky device tree property but that the DT
> maintainers will not like either.

My point is that whatever mechanism is used to "decide" that the sysfs
knob gets set, can also be used to "decide" that a DT property is
instantiated in the device tree.
--
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/3] drivers: clk: add samsung common clock config option

[Tomasz Figa]

Hi Pankaj,

On 26.02.2014 06:24, Pankaj Dubey wrote:

add samsung common clock config option and let ARCH_EXYNOS or ARCH_S3C
select this if they want to use samsung common clock infrastructure.

CC: Mike Turquette 
Signed-off-by: Pankaj Dubey 
---
  drivers/clk/Kconfig  |   10 ++
  drivers/clk/Makefile |2 +-
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 7641965..d93a325 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -23,6 +23,16 @@ config COMMON_CLK
  menu "Common Clock Framework"
depends on COMMON_CLK

+config COMMON_CLK_SAMSUNG
+   bool "Clock driver for Samsung SoCs"
+   depends on ARCH_S3C64XX || ARCH_S3C24XX || ARCH_EXYNOS || ARM64
+   ---help---
+  Supports clocking on Exynos SoCs:
+ - Exynos5250, Exynos5420 board.
+ - Exynos4 boards.
+ - S3C2412, S3C2416, S3C2466 boards.
+ - S3C64XX boards.


I don't think listing the platforms here explicitly is a good idea, as 
this option shouldn't generally be user-visible (related platforms would 
not work without this option enabled) and adding support for every new 
SoC would require changing the help string.


I wonder if we really need this to be user-visible. What about moving it 
out of this menu, making the symbol select COMMON_CLK and let the 
platforms just select COMMON_CLK_SAMSUNG alone?


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

Re: [PATCH 5/9 v7] clk: samsung exynos5250/5420: Add gate clock for SSS module

[Tomasz Figa]

On 17.02.2014 10:44, Naveen Krishna Chatradhi wrote:

This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250/5420.

Signed-off-by: Naveen Krishna Chatradhi 
Reviewed-by: Tomasz Figa 
TO: 
TO: Tomasz Figa 
CC: David S. Miller 
CC: Kukjin Kim 
CC: 
---
changes since v6:
None
changes since v5:
1. Added Reviewed-by: Tomasz Figa 

  .../devicetree/bindings/clock/exynos5250-clock.txt |1 +
  drivers/clk/samsung/clk-exynos5250.c   |1 +
  drivers/clk/samsung/clk-exynos5420.c   |4 
  include/dt-bindings/clock/exynos5250.h |1 +
  4 files changed, 7 insertions(+)


Applied to samsung-clk tree.

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

[GIT PULL] x86 fixes for v3.14-rc6 - bad patch dropped

[H. Peter Anvin]

Hi Linus,

The same collection of fixes except the broken NMI patch dropped.  I
will send a fixed version of that plus Suresh' FPU fix in a few days,
to get them some testing, plus I will be on a trip (part of why I got
unduly rushed this past Friday.  Sorry again for that.)

The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:

  Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus-fixed

for you to fetch changes up to d4078e232267ff53f3b030b9698a3c001db4dbec:

  x86, trace: Further robustify CR2 handling vs tracing (2014-03-06 10:58:18 
-0800)


Borislav Petkov (1):
  x86/efi: Quirk out SGI UV

H. Peter Anvin (1):
  Merge tag 'efi-urgent' into x86/urgent

Jiri Olsa (1):
  x86, trace: Fix CR2 corruption when tracing page faults

Peter Zijlstra (1):
  x86, trace: Further robustify CR2 handling vs tracing

 arch/x86/include/asm/efi.h  |  1 +
 arch/x86/kernel/setup.c | 10 ++
 arch/x86/mm/fault.c | 47 +++--
 arch/x86/platform/efi/efi.c | 20 +++
 4 files changed, 56 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 3d6b9f81cc68..acd86c850414 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -134,6 +134,7 @@ extern void efi_setup_page_tables(void);
 extern void __init old_map_region(efi_memory_desc_t *md);
 extern void __init runtime_code_page_mkexec(void);
 extern void __init efi_runtime_mkexec(void);
+extern void __init efi_apply_memmap_quirks(void);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 06853e670354..ce72964b2f46 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1239,14 +1239,8 @@ void __init setup_arch(char **cmdline_p)
register_refined_jiffies(CLOCK_TICK_RATE);
 
 #ifdef CONFIG_EFI
-   /* Once setup is done above, unmap the EFI memory map on
-* mismatched firmware/kernel archtectures since there is no
-* support for runtime services.
-*/
-   if (efi_enabled(EFI_BOOT) && !efi_is_native()) {
-   pr_info("efi: Setup done, disabling due to 32/64-bit 
mismatch\n");
-   efi_unmap_memmap();
-   }
+   if (efi_enabled(EFI_BOOT))
+   efi_apply_memmap_quirks();
 #endif
 }
 
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 6dea040cc3a1..a10c8c792161 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1020,13 +1020,17 @@ static inline bool smap_violation(int error_code, 
struct pt_regs *regs)
  * This routine handles page faults.  It determines the address,
  * and the problem, and then passes it off to one of the appropriate
  * routines.
+ *
+ * This function must have noinline because both callers
+ * {,trace_}do_page_fault() have notrace on. Having this an actual function
+ * guarantees there's a function trace entry.
  */
-static void __kprobes
-__do_page_fault(struct pt_regs *regs, unsigned long error_code)
+static void __kprobes noinline
+__do_page_fault(struct pt_regs *regs, unsigned long error_code,
+   unsigned long address)
 {
struct vm_area_struct *vma;
struct task_struct *tsk;
-   unsigned long address;
struct mm_struct *mm;
int fault;
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
@@ -1034,9 +1038,6 @@ __do_page_fault(struct pt_regs *regs, unsigned long 
error_code)
tsk = current;
mm = tsk->mm;
 
-   /* Get the faulting address: */
-   address = read_cr2();
-
/*
 * Detect and handle instructions that would cause a page fault for
 * both a tracked kernel page and a userspace page.
@@ -1248,32 +1249,50 @@ good_area:
up_read(&mm->mmap_sem);
 }
 
-dotraplinkage void __kprobes
+dotraplinkage void __kprobes notrace
 do_page_fault(struct pt_regs *regs, unsigned long error_code)
 {
+   unsigned long address = read_cr2(); /* Get the faulting address */
enum ctx_state prev_state;
 
+   /*
+* We must have this function tagged with __kprobes, notrace and call
+* read_cr2() before calling anything else. To avoid calling any kind
+* of tracing machinery before we've observed the CR2 value.
+*
+* exception_{enter,exit}() contain all sorts of tracepoints.
+*/
+
prev_state = exception_enter();
-   __do_page_fault(regs, error_code);
+   __do_page_fault(regs, error_code, address);
exception_exit(prev_state);
 }
 
-static void trace_page_fault_entries(struct pt_regs *regs,
+#ifdef CONFIG_TRACING
+static void trace_page_fault_entries(unsigned long address, struct pt_regs 
*regs,
 unsigned long error_

Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[H. Peter Anvin]

On 03/09/2014 12:47 AM, Stefani Seibold wrote:
> 
> But let me ask an other question: Is the compat mode still needed
> anymore?
> 
> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
> the __FIXADDR_TOP, there is no fix place for the VDSO page. Also in the
> 32 bit emulation layer the address is not fix.
> 
> So all applications can fail when try directly access the VDSO page with
> a hard coded address 0xe000.
> 
> IMHO this is broken. So an other solution is to remove the whole VDSO
> compat code.
> 

Lguest, Xen, OLPC and reservetop are corner cases.  My understanding is
that at least one widely used distro actually cared about this, and
Linus especially is adamant that "we don't break userspace."

The dual vdso approach might be the best bet, for the cases where
compatibility is even possible.

-hpa


--
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] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls

[Stanislav Meduna]

On 09.03.2014 23:53, David Miller wrote:

> To me it means "I've got nothing to do if other tasks want to run right
> now"  Yes, I even see it having this meaning when an RT task executes
> it.

http://www.kernel.org/doc/htmldocs/device-drivers/API-yield.html
lists this exact "while (!event) yield;" pattern as a broken usage
and states "Never use yield as a progress guarantee!!".

> How else can you interpret the intent above?

IMNSHO there is no way to make the yield() honor this intent if it is
called from a SCHED_FIFO or SCHED_RR task and the task unblocking
it is running at a lower priority. On the PREEMPT_RT systems where
the interrupt handlers are threads an application thread running
at higher priority than some interrupt handlers is a common situation.

The semantics of the scheduler here is "run the highest priority
runnable task until it blocks (FIFO) or its time slice is over
and there are more with the _same_ priority (RR)". This scenario
then collapses into a busy loop never making progress.

> If you change it to msleep(1), you're assigning an extra completely
> arbitrary time limit to the yield.  The code doesn't want to sleep
> for 1ms, that's not what it's asking for.

The problem is that there is no way to formulate what it is asking
for in scheduler terms only.

Regards
-- 
 Stano

--
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: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()

[H. Peter Anvin]

On 03/09/2014 11:07 AM, Paolo Bonzini wrote:
> 
> We really should give a loud warning if qemu64 is used with KVM.  It
> makes no sense with KVM, even less than it does with dynamic translation.
> 

Well, this is dynamic translation.

-hpa


--
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: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[H. Peter Anvin]

On 03/09/2014 12:08 AM, Stefani Seibold wrote:
> 
> This was not addressed to you, it was addressed to the x86 intel kernel
> developers to do more testing, since this piece of code has so many side
> effects. I apologizes this miss understanding.
> 

I think you're misunderstanding.

We cannot debug every single contributors' code for them.  There isn't
enough of us to go around.  We have in fact stretched well beyond the
point which we usually can accommodate for this particular patchset.

-hpa


--
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] staging: cxt1e1: remove redundant memset() call

[Daeseok Youn]

The name array doens't need to set to 0. Because
sprintf/snprintf adds a terminating '\0'.

And also it doesn't need to assign name array
address to np pointer.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/cxt1e1/linux.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
index 5d7ddd4..efd3eb8 100644
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@ -204,15 +204,13 @@ status_t
 c4_wq_port_init(mpi_t *pi)
 {
 
-   charname[16], *np;  /* NOTE: name of the queue limited by system
+   charname[16];  /* NOTE: name of the queue limited by system
 * to 10 characters */
-
if (pi->wq_port)
return 0;   /* already initialized */
 
-   np = name;
-   memset(name, 0, 16);
-   sprintf(np, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01) */
+   /* IE pmcc4-01 */
+   snprintf(name, sizeof(name), "%s%d", pi->up->devname, pi->portnum);
 
 #ifdef RLD_RESTART_DEBUG
pr_info(">> %s: creating workqueue <%s> for Port %d.\n",
-- 
1.7.4.4


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

[PATCH 1/2] staging: cxtie1: remove unneeded mkret() calls

[Daeseok Youn]

The mkret() change a value of error from positive to
negative. This patch is modified to return negative value
when it failed. It doesn't need to call with function
for changing from positive to negative.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/cxt1e1/linux.c |   72 +--
 drivers/staging/cxt1e1/musycc.c|2 +-
 drivers/staging/cxt1e1/pmcc4_drv.c |   40 ++--
 3 files changed, 48 insertions(+), 66 deletions(-)

diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
index 549efd1..5d7ddd4 100644
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@ -145,16 +145,6 @@ get_hdlc_name(hdlc_device *hdlc)
return dev->name;
 }
 
-
-static status_t
-mkret(int bsd)
-{
-   if (bsd > 0)
-   return -bsd;
-   else
-   return bsd;
-}
-
 /***/
 #include 
 
@@ -292,8 +282,8 @@ chan_open(struct net_device *ndev)
}
 
ret = c4_chan_up(priv->ci, priv->channum);
-   if (ret)
-   return -ret;
+   if (ret < 0)
+   return ret;
try_module_get(THIS_MODULE);
netif_start_queue(ndev);
return 0;   /* no error = success */
@@ -523,8 +513,8 @@ do_get_port(struct net_device *ndev, void *data)
if (!ci)
return -EINVAL; /* get card info */
 
-   ret = mkret(c4_get_port(ci, pp.portnum));
-   if (ret)
+   ret = c4_get_port(ci, pp.portnum);
+   if (ret < 0)
return ret;
if (copy_to_user(data, &ci->port[pp.portnum].p,
 sizeof(struct sbecom_port_param)))
@@ -551,7 +541,7 @@ do_set_port(struct net_device *ndev, void *data)
return -ENXIO;
 
memcpy(&ci->port[pp.portnum].p, &pp, sizeof(struct sbecom_port_param));
-   return mkret(c4_set_port(ci, pp.portnum));
+   return c4_set_port(ci, pp.portnum);
 }
 
 /* work the port loopback mode as per directed */
@@ -566,7 +556,7 @@ do_port_loop(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
-   return mkret(c4_loop_port(ci, pp.portnum, pp.port_mode));
+   return c4_loop_port(ci, pp.portnum, pp.port_mode);
 }
 
 /* set the specified register with the given value / or just read it */
@@ -582,8 +572,8 @@ do_framer_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
-   ret = mkret(c4_frame_rw(ci, &pp));
-   if (ret)
+   ret = c4_frame_rw(ci, &pp);
+   if (ret < 0)
return ret;
if (copy_to_user(data, &pp, sizeof(struct sbecom_port_param)))
return -EFAULT;
@@ -603,7 +593,8 @@ do_pld_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
-   ret = mkret(c4_pld_rw(ci, &pp));
+
+   ret = c4_pld_rw(ci, &pp);
if (ret)
return ret;
if (copy_to_user(data, &pp, sizeof(struct sbecom_port_param)))
@@ -624,8 +615,8 @@ do_musycc_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
-   ret = mkret(c4_musycc_rw(ci, &mp));
-   if (ret)
+   ret = c4_musycc_rw(ci, &mp);
+   if (ret < 0)
return ret;
if (copy_to_user(data, &mp, sizeof(struct c4_musycc_param)))
return -EFAULT;
@@ -642,8 +633,8 @@ do_get_chan(struct net_device *ndev, void *data)
sizeof(struct sbecom_chan_param)))
return -EFAULT;
 
-   ret = mkret(c4_get_chan(cp.channum, &cp));
-   if (ret)
+   ret = c4_get_chan(cp.channum, &cp);
+   if (ret < 0)
return ret;
 
if (copy_to_user(data, &cp, sizeof(struct sbecom_chan_param)))
@@ -655,7 +646,6 @@ static status_t
 do_set_chan(struct net_device *ndev, void *data)
 {
struct sbecom_chan_param cp;
-   int ret;
ci_t   *ci;
 
if (copy_from_user(&cp, data, sizeof(struct sbecom_chan_param)))
@@ -663,13 +653,7 @@ do_set_chan(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
-   switch (ret = mkret(c4_set_chan(cp.channum, &cp)))
-   {
-   case 0:
-   return 0;
-   default:
-   return ret;
-   }
+   return c4_set_chan(cp.channum, &cp);
 }
 
 static status_t
@@ -688,8 +672,8 @@ do_create_chan(struct net_device *ndev, void *data)
dev = create_chan(ndev, ci, &cp);
if (!dev)
return -EBUSY;
-   ret = mkret(c4_new_chan(ci, cp.port, cp.channum, dev));
-   if (ret) {
+   ret = c4_new_chan(ci, cp.port, cp.channum, dev);
+   if (ret < 0) {
/* needed due to Ioctl calling seq

Generic HSI client DT bindings

[Sebastian Reichel]

Hi,

I'm currently working on Device Tree support for the HSI subsystem
to get the Nokia N900 modem working in the mainline kernel. I guess
the key question for the binding has been asked by Mark:

Mark Rutland  wrote [0]:
> Does HSI have an addressing scheme, or does each port
> have a single device?

It's easy to answer the question in an abstract way: A HSI link
connects two processors with each other providing multiple logical
channels. The problem is, that only the physical layer is specified
AFAIK (I do not have access to HSI specification, so I do not know
for sure). Thus the exact usage of the channels is vendor specific.

For the Nokia N900 modem the following one of the following bindings
seem senseful to me:

= Variant A =
hsi-port {
/* some nodes describing the port */

n900_modem: client-device {
compatible = "nokia,n900-modem";
reg = <0>, <1>, <2>, <3>;
reg-names = "mcsaab-control",
"speech-control",
"mcsaab-data",
"speech-data";
hsi-mode = "stream";
hsi-speed-kbps = <55000>;
hsi-flow = "synchronized";
hsi-arb-mode = "round-robin";
};
};
#

= Variant B =
hsi-port {
/* some nodes describing the port */

cmt_mcsaab: client-device@0 {
compatible = "nokia,mcsaab-protocol";
reg = <0>, <2>;
reg-names = "mcsaab-control",
"mcsaab-data";
hsi-mode = "stream";
hsi-channels = <4>;
hsi-speed-kbps = <55000>;
hsi-flow = "synchronized";
hsi-arb-mode = "round-robin";
};

cmt_speech: client-device@1 {
compatible = "nokia,cmt-speech";
reg = <1>, <4>;
reg-names = "speech-control",
"speech-data";
hsi-mode = "stream";
hsi-channels = <4>;
hsi-speed-kbps = <55000>;
hsi-flow = "synchronized";
hsi-arb-mode = "round-robin";
};
};
#

Both bindings are simplified and do not map all of the hardware's
capabilities: Some settings can be configured differently for RX and
TX. It should be easy to extend the support for e.g. hsi-mode-rx
and hsi-mode-tx once this is needed. For devices configuring them
the same having just one node seems better to me (I assume almost
all devices want them to be the same).

As far as I can see only ST-Erricson has also HSI clients prepared
for the mainline kernel. It would be nice to get some feedback from
you. If you know more HSI users, which are not yet Cc'd please feel
free to point them here.

[0] http://article.gmane.org/gmane.linux.kernel/1654456

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls

[David Lang]

On Sun, 9 Mar 2014, Ben Hutchings wrote:


On Sun, 2014-03-09 at 18:53 -0400, David Miller wrote:

From: Ben Hutchings 
Date: Sun, 09 Mar 2014 19:09:20 +


On Thu, 2014-03-06 at 16:06 -0500, David Miller wrote:

From: Marc Kleine-Budde 
Date: Wed,  5 Mar 2014 00:49:47 +0100


@@ -839,7 +839,7 @@ void dev_deactivate_many(struct list_head *head)
  /* Wait for outstanding qdisc_run calls. */
  list_for_each_entry(dev, head, unreg_list)
  while (some_qdisc_is_busy(dev))
- yield();
+ msleep(1)
 }


I don't understand this.

yield() should really _mean_ yield.

The intent of a yield() call, like this one here, is unambiguously
that the current thread cannot do anything until some other thread
gets onto the cpu and makes forward progress.

Therefore it should allow lower priority threads to run, not just
equal or higher priority ones.


Until when?

yield() is not a sensible operation in a preemptive multitasking system,
regardless of RT.


To me it means "I've got nothing to do if other tasks want to run right
now"  Yes, I even see it having this meaning when an RT task executes
it.

How else can you interpret the intent above?


The problem is that 'I've got nothing to do ... now' is information
about a *point* in time, which gives the scheduler no clue as to when
this task might be ready again.  So far as task *state* goes, it never
ceases to be ready.


If you change it to msleep(1), you're assigning an extra completely
arbitrary time limit to the yield.  The code doesn't want to sleep
for 1ms, that's not what it's asking for.

[...]

I think you want to give up a 'time slice' to any task that's available.
But that's not a meaningful concept for all schedulers.  If your task is
highest priority and is ready, it must run.  You could drop priority
temporarily, but then you need it to somehow be bumped up again at some
time in the future.  Well, sleeping effectively does that.

I do understand that unconditionally sleeping also isn't ideal - the
task that unblocks this one might already be running on another CPU and
able to finish sooner than the sleep timeout.

Maybe the answer is a yield_for(time) which sleeps for the given time or
until there's an idle CPU, whichever is sooner.  But I don't know how
hard that would be to implement or how widely useful it would be.


what is msleep(0) defined to do? would it be any better?

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

Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

[Sebastian Hesselbarth]

On 03/10/2014 12:12 AM, David Miller wrote:

From: Sebastian Hesselbarth 
Date: Fri,  7 Mar 2014 12:34:52 +0100


commit 1211ce53077164e0d34641d0ca5fb4d4a7574498
   ("net: phy: resume/suspend PHYs on attach/detach")
introduced a feature to suspend PHYs when entering halted state.

Unfortunately, not all bootloaders properly power-up PHYs on reset
and fail to access ethernet because the PHY is still powered down.

Therefore, this adds code and documentation for a sysfs attribute to
allow/deny PHYs to be suspended on a per-PHY basis. Disabling that
attribute prevents PHYs from being suspended when entering halted state.

Signed-off-by: Sebastian Hesselbarth 
Reported-by: Andrew Lunn 


I know you won't like what I have to say, but I want to see a solution
without this sysfs knob.

First of all, you obviously have a way to end up having the sysfs knob
get set on the appropriate systems.

Therefore, you obviously have some way to propagate the same piece of
information into the kernel somehow during boot time.

For example, via a device tree property or similar.


There is no way to determine if a bootloader is broken or not. The
sysfs knob allows to provide a use case based decision. Of course, we
can invent some freaky device tree property but that the DT maintainers
will not like either.

This is not an issue with broken HW but SW. The PHY is fine, you can
suspend and resume it perfectly in Linux. But the bootloader fails to
properly initialize it on a warm boot. You could update the bootloader
and the issue disappears.


Please pursue an avenue such as that.  This sysfs thing, it's a user
facing interface we'd have to live with forever.


If you want me to try a devicetree property for the issue, we also
create ABI and we will have to live with it forever.

I am open for suggestions, but I have a bad feeling about a "broken
bootloader" DT property.

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/

Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls

[Ben Hutchings]

On Sun, 2014-03-09 at 18:53 -0400, David Miller wrote:
> From: Ben Hutchings 
> Date: Sun, 09 Mar 2014 19:09:20 +
> 
> > On Thu, 2014-03-06 at 16:06 -0500, David Miller wrote:
> >> From: Marc Kleine-Budde 
> >> Date: Wed,  5 Mar 2014 00:49:47 +0100
> >> 
> >> > @@ -839,7 +839,7 @@ void dev_deactivate_many(struct list_head *head)
> >> >   /* Wait for outstanding qdisc_run calls. */
> >> >   list_for_each_entry(dev, head, unreg_list)
> >> >   while (some_qdisc_is_busy(dev))
> >> > - yield();
> >> > + msleep(1)
> >> >  }
> >> 
> >> I don't understand this.
> >> 
> >> yield() should really _mean_ yield.
> >> 
> >> The intent of a yield() call, like this one here, is unambiguously
> >> that the current thread cannot do anything until some other thread
> >> gets onto the cpu and makes forward progress.
> >>
> >> Therefore it should allow lower priority threads to run, not just
> >> equal or higher priority ones.
> > 
> > Until when?
> > 
> > yield() is not a sensible operation in a preemptive multitasking system,
> > regardless of RT.
> 
> To me it means "I've got nothing to do if other tasks want to run right
> now"  Yes, I even see it having this meaning when an RT task executes
> it.
> 
> How else can you interpret the intent above?

The problem is that 'I've got nothing to do ... now' is information
about a *point* in time, which gives the scheduler no clue as to when
this task might be ready again.  So far as task *state* goes, it never
ceases to be ready.

> If you change it to msleep(1), you're assigning an extra completely
> arbitrary time limit to the yield.  The code doesn't want to sleep
> for 1ms, that's not what it's asking for.
[...]

I think you want to give up a 'time slice' to any task that's available.
But that's not a meaningful concept for all schedulers.  If your task is
highest priority and is ready, it must run.  You could drop priority
temporarily, but then you need it to somehow be bumped up again at some
time in the future.  Well, sleeping effectively does that.

I do understand that unconditionally sleeping also isn't ideal - the
task that unblocks this one might already be running on another CPU and
able to finish sooner than the sleep timeout.

Maybe the answer is a yield_for(time) which sleeps for the given time or
until there's an idle CPU, whichever is sooner.  But I don't know how
hard that would be to implement or how widely useful it would be.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


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

Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

[David Miller]

From: Sebastian Hesselbarth 
Date: Fri,  7 Mar 2014 12:34:52 +0100

> commit 1211ce53077164e0d34641d0ca5fb4d4a7574498
>   ("net: phy: resume/suspend PHYs on attach/detach")
> introduced a feature to suspend PHYs when entering halted state.
> 
> Unfortunately, not all bootloaders properly power-up PHYs on reset
> and fail to access ethernet because the PHY is still powered down.
> 
> Therefore, this adds code and documentation for a sysfs attribute to
> allow/deny PHYs to be suspended on a per-PHY basis. Disabling that
> attribute prevents PHYs from being suspended when entering halted state.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Andrew Lunn 

I know you won't like what I have to say, but I want to see a solution
without this sysfs knob.

First of all, you obviously have a way to end up having the sysfs knob
get set on the appropriate systems.

Therefore, you obviously have some way to propagate the same piece of
information into the kernel somehow during boot time.

For example, via a device tree property or similar.

Please pursue an avenue such as that.  This sysfs thing, it's a user
facing interface we'd have to live with forever.
--
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] netlink: switch net_ns only if net is not init_net

[David Miller]

From: Gu Zheng 
Date: Fri, 07 Mar 2014 18:47:30 +0800

> Many netlink users create netlink sock in the init_net, and the
> switching nes_ns(init_net-->net) is needless in this case. So here
> we add a pre-check to avoid this.
> 
> Signed-off-by: Gu Zheng 

This check is more appropriately placed into sk_change_net() itself.
--
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/