Re: is L1 really disabled in iwlwifi

[Emmanuel Grumbach]

>
> I couldn't imagine that silently ignoring the request to disable ASPM
> would be the right thing, but I spent a long time experimenting with
> Windows on qemu, and I think you're right.  Windows 7 also seems to
> ignore the "PciASPMOptOut" directive when we don't have permission
> to manage ASPM.  All the gory details are at
> https://bugzilla.kernel.org/show_bug.cgi?id=57331
>
> The current behavior is definitely confusing.  I hate to rename or change
> pci_disable_link_state() because it's exported and we'd have to maintain
> the old interface for a while anyway.  And I don't really want to return
> failure to drivers, because I think that would encourage people to fiddle
> with the Link Control register directly in the driver, which doesn't seem
> like a good idea.
>
> And you're also right that (as far as I know) there's not an actual
> problem with the current behavior other than the confusion it causes.
>
> So, how about something like the following patch, which just prints a
> warning when we can't do what the driver requested?  I suppose this may
> also be a nuisance, because users will be worried, but they can't actually
> *do* anything about it.  Maybe it should be dev_info() instead.
>

Good for me - now I would be notified that something wrong happened.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Consult] Why need we call device_remove_file() firstly before call device_unregister() ?

[Chen Gang]

Hello All:

I searched 'arch/*' and 'drivers/*' sub-directory, all of them are 'obey
this rule', even in device_unregister() itself, it also firstly calls
device_remove_file(), then call kobject_del().

But after read the related code (fs/sysfs/*, drivers/base/core.c), it
seems kobject_del() -> sysfs_remove_dir() which will release all related
things (can instead of device_remove_file()).

So in fact, we need not call device_remove_file() before call
device_unregister(), is it correct ?


Welcome any member to give a suggestion or completion about it, thanks.


Thanks.
-- 
Chen Gang

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

Re: [PATCH v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[H. Peter Anvin]

On 05/16/2013 09:29 PM, Eric W. Biederman wrote:
> 
> Whatever theoretical issues you have with /dev/oldmem and /proc/vmcore
> can and should be talked about and addressed independently of these
> changes.

And they are... last I know Dave Hansen was looking at it.

-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] ARM: OMAP4: change the device names in usb_bind_phy

[Kishon Vijay Abraham I]

Hi,

On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote:

* Tomi Valkeinen  [130516 09:11]:

On 16/05/13 18:58, Tony Lindgren wrote:

* Tomi Valkeinen  [130515 03:59]:

Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
like the some transceivers should depend on that for omap4.


Yes, I have OCP2SCP=y.


Hmm well no idea beyond that then. Sounds like Kishon should check it.


The musb-hdrc id is wrong on overo also.


Hmm has there been a fix posted for that?


I couldn't find with a quick look. We debugged and discussed this on an irc
channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
on overo fixed the issue, and it looks very similar to the error on 4430sdp.
The overo fix was just:


hmm.. I think using device name to bind the controller and the phy can 
no longer be used reliably. I think it's better to have something like 
what Grant suggested in my other patch series.. to have the phy 
reference into the host controllers platform_data structure. And for the 
phy reference I'll have label and id.


Does this makes sense to you?

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

[PATCHv6 2/3] net: velocity: Convert to generic dma functions

[Tony Prisk]

Remove the pci_* dma functions and replace with the more generic
versions.

In preparation of adding platform support, a new struct device *dev
is added to struct velocity_info which can be used by both the pci
and platform code.

Signed-off-by: Tony Prisk 
---
 drivers/net/ethernet/via/via-velocity.c |   51 +++
 drivers/net/ethernet/via/via-velocity.h |1 +
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index 187eef3..5996cee 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1459,7 +1460,6 @@ static int velocity_init_dma_rings(struct velocity_info 
*vptr)
struct velocity_opt *opt = >options;
const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
-   struct pci_dev *pdev = vptr->pdev;
dma_addr_t pool_dma;
void *pool;
unsigned int i;
@@ -1467,13 +1467,13 @@ static int velocity_init_dma_rings(struct velocity_info 
*vptr)
/*
 * Allocate all RD/TD rings a single pool.
 *
-* pci_alloc_consistent() fulfills the requirement for 64 bytes
+* dma_alloc_coherent() fulfills the requirement for 64 bytes
 * alignment
 */
-   pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
-   rx_ring_size, _dma);
+   pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
+   rx_ring_size, _dma, GFP_ATOMIC);
if (!pool) {
-   dev_err(>dev, "%s : DMA memory allocation failed.\n",
+   dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
vptr->netdev->name);
return -ENOMEM;
}
@@ -1524,8 +1524,8 @@ static int velocity_alloc_rx_buf(struct velocity_info 
*vptr, int idx)
 */
skb_reserve(rd_info->skb,
64 - ((unsigned long) rd_info->skb->data & 63));
-   rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
-   vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+   rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
+   vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
/*
 *  Fill in the descriptor to match
@@ -1588,8 +1588,8 @@ static void velocity_free_rd_ring(struct velocity_info 
*vptr)
 
if (!rd_info->skb)
continue;
-   pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-PCI_DMA_FROMDEVICE);
+   dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+DMA_FROM_DEVICE);
rd_info->skb_dma = 0;
 
dev_kfree_skb(rd_info->skb);
@@ -1670,7 +1670,7 @@ static void velocity_free_dma_rings(struct velocity_info 
*vptr)
const int size = vptr->options.numrx * sizeof(struct rx_desc) +
vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
 
-   pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
+   dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
 }
 
 static int velocity_init_rings(struct velocity_info *vptr, int mtu)
@@ -1727,8 +1727,8 @@ static void velocity_free_tx_buf(struct velocity_info 
*vptr,
pktlen = max_t(size_t, pktlen,
td->td_buf[i].size & ~TD_QUEUE);
 
-   pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
-   le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
+   dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
+   le16_to_cpu(pktlen), DMA_TO_DEVICE);
}
}
dev_kfree_skb_irq(skb);
@@ -1750,8 +1750,8 @@ static void velocity_free_td_ring_entry(struct 
velocity_info *vptr,
if (td_info->skb) {
for (i = 0; i < td_info->nskb_dma; i++) {
if (td_info->skb_dma[i]) {
-   pci_unmap_single(vptr->pdev, 
td_info->skb_dma[i],
-   td_info->skb->len, PCI_DMA_TODEVICE);
+   dma_unmap_single(vptr->dev, td_info->skb_dma[i],
+   td_info->skb->len, DMA_TO_DEVICE);
td_info->skb_dma[i] = 0;
}
}
@@ -2029,7 +2029,6 @@ static inline void velocity_iph_realign(struct 
velocity_info *vptr,
  */
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
-   void 

[PATCHv6 3/3] net: velocity: Add platform device support to VIA velocity driver

[Tony Prisk]

Add support for the VIA Velocity network driver to be bound to a
OF created platform device.

Signed-off-by: Tony Prisk 
---
 .../devicetree/bindings/net/via-velocity.txt   |   20 +
 drivers/net/ethernet/via/Kconfig   |3 +-
 drivers/net/ethernet/via/via-velocity.c|  388 ++--
 drivers/net/ethernet/via/via-velocity.h|   32 +-
 4 files changed, 321 insertions(+), 122 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt 
b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+   devices quite often set this data in uboot and do not provide an eeprom.
+   Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0@d8004000 {
+   compatible = "via,velocity-vt6110";
+   reg = <0xd8004000 0x400>;
+   interrupts = <10>;
+   no-eeprom;
+};
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 68a9ba6..6a87097 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -5,7 +5,6 @@
 config NET_VENDOR_VIA
bool "VIA devices"
default y
-   depends on PCI
---help---
  If you have a network (Ethernet) card belonging to this class, say Y
  and read the Ethernet-HOWTO, available from
@@ -45,7 +44,7 @@ config VIA_RHINE_MMIO
 
 config VIA_VELOCITY
tristate "VIA Velocity support"
-   depends on PCI
+   depends on (PCI || USE_OF)
select CRC32
select CRC_CCITT
select NET_CORE
diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index 5996cee..b30ab62 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -65,7 +65,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -84,6 +88,16 @@
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
+static void velocity_set_power_state(struct velocity_info *vptr, char state)
+{
+   void *addr = vptr->mac_regs;
+
+   if (vptr->bustype == BUS_PCI)
+   pci_set_power_state(vptr->pdev, state);
+   else
+   writeb(state, addr + 0x154);
+}
+
 /**
  * mac_get_cam_mask-   Read a CAM mask
  * @regs: register block for this velocity
@@ -362,12 +376,23 @@ static struct velocity_info_tbl chip_info_table[] = {
  * Describe the PCI device identifiers that we support in this
  * device driver. Used for hotplug autoloading.
  */
-static DEFINE_PCI_DEVICE_TABLE(velocity_id_table) = {
+
+static DEFINE_PCI_DEVICE_TABLE(velocity_pci_id_table) = {
{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X) },
{ }
 };
 
