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

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

linux.kernel@googlegroups.com

Today's topics:

* batman-adv: Use seq_overflow - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4c6be54c4cfbdd71?hl=en
* mtd: st_spi_fsm: Allocate resources and register with MTD framework - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/8eb175d8e03582a7?hl=en
* dma: tegra: Use runtime_pm for clk enable/disable - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6766cc6ffea941f6?hl=en
* mm/migrate: remove result argument on page allocation function for migration
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fab8622d4d72e03b?hl=en
* usb: dwc3: use quirks to know if a particualr platform doesn't have PHY - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/185df9b46897a043?hl=en
* phy: Add provision for tuning phy. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d26d42c3b09f58d4?hl=en
* mm/zswap: change zswap to writethrough cache - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/83a057c0f19449e9?hl=en
* sched/numa: fix set cpupid on page migration twice against normal page - 5
messages, 1 author
http://groups.google.com/group/linux.kernel/t/2879b635b367c8c6?hl=en
* mfd: menelaus: Start to use irqdomain - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0018ab22f96f187d?hl=en
* net: of_mdio: Scan PHYs which have device_type set to ethernet-phy - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/098803c3358dfc40?hl=en
* dma: mv_xor: remove mv_desc_get_dest_addr() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1dba4c15122332c3?hl=en
* Documentation: pci: Minor cleanup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cda14d708591570c?hl=en
* Documentation: pci: Add pcie-howto.txt - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d50a5a1acc7d6131?hl=en
* mfd: ssbi: Remove platform data structs and hide ssbi type enum - 4 messages,
1 author
http://groups.google.com/group/linux.kernel/t/b32f44967d482775?hl=en
* mm, page_alloc: allow __GFP_NOFAIL to allocate below watermarks after
reclaim - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c2e46b04eaa7fc17?hl=en
* debugobject: add support for kref - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0aa9a7811e6f1e9f?hl=en

==============================================================================
TOPIC: batman-adv: Use seq_overflow
http://groups.google.com/group/linux.kernel/t/4c6be54c4cfbdd71?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 12:40 am
From: Al Viro


On Wed, Dec 11, 2013 at 12:26:17AM -0800, Joe Perches wrote:
> On Wed, 2013-12-11 at 08:05 +0000, Al Viro wrote:
> > On Wed, Dec 11, 2013 at 07:55:26AM +0000, Al Viro wrote:
> >
> > > This sucker should return 0. Insufficiently large buffer will be handled
> > > by caller, TYVM, if you give that caller a chance to do so. Returning 1
> > > from ->show() is a bug in almost all cases, and definitely so in this one.
> > >
> > > Just in case somebody decides that above is worth copying: It Is Not.
> > > Original code is buggy, plain and simple. This one trades the older
> > > bug ("fail with -EINVAL whenever the buffer is too small") with just as buggy
> > > "silently skip an entry entirely whenever the buffer is too small".
> > >
> > > Don't Do That.
> >
> > Pardon - Joe has made seq_overflow return -1 instead of true. Correction
> > to the above, then - s/This trades.*\./This is just as buggy./
>
> Yeah, I started to use true/false, 0/1, but thought
> I needed to match what seq_printf/seq_vprintf does.
>
> > Conclusion is still the same - Don't Do That. Returning -1 on insufficiently
> > large buffer is a bug, plain and simple.
>
> int seq_vprintf(struct seq_file *m, const char *f, va_list args)
> {
> int len;
>
> if (m->count < m->size) {
> len = vsnprintf(m->buf + m->count, m->size - m->count, f, args);
> if (m->count + len < m->size) {
> m->count += len;
> return 0;
> }
> }
> seq_set_overflow(m);
> return -1;
> }
> EXPORT_SYMBOL(seq_vprintf);
>
> int seq_printf(struct seq_file *m, const char *f, ...)
> {
> int ret;
> va_list args;
>
> va_start(args, f);
> ret = seq_vprintf(m, f, args);
> va_end(args);
>
> return ret;
> }
> EXPORT_SYMBOL(seq_printf);
>
> > And this patch series is completely misguided - it doesn't fix any bugs
> > *and* it provides a misleading example for everyone. See the reaction
> > right in this thread, proposing to spread the same bug to currently
> > working iterators.
>
> Anyway, changing seq_overflow is easy enough
>
> You prefer this?
>
> bool seq_overflow(struct seq_file *seq)
> {
> return m->count == m->size;
> }

I prefer a series that starts with fixing the obvious bugs (i.e. places
where we return seq_printf/seq_puts/seq_putc return value from ->show()).
All such places should return 0. Then we need to look at the remaining
places that check return value of seq_printf() et.al. And decide whether
the callers really care about it.

Theoretically, there is a legitimate case when we want to look at that
return value. Namely,
seq_print(...)
if (!overflowed)
do tons of expensive calculations
generate more output
return 0
That is the reason why those guys hadn't been returning void to start with.
And yes, it was inviting bugs with ->show() returning -1 on overflows.
Bad API design, plain and simple.

I'm not sure we actually have any instances of that legitimate case, TBH.
_IF_ we do, we ought to expose seq_overflow() (with saner name - this one
invites the same "it's an error, need to report it" kind of bugs) and use
it in such places. But that needs to be decided on per-caller basis. And
I'd expect that there would be few enough such places after we kill the
obvious bugs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mtd: st_spi_fsm: Allocate resources and register with MTD framework
http://groups.google.com/group/linux.kernel/t/8eb175d8e03582a7?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 11 2013 12:50 am
From: Lee Jones


Hi Brian,

Thank you for taking the time to review, it's very much appreciated.
You bought out some interesting points that I'm happy to go away and
rectify. Firstly however, as I inherited this code I'd like to give
Angus a chance to comment before we go off on our own tangent and
rework some of the good code which perhaps should remain unchanged.

Angus, do you have enough time to go through Brian's review comments
and perhaps reply to the ones that you feel would benefit from your
expert knowledge. To be frank, some of the questions that were asked I
wouldn't be able to answer without your guidance in any case.

Thanks both.

Kind regards,
Lee

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Wed, Dec 11 2013 1:40 am
From: Angus Clark


Hi Lee and Brian,

I would also like to thank Brian; as always, very sensible comments.

I am tied up most of today and off work tomorrow (Christmas shopping!), but I
will set aside Friday to go through the comments in detail. I should also have
some time next week if necessary, subject to any panics that might arise!

I also intend to respond to Huang's updated 'spi-nor' framework at the same
time. At some stage, I would expect some of the device probing code in
st_spi_fsm, particularly the configuration of read/write/erase operations based
on capabilities, to be pulled into the 'spi-nor' framework. I do not see this
an an obstacle to st_spi_fsm being integrated earlier though; it's presence in
the kernel would provide another example of a H/W Controller that 'spi-nor'
needs to accommodate.

