Re: [PATCH] KVM: mmu: allow page tables to be in read-only slots

[Paolo Bonzini]

Il 02/09/2013 12:07, Gleb Natapov ha scritto:
> On Mon, Sep 02, 2013 at 06:00:39PM +0800, Xiao Guangrong wrote:
>> On 09/02/2013 05:25 PM, Gleb Natapov wrote:
>>> On Mon, Sep 02, 2013 at 05:20:15PM +0800, Xiao Guangrong wrote:
 On 08/30/2013 08:41 PM, Paolo Bonzini wrote:
> Page tables in a read-only memory slot will currently cause a triple
> fault because the page walker uses gfn_to_hva and it fails on such a slot.
>
> OVMF uses such a page table; however, real hardware seems to be fine with
> that as long as the accessed/dirty bits are set.  Save whether the slot
> is readonly, and later check it when updating the accessed and dirty bits.

 Paolo, do you know why OVMF is using readonly memory like this?

>>> Just a guess, but perhaps they want to move to paging mode as early as
>>> possible even before memory controller is fully initialized.
>>>
 AFAIK, The fault trigged by this kind of access can hardly be fixed by
 userspace since the fault is trigged by pagetable walking not by the 
 current
 instruction. Do you have any idea to let uerspace emulate it properly?
>>> Not sure what userspace you mean here, but there shouldn't be a fault in the
>>
>> I just wonder how to fix this kind of fault. The current patch returns 
>> -EACCES
>> but that will crash the guest. I think we'd better let userspace to fix this
>> error (let userspace set the D/A bit.)
>>
> Ugh, this is not good. Missed that. Don't know what real HW will do
> here, but the easy thing for us to do would be to just return success.

Real hardware would just do a memory write.  What happens depends on
what is on the bus, i.e. on what the ROM is used for.

QEMU uses read-only slots for two things: actual read-only memory where
writes go to the bitbucket, and "ROMD" memory where writes are treated
as MMIO.

So, in the first case we would ignore the write.  In the second we would
do an MMIO exit to userspace.  But ignoring the write isn't always
correct, and doing an MMIO exit is complicated, so I would just kill the
guest.

EPT will probably write to the read-only slots without thinking much
about it.

My patch injects a page fault, which is very likely to escalate to a
triple fault.  This is probably never what you want---on the other hand,
I wasn't sure what level of accuracy we want in this case, given that
EPT does it wrong too.

Paolo

>>> first place if ROM page tables have access/dirty bit set and they do.
>>
>> Yes, so we can not call x86_emulate_instruction() to fix this fault (that 
>> function
>> emulates the access on the first place). Need directly return a MMIO-exit to
>> userpsace when met this fault? What happen if this fault on pagetable-walking
>> is trigged in x86_emulate_instruction().?
> I think we should not return MMIO-exit to userspace. Either ignore write 
> attempt
> or kill a guest.
> 
> --
>   Gleb.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of_irq.h: fix build warnings when CONFIG_OF is not enabled

[Randy Dunlap]

From: Randy Dunlap 

Fix build warnings when CONFIG_OF is not enabled:

include/linux/of_irq.h:82:7: warning: 'struct device_node' declared inside 
parameter list [enabled by default]
include/linux/of_irq.h:82:7: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
include/linux/of_irq.h:87:47: warning: 'struct device_node' declared inside 
parameter list [enabled by default]

Signed-off-by: Randy Dunlap 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
---
 include/linux/of_irq.h |2 ++
 1 file changed, 2 insertions(+)

--- linux-next-20130830.orig/include/linux/of_irq.h
+++ linux-next-20130830/include/linux/of_irq.h
@@ -78,6 +78,8 @@ extern void of_irq_init(const struct of_
 #endif /* CONFIG_OF_IRQ */
 
 #else /* !CONFIG_OF */
+struct device_node;
+
 static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
int index)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.9: kmemleak disables all CPUs except CPU0

[Martin MOKREJŠ]

Catalin Marinas wrote:
> On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote:
>> On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas  
>> wrote:
>>> On 31 August 2013 14:35, Martin MOKREJŠ  wrote:
   never realized that my CPUs are gone if I compile into kernel kmemleak.
 Is that really the aim?

 CONFIG_HAVE_DEBUG_KMEMLEAK=y
 CONFIG_DEBUG_KMEMLEAK=y
 CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
 # CONFIG_DEBUG_KMEMLEAK_TEST is not set
 # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set

 1.  Why isn't there /sys/devices/system/cpu/cpu0/online file?
 Does not matter if it contains 0 or 1. It just should exist.
>>>
>>> I can't really see how kmemleak would do this, maybe other config
>>> options that get set/cleared in the process of selecting kmemleak. Can
>>
>> Seems to be kmemcheck: from arch/x86/mm/kmemcheck/kmemcheck.c:
>>
>> int __init kmemcheck_init(void)
>> {
>> #ifdef CONFIG_SMP
>> /*
>>  * Limit SMP to use a single CPU. We rely on the fact that this code
>>  * runs before SMP is set up.
>>  */
>> if (setup_max_cpus > 1) {
>> printk(KERN_INFO
>> "kmemcheck: Limiting number of CPUs to 1.\n");
>> setup_max_cpus = 1;
>> }
>> #endif
> 
> Ah, ok, not my problem then ;)


Fine, so would somebody please update the help text accessible in "menuconfig"
for this entry? It should be clear that it has a huge performance impact if 
enabled.
And, by compiling in it is enabled by default.

Thank you
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC 00/16] EFI stub for ARM

[Roy Franz]

On Mon, Sep 2, 2013 at 3:33 AM, Matt Fleming  wrote:
> On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote:
>> Hi Matt,
>>
>>Do you have any more feedback on the X86 and common code (patches
>> 1-13) that needs to be addressed?  Mark Salter has a working ARM64 EFI
>> stub implemented based on these patches, so the common code has now
>> been tested with another architecture, and he has acked these patches.
>> If the current patches are OK, can this be queued for 3.12? (and into
>> linux-next, if appropriate)
>> The ARM portion may take a little longer based on the EFI runtime
>> services patch dependencies, but getting the common code merged would
>> allow the ARM64 EFI stub work to go forward independently.
>>
>> I can resend patches 1-13 as a new series of x86/common only changes
>> if you would like.
>
> I think resending the common patches as a new series, including Acked-by
> and Reviewed-by tags, and after addressing Grant's comments is the best
> idea.
>
> We've missed the v3.12 merge window now, but we can certainly get these
> into linux-next for some testing.
>
> --
> Matt Fleming, Intel Open Source Technology Center

Thanks Matt - I'll split the common patches out to a new series and resubmit
after taking care of Grant's feeback.

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

Re: 3.10.9: kmemleak disables all CPUs except CPU0

[Catalin Marinas]

On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote:
> On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas  
> wrote:
> > On 31 August 2013 14:35, Martin MOKREJŠ  wrote:
> >>   never realized that my CPUs are gone if I compile into kernel kmemleak.
> >> Is that really the aim?
> >>
> >> CONFIG_HAVE_DEBUG_KMEMLEAK=y
> >> CONFIG_DEBUG_KMEMLEAK=y
> >> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
> >> # CONFIG_DEBUG_KMEMLEAK_TEST is not set
> >> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
> >>
> >> 1.  Why isn't there /sys/devices/system/cpu/cpu0/online file?
> >> Does not matter if it contains 0 or 1. It just should exist.
> >
> > I can't really see how kmemleak would do this, maybe other config
> > options that get set/cleared in the process of selecting kmemleak. Can
> 
> Seems to be kmemcheck: from arch/x86/mm/kmemcheck/kmemcheck.c:
> 
> int __init kmemcheck_init(void)
> {
> #ifdef CONFIG_SMP
> /*
>  * Limit SMP to use a single CPU. We rely on the fact that this code
>  * runs before SMP is set up.
>  */
> if (setup_max_cpus > 1) {
> printk(KERN_INFO
> "kmemcheck: Limiting number of CPUs to 1.\n");
> setup_max_cpus = 1;
> }
> #endif

Ah, ok, not my problem then ;)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] usb: dwc3: get "usb_phy" only if the platform indicates the presence of PHY

[Kishon Vijay Abraham I]

There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/dwc3/Kconfig |1 +
 drivers/usb/dwc3/core.c  |   60 +-
 drivers/usb/dwc3/platform_data.h |1 +
 3 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate "DesignWare USB3 DRD Core Support"
depends on (USB || USB_GADGET) && GENERIC_HARDIRQS && HAS_DMA
depends on EXTCON
+   select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
help
  Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
 
-   dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
-   dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1);
+   if (of_property_read_bool(node, "usb-phy")) {
+   dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev,
+   "usb-phy", 0);
+   if (IS_ERR(dwc->usb2_phy))
+   return PTR_ERR(dwc->usb2_phy);
+   dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev,
+   "usb-phy", 1);
+   if (IS_ERR(dwc->usb3_phy))
+   return PTR_ERR(dwc->usb3_phy);
+   } else {
+   dwc->usb2_phy = NULL;
+   dwc->usb3_phy = NULL;
+   }
 
dwc->needs_fifo_resize = of_property_read_bool(node, 
"tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
 
-   dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+   if (pdata->has_phy) {
+   dwc->usb2_phy = devm_usb_get_phy(dev,
+   USB_PHY_TYPE_USB2);
+   if (IS_ERR(dwc->usb2_phy))
+   return PTR_ERR(dwc->usb2_phy);
+   dwc->usb3_phy = devm_usb_get_phy(dev,
+   USB_PHY_TYPE_USB3);
+   if (IS_ERR(dwc->usb3_phy))
+   return PTR_ERR(dwc->usb3_phy);
+   } else {
+   dwc->usb2_phy = NULL;
+   dwc->usb3_phy = NULL;
+   }
 
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
@@ -409,36 +431,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc->maximum_speed == USB_SPEED_UNKNOWN)
dwc->maximum_speed = USB_SPEED_SUPER;
 
-   if (IS_ERR(dwc->usb2_phy)) {
-   ret = PTR_ERR(dwc->usb2_phy);
-
-   /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
-   if (ret == -ENXIO)
-   return ret;
-
-   dev_err(dev, "no usb2 phy configured\n");
-   return -EPROBE_DEFER;
-   }
-
-   if (IS_ERR(dwc->usb3_phy)) {
-   ret = PTR_ERR(dwc->usb3_phy);
-
-   /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
-   if (ret == -ENXIO)
-   return ret;
-
-   dev_err(dev, "no usb3 phy configured\n");
-   return -EPROBE_DEFER;
-   }
-
dwc->xhci_resources[0].start = res->start;
dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
DWC3_XHCI_REGS_END;
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..5a5e068 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,5 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
  

Re: 3.10.9: kmemleak disables all CPUs except CPU0

[Martin MOKREJŠ]

Catalin Marinas wrote:
> On 31 August 2013 14:35, Martin MOKREJŠ  wrote:
>>   never realized that my CPUs are gone if I compile into kernel kmemleak.
>> Is that really the aim?
>>
>> CONFIG_HAVE_DEBUG_KMEMLEAK=y
>> CONFIG_DEBUG_KMEMLEAK=y
>> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
>> # CONFIG_DEBUG_KMEMLEAK_TEST is not set
>> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
>>
>> 1.  Why isn't there /sys/devices/system/cpu/cpu0/online file?
>> Does not matter if it contains 0 or 1. It just should exist.
> 
> I can't really see how kmemleak would do this, maybe other config
> options that get set/cleared in the process of selecting kmemleak. Can
> you do a diff between your config with /sys/... entries and the one
> without?

Hi,
  I tried but did not get to report back. One one these re-enabled my CPUs back.

@@ -3177,14 +3179,7 @@
 CONFIG_HAVE_ARCH_KGDB=y
 # CONFIG_KGDB is not set
 CONFIG_HAVE_ARCH_KMEMCHECK=y
-CONFIG_KMEMCHECK=y
-# CONFIG_KMEMCHECK_DISABLED_BY_DEFAULT is not set
-# CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT is not set
-CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT=y
-CONFIG_KMEMCHECK_QUEUE_SIZE=64
-CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT=5
-CONFIG_KMEMCHECK_PARTIAL_OK=y
-# CONFIG_KMEMCHECK_BITOPS_OK is not set
+# CONFIG_KMEMCHECK is not set
 # CONFIG_TEST_STRING_HELPERS is not set
 # CONFIG_TEST_KSTRTOX is not set
 # CONFIG_STRICT_DEVMEM is not set


So, the CONFIG_KMEMCHECK disables the additional CPUs I believe. I thought it
should be traceable from the dmesg output I sent to the list. Yes, I screwed the
subject line because I did not realize a difference so far. :(

Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework

[Kishon Vijay Abraham I]

Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().

However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
 drivers/usb/dwc3/Kconfig   |1 +
 drivers/usb/dwc3/core.c|   49 
 drivers/usb/dwc3/core.h|7 
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
  - compatible: must be "snps,dwc3"
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
  - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
 
 This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) && GENERIC_HARDIRQS && HAS_DMA
depends on EXTCON
select USB_PHY
+   select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
help
  Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
 
usb_phy_init(dwc->usb2_phy);
usb_phy_init(dwc->usb3_phy);
+
+   if (dwc->usb2_generic_phy)
+   phy_init(dwc->usb2_generic_phy);
+   if (dwc->usb3_generic_phy)
+   phy_init(dwc->usb3_generic_phy);
+
mdelay(100);
 
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
 {
usb_phy_shutdown(dwc->usb2_phy);
usb_phy_shutdown(dwc->usb3_phy);
+
+   if (dwc->usb2_generic_phy)
+   phy_power_off(dwc->usb2_generic_phy);
+   if (dwc->usb3_generic_phy)
+   phy_power_off(dwc->usb3_generic_phy);
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
 
+   if (of_property_read_bool(node, "phys") || pdata->has_phy) {
+   dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
+   if (IS_ERR(dwc->usb2_generic_phy)) {
+   dev_err(dev, "no usb2 phy configured yet");
+   return PTR_ERR(dwc->usb2_generic_phy);
+   }
+
+   dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
+   if (IS_ERR(dwc->usb3_generic_phy)) {
+   dev_err(dev, "no usb3 phy configured yet");
+   return PTR_ERR(dwc->usb3_generic_phy);
+   }
+   } else {
+   dwc->usb2_generic_phy = NULL;
+   dwc->usb3_generic_phy = NULL;
+   }
+
/* default to superspeed if no maximum_speed passed */
if (dwc->maximum_speed == USB_SPEED_UNKNOWN)
dwc->maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
 
+   if (dwc->usb2_generic_phy)
+   phy_power_on(dwc->usb2_generic_phy);
+   if (dwc->usb3_generic_phy)
+   phy_power_on(dwc->usb3_generic_phy);
+
spin_lock_init(>lock);
platform_set_drvdata(pdev, dwc);
 
@@ -576,6 +609,11 @@ static int dwc3_remove(struct platform_device *pdev)
usb_phy_set_suspend(dwc->usb2_phy, 1);
usb_phy_set_suspend(dwc->usb3_phy, 1);
 
+   if (dwc->usb2_generic_phy)
+   phy_power_off(dwc->usb2_generic_phy);
+   if (dwc->usb3_generic_phy)
+   phy_power_off(dwc->usb3_generic_phy);
+
pm_runtime_put(>dev);
pm_runtime_disable(>dev);
 
@@ -673,6 +711,11 @@ static int dwc3_suspend(struct device *dev)

[PATCH 3/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework

[Kishon Vijay Abraham I]

Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-omap-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/usb/usb-phy.txt  |5 +-
 drivers/phy/Kconfig|   10 +
 drivers/phy/Makefile   |1 +
 .../phy/phy-omap-usb3.c => phy/phy-omap-pipe3.c}   |  206 +++-
 drivers/usb/phy/Kconfig|   11 --
 drivers/usb/phy/Makefile   |1 -
 include/linux/phy/omap_pipe3.h |   52 +
 7 files changed, 177 insertions(+), 109 deletions(-)
 rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-omap-pipe3.c} (57%)
 create mode 100644 include/linux/phy/omap_pipe3.h

diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index c0245c8..36bdb17 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -21,10 +21,11 @@ usb2phy@4a0ad080 {
#phy-cells = <0>;
 };
 
-OMAP USB3 PHY
+OMAP PIPE3 PHY
 
 Required properties:
- - compatible: Should be "ti,omap-usb3"
+ - compatible: Should be "ti,omap-usb3", "ti,omap-pipe3", "ti,omap-sata"
+   or "ti,omap-pcie"
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in "reg".
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..5c2e7a0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,6 +27,16 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config OMAP_PIPE3
+   tristate "OMAP PIPE3 PHY Driver"
+   select GENERIC_PHY
+   select OMAP_CONTROL_USB
+   help
+ Enable this to support the PIPE3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the "OMAP Control PHY Driver" to power
+ on/off the PHY.
+
 config TWL4030_USB
tristate "TWL4030 USB Transceiver Driver"
depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..48bf9f2 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,4 +4,5 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_OMAP_PIPE3)   += phy-omap-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-omap-pipe3.c
similarity index 57%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-omap-pipe3.c
index 4004f82..ee9a901 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -1,5 +1,5 @@
 /*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * omap-pipe3 - PHY driver for SATA, USB and PCIE in OMAP platforms
  *
  * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
  * This program is free software; you can redistribute it and/or modify
@@ -19,7 +19,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -52,17 +53,17 @@
 
 /*
  * This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
  */
 # define PLL_IDLE_TIME  100;
 
-struct usb_dpll_map {
+struct pipe3_dpll_map {
unsigned long rate;
-   struct usb_dpll_params params;
+   struct pipe3_dpll_params params;
 };
 
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} },   /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} },  /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} },   /* 19.2 MHz */
@@ -71,7 +72,7 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20, 92843} },  /* 38.4 MHz */
 };
 
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(unsigned long rate)
 {
int i;
 
@@ -83,110 +84,113 @@ static struct usb_dpll_params 
*omap_usb3_get_dpll_params(unsigned long rate)
return 0;
 }
 
-static int omap_usb3_suspend(struct usb_phy *x, int suspend)
+static int omap_pipe3_power_off(struct phy *x)
 {
-   struct omap_usb *phy = phy_to_omapusb(x);
-   int val;
+   struct omap_pipe3 *phy = phy_get_drvdata(x);
+   int val;
  

Re: 3.10.9: kmemleak disables all CPUs except CPU0

[Max Filippov]

On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas  wrote:
> On 31 August 2013 14:35, Martin MOKREJŠ  wrote:
>>   never realized that my CPUs are gone if I compile into kernel kmemleak.
>> Is that really the aim?
>>
>> CONFIG_HAVE_DEBUG_KMEMLEAK=y
>> CONFIG_DEBUG_KMEMLEAK=y
>> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
>> # CONFIG_DEBUG_KMEMLEAK_TEST is not set
>> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
>>
>> 1.  Why isn't there /sys/devices/system/cpu/cpu0/online file?
>> Does not matter if it contains 0 or 1. It just should exist.
>
> I can't really see how kmemleak would do this, maybe other config
> options that get set/cleared in the process of selecting kmemleak. Can

Seems to be kmemcheck: from arch/x86/mm/kmemcheck/kmemcheck.c:

int __init kmemcheck_init(void)
{
#ifdef CONFIG_SMP
/*
 * Limit SMP to use a single CPU. We rely on the fact that this code
 * runs before SMP is set up.
 */
if (setup_max_cpus > 1) {
printk(KERN_INFO
"kmemcheck: Limiting number of CPUs to 1.\n");
setup_max_cpus = 1;
}
#endif

-- 
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] arm/dts: added dt properties to adapt to the new phy framwork

[Kishon Vijay Abraham I]

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/omap5.dtsi |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 94abef5..9fe71ff 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -651,7 +651,8 @@
compatible = "snps,dwc3";
reg = <0x4a03 0x1>;
interrupts = ;
-   usb-phy = <_phy>, <_phy>;
+   phys = <_phy>, <_phy>;
+   phy-names = "usb2-phy", "usb3-phy";
tx-fifo-resize;
};
};
@@ -667,6 +668,7 @@
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
ctrl-module = <_control_usb2phy>;
+   #phy-cells = <0>;
};
 
usb3_phy: usb3phy@4a084400 {
@@ -676,6 +678,7 @@
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <_control_usb3phy>;
+   #phy-cells = <0>;
};
};
 
-- 
1.7.10.4

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