-MODULE_DEVICE_TABLE(pci, velocity_id_table);
+MODULE_DEVICE_TABLE(pci, velocity_pci_id_table);
+
+/**
+ * Describe the OF device identifiers that we support in this
+ * device driver. Used for devicetree nodes.
+ */
+static struct of_device_id velocity_of_ids[] = {
+   { .compatible = "via,velocity-vt6110", .data = _info_table[0] },
+   { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, velocity_of_ids);
 
 /**
  * get_chip_name   -   identifier to name
@@ -386,29 +411,6 @@ static const char *get_chip_name(enum chip_type chip_id)
 }
 
 /**
- * velocity_remove1-   device unplug
- * @pdev: PCI device being removed
- *
- * Device unload callback. Called on an unplug or on module
- * unload for each active device that is present. Disconnects
- * the device from the network layer and frees all the resources
- */
-static void velocity_remove1(struct pci_dev *pdev)
-{
-   struct net_device *dev = pci_get_drvdata(pdev);
-   struct velocity_info *vptr = netdev_priv(dev);
-
-   unregister_netdev(dev);
-   iounmap(vptr->mac_regs);
-   pci_release_regions(pdev);
-   pci_disable_device(pdev);
-   pci_set_drvdata(pdev, NULL);
-   free_netdev(dev);
-
-   velocity_nics--;
-}
-
-/**
  * velocity_set_int_opt-   parser for integer options
  * @opt: pointer to option value
  * @val: value the user requested (or -1 for default)
@@ -1181,6 +1183,17 @@ static void mii_init(struct velocity_info *vptr, u32 
mii_status)
u16 BMCR;
 
switch (PHYID_GET_PHY_ID(vptr->phy_id)) {
+   case PHYID_ICPLUS_IP101A:
+   

[PATCHv6 1/3] net: velocity: Rename vptr->dev to vptr->netdev

[Tony Prisk]

Improve the clarity of the code in preparation for converting the
dma functions to generic versions, which require a struct device *.

This makes it possible to store a 'struct device *dev' in the
velocity_info structure.

Signed-off-by: Tony Prisk 
---
 drivers/net/ethernet/via/via-velocity.c |   66 +++
 drivers/net/ethernet/via/via-velocity.h |4 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index fb62489..187eef3 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -998,9 +998,9 @@ static void velocity_print_link_status(struct velocity_info 
*vptr)
 {
 
if (vptr->mii_status & VELOCITY_LINK_FAIL) {
-   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect 
cable link\n", vptr->dev->name);
+   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect 
cable link\n", vptr->netdev->name);
} else if (vptr->options.spd_dpx == SPD_DPX_AUTO) {
-   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link 
auto-negotiation", vptr->dev->name);
+   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link 
auto-negotiation", vptr->netdev->name);
 
if (vptr->mii_status & VELOCITY_SPEED_1000)
VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps");
@@ -1014,7 +1014,7 @@ static void velocity_print_link_status(struct 
velocity_info *vptr)
else
VELOCITY_PRT(MSG_LEVEL_INFO, " half duplex\n");
} else {
-   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", 
vptr->dev->name);
+   VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", 
vptr->netdev->name);
switch (vptr->options.spd_dpx) {
case SPD_DPX_1000_FULL:
VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps full 
duplex\n");
@@ -1319,7 +1319,7 @@ static void velocity_init_registers(struct velocity_info 
*vptr,
case VELOCITY_INIT_RESET:
case VELOCITY_INIT_WOL:
 
-   netif_stop_queue(vptr->dev);
+   netif_stop_queue(vptr->netdev);
 
/*
 *  Reset RX to prevent RX pointer not on the 4X location
@@ -1332,7 +1332,7 @@ static void velocity_init_registers(struct velocity_info 
*vptr,
if (velocity_set_media_mode(vptr, mii_status) != 
VELOCITY_LINK_CHANGE) {
velocity_print_link_status(vptr);
if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-   netif_wake_queue(vptr->dev);
+   netif_wake_queue(vptr->netdev);
}
 
enable_flow_control_ability(vptr);
@@ -1354,7 +1354,7 @@ static void velocity_init_registers(struct velocity_info 
*vptr,
 
mac_eeprom_reload(regs);
for (i = 0; i < 6; i++)
-   writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));
+   writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
 
/*
 *  clear Pre_ACPI bit.
@@ -1377,7 +1377,7 @@ static void velocity_init_registers(struct velocity_info 
*vptr,
/*
 *  Set packet filter: Receive directed and broadcast 
address
 */
-   velocity_set_multi(vptr->dev);
+   velocity_set_multi(vptr->netdev);
 
/*
 *  Enable MII auto-polling
@@ -1404,14 +1404,14 @@ static void velocity_init_registers(struct 
velocity_info *vptr,
writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT), 
>CR0Set);
 
mii_status = velocity_get_opt_media_mode(vptr);
-   netif_stop_queue(vptr->dev);
+   netif_stop_queue(vptr->netdev);
 
mii_init(vptr, mii_status);
 
if (velocity_set_media_mode(vptr, mii_status) != 
VELOCITY_LINK_CHANGE) {
velocity_print_link_status(vptr);
if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-   netif_wake_queue(vptr->dev);
+   netif_wake_queue(vptr->netdev);
}
 
enable_flow_control_ability(vptr);
@@ -1474,7 +1474,7 @@ static int velocity_init_dma_rings(struct velocity_info 
*vptr)
rx_ring_size, _dma);
if (!pool) {
dev_err(>dev, "%s : DMA memory allocation failed.\n",
-   vptr->dev->name);
+   vptr->netdev->name);
return -ENOMEM;
}
 
@@ -1514,7 +1514,7 @@ static int velocity_alloc_rx_buf(struct velocity_info 
*vptr, int idx)
struct rx_desc *rd = &(vptr->rx.ring[idx]);
struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 
-   

[PATCHv6 0/3] Add support for velocity network driver on platform devices

[Tony Prisk]

v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simplify PM code to use velocity_(suspend/resume) - remove the individual
pci and platform functions.
Add a struct pci_dev variable to velocity_get_pci_info() to reduce churn

v5 changes:
Remove velocity_info union. Change velocity_info->pdev back to struct pci_dev.
Remove more 'if (pci)' sections.
Remove 'void *pdev' function parameters.
Pass correct variable to velocity_choose_state()

v4 changes:
Code tidyup as requested by Francois Romieu
Removed '#ifdef PCI' around PCI code. Compile tested on (!)PCI and (!)PM.

v3 changes:
Rebased against net-next.
Fix errors in pm code.

v2 changes:
Drop patch #1 as requested by David Miller.
Correct the PHYID_ICPLUS_IP101A MII bits - should be ON, rather than OFF.
Read the platform rev_id from the correct register [regs->rev_id]. It's possible
this would work for the PCI version as well and would remove the need for the
'if (pci)' test to set vptr->rev_id.

v1:
The first three patches are general tidyup.

[DROPPED] Patch ## just alphabetizes the #includes to make it easier to read.

Patch #1 replaces vptr->dev with vptr->netdev, in preparation of adding a
struct device *dev in Patch #2

Patch #2 replaces the pci dma functions with the generic versions.

I have build tested these patches but don't have a PCI velocity to run-test it.
I can't see that they should introduce any problems as it is all renames and
function swapping.

Patch #3 adds support for the velocity driver on devicetree platform devices.
Binding document included. This patch is compile-tested for PCI, and boot
tested on a VIA APC8750.

I think it would be pertinent to get some tested-by's for PCI users.

Regards
Tony Prisk


Tony Prisk (3):
  net: velocity: Rename vptr->dev to vptr->netdev
  net: velocity: Convert to generic dma functions
  net: velocity: Add platform device support to VIA velocity driver

 .../devicetree/bindings/net/via-velocity.txt   |   20 +
 drivers/net/ethernet/via/Kconfig   |3 +-
 drivers/net/ethernet/via/via-velocity.c|  497 +---
 drivers/net/ethernet/via/via-velocity.h|   35 +-
 4 files changed, 377 insertions(+), 178 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

-- 
1.7.9.5

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

Re: linux-next: build warning after merge of the final tree (in Linus' tree)

[Viresh Kumar]

On Wed, May 15, 2013 at 7:02 PM, Eric Paris  wrote:
> On Wed, 2013-05-15 at 13:20 +1000, Stephen Rothwell wrote:
>> Hi ,
>>
>> After merging the final tree, today's linux-next build (i386 defconfig)
>> produced this warning:
>>
>> kernel/auditfilter.c: In function 'audit_data_to_entry':
>> kernel/auditfilter.c:426:3: warning: this decimal constant is unsigned only 
>> in ISO C90 [enabled by default]
>>
>> Introduced by commit 780a7654cee8 ("audit: Make testing for a valid
>> loginuid explicit") from Linus' tree.
>
> Thank you, I'll fix it up.  What am I likely missing that I don't see it
> on my builds?  I'm using gcc 4.8.  Is there a config option that enables
> additional warnings?

Is  this fixed? I couldn't find a relevant patch in linux-next/master for it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] media: davinci: vpif: remove unwanted header includes

[Prabhakar Lad]

Hi Laurent,

Thanks for the review.

On Thu, May 16, 2013 at 6:32 PM, Laurent Pinchart
 wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Thursday 16 May 2013 18:28:16 Lad Prabhakar wrote:
>> From: Lad, Prabhakar 
>>
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>  drivers/media/platform/davinci/vpif.c |7 ---
>>  1 files changed, 0 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif.c
>> b/drivers/media/platform/davinci/vpif.c index ea82a8b..d354d50 100644
>> --- a/drivers/media/platform/davinci/vpif.c
>> +++ b/drivers/media/platform/davinci/vpif.c
>> @@ -17,18 +17,11 @@
>>   * GNU General Public License for more details.
>>   */
>>
>> -#include 
>>  #include 
>>  #include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>>  #include 
>>  #include 
>
> I think you should keep most of those includes. For instance this file uses
> spinlock functions, so linux/spinlock.h should be included. It might work fine
> now due to nested includes, but if someone reorganizes the kernel headers
> internal includes then the driver might break. As a general rule of good
> practice you should include headers for all the APIs you use.
>
OK, do you want me too drop the similar patches from this series ?

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

[PATCH 3/3] BusLogic: Use more conventional argument order for logging

[Joe Perches]

Subsystem specific logging messages generally use
subsystem_(struct subsystem *, fmt, ...)
not
subsystem_(fmt, struct subsystem *, ...)

Convert to use the more generally used kernel style.

Signed-off-by: Joe Perches 
---
 drivers/scsi/BusLogic.c | 304 
 drivers/scsi/BusLogic.h |  24 ++--
 2 files changed, 161 insertions(+), 167 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index bd588cf..d5a5d97 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -140,8 +140,8 @@ static char *blogic_cmd_failure_reason;
 
 static void blogic_announce_drvr(struct blogic_adapter *adapter)
 {
-   blogic_announce("* BusLogic SCSI Driver Version " 
blogic_drvr_version " of " blogic_drvr_date " *\n", adapter);
-   blogic_announce("Copyright 1995-1998 by Leonard N. Zubkoff 
\n", adapter);
+   blogic_announce(adapter, "* BusLogic SCSI Driver Version " 
blogic_drvr_version " of " blogic_drvr_date " *\n");
+   blogic_announce(adapter, "Copyright 1995-1998 by Leonard N. Zubkoff 
\n");
 }
 
 
@@ -204,8 +204,7 @@ static bool __init blogic_create_initccbs(struct 
blogic_adapter *adapter)
blk_pointer = pci_alloc_consistent(adapter->pci_device,
blk_size, );
if (blk_pointer == NULL) {
-   blogic_err("UNABLE TO ALLOCATE CCB GROUP - DETACHING\n",
-   adapter);
+   blogic_err(adapter, "UNABLE TO ALLOCATE CCB GROUP - 
DETACHING\n");
return false;
}
blogic_init_ccbs(adapter, blk_pointer, blk_size, blkp);
@@ -264,10 +263,10 @@ static void blogic_create_addlccbs(struct blogic_adapter 
*adapter,
}
if (adapter->alloc_ccbs > prev_alloc) {
if (print_success)
-   blogic_notice("Allocated %d additional CCBs (total now 
%d)\n", adapter, adapter->alloc_ccbs - prev_alloc, adapter->alloc_ccbs);
+   blogic_notice(adapter, "Allocated %d additional CCBs 
(total now %d)\n", adapter->alloc_ccbs - prev_alloc, adapter->alloc_ccbs);
return;
}
-   blogic_notice("Failed to allocate additional CCBs\n", adapter);
+   blogic_notice(adapter, "Failed to allocate additional CCBs\n");
if (adapter->drvr_qdepth > adapter->alloc_ccbs - adapter->tgt_count) {
adapter->drvr_qdepth = adapter->alloc_ccbs - adapter->tgt_count;
adapter->scsi_host->can_queue = adapter->drvr_qdepth;
@@ -444,7 +443,7 @@ static int blogic_cmd(struct blogic_adapter *adapter, enum 
blogic_opcode opcode,
goto done;
}
if (blogic_global_options.trace_config)
-   blogic_notice("blogic_cmd(%02X) Status = %02X: (Modify 
I/O Address)\n", adapter, opcode, statusreg.all);
+   blogic_notice(adapter, "blogic_cmd(%02X) Status = %02X: 
(Modify I/O Address)\n", opcode, statusreg.all);
result = 0;
goto done;
}
@@ -502,15 +501,15 @@ static int blogic_cmd(struct blogic_adapter *adapter, 
enum blogic_opcode opcode,
 */
if (blogic_global_options.trace_config) {
int i;
-   blogic_notice("blogic_cmd(%02X) Status = %02X: %2d ==> %2d:",
-   adapter, opcode, statusreg.all, replylen,
-   reply_b);
+   blogic_notice(adapter, "blogic_cmd(%02X) Status = %02X: %2d ==> 
%2d:",
+ opcode, statusreg.all, replylen,
+ reply_b);
if (replylen > reply_b)
replylen = reply_b;
for (i = 0; i < replylen; i++)
-   blogic_notice(" %02X", adapter,
-   ((unsigned char *) reply)[i]);
-   blogic_notice("\n", adapter);
+   blogic_notice(adapter, " %02X",
+ ((unsigned char *) reply)[i]);
+   blogic_notice(adapter, "\n");
}
/*
   Process Command Invalid conditions.
@@ -720,23 +719,23 @@ static int __init blogic_init_mm_probeinfo(struct 
blogic_adapter *adapter)
pci_addr = base_addr1 = pci_resource_start(pci_device, 1);
 
if (pci_resource_flags(pci_device, 0) & IORESOURCE_MEM) {
-   blogic_err("BusLogic: Base Address0 0x%lX not I/O for 
MultiMaster Host Adapter\n", NULL, base_addr0);
-   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
+   blogic_err(NULL, "BusLogic: Base Address0 0x%lX not I/O 
for MultiMaster Host Adapter\n", base_addr0);
+   blogic_err(NULL, "at PCI Bus %d Device %d I/O Address 

Re: [PATCH] ARM: davinci: dma: Convert to devm_* api

[Prabhakar Lad]

Hi Sergei,

Thanks for the review.

On Thu, May 16, 2013 at 6:47 PM, Sergei Shtylyov
 wrote:
> Hello.
>
>
> On 16-05-2013 10:58, Lad Prabhakar wrote:
>
>> From: Lad, Prabhakar 
>
>
>> Use devm_ioremap_resource instead of reques_mem_region()/ioremap() and
>> devm_request_irq() instead of request_irq().
>
>
>> This ensures more consistent error values and simplifies error paths.
>
>
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>   NOte:- Boot tested on Logic-PD OMAP-L138 EVM
>
>
>>   arch/arm/mach-davinci/dma.c |   63
>> --
>>   1 files changed, 24 insertions(+), 39 deletions(-)
>
>
>> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
>> index 45b7c71..aeda496 100644
>> --- a/arch/arm/mach-davinci/dma.c
>> +++ b/arch/arm/mach-davinci/dma.c
>
> [...]
>
>> @@ -1422,25 +1421,16 @@ static int __init edma_probe(struct
>> platform_device *pdev)
>> found = 1;
>> }
>>
>> -   len[j] = resource_size(r[j]);
>> -
>> -   r[j] = request_mem_region(r[j]->start, len[j],
>> -   dev_name(>dev));
>> -   if (!r[j]) {
>> -   status = -EBUSY;
>> -   goto fail1;
>> -   }
>> -
>> -   edmacc_regs_base[j] = ioremap(r[j]->start, len[j]);
>> -   if (!edmacc_regs_base[j]) {
>> +   edmacc_regs_base[j] = devm_ioremap_resource(>dev,
>> r[j]);
>> +   if (IS_ERR(edmacc_regs_base[j])) {
>> status = -EBUSY;
>
>
>And you call that "more consistent error values"? Why not:
>
> status = PTR_ERR(edmacc_regs_base[j]);
>
Yes missed it will fix it in v2.

>
>> edma_cc[j] = kzalloc(sizeof(struct edma), GFP_KERNEL);
>
>
>Maybe it's worth using devm_kzalloc() too?
>
OK

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

[PATCH 2/3] BusLogic: Coalesce formats with multiple string fragments

[Joe Perches]

Strings fragments coalesced by the compiler are
difficult to grep.  Coalesce them instead.

Signed-off-by: Joe Perches 
---
 drivers/scsi/BusLogic.c | 66 -
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 28c2051..bd588cf 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -141,7 +141,7 @@ static char *blogic_cmd_failure_reason;
 static void blogic_announce_drvr(struct blogic_adapter *adapter)
 {
blogic_announce("* BusLogic SCSI Driver Version " 
blogic_drvr_version " of " blogic_drvr_date " *\n", adapter);
-   blogic_announce("Copyright 1995-1998 by Leonard N. Zubkoff " 
"\n", adapter);
+   blogic_announce("Copyright 1995-1998 by Leonard N. Zubkoff 
\n", adapter);
 }
 
 
@@ -444,7 +444,7 @@ static int blogic_cmd(struct blogic_adapter *adapter, enum 
blogic_opcode opcode,
goto done;
}
if (blogic_global_options.trace_config)
-   blogic_notice("blogic_cmd(%02X) Status = %02X: " 
"(Modify I/O Address)\n", adapter, opcode, statusreg.all);
+   blogic_notice("blogic_cmd(%02X) Status = %02X: (Modify 
I/O Address)\n", adapter, opcode, statusreg.all);
result = 0;
goto done;
}
@@ -720,22 +720,22 @@ static int __init blogic_init_mm_probeinfo(struct 
blogic_adapter *adapter)
pci_addr = base_addr1 = pci_resource_start(pci_device, 1);
 
if (pci_resource_flags(pci_device, 0) & IORESOURCE_MEM) {
-   blogic_err("BusLogic: Base Address0 0x%lX not I/O for " 
"MultiMaster Host Adapter\n", NULL, base_addr0);
+   blogic_err("BusLogic: Base Address0 0x%lX not I/O for 
MultiMaster Host Adapter\n", NULL, base_addr0);
blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (pci_resource_flags(pci_device, 1) & IORESOURCE_IO) {
-   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for " "MultiMaster Host Adapter\n", NULL, base_addr1);
+   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for MultiMaster Host Adapter\n", NULL, base_addr1);
blogic_err("at PCI Bus %d Device %d PCI Address 
0x%lX\n", NULL, bus, device, pci_addr);
continue;
}
if (irq_ch == 0) {
-   blogic_err("BusLogic: IRQ Channel %d invalid for " 
"MultiMaster Host Adapter\n", NULL, irq_ch);
+   blogic_err("BusLogic: IRQ Channel %d invalid for 
MultiMaster Host Adapter\n", NULL, irq_ch);
blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (blogic_global_options.trace_probe) {
-   blogic_notice("BusLogic: PCI MultiMaster Host Adapter " 
"detected at\n", NULL);
+   blogic_notice("BusLogic: PCI MultiMaster Host Adapter 
detected at\n", NULL);
blogic_notice("BusLogic: PCI Bus %d Device %d I/O 
Address 0x%lX PCI Address 0x%lX\n", NULL, bus, device, io_addr, pci_addr);
}
/*
@@ -822,7 +822,7 @@ static int __init blogic_init_mm_probeinfo(struct 
blogic_adapter *adapter)
nonpr_mmcount++;
mmcount++;
} else
-   blogic_warn("BusLogic: Too many Host Adapters " 
"detected\n", NULL);
+   blogic_warn("BusLogic: Too many Host Adapters 
detected\n", NULL);
}
/*
   If the AutoSCSI "Use Bus And Device # For PCI Scanning Seq."
@@ -960,22 +960,22 @@ static int __init blogic_init_fp_probeinfo(struct 
blogic_adapter *adapter)
pci_addr = base_addr1 = pci_resource_start(pci_device, 1);
 #ifdef CONFIG_SCSI_FLASHPOINT
if (pci_resource_flags(pci_device, 0) & IORESOURCE_MEM) {
-   blogic_err("BusLogic: Base Address0 0x%lX not I/O for " 
"FlashPoint Host Adapter\n", NULL, base_addr0);
+   blogic_err("BusLogic: Base Address0 0x%lX not I/O for 
FlashPoint Host Adapter\n", NULL, base_addr0);
blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (pci_resource_flags(pci_device, 1) & IORESOURCE_IO) {
-   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for " "FlashPoint Host Adapter\n", NULL, base_addr1);
+   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for FlashPoint Host Adapter\n", NULL, base_addr1);
blogic_err("at PCI Bus %d 

[PATCH 1/3] BusLogic: Add __printf verification, fix fallout

[Joe Perches]

Make format and arguments match.

Signed-off-by: Joe Perches 
---
 drivers/scsi/BusLogic.c | 50 -
 drivers/scsi/BusLogic.h |  1 +
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index feab3a5..28c2051 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -720,23 +720,23 @@ static int __init blogic_init_mm_probeinfo(struct 
blogic_adapter *adapter)
pci_addr = base_addr1 = pci_resource_start(pci_device, 1);
 
if (pci_resource_flags(pci_device, 0) & IORESOURCE_MEM) {
-   blogic_err("BusLogic: Base Address0 0x%X not I/O for " 
"MultiMaster Host Adapter\n", NULL, base_addr0);
-   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%X\n", NULL, bus, device, io_addr);
+   blogic_err("BusLogic: Base Address0 0x%lX not I/O for " 
"MultiMaster Host Adapter\n", NULL, base_addr0);
+   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (pci_resource_flags(pci_device, 1) & IORESOURCE_IO) {
-   blogic_err("BusLogic: Base Address1 0x%X not Memory for 
" "MultiMaster Host Adapter\n", NULL, base_addr1);
-   blogic_err("at PCI Bus %d Device %d PCI Address 
0x%X\n", NULL, bus, device, pci_addr);
+   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for " "MultiMaster Host Adapter\n", NULL, base_addr1);
+   blogic_err("at PCI Bus %d Device %d PCI Address 
0x%lX\n", NULL, bus, device, pci_addr);
continue;
}
if (irq_ch == 0) {
blogic_err("BusLogic: IRQ Channel %d invalid for " 
"MultiMaster Host Adapter\n", NULL, irq_ch);
-   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%X\n", NULL, bus, device, io_addr);
+   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (blogic_global_options.trace_probe) {
blogic_notice("BusLogic: PCI MultiMaster Host Adapter " 
"detected at\n", NULL);
-   blogic_notice("BusLogic: PCI Bus %d Device %d I/O 
Address " "0x%X PCI Address 0x%X\n", NULL, bus, device, io_addr, pci_addr);
+   blogic_notice("BusLogic: PCI Bus %d Device %d I/O 
Address 0x%lX PCI Address 0x%lX\n", NULL, bus, device, io_addr, pci_addr);
}
/*
   Issue the Inquire PCI Host Adapter Information command to 
determine
@@ -960,23 +960,23 @@ static int __init blogic_init_fp_probeinfo(struct 
blogic_adapter *adapter)
pci_addr = base_addr1 = pci_resource_start(pci_device, 1);
 #ifdef CONFIG_SCSI_FLASHPOINT
if (pci_resource_flags(pci_device, 0) & IORESOURCE_MEM) {
-   blogic_err("BusLogic: Base Address0 0x%X not I/O for " 
"FlashPoint Host Adapter\n", NULL, base_addr0);
-   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%X\n", NULL, bus, device, io_addr);
+   blogic_err("BusLogic: Base Address0 0x%lX not I/O for " 
"FlashPoint Host Adapter\n", NULL, base_addr0);
+   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (pci_resource_flags(pci_device, 1) & IORESOURCE_IO) {
-   blogic_err("BusLogic: Base Address1 0x%X not Memory for 
" "FlashPoint Host Adapter\n", NULL, base_addr1);
-   blogic_err("at PCI Bus %d Device %d PCI Address 
0x%X\n", NULL, bus, device, pci_addr);
+   blogic_err("BusLogic: Base Address1 0x%lX not Memory 
for " "FlashPoint Host Adapter\n", NULL, base_addr1);
+   blogic_err("at PCI Bus %d Device %d PCI Address 
0x%lX\n", NULL, bus, device, pci_addr);
continue;
}
if (irq_ch == 0) {
blogic_err("BusLogic: IRQ Channel %d invalid for " 
"FlashPoint Host Adapter\n", NULL, irq_ch);
-   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%X\n", NULL, bus, device, io_addr);
+   blogic_err("at PCI Bus %d Device %d I/O Address 
0x%lX\n", NULL, bus, device, io_addr);
continue;
}
if (blogic_global_options.trace_probe) {
blogic_notice("BusLogic: FlashPoint Host Adapter " 
"detected at\n", NULL);
-   blogic_notice("BusLogic: PCI Bus %d Device %d I/O 
Address " "0x%X PCI Address 0x%X\n", NULL, bus, device, io_addr, pci_addr);
+   

[PATCH 0/3] BusLogic: Message logging neatening

[Joe Perches]

If you're going through the trouble to fix this CamelCase stuff
and make it work on 64 bit, how about a little more cleanup?

Joe Perches (3):
  BusLogic: Add __printf verification, fix fallout
  BusLogic: Coalesce formats with multiple string fragments
  BusLogic: Use more conventional argument order for logging

 drivers/scsi/BusLogic.c | 304 
 drivers/scsi/BusLogic.h |  23 ++--
 2 files changed, 161 insertions(+), 166 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty

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

Re: [PATCH 3/4] ipmi: Improve error messages on failed irq enable

[Joe Perches]

On Thu, 2013-05-16 at 22:47 -0500, Corey Minyard wrote:
> On 05/16/2013 05:23 PM, Andy Lutomirski wrote:
> >
> >  /* We got the flags from the SMI, now handle them. */
> >  smi_info->handlers->get_result(smi_info->si_sm, msg, 4);
> > -   if (msg[2] != 0)
> > -   dev_warn(smi_info->dev, "Could not enable 
> > interrupts"
> > -", failed set, using polled mode.\n");
> > -   else
> > +   if (msg[2] != 0) {
> > +   dev_warn(smi_info->dev,
> > +"Couldn't set irq info: %x.\n", msg[2]);
> > +   dev_warn(smi_info->dev,
> > +"Maybe ok, but ipmi might run very 
> > slowly.\n");
> > +   } else
> > Minor nit: it would be nice if these warnings were collapsed into a
> > single printk -- that would save me a whitelist entry of acceptable
> > KERN_WARNING messages :)
> 
> Yeah, the trouble is that checkpatch will give a warning if you split a 
> string
> between two lines or if a line is longer than 80 characters.

Hi Corey.

Yes it will and no it won't.

dev_(struct device *, "some really really long format string 
that makes the line longer than 80 chars\n");

passes checkpatch without warning just fine.

I'd use something like:

dev_warn(smi_info->dev,
 "Couldn't set irq info: %x - this may be OK, 
but ipmi might run very slowly\n",
 msg[2]);


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

Re: [PATCH 1/6] media: i2c: ths7303: remove init_enable option from pdata

[Prabhakar Lad]

Hi Sakari,

Thanks for the review.

On Fri, May 17, 2013 at 4:07 AM, Sakari Ailus  wrote:
> Hi Prabhakar,
>
> Thanks for the patch!
>
> On Wed, May 15, 2013 at 05:27:17PM +0530, Lad Prabhakar wrote:
>> diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
>> index 65853ee..8cddcd0 100644
>> --- a/drivers/media/i2c/ths7303.c
>> +++ b/drivers/media/i2c/ths7303.c
>> @@ -356,9 +356,7 @@ static int ths7303_setup(struct v4l2_subdev *sd)
>>   int ret;
>>   u8 mask;
>>
>> - state->stream_on = pdata->init_enable;
>> -
>> - mask = state->stream_on ? 0xff : 0xf8;
>> + mask = 0xf8;
>
> You can assign mask in declaration. It'd be nice to have a human-readable
> name for the mask, too.
>
This function gets removed in the preceding patch of this series.

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

Re: [PATCH 2/5] net: davinci_emac: remove unwanted header inclusion and sort the alphabetically

[Prabhakar Lad]

Hi Sergei,

Thanks for the review.

On Fri, May 17, 2013 at 12:25 AM, Sergei Shtylyov
 wrote:
> On 16-05-2013 11:30, Lad Prabhakar wrote:
>
>> From: Lad, Prabhakar 
>
>
>> This patch removes unwanted header inclusion
>
>
>Why are they unwanted?
>
The driver builds without this includes.

This is arguable, if I would have added a new driver with the only
#includes which were required to build thats accepted. But when I remove
unnecessary #includes from the existing drivers that's not acceptable ?

This applies to rest of the similar patches in the series.

>> and sorts them alphabetically
>
>
>In the subject you typed "the" instead of "them".
>
Hmm carry forwarded this copy paste error every where will fix it in V2.

Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: omap2430: fix memleak in err case

[Libo Chen]

On 2013/5/15 19:55, Sergei Shtylyov wrote:
> Hello.
> 
> On 15-05-2013 5:35, Libo Chen wrote:
> 
>> when omap_get_control_dev fail, we should release relational platform_device
> 
>s/fail/fails/, s/relational/related/?
> 
>> Signed-off-by: Libo Chen 
> 
>You've posted this to the wrong mailing list, linux-mips; 
> devicetree-discuss also seems hardly related.
> 
> WBR, Sergei
> 
> 
> 

Hi Sergei,

Thank you for your remind.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: davinci_mdio: trivial cleanup

[Prabhakar Lad]

Hi Sergei,

Thanks for the review.

On Fri, May 17, 2013 at 12:28 AM, Sergei Shtylyov
 wrote:
> On 16-05-2013 11:30, Lad Prabhakar wrote:
>
>> From: Lad, Prabhakar 
>
>
>> remove unwanted header inclusion and sort the alphabetically
>
>
>s/the/them/.
OK
>
>
>> also guard the davinci_mdio_of_mtable table and davinci_mdio_probe_dt()
>> with CONFIG_OF.
>
>
>Saying "also" in the changelog is often a good sign there should be one
> more patch -- as in this case.
>
OK I'll split the patch.

Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: BUG: tty: memory corruption through tty_release/tty_ldisc_release

[Alexander Holler]

Am 16.05.2013 23:53, schrieb Peter Hurley:

> And the tty layer can't really _prevent_ the tty driver from mishandling
> the port kref.
> 
>> Especially since it seemed to have been worked before tty_ports got
>> introduced.
> 
> Well, at the time tty_port was introduced to RFCOMM, there was nothing
> to tear-down in tty_port. Now that tty_port owns the flip buffers and
> must do proper tear-down, the problem has surfaced.
> 
>> But I can't add much more to this discussion, as I'm rather a novice
>> in regard to the tty subsystem. I even don't know much about the task
>> sharing between tty, tty_port and tty_ldisc, except the stuff I found
>> out because I got hit by that bug and therefor have read some of the
>> sources.
> 
> Ok. Could you paste the BUG() and steps to reproduce?
> I have a plan to fix it but I'd like to review what you have
> first.

As described before, it ends up with memory corruption because freed
memory is used, so if a BUG() happens, it doesn't help much. E.g. with
kernel 3.9.2 I never have seen a bug, just a rebooting machine
(sometimes minutes after the real bug happened).

To reproduce it, call rfcomm connect /dev/rfcommN and after the
connection to the remote device happened, power down the remote device
and wait 20s (the timeout until a connection drop will be discovered).
Furthermore I would suggest to use commit ecbbfd4, because of the above
mentioned problem. With that you might have luck and see a BUG like this:

May 16 00:06:18 laptopahvpn kernel: [   51.238969] [ cut
here ]
May 16 00:06:18 laptopahvpn kernel: [   51.241754] kernel BUG at
kernel/workqueue.c:609!
May 16 00:06:18 laptopahvpn kernel: [5.603591] error attempted to
write to tty [0x  (null)] = NULL
May 16 00:06:18 laptopahvpn kernel: [   51.244131] invalid opcode: 
[#1] SMP
May 16 00:06:18 laptopahvpn kernel: [   51.249491] Modules linked in:
sch_sfq cdc_acm msr nfs lockd sunrpc rfcomm bnep iptable_nat nf_na
t_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_recent xt_conntrack
nf_conntrack iptable_filter xt_LOG xt_limit ip6table_filter ip6_ta
bles ipv6 btusb bluetooth snd_hda_codec_hdmi coretemp kvm_intel
snd_hda_codec_realtek arc4 kvm crc32c_intel iwldvm ghash_clmulni_intel
mac80211 aesni_intel aes_x86_64 ablk_helper cryptd samsung_laptop xts
lrw gf128mul iwlwifi microcode cfg80211 xhci_hcd rfkill snd_hda_intel
snd_hda_codec snd_hwdep snd_pcm ehci_hcd snd_page_alloc snd_timer snd
usbcore soundcore lpc_ich usb_common mfd_core joydev
May 16 00:06:18 laptopahvpn kernel: [   51.261073] CPU 1
May 16 00:06:18 laptopahvpn kernel: [   51.261106] Pid: 2449, comm:
rfcomm Not tainted 3.7.0-rc2-00023-gecbbfd4-dirty #208 SAMSUNG
ELECTRONICS CO., LTD. 900X3C/900X3D/900X4C/900X4D/SAMSUNG_NP1234567890
May 16 00:06:18 laptopahvpn kernel: [   51.266958] RIP:
0010:[]  [] get_work_gcwq+0x5e/0x60
May 16 00:06:18 laptopahvpn kernel: [   51.270064] RSP:
0018:88020f253da0  EFLAGS: 00010016
May 16 00:06:18 laptopahvpn kernel: [   51.273155] RAX: 81931380
RBX: 880214fee400 RCX: 0024
May 16 00:06:18 laptopahvpn kernel: [   51.276270] RDX: 007fffc4010a7f73
RSI:  RDI: 880214fee400
May 16 00:06:18 laptopahvpn kernel: [   51.279333] RBP: 
R08: 000a R09: 181c
May 16 00:06:18 laptopahvpn kernel: [   51.282319] R10: 
R11: 181b R12: 
May 16 00:06:18 laptopahvpn kernel: [   51.285286] R13: 0004
R14: 880210863000 R15: 
May 16 00:06:18 laptopahvpn kernel: [   51.288265] FS:
7f8bd6e94700() GS:88021f28() knlGS:
May 16 00:06:18 laptopahvpn kernel: [   51.291283] CS:  0010 DS: 
ES:  CR0: 80050033
May 16 00:06:18 laptopahvpn kernel: [   51.294328] CR2: 7fc249111e60
CR3: 00020f1d3000 CR4: 001407e0
May 16 00:06:18 laptopahvpn kernel: [   51.297415] DR0: 
DR1:  DR2: 
May 16 00:06:18 laptopahvpn kernel: [   51.300506] DR3: 
DR6: 0ff0 DR7: 0400
May 16 00:06:18 laptopahvpn kernel: [   51.303555] Process rfcomm (pid:
2449, threadinfo 88020f252000, task 880210bbee80)
May 16 00:06:18 laptopahvpn kernel: [   51.306638] Stack:
May 16 00:06:18 laptopahvpn kernel: [   51.309704]  8104a471
00014040 0296 880210863000
May 16 00:06:18 laptopahvpn kernel: [   51.312850]  
0001 81258188 
May 16 00:06:18 laptopahvpn kernel: [   51.315998]  812591b4
00013fc0 880215278700 
May 16 00:06:18 laptopahvpn kernel: [   51.319139] Call Trace:
May 16 00:06:18 laptopahvpn kernel: [   51.322236]  []
? __cancel_work_timer+0x31/0xa0
May 16 00:06:18 laptopahvpn kernel: [   51.325398]  []
? tty_ldisc_halt+0x18/0x20
May 16 00:06:18 laptopahvpn kernel: [   51.328551]  []
? tty_ldisc_release+0x34/0x110
May 16 

Re: [PATCH 0/3] CPUFreq Fixes for 3.10-rc2

[Viresh Kumar]

On 17 May 2013 02:21, Rafael J. Wysocki  wrote:
> While I kind of understand why you want [3/3] to go into 3.10, I'm wondering
> about the other two patches.  Why exactly are they needed now?

First one:

  cpufreq: Add EXPORT_SYMBOL_GPL for have_governor_per_policy

is required so that governors can be compiled as module. Otherwise they
may break.. I haven't tried that but I believe that is the case.


For second one:

  cpufreq: governors: Move get_governor_parent_kobj() to cpufreq.c

I was actually working on Android's Interactive governor (Where I enabled
same per-policy-instance of governor support), And i required this patch
for its working. Then I thought other platform specific governors present
in mainline might also use this routine and so must be pushed to cpufreq.c.

Now, because this patch is around due to something which got
added in 3.10-rc1, its better to fix it in rcs only rather than fixing
it in 3.11.
I will trust your judgement here, push it for 3.10-rc if it looks okay to you.

> And speaking of patch [3/3], if you paste kernel logs into changelogs, please
> remove the time stamps (unless they are relevant to the problem being fixed).

Okay.. Will keep that in mind.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Randy Dunlap]

On 05/16/13 16:42, Rusty Russell wrote:
> Joe Perches  writes:
>> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
>>> Asias He  writes:
 On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
>> []
 Other users are using memcpy_fromiovec and friends outside net. It seems
 a good idea to put it in a util library. e.g.  crypto/algif_skcipher.c
 which also depends on NET for it.
>>
>> []
>>> Subject: Hoist memcpy_fromiovec into lib/
>>
>> You'll need the "friends" memcpy_toiovec too.
>>
>> $ git grep -E \bmemcpy\w+iovec\w*"
>> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result, len);
>> crypto/algif_skcipher.c:err = 
>> memcpy_fromiovec(page_address(sg_page(sg)) +
>> crypto/algif_skcipher.c:err = 
>> memcpy_fromiovec(page_address(sg_page(sg + i)),
>> drivers/dma/iovlock.c:#include  /* for memcpy_toiovec */
>> drivers/dma/iovlock.c:  return memcpy_toiovec(iov, kdata, len);
>> drivers/dma/iovlock.c:  err = memcpy_toiovec(iov, vaddr + offset, 
>> len);
>> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len), 
>> msg->msg_iov, len)) {
>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
>> memcpy_fromiovec((u8 *)va + page_o
>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
>> memcpy_toiovec(iov, (u8 *)va + pag
> 
> Fascinating.  These all indirectly depend on NET, so there's no problem
> at the moment.  But it is a bit weird...
> 
> crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
> crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
> drivers/dma/iovlock.c: depends on NET_DMA -> NET
> drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
> drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET
> 
> Patch welcome.
> 
> Meanwhile, to avoid more bikeshedding I've put the patch I posted with
> all acks in my fixes branch.  One cycle through linux-next, then
> straight to Linus.
> 

I agree with whoever suggested that more be moved into /lib.
E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the
code there uses both memcpy_toiovec() and memcpy_fromiovec().
See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.


> Subject: Hoist memcpy_fromiovec into lib/
> 
> ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
> 
> That function is only present with CONFIG_NET.  Turns out that
> crypto/algif_skcipher.c also uses that outside net, but it actually
> needs sockets anyway.
> 
> socket.h already include uio.h, so no callers need updating.
> 
> Reported-by: Randy Dunlap 
> Acked-by: David S. Miller 
> Acked-by: Michael S. Tsirkin 
> Signed-off-by: Rusty Russell 
> 
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 428c37a..7266775 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -305,7 +305,6 @@ struct ucred {
>  
>  extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct 
> ucred *ucred);
>  
> -extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int 
> len);
>  extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
>  int offset, int len);
>  extern int csum_partial_copy_fromiovecend(unsigned char *kdata, 
> diff --git a/include/linux/uio.h b/include/linux/uio.h
> index 629aaf5..21628d3 100644
> --- a/include/linux/uio.h
> +++ b/include/linux/uio.h
> @@ -35,4 +35,6 @@ static inline size_t iov_length(const struct iovec *iov, 
> unsigned long nr_segs)
>  }
>  
>  unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t 
> to);
> +
> +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
>  #endif
> diff --git a/lib/Makefile b/lib/Makefile
> index e9c52e1..2377211 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -9,7 +9,7 @@ endif
>  
>  lib-y := ctype.o string.o vsprintf.o cmdline.o \
>rbtree.o radix-tree.o dump_stack.o timerqueue.o\
> -  idr.o int_sqrt.o extable.o \
> +  idr.o int_sqrt.o extable.o iovec.o \
>sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
>proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
>is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> diff --git a/lib/iovec.c b/lib/iovec.c
> new file mode 100644
> index 000..632c5ea
> --- /dev/null
> +++ b/lib/iovec.c
> @@ -0,0 +1,29 @@
> +#include 
> +#include 
> +#include 
> +
> +/*
> + *   Copy iovec to kernel. Returns -EFAULT on error.
> + *
> + *   Note: this modifies the original iovec.
> + */
> +
> +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
> +{
> + while (len > 0) {
> + if (iov->iov_len) {
> + int copy = min_t(unsigned int, len, iov->iov_len);
> + if (copy_from_user(kdata, iov->iov_base, copy))
> + return -EFAULT;
> + len -= 

[PATCH v3] kernel/module.c: need return the first error code to upper caller when error occurs

[Chen Gang]

When multiple errors occur, simplify_symbols() will return the last
error code to the upper caller.

In this case, better to return the first error code to the upper caller.

Just like "using compiler": it will print all errors and warnings as
much as it can, but the user usually mainly focus on the first error or
warning. Since 'user' only can get one error return code, 'he/she'
usually assume the error code will match the first error print line.


Signed-off-by: Chen Gang 
---
 kernel/module.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index e4ee1bf..9e6c96d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1976,7 +1976,8 @@ static int simplify_symbols(struct module *mod, const 
struct load_info *info)
pr_debug("Common symbol: %s\n", name);
printk("%s: please compile with -fno-common\n",
   mod->name);
-   ret = -ENOEXEC;
+   if (!ret)
+   ret = -ENOEXEC;
break;
 
case SHN_ABS:
@@ -1999,7 +2000,8 @@ static int simplify_symbols(struct module *mod, const 
struct load_info *info)
 
printk(KERN_WARNING "%s: Unknown symbol %s (err %li)\n",
   mod->name, name, PTR_ERR(ksym));
-   ret = PTR_ERR(ksym) ?: -ENOENT;
+   if (!ret)
+   ret = PTR_ERR(ksym) ?: -ENOENT;
break;
 
default:
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: samsung: fix suspend/resume functionality

[Doug Anderson]

The GPIO states need to be restored after s2r and this is not currently
supported in the pinctrl driver. This patch saves the gpio states before
suspend and restores them after resume.

Saving and restoring is done very early using syscore_ops and must
happen before pins are released from their powerdown state.

Patch originally from Prathyush K  but
rewritten by Doug Anderson .

Signed-off-by: Prathyush K 
Signed-off-by: Doug Anderson 
---
Changes in v3:
- Skip save and restore for banks with no powerdown config.

Changes in v2:
- Now uses sycore_ops to make sure we're early enough.
- Try to handle two CON registers better.
- Should handle s3c24xx better as per Heiko.
- Simpler code; no longer tries to avoid glitching lines since
  we _think_ all current SoCs should have pins in power down state
  when the restore is called.
- Dropped eint patch for now; Tomasz will post his version.

 drivers/pinctrl/pinctrl-samsung.c | 148 ++
 drivers/pinctrl/pinctrl-samsung.h |   5 ++
 2 files changed, 153 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-samsung.c 
b/drivers/pinctrl/pinctrl-samsung.c
index 9763668..d45e36f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 #include "pinctrl-samsung.h"
@@ -48,6 +49,9 @@ static struct pin_config {
{ "samsung,pin-pud-pdn", PINCFG_TYPE_PUD_PDN },
 };
 
+/* Global list of devices (struct samsung_pinctrl_drv_data) */
+LIST_HEAD(drvdata_list);
+
 static unsigned int pin_base;
 
 static inline struct samsung_pin_bank *gc_to_pin_bank(struct gpio_chip *gc)
@@ -961,9 +965,145 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
ctrl->eint_wkup_init(drvdata);
 
platform_set_drvdata(pdev, drvdata);
+
+   /* Add to the global list */
+   list_add_tail(>node, _list);
+
return 0;
 }
 
+#ifdef CONFIG_PM
+
+/**
+ * samsung_pinctrl_suspend_dev - save pinctrl state for suspend for a device
+ *
+ * Save data for all banks handled by this device.
+ */
+static void samsung_pinctrl_suspend_dev(
+   struct samsung_pinctrl_drv_data *drvdata)
+{
+   struct samsung_pin_ctrl *ctrl = drvdata->ctrl;
+   void __iomem *virt_base = drvdata->virt_base;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; i++) {
+   struct samsung_pin_bank *bank = >pin_banks[i];
+   void __iomem *reg = virt_base + bank->pctl_offset;
+
+   u8 *offs = bank->type->reg_offset;
+   u8 *widths = bank->type->fld_width;
+   enum pincfg_type type;
+
+   /* Registers without a powerdown config aren't lost */
+   if (!widths[PINCFG_TYPE_CON_PDN])
+   continue;
+
+   for (type = 0; type < PINCFG_TYPE_NUM; type++)
+   if (widths[type])
+   bank->pm_save[type] = readl(reg + offs[type]);
+
+   if (widths[PINCFG_TYPE_FUNC] * bank->nr_pins > 32) {
+   /* Some banks have two config registers */
+   bank->pm_save[PINCFG_TYPE_NUM] =
+   readl(reg + offs[PINCFG_TYPE_FUNC] + 4);
+   pr_debug("Save %s @ %p (con %#010x %08x)\n",
+bank->name, reg,
+bank->pm_save[PINCFG_TYPE_FUNC],
+bank->pm_save[PINCFG_TYPE_NUM]);
+   } else {
+   pr_debug("Save %s @ %p (con %#010x)\n", bank->name,
+reg, bank->pm_save[PINCFG_TYPE_FUNC]);
+   }
+   }
+}
+
+/**
+ * samsung_pinctrl_resume_dev - restore pinctrl state from suspend for a device
+ *
+ * Restore one of the banks that was saved during suspend.
+ *
+ * We don't bother doing anything complicated to avoid glitching lines since
+ * we're called before pad retention is turned off.
+ */
+static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data 
*drvdata)
+{
+   struct samsung_pin_ctrl *ctrl = drvdata->ctrl;
+   void __iomem *virt_base = drvdata->virt_base;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; i++) {
+   struct samsung_pin_bank *bank = >pin_banks[i];
+   void __iomem *reg = virt_base + bank->pctl_offset;
+
+   u8 *offs = bank->type->reg_offset;
+   u8 *widths = bank->type->fld_width;
+   enum pincfg_type type;
+
+   /* Registers without a powerdown config aren't lost */
+   if (!widths[PINCFG_TYPE_CON_PDN])
+   continue;
+
+   if (widths[PINCFG_TYPE_FUNC] * bank->nr_pins > 32) {
+   /* Some banks have two config registers */
+   pr_debug("%s @ %p (con %#010x %08x => %#010x %08x)\n",
+bank->name, reg,
+

Re: [PATCH 4/4] usb: tilegx: fix memleak when create hcd fail

[Libo Chen]

Hi Greg,

On 2013/5/17 8:34, Greg KH wrote:
> On Thu, May 09, 2013 at 12:58:11PM +0800, Libo Chen wrote:
>> From: Libo Chen 
>>
>> When usb_create_hcd fail, we should call gxio_usb_host_destroy
>>
>> Signed-off-by: Libo Chen 
>> ---
>>  drivers/usb/host/ohci-tilegx.c |7 +--
>>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> This patch doesn't apply at all, care to refresh it?
> 
> thanks,
> 
> greg k-h
> 
> .

this patch has been merged to upstream by Chris Metcalf .
(commit: abab8761d095e0805879df48a8ba6ea7f8b31c5e)

thanks,
Libo


> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On 05/16/2013 07:53 PM, Eric W. Biederman wrote:
>> 
>> That is completely and totally orthogonal to this change.
>> 
>> read_oldmem may have problems but in practice on a large systems those
>> problems are totally dwarfed by real life performance issues that come
>> from playing too much with the page tables.
>> 
>> I really don't find bringing up whatever foundational issues you have
>> with read_oldmem() appropriate or relevant here.
>> 
>
> Well, it is in the sense that we have two pieces of code doing the same
> thing, each with different bugs.

Not a the tiniest little bit.

All this patchset is about is which page table kernel vs user we map the
physical addresses in.

As such this patchset should neither increase nor decrease the number of
bugs, or cause any other hilarity.

Whatever theoretical issues you have with /dev/oldmem and /proc/vmcore
can and should be talked about and addressed independently of these
changes.  HATMAYA Daisuke already has enough to handle coming up with a
clean set of patches that add mmap support.

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/

linux-next: Tree for May 17

[Stephen Rothwell]

Hi all,

Changes since 20130516:





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

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

Below is a summary of the state of the merge.

We are up to 226 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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

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

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (d5fe85a Merge tag 'pm+acpi-3.10-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (f66ba56 package: Makefile: unbreak binrpm-pkg 
target)
Merging arc-current/for-curr (81ec684 ARC: [mm] change semantics of 
__sync_icache_dcache() to inv d$ lines)
Merging arm-current/fixes (6eabb33 ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't 
clear upper 32 bits of the old/new value)
Merging m68k-current/for-linus (f722406 Linux 3.10-rc1)
Merging powerpc-merge/merge (e34166a powerpc: Set show_unhandled_signals to 1 
by default)
Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc)
Merging net/master (b0ce350 bonding: allow TSO being set on bonding master)
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (436c4a0 ALSA: hda - Add headset mic support 
for another Dell machine)
Merging pci-current/for-linus (f722406 Linux 3.10-rc1)
Merging wireless/master (61f1598 Merge branch 'wireless')
Merging driver-core.current/driver-core-linus (9affd6b arm: fix mismerge of 
arch/arm/mach-omap2/timer.c)
Merging tty.current/tty-linus (f722406 Linux 3.10-rc1)
Merging usb.current/usb-linus (98f541c USB: remove remaining instances of 
USB_SUSPEND)
Merging staging.current/staging-linus (c2b62f6 staging: nvec: cleanup childs on 
remove)
Merging char-misc.current/char-misc-linus (f722406 Linux 3.10-rc1)
Merging input-current/for-linus (f0aacea Input: wacom - add a few new styli for 
Cintiq series)
Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks 
of hybid raid1/raid10 array)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (286233e crypto: caam - fix inconsistent assoc 
dma mapping direction)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (e5c4b5d module: Add section ".ref.data" into 
kmemleak-scan-area.)
Merging mfd-fixes/master (e9d7b4b mfd: db8500-prcmu: Update stored DSI PLL 
divider value)
Merging vfio-fixes/for-linus (904c680 vfio-pci: Fix possible integer overflow)
Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h f

Re: [PATCH] Staging: android: sync: fixed a brace coding style issue

[Brandon Height]

Actually it looks like this patch is not needed against linux-next.
My mistake.

On May 16, 2013, at 1:07 PM, Greg KH  wrote:

> On Thu, May 16, 2013 at 08:42:22AM -1000, bmhei...@gmail.com wrote:
>> From: Brandon Height 
>> 
>> Fixed a coding style issue.
>> 
>> Signed-off-by: Brandon Height 
> 
> This doesn't apply to my tree, can you please redo it against linux-next
> and resend?
> 
> thanks,
> 
> greg k-h

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

Re: [PATCH] drivers: parport: Use kmemdup

[Greg Kroah-Hartman]

On Sun, Apr 28, 2013 at 07:54:38PM +0300, Alexandru Gheorghiu wrote:
> Used kmemdup instead of kmalloc and memcpy.
> Patch found using coccinelle.
> 
> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/parport/parport_gsc.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This patch doesn't apply to my tree, care to redo it and resend it?

thanks,

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

Re: [PATCH 2/2] powerpc/512x: DMA via LocalPlus Bus testing driver

[Greg Kroah-Hartman]

On Thu, May 02, 2013 at 07:23:15PM +0400, Alexander Popov wrote:
> This module tests Direct Memory Access to some device on LocalPlus Bus
> for Freescale MPC512x. In other words it tests the bundle
> of mpc512x_lpbfifo and mpc512x_dma drivers.
> 
> This testing driver was multiply used with static RAM (CY62167EV30LL-45ZXI)
> which lives on LocalPlus Bus on our board. This testing driver was used
> instead of the original static RAM driver and it is an abnormal hack.
> That is why I just provide the driver code and don't modify any environment.
> 
> Signed-off-by: Alexander Popov 
> ---
>  drivers/misc/mpc512x_lpbdma_test.c | 310 
> +
>  1 file changed, 310 insertions(+)
>  create mode 100644 drivers/misc/mpc512x_lpbdma_test.c

You obviously didn't test your testing driver to see if it would build
in the kernel source tree :(

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

Re: [PATCH 3.9-stable] mmc: dw_mmc: fix fifo access for 64-bit

[Greg KH]

On Mon, May 06, 2013 at 01:33:22PM +0900, Jonghwan Choi wrote:
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?

It doesn't apply to the 3.9 tree, so it's going to be bit hard to do
this...

sorry,

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

Re: [PATCH 3/4] usb: ohci: fix goto wrong tag in err case

[Greg KH]

On Thu, May 09, 2013 at 12:58:10PM +0800, Libo Chen wrote:
> From: Libo Chen 
> 
> fix goto wrong tag in usb_hcd_nxp_probe
> 
> Signed-off-by: Libo Chen 
> ---
>  drivers/usb/host/ohci-nxp.c |   12 ++--
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
> index f4988fb..eb294a9 100644
> --- a/drivers/usb/host/ohci-nxp.c
> +++ b/drivers/usb/host/ohci-nxp.c
> @@ -234,7 +234,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
>   if (usb_disabled()) {
>   dev_err(>dev, "USB is disabled\n");
>   ret = -ENODEV;
> - goto out;
> + goto out1;

Please fix this up to use better error case names so this does not
happen again.

thanks,

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

Re: [PATCH 4/4] usb: tilegx: fix memleak when create hcd fail

[Greg KH]

On Thu, May 09, 2013 at 12:58:11PM +0800, Libo Chen wrote:
> From: Libo Chen 
> 
> When usb_create_hcd fail, we should call gxio_usb_host_destroy
> 
> Signed-off-by: Libo Chen 
> ---
>  drivers/usb/host/ohci-tilegx.c |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)

This patch doesn't apply at all, care to refresh it?

thanks,

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

Re: [PATCH] Allow binding drivers/uio/uio_pdrv_genirq.c to devices using command line option

[Greg KH]

On Mon, May 06, 2013 at 12:53:52PM +0200, Pavel Machek wrote:
> Hello!
> 
> > This adds ability to bind uio driver to given open firmware device
> > using command line option. Thus, userspace driver can be developed and
> > used without modifying the kernel.
> > 
> > Signed-off-by: Pavel Machek  
> 
> I got no comments here, and patch is pretty simple. Greg, can you
> merge it?

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

Re: [PATCH v2] usb: ohci: fix goto wrong tag in err case

[Greg KH]

On Fri, May 10, 2013 at 02:22:42PM +0800, Libo Chen wrote:
> fix goto wrong tag in usb_hcd_nxp_probe
> 
> Signed-off-by: Libo Chen 

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

Re: [PATCH 3/4] ipmi: Improve error messages on failed irq enable

[Corey Minyard]

On 05/16/2013 05:23 PM, Andy Lutomirski wrote:


 /* We got the flags from the SMI, now handle them. */
 smi_info->handlers->get_result(smi_info->si_sm, msg, 4);
-   if (msg[2] != 0)
-   dev_warn(smi_info->dev, "Could not enable interrupts"
-", failed set, using polled mode.\n");
-   else
+   if (msg[2] != 0) {
+   dev_warn(smi_info->dev,
+"Couldn't set irq info: %x.\n", msg[2]);
+   dev_warn(smi_info->dev,
+"Maybe ok, but ipmi might run very slowly.\n");
+   } else
Minor nit: it would be nice if these warnings were collapsed into a
single printk -- that would save me a whitelist entry of acceptable
KERN_WARNING messages :)


Yeah, the trouble is that checkpatch will give a warning if you split a 
string
between two lines or if a line is longer than 80 characters.  I'm not 
creative
enough to fit it into a single line.  Maybe I'm trying to be too literal 
here,

but I split it into two prints to avoid the warning.



My Dell 12g server says:

[97627.407724] ipmi_si ipmi_si.0: Using irq 10
[97627.421369] ipmi_si ipmi_si.0: Couldn't set irq info: cc.
[97627.427389] ipmi_si ipmi_si.0: Maybe ok, but ipmi might run very slowly.

Tested-by: Andy Lutomirski 


Thanks a bunch.

-corey


--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: [PATCH v4] usb host: Faraday USB2.0 FUSBH200-HCD driver

[Greg KH]

On Fri, Apr 26, 2013 at 09:37:20AM +, Yuan-Hsin Chen wrote:
> FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200.
> FUSBH200 is an ehci-like controller with some differences.
> First, register layout of FUSBH200 is incompatible with EHCI.
> Furthermore, FUSBH200 is lack of siTDs which means iTDs
> are used for both HS and FS ISO transfer.
> 
> Signed-off-by: Yuan-Hsin Chen 

This patch breaks the build on my machine, so I can't accept it:
  CC [M]  drivers/usb/host/fusbh200-hcd.o
drivers/usb/host/fusbh200-hcd.c: In function ‘dbg_hcc_params’:
drivers/usb/host/fusbh200-hcd.c:149:2: error: implicit declaration of function 
‘HCC_HW_PREFETCH’ [-Werror=implicit-function-declaration]
drivers/usb/host/fusbh200-hcd.c:149:2: error: implicit declaration of function 
‘HCC_32FRAME_PERIODIC_LIST’ [-Werror=implicit-function-declaration]
drivers/usb/host/fusbh200-hcd.c:149:2: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 6 has type ‘char *’ [-Wformat]
drivers/usb/host/fusbh200-hcd.c: At top level:
drivers/usb/host/fusbh200-hcd.c:906:12: warning: ‘debug_lpm_close’ defined but 
not used [-Wunused-function]
cc1: some warnings being treated as errors

Please be more careful.  Can you fix this up and resend it?

thanks,

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

Re: [PATCH v3] usb: ehci: Only sleep for post-resume handover if devices use persist

[Greg Kroah-Hartman]

On Thu, Apr 25, 2013 at 09:08:27AM -0700, Julius Werner wrote:
> The current EHCI code sleeps a flat 110ms in the resume path if there
> was a USB 1.1 device connected to its companion controller during
> suspend, waiting for the device to reappear and reset so that it can be
> handed back to the companion. This is necessary if the device uses
> persist, so that the companion controller can actually see it during its
> own resume path.
> 
> However, if the device doesn't use persist, this is entirely
> unnecessary. We might just as well ignore it and have the normal device
> detection/reset/handoff code handle it asynchronously when it eventually
> shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
> which persist has no value), this can allow distros to shave another
> tenth of a second off their resume time.
> 
> In order to enable this optimization, the patch also adds a new
> usb_for_each_dev() iterator that is exported by the USB core and wraps
> bus_for_each_dev() with the logic to differentiate between struct
> usb_device and struct usb_interface on the usb_bus_type bus.
> 
> Signed-off-by: Julius Werner 
> Acked-by: Alan Stern 
> ---
>  drivers/usb/core/usb.c  | 33 +
>  drivers/usb/host/ehci-hub.c | 17 +
>  include/linux/usb.h |  1 +
>  3 files changed, 51 insertions(+)

This patch is corrupted somehow, but I can't figure out how.

I'm getting the error:
checking file drivers/usb/core/usb.c
checking file drivers/usb/host/ehci-hub.c
patch:  malformed patch at line 164: @@ -56,6 +63,16 @@ static void 
ehci_handover_companion_ports(struct ehci_hcd *ehci)

when trying to apply it.  git also doesn't like it.

Care to fix this up and resend it so I can apply it?

thanks,

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

Re: [PATCH 2/9] mm: vmscan: Obey proportional scanning requirements for kswapd

[Kamezawa Hiroyuki]

(2013/05/13 17:12), Mel Gorman wrote:
> Simplistically, the anon and file LRU lists are scanned proportionally
> depending on the value of vm.swappiness although there are other factors
> taken into account by get_scan_count().  The patch "mm: vmscan: Limit
> the number of pages kswapd reclaims" limits the number of pages kswapd
> reclaims but it breaks this proportional scanning and may evenly shrink
> anon/file LRUs regardless of vm.swappiness.
> 
> This patch preserves the proportional scanning and reclaim. It does mean
> that kswapd will reclaim more than requested but the number of pages will
> be related to the high watermark.
> 
> [mho...@suse.cz: Correct proportional reclaim for memcg and simplify]
> [kamezawa.hir...@jp.fujitsu.com: Recalculate scan based on target]
> [han...@cmpxchg.org: Account for already scanned pages properly]
> Signed-off-by: Mel Gorman 
> Acked-by: Rik van Riel 

Acked-by: KAMEZAWA Hiroyuki 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 07/10] mtd: add ECC info for nand_flash_dev{}

[Huang Shijie]

Add an instance of an anonymous struct to store the ECC infor for full id
nand chips.
@ecc.strength_ds: ECC correctability from the datasheet.
@ecc.step_ds: ECC size required by the @ecc.strength_ds,

These two fields are all from the datasheet.

Also add the necessary macros to make the code simple and clean.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 9574e0a..217cdfe 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -625,6 +625,11 @@ struct nand_chip {
{ .name = (nm), {{ .dev_id = (devid) }}, .chipsize = (chipsz), \
  .options = (opts) }
 
+#define NAND_ECC_INFO(_strength, _step)\
+   { .strength_ds = (_strength), .step_ds = (_step) }
+#define NAND_ECC_STRENGTH(type)((type)->ecc.strength_ds)
+#define NAND_ECC_STEP(type)((type)->ecc.step_ds)
+
 /**
  * struct nand_flash_dev - NAND Flash Device ID Structure
  * @name: a human-readable name of the NAND chip
@@ -642,6 +647,12 @@ struct nand_chip {
  * @options: stores various chip bit options
  * @id_len: The valid length of the @id.
  * @oobsize: OOB size
+ * @ecc.strength_ds: The ECC correctability from the datasheet, same as the
+ *   @ecc_strength_ds in nand_chip{}.
+ * @ecc.step_ds: The ECC step required by the @ecc.strength_ds, same as the
+ *   @ecc_step_ds in nand_chip{}, also from the datasheet.
+ *   For example, the "4bit ECC for each 512Byte" can be set with
+ *   NAND_ECC_INFO(4, 512).
  */
 struct nand_flash_dev {
char *name;
@@ -658,6 +669,10 @@ struct nand_flash_dev {
unsigned int options;
uint16_t id_len;
uint16_t oobsize;
+   struct {
+   uint16_t strength_ds;
+   uint16_t step_ds;
+   } ecc;
 };
 
 /**
-- 
1.7.1


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

[PATCH v6 08/10] mtd: parse out the ECC info for the full-id nand chips

[Huang Shijie]

Parse out the ECC information for the full-id nand chips.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 355976d..f7b514b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3246,6 +3246,8 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
struct nand_chip *chip,
chip->cellinfo = id_data[2];
chip->chipsize = (uint64_t)type->chipsize << 20;
chip->options |= type->options;
+   chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
+   chip->ecc_step_ds = NAND_ECC_STEP(type);
 
*busw = type->options & NAND_BUSWIDTH_16;
 
-- 
1.7.1


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

[PATCH v6 04/10] mtd: add a helper to get the supported features for ONFI nand

[Huang Shijie]

From: Huang Shijie 

add a helper to get the supported features for ONFI nand.
Also add the neccessary macros.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index f1ce48e..9574e0a 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -202,6 +202,10 @@ typedef enum {
 /* Keep gcc happy */
 struct nand_chip;
 
+/* ONFI features */
+#define ONFI_FEATURE_16_BIT_BUS(1 << 0)
+#define ONFI_FEATURE_EXT_PARAM_PAGE(1 << 7)
+
 /* ONFI timing mode, used in both asynchronous and synchronous mode */
 #define ONFI_TIMING_MODE_0 (1 << 0)
 #define ONFI_TIMING_MODE_1 (1 << 1)
@@ -753,6 +757,12 @@ struct platform_nand_chip *get_platform_nandchip(struct 
mtd_info *mtd)
return chip->priv;
 }
 
+/* return the supported features. */
+static inline int onfi_feature(struct nand_chip *chip)
+{
+   return chip->onfi_version ? le16_to_cpu(chip->onfi_params.features) : 0;
+}
+
 /* return the supported asynchronous timing mode. */
 static inline int onfi_get_async_timing_mode(struct nand_chip *chip)
 {
-- 
1.7.1


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

[PATCH v6 03/10] mtd: add data structures for Extended Parameter Page

[Huang Shijie]

Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
to store the ECC info.

The onfi spec tells us that if the nand chip's recommended ECC codeword
size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
read the Extended ECC information that is part of the extended parameter
page to retrieve the ECC requirements for this device.

This patch adds
[1] the neccessary fields for nand_onfi_params{},
[2] and adds the onfi_ext_ecc_info{} for Extended ECC information,
[3] adds onfi_ext_section{} for extended sections,
[4] and adds onfi_ext_param_page{} for the Extended Parameter Page.

Acked-by: Pekon Gupta 
Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |   39 ++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index ee696f1..f1ce48e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -224,7 +224,10 @@ struct nand_onfi_params {
__le16 revision;
__le16 features;
__le16 opt_cmd;
-   u8 reserved[22];
+   u8 reserved0[2];
+   __le16 ext_param_page_length; /* since ONFI 2.1 */
+   u8 num_of_param_pages;/* since ONFI 2.1 */
+   u8 reserved1[17];
 
/* manufacturer information block */
char manufacturer[12];
@@ -281,6 +284,40 @@ struct nand_onfi_params {
 
 #define ONFI_CRC_BASE  0x4F4E
 
+/* Extended ECC information Block Definition (since ONFI 2.1) */
+struct onfi_ext_ecc_info {
+   u8 ecc_bits;
+   u8 codeword_size;
+   __le16 bb_per_lun;
+   __le16 block_endurance;
+   u8 reserved[2];
+} __attribute__((packed));
+
+#define ONFI_SECTION_TYPE_00   /* Unused section. */
+#define ONFI_SECTION_TYPE_11   /* for additional sections. */
+#define ONFI_SECTION_TYPE_22   /* for ECC information. */
+struct onfi_ext_section {
+   u8 type;
+   u8 length;
+} __attribute__((packed));
+
+#define ONFI_EXT_SECTION_MAX 8
+
+/* Extended Parameter Page Definition (since ONFI 2.1) */
+struct onfi_ext_param_page {
+   __le16 crc;
+   u8 sig[4]; /* 'E' 'P' 'P' 'S' */
+   u8 reserved0[10];
+   struct onfi_ext_section sections[ONFI_EXT_SECTION_MAX];
+
+   /*
+* The actual size of the Extended Parameter Page is in
+* @ext_param_page_length of nand_onfi_params{}.
+* The following are the variable length sections.
+* So we do not add any fields below. Please see the ONFI spec.
+*/
+} __attribute__((packed));
+
 /**
  * struct nand_hw_control - Control structure for hardware controller (e.g ECC 
generator) shared among independent devices
  * @lock:   protection lock
-- 
1.7.1


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

[PATCH v6 05/10] mtd: get the ECC info from the Extended Parameter Page

[Huang Shijie]

Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
to store the ECC info.

The onfi spec tells us that if the nand chip's recommended ECC codeword
size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
read the Extended ECC information that is part of the extended parameter
page to retrieve the ECC requirements for this device.

This patch implement the reading of the Extended Parameter Page, and parses
the sections for ECC type, and get the ECC info from the ECC section.

Tested this patch with Micron MT29F64G08CBABAWP.

Acked-by: Pekon Gupta 
Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |   80 ++
 1 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index b63b731..0b1162a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2835,6 +2835,71 @@ static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
return crc;
 }
 
+/* Parse the Extended Parameter Page. */
+static int nand_flash_detect_ext_param_page(struct mtd_info *mtd,
+   struct nand_chip *chip, struct nand_onfi_params *p)
+{
+   struct onfi_ext_param_page *ep;
+   struct onfi_ext_section *s;
+   struct onfi_ext_ecc_info *ecc;
+   uint8_t *cursor;
+   int len;
+   int ret;
+   int i;
+
+   len = le16_to_cpu(p->ext_param_page_length) * 16;
+   ep = kmalloc(len, GFP_KERNEL);
+   if (!ep) {
+   ret = -ENOMEM;
+   goto ext_out;
+   }
+
+   /* Send our own NAND_CMD_PARAM. */
+   chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+
+   /* Use the Change Read Column command to skip the ONFI param pages. */
+   chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
+   sizeof(*p) * p->num_of_param_pages , -1);
+
+   /* Read out the Extended Parameter Page. */
+   chip->read_buf(mtd, (uint8_t *)ep, len);
+   if ((onfi_crc16(ONFI_CRC_BASE, ((uint8_t *)ep) + 2, len - 2)
+   != le16_to_cpu(ep->crc)) || strncmp(ep->sig, "EPPS", 4)) {
+   pr_debug("fail in the CRC.\n");
+   ret = -EINVAL;
+   goto ext_out;
+   }
+
+   /* find the ECC section. */
+   cursor = (uint8_t *)(ep + 1);
+   for (i = 0; i < ONFI_EXT_SECTION_MAX; i++) {
+   s = ep->sections + i;
+   if (s->type == ONFI_SECTION_TYPE_2)
+   break;
+   cursor += s->length * 16;
+   }
+   if (i == ONFI_EXT_SECTION_MAX) {
+   pr_debug("We can not find the ECC section.\n");
+   ret = -EINVAL;
+   goto ext_out;
+   }
+
+   /* get the info we want. */
+   ecc = (struct onfi_ext_ecc_info *)cursor;
+
+   if (ecc->codeword_size) {
+   chip->ecc_strength_ds = ecc->ecc_bits;
+   chip->ecc_step_ds = 1 << ecc->codeword_size;
+   }
+
+   pr_info("ONFI extended param page detected.\n");
+   return 0;
+
+ext_out:
+   kfree(ep);
+   return ret;
+}
+
 /*
  * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
  */
@@ -2903,6 +2968,21 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
if (p->ecc_bits != 0xff) {
chip->ecc_strength_ds = p->ecc_bits;
chip->ecc_step_ds = 512;
+   } else if (chip->onfi_version >= 21 &&
+   (onfi_feature(chip) & ONFI_FEATURE_EXT_PARAM_PAGE)) {
+
+   /*
+* The nand_flash_detect_ext_param_page() uses the
+* Change Read Column command which maybe not supported
+* by the chip->cmdfunc. So try to update the chip->cmdfunc
+* now. We do not replace user supplied command function.
+*/
+   if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
+   chip->cmdfunc = nand_command_lp;
+
+   /* The Extended Parameter Page is supported since ONFI 2.1. */
+   if (nand_flash_detect_ext_param_page(mtd, chip, p))
+   pr_info("Failed to detect the extended param page.\n");
}
 
pr_info("ONFI flash detected\n");
-- 
1.7.1


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

Re: [PATCH] memcg: update TODO list in Documentation

[Kamezawa Hiroyuki]

(2013/05/17 12:29), Li Zefan wrote:
> hugetlb cgroup has already been implemented.
> 
> Signed-off-by: Li Zefan 

Acked-by: KAMEZAWA Hiroyuki 

> ---
>   Documentation/cgroups/memory.txt | 7 +++
>   1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/cgroups/memory.txt 
> b/Documentation/cgroups/memory.txt
> index ddf4f93..327acec 100644
> --- a/Documentation/cgroups/memory.txt
> +++ b/Documentation/cgroups/memory.txt
> @@ -834,10 +834,9 @@ Test:
>   
>   12. TODO
>   
> -1. Add support for accounting huge pages (as a separate controller)
> -2. Make per-cgroup scanner reclaim not-shared pages first
> -3. Teach controller to account for shared-pages
> -4. Start reclamation in the background when the limit is
> +1. Make per-cgroup scanner reclaim not-shared pages first
> +2. Teach controller to account for shared-pages
> +3. Start reclamation in the background when the limit is
>  not yet hit but the usage is getting closer
>   
>   Summary
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 02/10] mtd: get the ECC info from the parameter page for ONFI nand

[Huang Shijie]

>From the ONFI spec, we can just get the ECC info from the @ecc_bits field of
the parameter page.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index edc7663..b63b731 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2900,6 +2900,11 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
if (le16_to_cpu(p->features) & 1)
*busw = NAND_BUSWIDTH_16;
 
+   if (p->ecc_bits != 0xff) {
+   chip->ecc_strength_ds = p->ecc_bits;
+   chip->ecc_step_ds = 512;
+   }
+
pr_info("ONFI flash detected\n");
return 1;
 }
-- 
1.7.1


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

[PATCH v6 10/10] mtd: gpmi: set the BCH's geometry with the ecc info

[Huang Shijie]

If the nand chip provides us the ECC info, we can use it firstly.
The set_geometry_by_ecc_info() will use the ECC info, and
calculate the parameters we need.

Rename the old code to legacy_set_geometry() which will takes effect
when there is no ECC info from the nand chip or we fails in the ECC info case.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  132 +++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 25ecfa1..92c760b 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -112,7 +112,132 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data 
*this)
return true;
 }
 
-int common_nfc_set_geometry(struct gpmi_nand_data *this)
+/*
+ * If we can get the ECC information from the nand chip, we do not
+ * need to calculate them ourselves.
+ *
+ * We may have available oob space in this case.
+ */
+static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this)
+{
+   struct bch_geometry *geo = >bch_geometry;
+   struct mtd_info *mtd = >mtd;
+   struct nand_chip *chip = mtd->priv;
+   struct nand_oobfree *of = gpmi_hw_ecclayout.oobfree;
+   unsigned int block_mark_bit_offset;
+
+   if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
+   return false;
+
+   switch (chip->ecc_step_ds) {
+   case SZ_512:
+   geo->gf_len = 13;
+   break;
+   case SZ_1K:
+   geo->gf_len = 14;
+   break;
+   default:
+   dev_err(this->dev,
+   "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
+   chip->ecc_strength_ds, chip->ecc_step_ds);
+   return false;
+   }
+   geo->ecc_chunk_size = chip->ecc_step_ds;
+   geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
+   if (!gpmi_check_ecc(this))
+   return false;
+
+   /* Keep the C >= O */
+   if (geo->ecc_chunk_size < mtd->oobsize) {
+   dev_err(this->dev,
+   "unsupported nand chip. ecc size: %d, oob size : %d\n",
+   chip->ecc_step_ds, mtd->oobsize);
+   return false;
+   }
+
+   /* The default value, see comment in the legacy_set_geometry(). */
+   geo->metadata_size = 10;
+
+   geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size;
+
+   /*
+* Now, the NAND chip with 2K page(data chunk is 512byte) shows below:
+*
+*|  P|
+*|<->|
+*|   |
+*|(Block Mark)   |
+*|  P'  |  | | |
+*|<>|  D   | |  O' |
+*|  |<>| |<--->|
+*V  V  V V V
+*+---+--+-+--+-+--+-+--+-+-+
+*| M |   data   |E|   data   |E|   data   |E|   data   |E| |
+*+---+--+-+--+-+--+-+--+-+-+
+*   ^  ^
+*   |  O   |
+*   |<>|
+*   |  |
+*
+*  P : the page size for BCH module.
+*  E : The ECC strength.
+*  G : the length of Galois Field.
+*  N : The chunk count of per page.
+*  M : the metasize of per page.
+*  C : the ecc chunk size, aka the "data" above.
+*  P': the nand chip's page size.
+*  O : the nand chip's oob size.
+*  O': the free oob.
+*
+*  The formula for P is :
+*
+*  E * G * N
+* P =  + P' + M
+*  8
+*
+* The position of block mark moves forward in the ECC-based view
+* of page, and the delta is:
+*
+*   E * G * (N - 1)
+* D = ( + M)
+*  8
+*
+* Please see the comment in legacy_set_geometry().
+* With the condition C >= O , we still can get same result.
+* So the bit position of the physical block mark within the ECC-based
+* view of the page is :
+* (P' - D) * 8
+*/
+   geo->page_size = mtd->writesize + 

[PATCH v6 01/10] mtd: add datasheet's ECC information to nand_chip{}

[Huang Shijie]

1.) Why add the ECC information to the nand_chip{} ?
   Each nand chip has its requirement for the ECC correctability, such as
   "4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte".
   This ECC info is very important to the nand controller, such as gpmi.

   Take the Micron MT29F64G08CBABA for example, its geometry is
   8k page size, 744 bytes oob size and it requires 40bit ECC per 1K bytes.
   If we do not provide the ECC info to the gpmi nand driver, it has to
   calculate the ECC correctability itself. The gpmi driver will gets the 56bit
   ECC for per 1K bytes which is beyond its BCH's 40bit ecc capibility.
   The gpmi will quits in this case. But in actually, the gpmi can supports
   this nand chip if it can get the right ECC info.

2.) about the new fields.
   The @ecc_strength_ds stands for the ecc bits needed within the @ecc_step_ds.
   The two fields should be set from the nand chip's datasheets.

   For example:
"4bit ECC for each 512Byte" could be:
@ecc_strength_ds = 4, @ecc_step_ds = 512.
"40bit ECC for each 1024Byte" could be:
@ecc_strength_ds = 40, @ecc_step_ds = 1024.

3.) Why do not re-use the @strength and @size in the nand_ecc_ctrl{}?
   The @strength and @size in nand_ecc_ctrl{} is used by the nand controller
   driver, while the @ecc_strength_ds and @ecc_step_ds are get from the 