Cheers,

Angus


On 12/11/2013 08:48 AM, Lee Jones wrote:
> Hi Brian,
>
> Thank you for taking the time to review, it's very much appreciated.
> You bought out some interesting points that I'm happy to go away and
> rectify. Firstly however, as I inherited this code I'd like to give
> Angus a chance to comment before we go off on our own tangent and
> rework some of the good code which perhaps should remain unchanged.
>
> Angus, do you have enough time to go through Brian's review comments
> and perhaps reply to the ones that you feel would benefit from your
> expert knowledge. To be frank, some of the questions that were asked I
> wouldn't be able to answer without your guidance in any case.
>
> Thanks both.
>
> Kind regards,
> Lee
>

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





==============================================================================
TOPIC: dma: tegra: Use runtime_pm for clk enable/disable
http://groups.google.com/group/linux.kernel/t/6766cc6ffea941f6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 12:50 am
From: Chaitanya Bandi


Used runtime_pm APIs for clock enabling/disabling.
Made changes such that clock is not enabled during
idle. Also moved the usage of clk prepare/unprepare
such that they are not called in isr context.

Signed-off-by: Chaitanya Bandi <bandik@nvidia.com>
---
Verified with audio playback on Dalmore and check runtime status.

drivers/dma/tegra20-apb-dma.c | 35 ++++++++++++++++++++++-------------
1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 73654e3..355572d 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -1,7 +1,7 @@
/*
* DMA driver for Nvidia's Tegra20 APB DMA controller.
*
- * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2012-13, NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -580,6 +580,11 @@ static void handle_once_dma_done(struct tegra_dma_channel *tdc,
list_add_tail(&sgreq->node, &tdc->free_sg_req);

/* Do not start DMA if it is going to be terminate */
+ if (list_empty(&tdc->pending_sg_req) && (!to_terminate)) {
+ clk_disable(tdc->tdma->dma_clk);
+ pm_runtime_put(tdc->tdma->dev);
+ }
+
if (to_terminate || list_empty(&tdc->pending_sg_req))
return;

@@ -682,12 +687,21 @@ static void tegra_dma_issue_pending(struct dma_chan *dc)
{
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
unsigned long flags;
+ int ret;

spin_lock_irqsave(&tdc->lock, flags);
if (list_empty(&tdc->pending_sg_req)) {
dev_err(tdc2dev(tdc), "No DMA request\n");
goto end;
}
+
+ pm_runtime_get(tdc->tdma->dev);
+ ret = clk_enable(tdc->tdma->dma_clk);
+ if (ret < 0) {
+ dev_err(tdc2dev(tdc), "clk_enable failed: %d\n", ret);
+ return;
+ }
+
if (!tdc->busy) {
tdc_start_head_req(tdc);

@@ -744,6 +758,8 @@ static void tegra_dma_terminate_all(struct dma_chan *dc)
get_current_xferred_count(tdc, sgreq, status);
}
tegra_dma_resume(tdc);
+ clk_disable(tdc->tdma->dma_clk);
+ pm_runtime_put(tdc->tdma->dev);

skip_dma_stop:
tegra_dma_abort_all(tdc);
@@ -1153,22 +1169,16 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
static int tegra_dma_alloc_chan_resources(struct dma_chan *dc)
{
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
- struct tegra_dma *tdma = tdc->tdma;
- int ret;

+ clk_prepare(tdc->tdma->dma_clk);
dma_cookie_init(&tdc->dma_chan);
tdc->config_init = false;
- ret = clk_prepare_enable(tdma->dma_clk);
- if (ret < 0)
- dev_err(tdc2dev(tdc), "clk_prepare_enable failed: %d\n", ret);
- return ret;
+ return 0;
}

static void tegra_dma_free_chan_resources(struct dma_chan *dc)
{
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
- struct tegra_dma *tdma = tdc->tdma;
-
struct tegra_dma_desc *dma_desc;
struct tegra_dma_sg_req *sg_req;
struct list_head dma_desc_list;
@@ -1182,7 +1192,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc)

if (tdc->busy)
tegra_dma_terminate_all(dc);
-
+ clk_unprepare(tdc->tdma->dma_clk);
spin_lock_irqsave(&tdc->lock, flags);
list_splice_init(&tdc->pending_sg_req, &sg_req_list);
list_splice_init(&tdc->free_sg_req, &sg_req_list);
@@ -1204,7 +1214,6 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc)
list_del(&sg_req->node);
kfree(sg_req);
}
- clk_disable_unprepare(tdma->dma_clk);
}

/* Tegra20 specific DMA controller information */
@@ -1418,7 +1427,7 @@ static int tegra_dma_runtime_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct tegra_dma *tdma = platform_get_drvdata(pdev);

- clk_disable_unprepare(tdma->dma_clk);
+ clk_disable(tdma->dma_clk);
return 0;
}

@@ -1428,7 +1437,7 @@ static int tegra_dma_runtime_resume(struct device *dev)
struct tegra_dma *tdma = platform_get_drvdata(pdev);
int ret;

