[PATCH v12 1/6] PM / Runtime: Add getter for querying the IRQ safe option
Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime
PM IRQ safe was set or not.
Various bus drivers implementing runtime PM may use choose to suspend
differently based on IRQ safeness status of child driver (e.g. do not
unprepare the clock if IRQ safe is not set).
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Ulf Hansson
Acked-by: Rafael J. Wysocki
---
Documentation/power/runtime_pm.txt | 4
include/linux/pm_runtime.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/Documentation/power/runtime_pm.txt
b/Documentation/power/runtime_pm.txt
index 0e5ea26b255a..44fe1d28a163 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -468,6 +468,10 @@ drivers/base/power/runtime.c and
include/linux/pm_runtime.h:
- set the power.irq_safe flag for the device, causing the runtime-PM
callbacks to be invoked with interrupts off
+ bool pm_runtime_is_irq_safe(struct device *dev);
+- return true if power.irq_safe flag was set for the device, causing
+ the runtime-PM callbacks to be invoked with interrupts off
+
void pm_runtime_mark_last_busy(struct device *dev);
- set the power.last_busy field to the current time
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 367f49b9a1c9..44d74f0f182e 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -128,6 +128,11 @@ static inline void pm_runtime_mark_last_busy(struct device
*dev)
ACCESS_ONCE(dev->power.last_busy) = jiffies;
}
+static inline bool pm_runtime_is_irq_safe(struct device *dev)
+{
+ return dev->power.irq_safe;
+}
+
#else /* !CONFIG_PM_RUNTIME */
static inline int __pm_runtime_idle(struct device *dev, int rpmflags)
@@ -167,6 +172,7 @@ static inline bool pm_runtime_enabled(struct device *dev) {
return false; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
static inline void pm_runtime_irq_safe(struct device *dev) {}
+static inline bool pm_runtime_is_irq_safe(struct device *dev) { return false; }
static inline bool pm_runtime_callbacks_present(struct device *dev) { return
false; }
static inline void pm_runtime_mark_last_busy(struct device *dev) {}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] mm, compaction: pass classzone_idx and alloc_flags to watermark checking
On 10/31/2014 08:49 AM, Joonsoo Kim wrote: > On Wed, Oct 29, 2014 at 02:51:11PM +0100, Vlastimil Babka wrote: >> On 10/28/2014 08:16 AM, Joonsoo Kim wrote:> On Mon, Oct 27, 2014 at >> 10:11:31AM +0100, Vlastimil Babka wrote: >> >> I thought that the second check in compaction_suitable() makes sure >> of this, but now I see it's in fact not. >> But i'm not sure if we should just put the flags in the first check, >> as IMHO the flags should only affect the final high-order >> allocation, not also the temporary pages needed for migration? > > I don't think so. > As mentioned before, if we don't have not enough freepages, compaction > will fail due to shortage of freepage at final high-order watermark > check. Maybe it failes due to not enough freepage rather than ordered > freepage. Proper flags and index make us avoid useless compaction so > I prefer put the flags in the first check. > >> >> BTW now I'm not even sure that the 2UL << order part makes sense >> anymore. The number of pages migrated at once is always restricted >> by COMPACT_CLUSTER_MAX, so why would we need more than that to cover >> migration? > > In fact, any values seems to be wrong. We can isolate high order freepage > for this temporary use. I don't have any idea what the proper value is. > >> Also the order of checks seems wrong. It should return >> COMPACT_PARTIAL "If the allocation would succeed without compaction" >> but that only can happen after passing the check if the zone has the >> extra 1UL << order for migration. Do you agree? > > Yes, agree! > >>> I guess that __isolate_free_page() is also good candidate to need this >>> information in order to prevent compaction from isolating too many >>> freepage in low memory condition. >> >> I don't see how it would help here. It's temporary allocations for >> page migration. How would passing classzone_idx and alloc_flags >> prevent isolating too many? > > It is temporary allocation, but, anyway, it could holds many freepage > in some duration. As mentioned above, if we isolate high order freepage, > we can hold 1MB or more freepage at once. I guess that passing flags helps > system stability. OK, here's a patch-fix to address everything discussed above. My testing didn't show much difference, but I know it's limited anyway. --8<-- From: Vlastimil Babka Date: Mon, 3 Nov 2014 15:26:40 +0100 Subject: mm-compaction-pass-classzone_idx-and-alloc_flags-to-watermark-checking-fix This patch-fix changes zone watermark checking in compaction_suitable() as we discussed with Joonsoo Kim. First, it moves up the watermark check for answering the question "does the zone need compaction at all?". Before this change, the check is preceded by a check that answers the question "does the zone have enough free pages to succeed compaction". So it might happen that there is already a high-order page available, but not enough pages for performing the compaction (which assumes extra pages for the migrations). Before the patch, compaction_suitable() would return COMPACT_SKIPPED which means "compaction cannot succeed, reclaim more", after this change it returns COMPACT_PARTIAL which means "compaction not needed, try allocating". Second, the check for answering "can the compaction succeed?" now also includes classzone_idx and alloc_flags parameters. This prevents starting compaction that would not lead to successful allocation due to not having enough free pages. The addition of extra pages for migration is left in the check. Although these are temporary allocations and thus should not be affected by alloc_flags and classzone_idx, it only matters when we are close to the watermark, where it does not hurt to be a bit pessimistic. Signed-off-by: Vlastimil Babka Cc: Minchan Kim Cc: Mel Gorman Cc: Joonsoo Kim Cc: Michal Nazarewicz Cc: Naoya Horiguchi Cc: Christoph Lameter Cc: Rik van Riel Cc: David Rientjes --- When squashed, full changelog of the patch+fix should be: Compaction relies on zone watermark checks for decisions such as if it's worth to start compacting in compaction_suitable() or whether compaction should stop in compact_finished(). The watermark checks take classzone_idx and alloc_flags parameters, which are related to the memory allocation request. But from the context of compaction they are currently passed as 0, including the direct compaction which is invoked to satisfy the allocation request, and could therefore know the proper values. The lack of proper values can lead to mismatch between decisions taken during compaction and decisions related to the allocation request. Lack of proper classzone_idx value means that lowmem_reserve is not taken into account. This has manifested (during recent changes to deferred compaction) when DMA zone was used as fallback for preferred Normal zone. compaction_suitable() without proper classzone_idx would think that the watermarks are already satisfied, but watermark check in get_page_from_freelist() would fail. Because of
Re: [PATCH v4 0/3] Rework "xhci: clear root port wake on bits if controller isn't wake-up capable"
On 14.11.2014 05:14, Lu, Baolu wrote: > Hi Mathias, > > This patch series has been acked by Alan Stern. There seems no further > comments from others. Can you please pull in it? > > Thanks, > -baolu > Ah, yes, thanks for reminding, I'll pull them in and send them forward. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v12 5/6] dmaengine: pl330: Add PM sleep support
Add system suspend/resume capabilities to the pl330 driver so the amba
bus clock could be also unprepared to conserve energy.
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma/pl330.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index c3bd3584f261..e499bb118f0a 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2627,6 +2627,46 @@ static int pl330_dma_device_slave_caps(struct dma_chan
*dchan,
return 0;
}
+/*
+ * Runtime PM callbacks are provided by amba/bus.c driver.
+ *
+ * It is assumed here that IRQ safe runtime PM is chosen in probe and amba
+ * bus driver will only disable/enable the clock in runtime PM callbacks.
+ */
+static int __maybe_unused pl330_suspend(struct device *dev)
+{
+ struct amba_device *pcdev = to_amba_device(dev);
+
+ pm_runtime_disable(dev);
+
+ if (!pm_runtime_status_suspended(dev)) {
+ /* amba did not disable the clock */
+ amba_pclk_disable(pcdev);
+ }
+ amba_pclk_unprepare(pcdev);
+
+ return 0;
+}
+
+static int __maybe_unused pl330_resume(struct device *dev)
+{
+ struct amba_device *pcdev = to_amba_device(dev);
+ int ret;
+
+ ret = amba_pclk_prepare(pcdev);
+ if (ret)
+ return ret;
+
+ if (!pm_runtime_status_suspended(dev))
+ ret = amba_pclk_enable(pcdev);
+
+ pm_runtime_enable(dev);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(pl330_pm, pl330_suspend, pl330_resume);
+
static int
pl330_probe(struct amba_device *adev, const struct amba_id *id)
{
@@ -2853,6 +2893,7 @@ static struct amba_driver pl330_driver = {
.drv = {
.owner = THIS_MODULE,
.name = "dma-pl330",
+ .pm = _pm,
},
.id_table = pl330_ids,
.probe = pl330_probe,
--
1.9.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 v12 4/6] dmaengine: pl330: Add runtime Power Management support
This patch adds runtime PM support to pl330 DMA engine driver.
The runtime power management for pl330 DMA driver allows gating of AMBA
clock (PDMA) in FSYS clock domain, when the device is not processing any
requests. This is necessary to enter low power modes on Exynos SoCs
(e.g. LPA on Exynos4x12 or W-AFTR on Exynos3250).
Runtime PM resuming of the device may happen in atomic context (during
call device_issue_pending()) so pm_runtime_irq_safe() is used. This will
lead only to disabling/enabling of the clock but this is sufficient for
gating the clock and for reducing energy usage.
Driver uses runtime PM callbacks from amba/bus.c driver only.
Suggested-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Ulf Hansson
Acked-by: Vinod Koul
---
drivers/dma/pl330.c | 58 +
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 83e2257c324a..c3bd3584f261 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "dmaengine.h"
#define PL330_MAX_CHAN 8
@@ -265,6 +266,9 @@ static unsigned cmd_line;
#define NR_DEFAULT_DESC16
+/* Delay for runtime PM autosuspend, ms */
+#define PL330_AUTOSUSPEND_DELAY 20
+
/* Populated by the PL330 core driver for DMA API driver's info */
struct pl330_config {
u32 periph_id;
@@ -1958,6 +1962,7 @@ static void pl330_tasklet(unsigned long data)
struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
struct dma_pl330_desc *desc, *_dt;
unsigned long flags;
+ bool power_down = false;
spin_lock_irqsave(>lock, flags);
@@ -1972,10 +1977,17 @@ static void pl330_tasklet(unsigned long data)
/* Try to submit a req imm. next to the last completed cookie */
fill_queue(pch);
- /* Make sure the PL330 Channel thread is active */
- spin_lock(>thread->dmac->lock);
- _start(pch->thread);
- spin_unlock(>thread->dmac->lock);
+ if (list_empty(>work_list)) {
+ spin_lock(>thread->dmac->lock);
+ _stop(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ power_down = true;
+ } else {
+ /* Make sure the PL330 Channel thread is active */
+ spin_lock(>thread->dmac->lock);
+ _start(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ }
while (!list_empty(>completed_list)) {
dma_async_tx_callback callback;
@@ -1990,6 +2002,12 @@ static void pl330_tasklet(unsigned long data)
if (pch->cyclic) {
desc->status = PREP;
list_move_tail(>node, >work_list);
+ if (power_down) {
+ spin_lock(>thread->dmac->lock);
+ _start(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ power_down = false;
+ }
} else {
desc->status = FREE;
list_move_tail(>node, >dmac->desc_pool);
@@ -2004,6 +2022,12 @@ static void pl330_tasklet(unsigned long data)
}
}
spin_unlock_irqrestore(>lock, flags);
+
+ /* If work list empty, power down */
+ if (power_down) {
+ pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
+ pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
+ }
}
bool pl330_filter(struct dma_chan *chan, void *param)
@@ -2073,6 +2097,7 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
switch (cmd) {
case DMA_TERMINATE_ALL:
+ pm_runtime_get_sync(pl330->ddma.dev);
spin_lock_irqsave(>lock, flags);
spin_lock(>lock);
@@ -2099,10 +2124,15 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
dma_cookie_complete(>txd);
}
+ if (!list_empty(>work_list))
+ pm_runtime_put(pl330->ddma.dev);
+
list_splice_tail_init(>submitted_list, >desc_pool);
list_splice_tail_init(>work_list, >desc_pool);
list_splice_tail_init(>completed_list, >desc_pool);
spin_unlock_irqrestore(>lock, flags);
+ pm_runtime_mark_last_busy(pl330->ddma.dev);
+ pm_runtime_put_autosuspend(pl330->ddma.dev);
break;
case DMA_SLAVE_CONFIG:
slave_config = (struct dma_slave_config *)arg;
@@ -2138,6 +2168,7 @@ static void pl330_free_chan_resources(struct dma_chan
*chan)
tasklet_kill(>task);
+ pm_runtime_get_sync(pch->dmac->ddma.dev);
spin_lock_irqsave(>lock, flags);
[PATCH v12 6/6] amba: Use inlines instead of macros for amba_pclk_enable/disable
Replace the amba_pclk_enable and amba_pclk_disable macros with static
inline functions and remove checks for IS_ERR. The amba bus clock won't
be ERR because probe would fail before the use of these functions.
Signed-off-by: Krzysztof Kozlowski
---
include/linux/amba/bus.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 2afc618b15ce..0ab5f8e0dea2 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -92,11 +92,15 @@ struct amba_device *amba_find_device(const char *, struct
device *, unsigned int
int amba_request_regions(struct amba_device *, const char *);
void amba_release_regions(struct amba_device *);
-#define amba_pclk_enable(d)\
- (IS_ERR((d)->pclk) ? 0 : clk_enable((d)->pclk))
+static inline int amba_pclk_enable(struct amba_device *dev)
+{
+ return clk_enable(dev->pclk);
+}
-#define amba_pclk_disable(d) \
- do { if (!IS_ERR((d)->pclk)) clk_disable((d)->pclk); } while (0)
+static inline void amba_pclk_disable(struct amba_device *dev)
+{
+ clk_disable(dev->pclk);
+}
static inline int amba_pclk_prepare(struct amba_device *dev)
{
--
1.9.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 v12 0/6] amba/dmaengine: pl330: add Power Management support
Hi, Changes since v11: == 1. Patch 1/6: Add Rafael's acked-by. 2. Patch 3/6: Add Ulf's reviewed-by. 3. Patch 5/6: Add missing pm_runtime_disable(), suggested by Ulf. 4. Uploaded first 4 patches to Russell's patch system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8199/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8200/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8201/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8202/1 Changes since v10: == 1. Bring back wrapper pm_runtime_is_irq_safe() (patch 1/6). This replaces patch 1/5 from v9 (moving dev->power.irq_safe out of CONFIG_PM_RUNTIME). 2. Patch 3/6 amba: Don't store current irq_safe during runtime suspend (suggested by Rafael J. Wysocki). Because of this change I dropped reviewed-by tags from this patch. 3. Patch 4/6 pl330: Add only runtime PM, without system PM (minor changes to the patch so I retained the revewed/acked tags). Add ack from Vinod. 4. Add patch 5/6 pl330: Add system PM to the pl330 which *does not* depends on runtime PM. I followed the discusions on LKML trying to reach consensus. Reasons tosplit previous patch into two patches (1st: runtime, 2nd: system PM): - easier review, - the first part (runtime PM) could be applied independently to system PM support. 6. Patch 6/6 amba: reworked the amba_pclk_* macros into inlines. Previously they were not used but now patch 5/6 depends on them. 7. Rebase on next-20141112. Changes since v9: = 1. Add patch 1/5: Move dev->power.irq_safe out of CONFIG_PM_RUNTIME. If CONFIG_PM_RUNTIME is not set, amba bus driver must still know whether child driver set irq_safe or not. Suggested by Ulf Hansson. Changes since v8: = 1. Remove the pm_runtime_is_irq_safe() wrapper (patch 1). 2. Patch 2/4 (amba): Store current irq_safe during runtime suspend. Resume will mirror suspend's work. Add a macro for safe access of irq_safe if CONFIG_PM_RUNTIME is unset. Dropped reviewed-by Ulf Hansson (major changes in patch). Changes since v7: = 1. Add reviewed-by Ulf Hansson (patches 3, 4 and 5). 2. Patch 2/5: Fix missing return in amba_pclk_prepare() (suggested by Ulf Hansson). 3. Rebased on next-20141020. Changes since v6: = 1. Add patch 5 removing the amba_pclk_*able macros. 2. Patch 2/5: Remove IS_ERR, use static inline functions instead of macros. 3. Patch 4/5: Force runtime suspend/resume in system sleep callbacks. Put with autosuspend at end of probe instead of no_idle. Suggested by Ulf Hansson. Changes since v5: = 1. Patch 1/4: Add Ulf Hansson's reviewed-by. 2. Patch 4/4: Use PM runtime autosuspend (suggested by Ulf Hansson). 3. Rebase on next-20140922. Changes since v4: 1. Patch 3/4: Explicitly initialize amba_device.irq_safe field after probing driver (suggested by Russell King). Changes since v3: 1. Patch 1/4: Document new API in Documentation/power/runtime_pm.txt (pointed by Alan Stern). Changes since v2: 1. Add patch 1 (PM / Runtime: Add getter for querying the IRQ safe option) 2. Add patch 2 (amba: Add helper macros for (un)preparing AMBA clock) 3. Patch 3/4: Rewrite the idea. If IRQ safe runtime PM is set then do not unprepare/prepare the clocks. Suggested by Russell King. 4. Patch 4/4: During system sleep unprepare the clock. Changes since v1: 1. Add patch 1 (amba: Allow AMBA drivers to use their own runtime PM). 2. Patch 2/2: Apply Michal Simek's suggestions. 3. Patch 2/2: Fix atomic context safeness in pl330_issue_pending(). Description: This patchset adds runtime and system PM to the pl330 driver. The runtime PM of pl330 driver requires interrupt safe suspend/resume callbacks which is in conflict with current amba bus driver. The latter also unprepares and prepares the AMBA bus clock which is not safe for atomic context. The patchset solves this in patch 3/6 by handling clocks in different way if device driver set interrupt safe runtime PM. Comments are welcome. Tested on board with pl330 DMA driver: - Trats2 (Exynos4212) Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (6): PM / Runtime: Add getter for querying the IRQ safe option amba: Add helpers for (un)preparing AMBA clock amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM dmaengine: pl330: Add runtime Power Management support dmaengine: pl330: Add PM sleep support amba: Use inlines instead of macros for amba_pclk_enable/disable Documentation/power/runtime_pm.txt | 4 ++ drivers/amba/bus.c | 15 -- drivers/dma/pl330.c| 99 -- include/linux/amba/bus.h | 22 +++-- include/linux/pm_runtime.h | 6 +++ 5 files changed, 134 insertions(+), 12 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send
[PATCH v12 2/6] amba: Add helpers for (un)preparing AMBA clock
Add amba_pclk_prepare() and amba_pclk_unprepare() inline functions for
handling the AMBA bus clock by device drivers.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Ulf Hansson
---
include/linux/amba/bus.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index d024bd9c9d9b..2afc618b15ce 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -98,6 +98,16 @@ void amba_release_regions(struct amba_device *);
#define amba_pclk_disable(d) \
do { if (!IS_ERR((d)->pclk)) clk_disable((d)->pclk); } while (0)
+static inline int amba_pclk_prepare(struct amba_device *dev)
+{
+ return clk_prepare(dev->pclk);
+}
+
+static inline void amba_pclk_unprepare(struct amba_device *dev)
+{
+ clk_unprepare(dev->pclk);
+}
+
/* Some drivers don't use the struct amba_device */
#define AMBA_CONFIG_BITS(a) (((a) >> 24) & 0xff)
#define AMBA_REV_BITS(a) (((a) >> 20) & 0x0f)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Fix Text randomization
On Fri, Nov 14, 2014 at 11:50 AM, Michael Ellerman wrote: > On Fri, 2014-11-14 at 11:03 +0530, Vineeth Vijayan wrote: >> ping ! >> >> any update on this ? As i understand, only powerpc and s390 uses the >> randomize_et_dyn call; for all other architecture this is an obsolete >> function call. > > I asked: > >> >> I'm not clear on what has changed to break this? > Disabling PIE randomization was added in the commit a3defbe5c337dbc6da911f8cc49ae3cc3b49b453 (binfmt_elf: fix PIE execution with randomization disabled). The randomization is decided as per the randomize_va_space sysctl flag. As i understand, the randomization of the base address is implemented at elf_map and not from the arch/<>/include/asm/elf.h Now, for powerpc, there's no support to disable the PIE randomization, even after we disable the same form randomize_va_space sysctl.This patch gives the support to disable PIE randomization in case it is disabled from this sysctl. > And you didn't tell me. > >> this call for another patch where randomize_et_dyn is removed. > > Patches welcome :) > i will follow up with the patch. > cheers > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On 11/14/2014 09:24 AM, George Cherian wrote: > Disable the MUSB interrupts till MUSB is recovered fully from BABBLE > condition. There are chances that we could get multiple interrupts > till the time the babble recover work gets scheduled. Sometimes > this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] clk: sunxi: Add support for sun9i a80 usb clocks and resets
Hi,
Sorry for the belated answer.
On Thu, Nov 06, 2014 at 05:19:24PM +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 6, 2014 at 4:54 PM, Maxime Ripard
> wrote:
> > On Thu, Nov 06, 2014 at 10:09:27AM +0800, Chen-Yu Tsai wrote:
> >> >> >> +static void __init sun9i_a80_usb_mod_setup(struct device_node *node)
> >> >> >> +{
> >> >> >> + /* AHB1 gate must be enabled to access registers */
> >> >> >> + struct clk *ahb = of_clk_get(node, 0);
> >> >> >> +
> >> >> >> + WARN_ON(IS_ERR(ahb));
> >> >> >> + clk_prepare_enable(ahb);
> >> >> >
> >> >> > H. That look off.
> >> >> >
> >> >> > Why do you need the clock to be enabled all the time? Isn't the CCF
> >> >> > already taking care of enabling the parent clock whenever it needs to
> >> >> > access any register?
> >> >>
> >> >> There are also resets in the same block. That and I couldn't get it
> >> >> working without enabling the clock beforehand.
> >> >
> >> > Ah, right.
> >> >
> >> > What happens if you just enable and disable the clocks in the
> >> > reset_assert and reset_deassert right before and after accessing the
> >> > registers?
> >>
> >> That doesn't work either. I forgot to mention that most of the clock
> >> gates have the peripheral pll as their parent, not the ahb clock gate.
> >
> > Why it doesn't work? The clock needs more time to stabilize? The reset
> > line is set back in reset if the clocks are disabled?
>
> Let me clarify, what you proposed will work for the resets.
>
> However the clock gates won't work if we use the generic clk-gate driver.
> The problem is most of the gates don't have the ahb gate as their parent,
> but pll4 (peripheral pll). When we enable the clock, the ahb gate isn't
> its parent, and doesn't get enabled as a result. This is especially true
> for the usb phy clocks: all of them use pll4 as their parent.
I'm not sure I get this right. You mean that this USB clock needs
*both* pll4 and its AHB gates to be enabled in order to run properly?
Or that the PHY needs its AHB gate to be enabled?
Both ways, I still don't think it's the right thing to do.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v3] of: replace Asahi Kasei Corp venter prefix
On 11/14/2014 10:43 AM, Kuninori Morimoto wrote:
From: Kuninori Morimoto
Current vendor-prefixes.txt already has
"ak" prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process.
But, almost all Asahi Kasei chip drivers are
using "asahi-kasei" prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is
using "ak,ak8975", but there are instances of
"asahi-kasei,ak8975" in other dts files.
And drivers/iio/magnetometer/ak8975.c
doesn't support "ak,ak8975")
So, we made a mistake there.
In addition, checkpatch.pl reports WARNING
if it is using "asahi-kasei" prerfix in DT file.
(DT compatible string vendor "asahi-kasei" appears un-documented)
Marking it deprecated and warning with checkpatch
is certainly preferable.
So, this patch replace "ak" to "asahi-kasei" in
vendor-prefixes.txt. (and fixup tegra20-seaboard)
OTOH, Asahi Kasei is usually referred to as "AKM",
but this patch doesn't care about it.
Because no DT is using that today.
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/vendor-prefixes.txt|2 +-
arch/arm/boot/dts/tegra20-seaboard.dts |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..ddcb4cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -9,7 +9,6 @@ ad Avionic Design GmbH
adapteva Adapteva, Inc.
adi Analog Devices, Inc.
aeroflexgaisler Aeroflex Gaisler AB
-ak Asahi Kasei Corp.
allwinner Allwinner Technology Co., Ltd.
altr Altera Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
@@ -20,6 +19,7 @@ amstaos AMS-Taos Inc.
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
armadeus ARMadeus Systems SARL
+asahi-kaseiAsahi Kasei Corp.
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = <40>;
magnetometer@c {
- compatible = "ak,ak8975";
+ compatible = "asahi-kasei,ak8975";
Mmm. So does this mean this device was never probed because the driver
did not recognize its compatible property? I cannot find "ak,ak8975"
anywhere else in the kernel.
If so,
Acked-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: Add output-disable
On Mon, Nov 3, 2014 at 10:09 PM, Doug Anderson wrote:
> On Fri, Oct 31, 2014 at 1:49 AM, Linus Walleij
> wrote:
>> Figure out the exact electronic meaning of what happens when you do
>> "output disable" in your hardware, I think it is very likely that
>> PIN_CONFIG_BIAS_HIGH_IMPEDANCE is what you are really
>> after here.
>
> OK, that seems plausible. ...so it is OK to set both
> "bias-high-impedance" _and_ "bias-pull-up" on a pin? That seemed
> weird to me but if that's right I can do that and try to implement
> "bias-high-impedance" on Rockchip...
I don't quite get the question. What this patch does is add something
called "output disable" which I think is analogous to high impedance.
If you enable both as the same time something is likely wrong
because it doesn't make electronic sense, high impedance and
pull up are kind of mutually exclusive. High impedance is also
know as "tristate" and means the line will assume the level of
whatever it is connected to, not try to pull things up.
So either:
- This is the wrong terminology, "output disable" means something
else. Like "disconnect the driver stages" or something, so pull-up
can be enabled.
- Stuff has been programmed in a bad way all the time.
Understanding the hardware is paramount...
> Maybe better to explain the problem. I have a pin that I wish to
> drive high weakly (using a pullup rather than actually pushing
> output-high to the pin). The firmware has left the pin configured as
> an output with no pull.
>
> I can configure the pin like this:
> rockchip,pins = <7 12 RK_FUNC_GPIO _pull_up>;
>
> pcfg_pull_up: pcfg-pull-up {
> bias-pull-up;
> };
This makes perfect sense.
> When I do this the current Rockchip pinctrl driver will _not_
> configure me as an input. It will happily flip the "pullup" bit in
> hardware and leave the pin configured as an output.
You seem to imply that the pins registers work such that
input needs to be enabled for pull-up to work.
This is a hardware pecularity. Just enable input in the hardware
whenever pull-up is requested then, as that is how that hardware
has to work. If you want to be explicit there is always
PIN_CONFIG_INPUT_ENABLE (input-enable;)
> I could certainly reach into the GPIO controller part of things
> whenever I see "bias-pull-up" and configure the pin as an input.
I think you should. This is a side effect of combined hardware
and expected.
> I
> guess that wouldn't actually hurt to do even if the pin wasn't
> configured as a GPIO...
This is why we have the callbacks:
pinctrl_request_gpio()
pinctrl_free_gpio()
pinctrl_gpio_direction_input()
pinctrl_gpio_direction_output()
By letting the GPIO driver side call these to set direction, we
can leave the control over direction status and incommensurable
states to the pin control driver.
Not that I have all things in my head, but if you're not using
the above calls in your GPIO driver, I suggest doing so and leaving
the pin direction status for the pinctrl side to handle.
> A third option that would work in my case (and actually be sorta
> clean) would be to implement a faux open-drain output. The hardware
> itself doesn't have a concept of open drain (unlike some SoCs) but I
> could implement it by swapping between "input pulled up" and "output
> driven low".
Uhm. Not following this. Probably you are better at electronics than
I am.
Anyway, I think the answers above is what you actually need to
keep working on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dr. Erich Schubert is a liar. Refutation.
Dear Mr Schubert; "He has not contributed anything to the open source community." This is a complete lie. I've contributed gigabytes of media alone. I've done years and years of programming work. I have done far more than you ever will. "His songs and "games" are not worth looking at," Your subjective view. Coloured by your social views and your disdain for those who oppose you in that. "and I'm not aware of any project that has accepted any of his "contributions"." The only objectively true thing you've said: you're not aware. I'm glad you're unaware, I hope that trend continues. I expect this post to be censored, it is par for the course for people like you. Sincerely; --MikeeUSA-- - (Erich Schubert put forth false claims about lack of involvement of mine in free/opensource software) (When corrected he first engaged, then deleted all the posts, keeping only his false statements visible) http://www.vitavonni.de/blog/201411/2014110901-gr-vote-on-init-coupling.html About Erich_Schubert: http://www.dbs.ifi.lmu.de/cms/Erich_Schubert Ludwig-Maximilians-Universität München Lehr- und Forschungseinheit für Datenbanksysteme Oettingenstraße 67 80538 München Germany Room: F 109 Phone: +49-89-2180-9325 Fax:+49-89-2180-9192 Email: sch...@dbs.ifi.lmu.de Sprechstunde: jeden Donnerstag 15-16 Uhr, Zimmer F 109 What is he all about? Data-Mining an der Hochschule Rosenheim (also seen on his most recent projects) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A fork starts with a single branch.
(A shout-out goes out to David Miller, boss ass mother fker, thanks for all you do) A fork starts with a single branch. As a precaution, I and others have all the debian source packages allready, and the full binary set for some architectures. (I'm sure many others have taken this precaution aswell, some as a matter of course) This is how all forks start. I've done it more than once. The key is a stable base, no shifting sands. Then you can build and build, gradually, till you die. (and it's fun all the time) I think the Best path is 3 and then 4. Once people stop work on Wheezy (they still release point releases) then it is truly time to continue on from there. There must be preperations made to be ready by that time, however. Some have allready been done. Perhaps the mempo and other debian-based projects who work best in a unix-like linux can set sail down the same river when that time comes? As for the coup. I believe that the coupists should be continually confronted and harranged. They should not be allowed to get away with this without so much as a word. They need to be exposed, pointed at, shown to be what they are. In one's free time between working, on projects, as a way of not burning one-self out continually doing one and only one thing. (One feature that would be good for such a fork would be to provide old versions of things like python installable alongside current versions, this is because python (and others) break compatability between versions. I have "old" programs that require the old versions. Had to find and build the old version. Might aswell package it up at some time. Also things like earier versions of KDE would be nice. To some degree things like this allready exist in debian (*box wms)) A full fork of Debian is not impossible, infact debian makes it easy to do. One change is how it always, always starts. Best of linux, before systemd. http://youtu.be/Bml5bjoMYjQ Rambling Proposal pt 1 of 2. Unix-like Fork. "Indelible Linux/Crystalline Linux" http://youtu.be/N18rNxe3Z-o Rambling Proposal pt 2 of 2. Unix-like Fork. "Indelible Linux/Crystalline Linux" http://youtu.be/TG1uqwNzlnk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kdump, x86: report actual value of phys_base in VMCOREINFO
On Fri, 14 Nov 2014 10:42:35 +0900 (JST) HATAYAMA Daisuke wrote: > From: Petr Tesarik > Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in > VMCOREINFO > Date: Thu, 13 Nov 2014 15:48:10 +0100 > > > On Thu, 13 Nov 2014 09:25:48 -0500 > > Vivek Goyal wrote: > > > >> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote: > >> > > >> > (2014/11/13 17:06), Petr Tesarik wrote: > >> > >On Thu, 13 Nov 2014 09:17:09 +0900 (JST) > >> > >HATAYAMA Daisuke wrote: > >> > > > >> > >>From: Vivek Goyal > >> > >>Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in > >> > >>VMCOREINFO > >> > >>Date: Wed, 12 Nov 2014 17:12:05 -0500 > >> > >> > >> > >>>On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote: > >> > Currently, VMCOREINFO note information reports the virtual address of > >> > phys_base that is assigned to symbol phys_base. But this doesn't make > >> > sense because to refer to value of the phys_base, it's necessary to > >> > get the value of phys_base itself we are now about to refer to. > >> > > >> > >>> > >> > >>>Hi Hatayama, > >> > >>> > >> > >>>/proc/vmcore ELF headers have virtual address information and using > >> > >>>that you should be able to read actual value of phys_base. gdb deals > >> > >>>with virtual addresses all the time and can read value of any symbol > >> > >>>using those headers. > >> > >>> > >> > >>>So I am not sure what's the need for exporting actual value of > >> > >>>phys_base. > >> > >>> > >> > >> > >> > >>Sorry, my logic in the patch description was wrong. For /proc/vmcore, > >> > >>there's enough information for makedumpdile to get phys_base. It's > >> > >>correct. The problem here is that other crash dump mechanisms that run > >> > >>outside Linux kernel independently don't have information to get > >> > >>phys_base. > >> > > > >> > >Yes, but these mechanisms won't be able to read VMCOREINFO either, will > >> > >they? > >> > > > >> > > >> > I don't intend such sophisticated function only by VMCOREINFO. > >> > Search vmcore for VMCOREINFO using strings + grep before opening it by > >> > crash. > >> > I intend that only here. > >> > >> I think this is very crude and not proper way to get to vmcoreinfo. > > > > Same here. If VMCOREINFO must be locatable without communicating any > > information to the hypervisor, then I would rather go for something > > similar to what s390(x) folks do - a well-known location in physical > > memory that contains a pointer to a checksummed OS info structure, > > which in turn contains the VMCOREINFO pointers. > > > > I'm a bit surprised such mechanism is not needed by Fujitsu SADUMP. > > Or is that part of the current plan, Daisuke? > > > > It's useful if there is. I don't plan now. For now, the idea of this > patch is enough for me. > > BTW, for the above idea, I suspect that if the location in the > physical memory is unique, it cannot deal with the kdump 2nd kernel > case. No, not at all. The low 640K are copied away to a pre-allocated area by kexec purgatory code on x86_64, so it's safe to overwrite any location in there. The copy is needed, because BIOS already uses some hardcoded addresses in that range. I think the Linux kernel may safely use part of PFN 0 starting at physical address 0x0500. This area was originally used by MS-DOS, so chances are high that no broken BIOS out there corrupts this part of RAM... Anyway, I'm not going to implement it right now for lack of time. I'm adding it to my TODO list, but if anybody wants to post a patch, I won't be offended. Petr T -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Discussion on lennart poettering, systemd, sysv
Discussion on lennart poettering, systemd, sysv http://youtu.be/2toVPMHRo8M (Hi David Miller.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Bass song) SystemD Abomination_More
Sonic description of SystemD http://youtu.be/zw8Ta1A3sTQ (Hi David Miller.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(SystemD) Empires only fall to an enemy within. (SystemD, Feminists)
Free software worked great for a time, it was a movement on the upswing. Then it was noticed. Feminists appeared and lobbied to have those of unclean mind excluded from the free/opensource movement, only those who believed the correct thing were allowed to stay. Code nor contribution mattered anymore. Believing in social justice for women, self-mutilated men/women, and gays was what was now important. No longer is it enough that a man has the ability and the will to code and contribute. His balls must be in a purse. Now SystemD has appeared aswell, and is tearing down what once were stable, time tested, edifices. Its proponents strangely also are of the pro-feminist / social justice warrior camp. Dissent is crushed. Empires only fall to an enemy within. http://youtu.be/y0aTqsl-vfU (Hi David Miller.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 14
Hi all,
Changes since 20141113:
New tree: overlayfs
The idle tree gained a conflict against Linus' tree.
The scsi tree gained a conflict against the usb tree.
Non-merge commits (relative to Linus' tree): 6264
6509 files changed, 209171 insertions(+), 167101 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.
Below is a summary of the state of the merge.
I am currently merging 229 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (2c54396e40c7 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (b94d525e58dc Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem
fast path in kmap_atomic_pfn())
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (8a97577a5967 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux)
Merging sparc/master (ab5c780913bc sparc64: Do irq_{enter,exit}() around
generic_smp_call_function*().)
Merging net/master (19ca9fc1445b vxlan: Do not reuse sockets for a different
address family)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (3542aed74809 ALSA: hda - Add mute LED control
for Lenovo Ideapad Z560)
Merging pci-current/for-linus (7a1562d4f2d0 PCI: Apply _HPX Link Control
settings to all devices with a link)
Merging wireless/master (4e6ce4dc7ce7 ath9k: Fix RTC_DERIVED_CLK usage)
Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb.current/usb-linus (2aea83a484fc Merge tag 'fixes-for-v3.18-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (ffcfe30ebd8d USB: serial: cp210x: add IDs
for CEL MeshConnect USB Stick)
Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3)
Merging input-current/for-linus (4ab8f7f320f9 Input: alps - ignore potential
bare packets when device is out of sync)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard"
stripe)
Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read
API and fix stack corruption)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (a87fa1d81a9f of: Fix overflow bug
in string property parsing functions)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch
'for-joerg/arm-smmu/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (7069a97a1415 selftests/net: move test out of
Makefile into a shell script)
Merging drm-intel-fixes/for-linux-next-fixes (e9d784d535e4
Re: [PATCH v5 1/4] mm/page_alloc: fix incorrect isolation behavior by rechecking migratetype
On Fri, Oct 31, 2014 at 3:25 PM, Joonsoo Kim wrote:
> There are two paths to reach core free function of buddy allocator,
> __free_one_page(), one is free_one_page()->__free_one_page() and the
> other is free_hot_cold_page()->free_pcppages_bulk()->__free_one_page().
> Each paths has race condition causing serious problems. At first, this
> patch is focused on first type of freepath. And then, following patch
> will solve the problem in second type of freepath.
>
> In the first type of freepath, we got migratetype of freeing page without
> holding the zone lock, so it could be racy. There are two cases of this
> race.
>
> 1. pages are added to isolate buddy list after restoring orignal
> migratetype
>
> CPU1 CPU2
>
> get migratetype => return MIGRATE_ISOLATE
> call free_one_page() with MIGRATE_ISOLATE
>
> grab the zone lock
> unisolate pageblock
> release the zone lock
>
> grab the zone lock
> call __free_one_page() with MIGRATE_ISOLATE
> freepage go into isolate buddy list,
> although pageblock is already unisolated
>
> This may cause two problems. One is that we can't use this page anymore
> until next isolation attempt of this pageblock, because freepage is on
> isolate buddy list. The other is that freepage accouting could be wrong
> due to merging between different buddy list. Freepages on isolate buddy
> list aren't counted as freepage, but ones on normal buddy list are counted
> as freepage. If merge happens, buddy freepage on normal buddy list is
> inevitably moved to isolate buddy list without any consideration of
> freepage accouting so it could be incorrect.
>
> 2. pages are added to normal buddy list while pageblock is isolated.
> It is similar with above case.
>
> This also may cause two problems. One is that we can't keep these
> freepages from being allocated. Although this pageblock is isolated,
> freepage would be added to normal buddy list so that it could be
> allocated without any restriction. And the other problem is same as
> case 1, that it, incorrect freepage accouting.
>
> This race condition would be prevented by checking migratetype again
> with holding the zone lock. Because it is somewhat heavy operation
> and it isn't needed in common case, we want to avoid rechecking as much
> as possible. So this patch introduce new variable, nr_isolate_pageblock
> in struct zone to check if there is isolated pageblock.
> With this, we can avoid to re-check migratetype in common case and do
> it only if there is isolated pageblock or migratetype is MIGRATE_ISOLATE.
> This solve above mentioned problems.
>
> Changes from v3:
> Add one more check in free_one_page() that checks whether migratetype is
> MIGRATE_ISOLATE or not. Without this, abovementioned case 1 could happens.
>
> Cc:
> Acked-by: Minchan Kim
> Acked-by: Michal Nazarewicz
> Acked-by: Vlastimil Babka
> Signed-off-by: Joonsoo Kim
> ---
> include/linux/mmzone.h |9 +
> include/linux/page-isolation.h |8
> mm/page_alloc.c| 11 +--
> mm/page_isolation.c|2 ++
> 4 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 4593567..3d090af 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -431,6 +431,15 @@ struct zone {
> */
> int nr_migrate_reserve_block;
>
> +#ifdef CONFIG_MEMORY_ISOLATION
> + /*
> +* Number of isolated pageblock. It is used to solve incorrect
> +* freepage counting problem due to racy retrieving migratetype
> +* of pageblock. Protected by zone->lock.
> +*/
> + unsigned long nr_isolate_pageblock;
> +#endif
> +
First sorry for this deferred reply, I see these patches have been merged
into the mainline.
However, I still have a tiny question:
Why use ZONE_PADDING(_pad1_) seperate it and zone->lock?
How about move it to the same cacheline with zone->lock, because it is
accessed under zone->lock?
> #ifdef CONFIG_MEMORY_HOTPLUG
> /* see spanned/present_pages for more description */
> seqlock_t span_seqlock;
> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> index 3fff8e7..2dc1e16 100644
> --- a/include/linux/page-isolation.h
> +++ b/include/linux/page-isolation.h
> @@ -2,6 +2,10 @@
> #define __LINUX_PAGEISOLATION_H
>
> #ifdef CONFIG_MEMORY_ISOLATION
> +static inline bool has_isolate_pageblock(struct zone *zone)
> +{
> + return zone->nr_isolate_pageblock;
> +}
> static inline bool is_migrate_isolate_page(struct page *page)
> {
> return get_pageblock_migratetype(page) == MIGRATE_ISOLATE;
> @@ -11,6 +15,10 @@ static inline bool is_migrate_isolate(int migratetype)
> return migratetype == MIGRATE_ISOLATE;
> }
> #else
> +static inline bool
[PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: Felipe Balbi
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3345c94..992c768 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -423,6 +423,7 @@ void musb_hnp_stop(struct musb *musb)
musb->port1_status &= ~(USB_PORT_STAT_C_CONNECTION << 16);
}
+static void musb_generic_disable(struct musb *musb);
/*
* Interrupt Service Routine to record USB "global" interrupts.
* Since these do not happen often and signify things of
@@ -846,9 +847,11 @@ b_host:
}
/* handle babble condition */
- if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
+ if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb)) {
+ musb_generic_disable(musb);
schedule_delayed_work(>recover_work,
msecs_to_jiffies(100));
+ }
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] perf tool: re-organize thread__resolve_callchain_sample
On Thu, Nov 13, 2014 at 10:48:10AM -0800, Andi Kleen wrote: > > Any chance you guys could sync on this? ..you're touching the > > same code.. Andi, maybe you wouldn't mind having this patch > > instead of your change.. looks like the only extra part is the > > cpumode resolve. > > Please just merge one of them, and the other can rebase. > > Note the lbr as callgraph has been posted since nearly a year now > (v1 was in January) > Arnaldo just took it: http://marc.info/?l=linux-kernel=141590608310095=2 Kan, please rebase once it's pushed out. thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: fix overly aggressive shmdt() when calls span multiple segments
On Mon, 2014-11-03 at 16:06 -0800, Dave Hansen wrote: > From: Dave Hansen > > This is a highly-contrived scenario. But, a single shmdt() call > can be induced in to unmapping memory from mulitple shm segments. > Example code is here: > > http://www.sr71.net/~dave/intel/shmfun.c > > The fix is pretty simple: Record the 'struct file' for the first > VMA we encounter and then stick to it. Decline to unmap anything > not from the same file and thus the same segment. > > I found this by inspection and the odds of anyone hitting this in > practice are pretty darn small. > > Lightly tested, but it's a pretty small patch. Passed shmdt ltp tests, fwiw. > Signed-off-by: Dave Hansen Reviewed-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 2/2] ALSA: ice1712: remove unused variable
On Thu, Nov 13, 2014 at 04:22:45PM +0100, Takashi Iwai wrote:
> At Thu, 13 Nov 2014 20:44:17 +0530,
> Sudip Mukherjee wrote:
> >
> > if (snd_pcm_format_width(runtime->format) == 16)
> > tmp &= ~0x04;
> > diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
> > index 1112ec1..1f40dab 100644
> > --- a/sound/pci/ice1712/revo.c
> > +++ b/sound/pci/ice1712/revo.c
> > @@ -481,7 +481,6 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
> > static const unsigned char ak4114_init_txcsb[] = {
> > 0x41, 0x02, 0x2c, 0x00, 0x00
> > };
> > - int err;
> >
> > struct revo51_spec *spec;
> > spec = kzalloc(sizeof(*spec), GFP_KERNEL);
> > @@ -489,11 +488,9 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
> > return -ENOMEM;
> > ice->spec = spec;
> >
> > - err = snd_ak4114_create(ice->card,
> > -ap192_ak4114_read,
> > -ap192_ak4114_write,
> > -ak4114_init_vals, ak4114_init_txcsb,
> > -ice, >ak4114);
> > + snd_ak4114_create(ice->card, ap192_ak4114_read, ap192_ak4114_write,
> > + ak4114_init_vals, ak4114_init_txcsb, ice,
> > + >ak4114);
>
> IMO, this is rather a bug. It should return the error (with a proper
> error handling).
>
error handling is already there. ap192_ak4114_init is being called by revo_init,
where the return value is being checked. revo_init is the callback function of
chip_init, so if we return the error value here then chip_init will fail.
but since the author commented "error ignored; it's no fatal error", so i also
thought of ignoring the error.
I will send you a revised patch.
thanks
sudip
>
> thanks,
>
> Takashi
>
>
> > /* AK4114 in Revo cannot detect external rate correctly.
> > * No reason to stop capture stream due to incorrect checks */
> > spec->ak4114->check_flags = AK4114_CHECK_NO_RATE;
> > --
> > 1.8.1.2
> >
> > ___
> > Alsa-devel mailing list
> > alsa-de...@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] can: Fix bug in suspend/resume
The drvdata in the suspend/resume is of type struct net_device,
not the platform device.Enable the clocks in the suspend before
accessing the registers of the CAN.
Signed-off-by: Kedareswara rao Appana
---
Changes for v2:
- Removed the struct platform_device* from suspend/resume
as suggest by Lothar.
- The clocks are getting disabled and un prepared at the end of the probe.
In the suspend the driver is doing a register write.In order
To do that register write we have to again enable and prepare the clocks.
drivers/net/can/xilinx_can.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 5e8b560..485262f 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -972,15 +972,28 @@ static const struct net_device_ops xcan_netdev_ops = {
*/
static int __maybe_unused xcan_suspend(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
+ int ret;
if (netif_running(ndev)) {
netif_stop_queue(ndev);
netif_device_detach(ndev);
}
+ ret = clk_prepare_enable(priv->can_clk);
+ if (ret) {
+ dev_err(dev, "unable to enable device clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->bus_clk);
+ if (ret) {
+ dev_err(dev, "unable to enable bus clock\n");
+ clk_disable_unprepare(priv->can_clk);
+ return ret;
+ }
+
priv->write_reg(priv, XCAN_MSR_OFFSET, XCAN_MSR_SLEEP_MASK);
priv->can.state = CAN_STATE_SLEEPING;
@@ -999,8 +1012,7 @@ static int __maybe_unused xcan_suspend(struct device *dev)
*/
static int __maybe_unused xcan_resume(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 1/6] PM / Runtime: Add getter for querying the IRQ safe option
On czw, 2014-11-13 at 02:34 +0100, Rafael J. Wysocki wrote: > On Wednesday, November 12, 2014 03:32:23 PM Krzysztof Kozlowski wrote: > > Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime > > PM IRQ safe was set or not. > > > > Various bus drivers implementing runtime PM may use choose to suspend > > differently based on IRQ safeness status of child driver (e.g. do not > > unprepare the clock if IRQ safe is not set). > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Ulf Hansson > > I'm fine with this one, please feel free to add my ACK if that needs to go > through a different tree. Thanks! With your ack I'll push patchset through Russell's patch system. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86/iommu: fix incorrect bit operations in setting values
1st step shows we should NOT disable the iommu when it is already enabled. But current code does disable-enable. So there is still works to do. The original kernel does a disable and re-enable , Bill's patchset removed the disable operation. I think step 2 is necessary, because when the driver initializes, the device need a new map, and the old data from the old kernel can not be used for the new driver. Now I am trying to implement these ideas. 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 v11 5/6] dmaengine: pl330: Add PM sleep support
On czw, 2014-11-13 at 10:03 +0100, Ulf Hansson wrote:
> On 13 November 2014 02:37, Rafael J. Wysocki wrote:
> > On Wednesday, November 12, 2014 03:32:27 PM Krzysztof Kozlowski wrote:
> >> Add system suspend/resume capabilities to the pl330 driver so the amba
> >> bus clock could be also unprepared to conserve energy.
> >>
> >> Signed-off-by: Krzysztof Kozlowski
> >> ---
> >> drivers/dma/pl330.c | 37 +
> >> 1 file changed, 37 insertions(+)
> >>
> >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> >> index c3bd3584f261..fd71777fc565 100644
> >> --- a/drivers/dma/pl330.c
> >> +++ b/drivers/dma/pl330.c
> >> @@ -2627,6 +2627,42 @@ static int pl330_dma_device_slave_caps(struct
> >> dma_chan *dchan,
> >> return 0;
> >> }
> >>
> >> +/*
> >> + * Runtime PM callbacks are provided by amba/bus.c driver.
> >> + *
> >> + * It is assumed here that IRQ safe runtime PM is chosen in probe and amba
> >> + * bus driver will only disable/enable the clock in runtime PM callbacks.
> >> + */
> >> +static int __maybe_unused pl330_suspend(struct device *dev)
> >> +{
> >> + struct amba_device *pcdev = to_amba_device(dev);
> >> +
> >> + if (!pm_runtime_status_suspended(dev)) {
> >
> > It generally isn't safe to call that in .suspend(), because the status may
> > still
> > change in theory. On the other hand, if you do that in .suspend_late(),
> > you'll
> > be safe from that.
> >
>
> Just to clarify that statement; it's safe in a ->suspend_late()
> callback, because runtime PM has been disabled by the PM core.
>
> That's also the reason why the pm_runtime_force_suspend() helper is
> disabling runtime PM, such it may be used in some of the earlier
> phases of the system PM callbacks.
So actually only pm_runtime_disable() is missing here (as you mentioned
earlier)?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ARM: mediatek: Add driver for Mediatek I2C controller
On Fri, 2014-11-14 at 11:12 +0800, xudong chen wrote: > On Thu, 2014-11-13 at 19:31 +0100, Wolfram Sang wrote: > > > MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c > > > registers in MT8135 side. > > > > I still didn't get this, even after reading the mail thread of old > > series. Can someone maybe draw me a nice ASCII picture showing the setup > > which is going on here? > > > > 1. The DIR_PATH register is in MT8135. > 2. All the registers used in the driver are in MT8135. > 3. If want I2C wave go/from PMIC need to set the DIR_PATH register bit^0 > to 1 extra. Hi, Some supplemental, I hope this make it more clear. +---+ | MT8135| | | |+--| ||I2C |___SDA ||controller|___SCL |+--| | | +---+ |+--| | MT6397| || pwrap | | |___SDA_pmic || |<>| |___SCL_pmic +---+ +---+ This is the simplified block diagram of mt8135 and mt6397. MT8135 can works with MTK PMIC MT6397. On MT8135, it use pwrap module to control /communicate with the PMIC. Pwrap is a hardware communicate with pmic through MTK proprietary interface. There are several PMIC functionality that is controlled by registers and controllers on MT8135, I2C is one of them. On MT8135, I2C controller can control I2C pins on MT8135 and MT6397. When you set I2C DIR_PATH register on MT8135, i2c controller will control PMIC pins(through pwrap) to send i2c signal. Because the i2c controllers are on 8135, it can still do DMA from system memory. So it kinds of like these 2 works like a virtual SoC. Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ARM: mediatek: Add driver for Mediatek I2C controller
On Fri, 2014-11-14 at 11:12 +0800, xudong chen wrote: On Thu, 2014-11-13 at 19:31 +0100, Wolfram Sang wrote: MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. I still didn't get this, even after reading the mail thread of old series. Can someone maybe draw me a nice ASCII picture showing the setup which is going on here? 1. The DIR_PATH register is in MT8135. 2. All the registers used in the driver are in MT8135. 3. If want I2C wave go/from PMIC need to set the DIR_PATH register bit^0 to 1 extra. Hi, Some supplemental, I hope this make it more clear. +---+ | MT8135| | | |+--| ||I2C |___SDA ||controller|___SCL |+--| | | +---+ |+--| | MT6397| || pwrap | | |___SDA_pmic || || |___SCL_pmic +---+ +---+ This is the simplified block diagram of mt8135 and mt6397. MT8135 can works with MTK PMIC MT6397. On MT8135, it use pwrap module to control /communicate with the PMIC. Pwrap is a hardware communicate with pmic through MTK proprietary interface. There are several PMIC functionality that is controlled by registers and controllers on MT8135, I2C is one of them. On MT8135, I2C controller can control I2C pins on MT8135 and MT6397. When you set I2C DIR_PATH register on MT8135, i2c controller will control PMIC pins(through pwrap) to send i2c signal. Because the i2c controllers are on 8135, it can still do DMA from system memory. So it kinds of like these 2 works like a virtual SoC. Joe.C -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] x86/iommu: fix incorrect bit operations in setting values
1st step shows we should NOT disable the iommu when it is already enabled. But current code does disable-enable. So there is still works to do. The original kernel does a disable and re-enable , Bill's patchset removed the disable operation. I think step 2 is necessary, because when the driver initializes, the device need a new map, and the old data from the old kernel can not be used for the new driver. Now I am trying to implement these ideas. 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 v11 5/6] dmaengine: pl330: Add PM sleep support
On czw, 2014-11-13 at 10:03 +0100, Ulf Hansson wrote:
On 13 November 2014 02:37, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, November 12, 2014 03:32:27 PM Krzysztof Kozlowski wrote:
Add system suspend/resume capabilities to the pl330 driver so the amba
bus clock could be also unprepared to conserve energy.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/dma/pl330.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index c3bd3584f261..fd71777fc565 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2627,6 +2627,42 @@ static int pl330_dma_device_slave_caps(struct
dma_chan *dchan,
return 0;
}
+/*
+ * Runtime PM callbacks are provided by amba/bus.c driver.
+ *
+ * It is assumed here that IRQ safe runtime PM is chosen in probe and amba
+ * bus driver will only disable/enable the clock in runtime PM callbacks.
+ */
+static int __maybe_unused pl330_suspend(struct device *dev)
+{
+ struct amba_device *pcdev = to_amba_device(dev);
+
+ if (!pm_runtime_status_suspended(dev)) {
It generally isn't safe to call that in .suspend(), because the status may
still
change in theory. On the other hand, if you do that in .suspend_late(),
you'll
be safe from that.
Just to clarify that statement; it's safe in a -suspend_late()
callback, because runtime PM has been disabled by the PM core.
That's also the reason why the pm_runtime_force_suspend() helper is
disabling runtime PM, such it may be used in some of the earlier
phases of the system PM callbacks.
So actually only pm_runtime_disable() is missing here (as you mentioned
earlier)?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v11 1/6] PM / Runtime: Add getter for querying the IRQ safe option
On czw, 2014-11-13 at 02:34 +0100, Rafael J. Wysocki wrote: On Wednesday, November 12, 2014 03:32:23 PM Krzysztof Kozlowski wrote: Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime PM IRQ safe was set or not. Various bus drivers implementing runtime PM may use choose to suspend differently based on IRQ safeness status of child driver (e.g. do not unprepare the clock if IRQ safe is not set). Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org I'm fine with this one, please feel free to add my ACK if that needs to go through a different tree. Thanks! With your ack I'll push patchset through Russell's patch system. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] can: Fix bug in suspend/resume
The drvdata in the suspend/resume is of type struct net_device,
not the platform device.Enable the clocks in the suspend before
accessing the registers of the CAN.
Signed-off-by: Kedareswara rao Appana appa...@xilinx.com
---
Changes for v2:
- Removed the struct platform_device* from suspend/resume
as suggest by Lothar.
- The clocks are getting disabled and un prepared at the end of the probe.
In the suspend the driver is doing a register write.In order
To do that register write we have to again enable and prepare the clocks.
drivers/net/can/xilinx_can.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 5e8b560..485262f 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -972,15 +972,28 @@ static const struct net_device_ops xcan_netdev_ops = {
*/
static int __maybe_unused xcan_suspend(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
+ int ret;
if (netif_running(ndev)) {
netif_stop_queue(ndev);
netif_device_detach(ndev);
}
+ ret = clk_prepare_enable(priv-can_clk);
+ if (ret) {
+ dev_err(dev, unable to enable device clock\n);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv-bus_clk);
+ if (ret) {
+ dev_err(dev, unable to enable bus clock\n);
+ clk_disable_unprepare(priv-can_clk);
+ return ret;
+ }
+
priv-write_reg(priv, XCAN_MSR_OFFSET, XCAN_MSR_SLEEP_MASK);
priv-can.state = CAN_STATE_SLEEPING;
@@ -999,8 +1012,7 @@ static int __maybe_unused xcan_suspend(struct device *dev)
*/
static int __maybe_unused xcan_resume(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
--
1.7.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: [alsa-devel] [PATCH 2/2] ALSA: ice1712: remove unused variable
On Thu, Nov 13, 2014 at 04:22:45PM +0100, Takashi Iwai wrote:
At Thu, 13 Nov 2014 20:44:17 +0530,
Sudip Mukherjee wrote:
snip
if (snd_pcm_format_width(runtime-format) == 16)
tmp = ~0x04;
diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
index 1112ec1..1f40dab 100644
--- a/sound/pci/ice1712/revo.c
+++ b/sound/pci/ice1712/revo.c
@@ -481,7 +481,6 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
static const unsigned char ak4114_init_txcsb[] = {
0x41, 0x02, 0x2c, 0x00, 0x00
};
- int err;
struct revo51_spec *spec;
spec = kzalloc(sizeof(*spec), GFP_KERNEL);
@@ -489,11 +488,9 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice)
return -ENOMEM;
ice-spec = spec;
- err = snd_ak4114_create(ice-card,
-ap192_ak4114_read,
-ap192_ak4114_write,
-ak4114_init_vals, ak4114_init_txcsb,
-ice, spec-ak4114);
+ snd_ak4114_create(ice-card, ap192_ak4114_read, ap192_ak4114_write,
+ ak4114_init_vals, ak4114_init_txcsb, ice,
+ spec-ak4114);
IMO, this is rather a bug. It should return the error (with a proper
error handling).
error handling is already there. ap192_ak4114_init is being called by revo_init,
where the return value is being checked. revo_init is the callback function of
chip_init, so if we return the error value here then chip_init will fail.
but since the author commented error ignored; it's no fatal error, so i also
thought of ignoring the error.
I will send you a revised patch.
thanks
sudip
thanks,
Takashi
/* AK4114 in Revo cannot detect external rate correctly.
* No reason to stop capture stream due to incorrect checks */
spec-ak4114-check_flags = AK4114_CHECK_NO_RATE;
--
1.8.1.2
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix overly aggressive shmdt() when calls span multiple segments
On Mon, 2014-11-03 at 16:06 -0800, Dave Hansen wrote: From: Dave Hansen dave.han...@linux.intel.com This is a highly-contrived scenario. But, a single shmdt() call can be induced in to unmapping memory from mulitple shm segments. Example code is here: http://www.sr71.net/~dave/intel/shmfun.c The fix is pretty simple: Record the 'struct file' for the first VMA we encounter and then stick to it. Decline to unmap anything not from the same file and thus the same segment. I found this by inspection and the odds of anyone hitting this in practice are pretty darn small. Lightly tested, but it's a pretty small patch. Passed shmdt ltp tests, fwiw. Signed-off-by: Dave Hansen dave.han...@linux.intel.com Reviewed-by: Davidlohr Bueso d...@stgolabs.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 2/3] perf tool: re-organize thread__resolve_callchain_sample
On Thu, Nov 13, 2014 at 10:48:10AM -0800, Andi Kleen wrote: Any chance you guys could sync on this? ..you're touching the same code.. Andi, maybe you wouldn't mind having this patch instead of your change.. looks like the only extra part is the cpumode resolve. Please just merge one of them, and the other can rebase. Note the lbr as callgraph has been posted since nearly a year now (v1 was in January) Arnaldo just took it: http://marc.info/?l=linux-kernelm=141590608310095w=2 Kan, please rebase once it's pushed out. thanks, jirka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3345c94..992c768 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -423,6 +423,7 @@ void musb_hnp_stop(struct musb *musb)
musb-port1_status = ~(USB_PORT_STAT_C_CONNECTION 16);
}
+static void musb_generic_disable(struct musb *musb);
/*
* Interrupt Service Routine to record USB global interrupts.
* Since these do not happen often and signify things of
@@ -846,9 +847,11 @@ b_host:
}
/* handle babble condition */
- if (int_usb MUSB_INTR_BABBLE is_host_active(musb))
+ if (int_usb MUSB_INTR_BABBLE is_host_active(musb)) {
+ musb_generic_disable(musb);
schedule_delayed_work(musb-recover_work,
msecs_to_jiffies(100));
+ }
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] mm/page_alloc: fix incorrect isolation behavior by rechecking migratetype
On Fri, Oct 31, 2014 at 3:25 PM, Joonsoo Kim iamjoonsoo@lge.com wrote:
There are two paths to reach core free function of buddy allocator,
__free_one_page(), one is free_one_page()-__free_one_page() and the
other is free_hot_cold_page()-free_pcppages_bulk()-__free_one_page().
Each paths has race condition causing serious problems. At first, this
patch is focused on first type of freepath. And then, following patch
will solve the problem in second type of freepath.
In the first type of freepath, we got migratetype of freeing page without
holding the zone lock, so it could be racy. There are two cases of this
race.
1. pages are added to isolate buddy list after restoring orignal
migratetype
CPU1 CPU2
get migratetype = return MIGRATE_ISOLATE
call free_one_page() with MIGRATE_ISOLATE
grab the zone lock
unisolate pageblock
release the zone lock
grab the zone lock
call __free_one_page() with MIGRATE_ISOLATE
freepage go into isolate buddy list,
although pageblock is already unisolated
This may cause two problems. One is that we can't use this page anymore
until next isolation attempt of this pageblock, because freepage is on
isolate buddy list. The other is that freepage accouting could be wrong
due to merging between different buddy list. Freepages on isolate buddy
list aren't counted as freepage, but ones on normal buddy list are counted
as freepage. If merge happens, buddy freepage on normal buddy list is
inevitably moved to isolate buddy list without any consideration of
freepage accouting so it could be incorrect.
2. pages are added to normal buddy list while pageblock is isolated.
It is similar with above case.
This also may cause two problems. One is that we can't keep these
freepages from being allocated. Although this pageblock is isolated,
freepage would be added to normal buddy list so that it could be
allocated without any restriction. And the other problem is same as
case 1, that it, incorrect freepage accouting.
This race condition would be prevented by checking migratetype again
with holding the zone lock. Because it is somewhat heavy operation
and it isn't needed in common case, we want to avoid rechecking as much
as possible. So this patch introduce new variable, nr_isolate_pageblock
in struct zone to check if there is isolated pageblock.
With this, we can avoid to re-check migratetype in common case and do
it only if there is isolated pageblock or migratetype is MIGRATE_ISOLATE.
This solve above mentioned problems.
Changes from v3:
Add one more check in free_one_page() that checks whether migratetype is
MIGRATE_ISOLATE or not. Without this, abovementioned case 1 could happens.
Cc: sta...@vger.kernel.org
Acked-by: Minchan Kim minc...@kernel.org
Acked-by: Michal Nazarewicz min...@mina86.com
Acked-by: Vlastimil Babka vba...@suse.cz
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
include/linux/mmzone.h |9 +
include/linux/page-isolation.h |8
mm/page_alloc.c| 11 +--
mm/page_isolation.c|2 ++
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 4593567..3d090af 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -431,6 +431,15 @@ struct zone {
*/
int nr_migrate_reserve_block;
+#ifdef CONFIG_MEMORY_ISOLATION
+ /*
+* Number of isolated pageblock. It is used to solve incorrect
+* freepage counting problem due to racy retrieving migratetype
+* of pageblock. Protected by zone-lock.
+*/
+ unsigned long nr_isolate_pageblock;
+#endif
+
First sorry for this deferred reply, I see these patches have been merged
into the mainline.
However, I still have a tiny question:
Why use ZONE_PADDING(_pad1_) seperate it and zone-lock?
How about move it to the same cacheline with zone-lock, because it is
accessed under zone-lock?
#ifdef CONFIG_MEMORY_HOTPLUG
/* see spanned/present_pages for more description */
seqlock_t span_seqlock;
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 3fff8e7..2dc1e16 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -2,6 +2,10 @@
#define __LINUX_PAGEISOLATION_H
#ifdef CONFIG_MEMORY_ISOLATION
+static inline bool has_isolate_pageblock(struct zone *zone)
+{
+ return zone-nr_isolate_pageblock;
+}
static inline bool is_migrate_isolate_page(struct page *page)
{
return get_pageblock_migratetype(page) == MIGRATE_ISOLATE;
@@ -11,6 +15,10 @@ static inline bool is_migrate_isolate(int migratetype)
return migratetype == MIGRATE_ISOLATE;
}
#else
+static inline bool
linux-next: Tree for Nov 14
Hi all,
Changes since 20141113:
New tree: overlayfs
The idle tree gained a conflict against Linus' tree.
The scsi tree gained a conflict against the usb tree.
Non-merge commits (relative to Linus' tree): 6264
6509 files changed, 209171 insertions(+), 167101 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one. You should use git fetch and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.
Below is a summary of the state of the merge.
I am currently merging 229 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (2c54396e40c7 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (b94d525e58dc Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem
fast path in kmap_atomic_pfn())
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (8a97577a5967 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux)
Merging sparc/master (ab5c780913bc sparc64: Do irq_{enter,exit}() around
generic_smp_call_function*().)
Merging net/master (19ca9fc1445b vxlan: Do not reuse sockets for a different
address family)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (3542aed74809 ALSA: hda - Add mute LED control
for Lenovo Ideapad Z560)
Merging pci-current/for-linus (7a1562d4f2d0 PCI: Apply _HPX Link Control
settings to all devices with a link)
Merging wireless/master (4e6ce4dc7ce7 ath9k: Fix RTC_DERIVED_CLK usage)
Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb.current/usb-linus (2aea83a484fc Merge tag 'fixes-for-v3.18-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (ffcfe30ebd8d USB: serial: cp210x: add IDs
for CEL MeshConnect USB Stick)
Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3)
Merging input-current/for-linus (4ab8f7f320f9 Input: alps - ignore potential
bare packets when device is out of sync)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard
stripe)
Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read
API and fix stack corruption)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (a87fa1d81a9f of: Fix overflow bug
in string property parsing functions)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch
'for-joerg/arm-smmu/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (7069a97a1415 selftests/net: move test out of
Makefile into a shell script)
Merging drm-intel-fixes/for-linux-next-fixes (e9d784d535e4 drm/i915:
(SystemD) Empires only fall to an enemy within. (SystemD, Feminists)
Free software worked great for a time, it was a movement on the upswing. Then it was noticed. Feminists appeared and lobbied to have those of unclean mind excluded from the free/opensource movement, only those who believed the correct thing were allowed to stay. Code nor contribution mattered anymore. Believing in social justice for women, self-mutilated men/women, and gays was what was now important. No longer is it enough that a man has the ability and the will to code and contribute. His balls must be in a purse. Now SystemD has appeared aswell, and is tearing down what once were stable, time tested, edifices. Its proponents strangely also are of the pro-feminist / social justice warrior camp. Dissent is crushed. Empires only fall to an enemy within. http://youtu.be/y0aTqsl-vfU (Hi David Miller.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Bass song) SystemD Abomination_More
Sonic description of SystemD http://youtu.be/zw8Ta1A3sTQ (Hi David Miller.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] kdump, x86: report actual value of phys_base in VMCOREINFO
On Fri, 14 Nov 2014 10:42:35 +0900 (JST) HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote: From: Petr Tesarik ptesa...@suse.cz Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO Date: Thu, 13 Nov 2014 15:48:10 +0100 On Thu, 13 Nov 2014 09:25:48 -0500 Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote: (2014/11/13 17:06), Petr Tesarik wrote: On Thu, 13 Nov 2014 09:17:09 +0900 (JST) HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote: From: Vivek Goyal vgo...@redhat.com Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO Date: Wed, 12 Nov 2014 17:12:05 -0500 On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote: Currently, VMCOREINFO note information reports the virtual address of phys_base that is assigned to symbol phys_base. But this doesn't make sense because to refer to value of the phys_base, it's necessary to get the value of phys_base itself we are now about to refer to. Hi Hatayama, /proc/vmcore ELF headers have virtual address information and using that you should be able to read actual value of phys_base. gdb deals with virtual addresses all the time and can read value of any symbol using those headers. So I am not sure what's the need for exporting actual value of phys_base. Sorry, my logic in the patch description was wrong. For /proc/vmcore, there's enough information for makedumpdile to get phys_base. It's correct. The problem here is that other crash dump mechanisms that run outside Linux kernel independently don't have information to get phys_base. Yes, but these mechanisms won't be able to read VMCOREINFO either, will they? I don't intend such sophisticated function only by VMCOREINFO. Search vmcore for VMCOREINFO using strings + grep before opening it by crash. I intend that only here. I think this is very crude and not proper way to get to vmcoreinfo. Same here. If VMCOREINFO must be locatable without communicating any information to the hypervisor, then I would rather go for something similar to what s390(x) folks do - a well-known location in physical memory that contains a pointer to a checksummed OS info structure, which in turn contains the VMCOREINFO pointers. I'm a bit surprised such mechanism is not needed by Fujitsu SADUMP. Or is that part of the current plan, Daisuke? It's useful if there is. I don't plan now. For now, the idea of this patch is enough for me. BTW, for the above idea, I suspect that if the location in the physical memory is unique, it cannot deal with the kdump 2nd kernel case. No, not at all. The low 640K are copied away to a pre-allocated area by kexec purgatory code on x86_64, so it's safe to overwrite any location in there. The copy is needed, because BIOS already uses some hardcoded addresses in that range. I think the Linux kernel may safely use part of PFN 0 starting at physical address 0x0500. This area was originally used by MS-DOS, so chances are high that no broken BIOS out there corrupts this part of RAM... Anyway, I'm not going to implement it right now for lack of time. I'm adding it to my TODO list, but if anybody wants to post a patch, I won't be offended. Petr T -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Discussion on lennart poettering, systemd, sysv
Discussion on lennart poettering, systemd, sysv http://youtu.be/2toVPMHRo8M (Hi David Miller.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A fork starts with a single branch.
(A shout-out goes out to David Miller, boss ass mother fker, thanks for all you do) A fork starts with a single branch. As a precaution, I and others have all the debian source packages allready, and the full binary set for some architectures. (I'm sure many others have taken this precaution aswell, some as a matter of course) This is how all forks start. I've done it more than once. The key is a stable base, no shifting sands. Then you can build and build, gradually, till you die. (and it's fun all the time) I think the Best path is 3 and then 4. Once people stop work on Wheezy (they still release point releases) then it is truly time to continue on from there. There must be preperations made to be ready by that time, however. Some have allready been done. Perhaps the mempo and other debian-based projects who work best in a unix-like linux can set sail down the same river when that time comes? As for the coup. I believe that the coupists should be continually confronted and harranged. They should not be allowed to get away with this without so much as a word. They need to be exposed, pointed at, shown to be what they are. In one's free time between working, on projects, as a way of not burning one-self out continually doing one and only one thing. (One feature that would be good for such a fork would be to provide old versions of things like python installable alongside current versions, this is because python (and others) break compatability between versions. I have old programs that require the old versions. Had to find and build the old version. Might aswell package it up at some time. Also things like earier versions of KDE would be nice. To some degree things like this allready exist in debian (*box wms)) A full fork of Debian is not impossible, infact debian makes it easy to do. One change is how it always, always starts. Best of linux, before systemd. http://youtu.be/Bml5bjoMYjQ Rambling Proposal pt 1 of 2. Unix-like Fork. Indelible Linux/Crystalline Linux http://youtu.be/N18rNxe3Z-o Rambling Proposal pt 2 of 2. Unix-like Fork. Indelible Linux/Crystalline Linux http://youtu.be/TG1uqwNzlnk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dr. Erich Schubert is a liar. Refutation.
Dear Mr Schubert; He has not contributed anything to the open source community. This is a complete lie. I've contributed gigabytes of media alone. I've done years and years of programming work. I have done far more than you ever will. His songs and games are not worth looking at, Your subjective view. Coloured by your social views and your disdain for those who oppose you in that. and I'm not aware of any project that has accepted any of his contributions. The only objectively true thing you've said: you're not aware. I'm glad you're unaware, I hope that trend continues. I expect this post to be censored, it is par for the course for people like you. Sincerely; --MikeeUSA-- - (Erich Schubert put forth false claims about lack of involvement of mine in free/opensource software) (When corrected he first engaged, then deleted all the posts, keeping only his false statements visible) http://www.vitavonni.de/blog/201411/2014110901-gr-vote-on-init-coupling.html About Erich_Schubert: http://www.dbs.ifi.lmu.de/cms/Erich_Schubert Ludwig-Maximilians-Universität München Lehr- und Forschungseinheit für Datenbanksysteme Oettingenstraße 67 80538 München Germany Room: F 109 Phone: +49-89-2180-9325 Fax:+49-89-2180-9192 Email: sch...@dbs.ifi.lmu.de Sprechstunde: jeden Donnerstag 15-16 Uhr, Zimmer F 109 What is he all about? Data-Mining an der Hochschule Rosenheim (also seen on his most recent projects) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] pinctrl: Add output-disable
On Mon, Nov 3, 2014 at 10:09 PM, Doug Anderson diand...@chromium.org wrote:
On Fri, Oct 31, 2014 at 1:49 AM, Linus Walleij linus.wall...@linaro.org
wrote:
Figure out the exact electronic meaning of what happens when you do
output disable in your hardware, I think it is very likely that
PIN_CONFIG_BIAS_HIGH_IMPEDANCE is what you are really
after here.
OK, that seems plausible. ...so it is OK to set both
bias-high-impedance _and_ bias-pull-up on a pin? That seemed
weird to me but if that's right I can do that and try to implement
bias-high-impedance on Rockchip...
I don't quite get the question. What this patch does is add something
called output disable which I think is analogous to high impedance.
If you enable both as the same time something is likely wrong
because it doesn't make electronic sense, high impedance and
pull up are kind of mutually exclusive. High impedance is also
know as tristate and means the line will assume the level of
whatever it is connected to, not try to pull things up.
So either:
- This is the wrong terminology, output disable means something
else. Like disconnect the driver stages or something, so pull-up
can be enabled.
- Stuff has been programmed in a bad way all the time.
Understanding the hardware is paramount...
Maybe better to explain the problem. I have a pin that I wish to
drive high weakly (using a pullup rather than actually pushing
output-high to the pin). The firmware has left the pin configured as
an output with no pull.
I can configure the pin like this:
rockchip,pins = 7 12 RK_FUNC_GPIO pcfg_pull_up;
pcfg_pull_up: pcfg-pull-up {
bias-pull-up;
};
This makes perfect sense.
When I do this the current Rockchip pinctrl driver will _not_
configure me as an input. It will happily flip the pullup bit in
hardware and leave the pin configured as an output.
You seem to imply that the pins registers work such that
input needs to be enabled for pull-up to work.
This is a hardware pecularity. Just enable input in the hardware
whenever pull-up is requested then, as that is how that hardware
has to work. If you want to be explicit there is always
PIN_CONFIG_INPUT_ENABLE (input-enable;)
I could certainly reach into the GPIO controller part of things
whenever I see bias-pull-up and configure the pin as an input.
I think you should. This is a side effect of combined hardware
and expected.
I
guess that wouldn't actually hurt to do even if the pin wasn't
configured as a GPIO...
This is why we have the callbacks:
pinctrl_request_gpio()
pinctrl_free_gpio()
pinctrl_gpio_direction_input()
pinctrl_gpio_direction_output()
By letting the GPIO driver side call these to set direction, we
can leave the control over direction status and incommensurable
states to the pin control driver.
Not that I have all things in my head, but if you're not using
the above calls in your GPIO driver, I suggest doing so and leaving
the pin direction status for the pinctrl side to handle.
A third option that would work in my case (and actually be sorta
clean) would be to implement a faux open-drain output. The hardware
itself doesn't have a concept of open drain (unlike some SoCs) but I
could implement it by swapping between input pulled up and output
driven low.
Uhm. Not following this. Probably you are better at electronics than
I am.
Anyway, I think the answers above is what you actually need to
keep working on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] of: replace Asahi Kasei Corp venter prefix
On 11/14/2014 10:43 AM, Kuninori Morimoto wrote:
From: Kuninori Morimoto kuninori.morimoto...@renesas.com
Current vendor-prefixes.txt already has
ak prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process.
But, almost all Asahi Kasei chip drivers are
using asahi-kasei prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is
using ak,ak8975, but there are instances of
asahi-kasei,ak8975 in other dts files.
And drivers/iio/magnetometer/ak8975.c
doesn't support ak,ak8975)
So, we made a mistake there.
In addition, checkpatch.pl reports WARNING
if it is using asahi-kasei prerfix in DT file.
(DT compatible string vendor asahi-kasei appears un-documented)
Marking it deprecated and warning with checkpatch
is certainly preferable.
So, this patch replace ak to asahi-kasei in
vendor-prefixes.txt. (and fixup tegra20-seaboard)
OTOH, Asahi Kasei is usually referred to as AKM,
but this patch doesn't care about it.
Because no DT is using that today.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
.../devicetree/bindings/vendor-prefixes.txt|2 +-
arch/arm/boot/dts/tegra20-seaboard.dts |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..ddcb4cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -9,7 +9,6 @@ ad Avionic Design GmbH
adapteva Adapteva, Inc.
adi Analog Devices, Inc.
aeroflexgaisler Aeroflex Gaisler AB
-ak Asahi Kasei Corp.
allwinner Allwinner Technology Co., Ltd.
altr Altera Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
@@ -20,6 +19,7 @@ amstaos AMS-Taos Inc.
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
armadeus ARMadeus Systems SARL
+asahi-kaseiAsahi Kasei Corp.
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = 40;
magnetometer@c {
- compatible = ak,ak8975;
+ compatible = asahi-kasei,ak8975;
Mmm. So does this mean this device was never probed because the driver
did not recognize its compatible property? I cannot find ak,ak8975
anywhere else in the kernel.
If so,
Acked-by: Alexandre Courbot acour...@nvidia.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] clk: sunxi: Add support for sun9i a80 usb clocks and resets
Hi,
Sorry for the belated answer.
On Thu, Nov 06, 2014 at 05:19:24PM +0800, Chen-Yu Tsai wrote:
On Thu, Nov 6, 2014 at 4:54 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Thu, Nov 06, 2014 at 10:09:27AM +0800, Chen-Yu Tsai wrote:
+static void __init sun9i_a80_usb_mod_setup(struct device_node *node)
+{
+ /* AHB1 gate must be enabled to access registers */
+ struct clk *ahb = of_clk_get(node, 0);
+
+ WARN_ON(IS_ERR(ahb));
+ clk_prepare_enable(ahb);
H. That look off.
Why do you need the clock to be enabled all the time? Isn't the CCF
already taking care of enabling the parent clock whenever it needs to
access any register?
There are also resets in the same block. That and I couldn't get it
working without enabling the clock beforehand.
Ah, right.
What happens if you just enable and disable the clocks in the
reset_assert and reset_deassert right before and after accessing the
registers?
That doesn't work either. I forgot to mention that most of the clock
gates have the peripheral pll as their parent, not the ahb clock gate.
Why it doesn't work? The clock needs more time to stabilize? The reset
line is set back in reset if the clocks are disabled?
Let me clarify, what you proposed will work for the resets.
However the clock gates won't work if we use the generic clk-gate driver.
The problem is most of the gates don't have the ahb gate as their parent,
but pll4 (peripheral pll). When we enable the clock, the ahb gate isn't
its parent, and doesn't get enabled as a result. This is especially true
for the usb phy clocks: all of them use pll4 as their parent.
I'm not sure I get this right. You mean that this USB clock needs
*both* pll4 and its AHB gates to be enabled in order to run properly?
Or that the PHY needs its AHB gate to be enabled?
Both ways, I still don't think it's the right thing to do.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On 11/14/2014 09:24 AM, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Fix Text randomization
On Fri, Nov 14, 2014 at 11:50 AM, Michael Ellerman m...@ellerman.id.au wrote: On Fri, 2014-11-14 at 11:03 +0530, Vineeth Vijayan wrote: ping ! any update on this ? As i understand, only powerpc and s390 uses the randomize_et_dyn call; for all other architecture this is an obsolete function call. I asked: I'm not clear on what has changed to break this? Disabling PIE randomization was added in the commit a3defbe5c337dbc6da911f8cc49ae3cc3b49b453 (binfmt_elf: fix PIE execution with randomization disabled). The randomization is decided as per the randomize_va_space sysctl flag. As i understand, the randomization of the base address is implemented at elf_map and not from the arch//include/asm/elf.h Now, for powerpc, there's no support to disable the PIE randomization, even after we disable the same form randomize_va_space sysctl.This patch gives the support to disable PIE randomization in case it is disabled from this sysctl. And you didn't tell me. this call for another patch where randomize_et_dyn is removed. Patches welcome :) i will follow up with the patch. cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 v12 2/6] amba: Add helpers for (un)preparing AMBA clock
Add amba_pclk_prepare() and amba_pclk_unprepare() inline functions for
handling the AMBA bus clock by device drivers.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
include/linux/amba/bus.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index d024bd9c9d9b..2afc618b15ce 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -98,6 +98,16 @@ void amba_release_regions(struct amba_device *);
#define amba_pclk_disable(d) \
do { if (!IS_ERR((d)-pclk)) clk_disable((d)-pclk); } while (0)
+static inline int amba_pclk_prepare(struct amba_device *dev)
+{
+ return clk_prepare(dev-pclk);
+}
+
+static inline void amba_pclk_unprepare(struct amba_device *dev)
+{
+ clk_unprepare(dev-pclk);
+}
+
/* Some drivers don't use the struct amba_device */
#define AMBA_CONFIG_BITS(a) (((a) 24) 0xff)
#define AMBA_REV_BITS(a) (((a) 20) 0x0f)
--
1.9.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 v12 6/6] amba: Use inlines instead of macros for amba_pclk_enable/disable
Replace the amba_pclk_enable and amba_pclk_disable macros with static
inline functions and remove checks for IS_ERR. The amba bus clock won't
be ERR because probe would fail before the use of these functions.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
include/linux/amba/bus.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 2afc618b15ce..0ab5f8e0dea2 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -92,11 +92,15 @@ struct amba_device *amba_find_device(const char *, struct
device *, unsigned int
int amba_request_regions(struct amba_device *, const char *);
void amba_release_regions(struct amba_device *);
-#define amba_pclk_enable(d)\
- (IS_ERR((d)-pclk) ? 0 : clk_enable((d)-pclk))
+static inline int amba_pclk_enable(struct amba_device *dev)
+{
+ return clk_enable(dev-pclk);
+}
-#define amba_pclk_disable(d) \
- do { if (!IS_ERR((d)-pclk)) clk_disable((d)-pclk); } while (0)
+static inline void amba_pclk_disable(struct amba_device *dev)
+{
+ clk_disable(dev-pclk);
+}
static inline int amba_pclk_prepare(struct amba_device *dev)
{
--
1.9.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 v12 0/6] amba/dmaengine: pl330: add Power Management support
Hi, Changes since v11: == 1. Patch 1/6: Add Rafael's acked-by. 2. Patch 3/6: Add Ulf's reviewed-by. 3. Patch 5/6: Add missing pm_runtime_disable(), suggested by Ulf. 4. Uploaded first 4 patches to Russell's patch system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8199/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8200/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8201/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8202/1 Changes since v10: == 1. Bring back wrapper pm_runtime_is_irq_safe() (patch 1/6). This replaces patch 1/5 from v9 (moving dev-power.irq_safe out of CONFIG_PM_RUNTIME). 2. Patch 3/6 amba: Don't store current irq_safe during runtime suspend (suggested by Rafael J. Wysocki). Because of this change I dropped reviewed-by tags from this patch. 3. Patch 4/6 pl330: Add only runtime PM, without system PM (minor changes to the patch so I retained the revewed/acked tags). Add ack from Vinod. 4. Add patch 5/6 pl330: Add system PM to the pl330 which *does not* depends on runtime PM. I followed the discusions on LKML trying to reach consensus. Reasons tosplit previous patch into two patches (1st: runtime, 2nd: system PM): - easier review, - the first part (runtime PM) could be applied independently to system PM support. 6. Patch 6/6 amba: reworked the amba_pclk_* macros into inlines. Previously they were not used but now patch 5/6 depends on them. 7. Rebase on next-20141112. Changes since v9: = 1. Add patch 1/5: Move dev-power.irq_safe out of CONFIG_PM_RUNTIME. If CONFIG_PM_RUNTIME is not set, amba bus driver must still know whether child driver set irq_safe or not. Suggested by Ulf Hansson. Changes since v8: = 1. Remove the pm_runtime_is_irq_safe() wrapper (patch 1). 2. Patch 2/4 (amba): Store current irq_safe during runtime suspend. Resume will mirror suspend's work. Add a macro for safe access of irq_safe if CONFIG_PM_RUNTIME is unset. Dropped reviewed-by Ulf Hansson (major changes in patch). Changes since v7: = 1. Add reviewed-by Ulf Hansson (patches 3, 4 and 5). 2. Patch 2/5: Fix missing return in amba_pclk_prepare() (suggested by Ulf Hansson). 3. Rebased on next-20141020. Changes since v6: = 1. Add patch 5 removing the amba_pclk_*able macros. 2. Patch 2/5: Remove IS_ERR, use static inline functions instead of macros. 3. Patch 4/5: Force runtime suspend/resume in system sleep callbacks. Put with autosuspend at end of probe instead of no_idle. Suggested by Ulf Hansson. Changes since v5: = 1. Patch 1/4: Add Ulf Hansson's reviewed-by. 2. Patch 4/4: Use PM runtime autosuspend (suggested by Ulf Hansson). 3. Rebase on next-20140922. Changes since v4: 1. Patch 3/4: Explicitly initialize amba_device.irq_safe field after probing driver (suggested by Russell King). Changes since v3: 1. Patch 1/4: Document new API in Documentation/power/runtime_pm.txt (pointed by Alan Stern). Changes since v2: 1. Add patch 1 (PM / Runtime: Add getter for querying the IRQ safe option) 2. Add patch 2 (amba: Add helper macros for (un)preparing AMBA clock) 3. Patch 3/4: Rewrite the idea. If IRQ safe runtime PM is set then do not unprepare/prepare the clocks. Suggested by Russell King. 4. Patch 4/4: During system sleep unprepare the clock. Changes since v1: 1. Add patch 1 (amba: Allow AMBA drivers to use their own runtime PM). 2. Patch 2/2: Apply Michal Simek's suggestions. 3. Patch 2/2: Fix atomic context safeness in pl330_issue_pending(). Description: This patchset adds runtime and system PM to the pl330 driver. The runtime PM of pl330 driver requires interrupt safe suspend/resume callbacks which is in conflict with current amba bus driver. The latter also unprepares and prepares the AMBA bus clock which is not safe for atomic context. The patchset solves this in patch 3/6 by handling clocks in different way if device driver set interrupt safe runtime PM. Comments are welcome. Tested on board with pl330 DMA driver: - Trats2 (Exynos4212) Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (6): PM / Runtime: Add getter for querying the IRQ safe option amba: Add helpers for (un)preparing AMBA clock amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM dmaengine: pl330: Add runtime Power Management support dmaengine: pl330: Add PM sleep support amba: Use inlines instead of macros for amba_pclk_enable/disable Documentation/power/runtime_pm.txt | 4 ++ drivers/amba/bus.c | 15 -- drivers/dma/pl330.c| 99 -- include/linux/amba/bus.h | 22 +++-- include/linux/pm_runtime.h | 6 +++ 5 files changed, 134 insertions(+), 12 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the
Re: [PATCH v4 0/3] Rework xhci: clear root port wake on bits if controller isn't wake-up capable
On 14.11.2014 05:14, Lu, Baolu wrote: Hi Mathias, This patch series has been acked by Alan Stern. There seems no further comments from others. Can you please pull in it? Thanks, -baolu Ah, yes, thanks for reminding, I'll pull them in and send them forward. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 v12 5/6] dmaengine: pl330: Add PM sleep support
Add system suspend/resume capabilities to the pl330 driver so the amba
bus clock could be also unprepared to conserve energy.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/dma/pl330.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index c3bd3584f261..e499bb118f0a 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2627,6 +2627,46 @@ static int pl330_dma_device_slave_caps(struct dma_chan
*dchan,
return 0;
}
+/*
+ * Runtime PM callbacks are provided by amba/bus.c driver.
+ *
+ * It is assumed here that IRQ safe runtime PM is chosen in probe and amba
+ * bus driver will only disable/enable the clock in runtime PM callbacks.
+ */
+static int __maybe_unused pl330_suspend(struct device *dev)
+{
+ struct amba_device *pcdev = to_amba_device(dev);
+
+ pm_runtime_disable(dev);
+
+ if (!pm_runtime_status_suspended(dev)) {
+ /* amba did not disable the clock */
+ amba_pclk_disable(pcdev);
+ }
+ amba_pclk_unprepare(pcdev);
+
+ return 0;
+}
+
+static int __maybe_unused pl330_resume(struct device *dev)
+{
+ struct amba_device *pcdev = to_amba_device(dev);
+ int ret;
+
+ ret = amba_pclk_prepare(pcdev);
+ if (ret)
+ return ret;
+
+ if (!pm_runtime_status_suspended(dev))
+ ret = amba_pclk_enable(pcdev);
+
+ pm_runtime_enable(dev);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(pl330_pm, pl330_suspend, pl330_resume);
+
static int
pl330_probe(struct amba_device *adev, const struct amba_id *id)
{
@@ -2853,6 +2893,7 @@ static struct amba_driver pl330_driver = {
.drv = {
.owner = THIS_MODULE,
.name = dma-pl330,
+ .pm = pl330_pm,
},
.id_table = pl330_ids,
.probe = pl330_probe,
--
1.9.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 v12 4/6] dmaengine: pl330: Add runtime Power Management support
This patch adds runtime PM support to pl330 DMA engine driver.
The runtime power management for pl330 DMA driver allows gating of AMBA
clock (PDMA) in FSYS clock domain, when the device is not processing any
requests. This is necessary to enter low power modes on Exynos SoCs
(e.g. LPA on Exynos4x12 or W-AFTR on Exynos3250).
Runtime PM resuming of the device may happen in atomic context (during
call device_issue_pending()) so pm_runtime_irq_safe() is used. This will
lead only to disabling/enabling of the clock but this is sufficient for
gating the clock and for reducing energy usage.
Driver uses runtime PM callbacks from amba/bus.c driver only.
Suggested-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Vinod Koul vinod.k...@intel.com
---
drivers/dma/pl330.c | 58 +
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 83e2257c324a..c3bd3584f261 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -27,6 +27,7 @@
#include linux/of.h
#include linux/of_dma.h
#include linux/err.h
+#include linux/pm_runtime.h
#include dmaengine.h
#define PL330_MAX_CHAN 8
@@ -265,6 +266,9 @@ static unsigned cmd_line;
#define NR_DEFAULT_DESC16
+/* Delay for runtime PM autosuspend, ms */
+#define PL330_AUTOSUSPEND_DELAY 20
+
/* Populated by the PL330 core driver for DMA API driver's info */
struct pl330_config {
u32 periph_id;
@@ -1958,6 +1962,7 @@ static void pl330_tasklet(unsigned long data)
struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
struct dma_pl330_desc *desc, *_dt;
unsigned long flags;
+ bool power_down = false;
spin_lock_irqsave(pch-lock, flags);
@@ -1972,10 +1977,17 @@ static void pl330_tasklet(unsigned long data)
/* Try to submit a req imm. next to the last completed cookie */
fill_queue(pch);
- /* Make sure the PL330 Channel thread is active */
- spin_lock(pch-thread-dmac-lock);
- _start(pch-thread);
- spin_unlock(pch-thread-dmac-lock);
+ if (list_empty(pch-work_list)) {
+ spin_lock(pch-thread-dmac-lock);
+ _stop(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ power_down = true;
+ } else {
+ /* Make sure the PL330 Channel thread is active */
+ spin_lock(pch-thread-dmac-lock);
+ _start(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ }
while (!list_empty(pch-completed_list)) {
dma_async_tx_callback callback;
@@ -1990,6 +2002,12 @@ static void pl330_tasklet(unsigned long data)
if (pch-cyclic) {
desc-status = PREP;
list_move_tail(desc-node, pch-work_list);
+ if (power_down) {
+ spin_lock(pch-thread-dmac-lock);
+ _start(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ power_down = false;
+ }
} else {
desc-status = FREE;
list_move_tail(desc-node, pch-dmac-desc_pool);
@@ -2004,6 +2022,12 @@ static void pl330_tasklet(unsigned long data)
}
}
spin_unlock_irqrestore(pch-lock, flags);
+
+ /* If work list empty, power down */
+ if (power_down) {
+ pm_runtime_mark_last_busy(pch-dmac-ddma.dev);
+ pm_runtime_put_autosuspend(pch-dmac-ddma.dev);
+ }
}
bool pl330_filter(struct dma_chan *chan, void *param)
@@ -2073,6 +2097,7 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
switch (cmd) {
case DMA_TERMINATE_ALL:
+ pm_runtime_get_sync(pl330-ddma.dev);
spin_lock_irqsave(pch-lock, flags);
spin_lock(pl330-lock);
@@ -2099,10 +2124,15 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
dma_cookie_complete(desc-txd);
}
+ if (!list_empty(pch-work_list))
+ pm_runtime_put(pl330-ddma.dev);
+
list_splice_tail_init(pch-submitted_list, pl330-desc_pool);
list_splice_tail_init(pch-work_list, pl330-desc_pool);
list_splice_tail_init(pch-completed_list, pl330-desc_pool);
spin_unlock_irqrestore(pch-lock, flags);
+ pm_runtime_mark_last_busy(pl330-ddma.dev);
+ pm_runtime_put_autosuspend(pl330-ddma.dev);
break;
case DMA_SLAVE_CONFIG:
slave_config = (struct dma_slave_config *)arg;
@@ -2138,6 +2168,7 @@ static void
[PATCH v12 1/6] PM / Runtime: Add getter for querying the IRQ safe option
Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime
PM IRQ safe was set or not.
Various bus drivers implementing runtime PM may use choose to suspend
differently based on IRQ safeness status of child driver (e.g. do not
unprepare the clock if IRQ safe is not set).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Rafael J. Wysocki r...@rjwysocki.net
---
Documentation/power/runtime_pm.txt | 4
include/linux/pm_runtime.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/Documentation/power/runtime_pm.txt
b/Documentation/power/runtime_pm.txt
index 0e5ea26b255a..44fe1d28a163 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -468,6 +468,10 @@ drivers/base/power/runtime.c and
include/linux/pm_runtime.h:
- set the power.irq_safe flag for the device, causing the runtime-PM
callbacks to be invoked with interrupts off
+ bool pm_runtime_is_irq_safe(struct device *dev);
+- return true if power.irq_safe flag was set for the device, causing
+ the runtime-PM callbacks to be invoked with interrupts off
+
void pm_runtime_mark_last_busy(struct device *dev);
- set the power.last_busy field to the current time
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 367f49b9a1c9..44d74f0f182e 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -128,6 +128,11 @@ static inline void pm_runtime_mark_last_busy(struct device
*dev)
ACCESS_ONCE(dev-power.last_busy) = jiffies;
}
+static inline bool pm_runtime_is_irq_safe(struct device *dev)
+{
+ return dev-power.irq_safe;
+}
+
#else /* !CONFIG_PM_RUNTIME */
static inline int __pm_runtime_idle(struct device *dev, int rpmflags)
@@ -167,6 +172,7 @@ static inline bool pm_runtime_enabled(struct device *dev) {
return false; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
static inline void pm_runtime_irq_safe(struct device *dev) {}
+static inline bool pm_runtime_is_irq_safe(struct device *dev) { return false; }
static inline bool pm_runtime_callbacks_present(struct device *dev) { return
false; }
static inline void pm_runtime_mark_last_busy(struct device *dev) {}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] mm, compaction: pass classzone_idx and alloc_flags to watermark checking
On 10/31/2014 08:49 AM, Joonsoo Kim wrote: On Wed, Oct 29, 2014 at 02:51:11PM +0100, Vlastimil Babka wrote: On 10/28/2014 08:16 AM, Joonsoo Kim wrote: On Mon, Oct 27, 2014 at 10:11:31AM +0100, Vlastimil Babka wrote: I thought that the second check in compaction_suitable() makes sure of this, but now I see it's in fact not. But i'm not sure if we should just put the flags in the first check, as IMHO the flags should only affect the final high-order allocation, not also the temporary pages needed for migration? I don't think so. As mentioned before, if we don't have not enough freepages, compaction will fail due to shortage of freepage at final high-order watermark check. Maybe it failes due to not enough freepage rather than ordered freepage. Proper flags and index make us avoid useless compaction so I prefer put the flags in the first check. BTW now I'm not even sure that the 2UL order part makes sense anymore. The number of pages migrated at once is always restricted by COMPACT_CLUSTER_MAX, so why would we need more than that to cover migration? In fact, any values seems to be wrong. We can isolate high order freepage for this temporary use. I don't have any idea what the proper value is. Also the order of checks seems wrong. It should return COMPACT_PARTIAL If the allocation would succeed without compaction but that only can happen after passing the check if the zone has the extra 1UL order for migration. Do you agree? Yes, agree! I guess that __isolate_free_page() is also good candidate to need this information in order to prevent compaction from isolating too many freepage in low memory condition. I don't see how it would help here. It's temporary allocations for page migration. How would passing classzone_idx and alloc_flags prevent isolating too many? It is temporary allocation, but, anyway, it could holds many freepage in some duration. As mentioned above, if we isolate high order freepage, we can hold 1MB or more freepage at once. I guess that passing flags helps system stability. OK, here's a patch-fix to address everything discussed above. My testing didn't show much difference, but I know it's limited anyway. --8-- From: Vlastimil Babka vba...@suse.cz Date: Mon, 3 Nov 2014 15:26:40 +0100 Subject: mm-compaction-pass-classzone_idx-and-alloc_flags-to-watermark-checking-fix This patch-fix changes zone watermark checking in compaction_suitable() as we discussed with Joonsoo Kim. First, it moves up the watermark check for answering the question does the zone need compaction at all?. Before this change, the check is preceded by a check that answers the question does the zone have enough free pages to succeed compaction. So it might happen that there is already a high-order page available, but not enough pages for performing the compaction (which assumes extra pages for the migrations). Before the patch, compaction_suitable() would return COMPACT_SKIPPED which means compaction cannot succeed, reclaim more, after this change it returns COMPACT_PARTIAL which means compaction not needed, try allocating. Second, the check for answering can the compaction succeed? now also includes classzone_idx and alloc_flags parameters. This prevents starting compaction that would not lead to successful allocation due to not having enough free pages. The addition of extra pages for migration is left in the check. Although these are temporary allocations and thus should not be affected by alloc_flags and classzone_idx, it only matters when we are close to the watermark, where it does not hurt to be a bit pessimistic. Signed-off-by: Vlastimil Babka vba...@suse.cz Cc: Minchan Kim minc...@kernel.org Cc: Mel Gorman mgor...@suse.de Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: Michal Nazarewicz min...@mina86.com Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com Cc: Christoph Lameter c...@linux.com Cc: Rik van Riel r...@redhat.com Cc: David Rientjes rient...@google.com --- When squashed, full changelog of the patch+fix should be: Compaction relies on zone watermark checks for decisions such as if it's worth to start compacting in compaction_suitable() or whether compaction should stop in compact_finished(). The watermark checks take classzone_idx and alloc_flags parameters, which are related to the memory allocation request. But from the context of compaction they are currently passed as 0, including the direct compaction which is invoked to satisfy the allocation request, and could therefore know the proper values. The lack of proper values can lead to mismatch between decisions taken during compaction and decisions related to the allocation request. Lack of proper classzone_idx value means that lowmem_reserve is not taken into account. This has manifested (during recent changes to deferred compaction) when DMA zone was used as fallback for preferred Normal zone. compaction_suitable() without proper classzone_idx would think that the watermarks are already
[PATCH v12 3/6] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
The AMBA bus driver defines runtime Power Management functions which
disable and unprepare AMBA bus clock. This is problematic for runtime PM
because unpreparing a clock might sleep so it is not interrupt safe.
However some drivers may want to implement runtime PM functions in
interrupt-safe way (see pm_runtime_irq_safe()). In such case the AMBA
bus driver should only disable/enable the clock in runtime suspend and
resume callbacks.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/amba/bus.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index a4ac490dd784..c2153a1d1981 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -95,8 +95,12 @@ static int amba_pm_runtime_suspend(struct device *dev)
struct amba_device *pcdev = to_amba_device(dev);
int ret = pm_generic_runtime_suspend(dev);
- if (ret == 0 dev-driver)
- clk_disable_unprepare(pcdev-pclk);
+ if (ret == 0 dev-driver) {
+ if (pm_runtime_is_irq_safe(dev))
+ clk_disable(pcdev-pclk);
+ else
+ clk_disable_unprepare(pcdev-pclk);
+ }
return ret;
}
@@ -107,7 +111,10 @@ static int amba_pm_runtime_resume(struct device *dev)
int ret;
if (dev-driver) {
- ret = clk_prepare_enable(pcdev-pclk);
+ if (pm_runtime_is_irq_safe(dev))
+ ret = clk_enable(pcdev-pclk);
+ else
+ ret = clk_prepare_enable(pcdev-pclk);
/* Failure is probably fatal to the system, but... */
if (ret)
return ret;
@@ -115,7 +122,7 @@ static int amba_pm_runtime_resume(struct device *dev)
return pm_generic_runtime_resume(dev);
}
-#endif
+#endif /* CONFIG_PM */
static const struct dev_pm_ops amba_pm = {
.suspend= pm_generic_suspend,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] can: Fix bug in suspend/resume
On 11/14/2014 09:16 AM, Kedareswara rao Appana wrote: The drvdata in the suspend/resume is of type struct net_device, not the platform device.Enable the clocks in the suspend before accessing the registers of the CAN. Signed-off-by: Kedareswara rao Appana appa...@xilinx.com --- Changes for v2: - Removed the struct platform_device* from suspend/resume as suggest by Lothar. - The clocks are getting disabled and un prepared at the end of the probe. In the suspend the driver is doing a register write.In order To do that register write we have to again enable and prepare the clocks. Please look the at suspend/resume code and count the clock_enable/disable manually. After a suspend/resume cycle, you have enabled the clock twice, but disabled it once. I think you have to abstract the clock handling behind runtime PM. I haven't done this myself yet, but the strong feeling that this is a possible solution to your problem. These links might help: http://lwn.net/Articles/505683/ http://www.slideshare.net/linaroorg/runtime-pm http://www.slideshare.net/linaroorg/lca14-407-deployingruntimepmonarmsocs http://www.slideshare.net/SamsungOSG/shuah-khan-lpcpmops Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH] overlayfs: support more than one read-only layer
EL Mon, 10 Nov 2014 10:09:54 +0100
Miklos Szeredi mik...@szeredi.hu escrigué:
Maybe it wasn't clear, but the number of lower layers isn't limited by
FILESYSTEM_MAX_STACK_DEPTH,
sorry, you have been clear, it's me that have not explained the purpose
of that patch. This idea is also valid for the main overlayfs
development.
Consider that we have an encrypted partition and a live OS that
uses overlayfs and works over it, when the OS is started already
reaches the maximum stacking depth (2). Also, hardcoding parameters
into the code may be annoying because a change implies creating and
mantaining patches, otherwise when the parameter is configurable we can
change it in a config value.
Also, I include a patch to explain better my first statement,
would say lowerdirs has extended the functionality of lowerdir,
therefore we can discard the lowerdir case that only works with one
lower layer and rename lowerdirs to lowerdir. It's more simple and all
the functionality is preserved.
Regards,
Jordi Pujol
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c 2014-11-12 10:23:54.285960418 +0100
@@ -29,7 +29,6 @@ MODULE_VERSION(OVERLAYFS_VERSION);
struct ovl_config {
char *lowerdir;
- char *lowerdirs;
char *upperdir;
char *workdir;
};
@@ -497,8 +496,6 @@ static int ovl_show_options(struct seq_f
if (ufs-config.lowerdir)
seq_printf(m, ,lowerdir=%s, ufs-config.lowerdir);
- if (ufs-config.lowerdirs)
- seq_printf(m, ,lowerdirs=%s, ufs-config.lowerdirs);
if (ufs-config.upperdir) {
seq_printf(m, ,upperdir=%s, ufs-config.upperdir);
seq_printf(m, ,workdir=%s, ufs-config.workdir);
@@ -522,7 +519,6 @@ enum {
static const match_table_t ovl_tokens = {
{OPT_LOWERDIR, lowerdir=%s},
- {OPT_LOWERDIRS, lowerdirs=%s},
{OPT_UPPERDIR, upperdir=%s},
{OPT_WORKDIR, workdir=%s},
{OPT_ERR, NULL}
@@ -555,13 +551,6 @@ static int ovl_parse_opt(char *opt, stru
return -ENOMEM;
break;
- case OPT_LOWERDIRS:
- kfree(config-lowerdirs);
- config-lowerdirs = match_strdup(args[0]);
- if (!config-lowerdirs)
- return -ENOMEM;
- break;
-
case OPT_WORKDIR:
kfree(config-workdir);
config-workdir = match_strdup(args[0]);
@@ -718,24 +707,18 @@ static int ovl_fill_super(struct super_b
goto out_free_config;
err = -EINVAL;
- if (ufs-config.lowerdir ufs-config.lowerdirs) {
- pr_err(overlayfs: both 'lowerdir' and 'lowerdirs' not
allowed\n);
- goto out_free_config;
- }
if (ufs-config.upperdir !ufs-config.workdir) {
pr_err(overlayfs: missing 'workdir'\n);
goto out_free_config;
}
if (!ufs-config.upperdir
- !ufs-config.lowerdir !ufs-config.lowerdirs) {
- pr_err(overlayfs: no 'upperdir', 'lowerdir' or 'lowerdirs'
specified\n);
+ !ufs-config.lowerdir) {
+ pr_err(overlayfs: no 'upperdir' or 'lowerdir' specified\n);
goto out_free_config;
}
if (ufs-config.lowerdir) {
- stacklen = 1;
- } else if (ufs-config.lowerdirs) {
- char *p = ufs-config.lowerdirs;
+ char *p = ufs-config.lowerdir;
for (;;) {
stacklen++;
@@ -780,15 +763,7 @@ static int ovl_fill_super(struct super_b
}
if (ufs-config.lowerdir) {
- BUG_ON(numlower = stacklen);
-
- err = ovl_lower_dir(ufs-config.lowerdir, stack[numlower],
ufs-lower_namelen, sb-s_stack_depth);
- if (err)
- goto out_put_workpath;
-
- numlower++;
- } else if (ufs-config.lowerdirs) {
- char *p = ufs-config.lowerdirs;
+ char *p = ufs-config.lowerdir;
for (;;) {
char *next = strchr(p, ':');
Re: kdbus: add selftests
On 11/14/2014 04:42 AM, Michael Ellerman wrote: On Wed, 2014-10-29 at 15:00 -0700, Greg Kroah-Hartman wrote: From: Daniel Mack dan...@zonque.org This patch adds a quite extensive test suite for kdbus that checks the most important code pathes in the driver. The idea is to extend the test suite over time. Also, this code can serve as an example implementation to show how to use the kernel API from userspace. Great to see selftests included. I needed this to get them building: Thanks a lot for testing! I've added your hunks to the patch set now. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] brcmfmac: kill URB when request timed out
On 13-11-14 03:33, Mathy Vanhoef wrote:
Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
assures the URB is never submitted twice. It also prevents a possible
use-after-free of the URB transfer buffer if a timeout occurs.
Acked-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: Mathy Vanhoef vanho...@gmail.com
---
For a discussion about this patch and the underlying problem, see the mails
with as subject [PATCH] brcmfmac: unlink URB when request timed out.
drivers/net/wireless/brcm80211/brcmfmac/usb.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 5265aa7..4572def 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinfo, u8 cmd,
goto finalize;
}
- if (!brcmf_usb_ioctl_resp_wait(devinfo))
+ if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
+ usb_kill_urb(devinfo-ctl_urb);
ret = -ETIMEDOUT;
- else
+ } else {
memcpy(buffer, tmpbuf, buflen);
+ }
finalize:
kfree(tmpbuf);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] mm, compaction: always update cached scanner positions
On 11/04/2014 01:28 AM, Joonsoo Kim wrote:
On Fri, Oct 31, 2014 at 04:53:44PM +0100, Vlastimil Babka wrote:
On 10/28/2014 08:08 AM, Joonsoo Kim wrote:
OK, so you don't find a problem with how this patch changes
migration scanner caching, just the free scanner, right?
So how about making release_freepages() return the highest freepage
pfn it encountered (could perhaps do without comparing individual
pfn's, the list should be ordered so it could be just the pfn of
first or last page in the list, but need to check that) and updating
cached free pfn with that? That should ensure rescanning only when
needed.
Hello,
Updating cached free pfn in release_freepages() looks good to me.
In fact, I guess that migration scanner also has similar problems, but,
it's just my guess. I admit your following arguments in patch description.
However, the downside is that potentially many pages are rescanned without
successful isolation. At worst, there might be a page where isolation from
LRU
succeeds but migration fails (potentially always).
So, I'm okay if you update cached free pfn in release_freepages().
Hi, here's the patch-fix to update cached free pfn based on release_freepages().
No significant difference in my testing.
--8--
From: Vlastimil Babka vba...@suse.cz
Date: Wed, 12 Nov 2014 16:37:21 +0100
Subject: [PATCH] mm-compaction-always-update-cached-scanner-positions-fix
This patch-fix addresses Joonsoo Kim's concerns about free pages potentially
being skipped when they are isolated and then returned due to migration
failure. It does so by setting the cached scanner pfn to the pageblock where
where the free page with the highest pfn of all returned free pages resides.
A small downside is that release_freepages() no longer returns the number of
freed pages, which has been used in a VM_BUG_ON check. I don't think the check
was important enough to warrant a more complex solution.
Signed-off-by: Vlastimil Babka vba...@suse.cz
Cc: Minchan Kim minc...@kernel.org
Cc: Mel Gorman mgor...@suse.de
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Michal Nazarewicz min...@mina86.com
Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: Christoph Lameter c...@linux.com
Cc: Rik van Riel r...@redhat.com
Cc: David Rientjes rient...@google.com
---
When squashed, the following paragraph should be appended to the fixed patch's
changelog:
To prevent free scanner from leaving free pages behind after they are returned
due to page migration failure, the cached scanner pfn is changed to point to
the pageblock of the returned free page with the highest pfn, before leaving
compact_zone().
mm/compaction.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index e0befc3..3669f92 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -41,15 +41,17 @@ static inline void count_compact_events(enum vm_event_item
item, long delta)
static unsigned long release_freepages(struct list_head *freelist)
{
struct page *page, *next;
- unsigned long count = 0;
+ unsigned long high_pfn = 0;
list_for_each_entry_safe(page, next, freelist, lru) {
+ unsigned long pfn = page_to_pfn(page);
list_del(page-lru);
__free_page(page);
- count++;
+ if (pfn high_pfn)
+ high_pfn = pfn;
}
- return count;
+ return high_pfn;
}
static void map_pages(struct list_head *list)
@@ -1223,9 +1225,24 @@ static int compact_zone(struct zone *zone, struct
compact_control *cc)
}
out:
- /* Release free pages and check accounting */
- cc-nr_freepages -= release_freepages(cc-freepages);
- VM_BUG_ON(cc-nr_freepages != 0);
+ /*
+* Release free pages and update where the free scanner should restart,
+* so we don't leave any returned pages behind in the next attempt.
+*/
+ if (cc-nr_freepages 0) {
+ unsigned long free_pfn = release_freepages(cc-freepages);
+ cc-nr_freepages = 0;
+
+ VM_BUG_ON(free_pfn == 0);
+ /* The cached pfn is always the first in a pageblock */
+ free_pfn = ~(pageblock_nr_pages-1);
+ /*
+* Only go back, not forward. The cached pfn might have been
+* already reset to zone end in compact_finished()
+*/
+ if (free_pfn zone-compact_cached_free_pfn)
+ zone-compact_cached_free_pfn = free_pfn;
+ }
trace_mm_compaction_end(ret);
--
2.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 0/5] clk: rockchip: add full support for HDMI clock on rk3288
Hi On 11/14/2014 09:46 AM, Mike Turquette wrote: Looking through the clock-tree there are a lot more components possibly using (or wanting to use) the npll: of course the VOPs, the edp, hdmi, isp, hevc, gpu, tsp uart0 and gmac. So I'm slightly uncomfortable with somehow reserving the npll for VOP0 alone. I understand the concern for other module clocks which may use NPLL as parent, we have to make sure all these clocks can get what they want even if NPLL is not available for them. So, let's have a look at them(without NPLL): with CPLL 400M and GPLL 594M, GPU/HEVC/ISP/TSP can get 100/200/400 from CPLL, and ~300/600 from GPLL, and ~500 from usbphy480m, these should be enough for those modules. DCLK_VOP1 for eDP/MIPI/LVDS, these clock can accept maybe more than 5% margin, we can get enough frequency for them now, we can change the CPLL to 800MHz for more option if it's needed one day. GMAC can get 50M from CPLL, usually we use external clock for GMAC. uart0 have frac divider, so we don't need to worry too much for it. It's true that I customized the usage of npll for VOP0 when we need some very special frequency, but it doesn't means other modules can't use the npll, it will always decided by clock core for module clocks that which parent is the best. We will just need to be very careful. As I've mentioned in the past we'll need to think about what happens to other clocks that happen to be parented by NPLL whenever we change it. So if we do this: 1. NPLL happens to be 500MHz. 2. We set GPU to be 500MHz and it picks NPLL. 3. We change NPLL to a different speed (like 600MHz). ...I believe in this scenario the GPU would start running at 600MHz immediately. We'd need to add special code to watch out for this and pick an alternate clock for the GPU (like the USB 480) before the NPLL change. If NPLL later changes back to 500MHz and the GPU still wanted 500MHz, we'd have to decide what to do. The summary is: it's pretty complicated It's complicated if there are more than one clock share the PLL and one of the clock wants to change the PLL output rate. Most of module clocks can't be changed during they are work, and it is better to route those clocks to a parent that would not change. Some of PLLs should not be changed after system initialized and they can be source for most of module clocks while some of PLLs have to change for some special requirement like HDMI that we can know the required frequency only when the device is plug in at run time. To make it simple, we can use the NPLL exclusively for HDMI/VOP0, just like what we do for APLL for cpu and DPLL for DDR, although what I though was share NPLL with other clocks in most of time, maybe we can use this case in the product like OTT BOX which will always have HDMI pluged. Maybe we can add an attribute for clock like NPLL in this way? There is an owner children for NPLL(for example VOP0) which can change NPLL's rate, and there it a fixed_rate attribute to describe if this clock is fixed or not. If VOP0 is not enabled, NPLL output is unfixed, other children clock can decide if they want to use a parent with unfixed output or another parent with fixed output. If VOP0 is enabled, then the NPLL's output has decide by the VOP0 and it become a fixed output parent. +Stephen Boyd Tomeu Vizoso Managing shared clocks is a subset of the general problems with clock constraints. Maybe Stephen or Tomeu have some comment here? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 / GPIO: Driver GPIO mappings for ACPI GPIOs
On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: With that change: Reviewed-by: Linus Walleij linus.wall...@linaro.org OK, made the changes and added your Reviewed-by. One semi-related question though. Alexandre ACKed the patch before, so what did that mean from the GPIO subsystem's perspective? Was the patch approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 2/3] mmc: omap_hsmmc: add tuning support
2014-11-13 13:56 GMT+01:00 Kishon Vijay Abraham I kis...@ti.com:
From: Balaji T K balaj...@ti.com
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host caps field.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[ kis...@ti.com : Set the functional clock to 192MHz if the contoller
supports HS200 ]
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 325
-
1 file changed, 322 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2e42ed3..675bd31d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -22,6 +22,7 @@
#include linux/dmaengine.h
#include linux/seq_file.h
#include linux/sizes.h
+#include linux/slab.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/dma-mapping.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
#define OMAP_HSMMC_SDMASA 0x0100
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -100,6 +102,7 @@
#define CLKEXTFREE (1 16)
#define CTPL (1 11)
#define DW8(1 5)
+#define BRR(1 5)
#define OD 0x1
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
@@ -129,6 +132,20 @@
#define CERR_EN(1 28)
#define BADA_EN(1 29)
+#define V1V8_SIGEN (1 19)
+#define AC12_SCLK_SEL (1 23)
+#define AC12_UHSMC_MASK(7 16)
+#define AC12_UHSMC_SDR50 (2 16)
+#define AC12_UHSMC_SDR104 (3 16)
+#define DLL_LOCK (1 0)
+#define DLL_CALIB (1 1)
+#define DLL_UNLOCK_STICKY (1 2)
+#define DLL_SWT(1 20)
+#define DLL_FORCE_SR_C_MASK(0x7F 13)
+#define DLL_FORCE_SR_C_SHIFT 13
+#define DLL_FORCE_VALUE(1 12)
+#define DLL_RESET (1 31)
+
#define INT_EN_MASK (BADA_EN | CERR_EN | ACE_EN | DEB_EN | DCRC_EN |\
DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
BRR_EN | BWR_EN | TC_EN | CC_EN)
@@ -143,18 +160,23 @@
#define SDR50 (1 0)
#define SDR104 (1 1)
#define DDR50 (1 2)
+#define CAPA2_TSDR50 (1 13)
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
+#define MAX_PHASE_DELAY0x7F
#define DRIVER_NAMEomap_hsmmc
#define VDD_1V8180 /* 18 uV */
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define EMMC_HSDDR_SD_SDR25_MAX5200
+#define SD_SDR50_MAX_FREQ 10400
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -198,6 +220,7 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ struct completion buf_ready;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -224,6 +247,13 @@ struct omap_hsmmc_host {
#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
#define HSMMC_WAKE_IRQ_ENABLED (1 2)
+
+ u32 *tuning_data;
+ int tuning_size;
+ int tuning_done;
+ int tuning_fsrc;
+ u32 tuning_uhsmc;
+ u32 tuning_opcode;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -233,6 +263,48 @@ struct omap_mmc_of_data {
u8 controller_flags;
};
+static const u32 ref_tuning_4bits[] = {
+ 0x00FF0FFF, 0xCCC3CCFF, 0xFFCC3CC3, 0xEFFEFFFE,
+ 0xDDFFDFFF, 0xFBFFFBFF, 0xFF7FFFBF, 0xEFBDF777,
+ 0xF0FFF0FF, 0x3CCCFC0F, 0xCFCC33CC, 0xEEFFEFFF,
+ 0xFDFFFDFF, 0xFFBFFFDF, 0xFFF7FFBB, 0xDE7B7FF7
+};
+
+static const u32 ref_tuning_8bits[]
Re: [PATCH RESEND 3.18-rc3 v2 1/2] trace: kdb: Fix kernel panic during ftdump
On 14/11/14 02:26, Steven Rostedt wrote: On Thu, 6 Nov 2014 12:41:55 + Daniel Thompson daniel.thomp...@linaro.org wrote: Currently kdb's ftdump command unconditionally crashes due to a null pointer de-reference whenever the command is run. This in turn causes the kernel to panic. The abridged stacktrace (gathered with ARCH=arm) is: --- cut here --- This is a nasty line. git am truncated the change log there thinking it was the end of the change log (that '---' did it). Oops. Looks like I shall have to train myself out of that particular habit (which will be tough, since I've used it long enough to be ingrained). Will repost as soon as I've thought about your other comments. Daniel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: usbhid: get/put around clearing needs_remote_wakeup
On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote: In usbhid_open, usb_autopm_get_interface is called before setting the needs_remote_wakeup flag, and usb_autopm_put_interface is called after hid_start_in. However, when the device is closed in usbhid_close, the same protection isn't there when clearing needs_remote_wakeup. This will add that to usbhid_close as well as usbhid_stop. Interesting, but this has the side effect of waking devices that are asleep just to remove the flag. Regards Oliver -- Oliver Neukum oneu...@suse.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [powerpc] Fix Text randomization
Now there is no way to disable TEXT randomization on a PPC32/PPC64
machine. Text randomization happens even in the case of echo 0
/proc/sys/kernel/randomize_va_space
This happens due to the incorrect definition of ELF_ET_DYN_BASE
at arch/powerpc/include/asm/elf.h
The function randomize_et_dyn is redundant and is removed.
Signed-off-by: Vineeth Vijayan vvija...@mvista.com
---
arch/powerpc/Kconfig |1 +
arch/powerpc/include/asm/elf.h |3 +--
arch/powerpc/kernel/process.c |9 -
3 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 88eace4..868a3c4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -88,6 +88,7 @@ config PPC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BINFMT_ELF
+ select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select OF
select OF_EARLY_FLATTREE
select OF_RESERVED_MEM
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 888d8f3..3793675 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -28,8 +28,7 @@
the loader. We need to make sure that it is out of the way of the program
that it will exec, and that there is sufficient room for the brk. */
-extern unsigned long randomize_et_dyn(unsigned long base);
-#define ELF_ET_DYN_BASE(randomize_et_dyn(0x2000))
+#define ELF_ET_DYN_BASE(0x2000)
#define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 923cd2d..e50467e 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1665,12 +1665,3 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
return ret;
}
-unsigned long randomize_et_dyn(unsigned long base)
-{
- unsigned long ret = PAGE_ALIGN(base + brk_rnd());
-
- if (ret base)
- return base;
-
- return ret;
-}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On 11/14/2014 02:12 PM, Sebastian Andrzej Siewior wrote: On 11/14/2014 09:24 AM, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? I have never seen this error while device is successfully enumerated and while working fine. Mostly u get it when we connect/disconnect devices to HOST port. Normally I use the following for testing BABBLE - Especially when a fully loaded USB HUB getting connected to HOST port. - Or repeatedly load and unload musb_hdrc.ko with some device connected. If nothing of the above work you might be the lucky one to have a good board Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] of: replace Asahi Kasei Corp venter prefix
On Friday 14 November 2014 17:38:58 Alexandre Courbot wrote:
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = 40;
magnetometer@c {
- compatible = ak,ak8975;
+ compatible = asahi-kasei,ak8975;
Mmm. So does this mean this device was never probed because the driver
did not recognize its compatible property? I cannot find ak,ak8975
anywhere else in the kernel.
No, the i2c bus behaves in a special way by matching the ak8975
i2c driver name with any *,ak8975 DT compatible string. Both
of the above will work with existing kernels.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch] gpio: add GPIO hogging mechanism
On Tue, Nov 4, 2014 at 1:38 AM, Benoit Parrot bpar...@ti.com wrote:
Sorry for slow replies...
Linus Walleij linus.wall...@linaro.org wrote on Mon [2014-Nov-03 10:59:53
+0100]:
On Tue, Oct 21, 2014 at 10:09 PM, Benoit Parrot bpar...@ti.com wrote:
qe_pio_a: gpio-controller@1400 {
@@ -110,6 +130,19 @@ Example of two SOC GPIO banks defined as
gpio-controller nodes:
reg = 0x1400 0x18;
gpio-controller;
#gpio-cells = 2;
+ gpio-hogs = line_b;
+
+ /* line_a hog is defined but not enabled in this example*/
+ line_a: line_a {
+ gpios = 5 0;
+ input;
+ };
+
+ line_b: line_b {
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
I don't see the point of having unused hogs and enabling them using
phandles.
Just let the core walk over all children nodes of a GPIO controller
and hog them. Put in a bool property saying it's a hog.
+ line_b: line_b {
+ gpio-hog;
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
I don't quite see the point with input hogs that noone can use
but whatever.
I am thinking that maybe the line name should be compulsory
so as to improbe readability. I mean there is always a reason
why you're hogging a pin and the name should say it.
Ok, so as an alternative I had presented something like this in my reply
to Alexandre Courbot's review comments:
I did consider a pinmux flavored format (not sure how hard to parse it
would be).
It would allow grouping if nothing else.
/* Line syntax: line_name gpio# flags direction-value [export] */
gpio-hogs = group_y;
group_y: group_y {
gpio-hogs-group =
line_x 15 0 output-low
line_y 16 0 output-high export
line_z 17 0 input
;
};
Now based on your comment would something like this work?
qe_pio_a: gpio-controller@1400 {
reg = 0x1400 0x18;
gpio-controller;
#gpio-cells = 2;
/* Line syntax: line_name gpio# flags direction-value [export] */
gpio-hogs: {
gpio-hogs-group =
foo-bar-gpio 15 0 output-low
bar-foo-gpio 16 0 output-high export
;
};
};
I *DON'T* want to mix up the exporting interface with the hogging
mechanism. These have to be two different things and different
patches.
But it looks strange and a bit convoluted. I don't see the point
of the grouping concept. There are ages old mails where I suggest
a very flat mechanism like this:
qe_pio_a: gpio-controller@1400 {
reg = 0x1400 0x18;
gpio-controller;
#gpio-cells = 2;
gpio-hogs-output-high = 15 0, 12 0;
gpio-hogs-output-low = 16 0;
};
I understand that if you want to give names to the pins that
is maybe a bit terse, then I suggest these named nodes:
qe_pio_a: gpio-controller@1400 {
reg = 0x1400 0x18;
gpio-controller;
#gpio-cells = 2;
{
gpio-hog-output-high = 15 0;
line-name = foo;
};
{
gpio-hog-output-high = 12 0;
line-name = bar;
};
{
gpio-hog-output-low = 16 0;
line-name = baz;
};
};
This is pretty straight-forward to parse from the device
tree by just walking over the children of a GPIO controller
node and looking for the hog keywords and optional
line names.
This mechanism can later add some per-pin export
keyword too, if that is desired. But that is a separate
discussion.
Still no need for groups or phandles or stuff like that...
It's a terser version of what I suggested in the last
reply from me:
+ line_b: line_b {
+ gpio-hog;
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
Just that I combine gpio-hog, gpios and output-low
into one property.
Any version works, I just don't get this grouping and
phandle business, if such complexity is needed it has
to be motivated.
This would group all hogs for one controller under a single child node.
Why is that a desireable feature?
I will try to find the other mail thread...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [Cocci] spatch for trivial pointer comparison style?
On Thu, 13 Nov 2014, Joe Perches wrote: On Fri, 2014-11-14 at 07:06 +0100, Julia Lawall wrote: On Thu, 13 Nov 2014, Joe Perches wrote: I added a checkpatch entry for this. Maybe some cocci test like this would be useful? @@ type t; t *p; @@ - p == NULL + !p @@ type t; t *p; @@ - p != NULL + p @@ type t; t *p; @@ - NULL == p + !p @@ type t; t *p; @@ - NULL != p + p This was discussed many years ago. I don't think that the change is desirable in all cases. There are functions like kmalloc where NULL means failure and !p seems like the reasonable choice. But there maybe other cases where NULL is somehow a meaningful value. Here is a link to the part of the discussion: https://lkml.org/lkml/2007/7/27/103 Yes, I agree with some of the things Al Viro said there, but isn't 'type t; t *p;' a subset of expression *e? No. How would you expect it to be different. type t means that the type is known. expression *e means that there is a * in the type. But there is no way to know that there is a * in the type without knowing the full type. Maybe something like e = f(...); ... if (e == NULL) S1 else S2 would be acceptable? But I was thinking that for some functions NULL might be considered to be a meaningful result, rather than a sign of failure. The following semantic patch gives almost 3000 results: @disable is_null@ expression e; statement S1,S2; @@ e = \(kmalloc\|kzalloc\|kcalloc\|devm_kmalloc\|devm_kzalloc\)(...); ... when != e if (+... - e == NULL + !e ...+) S1 else S2 julia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] gpio: add GPIO hogging mechanism
On Wed, Oct 29, 2014 at 8:09 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Wed, Oct 22, 2014 at 5:09 AM, Benoit Parrot bpar...@ti.com wrote:
+ line_b: line_b {
+ line_b {
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
+ };
(...)
I wonder if such usage of child nodes could not interfere with GPIO
drivers (existing or to be) that need to use child nodes for other
purposes. Right now there is no way to distinguish a hog node from a
node that serves another purpose, and that might become a problem in
the future.
Yes, so I have suggested a hog-something; keyword in there.
As long as the children don't have any compatible-strings we can
decide pretty much how they should be handled internally.
Are there custom drivers with child nodes inside the main chip
today?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: zynq: Remove secondary_startup() declaration from header
secondary_startup() in the header is not needed at all. Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/mach-zynq/common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h index 2bc71273c73c..382c60e9aa16 100644 --- a/arch/arm/mach-zynq/common.h +++ b/arch/arm/mach-zynq/common.h @@ -29,7 +29,6 @@ extern void zynq_slcr_cpu_state_write(int cpu, bool die); extern u32 zynq_slcr_get_device_id(void); #ifdef CONFIG_SMP -extern void secondary_startup(void); extern char zynq_secondary_trampoline; extern char zynq_secondary_trampoline_jump; extern char zynq_secondary_trampoline_end; -- 1.8.2.3 pgpEzlpfZ_MkZ.pgp Description: PGP signature
Re: [PATCH v3] of: replace Asahi Kasei Corp venter prefix
On Fri, Nov 14, 2014 at 05:38:58PM +0900, Alexandre Courbot wrote:
On 11/14/2014 10:43 AM, Kuninori Morimoto wrote:
[...]
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = 40;
magnetometer@c {
-compatible = ak,ak8975;
+compatible = asahi-kasei,ak8975;
Mmm. So does this mean this device was never probed because the driver did
not recognize its compatible property?
I2C (like SPI) has a fallback in case the OF table yields no match. The
of_modalias_node() that it uses extracts the module name from the device
tree node's compatible string by skipping the vendor prefix. The
resulting string is then set as the I2C client's name and causes the I2C
standard ID matching to succeed (see of_i2c_register_devices() for how
this is done in detail).
I cannot find ak,ak8975 anywhere else in the kernel.
If so,
Acked-by: Alexandre Courbot acour...@nvidia.com
Technically this is breaking backwards-compatibility from a DT
perspective, but I think it's safe to do because the Linux kernel has a
way of dealing with this and other operating systems should be able to
deal with this in a similar way (or even easier by letting the driver
match on the ak prefix as well for this particular chip).
So:
Acked-by: Thierry Reding tred...@nvidia.com
pgpjkZxRdF_7a.pgp
Description: PGP signature
loan offer apply now at 2%, only serious replies needed
Are you in need of any type of loan? of yes, kindly contact barrmarklewi...@gmail.com for more information. 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] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Mon, Nov 3, 2014 at 7:42 PM, Mika Westerberg mika.westerb...@linux.intel.com wrote: On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote: that's an issue that needs solving, but forcing every x86 kernel to ship with this driver, is not a proper solution. I would rather have the driver build in to the kernel now (and btw it has been already in mainline quite some time so I suspect many distros have already enabled it), than turning it module and render some devices that have been working previously, fail suddenly. We have an analogous problem with large device tree kernels for ARM (supporting a multitude of ARM subarchitectures): a lot of statically compiled-in drivers that just idle around after boot. What would be nice was for the kernel to have a way of marking some platform drivers such that if it has not been probed by init_late(), the entire driver would be discarded, like a module that gets unloaded. When I posed this idea in some forum it was considered pretty hard to achieve (plus I guess it runs into the dilemma that we can never discard strings) but I still think it'd be the right thing to do. It'd be very straight-forward for driver authors to annotate their on-chip platform drivers with some MODULE_LATE_DISCARD() or whatever. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v3] of: replace Asahi Kasei Corp venter prefix
On Fri, Nov 14, 2014 at 01:43:03AM +, Kuninori Morimoto wrote: From: Kuninori Morimoto kuninori.morimoto...@renesas.com Current vendor-prefixes.txt already has ak prefix for Asahi Kasei Corp by ae8c4209af2cec065fef15d200a42a04130799f7 It's usually enough to show the first 12 (or so) characters of the SHA1 here. git will show you the right one if you do something like: git log --abbrev=12 --abbrev-commit It's probably useful to git config core.abbrev 12 for Linux kernel repositories. Other than that it seems like you're being overly careful about not exceeding 72 characters. Your lines seem to wrap at around less than 50 columns. However, making lines too short results in equally hard to read commit messages, so please try to shoot for 72 columns for maximum readability. Thierry pgpWdGMsGZFww.pgp Description: PGP signature
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
It looks we have an implicit dependency to GPIO driver in Bay Trail, and
having this window until load the module is not acceptable to fulfill
this implicit dependency.
It is not implicit at all.
The user of the GPIO in ACPI DSDT table says something like:
Name (_DEP, Package () { \_SB.GPO2 })
or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
GPIO banks.
That's very nice for ACPI. But what do you expect the Linux kernel to
do with that?
Basically that is just like getting an -EPROBE_DEFER from the
gpiochip when the gpiod_get() call is issued, and you have to wait
because the gpiochip is not probed yet. We can solve that at runtime
right?
I had a discussion with Greg the other day that we have no way of
expressing inside the kernel that a resource such as a GPIO, a pin,
a clk or a regulator is used by some module. It's just a synchronous
gpiod_get() or whatever call, then there is a warning if you remove
a gpiochip with gpios still in use.
What is needed to make use of such a dependency mechanism is
a way to graph the dependencies between kernel drivers and
the resources (gpios, clocks, regulators...) they provide to other
drivers, so this information can be used when probing, removing,
powering up/down the cluster.
That problem needs to be solved in the device core, until then there
is not way to actually use that ACPI _DEP property for what I can
tell.
(On a side note: whoever came up with the idea that ACPI props
be 4 characters wide and start with an underscore and this
backslash obfuscation needs to... think differently.)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Tue, Nov 4, 2014 at 10:51 PM, David Cohen david.a.co...@linux.intel.com wrote: On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote: to a list of devices we depend on, we can defer this particular driver going further in probe until all the dependencies listed in _DEP are resolved. That's the best way to prevent this issue IMHO, but looks like it's already being addressed: https://lkml.org/lkml/2014/10/27/455 -EPROVE_DEFER will solve (hackishly) the probing problem. It will not solve remove() or power up/down sequencing. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 net 2/4] be2net: Implement ndo_gso_check()
-Original Message-
From: Joe Stringer [mailto:joestrin...@nicira.com]
Use vxlan_gso_check() to advertise offload support for this NIC.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Sathya Perla spe...@emulex.com
Thanks!
---
v2: Refactor out vxlan helper.
---
drivers/net/ethernet/emulex/benet/be_main.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 9a18e79..3e8475c 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4421,6 +4421,11 @@ static void be_del_vxlan_port(struct net_device
*netdev, sa_family_t sa_family,
Disabled VxLAN offloads for UDP port %d\n,
be16_to_cpu(port));
}
+
+static bool be_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+ return vxlan_gso_check(skb);
+}
#endif
static const struct net_device_ops be_netdev_ops = {
@@ -4450,6 +4455,7 @@ static const struct net_device_ops be_netdev_ops
= {
#ifdef CONFIG_BE2NET_VXLAN
.ndo_add_vxlan_port = be_add_vxlan_port,
.ndo_del_vxlan_port = be_del_vxlan_port,
+ .ndo_gso_check = be_gso_check,
#endif
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
From: Petr Tesarik ptesa...@suse.cz Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO Date: Fri, 14 Nov 2014 09:31:45 +0100 On Fri, 14 Nov 2014 10:42:35 +0900 (JST) HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote: From: Petr Tesarik ptesa...@suse.cz Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO Date: Thu, 13 Nov 2014 15:48:10 +0100 On Thu, 13 Nov 2014 09:25:48 -0500 Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote: (2014/11/13 17:06), Petr Tesarik wrote: On Thu, 13 Nov 2014 09:17:09 +0900 (JST) HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote: From: Vivek Goyal vgo...@redhat.com Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO Date: Wed, 12 Nov 2014 17:12:05 -0500 On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote: Currently, VMCOREINFO note information reports the virtual address of phys_base that is assigned to symbol phys_base. But this doesn't make sense because to refer to value of the phys_base, it's necessary to get the value of phys_base itself we are now about to refer to. Hi Hatayama, /proc/vmcore ELF headers have virtual address information and using that you should be able to read actual value of phys_base. gdb deals with virtual addresses all the time and can read value of any symbol using those headers. So I am not sure what's the need for exporting actual value of phys_base. Sorry, my logic in the patch description was wrong. For /proc/vmcore, there's enough information for makedumpdile to get phys_base. It's correct. The problem here is that other crash dump mechanisms that run outside Linux kernel independently don't have information to get phys_base. Yes, but these mechanisms won't be able to read VMCOREINFO either, will they? I don't intend such sophisticated function only by VMCOREINFO. Search vmcore for VMCOREINFO using strings + grep before opening it by crash. I intend that only here. I think this is very crude and not proper way to get to vmcoreinfo. Same here. If VMCOREINFO must be locatable without communicating any information to the hypervisor, then I would rather go for something similar to what s390(x) folks do - a well-known location in physical memory that contains a pointer to a checksummed OS info structure, which in turn contains the VMCOREINFO pointers. I'm a bit surprised such mechanism is not needed by Fujitsu SADUMP. Or is that part of the current plan, Daisuke? It's useful if there is. I don't plan now. For now, the idea of this patch is enough for me. BTW, for the above idea, I suspect that if the location in the physical memory is unique, it cannot deal with the kdump 2nd kernel case. No, not at all. The low 640K are copied away to a pre-allocated area by kexec purgatory code on x86_64, so it's safe to overwrite any location in there. The copy is needed, because BIOS already uses some hardcoded addresses in that range. I think the Linux kernel may safely use part of PFN 0 starting at physical address 0x0500. This area was originally used by MS-DOS, so chances are high that no broken BIOS out there corrupts this part of RAM... In fact, I didn't consider in such deep way... I had forgot back up region at all. But it's hard to use the low 640K area. Then, it's hard to get phys_base of the kdump 1st kernel that is assumed to be saved in thw low 640K now. Because externally running mechanism can run after kdump 2nd kernel has booted up, crash utility needs to convert a read request to the low 640K area into the corresponding part of the pre-allocated area. See kdump_backup_region_init() in crash utility, which tries to find the pre-allocated area via ELF header, where symbol kexec_crash_image is read to find ELF header. This means we need phys_base to find the pre-allocated area. Anyway, I'm not going to implement it right now for lack of time. I'm adding it to my TODO list, but if anybody wants to post a patch, I won't be offended. Petr T -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction
On Thu, Nov 13, 2014 at 05:26:34PM -0800, Joe Perches wrote: On Fri, 2014-11-14 at 01:18 +, Russell King - ARM Linux wrote: On Thu, Nov 13, 2014 at 04:45:43PM -0800, Joe Perches wrote: I think you shouldn't apply these patches or updated ones either until all the current uses are converted. Where are the dependencies mentioned? I mentioned it when these patches (which are not mine btw), were submitted the second time. Yes, I'm well aware that the author of the ARM patches are Yalin Wang. https://lkml.org/lkml/2014/10/27/69 How do I get to know when all the dependencies are met? No idea. Who is tracking the dependencies? Not me. Right, what that means is that no one is doing that. What you've also said in this thread now is that the ARM patches should not be applied until all the other users are converted. As those patches are going via other trees, that means the ARM patches can only be applied _after_ the next merge window _if_ all maintainers pick up the previous set. As I'm not tracking the status of what other maintainers do, I'm simply going to avoid applying these patches until after the next merge window and hope that the other maintainers pick the dependent patches up and get them in during the next merge window. If not, I guess we'll see compile breakage. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
+Rafael
On Fri, Nov 14, 2014 at 10:39:07AM +0100, Linus Walleij wrote:
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
It looks we have an implicit dependency to GPIO driver in Bay Trail, and
having this window until load the module is not acceptable to fulfill
this implicit dependency.
It is not implicit at all.
The user of the GPIO in ACPI DSDT table says something like:
Name (_DEP, Package () { \_SB.GPO2 })
or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
GPIO banks.
That's very nice for ACPI. But what do you expect the Linux kernel to
do with that?
It should prevent the driver from probing until all the devices listed
in _DEP have drivers probed.
However, it turned out that this is not that straightforward after all
:-( For one, it looks like _DEP is used also for non-operation region
dependencies. This is not in the ACPI spec but we have seen this in real
machines out there.
Other thing I heard, is that handling all these dependencies in driver
core might be nightmare to maintain.
Basically that is just like getting an -EPROBE_DEFER from the
gpiochip when the gpiod_get() call is issued, and you have to wait
because the gpiochip is not probed yet. We can solve that at runtime
right?
Yes we can if the driver core prevents probing the driver.
I had a discussion with Greg the other day that we have no way of
expressing inside the kernel that a resource such as a GPIO, a pin,
a clk or a regulator is used by some module. It's just a synchronous
gpiod_get() or whatever call, then there is a warning if you remove
a gpiochip with gpios still in use.
What is needed to make use of such a dependency mechanism is
a way to graph the dependencies between kernel drivers and
the resources (gpios, clocks, regulators...) they provide to other
drivers, so this information can be used when probing, removing,
powering up/down the cluster.
That problem needs to be solved in the device core, until then there
is not way to actually use that ACPI _DEP property for what I can
tell.
I agree.
(On a side note: whoever came up with the idea that ACPI props
be 4 characters wide and start with an underscore and this
backslash obfuscation needs to... think differently.)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes
Hi Arnd, On Thu, 13 Nov 2014, Arnd Bergmann wrote: On Thursday 13 November 2014 14:54:19 Peter Griffin wrote: It also seems that you have put the node in the wrong place, as the reg property apparently refers to a different address space. Did you mean to put this under the syscfg_core node? Your correct in that it refers to the syscfg_core address space. However I intentionaly didn't put it under the syscfg_core node. The phy is more unique than most other devices in that in this instance it is only controlled from two syscfg_core registers which happen to be in the same sysconf bank. However most other devices tend to have a combination of some memory mapped registers and also some sysconfig registers which does then create a conflict over where the dt node should live. Currently I can't find an example but there is also no guarentee that a device will not have some configuration bits in syscfg_core and some other bits in syscfg_rear/front registers. The phy for example could have had one register in each, which would make deciding where to put it difficult. So to create coherency / conformity we decided to put all the IP blocks under the soc node. Also its worth pointing if your not already aware that sysconf_core/rear/front isn't really a device, it's just a regmap abstraction of some memory mapped configuration registers where a bunch of seemingly random control bits get stuffed. Of course if you feel strongly about it I can of course change it like you suggested, but that is the reasoning / rationale of why it was done like this initially. The problem is your use of the 'reg' property. If it doesn't refer to the node's address space, it shouldn't be called 'reg'. Please fix the binding. I'll appologize in advance as I'm not sure I've understood you correctly, definately your answer has given me a bunch more questions to clarify my understanding... In the case of this particular node, then both reg properties refer to the syscfg_core address space as both 0xf8 0x04 and 0xf4 0x04 are offsets into syscfg_core registers. So moving it under the syscfg_core like you originaly suggested I believe would meet the definition of 'reg' (describes the address of the device's resources within the address space defined by its parent bus). Or maybe you meant, if I want to keep the picophy node where it is (under soc), I need to stop using the reg property? The other problem I was describing is a device with some memory mapped registers and some sysconfig registers you can find examples already upstream in stih416.dtsi file with the ethernet0 and miphy365x_phy nodes. Here the first 1/2 reg properties are expressed as a 32 bit physical address and size (meets the spec definition), and the last is expressed as a sysconfig offset and size (which AFAIK doesn't match the spec definition). This change in address space is however documented in the bindings documentation. How should devices which have multiple address spaces ideally be handled? From looking around in the source I see a few different ways people have done this: - 1) Some drivers encode the data statically into the source and make a decision based on compatible string. 2) Some drivers add a couple of extra dt properties to encode the offset (spifsm in stih416) 3) Some drivers mix address spaces in the reg properties (examples given above) 3) Probably some other ways I've not found yet Is there a blessed way of doing this? It would be nice at least for all the drivers in STI to be doing it the same as currently there seems to be a mix of implementations. For the moment I think we can forget the third example in my previous email as it is currently hypothetical. regards, 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 v2] kvm: memslots: replace heap sort with insertion sort
On 14/11/2014 00:00, Igor Mammedov wrote:
memslots is a sorted array, when slot changes in it
with current heapsort it would take O(n log n) time
to update array, while using insertion sort like
algorithm on array with 1 item out of order will
take only O(n) time.
Replace current heapsort with custom sort that
takes advantage of memslots usage pattern and known
position of changed slot.
performance change of 128 memslots insersions with
gradually increasing size (the worst case):
heap sort custom sort
max: 249747 2500 cycles
with custom sort alg taking ~98% less then original
update time.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
v2:
- replace swap with slot shift, improves result 2x
- reprofile original/swap based and swapless 15 times
discarding spikes swap based takes ~5900 cycles max
and swapless ~2500 cycles.
---
virt/kvm/kvm_main.c | 54
++---
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 25ffac9..49f896a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -668,31 +668,35 @@ static int kvm_create_dirty_bitmap(struct
kvm_memory_slot *memslot)
return 0;
}
-static int cmp_memslot(const void *slot1, const void *slot2)
-{
- struct kvm_memory_slot *s1, *s2;
-
- s1 = (struct kvm_memory_slot *)slot1;
- s2 = (struct kvm_memory_slot *)slot2;
-
- if (s1-npages s2-npages)
- return 1;
- if (s1-npages s2-npages)
- return -1;
-
- return 0;
-}
-
/*
- * Sort the memslots base on its size, so the larger slots
- * will get better fit.
+ * Insert memslot and re-sort memslots based on their size,
+ * so the larger slots will get better fit. Sorting algorithm
+ * takes advantage of having initially sorted array and
+ * known changed memslot position.
*/
-static void sort_memslots(struct kvm_memslots *slots)
+static void insert_memslot(struct kvm_memslots *slots,
+struct kvm_memory_slot *new)
{
- int i;
+ int i = slots-id_to_index[new-id];
+ struct kvm_memory_slot *old = id_to_memslot(slots, new-id);
+ struct kvm_memory_slot *mslots = slots-memslots;
+
It is important to leave the *old = *new assignment here, see the
comment in __kvm_set_memory_region:
/*
* We can re-use the old_memslots from above, the only difference
* from the currently installed memslots is the invalid flag. This
* will get overwritten by update_memslots anyway.
*/
This small problem was already present in v1, but I didn't notice it
yesterday. With the new code, we can add it inside this if:
+ if (new-npages == old-npages)
+ return;
Do you agree? (No need to send v3).
Paolo
- sort(slots-memslots, KVM_MEM_SLOTS_NUM,
- sizeof(struct kvm_memory_slot), cmp_memslot, NULL);
+ while (1) {
+ if (i (KVM_MEM_SLOTS_NUM - 1)
+ new-npages mslots[i + 1].npages) {
+ mslots[i] = mslots[i + 1];
+ i++;
+ } else if (i 0 new-npages mslots[i - 1].npages) {
+ mslots[i] = mslots[i - 1];
+ i--;
+ } else {
+ mslots[i] = *new;
+ break;
+ }
+ }
for (i = 0; i KVM_MEM_SLOTS_NUM; i++)
slots-id_to_index[slots-memslots[i].id] = i;
@@ -702,13 +706,7 @@ static void update_memslots(struct kvm_memslots *slots,
struct kvm_memory_slot *new)
{
if (new) {
- int id = new-id;
- struct kvm_memory_slot *old = id_to_memslot(slots, id);
- unsigned long npages = old-npages;
-
- *old = *new;
- if (new-npages != npages)
- sort_memslots(slots);
+ insert_memslot(slots, new);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 V6 2/3] arm:add bitrev.h file to support rbit instruction
On Fri, Nov 14, 2014 at 10:01:34AM +0800, Wang, Yalin wrote: -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, November 14, 2014 7:53 AM To: Wang, Yalin On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote: This patch add bitrev.h file to support rbit instruction, so that we can do bitrev operation by hardware. Signed-off-by: Yalin Wang yalin.w...@sonymobile.com --- arch/arm/Kconfig | 1 + arch/arm/include/asm/bitrev.h | 21 + 2 files changed, 22 insertions(+) create mode 100644 arch/arm/include/asm/bitrev.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 89c4b5c..be92b3b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -28,6 +28,7 @@ config ARM select HANDLE_DOMAIN_IRQ select HARDIRQS_SW_RESEND select HAVE_ARCH_AUDITSYSCALL if (AEABI !OABI_COMPAT) + select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7) Looking at this, this is just wrong. Take a moment to consider what happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs. What happens if an ARMv6 CPU tries to execute an rbit instruction? Is it possible to build a kernel that support both CPU_V6 and CPU_V7? Absolutely it is. I mean in Kconfig, CPU_V6 = y and CPU_V7 = y ? Yes. If there is problem like you said, How about this solution: select HAVE_ARCH_BITREVERSE if ((CPU_V7M || CPU_V7) !CPU_V6) That would work. For this patch, I just cherry-pick from Joe, If you are not responsible for this part, I will submit to the maintainers for these patches . Sorry for that . I think you need to discuss with Joe how Joe would like his patches handled. However, it seems that Joe already sent his patches to the appropriate maintainers, and they have been applying those patches themselves. Since your generic ARM changes depend on these patches being accepted first, this means is that I can't apply the generic ARM changes until those other patches have hit mainline, otherwise things are going to break. So, when you come to submit the latest set of patches to the patch system, please do so only after these dependent patches have been merged into mainline so that they don't get accidentally applied before hand and break the two drivers that Joe mentioned. Thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 7/8] powerpc, ptrace: Enable support for miscellaneous debug registers
On 11/13/14, Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
On 11/11/2014 10:56 AM, Anshuman Khandual wrote:
This patch enables get and set of miscellaneous debug registers through
ptrace PTRACE_GETREGSET-PTRACE_SETREGSET interface by implementing new
powerpc specific register set REGSET_MISC support corresponding to the
new ELF core note NT_PPC_MISC added previously in this regard.
Right now this one does not compile for ppc64e_defconfig and
pmac32_defconfig config options. The patch below will fix it
and would be part of next revision.
It would be great to have a test tool for that under
tools/testing/selftests/ptrace/
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 61a2581..be566eb 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1326,6 +1326,7 @@ static int tm_cvmx_set(struct task_struct *target,
}
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+#ifdef CONFIG_PPC64
/*
* get_misc_dbg
*
@@ -1339,6 +1340,9 @@ static int tm_cvmx_set(struct task_struct *target,
* unsigned long ppr;
* unsigned long tar;
* };
+ *
+ * The data element 'tar' will be valid only if the
+ * kernel has CONFIG_PPC_BOOK3S_64 config option enabled.
*/
static int get_misc_dbg(struct task_struct *target,
const struct user_regset *regset, unsigned int pos,
@@ -1348,7 +1352,10 @@ static int get_misc_dbg(struct task_struct *target,
/* Build test */
BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
/* DSCR register */
ret = user_regset_copyout(pos, count, kbuf, ubuf,
@@ -1362,12 +1369,14 @@ static int get_misc_dbg(struct task_struct *target,
sizeof(unsigned long),
2 * sizeof(unsigned long));
+#ifdef CONFIG_PPC_BOOK3S_64
/* TAR register */
if (!ret)
ret = user_regset_copyout(pos, count, kbuf, ubuf,
target-thread.tar,
2 * sizeof(unsigned long),
3 * sizeof(unsigned long));
+#endif
return ret;
}
@@ -1384,6 +1393,9 @@ static int get_misc_dbg(struct task_struct *target,
* unsigned long ppr;
* unsigned long tar;
* };
+ *
+ * The data element 'tar' will be valid only if the
+ * kernel has CONFIG_PPC_BOOK3S_64 config option enabled.
*/
static int set_misc_dbg(struct task_struct *target,
const struct user_regset *regset, unsigned int pos,
@@ -1394,7 +1406,10 @@ static int set_misc_dbg(struct task_struct *target,
/* Build test */
BUILD_BUG_ON(TSO(dscr) + 2 * sizeof(unsigned long) != TSO(ppr));
+
+#ifdef CONFIG_PPC_BOOK3S_64
BUILD_BUG_ON(TSO(ppr) + sizeof(unsigned long) != TSO(tar));
+#endif
/* DSCR register */
ret = user_regset_copyin(pos, count, kbuf, ubuf,
@@ -1407,15 +1422,17 @@ static int set_misc_dbg(struct task_struct *target,
target-thread.ppr,
sizeof(unsigned long),
2 * sizeof(unsigned long));
-
+#ifdef CONFIG_PPC_BOOK3S_64
/* TAR register */
if (!ret)
ret = user_regset_copyin(pos, count, kbuf, ubuf,
target-thread.tar,
2 * sizeof(unsigned long),
3 * sizeof(unsigned long));
+#endif
return ret;
}
+#endif /* CONFIG_PPC64 */
/*
* These are our native regset flavors.
@@ -1438,7 +1455,9 @@ enum powerpc_regset {
REGSET_TM_CFPR, /* TM checkpointed FPR registers */
REGSET_TM_CVMX, /* TM checkpointed VMX registers */
#endif
+#ifdef CONFIG_PPC64
REGSET_MISC /* Miscellaneous debug registers */
+#endif
};
static const struct user_regset native_regsets[] = {
@@ -1495,11 +1514,13 @@ static const struct user_regset native_regsets[] = {
.active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
},
#endif
+#ifdef CONFIG_PPC64
[REGSET_MISC] = {
.core_note_type = NT_PPC_MISC, .n = ELF_NMISCREG,
.size = sizeof(u64), .align = sizeof(u64),
.get = get_misc_dbg, .set = set_misc_dbg
},
+#endif
};
static const struct user_regset_view user_ppc_native_view = {
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Regards,
Denis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: [PATCH v2 1/1] ftruncate, truncate: create fanotify events
On Tue 11-11-14 20:55:26, Heinrich Schuchardt wrote: On 11.11.2014 12:09, Jan Kara wrote: On Mon 10-11-14 23:34:15, Christoph Hellwig wrote: On Mon, Nov 10, 2014 at 09:30:29PM +0100, Jan Kara wrote: So what I somewhat dislike about this patch is that notify_change() is sometimes called with dentry and sometimes with path. That way it's not completely clear when fanotify events will be generated and when not. No. With my patch notify_change is still only called with dentry. It is only new function notify_change_path which will be called with a path. And this function will only be called from do_truncate up to now. Sadly it isn't easy to provide struct path in all the places where we are calling notify_change() so I'm not sure what would a better solution look like either :( We only want to create FAN_MODIFY events for ATTR_SIZE. So only for these events we need a path. To my knowledge notify_change is called with ATTR_SIZE from do_truncate(), ecryptfs_truncate() and will be called with ATTR_SIZE from ovl_setattr() for a truncation. There's also a call in fs/cachefiles/interface.c: cachefiles_attr_changed() and fs/hpfs/namei.c: hpfs_unlink() and nfs plays with ATTR_SIZE although I wasn't able to track down whether it actually passes it to notify_change(). So I agree you have covered almost all the cases. But it's just prone to errors (as you can see when you missed some cases) because it isn't clear to callers of notify_change() whether and why they should provide the path via notify_change_path() or not. But see below. ecryptfs_dentry_to_lower_path() could be used in ecryptfs_truncate() to obtain a path. ovl_path_upper() could be used in ovl_setattr() to obtain a path. Agreed, this can and should be done. I suspect the right thing to do is to split out the truncate path from notify_change, as it's fairly different anyway. Yeah, that would make sense. I wanted to say it's quite a lot of work to change all the filesystems (where the separation of truncate path makes sense as well IMHO) but actually it's possible to just do the separation at the VFS level and still call -setattr() fs callback for now. Heinrich will you look into this? You seem to agree that struct path has to passed to do_truncate() and further to the notification layer. Yes. Currently do_truncate() calls notify_change() which does not accept a path argument. Here the size change is implemented as an attribute change. Furthermore time attributes are changed. What do you exactly mean by just do the separation at the virtual file system level and still call -setattr() fs callback for now. Do you want to duplicate the logic of notify_change() to a new function notify_truncate() which will at least have to handle ATTR_SIZE, ATTR_FORCE, ATTR_KILL_SUID, ATTR_KILL_SGID, ATTR_FILE and time attributes? And from notify_truncate() call new function fsnotify_truncate() with a logic like fsnotify_modify() but accepting a path? This would result in a lot of code duplication. Yes, I forgot about other changes coupled with truncate and you're right that duplicating them would do more bad than good. But what we could do is to just have __notify_change() which takes both path dentry as you did it. notify_change() which takes just dentry and verifies ATTR_SIZE is not set (WARN_ON_ONCE if it is). notify_change_truncate() which takes path. This still isn't pretty but at least makes errors harder to do. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/2] ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12
The TMU device tree node definition for Exynos4x12 family of SoCs.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 861bb91..2e9f1f7 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -271,4 +271,14 @@
compatible = samsung,exynos4x12-usb2-phy;
samsung,sysreg-phandle = sys_reg;
};
+
+ tmu@100C {
+ compatible = samsung,exynos4412-tmu;
+ interrupt-parent = combiner;
+ interrupts = 2 4;
+ reg = 0x100C 0x100;
+ clocks = clock 383;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 2/2] ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
This patch enables support for TMU at Exynos4412 based Trats2 board.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 5e066cd..121430d 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -551,6 +551,11 @@
status = okay;
};
+ tmu@100C {
+ vtmu-supply = ldo10_reg;
+ status = okay;
+ };
+
i2c_ak8975: i2c-gpio-0 {
compatible = i2c-gpio;
gpios = gpy2 4 0, gpy2 5 0;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/6 V2] Documentation: devicetree: arizona: Add bindings for WM8280
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7bd1273..dc81b71 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -8,6 +8,7 @@ Required properties: - compatible : One of the following chip-specific strings: wlf,wm5102 wlf,wm5110 +wlf,wm8280 wlf,wm8997 - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -26,10 +27,16 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered -in Documentation/devicetree/bindings/regulator/regulator.txt + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, +as covered in Documentation/devicetree/bindings/regulator/regulator.txt + + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, +wm5110, wm8280) + + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, +wm5110, wm8280) + + - SPKVDD-supply : Speaker driver power supply (wm8997) Optional properties: -- 1.7.2.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: [GIT PULL] Immutable branch between MFD, GPIO and I2C
On Mon, Nov 10, 2014 at 6:43 PM, Lee Jones lee.jo...@linaro.org wrote: Please don't pull this -- it is missing a patch. Will fix. Okay, dependency fixed. Sorry for the fuss. Pull when ready. Letting it just sit around unless there are conflicts coming up... Seems like this can go through MFD alone from the GPIO side of things. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [Cocci] spatch for trivial pointer comparison style?
I don't think that the change is desirable in all cases. There are functions like kmalloc where NULL means failure and !p seems like the reasonable choice. But there maybe other cases where NULL is somehow a meaningful value. How do you think about to adjust checks for null pointers not only in Linux source files but also in other applications? Are there any more software design challenges to consider with the definition of the preprocessor symbol NULL? Regards, Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/6] gpio: arizona: Add support for WM8280/WM8281
On Thu, Nov 13, 2014 at 6:50 PM, Richard Fitzgerald r...@opensource.wolfsonmicro.com wrote: Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch: Introduce load_acquire() and store_release()
Hi Alex, On Thu, Nov 13, 2014 at 07:27:23PM +, Alexander Duyck wrote: It is common for device drivers to make use of acquire/release semantics when dealing with descriptors stored in device memory. On reviewing the documentation and code for smp_load_acquire() and smp_store_release() as well as reviewing an IBM website that goes over the use of PowerPC barriers at http://www.ibm.com/developerworks/systems/articles/powerpc.html it occurred to me that the same code could likely be applied to device drivers. As a result this patch introduces load_acquire() and store_release(). The load_acquire() function can be used in the place of situations where a test for ownership must be followed by a memory barrier. The below example is from ixgbe: if (!rx_desc-wb.upper.status_error) break; /* This memory barrier is needed to keep us from reading * any other fields out of the rx_desc until we know the * descriptor has been written back */ rmb(); With load_acquire() this can be changed to: if (!load_acquire(rx_desc-wb.upper.status_error)) break; I still don't think this is a good idea for the specific use-case you're highlighting. On ARM, an mb() can be *significantly* more expensive than an rmb() (since we may have to drain store buffers on an outer L2 cache) and on arm64 it's not at all clear that an LDAR is more efficient than an LDR; DMB LD sequence. I can certainly imagine implementations where the latter would be preferred. So, whilst I'm perfectly fine to go along with mandatory acquire/release macros (we should probably add a check to barf on __iomem pointers), I don't agree with using them in preference to finer-grained read/write barriers. Doing so will have a real impact on I/O performance. Finally, do you know of any architectures where load_acquire/store_release aren't implemented the same way as the smp_* variants on SMP kernels? Will -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