datasheet.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 38535eb..ee696f1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -434,6 +434,12 @@ struct nand_buffers {
  * bad block marker position; i.e., BBM == 0111b is
  * not bad when badblockbits == 7
  * @cellinfo:  [INTERN] MLC/multichip data from chip ident
+ * @ecc_strength_ds:   [INTERN] ECC correctability from the datasheet.
+ * Minimum amount of bit errors per @ecc_step_ds guaranteed
+ * to be correctable. If unknown, set to zero.
+ * @ecc_step_ds:   [INTERN] ECC step required by the @ecc_strength_ds,
+ *  also from the datasheet. It is the recommended ECC step
+ * size, if known; if unknown, set to zero.
  * @numchips:  [INTERN] number of physical chips
  * @chipsize:  [INTERN] the size of one chip for multichip arrays
  * @pagemask:  [INTERN] page number mask = number of (pages / chip) - 1
@@ -510,6 +516,8 @@ struct nand_chip {
unsigned int pagebuf_bitflips;
int subpagesize;
uint8_t cellinfo;
+   uint16_t ecc_strength_ds;
+   uint16_t ecc_step_ds;
int badblockpos;
int badblockbits;
 
-- 
1.7.1


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

[PATCH v6 09/10] mtd: add the ecc info for some full-id nand chips

[Huang Shijie]

Add the ecc info for TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2 and TC58NVG6D2.

>From these chips' datasheets, we know that:
   The TC58NVG2S0F and TC58NVG3S0F require 4bit ECC for per 512byte.
   The TC58NVG5D2 and TC58NVG6D2 require 40bits ECC for per 1024byte.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_ids.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 683813a..a87b0a3 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -33,16 +33,16 @@ struct nand_flash_dev nand_flash_ids[] = {
 */
{"TC58NVG2S0F 4G 3.3V 8-bit",
{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
- SZ_4K, SZ_512, SZ_256K, 0, 8, 224},
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
{"TC58NVG3S0F 8G 3.3V 8-bit",
{ .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
- SZ_4K, SZ_1K, SZ_256K, 0, 8, 232},
+ SZ_4K, SZ_1K, SZ_256K, 0, 8, 232, NAND_ECC_INFO(4, SZ_512) },
{"TC58NVG5D2 32G 3.3V 8-bit",
{ .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
- SZ_8K, SZ_4K, SZ_1M, 0, 8, 640},
+ SZ_8K, SZ_4K, SZ_1M, 0, 8, 640, NAND_ECC_INFO(40, SZ_1K) },
{"TC58NVG6D2 64G 3.3V 8-bit",
{ .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
- SZ_8K, SZ_8K, SZ_2M, 0, 8, 640},
+ SZ_8K, SZ_8K, SZ_2M, 0, 8, 640, NAND_ECC_INFO(40, SZ_1K) },
 
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
-- 
1.7.1


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

[PATCH v6 06/10] mtd: replace the hardcode with the onfi_feature()

[Huang Shijie]

The current code uses the hardcode to detect the 16-bit bus width.
Use the onfi_feature() to replace it.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 0b1162a..355976d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2961,9 +2961,9 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
chip->chipsize = le32_to_cpu(p->blocks_per_lun);
chip->chipsize *= (uint64_t)mtd->erasesize * p->lun_count;
-   *busw = 0;
-   if (le16_to_cpu(p->features) & 1)
-   *busw = NAND_BUSWIDTH_16;
+
+   *busw = (onfi_feature(chip) & ONFI_FEATURE_16_BIT_BUS) ?
+   NAND_BUSWIDTH_16 : 0;
 
if (p->ecc_bits != 0xff) {
chip->ecc_strength_ds = p->ecc_bits;
-- 
1.7.1


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

[PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{}

[Huang Shijie]

1.) Why add the ECC information to the nand_chip{} ?
   Each nand chip has its requirement for the ECC correctability, such as
   "4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte".
   This ECC info is very important to the nand controller, such as gpmi.

   Take the Micron MT29F64G08CBABA for example, its geometry is
   8k page size, 744 bytes oob size and it requires 40bit ECC per 1K bytes.
   If we do not provide the ECC info to the gpmi nand driver, it has to
   calculate the ECC correctability itself. The gpmi driver will gets the 56bit
   ECC for per 1K bytes which is beyond its BCH's 40bit ecc capibility.
   The gpmi will quits in this case. But in actually, the gpmi can supports
   this nand chip if it can get the right ECC info.

2.) About the patch set:
   2.1) patch 1:
  The keynote patch.

   2.2) patch 2 ~ patch 6:
   These patches are for ONFI nand.
   Parse out the ecc info from the parameter page if we can, else
   parse out the ecc info from the extended parameter page.
   
   2.2) patch 7 ~ patch 9:
   Add the ECC info for full-id nand, and parse it out.

   2.3) patch 10 
   The gpmi uses the ecc info to set the BCH module. and with this
   patch set, the gpmi can supports the MT29F64G08CBABA now.