- ret = clk_prepare_enable(tdma->dma_clk);
+ ret = clk_enable(tdma->dma_clk);
if (ret < 0) {
dev_err(dev, "clk_enable failed: %d\n", ret);
return ret;
--
1.8.1.5

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





==============================================================================
TOPIC: mm/migrate: remove result argument on page allocation function for
migration
http://groups.google.com/group/linux.kernel/t/fab8622d4d72e03b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 12:50 am
From: Joonsoo Kim


On Mon, Dec 09, 2013 at 04:40:06PM +0000, Christoph Lameter wrote:
> On Mon, 9 Dec 2013, Joonsoo Kim wrote:
>
> > First, we don't use error number in fail case. Call-path related to
> > new_page_node() is shown in the following.
> >
> > do_move_page_to_node_array() -> migrate_pages() -> unmap_and_move()
> > -> new_page_node()
> >
> > If unmap_and_move() failed, migrate_pages() also returns err, and then
> > do_move_page_to_node_array() skips to set page's status to user buffer.
> > So we don't need to set error number to each pages on failure case.
>
> I dont get this. new_page_node() sets the error condition in the
> page_to_node array before this patch. There is no post processing in
> do_move_page_to_node_array(). The function simply returns and relies on
> new_page_node() to have set the page status. do_move_pages() then returns
> the page status back to userspace. How does the change preserve these
> diagnostics?

Hello, Christoph.

In do_move_pages(), if error occurs, 'goto out_pm' is executed and the
page status doesn't back to userspace. So we don't need to store err number.

Perhaps my description should be changed something like below.

*do_move_pages()* -> do_move_page_to_node_array() -> migrate_pages()
-> unmap_and_move() -> new_page_node()

If unmap_and_move() failed, migrate_pages() also returns err, and then
*do_move_pages()* skips to set page's status to user buffer.
So we don't need to set error number to each pages on failure case.

Is it sufficient explanation?

>
> > Next, we don't need to set node id of the new page in unmap_and_move(),
> > since it cannot be different with pm->node. In new_page_node(), we always
> > try to allocate the page in exact node by referencing pm->node. So it is
> > sufficient to set node id of the new page in new_page_node(), instead of
> > unmap_and_move().
>
> Thats a good thought.

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





==============================================================================
TOPIC: usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
http://groups.google.com/group/linux.kernel/t/185df9b46897a043?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 11 2013 1:00 am
From: Heikki Krogerus


Hi,

On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote:
> > >>>Can you guys explain why is something like this needed? Like with
> > >>>clocks and gpios, the device drivers shouldn't need to care any more
> > >>>if the platform has the phys or not. -ENODEV tells you your platform
> > >>
> > >>Shouldn't we report if a particular platform needs a PHY and not able to get
> > >>it. How will a user know if a particular controller is not working because it's
> > >>not able to get and initialize the PHYs? Don't you think in such cases it's
> > >>better to fail (and return from probe) because the controller will not work
> > >>anyway without the PHY?
> > >
> > >My point is that you do not need to separately tell this to the driver
> > >like you do with the quirks (if you did, then you would need to fix
> > >your framework and not hack the drivers).
> > >
> > >Like I said, ENODEV tells you that there is no phy on this platform
> > >for you, allowing you to safely continue. If your phy driver is not
> > >loaded, the framework already returns EPROBE_DEFER, right. Any other
> >
> > right. but that doesn't consider broken dt data. With quirks we'll
> > able to tell if a controller in a particular platform has PHY or not
> > without depending on the dt data.
>
> Broken dt data? What kind of scenario are you thinking here? Do you
> mean case where the dt does not describe the phy on a platform that
> depends on it? Shouldn't that problem be fixed in the dt and not
> hacked in the drivers? Or are you thinking about something else?
>
> Is there a case where something like that is actually happening?

I'm guessing I'm not getting an answer to this one.

Look, this patch will not work with ACPI enumerated devices. We will
have a platform providing a single ACPI id, but there is a whole bunch
of boards based on it and we have no way of telling which of them
need/have phys to deal with and which ones don't.


Thanks,

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




== 2 of 2 ==
Date: Wed, Dec 11 2013 1:10 am
From: Kishon Vijay Abraham I


On Wednesday 11 December 2013 02:23 PM, Heikki Krogerus wrote:
> Hi,
>
> On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote:
>>>>>> Can you guys explain why is something like this needed? Like with
>>>>>> clocks and gpios, the device drivers shouldn't need to care any more
>>>>>> if the platform has the phys or not. -ENODEV tells you your platform
>>>>>
>>>>> Shouldn't we report if a particular platform needs a PHY and not able to get
>>>>> it. How will a user know if a particular controller is not working because it's
>>>>> not able to get and initialize the PHYs? Don't you think in such cases it's
>>>>> better to fail (and return from probe) because the controller will not work
>>>>> anyway without the PHY?
>>>>
>>>> My point is that you do not need to separately tell this to the driver
>>>> like you do with the quirks (if you did, then you would need to fix
>>>> your framework and not hack the drivers).
>>>>
>>>> Like I said, ENODEV tells you that there is no phy on this platform
>>>> for you, allowing you to safely continue. If your phy driver is not
>>>> loaded, the framework already returns EPROBE_DEFER, right. Any other
>>>
>>> right. but that doesn't consider broken dt data. With quirks we'll
>>> able to tell if a controller in a particular platform has PHY or not
>>> without depending on the dt data.
>>
>> Broken dt data? What kind of scenario are you thinking here? Do you
>> mean case where the dt does not describe the phy on a platform that
>> depends on it? Shouldn't that problem be fixed in the dt and not
>> hacked in the drivers? Or are you thinking about something else?
>>
>> Is there a case where something like that is actually happening?
>
> I'm guessing I'm not getting an answer to this one.
>
> Look, this patch will not work with ACPI enumerated devices. We will
> have a platform providing a single ACPI id, but there is a whole bunch
> of boards based on it and we have no way of telling which of them
> need/have phys to deal with and which ones don't.

Alright.. I'll drop this patch then.

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





==============================================================================
TOPIC: phy: Add provision for tuning phy.
http://groups.google.com/group/linux.kernel/t/d26d42c3b09f58d4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:00 am
From: Heikki Krogerus


Hi again,

On Wed, Dec 11, 2013 at 02:02:43PM +0530, Vivek Gautam wrote:
> On Wed, Dec 11, 2013 at 1:39 PM, Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
> > On Wed, Dec 11, 2013 at 12:08:04PM +0530, Vivek Gautam wrote:
> >> On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus
> >> > I think "setup" instead of "tune" is much more clear and reusable.
> >>
> >> I think "setup" will look more like first time setting up the phy,
> >> which is rather served by "init" callback.
> >> This i thought would serve the purpose of over-riding certain PHY
> >> parameters, which would not have been
> >> possible at "init" time.
> >> Please correct my thinking if i am unable to understand your point here.
> >
> > OK, sorry I was not clear on this. I'm thinking the same, that this is
> > something that is called later, for example when the controller is
> > ready. Some ULPI phys need to be initialized, but since the controller
> > provides the interface, it's usually not possible during init time.
> > This hook could be used in that case as well.
> >
> > All I'm saying is that "tune" is a poor expression. You will need to
> > add a comment explaining what the hook does in any case, so you'll
> > have something like "this is something that is called when the
> > controller is ready" or something similar. That will make it clear
> > what it's meant for.
>
> Ok, i think i should have kept a comment atleast :-(
> I will add proper comments above, and as suggested in the mail by
> Kishon, may be name it calibrate ?
> What do you think ?

Sure, I'm fine with that.

Thanks,

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





==============================================================================
TOPIC: mm/zswap: change zswap to writethrough cache
http://groups.google.com/group/linux.kernel/t/83a057c0f19449e9?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:10 am
From: Bob Liu


Hi Dan & Seth,

On Wed, Nov 27, 2013 at 9:28 AM, Dan Streetman <ddstreet@ieee.org> wrote:
> On Mon, Nov 25, 2013 at 1:00 PM, Seth Jennings <sjennings@variantweb.net> wrote:
>> On Fri, Nov 22, 2013 at 11:29:16AM -0600, Seth Jennings wrote:
>>> On Wed, Nov 20, 2013 at 02:49:33PM -0500, Dan Streetman wrote:
>>> > Currently, zswap is writeback cache; stored pages are not sent
>>> > to swap disk, and when zswap wants to evict old pages it must
>>> > first write them back to swap cache/disk manually. This avoids
>>> > swap out disk I/O up front, but only moves that disk I/O to
>>> > the writeback case (for pages that are evicted), and adds the
>>> > overhead of having to uncompress the evicted pages, and adds the
>>> > need for an additional free page (to store the uncompressed page)
>>> > at a time of likely high memory pressure. Additionally, being
>>> > writeback adds complexity to zswap by having to perform the
>>> > writeback on page eviction.
>>> >
>>> > This changes zswap to writethrough cache by enabling
>>> > frontswap_writethrough() before registering, so that any
>>> > successful page store will also be written to swap disk. All the
>>> > writeback code is removed since it is no longer needed, and the
>>> > only operation during a page eviction is now to remove the entry
>>> > from the tree and free it.
>>>
>>> I like it. It gets rid of a lot of nasty writeback code in zswap.
>>>
>>> I'll have to test before I ack, hopefully by the end of the day.
>>>
>>> Yes, this will increase writes to the swap device over the delayed
>>> writeback approach. I think it is a good thing though. I think it
>>> makes the difference between zswap and zram, both in operation and in
>>> application, more apparent. Zram is the better choice for embedded where
>>> write wear is a concern, and zswap being better if you need more
>>> flexibility to dynamically manage the compressed pool.
>>
>> One thing I realized while doing my testing was that making zswap
>> writethrough also impacts synchronous reclaim. Zswap, as it is now,
>> makes the swapcache page clean during swap_writepage() which allows
>> shrink_page_list() to immediately reclaim it. Making zswap writethrough
>> eliminates this advantage and swapcache pages must be scanned again
>> before they can be reclaimed, as is the case with normal swapping.
>
> Yep, I thought about that as well, and it is true, but only while
> zswap is not full. With writeback, once zswap fills up, page stores
> will frequently have to reclaim pages by writing compressed pages to
> disk. With writethrough, the zbud reclaim should be quick, as it only
> has to evict the pages, not write them to disk. So I think basically
> writeback should speed up (compared to no-zswap case) swap_writepage()
> while zswap is not full, but (theoretically) slow it down (compared to
> no-zswap case) while zswap is full, while writethrough should slow
> down swap_writepage() slightly (the time it takes to compress/store
> the page) but consistently, almost the same amount before it's full vs
> when it's full. Theoretically :-) Definitely something to think
> about and test for.
>

Have you gotten any further benchmark result?

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





==============================================================================
TOPIC: sched/numa: fix set cpupid on page migration twice against normal page
http://groups.google.com/group/linux.kernel/t/2879b635b367c8c6?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Dec 11 2013 1:10 am
From: Mel Gorman


On Wed, Dec 11, 2013 at 08:49:57AM +0800, Wanpeng Li wrote:
> commit 7851a45cd3 (mm: numa: Copy cpupid on page migration) copy over
> the cpupid at page migration time, there is unnecessary to set it again
> in function alloc_misplaced_dst_page, this patch fix it.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>

migratepages aops is not necessarily required to go through migrate_page_copy
but in practice all of them do and it's hard to imagine one that didn't
so.

Acked-by: Mel Gorman <mgorman@suse.de>

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




== 2 of 5 ==
Date: Wed, Dec 11 2013 1:10 am
From: Mel Gorman


On Wed, Dec 11, 2013 at 08:49:58AM +0800, Wanpeng Li wrote:
> Use wrapper function task_faults_idx to calculate index in group_faults.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>

Acked-by: Mel Gorman <mgorman@suse.de>

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




== 3 of 5 ==
Date: Wed, Dec 11 2013 1:10 am
From: Mel Gorman


On Wed, Dec 11, 2013 at 08:49:59AM +0800, Wanpeng Li wrote:
> Changelog:
> v3 -> v4:
> * remove period_slot recalculation
>
> The original code is as intended and was meant to scale the difference
> between the NUMA_PERIOD_THRESHOLD and local/remote ratio when adjusting
> the scan period. The period_slot recalculation can be dropped.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>

Acked-by: Mel Gorman <mgorman@suse.de>

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




== 4 of 5 ==
Date: Wed, Dec 11 2013 1:20 am
From: Mel Gorman


On Wed, Dec 11, 2013 at 08:50:00AM +0800, Wanpeng Li wrote:
> Adjust numa_scan_period in task_numa_placement, depending on how much useful
> work the numa code can do. The local faults and remote faults should be used
> to check if there is record hinting faults instead of local faults and shared
> faults. This patch fix it.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>

This potentially has the side-effect of making it easier to reduce the
scan rate because it'll only take the most recent scan window into
account. The existing code takes recent shared accesses into account.
What sort of tests did you do on this patch and what was the result?

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




== 5 of 5 ==
Date: Wed, Dec 11 2013 1:30 am
From: Mel Gorman


On Wed, Dec 11, 2013 at 08:50:01AM +0800, Wanpeng Li wrote:
> Drop unnecessary total_faults variable in function task_weight to unify
> task_weight and group_weight.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>

Nak.

task_weight is called for tasks other than current. If p handles a fault
in parallel then it can drop to 0 between when it's checked and used to
divide resulting in an oops.

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





==============================================================================
TOPIC: mfd: menelaus: Start to use irqdomain
http://groups.google.com/group/linux.kernel/t/0018ab22f96f187d?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 11 2013 1:10 am
From: Lee Jones


On Tue, 10 Dec 2013, Tony Lindgren wrote:

> * Lee Jones <lee.jones@linaro.org> [131210 10:39]:
> > > > > Introduce an irq_chip and irq_domain for menelaus driver. Following
> > > > > patches will convert uses to traditional request_threaded_irq().
> > > > >
> > > > > While at that, some better error handling had to be added, so we could
> > > > > free irq descs we allocated.
> > > > >
> > > > > Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > > ---
> > > > > drivers/mfd/menelaus.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++---
> > > >
> > > > <snip>
> > > >
> > > > > + irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
> > > > > + &irq_domain_simple_ops, m);
> > > >
> > > > When will this driver become DT compliant?
> > >
> > > when OMAP2 becomes DT-compliant. It still boots with legacy board-file +
> > > platform_data.
> >
> > Really? Tony, are there any plans to DT the platform?
>
> Yeah and what Felipe is doing here is an important step towards that.
> We'll be booting omap2 in DT only mode with v3.14

Okay, sounds good. Thanks for the clarification.

> but we still need
> to rely on some pdata quirks at least for the MMC because Menelaus
> does not provide the needed regulator phandles for the .dts files for
> the driver to use.

I'll take your word for it. :)

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Wed, Dec 11 2013 1:20 am
From: Lee Jones


On Tue, 10 Dec 2013, Felipe Balbi wrote:

> On Tue, Dec 10, 2013 at 08:57:01AM +0000, Lee Jones wrote:
> > > Pass a menelaus_chip pointer as argument to most functions so we can
> > > minimize the usage of the global the_menelaus pointer.
> > >
> > > Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > ---
> > > drivers/mfd/menelaus.c | 265 ++++++++++++++++++++++++++-----------------------
> > > 1 file changed, 142 insertions(+), 123 deletions(-)
> >
> > How is this different from patch 6?
>
> have you read the patch ? patch 6 converts *only* enable/disable irq
> functions.

Well it actually converts menelaus_ack_irq() too, but that's not the
point I was making.

I can see that the 'code' is different, but the functionality of the
patch is the same i.e. converting functions to pass around the
menelaus_chip pointer for eradication of the_menelaus global pointer.

I'm not concerned about the 'lines changed' count. The change your
making is trivial, thus there is no requirement to split unnecessarily
over 5 patches. Please squash them into a single functionality patch.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: net: of_mdio: Scan PHYs which have device_type set to ethernet-phy
http://groups.google.com/group/linux.kernel/t/098803c3358dfc40?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:20 am
From: Grant Likely


On Wed, 11 Dec 2013 07:15:54 +0000, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le jeudi 14 novembre 2013, 15:05:56 Srinivas Kandagatla a écrit :
> > According to Documentation/devicetree/bindings/net/phy.txt device_type
> > property of PHY nodes is mandatory, which should be set to
> > "ethernet-phy". This patch adds check in scanning phys and only scans
> > node which have device-type set to "ethernet-phy".
>
> Please CC netdev@vger.kernel.org as there might be networking folks not
> actively following devicetree-discuss.
>
> >
> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > ---
> > drivers/of/of_mdio.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> > index d5a57a9..78c53c7 100644
> > --- a/drivers/of/of_mdio.c
> > +++ b/drivers/of/of_mdio.c
> > @@ -57,6 +57,9 @@ int of_mdiobus_register(struct mii_bus *mdio, struct
> > device_node *np)
> >
> > /* Loop over the child nodes and register a phy_device for each one */
> > for_each_available_child_of_node(np, child) {
> > + /* A PHY must have device_type set to "ethernet-phy" */
> > + if (of_node_cmp(child->type, "ethernet-phy"))
> > + continue;
>
> As already stated by Grant this will break quite a lot of platforms out there.
> Technically speaking, ePAPR v1.1 only specifies that "cpu" and "memory" nodes
> should have a "device_type" property for compatibility. Altough I do agree
> that it is nice to have a properly set "device_type", we can't always rely on
> that.

Actually it is the opposite. device_type is deprecated and has been for
a long time now. Device bindings should not not be using device_type
unless it is there for legacy compatibility.

g.

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





==============================================================================
TOPIC: dma: mv_xor: remove mv_desc_get_dest_addr()
http://groups.google.com/group/linux.kernel/t/1dba4c15122332c3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:20 am
From: Dan Williams


On Tue, Dec 10, 2013 at 3:14 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Dec 10, 2013 at 03:43:31PM +0530, Vinod Koul wrote:
>> On Mon, Dec 09, 2013 at 11:50:35PM +0000, Russell King - ARM Linux wrote:
>> > On Thu, Nov 28, 2013 at 11:27:06AM +0530, Vinod Koul wrote:
>> > > + Dan
>> > >
>> > > On Mon, Nov 25, 2013 at 07:39:25PM +0000, Jason Cooper wrote:
>> > > > The following commit:
>> > > >
>> > > > 54f8d501e842 dmaengine: remove DMA unmap from drivers
>> > > >
>> > > > removed the last caller to mv_desc_get_dest_addr(), creating the
>> > > > warning:
>> > > >
>> > > > drivers/dma/mv_xor.c:57:12: warning: 'mv_desc_get_dest_addr' defined
>> > > > but not used [-Wunused-function]
>> > > >
>> > > > Remove it.
>> > > >
>> > > > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>> > > Acked-by: Vinod Koul <vinod.koul@intel.com>
>> > >
>> > > This should go thru Dan's tree
>> >
>> > So what's happening with this patch? I don't see it in -rc yet.
>> Dan has applied this to his next. So this should show us in next rc1
>
> Wrong answer. This is a compile regression introduced in the last merge
> window, it should be going into an -rc kernel.

Vinod, if your fixes branch is ready I'll take it along with the rest
of the regression fixes to Linus.

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





==============================================================================
TOPIC: Documentation: pci: Minor cleanup
http://groups.google.com/group/linux.kernel/t/cda14d708591570c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:20 am
From: Jagannadha Sutradharudu Teki


- Used small letters for file names
- Renamed few pcie txt files
- Re-arranged file names in 00-INDEX
- Removed PCI-DMA-mapping.txt from 00-INDEX

Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Documentation/PCI/00-INDEX | 22 +++++++++++-----------
.../PCI/{pcieaer-howto.txt => pcie-aer-howto.txt} | 0
.../PCI/{pci-iov-howto.txt => pcie-iov-howto.txt} | 0
.../{PCIEBUS-HOWTO.txt => pcie-portbus-howto.txt} | 0
4 files changed, 11 insertions(+), 11 deletions(-)
rename Documentation/PCI/{pcieaer-howto.txt => pcie-aer-howto.txt} (100%)
rename Documentation/PCI/{pci-iov-howto.txt => pcie-iov-howto.txt} (100%)
rename Documentation/PCI/{PCIEBUS-HOWTO.txt => pcie-portbus-howto.txt} (100%)

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 812b17f..b8b7721 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -1,14 +1,14 @@
00-INDEX
- this file
-MSI-HOWTO.txt
- - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
-PCI-DMA-mapping.txt
- - info for PCI drivers using DMA portably across all platforms
-PCIEBUS-HOWTO.txt
- - a guide describing the PCI Express Port Bus driver
-pci-error-recovery.txt
- - info on PCI error recovery
pci.txt
- - info on the PCI subsystem for device driver authors
-pcieaer-howto.txt
- - the PCI Express Advanced Error Reporting Driver Guide HOWTO
+ - Info on the PCI subsystem for device driver authors
+pci-error-recovery.txt
+ - Info on PCI error recovery
+MSI-HOWTO.txt
+ - The Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ
+pcie-portbus-howto.txt
+ - A guide describing the PCI Express Port Bus driver
+pcie-aer-howto.txt
+ - The PCI Express Advanced Error Reporting Driver Guide HOWTO
+pcie-iov-howto.txt
+ - Info on PCI Express I/O Virtualization
diff --git a/Documentation/PCI/pcieaer-howto.txt b/Documentation/PCI/pcie-aer-howto.txt
similarity index 100%
rename from Documentation/PCI/pcieaer-howto.txt
rename to Documentation/PCI/pcie-aer-howto.txt
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pcie-iov-howto.txt
similarity index 100%
rename from Documentation/PCI/pci-iov-howto.txt
rename to Documentation/PCI/pcie-iov-howto.txt
diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/pcie-portbus-howto.txt
similarity index 100%
rename from Documentation/PCI/PCIEBUS-HOWTO.txt
rename to Documentation/PCI/pcie-portbus-howto.txt
--
1.8.3


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





==============================================================================
TOPIC: Documentation: pci: Add pcie-howto.txt
http://groups.google.com/group/linux.kernel/t/d50a5a1acc7d6131?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:20 am
From: Jagannadha Sutradharudu Teki


Added pcie-howto.txt for describing the information
on PCI Express basics and Root Complex driver.

Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
---
Documentation/PCI/00-INDEX | 2 +
Documentation/PCI/pcie-howto.txt | 184 +++++++++++++++++++++++++++++++++++++++
2 files changed, 186 insertions(+)
create mode 100644 Documentation/PCI/pcie-howto.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index b8b7721..d61e7b9 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -6,6 +6,8 @@ pci-error-recovery.txt
- Info on PCI error recovery
MSI-HOWTO.txt
- The Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ
+pcie-howto.txt
+ - A guide describing the PCI Express basics and Root Complex driver
pcie-portbus-howto.txt
- A guide describing the PCI Express Port Bus driver
pcie-aer-howto.txt
diff --git a/Documentation/PCI/pcie-howto.txt b/Documentation/PCI/pcie-howto.txt
new file mode 100644
index 0000000..963cb75
--- /dev/null
+++ b/Documentation/PCI/pcie-howto.txt
@@ -0,0 +1,184 @@
+ PCI Express HOWTO
+ Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+ 05/12/2013
+
+1. About this guide
+
+This guide describes the basics of the PCI Express and provides
+information on how Linux PCIe subsystem looks like and at last
+with brief description of PCI Host controller/Root complex driver
+along with some sample code.
+
+2. Basic terminology and conventions
+
+PCI Express is
+- A high performance, IO interconnect for peripherals.
+- Low hardware design overhead compared to PCI, as it uses less pins.
+- A serial point-to-point interconnect between two devices.
+- Implements packet based protocol for data transfer.
+- Supports features like Advanced power management, Advanced error
+ reporting facility, and hot-plug.
+ _________
+ | |
+ | CPU |
+ |_________|
+ |
+ ___________________|___________________________
+ | | ________
+ | ROOT COMPLEX | | |
+ | |--------| Memory |
+ | Switch Port Root port | |________|
+ |_______________________________________________|
+ | PCIe Bus0
+ ____________________________|______________________________________
+ | | |
+ ____ ______|______ | ____|____
+ | | / \ __|__ | |
+ | EP |-----| SWITCH | | | | BRIDGE |
+ |____| \_____________/ | EP | | PCIe - |
+ | | |_____| | PCI/PCIe|
+ __|__ __|__ |_________|
+ | | | | | PCIe Bus1
+ | EP | | EP | __________|________________
+ |_____| |_____| | |
+ __|__ __|__
+ | | | |
+ | EP | | EP |
+ |_____| |_____|
+
+Root Complex (RC)
+Connects the CPU and memory subsystem to the PCIe fabric (A topology comprised of PCIe
+nodes like Root Complex, Endpoint, Bridge or a Switch)
+
+Port
+Interface between a PCIe component and the Link.
+
+Link
+PCIe interconnect is referred as a Link, and connects two devices.
+
+Lane
+A PCIe link consists of either 1, 2, 4, 8, 12, 16 or 32 signals in each direction
+(each signal needs two wires - one for Tx and other for Rx). these signals are
+referred to as Lanes.
+
+Upstream Port
+Port that points in the direction of RC.
+
+Downstream Port
+Port the points away from the RC.
+
+Root Port
+Whose upstream port is RC and dowstream port should be a EP or Bridge.
+
+Switch Port
+Whose upstream port is RC and dowstream port is always be a switch.
+
+Endpoint (EP)
+Devices other than RC, Switches and Bridges which either generates or terminates a PCIe
+transaction. These are peripheral devices such as Ethernet, USB and graphics devices.
+
+Switch
+PCIe device single upstream port as RC and multiple downstream ports as EP's,
+Switches or Bridges.
+
+Bridge
+Is for extending PCIe Bus segment - whose downstream port points to one more PCIe bus.
+
+3. Linux PCIe Subsystem
+
+ ifconfig open()/close/read()/write() /proc, /sys
+ ^ ^ ^ ^
+ | | | |
+ | | | |
+ | | | V
+ | | | PCIe Port Bus services
+ | | | (AER, HP, PME, VC
+ | | | drivers/pci/pcie/
+ | | | drivers/pci/hotplug)
+ V V V ^
+ Socket Block Char |
+ layer Subsystem Subsystem |
+ ^ ^ ^ | pcie_port_service_register()
+ | | | |
+ | | | |
+ V V V V
+ Common net USB Input PCIe Port Core
+ device layer Core Core (drivers/pci/pcie/portdrv_core.c)
+ ^ ^ ^ ^
+ | | | | pcie_port_bus_register()
+ | | | |
+ _____V_____ ____V____ ____V_____ _________V___________
+ | | | | | | | |
+ All these are | GEM | | USB HC | | Mouse/KB/| | PCIe Port Bus driver|
+ PCI endpoint | Controller| | driver | | TS HC | | (drivers/pci/pcie/ |
+ drivers | driver | | | | driver | | portdrv_pci.c) |
+ |___________| |_________| |__________| |_____________________|
+ ^ ^ ^ ^
+ |__________ | | _________|
+ | | | | pci_register_driver()
+ ___________________ pci_bus_*() __V___V_____________V__________V______
+ | | pci_scan_root_bus() | |
+ | PCI BIOS |-------------------->| PCI Core |
+ | (arch/arm/kernel/ |<--------------------| (drivers/pci/pci* |
+ ----->| bios32.c)) |<--- pcibios_*() | drivers/pci/bus.c) |
+ | |___________________| | |______________________________________|
+ | ^ |
+ | | | pci_common_init_dev()
+ | | |
+ ____V___ ____V___ ___V____
+ | | | | | |
+ | Renesas| | Tergra | | Exynos |
+ | PCI HC | | PCIe HC| | PCIe HC| drivers/pci/host/
+ | driver | | driver | | driver | All these are
+ |________| |________| |________| PCI Root Complex drivers
+ | | |
+ | | |
+ V V V
+ platform_driver_register()
+
+Note:
+Linux PCI subsystem is like above one without have a PCIe port bus stack.
+For more details abou this block see http://jagannadhteki.blog.com/2013/12/04/linux-pcie-subsystem/
+
+PCI HC/RC driver
+- Low level initialization and configuration (board, soc)
+- Invokes PCI-BIOS - for bus enumerations so-that the endpoints on bus is ready.
+- Supplies struct pci_ops to read/write config space.
+- Setup the resources like bus numbers, memory/IO space, Interrupt numbers, MSI.
+- Register PCI-BIOS as pci_common_init_dev()
+
+PCI BIOS
+- Architecture specific PCI
+- Bus enumeration - Lane, Bus, Device, Memory, Interrupt.
+- Enumeration ends up with scanning all endpoints on bus got discovered.
+- Register to PCI core for common accessing of endpoint drivers.
+- pci_scan_root_bus() and pci_bus_*()
+
+PCI Core
+- Provides services to Lower level BIOS and Upper level endpoint layers.
+- Creates device entries for proc/sysfs information.
+- Linux kernel pci bus and driver management code.
+- Provides set of abstraction functions that endpoint drivers can used to
+ initiate pci communication with attached endpoints.
+- Calls BIOS codes with pcibios_*
+
+PCI Endpoint driver
+- Individual endpoint drivers from upper layer.
+- Accessing config space upon respective endpoint enumeration done.
+- Communicate over the endpoint for Tx/Rx transactions.
+- Register to PCI core as pci_driver_register()
+
+PCIe Port Bus driver
+- A logical PCI-PCI Bridge structure.
+- Root Port and the Switch Port.
+- See Documentation/PCI/pcie-busport-howto.txt
+
+4. PCI HC/RC driver
+
+4.1 Description
+
+4.2 Sample code
+
+5. References
+http://www.mindshare.com/files/ebooks/pci%20express%20system%20architecture.pdf
+http://www.pcisig.com/developers/main/training_materials/
--
1.8.3


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





==============================================================================
TOPIC: mfd: ssbi: Remove platform data structs and hide ssbi type enum
http://groups.google.com/group/linux.kernel/t/b32f44967d482775?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Dec 11 2013 1:30 am
From: Lee Jones


On Tue, 10 Dec 2013, Stephen Boyd wrote:

> The ssbi driver assumes that the device is DT based. Remove the
> platform data structs that will never be used and hide the enum
> in the only C file that uses it.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/mfd/ssbi.c | 6 ++++++
> include/linux/ssbi.h | 17 +----------------
> 2 files changed, 7 insertions(+), 16 deletions(-)

I don't see any uses of the aforementioned struct.

Patch applied, thanks.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Wed, Dec 11 2013 1:30 am
From: Lee Jones


On Tue, 10 Dec 2013, Stephen Boyd wrote:

> In preparation for passing a const pointer directly to
> ssbi_write() from the regmap APIs.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/mfd/ssbi.c | 8 ++++----
> include/linux/ssbi.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 4 ==
Date: Wed, Dec 11 2013 1:30 am
From: Lee Jones


On Tue, 10 Dec 2013, Stephen Boyd wrote:

> This is a read-only data structure.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/mfd/ssbi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

It certainly is.

Applied, thanks.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Wed, Dec 11 2013 1:40 am
From: Lee Jones


On Tue, 10 Dec 2013, Stephen Boyd wrote:

> The pm8xxx-irq.c code is practically mandatory given that the
> pm8921-core driver will WARN about it missing and the Kconfig
> marks it as default y when a PM8xxx chips is enabled. The only
> reason the file was split out was because we planned to support
> other pm8xxx chips with different pm8xxx-core.c files. Now that
> we have DT on ARM this isn't necessary because we should be able
> to support all the ssbi based PM8xxx chips in one driver and one
> file with no data bloat. Let's move this code into the only
> driver that uses it right now (pm8921) so that it's always compiled when
> needed. In the future we can rename pm8921-core.c to something
> more generic.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/mfd/Kconfig | 10 --
> drivers/mfd/pm8921-core.c | 349 +++++++++++++++++++++++++++++++++++++++++++
> drivers/mfd/pm8xxx-irq.c | 371 ----------------------------------------------

If you're going to take this approach (which I'm fine with unless
there are likely to be anymore incarnations of pm8xxx chips?), I think
you should also clean-up the header in this patch.

