[PATCH 2/2] spi: devicetree: add support for loopback mode
there are a few spi master drivers which make use of that flag but there is no way to pass it through devicetree. This patch just creates a way to pass SPI_LOOP via devicetree. Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ drivers/spi/spi.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e..1949586 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-loopback- (optional) Empty property indicating device requires + loopback mode. If a gpio chipselect is used for the SPI slave the gpio number will be passed via the cs_gpio diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 3f1b9ee..6bcdc03 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) spi->mode |= SPI_CS_HIGH; if (of_find_property(nc, "spi-3wire", NULL)) spi->mode |= SPI_3WIRE; + if (of_find_property(nc, "spi-loopback", NULL)) + spi->mode |= SPI_LOOP; /* Device speed */ prop = of_get_property(nc, "spi-max-frequency", ); -- 1.8.1.rc1.5.g7e0651a -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] spi: omap2: disable DMA requests before complete()
No actual errors have been found for completing before disabling DMA request lines, but it just looks more semantically correct that on our DMA callback we quiesce the whole thing before stating transfer is finished. Signed-off-by: Felipe Balbi --- drivers/spi/spi-omap2-mcspi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index b610f52..68446db 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -298,10 +298,10 @@ static void omap2_mcspi_rx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); struct omap2_mcspi_dma *mcspi_dma = >dma_channels[spi->chip_select]; - complete(_dma->dma_rx_completion); - /* We must disable the DMA RX request */ omap2_mcspi_set_dma_req(spi, 1, 0); + + complete(_dma->dma_rx_completion); } static void omap2_mcspi_tx_callback(void *data) @@ -310,10 +310,10 @@ static void omap2_mcspi_tx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); struct omap2_mcspi_dma *mcspi_dma = >dma_channels[spi->chip_select]; - complete(_dma->dma_tx_completion); - /* We must disable the DMA TX request */ omap2_mcspi_set_dma_req(spi, 0, 0); + + complete(_dma->dma_tx_completion); } static void omap2_mcspi_tx_dma(struct spi_device *spi, -- 1.8.1.rc1.5.g7e0651a -- 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 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Tue 11-12-12 14:43:37, Ying Han wrote:
> On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko wrote:
> > On Tue 11-12-12 16:50:25, Michal Hocko wrote:
> >> On Sun 09-12-12 08:59:54, Ying Han wrote:
> >> > On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> >> [...]
> >> > > + /*
> >> > > +* Even if we found a group we have to make sure it is
> >> > > alive.
> >> > > +* css && !memcg means that the groups should be
> >> > > skipped and
> >> > > +* we should continue the tree walk.
> >> > > +* last_visited css is safe to use because it is
> >> > > protected by
> >> > > +* css_get and the tree walk is rcu safe.
> >> > > +*/
> >> > > + if (css == >css || (css && css_tryget(css)))
> >> > > + memcg = mem_cgroup_from_css(css);
> >> > >
> >> > > if (reclaim) {
> >> > > - iter->position = id;
> >> > > + struct mem_cgroup *curr = memcg;
> >> > > +
> >> > > + if (last_visited)
> >> > > + css_put(_visited->css);
> >> > > +
> >> > > + if (css && !memcg)
> >> > > + curr = mem_cgroup_from_css(css);
> >> >
> >> > In this case, the css_tryget() failed which implies the css is on the
> >> > way to be removed. (refcnt ==0) If so, why it is safe to call
> >> > css_get() directly on it below? It seems not preventing the css to be
> >> > removed by doing so.
> >>
> >> Well, I do not remember exactly but I guess the code is meant to say
> >> that we need to store a half-dead memcg because the loop has to be
> >> retried. As we are under RCU hood it is just half dead.
> >> Now that you brought this up I think this is not safe as well because
> >> another thread could have seen the cached value while we tried to retry
> >> and his RCU is not protecting the group anymore.
> >
> > Hmm, thinking about it some more, it _is_ be safe in the end.
> >
> > We are safe because we are under RCU. And even if somebody else looked
> > at the half-dead memcg from iter->last_visited it cannot disappear
> > because the current one will retry without dropping RCU so the grace
> > period couldn't have been finished.
> >
> > CPU0CPU1
> > rcu_read_lock() rcu_read_lock()
> > while(!memcg) { while(!memcg)
> > [...]
> > spin_lock(>iter_lock)
> > [...]
> > if (css == >css ||
> > (css && css_tryget(css)))
> > memcg = mem_cgroup_from_css(css)
> > [...]
> > if (css && !memcg)
> > curr = mem_cgroup_from_css(css)
> > if (curr)
> > css_get(curr);
> > spin_unlock(>iter_lock)
> >
> > spin_lock(>iter_lock)
> > /* sees the half
> > dead memcg but its cgroup is still valid */
> > [...]
> >
> > spin_unlock(>iter_lock)
> > /* we do retry */
> > }
> > rcu_read_unlock()
> >
> > so the css_get will just helps to prevent from further code obfuscation.
> >
> > Makes sense? The code gets much simplified later in the series,
> > fortunately.
>
> My understanding on this is that we should never call css_get()
> without calling css_tryget() and it succeed.
Hmm, what would be the point of using css_get then?
> Whether or not it is *safe* to do so, that seems conflicts with the
> assumption of the cgroup_rmdir().
>
> I would rather make the change to do the retry after css_tryget()
> failed. The patch I have on my local tree:
OK, I am not against, the retry is just nicer and that is the reason
I changed that in the follow up patch. Just note that this is an
intermediate patch and the code is changed significantly in the later
patches so the question is whether it is worth changing that.
This surely couldn't have caused your testing issue, right?
So I can refactor the two patches and move the retry from the later to
this one if you or anybody else really insist ;)
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index f26..e2af02d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -991,6 +991,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> while (!memcg) {
> struct mem_cgroup_reclaim_iter *uninitialized_var(iter);
> struct cgroup_subsys_state *css = NULL;
> + struct cgroup *prev_cgroup, *next_cgroup;
>
> if (reclaim) {
> int nid = zone_to_nid(reclaim->zone);
> @@ -1018,10 +1019,9 @@ struct mem_cgroup *mem_cgroup_iter(struct
> mem_cgroup *root,
> if (!last_visited) {
> css = >css;
> }
Re: [PATCH 2/2] uio: do not expose inode to uio open/release hooks
Am Wed, 12 Dec 2012 09:50:54 +0100 schrieb "Hans J. Koch" : > On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote: > > Yes, but what does that have to do with this in-kernel, internal api? > > Ah, OK. You're right, the commit message is confusing. > > Bene, it's enough to say we drop the inode parameter because nobody > ever needed it. I am fine with that. > I cannot see why this also helps with the other problem. It would help, because we can defer calling the release hook until the last mmap user is gone. In this case the inode pointer may not be valid anymore. Regards Bene -- 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 RESEND 3] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana Tested-by: Claudio Fontana diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.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 v3 4/4] leds: leds-pwm: Add device tree bindings
On 12/11/2012 08:25 AM, Thierry Reding wrote:
>> +static const struct of_device_id of_pwm_leds_match[] = {
>> +{ .compatible = "pwm-leds", },
>> +{},
>> +};
>
> Doesn't this cause a compiler warning for !OF builds?
This is not causing any compiler warnings.
--
Péter
--
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 v4 2/7] leds: leds-pwm: Preparing the driver for device tree support
In order to be able to add device tree support for leds-pwm driver we need
to rearrange the data structures used by the drivers.
Signed-off-by: Peter Ujfalusi
---
drivers/leds/leds-pwm.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 351257c..c767837 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -30,6 +30,11 @@ struct led_pwm_data {
unsigned intperiod;
};
+struct led_pwm_priv {
+ int num_leds;
+ struct led_pwm_data leds[0];
+};
+
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -47,25 +52,29 @@ static void led_pwm_set(struct led_classdev *led_cdev,
}
}
+static inline size_t sizeof_pwm_leds_priv(int num_leds)
+{
+ return sizeof(struct led_pwm_priv) +
+ (sizeof(struct led_pwm_data) * num_leds);
+}
+
static int led_pwm_probe(struct platform_device *pdev)
{
struct led_pwm_platform_data *pdata = pdev->dev.platform_data;
- struct led_pwm *cur_led;
- struct led_pwm_data *leds_data, *led_dat;
+ struct led_pwm_priv *priv;
int i, ret = 0;
if (!pdata)
return -EBUSY;
- leds_data = devm_kzalloc(>dev,
- sizeof(struct led_pwm_data) * pdata->num_leds,
- GFP_KERNEL);
- if (!leds_data)
+ priv = devm_kzalloc(>dev, sizeof_pwm_leds_priv(pdata->num_leds),
+ GFP_KERNEL);
+ if (!priv)
return -ENOMEM;
for (i = 0; i < pdata->num_leds; i++) {
- cur_led = >leds[i];
- led_dat = _data[i];
+ struct led_pwm *cur_led = >leds[i];
+ struct led_pwm_data *led_dat = >leds[i];
led_dat->pwm = devm_pwm_get(>dev, cur_led->name);
if (IS_ERR(led_dat->pwm)) {
@@ -88,15 +97,16 @@ static int led_pwm_probe(struct platform_device *pdev)
if (ret < 0)
goto err;
}
+ priv->num_leds = pdata->num_leds;
- platform_set_drvdata(pdev, leds_data);
+ platform_set_drvdata(pdev, priv);
return 0;
err:
if (i > 0) {
for (i = i - 1; i >= 0; i--)
- led_classdev_unregister(_data[i].cdev);
+ led_classdev_unregister(>leds[i].cdev);
}
return ret;
@@ -104,14 +114,11 @@ err:
static int led_pwm_remove(struct platform_device *pdev)
{
+ struct led_pwm_priv *priv = platform_get_drvdata(pdev);
int i;
- struct led_pwm_platform_data *pdata = pdev->dev.platform_data;
- struct led_pwm_data *leds_data;
-
- leds_data = platform_get_drvdata(pdev);
- for (i = 0; i < pdata->num_leds; i++)
- led_classdev_unregister(_data[i].cdev);
+ for (i = 0; i < priv->num_leds; i++)
+ led_classdev_unregister(>leds[i].cdev);
return 0;
}
--
1.8.0
--
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 v4 1/7] leds: leds-pwm: Convert to use devm_get_pwm
Update the driver to use the new API for requesting pwm so we can take
advantage of the pwm_lookup table to find the correct pwm to be used for the
LED functionality.
Signed-off-by: Peter Ujfalusi
---
drivers/leds/leds-pwm.c | 19 ++-
include/linux/leds_pwm.h | 2 +-
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2157524..351257c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -67,12 +67,11 @@ static int led_pwm_probe(struct platform_device *pdev)
cur_led = >leds[i];
led_dat = _data[i];
- led_dat->pwm = pwm_request(cur_led->pwm_id,
- cur_led->name);
+ led_dat->pwm = devm_pwm_get(>dev, cur_led->name);
if (IS_ERR(led_dat->pwm)) {
ret = PTR_ERR(led_dat->pwm);
- dev_err(>dev, "unable to request PWM %d\n",
- cur_led->pwm_id);
+ dev_err(>dev, "unable to request PWM for %s\n",
+ cur_led->name);
goto err;
}
@@ -86,10 +85,8 @@ static int led_pwm_probe(struct platform_device *pdev)
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
ret = led_classdev_register(>dev, _dat->cdev);
- if (ret < 0) {
- pwm_free(led_dat->pwm);
+ if (ret < 0)
goto err;
- }
}
platform_set_drvdata(pdev, leds_data);
@@ -98,10 +95,8 @@ static int led_pwm_probe(struct platform_device *pdev)
err:
if (i > 0) {
- for (i = i - 1; i >= 0; i--) {
+ for (i = i - 1; i >= 0; i--)
led_classdev_unregister(_data[i].cdev);
- pwm_free(leds_data[i].pwm);
- }
}
return ret;
@@ -115,10 +110,8 @@ static int led_pwm_remove(struct platform_device *pdev)
leds_data = platform_get_drvdata(pdev);
- for (i = 0; i < pdata->num_leds; i++) {
+ for (i = 0; i < pdata->num_leds; i++)
led_classdev_unregister(_data[i].cdev);
- pwm_free(leds_data[i].pwm);
- }
return 0;
}
diff --git a/include/linux/leds_pwm.h b/include/linux/leds_pwm.h
index 33a0711..a65e964 100644
--- a/include/linux/leds_pwm.h
+++ b/include/linux/leds_pwm.h
@@ -7,7 +7,7 @@
struct led_pwm {
const char *name;
const char *default_trigger;
- unsignedpwm_id;
+ unsignedpwm_id __deprecated;
u8 active_low;
unsignedmax_brightness;
unsignedpwm_period_ns;
--
1.8.0
--
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 v4 0/7] leds: leds-pwm: Device tree support
Hello, Changes since v3: Addressed comments from Thierry Redding: - DT binding documentation for leds-pwm updated - of_pwm_request() renamed as of_pwm_get() - introduction of devm_of_pwm_get() - Commit message updates - Other comments has been also addressed - Acked-by from Grant is not added to the patches since they were modified since v3 Changes since v2: - rebased on top of linux-next - DT bindings now alligned with Grant's request - exporting of_pwm_request() from PWM core to allow clean DT bindings - DT binding documentation changed to reflect the changes Changes since v1: - As suggested by Bryan Wu: the legacy pwm_request() has been removed from patch 1 - Device tree bindings added for leds-pwm driver. When we boot with Device tree we handle one LED per device to be more aligned with PWM core's DT implementation. An example of the DT usage is provided in the new DT binding documentation for leds-pwm. Tested on OMAP4 Blaze (SDP), BeagleBoard with legacy and DT boot. On Zoom2 with legacy boot. Regards, Peter --- Peter Ujfalusi (7): leds: leds-pwm: Convert to use devm_get_pwm leds: leds-pwm: Preparing the driver for device tree support pwm: Correct parameter name in header for *pwm_get() functions pwm: core: Rename of_pwm_request() to of_pwm_get() and export it pwm: Add devm_of_pwm_get() as exported API for users leds: leds-pwm: Simplify cleanup code leds: leds-pwm: Add device tree bindings .../devicetree/bindings/leds/leds-pwm.txt | 48 +++ drivers/leds/leds-pwm.c| 152 +++-- drivers/pwm/core.c | 38 +- include/linux/leds_pwm.h | 2 +- include/linux/pwm.h| 20 ++- 5 files changed, 212 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt -- 1.8.0 -- 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 v4 4/7] pwm: core: Rename of_pwm_request() to of_pwm_get() and export it
Allow client driver to use of_pwm_get() to get the PWM they need. This
is needed for drivers which handle more than one PWM separately, like
leds-pwm driver, which have:
pwmleds {
compatible = "pwm-leds";
kpad {
label = "omap4::keypad";
pwms = <_pwm 0 7812500>;
max-brightness = <127>;
};
charging {
label = "omap4:green:chrg";
pwms = <_pwmled 0 7812500>;
max-brightness = <255>;
};
};
in the dts files.
Signed-off-by: Peter Ujfalusi
---
drivers/pwm/core.c | 8
include/linux/pwm.h | 7 +++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 903138b..3cb741d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -471,7 +471,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
}
/**
- * of_pwm_request() - request a PWM via the PWM framework
+ * of_pwm_get() - request a PWM via the PWM framework
* @np: device node to get the PWM from
* @con_id: consumer name
*
@@ -486,8 +486,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
* becomes mandatory for devices that look up the PWM device via the con_id
* parameter.
*/
-static struct pwm_device *of_pwm_request(struct device_node *np,
-const char *con_id)
+struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
{
struct pwm_device *pwm = NULL;
struct of_phandle_args args;
@@ -545,6 +544,7 @@ put:
return pwm;
}
+EXPORT_SYMBOL_GPL(of_pwm_get);
/**
* pwm_add_table() - register PWM device consumers
@@ -587,7 +587,7 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
- return of_pwm_request(dev->of_node, con_id);
+ return of_pwm_get(dev->of_node, con_id);
/*
* We look up the provider in the static table typically provided by
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index cc908a5..76a1959 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -175,6 +175,7 @@ struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip
*pc,
const struct of_phandle_args *args);
struct pwm_device *pwm_get(struct device *dev, const char *con_id);
+struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id);
void pwm_put(struct pwm_device *pwm);
struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
@@ -213,6 +214,12 @@ static inline struct pwm_device *pwm_get(struct device
*dev,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *of_pwm_get(struct device_node *np,
+ const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void pwm_put(struct pwm_device *pwm)
{
}
--
1.8.0
--
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 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Tue 11-12-12 14:36:10, Ying Han wrote:
> On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko wrote:
> > On Sun 09-12-12 11:39:50, Ying Han wrote:
> >> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> > [...]
> >> > if (reclaim) {
> >> > - iter->position = id;
> >> > + struct mem_cgroup *curr = memcg;
> >> > +
> >> > + if (last_visited)
> >> > + css_put(_visited->css);
> > ^^^
> > here
> >> > +
> >> > + if (css && !memcg)
> >> > + curr = mem_cgroup_from_css(css);
> >> > +
> >> > + /* make sure that the cached memcg is not
> >> > removed */
> >> > + if (curr)
> >> > + css_get(>css);
> >> > + iter->last_visited = curr;
> >>
> >> Here we take extra refcnt for last_visited, and assume it is under
> >> target reclaim which then calls mem_cgroup_iter_break() and we leaked
> >> a refcnt of the target memcg css.
> >
> > I think you are not right here. The extra reference is kept for
> > iter->last_visited and it will be dropped the next time somebody sees
> > the same zone-priority iter. See above.
> >
> > Or have I missed your question?
>
> Hmm, question remains.
>
> My understanding of the mem_cgroup_iter() is that each call path
> should close the loop itself, in the sense that no *leaked* css refcnt
> after that loop finished. It is the case for all the caller today
> where the loop terminates at memcg == NULL, where all the refcnt have
> been dropped by then.
Now I am not sure I understand you. mem_cgroup_iter_break will always
drop the reference of the last returned memcg. So far so good. But if
the last memcg got cached in per-zone-priority last_visited then we
_have_ to keep a reference to it regardless we broke out of the loop.
The last_visited thingy is shared between all parallel reclaimers so we
cannot just drop a reference to it.
> One exception is mem_cgroup_iter_break(), where the loop terminates
> with *leaked* refcnt and that is what the iter_break() needs to clean
> up. We can not rely on the next caller of the loop since it might
> never happen.
Yes, this is true and I already have a half baked patch for that. I
haven't posted it yet but it basically checks all node-zone-prio
last_visited and removes itself from them on the way out in pre_destroy
callback (I just need to cleanup "find a new last_visited" part and will
post it).
> It makes sense to drop the refcnt of last_visited, the same reason as
> drop refcnt of prev. I don't see why it makes different.
Because then it might vanish when somebody else wants to access it. If
we just did mem_cgroup_get which would be enough to keep only memcg part
in memory then what can we do at the time we visit it? css_tryget would
tell us "no your buddy is gone", you do not have any links to the tree
so you would need to start from the beginning. That is what I have
implemented in the first version. Then I've realized that this could
make a bigger pressure on the groups created earlier which doesn't seem
to be right. With css pinning we are sure that there is a link to a next
node in the tree.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/7] pwm: Correct parameter name in header for *pwm_get() functions
To synchronize the header file definition and the actual code. In the code the consumer parameter is named as con_id, change the header file and replace consumer -> con_id in the parameter list. Signed-off-by: Peter Ujfalusi --- include/linux/pwm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/pwm.h b/include/linux/pwm.h index 6d661f3..cc908a5 100644 --- a/include/linux/pwm.h +++ b/include/linux/pwm.h @@ -174,10 +174,10 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip, struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args); -struct pwm_device *pwm_get(struct device *dev, const char *consumer); +struct pwm_device *pwm_get(struct device *dev, const char *con_id); void pwm_put(struct pwm_device *pwm); -struct pwm_device *devm_pwm_get(struct device *dev, const char *consumer); +struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id); void devm_pwm_put(struct device *dev, struct pwm_device *pwm); #else static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data) -- 1.8.0 -- 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 v4 5/7] pwm: Add devm_of_pwm_get() as exported API for users
When booted with DT users can use devm version of of_pwm_get() to benefit
from automatic resource release.
Signed-off-by: Peter Ujfalusi
---
drivers/pwm/core.c | 30 ++
include/linux/pwm.h | 9 +
2 files changed, 39 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 3cb741d..4a13da4 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -708,6 +708,36 @@ struct pwm_device *devm_pwm_get(struct device *dev, const
char *con_id)
}
EXPORT_SYMBOL_GPL(devm_pwm_get);
+/**
+ * devm_of_pwm_get() - resource managed of_pwm_get()
+ * @dev: device for PWM consumer
+ * @np: device node to get the PWM from
+ * @con_id: consumer name
+ *
+ * This function performs like of_pwm_get() but the acquired PWM device will
+ * automatically be released on driver detach.
+ */
+struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
+ const char *con_id)
+{
+ struct pwm_device **ptr, *pwm;
+
+ ptr = devres_alloc(devm_pwm_release, sizeof(**ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ pwm = of_pwm_get(np, con_id);
+ if (!IS_ERR(pwm)) {
+ *ptr = pwm;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return pwm;
+}
+EXPORT_SYMBOL_GPL(devm_of_pwm_get);
+
static int devm_pwm_match(struct device *dev, void *res, void *data)
{
struct pwm_device **p = res;
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 76a1959..70655a2 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -179,6 +179,8 @@ struct pwm_device *of_pwm_get(struct device_node *np, const
char *con_id);
void pwm_put(struct pwm_device *pwm);
struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
+struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
+ const char *con_id);
void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
#else
static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
@@ -230,6 +232,13 @@ static inline struct pwm_device *devm_pwm_get(struct
device *dev,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
+struct device_node *np,
+const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
{
}
--
1.8.0
--
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 v4 6/7] leds: leds-pwm: Simplify cleanup code
The code looks more nicer if we use:
while (i--)
instead:
if (i > 0)
for (i = i - 1; i >= 0; i--)
Signed-off-by: Peter Ujfalusi
---
drivers/leds/leds-pwm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index c767837..46f4e44 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -104,10 +104,8 @@ static int led_pwm_probe(struct platform_device *pdev)
return 0;
err:
- if (i > 0) {
- for (i = i - 1; i >= 0; i--)
- led_classdev_unregister(>leds[i].cdev);
- }
+ while (i--)
+ led_classdev_unregister(>leds[i].cdev);
return ret;
}
--
1.8.0
--
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] AES instead of SHA1 for /dev/urandom
On Wed, 12 Dec 2012 09:58:16 +0100 Ondřej Bílka wrote: > On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote: > > On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka wrote: > > > > > I consider to speed-up /dev/urandom on recent intel processors by > > > using hardware aes. Same for accelerated aes crypto. > > > > > > Would you accept a patch if I wrote it? > > > > Have you read https://lwn.net/Articles/525459 ? > > > Yes > > In particular the paragraph containing: > > > >A member of the audience asked why the kernel couldn't just do away with > >the existing system and use the HWRNG directly. > > > > Does that answer your question in any way? > > > No as AES is a HWRNG about as much as horse is type of automobile. Yes, of course. Thanks. NeilBrown signature.asc Description: PGP signature
Re: [PATCH v3 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On 12/12/2012 08:49 AM, Jiang Liu wrote: This patch introduces a new array zone_movable_limit[] to store the ZONE_MOVABLE limit from movablecore_map boot option for all nodes. The function sanitize_zone_movable_limit() will find out to which node the ranges in movable_map.map[] belongs, and calculates the low boundary of ZONE_MOVABLE for each node. What's the difference between zone_movable_limit[nid] and zone_movable_pfn[nid]? zone_movable_limit[] is a temporary storage for zone_moveable_pfn[]. It's used to handle a special case if user specifies both movablecore_map and movablecore/kernelcore on the kernel command line. Hi Simon, Liu, Sorry for the late and thanks for your discussion. :) As Liu said, zone_movable_limit[] is a temporary array for calculation. If users specified movablecore_map option, zone_movable_limit[] holds the lowest pfn of ZONE_MOVABLE limited by movablecore_map option. It is constant, won't change. Please refer to find_zone_movable_pfns_for_nodes() in patch4, you will see that zone_moveable_pfn[] will be changed each time kernel area increases. So when kernel area increases on node i, zone_moveable_pfn[i] will increase. And if zone_moveable_pfn[i] > zone_movable_limit[i], we should stop allocate memory for kernel on node i. Here, I give movablecore_map higher priority than kernelcore/movablecore. And also, I tried to use zone_moveable_pfn[] to store limits. But when calculating the kernel area, I still have to store the limits in temporary variables. I think the code was ugly. So I added an new array. 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/
[PATCH v4 7/7] leds: leds-pwm: Add device tree bindings
Support for device tree booted kernel.
For usage see:
Documentation/devicetree/bindings/leds/leds-pwm.txt
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/leds/leds-pwm.txt | 48 +
drivers/leds/leds-pwm.c| 112 +
2 files changed, 140 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt
b/Documentation/devicetree/bindings/leds/leds-pwm.txt
new file mode 100644
index 000..7297107
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -0,0 +1,48 @@
+LED connected to PWM
+
+Required properties:
+- compatible : should be "pwm-leds".
+
+Each LED is represented as a sub-node of the pwm-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
+ specify the period time to be used: < id period_ns>;
+- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM
device
+ For the pwms and pwm-names property please refer to:
+ Documentation/devicetree/bindings/pwm/pwm.txt
+- max-brightness : Maximum brightness possible for the LED
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+twl_pwm: pwm {
+ /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+ compatible = "ti,twl6030-pwm";
+ #pwm-cells = <2>;
+};
+
+twl_pwmled: pwmled {
+ /* provides one PWM (id 0 for Charing indicator LED) */
+ compatible = "ti,twl6030-pwmled";
+ #pwm-cells = <2>;
+};
+
+pwmleds {
+ compatible = "pwm-leds";
+ kpad {
+ label = "omap4::keypad";
+ pwms = <_pwm 0 7812500>;
+ max-brightness = <127>;
+ };
+
+ charging {
+ label = "omap4:green:chrg";
+ pwms = <_pwmled 0 7812500>;
+ max-brightness = <255>;
+ };
+};
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 46f4e44..a1ea5f6 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -58,46 +59,110 @@ static inline size_t sizeof_pwm_leds_priv(int num_leds)
(sizeof(struct led_pwm_data) * num_leds);
}
-static int led_pwm_probe(struct platform_device *pdev)
+static struct led_pwm_priv *led_pwm_create_of(struct platform_device *pdev)
{
- struct led_pwm_platform_data *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *child;
struct led_pwm_priv *priv;
- int i, ret = 0;
+ int count, ret;
- if (!pdata)
- return -EBUSY;
+ /* count LEDs in this device, so we know how much to allocate */
+ count = of_get_child_count(node);
+ if (!count)
+ return NULL;
- priv = devm_kzalloc(>dev, sizeof_pwm_leds_priv(pdata->num_leds),
+ priv = devm_kzalloc(>dev, sizeof_pwm_leds_priv(count),
GFP_KERNEL);
if (!priv)
- return -ENOMEM;
+ return NULL;
- for (i = 0; i < pdata->num_leds; i++) {
- struct led_pwm *cur_led = >leds[i];
- struct led_pwm_data *led_dat = >leds[i];
+ for_each_child_of_node(node, child) {
+ struct led_pwm_data *led_dat = >leds[priv->num_leds];
- led_dat->pwm = devm_pwm_get(>dev, cur_led->name);
+ led_dat->cdev.name = of_get_property(child, "label",
+NULL) ? : child->name;
+
+ led_dat->pwm = devm_of_pwm_get(>dev, child, NULL);
if (IS_ERR(led_dat->pwm)) {
- ret = PTR_ERR(led_dat->pwm);
dev_err(>dev, "unable to request PWM for %s\n",
- cur_led->name);
+ led_dat->cdev.name);
goto err;
}
+ /* Get the period from PWM core when n*/
+ led_dat->period = pwm_get_period(led_dat->pwm);
+
+ led_dat->cdev.default_trigger = of_get_property(child,
+ "linux,default-trigger", NULL);
+ of_property_read_u32(child, "max-brightness",
+_dat->cdev.max_brightness);
- led_dat->cdev.name = cur_led->name;
- led_dat->cdev.default_trigger = cur_led->default_trigger;
- led_dat->active_low = cur_led->active_low;
- led_dat->period = cur_led->pwm_period_ns;
led_dat->cdev.brightness_set = led_pwm_set;
Re: [RFC] dynamic_debug: introduce debug_hex_dump()
On Tuesday, December 11, 2012 02:55:55 PM Luis R. Rodriguez wrote:
> Vladimir, to be clear, you can continue with waiting for the patches
> to get into 3.9 but that will take a while but given that you want
> your driver in 3.8 you can fold those routines into your driver as
> you had before but with a rename by adding a prefix and sumbit that
> driver and specify it is for 3.8.
>
I have internally patch that will compensate not merged yet functionality,
without any rename, see below. I can massage commit message and include it
with my driver as separate patch to be easier to undo later.
Comments?
>From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev
Date: Wed, 21 Nov 2012 13:57:21 +0200
Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel
Unless patch for dynamic hexdump merged into mainstream kernel,
need to provide replacement for the dynamic hexdump functionality
Do not hurt compilation with kernel that have patch above merged.
REMOVE when dynamic hexdump merged into mainstream kernel!!
Change-Id: I6abb8f91ed529ffc84bd9cc21444a59ee15fe456
---
dbg_hexdump.h | 32
wil6210.h |2 ++
2 files changed, 34 insertions(+)
create mode 100644 dbg_hexdump.h
diff --git a/dbg_hexdump.h b/dbg_hexdump.h
new file mode 100644
index 000..7144eed
--- /dev/null
+++ b/dbg_hexdump.h
@@ -0,0 +1,32 @@
+#ifndef DBG_HEXDUMP_H_
+#define DBG_HEXDUMP_H_
+
+#if !defined(print_hex_dump_debug)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, \
+ __builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT)) \
+ print_hex_dump(KERN_DEBUG, prefix_str, \
+ prefix_type, rowsize, groupsize, \
+ buf, len, ascii);\
+} while (0)
+
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+ dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)
+
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+ dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else /* defined(CONFIG_DYNAMIC_DEBUG) */
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+ print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,\
+ groupsize, buf, len, ascii)
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
+#endif /* !defined(print_hex_dump_debug) */
+
+#endif /* DBG_HEXDUMP_H_ */
diff --git a/wil6210.h b/wil6210.h
index b37c3d2..4797da0 100644
--- a/wil6210.h
+++ b/wil6210.h
@@ -21,6 +21,8 @@
#include
#include
+#include "dbg_hexdump.h"
+
#define WIL_NAME "wil6210"
/**
--
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 3/4 v2] gpio/mvebu: convert to use irq_domain_add_simple()
Dear Linus Walleij,
On Wed, 12 Dec 2012 08:56:03 +0100, Linus Walleij wrote:
> > Unfortunately, this creates the following warning at boot time for each
> > GPIO bank:
>
> Grant has a patch in his irqdomain tree that will turn this warning into
> a simple pr_info() thing instead. It's not that bad... The immediate
> problem will soon go away.
Ok.
> > Of course, the fix should be to remove the irq_alloc_descs() from the
> > driver prior to calling irq_domain_add_simple(). But the thing is that
> > our gpio-mvebu driver uses the
> > irq_alloc_generic_chip()/irq_setup_generic_chip() infrastructure, which
> > it seems requires a legacy IRQ domain (it needs the base IRQ number).
>
> Actually it looks like a core infrastructure issue. Sorry for not
> spotting this in the first place:
>
> First you allocate some descriptors, just any descriptors, with
> mvchip->irqbase = irq_alloc_descs(-1, 0, ngpios, -1);
>
> Then you allocate a generic chip using the obtained
> descriptor base:
> gc = irq_alloc_generic_chip("mvebu_gpio_irq", 2, mvchip->irqbase,
> mvchip->membase, handle_level_irq);
>
> Then you set up the generic chip with a nailed down IRQ base number
> from step 1:
> irq_setup_generic_chip(gc, IRQ_MSK(ngpios), 0,
> IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
>
> This, if I understand it correctly, is done because you have two different
> chip types on the generic chip: one for high/low level IRQ and another
> for rising/falling. (Which is a very nice way to use the generic chip!)
>
> Finally set up the IRQ domain:
> mvchip->domain = irq_domain_add_simple(np, mvchip->chip.ngpio,
> mvchip->irqbase,
> _domain_simple_ops,
> mvchip);
>
> So the problem is that you cannot allocate a generic chip
> without having a base IRQ at that point, if I understand
> correctly. If this was not necessary you would not need to
> allocate descriptors in advance.
Yes that's my understand as well.
> Or rather: the *real* problem, which will face anyone trying
> to implement a combined edge+level IRQ chip in a driver,
> is that the generic irqchip does not play well with irqdomain.
>
> Using legacy in this case is clearly wrong, the generic IRQ chip
> is not one least bit legacy, it's top-of-the-line IRQ handling,
> using generic code as we want.
>
> However it seems generic chips cannot handle sparse IRQs
> at all, it requires the descriptors to be allocated before
> we create and instance of it.
>
> So I see two solutions:
>
> - Fix the generic chip to handle sparse IRQs by patching
> a lot in kernel/irq/generic-chip.c and allowing to pass
> something like < 0 for irq base.
>
> - Add something like irq_domain_add_generic() for
> generic chips and handle the oddities there.
>
> The latter would be a pretty straight-forward wrapper to legacy
> domain as of now.
>
> Any preference? Or should we just consider generic irqchips
> a legacy case?
There has been some work in the past to make generic-chip play well
with irqdomain (by Rob Herring), but apparently, none of that work has
been merged. See:
Subject: [PATCH v6] irq: add irq_domain support to generic-chip
Date: Wed, 8 Feb 2012 16:55:22 -0600
Also at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/083897.html
Rob, do you intend to push something like this further? What were the
blocking points?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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/
[PATCH, resend] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Resubmit since it seemed to have gotten lost last cycle.
include/linux/dma-buf.h | 99 -
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
--
1.8.0
--
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 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On Wed, 2012-12-12 at 17:09 +0800, Tang Chen wrote: > On 12/12/2012 08:49 AM, Jiang Liu wrote: > > This patch introduces a new array zone_movable_limit[] to store the > > ZONE_MOVABLE limit from movablecore_map boot option for all nodes. > > The function sanitize_zone_movable_limit() will find out to which > > node the ranges in movable_map.map[] belongs, and calculates the > > low boundary of ZONE_MOVABLE for each node. > >> > >> What's the difference between zone_movable_limit[nid] and > >> zone_movable_pfn[nid]? > > zone_movable_limit[] is a temporary storage for zone_moveable_pfn[]. > > It's used to handle a special case if user specifies both movablecore_map > > and movablecore/kernelcore on the kernel command line. > > > Hi Simon, Liu, > > Sorry for the late and thanks for your discussion. :) > > As Liu said, zone_movable_limit[] is a temporary array for calculation. > > If users specified movablecore_map option, zone_movable_limit[] holds > the lowest pfn of ZONE_MOVABLE limited by movablecore_map option. It is > constant, won't change. > > Please refer to find_zone_movable_pfns_for_nodes() in patch4, you will > see that zone_moveable_pfn[] will be changed each time kernel area > increases. > > So when kernel area increases on node i, zone_moveable_pfn[i] will > increase. And if zone_moveable_pfn[i] > zone_movable_limit[i], we should > stop allocate memory for kernel on node i. Here, I give movablecore_map > higher priority than kernelcore/movablecore. > > And also, I tried to use zone_moveable_pfn[] to store limits. But when > calculating the kernel area, I still have to store the limits in > temporary variables. I think the code was ugly. So I added an new array. > > Thanks. :) Thanks for your clarify. Enable PAE on x86 32bit kernel, 8G memory, movablecore=6.5G > > [0.00] 8304MB HIGHMEM available. > [0.00] 885MB LOWMEM available. > [0.00] mapped low ram: 0 - 375fe000 > [0.00] low ram: 0 - 375fe000 > [0.00] Zone ranges: > [0.00] DMA [mem 0x0001-0x00ff] > [0.00] Normal [mem 0x0100-0x375fdfff] > [0.00] HighMem [mem 0x375fe000-0x3e5f] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x0001-0x0009cfff] > [0.00] node 0: [mem 0x0010-0x1fff] > [0.00] node 0: [mem 0x2020-0x3fff] > [0.00] node 0: [mem 0x4020-0xb69cbfff] > [0.00] node 0: [mem 0xb6a46000-0xb6a47fff] > [0.00] node 0: [mem 0xb6b1c000-0xb6cf] > [0.00] node 0: [mem 0x-0x3e5f] > [0.00] On node 0 totalpages: 2051391 > [0.00] free_area_init_node: node 0, pgdat c0c26a80, > node_mem_map > f19de200 > [0.00] DMA zone: 32 pages used for memmap > [0.00] DMA zone: 0 pages reserved > [0.00] DMA zone: 3949 pages, LIFO batch:0 > [0.00] Normal zone: 1740 pages used for memmap > [0.00] Normal zone: 220466 pages, LIFO batch:31 > [0.00] HighMem zone: 16609 pages used for memmap > [0.00] HighMem zone: 1808595 pages, LIFO batch:31 Why zone movable disappear? -- 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 4/5][RESEND] page_alloc: Make movablecore_map has higher priority
Hi Simon,
Thanks for reviewing. This logic is aimed at make movablecore_map
coexist with kernelcore/movablecore.
Please see below. :)
On 12/12/2012 09:33 AM, Simon Jeons wrote:
@@ -4839,9 +4839,17 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
- /* If kernelcore was not specified, there is no ZONE_MOVABLE */
- if (!required_kernelcore)
+ /*
+* If neither kernelcore/movablecore nor movablecore_map is specified,
+* there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+* start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+*/
+ if (!required_kernelcore) {
+ if (movablecore_map.nr_map)
+ memcpy(zone_movable_pfn, zone_movable_limit,
+ sizeof(zone_movable_pfn));
If users didn't specified kernelcore option, then zone_movable_pfn[]
and zone_movable_limit[] are all the same. We skip the logic.
goto out;
+ }
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
@@ -4871,10 +4879,24 @@ restart:
for_each_mem_pfn_range(i, nid,_pfn,_pfn, NULL) {
unsigned long size_pages;
+ /*
+* Find more memory for kernelcore in
+* [zone_movable_pfn[nid], zone_movable_limit[nid]).
+*/
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn>= end_pfn)
continue;
Hi Chen,
+ if (zone_movable_limit[nid]) {
If users didn't give any limitation of ZONE_MOVABLE on node i, we could
skip the logic too.
+ end_pfn = min(end_pfn, zone_movable_limit[nid]);
In order to reuse the original kernelcore/movablecore logic, we keep
end_pfn <= zone_movable_limit[nid]. We device [start_pfn, end_pfn) into
two parts:
[start_pfn, zone_movable_limit[nid])
and
[zone_movable_limit[nid], end_pfn).
We just remove the second part, and go on to the original logic.
+ /* No range left for kernelcore in this node */
+ if (start_pfn>= end_pfn) {
Since we re-evaluated end_pfn, if we have crossed the limitation, we
should stop.
+ zone_movable_pfn[nid] =
+ zone_movable_limit[nid];
Here, we found the real limitation. That means, the lowest pfn of
ZONE_MOVABLE is either zone_movable_limit[nid] or the value the original
logic calculates out, which is below zone_movable_limit[nid].
+ break;
Then we break and go on to the next node.
+ }
+ }
+
Could you explain this part of codes? hard to understand.
/* Account for what is only usable for kernelcore */
if (start_pfn< usable_startpfn) {
unsigned long kernel_pages;
@@ -4934,12 +4956,12 @@ restart:
if (usable_nodes&& required_kernelcore> usable_nodes)
goto restart;
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid< MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
-out:
/* restore the node_state */
node_states[N_HIGH_MEMORY] = saved_node_state;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] First round of SCSI updates for the 3.7+ merge window
This patch set includes two large new drivers: mpt3sas (for the next gen fusion SAS hardware) and csiostor a FCoE offload driver for the Chelsio converged network cards (this includes some net changes which I've OK'd with DaveM). The rest of the patch is driver updates (qla2xxx, lpfc, hptiop, be2iscsi) plus a few assorted updates and bug fixes. We also have a Power Management rework in the Upper Layer Drivers preparatory to doing ACPI zero power optical devices, but the actual enabler is still being worked on. Because of the need to keep the tree stable for next testing, anything submitted after last Saturday (1 Dec) will be in the next round. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc The short changelog is Aaron Lu (5): sd: update sd to use the new pm callbacks scsi_pm: use callbacks from dev_pm_ops for scsi devices Revert "[SCSI] runtime resume parent for child's system-resume" Revert "[SCSI] scsi_pm: set device runtime state before parent suspended" sd: put to stopped power state when runtime suspend Andrew Vasquez (2): qla2xxx: Use correct Request-Q-Out register during bidirectional request processing qla2xxx: Clear unsupported 'states' during Get-FW-State queries. Armen Baloyan (2): qla2xxx: No fcport FC-4 type assignment in GA_NXT response. qla2xxx: Properly set result field of bsg_job reply structure for success and failure. Boaz Harrosh (1): osd_uld: Add osdname & systemid sysfs at scsi_osd class Chad Dupuis (3): qla2xxx: Update ql2xextended_error_logging parameter description with new option. qla2xxx: Move noisy Start scsi failed messages to verbose logging level. qla2xxx: Remove spurious taking of ha->vport_slock spinlock. Dan Carpenter (1): csiostor: remove unneeded memset() David Jeffery (1): qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically. Eddie Wai (1): bnx2i: removed the individual PCI DEVICE ID checking Eric Northup (1): virtio_scsi: fix memory leak on full queue condition. Giridhar Malavali (1): qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver. HighPoint Linux Team (1): hptiop: Support HighPoint RR4520/RR4522 HBA James Smart (7): lpfc 8.3.36: Update lpfc version for 8.3.36 driver release lpfc 8.3.36: Correct mask error lpfc 8.3.36: Correct buffer length overrun lpfc 8.3.36: Fixed setting sequential delivery bit lpfc 8.3.36: Update DIF support for passthru/strip/insert lpfc 8.3.36: Fix bug with Target Resets and FCP2 devices lpfc 8.3.36: Fixed boot from san failure Jason J. Herne (1): sd: Use SCSI read/write(16) with > 32-bit LBA drives Joe Carnuccio (4): qla2xxx: Parameterize the link speed of hba rather than fcport. qla2xxx: Add 16Gb/s case to get port speed capability. qla2xxx: Move marking fcport online ahead of setting iiDMA speed. qla2xxx: Add acquiring of risc semaphore before doing ISP reset. Joel D. Diaz (1): sd: Reshuffle init_sd to avoid crash John Soni Jose (18): be2iscsi: Bump the driver version be2iscsi: Fix Unrecoverable Error Detection be2iscsi: Fix for MBX timeout issue be2iscsi: Update the copyright information be2iscsi: Fix issue of displaying adapter family. be2iscsi: Fix Task Completion Event handling be2iscsi: Fix session update context with V2 version. be2iscsi: Fix support for V2 version of WRB. be2iscsi: Fix support for handling CQ_CREATE V2 version. be2iscsi: Fix max EQ supported by the driver. be2iscsi: Fix driver support for Skyhawk-R adapter. be2iscsi: Fix return value and typo. be2iscsi: Fix kernel panic in blk_iopoll disable mode. be2iscsi: Issue an function level reset when driver is loaded be2iscsi: Display driver name and version in device attribute be2iscsi: Fix max supported EQ count to 8. be2iscsi: Fix memory leak in control path of driver be2iscsi: Display Completion Event string instead of Opcode Mahesh Rajashekhara (1): aacraid: SCSI dma mapping failure case handling Masanari Iida (1): qla2xxx: Fix typo in qla2xxx driver. Minh Tran (1): be2iscsi: Fix the issue with soft reset. Naresh Kumar Inna (3): csiostor: Fix sparse warnings. csiostor: Chelsio FCoE offload driver cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header updates). Sasha Levin (1): prevent stack buffer overflow in host_reset Saurav Kashyap (9): qla2xxx: Display that driver is operating in legacy interrupt mode. qla2xxx: Dont clear drv active on iospace config failure. qla2xxx: Ignore driver ack bit if corresponding presence bit is not set. qla2xxx: Fix typo in qla83xx_fw_dump function. qla2xxx: Add Gen3 PCIe speed 8GT/s to the log message. qla2xxx:
[PATCH 0/7] various ste_dma40 fixes
Hi all, this patch set contains some fixes for the ste_dma40 driver. Thanks, Fabio Gerald Baeza (1): dmaengine: ste_dma40: support fixed physical channel allocation Narayanan (1): dmaengine: ste_dma40: reset priority bit for logical channels Narayanan G (1): dmaengine: ste_dma40: don't check for pm_runtime_suspended() Per Forlin (3): dmaengine: ste_dma40: use writel_relaxed for lcxa dmaengine: ste_dma40: set dma max seg size dmaengine: ste_dma40: limit burst size to 16 Rabin Vincent (1): dmaengine: ste_dma40: don't allow high priority dest event lines drivers/dma/ste_dma40.c| 46 +- drivers/dma/ste_dma40_ll.c | 27 ++- 2 files changed, 55 insertions(+), 18 deletions(-) -- 1.7.12.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 2/7] dmaengine: ste_dma40: use writel_relaxed for lcxa
From: Per Forlin
lcpa and lcla are written often and the cache_sync() overhead in writel
is costly, especially for wlan where every single network packet (in RX
mode) corresponds to a separate DMA transfer.
Signed-off-by: Per Forlin
Reviewed-by: Narayanan Gopalakrishnan
Reviewed-by: Rabin Vincent
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40_ll.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 536e848..c0781ae 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -332,10 +332,10 @@ void d40_log_lli_lcpa_write(struct d40_log_lli_full *lcpa,
{
d40_log_lli_link(lli_dst, lli_src, next, flags);
- writel(lli_src->lcsp02, [0].lcsp0);
- writel(lli_src->lcsp13, [0].lcsp1);
- writel(lli_dst->lcsp02, [0].lcsp2);
- writel(lli_dst->lcsp13, [0].lcsp3);
+ writel_relaxed(lli_src->lcsp02, [0].lcsp0);
+ writel_relaxed(lli_src->lcsp13, [0].lcsp1);
+ writel_relaxed(lli_dst->lcsp02, [0].lcsp2);
+ writel_relaxed(lli_dst->lcsp13, [0].lcsp3);
}
void d40_log_lli_lcla_write(struct d40_log_lli *lcla,
@@ -345,10 +345,10 @@ void d40_log_lli_lcla_write(struct d40_log_lli *lcla,
{
d40_log_lli_link(lli_dst, lli_src, next, flags);
- writel(lli_src->lcsp02, [0].lcsp02);
- writel(lli_src->lcsp13, [0].lcsp13);
- writel(lli_dst->lcsp02, [1].lcsp02);
- writel(lli_dst->lcsp13, [1].lcsp13);
+ writel_relaxed(lli_src->lcsp02, [0].lcsp02);
+ writel_relaxed(lli_src->lcsp13, [0].lcsp13);
+ writel_relaxed(lli_dst->lcsp02, [1].lcsp02);
+ writel_relaxed(lli_dst->lcsp13, [1].lcsp13);
}
static void d40_log_fill_lli(struct d40_log_lli *lli,
--
1.7.12.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 7/7] dmaengine: ste_dma40: support fixed physical channel allocation
From: Gerald Baeza
This patch makes existing use_fixed_channel field (of stedma40_chan_cfg
structure) applicable to physical channels.
Signed-off-by: Gerald Baeza
Tested-by: Yannick Fertre
Reviewed-by: Per Forlin
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index f871df6..efe8be7 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -1712,10 +1712,12 @@ static int d40_allocate_channel(struct d40_chan *d40c,
bool *first_phy_user)
int i;
int j;
int log_num;
+ int num_phy_chans;
bool is_src;
bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
phys = d40c->base->phy_res;
+ num_phy_chans = d40c->base->num_phy_chans;
if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
dev_type = d40c->dma_cfg.src_dev_type;
@@ -1736,12 +1738,19 @@ static int d40_allocate_channel(struct d40_chan *d40c,
bool *first_phy_user)
if (!is_log) {
if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
/* Find physical half channel */
- for (i = 0; i < d40c->base->num_phy_chans; i++) {
-
+ if (d40c->dma_cfg.use_fixed_channel) {
+ i = d40c->dma_cfg.phy_channel;
if (d40_alloc_mask_set([i], is_src,
0, is_log,
first_phy_user))
goto found_phy;
+ } else {
+ for (i = 0; i < num_phy_chans; i++) {
+ if (d40_alloc_mask_set([i], is_src,
+ 0, is_log,
+ first_phy_user))
+ goto found_phy;
+ }
}
} else
for (j = 0; j < d40c->base->num_phy_chans; j += 8) {
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] dmaengine: ste_dma40: limit burst size to 16
From: Per Forlin
The client is not aware of the maximum burst size in the dma driver. If
the size exceeds 16 set max to 16.
Signed-off-by: Per Forlin
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 16c96f5..0b80ee9 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2579,6 +2579,14 @@ static int d40_set_runtime_config(struct dma_chan *chan,
return -EINVAL;
}
+ if (src_maxburst > 16) {
+ src_maxburst = 16;
+ dst_maxburst = src_maxburst * src_addr_width / dst_addr_width;
+ } else if (dst_maxburst > 16) {
+ dst_maxburst = 16;
+ src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
+ }
+
ret = dma40_config_to_halfchannel(d40c, >src_info,
src_addr_width,
src_maxburst);
--
1.7.12.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: [Xen-devel] [PATCH] xen/swiotlb: Exchange to contiguous memory for map_sg hook
>>> On 12.12.12 at 02:03, "Xu, Dongxiao" wrote: >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] >> On Tue, Dec 11, 2012 at 06:39:35AM +, Xu, Dongxiao wrote: >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] >> > > What if this check was done in the routines that provide the >> > > software static buffers and there try to provide a nice DMA contingous >> swatch of pages? >> > >> > Yes, this approach also came to our mind, which needs to modify the driver >> itself. >> > If so, it requires driver not using such static buffers (e.g., from > kmalloc) to do >> DMA even if the buffer is continuous in native. >> >> I am bit loss here. >> >> Is the issue you found only with drivers that do not use DMA API? >> Can you perhaps point me to the code that triggered this fix in the first > place? > > Yes, we met this issue on a specific SAS device/driver, and it calls into > libata-core code, you can refer to function ata_dev_read_id() called from > ata_dev_reread_id() in drivers/ata/libata-core.c. > > In the above function, the target buffer is (void > *)dev->link->ap->sector_buf, > which is 512 bytes static buffer and unfortunately it across the page > boundary. I wonder whether such use of sg_init_one()/sg_set_buf() is correct in the first place. While there aren't any restrictions documented for its use, one clearly can't pass in whatever one wants (a pointer into vmalloc()-ed memory, for instance, won't work afaict). I didn't go through all other users of it, but quite a few of the uses elsewhere look similarly questionable. >> I am still not completely clear on what you had in mind. The one method I >> thought about that might help in this is to have Xen-SWIOTLB track which >> memory ranges were exchanged (so xen_swiotlb_fixup would save the *buf >> and the size for each call to xen_create_contiguous_region in a list or > array). >> >> When xen_swiotlb_map/xen_swiotlb_map_sg_attrs care called they would >> consult said array/list to see if the region they retrieved crosses said 2MB >> chunks. If so.. and here I am unsure of what would be the best way to > proceed. > > We thought we can solve the issue in several ways: > > 1) Like the previous patch I sent out, we check the DMA region in > xen_swiotlb_map_page() and xen_swiotlb_map_sg_attr(), and if DMA region > crosses page boundary, we exchange the memory and copy the content. However > it has race condition that when copying the memory content (we introduced two > memory copies in the patch), some other code may also visit the page, which > may encounter incorrect values. That's why, after mapping a buffer (or SG list) one has to call the sync functions before looking at data. Any race as described by you is therefore a programming error. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] dmaengine: ste_dma40: don't allow high priority dest event lines
From: Rabin Vincent
Hardware bug: when a logical channel is triggerred by a high priority
destination event line, an extra packet transaction is generated in case
of important data write response latency on previous logical channel A
and if the source transfer of current logical channel B is already
completed and if no other channel with a higher priority than B is
waiting for execution.
Software workaround: do not set the high priority level for the
destination event lines that trigger logical channels.
Signed-off-by: Rabin Vincent
Reviewed-by: Shreshtha Kumar Sahu
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d8d58d9..f871df6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2181,11 +2181,24 @@ static void __d40_set_prio_rt(struct d40_chan *d40c,
int dev_type, bool src)
{
bool realtime = d40c->dma_cfg.realtime;
bool highprio = d40c->dma_cfg.high_priority;
- u32 prioreg = highprio ? D40_DREG_PSEG1 : D40_DREG_PCEG1;
u32 rtreg = realtime ? D40_DREG_RSEG1 : D40_DREG_RCEG1;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
u32 bit = 1 << event;
+ u32 prioreg;
+
+ /*
+* Due to a hardware bug, in some cases a logical channel triggered by
+* a high priority destination event line can generate extra packet
+* transactions.
+*
+* The workaround is to not set the high priority level for the
+* destination event lines that trigger logical channels.
+*/
+ if (!src && chan_is_logical(d40c))
+ highprio = false;
+
+ prioreg = highprio ? D40_DREG_PSEG1 : D40_DREG_PCEG1;
/* Destination event lines are stored in the upper halfword */
if (!src)
--
1.7.12.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] sched/rt: don't enable runtime if already enabled
On Tue, 2012-12-11 at 21:38 -0800, Neil Zhang wrote:
> Ingo and All,
Hm, /me wonders why we would even need update_runtime() handler. We
disable at CPU_DOWN_PREPARE in update_runtime(), again at CPU_DYING in
migration_call(), and enable at CPU_ONLINE in both.
> -Original Message-
> From: Neil Zhang
> Sent: 2012年12月4日 17:31
> To: Neil Zhang; pet...@infradead.org; mi...@kernel.org
> Cc: Chao Xie; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] sched/rt: don't enable runtime if already enabled
>
> Hi All,
>
> -Original Message-
> From: Neil Zhang [mailto:zhan...@marvell.com]
> Sent: 2012年12月3日 16:01
> To: mi...@redhat.com; pet...@infradead.org
> Cc: Chao Xie; linux-kernel@vger.kernel.org; Neil Zhang
> Subject: [PATCH] sched/rt: don't enable runtime if already enabled
>
> There are two paths will call __enable_runtime, they are enable_runtime and
> rq_online. Don't enable runtime again if it is already enabled.
> It can fix the following kernel BUG when do cpu hotplug while there are
> realtime threads running.
>
> [ 3347.091644] kernel BUG at kernel/sched/rt.c:687!
> [ 3347.091674] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [
> 3347.091674] Modules linked in: cidatattydev(O) gs_diag(O) diag(O)
> gs_modem(O) ccinetdev(O) cci_datastub(O) citty(O) msocke
> [ 3347.091705] CPU: 1Tainted: G O (3.4.5+ #439)
> [ 3347.091735] PC is at __disable_runtime+0x1e4/0x240 [ 3347.091735] LR is at
> __disable_runtime+0x1dc/0x240
> [ 3347.091735] pc : []lr : []psr:
> a093
> [ 3347.091735] sp : e0061dc8 ip : c0807861 fp : c07a9740 [ 3347.091766]
> r10: c1a0b740 r9 : r8 : fd050f80 [ 3347.091766] r7 : 0002 r6
> : 03f8 r5 : c1a13740 r4 : c1a137d8 [ 3347.091766] r3 : r2 :
> e0061dbc r1 : c06b11b6 r0 : 0037 [ 3347.091796] Flags: NzCv IRQs off
> FIQs on Mode SVC_32 ISA ARM Segment kernel [ 3347.091796] Control:
> 10c53c7d Table: 21e5004a DAC: 0015
>
> Signed-off-by: Neil Zhang
> ---
> kernel/sched/rt.c |8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 418feb0..6525e5b
> 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -722,9 +722,11 @@ static void __enable_runtime(struct rq *rq)
>
> raw_spin_lock(_b->rt_runtime_lock);
> raw_spin_lock(_rq->rt_runtime_lock);
> - rt_rq->rt_runtime = rt_b->rt_runtime;
> - rt_rq->rt_time = 0;
> - rt_rq->rt_throttled = 0;
> + if (rt_rq->rt_runtime == RUNTIME_INF) {
> + rt_rq->rt_runtime = rt_b->rt_runtime;
> + rt_rq->rt_time = 0;
> + rt_rq->rt_throttled = 0;
> + }
> raw_spin_unlock(_rq->rt_runtime_lock);
> raw_spin_unlock(_b->rt_runtime_lock);
> }
> --
> 1.7.4.1
>
> Ingo seems use another mail now, update the To list.
>
> Best Regards,
> Neil Zhang
>
> Please help review it.
>
> Best Regards,
> Neil Zhang
> NР骒rybX肚v^)藓{.n+伐{赙zXФ≤}财z:+v赙zZ++zf＂h~izwア?ㄨ&)撷f^j谦ym@Aa囤0鹅hi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] dmaengine: ste_dma40: don't check for pm_runtime_suspended()
From: Narayanan G The check for runtime suspend is not needed during a regular suspend, as the framework takes care of this. This fixes the issue of DMA driver not letting the system to go to deepsleep in the first attempt. Signed-off-by: Narayanan G Reviewed-by: Rabin Vincent Acked-by: Linus Walleij Signed-off-by: Fabio Baltieri --- drivers/dma/ste_dma40.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c index 0b80ee9..d8d58d9 100644 --- a/drivers/dma/ste_dma40.c +++ b/drivers/dma/ste_dma40.c @@ -2783,8 +2783,6 @@ static int dma40_pm_suspend(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct d40_base *base = platform_get_drvdata(pdev); int ret = 0; - if (!pm_runtime_suspended(dev)) - return -EBUSY; if (base->lcpa_regulator) ret = regulator_disable(base->lcpa_regulator); -- 1.7.12.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 3/7] dmaengine: ste_dma40: set dma max seg size
From: Per Forlin
Maximum DMA seg size is (0x x data_width). If max seg
size is not set it deafults to 64k. This results in failure
if transferring 64k in byte mode.
Large seg sizes may be supported by splitting large transfer.
Signed-off-by: Per Forlin
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ae55091..16c96f5 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -345,6 +345,7 @@ struct d40_base {
int irq;
int num_phy_chans;
int num_log_chans;
+ struct device_dma_parameters dma_parms;
struct dma_device dma_both;
struct dma_device dma_slave;
struct dma_device dma_memcpy;
@@ -3363,6 +3364,13 @@ static int __init d40_probe(struct platform_device *pdev)
if (err)
goto failure;
+ base->dev->dma_parms = >dma_parms;
+ err = dma_set_max_seg_size(base->dev, STEDMA40_MAX_SEG_SIZE);
+ if (err) {
+ d40_err(>dev, "Failed to set dma max seg size\n");
+ goto failure;
+ }
+
d40_hw_init(base);
dev_info(base->dev, "initialized\n");
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] dmaengine: ste_dma40: reset priority bit for logical channels
From: Narayanan G
This patch sets the SSCFG/SDCFG bit[7] PRI only for physical channel
requests with high priority. For logical channels, this bit will be
zero.
Signed-off-by: Narayanan G
Reviewed-by: Rabin Vincent
Acked-by: Linus Walleij
Signed-off-by: Fabio Baltieri
---
drivers/dma/ste_dma40_ll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index cad9e1d..536e848 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -102,17 +102,18 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
+ /* Set the priority bit to high for the physical channel */
+ if (cfg->high_priority) {
+ src |= 1 << D40_SREG_CFG_PRI_POS;
+ dst |= 1 << D40_SREG_CFG_PRI_POS;
+ }
+
} else {
/* Logical channel */
dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
}
- if (cfg->high_priority) {
- src |= 1 << D40_SREG_CFG_PRI_POS;
- dst |= 1 << D40_SREG_CFG_PRI_POS;
- }
-
if (cfg->src_info.big_endian)
src |= 1 << D40_SREG_CFG_LBE_POS;
if (cfg->dst_info.big_endian)
--
1.7.12.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] xen/blkback: prevent repeated backend_changed invocations
>>> On 11.12.12 at 21:50, Olaf Hering wrote: > backend_changed might be called multiple times, which will leak > be->mode. Make sure it will be called only once. Remove some unneeded > checks. Also the be->mode string was leaked, release the memory on > device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] HID: autodetect USB HID sensor hubs.
On Sun, 9 Dec 2012, Alexander Holler wrote: > It should not be necessary to add IDs for HID sensor hubs to lists > in hid-core.c and hid-sensor-hub.c. So instead of a whitelist, > autodetect such USB HID sensor hubs, based on a collection of type > physical inside a useage page of type sensor. If some sensor hubs > stil must be usable as raw devices, a blacklist might be created. > > Signed-off-by: Alexander Holler I like this change and would like to merge it, but I'd appreciate Ack from Srinivas first. Srinivas? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] llist: add a safe version of llist_for_each_entry
On 12/12/12 01:37, Huang Ying wrote: > On Tue, 2012-12-11 at 12:25 +0100, Roger Pau Monne wrote: >> Signed-off-by: Roger Pau Monné >> Cc: Huang Ying >> Cc: Konrad Rzeszutek Wilk >> --- >> Changes since v2: >> * Allow to pass a NULL node as the first entry of deleted list >>entries. >> --- >> include/linux/llist.h | 27 +++ >> 1 files changed, 27 insertions(+), 0 deletions(-) >> >> diff --git a/include/linux/llist.h b/include/linux/llist.h >> index a5199f6..4e0aec1 100644 >> --- a/include/linux/llist.h >> +++ b/include/linux/llist.h >> @@ -125,6 +125,33 @@ static inline void init_llist_head(struct llist_head >> *list) >> (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member)) >> >> /** >> + * llist_for_each_entry_safe - safely iterate over some deleted entries of >> + * lock-less list of given type >> + * @pos:the type * to use as a loop cursor. >> + * @n: the llist_node to use as a temporary loop cursor > > In list_for_each_entry_safe, n is type *, why not follow that? Thanks for the review, yes I just saw it, I was using llist_node because I didn't need a type *, but I agree that it's best to stick with list_for_each_entry_safe interface. Will send v4 > > Best Regards, > Huang Ying > >> + * @node: the fist entry of deleted list entries. >> + * @member: the name of the llist_node with the struct. >> + * >> + * In general, some entries of the lock-less list can be traversed >> + * safely only after being removed from list, so start with an entry >> + * instead of list head. >> + * >> + * If being used on entries deleted from lock-less list directly, the >> + * traverse order is from the newest to the oldest added entry. If >> + * you want to traverse from the oldest to the newest, you must >> + * reverse the order by yourself before traversing. >> + * >> + * n is used to store a reference to the next item llist_node, so >> + * pos can be freed while iterating. >> + */ >> +#define llist_for_each_entry_safe(pos, n, node, member) \ >> +for ((pos) = llist_entry((node), typeof(*(pos)), member), \ >> + (n) = (&(pos)->member != NULL) ? (pos)->member.next : NULL;\ >> + &(pos)->member != NULL;\ >> + (pos) = llist_entry(n, typeof(*(pos)), member),\ >> + (n) = (&(pos)->member != NULL) ? (pos)->member.next : NULL) >> + >> +/** >> * llist_empty - tests whether a lock-less list is empty >> * @head: the list to test >> * > > -- 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: [braindump][RFC] signals and syscall restarts (Re: [PATCH v2 19/44] metag: Signal handling)
On 08/12/12 18:14, Al Viro wrote:
> On Thu, Dec 06, 2012 at 10:09:55PM +, Al Viro wrote:
>
>> What we need to guarantee is
>> * restarts do not happen on signals caught in interrupts or exceptions
>> * restarts do not happen on signals caught in sigreturn()
Since we don't currently have an orig syscall in our pt_regs that
we can make invalid, is it acceptable to just explicitly exclude
rt_sigreturn? e.g. using something like this around the switch
statements that check for -ERESTART*:
/*
* Decide whether a syscall restart should be checked for.
* This needs to exclude non-syscalls (syscall == -1), and sys_rt_sigreturn.
*/
static int restartable_syscall(int syscall)
{
return syscall >= 0 && syscall != __NR_rt_sigreturn;
}
>> * restart should happen only once, even if we get through do_signal() many
>> times.
>
> BTW, signal caught in sigreturn is *not* something requiring a narrow
> race. It's perfectly normal to have some signals blocked for the
> duration of signal handler - the signal itself is blocked by default
> unless you have set SA_NODEFER in sa_flags and there's sa_mask allowing
> to block an arbitrary set of signals. Upon return from signal handler
> we undo that and if any of the temporary blocked signals has arrived
> while we'd been in the handler (e.g. had been raised by the handler itself),
> it will be caught as soon as we unblock it, i.e. in sigreturn.
>
> Unfortunately, the testcases are somewhat architecture-dependent. See, for
> example, arm one in commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86; there
> might be a way to arrange for asm-free equivalent if one played with -O0,
> but it's probably not worth the trouble. That one deals with sigreturn
> from signal caught in interrupt; sigreturn from signal caught in syscall
> is a bit trickier. TBH, I don't understand your syscall calling conventions
> well enough to cook one up; your restart logics looks really strange.
> You leave ->DX[0].U0 modified - fair enough, it doesn't seem to be used
> by syscall entry path - *and* you revert ->DX[0].U1 to the state you
> used to have on entry. The thing is, I don't see any place that would
> have changed it in between; why do you need that
> regs->REG_SYSCALL = orig_syscall;
> in there at all?
Yes, this doesn't seem to be necessary. The only other place
REG_SYSCALL is changed is when it's set to __NR_restart_syscall, in
which case I presume it never needs to be reset i.e. if a syscall
returns -ERESTART_RESTARTBLOCK, it either doesn't return a different
-ERESTART* from the restart block callback, or it's acceptable in
that case to restart sys_restart_syscall rather than the original
syscall that returned -ERESTART_RESTARTBLOCK. Is that right?
>
> BTW, could you (and other folks submitting ports) document the ABI?
> See e.g. Documentation/frv/kernel-ABI.txt for fairly decent example...
>
Good idea, something like below?
Thanks
James
Date: Tue, 11 Dec 2012 10:08:26 +
Subject: [PATCH 1/1] metag: add kernel-ABI document
Add a document in Documentation/metag/ describing the Linux ABI for
metag. It includes an outline of the registers, which ones are special
in userland and the kernel, the system call ABI, and an overview of the
calling conventions.
It was suggested that new architecture ports should have some ABI
documentation available, with Documentation/frv/kernel-ABI.txt
referenced as a decent example, from which some inspiration was drawn
for this patch.
Signed-off-by: James Hogan
Reported-by: Al Viro
---
Documentation/metag/00-INDEX |2 +
Documentation/metag/kernel-ABI.txt | 256
2 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 Documentation/metag/kernel-ABI.txt
diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX
index 4fe2e16..4a93a27 100644
--- a/Documentation/metag/00-INDEX
+++ b/Documentation/metag/00-INDEX
@@ -6,3 +6,5 @@ coremem.txt
- Documents the core memory interface used by suspend code
comet/
- Documentation specific to the Comet SoC
+kernel-ABI.txt
+ - Documents metag ABI details
diff --git a/Documentation/metag/kernel-ABI.txt
b/Documentation/metag/kernel-ABI.txt
new file mode 100644
index 000..7b8dee8
--- /dev/null
+++ b/Documentation/metag/kernel-ABI.txt
@@ -0,0 +1,256 @@
+ ==
+ KERNEL ABIS FOR METAG ARCH
+ ==
+
+This document describes the Linux ABIs for the metag architecture, and has the
+following sections:
+
+ (*) Outline of registers
+ (*) Userland registers
+ (*) Kernel registers
+ (*) System call ABI
+ (*) Calling conventions
+
+
+
+OUTLINE OF REGISTERS
+
+
+The main Meta core registers are arranged in units:
+
+ UNITTypeDESCRIPTION GP EXT PRIVGLOBAL
+ === === === === === ===
[Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
Hello Omar Ramirez Luna:
in drivers/staging/tidspbridge/core/io_sm.c:
it is for function dump_dsp_stack.
"char name[256]" is not initialized. (line 1898)
name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
2098..2103)
if node_find_addr fails, pr_err may cause issue (name may not be
initialized)
in drivers/staging/tidspbridge/rmgr/node.c:
function node_find_addr can be called by dump_dsp_stack.
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
in drivers/staging/tidspbridge/rmgr/nldr.c:
function nldr_find_addr can be called by node_find_addr
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
please help checking, thanks.
gchen.
in drivers/staging/tidspbridge/rmgr/nldr.c:
1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
1799 u32 offset_range, void *offset_output, char
*sym_name)
1800 {
1801 int status = 0;
1802 bool status1 = false;
1803 s32 i = 0;
1804 struct lib_node root = { NULL, 0, NULL };
1805 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__, (u32)
nldr_node,
1806 sym_addr, offset_range, (u32) offset_output,
sym_name);
1807
...
in drivers/staging/tidspbridge/rmgr/node.c:
3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
3010 u32 offset_range, void *sym_addr_output, char *sym_name)
3011 {
3012 struct node_object *node_obj;
3013 int status = -ENOENT;
3014
3015 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__,
3016 (unsigned int) node_mgr,
3017 sym_addr, offset_range,
3018 (unsigned int) sym_addr_output, sym_name);
3019
3020 list_for_each_entry(node_obj, _mgr->node_list, list_elem) {
3021 status = nldr_find_addr(node_obj->nldr_node_obj, sym_addr,
3022 offset_range, sym_addr_output, sym_name);
3023 if (!status)
3024 break;
3025 }
3026
3027 return status;
3028 }
in drivers/staging/tidspbridge/core/io_sm.c:
1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
1893 {
1894 int status = 0;
1895 struct cod_manager *code_mgr;
1896 struct node_mgr *node_mgr;
1897 u32 trace_begin;
1898 char name[256];
1899 struct {
1900 u32 head[2];
1901 u32 size;
1902 } mmu_fault_dbg_info;
1903 u32 *buffer;
1904 u32 *buffer_beg;
1905 u32 *buffer_end;
1906 u32 exc_type;
1907 u32 dyn_ext_base;
1908 u32 i;
1909 u32 offset_output;
1910 u32 total_size;
1911 u32 poll_cnt;
1912 const char *dsp_regs[] = {"EFR", "IERR", "ITSR", "NTSR",
1913 "IRP", "NRP", "AMR", "SSR",
1914 "ILC", "RILC", "IER", "CSR"};
1915 const char *exec_ctxt[] = {"Task", "SWI", "HWI", "Unknown"};
1916 struct bridge_drv_interface *intf_fxns;
1917 struct dev_object *dev_object = bridge_context->dev_obj;
1918
1919 status = dev_get_cod_mgr(dev_object, _mgr);
1920 if (!code_mgr) {
1921 pr_debug("%s: Failed on dev_get_cod_mgr.\n", __func__);
1922 status = -EFAULT;
1923 }
1924
1925 if (!status) {
1926 status = dev_get_node_manager(dev_object, _mgr);
1927 if (!node_mgr) {
1928 pr_debug("%s: Failed on dev_get_node_manager.\n",
1929 __func__);
1930 status = -EFAULT;
1931 }
1932 }
1933
1934 if (!status) {
1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
1936 status =
1937 cod_get_sym_value(code_mgr, COD_TRACEBEG,
_begin);
1938 pr_debug("%s: trace_begin Value 0x%x\n",
1939 __func__, trace_begin);
1940 if (status)
1941 pr_debug("%s: Failed on cod_get_sym_value.\n",
1942 __func__);
1943 }
1944 if (!status)
1945 status = dev_get_intf_fxns(dev_object, _fxns);
1946 /*
1947 * Check for the "magic number" in the trace buffer. If it has
1948 * yet to appear then poll the trace buffer to wait for it. Its
1949 * appearance signals that the DSP has finished dumping its state.
1950 */
1951 mmu_fault_dbg_info.head[0] = 0;
1952 mmu_fault_dbg_info.head[1] = 0;
1953 if (!status) {
1954 poll_cnt = 0;
1955 while
Re: [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, Dec 12, Jan Beulich wrote: > >>> On 11.12.12 at 21:50, Olaf Hering wrote: > > backend_changed might be called multiple times, which will leak > > be->mode. Make sure it will be called only once. Remove some unneeded > > checks. Also the be->mode string was leaked, release the memory on > > device shutdown. > > So did I miss some discussion here? I haven't seen any > confirmation of this function indeed being supposed to be called > just once. > > Also, as said previously, if indeed it is to be called just once, > removing the watch during/after the first invocation would seem > to be the more appropriate thing to do. Does the API allow this, that the called function can disable the watch? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
On 12/11/2012 07:21 PM, Alexander Holler wrote:
> This driver makes the time from HID sensors (hubs) which are offering
> such available like any other RTC does.
>
> Currently the time can only be read. Setting the time must be done
> through sending a report, which currently isn't supported by
> hid-sensor-hub. (I've planned to submit patches.)
>
> It is necessary that all values like year, month etc, are send as
> 8bit values (1 byte each) and all of them in 1 report. Also the
> spec HUTRR39b doesn't define the range of the year field, we
> tread it as 0 - 99 because that's what most RTCs I know about are
> offering.
>
> Signed-off-by: Alexander Holler
Looks good, but as I wrote during the last review the __devinits need to go.
A few other suggerstions online
> ---
> drivers/rtc/Kconfig | 16 ++
> drivers/rtc/Makefile |1 +
> drivers/rtc/rtc-hid-sensor-time.c | 284
> +
> 3 files changed, 301 insertions(+), 0 deletions(-)
> create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 19c03ab..7c7b33e 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS
> This driver can also be built as a module, if so, the module
> will be called "rtc-snvs".
>
> +comment "HID Sensor RTC drivers"
> +
> +config RTC_DRV_HID_SENSOR_TIME
> + tristate "HID Sensor Time"
> + depends on USB_HID
> + select IIO
> + select HID_SENSOR_HUB
> + select HID_SENSOR_IIO_COMMON
> + help
> + Say yes here to build support for the HID Sensors of type Time.
> + This drivers makes such sensors available as RTCs.
> +
> + If this driver is compiled as a module, it will be named
> + rtc-hid-sensor-time.
The help text should be indented using one tab followed by two spaces
> +
> +
> endif # RTC_CLASS
[...]
> diff --git a/drivers/rtc/rtc-hid-sensor-time.c
> b/drivers/rtc/rtc-hid-sensor-time.c
> new file mode 100644
> index 000..42b7ba1
> --- /dev/null
> +++ b/drivers/rtc/rtc-hid-sensor-time.c
> @@ -0,0 +1,284 @@
[...]
> +
> +/* Channel names for verbose error messages */
> +static const char *hid_time_channel_names[TIME_RTC_CHANNEL_MAX] = {
const char * const
> + "year", "month", "day", "hour", "minute", "second",
> +};
> +
> +/* Callback handler to send event after all samples are received and
> captured */
> +static int hid_time_proc_event(struct hid_sensor_hub_device *hsdev,
> + unsigned usage_id, void *priv)
> +{
> + unsigned long flags;
> + struct hid_time_state *time_state = platform_get_drvdata(priv);
> +
> + spin_lock_irqsave(_state->lock_last_time, flags);
> + time_state->last_time = time_state->time_buf;
> + spin_unlock_irqrestore(_state->lock_last_time, flags);
> + complete(_state->comp_last_time);
> + return 0;
> +}
> +
> +static int hid_time_capture_sample(struct hid_sensor_hub_device *hsdev,
> + unsigned usage_id, size_t raw_len,
> + char *raw_data, void *priv)
> +{
> + struct hid_time_state *time_state = platform_get_drvdata(priv);
> + struct rtc_time *time_buf = _state->time_buf;
> +
> + switch (usage_id) {
> + case HID_USAGE_SENSOR_TIME_YEAR:
> + time_buf->tm_year = *(u8 *)raw_data;
> + if (time_buf->tm_year < 70)
> + /* assume we are in 1970...2069 */
> + time_buf->tm_year += 100;
> + break;
> + case HID_USAGE_SENSOR_TIME_MONTH:
> + time_buf->tm_mon = --*(u8 *)raw_data;
What's up with the double minus?
> + break;
> + case HID_USAGE_SENSOR_TIME_DAY:
> + time_buf->tm_mday = *(u8 *)raw_data;
> + break;
> + case HID_USAGE_SENSOR_TIME_HOUR:
> + time_buf->tm_hour = *(u8 *)raw_data;
> + break;
> + case HID_USAGE_SENSOR_TIME_MINUTE:
> + time_buf->tm_min = *(u8 *)raw_data;
> + break;
> + case HID_USAGE_SENSOR_TIME_SECOND:
> + time_buf->tm_sec = *(u8 *)raw_data;
> + break;
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +/* small helper, haven't found any other way */
> +static const char *attrib_name(u32 attrib_id)
> +{
> + unsigned i = 0;
> + static const char unknown[] = "unknown";
> +
> + for (; i < TIME_RTC_CHANNEL_MAX; ++i) {
I would put the i = 0 in the for header.
> + if (hid_time_addresses[i] == attrib_id)
> + return hid_time_channel_names[i];
> + }
> + return unknown; /* should never happen */
> +}
> +
> +static int hid_time_parse_report(struct platform_device *pdev,
> + struct hid_sensor_hub_device *hsdev,
> + unsigned usage_id,
> +
Re: [PATCH 0/18] sched: simplified fork, enable load average into LB and power awareness scheduling
On Tue, Dec 11, 2012 at 10:10 PM, Arjan van de Ven wrote: > On 12/11/2012 8:13 AM, Borislav Petkov wrote: >> >> On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote: >>> >>> On 12/11/2012 7:48 AM, Borislav Petkov wrote: On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote: > > Another testing of parallel compress with pigz on Linus' git tree. > results show we get much better performance/power with powersaving and > balance policy: > > testing command: > #pigz -k -c -p$x -r linux* &> /dev/null > > On a NHM EP box > powersaving balance performance > x = 4166.516 /88 68 170.515 /82 71 165.283 /103 > 58 > x = 8173.654 /61 94 177.693 /60 93 172.31 /76 76 This looks funny: so "performance" is eating less watts than "powersaving" and "balance" on NHM. Could it be that the average watts measurements on NHM are not correct/precise..? On SNB they look as expected, according to your scheme. >>> >>> >>> well... it's not always beneficial to group or to spread out >>> it depends on cache behavior mostly which is best >> >> >> Let me try to understand what this means: so "performance" above with >> 8 threads means that those threads are spread out across more than one >> socket, no? >> >> If so, this would mean that you have a smaller amount of tasks on each >> socket, thus the smaller wattage. >> >> The "powersaving" method OTOH fills up the one socket up to the brim, >> thus the slightly higher consumption due to all threads being occupied. >> >> Is that it? > > > not sure. > > by and large, power efficiency is the same as performance efficiency, with > some twists. > or to reword that to be more clear > if you waste performance due to something that becomes inefficient, you're > wasting power as well. > now, you might have some hardware effects that can then save you power... > but those effects > then first need to overcome the waste from the performance inefficiency... > and that almost never happens. > > for example, if you have two workloads that each fit barely inside the last > level cache... > it's much more efficient to spread these over two sockets... where each has > its own full LLC > to use. > If you'd group these together, both would thrash the cache all the time and > run inefficient --> bad for power. > > now, on the other hand, if you have two threads of a process that share a > bunch of data structures, > and you'd spread these over 2 sockets, you end up bouncing data between the > two sockets a lot, > running inefficient --> bad for power. > Agree with all of the above. However.. > having said all this, if you have to tasks that don't have such cache > effects, the most efficient way > of running things will be on 2 hyperthreading halves... it's very hard to > beat the power efficiency of that. .. there are alternatives to hyperthreading. On ARM's big.LITTLE architecture you could simply schedule them on the LITTLE cores. The big cores just can't beat the power efficiency of the LITTLE ones even with 'race to halt' that you allude to below. And usecases like mp3 playback simply don't require the kind of performance that the big cores can offer. > But this assumes the tasks don't compete with resources much on the HT > level, and achieve good scaling. > and this still has to compete with "race to halt", because if you're done > quicker, you can put the memory > in self refresh quicker. > > none of this stuff is easy for humans or computer programs to determine > ahead of time... or sometimes even afterwards. > heck, even for just performance it's really really hard already, never mind > adding power. > > my personal gut feeling is that we should just optimize this scheduler stuff > for performance, and that > we're going to be doing quite well on power already if we achieve that. If Linux is to continue to work efficiently on heterogeneous multi-processing platforms, it needs to provide scheduling mechanisms that can be exploited as per the demands of the HW architecture. An example is the "small task packing (and spreading)" for which Vincent Guittot has posted a patchset[1] earlier and so has Alex now. [1] http://lwn.net/Articles/518834/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen/blkback: prevent repeated backend_changed invocations
>>> On 12.12.12 at 10:47, Olaf Hering wrote: > On Wed, Dec 12, Jan Beulich wrote: > >> >>> On 11.12.12 at 21:50, Olaf Hering wrote: >> > backend_changed might be called multiple times, which will leak >> > be->mode. Make sure it will be called only once. Remove some unneeded >> > checks. Also the be->mode string was leaked, release the memory on >> > device shutdown. >> >> So did I miss some discussion here? I haven't seen any >> confirmation of this function indeed being supposed to be called >> just once. >> >> Also, as said previously, if indeed it is to be called just once, >> removing the watch during/after the first invocation would seem >> to be the more appropriate thing to do. > > Does the API allow this, that the called function can disable the watch? That is what would need looking into (and why I said "during/after"). Jan -- 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: no release today (20121212)
Normal releases will resume tomorrow. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpx6rukip8fi.pgp Description: PGP signature
Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
于 2012年12月12日 17:48, Chen Gang 写道:
> Hello Omar Ramirez Luna:
>
> in drivers/staging/tidspbridge/core/io_sm.c:
> it is for function dump_dsp_stack.
> "char name[256]" is not initialized. (line 1898)
> name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
> 2098..2103)
> if node_find_addr fails, pr_err may cause issue (name may not be
> initialized)
oh sorry, pr_err no issue (it is my fault).
>
> in drivers/staging/tidspbridge/rmgr/node.c:
> function node_find_addr can be called by dump_dsp_stack.
> param sym_name is as out buf which may be not initialized.
> so pr_debug may cause issue (print sym_name).
>
> in drivers/staging/tidspbridge/rmgr/nldr.c:
> function nldr_find_addr can be called by node_find_addr
> param sym_name is as out buf which may be not initialized.
> so pr_debug may cause issue (print sym_name).
>
but they are still have issue.
I find by code review, please help check whether this suggestion is valid.
thanks.
> please help checking, thanks.
>
> gchen.
>
>
> in drivers/staging/tidspbridge/rmgr/nldr.c:
>
> 1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
> 1799 u32 offset_range, void *offset_output, char
> *sym_name)
> 1800 {
> 1801 int status = 0;
> 1802 bool status1 = false;
> 1803 s32 i = 0;
> 1804 struct lib_node root = { NULL, 0, NULL };
> 1805 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__, (u32)
> nldr_node,
> 1806 sym_addr, offset_range, (u32) offset_output,
> sym_name);
> 1807
> ...
>
>
> in drivers/staging/tidspbridge/rmgr/node.c:
>
> 3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
> 3010 u32 offset_range, void *sym_addr_output, char *sym_name)
> 3011 {
> 3012 struct node_object *node_obj;
> 3013 int status = -ENOENT;
> 3014
> 3015 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__,
> 3016 (unsigned int) node_mgr,
> 3017 sym_addr, offset_range,
> 3018 (unsigned int) sym_addr_output, sym_name);
> 3019
> 3020 list_for_each_entry(node_obj, _mgr->node_list, list_elem) {
> 3021 status = nldr_find_addr(node_obj->nldr_node_obj,
> sym_addr,
> 3022 offset_range, sym_addr_output, sym_name);
> 3023 if (!status)
> 3024 break;
> 3025 }
> 3026
> 3027 return status;
> 3028 }
>
>
>
>
> in drivers/staging/tidspbridge/core/io_sm.c:
>
> 1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
> 1893 {
> 1894 int status = 0;
> 1895 struct cod_manager *code_mgr;
> 1896 struct node_mgr *node_mgr;
> 1897 u32 trace_begin;
> 1898 char name[256];
> 1899 struct {
> 1900 u32 head[2];
> 1901 u32 size;
> 1902 } mmu_fault_dbg_info;
> 1903 u32 *buffer;
> 1904 u32 *buffer_beg;
> 1905 u32 *buffer_end;
> 1906 u32 exc_type;
> 1907 u32 dyn_ext_base;
> 1908 u32 i;
> 1909 u32 offset_output;
> 1910 u32 total_size;
> 1911 u32 poll_cnt;
> 1912 const char *dsp_regs[] = {"EFR", "IERR", "ITSR", "NTSR",
> 1913 "IRP", "NRP", "AMR", "SSR",
> 1914 "ILC", "RILC", "IER", "CSR"};
> 1915 const char *exec_ctxt[] = {"Task", "SWI", "HWI", "Unknown"};
> 1916 struct bridge_drv_interface *intf_fxns;
> 1917 struct dev_object *dev_object = bridge_context->dev_obj;
> 1918
> 1919 status = dev_get_cod_mgr(dev_object, _mgr);
> 1920 if (!code_mgr) {
> 1921 pr_debug("%s: Failed on dev_get_cod_mgr.\n", __func__);
> 1922 status = -EFAULT;
> 1923 }
> 1924
> 1925 if (!status) {
> 1926 status = dev_get_node_manager(dev_object, _mgr);
> 1927 if (!node_mgr) {
> 1928 pr_debug("%s: Failed on dev_get_node_manager.\n",
> 1929
> __func__);
> 1930 status = -EFAULT;
> 1931 }
> 1932 }
> 1933
> 1934 if (!status) {
> 1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
> 1936 status =
> 1937 cod_get_sym_value(code_mgr, COD_TRACEBEG,
> _begin);
> 1938 pr_debug("%s: trace_begin Value 0x%x\n",
> 1939 __func__, trace_begin);
> 1940 if (status)
> 1941 pr_debug("%s: Failed on cod_get_sym_value.\n",
> 1942
> __func__);
> 1943 }
> 1944 if (!status)
> 1945 status =
[GIT PULL] Automatic NUMA Balancing V11
Hi Linus, This is a pull request for "Automatic NUMA Balancing V11". The list of changes since commit f4a75d2eb7b1e2206094b901be09adb31ba63681: Linux 3.7-rc6 (2012-11-16 17:42:40 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux-balancenuma.git balancenuma-v11 for you to fetch changes up to 4fc3f1d66b1ef0d7b8dc11f4ff1cc510f78b37d6: mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable (2012-12-11 14:43:00 +) There are three implementations for NUMA balancing, this tree (balancenuma), numacore which has been developed in tip/master and autonuma which is in aa.git. In almost all respects balancenuma is the dumbest of the three because its main impact is on the VM side with no attempt to be smart about scheduling. In the interest of getting the ball rolling, it would be desirable to see this much merged for 3.8 with the view to building scheduler smarts on top and adapting the VM where required for 3.9. The most recent set of comparisons available from different people are mel:https://lkml.org/lkml/2012/12/9/108 mingo: https://lkml.org/lkml/2012/12/7/331 tglx: https://lkml.org/lkml/2012/12/10/437 srikar: https://lkml.org/lkml/2012/12/10/397 The results are a mixed bag. In my own tests, balancenuma does reasonably well. It's dumb as rocks and does not regress against mainline. On the other hand, Ingo's tests shows that balancenuma is incapable of converging for this workloads driven by perf which is bad but is potentially explained by the lack of scheduler smarts. Thomas' results show balancenuma improves on mainline but falls far short of numacore or autonuma. Srikar's results indicate we all suffer on a large machine with imbalanced node sizes. My own testing showed that recent numacore results have improved dramatically, particularly in the last week but not universally. We've butted heads heavily on system CPU usage and high levels of migration even when it shows that overall performance is better. There are also cases where it regresses. Of interest is that for specjbb in some configurations it will regress for lower numbers of warehouses and show gains for higher numbers which is not reported by the tool by default and sometimes missed in treports. Recently I reported for numacore that the JVM was crashing with NullPointerExceptions but currently it's unclear what the source of this problem is. Initially I thought it was in how numacore batch handles PTEs but I'm no longer think this is the case. It's possible numacore is just able to trigger it due to higher rates of migration. These reports were quite late in the cycle so I/we would like to start with this tree as it contains much of the code we can agree on and has not changed significantly over the last 2-3 weeks. Thanks. Andrea Arcangeli (5): mm: numa: define _PAGE_NUMA mm: numa: pte_numa() and pmd_numa() mm: numa: Support NUMA hinting page faults from gup/gup_fast mm: numa: split_huge_page: transfer the NUMA type from the pmd to the pte mm: numa: Structures for Migrate On Fault per NUMA migration rate limiting Hillf Danton (2): mm: numa: split_huge_page: Transfer last_nid on tail page mm: numa: migrate: Set last_nid on newly allocated page Ingo Molnar (3): mm: Optimize the TLB flush of sys_mprotect() and change_protection() users mm/rmap: Convert the struct anon_vma::mutex to an rwsem mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable Lee Schermerhorn (3): mm: mempolicy: Add MPOL_NOOP mm: mempolicy: Check for misplaced page mm: mempolicy: Add MPOL_MF_LAZY Mel Gorman (26): mm: Check if PTE is already allocated during page fault mm: compaction: Move migration fail/success stats to migrate.c mm: migrate: Add a tracepoint for migrate_pages mm: compaction: Add scanned and isolated counters for compaction mm: numa: Create basic numa page hinting infrastructure mm: migrate: Drop the misplaced pages reference count if the target node is full mm: mempolicy: Use _PAGE_NUMA to migrate pages mm: mempolicy: Implement change_prot_numa() in terms of change_protection() mm: mempolicy: Hide MPOL_NOOP and MPOL_MF_LAZY from userspace for now sched, numa, mm: Count WS scanning against present PTEs, not virtual memory ranges mm: numa: Add pte updates, hinting and migration stats mm: numa: Migrate on reference policy mm: numa: Migrate pages handled during a pmd_numa hinting fault mm: numa: Rate limit the amount of memory that is migrated between nodes mm: numa: Rate limit setting of pte_numa if node is saturated sched: numa: Slowly increase the scanning period as NUMA faults are handled mm: numa: Introduce last_nid to the page frame mm: numa: Use a two-stage filter to restrict pages being migrated for unlikely task<->node relationships
Re: linux-next: no release today (20121212)
On Wed, Dec 12, 2012 at 10:59 AM, Stephen Rothwell wrote: > Normal releases will resume tomorrow. > Good, no more ambitions to repair my Ubuntu/precise WUBI installation after Win7 updates or sth. else broke the wubi-loader... - Sedat - > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: decompressor: Flush tlb before swiching domain 0 to client mode
On Wednesday 12 December 2012 02:41 AM, Arve Hjønnevåg wrote: If the bootloader used a page table that is incompatible with domain 0 in client mode, then swithing domain 0 to client mode causes a fault if we don't flush the tlb after updating the page table pointer. Signed-off-by: Arve Hjønnevåg --- arch/arm/boot/compressed/head.S |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 90275f0..9c8034c 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -704,6 +704,7 @@ __armv7_mmu_cache_on: bic r6, r6, #1 << 31@ 32-bit translation system bic r6, r6, #3 << 0 @ use only ttbr0 mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer + mcrne p15, 0, r0, c8, c7, 0 @ flush I,D TLBs mcrne p15, 0, r1, c3, c0, 0 @ load domain access control mcrne p15, 0, r6, c2, c0, 2 @ load ttb control #endif The TLB's are already flushed few lines above so above patching shouldn't help if it was really dirty TLB entry issue. I suspect that your boot-loader clean-up [1] function may not be taking care of flushing caches which could potetially lead to the issue. Have you checked that ? Regards Santosh [1] http://www.arm.linux.org.uk/developer/noboot-checklist/ -- 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: Read starvation by sync writes
On Wed 12-12-12 10:55:15, Shaohua Li wrote: > 2012/12/11 Jan Kara : > > Hi, > > > > I was looking into IO starvation problems where streaming sync writes (in > > my case from kjournald but DIO would look the same) starve reads. This is > > because reads happen in small chunks and until a request completes we don't > > start reading further (reader reads lots of small files) while writers have > > plenty of big requests to submit. Both processes end up fighting for IO > > requests and writer writes nr_batching 512 KB requests while reader reads > > just one 4 KB request or so. Here the effect is magnified by the fact that > > the drive has relatively big queue depth so it usually takes longer than > > BLK_BATCH_TIME to complete the read request. The net result is it takes > > close to two minutes to read files that can be read under a second without > > writer load. Without the big drive's queue depth, results are not ideal but > > they are bearable - it takes about 20 seconds to do the reading. And for > > comparison, when writer and reader are not competing for IO requests (as it > > happens when writes are submitted as async), it takes about 2 seconds to > > complete reading. > > > > Simple reproducer is: > > > > echo 3 >/proc/sys/vm/drop_caches > > dd if=/dev/zero of=/tmp/f bs=1M count=1 & > > sleep 30 > > time cat /etc/* 2>&1 >/dev/null > > killall dd > > rm /tmp/f > > > > The question is how can we fix this? Two quick hacks that come to my mind > > are remove timeout from the batching logic (is it that important?) or > > further separate request allocation logic so that reads have their own > > request pool. More systematic fix would be to change request allocation > > logic to always allow at least a fixed number of requests per IOC. What do > > people think about this? > > As long as queue depth > workload iodepth, there is little we can do > to prioritize tasks/IOC. Because throttling a task/IOC means queue > will be idle. We don't want to idle a queue (especially for SSD), so > we always push as more requests as possible to the queue, which > will break any prioritization. As far as I know we always have such > issue in CFQ for big queue depth disk. Yes, I understand that. But actually big queue depth on its own doesn't make the problem really bad (at least for me). When the reader doesn't have to wait for free IO requests, it progresses at a reasonable speed. What makes it really bad is that big queue depth effectively disallows any use of ioc_batching() mode for the reader and thus it blocks in request allocation for every single read request unlike writer which always uses its full batch (32 requests). Honza -- Jan Kara 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/
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: > On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas > wrote: >> IGEP technology devices are TI OMAP3 SoC based industrial embedded >> and computer-on-module boards. This patch-set adds initial device >> tree support for these devices. >> >> The device trees allows to boot from an MMC and are working all the >> components that already have device tree support on OMAP3 SoCs: >> >> - MMC/SD >> - UARTs >> - GPIO LEDs >> - TWL4030 codec audio >> - pinmux/pinconf pinctrl >> >> Some peripheral are still not working such as Flash storage and >> Ethernet but support for these will also be included once the >> OMAP GPMC device tree binding patches land on mainline. >> >> This is a v3 of the patch-set that solves issues pointed out by >> Enric Balletbo and Benoit Cousson. >> >> The patch-set is composed of the following patches: >> >> [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices >> [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board >> [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module >> >> Best regards, >> Javier >> -- > > Hi Benoit and Tony, > > Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit -- 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/
Fwd: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
Hello Greg Kroah-Hartman:
excuse me, I have to forward this mail to you.
I have sent it to Omar Ramirez Luna , but failed.
(get mail delivery failed )
thanks.
gchen
原始消息
主题: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug
for uninitialized buffer (name buf not initialized).
日期: Wed, 12 Dec 2012 18:02:44 +0800
发件人: Chen Gang
收件人: omar.rami...@ti.com
抄送: linux-kernel@vger.kernel.org
于 2012年12月12日 17:48, Chen Gang 写道:
> Hello Omar Ramirez Luna:
>
> in drivers/staging/tidspbridge/core/io_sm.c:
> it is for function dump_dsp_stack.
> "char name[256]" is not initialized. (line 1898)
> name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
> 2098..2103)
> if node_find_addr fails, pr_err may cause issue (name may not be
> initialized)
oh sorry, pr_err no issue (it is my fault).
>
> in drivers/staging/tidspbridge/rmgr/node.c:
> function node_find_addr can be called by dump_dsp_stack.
> param sym_name is as out buf which may be not initialized.
> so pr_debug may cause issue (print sym_name).
>
> in drivers/staging/tidspbridge/rmgr/nldr.c:
> function nldr_find_addr can be called by node_find_addr
> param sym_name is as out buf which may be not initialized.
> so pr_debug may cause issue (print sym_name).
>
but they are still have issue (pr_debug).
I find by code review, please help check whether this suggestion is valid.
thanks.
> please help checking, thanks.
>
> gchen.
>
>
> in drivers/staging/tidspbridge/rmgr/nldr.c:
>
> 1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
> 1799 u32 offset_range, void *offset_output, char
> *sym_name)
> 1800 {
> 1801 int status = 0;
> 1802 bool status1 = false;
> 1803 s32 i = 0;
> 1804 struct lib_node root = { NULL, 0, NULL };
> 1805 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__, (u32)
> nldr_node,
> 1806 sym_addr, offset_range, (u32) offset_output,
> sym_name);
> 1807
> ...
>
>
> in drivers/staging/tidspbridge/rmgr/node.c:
>
> 3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
> 3010 u32 offset_range, void *sym_addr_output, char *sym_name)
> 3011 {
> 3012 struct node_object *node_obj;
> 3013 int status = -ENOENT;
> 3014
> 3015 pr_debug("%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n", __func__,
> 3016 (unsigned int) node_mgr,
> 3017 sym_addr, offset_range,
> 3018 (unsigned int) sym_addr_output, sym_name);
> 3019
> 3020 list_for_each_entry(node_obj, _mgr->node_list, list_elem) {
> 3021 status = nldr_find_addr(node_obj->nldr_node_obj,
> sym_addr,
> 3022 offset_range, sym_addr_output, sym_name);
> 3023 if (!status)
> 3024 break;
> 3025 }
> 3026
> 3027 return status;
> 3028 }
>
>
>
>
> in drivers/staging/tidspbridge/core/io_sm.c:
>
> 1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
> 1893 {
> 1894 int status = 0;
> 1895 struct cod_manager *code_mgr;
> 1896 struct node_mgr *node_mgr;
> 1897 u32 trace_begin;
> 1898 char name[256];
> 1899 struct {
> 1900 u32 head[2];
> 1901 u32 size;
> 1902 } mmu_fault_dbg_info;
> 1903 u32 *buffer;
> 1904 u32 *buffer_beg;
> 1905 u32 *buffer_end;
> 1906 u32 exc_type;
> 1907 u32 dyn_ext_base;
> 1908 u32 i;
> 1909 u32 offset_output;
> 1910 u32 total_size;
> 1911 u32 poll_cnt;
> 1912 const char *dsp_regs[] = {"EFR", "IERR", "ITSR", "NTSR",
> 1913 "IRP", "NRP", "AMR", "SSR",
> 1914 "ILC", "RILC", "IER", "CSR"};
> 1915 const char *exec_ctxt[] = {"Task", "SWI", "HWI", "Unknown"};
> 1916 struct bridge_drv_interface *intf_fxns;
> 1917 struct dev_object *dev_object = bridge_context->dev_obj;
> 1918
> 1919 status = dev_get_cod_mgr(dev_object, _mgr);
> 1920 if (!code_mgr) {
> 1921 pr_debug("%s: Failed on dev_get_cod_mgr.\n", __func__);
> 1922 status = -EFAULT;
> 1923 }
> 1924
> 1925 if (!status) {
> 1926 status = dev_get_node_manager(dev_object, _mgr);
> 1927 if (!node_mgr) {
> 1928 pr_debug("%s: Failed on dev_get_node_manager.\n",
> 1929
> __func__);
> 1930 status = -EFAULT;
> 1931 }
> 1932 }
> 1933
> 1934 if (!status) {
> 1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
> 1936 status =
> 1937 cod_get_sym_value(code_mgr,
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
Am 12.12.2012 10:51, schrieb Lars-Peter Clausen: Looks good, but as I wrote during the last review the __devinits need to go. A few other suggerstions online Oh, have forgotten it. Ok, will make a v4, changing the other few things too. + case HID_USAGE_SENSOR_TIME_MONTH: + time_buf->tm_mon = --*(u8 *)raw_data; Time sensors are sending the month in the range 1-12, not 0-11. Regards, Alexander -- 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/7] various ste_dma40 fixes
On Wed, Dec 12, 2012 at 10:37:14AM +0100, Fabio Baltieri wrote: > this patch set contains some fixes for the ste_dma40 driver. Adding DMA maintainers to the thread. Want me to resend the whole set? Thanks, Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
On 12/12/2012 11:14 AM, Alexander Holler wrote: > Am 12.12.2012 10:51, schrieb Lars-Peter Clausen: > >> Looks good, but as I wrote during the last review the __devinits need to go. >> A few other suggerstions online > > Oh, have forgotten it. Ok, will make a v4, changing the other few things too. > >>> +case HID_USAGE_SENSOR_TIME_MONTH: >>> +time_buf->tm_mon = --*(u8 *)raw_data; > > Time sensors are sending the month in the range 1-12, not 0-11. > Ah, sorry, I guess hadn't had enough coffee yet, I read this as -(-(*(u8 *)raw_data))) and was a bit confused... -- 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/hugetlb: create hugetlb cgroup file in hugetlb_init
On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
> system will boot fail.
>
> This failure is caused by following code path:
> setup_hugepagesz
> hugetlb_add_hstate
> hugetlb_cgroup_file_init
> cgroup_add_cftypes
> kzalloc <--slab is *not available* yet
>
> For this path, slab is not available yet, so memory allocated will be
> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
>
> So I move hugetlb_cgroup_file_init() into hugetlb_init().
I do not think this is a good idea. hugetlb_init is in __init section as
well so what guarantees that the slab is initialized by then? Isn't this
just a good ordering that makes this working?
Shouldn't this be rather placed in hugetlb_cgroup_create?
> Signed-off-by: Jianguo Wu
> Signed-off-by: Jiang Liu
> ---
> include/linux/hugetlb_cgroup.h |7 ++-
> mm/hugetlb.c | 11 +--
> mm/hugetlb_cgroup.c| 23 +--
> 3 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
> index d73878c..5bb9c28 100644
> --- a/include/linux/hugetlb_cgroup.h
> +++ b/include/linux/hugetlb_cgroup.h
> @@ -62,7 +62,7 @@ extern void hugetlb_cgroup_uncharge_page(int idx, unsigned
> long nr_pages,
>struct page *page);
> extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
> struct hugetlb_cgroup *h_cg);
> -extern int hugetlb_cgroup_file_init(int idx) __init;
> +extern void hugetlb_cgroup_file_init(void) __init;
> extern void hugetlb_cgroup_migrate(struct page *oldhpage,
> struct page *newhpage);
>
> @@ -111,10 +111,7 @@ hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long
> nr_pages,
> return;
> }
>
> -static inline int __init hugetlb_cgroup_file_init(int idx)
> -{
> - return 0;
> -}
> +static inline void __init hugetlb_cgroup_file_init() {}
>
> static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
> struct page *newhpage)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 1ef2cd4..a30da48 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1906,14 +1906,12 @@ static int __init hugetlb_init(void)
> default_hstate.max_huge_pages = default_hstate_max_huge_pages;
>
> hugetlb_init_hstates();
> -
> gather_bootmem_prealloc();
> -
> report_hugepages();
>
> hugetlb_sysfs_init();
> -
> hugetlb_register_all_nodes();
> + hugetlb_cgroup_file_init();
>
> return 0;
> }
> @@ -1943,13 +1941,6 @@ void __init hugetlb_add_hstate(unsigned order)
> h->next_nid_to_free = first_node(node_states[N_HIGH_MEMORY]);
> snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
> huge_page_size(h)/1024);
> - /*
> - * Add cgroup control files only if the huge page consists
> - * of more than two normal pages. This is because we use
> - * page[2].lru.next for storing cgoup details.
> - */
> - if (order >= HUGETLB_CGROUP_MIN_ORDER)
> - hugetlb_cgroup_file_init(hugetlb_max_hstate - 1);
>
> parsed_hstate = h;
> }
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index a3f358f..284cb68 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -340,7 +340,7 @@ static char *mem_fmt(char *buf, int size, unsigned long
> hsize)
> return buf;
> }
>
> -int __init hugetlb_cgroup_file_init(int idx)
> +static void __init __hugetlb_cgroup_file_init(int idx)
> {
> char buf[32];
> struct cftype *cft;
> @@ -382,7 +382,26 @@ int __init hugetlb_cgroup_file_init(int idx)
>
> WARN_ON(cgroup_add_cftypes(_subsys, h->cgroup_files));
>
> - return 0;
> + return;
> +}
> +
> +void __init hugetlb_cgroup_file_init()
> +{
> + struct hstate *h;
> + int idx;
> +
> + idx = 0;
> + for_each_hstate(h) {
> + /*
> + * Add cgroup control files only if the huge page consists
> + * of more than two normal pages. This is because we use
> + * page[2].lru.next for storing cgoup details.
> + */
> + if (h->order >= HUGETLB_CGROUP_MIN_ORDER)
> + __hugetlb_cgroup_file_init(idx);
> +
> + idx++;
> + }
> }
>
> /*
> -- 1.7.1
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
From: fangxiaozhi
1. To optimize the match rules for the Huawei USB storage devices. Avoid to
load USB storage driver for modem interface with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi
-
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-12
16:26:53.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
}
+
+/*Find the supported Huawei USB dongles*/
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ int ret = 0;
+ struct usb_interface_descriptor *idesc = NULL;
+ idesc = >pusb_intf->cur_altsetting->desc;
+ if (idesc != NULL && idesc->bInterfaceNumber == 0) {
+ if ((us->pusb_dev->descriptor.idProduct >= 0x1401 &&
us->pusb_dev->descriptor.idProduct <= 0x1600)
+ || (us->pusb_dev->descriptor.idProduct
>= 0x1c02 && us->pusb_dev->descriptor.idProduct <= 0x2202)
+ || (us->pusb_dev->descriptor.idProduct
== 0x1001)
+ || (us->pusb_dev->descriptor.idProduct
== 0x1003)
+ || (us->pusb_dev->descriptor.idProduct
== 0x1004)) {
+
+ if (us->pusb_dev->descriptor.idProduct >=
0x1501
+ && us->pusb_dev->descriptor.idProduct
<= 0x1504) {
+ ret = 0;
+ } else {
+ ret = 1;
+ }
+ }
+ }
+ return ret;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00,
0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00};
+ struct bulk_cb_wrap bcbw = {0};
+ bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw.Tag = 0;
+ bcbw.DataTransferLength = cpu_to_le32(0);
+ bcbw.Flags = bcbw.Lun = 0;
+ bcbw.Length = sizeof(rewind_cmd);
+ memset(bcbw.CDB, 0, sizeof(bcbw.CDB));
+ memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf (us, us->send_bulk_pipe, , 31,
_len);
+ US_DEBUGP("usb_stor_bulk_transfer_buf performing result is %d, transfer
the actual length=%d\n", result, act_len);
+ return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+ if(usb_stor_huawei_dongles_pid(us)) {
+ if ((us->pusb_dev->descriptor.idProduct >= 0x1446)) {
+ result = usb_stor_huawei_scsi_init(us);
+ } else {
+ result = usb_stor_huawei_feature_init(us);
+ }
+ }
+ return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h
linux-3.7/drivers/usb/storage/initializers.h
--- linux-3.7_bak/drivers/usb/storage/initializers.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.h2012-12-12
11:43:58.0 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.7_bak/drivers/usb/storage/unusual_devs.h
linux-3.7/drivers/usb/storage/unusual_devs.h
--- linux-3.7_bak/drivers/usb/storage/unusual_devs.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/unusual_devs.h2012-12-12
11:47:34.0 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x
/* Reported by fangxiaozhi
* This brings the HUAWEI data card devices into multi-port mode
*/
-UNUSUAL_DEV( 0x12d1, 0x1001, 0x, 0x,
+UNUSUAL_VENDOR_INTF( 0x12d1, 0x08, 0x06, 0x50,
"HUAWEI MOBILE",
"Mass Storage",
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
-
Re: [PATCH V4 3/3] MCE: fix an error of mce_bad_pages statistics
On Wed, Dec 12, 2012 at 11:35:33AM +0800, Xishi Qiu wrote: > Since MCE is an x86 concept, and this code is in mm/, it would be > better to use the name num_poisoned_pages instead of mce_bad_pages. > > Signed-off-by: Xishi Qiu > Signed-off-by: Jiang Liu > Signed-off-by: Borislav Petkov This is not how Signed-of-by: works. You should read Documentation/SubmittingPatches (yes, the whole of it) about how that whole S-o-b thing works. And, FWIW, it should be "Suggested-by: Borislav Petkov " Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] battery-2.6.git
Hello Linus, Here are a few updates and new drivers queued for v3.8. All the patches were sitting in the -next tree for awhile, except for the last merge commit -- I made it a few hours ago just to fix some conflicts, so that you won't have to bother. Highlights for this pull: - Two new drivers from Pali Rohár and N900 hackers: rx51_battery and bq2415x_charger. The drivers are a part of a solution to replace the proprietary Nokia BME stack; - Power supply core now registers devices with a thermal cooling subsystem, so we can now automatically throttle charging. Thanks to Ramakrishna Pallala! - Device tree support for ab8500 and max8925_power drivers; - Random fixups and enhancements for a bunch of drivers. Thanks! The following changes since commit 1ebaf4f4e6912199f8a4e30ba3ab55da2b71bcdf: Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2012-12-11 20:01:33 -0800) are available in the git repository at: git://git.infradead.org/battery-2.6.git tags/for-v3.8-merged for you to fetch changes up to 76d8a23b127020472207b281427d3e9f4f1227e4: Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux (2012-12-11 22:15:57 -0800) Alan Cox (1): max17042_battery: Fix missing verify_model_lock() return value check Anton Vorontsov (3): bq2415x_charger: Add Kconfig/Makefile entries bq2415x_charger: Fix style issues Merge git://git.kernel.org/.../torvalds/linux Axel Lin (1): generic-adc-battery: Fix checking return value of request_any_context_irq Dan Carpenter (2): generic-adc-battery: Pointer math issue in gab_probe() ds2782_battery: Fix signedness bug in ds278x_read_reg16() Kim, Milo (3): lp8788-charger: Use consumer device name on setting IIO channels lp8788-charger: Fix wrong ADC conversion lp8788-charger: Fix ADC channel names Marcos Paulo de Souza (2): jz4740-battery: Use devm_kzalloc jz4740-battery: Use devm_request_and_ioremap Pali Rohár (3): power_supply: Add new Nokia RX-51 (N900) power supply battery driver power_supply: Add bq2415x charger driver bq27x00_battery: Fixup nominal available capacity reporting Peter Ujfalusi (1): twl4030_charger: Change TWL4030_MODULE_* ids to TWL_MODULE_* Qing Xu (1): max8925_power: Add support for device-tree initialization Rajanikanth H.V (4): ab8500: Add devicetree support for fuelgauge ab8500: Add devicetree support for btemp ab8500: Add devicetree support for charger ab8500: Add devicetree support for chargalg Ramakrishna Pallala (2): power_supply: Add support for CHARGE_CONTROL_* attributes power_supply: Register power supply for thermal cooling device Documentation/devicetree/bindings/mfd/ab8500.txt | 27 +- Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt | 16 + .../devicetree/bindings/power_supply/ab8500/chargalg.txt | 16 + .../devicetree/bindings/power_supply/ab8500/charger.txt | 25 + Documentation/devicetree/bindings/power_supply/ab8500/fg.txt | 58 + Documentation/power/power_supply_class.txt |3 + arch/arm/boot/dts/dbx5x0.dtsi| 28 +- drivers/mfd/ab8500-core.c| 20 + drivers/power/Kconfig| 23 +- drivers/power/Makefile |4 +- drivers/power/ab8500_bmdata.c| 521 + drivers/power/ab8500_btemp.c | 77 +- drivers/power/ab8500_charger.c | 84 +- drivers/power/ab8500_fg.c| 82 +- drivers/power/abx500_chargalg.c | 56 +- drivers/power/bq2415x_charger.c | 1670 drivers/power/bq27x00_battery.c |8 + drivers/power/ds2782_battery.c |4 +- drivers/power/generic-adc-battery.c |5 +- drivers/power/jz4740-battery.c | 45 +- drivers/power/lp8788-charger.c | 75 +- drivers/power/max17042_battery.c |3 +- drivers/power/max8925_power.c| 51 +- drivers/power/power_supply_core.c| 96 ++ drivers/power/power_supply_sysfs.c |2 + drivers/power/rx51_battery.c | 251 + drivers/power/twl4030_charger.c | 12 +- include/linux/mfd/abx500.h | 34 +-
Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
On Tue, Dec 11, 2012 at 11:14 PM, Yinghai Lu wrote: > > please check draft version for early_memremap version for microcode... > > 1. make find_cpio take map/unmap function pointer, and use that to set > sliding window. > 2. clean the end to size in some function to fix -1 offset > 3. update_mc_saved to change back to __va for ap etc and after > initrd_relocation. > > should use this one on top of early_ioremap_head64.patch that i sent > it out this afternoon. > this one pass the test on 64bit without microcode cpio with initrd... Fenghua, can you check it on 64 config with more than 4g RAM ? on top of tip/x86/microcode and early_ioremap_head64.patch Thanks Yinghai fix_microcode_v2.patch Description: Binary data
Re: Read starvation by sync writes
On Wed 12-12-12 15:18:21, Dave Chinner wrote: > On Wed, Dec 12, 2012 at 03:31:37AM +0100, Jan Kara wrote: > > On Tue 11-12-12 16:44:15, Jeff Moyer wrote: > > > Jan Kara writes: > > > > > > > Hi, > > > > > > > > I was looking into IO starvation problems where streaming sync writes > > > > (in > > > > my case from kjournald but DIO would look the same) starve reads. This > > > > is > > > > because reads happen in small chunks and until a request completes we > > > > don't > > > > start reading further (reader reads lots of small files) while writers > > > > have > > > > plenty of big requests to submit. Both processes end up fighting for IO > > > > requests and writer writes nr_batching 512 KB requests while reader > > > > reads > > > > just one 4 KB request or so. Here the effect is magnified by the fact > > > > that > > > > the drive has relatively big queue depth so it usually takes longer than > > > > BLK_BATCH_TIME to complete the read request. The net result is it takes > > > > close to two minutes to read files that can be read under a second > > > > without > > > > writer load. Without the big drive's queue depth, results are not ideal > > > > but > > > > they are bearable - it takes about 20 seconds to do the reading. And for > > > > comparison, when writer and reader are not competing for IO requests > > > > (as it > > > > happens when writes are submitted as async), it takes about 2 seconds to > > > > complete reading. > > > > > > > > Simple reproducer is: > > > > > > > > echo 3 >/proc/sys/vm/drop_caches > > > > dd if=/dev/zero of=/tmp/f bs=1M count=1 & > > > > sleep 30 > > > > time cat /etc/* 2>&1 >/dev/null > > > > killall dd > > > > rm /tmp/f > > > > > > This is a buffered writer. How does it end up that you are doing all > > > synchronous write I/O? Also, you forgot to mention what file system you > > > were using, and which I/O scheduler. > > So IO scheduler is CFQ, filesystem is ext3 - which is the culprit why IO > > ends up being synchronous - in ext3 in data=ordered mode kjournald often > > ends > > up submitting all the data to disk and it can do it as WRITE_SYNC if > > someone is > > waiting for transaction commit. In theory this can happen with AIO DIO > > writes or someone running fsync on a big file as well. Although when I > > tried this now, I wasn't able to create as big problem as kjournald does > > (a kernel thread submitting huge linked list of buffer heads in a tight loop > > is hard to beat ;). Hum, so maybe just adding some workaround in kjournald > > so that it's not as aggressive will solve the real world cases as well... > > Maybe kjournald shouldn't be using WRITE_SYNC for those buffers? I > mean, if there is that many of them then it's really a batch > submission an dthe latency of a single buffer IO is really > irrelevant to the rate at which the buffers are flushed to disk Yeah, the idea why kjournald uses WRITE_SYNC is that we know someone is waiting for transaction commit and that's pretty much definition of what WRITE_SYNC means. Kjournald could keep using WRITE if we see we have tens of megabytes of data in the commit. I'm just afraid that e.g. a process doing large DIO overwrite (which is WRITE_SYNC as well) could starve kjournald doing async IO and thus would effectively block any other fs activity. Hum, maybe if DIO wasn't using WRITE_SYNC (one could make similar argument there as with kjournald). But then the definition of what WRITE_SYNC should mean starts to be pretty foggy. Honza -- Jan Kara 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/
Re: [PATCH v3 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
Hi Simon, On 12/12/2012 05:29 PM, Simon Jeons wrote: Thanks for your clarify. Enable PAE on x86 32bit kernel, 8G memory, movablecore=6.5G Could you please provide more info ? Such as the whole kernel commondline. And did this happen after you applied these patches ? What is the output without these patches ? Thanks. :) [0.00] 8304MB HIGHMEM available. [0.00] 885MB LOWMEM available. [0.00] mapped low ram: 0 - 375fe000 [0.00] low ram: 0 - 375fe000 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x375fdfff] [0.00] HighMem [mem 0x375fe000-0x3e5f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009cfff] [0.00] node 0: [mem 0x0010-0x1fff] [0.00] node 0: [mem 0x2020-0x3fff] [0.00] node 0: [mem 0x4020-0xb69cbfff] [0.00] node 0: [mem 0xb6a46000-0xb6a47fff] [0.00] node 0: [mem 0xb6b1c000-0xb6cf] [0.00] node 0: [mem 0x-0x3e5f] [0.00] On node 0 totalpages: 2051391 [0.00] free_area_init_node: node 0, pgdat c0c26a80, node_mem_map f19de200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3949 pages, LIFO batch:0 [0.00] Normal zone: 1740 pages used for memmap [0.00] Normal zone: 220466 pages, LIFO batch:31 [0.00] HighMem zone: 16609 pages used for memmap [0.00] HighMem zone: 1808595 pages, LIFO batch:31 Why zone movable disappear? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, 2012-12-12 at 09:42 +, Jan Beulich wrote: > >>> On 11.12.12 at 21:50, Olaf Hering wrote: > > backend_changed might be called multiple times, which will leak > > be->mode. Make sure it will be called only once. Remove some unneeded > > checks. Also the be->mode string was leaked, release the memory on > > device shutdown. > > So did I miss some discussion here? I haven't seen any > confirmation of this function indeed being supposed to be called > just once. > > Also, as said previously, if indeed it is to be called just once, > removing the watch during/after the first invocation would seem > to be the more appropriate thing to do. The watch fires (often needlessly) when you first register it so in the common case it is going to be called twice. Of course that first time should abort early on so perhaps that's a moot point. Ian. -- 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]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
Hi,
ok, let's start.
On Wed, Dec 12, 2012 at 06:20:33PM +0800, fangxiaozhi 00110321 wrote:
> From: fangxiaozhi
>
> 1. To optimize the match rules for the Huawei USB storage devices. Avoid to
> load USB storage driver for modem interface with Huawei devices.
> 2. Add to support new switch command for new Huawei USB dongles.
first of all you're doing a whole lot more than these two things and
your commit log is a lot over 72 characters.
> Signed-off-by: fangxiaozhi
> -
> diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
> linux-3.7/drivers/usb/storage/initializers.c
> --- linux-3.7_bak/drivers/usb/storage/initializers.c 2012-12-11
> 09:56:11.0 +0800
> +++ linux-3.7/drivers/usb/storage/initializers.c 2012-12-12
> 16:26:53.0 +0800
> @@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
> return 0;
> }
>
> -/* This places the HUAWEI E220 devices in multi-port mode */
> -int usb_stor_huawei_e220_init(struct us_data *us)
> +/* This places the HUAWEI usb dongles in multi-port mode */
> +static int usb_stor_huawei_feature_init(struct us_data *us)
renaming this function doesn't look like is part of $SUBJECT
> {
> int result;
>
> @@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
> US_DEBUGP("Huawei mode set result is %d\n", result);
> return 0;
> }
> +
> +/*Find the supported Huawei USB dongles*/
comment style is wrong, you miss a space after /* and before */
> +static int usb_stor_huawei_dongles_pid(struct us_data *us)
> +{
> + int ret = 0;
> + struct usb_interface_descriptor *idesc = NULL;
could add a blank line here to aid readability
> + idesc = >pusb_intf->cur_altsetting->desc;
> + if (idesc != NULL && idesc->bInterfaceNumber == 0) {
> + if ((us->pusb_dev->descriptor.idProduct >= 0x1401 &&
> us->pusb_dev->descriptor.idProduct <= 0x1600)
> + || (us->pusb_dev->descriptor.idProduct
> >= 0x1c02 && us->pusb_dev->descriptor.idProduct <= 0x2202)
> + || (us->pusb_dev->descriptor.idProduct
> == 0x1001)
> + || (us->pusb_dev->descriptor.idProduct
> == 0x1003)
> + || (us->pusb_dev->descriptor.idProduct
> == 0x1004)) {
clearly you didn't even run checkpatch.pl here.
> + if (us->pusb_dev->descriptor.idProduct >=
> 0x1501
^
trailing
whitespace
> + && us->pusb_dev->descriptor.idProduct
> <= 0x1504) {
> + ret = 0;
ret is already initialized to zero, why do it again ?
> + } else {
> + ret = 1;
> + }
> + }
> + }
> + return ret;
> +}
> +
> +static int usb_stor_huawei_scsi_init(struct us_data *us)
> +{
> + int result = 0;
> + int act_len = 0;
> + unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00,
> 0x00,
^
trailing
whitespace
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00};
> + struct bulk_cb_wrap bcbw = {0};
> + bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
> + bcbw.Tag = 0;
> + bcbw.DataTransferLength = cpu_to_le32(0);
> + bcbw.Flags = bcbw.Lun = 0;
> + bcbw.Length = sizeof(rewind_cmd);
> + memset(bcbw.CDB, 0, sizeof(bcbw.CDB));
the entire structure is already initialized to zero, no ?
> + memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
> +
> + result = usb_stor_bulk_transfer_buf (us, us->send_bulk_pipe, , 31,
> _len);
> + US_DEBUGP("usb_stor_bulk_transfer_buf performing result is %d, transfer
> the actual length=%d\n", result, act_len);
waay over 80-characters. Run checkpatch.pl
> + return result;
> +}
> +
> +int usb_stor_huawei_init(struct us_data *us)
> +{
> + int result = 0;
> + if(usb_stor_huawei_dongles_pid(us)) {
> + if ((us->pusb_dev->descriptor.idProduct >= 0x1446)) {
> + result = usb_stor_huawei_scsi_init(us);
> + } else {
> + result = usb_stor_huawei_feature_init(us);
> + }
read Documentation/CodingStyle, you'll see this is wrong.
> + }
> + return result;
> +}
> diff -uprN
Re: [Xen-devel] [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, Dec 12, Ian Campbell wrote: > On Wed, 2012-12-12 at 09:42 +, Jan Beulich wrote: > > >>> On 11.12.12 at 21:50, Olaf Hering wrote: > > > backend_changed might be called multiple times, which will leak > > > be->mode. Make sure it will be called only once. Remove some unneeded > > > checks. Also the be->mode string was leaked, release the memory on > > > device shutdown. > > > > So did I miss some discussion here? I haven't seen any > > confirmation of this function indeed being supposed to be called > > just once. > > > > Also, as said previously, if indeed it is to be called just once, > > removing the watch during/after the first invocation would seem > > to be the more appropriate thing to do. > > The watch fires (often needlessly) when you first register it so in the > common case it is going to be called twice. Of course that first time > should abort early on so perhaps that's a moot point. The current code handles that, if a property does not exist the function will exit early. Olaf -- 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/hugetlb: create hugetlb cgroup file in hugetlb_init
On 2012/12/12 18:19, Michal Hocko wrote:
> On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
>> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
>> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
>> system will boot fail.
>>
>> This failure is caused by following code path:
>> setup_hugepagesz
>> hugetlb_add_hstate
>> hugetlb_cgroup_file_init
>> cgroup_add_cftypes
>> kzalloc <--slab is *not available* yet
>>
>> For this path, slab is not available yet, so memory allocated will be
>> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
>>
>> So I move hugetlb_cgroup_file_init() into hugetlb_init().
>
> I do not think this is a good idea. hugetlb_init is in __init section as
> well so what guarantees that the slab is initialized by then? Isn't this
> just a good ordering that makes this working?
Hi Michal,
__initcall functions will be called in
start_kernel()
rest_init() // -> slab is already
kernel_init()
kernel_init_freeable()
do_basic_setup()
do_initcalls()
and setup_hugepagesz() will be called in
start_kernel()
parse_early_param() // -> before mm_init() -> kmem_cache_init()
Is this right?
Thanks
Xishi Qiu
> Shouldn't this be rather placed in hugetlb_cgroup_create?
>
>> Signed-off-by: Jianguo Wu
>> Signed-off-by: Jiang Liu
>> ---
>> include/linux/hugetlb_cgroup.h |7 ++-
>> mm/hugetlb.c | 11 +--
>> mm/hugetlb_cgroup.c| 23 +--
>> 3 files changed, 24 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
>> index d73878c..5bb9c28 100644
>> --- a/include/linux/hugetlb_cgroup.h
>> +++ b/include/linux/hugetlb_cgroup.h
>> @@ -62,7 +62,7 @@ extern void hugetlb_cgroup_uncharge_page(int idx, unsigned
>> long nr_pages,
>> struct page *page);
>> extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
>> struct hugetlb_cgroup *h_cg);
>> -extern int hugetlb_cgroup_file_init(int idx) __init;
>> +extern void hugetlb_cgroup_file_init(void) __init;
>> extern void hugetlb_cgroup_migrate(struct page *oldhpage,
>> struct page *newhpage);
>>
>> @@ -111,10 +111,7 @@ hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long
>> nr_pages,
>> return;
>> }
>>
>> -static inline int __init hugetlb_cgroup_file_init(int idx)
>> -{
>> -return 0;
>> -}
>> +static inline void __init hugetlb_cgroup_file_init() {}
>>
>> static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
>>struct page *newhpage)
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 1ef2cd4..a30da48 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1906,14 +1906,12 @@ static int __init hugetlb_init(void)
>> default_hstate.max_huge_pages = default_hstate_max_huge_pages;
>>
>> hugetlb_init_hstates();
>> -
>> gather_bootmem_prealloc();
>> -
>> report_hugepages();
>>
>> hugetlb_sysfs_init();
>> -
>> hugetlb_register_all_nodes();
>> +hugetlb_cgroup_file_init();
>>
>> return 0;
>> }
>> @@ -1943,13 +1941,6 @@ void __init hugetlb_add_hstate(unsigned order)
>> h->next_nid_to_free = first_node(node_states[N_HIGH_MEMORY]);
>> snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
>> huge_page_size(h)/1024);
>> -/*
>> - * Add cgroup control files only if the huge page consists
>> - * of more than two normal pages. This is because we use
>> - * page[2].lru.next for storing cgoup details.
>> - */
>> -if (order >= HUGETLB_CGROUP_MIN_ORDER)
>> -hugetlb_cgroup_file_init(hugetlb_max_hstate - 1);
>>
>> parsed_hstate = h;
>> }
>> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
>> index a3f358f..284cb68 100644
>> --- a/mm/hugetlb_cgroup.c
>> +++ b/mm/hugetlb_cgroup.c
>> @@ -340,7 +340,7 @@ static char *mem_fmt(char *buf, int size, unsigned long
>> hsize)
>> return buf;
>> }
>>
>> -int __init hugetlb_cgroup_file_init(int idx)
>> +static void __init __hugetlb_cgroup_file_init(int idx)
>> {
>> char buf[32];
>> struct cftype *cft;
>> @@ -382,7 +382,26 @@ int __init hugetlb_cgroup_file_init(int idx)
>>
>> WARN_ON(cgroup_add_cftypes(_subsys, h->cgroup_files));
>>
>> -return 0;
>> +return;
>> +}
>> +
>> +void __init hugetlb_cgroup_file_init()
>> +{
>> +struct hstate *h;
>> +int idx;
>> +
>> +idx = 0;
>> +for_each_hstate(h) {
>> +/*
>> + * Add cgroup control files only if the huge page consists
>> + * of more than two normal pages. This is because we use
>> + * page[2].lru.next for
Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
On Wed, 12 Dec 2012 18:20:33 +0800 fangxiaozhi 00110321 wrote: > From: fangxiaozhi > > 1. To optimize the match rules for the Huawei USB storage devices. Avoid to > load USB storage driver for modem interface with Huawei devices. > 2. Add to support new switch command for new Huawei USB dongles. This prevents people getting access to the storage device if they want. It also means you need to change kernel not simply a user space file to add support for different new identifiers. So it seems a large step backwards to me. Why not just teach udev the new switch command then it'll work as a udev update on all sorts of existing kernels as well as being the kind of small safe change you can get into the entprise distributions ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] MCE: fix an error of mce_bad_pages statistics
On 2012/12/12 18:25, Borislav Petkov wrote: > On Wed, Dec 12, 2012 at 11:35:33AM +0800, Xishi Qiu wrote: >> Since MCE is an x86 concept, and this code is in mm/, it would be >> better to use the name num_poisoned_pages instead of mce_bad_pages. >> >> Signed-off-by: Xishi Qiu >> Signed-off-by: Jiang Liu >> Signed-off-by: Borislav Petkov > > This is not how Signed-of-by: works. You should read > Documentation/SubmittingPatches (yes, the whole of it) about how that > whole S-o-b thing works. > > And, FWIW, it should be "Suggested-by: Borislav Petkov " > > Thanks. > Sorry, I will pay more attention to it next time, thank you. :> -- 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] avoid entropy starvation due to stack protection
On 11.12.2012 13:33:04, +0100, Stephan Mueller wrote:
Hi,
I just noticed a misuse of a variable in my initial patch
> + if (r->limit == 2 && r->entropy_count >= r->poolinfo->poolwords)
Instead of r->entropy_count, the code should use entropy_count.
Please see new patch attached.
Signed-off-by: Stephan Mueller
---
diff -purN linux-3.6/drivers/char/random.c
linux-3.6-sm/drivers/char/random.c
--- linux-3.6/drivers/char/random.c2012-10-01 01:47:46.0 +0200
+++ linux-3.6-sm/drivers/char/random.c2012-12-12 11:06:23.443403746
+0100
@@ -404,11 +404,12 @@ static bool debug;
module_param(debug, bool, 0644);
#define DEBUG_ENT(fmt, arg...) do { \
if (debug) \
-printk(KERN_DEBUG "random %04d %04d %04d: " \
+printk(KERN_DEBUG "random %04d %04d %04d %04d: " \
fmt,\
input_pool.entropy_count,\
blocking_pool.entropy_count,\
nonblocking_pool.entropy_count,\
+kernel_pool.entropy_count,\
## arg); } while (0)
#else
#define DEBUG_ENT(fmt, arg...) do {} while (0)
@@ -428,7 +429,11 @@ struct entropy_store {
__u32 *pool;
const char *name;
struct entropy_store *pull;
-int limit;
+int limit;/* 0 -> no limit when extracting data (nonblocking)
+ * 1 -> limit extracted data based on entropy counter
+ * 2 -> no limit when extracting data and disabling
+ * use of seed source once pool has full entropy
+ */
/* read-write data: */
spinlock_t lock;
@@ -443,6 +448,7 @@ struct entropy_store {
static __u32 input_pool_data[INPUT_POOL_WORDS];
static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS];
+static __u32 kernel_pool_data[OUTPUT_POOL_WORDS];
static struct entropy_store input_pool = {
.poolinfo = _table[0],
@@ -469,6 +475,15 @@ static struct entropy_store nonblocking_
.pool = nonblocking_pool_data
};
+static struct entropy_store kernel_pool = {
+.poolinfo = _table[1],
+.name = "kernel",
+.limit = 2,
+.pull = _pool,
+.lock = __SPIN_LOCK_UNLOCKED(_pool.lock),
+.pool = kernel_pool_data
+};
+
static __u32 const twist_table[8] = {
0x, 0x3b6e20c8, 0x76dc4190, 0x4db26158,
0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };
@@ -613,6 +628,15 @@ retry:
r->initialized = 1;
}
+/*
+ * An entropy pool that is marked with limit 2 will only be
+ * seeded by the input_pool until it is full of entropy.
+ */
+if (r->limit == 2 && entropy_count >= r->poolinfo->poolwords)
+{
+r->pull = NULL;
+}
+
trace_credit_entropy_bits(r->name, nbits, entropy_count,
r->entropy_total, _RET_IP_);
@@ -652,6 +676,8 @@ void add_device_randomness(const void *b
mix_pool_bytes(_pool, , sizeof(time), NULL);
mix_pool_bytes(_pool, buf, size, NULL);
mix_pool_bytes(_pool, , sizeof(time), NULL);
+mix_pool_bytes(_pool, buf, size, NULL);
+mix_pool_bytes(_pool, , sizeof(time), NULL);
}
EXPORT_SYMBOL(add_device_randomness);
@@ -820,7 +846,7 @@ static void xfer_secondary_pool(struct e
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
/* If we're limited, always leave two wakeup worth's BITS */
-int rsvd = r->limit ? 0 : random_read_wakeup_thresh/4;
+int rsvd = r->limit == 1 ? 0 : random_read_wakeup_thresh/4;
int bytes = nbytes;
/* pull at least as many as BYTES as wakeup BITS */
@@ -868,7 +894,7 @@ static size_t account(struct entropy_sto
nbytes = 0;
} else {
/* If limited, never pull more than available */
-if (r->limit && nbytes + reserved >= r->entropy_count / 8)
+if (r->limit == 1 && nbytes + reserved >= r->entropy_count / 8)
nbytes = r->entropy_count/8 - reserved;
if (r->entropy_count / 8 >= nbytes + reserved)
@@ -883,7 +909,7 @@ static size_t account(struct entropy_sto
}
DEBUG_ENT("debiting %d entropy credits from %s%s\n",
- nbytes * 8, r->name, r->limit ? "" : " (unlimited)");
+ nbytes * 8, r->name, r->limit == 1 ? "" : " (unlimited)");
spin_unlock_irqrestore(>lock, flags);
@@ -1037,6 +1063,21 @@ void get_random_bytes(void *buf, int nby
EXPORT_SYMBOL(get_random_bytes);
/*
+ * This function exports the kernel random number pool. It is of
+ * slightly less quality than the nonblocking_pool exported by
+ * the function get_random_bytes because once it is filled completely
+ * with entropy, it is never seeded again. Yet, the quality of the
+ * random bytes depend on the SHA-1 hash and should be sufficient
+ * for purposes like ASLR and stack protection.
+ */
+void get_random_kernel_bytes(void *buf, int nbytes)
+{
+extract_entropy(_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_random_kernel_bytes);
+
+
+/*
* This function will use the architecture-specific hardware
Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
On Wed, Dec 12, 2012 at 12:44:33AM +0100, Rafael J. Wysocki wrote: > On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote: > > On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote: > > > Boris, please send the output of "lspci -vvv' from that box. > > > > Attached. > > So the audio is a Root Complex Integrated Endpoind and there shouldn't be > any problems with it related to PCIe ports power management. > > It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN > to indicate that it actually can't be suspended (if my understanding the > code is correct). However, it shouldn't do that, because that causes > the runtime PM core to repeat the attempts. It rather should implement > a .runtime_idle() callback returning an error code instead. > > Those messages are just noise, though. Adding author of this (b8dfc4624162c0547d7f36a9df48da2d9b4bd58a). Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/2] kernel BUG at mm/huge_memory.c:212!
On Wed, Dec 12, 2012 at 01:36:36PM +0800, Bob Liu wrote: > On Mon, Dec 3, 2012 at 9:02 PM, Jiri Slaby wrote: > > On 11/30/2012 04:03 PM, Kirill A. Shutemov wrote: > >> From: "Kirill A. Shutemov" > >> > >> Hi Jiri, > >> > >> Sorry for late answer. It took time to reproduce and debug the issue. > >> > >> Could you test two patches below by thread. I expect it to fix both > >> issues: put_huge_zero_page() and Bad rss-counter state. > > > > Hi, yes, since applying the patches on the last Thu, it didn't recur. > > > >> Kirill A. Shutemov (2): > >> thp: fix anononymous page accounting in fallback path for COW of HZP > >> thp: avoid race on multiple parallel page faults to the same page > >> > >> mm/huge_memory.c | 30 +- > >> 1 file changed, 25 insertions(+), 5 deletions(-) > > > > I still saw this bug on 3.7.0-rc8, but it's hard to reproduce it. > It appears only once. I guess the patch you've posted fixes the issue, right? It's useful to enable debug_cow to test fallback path: echo 1 > /sys/kernel/mm/transparent_hugepage/debug_cow -- Kirill A. Shutemov signature.asc Description: Digital signature
Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
At Wed, 12 Dec 2012 00:44:33 +0100,
Rafael J. Wysocki wrote:
>
> On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
> > On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
> > > Boris, please send the output of "lspci -vvv' from that box.
> >
> > Attached.
>
> So the audio is a Root Complex Integrated Endpoind and there shouldn't be
> any problems with it related to PCIe ports power management.
>
> It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
> to indicate that it actually can't be suspended (if my understanding the
> code is correct). However, it shouldn't do that, because that causes
> the runtime PM core to repeat the attempts. It rather should implement
> a .runtime_idle() callback returning an error code instead.
Borislav, could you test the patch below?
thanks,
Takashi
---
From: Takashi Iwai
Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
The runtime_idle callback is the right place to check the suspend
capability, but currently we do it wrongly in the runtime_suspend
callback. This leads to a kernel error message like:
pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel]
returns -11
and the runtime PM core would even repeat the attempts.
Reported-by: Borislav Petkov
Cc: [v3.7]
Signed-off-by: Takashi Iwai
---
sound/pci/hda/hda_intel.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1da8a5c..0f3d3db 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2691,10 +2691,6 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;
- if (!power_save_controller ||
- !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
- return -EAGAIN;
-
azx_stop_chip(chip);
azx_clear_irq_pending(chip);
return 0;
@@ -2709,12 +2705,25 @@ static int azx_runtime_resume(struct device *dev)
azx_init_chip(chip, 1);
return 0;
}
+
+static int azx_runtime_idle(struct device *dev)
+{
+ struct snd_card *card = dev_get_drvdata(dev);
+ struct azx *chip = card->private_data;
+
+ if (!power_save_controller ||
+ !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
+ return -EBUSY;
+
+ return 0;
+}
+
#endif /* CONFIG_PM_RUNTIME */
#ifdef CONFIG_PM
static const struct dev_pm_ops azx_pm = {
SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
- SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, NULL)
+ SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume,
azx_runtime_idle)
};
#define AZX_PM_OPS _pm
--
1.8.0.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 0/3] gpio: twl4030: Correct status reporting for outputs
Hi Grant, On 12/07/2012 09:09 AM, Linus Walleij wrote: > On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi wrote: > >> As Grant commneted on the first version: >> https://lkml.org/lkml/2012/12/5/53 >> >> Introduce bitfields to cache the directionand output status of the pins so we >> can report them correctly. >> To do this I did some cleanup within the driver to get rid of the global >> variables and moved them under a private structure, changed the locking as >> well >> to protect the bitfield operation. >> As a last patch I added a note that the PWMA/B handling should not be in this >> driver at all. > > This looks good to me: > Acked-by: Linus Walleij > > Since Grant was requesting the changes I'll let him decide to merge. Would you have time to take a look at this set? Thanks, Péter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
This driver makes the time from HID sensors (hubs) which are offering
such available like any other RTC does.
Currently the time can only be read. Setting the time must be done
through sending a report, which currently isn't supported by
hid-sensor-hub. (I've planned to submit patches.)
It is necessary that all values like year, month etc, are send as
8bit values (1 byte each) and all of them in 1 report. Also the
spec HUTRR39b doesn't define the range of the year field, we
tread it as 0 - 99 because that's what most RTCs I know about are
offering.
Signed-off-by: Alexander Holler
---
drivers/rtc/Kconfig | 16 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hid-sensor-time.c | 283 +
3 files changed, 300 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..e0d29b5 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS
This driver can also be built as a module, if so, the module
will be called "rtc-snvs".
+comment "HID Sensor RTC drivers"
+
+config RTC_DRV_HID_SENSOR_TIME
+ tristate "HID Sensor Time"
+ depends on USB_HID
+ select IIO
+ select HID_SENSOR_HUB
+ select HID_SENSOR_IIO_COMMON
+ help
+ Say yes here to build support for the HID Sensors of type Time.
+ This drivers makes such sensors available as RTCs.
+
+ If this driver is compiled as a module, it will be named
+ rtc-hid-sensor-time.
+
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56297f0..9d1658a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o
obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o
obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
+obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
new file mode 100644
index 000..41bc011
--- /dev/null
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -0,0 +1,283 @@
+/*
+ * HID Sensor Time Driver
+ * Copyright (c) 2012, Alexander Holler.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Format: HID-SENSOR-usage_id_in_hex */
+/* Usage ID from spec for Time: 0x2000A0 */
+#define DRIVER_NAME "HID-SENSOR-2000a0" /* must be lowercase */
+
+enum hid_time_channel {
+ CHANNEL_SCAN_INDEX_YEAR,
+ CHANNEL_SCAN_INDEX_MONTH,
+ CHANNEL_SCAN_INDEX_DAY,
+ CHANNEL_SCAN_INDEX_HOUR,
+ CHANNEL_SCAN_INDEX_MINUTE,
+ CHANNEL_SCAN_INDEX_SECOND,
+ TIME_RTC_CHANNEL_MAX,
+};
+
+struct hid_time_state {
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_iio_common common_attributes;
+ struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX];
+ struct rtc_time last_time;
+ spinlock_t lock_last_time;
+ struct completion comp_last_time;
+ struct rtc_time time_buf;
+ struct rtc_device *rtc;
+};
+
+static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX] = {
+ HID_USAGE_SENSOR_TIME_YEAR,
+ HID_USAGE_SENSOR_TIME_MONTH,
+ HID_USAGE_SENSOR_TIME_DAY,
+ HID_USAGE_SENSOR_TIME_HOUR,
+ HID_USAGE_SENSOR_TIME_MINUTE,
+ HID_USAGE_SENSOR_TIME_SECOND,
+};
+
+/* Channel names for verbose error messages */
+static const char * const hid_time_channel_names[TIME_RTC_CHANNEL_MAX] = {
+ "year", "month", "day", "hour", "minute", "second",
+};
+
+/* Callback handler to send event after all samples are received and captured
*/
+static int hid_time_proc_event(struct hid_sensor_hub_device *hsdev,
+ unsigned usage_id, void *priv)
+{
+ unsigned long flags;
+ struct hid_time_state *time_state = platform_get_drvdata(priv);
+
+ spin_lock_irqsave(_state->lock_last_time, flags);
+ time_state->last_time = time_state->time_buf;
+
Re: [PATCH v3 2/3] mtd: devices: elm: Add support for ELM error correction
On 12/10/2012 12:13 PM, Philip, Avinash wrote:
> On Fri, Dec 07, 2012 at 16:07:23, Nori, Sekhar wrote:
>> On 11/29/2012 5:16 PM, Philip, Avinash wrote:
[...]
>>> +struct device *elm_request(enum bch_ecc bch_type)
>>> +{
>>> + struct elm_info *info;
>>> +
>>> + list_for_each_entry(info, _devices, list) {
>>> + if (info && info->dev) {
>>> + info->bch_type = bch_type;
>>> + elm_config(info);
>>> + return info->dev;
>>> + }
>>> + }
>>
>> This will always return the first ELM device probed since you never
>> remove the allocated device from the list.
>
> But now I realized that, there is no mechanism of freeing the requested
> resource.
Right. You essentially want to assign an ELM instance to work with a
given instance of GPMC and that could be done statically too. Just pass
phandle of ELM node in GPMC DT data?
> So I will add mechanism to request ELM module successfully only if ELM
> module is not requested already and add mechanism to free it, on NAND
> driver module unload (loadable module support). This way ELM driver
> can achieve multi instance support.
>
>> I wonder why you really need a list?
>
> The prime motivation for the list is the driver should support multi
> instances of ELM by removing global symbols.
I still think a request/free API is bit too much for something that will
turn out to be a simple 1-to-1 match anyway. Can you please look at the
phandle suggestion above? I am no DT expert, but I think that will work
for your use case.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Mfd: Initial support for Texas Instruments AIC family of CODECs
Initial support for TI's AIC platform and TLV320AIC3262 CODEC device. The AIC platform provides common interface to series of low power audio CODECS. This MFD core driver instantiates subdevices that help in supporting range of features provided by AIC family of devices. Signed-off-by: Mehar Bajwa --- drivers/mfd/Kconfig | 41 +++ drivers/mfd/Makefile|3 + drivers/mfd/tlv320aic3xxx-core.c| 462 +++ drivers/mfd/tlv320aic3xxx-i2c.c | 97 ++ drivers/mfd/tlv320aic3xxx-irq.c | 234 ++ drivers/mfd/tlv320aic3xxx-spi.c | 96 ++ include/linux/mfd/tlv320aic3262-registers.h | 312 ++ include/linux/mfd/tlv320aic3xxx-core.h | 153 + include/linux/mfd/tlv320aic3xxx-registers.h | 75 + 9 files changed, 1473 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/tlv320aic3xxx-core.c create mode 100644 drivers/mfd/tlv320aic3xxx-i2c.c create mode 100644 drivers/mfd/tlv320aic3xxx-irq.c create mode 100644 drivers/mfd/tlv320aic3xxx-spi.c create mode 100644 include/linux/mfd/tlv320aic3262-registers.h create mode 100644 include/linux/mfd/tlv320aic3xxx-core.h create mode 100644 include/linux/mfd/tlv320aic3xxx-registers.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 50bbe88..2ecfbad 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -45,6 +45,47 @@ config MFD_88PM805 components like codec device, headset/Mic device under the corresponding menus. +config MFD_AIC3XXX + bool "Support for AIC3XXX" + select REGMAP + select MFD_CORE + help + Say yes here if you want support for Texas Instruments AIC audio + codec. + You have to select individual I2C or SPI depending on + AIC3XXX interfacing with platform. + +config MFD_AIC3XXX_I2C + bool "Support Texas Instruments AIC3XXX platform with I2C" + select MFD_AIC3XXX + select REGMAP_I2C + depends on I2C + help + Support for the Texas Instruments TLV320AIC3XXX family of audio SoC + core functionality controlled via I2C. This driver provides common + support for accessing the device, additional drivers must be enabled + in order to use the functionality of the device. + +config MFD_AIC3XXX_SPI + bool "Support Texas Instruments AIC3XXX platform with SPI" + select MFD_AIC3XXX + select REGMAP_SPI + depends on SPI_MASTER + help + Support for the Texas Instruments TLV320AIC3XXX family of audio SoC + core functionality controlled via SPI. This driver provides common + support for accessing the device, additional drivers must be enabled + in order to use the functionality of the device. + +config MFD_AIC3262 + bool "Support Texas Instruments AIC3262" + depends on MFD_AIC3XXX + help + If you say yes here you will get support for Texas Instrument + TLV320AIC3262 low power audio SoC. + Addition driver must be enabled to use this in order to use + functionality on device. + config MFD_SM501 tristate "Support for Silicon Motion SM501" ---help--- diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index f2216df..8c97872 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -6,6 +6,9 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o +obj-$(CONFIG_MFD_AIC3XXX) += tlv320aic3xxx-core.o tlv320aic3xxx-irq.o +obj-$(CONFIG_MFD_AIC3XXX_I2C) += tlv320aic3xxx-i2c.o +obj-$(CONFIG_MFD_AIC3XXX_SPI) += tlv320aic3xxx-spi.o obj-$(CONFIG_MFD_SM501)+= sm501.o obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o diff --git a/drivers/mfd/tlv320aic3xxx-core.c b/drivers/mfd/tlv320aic3xxx-core.c new file mode 100644 index 000..6fd151b --- /dev/null +++ b/drivers/mfd/tlv320aic3xxx-core.c @@ -0,0 +1,462 @@ +/* + * tlv320aic3xxx-core.c -- driver for TLV320AIC3XXX + * + * Author: Mukund Navada + * Mehar Bajwa + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include
Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
On Wed 12-12-12 18:44:13, Xishi Qiu wrote: > On 2012/12/12 18:19, Michal Hocko wrote: > > > On Wed 12-12-12 16:25:59, Jianguo Wu wrote: > >> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y > >> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option, > >> system will boot fail. > >> > >> This failure is caused by following code path: > >> setup_hugepagesz > >>hugetlb_add_hstate > >>hugetlb_cgroup_file_init > >>cgroup_add_cftypes > >>kzalloc <--slab is *not available* yet > >> > >> For this path, slab is not available yet, so memory allocated will be > >> failed, and cause WARN_ON() in hugetlb_cgroup_file_init(). > >> > >> So I move hugetlb_cgroup_file_init() into hugetlb_init(). > > > > I do not think this is a good idea. hugetlb_init is in __init section as > > well so what guarantees that the slab is initialized by then? Isn't this > > just a good ordering that makes this working? > > Hi Michal, > > __initcall functions will be called in > start_kernel() > rest_init() // -> slab is already > kernel_init() > kernel_init_freeable() > do_basic_setup() > do_initcalls() > > and setup_hugepagesz() will be called in > start_kernel() > parse_early_param() // -> before mm_init() -> kmem_cache_init() > > Is this right? Yes this is right. I just noticed that kmem_cache_init_late is an __init function as well and didn't realize it is called directly. Sorry about the confusion. Anyway I still think it would be a better idea to move the call into the hugetlb_cgroup_create callback where it is more logical IMO but now that I'm looking at other controllers (blk and kmem.tcp) they all do this from init calls as well. So it doesn't make sense to have hugetlb behave differently. So Acked-by: Michal Hocko Thanks! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
>
>
> This patch is based on an earlier patch by Grant Erickson
> which provided pwm devices using the 'legacy' interface.
>
> This driver instead uses the new framework interface.
I'd prefer some kind of description about the driver here. Also the
subject should be something like:
pwm: Add OMAP support using dual-mode timers
or
pwm: omap: Add PWM support using dual-mode timers
I take this description to mean that OMAP doesn't have dedicated PWM
hardware? Otherwise it might be bad to call this pwm-omap.
Also please use all-caps when referring to PWM devices in prose. A few
other comments inline below.
> Cc: Grant Erickson
> Signed-off-by: NeilBrown
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index ed81720..7df573a 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -85,6 +85,15 @@ config PWM_MXS
> To compile this driver as a module, choose M here: the module
> will be called pwm-mxs.
>
> +config PWM_OMAP
> + tristate "OMAP pwm support"
"OMAP PWM support"
> diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
[...]
> + *The 'id' number for the device encodes the number of the dm timer
> + *to use, and the polarity of the output.
> + *lsb is '1' of active-high, and '0' for active low
> + *remaining bit a timer number and need to be shifted down before use.
I don't know if this is such a good idea. Usually you number platform
devices sequentially, while this would leave gaps in the numbering. I
know that adding platform data may sound a bit like overkill, but I
really think the added clarity and consistency is worth it.
> +#define pr_fmt(fmt) "pwm-omap: " fmt
You don't seem to be using any of the pr_*() logging functions, so this
isn't needed.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define DM_TIMER_LOAD_MIN0xFFFE
> +
> +struct omap_chip {
> + struct platform_device *pdev;
I don't see this field being used anywhere.
> + struct omap_dm_timer*dm_timer;
> + unsigned intpolarity;
The PWM subsystem already has enum pwm_polarity for this.
> + const char *label;
This isn't used anywhere either.
> +
> + unsigned intduty_ns, period_ns;
> + struct pwm_chip chip;
> +};
> +
> +#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
> +
> +#define pwm_dbg(_pwm, msg...) dev_dbg(&(_pwm)->pdev->dev, msg)
This is never used.
> +
> +/**
> + * pwm_calc_value - determines the counter value for a clock rate and period.
Nit: You should either start the sentence with a capital or not
terminate it with a full stop.
> + * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
> + *counter value for.
> + * @ns: The period, in nanoseconds, to computer the counter value for.
"compute"
> + *
> + * Returns the PWM counter value for the specified clock rate and period.
> + */
> +static inline int pwm_calc_value(unsigned long clk_rate, int ns)
> +{
> + const unsigned long nanoseconds_per_second = 10;
Maybe use NSEC_PER_SEC instead?
> + int cycles;
> + __u64 c;
I think for in-kernel use, the custom is to stick with simply u64.
> +
> + c = (__u64)clk_rate * ns;
> + do_div(c, nanoseconds_per_second);
> + cycles = c;
> +
> + return DM_TIMER_LOAD_MIN - cycles;
Can't you just do "DM_TIMER_LOAD_MIN - c" and get rid of the cycles
variable altogether?
> +static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct omap_chip *omap = to_omap_chip(chip);
> + int status = 0;
> +
> + /* Enable the counter--always--before attempting to write its
> + * registers and then set the timer to its minimum load value to
> + * ensure we get an overflow event right away once we start it.
> + */
Block comments should be in the following format:
/*
* foo...
* bar...
*/
> +
> + omap_dm_timer_enable(omap->dm_timer);
> + omap_dm_timer_write_counter(omap->dm_timer, DM_TIMER_LOAD_MIN);
> + omap_dm_timer_start(omap->dm_timer);
> + omap_dm_timer_disable(omap->dm_timer);
So omap_dm_timer_disable() doesn't actually stop the timer? It just
disables the access to the registers?
> + return status;
"return 0;" and drop the status variable.
> +static int omap_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> +int duty_ns, int period_ns)
> +{
> + struct omap_chip *omap = to_omap_chip(chip);
> + int status = 0;
This one can be dropped as well.
> + const bool enable = true;
> + const bool autoreload = true;
> + const bool toggle = true;
> + const int trigger = OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE;
I understand that these extra variables are
[PATCH] x86: Add support for 64bit get_user() on x86-32
From: Ville Syrjälä
Implement __get_user_8() for x86-32. It will return the
64bit result in edx:eax register pair, and ecx is used
to pass in the address and return the error value.
For consistency, change the register assignment for all
other __get_user_x() variants, so that address is passed in
ecx/rcx, the error value is returned in ecx/rcx, and eax/rax
contains the actual value.
This is a partial refresh of a patch [1] by Jamie Lokier from
2004. Only the minimal changes to implement 64bit get_user()
were picked from the original patch.
[1] http://article.gmane.org/gmane.linux.kernel/198823
Cc: Jamie Lokier
Signed-off-by: Ville Syrjälä
---
arch/x86/include/asm/uaccess.h | 17 ++--
arch/x86/kernel/i386_ksyms_32.c |1 +
arch/x86/lib/getuser.S | 82 ++
3 files changed, 69 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 7ccf8d1..3f4387e 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -127,7 +127,7 @@ extern int __get_user_bad(void);
#define __get_user_x(size, ret, x, ptr) \
asm volatile("call __get_user_" #size \
-: "=a" (ret), "=d" (x) \
+: "=c" (ret), "=a" (x) \
: "0" (ptr)) \
/* Careful: we have to cast the result to the type of the pointer
@@ -151,8 +151,11 @@ extern int __get_user_bad(void);
* On error, the variable @x is set to zero.
*/
#ifdef CONFIG_X86_32
-#define __get_user_8(__ret_gu, __val_gu, ptr) \
- __get_user_x(X, __ret_gu, __val_gu, ptr)
+#define __get_user_8(ret, x, ptr)\
+ asm volatile("call __get_user_8" \
+: "=c" (ret), "=A" (x) \
+: "0" (ptr)) \
+
#else
#define __get_user_8(__ret_gu, __val_gu, ptr) \
__get_user_x(8, __ret_gu, __val_gu, ptr)
@@ -162,6 +165,7 @@ extern int __get_user_bad(void);
({ \
int __ret_gu; \
unsigned long __val_gu; \
+ unsigned long long __val_gu8; \
__chk_user_ptr(ptr);\
might_fault(); \
switch (sizeof(*(ptr))) { \
@@ -175,13 +179,16 @@ extern int __get_user_bad(void);
__get_user_x(4, __ret_gu, __val_gu, ptr); \
break; \
case 8: \
- __get_user_8(__ret_gu, __val_gu, ptr); \
+ __get_user_8(__ret_gu, __val_gu8, ptr); \
break; \
default:\
__get_user_x(X, __ret_gu, __val_gu, ptr); \
break; \
} \
- (x) = (__typeof__(*(ptr)))__val_gu; \
+ if (sizeof(*(ptr)) == 8)\
+ (x) = (__typeof__(*(ptr)))__val_gu8;\
+ else\
+ (x) = (__typeof__(*(ptr)))__val_gu; \
__ret_gu; \
})
diff --git a/arch/x86/kernel/i386_ksyms_32.c b/arch/x86/kernel/i386_ksyms_32.c
index 9c3bd4a..0fa6912 100644
--- a/arch/x86/kernel/i386_ksyms_32.c
+++ b/arch/x86/kernel/i386_ksyms_32.c
@@ -26,6 +26,7 @@ EXPORT_SYMBOL(csum_partial_copy_generic);
EXPORT_SYMBOL(__get_user_1);
EXPORT_SYMBOL(__get_user_2);
EXPORT_SYMBOL(__get_user_4);
+EXPORT_SYMBOL(__get_user_8);
EXPORT_SYMBOL(__put_user_1);
EXPORT_SYMBOL(__put_user_2);
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index 156b9c8..38afef0 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -14,12 +14,11 @@
/*
* __get_user_X
*
- * Inputs: %[r|e]ax contains the address.
- * The register is modified, but all changes are undone
- * before returning because the C code doesn't know about it.
+ * Inputs: %[r|e]cx contains the address.
*
- * Outputs:%[r|e]ax is error code (0 or -EFAULT)
- * %[r|e]dx contains zero-extended value
+ * Outputs:%[r|e]cx is error code (0 or -EFAULT)
+ * %[r|e]ax contains zero-extended value
+ *
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson wrote: > Hi Javier, > > On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: >> On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas >> wrote: >>> IGEP technology devices are TI OMAP3 SoC based industrial embedded >>> and computer-on-module boards. This patch-set adds initial device >>> tree support for these devices. >>> >>> The device trees allows to boot from an MMC and are working all the >>> components that already have device tree support on OMAP3 SoCs: >>> >>> - MMC/SD >>> - UARTs >>> - GPIO LEDs >>> - TWL4030 codec audio >>> - pinmux/pinconf pinctrl >>> >>> Some peripheral are still not working such as Flash storage and >>> Ethernet but support for these will also be included once the >>> OMAP GPMC device tree binding patches land on mainline. >>> >>> This is a v3 of the patch-set that solves issues pointed out by >>> Enric Balletbo and Benoit Cousson. >>> >>> The patch-set is composed of the following patches: >>> >>> [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices >>> [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board >>> [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module >>> >>> Best regards, >>> Javier >>> -- >> >> Hi Benoit and Tony, >> >> Any comments on these? > > Nope, that's fine. I'll applied the series for 3.9. > > Thanks, > Benoit > > Great, thanks a lot for! Best regards, Javier -- 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] sched: rt: fix selecting runqueue for task to be pushed
On Wed, Dec 12, 2012 at 10:46 AM, Steven Rostedt wrote: > On Tue, 2012-12-11 at 20:54 -0500, Steven Rostedt wrote: > >> I'm actually thinking that that test should always fail. The >> cpupri_find() does a scan of all priorities up to but not including the >> current task's priority. If cpupri_find() finds a mask, it means that it >> found CPUs that are running only tasks of lower priority than the task >> we are checking. Which means, it should never include the task's CPU, as >> that CPU should have a higher priority than what is being returned by >> lowest_mask. If it can't find a set of CPUs of lower priority, it should >> return false, and the find_lowest_rq() should exit. >> >> I'll add a WARN_ON_ONCE() there, and see if I can trigger it. :-/ > > Ah, for select_task_rq_rt() it can get that CPU, because it's called in > the wakeup path before the task is added into the CPUs priority. And we > definitely want the current CPU in that case. > Hm ... the latency of the woken task increases iff we overload its runqueue, no? Hillf -- 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] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(>mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, _uV, _uV);
if (ret < 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator->min_uV;
+ old_max_uV = regulator->max_uV;
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;
ret = regulator_check_consumers(rdev, _uV, _uV);
if (ret < 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret < 0)
+ goto out2;
+
out:
mutex_unlock(>mutex);
return ret;
+out2:
+ regulator->min_uV = old_min_uV;
+ regulator->max_uV = old_max_uV;
+ mutex_unlock(>mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
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 v2 0/3] gpio: twl4030: Correct status reporting for outputs
On Wed, Dec 12, 2012 at 11:12 AM, Peter Ujfalusi wrote: > Hi Grant, > > On 12/07/2012 09:09 AM, Linus Walleij wrote: >> On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi >> wrote: >> >>> As Grant commneted on the first version: >>> https://lkml.org/lkml/2012/12/5/53 >>> >>> Introduce bitfields to cache the directionand output status of the pins so >>> we >>> can report them correctly. >>> To do this I did some cleanup within the driver to get rid of the global >>> variables and moved them under a private structure, changed the locking as >>> well >>> to protect the bitfield operation. >>> As a last patch I added a note that the PWMA/B handling should not be in >>> this >>> driver at all. >> >> This looks good to me: >> Acked-by: Linus Walleij >> >> Since Grant was requesting the changes I'll let him decide to merge. > > Would you have time to take a look at this set? I will take a look at it this week, but I cannot pick it up for v3.8 unless it is a regression bug fix from v3.6. It will have to wait for v3.9 and it can be merged into linux-next after the v3.8 merge window closes. g. -- 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] regulator: core: if voltage scaling fails, restore original
And after a second look it's clear what's going on:
[...]
[5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV
[5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[5.590332] cpu cpu0: omap_target: unable to scale voltage up.
[1]
[5.596649] notification 1 of frequency transition to 30 kHz
[5.603179] FREQ: 30 - CPU: 0
[5.606597] governor: change or update limits
[5.611572] __cpufreq_governor for CPU 0, event 3
[5.616699] setting to 80 kHz because of event 3
[5.622039] target for CPU 0: 80 kHz, relation 1
[5.627441] request for target 80 kHz (relation: 1) for cpu 0
[5.634063] target is 2 (80 kHz, 2)
[5.638183] notification 0 of frequency transition to 80 kHz
[5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV
[2]
[hangs here]
first time[1] it tries to ramp up frequency (and thus voltage),
regulator_set_voltage() returns an error and we exit:
omap-cpufreq.c::omap_target():
...
dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n",
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
if (mpu_reg && (freqs.new > freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
__func__);
freqs.new = freqs.old;
goto done;
}
}
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
...
but inside regulator_set_voltage(), we save the new regulator voltage before
actually ramping up:
core.c::regulator_set_voltage():
...
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;
ret = regulator_check_consumers(rdev, _uV, _uV);
if (ret < 0)
goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); <-- ERROR!!!
if (ret < 0)
goto out2;
...
and by the time we try to change frequency again[2], regulator_set_voltage()
is a noop because it thinks we are already at the desired voltage:
core.c::regulator_set_voltage():
...
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
*/
if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
goto out;
...
and as a consequence, in omap_target(), we call clk_set_rate() with
the wrong voltage.
The attached patch restore the original regulator voltage values in case
of an error.
CCing stable@ since it predates 2.6.38rc1 when the noop optimization was
introduced:
commit 95a3c23ae620c1b4c499746e70f4034bdc067737
Author: Mark Brown
Date: Thu Dec 16 15:49:37 2010 +
regulator: Optimise out noop voltage changes
Paolo Pisati (1):
regulator: core: if voltage scaling fails, restore original voltage
values
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/pinctrl/pinctrl-at91.c: convert kfree to devm_kfree
On 11:58 Tue 11 Dec , Julia Lawall wrote:
> From: Julia Lawall
>
> The function at91_dt_node_to_map is ultimately called by the function
> pinctrl_get, which is an exported function. Since it is possible that this
> function is not called from within a probe function, for safety, the kfree
> is converted to a devm_kfree, to both free the data and remove it from the
> device in a failure situation.
>
> A newline is added in the call to devm_kfree to avoid exceeding the 80
> character limit.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/pinctrl/pinctrl-at91.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index c5e7571..0da8a5f 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -255,7 +255,8 @@ static int at91_dt_node_to_map(struct pinctrl_dev
> *pctldev,
> }
>
> map_num += grp->npins;
> - new_map = devm_kzalloc(pctldev->dev, sizeof(*new_map) * map_num,
> GFP_KERNEL);
> + new_map = devm_kzalloc(pctldev->dev, sizeof(*new_map) * map_num,
> +GFP_KERNEL);
not related please drop
> if (!new_map)
> return -ENOMEM;
>
> @@ -265,7 +266,7 @@ static int at91_dt_node_to_map(struct pinctrl_dev
> *pctldev,
> /* create mux map */
> parent = of_get_parent(np);
> if (!parent) {
> - kfree(new_map);
> + devm_kfree(pctldev->dev, new_map);
ok
> return -EINVAL;
> }
> new_map[0].type = PIN_MAP_TYPE_MUX_GROUP;
>
Best Regards,
J.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] regulator: vexpress: Add missing n_voltages setting
On Tue, 2012-12-11 at 23:39 +, Axel Lin wrote:
> I was thinking below patch to fix the issue:
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index cd1b201..891bc96 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1885,9 +1885,14 @@ int regulator_can_change_voltage(struct
> regulator *regulator)
> struct regulator_dev*rdev = regulator->rdev;
>
> if (rdev->constraints &&
> - rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE &&
> - rdev->desc->n_voltages > 1)
> - return 1;
> + rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE) {
> + if (rdev->desc->n_voltages > 1)
> + return 1;
> + if (rdev->desc->continuous_voltage_range &&
> + rdev->constraints->min_uV && rdev->constraints->max_uV)
> + return 1;
> +
> + }
>
> return 0;
> }
I wouldn't say so, although of course it's not my call. To my ming the
(valid_ops_mask & REGULATOR_CHANGE_VOLTAGE) should really be the only
condition here. I'd even risk saying that checking n_voltages > 1 or
continuous_voltage_range is a bit over the top. So maybe the correct
thing to do would be:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index cd1b201..38fe3a2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1885,8 +1885,7 @@ int regulator_can_change_voltage(struct regulator
*regulator)
struct regulator_dev*rdev = regulator->rdev;
if (rdev->constraints &&
- rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE &&
- rdev->desc->n_voltages > 1)
+ rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE)
return 1;
return 0;
And before you ask - I initialize regulator data from the device tree,
so I get all constraints and valid_ops_mask set by
of_get_regulator_init_data() and of_get_regulation_constraints().
> But then I think if the core relies on n_voltages settings, why not
> set n_voltages in the driver
> even if a driver has continuous_voltage_range set.
I'm not sure that you can say that "the core relies on n_voltages". This
is probably a question for Mark, but to my mind it's one of the possible
cases.
>
> Maybe I'm still not full understand about continuous_voltage_range,
> A driver with continuous_voltage_range looks special to me:
> 1. regulator_count_voltages() always return 0
> 2. regulator_list_voltage() returns -EINVAL. ( Does it make sense to
> not implement list_voltage ? )
Because it doesn't have "discreet" operating points. The count/list
voltage interface is supposed to represent a regulator that can be set
to (for example) 1V, 2V, 3V, 4V or 5V. "My" regulator (example again)
can be set to any value between 1V and 5V, for example 2.3456. Why would
you like to enumerate all thousands of possible values between 1 and 5?
> 3. vexpress_regulator_set_voltage() looks does not have voltage range
> checking:
> Given init_data->constraints.min_uV= 5
> init_data->constraints.max_uV=6
> What happen if vexpress_regulator_set_voltage is called with
> min_uV=8, max_uV=10?
The core takes care of that - have a look at regulator_set_voltage()
(hint: regulator_check_voltage ;-). The driver can assume that it will
get values within the constraints.
> 4. It's unclear to me if only one of
> init_data->constraints->min_uV/init_data->constraints->max_uV is set.
Again, from my point of view it's the core's problem. I don't think it's
a legal case though.
Paweł
--
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 v9 3/3] 1/1] virtio_console: Remove buffers from out_vq at port removal
On (Wed) 12 Dec 2012 [10:31:04], Rusty Russell wrote: > Amit Shah writes: > > > On (Tue) 11 Dec 2012 [09:39:41], Rusty Russell wrote: > >> Amit Shah writes: > >> > >> > On (Fri) 16 Nov 2012 [11:22:09], Rusty Russell wrote: > >> >> Amit Shah writes: > >> >> > From: Sjur Brændeland > >> >> > > >> >> > Remove buffers from the out-queue when a port is removed. Rproc_serial > >> >> > communicates with remote processors that may crash and leave buffers > >> >> > in > >> >> > the out-queue. The virtio serial ports may have buffers in the > >> >> > out-queue > >> >> > as well, e.g. for non-blocking ports and the host didn't consume them > >> >> > yet. > >> >> > > >> >> > [Amit: Remove WARN_ON for generic ports case.] > >> >> > > >> >> > Signed-off-by: Sjur Brændeland > >> >> > Signed-off-by: Amit Shah > >> >> > >> >> I already have this in my pending queue; I've promoted it to my > >> >> virtio-next branch now. > >> > > >> > Rusty, I still see this series in your pending queue, not in > >> > virtio-next. Did anything change in the meantime? > >> > >> Hmm: > >> > >> 40e625ac50f40d87ddba93280d0a503425aa68e9? > > > > I'm sorry, I meant the remoteproc code, not this patch. > > Still waiting for v9, AFIACT? Instead of sending all patches marked v9, just this patch was re-spun. I think you can just pick up patches 1 and 2 from v8 (they have my acked-by), and patch 3 was an earlier version of this one, which should just be dropped. Amit -- 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: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
On Wed, Dec 12, 2012 at 11:58:41AM +0100, Takashi Iwai wrote: > Borislav, could you test the patch below? [ … ] > From: Takashi Iwai > Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback > > The runtime_idle callback is the right place to check the suspend > capability, but currently we do it wrongly in the runtime_suspend > callback. This leads to a kernel error message like: >pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] > returns -11 > and the runtime PM core would even repeat the attempts. > > Reported-by: Borislav Petkov -and-tested-by: ... Thanks Takashi. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/pinctrl: grab default handles from device core
On 10:13 Tue 11 Dec , Greg Kroah-Hartman wrote:
> On Tue, Dec 11, 2012 at 02:40:46PM +0100, Linus Walleij wrote:
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 86ef6ab..dc399ab 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -605,6 +606,8 @@ struct device_dma_parameters {
> > * @pm_domain: Provide callbacks that are executed during system
> > suspend,
> > * hibernation, system resume and during runtime PM
> > transitions
> > * along with subsystem-level and driver-level callbacks.
> > + * @pins: For device pin management.
> > + * See Documentation/pinctrl.txt for details.
> > * @numa_node: NUMA node this device is close to.
> > * @dma_mask: Dma mask (if dma'ble device).
> > * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as
> > not all
> > @@ -656,6 +659,10 @@ struct device {
> > struct dev_pm_info power;
> > struct dev_pm_domain*pm_domain;
> >
> > +#ifdef CONFIG_PINCTRL
> > + struct dev_pin_info pins;
> > +#endif
>
> Can't you just make this a * to the structure, saving a bit of space for
> those that don't use this structure? Ok, it's only saving one pointer,
> so it's really not a big deal to me if you don't want to do this, just
> asking...
>
> Also, this will have to wait until after 3.8-rc1 before I can consider
> merging it, I'm a bit busy for the next two weeks at the least...
can do do not put ifdef in the struct as if will force us to put ifdef in the
c code too instead of just use a inline function
Best Regards,
J.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: imx5: fix GPIO_8 pad CAN1_RXCAN configuration
3 is an invalid value for the CAN1_IPP_IND_CANRX_SELECT_INPUT
register. Set it to 2, which correctly selects the GPIO_8 pad.
Signed-off-by: Philipp Zabel
---
drivers/pinctrl/pinctrl-imx53.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c
index 783feb1..e069027 100644
--- a/drivers/pinctrl/pinctrl-imx53.c
+++ b/drivers/pinctrl/pinctrl-imx53.c
@@ -1371,7 +1371,7 @@ static struct imx_pin_reg imx53_pin_regs[] = {
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 0, 0x7F8, 1), /*
MX53_PAD_GPIO_8__ESAI1_TX5_RX0 */
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 1, 0x000, 0), /*
MX53_PAD_GPIO_8__GPIO1_8 */
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 2, 0x000, 0), /*
MX53_PAD_GPIO_8__EPIT2_EPITO */
- IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 3, 0x760, 3), /*
MX53_PAD_GPIO_8__CAN1_RXCAN */
+ IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 3, 0x760, 2), /*
MX53_PAD_GPIO_8__CAN1_RXCAN */
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 4, 0x880, 5), /*
MX53_PAD_GPIO_8__UART2_RXD_MUX */
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 5, 0x000, 0), /*
MX53_PAD_GPIO_8__FIRI_TXD */
IMX_PIN_REG(MX53_PAD_GPIO_8, 0x6C8, 0x338, 6, 0x000, 0), /*
MX53_PAD_GPIO_8__SPDIF_SRCLK */
--
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 v3] mmc: core: Add support for idle time BKOPS
Hi Ulf, Sorry for the late response. See my reply below. Thanks, Maya On Thu, December 6, 2012 2:18 am, Ulf Hansson wrote: > Hi Maya, > > On 4 December 2012 22:17, wrote: >> Hi Ulf, >> >> Let me try to better explain: >> The idea behind the periodic BKOPS is to check the card's need for BKOPS >> periodically in order to prevent an urgent BKOPS need by the card. >> In order to actually manage to prevent the urgent BKOPS need, the host >> should give the card enough time to perform the BKOPS (when it >> recognizes >> BKOPS need), otherwise there is no point in having the periodic BKOPS. >> The above results in the following: >> 1. After starting non-urgent BKOPS we "delay" getting into suspend by >> polling on the card's status (explanation below), in order to give the >> card time to perform the BKOPS. This has no effect on the power >> consumption since the same BKOPS operations that were performed after >> the >> foregound operation just moved to another location, meaning before going >> into suspend. > > I am not sure what you are talking about here, runtime suspend or > system suspend? Polling the card's status will not prevent any of > this. So you have got this wrong. I am referring to the runtime suspend. Our controller implements the runtime suspend and is not using the default implementation of core/bus.c. This is the reason why in our implementation polling the card status "delays" the runtime suspend while it is not the case when using the default runtime suspend implementation. I can try to explain here what our controller is doing but since it is specific to us then I guess it is not relevant to the discussion. Our controller is calling mmc_suspend_host in runtime suspend, which issues an HPI to stop the BKOPS. Now that I understand that this code is not needed for all the host drivers I will add a flag to decide if polling is required when doing an unblocking BKOPS. Other host drivers that actually suspend on runtime suspend can enable this flag and allow BKOPS to be active for a longer period. I will prepare a new patch and send it for review. > >> 2. Using PM_SUSPEND_PREPARE instead of the workqueue would not be >> efficient since we don't want to wait until the host is ready to get >> into >> suspend and then prevent him from suspending by doing BKOPS operations >> that can take a long time. It is better to start the BKOPS earlier. > > I did not suggest to use PM_SUSPEND_PREPARE, but to use runtime PM for > the card device. It can be an option to implement this feature on top > of a workqueue. At least worth to consider. > We consider to call mmc_start_bkops every time MMC becomes idle, to check the need for BKOPS. I will test it and include it in the next patch. >> >> I am not too familiar with the controllers code and also my >> understanding >> in runtime suspend is very basic, so feel free to correct me if I'm >> wrong >> here or the behavior in other controllers is different from msm_sdcc. >> mmc_claim_host calls host->ops->enable. This API is implemented per >> controller but as far as I understand it, this API must prevent suspend, >> otherwise we might go into suspend while there is bus activity. By doing >> get_card_status we call mmc_claim_host and this call is the one that >> "delays" getting into suspend. > > host->ops->enable is the old way of implementing runtime power save > for host drivers. Nowadays most drivers is using runtime PM instead. > > When you say that mmc_claim_host will prevent suspend, I suppose you > mean that host->ops->disable wont be called? That is definitely not > the same as preventing a system suspend, and moreover it should not. > If you think that the host must be prevented from entering runtime > power save (runtime_supend or host->ops->disable), you must elaborate > more on this, because I don't understand why this is needed. > Again, this is specific to our controller, so you can just ignore that. >> If this is not the case in other controllers than the BKOPS will not >> prevent the suspend and BKOPS will be interrupted. >> As for the effect on the battery consumption, this is probably something >> specific to our controller, so sorry if I created a confusion. >> >> Additional comments inline. >> >> Thanks, >> Maya >> >> On Tue, December 4, 2012 1:52 am, Ulf Hansson wrote: >>> On 3 December 2012 10:49, wrote: Hi Jaehoon, With this patch we don't expect to see any degradation. Thanks for verifying that. The test plan would be to run the lmdd and iozone benchmarks with this patch and verify that the performance is not degraded. I verified it with the msm_sdcc controller. Chris - We do expect it to influence the battery consumption, since we now delay getting into suspend (since mmc_start_bkops which is called after the delayed work is executed claims the host). The solution for that should be done by the controller which can shorten the timeout given to
RE: [[PATCH v9 3/3] 1/1] virtio_console: Remove buffers from out_vq at port removal
> Amit Shah [mailto:amit.s...@redhat.com] writes: > On (Wed) 12 Dec 2012 [10:31:04], Rusty Russell wrote: > > Amit Shah writes: > > > On (Tue) 11 Dec 2012 [09:39:41], Rusty Russell wrote: > > >> Amit Shah writes: > > >> > On (Fri) 16 Nov 2012 [11:22:09], Rusty Russell wrote: > > >> >> Amit Shah writes: > > >> >> > From: Sjur Brændeland > > >> >> > > > >> >> > Remove buffers from the out-queue when a port is removed. > Rproc_serial > > >> >> > communicates with remote processors that may crash and leave > buffers in > > >> >> > the out-queue. The virtio serial ports may have buffers in the out- > queue > > >> >> > as well, e.g. for non-blocking ports and the host didn't consume > them > > >> >> > yet. > > >> >> > > > >> >> > [Amit: Remove WARN_ON for generic ports case.] > > >> >> > > > >> >> > Signed-off-by: Sjur Brændeland > > > >> >> > Signed-off-by: Amit Shah > > >> >> > > >> >> I already have this in my pending queue; I've promoted it to my > > >> >> virtio-next branch now. > > >> > > > >> > Rusty, I still see this series in your pending queue, not in > > >> > virtio-next. Did anything change in the meantime? > > >> > > >> Hmm: > > >> > > >> 40e625ac50f40d87ddba93280d0a503425aa68e9? > > > > > > I'm sorry, I meant the remoteproc code, not this patch. > > > > Still waiting for v9, AFIACT? > > Instead of sending all patches marked v9, just this patch was > re-spun. I think you can just pick up patches 1 and 2 from v8 (they > have my acked-by), and patch 3 was an earlier version of this one, Yes, that's right. V8 contained three patches, Amit did a respin of 3/3 that was applied. (And I mistakenly thought 1/3 and 2/3 was applied as well). Anyway I'm resending a new patch-set with the two missing patches. The patches are identical to the V8, but are rebased to the virtio-next branch. Sorry for the confusion here. Regards, Sjur -- 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] vfio powerpc: enabled on powernv platform
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and providing DMA window properties.
This API is going to be used later by QEMU-VFIO to handle
h_put_tce hypercalls from the KVM guest.
Although this driver has been tested only on the POWERNV
platform, it should work on any platform which supports
TCE tables.
To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
option and configure VFIO as required.
Cc: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 10 ++
arch/powerpc/kernel/iommu.c | 329 ++
arch/powerpc/platforms/powernv/pci.c | 134 ++
drivers/iommu/Kconfig|8 +
4 files changed, 481 insertions(+)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index cbfe678..3c861ae 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -76,6 +76,9 @@ struct iommu_table {
struct iommu_pool large_pool;
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
+#ifdef CONFIG_IOMMU_API
+ struct iommu_group *it_group;
+#endif
};
struct scatterlist;
@@ -147,5 +150,12 @@ static inline void iommu_restore(void)
}
#endif
+extern void iommu_reset_table(struct iommu_table *tbl, bool restore);
+extern long iommu_clear_tces(struct iommu_table *tbl, unsigned long ioba,
+ unsigned long size);
+extern long iommu_put_tces(struct iommu_table *tbl, unsigned long ioba,
+ uint64_t tce, enum dma_data_direction direction,
+ unsigned long size);
+
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ff5a6ce..f3bb2e7 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
#include
+#include
#define DBG(...)
@@ -856,3 +858,330 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t
size,
free_pages((unsigned long)vaddr, get_order(size));
}
}
+
+#ifdef CONFIG_IOMMU_API
+/*
+ * SPAPR TCE API
+ */
+
+struct vwork {
+ struct mm_struct*mm;
+ longnpage;
+ struct work_struct work;
+};
+
+/* delayed decrement/increment for locked_vm */
+static void lock_acct_bg(struct work_struct *work)
+{
+ struct vwork *vwork = container_of(work, struct vwork, work);
+ struct mm_struct *mm;
+
+ mm = vwork->mm;
+ down_write(>mmap_sem);
+ mm->locked_vm += vwork->npage;
+ up_write(>mmap_sem);
+ mmput(mm);
+ kfree(vwork);
+}
+
+static void lock_acct(long npage)
+{
+ struct vwork *vwork;
+ struct mm_struct *mm;
+
+ if (!current->mm)
+ return; /* process exited */
+
+ if (down_write_trylock(>mm->mmap_sem)) {
+ current->mm->locked_vm += npage;
+ up_write(>mm->mmap_sem);
+ return;
+ }
+
+ /*
+* Couldn't get mmap_sem lock, so must setup to update
+* mm->locked_vm later. If locked_vm were atomic, we
+* wouldn't need this silliness
+*/
+ vwork = kmalloc(sizeof(struct vwork), GFP_KERNEL);
+ if (!vwork)
+ return;
+ mm = get_task_mm(current);
+ if (!mm) {
+ kfree(vwork);
+ return;
+ }
+ INIT_WORK(>work, lock_acct_bg);
+ vwork->mm = mm;
+ vwork->npage = npage;
+ schedule_work(>work);
+}
+
+/*
+ * iommu_reset_table is called when it started/stopped being used.
+ *
+ * restore==true says to bring the iommu_table into the state as it was
+ * before being used by VFIO.
+ */
+void iommu_reset_table(struct iommu_table *tbl, bool restore)
+{
+ /* Page#0 is marked as used in iommu_init_table, so we clear it... */
+ if (!restore && (tbl->it_offset == 0))
+ clear_bit(0, tbl->it_map);
+
+ iommu_clear_tces(tbl, tbl->it_offset, tbl->it_size);
+
+ /* ... or restore */
+ if (restore && (tbl->it_offset == 0))
+ set_bit(0, tbl->it_map);
+}
+EXPORT_SYMBOL_GPL(iommu_reset_table);
+
+/*
+ * Returns the number of used IOMMU pages (4K) within
+ * the same system page (4K or 64K).
+ *
+ * syspage_weight_zero is optimized for expected case == 0
+ * syspage_weight_one is optimized for expected case > 1
+ * Other case are not used in this file.
+ */
+#if PAGE_SIZE == IOMMU_PAGE_SIZE
+
+#define syspage_weight_zero(map, offset) test_bit((map), (offset))
+#define syspage_weight_one(map, offset)
[PATCH] vfio powerpc: implemented IOMMU driver for VFIO
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does mapping/unmapping pages for the guest IO and
provides information about DMA window (required by a POWERPC
guest).
The counterpart in QEMU is required to support this functionality.
Cc: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/Kconfig|6 +
drivers/vfio/Makefile |1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 249 +++
include/linux/vfio.h| 31 +
4 files changed, 287 insertions(+)
create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 7cd5dec..b464687 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
depends on VFIO
default n
+config VFIO_IOMMU_SPAPR_TCE
+ tristate
+ depends on VFIO && SPAPR_TCE_IOMMU
+ default n
+
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
+ select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
help
VFIO provides a framework for secure userspace device drivers.
See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 2398d4a..72bfabc 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_VFIO) += vfio.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
+obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
new file mode 100644
index 000..714bf57
--- /dev/null
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -0,0 +1,249 @@
+/*
+ * VFIO: IOMMU DMA mapping support for TCE on POWER
+ *
+ * Copyright (C) 2012 IBM Corp. All rights reserved.
+ * Author: Alexey Kardashevskiy
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Derived from original vfio_iommu_type1.c:
+ * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
+ * Author: Alex Williamson
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "a...@ozlabs.ru"
+#define DRIVER_DESC "VFIO IOMMU SPAPR TCE"
+
+static void tce_iommu_detach_group(void *iommu_data,
+ struct iommu_group *iommu_group);
+
+/*
+ * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
+ *
+ * This code handles mapping and unmapping of user data buffers
+ * into DMA'ble space using the IOMMU
+ */
+
+/*
+ * The container descriptor supports only a single group per container.
+ * Required by the API as the container is not supplied with the IOMMU group
+ * at the moment of initialization.
+ */
+struct tce_container {
+ struct mutex lock;
+ struct iommu_table *tbl;
+};
+
+static void *tce_iommu_open(unsigned long arg)
+{
+ struct tce_container *container;
+
+ if (arg != VFIO_SPAPR_TCE_IOMMU) {
+ pr_err("tce_vfio: Wrong IOMMU type\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ container = kzalloc(sizeof(*container), GFP_KERNEL);
+ if (!container)
+ return ERR_PTR(-ENOMEM);
+
+ mutex_init(>lock);
+
+ return container;
+}
+
+static void tce_iommu_release(void *iommu_data)
+{
+ struct tce_container *container = iommu_data;
+
+ WARN_ON(container->tbl && !container->tbl->it_group);
+ if (container->tbl && container->tbl->it_group)
+ tce_iommu_detach_group(iommu_data, container->tbl->it_group);
+
+ mutex_destroy(>lock);
+
+ kfree(container);
+}
+
+static long tce_iommu_ioctl(void *iommu_data,
+unsigned int cmd, unsigned long arg)
+{
+ struct tce_container *container = iommu_data;
+ unsigned long minsz;
+ long ret;
+
+ switch (cmd) {
+ case VFIO_CHECK_EXTENSION:
+ return (arg == VFIO_SPAPR_TCE_IOMMU) ? 1 : 0;
+
+ case VFIO_IOMMU_SPAPR_TCE_GET_INFO: {
+ struct vfio_iommu_spapr_tce_info info;
+ struct iommu_table *tbl = container->tbl;
+
+ if (WARN_ON(!tbl))
+ return -ENXIO;
+
+ minsz = offsetofend(struct vfio_iommu_spapr_tce_info,
+ dma32_window_size);
+
+ if (copy_from_user(, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ if (info.argsz < minsz)
+
[GIT PULL] KVM updates for the 3.8 merge window
Linus, Please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.8-1 to receive the KVM updates for the 3.8 merge window, including considerable KVM/PPC work, x86 kvmclock vsyscall support, IA32_TSC_ADJUST MSR emulation, amongst others. Alex Williamson (2): KVM: Fix user memslot overlap check kvm: Fix irqfd resampler list walk Alexander Graf (37): KVM: PPC: PR: Use generic tracepoint for guest exit KVM: PPC: Expose SYNC cap based on mmu notifiers KVM: PPC: BookE: Expose remote TLB flushes in debugfs KVM: PPC: E500: Fix clear_tlb_refs KVM: PPC: BookE: Add check_requests helper function KVM: PPC: BookE: Add support for vcpu->mode KVM: PPC: E500: Implement MMU notifiers KVM: PPC: BookE: Add some more trace points KVM: PPC: BookE: No duplicate request != 0 check KVM: PPC: Use same kvmppc_prepare_to_enter code for booke and book3s_pr KVM: PPC: Book3s: PR: Add (dumb) MMU Notifier support KVM: PPC: BookE: Drop redundant vcpu->mode set KVM: PPC: Book3S: PR: Only do resched check once per exit KVM: PPC: Exit guest context while handling exit KVM: PPC: Book3S: PR: Indicate we're out of guest mode KVM: PPC: Consistentify vcpu exit path KVM: PPC: Book3S: PR: Rework irq disabling KVM: PPC: Move kvm_guest_enter call into generic code KVM: PPC: Ignore EXITING_GUEST_MODE mode KVM: PPC: Add return value in prepare_to_enter KVM: PPC: Add return value to core_check_requests KVM: PPC: 44x: Initialize PVR KVM: PPC: BookE: Add MCSR SPR support KVM: PPC: Use symbols for exit trace KVM: PPC: E500: Remove E500_TLB_DIRTY flag KVM: PPC: 440: Implement mtdcrx KVM: PPC: 440: Implement mfdcrx KVM: PPC: BookE: Support FPU on non-hv systems KVM: PPC: 44x: fix DCR read/write KVM: Documentation: Fix reentry-to-be-consistent paragraph KVM: PPC: Move mtspr/mfspr emulation into own functions PPC: ePAPR: Convert header to uapi Merge commit 'origin/queue' into for-queue PPC: ePAPR: Convert hcall header to uapi (round 2) KVM: Distangle eventfd code from irqchip KVM: PPC: Support eventfd KVM: PPC: Make EPCR a valid field for booke64 and bookehv Bharat Bhushan (3): KVM: PPC: booke: Add watchdog emulation booke: Added ONE_REG interface for IAC/DAC debug registers Document IACx/DACx registers access using ONE_REG API Borislav Petkov (1): KVM: SVM: Cleanup error statements Christian Borntraeger (1): s390/kvm: dont announce RRBM support Christoffer Dall (1): KVM: Take kvm instead of vcpu to mmu_notifier_retry Cornelia Huck (1): s390/kvm: Add documentation for KVM_S390_INTERRUPT Gleb Natapov (5): KVM: do not de-cache cr4 bits needlessly KVM: use is_idle_task() instead of idle_cpu() to decide when to halt in async_pf KVM: VMX: fix DPL during entry to protected mode VMX: remove unneeded enable_unrestricted_guest check KVM: emulator: fix real mode segment checks in address linearization Guo Chao (3): KVM: do not kfree error pointer KVM: x86: fix return value of kvm_vm_ioctl_set_tss_addr() KVM: remove unnecessary return value check Jan Kiszka (3): KVM: x86: Convert kvm_arch_vcpu_reset into private kvm_vcpu_reset KVM: x86: Make emulator_fix_hypercall static KVM: x86: Fix uninitialized return code Jason J. Herne (1): s390/kvm: Interrupt injection bugfix Joerg Roedel (1): KVM: SVM: update MAINTAINERS entry Julia Lawall (1): arch/powerpc/kvm/e500_tlb.c: fix error return code Julian Stecklina (1): KVM: x86: Make register state after reset conform to specification Liu Yu-B13201 (3): KVM: PPC: Add support for ePAPR idle hcall in host kernel KVM: PPC: ev_idle hcall support for e500 guests PPC: Don't use hardcoded opcode for ePAPR hcall invocation Marcelo Tosatti (22): Merge branch 'for-upstream' of http://github.com/agraf/linux-2.6 into queue Merge remote-tracking branch 'master' into queue Merge branch 'for-queue' of https://github.com/agraf/linux-2.6 into queue KVM: x86: retain pvclock guest stopped bit in guest memory x86: kvmclock: allocate pvclock shared memory area x86: pvclock: make sure rdtsc doesnt speculate out of region x86: pvclock: remove pvclock_shadow_time x86: pvclock: create helper for pvclock data retrieval x86: pvclock: introduce helper to read flags x86: pvclock: add note about rdtsc barriers sched: add notifier for cross-cpu migrations x86: pvclock: generic pvclock vsyscall initialization x86: kvm guest: pvclock vsyscall support x86: vdso: pvclock gettime support KVM: x86: pass host_tsc to read_l1_tsc time: export time information for KVM pvclock KVM: x86: notifier for clocksource changes KVM: x86: implement
[PATCHv9 0/2] virtio_console: Add rproc_serial driver
This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to virtio-next. Regards, Sjur Sjur Brændeland (2): virtio_console: Merge struct buffer_token into struct port_buffer virtio_console: Add support for remoteproc serial drivers/char/virtio_console.c | 317 +++ include/uapi/linux/virtio_ids.h |1 + 2 files changed, 221 insertions(+), 97 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv9 1/2] virtio_console: Merge struct buffer_token into struct port_buffer
Refactoring the splice functionality by unifying the approach for
sending scatter-lists and regular buffers. This simplifies
buffer handling and reduces code size. Splice will now allocate
a port_buffer and send_buf() and free_buf() can always be used
for any buffer.
Signed-off-by: Sjur Brændeland
Acked-by: Amit Shah
---
drivers/char/virtio_console.c | 129 +
1 files changed, 53 insertions(+), 76 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index db244b5..5482246 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -111,6 +111,12 @@ struct port_buffer {
size_t len;
/* offset in the buf from which to consume data */
size_t offset;
+
+ /* If sgpages == 0 then buf is used */
+ unsigned int sgpages;
+
+ /* sg is used if spages > 0. sg must be the last in is struct */
+ struct scatterlist sg[0];
};
/*
@@ -338,17 +344,39 @@ static inline bool use_multiport(struct ports_device
*portdev)
static void free_buf(struct port_buffer *buf)
{
+ unsigned int i;
+
kfree(buf->buf);
+ for (i = 0; i < buf->sgpages; i++) {
+ struct page *page = sg_page(>sg[i]);
+ if (!page)
+ break;
+ put_page(page);
+ }
+
kfree(buf);
}
-static struct port_buffer *alloc_buf(size_t buf_size)
+static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size,
+int pages)
{
struct port_buffer *buf;
- buf = kmalloc(sizeof(*buf), GFP_KERNEL);
+ /*
+* Allocate buffer and the sg list. The sg list array is allocated
+* directly after the port_buffer struct.
+*/
+ buf = kmalloc(sizeof(*buf) + sizeof(struct scatterlist) * pages,
+ GFP_KERNEL);
if (!buf)
goto fail;
+
+ buf->sgpages = pages;
+ if (pages > 0) {
+ buf->buf = NULL;
+ return buf;
+ }
+
buf->buf = kmalloc(buf_size, GFP_KERNEL);
if (!buf->buf)
goto free_buf;
@@ -478,52 +506,26 @@ static ssize_t send_control_msg(struct port *port,
unsigned int event,
return 0;
}
-struct buffer_token {
- union {
- void *buf;
- struct scatterlist *sg;
- } u;
- /* If sgpages == 0 then buf is used, else sg is used */
- unsigned int sgpages;
-};
-
-static void reclaim_sg_pages(struct scatterlist *sg, unsigned int nrpages)
-{
- int i;
- struct page *page;
-
- for (i = 0; i < nrpages; i++) {
- page = sg_page([i]);
- if (!page)
- break;
- put_page(page);
- }
- kfree(sg);
-}
/* Callers must take the port->outvq_lock */
static void reclaim_consumed_buffers(struct port *port)
{
- struct buffer_token *tok;
+ struct port_buffer *buf;
unsigned int len;
if (!port->portdev) {
/* Device has been unplugged. vqs are already gone. */
return;
}
- while ((tok = virtqueue_get_buf(port->out_vq, ))) {
- if (tok->sgpages)
- reclaim_sg_pages(tok->u.sg, tok->sgpages);
- else
- kfree(tok->u.buf);
- kfree(tok);
+ while ((buf = virtqueue_get_buf(port->out_vq, ))) {
+ free_buf(buf);
port->outvq_full = false;
}
}
static ssize_t __send_to_port(struct port *port, struct scatterlist *sg,
int nents, size_t in_count,
- struct buffer_token *tok, bool nonblock)
+ void *data, bool nonblock)
{
struct virtqueue *out_vq;
int err;
@@ -536,7 +538,7 @@ static ssize_t __send_to_port(struct port *port, struct
scatterlist *sg,
reclaim_consumed_buffers(port);
- err = virtqueue_add_buf(out_vq, sg, nents, 0, tok, GFP_ATOMIC);
+ err = virtqueue_add_buf(out_vq, sg, nents, 0, data, GFP_ATOMIC);
/* Tell Host to go! */
virtqueue_kick(out_vq);
@@ -574,37 +576,6 @@ done:
return in_count;
}
-static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count,
- bool nonblock)
-{
- struct scatterlist sg[1];
- struct buffer_token *tok;
-
- tok = kmalloc(sizeof(*tok), GFP_ATOMIC);
- if (!tok)
- return -ENOMEM;
- tok->sgpages = 0;
- tok->u.buf = in_buf;
-
- sg_init_one(sg, in_buf, in_count);
-
- return __send_to_port(port, sg, 1, in_count, tok, nonblock);
-}
-
-static ssize_t send_pages(struct port *port, struct scatterlist *sg, int nents,
- size_t in_count, bool nonblock)
-{
- struct buffer_token *tok;
-
- tok = kmalloc(sizeof(*tok),
[PATCHv9 2/2] virtio_console: Add support for remoteproc serial
Add a simple serial connection driver called
VIRTIO_ID_RPROC_SERIAL (11) for communicating with a
remote processor in an asymmetric multi-processing
configuration.
This implementation reuses the existing virtio_console
implementation, and adds support for DMA allocation
of data buffers and disables use of tty console and
the virtio control queue.
Signed-off-by: Sjur Brændeland
Acked-by: Amit Shah
---
drivers/char/virtio_console.c | 192 ++-
include/uapi/linux/virtio_ids.h |1 +
2 files changed, 170 insertions(+), 23 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 5482246..55a89a4 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -37,8 +37,12 @@
#include
#include
#include
+#include
+#include
#include "../tty/hvc/hvc_console.h"
+#define is_rproc_enabled IS_ENABLED(CONFIG_REMOTEPROC)
+
/*
* This is a global struct for storing common data for all the devices
* this driver handles.
@@ -112,6 +116,15 @@ struct port_buffer {
/* offset in the buf from which to consume data */
size_t offset;
+ /* DMA address of buffer */
+ dma_addr_t dma;
+
+ /* Device we got DMA memory from */
+ struct device *dev;
+
+ /* List of pending dma buffers to free */
+ struct list_head list;
+
/* If sgpages == 0 then buf is used */
unsigned int sgpages;
@@ -331,6 +344,11 @@ static bool is_console_port(struct port *port)
return false;
}
+static bool is_rproc_serial(const struct virtio_device *vdev)
+{
+ return is_rproc_enabled && vdev->id.device == VIRTIO_ID_RPROC_SERIAL;
+}
+
static inline bool use_multiport(struct ports_device *portdev)
{
/*
@@ -342,11 +360,13 @@ static inline bool use_multiport(struct ports_device
*portdev)
return portdev->vdev->features[0] & (1 << VIRTIO_CONSOLE_F_MULTIPORT);
}
-static void free_buf(struct port_buffer *buf)
+static DEFINE_SPINLOCK(dma_bufs_lock);
+static LIST_HEAD(pending_free_dma_bufs);
+
+static void free_buf(struct port_buffer *buf, bool can_sleep)
{
unsigned int i;
- kfree(buf->buf);
for (i = 0; i < buf->sgpages; i++) {
struct page *page = sg_page(>sg[i]);
if (!page)
@@ -354,14 +374,57 @@ static void free_buf(struct port_buffer *buf)
put_page(page);
}
+ if (!buf->dev) {
+ kfree(buf->buf);
+ } else if (is_rproc_enabled) {
+ unsigned long flags;
+
+ /* dma_free_coherent requires interrupts to be enabled. */
+ if (!can_sleep) {
+ /* queue up dma-buffers to be freed later */
+ spin_lock_irqsave(_bufs_lock, flags);
+ list_add_tail(>list, _free_dma_bufs);
+ spin_unlock_irqrestore(_bufs_lock, flags);
+ return;
+ }
+ dma_free_coherent(buf->dev, buf->size, buf->buf, buf->dma);
+
+ /* Release device refcnt and allow it to be freed */
+ put_device(buf->dev);
+ }
+
kfree(buf);
}
+static void reclaim_dma_bufs(void)
+{
+ unsigned long flags;
+ struct port_buffer *buf, *tmp;
+ LIST_HEAD(tmp_list);
+
+ if (list_empty(_free_dma_bufs))
+ return;
+
+ /* Create a copy of the pending_free_dma_bufs while holding the lock */
+ spin_lock_irqsave(_bufs_lock, flags);
+ list_cut_position(_list, _free_dma_bufs,
+ pending_free_dma_bufs.prev);
+ spin_unlock_irqrestore(_bufs_lock, flags);
+
+ /* Release the dma buffers, without irqs enabled */
+ list_for_each_entry_safe(buf, tmp, _list, list) {
+ list_del(>list);
+ free_buf(buf, true);
+ }
+}
+
static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size,
int pages)
{
struct port_buffer *buf;
+ reclaim_dma_bufs();
+
/*
* Allocate buffer and the sg list. The sg list array is allocated
* directly after the port_buffer struct.
@@ -373,11 +436,34 @@ static struct port_buffer *alloc_buf(struct virtqueue
*vq, size_t buf_size,
buf->sgpages = pages;
if (pages > 0) {
+ buf->dev = NULL;
buf->buf = NULL;
return buf;
}
- buf->buf = kmalloc(buf_size, GFP_KERNEL);
+ if (is_rproc_serial(vq->vdev)) {
+ /*
+* Allocate DMA memory from ancestor. When a virtio
+* device is created by remoteproc, the DMA memory is
+* associated with the grandparent device:
+* vdev => rproc => platform-dev.
+* The code here would have been less quirky if
+* DMA_MEMORY_INCLUDES_CHILDREN had been supported
+*
Re: [PATCH] vfio powerpc: enabled on powernv platform
Hi Alex, I posted other pair of patches. While debugging and testing my stuff I implemented some rough hack to support IOMMU mappings without passing those hypercalls to the QEMU, this is why I moved pieces of code around - want to support both QEMU-VFIO and kernel optimized H_PUT_TCE handler. On 12/12/12 23:34, Alexey Kardashevskiy wrote: This patch initializes IOMMU groups based on the IOMMU configuration discovered during the PCI scan on POWERNV (POWER non virtualized) platform. The IOMMU groups are to be used later by VFIO driver (PCI pass through). It also implements an API for mapping/unmapping pages for guest PCI drivers and providing DMA window properties. This API is going to be used later by QEMU-VFIO to handle h_put_tce hypercalls from the KVM guest. Although this driver has been tested only on the POWERNV platform, it should work on any platform which supports TCE tables. To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config option and configure VFIO as required. Cc: David Gibson Signed-off-by: Alexey Kardashevskiy --- -- Alexey -- 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: [Line6linux-devel] [PATCH] staging: line6: pcm.c fix checkpatch issues
Ping ? 2012/11/30, Stefan Hajnoczi : > Changes are fine. > > In the future, please split changes into individual patches. For example: > Patch 1 - Rename 'rv' to 'ret' > Patch 2 - Replace decprecated simple_strtoul() with kstrtoint() in > pcm_set_impulse_period() > Patch 3 - Realign comment in line6_init_pcm() switch statement > > Keeping patches focussed on doing just one thing makes it easier to > revert, bisect, and review them. > > Reviewed-by: Stefan Hajnoczi > Should I split patches as suggested by Stefan ? Laurent. -- 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] gpio: twl4030: Correct status reporting for outputs
On 12/12/2012 12:45 PM, Grant Likely wrote: > I will take a look at it this week Thanks > but I cannot pick it up for v3.8 unless it is a regression bug fix from > v3.6. It will have to wait for v3.9 and it can be merged into linux-next > after the v3.8 merge window closes. 3.9 is fine. the gpio-twl4030 never reported the output state correctly, I just found it out while doing some cleanups around the twl-core and board files. Thanks, Péter -- 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/hugetlb: create hugetlb cgroup file in hugetlb_init
On Wed 12-12-12 12:23:29, Michal Hocko wrote: > On Wed 12-12-12 18:44:13, Xishi Qiu wrote: [...] > > Hi Michal, > > > > __initcall functions will be called in > > start_kernel() > > rest_init() // -> slab is already > > kernel_init() > > kernel_init_freeable() > > do_basic_setup() > > do_initcalls() > > > > and setup_hugepagesz() will be called in > > start_kernel() > > parse_early_param() // -> before mm_init() -> kmem_cache_init() > > > > Is this right? > > Yes this is right. I just noticed that kmem_cache_init_late is an __init > function as well and didn't realize it is called directly. Sorry about > the confusion. > Anyway I still think it would be a better idea to move the call into the > hugetlb_cgroup_create callback where it is more logical IMO but now that > I'm looking at other controllers (blk and kmem.tcp) they all do this from > init calls as well. So it doesn't make sense to have hugetlb behave > differently. > > So > Acked-by: Michal Hocko Ohh, and this deserves to be backported to stable (since 3.6). -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