v5 --> v6:
[0] rename the ecc_strength/ecc_step to ecc_strength_ds/ecc_step_ds.
[1] fix a case when "the codeword is 0".
[2] fix typo.
[3] add the 'O' to the diagram in the gpmi patch.

v4 --> v5:
[0] rebase the new l2-mtd(dropped the 3 merged patches).
[1] rename ecc_size to ecc_step.
[2] change the comment for the new fields.

v3 --> v4:
[0] remove the printk for "out of memory".
[1] remove the hardcode nand_command_lp(). Update the chip->cmd_func
before we call the nand_flash_detect_ext_param_page().
[2] split the ecc_info to two fields for full id nand.
[3] update the comments for ecc_strength/ecc_size (from Brian).
   
v2 --> v3:
[0] add a new patch to define the semantics of the two fields.
[1] Use the Change Read Column command to remove the "last" argument.
[2] simplify the onfi_feature().
[3] Use kmalloc() to replace kcalloc().
[4] others.

v1 --> v2:
[0] Since the first 3 patches are accepted, I do not send them in the
version 2.
[1] add NAND_ prefix for macros used by the full-id nands.
[2] add onfi_ prefix for the extend parameter page data structures.
[3] rename the onfi_get_feature() to onfi_feature().
[4] I re-test this patch set again.