include/linux/mfd/pm8xxx/irq.h

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mm, page_alloc: allow __GFP_NOFAIL to allocate below watermarks after
reclaim
http://groups.google.com/group/linux.kernel/t/c2e46b04eaa7fc17?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:30 am
From: Mel Gorman


On Tue, Dec 10, 2013 at 03:03:39PM -0800, David Rientjes wrote:
> On Tue, 10 Dec 2013, Mel Gorman wrote:
>
> > > If direct reclaim has failed to free memory, __GFP_NOFAIL allocations
> > > can potentially loop forever in the page allocator. In this case, it's
> > > better to give them the ability to access below watermarks so that they
> > > may allocate similar to the same privilege given to GFP_ATOMIC
> > > allocations.
> > >
> > > We're careful to ensure this is only done after direct reclaim has had
> > > the chance to free memory, however.
> > >
> > > Signed-off-by: David Rientjes <rientjes@google.com>
> >
> > The main problem with doing something like this is that it just smacks
> > into the adjusted watermark if there are a number of __GFP_NOFAIL. Who
> > was the user of __GFP_NOFAIL that was fixed by this patch?
> >
>
> Nobody, it comes out of a memcg discussion where __GFP_NOFAIL were
> recently given the ability to bypass charges to the root memcg when the
> memcg has hit its limit since we disallow the oom killer to kill a process
> (for the same reason that the vast majority of __GFP_NOFAIL users, those
> that do GFP_NOFS | __GFP_NOFAIL, disallow the oom killer in the page
> allocator).
>
> Without some other thread freeing memory, these allocations simply loop
> forever. We probably don't want to reconsider the choice that prevents
> calling the oom killer in !__GFP_FS contexts since it will allow
> unnecessary oom killing when memory can actually be freed by another
> thread.
>
> Since there are comments in both gfp.h and page_alloc.c that say no new
> users will be added, it seems legitimate to ensure that the allocation
> will at least have a chance of succeeding, but not the point of depleting
> memory reserves entirely.
>