[PATCH 4/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/omap-phy.txt

[Kishon Vijay Abraham I]

Since now we have a separate folder for phy, move the PHY dt binding
documentation of OMAP to that folder.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/{usb/usb-phy.txt => phy/omap-phy.txt}|2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename Documentation/devicetree/bindings/{usb/usb-phy.txt => phy/omap-phy.txt} 
(96%)

diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/phy/omap-phy.txt
similarity index 96%
rename from Documentation/devicetree/bindings/usb/usb-phy.txt
rename to Documentation/devicetree/bindings/phy/omap-phy.txt
index 36bdb17..2c485ee 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/omap-phy.txt
@@ -1,4 +1,4 @@
-USB PHY
+OMAP PHY: DT DOCUMENTATION FOR PHYs in OMAP PLATFORM
 
 OMAP USB2 PHY
 
-- 
1.7.10.4

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

[PATCH 5/7] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/

[Kishon Vijay Abraham I]

No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-omap-usb2.c   |2 +-
 drivers/usb/phy/phy-twl6030-usb.c |2 +-
 include/linux/{usb => phy}/omap_usb.h |3 ---
 3 files changed, 2 insertions(+), 5 deletions(-)
 rename include/linux/{usb => phy}/omap_usb.h (95%)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index b25d623..6c78584 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/usb/phy/phy-twl6030-usb.c 
b/drivers/usb/phy/phy-twl6030-usb.c
index 16dbc93..b5ad3eb 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -26,8 +26,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
 struct omap_usb {
struct usb_phy  phy;
struct phy_companion*comparator;
-   void __iomem*pll_ctrl_base;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
-   struct clk  *sys_clk;
struct clk  *optclk;
-   u8  is_suspended:1;
 };
 
 #definephy_to_omapusb(x)   container_of((x), struct omap_usb, phy)
-- 
1.7.10.4

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

[PATCH 7/7] drivers: phy: renamed struct omap_control_usb to struct omap_control_phy

[Kishon Vijay Abraham I]

renamed struct omap_control_usb to struct omap_control_phy since it can
be used to control PHY of USB, SATA and PCIE. Also moved the driver and
include files under *phy* and made the corresponding changes in the users
of phy-omap-control.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig|   14 +-
 drivers/phy/Makefile   |1 +
 drivers/{usb => }/phy/phy-omap-control.c   |  164 ++--
 drivers/phy/phy-omap-pipe3.c   |8 +-
 drivers/phy/phy-omap-usb2.c|8 +-
 drivers/usb/musb/omap2430.c|2 +-
 drivers/usb/phy/Makefile   |1 -
 .../omap_control_usb.h => phy/omap_control_phy.h}  |   32 ++--
 8 files changed, 120 insertions(+), 110 deletions(-)
 rename drivers/{usb => }/phy/phy-omap-control.c (55%)
 rename include/linux/{usb/omap_control_usb.h => phy/omap_control_phy.h} (69%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c2e7a0..fd11294 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,12 +15,22 @@ config GENERIC_PHY
  phy users can obtain reference to the PHY. All the users of this
  framework should select this config.
 
+config OMAP_CONTROL_PHY
+   tristate "OMAP CONTROL PHY Driver"
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   help
+ Enable this to add support for the PHY part present in the control
+ module. This driver has API to power on the USB2 PHY and to write to
+ the mailbox. The mailbox is present only in omap4 and the register to
+ power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has
+ additional registers to power on PIPE3 PHYs.
+
 config OMAP_USB2
tristate "OMAP USB2 PHY Driver"
depends on ARCH_OMAP2PLUS
select GENERIC_PHY
select USB_PHY
-   select OMAP_CONTROL_USB
+   select OMAP_CONTROL_PHY
help
  Enable this to support the transceiver that is part of SOC. This
  driver takes care of all the PHY functionality apart from comparator.
@@ -30,7 +40,7 @@ config OMAP_USB2
 config OMAP_PIPE3
tristate "OMAP PIPE3 PHY Driver"
select GENERIC_PHY
-   select OMAP_CONTROL_USB
+   select OMAP_CONTROL_PHY
help
  Enable this to support the PIPE3 PHY that is part of SOC. This
  driver takes care of all the PHY functionality apart from comparator.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 48bf9f2..f0127f6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
+obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
 obj-$(CONFIG_OMAP_PIPE3)   += phy-omap-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
similarity index 55%
rename from drivers/usb/phy/phy-omap-control.c
rename to drivers/phy/phy-omap-control.c
index 1a7e19a..ece3573 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -1,5 +1,5 @@
 /*
- * omap-control-usb.c - The USB part of control module.
+ * phy-omap-control.c - The USB part of control module.
  *
  * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
  * This program is free software; you can redistribute it and/or modify
@@ -24,36 +24,36 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /**
- * omap_control_usb_phy_power - power on/off the phy using control module reg
+ * omap_control_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
  * @on: 0 or 1, based on powering on or off the PHY
  */
-void omap_control_usb_phy_power(struct device *dev, int on)
+void omap_control_phy_power(struct device *dev, int on)
 {
u32 val, val_aux;
unsigned long rate;
-   struct omap_control_usb *control_usb;
+   struct omap_control_phy *control_phy;
 
if (IS_ERR(dev) || !dev) {
pr_err("%s: invalid device\n", __func__);
return;
}
 
-   control_usb = dev_get_drvdata(dev);
-   if (!control_usb) {
+   control_phy = dev_get_drvdata(dev);
+   if (!control_phy) {
dev_err(dev, "%s: invalid control usb device\n", __func__);
return;
}
 
-   if (control_usb->type == OMAP_CTRL_TYPE_OMAP4)
+   if (control_phy->type == OMAP_CTRL_TYPE_OMAP4)
return;
 
-   val = readl(control_usb->power);
+   val = readl(control_phy->power);
 
-   switch (control_usb->type) {
+   switch (control_phy->type) {
case OMAP_CTRL_TYPE_USB2:
if (on)
val &= ~OMAP_CTRL_DEV_PHY_PD;
@@ -62,24 +62,24 @@ void omap_control_usb_phy_power(struct device *dev, int on)
   

[PATCH 0/7] Make dwc3 use Generic PHY Framework and misc cleanup

[Kishon Vijay Abraham I]

Modified dwc3 core to find PHYs only if the platform indicates that it has
to use a PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also
changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver
has to be used for SATA and PCIE too.

This series also includes a bunch of misc cleanups and also renamed
omap_control_usb to omap_control_phy (done on top of rogers patches [1])

Did g_zero enumeration testing on OMAP4 PANDA and did xhci testing in
OMAP5 uEvm.

I have pushed this branch to http://git.gitorious.org/linuxphy/linuxphy.git
dwc3_generic_phy

[1] -> git://github.com/rogerq/linux.git usb-control-module

Kishon Vijay Abraham I (7):
  usb: dwc3: get "usb_phy" only if the platform indicates the presence
of PHY
  usb: dwc3: adapt dwc3 core to use Generic PHY Framework
  drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
  Documentation: dt bindings: move ..usb/usb-phy.txt to
..phy/omap-phy.txt
  phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
  arm/dts: added dt properties to adapt to the new phy framwork
  drivers: phy: renamed struct omap_control_usb to struct
omap_control_phy

 .../bindings/{usb/usb-phy.txt => phy/omap-phy.txt} |7 +-
 Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
 arch/arm/boot/dts/omap5.dtsi   |5 +-
 drivers/phy/Kconfig|   22 +-
 drivers/phy/Makefile   |2 +
 drivers/{usb => }/phy/phy-omap-control.c   |  164 +++
 .../phy/phy-omap-usb3.c => phy/phy-omap-pipe3.c}   |  212 +++-
 drivers/phy/phy-omap-usb2.c|   10 +-
 drivers/usb/dwc3/Kconfig   |2 +
 drivers/usb/dwc3/core.c|  109 ++
 drivers/usb/dwc3/core.h|7 +
 drivers/usb/dwc3/platform_data.h   |1 +
 drivers/usb/musb/omap2430.c|2 +-
 drivers/usb/phy/Kconfig|   11 -
 drivers/usb/phy/Makefile   |2 -
 drivers/usb/phy/phy-twl6030-usb.c  |2 +-
 .../omap_control_usb.h => phy/omap_control_phy.h}  |   32 +--
 include/linux/{usb/omap_usb.h => phy/omap_pipe3.h} |   33 +--
 include/linux/{usb => phy}/omap_usb.h  |3 -
 19 files changed, 348 insertions(+), 284 deletions(-)
 rename Documentation/devicetree/bindings/{usb/usb-phy.txt => phy/omap-phy.txt} 
(88%)
 rename drivers/{usb => }/phy/phy-omap-control.c (55%)
 rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-omap-pipe3.c} (55%)
 rename include/linux/{usb/omap_control_usb.h => phy/omap_control_phy.h} (69%)
 copy include/linux/{usb/omap_usb.h => phy/omap_pipe3.h} (52%)
 rename include/linux/{usb => phy}/omap_usb.h (95%)

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

Hallo..........

[Mutoni Williams]

Hello,How are you,I hope you're well,my name is Mutoni,I'm medium height and 
fair in complexion,i love,caring and I decided to contact you.I really want to 
have a good relationship with you.Next I have a special something I want to 
discuss with you,and tell you more about my self.Hope hear from you soon.I know 
age will not be a bearier to our relationship,I will give my best. 
Yours,Miss.Mutoni.
 
Hallo,Wie geht es dir,ich hoffe,du bist gut,mein Name ist Mutoni, ich mittlerer 
Höhe und Messe in Teint bin,ich liebe,fürsorgliche und ich beschlossen,you.I 
kontaktieren wirklich wollen,eine gute Beziehung mit Ihnen haben.Weiter habe 
ich eine besondere etwas möchte ich mit Ihnen zu besprechen haben,und erfahren 
Sie mehr über meine self.Hope von Ihnen zu hören soon.i wissen Alter wird kein 
bearier,unsere Beziehung zu sein, werde ich mein Bestes geben.Yours,Miss.Mutoni.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.9: kmemleak disables all CPUs except CPU0

[Catalin Marinas]

On 31 August 2013 14:35, Martin MOKREJŠ  wrote:
>   never realized that my CPUs are gone if I compile into kernel kmemleak.
> Is that really the aim?
>
> CONFIG_HAVE_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
> # CONFIG_DEBUG_KMEMLEAK_TEST is not set
> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
>
> 1.  Why isn't there /sys/devices/system/cpu/cpu0/online file?
> Does not matter if it contains 0 or 1. It just should exist.

I can't really see how kmemleak would do this, maybe other config
options that get set/cleared in the process of selecting kmemleak. Can
you do a diff between your config with /sys/... entries and the one
without?

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: mach-iop32x: iq31244: Replace if-then-else with a switch statement

[Valentin Ilie]

Convert a compound if-else blob to a switch statement.

Signed-off-by: Valentin Ilie 
---
 arch/arm/mach-iop32x/iq31244.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index f2cd296..3415f11 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -101,28 +101,21 @@ void __init iq31244_map_io(void)
 static int __init
 ep80219_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   int irq;
-
-   if (slot == 0) {
-   /* CFlash */
-   irq = IRQ_IOP32X_XINT1;
-   } else if (slot == 1) {
-   /* 82551 Pro 100 */
-   irq = IRQ_IOP32X_XINT0;
-   } else if (slot == 2) {
-   /* PCI-X Slot */
-   irq = IRQ_IOP32X_XINT3;
-   } else if (slot == 3) {
-   /* SATA */
-   irq = IRQ_IOP32X_XINT2;
-   } else {
+   switch (slot) {
+   case 0: /* CFlash */
+   return IRQ_IOP32X_XINT1;
+   case 1: /* 82551 Pro 100 */
+   return IRQ_IOP32X_XINT0;
+   case 2: /* PCI-X Slot */
+   return IRQ_IOP32X_XINT3;
+   case 3: /* SATA */
+   return IRQ_IOP32X_XINT2;
+   default:
printk(KERN_ERR "ep80219_pci_map_irq() called for unknown "
"device PCI:%d:%d:%d\n", dev->bus->number,
PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
-   irq = -1;
+   return -1;
}
-
-   return irq;
 }
 
 static struct hw_pci ep80219_pci __initdata = {
-- 
1.8.1.2

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

Re: [PATCH] Remove support for score architecture

[Lennox Wu]

Before we start the development of the S+core, Sunplus had licensed
ARM and MIPS. We develop S+core for other reason such as the price.
Some products on the web of Sunplus adopt S+core , for example
the SPV7050.(http://w3.sunplus.com/products/spv7050.asp) These products
could still be bought from the market. Some high-end products adopt
ARM or MIPS. So, there is no conflict for a company adopts multiple
architectures.

As I said, we recognize that we rarely update because of the limited
applications and rare requests from customers. Maybe we don’t
understand the culture enough; we think that it is unnecessary if we
have no new bugs or new functions, the thought seems wrong. We can
commit some patches in the near future.

Best,
Lennox

2013/9/2 Guenter Roeck :
> On 09/01/2013 09:13 PM, Lennox Wu wrote:
>>
>> Dear all,
>>
>> Indeed, Sunplus S+core is not a popular architecture and there is no
>> standalone to be sold so you should not find related news on the
>> Internet.  However, the s+core is adopted by our SoCs and these SoCs
>> are indeed adopted by some companies, we hope the architecture can be
>> reserved to provide the more and more powerful Linux for our
>> customers. It is true that we rarely update the code because that we
>> are rarely requested to add new functions and to correct bugs by our
>> customers, and it is also because we have no new product to release.
>> In the near future, we will release some patches for the existed
>> S+core architecture.
>>
>
> Key question is not if the platform is popular, but if it is maintained.
> The commit log over the last two years strongly suggests that this is
> not the case. I suspect that the code is far from compilable at this point,
> much less executable. Unfortunately this is hard to verify, as a pre-built
> or even buildable toolchain is not easily available.
>
> From a company perspective, you might want to decide if you want to put
> resources into this architecture to keep it alive, or focus on more recent
> chips and architectures. Information available on the internet suggests
> that Suncore's more recent chips are based on ARM. Given that, it appears
> somewhat unlikely that resources for maintaining S+core will be made
> available. Guess we'll see if the situation changes.
>
> Guenter
>
>
>> 2013/8/31 Guenter Roeck :
>>>
>>> The web site associated with the score architecture in MAINTAINERS
>>> is non-functional and available for sale. The last Ack from one
>>> of the maintainers was in December 2012. The main maintainer's last
>>> commit was in 2011. The last maintainer pull request was early 2011.
>>>
>>> Cc: Lennox Wu 
>>> Cc: Chen Liqin 
>>> Signed-off-by: Guenter Roeck 
>>> ---
>>> More housekeeping.
>>>
>>> Maybe this removal request is a bit early, but architecture support seems
>>> to have vanished entirely. At the very least this puts interested parties
>>> (if there are any) on notice.
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM/ARM64 architected timer updates for v3.12, take 2

[Daniel Lezcano]

On 09/02/2013 05:04 PM, Sudeep KarkadaNagesha wrote:
> On 02/09/13 15:54, Daniel Lezcano wrote:
>> On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote:
>>> git://linux-arm.org/linux-skn.git timer_evtstrm
>>
>> Hi Sudeep,
>>
>> I don't see the acked-by from Olof or Kevin.
>>
>> Your patchset touches files under arch/arm which are maintained by them
>> and I won't take the patchset if they don't agree the modifications on
>> the files falling under my umbrella that will pass through my tree.
>>
>> Please do it ASAP if you want a chance to hit 3.12, it is already very late.
> 
> As Olof already mentioned, I think its too late for v3.12.
> He wants me to repost after v3.12 merge window. I will do the same.

ok.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM/ARM64 architected timer updates for v3.12, take 2

[Sudeep KarkadaNagesha]

On 02/09/13 15:54, Daniel Lezcano wrote:
> On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote:
>> git://linux-arm.org/linux-skn.git timer_evtstrm
> 
> Hi Sudeep,
> 
> I don't see the acked-by from Olof or Kevin.
> 
> Your patchset touches files under arch/arm which are maintained by them
> and I won't take the patchset if they don't agree the modifications on
> the files falling under my umbrella that will pass through my tree.
> 
> Please do it ASAP if you want a chance to hit 3.12, it is already very late.

As Olof already mentioned, I think its too late for v3.12.
He wants me to repost after v3.12 merge window. I will do the same.

Regards,
Sudeep



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

[PATCH 1/1] drivers/acpi: acpi_ipmi.c replace mutex with spin_lock_irqsave

[Tony Camuso]

From: tcam...@redhat.com

From: Tony Camuso 

We were getting occasional "Scheduling while atomic" call traces
during boot on some systems. Problem was first seen on a Cisco C210
but we were able to reproduce it on a Cisco c220m3. Setting
CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.

=
[ INFO: inconsistent lock state ]
2.6.32-415.el6.x86_64-debug-splck #1
-
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (_device->tx_msg_lock){+.?...}, at: [] 
ipmi_msg_handler+0x71/0x126
{SOFTIRQ-ON-W} state was registered at:
  [] __lock_acquire+0x63c/0x1570
  [] lock_acquire+0xa4/0x120
  [] __mutex_lock_common+0x4c/0x400
  [] mutex_lock_nested+0x4a/0x60
  [] acpi_ipmi_space_handler+0x11b/0x234
  [] acpi_ev_address_space_dispatch+0x170/0x1be

The ipmi_msg_handler() function in drivers/acpi/acpi_ipmi was taking
a mutex_lock after ultimately being called from a call chain initiated
by function smi_rcv_tasklet() in drivers/char/ipmi/ipmi_msghandler.c.

Documentation/mutex-design.txt on lines 93 and 94 says, "mutexes may
not be used in hardware or software interrupt contexts such as
tasklets and timers."

The patch changes the mutex member tx_msg_lock in acpi_ipmi.c struct
acpi_ipmi_device to a spinlock_t and replaces mutex_lock/unlock pairs
with spin_lock_irqsave/unlock_irqrestore around tx_msg_lock for
accesses to that struct.

Tested the patch in a boot loop with lockdep debug enabled and never
saw the problem in over 400 reboots.

Signed-off-by: Tony Camuso 

---
 drivers/acpi/acpi_ipmi.c |   24 ++--
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index f40acef..a4b428d 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -57,7 +57,7 @@ struct acpi_ipmi_device {
struct list_head head;
/* the IPMI request message list */
struct list_head tx_msg_list;
-   struct mutextx_msg_lock;
+   spinlock_t tx_msg_lock;
acpi_handle handle;
struct pnp_dev *pnp_dev;
ipmi_user_t user_interface;
@@ -147,6 +147,7 @@ static void acpi_format_ipmi_msg(struct acpi_ipmi_msg 
*tx_msg,
struct kernel_ipmi_msg *msg;
struct acpi_ipmi_buffer *buffer;
struct acpi_ipmi_device *device;
+   unsigned long flags;
 
msg = _msg->tx_message;
/*
@@ -177,10 +178,10 @@ static void acpi_format_ipmi_msg(struct acpi_ipmi_msg 
*tx_msg,
 
/* Get the msgid */
device = tx_msg->device;
-   mutex_lock(>tx_msg_lock);
+   spin_lock_irqsave(>tx_msg_lock, flags);
device->curr_msgid++;
tx_msg->tx_msgid = device->curr_msgid;
-   mutex_unlock(>tx_msg_lock);
+   spin_unlock_irqrestore(>tx_msg_lock, flags);
 }
 
 static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
@@ -242,6 +243,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, 
void *user_msg_data)
int msg_found = 0;
struct acpi_ipmi_msg *tx_msg;
struct pnp_dev *pnp_dev = ipmi_device->pnp_dev;
+   unsigned long flags;
 
if (msg->user != ipmi_device->user_interface) {
dev_warn(_dev->dev, "Unexpected response is returned. "
@@ -250,7 +252,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, 
void *user_msg_data)
ipmi_free_recv_msg(msg);
return;
}
-   mutex_lock(_device->tx_msg_lock);
+   spin_lock_irqsave(_device->tx_msg_lock, flags);
list_for_each_entry(tx_msg, _device->tx_msg_list, head) {
if (msg->msgid == tx_msg->tx_msgid) {
msg_found = 1;
@@ -258,7 +260,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, 
void *user_msg_data)
}
}
 
-   mutex_unlock(_device->tx_msg_lock);
+   spin_unlock_irqrestore(_device->tx_msg_lock, flags);
if (!msg_found) {
dev_warn(_dev->dev, "Unexpected response (msg id %ld) is "
"returned.\n", msg->msgid);
@@ -378,6 +380,8 @@ acpi_ipmi_space_handler(u32 function, acpi_physical_address 
address,
struct acpi_ipmi_device *ipmi_device = handler_context;
int err, rem_time;
acpi_status status;
+   unsigned long flags;
+
/*
 * IPMI opregion message.
 * IPMI message is firstly written to the BMC and system software
@@ -395,9 +399,9 @@ acpi_ipmi_space_handler(u32 function, acpi_physical_address 
address,
return AE_NO_MEMORY;
 
acpi_format_ipmi_msg(tx_msg, address, value);
-   mutex_lock(_device->tx_msg_lock);
+   spin_lock_irqsave(_device->tx_msg_lock, flags);
list_add_tail(_msg->head, _device->tx_msg_list);
-   mutex_unlock(_device->tx_msg_lock);
+   spin_unlock_irqrestore(_device->tx_msg_lock, flags);
 

Re: [GIT PULL] ARM/ARM64 architected timer updates for v3.12, take 2

[Daniel Lezcano]

On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote:
> git://linux-arm.org/linux-skn.git timer_evtstrm

Hi Sudeep,

I don't see the acked-by from Olof or Kevin.

Your patchset touches files under arch/arm which are maintained by them
and I won't take the patchset if they don't agree the modifications on
the files falling under my umbrella that will pass through my tree.

Please do it ASAP if you want a chance to hit 3.12, it is already very late.

Thanks
  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH] drm/i2c: Fix broken TDA998x audio (was: Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration)

[Russell King - ARM Linux]

On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> From: Russell King 
> 
> This patch adds tda998x specific parameters to allow it to be configured
> for different boards using it. Also, this implements rudimentary audio
> support for S/PDIF attached controllers.
> 
> Signed-off-by: Russell King 
> Signed-off-by: Sebastian Hesselbarth 
> Tested-by: Darren Etheridge 
> ---

It looks like there's been a bug introduced in this patch (which wasn't
in my original).

> @@ -445,8 +681,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int 
> mode)
>  
>   switch (mode) {
>   case DRM_MODE_DPMS_ON:
> - /* enable audio and video ports */
> - reg_write(encoder, REG_ENA_AP, 0xff);
> + /* enable video ports, audio will be enabled later */
>   reg_write(encoder, REG_ENA_VP_0, 0xff);
>   reg_write(encoder, REG_ENA_VP_1, 0xff);
>   reg_write(encoder, REG_ENA_VP_2, 0xff);

I also disabled the writing to REG_ENA_AP in the DPMS off path as well,
which clears this register.

That seems to be missing from this patch, and it means that when the
display is placed into DPMS-off mode, the audio inputs are disabled,
never to be re-enabled.  There is no need to disable the audio input
in DPMS-off mode.

8<=
From: Russell King 
Subject: [PATCH] drm/i2c: Fix broken TDA998x audio

In patch "drm/i2c: tda998x: add video and audio input configuration" in
its original version, disabling the audio input port was removed.  The
version which was submitted for merging had this change deleted, which
results in audio being non-functional.  Fix this by removing the write.
While here, update the comment too.

Signed-off-by: Russell King 
--- 
 drivers/gpu/drm/i2c/tda998x_drv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 5742cfc..59878af 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -705,8 +705,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
reg_write(encoder, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
break;
case DRM_MODE_DPMS_OFF:
-   /* disable audio and video ports */
-   reg_write(encoder, REG_ENA_AP, 0x00);
+   /* disable video ports */
reg_write(encoder, REG_ENA_VP_0, 0x00);
reg_write(encoder, REG_ENA_VP_1, 0x00);
reg_write(encoder, REG_ENA_VP_2, 0x00);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dmaengine: dma_slave_caps: remove sg entries

[Lars-Peter Clausen]

On 09/02/2013 02:21 PM, Vinod Koul wrote:
> As pointed by Russell in [1], the sg properties are already availble in 
> struct device,
> so no need to duplicate here.
> 
> [1]: http://marc.info/?l=linux-omap=137416733628831

Hm, I guess that will work as well, but shouldn't we update the drivers that
already implementing this interface first?

- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Clock framework deadlock with external SPI clockchip

[Lars-Peter Clausen]

On 09/02/2013 01:18 PM, Peter De Schrijver wrote:
> On Fri, Aug 30, 2013 at 03:24:45PM +0200, Lars-Peter Clausen wrote:
>> Hi,
>>
>> I'm currently facing a deadlock in the common clock framework that
>> unfortunately is not addressed by the reentrancy patches. I have a external
>> clock chip that is controlled via SPI. So for example to configure the rate
>> of the clock chip you need to send a SPI message. Naturally the clock
>> framework will hold the prepare lock while configuring the rate.
>> Communication in the SPI framework happens asynchronously, spi_sync() will
>> enqueue a message in the SPI masters queue and then wait using
>> wait_for_completion(). The master will call complete() once the transfer has
>> been finished. The SPI master runs in it's own thread in which it processes
>> the messages. In this thread it also calls clk_set_rate() to configure the
>> SPI transfer clock rate based on what the message says. Now the deadlock
>> happens as we try to take the prepare_lock again and since the clock chip
>> and the SPI master run in different threads the reentrancy code does not
>> kick in.
>>
>> The basic sequence is like this:
>>
>> === Clock chip driver ====== SPI master driver ===
>>  clk_prepare_lock()
>>  spi_sync()
>>wait_for_completion(X)
>>  clk_get_rate()
>> clk_prepare_lock() <--- DEADLOCK
>> clk_prepare_unlock()
>>   ...
>>   complete(X)
>>  ...
>>  clk_prepare_unlock()
>>
>> I'm wondering if you have any idea how this can be fixed. In my opinion we'd
>> need a per clock mutex to address this properly.
> 
> One workaround is to leave the SPI masters clock always prepared. A similar
> problem can occur with I2C and DVFS using notifiers.


That's kind of what I'm doing right now as a temporary solution. But we'd
basically need to have all SPI or I2C master drivers to be aware that they
might be used for controlling a external clock chip. And there are also
situations where the workaround does not work. E.g. if the clk API is used
to configure the rate of the SPI SCK signal, since the rate can be set by
the spi message.

- Lars

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

Re: [Xen-devel] [PATCH v5 02/13] arm: introduce a global dma_ops pointer

[Julien Grall]

On 08/29/2013 07:32 PM, Stefano Stabellini wrote:
> Initially set dma_ops to arm_dma_ops.
> 
> 
> Signed-off-by: Stefano Stabellini 
> Acked-by: Konrad Rzeszutek Wilk 
> CC: will.dea...@arm.com
> CC: li...@arm.linux.org.uk
> 
> 
> Changes in v3:
> -  keep using arm_dma_ops in dmabounce.
> ---
>  arch/arm/include/asm/dma-mapping.h |3 ++-
>  arch/arm/mm/dma-mapping.c  |3 +++
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/include/asm/dma-mapping.h 
> b/arch/arm/include/asm/dma-mapping.h
> index 0982206..7d6e4f9 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -13,6 +13,7 @@
>  #include 
>  
>  #define DMA_ERROR_CODE   (~0)
> +extern struct dma_map_ops *dma_ops;

Hi,

I tried to build your swiotlb patch series for the Arndale. I have a compilation
error because dma_ops is already used in samsung sound driver 
(sound/soc/samsung/dma.c).

This small fix allow me to built this serie for the Arndale.
Do I need to send it separately?

===
commit 73d4ceded87f52fa958b92d8d8d65be485e90857
Author: Julien Grall 
Date:   Mon Sep 2 15:36:35 2013 +0100

ASoC: Samsung: Rename dma_ops by samsung_dma_ops

The commit "arm: introduce a global dma_ops pointer" introduce compilation 
issue
when CONFIG_SND_SOC_SAMSUNG is enabled.

sound/soc/samsung/dma.c:345:27: error: conflicting types for 'dma_ops'

/local/home/julien/works/arndale/linux/arch/arm/include/asm/dma-mapping.h:16:28:
note: previous declaration of 'dma_ops' was here

Signed-off-by: Julien Grall 

diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
index ddea134..c341603 100644
--- a/sound/soc/samsung/dma.c
+++ b/sound/soc/samsung/dma.c
@@ -342,7 +342,7 @@ static int dma_mmap(struct snd_pcm_substream *substream,
 runtime->dma_bytes);
 }
 
-static struct snd_pcm_ops dma_ops = {
+static struct snd_pcm_ops samsung_dma_ops = {
.open   = dma_open,
.close  = dma_close,
.ioctl  = snd_pcm_lib_ioctl,
@@ -429,7 +429,7 @@ out:
 }
 
 static struct snd_soc_platform_driver samsung_asoc_platform = {
-   .ops= _ops,
+   .ops= _dma_ops,
.pcm_new= dma_new,
.pcm_free   = dma_free_dma_buffers,
 };

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

[Ding Tianhong]

于 2013/9/2 2:35, Hannes Frederic Sowa 写道:

On Fri, Aug 30, 2013 at 05:02:38PM +0200, Petr Holasek wrote:

This two-liner removes max_addresses variable which is now unecessary related
to patch [ipv6: remove max_addresses check from ipv6_create_tempaddr].

Signed-off-by: Petr Holasek 

Uh, yes, I missed that. Thanks a lot!

Acked-by: Hannes Frederic Sowa 


Acked-by: Ding Tianhong 

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



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

RE: linux-next: build failure after merge of the final tree (drm tree related)

[Deucher, Alexander]

> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Monday, September 02, 2013 5:01 AM
> To: Dave Airlie
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
> Alexander
> Subject: linux-next: build failure after merge of the final tree (drm tree
> related)
> 
> Hi all,
> 
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/gpu/drm/radeon/ci_dpm.c: In function
> 'ci_request_link_speed_change_before_state_change':
> drivers/gpu/drm/radeon/ci_dpm.c:4212:4: error: implicit declaration of
> function 'radeon_acpi_pcie_performance_request' [-Werror=implicit-
> function-declaration]
> if (radeon_acpi_pcie_performance_request(rdev,
> PCIE_PERF_REQ_PECI_GEN3, false) == 0)
> ^
> 
> Caused by commit cc8dbbb4f62a ("drm/radeon: add dpm support for CI
> dGPUs
> (v2)").  These calls need protecting with CONFIG_ACPI (like is done in
> cypress_dpm.c, I guess).
> 
> I tried reverting commit 9c725e5bcdae ("Merge branch 'drm-next-3.12' of
> git://people.freedesktop.org/~agd5f/linux into drm-next") but that failed
> because that branch is based on v3.11-rc7 (!) which is later than the
> base of the drm tree (v3.11-rc3).  :-(
> 
> I added this fix up patch for today (it may be wrong, butfixes the build
> failure).
> 
> From: Stephen Rothwell 
> Date: Mon, 2 Sep 2013 18:57:41 +1000
> Subject: [PATCH] drm/radeon: protect ACPI calls with CONFIG_ACPI
> 
> Signed-off-by: Stephen Rothwell 

The patch looks fine.

Thanks,

Alex

> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c
> index 916630f..3cce533 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -4208,6 +4208,7 @@ static void
> ci_request_link_speed_change_before_state_change(struct radeon_devic
>   pi->pspp_notify_required = false;
>   if (target_link_speed > current_link_speed) {
>   switch (target_link_speed) {
> +#ifdef CONFIG_ACPI
>   case RADEON_PCIE_GEN3:
>   if (radeon_acpi_pcie_performance_request(rdev,
> PCIE_PERF_REQ_PECI_GEN3, false) == 0)
>   break;
> @@ -4217,6 +4218,7 @@ static void
> ci_request_link_speed_change_before_state_change(struct radeon_devic
>   case RADEON_PCIE_GEN2:
>   if (radeon_acpi_pcie_performance_request(rdev,
> PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>   break;
> +#endif
>   default:
>   pi->force_pcie_gen =
> ci_get_current_pcie_speed(rdev);
>   break;
> @@ -4248,7 +4250,9 @@ static void
> ci_notify_link_speed_change_after_state_change(struct radeon_device
>   (ci_get_current_pcie_speed(rdev) > 0))
>   return;
> 
> +#ifdef CONFIG_ACPI
>   radeon_acpi_pcie_performance_request(rdev, request,
> false);
> +#endif
>   }
>  }
> 
> --
> 1.8.4.rc3
> 
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.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/

[PATCH] smp: harmonize prototypes of smp functions

[Javi Merino]

Avoid unnecessary casts from int to bool in smp functions.  Some
functions in kernel/smp.c have a wait parameter that can be set to one
if you want to wait for the command to complete.  It's defined as bool
in a few of them and int in the rest.  If a function with wait
declared as int calls a function whose prototype has wait defined as
bool, the compiler needs to test if the int is != 0 and change it to 1
if so.  This useless check can be avoided if we are consistent and
make all the functions use the same type for this parameter.

For example in arm, before this patch:

800464e4 :
800464e4:   b538push{r3, r4, r5, lr}
800464e6:   460dmov r5, r1
800464e8:   4613mov r3, r2   ; move wait to r3
800464ea:   f64f 448c   movwr4, #64652
800464ee:   3300addsr3, #0   ; test if wait is 0
800464f0:   f2c8 0425   movtr4, #32805
800464f4:   4601mov r1, r0
800464f6:   bf18it  ne
800464f8:   2301movne   r3, #1   ; if it is not, wait = 1
800464fa:   462amov r2, r5
800464fc:   6820ldr r0, [r4, #0]
800464fe:   f7ff fea9   bl  80046254 
80046502:   2000movsr0, #0
80046504:   bd38pop {r3, r4, r5, pc}
80046506:   bf00nop

After the patch:

800464e4 :
800464e4:   b538push{r3, r4, r5, lr}
800464e6:   460dmov r5, r1
800464e8:   4613mov r3, r2  ; just move it to r3
800464ea:   f64f 448c   movwr4, #64652
800464ee:   4601mov r1, r0
800464f0:   f2c8 0425   movtr4, #32805
800464f4:   462amov r2, r5
800464f6:   6820ldr r0, [r4, #0]
800464f8:   f7ff feac   bl  80046254 
800464fc:   2000movsr0, #0
800464fe:   bd38pop {r3, r4, r5, pc}

Same for x86.  Before:

8109bf10 :
8109bf10:   55  push   %rbp
8109bf11:   48 89 e5mov%rsp,%rbp
8109bf14:   31 c9   xor%ecx,%ecx  ; ecx = 0
8109bf16:   85 d2   test   %edx,%edx  ; test if 
wait is 0
8109bf18:   48 89 f2mov%rsi,%rdx
8109bf1b:   48 89 femov%rdi,%rsi
8109bf1e:   48 8b 3d 4b d3 76 00mov0x76d34b(%rip),%rdi  
  # 81809270 
8109bf25:   0f 95 c1setne  %cl; if it is 
not, ecx = 1
8109bf28:   e8 43 fc ff ff  callq  8109bb70 

8109bf2d:   31 c0   xor%eax,%eax
8109bf2f:   5d  pop%rbp
8109bf30:   c3  retq

After:

8109bf20 :
8109bf20:   55  push   %rbp
8109bf21:   48 89 e5mov%rsp,%rbp
8109bf24:   89 d1   mov%edx,%ecx  ; just move 
wait to ecx
8109bf26:   48 89 f2mov%rsi,%rdx
8109bf29:   48 89 femov%rdi,%rsi
8109bf2c:   48 8b 3d 3d d3 76 00mov0x76d33d(%rip),%rdi  
  # 81809270 
8109bf33:   e8 48 fc ff ff  callq  8109bb80 

8109bf38:   31 c0   xor%eax,%eax
8109bf3a:   5d  pop%rbp
8109bf3b:   c3  retq
8109bf3c:   0f 1f 40 00 nopl   0x0(%rax)

Cc: Andrew Morton 
Signed-off-by: Javi Merino 
---
 include/linux/smp.h |6 +++---
 kernel/smp.c|6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/smp.h b/include/linux/smp.h
index c181399..a894405 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -72,7 +72,7 @@ extern void smp_cpus_done(unsigned int max_cpus);
  */
 int smp_call_function(smp_call_func_t func, void *info, int wait);
 void smp_call_function_many(const struct cpumask *mask,
-   smp_call_func_t func, void *info, bool wait);
+   smp_call_func_t func, void *info, int wait);
 
 void __smp_call_function_single(int cpuid, struct call_single_data *data,
int wait);
@@ -104,7 +104,7 @@ int on_each_cpu(smp_call_func_t func, void *info, int wait);
  * the local one.
  */
 void on_each_cpu_mask(const struct cpumask *mask, smp_call_func_t func,
-   void *info, bool wait);
+   void *info, int wait);
 
 /*
  * Call a function on each processor for which the supplied function
@@ -112,7 +112,7 @@ void on_each_cpu_mask(const struct cpumask *mask, 
smp_call_func_t func,
  * processor.
  */
 void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
-

[PATCH v2 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 io/prealloc.c |   39 ++-
 man/man8/xfs_io.8 |6 ++
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/io/prealloc.c b/io/prealloc.c
index 8380646..e7ff940 100644
--- a/io/prealloc.c
+++ b/io/prealloc.c
@@ -29,6 +29,10 @@
 #define FALLOC_FL_PUNCH_HOLE   0x02
 #endif
 
+#ifndef FALLOC_FL_COLLAPSE_RANGE
+#define FALLOC_FL_COLLAPSE_RANGE 0x08
+#endif
+
 static cmdinfo_t allocsp_cmd;
 static cmdinfo_t freesp_cmd;
 static cmdinfo_t resvsp_cmd;
@@ -37,6 +41,7 @@ static cmdinfo_t zero_cmd;
 #if defined(HAVE_FALLOCATE)
 static cmdinfo_t falloc_cmd;
 static cmdinfo_t fpunch_cmd;
+static cmdinfo_t fcollapse_cmd;
 #endif
 
 static int
@@ -159,8 +164,11 @@ fallocate_f(
int mode = 0;
int c;
 
-   while ((c = getopt(argc, argv, "kp")) != EOF) {
+   while ((c = getopt(argc, argv, "ckp")) != EOF) {
switch (c) {
+   case 'c':
+   mode = FALLOC_FL_COLLAPSE_RANGE;
+   break;
case 'k':
mode = FALLOC_FL_KEEP_SIZE;
break;
@@ -203,6 +211,25 @@ fpunch_f(
}
return 0;
 }
+
+static int
+fcollapse_f(
+   int argc,
+   char**argv)
+{
+   xfs_flock64_t   segment;
+   int mode = FALLOC_FL_COLLAPSE_RANGE;
+
+   if(!offset_length(argv[1], argv[2], ))
+   return 0;
+
+   if (fallocate(file->fd, mode,
+   segment.l_start, segment.l_len)) {
+   perror("fallocate");
+   return 0;
+   }
+   return 0;
+}
 #endif /* HAVE_FALLOCATE */
 
 void
@@ -277,5 +304,15 @@ prealloc_init(void)
fpunch_cmd.oneline =
_("de-allocates space assocated with part of a file via 
fallocate");
add_command(_cmd);
+
+   fcollapse_cmd.name = "fcollapse";
+   fcollapse_cmd.cfunc = fcollapse_f;
+   fcollapse_cmd.argmin = 2;
+   fcollapse_cmd.argmax = 2;
+   fcollapse_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
+   fcollapse_cmd.args = _("off len");
+   fcollapse_cmd.oneline =
+   _("de-allocates space and nullify the hole by shifting extents 
into it");
+   add_command(_cmd);
 #endif /* HAVE_FALLOCATE */
 }
diff --git a/man/man8/xfs_io.8 b/man/man8/xfs_io.8
index 767b50e..9543b20 100644
--- a/man/man8/xfs_io.8
+++ b/man/man8/xfs_io.8
@@ -380,6 +380,12 @@ will set the FALLOC_FL_KEEP_SIZE flag as described in
 .PD
 .RE
 .TP
+.BI fcollapse " offset length"
+Call fallocate with FALLOC_FL_COLLAPSE_RANGE flag as described in the
+.BR fallocate (2)
+manual page to de-allocates blocks and eliminates the hole created in this 
process
+by shifting data blocks into the hole.
+.TP
 .BI fpunch " offset length"
 Punches (de-allocates) blocks in the file by calling fallocate with 
 the FALLOC_FL_PUNCH_HOLE flag as described in the
-- 
1.7.9.5

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

[PATCH v2 3/7] ext4: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 fs/ext4/ext4.h  |3 +
 fs/ext4/extents.c   |  286 ++-
 fs/ext4/move_extent.c   |2 +-
 include/trace/events/ext4.h |   25 
 4 files changed, 314 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index f3c43fc..a13e0f4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2737,6 +2737,7 @@ extern int ext4_find_delalloc_cluster(struct inode 
*inode, ext4_lblk_t lblk);
 extern int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
__u64 start, __u64 len);
 extern int ext4_ext_precache(struct inode *inode);
+extern int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len);
 
 /* move_extent.c */
 extern void ext4_double_down_write_data_sem(struct inode *first,
@@ -2748,6 +2749,8 @@ void ext4_inode_double_unlock(struct inode *inode1, 
struct inode *inode2);
 extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
 __u64 start_orig, __u64 start_donor,
 __u64 len, __u64 *moved_len);
+extern int mext_next_extent(struct inode *inode, struct ext4_ext_path *path,
+   struct ext4_extent **extent);
 
 /* page-io.c */
 extern int __init ext4_init_pageio(void);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 54d52af..baf1faf 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4580,12 +4580,16 @@ long ext4_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
unsigned int credits, blkbits = inode->i_blkbits;
 
/* Return error if mode is not supported */
-   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
 
if (mode & FALLOC_FL_PUNCH_HOLE)
return ext4_punch_hole(inode, offset, len);
 
+   if (mode & FALLOC_FL_COLLAPSE_RANGE)
+   return ext4_collapse_range(inode, offset, len);
+
ret = ext4_convert_inline_data(inode);
if (ret)
return ret;
@@ -4884,3 +4888,283 @@ int ext4_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
ext4_es_lru_add(inode);
return error;
 }
+
+/*
+ * ext4_access_path:
+ * Function to access the path buffer for marking it dirty.
+ * It also checks if there are sufficient credits left in the journal handle
+ * to update path.
+ */
+static int
+ext4_access_path(handle_t *handle, struct inode *inode,
+   struct ext4_ext_path *path)
+{
+   int credits, err;
+
+   /*
+* Check if need to extend journal credits
+* 3 for leaf, sb, and inode plus 2 (bmap and group
+* descriptor) for each block group; assume two block
+* groups
+*/
+   if (handle->h_buffer_credits < 7) {
+   credits = ext4_writepage_trans_blocks(inode);
+   err = ext4_ext_truncate_extend_restart(handle, inode, credits);
+   /* EAGAIN is success */
+   if (err && err != -EAGAIN)
+   return err;
+   }
+
+   err = ext4_ext_get_access(handle, inode, path);
+   return err;
+}
+
+/*
+ * ext4_ext_shift_path_extents:
+ * Shift the extents of a path structure lying between path[depth].p_ext
+ * and EXT_LAST_EXTENT(path[depth].p_hdr) downwards, by subtracting shift
+ * from starting block for each extent.
+ */
+static int
+ext4_ext_shift_path_extents(struct ext4_ext_path *path, ext4_lblk_t shift,
+   struct inode *inode, handle_t *handle,
+   ext4_lblk_t *start)
+{
+   int depth, err = 0;
+   struct ext4_extent *ex_start, *ex_last;
+   bool update = 0;
+   depth = path->p_depth;
+
+   while (depth >= 0) {
+   if (depth == path->p_depth) {
+   ex_start = path[depth].p_ext;
+   if (!ex_start)
+   return -EIO;
+
+   ex_last = EXT_LAST_EXTENT(path[depth].p_hdr);
+   if (!ex_last)
+   return -EIO;
+
+   err = ext4_access_path(handle, inode, path + depth);
+   if (err)
+   goto out;
+
+   if (ex_start == EXT_FIRST_EXTENT(path[depth].p_hdr))
+   update = 1;
+
+   *start = ex_last->ee_block +
+   ext4_ext_get_actual_len(ex_last);
+
+   while (ex_start <= ex_last) {
+   ex_start->ee_block -= shift;
+   ext4_ext_try_to_merge(handle, inode,
+   path, 

[PATCH v2 7/7] manpage: update FALLOC_FL_COLLAPSE_RANGE flag in fallocate

[Namjae Jeon]

From: Namjae Jeon 

Update FALLOC_FL_COLLAPSE_RANGE flag in fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 man2/fallocate.2 |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/man2/fallocate.2 b/man2/fallocate.2
index f5c395d..b042c59 100644
--- a/man2/fallocate.2
+++ b/man2/fallocate.2
@@ -7,6 +7,7 @@
 .\"
 .\" 2011-09-19: Added FALLOC_FL_PUNCH_HOLE
 .\" 2011-09-19: Substantial restructuring of the page
+.\" 2013-09-01: Added FALLOC_FL_COLLAPSE_RANGE
 .\"
 .TH FALLOCATE 2 2013-06-10 "Linux" "Linux Programmer's Manual"
 .SH NAME
@@ -109,6 +110,19 @@ does not change.
 Not all filesystems support
 .BR FALLOC_FL_PUNCH_HOLE ;
 if a filesystem doesn't support the operation, an error is returned.
+.SS Collapsing file space
+Specifiying the
+.BR FALLOC_FL_COLLAPSE_RANGE
+flag in
+.I mode
+collpse space in the byte range starting at
+.I offset
+and continuing for
+.I len
+bytes, where the offset and len are aligned with block size of filesystem.
+Within the specified range, it first de-allocates blocks and eliminates
+the hole created in this process by shifting data blocks into the hole.
+
 .SH RETURN VALUE
 On success,
 .BR fallocate ()
@@ -139,7 +153,8 @@ was less than 0, or
 .\" See "Re: [PATCH] fallocate.2: add FALLOC_FL_PUNCH_HOLE flag definition"
 .\" 21 Sep 2012
 .\" http://thread.gmane.org/gmane.linux.file-systems/48331/focus=1193526
-was less than or equal to 0.
+was less than or equal to 0 or in case of FALLOC_FL_COLLAPSE_RANGE
+offset and len are not aligned with file system's block size.
 .TP
 .B EIO
 An I/O error occurred while reading from or writing to a filesystem.
-- 
1.7.9.5

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

[PATCH v2 6/7] xfstest: Add test case to test multiple collapse range call

[Namjae Jeon]

From: Namjae Jeon 

We execute collapse range multiple times on same file.
Each collapse range call collapses a single alternate block.
After the test execution, file will be left with 80 blocks and
as much number of extents.
We also check for file system consistency after the completion.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 tests/shared/317 |   96 ++
 tests/shared/317.out |   85 
 tests/shared/group   |1 +
 3 files changed, 182 insertions(+)
 create mode 100644 tests/shared/317
 create mode 100644 tests/shared/317.out

diff --git a/tests/shared/317 b/tests/shared/317
new file mode 100644
index 000..1d7c384
--- /dev/null
+++ b/tests/shared/317
@@ -0,0 +1,96 @@
+#! /bin/bash
+# FS QA Test No. 317
+#
+# Test multiple fallocate collapse range calls
+#
+#---
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs xfs ext4
+_supported_os Linux
+
+_require_scratch
+_require_xfs_io_fiemap
+_require_xfs_io_falloc_collapse
+_do_die_on_error=y
+test=$SCRATCH_MNT/test
+testfile=$SCRATCH_MNT/317.$$
+BSIZE=4096
+BLOCKS=10240
+
+# Filters fiemap output
+_filter_fiemap()
+{
+   awk --posix '
+   $3 ~ /hole/ {
+   print $1, $2, $3; 
+   next;
+   }   
+   $5 ~ /0x[[:xdigit:]]+/ {
+   print $1, $2, "extent";
+   }'
+}
+
+case $FSTYP in
+   ext4)
+   export MKFS_OPTIONS="-F -b $BSIZE"
+   ;;
+   xfs)
+   export MKFS_OPTIONS="-f -b size=$BSIZE"
+   ;;
+esac
+
+# make filesystem on scratch with 4KB blocksize
+_do 'make filesystem on $SCRATCH_DEV' '_scratch_mkfs'
+_do 'mount filesytem' '_scratch_mount'
+
+# Write file
+length=$(($BLOCKS*$BSIZE))
+$XFS_IO_PROG -f -c "pwrite 0 $length" -c fsync $testfile > /dev/null
+
+# Collapse alternate blocks 
+for (( i = 1; i <= 7; i++ )); do
+   for(( j=0 ; j < $(($BLOCKS/(2**$i))) ; j++ )); do
+   offset=$(($j*$BSIZE))
+   $XFS_IO_PROG -c "fcollapse $offset $BSIZE" $testfile > /dev/null
+   done
+done
+
+# Check if 80 extents are present
+$XFS_IO_PROG -c "fiemap -v" $testfile | _filter_fiemap
+
+_do 'unmount $SCRATCH_DEV' 'umount $SCRATCH_DEV'
+_do 'repair filesystem' '_check_scratch_fs'
+
+# success, all done
+status=0; exit
diff --git a/tests/shared/317.out b/tests/shared/317.out
new file mode 100644
index 000..836f0fe
--- /dev/null
+++ b/tests/shared/317.out
@@ -0,0 +1,85 @@
+QA output created by 317
+make filesystem on $SCRATCH_DEV... done
+mount filesytem... done
+0: [0..7]: extent
+1: [8..15]: extent
+2: [16..23]: extent
+3: [24..31]: extent
+4: [32..39]: extent
+5: [40..47]: extent
+6: [48..55]: extent
+7: [56..63]: extent
+8: [64..71]: extent
+9: [72..79]: extent
+10: [80..87]: extent
+11: [88..95]: extent
+12: [96..103]: extent
+13: [104..111]: extent
+14: [112..119]: extent
+15: [120..127]: extent
+16: [128..135]: extent
+17: [136..143]: extent
+18: [144..151]: extent
+19: [152..159]: extent
+20: [160..167]: extent
+21: [168..175]: extent
+22: [176..183]: extent
+23: [184..191]: extent
+24: [192..199]: extent
+25: [200..207]: extent
+26: [208..215]: extent
+27: [216..223]: extent
+28: [224..231]: extent
+29: [232..239]: extent
+30: [240..247]: extent
+31: [248..255]: extent
+32: [256..263]: extent
+33: [264..271]: extent
+34: [272..279]: extent
+35: [280..287]: extent
+36: [288..295]: extent
+37: [296..303]: extent
+38: [304..311]: extent
+39: [312..319]: extent
+40: [320..327]: extent
+41: [328..335]: extent
+42: [336..343]: extent
+43: [344..351]: extent
+44: [352..359]: extent
+45: [360..367]: extent
+46: [368..375]: extent
+47: [376..383]: extent
+48: [384..391]: extent
+49: [392..399]: extent
+50: [400..407]: extent
+51: [408..415]: extent

[PATCH v2 5/7] xfstest: Add test case to check various corner cases for collapsing range

[Namjae Jeon]

From: Namjae Jeon 

This patch checks various corner cases for collapsing a range.
This patch is based on generic/255 test case which checks various corner
cases for punch hole.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 common/collapse  |  264 ++
 common/rc|   14 +++
 tests/shared/316 |   70 +
 tests/shared/316.out |  221 ++
 tests/shared/group   |2 +-
 5 files changed, 570 insertions(+), 1 deletion(-)
 create mode 100644 common/collapse
 create mode 100644 tests/shared/316
 create mode 100644 tests/shared/316.out

diff --git a/common/collapse b/common/collapse
new file mode 100644
index 000..dd3be5e
--- /dev/null
+++ b/common/collapse
@@ -0,0 +1,264 @@
+##/bin/bash
+#
+# Copyright (c) 2013 Samsung Electronics.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+# Test procedure for checking collapse range feature
+
+# Test different corner cases for collapsing a range:
+#
+#  1. into a hole
+#  2. into allocated space
+#  3. into unwritten space
+#  4. hole -> data
+#  5. hole -> unwritten
+#  6. data -> hole
+#  7. data -> unwritten
+#  8. unwritten -> hole
+#  9. unwritten -> data
+#  10. hole -> data -> hole
+#  11. data -> hole -> data
+#  12. unwritten -> data -> unwritten
+#  13. data -> unwritten -> data
+#  14. data -> hole @ EOF
+#  15. data -> hole @ 0
+#  16. data -> cache cold ->hole
+#
+# Test file is removed, created and sync'd between tests.
+#
+# Use -k flag to keep the file between tests.  This will
+# test the handling of pre-existing holes.
+#
+# Use the -d flag to not sync the file between tests.
+# This will test the handling of delayed extents
+#
+_test_generic_collapse()
+{
+
+   remove_testfile=1
+   sync_cmd="-c fsync"
+   OPTIND=1
+   while getopts 'dk' OPTION
+   do
+   case $OPTION in
+   k)  remove_testfile=
+   ;;
+   d)  sync_cmd=
+   ;;
+   ?)  echo Invalid flag
+   exit 1
+   ;;
+   esac
+   done
+   shift $(($OPTIND - 1))
+
+   alloc_cmd=$1
+   collapse_cmd=$2
+   punch_cmd=$3
+   map_cmd=$4
+   filter_cmd=$5
+   testfile=$6
+
+   echo "  1. into a hole"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+   -c "$collapse_cmd 16k 32k" \
+   -c "$map_cmd -v" $testfile | $filter_cmd
+   [ $? -ne 0 ] && die_now
+   _md5_checksum $testfile
+
+   echo "  2. into allocated space"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+   -c "pwrite 0 80k" $sync_cmd \
+   -c "$collapse_cmd 16k 32k" \
+   -c "$map_cmd -v" $testfile | $filter_cmd
+   [ $? -ne 0 ] && die_now
+   _md5_checksum $testfile
+
+   echo "  3. into unwritten space"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+   -c "$alloc_cmd 0 80k" \
+   -c "$collapse_cmd 16k 32k" \
+   -c "$map_cmd -v" $testfile | $filter_cmd
+   [ $? -ne 0 ] && die_now
+   _md5_checksum $testfile
+
+   echo "  4. hole -> data"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+   -c "pwrite 32k 32k" $sync_cmd \
+   -c "$collapse_cmd 16k 32k" \
+   -c "$map_cmd -v" $testfile | $filter_cmd
+   [ $? -ne 0 ] && die_now
+   _md5_checksum $testfile
+
+   echo "  5. hole -> unwritten"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+   -c "$alloc_cmd 32k 32k" \
+   -c "$collapse_cmd 16k 32k" \
+   -c "$map_cmd -v" $testfile | $filter_cmd
+   [ $? -ne 0 ] && die_now
+   _md5_checksum $testfile
+
+   echo "  6. data -> hole"
+   if [ "$remove_testfile" ]; then
+   rm -f $testfile
+   fi
+   $XFS_IO_PROG -f -c "truncate 80k" \
+

[PATCH v4 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 io/prealloc.c |   39 ++-
 man/man8/xfs_io.8 |6 ++
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/io/prealloc.c b/io/prealloc.c
index 8380646..e7ff940 100644
--- a/io/prealloc.c
+++ b/io/prealloc.c
@@ -29,6 +29,10 @@
 #define FALLOC_FL_PUNCH_HOLE   0x02
 #endif
 
+#ifndef FALLOC_FL_COLLAPSE_RANGE
+#define FALLOC_FL_COLLAPSE_RANGE 0x08
+#endif
+
 static cmdinfo_t allocsp_cmd;
 static cmdinfo_t freesp_cmd;
 static cmdinfo_t resvsp_cmd;
@@ -37,6 +41,7 @@ static cmdinfo_t zero_cmd;
 #if defined(HAVE_FALLOCATE)
 static cmdinfo_t falloc_cmd;
 static cmdinfo_t fpunch_cmd;
+static cmdinfo_t fcollapse_cmd;
 #endif
 
 static int
@@ -159,8 +164,11 @@ fallocate_f(
int mode = 0;
int c;
 
-   while ((c = getopt(argc, argv, "kp")) != EOF) {
+   while ((c = getopt(argc, argv, "ckp")) != EOF) {
switch (c) {
+   case 'c':
+   mode = FALLOC_FL_COLLAPSE_RANGE;
+   break;
case 'k':
mode = FALLOC_FL_KEEP_SIZE;
break;
@@ -203,6 +211,25 @@ fpunch_f(
}
return 0;
 }
+
+static int
+fcollapse_f(
+   int argc,
+   char**argv)
+{
+   xfs_flock64_t   segment;
+   int mode = FALLOC_FL_COLLAPSE_RANGE;
+
+   if(!offset_length(argv[1], argv[2], ))
+   return 0;
+
+   if (fallocate(file->fd, mode,
+   segment.l_start, segment.l_len)) {
+   perror("fallocate");
+   return 0;
+   }
+   return 0;
+}
 #endif /* HAVE_FALLOCATE */
 
 void
@@ -277,5 +304,15 @@ prealloc_init(void)
fpunch_cmd.oneline =
_("de-allocates space assocated with part of a file via 
fallocate");
add_command(_cmd);
+
+   fcollapse_cmd.name = "fcollapse";
+   fcollapse_cmd.cfunc = fcollapse_f;
+   fcollapse_cmd.argmin = 2;
+   fcollapse_cmd.argmax = 2;
+   fcollapse_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
+   fcollapse_cmd.args = _("off len");
+   fcollapse_cmd.oneline =
+   _("de-allocates space and nullify the hole by shifting extents 
into it");
+   add_command(_cmd);
 #endif /* HAVE_FALLOCATE */
 }
diff --git a/man/man8/xfs_io.8 b/man/man8/xfs_io.8
index 767b50e..9543b20 100644
--- a/man/man8/xfs_io.8
+++ b/man/man8/xfs_io.8
@@ -380,6 +380,12 @@ will set the FALLOC_FL_KEEP_SIZE flag as described in
 .PD
 .RE
 .TP
+.BI fcollapse " offset length"
+Call fallocate with FALLOC_FL_COLLAPSE_RANGE flag as described in the
+.BR fallocate (2)
+manual page to de-allocates blocks and eliminates the hole created in this 
process
+by shifting data blocks into the hole.
+.TP
 .BI fpunch " offset length"
 Punches (de-allocates) blocks in the file by calling fallocate with 
 the FALLOC_FL_PUNCH_HOLE flag as described in the
-- 
1.7.9.5

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

[PATCH v3 3/7] ext4: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 fs/ext4/ext4.h  |3 +
 fs/ext4/extents.c   |  286 ++-
 fs/ext4/move_extent.c   |2 +-
 include/trace/events/ext4.h |   25 
 4 files changed, 314 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index f3c43fc..a13e0f4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2737,6 +2737,7 @@ extern int ext4_find_delalloc_cluster(struct inode 
*inode, ext4_lblk_t lblk);
 extern int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
__u64 start, __u64 len);
 extern int ext4_ext_precache(struct inode *inode);
+extern int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len);
 
 /* move_extent.c */
 extern void ext4_double_down_write_data_sem(struct inode *first,
@@ -2748,6 +2749,8 @@ void ext4_inode_double_unlock(struct inode *inode1, 
struct inode *inode2);
 extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
 __u64 start_orig, __u64 start_donor,
 __u64 len, __u64 *moved_len);
+extern int mext_next_extent(struct inode *inode, struct ext4_ext_path *path,
+   struct ext4_extent **extent);
 
 /* page-io.c */
 extern int __init ext4_init_pageio(void);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 54d52af..baf1faf 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4580,12 +4580,16 @@ long ext4_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
unsigned int credits, blkbits = inode->i_blkbits;
 
/* Return error if mode is not supported */
-   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
 
if (mode & FALLOC_FL_PUNCH_HOLE)
return ext4_punch_hole(inode, offset, len);
 
+   if (mode & FALLOC_FL_COLLAPSE_RANGE)
+   return ext4_collapse_range(inode, offset, len);
+
ret = ext4_convert_inline_data(inode);
if (ret)
return ret;
@@ -4884,3 +4888,283 @@ int ext4_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
ext4_es_lru_add(inode);
return error;
 }
+
+/*
+ * ext4_access_path:
+ * Function to access the path buffer for marking it dirty.
+ * It also checks if there are sufficient credits left in the journal handle
+ * to update path.
+ */
+static int
+ext4_access_path(handle_t *handle, struct inode *inode,
+   struct ext4_ext_path *path)
+{
+   int credits, err;
+
+   /*
+* Check if need to extend journal credits
+* 3 for leaf, sb, and inode plus 2 (bmap and group
+* descriptor) for each block group; assume two block
+* groups
+*/
+   if (handle->h_buffer_credits < 7) {
+   credits = ext4_writepage_trans_blocks(inode);
+   err = ext4_ext_truncate_extend_restart(handle, inode, credits);
+   /* EAGAIN is success */
+   if (err && err != -EAGAIN)
+   return err;
+   }
+
+   err = ext4_ext_get_access(handle, inode, path);
+   return err;
+}
+
+/*
+ * ext4_ext_shift_path_extents:
+ * Shift the extents of a path structure lying between path[depth].p_ext
+ * and EXT_LAST_EXTENT(path[depth].p_hdr) downwards, by subtracting shift
+ * from starting block for each extent.
+ */
+static int
+ext4_ext_shift_path_extents(struct ext4_ext_path *path, ext4_lblk_t shift,
+   struct inode *inode, handle_t *handle,
+   ext4_lblk_t *start)
+{
+   int depth, err = 0;
+   struct ext4_extent *ex_start, *ex_last;
+   bool update = 0;
+   depth = path->p_depth;
+
+   while (depth >= 0) {
+   if (depth == path->p_depth) {
+   ex_start = path[depth].p_ext;
+   if (!ex_start)
+   return -EIO;
+
+   ex_last = EXT_LAST_EXTENT(path[depth].p_hdr);
+   if (!ex_last)
+   return -EIO;
+
+   err = ext4_access_path(handle, inode, path + depth);
+   if (err)
+   goto out;
+
+   if (ex_start == EXT_FIRST_EXTENT(path[depth].p_hdr))
+   update = 1;
+
+   *start = ex_last->ee_block +
+   ext4_ext_get_actual_len(ex_last);
+
+   while (ex_start <= ex_last) {
+   ex_start->ee_block -= shift;
+   ext4_ext_try_to_merge(handle, inode,
+   path, 

[PATCH v2 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 fs/xfs/xfs_bmap.c  |  174 
 fs/xfs/xfs_bmap.h  |3 +
 fs/xfs/xfs_bmap_util.c |   96 ++
 fs/xfs/xfs_bmap_util.h |2 +
 fs/xfs/xfs_file.c  |   20 --
 fs/xfs/xfs_fs.h|6 ++
 6 files changed, 296 insertions(+), 5 deletions(-)

diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c
index 92b8309..c12358e 100644
--- a/fs/xfs/xfs_bmap.c
+++ b/fs/xfs/xfs_bmap.c
@@ -5356,3 +5356,177 @@ error0:
}
return error;
 }
+
+/*
+ * Update extents by shifting them downwards into a hole.
+ * At max count number of extents will be shifted and *current_ext
+ * is the extent number which is currently being shifted.
+ * This function will return error if the hole is not present
+ * while shifting extents. On success, 0 is returned.
+ */
+int
+xfs_bmap_shift_extents(
+   struct xfs_trans*tp,
+   struct xfs_inode*ip,
+   int *done,
+   xfs_fileoff_t   start_fsb,
+   xfs_fileoff_t   shift,
+   xfs_extnum_t*current_ext,
+   xfs_fsblock_t   *firstblock,
+   struct xfs_bmap_free*flist,
+   int count)
+{
+   struct xfs_btree_cur*cur;
+   struct xfs_bmbt_rec_host*gotp;
+   struct xfs_bmbt_irecleft;
+   struct xfs_mount*mp = ip->i_mount;
+   struct xfs_ifork*ifp;
+   xfs_extnum_tnexts = 0;
+   xfs_fileoff_t   startoff;
+   int error = 0;
+   int i;
+   int whichfork = XFS_DATA_FORK;
+   int state;
+   int logflags;
+   xfs_filblks_t   blockcount = 0;
+
+   if (unlikely(XFS_TEST_ERROR(
+   (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_EXTENTS &&
+XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_BTREE),
+mp, XFS_ERRTAG_BMAPIFORMAT, XFS_RANDOM_BMAPIFORMAT))) {
+   XFS_ERROR_REPORT("xfs_bmap_shift_extents",
+XFS_ERRLEVEL_LOW, mp);
+   return XFS_ERROR(EFSCORRUPTED);
+   }
+
+   if (XFS_FORCED_SHUTDOWN(mp))
+   return XFS_ERROR(EIO);
+
+   ifp = XFS_IFORK_PTR(ip, whichfork);
+
+   if (!(ifp->if_flags & XFS_IFEXTENTS)) {
+   /* Read in all the extents */
+   error = xfs_iread_extents(tp, ip, whichfork);
+   if (error)
+   return error;
+   }
+
+   if (!*current_ext) {
+   gotp = xfs_iext_bno_to_ext(ifp, start_fsb, current_ext);
+   /*
+* gotp can be null in 2 cases: 1) if there are no extents
+* or 2) start_fsb lies in a hole beyond which there are
+* no extents. Either way, we are done.
+*/
+   if (!gotp) {
+   *done = 1;
+   return 0;
+   }
+   }
+
+   /* We are going to change core inode */
+   logflags = XFS_ILOG_CORE;
+
+   if (ifp->if_flags & XFS_IFBROOT) {
+   cur = xfs_bmbt_init_cursor(mp, tp, ip, whichfork);
+   cur->bc_private.b.firstblock = *firstblock;
+   cur->bc_private.b.flist = flist;
+   cur->bc_private.b.flags = 0;
+   }
+   else {
+   cur = NULL;
+   logflags |= XFS_ILOG_DEXT;
+   }
+
+   while (nexts++ < count &&
+  *current_ext <  XFS_IFORK_NEXTENTS(ip, whichfork)) {
+   state = 0;
+
+   gotp = xfs_iext_get_ext(ifp, *current_ext);
+   startoff = xfs_bmbt_get_startoff(gotp);
+   startoff -= shift;
+
+   /*
+* Before shifting extent into hole, make sure that the hole
+* is large enough to accomodate the shift.
+*/
+   if (*current_ext) {
+   state |= BMAP_LEFT_VALID;
+   xfs_bmbt_get_all(xfs_iext_get_ext(ifp,
+   *current_ext - 1), );
+
+   if (isnullstartblock(left.br_startblock))
+   state |= BMAP_LEFT_DELAY;
+
+   if (startoff < left.br_startoff + left.br_blockcount)
+   error = XFS_ERROR(EFSCORRUPTED);
+
+   } else if (startoff > xfs_bmbt_get_startoff(gotp))
+   /* Hole is at the start but not large enough */
+   error = XFS_ERROR(EFSCORRUPTED);
+
+   if (error)
+   goto del_cursor;
+
+   /* 

[PATCH v2 1/7] fs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate

[Namjae Jeon]

From: Namjae Jeon 

Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate.
updated detailed semantics in comments.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 fs/open.c   |   24 +---
 include/uapi/linux/falloc.h |   17 +
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/fs/open.c b/fs/open.c
index 7931f76..85d243a 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -225,12 +225,14 @@ int do_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
 {
struct inode *inode = file_inode(file);
long ret;
+   unsigned blksize_mask = (1 << inode->i_blkbits) - 1;
 
if (offset < 0 || len <= 0)
return -EINVAL;
 
/* Return error if mode is not supported */
-   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
 
/* Punch hole must have keep size set */
@@ -241,8 +243,12 @@ int do_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
if (!(file->f_mode & FMODE_WRITE))
return -EBADF;
 
-   /* It's not possible punch hole on append only file */
-   if (mode & FALLOC_FL_PUNCH_HOLE && IS_APPEND(inode))
+   /*
+* It's not possible to punch hole or perform collapse range
+* on append only file
+*/
+   if (mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_COLLAPSE_RANGE)
+   && IS_APPEND(inode))
return -EPERM;
 
if (IS_IMMUTABLE(inode))
@@ -270,6 +276,18 @@ int do_fallocate(struct file *file, int mode, loff_t 
offset, loff_t len)
if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0))
return -EFBIG;
 
+   /*
+* Collapse range works only on fs block size aligned offsets.
+* Check if collapse range is contained within (aligned)i_size.
+* Collapse range can only be used exclusively.
+*/
+   if ((mode & FALLOC_FL_COLLAPSE_RANGE) &&
+   (offset & blksize_mask || len & blksize_mask ||
+mode & ~FALLOC_FL_COLLAPSE_RANGE ||
+(offset + len >
+ round_up(i_size_read(inode), (blksize_mask + 1)
+   return -EINVAL;
+
if (!file->f_op->fallocate)
return -EOPNOTSUPP;
 
diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h
index 990c4cc..9614b72 100644
--- a/include/uapi/linux/falloc.h
+++ b/include/uapi/linux/falloc.h
@@ -4,6 +4,23 @@
 #define FALLOC_FL_KEEP_SIZE0x01 /* default is extend size */
 #define FALLOC_FL_PUNCH_HOLE   0x02 /* de-allocates range */
 #define FALLOC_FL_NO_HIDE_STALE0x04 /* reserved codepoint */
+/*
+ * FALLOC_FL_COLLAPSE_RANGE:
+ * This flag works in 2 steps.
+ * Firstly, it deallocates any data blocks present between [offset, offset+len)
+ * This step is same as punch hole and leaves a hole in the place from where
+ * the blocks are removed.
+ * Next, it eliminates the hole created by moving data blocks into it.
+ * For extent based file systems, we achieve this functionality simply by
+ * updating the starting logical offset of each extent which appears beyond
+ * the hole. As this flag works on blocks of filesystem, the offset and len
+ * provided to fallocate should be aligned with block size of filesystem.
+ * The semantics of this flag are:
+ * 1) It should be used exclusively. No other fallocate flag in combination.
+ * 2) Offset and len supplied to fallocate should be aligned with block size.
+ * 3) (offset + len) could not be greater than file size.
+ */
+#define FALLOC_FL_COLLAPSE_RANGE   0x08 /* it does not leave a hole */
 
 
 #endif /* _UAPI_FALLOC_H_ */
-- 
1.7.9.5

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

[PATCH v2 0/7] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate

[Namjae Jeon]

From: Namjae Jeon 

This patch series is in response of the following post:
http://lwn.net/Articles/556136/
"ext4: introduce two new ioctls"

Dave chinner suggested that truncate_block_range (which was one of the ioctls 
name)
should be an fallocate operation and not any fs specific ioctl, hence
we add this functionality to fallocate.

This patch series introduces new flag FALLOC_FL_COLLAPSE_RANGE for fallocate
and implements it for XFS and Ext4.

The semantics of this flag are following:
1) It collapses the range lying between offset and length by removing any data
   blocks which are present in this range and than updates all the logical
   offsets of extents beyond "offset + len" to nullify the hole created by
   removing blocks. In short, it does not leave a hole.
2) It should be used exclusively. No other fallocate flag in combination.
3) Offset and length supplied to fallocate should be fs block size aligned.

This new functionality of collapsing range could be used by media editing tools
which does non linear editing to quickly purge and edit parts of a media file.
This will immensely improve the performance of these operations.
The limitation of fs block size aligned offsets can be easily handled
by media codecs which are encapsulated in a conatiner as they have to
just change the offset to next keyframe value to match the proper alignment.

Change log
v2:
 Fix review points from Dave Chinner.
  - merge adjacent extents
  - fix journal log usage.
  - change reasonable function name.
  - update xfsio, xfstest, manpage
  - etc.

Namjae Jeon (7):
  fs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
  xfs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
  ext4: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
  xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
  xfstest: Add test case to check various corner cases for collapsing range
  xfstest: Add test case to test multiple collapse range call
  manpage: update FALLOC_FL_COLLAPSE_RANGE flag in fallocate

-- 
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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Sergey Senozhatsky]

On (09/02/13 16:13), Frederic Weisbecker wrote:
> > On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > > > Hope this may help.
> > > > I've added a silly check to make sure that `stime < rtime'
> > > > 
> > > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime 
> > > > *curr,
> > > > if (total) {
> > > > stime = scale_stime((__force u64)stime,
> > > > (__force u64)rtime, (__force 
> > > > u64)total);
> > > > +   if (stime > rtime) {
> > > > +   printk(KERN_ERR "Ooops: stime:%llu 
> > > > rtime:%llu\n", stime, rtime);
> > > > +   WARN_ON(1);
> > > > +   }
> > > > utime = rtime - stime;
> > > > } else {
> > > > stime = rtime;
> > [snip]
> > 
> > > Thanks a lot Sergey for testing this further!
> > > 
> > > Interesting results, so rtime is always one or two units off stime after 
> > > scaling.
> > > Stanislaw made the scaling code with Linus and he has a better idea on 
> > > the math guts
> > > here.
> > 
> > I don't think this is scale issue, but rather at scale_stime() input
> > stime is already bigger then rtime. Sergey, could you verify that
> > by adding check before scale_stime() ?
> 
> Note that having stime > rtime should be fine to handle. This can happen for
> example if the task runs on tiny timeslices but is unlucky enough that all 
> these
> timeslices are interrupted by the tick.
>

even is stime > rtime, scale_stime() fixes it:

if (stime > rtime)
swap(rtime, stime);

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

[PATCH RFC 5/6] ARM: dts: AM335x: prcm node (for reset)

[Afzal Mohammed]

Add AM335x prcm node with reset binding.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4701e3c..c2ccf94 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,6 +530,12 @@
#size-cells = <1>;
status = "disabled";
};
+
+   prcm: prcm@44e0 {
+   compatible = "ti,am3352-prcm";
+   reg = <0x44e0 0x1300>;
+   #reset-cells = <1>;
+   };
};
 
clocks {
-- 
1.8.3.4

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

[PATCH RFC 6/6] ARM: dts: AM4372: prcm node (for reset)

[Afzal Mohammed]

Add AM4372 prcm node with reset binding.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/boot/dts/am4372.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a68fde..d0d11b3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -411,6 +411,12 @@
ti,hwmods = "epwmss5";
status = "disabled";
};
+
+   prcm: prcm@44df {
+   compatible = "ti,am4372-prcm";
+   reg = <0x44df 0xa000>;
+   #reset-cells = <1>;
+   };
};
 
clocks {
-- 
1.8.3.4

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

[PATCH RFC 4/6] ARM: OMAP2+: AM43x/AM335x: have reset controller

[Afzal Mohammed]

AM43x, AM335x have reset block as part of prcm, let reset driver be
usable with these SoC's.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3eed000..fa28d1d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -72,6 +72,7 @@ config SOC_AM33XX
select CPU_V7
select MULTI_IRQ_HANDLER
select COMMON_CLK
+   select ARCH_HAS_RESET_CONTROLLER
 
 config SOC_AM43XX
bool "TI AM43x"
@@ -82,6 +83,7 @@ config SOC_AM43XX
select ARM_GIC
select COMMON_CLK
select MACH_OMAP_GENERIC
+   select ARCH_HAS_RESET_CONTROLLER
 
 config ARCH_OMAP2PLUS
bool
-- 
1.8.3.4

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

[PATCH RFC 3/6] reset: am43x/am335x support

[Afzal Mohammed]

Driver to handle reset block in prcm of AM43x, AM335x SoC's. There are
three reset's that can be handled by this reset driver - gfx, m3 and
pruss. Of this only gfx has been handled here, adding support for the
remaining only require adding array entries with details of pruss and
m3.

Signed-off-by: Afzal Mohammed 
---
 drivers/reset/Kconfig  |  14 
 drivers/reset/Makefile |   1 +
 drivers/reset/amx3_reset.c | 157 +
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/reset/amx3_reset.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..2af81b9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,17 @@ menuconfig RESET_CONTROLLER
  via GPIOs or SoC-internal reset controller modules.
 
  If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_AMX3
+   bool "AMx3 reset controller"
+   help
+ Reset controller support for AM43x/AM335x SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x
+
+ If unsure, say no.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b8c1afe 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_AMX3) += amx3_reset.o
diff --git a/drivers/reset/amx3_reset.c b/drivers/reset/amx3_reset.c
new file mode 100644
index 000..4e476a5
--- /dev/null
+++ b/drivers/reset/amx3_reset.c
@@ -0,0 +1,157 @@
+/*
+ * PRCM reset driver for AM335x & AM43x SoC's
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "amx3_reset"
+
+struct amx3_reset_reg_data {
+   u32 rstctrl_offs;
+   u32 rstst_offs;
+   u8  rstctrl_bit;
+   u8  rstst_bit;
+};
+
+struct amx3_reset_data {
+   struct  amx3_reset_reg_data *reg_data;
+   u8  nr_resets;
+};
+
+static void __iomem *reg_base;
+static const struct amx3_reset_data *amx3_reset_data;
+
+static struct amx3_reset_reg_data am335x_reset_reg_data[] = {
+   {
+   .rstctrl_offs   = 0x1104,
+   .rstst_offs = 0x1114,
+   .rstctrl_bit= 0,
+   .rstst_bit  = 0,
+   },
+};
+
+static struct amx3_reset_data am335x_reset_data = {
+   .reg_data   = am335x_reset_reg_data,
+   .nr_resets  = ARRAY_SIZE(am335x_reset_reg_data),
+};
+
+static struct amx3_reset_reg_data am43x_reset_reg_data[] = {
+   {
+   .rstctrl_offs   = 0x410,
+   .rstst_offs = 0x414,
+   .rstctrl_bit= 0,
+   .rstst_bit  = 0,
+   },
+};
+
+static struct amx3_reset_data am43x_reset_data = {
+   .reg_data   = am43x_reset_reg_data,
+   .nr_resets  = ARRAY_SIZE(am43x_reset_reg_data),
+};
+
+static int amx3_reset_clear_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   void __iomem *reg = amx3_reset_data->reg_data[id].rstst_offs + reg_base;
+   u8 bit = amx3_reset_data->reg_data[id].rstst_bit;
+   u32 val = readl(reg);
+
+   val &= ~(1 << bit);
+   val |= 1 << bit;
+   writel(val, reg);
+   return 0;
+}
+
+static int amx3_reset_is_reset(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   void __iomem *reg = amx3_reset_data->reg_data[id].rstst_offs + reg_base;
+   u8 bit = amx3_reset_data->reg_data[id].rstst_bit;
+   u32 val = readl(reg);
+
+   val &= (1 << bit);
+   return !!val;
+}
+
+static int amx3_reset_deassert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   void __iomem *reg = amx3_reset_data->reg_data[id].rstctrl_offs +
+   reg_base;
+   u8 bit = amx3_reset_data->reg_data[id].rstctrl_bit;
+   u32 val = readl(reg);
+
+   val &= ~(1 << bit);
+   writel(val, reg);
+   return 0;
+}
+
+static struct reset_control_ops amx3_reset_ops = {
+   .deassert = amx3_reset_deassert,
+   .is_reset = amx3_reset_is_reset,
+   .clear_reset = amx3_reset_clear_reset,
+};
+
+static struct reset_controller_dev amx3_reset_controller = {
+   .ops = _reset_ops,
+};
+
+static const struct of_device_id amx3_reset_of_match[] = {
+   { .compatible = "ti,am3352-prcm", .data = _reset_data,},
+   { .compatible = "ti,am4372-prcm", .data = _reset_data,},
+   {},
+};
+
+static int amx3_reset_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   const struct of_device_id *id;
+
+   res = platform_get_resource(pdev, 

[PATCH RFC 2/6] doc: dt: binding: omap: am43x/am335x prcm reset

[Afzal Mohammed]

prcm reset binding for AM43x/AM335x SoC's.

This was started with an attempt to add reset binding without a clear
idea on the device node where binding should appear. So a new node
with compatible "am4372-reset" to represent reset managment in prcm
was added. But finally ended up with a node to represent prcm (with
compatible "am4372-prcm") which was felt to be the natural one.

Signed-off-by: Afzal Mohammed 
---
 Documentation/devicetree/bindings/arm/omap/prcm.txt | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt 
b/Documentation/devicetree/bindings/arm/omap/prcm.txt
new file mode 100644
index 000..ad25abc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt
@@ -0,0 +1,13 @@
+TI Power Reset Clock Manager (PRCM)
+
+Properties:
+- compatible:  "ti,am4372-prcm" for prcm in am43x SoC's
+   "ti,am3352-prcm" for prcm in am335x SoC's
+- #reset-cells: 1 (refer generic reset bindings for details)
+
+example:
+   prcm: prcm@44df {
+   compatible = "ti,am4372-prcm";
+   reg = <0x44df 0xa000>;
+   #reset-cells = <1>;
+   };
-- 
1.8.3.4

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

[PATCH RFC 1/6] reset: is_reset and clear_reset api's

[Afzal Mohammed]

Enhance reset framework with "is_reset" and "clear_reset" api's.
is_reset - used by client driver to know reset status
clear_reset - used by client driver to clear reset status

These functionalities may sometimes be achieved by using existing api
like deassert. But in some scenarios, steps to achieve reset requires
clearing reset, deassert reset, enabling clock to module and then
checking reset status. Here enabling clock module is coming in between
reset procedure, hence enhance framework with additional api's.

Signed-off-by: Afzal Mohammed 
---
 drivers/reset/core.c | 32 
 include/linux/reset-controller.h |  2 ++
 include/linux/reset.h|  2 ++
 3 files changed, 36 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..ba12171 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -127,6 +127,38 @@ int reset_control_deassert(struct reset_control *rstc)
 EXPORT_SYMBOL_GPL(reset_control_deassert);
 
 /**
+ * reset_control_is_reset - check reset status
+ * @rstc: reset controller
+ *
+ * Returns a boolean or negative error code
+ *
+ */
+int reset_control_is_reset(struct reset_control *rstc)
+{
+   if (rstc->rcdev->ops->is_reset)
+   return rstc->rcdev->ops->is_reset(rstc->rcdev, rstc->id);
+
+   return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_is_reset);
+
+/**
+ * reset_control_clear_reset - clear the reset
+ * @rstc: reset controller
+ *
+ * Returns zero on success or negative error code
+ *
+ */
+int reset_control_clear_reset(struct reset_control *rstc)
+{
+   if (rstc->rcdev->ops->clear_reset)
+   return rstc->rcdev->ops->clear_reset(rstc->rcdev, rstc->id);
+
+   return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_clear_reset);
+
+/**
  * reset_control_get - Lookup and obtain a reference to a reset controller.
  * @dev: device to be reset by the controller
  * @id: reset line name
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index 2f61311..c9bbadb 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -17,6 +17,8 @@ struct reset_control_ops {
int (*reset)(struct reset_controller_dev *rcdev, unsigned long id);
int (*assert)(struct reset_controller_dev *rcdev, unsigned long id);
int (*deassert)(struct reset_controller_dev *rcdev, unsigned long id);
+   int (*is_reset)(struct reset_controller_dev *rcdev, unsigned long id);
+   int (*clear_reset)(struct reset_controller_dev *rcdev, unsigned long i);
 };
 
 struct module;
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 6082247..da59f9f 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -7,6 +7,8 @@ struct reset_control;
 int reset_control_reset(struct reset_control *rstc);
 int reset_control_assert(struct reset_control *rstc);
 int reset_control_deassert(struct reset_control *rstc);
+int reset_control_is_reset(struct reset_control *rstc);
+int reset_control_clear_reset(struct reset_control *rstc);
 
 struct reset_control *reset_control_get(struct device *dev, const char *id);
 void reset_control_put(struct reset_control *rstc);
-- 
1.8.3.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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Frederic Weisbecker]

On Mon, Sep 02, 2013 at 03:50:34PM +0200, Stanislaw Gruszka wrote:
> On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > > Hope this may help.
> > > I've added a silly check to make sure that `stime < rtime'
> > > 
> > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
> > > if (total) {
> > > stime = scale_stime((__force u64)stime,
> > > (__force u64)rtime, (__force 
> > > u64)total);
> > > +   if (stime > rtime) {
> > > +   printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", 
> > > stime, rtime);
> > > +   WARN_ON(1);
> > > +   }
> > > utime = rtime - stime;
> > > } else {
> > > stime = rtime;
> [snip]
> 
> > Thanks a lot Sergey for testing this further!
> > 
> > Interesting results, so rtime is always one or two units off stime after 
> > scaling.
> > Stanislaw made the scaling code with Linus and he has a better idea on the 
> > math guts
> > here.
> 
> I don't think this is scale issue, but rather at scale_stime() input
> stime is already bigger then rtime. Sergey, could you verify that
> by adding check before scale_stime() ?

Note that having stime > rtime should be fine to handle. This can happen for
example if the task runs on tiny timeslices but is unlucky enough that all these
timeslices are interrupted by the tick.

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

[PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver

[Afzal Mohammed]

Hi,

This is an attempt to achieve reset on AM43x/AM335x based SoC's with
reset driver making use of the reset framework.

prcm node is added in device tree, which would hold reset bindings.
Initially node was made as a one that represents reset functionality
of SoC. but ended up with node for prcm (which is felt to be natural
choice) instead. I am a bit doubtful whether placement of prcm node in
root node as in this series is the right thing.

Reset driver gets probed for specific prcm node, the same defines
register details to be used for a particular SoC (using ".data" field
associated with ".compatible" in driver match table).

Another option to handle different SoC's would be to add register
details to DT and let the driver extract it from DT. I vaguely
remember seeing a thread mentioning that putting register details in
DT is not preferred. But open to putting register level details
instead in DT if that is being generally preferred. This would have
advantage that adding reset support for a new SoC would be easier, but
would have to put more thought before doing so as DT bindings should
not change.

With the approach taken here, for supporting a new SoC with new prcm
register details, driver would have to be updated much like the way a
pci based ethernet driver would have to be updated to handle a new IP
version that is not register level compatible with the existing ones.

In this series out of the three IP's (gfx, m3, pruss) that would need
reset support, here as a proof of concept only gfx is taken care.
Other's can be easily supported by adding new register data array
entries.

Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.

*--*
client IP handling s/w (DT based) should do as follows:

1. Specify reset handle in the relevant DT node, for eg.

myip@deadbeef {
:
:
/* here prcm is the handle to reset binding node */
resets = < 0>;
};

2. In driver, that require reset to be deasserted,
 (this is the sequence required for gfx on AM43x/AM335x, this would
  depend on requirements of the IP)

mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(>dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}

*--*

May be removing reset handling in hwmod can be considered by making
use of reset driver.

Or as another extreme, perhaps, other logic's in the prcm can be
handled by a new prcm driver and then this reset driver can be a child
of it.

Regards
Afzal


Afzal Mohammed (6):
  reset: is_reset and clear_reset api's
  doc: dt: binding: omap: am43x/am335x prcm reset
  reset: am43x/am335x support
  ARM: OMAP2+: AM43x/AM335x: have reset controller
  ARM: dts: AM335x: prcm node (for reset)
  ARM: dts: AM4372: prcm node (for reset)

 .../devicetree/bindings/arm/omap/prcm.txt  |  13 ++
 arch/arm/boot/dts/am33xx.dtsi  |   6 +
 arch/arm/boot/dts/am4372.dtsi  |   6 +
 arch/arm/mach-omap2/Kconfig|   2 +
 drivers/reset/Kconfig  |  14 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/amx3_reset.c | 157 +
 drivers/reset/core.c   |  32 +
 include/linux/reset-controller.h   |   2 +
 include/linux/reset.h  |   2 +
 10 files changed, 235 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
 create mode 100644 drivers/reset/amx3_reset.c

-- 
1.8.3.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: [PATCHv2 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional

[Eduardo Valentin]

Hi,

On 29-08-2013 16:12, Eduardo Valentin wrote:
> When registering a new thermal_device, the thermal framework
> will always add a hwmon sysfs interface.
> 
> This patch adds a flag to make this behavior optional. Now
> when registering a new thermal device, the caller can
> optionally inform if hwmon interface is desirable. This can
> be done by means of passing a thermal_zone_params.no_hwmon == true.
> 
> In order to keep same behavior as of today, all current
> calls will by default create the hwmon interface.
> 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: Zhang Rui 
> Suggested-by: Wei Ni 
> Signed-off-by: Eduardo Valentin 
> ---
>  Documentation/thermal/sysfs-api.txt | 5 +
>  drivers/thermal/thermal_core.c  | 8 +---
>  include/linux/thermal.h | 8 
>  3 files changed, 18 insertions(+), 3 deletions(-)
> ---
> 
> Hello all,
> 
> So, here is then a different way of implementing same feature.
> As requested by Rui, now the flag goes via thermal_zone_params,
> because this seams to be the preferred way, at least in near future.
> 
> Using this method the amount of subsystems involved is reduced to 1:
> thermal, as requested by Raphael. I just made is a negative flag
> in order to keep the same behavior of the existing drivers, without
> changing them. The flag is documented though.
> 

Objections on this way of adding this flag?

Rui,

If you are OK, I can add this series to my tree too.


> All best,
> 
> 
> diff --git a/Documentation/thermal/sysfs-api.txt 
> b/Documentation/thermal/sysfs-api.txt
> index a71bd5b..37c5486 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -142,6 +142,11 @@ temperature) and throttle appropriate devices.
>  This is an optional feature where some platforms can choose not to
>  provide this data.
>  .governor_name: Name of the thermal governor used for this zone
> +.no_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
> +   is required. when no_hwmon == false, a hwmon sysfs interface
> +   will be created. when no_hwmon == true, nothing will be done.
> +   In case the thermal_zone_params is NULL, the hwmon interface
> +   will be created (for backward compatibility).
>  .num_tbps: Number of thermal_bind_params entries for this zone
>  .tbp: thermal_bind_params entries
>  
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 247528b..51648bf 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1462,9 +1462,11 @@ struct thermal_zone_device 
> *thermal_zone_device_register(const char *type,
>  
>   mutex_unlock(_governor_lock);
>  
> - result = thermal_add_hwmon_sysfs(tz);
> - if (result)
> - goto unregister;
> + if (!tz->tzp || !tz->tzp->no_hwmon) {
> + result = thermal_add_hwmon_sysfs(tz);
> + if (result)
> + goto unregister;
> + }
>  
>   mutex_lock(_list_lock);
>   list_add_tail(>node, _tz_list);
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a386a1c..b4a975f 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -214,6 +214,14 @@ struct thermal_bind_params {
>  /* Structure to define Thermal Zone parameters */
>  struct thermal_zone_params {
>   char governor_name[THERMAL_NAME_LENGTH];
> +
> + /*
> +  * a boolean to indicate if the thermal to hwmon sysfs interface
> +  * is required. when no_hwmon == false, a hwmon sysfs interface
> +  * will be created. when no_hwmon == true, nothing will be done
> +  */
> + bool no_hwmon;
> +
>   int num_tbps;   /* Number of tbp entries */
>   struct thermal_bind_params *tbp;
>  };
> 




-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 3/6] ARM: edma: Add function to manually trigger an EDMA channel

[Sekhar Nori]

On 8/30/2013 4:35 AM, Joel Fernandes wrote:
> Manual trigger for events missed as a result of splitting a
> scatter gather list and DMA'ing it in batches. Add a helper
> function to trigger a channel incase any such events are missed.
> 
> Signed-off-by: Joel Fernandes 

Acked-by: Sekhar Nori 

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Sergey Senozhatsky]

On (09/02/13 15:50), Stanislaw Gruszka wrote:
> Date: Mon, 2 Sep 2013 15:50:34 +0200
> From: Stanislaw Gruszka 
> To: Frederic Weisbecker 
> Cc: Sergey Senozhatsky , Ingo Molnar
>  , Peter Zijlstra , "Paul E.
>  McKenney" , Borislav Petkov ,
>  linux-kernel@vger.kernel.org
> Subject: Re: [sched next] overflowed cpu time for kernel threads in
>  /proc/PID/stat
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > > Hope this may help.
> > > I've added a silly check to make sure that `stime < rtime'
> > > 
> > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
> > > if (total) {
> > > stime = scale_stime((__force u64)stime,
> > > (__force u64)rtime, (__force 
> > > u64)total);
> > > +   if (stime > rtime) {
> > > +   printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", 
> > > stime, rtime);
> > > +   WARN_ON(1);
> > > +   }
> > > utime = rtime - stime;
> > > } else {
> > > stime = rtime;
> [snip]
> 
> > Thanks a lot Sergey for testing this further!
> > 
> > Interesting results, so rtime is always one or two units off stime after 
> > scaling.
> > Stanislaw made the scaling code with Linus and he has a better idea on the 
> > math guts
> > here.
> 
> I don't think this is scale issue, but rather at scale_stime() input
> stime is already bigger then rtime. Sergey, could you verify that
> by adding check before scale_stime() ?
> 

usually stime < rtime.
this is what scale_stime() gets as input:

[ 1291.409566] stime:3790580815 rtime:4344293130 total:3790580815
[ 1300.484675] stime:3966526699 rtime:4316110636 total:3966526699
[ 1309.548850] stime:4016453845 rtime:4369061182 total:4016453845
[ 1315.597880] stime:4055256777 rtime:4409603756 total:4055256777
[ 1315.598340] stime:4004230541 rtime:4571167362 total:4004230541
[ 1318.623774] stime:4072651687 rtime:4427641260 total:4072651687
[ 1318.624194] stime:3307672697 rtime:4359433252 total:3307672697
[ 1321.661950] stime:4073588267 rtime:4644946914 total:4073588267
[ 1324.691457] stime:4105876887 rtime:4462631018 total:4105876887
[ 1327.722074] stime:3375231967 rtime:4439900096 total:3375231967
[ 1333.757482] stime:4156087279 rtime:4514990216 total:4156087279
[ 1333.757755] stime:3427423145 rtime:4504337498 total:3427423145
[ 1333.758080] stime:4180115893 rtime:4758073724 total:4180115893
[ 1339.813117] stime:3465843945 rtime:4554325330 total:3465843945
[ 1342.845746] stime:4204665773 rtime:4565346324 total:4204665773
[ 1345.888570] stime:3497346343 rtime:4592210094 total:3497346343
[ 1348.922371] stime:4348957782 rtime:4935439460 total:4348957782
[ 1351.950096] stime:4362056506 rtime:4949617939 total:4362056506
[ 1361.021453] stime:4295785738 rtime:4661661137 total:4295785738
[ 1361.022000] stime:4458897246 rtime:5051395981 total:4458897246
[ 1364.050371] stime:4311972683 rtime:4678581654 total:4311972683
[ 1364.050765] stime:4479087426 rtime:5072949454 total:4479087426
[ 1367.076973] stime:4499465526 rtime:5094687861 total:4499465526
[ 1370.099987] stime:4343775870 rtime:4712036053 total:4343775870
[ 1373.125650] stime:4359154163 rtime:4727095545 total:4359154163
[ 1373.126009] stime:4552630150 rtime:5150626456 total:4552630150
[ 1376.148541] stime:4374640011 rtime:4743265121 total:4374640011
[ 1379.177031] stime:3732027459 rtime:4887067184 total:3732027459
[ 1382.220666] stime:4404735122 rtime:4774829507 total:4404735122
[ 1385.246696] stime:4420289930 rtime:4790957716 total:4420289930
[ 1385.247197] stime:4649961982 rtime:5253432805 total:4649961982
[ 1388.269661] stime:4433706951 rtime:4804365472 total:4433706951
[ 1388.270078] stime:3783514895 rtime:4952742424 total:3783514895
[ 1391.299533] stime:4449952651 rtime:4821791998 total:4449952651
[ 1394.329016] stime:4463714342 rtime:4836891922 total:4463714342

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

Fix style in s3c-hsotg.c

[Pavel Machek]

Hi!

checkpatch.pl has some valid complaints about style in s3c-hsotg.c :
macro with if should be really enclosed in do {} while, and puts is
going to be slightly faster.

Here's suggested patch. I don't have the hardware, so it is completely
untested.

Signed-off-by: Pavel Machek, 

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index af22f24..f8e762a 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -2091,12 +2091,14 @@ static void kill_all_requests(struct s3c_hsotg *hsotg,
 }
 
 #define call_gadget(_hs, _entry) \
+do { \
if ((_hs)->gadget.speed != USB_SPEED_UNKNOWN && \
(_hs)->driver && (_hs)->driver->_entry) { \
spin_unlock(&_hs->lock); \
(_hs)->driver->_entry(&(_hs)->gadget); \
spin_lock(&_hs->lock); \
}
+} while (0)
 
 /**
  * s3c_hsotg_disconnect - disconnect service
@@ -3204,7 +3206,7 @@ static int state_show(struct seq_file *seq, void *v)
   readl(regs + GNPTXSTS),
   readl(regs + GRXSTSR));
 
-   seq_printf(seq, "\nEndpoint status:\n");
+   seq_puts(seq, "\nEndpoint status:\n");
 
for (idx = 0; idx < 15; idx++) {
u32 in, out;
@@ -3221,7 +3223,7 @@ static int state_show(struct seq_file *seq, void *v)
seq_printf(seq, ", DIEPTSIZ=0x%08x, DOEPTSIZ=0x%08x",
   in, out);
 
-   seq_printf(seq, "\n");
+   seq_puts(seq, "\n");
}
 
return 0;
@@ -3255,7 +3257,7 @@ static int fifo_show(struct seq_file *seq, void *v)
u32 val;
int idx;
 
-   seq_printf(seq, "Non-periodic FIFOs:\n");
+   seq_puts(seq, "Non-periodic FIFOs:\n");
seq_printf(seq, "RXFIFO: Size %d\n", readl(regs + GRXFSIZ));
 
val = readl(regs + GNPTXFSIZ);
@@ -3263,7 +3265,7 @@ static int fifo_show(struct seq_file *seq, void *v)
   val >> GNPTXFSIZ_NPTxFDep_SHIFT,
   val & GNPTXFSIZ_NPTxFStAddr_MASK);
 
-   seq_printf(seq, "\nPeriodic TXFIFOs:\n");
+   seq_puts(seq, "\nPeriodic TXFIFOs:\n");
 
for (idx = 1; idx <= 15; idx++) {
val = readl(regs + DPTXFSIZn(idx));
@@ -3334,7 +3336,7 @@ static int ep_show(struct seq_file *seq, void *v)
   readl(regs + DIEPTSIZ(index)),
   readl(regs + DOEPTSIZ(index)));
 
-   seq_printf(seq, "\n");
+   seq_puts(seq, "\n");
seq_printf(seq, "mps %d\n", ep->ep.maxpacket);
seq_printf(seq, "total_data=%ld\n", ep->total_data);
 
@@ -3345,7 +3347,7 @@ static int ep_show(struct seq_file *seq, void *v)
 
list_for_each_entry(req, >queue, queue) {
if (--show_limit < 0) {
-   seq_printf(seq, "not showing more requests...\n");
+   seq_puts(seq, "not showing more requests...\n");
break;
}
 

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

Please discard "checkpatch: warn when using extern with function prototypes in .h files"

[David Howells]

I noticed that a patch got committed to checkpatch to complain about function
prototypes prefixed by "extern".

Please discard/revert this patch:

commit 7cd0f806622836e386ef18ad1950a9a729803019
Author: Joe Perches 
Date:   Wed Aug 28 10:16:00 2013 +1000
checkpatch: warn when using extern with function prototypes in .h files

Using the extern keyword on function prototypes is superfluous visual
noise so suggest removing it.

This is inaccurate.  It's actually a useful visual cue - so if anything, please
make checkpatch indicate that it be added to all future function prototypes.

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

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Stanislaw Gruszka]

On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > Hope this may help.
> > I've added a silly check to make sure that `stime < rtime'
> > 
> > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
> > if (total) {
> > stime = scale_stime((__force u64)stime,
> > (__force u64)rtime, (__force u64)total);
> > +   if (stime > rtime) {
> > +   printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", 
> > stime, rtime);
> > +   WARN_ON(1);
> > +   }
> > utime = rtime - stime;
> > } else {
> > stime = rtime;
[snip]

> Thanks a lot Sergey for testing this further!
> 
> Interesting results, so rtime is always one or two units off stime after 
> scaling.
> Stanislaw made the scaling code with Linus and he has a better idea on the 
> math guts
> here.

I don't think this is scale issue, but rather at scale_stime() input
stime is already bigger then rtime. Sergey, could you verify that
by adding check before scale_stime() ?

Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Sergey Senozhatsky]

On (09/02/13 15:07), Frederic Weisbecker wrote:
> > $ dmesg | grep Ooops
> > [ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
> > [ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
> > [ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
> > [ 1313.493462] Ooops: stime:4724166945 rtime:4724166944
> > [ 1316.521740] Ooops: stime:4741142233 rtime:4741142232
> > [ 1325.605625] Ooops: stime:4793906690 rtime:4793906688
> > [ 1331.648611] Ooops: stime:4308413629 rtime:4308413628
> > [ 1337.708468] Ooops: stime:4510156747 rtime:4510156746
> > [ 1340.744586] Ooops: stime:4880584390 rtime:4880584389
> > [ 1343.773111] Ooops: stime:4442005879 rtime:4442005878
> > [ 1343.773362] Ooops: stime:4558310943 rtime:4558310942
> > [ 1349.815797] Ooops: stime:4927379646 rtime:4927379645
> > [ 1352.836936] Ooops: stime:4942782836 rtime:4942782834
> > [ 1358.885232] Ooops: stime:4979031940 rtime:4979031938
> > [ 1364.977902] Ooops: stime:5019633914 rtime:5019633912
> > [ 1364.978283] Ooops: stime:4601969101 rtime:4601969100
> > [ 1364.978623] Ooops: stime:4826393815 rtime:4826393814
> > [ 1371.034265] Ooops: stime:4894272175 rtime:4894272174
> > [ 1374.077150] Ooops: stime:4688831829 rtime:4688831828
> > [ 1374.077519] Ooops: stime:4916319315 rtime:4916319314
> > [ 1377.110416] Ooops: stime:5084174048 rtime:5084174047
> > [ 1377.111043] Ooops: stime:4949250198 rtime:4949250196
> > [ 1380.137382] Ooops: stime:5096963048 rtime:5096963046
> > [ 1380.137739] Ooops: stime:4975014880 rtime:4975014879
> > [ 1383.161441] Ooops: stime:5002466396 rtime:5002466394
> > [ 1389.212166] Ooops: stime:5140400038 rtime:5140400036
> > [ 1392.239303] Ooops: stime:5082051028 rtime:5082051027
> > [ 1395.270391] Ooops: stime:5170118636 rtime:5170118634
> > [ 1398.303593] Ooops: stime:5184355318 rtime:5184355316
> 
> 
> Thanks a lot Sergey for testing this further!
> 
> Interesting results, so rtime is always one or two units off stime after 
> scaling.
> Stanislaw made the scaling code with Linus and he has a better idea on the 
> math guts
> here.
> 
> Stanislaw, any idea?

sure. sorry, it took so long to get back to this.

actual scale_stime() input that triggers overflow:

[ 1291.409566] stime:3790580815 rtime:4344293130 total:3790580815
[ 1300.484675] stime:3966526699 rtime:4316110636 total:3966526699
[ 1309.548850] stime:4016453845 rtime:4369061182 total:4016453845
[ 1315.597880] stime:4055256777 rtime:4409603756 total:4055256777
[ 1315.598340] stime:4004230541 rtime:4571167362 total:4004230541
[ 1318.623774] stime:4072651687 rtime:4427641260 total:4072651687
[ 1318.624194] stime:3307672697 rtime:4359433252 total:3307672697
[ 1321.661950] stime:4073588267 rtime:4644946914 total:4073588267
[ 1324.691457] stime:4105876887 rtime:4462631018 total:4105876887
[ 1327.722074] stime:3375231967 rtime:4439900096 total:3375231967
[ 1333.757482] stime:4156087279 rtime:4514990216 total:4156087279
[ 1333.757755] stime:3427423145 rtime:4504337498 total:3427423145
[ 1333.758080] stime:4180115893 rtime:4758073724 total:4180115893
[ 1339.813117] stime:3465843945 rtime:4554325330 total:3465843945
[ 1342.845746] stime:4204665773 rtime:4565346324 total:4204665773
[ 1345.888570] stime:3497346343 rtime:4592210094 total:3497346343
[ 1348.922371] stime:4348957782 rtime:4935439460 total:4348957782
[ 1351.950096] stime:4362056506 rtime:4949617939 total:4362056506
[ 1361.021453] stime:4295785738 rtime:4661661137 total:4295785738
[ 1361.022000] stime:4458897246 rtime:5051395981 total:4458897246
[ 1364.050371] stime:4311972683 rtime:4678581654 total:4311972683
[ 1364.050765] stime:4479087426 rtime:5072949454 total:4479087426
[ 1367.076973] stime:4499465526 rtime:5094687861 total:4499465526
[ 1370.099987] stime:4343775870 rtime:4712036053 total:4343775870
[ 1373.125650] stime:4359154163 rtime:4727095545 total:4359154163
[ 1373.126009] stime:4552630150 rtime:5150626456 total:4552630150
[ 1376.148541] stime:4374640011 rtime:4743265121 total:4374640011
[ 1379.177031] stime:3732027459 rtime:4887067184 total:3732027459
[ 1382.220666] stime:4404735122 rtime:4774829507 total:4404735122
[ 1385.246696] stime:4420289930 rtime:4790957716 total:4420289930
[ 1385.247197] stime:4649961982 rtime:5253432805 total:4649961982
[ 1388.269661] stime:4433706951 rtime:4804365472 total:4433706951
[ 1388.270078] stime:3783514895 rtime:4952742424 total:3783514895
[ 1391.299533] stime:4449952651 rtime:4821791998 total:4449952651
[ 1394.329016] stime:4463714342 rtime:4836891922 total:4463714342


-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: perf_event: rdpmc self-monitoring overhead issue

[Vince Weaver]

On Mon, 2 Sep 2013, Stephane Eranian wrote:

> On Mon, Sep 2, 2013 at 4:50 AM, Andi Kleen  wrote:
> > Stephane Eranian  writes:
> >
> >> I don't see a flag in mmap() to fault it in immediately.
> >
> > MAP_PRESENT
> >
> I could not find this constant defined anywhere in the kernel source tree
> nor in /usr/include. Are you sure of the name?

I assume he means MAP_POPULATE

which does improve things, from ~3000 cycles to ~219 cycles but that's 
still more overhead than the ~130 or so you get by manually touching the 
page first.

Vince

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dmaengine: dma_slave_caps: remove sg entries

[Vinod Koul]

As pointed by Russell in [1], the sg properties are already availble in struct 
device,
so no need to duplicate here.

[1]: http://marc.info/?l=linux-omap=137416733628831

Signed-off-by: Vinod Koul 
---
 include/linux/dmaengine.h |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 5692bc3..4310b89 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -380,11 +380,6 @@ struct dma_slave_config {
  * should be checked by controller as well
  * @cmd_pause: true, if pause and thereby resume is supported
  * @cmd_terminate: true, if terminate cmd is supported
- *
- * @max_sg_nr: maximum number of SG segments supported
- * 0 for no maximum
- * @max_sg_len: maximum length of a SG segment supported
- * 0 for no maximum
  */
 struct dma_slave_caps {
u32 src_addr_widths;
@@ -392,9 +387,6 @@ struct dma_slave_caps {
u32 directions;
bool cmd_pause;
bool cmd_terminate;
-
-   u32 max_sg_nr;
-   u32 max_sg_len;
 };
 
 static inline const char *dma_chan_name(struct dma_chan *chan)
-- 
1.7.0.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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Frederic Weisbecker]

On Mon, Sep 02, 2013 at 03:28:45PM +0300, Sergey Senozhatsky wrote:
> On (08/31/13 01:04), Frederic Weisbecker wrote:
> > > in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime - 
> > > stime'
> > > sets wrong value.
> > 
> > But stime should always be below rtime due to the calculation done by 
> > scale_stime()
> > which roughly sums up to:
> > 
> >   stime = (stime / stime + utime) * rtime
> > 
> > So this shouldn't happen.
> > 
> > I couldn't manage to reproduce it though. Can you still trigger it with 
> > latest -next?
> >
> 
> Hope this may help.
> I've added a silly check to make sure that `stime < rtime'
> 
> @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
> if (total) {
> stime = scale_stime((__force u64)stime,
> (__force u64)rtime, (__force u64)total);
> +   if (stime > rtime) {
> +   printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", 
> stime, rtime);
> +   WARN_ON(1);
> +   }
> utime = rtime - stime;
> } else {
> stime = rtime;
> 
> 
> and got the following results:
> 
> 
> [ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
> [ 1295.311063] [ cut here ]
> [ 1295.311072] WARNING: CPU: 1 PID: 2167 at kernel/sched/cputime.c:584 
> cputime_adjust+0x132/0x140()
> [ 1295.311123] CPU: 1 PID: 2167 Comm: top Tainted: G C   
> 3.11.0-rc7-next-20130902-dbg-dirty #2
> [ 1295.311126] Hardware name: Acer Aspire 5741G/Aspire 5741G  
>   , BIOS V1.20 02/08/2011
> [ 1295.311128]  0009 880099937c50 8162fc85 
> 
> [ 1295.311134]  880099937c88 8104ee2d 8801530bb158 
> 880099937df0
> [ 1295.311139]  0001138994d0 0001138994d1 880153118ff0 
> 880099937c98
> [ 1295.311145] Call Trace:
> [ 1295.311155]  [] dump_stack+0x4e/0x82
> [ 1295.311162]  [] warn_slowpath_common+0x7d/0xa0
> [ 1295.311166]  [] warn_slowpath_null+0x1a/0x20
> [ 1295.311170]  [] cputime_adjust+0x132/0x140
> [ 1295.311175]  [] thread_group_cputime_adjusted+0x41/0x50
> [ 1295.311182]  [] do_task_stat+0x9c4/0xb50
> [ 1295.311188]  [] proc_tgid_stat+0x14/0x20
> [ 1295.311192]  [] proc_single_show+0x54/0xa0
> [ 1295.311198]  [] seq_read+0x164/0x3d0
> [ 1295.311204]  [] vfs_read+0xa1/0x180
> [ 1295.311208]  [] SyS_read+0x4c/0xa0
> [ 1295.311213]  [] tracesys+0xd4/0xd9
> [ 1295.311216] ---[ end trace bab1e899ff45eea2 ]---
> 
> [ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
> [ 1301.384401] [ cut here ]
> [ 1301.384409] WARNING: CPU: 0 PID: 2167 at kernel/sched/cputime.c:584 
> cputime_adjust+0x132/0x140()
> [ 1301.384450] CPU: 0 PID: 2167 Comm: top Tainted: GWC   
> 3.11.0-rc7-next-20130902-dbg-dirty #2
> [ 1301.384452] Hardware name: Acer Aspire 5741G/Aspire 5741G  
>   , BIOS V1.20 02/08/2011
> [ 1301.384454]  0009 880099937c50 8162fc85 
> 
> [ 1301.384458]  880099937c88 8104ee2d 8801530bb158 
> 880099937df0
> [ 1301.384462]  000115678476 000115678477 880153118ff0 
> 880099937c98
> [ 1301.384466] Call Trace:
> [ 1301.384475]  [] dump_stack+0x4e/0x82
> [ 1301.384481]  [] warn_slowpath_common+0x7d/0xa0
> [ 1301.384484]  [] warn_slowpath_null+0x1a/0x20
> [ 1301.384487]  [] cputime_adjust+0x132/0x140
> [ 1301.384491]  [] thread_group_cputime_adjusted+0x41/0x50
> [ 1301.384497]  [] do_task_stat+0x9c4/0xb50
> [ 1301.384501]  [] proc_tgid_stat+0x14/0x20
> [ 1301.384504]  [] proc_single_show+0x54/0xa0
> [ 1301.384509]  [] seq_read+0x164/0x3d0
> [ 1301.384514]  [] vfs_read+0xa1/0x180
> [ 1301.384517]  [] SyS_read+0x4c/0xa0
> [ 1301.384521]  [] tracesys+0xd4/0xd9
> [ 1301.384523] ---[ end trace bab1e899ff45eea3 ]---
> 
> and so on.
> 
> 
> $ dmesg | grep Ooops
> [ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
> [ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
> [ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
> [ 1313.493462] Ooops: stime:4724166945 rtime:4724166944
> [ 1316.521740] Ooops: stime:4741142233 rtime:4741142232
> [ 1325.605625] Ooops: stime:4793906690 rtime:4793906688
> [ 1331.648611] Ooops: stime:4308413629 rtime:4308413628
> [ 1337.708468] Ooops: stime:4510156747 rtime:4510156746
> [ 1340.744586] Ooops: stime:4880584390 rtime:4880584389
> [ 1343.773111] Ooops: stime:4442005879 rtime:4442005878
> [ 1343.773362] Ooops: stime:4558310943 rtime:4558310942
> 

Re: [PATCH 1/2] dma: sh: use devm_ioremap_resource() instead of devm_request_and_ioremap()

[Vinod Koul]

On Mon, Sep 02, 2013 at 12:04:29PM +0530, Vinod Koul wrote:
> On Mon, Sep 02, 2013 at 10:23:15AM +0900, Jingoo Han wrote:
> > Use devm_ioremap_resource() because devm_request_and_ioremap() is
> > obsoleted by devm_ioremap_resource().
> Applied both, Thanks
I have removed this one and reapplied patch 2. This was duplicate of Julia's
patch which was sent earlier, so I have applied that one

~Vinod
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] dma: replace devm_request_and_ioremap by devm_ioremap_resource

[Vinod Koul]

On Mon, Aug 19, 2013 at 01:20:38PM +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Use devm_ioremap_resource instead of devm_request_and_ioremap.
> 
> This was done using the semantic patch
> scripts/coccinelle/api/devm_ioremap_resource.cocci
> 
> The relevant call to platform_get_resource was manually moved down to the
> call to devm_ioremap_resource.
Applied, thanks

~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/6] dma: edma: Support scatter-lists of any length

[Vinod Koul]

On Thu, 2013-08-29 at 18:05 -0500, Joel Fernandes wrote:
> The following series adds support to EDMA driver to enable DMA of
> scatter-gather lists of arbitrary length, but still make use of only
> a certain MAX number of slots at a time for a given channel. Thus
> free-ing up the rest of the slots to other slaves/channels.  With this
> there is no need for slave drivers to query the EDMA driver about how
> much is the MAX it can send at a time as done in [1]. Drivers can send
> SG lists of any number of entries to DMA. Reference discussion at [2].
> 
> With this, all the patches for MMC and EDMA related to "sg limits" can be
> dropped.
> 
> Tested omap-aes and omap_hsmmc drivers with different MAX number of slots,
> even just 1. In the case where it is 1, only 1-slot is used to DMA an
> entire scatter list of arbitrary length.
> Since this series touches EDMA private API code also shared with davinci-pcm,
> playback of a 16-bit 44.1KHz audio file with davinci-pcm has been tested.
> 
> Sample test run with 1 vs 16 (MAX number of slots/SG) in omap-aes driver:
> MAX slots = 1:
>  (128 bit key, 8192 byte blocks): 1266 operations in 1 seconds (10371072 
> bytes)
> MAX slots = 16:
>  (128 bit key, 8192 byte blocks): 1601 operations in 1 seconds (13115392 
> bytes)
> 
> Note: For the above test, 8K buffer is mapped into SG list of size 2 so
> only 2 slots are required. So beyond size 2, there will not be any noticeable
> performance improvement. But above experiment just shows as proof of concept
> that even using 1 slot is managed by just DMA'ing 1 SG entry at a time.
much better series, thanks

I think i am okay with this, if anyone has objections pls speak up. Also
I need ack on the ARM patch 3/6 before I can carry this.

-- 
Vinod Koul
Intel Corp.

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

tsc2007 driver, read data abort after i2c timeout

[Super Eichtig]

Hello!
 
In the last few weeks I worked on a problem I had with I2C errors and the 
effect they had on the touchscreen performance with a TI TSC2007 IC.
For I'm stuck with an old kernel (2.6.28) i used the tsc2003 driver, but the 
code seems to be close to the tsc2007.c .
 
I came across the funktion "tsc2003_read_values" where 5 I2C transfers are 
executed after a PenIRQ event (read x,y,z1,z2 and power down).
In this function the return values of the tsc2007_xfer function are ignored. So 
there will always be 5 tries to access the bus.
In the I2C driver there is a timeout for failed transfers of 5 second. This 
leads to an overall time for the above function of 25s in case of an error on 
the i2c bus.
 
In my case it helped a lot to abort the read_values function after an error 
return value from the _xfer function.
 
I obviously don't know all the details of the tsc code. To this day I don't 
understand how the transfer recovers and reacts to the next penirq when the 
first transfer is interrupted and so the tsc-chip is never returned to the 
"power down and listen to the penirq" state. Maybe there are good reasons not 
to interrupt the function.
Can you comment on this change? Is it a grave mistake or could this work. It 
does right now but not understanding all implications means it probably bites 
me in the ass at one point.
 
Attached you'll find a patch for the tsc2003.c file.
 
Best regards
Sebastian
 
 
diff --git a/drivers/input/touchscreen/tsc2003.c 
b/drivers/input/touchscreen/tsc2003.c
index 4f3a2c9..7ad62f2 100644
--- a/drivers/input/touchscreen/tsc2003.c
+++ b/drivers/input/touchscreen/tsc2003.c
@@ -115,15 +115,31 @@ static inline int tsc2003_xfer(struct tsc2003 *tsc, u8 
cmd)
 
 static void tsc2003_read_values(struct tsc2003 *tsc, struct ts_event *tc)
 {
+    s32 temp;
+
+    tc->y = 0;
+    tc->x = 0;
+    tc->z1 = 0;
+    tc->z2 = 0;
+
     /* y- still on; turn on only y+ (and ADC) */
-    tc->y = tsc2003_xfer(tsc, READ_Y);
+    temp = tsc2003_xfer(tsc, READ_Y);
+    if (temp > 0) tc->y = temp;
+    else return;
 
     /* turn y- off, x+ on, then leave in lowpower */
-    tc->x = tsc2003_xfer(tsc, READ_X);
+    temp = tsc2003_xfer(tsc, READ_X);
+    if (temp > 0) tc->x = temp;
+    else return;
 
     /* turn y+ off, x- on; we'll use formula #1 */
-    tc->z1 = tsc2003_xfer(tsc, READ_Z1);
-    tc->z2 = tsc2003_xfer(tsc, READ_Z2);
+    temp = tsc2003_xfer(tsc, READ_Z1);
+    if (temp > 0) tc->z1 = temp;
+    else return;
+
+    temp = tsc2003_xfer(tsc, READ_Z2);
+    if (temp > 0) tc->z2 = temp;
+    else return;
 
     /* Prepare for next touch reading - power down ADC, enable PENIRQ */
     tsc2003_xfer(tsc, PWRDOWN);
 
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] dmaengine: add driver for Samsung s3c24xx SoCs

[Vinod Koul]

On Wed, Aug 28, 2013 at 12:13:51AM +0200, Heiko Stübner wrote:
> This adds a new driver to support the s3c24xx dma using the dmaengine
> and makes the old one in mach-s3c24xx obsolete in the long run.
> 
> Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
> with numerous virtual channels being mapped to a lot less physical ones.
> The driver therefore borrows a lot from the amba-pl08x driver in this
> regard. Functionality-wise the driver gains a memcpy ability in addition
> to the slave_sg one.
> 
> The driver supports both the method for requesting the peripheral used
> by SoCs before the S3C2443 and the different method for S3C2443 and later.
> 
> On earlier SoCs the hardware channels usable for specific peripherals is
> constrainted while on later SoCs all channels can be used for any peripheral.
> 
> Tested on a s3c2416-based board, memcpy using the dmatest module and
> slave_sg partially using the spi-s3c64xx driver.
> 

> +static int s3c24xx_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> +  unsigned long arg)
> +{
> + struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
> + struct s3c24xx_dma_engine *s3cdma = s3cchan->host;
> + unsigned long flags;
> + int ret = 0;
> +
> + /* Controls applicable to inactive channels */
> + if (cmd == DMA_SLAVE_CONFIG)
> + return s3c24xx_dma_set_runtime_config(s3cchan,
> +   (struct dma_slave_config *)arg);
> +
> + /*
> +  * Anything succeeds on channels with no physical allocation and
> +  * no queued transfers.
> +  */
> + spin_lock_irqsave(>vc.lock, flags);
> + if (!s3cchan->phy && !s3cchan->at) {
> + spin_unlock_irqrestore(>vc.lock, flags);
> + return 0;
this can be bad cmd or terminating already closed channel, return 0 doesnt make
sense
> + }
> +
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
why not DMA_SLAVE_CONFIG in this switch to make it look simpler...


> +static enum dma_status s3c24xx_dma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie, struct dma_tx_state *txstate)
> +{
> + struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
> + struct virt_dma_desc *vd;
> + unsigned long flags;
> + enum dma_status ret;
> + size_t bytes = 0;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> + if (ret == DMA_SUCCESS)
> + return ret;
> +
> + /*
> +  * There's no point calculating the residue if there's
> +  * no txstate to store the value.
> +  */
> + if (!txstate)
> + return ret;
> +
> + spin_lock_irqsave(>vc.lock, flags);
> + ret = dma_cookie_status(chan, cookie, txstate);
you are checking the cookie status twice, if you check txstate (which should be
valid anyways), then you avoid the duplication

> + if (ret != DMA_SUCCESS) {
> + struct s3c24xx_txd *txd;
> + struct s3c24xx_sg *dsg;
> +
> + vd = vchan_find_desc(>vc, cookie);
> + if (vd) {
> + /* On the issued list, so hasn't been processed yet */
> + txd = to_s3c24xx_txd(>tx);
> +
> + list_for_each_entry(dsg, >dsg_list, node)
> + bytes += dsg->len;
> + } else {
> + /*
> +  * Currently running, so sum over the pending sg's and
> +  * the currently active one.
> +  */
> + txd = s3cchan->at;
> +
> + dsg = list_entry(txd->at, struct s3c24xx_sg, node);
> + list_for_each_entry_from(dsg, >dsg_list, node);
> + bytes += dsg->len;
> +
> + bytes += s3c24xx_dma_getbytes_chan(s3cchan);
> + }
> + }
> + spin_unlock_irqrestore(>vc.lock, flags);
> +
> + /*
> +  * This cookie not complete yet
> +  * Get number of bytes left in the active transactions and queue
> +  */
> + dma_set_residue(txstate, bytes);
> +
> + /* Whether waiting or running, we're in progress */
> + return ret;
> +}
> +
> +/*
> + * Initialize a descriptor to be used by memcpy submit
> + */
> +static struct dma_async_tx_descriptor *s3c24xx_dma_prep_memcpy(
> + struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> + size_t len, unsigned long flags)
> +{
> + struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
> + struct s3c24xx_dma_engine *s3cdma = s3cchan->host;
> + struct s3c24xx_txd *txd;
> + struct s3c24xx_sg *dsg;
> +
> + dev_dbg(>pdev->dev, "prepare memcpy of %d bytes from %s\n",
> + len, s3cchan->name);
> +
> + if ((len & S3C24XX_DCON_TC_MASK) != len) {
> + dev_err(>pdev->dev, "memcpy size %d to large\n", len);
> + return NULL;
> + }
> +
> + txd = 

[PATCH 2/3] mm/vmalloc: don't warning vmalloc allocation failure twice

[Wanpeng Li]

Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if 
__vmalloc_area_node allocation failure.

Signed-off-by: Wanpeng Li 
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ee41cc6..e324d38 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1635,7 +1635,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned 
long align,
 
addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller);
if (!addr)
-   goto fail;
+   return NULL;
 
/*
 * In this function, newly allocated vm_struct has VM_UNINITIALIZED
-- 
1.8.1.2

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

[PATCH 3/3] mm/vmalloc: move VM_UNINITIALIZED just before show_numa_info

[Wanpeng Li]

The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid 
null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid 
accessing the pages field with unallocated page when show_numa_info() is 
called. This patch move the check just before show_numa_info in order that 
some messages still can be dumped via /proc/vmallocinfo.

Signed-off-by: Wanpeng Li 
---
 mm/vmalloc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e3ec8b4..c4720cd 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2590,11 +2590,6 @@ static int s_show(struct seq_file *m, void *p)
 
v = va->vm;
 
-   /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
-   smp_rmb();
-   if (v->flags & VM_UNINITIALIZED)
-   return 0;
-
seq_printf(m, "0x%pK-0x%pK %7ld",
v->addr, v->addr + v->size, v->size);
 
@@ -2622,6 +2617,11 @@ static int s_show(struct seq_file *m, void *p)
if (v->flags & VM_VPAGES)
seq_printf(m, " vpages");
 
+   /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
+   smp_rmb();
+   if (v->flags & VM_UNINITIALIZED)
+   return;
+
show_numa_info(m, v);
seq_putc(m, '\n');
return 0;
-- 
1.8.1.2

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

[PATCH 1/3] mm/vmalloc: don't set area->caller twice

[Wanpeng Li]

The caller address has already been set in set_vmalloc_vm(), there's no need 
to set it again in __vmalloc_area_node.

Signed-off-by: Wanpeng Li 
---
 mm/vmalloc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1074543..d78d117 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1566,7 +1566,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, 
gfp_t gfp_mask,
pages = kmalloc_node(array_size, nested_gfp, node);
}
area->pages = pages;
-   area->caller = caller;
if (!area->pages) {
remove_vm_area(area->addr);
kfree(area);
--
1.8.1.2


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

[PATCH 1/4] mm/hwpoison: fix traverse hugetlbfs page to avoid printk flood

[Wanpeng Li]

madvise_hwpoison won't check if the page is small page or huge page and 
traverse 
in small page granularity against the range unconditional, which result in a 
printk 
flood "MCE xxx: already hardware poisoned" if the page is huge page. This patch 
fix 
it by increase compound_order(compound_head(page)) for huge page iterator.

Testcase:

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PAGES_TO_TEST 3
#define PAGE_SIZE   4096 * 512

int main(void)
{
char *mem;
int i;

mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | 
MAP_HUGETLB, 0, 0);

if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;

munmap(mem, PAGES_TO_TEST * PAGE_SIZE);

return 0;
}

Signed-off-by: Wanpeng Li 
---
 mm/madvise.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 6975bc8..539eeb9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -343,10 +343,11 @@ static long madvise_remove(struct vm_area_struct *vma,
  */
 static int madvise_hwpoison(int bhv, unsigned long start, unsigned long end)
 {
+   struct page *p;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
-   for (; start < end; start += PAGE_SIZE) {
-   struct page *p;
+   for (; start < end; start += PAGE_SIZE <<
+   compound_order(compound_head(p))) {
int ret;
 
ret = get_user_pages_fast(start, 1, 0, );
-- 
1.8.1.2

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

[PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page

[Wanpeng Li]

PageTransHuge() can't guarantee the page is transparent huge page since it 
return true for both transparent huge and hugetlbfs pages. This patch fix 
it by check the page is also !hugetlbfs page.

Before patch:

[  121.571128] Injecting memory failure at pfn 23a200
[  121.571141] MCE 0x23a200: huge page recovery: Delayed
[  140.355100] MCE: Memory failure is now running on 0x23a200

After patch:

[   94.290793] Injecting memory failure at pfn 23a000
[   94.290800] MCE 0x23a000: huge page recovery: Delayed
[  105.722303] MCE: Software-unpoisoned page 0x23a000

Signed-off-by: Wanpeng Li 
---
 mm/memory-failure.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
 * worked by memory_failure() and the page lock is not held yet.
 * In such case, we yield to memory_failure() and make unpoison fail.
 */
-   if (PageTransHuge(page)) {
+   if (PageTransHuge(page) && !PageHuge(page)) {
pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
return 0;
}
-- 
1.8.1.2

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

[PATCH 3/4] mm/hwpoison: fix false report 2nd try page recovery

[Wanpeng Li]

If the page is poisoned by software inject w/ MF_COUNT_INCREASED flag, there
is a false report 2nd try page recovery which is not truth, this patch fix it
by report first try free buddy page recovery if MF_COUNT_INCREASED is set.

Before patch:

[  346.332041] Injecting memory failure at pfn 200010
[  346.332189] MCE 0x200010: free buddy, 2nd try page recovery: Delayed

After patch:

[  297.742600] Injecting memory failure at pfn 200010
[  297.742941] MCE 0x200010: free buddy page recovery: Delayed

Signed-off-by: Wanpeng Li 
---
 mm/memory-failure.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b114570..6293164 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1114,8 +1114,10 @@ int memory_failure(unsigned long pfn, int trapno, int 
flags)
 * shake_page could have turned it free.
 */
if (is_free_buddy_page(p)) {
-   action_result(pfn, "free buddy, 2nd try",
-   DELAYED);
+   if (flags & MF_COUNT_INCREASED)
+   action_result(pfn, "free buddy", 
DELAYED);
+   else
+   action_result(pfn, "free buddy, 2nd 
try", DELAYED);
return 0;
}
action_result(pfn, "non LRU", IGNORED);
-- 
1.7.5.4

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

[PATCH 4/4] mm/hwpoison: fix the lack of one reference count against poisoned page

[Wanpeng Li]

The lack of one reference count against poisoned page for hwpoison_inject w/o 
hwpoison_filter enabled result in hwpoison detect -1 users still referenced 
the page, however, the number should be 0 except the poison handler held one 
after successfully unmap. This patch fix it by hold one referenced count 
against 
poisoned page for hwpoison_inject w/ and w/o hwpoison_filter enabled.

Before patch:

[   71.902112] Injecting memory failure at pfn 224706
[   71.902137] MCE 0x224706: dirty LRU page recovery: Failed
[   71.902138] MCE 0x224706: dirty LRU page still referenced by -1 users

After patch:

[   94.710860] Injecting memory failure at pfn 215b68
[   94.710885] MCE 0x215b68: dirty LRU page recovery: Recovered

Signed-off-by: Wanpeng Li 
---
 mm/hwpoison-inject.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
index afc2daa..4c84678 100644
--- a/mm/hwpoison-inject.c
+++ b/mm/hwpoison-inject.c
@@ -20,8 +20,6 @@ static int hwpoison_inject(void *data, u64 val)
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
 
-   if (!hwpoison_filter_enable)
-   goto inject;
if (!pfn_valid(pfn))
return -ENXIO;
 
@@ -33,6 +31,9 @@ static int hwpoison_inject(void *data, u64 val)
if (!get_page_unless_zero(hpage))
return 0;
 
+   if (!hwpoison_filter_enable)
+   goto inject;
+
if (!PageLRU(p) && !PageHuge(p))
shake_page(p, 0);
/*
-- 
1.8.1.2

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

Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq_governor()

[Rafael J. Wysocki]

On Sunday, September 01, 2013 09:30:49 PM Viresh Kumar wrote:
> On 1 September 2013 18:58, Rafael J. Wysocki  wrote:
> > On Sunday, September 01, 2013 10:56:02 AM Viresh Kumar wrote:
> >> We can't take a big lock around __cpufreq_governor() as this causes 
> >> recursive
> >> locking for some cases. But calls to this routine must be serialized for 
> >> every
> >> policy.
> >
> > Care to explain here why it must be serialized?
> 
> Yes, added that to the attached patches (Added reported-by too):

OK, the attached patches queued up for 3.12.

Thanks,
Rafael

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

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

[Sergey Senozhatsky]

On (08/31/13 01:04), Frederic Weisbecker wrote:
> > in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime - 
> > stime'
> > sets wrong value.
> 
> But stime should always be below rtime due to the calculation done by 
> scale_stime()
> which roughly sums up to:
> 
>   stime = (stime / stime + utime) * rtime
> 
> So this shouldn't happen.
> 
> I couldn't manage to reproduce it though. Can you still trigger it with 
> latest -next?
>

Hope this may help.
I've added a silly check to make sure that `stime < rtime'

@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force u64)total);
+   if (stime > rtime) {
+   printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", 
stime, rtime);
+   WARN_ON(1);
+   }
utime = rtime - stime;
} else {
stime = rtime;


and got the following results:


[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1295.311063] [ cut here ]
[ 1295.311072] WARNING: CPU: 1 PID: 2167 at kernel/sched/cputime.c:584 
cputime_adjust+0x132/0x140()
[ 1295.311123] CPU: 1 PID: 2167 Comm: top Tainted: G C   
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1295.311126] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1295.311128]  0009 880099937c50 8162fc85 

[ 1295.311134]  880099937c88 8104ee2d 8801530bb158 
880099937df0
[ 1295.311139]  0001138994d0 0001138994d1 880153118ff0 
880099937c98
[ 1295.311145] Call Trace:
[ 1295.311155]  [] dump_stack+0x4e/0x82
[ 1295.311162]  [] warn_slowpath_common+0x7d/0xa0
[ 1295.311166]  [] warn_slowpath_null+0x1a/0x20
[ 1295.311170]  [] cputime_adjust+0x132/0x140
[ 1295.311175]  [] thread_group_cputime_adjusted+0x41/0x50
[ 1295.311182]  [] do_task_stat+0x9c4/0xb50
[ 1295.311188]  [] proc_tgid_stat+0x14/0x20
[ 1295.311192]  [] proc_single_show+0x54/0xa0
[ 1295.311198]  [] seq_read+0x164/0x3d0
[ 1295.311204]  [] vfs_read+0xa1/0x180
[ 1295.311208]  [] SyS_read+0x4c/0xa0
[ 1295.311213]  [] tracesys+0xd4/0xd9
[ 1295.311216] ---[ end trace bab1e899ff45eea2 ]---

[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1301.384401] [ cut here ]
[ 1301.384409] WARNING: CPU: 0 PID: 2167 at kernel/sched/cputime.c:584 
cputime_adjust+0x132/0x140()
[ 1301.384450] CPU: 0 PID: 2167 Comm: top Tainted: GWC   
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1301.384452] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1301.384454]  0009 880099937c50 8162fc85 

[ 1301.384458]  880099937c88 8104ee2d 8801530bb158 
880099937df0
[ 1301.384462]  000115678476 000115678477 880153118ff0 
880099937c98
[ 1301.384466] Call Trace:
[ 1301.384475]  [] dump_stack+0x4e/0x82
[ 1301.384481]  [] warn_slowpath_common+0x7d/0xa0
[ 1301.384484]  [] warn_slowpath_null+0x1a/0x20
[ 1301.384487]  [] cputime_adjust+0x132/0x140
[ 1301.384491]  [] thread_group_cputime_adjusted+0x41/0x50
[ 1301.384497]  [] do_task_stat+0x9c4/0xb50
[ 1301.384501]  [] proc_tgid_stat+0x14/0x20
[ 1301.384504]  [] proc_single_show+0x54/0xa0
[ 1301.384509]  [] seq_read+0x164/0x3d0
[ 1301.384514]  [] vfs_read+0xa1/0x180
[ 1301.384517]  [] SyS_read+0x4c/0xa0
[ 1301.384521]  [] tracesys+0xd4/0xd9
[ 1301.384523] ---[ end trace bab1e899ff45eea3 ]---

and so on.


$ dmesg | grep Ooops
[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
[ 1313.493462] Ooops: stime:4724166945 rtime:4724166944
[ 1316.521740] Ooops: stime:4741142233 rtime:4741142232
[ 1325.605625] Ooops: stime:4793906690 rtime:4793906688
[ 1331.648611] Ooops: stime:4308413629 rtime:4308413628
[ 1337.708468] Ooops: stime:4510156747 rtime:4510156746
[ 1340.744586] Ooops: stime:4880584390 rtime:4880584389
[ 1343.773111] Ooops: stime:4442005879 rtime:4442005878
[ 1343.773362] Ooops: stime:4558310943 rtime:4558310942
[ 1349.815797] Ooops: stime:4927379646 rtime:4927379645
[ 1352.836936] Ooops: stime:4942782836 rtime:4942782834
[ 1358.885232] Ooops: stime:4979031940 rtime:4979031938
[ 1364.977902] Ooops: stime:5019633914 rtime:5019633912
[ 1364.978283] Ooops: stime:4601969101 rtime:4601969100
[ 1364.978623] Ooops: stime:4826393815 rtime:4826393814
[ 1371.034265] Ooops: stime:4894272175 rtime:4894272174
[ 1374.077150] Ooops: stime:4688831829 rtime:4688831828
[ 1374.077519] Ooops: stime:4916319315 rtime:4916319314
[ 1377.110416] Ooops: stime:5084174048 rtime:5084174047
[ 1377.111043] Ooops: stime:4949250198 rtime:4949250196
[ 1380.137382

can not debug using gdbserver

[Suki Buryani]

hi,

i am tring debug a application on an arm based device using gdbserver, in code 
i am trying to add `set_debug_traps' and `breakpoint' functions but its giving 
me compilation error something like

undefined reference to `set_debug_traps'
multisoc.c:594: undefined reference to `breakpoint'

i am also tring to debug my code with using these function, after successfull 
burn and listen from remote connection, i am trying to add break point from 
main() but it tries to make breakpoint in shared liberaies and do not stop at 
that point.

anybody have idea what i am missing, how i can successfull use up gdbserver

thanks

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

Re: [PATCH] ACPI / LPSS: don't crash if a device has no MMIO resources

[Rafael J. Wysocki]

On Monday, September 02, 2013 01:30:25 PM Mika Westerberg wrote:
> Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ
> resources returned in their _CRS method. However, Apple Macbook Air with
> Haswell has LPSS devices enumerated from PCI bus instead and _CRS method
> returns only an interrupt number (but the device has _HID set that causes
> the scan handler to match it).
> 
> The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource
> is found for the device and in case of Macbook Air it is never found. That
> leads to a NULL pointer dereference in register_device_clock().
> 
> Correct this by always setting the pdata->dev_desc.
> 
> Reported-and-tested-by: Imre Kaloz 
> Signed-off-by: Mika Westerberg 
> Cc: sta...@vger.kernel.org # 3.10+

Queued up for 3.12, thanks for taking care of this Mika!

> ---
>  drivers/acpi/acpi_lpss.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 6a38218..fb78bb9 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -257,12 +257,13 @@ static int acpi_lpss_create_device(struct acpi_device 
> *adev,
>   pdata->mmio_size = resource_size(>res);
>   pdata->mmio_base = ioremap(rentry->res.start,
>  pdata->mmio_size);
> - pdata->dev_desc = dev_desc;
>   break;
>   }
>  
>   acpi_dev_free_resource_list(_list);
>  
> + pdata->dev_desc = dev_desc;
> +
>   if (dev_desc->clk_required) {
>   ret = register_device_clock(adev, pdata);
>   if (ret) {
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.11-rc7:BUG: soft lockup

[Baoquan He]

On 09/02/2013 05:04 PM, Ding Tianhong wrote:
> On 2013/9/2 16:24, Baoquan He wrote:
>> Hi Tianhong,
>>
>> I applied your patch and execute below cmd. 
>> Then keyboard inputting problems happened, 
>> I can't enter user/password correctly, then reboot again, it's OK now.
> Thanks for your work, I don't understand that the keyboard problem is the 
> patch fault or your system problem, 
> if it is not happen again, I think the problem is fixed.

Yeah,  I will wait and see if it will happen again. Up to now, it's OK.

Thank you all for help.

Baoquan
Thanks

>
>> The original bug still can't be reproduced.
>>
>> make SUBDIRS=net/bridge/netfilter/
>> cp /net/bridge/netfilter/ebtables.ko
>> /lib/modules/3.11.0-rc7+/kernel/net/bridge/netfilter/ebtables.ko
>> depmod
>> modprobe ebtables.ko
>> reboot
>>
>> Baoquan
>> Thanks
>>
>>> please try this patch and give me the result, thanks.
>>>
>>> Return the correct value if mutex_lock_interruptible() failed, avoid
>>> confusion with that the modules is not exist, and deal with the return
>>> value in right way.
>>>
>>> if mutex_lock_interrupt() failed, sh
>>>
>>> Signed-off-by: root 
>>> ---
>>>  net/bridge/netfilter/ebtables.c | 17 +++--
>>>  1 file changed, 7 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/net/bridge/netfilter/ebtables.c 
>>> b/net/bridge/netfilter/ebtables.c
>>> index ac78024..e7fe9f8 100644
>>> --- a/net/bridge/netfilter/ebtables.c
>>> +++ b/net/bridge/netfilter/ebtables.c
>>> @@ -322,17 +322,14 @@ static inline void *
>>>  find_inlist_lock_noload(struct list_head *head, const char *name, int 
>>> *error,
>>> struct mutex *mutex)
>>>  {
>>> -   struct {
>>> -   struct list_head list;
>>> -   char name[EBT_FUNCTION_MAXNAMELEN];
>>> -   } *e;
>>> +   struct ebt_table *e;
>>>  
>>> *error = mutex_lock_interruptible(mutex);
>>> if (*error != 0)
>>> -   return NULL;
>>> +   return ERR_PTR(-EINTR);
>>>  
>>> list_for_each_entry(e, head, list) {
>>> -   if (strcmp(e->name, name) == 0)
>>> +if (strcmp(e->name, name) == 0 && try_module_get(e->me))
>>> return e;
>>> }
>>> *error = -ENOENT;
>>> @@ -1005,7 +1002,7 @@ static int do_replace_finish(struct net *net, struct 
>>> ebt_replace *repl,
>>> goto free_counterstmp;
>>>  
>>> t = find_table_lock(net, repl->name, , _mutex);
>>> -   if (!t) {
>>> +   if (IS_ERR_OR_NULL(t)) {
>>> ret = -ENOENT;
>>> goto free_iterate;
>>> }
>>> @@ -1284,7 +1281,7 @@ static int do_update_counters(struct net *net, const 
>>> char *name,
>>> return -ENOMEM;
>>>  
>>> t = find_table_lock(net, name, , _mutex);
>>> -   if (!t)
>>> +   if (IS_ERR_OR_NULL(t))
>>> goto free_tmp;
>>>  
>>> if (num_counters != t->private->nentries) {
>>> @@ -1504,7 +1501,7 @@ static int do_ebt_get_ctl(struct sock *sk, int cmd, 
>>> void __user *user, int *len)
>>> return -EFAULT;
>>>  
>>> t = find_table_lock(net, tmp.name, , _mutex);
>>> -   if (!t)
>>> +   if (IS_ERR_OR_NULL(t))
>>> return ret;
>>>  
>>> switch(cmd) {
>>> @@ -2319,7 +2316,7 @@ static int compat_do_ebt_get_ctl(struct sock *sk, int 
>>> cmd,
>>> return -EFAULT;
>>>  
>>> t = find_table_lock(net, tmp.name, , _mutex);
>>> -   if (!t)
>>> +   if (IS_ERR_OR_NULL(t))
>>> return ret;
>>>  
>>> xt_compat_lock(NFPROTO_BRIDGE);
>>
>> .
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/6] Remove the duplicated _MAT evaluation and simplify _acpi_map_lsapic()

[Rafael J. Wysocki]

On Monday, September 02, 2013 11:57:33 AM Hanjun Guo wrote:
> v1->v2: Return specific error value instead of just return -1, and
> correct some grammar mistake in changelog.
> 
> For cpu hot add, evaluate _MAT or parse MADT will did twice to get
> APIC id:
> acpi_processor_add()
>   acpi_processor_get_info()
>   acpi_get_cpuid() will evaluate _MAT or parse MADT;
> acpi_processor_hotadd_init()
> acpi_map_lsapic() will evaluate _MAT again;
> 
> This patch set introduces apic_id in struct processor to save parsed
> APIC id, and use it to remove the duplicated _MAT evaluation.
> 
> Further more, the new logical cpu number will be generated in
> acpi_register_lapic(), this can be returned to remove the cpumask
> allocation and operation to simplify _acpi_map_lsapic().
> 
> There are also some cleanups for the ACPI processor dirver code.

I like the series, so I've queued it up for 3.13.

Thanks,
Rafael


> Hanjun Guo (2):
>   ACPI / processor: remove unnecessary if (!pr) check
>   ACPI / processor: Remove outdated comments
> 
> Jiang Liu (4):
>   ACPI / processor: Introduce apic_id in struct processor to save
> parsed APIC id
>   ACPI / processor: use apic_id and remove duplicated _MAT evaluation
>   x86 / ACPI: simplify _acpi_map_lsapic()
>   ACPI / processor: remove some dead code in acpi_processor_get_info()
> 
>  arch/ia64/kernel/acpi.c   |   38 ++
>  arch/x86/include/asm/mpspec.h |2 +-
>  arch/x86/kernel/acpi/boot.c   |   88 
> +
>  arch/x86/kernel/apic/apic.c   |8 ++--
>  drivers/acpi/acpi_processor.c |   22 +++
>  drivers/acpi/processor_core.c |   26 +---
>  include/acpi/processor.h  |3 ++
>  include/linux/acpi.h  |2 +-
>  8 files changed, 60 insertions(+), 129 deletions(-)
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] dma: Add Freescale eDMA engine driver support

[Vinod Koul]

On Mon, Sep 02, 2013 at 07:32:53AM +, Lu Jingchang-B35083 wrote:
> > > > > > > + chan->private = fn_param;
> > > > > > why do you need to use chan->private?
> > > > > [Lu Jingchang]
> > > > > The private used here is to store the slot_id information, which
> > must
> > > > be used
> > > > > by the DMAMUX in alloc_chan_resources function. Thanks.
> > > > Why dont you pass this in struct dma_slave_config memeber slave_id
> > for
> > > > this.
> > > [Lu Jingchang-b35083]
> > > I will drop this private and setup the slave_id directly in the filter
> > function.
> > why in filter? before calling prepare function you can set the slave
> > config
> How about change the filter_fn to follow:
> static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
> {
> struct fsl_edma_filter_param *fparam = fn_param;
> struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> unsigned char val;
> 
> if (fsl_chan->edmamux->mux_id != fparam->mux_id)
> return false;
> 
> val = EDMAMUX_CHCFG_ENBL | EDMAMUX_CHCFG_SOURCE(fparam->slot_id);
> fsl_edmamux_config_chan(fsl_chan, val);
> return true;
> }
> In fact the slot_id isn't need elsewhere, and if the filter return true, 
> This channel should be to this request. So no need to save the slave id, 
> Right?
something like

static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
{
struct fsl_edma_filter_param *fparam = fn_param;
struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);

if (fsl_chan->edmamux->mux_id != fparam->mux_id)
return false;
return true;
}

in thedriver which calls this:

before prep:

config->slave_id = val;

dma_set_slave_config(chan, slave);

~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Memory synchronization vs. interrupt handlers

[Catalin Marinas]

On 26 August 2013 16:49, Alan Stern  wrote:
> Here's a question that doesn't seem to be answered in
> Documentation/memory-barriers.txt.  Are memory accesses within an
> interrupt handler synchronized with respect to interrupts?
>
> In more detail, suppose we have an interrupt handler that uses a memory
> variable A.  The device attached to the IRQ line sends two interrupt
> requests, and we get:
>
> CPU 0   CPU 1
> -   -
> Receive IRQ
> Call the interrupt handler
> Write A
> Finish IRQ processing
>
> Receive IRQ
> Call the interrupt handler
> Read A
> Finish IRQ processing
>
> Is CPU 0's write to A guaranteed to be visible on CPU 1?  Given that
> interrupts on an IRQ line are serialized, and that IRQ processing must
> involve some amount of memory barriers, I would expect the answer to be
> Yes.

On arm (or arm64), this is not guaranteed. Finishing the IRQ
processing usually involves a device write but there is no ordering
required with other write accesses. It could easily be fixed in the
IRQ controller code (drivers/irqchip/irq-gic.c for newer ARM
processors). We have a barrier for SMP cross-calls for the same
ordering reason, so I guess we need one for EOI as well.

In practice I would think it's nearly impossible to hit this issue,
given the time to save the state when taking the interrupt plus some
spinlocks, the write from CPU0 would become visible.

Also, if the data is accessed by the same driver with the same IRQ,
most likely the interrupt goes to the same CPU (unless you had some
rebalancing, but this being rarer it makes it less likely). If the
data is being accessed between two separate IRQ handlers, a spinlock
must be used anyway.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: fix accounting on page_remove_rmap()

[Kirill A. Shutemov]

There's typo in page_remove_rmap(): we increase NR_ANON_PAGES counter
instead of decreasing it. Let's fix this.

Signed-off-by: Kirill A. Shutemov 
Reported-by: Ning Qu 
---
 mm/rmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 52cc59a..6219f07 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1156,7 +1156,7 @@ void page_remove_rmap(struct page *page)
__dec_zone_page_state(page,
  NR_ANON_TRANSPARENT_HUGEPAGES);
__mod_zone_page_state(page_zone(page), NR_ANON_PAGES,
-   hpage_nr_pages(page));
+   -hpage_nr_pages(page));
} else {
__dec_zone_page_state(page, NR_FILE_MAPPED);
mem_cgroup_dec_page_stat(page, MEM_CGROUP_STAT_FILE_MAPPED);
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC

[Vineet Gupta]

Hi Gilad,

On 09/02/2013 02:33 PM, Gilad Ben-Yossef wrote:
> Hi,
>
> On Tue, Aug 27, 2013 at 11:31 AM, Vineet Gupta
>  wrote:
>> Frame pointer on ARC doesn't serve the conventional purpose of stack
>> unwinding due to the typical way ABI designates it's usage.
> More out of curiosity to understand the platform better than actual
> review - can you explain a little what
> you meant by this statement?
>
> Is this statement because of the use of write back mode with ld/st to
> or not related?

No - this is not related to to any LD/ST addressing/wb modes.

ARCompact ISA has 2 stack related registers, SP (top) and FP (Base)

A typical frame pointer-ish ABI would do sometime like this
1. push BLINK (return address)
2. push FP
3. FP = SP
4. push callee-regs
5. allocate stack for local vars etc
...

Note that beyond #3, FP remains constant while this function is in scope. Thus
from anywhere inside the function, [FP, 4] always has caller's PC and [FP, 0]
always has caller's FP. This makes it possible to retract back to caller and 
from
there to it's caller and so on.

However the ARC gcc ABI - set in stone many years ago doesn't do this. It does 
1,
4, 2, 3...

With FP no longer having base address of current call, it can't be used to get
FP/BLINK of prev frame so from stack unwinding perspective, there's no point in
using FP for stack frames. More importantly, FP usage bloats function
prologue/epilogue - adds extra stack ops,  hence it's usage in general is
discouraged. gcc though is free to summon it's usage for typical stack frames 
(var
sized arrays etc).

Hence the reason we don't ever build ARC with FP and need for this patch.

HTH,
-Vineet

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: roccat: Added support for KonePureOptical v2

[Jiri Kosina]

On Fri, 30 Aug 2013, Stefan Achatz wrote:

> KonePureOptical is a KonePure with different sensor.
> 
> Signed-off-by: Stefan Achatz 

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/23] thp: represent file thp pages in meminfo and friends

[Kirill A. Shutemov]

Ning Qu wrote:
> Hi, Kirill
> 
> I believe there is a typo in your previous commit, but you didn't include
> it in this series of patch set. Below is the link for the commit. I think
> you are trying to decrease the value NR_ANON_PAGES in page_remove_rmap, but
> it is currently adding the value instead when using __mod_zone_page_state.Let
> me know if you would like to fix it in your commit or you want another
> patch from me. Thanks!

The patch is already in Andrew's tree. I'll send a fix for that. Thanks.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: usbhid: quirk for N-Trig DuoSense Touch Screen

[Jiri Kosina]

On Fri, 30 Aug 2013, Vasily Titskiy wrote:

> The DuoSense touchscreen device causes a 10 second timeout. This fix
> removes the delay.
> 
> Signed-off-by: Vasily Titskiy 
> ---
>  drivers/hid/hid-ids.h   |1 +
>  drivers/hid/usbhid/hid-quirks.c |1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 2168885..376170e 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -646,6 +646,7 @@
>  #define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_16   0x0012
>  #define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_17   0x0013
>  #define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_18   0x0014
> +#define USB_DEVICE_ID_NTRIG_DUOSENSE 0x1500
> 
>  #define USB_VENDOR_ID_ONTRAK 0x0a07
>  #define USB_DEVICE_ID_ONTRAK_ADU100 0x0064
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 19b8360..1671b47 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -109,6 +109,7 @@ static const struct hid_blacklist {
>   { USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
> HID_QUIRK_NO_INIT_REPORTS },
>   { USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X,
> HID_QUIRK_MULTI_INPUT },
>   { USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X, HID_QUIRK_MULTI_INPUT 
> },
> + { USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE,
> HID_QUIRK_NO_INIT_REPORTS },
>   { 0, 0 }
>  };

Vasily,

your mail client is line-wrapping text, which causes corrupted patches.

I have fixed it up and applied, but please keep that in mind for your 
future submissions.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: ste_dma40: Remove duplicate const

[Vinod Koul]

On Mon, Sep 02, 2013 at 01:44:58PM +0530, Sachin Kamat wrote:
> 'const' was added twice.
> 
Applied, both thanks

~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: imx-dma: Remove redundant NULL check

[Vinod Koul]

On Mon, Sep 02, 2013 at 01:21:18PM +0530, Sachin Kamat wrote:
> kfree on a NULL pointer is a no-op. Null pointer check is
> not necessary.

Applied, thanks

~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: Correct the USB IDs for the new Macbook Air 6

[Jiri Kosina]

On Sun, 1 Sep 2013, Henrik Rydberg wrote:

> A recent patch (9d9a04ee) added support for the new machine, but got
> the sequence of USB ids wrong. Reports from both Ian and Linus T show
> that the 0x0291 id is for ISO, not ANSI, which should have the missing
> number 0x0290. This patchs moves the three numbers accordingly, fixing
> the problem.
> 
> Cc: Dmitry Torokhov 
> Reported-and-tested-by: Ian Munsie 
> Tested-by: Linus G Thiel 
> Signed-off-by: Henrik Rydberg 
> ---
> Hi Jiri, Dmitry,
> 
> it looks like this change has been sufficiently tested now, in
> addition to making perfect sense. Jiri, would you mind taking it, if
> Dmitry approves?

Absolutely ... waiting for Dmitry's Ack.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] pm2301-charger: Staticize pm2xxx_charger_die_therm_mngt

[Sachin Kamat]

pm2xxx_charger_die_therm_mngt is used only in this file.
Make it static.

Signed-off-by: Sachin Kamat 
Cc: Lee Jones 
---
 drivers/power/pm2301_charger.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index ab87d1a..b9e1ef7 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -205,7 +205,7 @@ static int pm2xxx_charger_batt_therm_mngt(struct 
pm2xxx_charger *pm2, int val)
 }
 
 
-int pm2xxx_charger_die_therm_mngt(struct pm2xxx_charger *pm2, int val)
+static int pm2xxx_charger_die_therm_mngt(struct pm2xxx_charger *pm2, int val)
 {
queue_work(pm2->charger_wq, >check_main_thermal_prot_work);
 
-- 
1.7.9.5

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

[PATCH 2/4] ab8500-charger: Remove redundant break

[Sachin Kamat]

Each of the if-else blocks has a break statement.
Remove the additional one which is unreachable.

Signed-off-by: Sachin Kamat 
---
 drivers/power/ab8500_charger.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
index fec0546..608b63e 100644
--- a/drivers/power/ab8500_charger.c
+++ b/drivers/power/ab8500_charger.c
@@ -766,7 +766,6 @@ static int ab8500_charger_max_usb_curr(struct 
ab8500_charger *di,
ret = -ENXIO;
break;
}
-   break;
case USB_STAT_CARKIT_1:
case USB_STAT_CARKIT_2:
case USB_STAT_ACA_DOCK_CHARGER:
-- 
1.7.9.5

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

[PATCH 1/4] ab8500-charger: Check return value of regulator_enable

[Sachin Kamat]

Check the return value of regulator_enable to silence the following
type of warnings:
drivers/power/ab8500_charger.c:1390:20: warning: ignoring return value
of ‘regulator_enable’, declared with attribute warn_unused_result
[-Wunused-result]

Signed-off-by: Sachin Kamat 
Cc: Lee Jones 
---
 drivers/power/ab8500_charger.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
index a4c4a10..fec0546 100644
--- a/drivers/power/ab8500_charger.c
+++ b/drivers/power/ab8500_charger.c
@@ -1387,7 +1387,12 @@ static int ab8500_charger_ac_en(struct ux500_charger 
*charger,
 * the GPADC module independant of the AB8500 chargers
 */
if (!di->vddadc_en_ac) {
-   regulator_enable(di->regu);
+   ret = regulator_enable(di->regu);
+   if (ret) {
+   dev_err(di->dev,
+   "Failed to enable regulator\n");
+   return ret;
+   }
di->vddadc_en_ac = true;
}
 
@@ -1556,7 +1561,12 @@ static int ab8500_charger_usb_en(struct ux500_charger 
*charger,
 * the GPADC module independant of the AB8500 chargers
 */
if (!di->vddadc_en_usb) {
-   regulator_enable(di->regu);
+   ret = regulator_enable(di->regu);
+   if (ret) {
+   dev_err(di->dev,
+   "Failed to enable regulator\n");
+   return ret;
+   }
di->vddadc_en_usb = true;
}
 
-- 
1.7.9.5

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

[PATCH 3/4] pm2301-charger: Check return value of regulator_enable

[Sachin Kamat]

Check the return value of regulator_enable to silence the following
warning:
drivers/power/pm2301_charger.c:725:20: warning:
ignoring return value of ‘regulator_enable’, declared with
attribute warn_unused_result [-Wunused-result]

Signed-off-by: Sachin Kamat 
Cc: Lee Jones 
---
 drivers/power/pm2301_charger.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index ffa10ed..ab87d1a 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -722,7 +722,12 @@ static int pm2xxx_charger_ac_en(struct ux500_charger 
*charger,
 
dev_dbg(pm2->dev, "Enable AC: %dmV %dmA\n", vset, iset);
if (!pm2->vddadc_en_ac) {
-   regulator_enable(pm2->regu);
+   ret = regulator_enable(pm2->regu);
+   if (ret) {
+   dev_err(pm2->dev,
+   "Failed to enable regulator\n");
+   goto error_occured;
+   }
pm2->vddadc_en_ac = true;
}
 
-- 
1.7.9.5

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

[PATCH 3/5] uas: rename work list lock + list field

[Gerd Hoffmann]

This patch prepares for the addition of another list and renames the
work list lock and the list_head field in struct uas_cmd_info.

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/uas.c | 50 +++
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f89202f..a63972a 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -77,7 +77,7 @@ struct uas_cmd_info {
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
-   struct list_head list;
+   struct list_head work;
 };
 
 /* I hate forward declarations, but I actually have a loop */
@@ -89,7 +89,7 @@ static void uas_configure_endpoints(struct uas_dev_info 
*devinfo);
 static void uas_free_streams(struct uas_dev_info *devinfo);
 
 static DECLARE_WORK(uas_work, uas_do_work);
-static DEFINE_SPINLOCK(uas_work_lock);
+static DEFINE_SPINLOCK(uas_lists_lock);
 static LIST_HEAD(uas_work_list);
 
 static void uas_unlink_data_urbs(struct uas_dev_info *devinfo,
@@ -124,11 +124,11 @@ static void uas_do_work(struct work_struct *work)
unsigned long flags;
int err;
 
-   spin_lock_irq(_work_lock);
+   spin_lock_irq(_lists_lock);
list_replace_init(_work_list, );
-   spin_unlock_irq(_work_lock);
+   spin_unlock_irq(_lists_lock);
 
-   list_for_each_entry_safe(cmdinfo, temp, , list) {
+   list_for_each_entry_safe(cmdinfo, temp, , work) {
struct scsi_pointer *scp = (void *)cmdinfo;
struct scsi_cmnd *cmnd = container_of(scp,
struct scsi_cmnd, SCp);
@@ -139,10 +139,10 @@ static void uas_do_work(struct work_struct *work)
cmdinfo->state &= ~IS_IN_WORK_LIST;
spin_unlock_irqrestore(>lock, flags);
if (err) {
-   list_del(>list);
-   spin_lock_irq(_work_lock);
-   list_add_tail(>list, _work_list);
-   spin_unlock_irq(_work_lock);
+   list_del(>work);
+   spin_lock_irq(_lists_lock);
+   list_add_tail(>work, _work_list);
+   spin_unlock_irq(_lists_lock);
schedule_work(_work);
}
}
@@ -155,12 +155,12 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
struct list_head list;
unsigned long flags;
 
-   spin_lock_irq(_work_lock);
+   spin_lock_irq(_lists_lock);
list_replace_init(_work_list, );
-   spin_unlock_irq(_work_lock);
+   spin_unlock_irq(_lists_lock);
 
spin_lock_irqsave(>lock, flags);
-   list_for_each_entry_safe(cmdinfo, temp, , list) {
+   list_for_each_entry_safe(cmdinfo, temp, , work) {
struct scsi_pointer *scp = (void *)cmdinfo;
struct scsi_cmnd *cmnd = container_of(scp,
struct scsi_cmnd, SCp);
@@ -178,10 +178,10 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
uas_try_complete(cmnd, __func__);
} else {
/* not our uas device, relink into list */
-   list_del(>list);
-   spin_lock_irq(_work_lock);
-   list_add_tail(>list, _work_list);
-   spin_unlock_irq(_work_lock);
+   list_del(>work);
+   spin_lock_irq(_lists_lock);
+   list_add_tail(>work, _work_list);
+   spin_unlock_irq(_lists_lock);
}
}
spin_unlock_irqrestore(>lock, flags);
@@ -288,10 +288,10 @@ static void uas_xfer_data(struct urb *urb, struct 
scsi_cmnd *cmnd,
cmdinfo->state |= direction | SUBMIT_STATUS_URB;
err = uas_submit_urbs(cmnd, cmnd->device->hostdata, GFP_ATOMIC);
if (err) {
-   spin_lock(_work_lock);
-   list_add_tail(>list, _work_list);
+   spin_lock(_lists_lock);
+   list_add_tail(>work, _work_list);
cmdinfo->state |= IS_IN_WORK_LIST;
-   spin_unlock(_work_lock);
+   spin_unlock(_lists_lock);
schedule_work(_work);
}
 }
@@ -694,10 +694,10 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
spin_unlock_irqrestore(>lock, flags);
return SCSI_MLQUEUE_DEVICE_BUSY;
}
-   spin_lock(_work_lock);
-   list_add_tail(>list, _work_list);
+   spin_lock(_lists_lock);
+   list_add_tail(>work, _work_list);
cmdinfo->state |= IS_IN_WORK_LIST;
-   spin_unlock(_work_lock);
+   spin_unlock(_lists_lock);
schedule_work(_work);
}
 

[PATCH 2/5] uas: properly reinitialize in uas_eh_bus_reset_handler

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/uas.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index d966b59..f89202f 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -85,6 +85,8 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
struct uas_dev_info *devinfo, gfp_t gfp);
 static void uas_do_work(struct work_struct *work);
 static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller);
+static void uas_configure_endpoints(struct uas_dev_info *devinfo);
+static void uas_free_streams(struct uas_dev_info *devinfo);
 
 static DECLARE_WORK(uas_work, uas_do_work);
 static DEFINE_SPINLOCK(uas_work_lock);
@@ -800,7 +802,11 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd)
usb_kill_anchored_urbs(>cmd_urbs);
usb_kill_anchored_urbs(>sense_urbs);
usb_kill_anchored_urbs(>data_urbs);
+   uas_free_streams(devinfo);
err = usb_reset_device(udev);
+   if (!err) {
+   uas_configure_endpoints(devinfo);
+   }
devinfo->resetting = 0;
 
if (err) {
-- 
1.8.3.1

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

[PATCH 4/5] uas: add dead request list

[Gerd Hoffmann]

This patch adds a new list where all requests which are canceled are
added to, so we don't loose them.  Then, after killing all inflight
urbs on bus reset (and disconnect) we'll walk over the list and clean
them up.

Without this we can end up with aborted requests lingering around in
case of status pipe transfer errors.

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/uas.c | 69 +--
 1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index a63972a..9dfb8f9 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -78,6 +78,7 @@ struct uas_cmd_info {
struct urb *data_in_urb;
struct urb *data_out_urb;
struct list_head work;
+   struct list_head dead;
 };
 
 /* I hate forward declarations, but I actually have a loop */
@@ -87,10 +88,12 @@ static void uas_do_work(struct work_struct *work);
 static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller);
 static void uas_configure_endpoints(struct uas_dev_info *devinfo);
 static void uas_free_streams(struct uas_dev_info *devinfo);
+static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const char *caller);
 
 static DECLARE_WORK(uas_work, uas_do_work);
 static DEFINE_SPINLOCK(uas_lists_lock);
 static LIST_HEAD(uas_work_list);
+static LIST_HEAD(uas_dead_list);
 
 static void uas_unlink_data_urbs(struct uas_dev_info *devinfo,
 struct uas_cmd_info *cmdinfo)
@@ -167,15 +170,13 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
struct uas_dev_info *di = (void *)cmnd->device->hostdata;
 
if (di == devinfo) {
+   uas_log_cmd_state(cmnd, __func__);
+   BUG_ON(cmdinfo->state & COMMAND_ABORTED);
cmdinfo->state |= COMMAND_ABORTED;
+   spin_lock_irq(_lists_lock);
+   list_add_tail(>dead, _dead_list);
+   spin_unlock_irq(_lists_lock);
cmdinfo->state &= ~IS_IN_WORK_LIST;
-   if (devinfo->resetting) {
-   /* uas_stat_cmplt() will not do that
-* when a device reset is in
-* progress */
-   cmdinfo->state &= ~COMMAND_INFLIGHT;
-   }
-   uas_try_complete(cmnd, __func__);
} else {
/* not our uas device, relink into list */
list_del(>work);
@@ -187,6 +188,43 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
spin_unlock_irqrestore(>lock, flags);
 }
 
+static void uas_zap_dead(struct uas_dev_info *devinfo)
+{
+   struct uas_cmd_info *cmdinfo;
+   struct uas_cmd_info *temp;
+   struct list_head list;
+   unsigned long flags;
+
+   spin_lock_irq(_lists_lock);
+   list_replace_init(_dead_list, );
+   spin_unlock_irq(_lists_lock);
+
+   spin_lock_irqsave(>lock, flags);
+   list_for_each_entry_safe(cmdinfo, temp, , dead) {
+   struct scsi_pointer *scp = (void *)cmdinfo;
+   struct scsi_cmnd *cmnd = container_of(scp,
+   struct scsi_cmnd, SCp);
+   struct uas_dev_info *di = (void *)cmnd->device->hostdata;
+
+   if (di == devinfo) {
+   uas_log_cmd_state(cmnd, __func__);
+   BUG_ON(!(cmdinfo->state & COMMAND_ABORTED));
+   /* all urbs are killed, clear inflight bits */
+   cmdinfo->state &= ~(COMMAND_INFLIGHT |
+   DATA_IN_URB_INFLIGHT |
+   DATA_OUT_URB_INFLIGHT);
+   uas_try_complete(cmnd, __func__);
+   } else {
+   /* not our uas device, relink into list */
+   list_del(>dead);
+   spin_lock_irq(_lists_lock);
+   list_add_tail(>dead, _dead_list);
+   spin_unlock_irq(_lists_lock);
+   }
+   }
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 static void uas_sense(struct urb *urb, struct scsi_cmnd *cmnd)
 {
struct sense_iu *sense_iu = urb->transfer_buffer;
@@ -274,6 +312,9 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
char *caller)
if (cmdinfo->state & COMMAND_ABORTED) {
scmd_printk(KERN_INFO, cmnd, "abort completed\n");
cmnd->result = DID_ABORT << 16;
+   spin_lock_irq(_lists_lock);
+   list_del(>dead);
+   spin_unlock_irq(_lists_lock);
}
cmnd->scsi_done(cmnd);
return 0;
@@ -307,7 +348,12 @@ static void uas_stat_cmplt(struct urb *urb)
u16 tag;
 
if (urb->status) {
-  

[PATCH 5/5] uas: remove BROKEN

[Gerd Hoffmann]

xhci streams support is fixed, unblock usb attached scsi.

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig
index 8470e1b..4761a28 100644
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -202,7 +202,7 @@ config USB_STORAGE_ENE_UB6250
 
 config USB_UAS
tristate "USB Attached SCSI"
-   depends on SCSI && BROKEN
+   depends on SCSI
help
  The USB Attached SCSI protocol is supported by some USB
  storage devices.  It permits higher performance by supporting
-- 
1.8.3.1

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

[PATCH 1/5] xhci: fix usb3 streams

[Gerd Hoffmann]

xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring.  Each ring segment
must be added to the ring for this to work.  Currently xhci sticks
only the first segment of each stream ring into the radix tree.

Result is that things work initially, but as soon as the first segment
is full xhci can't map the trb address from the completion event to the
stream ring any more -> BOOM.  You'll find this message in the logs:

  ERROR Transfer event for disabled endpoint or incorrect stream ring

This patch adds a helper function to update the radix tree.  It can
both insert and remove ring segments.  It loops over the segment list
and handles all segments instead of just the first.  It is called
whenever an update is needed:  When allocating a ring, when expanding
a ring and when releasing a ring.

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/host/xhci-mem.c | 51 +
 drivers/usb/host/xhci.h |  2 ++
 2 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6f8c2fd..c7fd88f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -154,8 +154,11 @@ void xhci_ring_free(struct xhci_hcd *xhci, struct 
xhci_ring *ring)
if (!ring)
return;
 
-   if (ring->first_seg)
+   if (ring->first_seg) {
+   if (ring->type == TYPE_STREAM)
+   xhci_update_stream_ring(ring, false);
xhci_free_segments_for_ring(xhci, ring->first_seg);
+   }
 
kfree(ring);
 }
@@ -351,6 +354,11 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
xhci_dbg(xhci, "ring expansion succeed, now has %d segments\n",
ring->num_segs);
 
+   if (ring->type == TYPE_STREAM) {
+   ret = xhci_update_stream_ring(ring, true);
+   WARN_ON(ret); /* FIXME */
+   }
+
return 0;
 }
 
@@ -601,6 +609,33 @@ static int xhci_test_radix_tree(struct xhci_hcd *xhci,
  * extended systems (where the DMA address can be bigger than 32-bits),
  * if we allow the PCI dma mask to be bigger than 32-bits.  So don't do that.
  */
+
+int xhci_update_stream_ring(struct xhci_ring *ring, bool insert)
+{
+   struct xhci_segment *seg;
+   unsigned long key;
+   bool present;
+   int ret;
+
+   BUG_ON(ring->trb_address_map == NULL);
+   seg = ring->first_seg;
+   do {
+   key = (unsigned long)(seg->dma >> TRB_SEGMENT_SHIFT);
+   present = radix_tree_lookup(ring->trb_address_map, key) != NULL;
+   if (!present && insert) {
+   ret = radix_tree_insert(ring->trb_address_map, key, 
ring);
+   if (ret)
+   return ret;
+   }
+   if (present && !insert) {
+   radix_tree_delete(ring->trb_address_map, key);
+   }
+   seg = seg->next;
+   } while (seg != ring->first_seg);
+
+   return 0;
+}
+
 struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
unsigned int num_streams, gfp_t mem_flags)
@@ -608,7 +643,6 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
struct xhci_stream_info *stream_info;
u32 cur_stream;
struct xhci_ring *cur_ring;
-   unsigned long key;
u64 addr;
int ret;
 
@@ -663,6 +697,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
if (!cur_ring)
goto cleanup_rings;
cur_ring->stream_id = cur_stream;
+   cur_ring->trb_address_map = _info->trb_address_map;
/* Set deq ptr, cycle bit, and stream context type */
addr = cur_ring->first_seg->dma |
SCT_FOR_CTX(SCT_PRI_TR) |
@@ -672,10 +707,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
xhci_dbg(xhci, "Setting stream %d ring ptr to 0x%08llx\n",
cur_stream, (unsigned long long) addr);
 
-   key = (unsigned long)
-   (cur_ring->first_seg->dma >> TRB_SEGMENT_SHIFT);
-   ret = radix_tree_insert(_info->trb_address_map,
-   key, cur_ring);
+   ret = xhci_update_stream_ring(cur_ring, true);
if (ret) {
xhci_ring_free(xhci, cur_ring);
stream_info->stream_rings[cur_stream] = NULL;
@@ -702,9 +734,6 @@ cleanup_rings:
for (cur_stream = 1; cur_stream < num_streams; cur_stream++) {
cur_ring = stream_info->stream_rings[cur_stream];
if (cur_ring) {
-   addr = cur_ring->first_seg->dma;
-   

Re: Clock framework deadlock with external SPI clockchip

[Peter De Schrijver]

On Fri, Aug 30, 2013 at 03:24:45PM +0200, Lars-Peter Clausen wrote:
> Hi,
> 
> I'm currently facing a deadlock in the common clock framework that
> unfortunately is not addressed by the reentrancy patches. I have a external
> clock chip that is controlled via SPI. So for example to configure the rate
> of the clock chip you need to send a SPI message. Naturally the clock
> framework will hold the prepare lock while configuring the rate.
> Communication in the SPI framework happens asynchronously, spi_sync() will
> enqueue a message in the SPI masters queue and then wait using
> wait_for_completion(). The master will call complete() once the transfer has
> been finished. The SPI master runs in it's own thread in which it processes
> the messages. In this thread it also calls clk_set_rate() to configure the
> SPI transfer clock rate based on what the message says. Now the deadlock
> happens as we try to take the prepare_lock again and since the clock chip
> and the SPI master run in different threads the reentrancy code does not
> kick in.
> 
> The basic sequence is like this:
> 
> === Clock chip driver ====== SPI master driver ===
>  clk_prepare_lock()
>  spi_sync()
>wait_for_completion(X)
>  clk_get_rate()
>  clk_prepare_lock() <--- DEADLOCK
>  clk_prepare_unlock()
>...
>complete(X)
>  ...
>  clk_prepare_unlock()
> 
> I'm wondering if you have any idea how this can be fixed. In my opinion we'd
> need a per clock mutex to address this properly.

One workaround is to leave the SPI masters clock always prepared. A similar
problem can occur with I2C and DVFS using notifiers.

Cheers,

Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: add driver for R-Car HPB-DMAC

[Vinod Koul]

On Sun, Aug 25, 2013 at 12:33:24AM +0400, Sergei Shtylyov wrote:
> From: Max Filippov 
> 
> Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA 
> driver framework.
> 
> Based on the original patch by Phil Edworthy .
> 
> Signed-off-by: Max Filippov 
> [Sergei: removed useless #include, sorted #include's, fixed HPB_DMA_TCR_MAX,
> fixed formats and removed line breaks in the dev_dbg() calls, rephrased and
> added IRQ # to the shdma_request_irq() failure message, added MODULE_AUTHOR(),
> removed '__init'/'__exit' annotations from the probe()/remove() methods, 
> removed
> '__initdata' annotation from 'hpb_dmae_driver', fixed guard macro name in the
> header file, fixed #define ASYNCRSTR_ASRST20, added #define ASYNCRSTR_ASRST24,
> added the necessary runtime PM calls to the probe() and remove() methods,
> handled errors returned by dma_async_device_register(), beautified comments
> and #define's.]
> Signed-off-by: Sergei Shtylyov 
Applied, thanks

~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thp: support split page table lock

[Kirill A. Shutemov]

Naoya Horiguchi wrote:
> Thp related code also uses per process mm->page_table_lock now. So making
> it fine-grained can provide better performance.
> 
> This patch makes thp support split page table lock which makes us use
> page->ptl of the pages storing "pmd_trans_huge" pmds.

Hm. So, you use page->ptl only when you deal with thp pages, otherwise
mm->page_table_lock, right?

It looks inconsistent to me. Does it mean we have to take both locks on
split and collapse paths? I'm not sure if it's safe to take only
page->ptl for alloc path. Probably not.

Why not to use new locking for pmd everywhere?

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

Re: [RFC PATCH 1/2] i2c: prepare runtime PM support for I2C client devices

[Mika Westerberg]

On Wed, Aug 28, 2013 at 11:38:58AM +0200, Wolfram Sang wrote:
> On Tue, Aug 20, 2013 at 05:03:35PM +0300, Mika Westerberg wrote:
> > From: Aaron Lu 
> > 
> > This patch adds runtime PM support for the I2C bus in a similar way that
> > has been done for PCI bus already. This means that the I2C bus core
> > prepares runtime PM for a client device just before a driver is about to be
> > bound to it. Devices that are not bound to any driver are not prepared for
> > runtime PM.
> > 
> > In order to take advantage of this runtime PM support, the client device
> > driver needs drop the device runtime PM reference count by calling
> > pm_runtime_put() in its ->probe() callback and possibly implement rest of
> > the runtime PM callbacks.
> > 
> > However, this does not yet make runtime PM happen for the device, it has to
> > be explicitly allowed from userspace per each I2C client device. The
> > reason for this is that things like HID over I2C might not work as smoothly
> > when runtime PM is active. So we leave it to the user to balance between
> > performance and power efficiency.
> > 
> > User can allow runtime PM for the client device by running:
> > 
> > # echo auto > /sys/bus/i2c/devices//power/control
> > 
> > and it can be forbidden again by:
> > 
> > # echo on > /sys/bus/i2c/devices//power/control
> > 
> > Status of the device can be monitored by reading files under the device
> > power directory.
> > 
> > If the driver doesn't support runtime PM (like most of the existing I2C
> > client drivers), the device in question is regarded as being runtime PM
> > active and powered on.
> > 
> > The patch adds also runtime PM support for the adapter device because it is
> > needed to be able to runtime power manage the I2C controller device. The
> > adapter device is handled along with the I2C controller device (it uses
> > pm_runtime_no_callbacks()).
> > 
> > Signed-off-by: Aaron Lu 
> > Signed-off-by: Mika Westerberg 
> 
> CCing ALKML. Would appreciate comments/tags from the runtime-PM users of
> the ARM world.

Any comments on this?

I can resend the whole series with ALKML included if that helps.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/