Huang Shijie (10):
  mtd: add datasheet's ECC information to nand_chip{}
  mtd: get the ECC info from the parameter page for ONFI nand
  mtd: add data structures for Extended Parameter Page
  mtd: add a helper to get the supported features for ONFI nand
  mtd: get the ECC info from the Extended Parameter Page
  mtd: replace the hardcode with the onfi_feature()
  mtd: add ECC info for nand_flash_dev{}
  mtd: parse out the ECC info for the full-id nand chips
  mtd: add the ecc info for some full-id nand chips
  mtd: gpmi: set the BCH's geometry with the ecc info

 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  132 +++-
 drivers/mtd/nand/nand_base.c   |   93 ++-
 drivers/mtd/nand/nand_ids.c|8 +-
 include/linux/mtd/nand.h   |   72 +-
 4 files changed, 296 insertions(+), 9 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: android: sync: fixed a brace coding style issue

[Greg KH]

On Thu, May 16, 2013 at 08:42:22AM -1000, bmhei...@gmail.com wrote:
> From: Brandon Height 
> 
> Fixed a coding style issue.
> 
> Signed-off-by: Brandon Height 

This doesn't apply to my tree, can you please redo it against linux-next
and resend?

thanks,

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

Re: [PATCH] Staging: Goldfish: goldfish_nand: Fixed all checkpatch errors

[Greg KH]

On Sat, May 04, 2013 at 12:55:12PM -0400, jake.champlin...@gmail.com wrote:
> From: Jake Champlin 
> 
> Fixed all checkpatch errors included inside goldfish_nand.c.
> Checkpatch is now clean for goldfish_nand.c
> 
> Signed-off-by: "Jake Champlin" 

Can you respin this against linux-next as it doesn't seem to apply to my
tree at all.

thanks,

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

Re: [PATCH 1/1] Staging: hv: Fix a bug in get_vp_index()

[Greg KH]

On Fri, May 10, 2013 at 08:47:01AM -0700, K. Y. Srinivasan wrote:
> Linux' notion of cpuid is different from the Host's notion of CPUID. In the
> call to bind the channel interrupts, we should use the host's notion of
> CPU Ids. Fix this bug.
> 
> Signed-off-by: K. Y. Srinivasan 
> Cc: Stable  (V3.9)
> ---
>  drivers/hv/channel_mgmt.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Why do you have "Staging" in the Subject:?  This isn't a staging driver
anymore, right?

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

[PATCH] memcg: update TODO list in Documentation

[Li Zefan]

hugetlb cgroup has already been implemented.

Signed-off-by: Li Zefan 
---
 Documentation/cgroups/memory.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ddf4f93..327acec 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -834,10 +834,9 @@ Test:
 
 12. TODO
 
-1. Add support for accounting huge pages (as a separate controller)
-2. Make per-cgroup scanner reclaim not-shared pages first
-3. Teach controller to account for shared-pages
-4. Start reclamation in the background when the limit is
+1. Make per-cgroup scanner reclaim not-shared pages first
+2. Teach controller to account for shared-pages
+3. Start reclamation in the background when the limit is
not yet hit but the usage is getting closer
 
 Summary
-- 
1.8.0.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: [WiP]: aio support for migrating pages (Re: [PATCH V2 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable())

[Tang Chen]

Hi Benjamin,

Thank you very much for your idea. :)

I have no objection to your idea, but seeing from your patch, this only
works for aio subsystem because you changed the way to allocate the aio
ring pages, with a file mapping.

So far as I know, not only aio, but also other subsystems, such CMA, will
also have problem like this. The page cannot be migrated because it is
pinned in memory. So I think we should work out a common way to solve how
to migrate pinned pages.

I'm working in the way Mel has said, migrate_unpin() and migrate_pin()
callbacks. But as you saw, I met some problems, like I don't where to put
these two callbacks. And discussed with you guys, I want to try this:

1. Add a new member to struct page, used to remember the pin holders of
   this page, including the pin and unpin callbacks and the necessary data.
   This is more like a callback chain.
   (I'm worry about this step, I'm not sure if it is good enough. After 
all,

we need a good place to put the callbacks.)

And then, like Mel said,

2. Implement the callbacks in the subsystems, and register them to the
   new member in struct page.

3. Call these callbacks before and after migration.


I think I'll send a RFC patch next week when I finished the outline. I'm
just thinking of finding a common way to solve this problem that all the
other subsystems will benefit.

Thanks. :)


On 05/17/2013 08:23 AM, Benjamin LaHaise wrote:

On Thu, May 16, 2013 at 01:54:18PM +0800, Tang Chen wrote:
...

OK, I'll try to figure out a proper place to put the callbacks.
But I think we need to add something new to struct page. I'm just
not sure if it is OK. Maybe we can discuss more about it when I send
a RFC patch.

...

I ended up working on this a bit today, and managed to cobble together
something that somewhat works -- please see the patch below.  It still is
not completely tested, and it has a rather nasty bug owing to the fact
that the file descriptors returned by anon_inode_getfile() all share the
same inode (read: more than one instance of aio does not work), but it
shows the basic idea.  Also, bad things probably happen if someone does
an mremap() on the aio ring buffer.  I'll polish this off sometime next
week after the long weekend if noone beats me to it.

-ben

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

Re: [PATCH v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[H. Peter Anvin]

On 05/16/2013 07:53 PM, Eric W. Biederman wrote:
> 
> That is completely and totally orthogonal to this change.
> 
> read_oldmem may have problems but in practice on a large systems those
> problems are totally dwarfed by real life performance issues that come
> from playing too much with the page tables.
> 
> I really don't find bringing up whatever foundational issues you have
> with read_oldmem() appropriate or relevant here.
> 

Well, it is in the sense that we have two pieces of code doing the same
thing, each with different bugs.

-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: linux-next: Tree for May 15 (crypto /crct10dif)

[Xiong Zhou]

2013/5/17 Tim Chen :
> On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
>> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
>> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou  
>> > wrote:
>> > > --- a/crypto/Kconfig
>> > > +++ b/crypto/Kconfig
>> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>> > >
>> > >  config CRYPTO_CRCT10DIF
>> > > tristate "CRCT10DIF algorithm"
>> > > +   depends on CRC_T10DIF
>> >
>> > This is a library symbol, so "select CRC_T10DIF"?
>> >
>> > > select CRYPTO_HASH
>> > > help
>> > >   CRC T10 Data Integrity Field computation is being cast as
>> >
>> > Gr{oetje,eeting}s,
>> >
>> > Geert
>> >
>>
>> This is the fix I think that will resolve the build issues.  The generic
>> crc-t10dif transform depends on the library function crc_t10dif_generic
>> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
>> needed.
>>
>> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
>> allocate a T10DIF transform if it is available.  If not, it will simply
>> use the crc_t10dif_generic function. Loading the
>> generic t10dif crypto transform is not mandatory for the library
>> function crc_t10dif.
>>
>> Thanks for catching the issues.
>>
>> Tim
>>

cool.

>
> Need to also add select CRYPTO for CRC_T10DIF.  Updated fix below:
>
>
> Signed-off-by: Tim Chen 
> ---
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index d1ca631..015df24 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
>  config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> select CRYPTO_HASH
> +   depends on CRC_T10DIF
> help
>   CRC T10 Data Integrity Field computation is being cast as
>   a crypto transform.  This allows for faster crc t10 diff
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 0cee056..6407793 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -63,7 +63,8 @@ config CRC16
>
>  config CRC_T10DIF
> tristate "CRC calculation for the T10 Data Integrity Field"
> -   select CRYPTO_CRCT10DIF
> +   select CRYPTO
> +   select CRYPTO_HASH
> help
>   This option is only needed if a module that's not in the
>   kernel tree needs to calculate CRC checks for use with the
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for May 15 (crypto /crct10dif)

[Xiong Zhou]

2013/5/16 Geert Uytterhoeven :
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou  wrote:
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>>
>>  config CRYPTO_CRCT10DIF
>> tristate "CRCT10DIF algorithm"
>> +   depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?

En.. make sense, Thanks.

Xiong

>
>> select CRYPTO_HASH
>> help
>>   CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: lustre: fix return type of lo_release.

[Peng, Tao]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, May 17, 2013 3:02 AM
> To: Cyril Roelandt
> Cc: kernel-janit...@vger.kernel.org; andreas.dil...@intel.com; Peng, Tao; 
> de...@driverdev.osuosl.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] staging: lustre: fix return type of lo_release.
> 
> On Thu, May 16, 2013 at 06:06:20PM +0200, Cyril Roelandt wrote:
> > The return type of block_device_operations.release() changed to void in 
> > commit
> > db2a144b.
> 
> Interesting, how did you test build this patch, given that the driver
> doesn't currently build at all?  :)
> 
> Anyway, thanks, I'll go queue this up.
My stupid email client... Just saw this one. Please ignore my previous mail. 
Sorry for the noise.

Thanks,
Tao

Re: [PATCH v4] watchdog: Add Broadcom BCM2835 watchdog timer driver

[Stephen Warren]

On 03/27/2013 10:40 AM, Lubomir Rintel wrote:
> This adds a driver for watchdog timer hardware present on Broadcom BCM2835 
> SoC,
> used in Raspberry Pi and Roku 2 devices.

Lubomir, I don't believe this patch was applied for 3.10. Are you
planning to fix up any remaining issues and repost for 3.11?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On 05/15/2013 02:05 AM, HATAYAMA Daisuke wrote:
>> Currently, read to /proc/vmcore is done by read_oldmem() that uses
>> ioremap/iounmap per a single page. For example, if memory is 1GB,
>> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
>> times. This causes big performance degradation.
>
> read_oldmem() is fundamentally broken and unsafe.  It needs to be
> unified with the plain /dev/mem code and any missing functionality fixed
> instead of "let's just do a whole new driver".

That is completely and totally orthogonal to this change.

read_oldmem may have problems but in practice on a large systems those
problems are totally dwarfed by real life performance issues that come
from playing too much with the page tables.

I really don't find bringing up whatever foundational issues you have
with read_oldmem() appropriate or relevant here.

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: [PATCH] kernel/workqueue.c: need call device_remove_file() when failure occurs after called device_create_file()

[Chen Gang]

On 05/17/2013 01:50 AM, Tejun Heo wrote:
> Hey,
> 
> On Thu, May 16, 2013 at 12:48:43PM +0800, Chen Gang wrote:
>> __sysfs_remove_dir() remove all related things, but not deref the count.
>>
>> For __sysfs_remove_dir() ->
>>   ...
>>   sysfs_addrm_start()
>>   ...
>>   while() {
>> ...
>> sysfs_remove_one()  (not deref the related file)
>>   }
>>   sysfs_addrm_finish()  (will deref current dir)
>>
>> For device_remove_file() ->
>>   sysfs_remove_file() ->
>> sysfs_hash_and_remove() ->
>>   ...
>>   sysfs_addrm_start()
>>   ...
>>   sysfs_remove_one() (not deref the current file)
>>   sysfs_addrm_finish()  (will deref current file)
>>
>>
>> So if not call device_remove_file() firstly, the all files under the
>> directory are removed, but the related resources are not released which
>> will cause resource leak.
> 
> Can you please be more specific on what gets leaked and if possible
> fix it from sysfs side?
> 

