linux.kernel - 26 new messages in 17 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* linux-next: Tree for Jan 10 (drivers/media/mmc/siano/smssdio.c) - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/03eeed573d2f7d6e?hl=en
* mm, memcg: avoid oom notification when current needs access to memory
reserves - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ddffce70f2a0b5fc?hl=en
* misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c3af64c6af02e0ba?hl=en
* [PATCH] xen-blkfront: remove type check from blkfront_setup_discard - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/2129dbb7e1284afc?hl=en
* Staging: rtl8188eu: Fixed whitespace related coding style issues - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f60be82cc9fe91a0?hl=en
* lib: radix_tree: tree node interface - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8cc6f8a99500ab70?hl=en
* hwmon: (max197) add include guard - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/726c6a173c5a8f70?hl=en
* LED fix for 3.13 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1837b3b231e8ca0b?hl=en
* Unable to load modules from 9p filesystem with kmod 16 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/57bf21c25663646c?hl=en
* PCI: Only enable realloc auto when root bus has 64bit mmio - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/331f805b0100944b?hl=en
* Input: synaptics-rmi4 - switch to using i2c_transfer() - 4 messages, 1
author
http://groups.google.com/group/linux.kernel/t/127bd12f65fad9d0?hl=en
* re-shrink 'struct page' when SLUB is on. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d6d1692f51c2de27?hl=en
* VELGØRENHED BISTAND - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/314062796b286406?hl=en
* Documentation: DT: omap-ssi binding documentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eeb43e2db54d8847?hl=en
* lib/vsprintf: add %pT format specifier - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/798326cec82e4895?hl=en
* ACPI/SCAN: _STA status read - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/332c7e2cd251892f?hl=en
* APM - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8506cae9a47bc63?hl=en

==============================================================================
TOPIC: linux-next: Tree for Jan 10 (drivers/media/mmc/siano/smssdio.c)
http://groups.google.com/group/linux.kernel/t/03eeed573d2f7d6e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 2:40 pm
From: Randy Dunlap


On 01/09/2014 09:12 PM, Stephen Rothwell wrote:
> Hi all,
>
> This tree fails (more than usual) the powerpc allyesconfig build.
>
> Changes since 20140109:
>

on i386 with:
CONFIG_SMS_SIANO_MDTV=m
CONFIG_SMS_SIANO_RC=y