Which __GFP_NOFAIL on its own does not guarantee if they just smack into
that barrier and cannot do anything. It changes the timing, not fixes
the problem.

> > There are enough bad users of __GFP_NOFAIL that I really question how
> > good an idea it is to allow emergency reserves to be used when they are
> > potentially leaked to other !__GFP_NOFAIL users via the slab allocator
> > shortly afterwards.
> >
>
> You could make the same argument for GFP_ATOMIC which can also allow
> access to memory reserves.

The critical difference being that GFP_ATOMIC callers typically can handle
NULL being returned to them. GFP_ATOMIC storms may starve !GFP_ATOMIC
requests but it does not cause the same types of problems that
__GFP_NOFAIL using reserves would.

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





==============================================================================
TOPIC: debugobject: add support for kref
http://groups.google.com/group/linux.kernel/t/0aa9a7811e6f1e9f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 11 2013 1:30 am
From: Thomas Gleixner


On Tue, 10 Dec 2013, Greg KH wrote:
> On Sun, Nov 03, 2013 at 08:33:08PM +0100, Sebastian Andrzej Siewior wrote:
> > I run a couple times into the case where "put" was called on an already
> > cleanup object. The results was either nothing because "0" went back to
> > 0xff…ff and release was not called a second time or some thing like this
> > with SLAB once that memory region was used again:
> >
> > |edma-dma-engine edma-dma-engine.0: freeing channel for 57
> > |Slab corruption (Not tainted): kmalloc-256 start=edc4c8c0, len=256
> > |070: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkjkkkkkkkkkkk
> > |Single bit error detected. Probably bad RAM.
> > |Run a memory test tool.
> > |Prev obj: start=edc4c7c0, len=256
> > |000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > |010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > |Next obj: start=edc4c9c0, len=256
> > |000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > |010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> >
> > which got me a little confused about the bit flip at first.
> > The reason for this was resource counting that went wrong followed by a "put"
> > called from two places.
> > After the second time running into the same problem using the same driver,
> > I was looking for something to help me to find atleast one caller (and the
> > kind of object) a little quicker. Here is a debugobject extension to kref which
> > seems to do the job.
> > At kref_init() the debugobject is initialized and activated.
> > At kref_get() / kref_sub() time it is checked if the kref is active. If
> > it is, the request is completed otherwise the "usual" debugobject is
> > printed. Here an example of kref_put() on an already gone object:
> >
> > |edma-dma-engine edma-dma-engine.0: freeing channel for 57
> > |------------[ cut here ]------------
> > |WARNING: CPU: 0 PID: 2053 at lib/debugobjects.c:260 debug_print_object+0x94/0xc4()
> > |ODEBUG: active_state not available (active state 0) object type: kref hint: (null)
> > |Modules linked in: ti_am335x_adc(-)
> > |[<c0014d38>] (unwind_backtrace+0x0/0xf4) from [<c001249c>] (show_stack+0x14/0x1c)
> > |[<c001249c>] (show_stack+0x14/0x1c) from [<c0037264>] (warn_slowpath_common+0x64/0x84)
> > |[<c0037264>] (warn_slowpath_common+0x64/0x84) from [<c0037318>] (warn_slowpath_fmt+0x30/0x40)
> > |[<c0037318>] (warn_slowpath_fmt+0x30/0x40) from [<c022e8d0>] (debug_print_object+0x94/0xc4)
> > |[<c022e8d0>] (debug_print_object+0x94/0xc4) from [<c022e9e4>] (debug_object_active_state+0xe4/0x148)
> > |[<c022e9e4>] (debug_object_active_state+0xe4/0x148) from [<bf0a3474>] (iio_buffer_put+0x24/0x70 [industrialio])
> > |[<bf0a3474>] (iio_buffer_put+0x24/0x70 [industrialio]) from [<bf0a0340>] (iio_dev_release+0x44/0x64 [industrialio])
> > |[<bf0a0340>] (iio_dev_release+0x44/0x64 [industrialio]) from [<c0290308>] (device_release+0x2c/0x94)
> > |[<c0290308>] (device_release+0x2c/0x94) from [<c021f040>] (kobject_release+0x44/0x78)
> > |[<c021f040>] (kobject_release+0x44/0x78) from [<c029600c>] (release_nodes+0x1a0/0x248)
> > |[<c029600c>] (release_nodes+0x1a0/0x248) from [<c029355c>] (__device_release_driver+0x98/0xf0)
> > |[<c029355c>] (__device_release_driver+0x98/0xf0) from [<c0293668>] (driver_detach+0xb4/0xb8)
> > |[<c0293668>] (driver_detach+0xb4/0xb8) from [<c0292538>] (bus_remove_driver+0x98/0xec)
> > |[<c0292538>] (bus_remove_driver+0x98/0xec) from [<c008fe2c>] (SyS_delete_module+0x1e0/0x24c)
> > |[<c008fe2c>] (SyS_delete_module+0x1e0/0x24c) from [<c000e680>] (ret_fast_syscall+0x0/0x48)
> > |---[ end trace bc5e9551626b178a ]---
> >
> > This should help to notice that there is a second "put" and the
> > call chain should point to the object. The "hint" callback is empty because
> > in the "double free" case we don't have any information and the release
> > function is passed as an argument to kref_put(). I think the information
> > is quite good and it is not worth extending debugobject to somehow add
> > this information.
> > The "get/put unless" macros aren't traced completely because it is hard
> > to get it correct without a false positive and without touching each
> > user. The object might be added to a list which is browsed by someone.
> > That someone holds the same lock that is required for in the cleanup path
> > and so the cleanup is blocked. That means that the kref object is
> > gone from debugobject point of view but the release function has not yet
> > complete so it is valid to check the current counter.
> >
> > v1…v2:
> > - not an RFC anymore
> > - addressed tglx review:
> > - use debug_obj_descr with state active
> > - use debug_object_active_state() to check for active object instead the
> > other hack I had.
> > - added debug_object_free() in a way that does not interfere with the
> > NSA sniffer API so it does not get removed from the patch by accident.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> I need an ack from Thomas or some other debugobjects-knowledgable
> developer before I can take this...

Reviwed-by: Thomas Gleixner <tglx@linutronix.de>




==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en