Oh, it is my fault. It is not the correct reason.

But I will continue to analyse why it should be add device_remove_file()
before device_unregister() in all 'drivers/*' and 'arch/*' source files.


Thanks.
-- 
Chen Gang

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

RE: [PATCH] virtio-net: Reporting traffic queue distribution statistics through ethtool

[Narasimhan, Sriram]

Thanks for the pointer to the earlier discussion thread.
I am open to any consensus format.  I would also like to
get feedback from Michael on maintaining the stats in the
per-queue data structure.

Sriram

-Original Message-
From: Ben Hutchings [mailto:bhutchi...@solarflare.com] 
Sent: Thursday, May 16, 2013 2:48 PM
To: Narasimhan, Sriram
Cc: m...@redhat.com; ru...@rustcorp.com.au; 
virtualizat...@lists.linux-foundation.org; k...@vger.kernel.org; 
net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution 
statistics through ethtool

On Thu, 2013-05-16 at 13:24 -0700, Sriram Narasimhan wrote:
> This patch allows virtio-net driver to report traffic distribution
> to inbound/outbound queues through ethtool -S.  The per_cpu
> virtnet_stats is split into receive and transmit stats and are
> maintained on a per receive_queue and send_queue basis.
> virtnet_stats() is modified to aggregate interface level statistics
> from per-queue statistics.  Sample output below:
> 
> NIC statistics:
>  rxq0: rx_packets: 4357802
>  rxq0: rx_bytes: 292642052
>  txq0: tx_packets: 824540
>  txq0: tx_bytes: 55256404
>  rxq1: rx_packets: 0
>  rxq1: rx_bytes: 0
>  txq1: tx_packets: 1094268
>  txq1: tx_bytes: 73328316
>  rxq2: rx_packets: 0
>  rxq2: rx_bytes: 0
>  txq2: tx_packets: 1091466
>  txq2: tx_bytes: 73140566
>  rxq3: rx_packets: 0
>  rxq3: rx_bytes: 0
>  txq3: tx_packets: 1093043
>  txq3: tx_bytes: 73246142
> 
> Signed-off-by: Sriram Narasimhan 
[...]

That ordering is totally unreadable.  I want to see patches for ethtool
to let the user order and aggregate the queue statistics in a sensible
way:

$ ethtool -S eth0   # default would show aggregated statistics
NIC statistics:
rx_packets: 4357802
rx_bytes: 292642052
tx_packets: 4103317
tx_bytes: 274971428

$ ethtool -S eth0 full group queue  # full statistics, grouped by queue name
NIC statistics:
rxq0:
rx_packets: 4357802
rx_bytes: 292642052
rxq1:
rx_packets: 0
rx_bytes: 0
[...]
txq0:
tx_packets: 824540
tx_bytes: 55256404
txq1:
tx_packets: 1094268
tx_bytes: 73328316
[...]

$ ethtool -S eth0 full group statistic  # full statistics, grouped by statistic 
name
NIC statistics:
rx_packets:
rxq0: 4357802
rxq1: 0
rxq2: 0
rxq3: 0
rx_bytes:
rxq0: 292642052
rxq1: 0
rxq2: 0
rxq3: 0
[...]

Maybe even:

$ ethtool -S eth0 full table
NIC statistics:
rx_packets   rx_bytes
rxq0:  4357802  292642052
rxq1:0  0
rxq2:0  0
rxq3:0  0
tx_packets   tx_bytes
txq0:   824540   55256404
txq1:  1094268   73328316
txq2:  1091466   73140566
txq3:  1093043   73246142

(Difficult to do, but probably very useful!)

The queue names should be rx- and tx- like in sysfs.

We'll need to reach a consensus on the naming scheme for per-queue and
otherwise disaggregated statistics (see previous discussions in
). 
 I don't much care what they look like as long as there's an implementation for 
the ethtool side and they don't look too awful in older versions of ethtool.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

[PATCH 3/3] watchdog: Remove softlockup_thresh from Documentation

[Li Zefan]

The old softlockup detector has been replaced with new lockup
detector long ago.

Signed-off-by: Li Zefan 
---
 Documentation/sysctl/kernel.txt | 10 --
 1 file changed, 10 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index e8fabd6..bcff3f9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -70,7 +70,6 @@ show up in /proc/sys/kernel:
 - shmall
 - shmmax  [ sysv ipc ]
 - shmmni
-- softlockup_thresh
 - stop-a  [ SPARC only ]
 - sysrq   ==> Documentation/sysrq.txt
 - tainted
@@ -605,15 +604,6 @@ without users and with a dead originative process will be 
destroyed.
 
 ==
 
-softlockup_thresh:
-
-This value can be used to lower the softlockup tolerance threshold.  The
-default threshold is 60 seconds.  If a cpu is locked up for 60 seconds,
-the kernel complains.  Valid values are 1-60 seconds.  Setting this
-tunable to zero will disable the softlockup detection altogether.
-
-==
-
 tainted:
 
 Non-zero if the kernel has been tainted.  Numeric values, which
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] watchdog: Disallow setting watchdog_thresh to -1

[Li Zefan]

In old kernels, it's allowed to set softlockup_thresh to -1 or 0
to disable softlockup detection. However watchdog_thresh only
uses 0 to disable detection, and setting it to -1 just froze my
box and nothing I can do but reboot.

Signed-off-by: Li Zefan 
---
 kernel/sysctl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 9edcf45..b0a1f99 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -120,7 +120,6 @@ extern int blk_iopoll_enabled;
 /* Constants used for minimum and  maximum */
 #ifdef CONFIG_LOCKUP_DETECTOR
 static int sixty = 60;
-static int neg_one = -1;
 #endif
 
 static int zero;
@@ -814,7 +813,7 @@ static struct ctl_table kern_table[] = {
.maxlen = sizeof(int),
.mode   = 0644,
.proc_handler   = proc_dowatchdog,
-   .extra1 = _one,
+   .extra1 = ,
.extra2 = ,
},
{
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] watchdog: Document watchdog_thresh sysctl

[Li Zefan]

Signed-off-by: Li Zefan 
---
 Documentation/sysctl/kernel.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ccd4258..e8fabd6 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -76,6 +76,7 @@ show up in /proc/sys/kernel:
 - tainted
 - threads-max
 - unknown_nmi_panic
+- watchdog_thresh
 - version
 
 ==
@@ -648,3 +649,16 @@ that time, kernel debugging information is displayed on 
console.
 
 NMI switch that most IA32 servers have fires unknown NMI up, for
 example.  If a system hangs up, try pressing the NMI switch.
+
+==
+
+watchdog_thresh:
+
+This value can be used to control the frequency of hrtimer and NMI
+events and the soft and hard lockup thresholds. The default threshold
+is 10 seconds.
+
+The softlockup threshold is (2 * watchdog_thresh). Setting this
+tunable to zero will disable lockup detection altogether.
+
+==
-- 
1.8.0.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: [Bug] ARM 'perf' regression by commit a43cb95d5

[Ming Lei]

On Fri, May 17, 2013 at 10:16 AM, Ming Lei  wrote:
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index f219703..89bc3a4 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -225,7 +225,7 @@ void __show_regs(struct pt_regs *regs)
> unsigned long flags;
> char buf[64];
>
> -   show_regs_print_info(KERN_DEFAULT);
> +   //show_regs_print_info(KERN_DEFAULT);

Forget to mention, __show_regs() isn't run under both cases.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xen: reuse the same pirq allocated when driver load first time

[Zhenzhong Duan]

On 2013-05-15 17:41, Stefano Stabellini wrote:

On Tue, 14 May 2013, Konrad Rzeszutek Wilk wrote:

On Tue, May 14, 2013 at 02:49:50PM +0100, Stefano Stabellini wrote:

On Mon, 13 May 2013, Konrad Rzeszutek Wilk wrote:

On Mon, May 13, 2013 at 06:24:46PM +0100, Stefano Stabellini wrote:

On Mon, 13 May 2013, Konrad Rzeszutek Wilk wrote:

On Mon, May 13, 2013 at 03:50:52PM +0100, Stefano Stabellini wrote:

On Mon, 13 May 2013, Konrad Rzeszutek Wilk wrote:

On Mon, May 13, 2013 at 12:06:43PM +0100, Stefano Stabellini wrote:

On Fri, 10 May 2013, Konrad Rzeszutek Wilk wrote:

On Wed, May 08, 2013 at 04:18:24PM +0800, Zhenzhong Duan wrote:

When driver load and unload in a loop, pirq will exhaust finally.
Try to use the same pirq which was already mapped and binded at first time

So what happens if I unload and reload two drivers in random order?


when driver loaded.

Read pirq from msix entry and test if data is XEN_PIRQ_MSI_DATA
xen_irq_from_pirq(pirq) < 0 checking is wrong as irq will be freed
when driver unload, it's always true in second load.

If my understanding is right the issue at hand is that the caching
information about the pirq disappears once the driver has been
unloaded b/c the event's irq-info is removed (as the driver is
unloaded and free_irq is called).

Stefano,
Is there a specific write to the MSI structure that would cause the
hypervisor to drop the PIRQ? Or a nice hypercall to "free" an
PIRQ in usage?

We already have a "free PIRQ" hypercall, it's called
PHYSDEVOP_unmap_pirq and should be called by QEMU.

Considering that we call function that allocates (PHYSDEVOP_get_free_pirq)
it in the Linux kernel (and not in QEMU), perhaps that should be done in the
Linux kernel as part of xen_destroy_irq()? Or would that confuse QEMU?

I think it would confuse QEMU. It is probably better to let the unmap
being handled by it.



It looks like QEMU only does that hypercall (via xc_physdev_unmap_pirq)
unregister_real_device which is only called during pci unplug?

You are right! I would think that this behaviour is erroneous unless it
was done on purpose to avoid allocating MSIs twice.
If that is the case we would need to do something similar in Linux too.

I think that the issue is the mismatch between QEMU's and Linux's
behaviours: either both should be allocating MSIs once, or they should
both be allocating and deallocating MSIs every time the driver is loaded
and unloaded.

Right. But we also have the scenario that QEMU and Linux are going to
be out of sync. So we need fixes in both places - I think.

QEMU is the owner of the pirq, in fact it is the one that creates and
destroys the mapping. I think that the right place to fix this problem
is in QEMU, the ABI would be much cleaner as a result. As a side effect
we don't need to make any changes in Linux.

You do. You need to remove the PHYSDEVOP_get_free_pirq call in that case.
  
PHYSDEVOP_get_free_pirq needs to stay, because Linux needs to know the

pirq that QEMU is going to use.

That looks like an API violation. We have an hypercall that
allocates the PIRQ in the Linux, then two hypercalls in the QEMU
layer - one to map, and the other to unmap and free.


However I would let QEMU handle the mapping (it already does that in
pt_msi_setup calling xc_physdev_map_pirq_msi) and unmapping (that is
done by calling xc_domain_unbind_msi_irq from pt_msi_disable).
I think the problem is that pt_msi_disable is only called on
unregister_real_device and pt_reset_interrupt_and_io_mapping, not when
the guest disables MSIs.

Sure, I am not disputing that. I think the fix in QEMU to call the
unmap is correct.

But I am also wondering whether it makes sense to do that in the Linux
kernel - as it does the alloc in the first place. Seems like a bit of
duct-tape has been used to connect this plumbing together.


I admit that it is not a great interface.
I would be open to options that move the entire setup/freeing in Linux,
but keep in mind that we need to retain the pirq code in QEMU for pure
HVM guests.

Hi Stefano,

do you work out a patch for me to test?

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

Re: [PATCH 2/5] perf: Reorder parameters of strglobmatch

[Masami Hiramatsu]

(2013/05/16 23:55), Steven Rostedt wrote:
> On Thu, 2013-05-16 at 20:48 +0900, Masami Hiramatsu wrote:
>> Reorder parameters of strglobmatch() so that the first
>> parameter is the glob pattern as like as regexec(),
>> because the subjective parameter of strglobmatch() must
>> be the glob pattern, but not a sample string.
>> So, the new interface is:
> 
> I'm a bit confused to the rational here. Can you explain in more detail
> to why this patch is actually needed?

Yes, actually, this patch is not needed from the viewpoint of execution,
but less misuse for future use of the strglobmatch, I think.

For example, glob(3) has the pattern parameter as the first one,

   int glob(const char *pattern, int flags,
int (*errfunc) (const char *epath, int eerrno),
glob_t *pglob);

regexec(3) also has the compiled regexp at the first parameter,

   int regexec(const regex_t *preg, const char *string, size_t nmatch,
   regmatch_t pmatch[], int eflags);

Thus, I think a new user of strglobmatch() may guess that the first
parameter should be the glob pattern.

So, this patch is not technically needed, but from the viewpoint of coding
naturally, it should be changed, IMHO.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

[Bug] ARM 'perf' regression by commit a43cb95d5

[Ming Lei]

Hi,

The commit a43cb95d5(dump_stack: unify debug information printed by show_regs())
caused ARM perf regression, then 'perf top' outputs mistakenly, see
[1].  The correct
output should be [2], which can be got after reverting the commit or
doing it partly
by the one line change below:

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f219703..89bc3a4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -225,7 +225,7 @@ void __show_regs(struct pt_regs *regs)
unsigned long flags;
char buf[64];

-   show_regs_print_info(KERN_DEFAULT);
+   //show_regs_print_info(KERN_DEFAULT);


Looks a bit weird, anyone can give a hint?


Thanks,
--
Ming Lei

[1], 'perf top' mistaken output
Samples: 17K of event 'cpu-clock', Event count (approx.): 3516532661
 97.51%  [smsc95xx][k] 0x013645b8
  0.21%  libc-2.15.so  [.] strstr
  0.14%  libc-2.15.so  [.] strchr
  0.12%  libc-2.15.so  [.] strcmp
  0.12%  perf  [.] perf_evsel__parse_sample
  0.09%  perf  [.] symbols__insert
  0.09%  perf  [.] dso__load_sym
  0.08%  perf  [.] perf_top__mmap_read_idx
  0.08%  perf  [.] symbol_filter
  0.07%  libc-2.15.so  [.] memchr
  0.07%  libc-2.15.so  [.] memset
  0.07%  perf  [.] internal_cplus_demangle
  0.06%  perf  [.] sort__dso_cmp
  0.06%  libc-2.15.so  [.] strncmp
  0.06%  perf  [.] add_hist_entry.isra.2
  0.06%  perf  [.] dso__find_symbol
  0.06%  libc-2.15.so  [.] _int_malloc
  0.05%  perf  [.] 0x00010d60
  0.04%  libc-2.15.so  [.] memcpy
  0.04%  perf  [.] map__find_symbol
  0.04%  perf  [.] rb_next
  0.04%  libelf-0.154.so   [.] gelf_getsym


[2], 'perf top' correct output
Samples: 46K of event 'cpu-clock', Event count (approx.): 937128704
 96.44%  [kernel][k] cpuidle_enter_state
  0.19%  libc-2.15.so[.] strstr
  0.16%  [kernel][k] kallsyms_expand_symbol.clone.0
  0.13%  [kernel][k] _raw_spin_unlock_irq
  0.13%  [kernel][k] _raw_spin_unlock_irqrestore
  0.10%  [kernel][k] format_decode
  0.10%  perf[.] perf_top__mmap_read_idx
  0.10%  perf[.] rb_next
  0.09%  perf[.] dso__find_symbol
  0.08%  [kernel][k] vsnprintf
  0.08%  perf[.] add_hist_entry.isra.2
  0.08%  libc-2.15.so[.] strcmp
  0.08%  libc-2.15.so[.] memchr
  0.07%  perf[.] sort__dso_cmp
  0.07%  libc-2.15.so[.] strchr
  0.07%  [kernel][k] number.clone.1
  0.07%  perf[.] map__process_kallsym_symbol
  0.06%  [kernel][k] memcpy
  0.05%  perf[.] perf_evsel__parse_sample
  0.05%  libc-2.15.so[.] _int_malloc
  0.05%  libc-2.15.so[.] memcpy
  0.05%  perf[.] perf_event__preprocess_sample
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] can: flexcan: allow compilation on arm and powerpc

[Shawn Guo]

Hi Marc,

On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
> IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
> all arm and powerpc platforms.

I'm generally fine with the approach.  But with Kconfig symbol
IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
platform-flexcan.o work?

arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) += 
platform-flexcan.o

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: [PATCH 16/20] ARM: mxs: Remove init_irq declaration in machine description

[Shawn Guo]

On Tue, May 14, 2013 at 05:38:49PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for mxs as well.
> 
> Signed-off-by: Maxime Ripard 

Applied, thanks.

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Fix for radeon nomodeset regression, old radeon interface cliprects fix, 2 
qxl crasher fixes, and a couple of minor cleanups.

I may have a new AMD hw support branch next week, its one of those doesn't 
affect anything existing just adds new support, I'll see how it 
shapes up and I might ask you to take it, just thought I'd warn in 
advance.

Dave.

The following changes since commit 9f1d036648c1c5ed81b0e98d7a06d55df972701e:

  drm/mgag200: Fix framebuffer base address programming (2013-05-13 12:17:32 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to e9ced8e040ebe40e9953db90acbe7d0b58702ebb:

  drm/radeon: restore nomodeset operation (v2) (2013-05-17 11:47:07 +1000)


Dave Airlie (6):
  drm: remove unused wrapper macros
  drm/qxl: fix ioport interactions for kernel submitted commands.
  qxl: drop unused variable.
  drm/qxl: drop active_user_framebuffer as its unneeded
  qxl: fix bug with object eviction and update area
  drm/radeon: restore nomodeset operation (v2)

Kees Cook (1):
  drm/radeon: check incoming cliprects pointer

 drivers/gpu/drm/qxl/qxl_cmd.c| 29 +++--
 drivers/gpu/drm/qxl/qxl_display.c| 17 -
 drivers/gpu/drm/qxl/qxl_drv.h|  7 ---
 drivers/gpu/drm/qxl/qxl_ioctl.c  |  1 +
 drivers/gpu/drm/radeon/r300_cmdbuf.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c  | 12 +++-
 include/drm/drm_os_linux.h   |  9 -
 7 files changed, 36 insertions(+), 41 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[HATAYAMA Daisuke]

(2013/05/17 9:06), H. Peter Anvin wrote:

On 05/15/2013 02:05 AM, HATAYAMA Daisuke wrote:

Currently, read to /proc/vmcore is done by read_oldmem() that uses
ioremap/iounmap per a single page. For example, if memory is 1GB,
ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
times. This causes big performance degradation.


read_oldmem() is fundamentally broken and unsafe.  It needs to be
unified with the plain /dev/mem code and any missing functionality fixed
instead of "let's just do a whole new driver".

-hpa


Do you mean range_is_allowed should be extended so that it checks 
according to memory map passed from the 1st kernel?


BTW, read request to read_oldmem via read_vmcore and mmap on some part 
of the 1st kernel, seems safe since it's always restrected to within the 
memory map.


Or is there other missing point?

--
Thanks.
HATAYAMA, Daisuke

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

[PATCH v2 0/2] scsi: Port buslogic driver to 64 bits

[Khalid Aziz]

This patchset ports buslogic driver to 64-bit.

Current buslogic driver is composed of two components - SCCB manager
which communicates with adapter to execute SCSI commands (contained in
FlashPoint.c), and Linux driver part that interfaces with rest of the
kernel (contained in BusLogic.c). SCCB manager code came from the
Mylex SDK. SCCB manager code is used by flashpoint adapters only.
Multimaster adapters do not need SCCB manager since the SCSI state
machine is implemented in firmware on these adapters. If the filenames
alone did not give it away already, buslogic driver code is full of
CamelCase, besides being full of very ling lines, and is just very
difficult to read and understand. So the first step was to clean up
the existing code. First patch in the set does just that. Second patch
includes necessary code modifications to allow the driver to build and
run on 64-bit kernel. Since SCCB manager code came from Mylex SDK, I
have tried to touch it only when necessary which includes not fixing
all CamelCase issues in FlashPoint.c. Many lines over 80 characters
remain in BusLogic.c. These fall into two categories generally -
(1) it prints a message and I didn't want to touch driver messages
in case there are scripts out there that parse driver messages,
(2) code is indented deeply and is hard to keep it under 80 characters.
Such code could use refactoring at some point.

I have tested this patch with a flashpoint adapter on 64-bit and 
32-bit kernels with fio running random read/write test while verifying
data. I also measured performance for current buslogic driver and 
buslogic driver with these patches with 32-bit and 64-bit kernel and
ensured there was no degradation in performance.

Changelog:
v2:
- Updated to apply on top of current Linus' tree as of May 16, 2013. 
  No functional changes.

Khalid Aziz (2):
  Fix CamelCase and extra long lines in the buslogic driver.
  Port buslogic driver to 64-bit.

 drivers/scsi/BusLogic.c   | 4452 -
 drivers/scsi/BusLogic.h   | 1487 ---
 drivers/scsi/FlashPoint.c |  626 +++
 drivers/scsi/Kconfig  |2 +-
 4 files changed, 3377 insertions(+), 3190 deletions(-)

-- 
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] virtio_console: fix uapi header

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> uapi should use __u32 not u32.
> Fix a macro in virtio_console.h which uses u32.
>
> Signed-off-by: Michael S. Tsirkin 