drivers/built-in.o: In function `smssdio_remove':
smssdio.c:(.text+0x445e97): undefined reference to `smscore_putbuffer'
smssdio.c:(.text+0x445e9f): undefined reference to `smscore_unregister_device'
drivers/built-in.o: In function `smssdio_interrupt':
smssdio.c:(.text+0x445f47): undefined reference to `smscore_getbuffer'
smssdio.c:(.text+0x44606f): undefined reference to `smsendian_handle_rx_message'
smssdio.c:(.text+0x446079): undefined reference to `smscore_onresponse'
smssdio.c:(.text+0x4460f0): undefined reference to `smscore_putbuffer'
smssdio.c:(.text+0x446159): undefined reference to `smscore_putbuffer'
drivers/built-in.o: In function `smssdio_sendrequest':
smssdio.c:(.text+0x4461e3): undefined reference to `smsendian_handle_tx_message'
drivers/built-in.o: In function `smssdio_probe':
smssdio.c:(.text+0x446325): undefined reference to `sms_get_board'
smssdio.c:(.text+0x44635b): undefined reference to `smscore_register_device'
smssdio.c:(.text+0x446385): undefined reference to `smscore_set_board_id'
smssdio.c:(.text+0x44641f): undefined reference to `smscore_start_device'
smssdio.c:(.text+0x44645e): undefined reference to `smscore_unregister_device'



Full randconfig file is attached.

--
~Randy





==============================================================================
TOPIC: mm, memcg: avoid oom notification when current needs access to memory
reserves
http://groups.google.com/group/linux.kernel/t/ddffce70f2a0b5fc?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 2:40 pm
From: Johannes Weiner


On Fri, Jan 10, 2014 at 01:38:50PM -0800, David Rientjes wrote:
> On Fri, 10 Jan 2014, Michal Hocko wrote:
>
> > I have already explained why I have acked it. I will not repeat
> > it here again. I have also proposed an alternative solution
> > (https://lkml.org/lkml/2013/12/12/174) which IMO is more viable because
> > it handles both user/kernel memcg OOM consistently. This patch still has
> > to be discussed because of other Johannes concerns. I plan to repost it
> > in a near future.
> >
>
> This three ring circus has to end. Really.
>
> Your patch, which is partially based on my suggestion to move the
> mem_cgroup_oom_notify() and call it from two places to support both
> memory.oom_control == 1 and != 1, is something that I liked as you know.
> It's based on my patch which is now removed from -mm. So if you want to
> rebase that patch and propose it, that's great, but this is yet another
> occurrence of where important patches have been yanked out just before the
> merge window when the problem they are fixing is real and we depend on
> them.

We tried to discuss and understand the problem, yet all we got was
"it's OBVIOUS" and "Google has been using this patch ever since we
switched to memcg" and flat out repetitions of the same points about
reliable OOM notification that were already put into question.

You still have not convinced me that the problem exists as you
described it, apart from the aspects that Michal is now fixing
separately because you did not show any signs of cooperating.

None of this will change until you start working with us and actually
address feedback and inquiries instead of just repeating your talking
points over and over.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic
Manager
http://groups.google.com/group/linux.kernel/t/c3af64c6af02e0ba?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 2:50 pm
From: Ravi Patel


On Sun, Jan 5, 2014 at 12:48 PM, Ravi Patel <rapatel@apm.com> wrote:
> On Sun, Jan 5, 2014 at 10:11 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sunday 05 January 2014, Ravi Patel wrote:
>>> On Sat, Dec 21, 2013 at 11:03 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> >
>>> > Please describe here what the purpose of the qmtm is, as this is not
>>> > entirely clear from the code or from your reply.
>>> >
>>> > Greg was guessing that it's a bus controller, my best guess is a DMA
>>> > engine. If it's something completely different, you have to let
>>> > us know what it is so we can do a proper review rather than guessing.
>>> >
>>> > Please provide a link to the data sheet if you are unable to explain.
>>>
>>> Here is URL to a text document explaining role of QMTM device with CPU, Ethernet
>>> subsystem.
>>>
>>> https://drive.google.com/file/d/0B28TgQZ3JLoRRGNnbjJoUGNHWW8/edit?usp=sharing
>>>
>>> For simplicity, I have shown only Ethernet.
>>> PktDMA and Security subsystem interfaces with QMTM in the same way as Ethernet.
>>
>> Thanks, that helps a lot. Please add this file to an appropriate place
>> in the Documentation directory in the next version of your patches.
>>
>> There is still one central aspect that remains unclear to me, which is
>> what the QMTM is actually good for, as opposed to how it gets used from
>> the OS.
>
> The document shows the run-time flow of messages between CPU, QMTM and Ethernet.
> QMTM is a centralized resource manager/driver which exports APIs to
> 1. Initialize & allocate queue & pbn to the Ethernet, PktDMA and
> Security subsystem.
> 2. Read queue state so that subsystems driver knows how much more work
> it can offload
> to its subsystem.
> 3. Apply QoS for subsystems on their queues.
>
>> In the text description, it sounds like the ethernet is the DMA
>> master and performs DMA all by itself but from that it's not clear why
>> a message to and from the QMTM is needed. From your drawing on the other
>> hand, it seems like the QMTM is really the DMA master and performs the
>> DMA on behalf of the ethernet device, which isn't connected to the
>> coherent interface itself. If this is correct, it seems that QMTM is more
>> like a DMA engine after all that should use the existing slave API to
>> provide services to slave drivers.
>
> Each subsystem defines their own format of work message.
> A message (or queue descriptor) has attribute fields (QMTM specific)
> which is common
> for all subsystem work messages.
> The remaining fields of a message are specific to subsystem.
> QMTM device doesn't have any knowledge of these subsystem specific
> fields and the data
> operation which subsystem is going to perform using these fields.
> e.g.
> 1. Ethernet work message includes data address & length which is used
> by Ethernet
> DMA engine for copying the data to/from its internal FIFO
> 2. PktDMA work message includes multiple data addresses & lengths for
> doing scatter/gather,
> XOR operations and result data address/es to give back result to the
> CPU (driver)
> 3. Security work message includes data address & length for doing
> encryption or decryption,
> the type of encryption or decryption and result data address to give
> back result to the CPU (driver)

Do you want any further clarification or document related to QMTM.
We want to make sure everyone is on same page, understand and
conclude upon that QMTM is a device and and not a bus or a dma
engine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: [PATCH] xen-blkfront: remove type check from blkfront_setup_discard
http://groups.google.com/group/linux.kernel/t/2129dbb7e1284afc?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 10 2014 2:50 pm
From: Olaf Hering


On Fri, Jan 10, Boris Ostrovsky wrote:

> I think we should at clear feature_discard and print an error in the log if
> *either* of xenbus_gather() calls fail.

Are you sure about that? AFAIK many other properties are optional as
well. I dont think there is a formal spec about the discard related
properties. Should every backend be required to provide all four
properties?

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




== 2 of 2 ==
Date: Fri, Jan 10 2014 3:00 pm
From: Boris Ostrovsky


On 01/10/2014 05:49 PM, Olaf Hering wrote:
> On Fri, Jan 10, Boris Ostrovsky wrote:
>
>> I think we should at clear feature_discard and print an error in the log if
>> *either* of xenbus_gather() calls fail.
> Are you sure about that? AFAIK many other properties are optional as
> well. I dont think there is a formal spec about the discard related
> properties. Should every backend be required to provide all four
> properties?

It's not whether the properties are required or not. It's that they may
have been set by the admin but we ignored them. I am particularly
concerned about security setting.

Can you determine from the error whether the call failed or the property
wasn't available?

Alternatively, we may have to require the toolstack that if
feature-discard is provided then all three of these are provided as
well. And then you disable discard on any error.

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





==============================================================================
TOPIC: Staging: rtl8188eu: Fixed whitespace related coding style issues
http://groups.google.com/group/linux.kernel/t/f60be82cc9fe91a0?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 3:00 pm
From: Tim Jester-Pfadt


This patch fixes two spaces at the start of the line aswell as all space after
opening parenthesis and space before closeing parenthesis checkpatch.pl warnings
in rtw_mlme.h

Signed-off-by: Tim Jester-Pfadt <t.jp@gmx.de>
---
drivers/staging/rtl8188eu/include/rtw_mlme.h | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme.h b/drivers/staging/rtl8188eu/include/rtw_mlme.h
index 33965ca..144f79c 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme.h
@@ -129,17 +129,17 @@ struct rt_link_detect {

struct profile_info {
u8 ssidlen;
- u8 ssid[ WLAN_SSID_MAXLEN ];
- u8 peermac[ ETH_ALEN ];
+ u8 ssid[WLAN_SSID_MAXLEN];
+ u8 peermac[ETH_ALEN];
};

struct tx_invite_req_info {
u8 token;
u8 benable;
- u8 go_ssid[ WLAN_SSID_MAXLEN ];
+ u8 go_ssid[WLAN_SSID_MAXLEN];
u8 ssidlen;
- u8 go_bssid[ ETH_ALEN ];
- u8 peer_macaddr[ ETH_ALEN ];
+ u8 go_bssid[ETH_ALEN];
+ u8 peer_macaddr[ETH_ALEN];
u8 operating_ch; /* This information will be set by using the
* p2p_set op_ch=x */
u8 peer_ch; /* The listen channel for peer P2P device */
@@ -182,9 +182,9 @@ struct tx_nego_req_info {
};

struct group_id_info {
- u8 go_device_addr[ ETH_ALEN ]; /* The GO's device address of
+ u8 go_device_addr[ETH_ALEN]; /* The GO's device address of
* this P2P group */
- u8 ssid[ WLAN_SSID_MAXLEN ]; /* The SSID of this P2P group */
+ u8 ssid[WLAN_SSID_MAXLEN]; /* The SSID of this P2P group */
};

struct scan_limit_info {
@@ -388,7 +388,7 @@ struct mlme_priv {
u8 *assoc_rsp;
u32 assoc_rsp_len;

-#if defined (CONFIG_88EU_AP_MODE)
+#if defined(CONFIG_88EU_AP_MODE)
/* Number of associated Non-ERP stations (i.e., stations using 802.11b
* in 802.11g BSS) */
int num_sta_non_erp;
@@ -472,7 +472,7 @@ void rtw_join_timeout_handler(void *FunctionContext);
void _rtw_scan_timeout_handler(void *FunctionContext);
void rtw_free_network_queue(struct adapter *adapter, u8 isfreeall);
int rtw_init_mlme_priv(struct adapter *adapter);
-void rtw_free_mlme_priv (struct mlme_priv *pmlmepriv);
+void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv);
int rtw_select_and_join_from_scanned_queue(struct mlme_priv *pmlmepriv);
int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv,
int keyid, u8 set_tx);
@@ -572,7 +572,7 @@ struct wlan_network *rtw_get_oldest_wlan_network(struct __queue *scanned_queue);
void rtw_free_assoc_resources(struct adapter *adapter, int lock_scanned_queue);
void rtw_indicate_disconnect(struct adapter *adapter);
void rtw_indicate_connect(struct adapter *adapter);
-void rtw_indicate_scan_done( struct adapter *padapter, bool aborted);
+void rtw_indicate_scan_done(struct adapter *padapter, bool aborted);
void rtw_scan_abort(struct adapter *adapter);

int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie,
@@ -588,7 +588,7 @@ void rtw_get_encrypt_decrypt_from_registrypriv(struct adapter *adapter);
void _rtw_join_timeout_handler(struct adapter *adapter);
void rtw_scan_timeout_handler(struct adapter *adapter);

- void rtw_dynamic_check_timer_handlder(struct adapter *adapter);
+void rtw_dynamic_check_timer_handlder(struct adapter *adapter);
#define rtw_is_scan_deny(adapter) false
#define rtw_clear_scan_deny(adapter) do {} while (0)
#define rtw_set_scan_deny_timer_hdl(adapter) do {} while (0)
@@ -605,7 +605,7 @@ int _rtw_enqueue_network(struct __queue *queue, struct wlan_network *pnetwork);

struct wlan_network *_rtw_dequeue_network(struct __queue *queue);

- struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv);
+struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv);


void _rtw_free_network(struct mlme_priv *pmlmepriv,
--
1.8.5.2

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





==============================================================================
TOPIC: lib: radix_tree: tree node interface
http://groups.google.com/group/linux.kernel/t/8cc6f8a99500ab70?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 10 2014 3:00 pm
From: Rik van Riel


On 01/10/2014 01:10 PM, Johannes Weiner wrote:
> Make struct radix_tree_node part of the public interface and provide
> API functions to create, look up, and delete whole nodes. Refactor
> the existing insert, look up, delete functions on top of these new
> node primitives.
>
> This will allow the VM to track and garbage collect page cache radix
> tree nodes.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>

Reviewed-by: Rik van Riel <riel@redhat.com>


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




== 2 of 3 ==
Date: Fri, Jan 10 2014 3:00 pm
From: Rik van Riel


On 01/10/2014 01:10 PM, Johannes Weiner wrote:

> This patch solves one half of the problem by decoupling the ability to
> detect working set changes from the inactive list size. By
> maintaining a history of recently evicted file pages it can detect
> frequently used pages with an arbitrarily small inactive list size,
> and subsequently apply pressure on the active list based on actual
> demand for cache, not just overall eviction speed.
>
> Every zone maintains a counter that tracks inactive list aging speed.
> When a page is evicted, a snapshot of this counter is stored in the
> now-empty page cache radix tree slot. On refault, the minimum access
> distance of the page can be assessed, to evaluate whether the page
> should be part of the active list or not.
>
> This fixes the VM's blindness towards working set changes in excess of
> the inactive list. And it's the foundation to further improve the
> protection ability and reduce the minimum inactive list size of 50%.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>

Reviewed-by: Rik van Riel <riel@redhat.com>

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




== 3 of 3 ==
Date: Fri, Jan 10 2014 3:20 pm
From: Rik van Riel


On 01/10/2014 01:10 PM, Johannes Weiner wrote:
> Previously, page cache radix tree nodes were freed after reclaim
> emptied out their page pointers. But now reclaim stores shadow
> entries in their place, which are only reclaimed when the inodes
> themselves are reclaimed. This is problematic for bigger files that
> are still in use after they have a significant amount of their cache
> reclaimed, without any of those pages actually refaulting. The shadow
> entries will just sit there and waste memory. In the worst case, the
> shadow entries will accumulate until the machine runs out of memory.
>
> To get this under control, the VM will track radix tree nodes
> exclusively containing shadow entries on a per-NUMA node list.
> Per-NUMA rather than global because we expect the radix tree nodes
> themselves to be allocated node-locally and we want to reduce
> cross-node references of otherwise independent cache workloads. A
> simple shrinker will then reclaim these nodes on memory pressure.

> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>

Reviewed-by: Rik van Riel <riel@redhat.com>

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





==============================================================================
TOPIC: hwmon: (max197) add include guard
http://groups.google.com/group/linux.kernel/t/726c6a173c5a8f70?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 10 2014 3:10 pm
From: Guenter Roeck


On 01/10/2014 01:44 PM, Vivien Didelot wrote:
> Add include guard to include/linux/platform_data/max197.h to prevent
> multiple inclusion.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> ---

Applied to hwmon-next.

Thanks,
Guenter

> include/linux/platform_data/max197.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/platform_data/max197.h b/include/linux/platform_data/max197.h
> index e2a41dd..8da8f94 100644
> --- a/include/linux/platform_data/max197.h
> +++ b/include/linux/platform_data/max197.h
> @@ -11,6 +11,9 @@
> * For further information, see the Documentation/hwmon/max197 file.
> */
>
> +#ifndef _PDATA_MAX197_H
> +#define _PDATA_MAX197_H
> +
> /**
> * struct max197_platform_data - MAX197 connectivity info
> * @convert: Function used to start a conversion with control byte ctrl.
> @@ -19,3 +22,5 @@
> struct max197_platform_data {
> int (*convert)(u8 ctrl);
> };
> +
> +