Ouch.  Added CC:stable, and put into fixes.  Mainly because it's
embarrassing :)

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Rusty Russell]

Joe Perches  writes:
> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
>> Asias He  writes:
>> > On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
> []
>> > Other users are using memcpy_fromiovec and friends outside net. It seems
>> > a good idea to put it in a util library. e.g.  crypto/algif_skcipher.c
>> > which also depends on NET for it.
>
> []
>> Subject: Hoist memcpy_fromiovec into lib/
>
> You'll need the "friends" memcpy_toiovec too.
>
> $ git grep -E \bmemcpy\w+iovec\w*"
> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result, len);
> crypto/algif_skcipher.c:err = 
> memcpy_fromiovec(page_address(sg_page(sg)) +
> crypto/algif_skcipher.c:err = 
> memcpy_fromiovec(page_address(sg_page(sg + i)),
> drivers/dma/iovlock.c:#include  /* for memcpy_toiovec */
> drivers/dma/iovlock.c:  return memcpy_toiovec(iov, kdata, len);
> drivers/dma/iovlock.c:  err = memcpy_toiovec(iov, vaddr + offset, 
> len);
> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len), 
> msg->msg_iov, len)) {
> drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
> memcpy_fromiovec((u8 *)va + page_o
> drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
> memcpy_toiovec(iov, (u8 *)va + pag

Fascinating.  These all indirectly depend on NET, so there's no problem
at the moment.  But it is a bit weird...

crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
drivers/dma/iovlock.c: depends on NET_DMA -> NET
drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET

Patch welcome.

Meanwhile, to avoid more bikeshedding I've put the patch I posted with
all acks in my fixes branch.  One cycle through linux-next, then
straight to Linus.

Subject: Hoist memcpy_fromiovec into lib/

ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!

That function is only present with CONFIG_NET.  Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.

socket.h already include uio.h, so no callers need updating.

Reported-by: Randy Dunlap 
Acked-by: David S. Miller 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell 

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 428c37a..7266775 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -305,7 +305,6 @@ struct ucred {
 
 extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct 
ucred *ucred);
 
-extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
 extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
   int offset, int len);
 extern int csum_partial_copy_fromiovecend(unsigned char *kdata, 
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 629aaf5..21628d3 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -35,4 +35,6 @@ static inline size_t iov_length(const struct iovec *iov, 
unsigned long nr_segs)
 }
 
 unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t to);
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
 #endif
diff --git a/lib/Makefile b/lib/Makefile
index e9c52e1..2377211 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -9,7 +9,7 @@ endif
 
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 rbtree.o radix-tree.o dump_stack.o timerqueue.o\
-idr.o int_sqrt.o extable.o \
+idr.o int_sqrt.o extable.o iovec.o \
 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
 proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
 is_single_threaded.o plist.o decompress.o kobject_uevent.o \
diff --git a/lib/iovec.c b/lib/iovec.c
new file mode 100644
index 000..632c5ea
--- /dev/null
+++ b/lib/iovec.c
@@ -0,0 +1,29 @@
+#include 
+#include 
+#include 
+
+/*
+ * Copy iovec to kernel. Returns -EFAULT on error.
+ *
+ * Note: this modifies the original iovec.
+ */
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
+{
+   while (len > 0) {
+   if (iov->iov_len) {
+   int copy = min_t(unsigned int, len, iov->iov_len);
+   if (copy_from_user(kdata, iov->iov_base, copy))
+   return -EFAULT;
+   len -= copy;
+   kdata += copy;
+   iov->iov_base += copy;
+   iov->iov_len -= copy;
+   }
+   iov++;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(memcpy_fromiovec);
+
diff --git a/net/core/iovec.c b/net/core/iovec.c
index 7e7aeb0..d81257f 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -125,31 +125,6 @@ int memcpy_toiovecend(const struct iovec *iov, unsigned 
char *kdata,
 

Re: V3.10-rc1 memory leak

[Rusty Russell]

Catalin Marinas  writes:

> On Wed, May 15, 2013 at 08:33:01PM +0100, Steven Rostedt wrote:
>> On Wed, 2013-05-15 at 15:37 +0100, Catalin Marinas wrote:
>> 
>> > >From 0621c7e1909ea86bf8499a0ffe5ea59d1007ee8c Mon Sep 17 00:00:00 2001
>> > From: Catalin Marinas 
>> > Date: Wed, 15 May 2013 15:30:46 +0100
>> > Subject: [PATCH] kmemleak: Scan the jump label module section
>> > 
>> > Objects allocated in jump_label_add_module() are currently reported as
>> > leaks, though the pointers are stored in the module jump label section.
>> > This patch informs kmemleak that this section needs to be scanned.
>> > 
>> > Signed-off-by: Catalin Marinas 
>> > Reported-by: Steven Rostedt 
>> 
>> This didn't work. I still get the leak messages. But this change did:
>> 
>> Instead of just picking data sections by name (names that start
>> with .data, .bss or .ref.data), use the section flags and scan all
>> sections that are allocated, writable and not executable. Which should
>> cover all sections of a module that might reference data.
>> 
>> Signed-off-by: Steven Rostedt 
>
> That's even better. I tested the two patches as well, added a subject
> and a bit of clean-up and pushed them to this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
> kmemleak
>
> Rusty, are you ok to take these or just ack and I'll push them to Linus.

Thanks.  I've dropped the original "add .ref.data" patch.

For both patches:
Acked-by: Rusty Russell 

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

Re: [PATCH] virtio_pci: fix macro exported in uapi

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> macro VIRTIO_PCI_CONFIG except in the unlikely event userspace
> actually has a structure with a field named msix_enabled.
> Get the msix_enabled by value instead, to make it useful
> for userspace.
>
> Signed-off-by: Michael S. Tsirkin 

Macro still isn't usable, because userspace can't know whether it's the
new or old.

We need to either remove it from UAPI, or rename it to
VIRTIO_PCI_CONFIG_OFF.

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

Re: [PATCH V2 1/3] virtio: console: Add emergency writeonly register to config space

[Rusty Russell]

Amit Shah  writes:
> On (Mon) 06 May 2013 [17:49:49], Pranavkumar Sawargaonkar wrote:
>> This patch adds an emerg_wr register (writeonly) in config space
>> of virtio console device which can be used for debugging.
>> 
>> Signed-off-by: Pranavkumar Sawargaonkar 
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Rusty Russell 
>
> OK, this change by itself looks harmless.
>
> Acked-by: Amit Shah 
>
>   Amit

Thanks.  This is queued for *next* merge window.

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

Re: [PATCH] KVM: allow host header to be included even for !CONFIG_KVM

[Frederic Weisbecker]

On Thu, May 16, 2013 at 12:52:03AM +0200, Frederic Weisbecker wrote:
> On Mon, Mar 25, 2013 at 02:14:20PM -0700, Kevin Hilman wrote:
> > Gleb Natapov  writes:
> > 
> > > On Sun, Mar 24, 2013 at 02:44:26PM +0100, Frederic Weisbecker wrote:
> > >> 2013/3/21 Gleb Natapov :
> > >> > Isn't is simpler for kernel/context_tracking.c to define empty
> > >> > __guest_enter()/__guest_exit() if !CONFIG_KVM.
> > >> 
> > >> That doesn't look right. Off-cases are usually handled from the
> > >> headers, right? So that we avoid iffdeffery ugliness in core code.
> > > Lets put it in linux/context_tracking.h header then.
> > 
> > Here's a version to do that.
> > 
> > Kevin
> > 
> > From d9d909394479dd7ff90b7bddb95a564945406719 Mon Sep 17 00:00:00 2001
> > From: Kevin Hilman 
> > Date: Mon, 25 Mar 2013 14:12:41 -0700
> > Subject: [PATCH v2] ontext_tracking: fix !CONFIG_KVM compile: add stub guest
> >  enter/exit
> 
> Sorry for my very delayed response...
> 
> > 
> > When KVM is not enabled, or not available on a platform, the KVM
> > headers should not be included.  Instead, just define stub
> > __guest_[enter|exit] functions.
> 
> May be it would be cleaner to move guest_enter/exit definitions altogether
> in linux/context_tracking.h
> 
> After all that's where the implementation mostly belong to.
> 
> Let me see if I can get that in shape.

Does the following work for you?

---
commit b1633c075527653a99df6fd54d2611cf8c8047f5
Author: Frederic Weisbecker 
Date:   Thu May 16 01:21:38 2013 +0200

kvm: Move guest entry/exit APIs to context_tracking

Signed-off-by: Frederic Weisbecker 

diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index 365f4a6..fc09d7b 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 struct context_tracking {
@@ -19,6 +20,26 @@ struct context_tracking {
} state;
 };
 
+static inline void __guest_enter(void)
+{
+   /*
+* This is running in ioctl context so we can avoid
+* the call to vtime_account() with its unnecessary idle check.
+*/
+   vtime_account_system(current);
+   current->flags |= PF_VCPU;
+}
+
+static inline void __guest_exit(void)
+{
+   /*
+* This is running in ioctl context so we can avoid
+* the call to vtime_account() with its unnecessary idle check.
+*/
+   vtime_account_system(current);
+   current->flags &= ~PF_VCPU;
+}
+
 #ifdef CONFIG_CONTEXT_TRACKING
 DECLARE_PER_CPU(struct context_tracking, context_tracking);
 
@@ -35,6 +56,9 @@ static inline bool context_tracking_active(void)
 extern void user_enter(void);
 extern void user_exit(void);
 
+extern void guest_enter(void);
+extern void guest_exit(void);
+
 static inline enum ctx_state exception_enter(void)
 {
enum ctx_state prev_ctx;
@@ -57,6 +81,17 @@ extern void context_tracking_task_switch(struct task_struct 
*prev,
 static inline bool context_tracking_in_user(void) { return false; }
 static inline void user_enter(void) { }
 static inline void user_exit(void) { }
+
+static inline void guest_enter(void)
+{
+   __guest_enter();
+}
+
+static inline void guest_exit(void)
+{
+   __guest_exit();
+}
+
 static inline enum ctx_state exception_enter(void) { return 0; }
 static inline void exception_exit(enum ctx_state prev_ctx) { }
 static inline void context_tracking_task_switch(struct task_struct *prev,
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index f0eea07..8db53cf 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -760,42 +761,6 @@ static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
 }
 #endif
 
-static inline void __guest_enter(void)
-{
-   /*
-* This is running in ioctl context so we can avoid
-* the call to vtime_account() with its unnecessary idle check.
-*/
-   vtime_account_system(current);
-   current->flags |= PF_VCPU;
-}
-
-static inline void __guest_exit(void)
-{
-   /*
-* This is running in ioctl context so we can avoid
-* the call to vtime_account() with its unnecessary idle check.
-*/
-   vtime_account_system(current);
-   current->flags &= ~PF_VCPU;
-}
-
-#ifdef CONFIG_CONTEXT_TRACKING
-extern void guest_enter(void);
-extern void guest_exit(void);
-
-#else /* !CONFIG_CONTEXT_TRACKING */
-static inline void guest_enter(void)
-{
-   __guest_enter();
-}
-
-static inline void guest_exit(void)
-{
-   __guest_exit();
-}
-#endif /* !CONFIG_CONTEXT_TRACKING */
-
 static inline void kvm_guest_enter(void)
 {
unsigned long flags;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: lustre: fix return type of lo_release.

[Peng, Tao]

> -Original Message-
> From: Cyril Roelandt [mailto:tipec...@gmail.com]
> Sent: Friday, May 17, 2013 12:06 AM
> To: kernel-janit...@vger.kernel.org; gre...@linuxfoundation.org; 
> andreas.dil...@intel.com; Peng, Tao;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Cc: Cyril Roelandt
> Subject: [PATCH] staging: lustre: fix return type of lo_release.
> 
> The return type of block_device_operations.release() changed to void in commit
> db2a144b.
> 
> Found with the following Coccinelle patch:
> 
> @has_release_func@
> identifier i;
> identifier release_func;
> @@
> struct block_device_operations i = {
>  .release = release_func
> };
> 
> @depends on has_release_func@
> identifier has_release_func.release_func;
> @@
> - int
> + void
> release_func(...) {
> ...
> - return ...;
> }
> 
> 
Yeah, thanks for the patch. I have one same patch but am still working on 
procfs change so didn't send it out. I'd be glad to take yours instead.

Greg, will you take it directly or do you want Andreas and me to queue it 
first? The patch is absolutely right btw.

Thanks,
Tao

> Signed-off-by: Cyril Roelandt 
> ---
>  drivers/staging/lustre/lustre/llite/lloop.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
> b/drivers/staging/lustre/lustre/llite/lloop.c
> index b72f257..9d4c17e 100644
> --- a/drivers/staging/lustre/lustre/llite/lloop.c
> +++ b/drivers/staging/lustre/lustre/llite/lloop.c
> @@ -596,15 +596,13 @@ static int lo_open(struct block_device *bdev, fmode_t 
> mode)
>   return 0;
>  }
> 
> -static int lo_release(struct gendisk *disk, fmode_t mode)
> +static void lo_release(struct gendisk *disk, fmode_t mode)
>  {
>   struct lloop_device *lo = disk->private_data;
> 
>   mutex_lock(>lo_ctl_mutex);
>   --lo->lo_refcnt;
>   mutex_unlock(>lo_ctl_mutex);
> -
> - return 0;
>  }
> 
>  /* lloop device node's ioctl function. */
> --
> 1.7.10.4
> 

Linux source tree size difference issue

[Chris Jones]

I have cloned the Linux kernel source tree locally. It comes in at
approx. ~500MB. I have then created another git repository to push the
source to for my own work. I rsynced the tree locally to another
directory and now I am currently pushing it in to the new repository and
it's at 58% and is already at 525MB.

I can not understand the stark difference in source and directory size.
Running diff tells me both local source tree directories are exactly the
same.

Can anyone explain this in layman's terms?


-- 

Chris Jones

Founder and Lead Software Architect
Paradise Software
chrisjo...@spin.net.au

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

[WiP]: aio support for migrating pages (Re: [PATCH V2 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable())

[Benjamin LaHaise]

On Thu, May 16, 2013 at 01:54:18PM +0800, Tang Chen wrote:
...
> OK, I'll try to figure out a proper place to put the callbacks.
> But I think we need to add something new to struct page. I'm just
> not sure if it is OK. Maybe we can discuss more about it when I send
> a RFC patch.
...

I ended up working on this a bit today, and managed to cobble together 
something that somewhat works -- please see the patch below.  It still is 
not completely tested, and it has a rather nasty bug owing to the fact 
that the file descriptors returned by anon_inode_getfile() all share the 
same inode (read: more than one instance of aio does not work), but it 
shows the basic idea.  Also, bad things probably happen if someone does 
an mremap() on the aio ring buffer.  I'll polish this off sometime next 
week after the long weekend if noone beats me to it.

-ben
-- 
"Thought is the essence of where you are now."

 fs/aio.c|   95 ++--
 include/linux/migrate.h |3 +
 mm/migrate.c|2 -
 3 files changed, 96 insertions(+), 4 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index c5b1a8c..dbad23e 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -35,6 +35,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -108,6 +111,7 @@ struct kioctx {
} cacheline_aligned_in_smp;
 
struct page *internal_pages[AIO_RING_PAGES];
+   struct file *ctx_file;
 };
 
 /*-- sysctl variables*/
@@ -146,8 +150,59 @@ static void aio_free_ring(struct kioctx *ctx)
 
if (ctx->ring_pages && ctx->ring_pages != ctx->internal_pages)
kfree(ctx->ring_pages);
+
+   if (ctx->ctx_file) {
+   truncate_setsize(ctx->ctx_file->f_inode, 0);
+   fput(ctx->ctx_file);
+   ctx->ctx_file = NULL;
+   }
+}
+
+static int aio_ctx_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   vma->vm_ops = _file_vm_ops;
+   return 0;
+}
+
+static const struct file_operations aio_ctx_fops = {
+   .mmap   = aio_ctx_mmap,
+};
+
+static int aio_set_page_dirty(struct page *page)
+{
+   return 0;
+}
+
+static int aio_migratepage(struct address_space *mapping, struct page *new,
+  struct page *old, enum migrate_mode mode)
+{
+   struct kioctx *ctx = mapping->private_data;
+   unsigned long flags;
+   unsigned idx = old->index;
+   int rc;
+
+   BUG_ON(PageWriteback(old));/* Writeback must be complete */
+   put_page(old);
+   rc = migrate_page_move_mapping(mapping, new, old, NULL, mode);
+   if (rc != MIGRATEPAGE_SUCCESS) {
+   get_page(old);
+   return rc;
+   }
+   get_page(new);
+
+   spin_lock_irqsave(>completion_lock, flags);
+   migrate_page_copy(new, old);
+   ctx->ring_pages[idx] = new;
+   spin_unlock_irqrestore(>completion_lock, flags);
+
+   return MIGRATEPAGE_SUCCESS;
 }
 
+static const struct address_space_operations aio_ctx_aops = {
+   .set_page_dirty = aio_set_page_dirty,
+   .migratepage= aio_migratepage,
+};
+
 static int aio_setup_ring(struct kioctx *ctx)
 {
struct aio_ring *ring;
@@ -155,6 +210,7 @@ static int aio_setup_ring(struct kioctx *ctx)
struct mm_struct *mm = current->mm;
unsigned long size, populate;
int nr_pages;
+   int i;
 
/* Compensate for the ring buffer's head/tail overlap entry */
nr_events += 2; /* 1 is required, 2 for good luck */
@@ -166,6 +222,31 @@ static int aio_setup_ring(struct kioctx *ctx)
if (nr_pages < 0)
return -EINVAL;
 
+   ctx->ctx_file = anon_inode_getfile("[aio]", _ctx_fops, ctx, O_RDWR);
+   if (IS_ERR(ctx->ctx_file)) {
+   ctx->ctx_file = NULL;
+   return -EAGAIN;
+   }
+   ctx->ctx_file->f_inode->i_mapping->a_ops = _ctx_aops;
+   ctx->ctx_file->f_inode->i_mapping->private_data = ctx;
+   ctx->ctx_file->f_inode->i_size = PAGE_SIZE * (loff_t)nr_pages;
+
+   for (i=0; ictx_file->f_inode->i_mapping,
+  i, GFP_KERNEL);
+   if (!page) {
+   break;
+   }
+   ptr = kmap(page);
+   clear_page(ptr);
+   kunmap(page);
+   SetPageUptodate(page);
+   SetPageDirty(page);
+   unlock_page(page);
+   }
+
nr_events = (PAGE_SIZE * nr_pages - sizeof(struct aio_ring)) / 
sizeof(struct io_event);
 
ctx->nr_events = 0;
@@ -180,20 +261,25 @@ static int aio_setup_ring(struct kioctx *ctx)
ctx->mmap_size = nr_pages * PAGE_SIZE;
pr_debug("attempting mmap of %lu bytes\n", ctx->mmap_size);
down_write(>mmap_sem);
-   ctx->mmap_base = do_mmap_pgoff(NULL, 0, ctx->mmap_size,
+   ctx->mmap_base = do_mmap_pgoff(ctx->ctx_file, 0, ctx->mmap_size,
   

Re: [PATCH v6 2/8] vmcore: allocate buffer for ELF headers on page-size alignment

[HATAYAMA Daisuke]

(2013/05/17 1:51), Vivek Goyal wrote:

On Wed, May 15, 2013 at 06:05:51PM +0900, HATAYAMA Daisuke wrote:

[..]

@@ -398,9 +403,7 @@ static int __init process_ptload_program_headers_elf64(char 
*elfptr,
phdr_ptr = (Elf64_Phdr*)(elfptr + sizeof(Elf64_Ehdr)); /* PT_NOTE hdr */

/* First program header is PT_NOTE header. */
-   vmcore_off = sizeof(Elf64_Ehdr) +
-   (ehdr_ptr->e_phnum) * sizeof(Elf64_Phdr) +
-   phdr_ptr->p_memsz; /* Note sections */
+   vmcore_off = elfsz + roundup(phdr_ptr->p_memsz, PAGE_SIZE);

for (i = 0; i < ehdr_ptr->e_phnum; i++, phdr_ptr++) {
if (phdr_ptr->p_type != PT_LOAD)
@@ -435,9 +438,7 @@ static int __init process_ptload_program_headers_elf32(char 
*elfptr,
phdr_ptr = (Elf32_Phdr*)(elfptr + sizeof(Elf32_Ehdr)); /* PT_NOTE hdr */

/* First program header is PT_NOTE header. */
-   vmcore_off = sizeof(Elf32_Ehdr) +
-   (ehdr_ptr->e_phnum) * sizeof(Elf32_Phdr) +
-   phdr_ptr->p_memsz; /* Note sections */
+   vmcore_off = elfsz + roundup(phdr_ptr->p_memsz, PAGE_SIZE);


Hmm.., so we are rounding up ELF note data size too here. I think this belongs
in some other patch as in this patch we are just rounding up the elf
headers.

This might create read problems too as we have not taking care of this
rounding when adding note to vc_list and it might happen that we are
reading wrong data at a particular offset.

So may be this rounding up we should do in later patches when we take
care of copying ELF notes data to second kernel.

Vivek



This is my careless fault. They should have been in 6/7.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/8] kdump, vmcore: support mmap() on /proc/vmcore

[H. Peter Anvin]

On 05/15/2013 02:05 AM, HATAYAMA Daisuke wrote:
> Currently, read to /proc/vmcore is done by read_oldmem() that uses
> ioremap/iounmap per a single page. For example, if memory is 1GB,
> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
> times. This causes big performance degradation.

read_oldmem() is fundamentally broken and unsafe.  It needs to be
unified with the plain /dev/mem code and any missing functionality fixed
instead of "let's just do a whole new driver".

-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 1/2] pinctrl: samsung: fix suspend/resume functionality

[Doug Anderson]

Tomasz,

On Thu, May 16, 2013 at 4:10 PM, Doug Anderson  wrote:
> If state of these registers isn't lost on those SoCs then running the
> save/restore shouldn't _hurt_ though, right?  If you can run the old
> GPIO code on one of those systems and do a suspend/resume you could
> check...

I think it's been too long of a day for me, too.

I just thought about this and realized that there is no "powerdown"
registers for the GPX banks on exynos5250.  ...and they don't lose
their state at sleep!  ...so maybe a reasonable thing to do would be
to skip save/restore in any case where there are no powerdown
registers?

You can see a printout in my case:

[  412.84] gpx0 @ f004ac00 (con 0x3110 => 0x3110)
[  412.84] gpx1 @ f004ac20 (con 0x1f10ff10 => 0x1f10ff10)
[  412.84] gpx2 @ f004ac40 (con 0x1f000f0f => 0x1f000f0f)
[  412.84] gpx3 @ f004ac60 (con 0x00f00f01 => 0x00f00f01)

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

Re: [PATCH 2/2] pinctrl: exynos: fix eint wakeup by using irq_set_wake()

[Doug Anderson]

Tomasz,

On Thu, May 16, 2013 at 3:37 PM, Tomasz Figa  wrote:
> Well, to make long story short, including headers from plat/ and mach/
> from files outside plat/ or mach/ is no longer valid with
> CONFIG_MULTIPLATFORM, because more than one plat and/or mach can be
> enabled at the same time. In addition to this, care must be taken for code
> to not break platforms other than written for, when compiled into the
> resulting kernel.

Right.  That makes sense.  That's also why it would be a bit of a
longshot for me to get this done right now.  I'd imagine that there
would be a number of changes to the samsung pm infrastructure that are
needed to make this work and I don't have all of those in my tree
right now.  We've already picked back a lot to 3.8, but multiplatform
seems too much.


>> Perhaps for this patch it makes more sense for you to post your
>> version and I can review it?  We may end up just keeping our version
>> of this patch for 3.8 and pick up yours when we do our next rebase.
>> Does that sound OK?
>
> Fine. I will also send a patch adding save and restore for several EINT
> registers that need it.

OK, sounds good.  I was trying to figure out why we didn't seem to
have those in our 3.4 stuff and that it seems to work without
saving/restoring.  I assumed that maybe higher level code was
masking/unmasking interrupts but didn't dig.


> Since EINT handling is highly SoC-specific (i.e. done in pinctrl-exynos,
> not pinctrl-samsung), such assumption wouldn't be a problem. Let me see
> how I solved this problem in my version tomorrow at work.

Fair enough.  :)  Looking forward to seeing your patch!

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 6/8] vmcore: allocate ELF note segment in the 2nd kernel vmalloc memory

[HATAYAMA Daisuke]

(2013/05/17 5:32), Vivek Goyal wrote:

On Wed, May 15, 2013 at 06:06:14PM +0900, HATAYAMA Daisuke wrote:

[..]


+static int __init get_note_number_and_size_elf32(const Elf32_Ehdr *ehdr_ptr,
+int *nr_ptnote, u64 *phdr_sz)
+{
+   return process_note_headers_elf32(ehdr_ptr, nr_ptnote, phdr_sz, NULL);
+}
+
+static int __init copy_notes_elf32(const Elf32_Ehdr *ehdr_ptr, char *notes_buf)
+{
+   return process_note_headers_elf32(ehdr_ptr, NULL, NULL, notes_buf);
+}
+


Please don't do this. We need to create two separate functions doing
two different operations and not just create wrapper around a function
which does two things.

I know both functions will have similar for loops for going through
the elf notes but it is better then doing function overloading based
on parameters passed.



I see. This part must be fixed in the next version.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 4/8] vmalloc: make find_vm_area check in range

[HATAYAMA Daisuke]

(2013/05/16 6:37), KOSAKI Motohiro wrote:

On Wed, May 15, 2013 at 5:06 AM, HATAYAMA Daisuke
 wrote:

Currently, __find_vmap_area searches for the kernel VM area starting
at a given address. This patch changes this behavior so that it
searches for the kernel VM area to which the address belongs. This
change is needed by remap_vmalloc_range_partial to be introduced in
later patch that receives any position of kernel VM area as target
address.

This patch changes the condition (addr > va->va_start) to the
equivalent (addr >= va->va_end) by taking advantage of the fact that
each kernel VM area is non-overlapping.

Signed-off-by: HATAYAMA Daisuke 
---

  mm/vmalloc.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d365724..3875fa2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -292,7 +292,7 @@ static struct vmap_area *__find_vmap_area(unsigned long 
addr)
 va = rb_entry(n, struct vmap_area, rb_node);
 if (addr < va->va_start)
 n = n->rb_left;
-   else if (addr > va->va_start)
+   else if (addr >= va->va_end)
 n = n->rb_right;


OK. This is natural definition. Looks good.

Acked-by: KOSAKI Motohiro 


Thanks for your reviewing. Could you or other someone review the next 
5/8 patch too? It also changes vmalloc and cc people's review is needed.


--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Power management and ACPI fixes for v3.10-rc2

[Dirk Brandewie]

On 05/16/2013 03:25 PM, Linus Torvalds wrote:

On Thu, May 16, 2013 at 1:07 PM, Rafael J. Wysocki  wrote:


- intel_pstate driver fixes and cleanups from Dirk Brandewie and
   Wei Yongjun.


Btw, is there some fundamental reason why the pstate driver is limited
to so few models?

I've tested it on models 0x25 (i5-670) and 0x3a (i5-3427U), and it
seems to work. But neither model is listed. (only 0x2a and 0x2d are).

I understand that people want to be careful, but it's not actually
getting very much *testing* right now, is it? Are models 0x2a/0x2d
actually special in any way?



No they are not I will send the patch out in the morning.


   Linus



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

Re: [PATCH RESEND] media: davinci: vpbe: fix checkpatch warning for CamelCase

[Sakari Ailus]

On Fri, May 03, 2013 at 05:09:25PM +0530, Prabhakar Lad wrote:
> From: Lad, Prabhakar 
> 
> This patch fixes checkpatch warning to avoid CamelCase.
> 
> Signed-off-by: Lad, Prabhakar 

Thanks!

Reviewed-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: samsung: fix suspend/resume functionality

[Doug Anderson]

The GPIO states need to be restored after s2r and this is not currently
supported in the pinctrl driver. This patch saves the gpio states before
suspend and restores them after resume.

Saving and restoring is done very early using syscore_ops and must
happen before pins are released from their powerdown state.

Patch originally from Prathyush K  but
rewritten by Doug Anderson .

Signed-off-by: Prathyush K 
Signed-off-by: Doug Anderson 
---
Changes in v2:
- Now uses sycore_ops to make sure we're early enough.
- Try to handle two CON registers better.
- Should handle s3c24xx better as per Heiko.
- Simpler code; no longer tries to avoid glitching lines since
  we _think_ all current SoCs should have pins in power down state
  when the restore is called.
- Dropped eint patch for now; Tomasz will post his version.

 drivers/pinctrl/pinctrl-samsung.c | 140 ++
 drivers/pinctrl/pinctrl-samsung.h |   5 ++
 2 files changed, 145 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-samsung.c 
b/drivers/pinctrl/pinctrl-samsung.c
index 9763668..851eada 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 #include "pinctrl-samsung.h"
@@ -48,6 +49,9 @@ static struct pin_config {
{ "samsung,pin-pud-pdn", PINCFG_TYPE_PUD_PDN },
 };
 
+/* Global list of devices (struct samsung_pinctrl_drv_data) */
+LIST_HEAD(drvdata_list);
+
 static unsigned int pin_base;
 
 static inline struct samsung_pin_bank *gc_to_pin_bank(struct gpio_chip *gc)
@@ -961,9 +965,137 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
ctrl->eint_wkup_init(drvdata);
 
platform_set_drvdata(pdev, drvdata);
+
+   /* Add to the global list */
+   list_add_tail(>node, _list);
+
return 0;
 }
 
+#ifdef CONFIG_PM
+
+/**
+ * samsung_pinctrl_suspend_dev - save pinctrl state for suspend for a device
+ *
+ * Save data for all banks handled by this device.
+ */
+static void samsung_pinctrl_suspend_dev(
+   struct samsung_pinctrl_drv_data *drvdata)
+{
+   struct samsung_pin_ctrl *ctrl = drvdata->ctrl;
+   void __iomem *virt_base = drvdata->virt_base;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; i++) {
+   struct samsung_pin_bank *bank = >pin_banks[i];
+   void __iomem *reg = virt_base + bank->pctl_offset;
+
+   u8 *offs = bank->type->reg_offset;
+   u8 *widths = bank->type->fld_width;
+   enum pincfg_type type;
+
+   for (type = 0; type < PINCFG_TYPE_NUM; type++)
+   if (widths[type])
+   bank->pm_save[type] = readl(reg + offs[type]);
+
+   if (widths[PINCFG_TYPE_FUNC] * bank->nr_pins > 32) {
+   /* Some banks have two config registers */
+   bank->pm_save[PINCFG_TYPE_NUM] =
+   readl(reg + offs[PINCFG_TYPE_FUNC] + 4);
+   pr_debug("Save %s @ %p (con %#010x %08x)\n",
+bank->name, reg,
+bank->pm_save[PINCFG_TYPE_FUNC],
+bank->pm_save[PINCFG_TYPE_NUM]);
+   } else {
+   pr_debug("Save %s @ %p (con %#010x)\n", bank->name,
+reg, bank->pm_save[PINCFG_TYPE_FUNC]);
+   }
+   }
+}
+
+/**
+ * samsung_pinctrl_resume_dev - restore pinctrl state from suspend for a device
+ *
+ * Restore one of the banks that was saved during suspend.
+ *
+ * We don't bother doing anything complicated to avoid glitching lines since
+ * we're called before pad retention is turned off.
+ */
+static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data 
*drvdata)
+{
+   struct samsung_pin_ctrl *ctrl = drvdata->ctrl;
+   void __iomem *virt_base = drvdata->virt_base;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; i++) {
+   struct samsung_pin_bank *bank = >pin_banks[i];
+   void __iomem *reg = virt_base + bank->pctl_offset;
+
+   u8 *offs = bank->type->reg_offset;
+   u8 *widths = bank->type->fld_width;
+   enum pincfg_type type;
+
+   if (widths[PINCFG_TYPE_FUNC] * bank->nr_pins > 32) {
+   /* Some banks have two config registers */
+   pr_debug("%s @ %p (con %#010x %08x => %#010x %08x)\n",
+bank->name, reg,
+readl(reg + offs[PINCFG_TYPE_FUNC]),
+readl(reg + offs[PINCFG_TYPE_FUNC] + 4),
+bank->pm_save[PINCFG_TYPE_FUNC],
+bank->pm_save[PINCFG_TYPE_NUM]);
+   writel(bank->pm_save[PINCFG_TYPE_NUM],
+  reg + offs[PINCFG_TYPE_FUNC] + 4);
+ 

Re: [PATCH 1/2] nohz: Disable LOCKUP_DETECTOR when NO_HZ_FULL is enabled

[Frederic Weisbecker]

On Thu, May 16, 2013 at 02:32:58PM -0400, Steven Rostedt wrote:
> On Thu, 2013-05-16 at 19:56 +0200, Peter Zijlstra wrote:
> 
> > I suppose the fundamental question was: will receiving NMIs negate 
> > NO_HZ_FULL's
> > functionality? That is, will the getting of NMIs make us drop out of 
> > NO_HZ_FULL
> > and re-enable all sorts of things?
> 
> It shouldn't. The nmi_enter() notifies RCU that it can no longer ignore
> this CPU, where as nmi_enter() tells it that it can ignore it, as it has
> re-entered user space.
> 
> > 
> > Because clearly RCU needs to exit from EQS, which might (or might not) mean
> > leaving NO_HZ_FULL.
> 
> Yep, but the two are pretty much agnostic from each other.
> 
> We only need to leave NO_HZ_FULL if RCU (or anything for that matter)
> required having a tick again. But as Paul said, getting an NMI in idle
> wont restart the tick, so there's no need to restart it here either.
> 
> Now if an NMI were to do a call_rcu() then it would require a tick. But
> NMIs doing call_rcu() has much bigger issues to worry about ;-)

Actually even calling call_rcu() won't restart the tick because the callback
and the grace period lifecycle that come along are handled by the RCU nocb
kthreads. If you have migrated these kthreads accordingly this is handled in the
housekeeping CPU. Of course calling call_rcu() from an NMI involve more 
problems ;)

In fact we never need to restart the tick for RCU. Even round-trips in the 
kernel
that are potentially longer than irqs/nmis, such as IO syscalls/exception  are
fine because they are either actually short and quickly return to user mode, or 
they
sleep and go idle so the result is the same: RCU idle mode.

There is just a possible exception that is not yet completely handled: if
a task stays in the kernel too long without sleeping, it may extend a
grace period dangerously (there is no tick to report quiescent states).
In this case we should restart the tick. This is only half implemented
currently: RCU sends IPIs to CPUs that do these excessive grace periods
extensions. Just the CPU that receives that IPI doesn't yet detect the issue
and doesn't restart the tick. That's in the TODO list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch v3 -mm 3/3] vmscan, memcg: Do softlimit reclaim also for targeted reclaim

[Tejun Heo]

On Mon, May 13, 2013 at 09:46:12AM +0200, Michal Hocko wrote:
> Soft reclaim has been done only for the global reclaim (both background
> and direct). Since "memcg: integrate soft reclaim tighter with zone
> shrinking code" there is no reason for this limitation anymore as the
> soft limit reclaim doesn't use any special code paths and it is a
> part of the zone shrinking code which is used by both global and
> targeted reclaims.
...
> Signed-off-by: Michal Hocko 

 Reviewed-by: Tejun Heo 

Some nitpicks follow.

>  /*
> - * A group is eligible for the soft limit reclaim if it is
> - *   a) is over its soft limit
> + * A group is eligible for the soft limit reclaim under the given root
> + * hierarchy if
> + *   a) it is over its soft limit
>   *   b) any parent up the hierarchy is over its soft limit

This was added before but in general I think the use of parent for
ancestor is a bit confusing.  Not a big deal but no reason to continue
it.

>   /*
> -  * If any parent up the hierarchy is over its soft limit then we
> -  * have to obey and reclaim from this group as well.
> +  * If any parent up to the root in the hierarchy is over its soft limit
> +  * then we have to obey and reclaim from this group as well.

Prolly using terms ancestors and subtree would make the explanation
clearer?

>  static bool mem_cgroup_should_soft_reclaim(struct scan_control *sc)
>  {
> - return global_reclaim(sc);
> + return true;

Kinda silly after this change, maybe just modify shrink_zone() like
the following?

if (IS_ENABLED(CONFIG_MEMCG)) {
__shrink_zone(zone, sc, true);
if (sc->nr_scanned == nr_scanned)
__shrink_zone(zone, sc, false);
} else {
__shrink_zone(zone, sc, false);
}

> @@ -1974,7 +1974,7 @@ __shrink_zone(struct zone *zone, struct scan_control 
> *sc, bool soft_reclaim)
>   struct lruvec *lruvec;
>  
>   if (soft_reclaim &&
> - 
> !mem_cgroup_soft_reclaim_eligible(memcg)) {
> + 
> !mem_cgroup_soft_reclaim_eligible(memcg, root)) {

Weird indentation which breaks line and goes over 80 col, why not do
the following?

if (soft_reclaim &&
!mem_cgroup_soft_reclaim_eligible(memcg, root)) {
memcg = mem_cgroup_iter(root, memcg, );
continue;
}

Thanks.

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

Re: [PATCH 1/2] pinctrl: samsung: fix suspend/resume functionality

[Doug Anderson]

Tomasz,

On Thu, May 16, 2013 at 3:56 PM, Tomasz Figa  wrote:
> Seems like I need some sleep, as I'm already starting to overlook large
> blobs of code.
>
> Originally, GPIO suspend/resume handlers have been configured in
> drivers/gpio/gpio-samsung.c, by setting pm field of samsung_gpio_chip
> struct to point to appropriate samsung_gpio_pm struct, which contains
> pointers to save and resume callbacks.
>
> In result, samsung_gpio_pm_2bit_* or samsung_gpio_pm_4bit_* have been
> used, depending on bank type, on all SoCs.
>
> Now since the documentation states that wake-up reset doesn't reset GPIO
> registers (at least on S3C2440 and S3C2416), I wonder what is the correct
> way of handling them.

If state of these registers isn't lost on those SoCs then running the
save/restore shouldn't _hurt_ though, right?  If you can run the old
GPIO code on one of those systems and do a suspend/resume you could
check...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] ARM: tegra: update device trees for USB binding rework

[Stephen Warren]

On 05/16/2013 08:12 AM, Venu Byravarasu wrote:
> This patch updates all Tegra board files so that they contain all the
> properties required by the updated USB DT binding. Note that this patch
> only adds the new properties and does not yet remove the old properties,
> in order to maintain bisectability. The old properties will be removed
> once the driver has been updated to assume the new bindings.

This series looks almost OK now. The one remaining issue is that in this
patch, the regulator-name properties don't match the schematics, and in
the Whistler patch below, both regulators you added have the same
regulator-name, which causes problems.

To fix this, when I apply this patch, I'm going to fold in the patch
I'll paste below.

Right now, I can't get Whistler to see the SD card. This is true even
without your patches. Once I've resolved that and tested Whistler,
assuming no more problems, I'll apply patches 1-3 to the Tegra tree, and
set up a branch that can be pulled into the USB tree so the rest of the
series can be applied there.

diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index b832088..009dafe 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -822,7 +822,7 @@
vbus_reg: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
-   regulator-name = "vdd_5v0";
+   regulator-name = "vdd_vbus_wup1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 24 0>; /* PD0 */
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts
b/arch/arm/boot/dts/tegra20-trimslice.dts
index d9b58cd..0e65c00e 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -404,7 +404,7 @@
vbus_reg: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
-   regulator-name = "vdd_5v0";
+   regulator-name = "usb1_vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 170 0>; /* PV2 */
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts
b/arch/arm/boot/dts/tegra20-whistler.dts
index e405c2f..3c24c9b 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -513,7 +513,7 @@

usb-phy@c500 {
status = "okay";
-   vbus-supply = <_reg1>;
+   vbus-supply = <_reg>;
};

usb@c5008000 {
@@ -523,7 +523,7 @@

usb-phy@c5008000 {
status = "okay";
-   vbus-supply = <_reg2>;
+   vbus-supply = <_reg>;
};

sdhci@c8000400 {
@@ -579,19 +579,19 @@
regulator-always-on;
};

-   vbus_reg1: regulator@2 {
+   vbus1_reg: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
-   regulator-name = "vdd_5v0";
+   regulator-name = "vbus1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 0 0>; /* GPIO_PMU0 */
};

-   vbus_reg2: regulator@3 {
+   vbus3_reg: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
-   regulator-name = "vdd_5v0";
+   regulator-name = "vbus3";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 1 0>; /* GPIO_PMU1 */
-- 
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 2/2] mfd: twl-core: convert to module_i2c_driver()

[Tony Lindgren]

* Samuel Ortiz  [130516 15:22]:
> Hi Grygorii,
> 
> On Tue, Apr 23, 2013 at 04:19:10PM +0300, Grygorii Strashko wrote:
> > Shift TWL initialization to module/device init layer, because I2C now is
> > not initialized on subsys init layer and shifted to module/device init
> > layer instead.
> > 
> > The I2C <--> TWL dependency should be resolved in drivers/Makefile now.
> >
> > Cc: Santosh Shilimkar 
> > Cc: linux-o...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > 
> > Signed-off-by: Grygorii Strashko 
> > ---
> >  drivers/mfd/twl-core.c |   12 +---
> >  1 file changed, 1 insertion(+), 11 deletions(-)
> I applied this one to mfd-next for now, and will move it to mfd-fixes if
> someone confirms that this is indeed a fix.

Thanks, AFAIK it can wait until v3.11 merge window.

Regards,

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