* [PATCH v4 5/9] dt-bindings: Update binding for PM domain idle states
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
Update DT bindings to describe idle states of PM domains.
This patch is based on the original patch by Marc Titinger.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
.../devicetree/bindings/power/power_domain.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..3c926b5 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,16 @@ Optional properties:
specified by this binding. More details about power domain specifier are
available in the next section.
+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
+ generic domain power state. The idle state definitions must be
+ compatible with "domain-idle-state" as well as
+ "arm,idle-state" as defined in [1].
+ The domain-idle-state property reflects the idle state of this PM domain and
+ not the idle states of the devices or sub-domains in the PM domain. Devices
+ and sub-domains have their own idle-states independent of the parent
+ domain's idle states. In the absence of this property, the domain would be
+ considered as capable of being powered-on or powered-off.
+
Example:
power: power-controller at 12340000 {
@@ -59,6 +69,38 @@ The nodes above define two power controllers: 'parent' and 'child'.
Domains created by the 'child' power controller are subdomains of '0' power
domain provided by the 'parent' power controller.
+Example 3:
+ parent: power-controller at 12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <0>;
+ domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
+ };
+
+ child: power-controller at 12341000 {
+ compatible = "foo,power-controller";
+ reg = <0x12341000 0x1000>;
+ power-domains = <&parent 0>;
+ #power-domain-cells = <0>;
+ domain-idle-states = <&DOMAIN_PWR_DN>;
+ };
+
+ DOMAIN_RET: state at 0 {
+ compatible = "domain-idle-state", "arm,idle-state";
+ reg = <0x0>;
+ entry-latency-us = <1000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <10000>;
+ };
+
+ DOMAIN_PWR_DN: state at 1 {
+ compatible = "domain-idle-state", "arm,idle-state";
+ reg = <0x1>;
+ entry-latency-us = <5000>;
+ exit-latency-us = <8000>;
+ min-residency-us = <7000>;
+ };
+
==PM domain consumers==
Required properties:
@@ -76,3 +118,5 @@ Example:
The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/9] dt-bindings: add domain-idle-state compatible to arm, idle-state
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
CPU's idle states are defined by the arm,idle-state compatible flag. See
[1]. PM domains that can contains devices and other domains also has
similar definition for its idle state. Reuse the definition of
arm,idle-state for PM domains by allowing an addition compatible string
("domain-idle-state") to denote idle states that are specific to PM
Domains.
[1]. Documentation/devicetree/bindings/arm/idle-states.txt
Cc: <devicetree@vger.kernel.org>
Cc: Rob Herring <robh@kernel.org>
Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/devicetree/bindings/arm/idle-states.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index b8e41c1..4b0ff59 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -271,6 +271,9 @@ follows:
Usage: Required
Value type: <stringlist>
Definition: Must be "arm,idle-state".
+ Additionally, nodes that are used to describe a
+ idle-state of PM domain must also define
+ "domain-idle-state" as compatible string.
- local-timer-stop
Usage: See definition
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/9] PM / Domains: Allow domain power states to be read from DT
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
This patch allows domains to define idle states in the DT. SoC's can
define domain idle states in DT using the "domain-idle-states" property
of the domain provider. Add API to read the idle states from DT that can
be set in the genpd object.
This patch is based on the original patch by Marc Titinger.
Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/base/power/domain.c | 94 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 8 ++++
2 files changed, 102 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 37ab7f1..0e59f1d 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1916,6 +1916,100 @@ out:
return ret ? -EPROBE_DEFER : 0;
}
EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
+
+static const struct of_device_id idle_state_match[] = {
+ { .compatible = "domain-idle-state", },
+ { }
+};
+
+static int genpd_parse_state(struct genpd_power_state *genpd_state,
+ struct device_node *state_node)
+{
+ int err;
+ u32 residency;
+ u32 entry_latency, exit_latency;
+ const struct of_device_id *match_id;
+
+ match_id = of_match_node(idle_state_match, state_node);
+ if (!match_id)
+ return -EINVAL;
+
+ err = of_property_read_u32(state_node, "entry-latency-us",
+ &entry_latency);
+ if (err) {
+ pr_debug(" * %s missing entry-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "exit-latency-us",
+ &exit_latency);
+ if (err) {
+ pr_debug(" * %s missing exit-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "min-residency-us", &residency);
+ if (!err)
+ genpd_state->residency_ns = 1000 * residency;
+
+ genpd_state->power_on_latency_ns = 1000 * exit_latency;
+ genpd_state->power_off_latency_ns = 1000 * entry_latency;
+
+ return 0;
+}
+
+/**
+ * of_genpd_parse_idle_states: Return array of idle states for the genpd.
+ *
+ * @dn: The genpd device node
+ * @states: The pointer to which the state array will be saved.
+ * @n: The count of elements in the array returned from this function.
+ *
+ * Returns the device states parsed from the OF node. The memory for the states
+ * is allocated by this function and is the responsibility of the caller to
+ * free the memory after use.
+ */
+int of_genpd_parse_idle_states(struct device_node *dn,
+ struct genpd_power_state **states, int *n)
+{
+ struct genpd_power_state *st;
+ struct device_node *np;
+ int i = 0;
+ int err, ret;
+ int count;
+ struct of_phandle_iterator it;
+
+ count = of_count_phandle_with_args(dn, "domain-idle-states", NULL);
+ if (!count)
+ return -EINVAL;
+
+ st = kcalloc(count, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ /* Loop over the phandles until all the requested entry is found */
+ of_for_each_phandle(&it, err, dn, "domain-idle-states", NULL, 0) {
+ np = it.node;
+ ret = genpd_parse_state(&st[i++], np);
+ if (ret) {
+ pr_err
+ ("Parsing idle state node %s failed with err %d\n",
+ np->full_name, ret);
+ of_node_put(np);
+ kfree(st);
+ return ret;
+ }
+ }
+
+ *n = count;
+ *states = st;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
+
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f4492eb..b489496 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -205,6 +205,8 @@ extern int of_genpd_add_device(struct of_phandle_args *args,
extern int of_genpd_add_subdomain(struct of_phandle_args *parent,
struct of_phandle_args *new_subdomain);
extern struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
+extern int of_genpd_parse_idle_states(struct device_node *dn,
+ struct genpd_power_state **states, int *n);
int genpd_dev_pm_attach(struct device *dev);
#else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
@@ -234,6 +236,12 @@ static inline int of_genpd_add_subdomain(struct of_phandle_args *parent,
return -ENODEV;
}
+static inline int of_genpd_parse_idle_states(struct device_node *dn,
+ struct genpd_power_state **states, int *n)
+{
+ return -ENODEV;
+}
+
static inline int genpd_dev_pm_attach(struct device *dev)
{
return -ENODEV;
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/9] PM / Domain: Add residency property to genpd states
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
Residency of a domain's idle state indicates that the minimum idle time
for the domain's idle state to be beneficial for power. Add the
parameter to the state node. Future patches, will use the residency
value in the genpd governor to determine if it is worth while to enter
an idle state.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index de1d8f3..f4492eb 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -38,6 +38,7 @@ struct gpd_dev_ops {
struct genpd_power_state {
s64 power_off_latency_ns;
s64 power_on_latency_ns;
+ s64 residency_ns;
};
struct generic_pm_domain {
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/9] PM / Domains: Make genpd state allocation dynamic
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
Allow PM Domain states to be defined dynamically by the drivers. This
removes the limitation on the maximum number of states possible for a
domain.
Cc: Axel Haslam <ahaslam+renesas@baylibre.com>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
---
arch/arm/mach-imx/gpc.c | 17 ++++++++++-------
drivers/base/power/domain.c | 35 +++++++++++++++++++++++------------
include/linux/pm_domain.h | 5 ++---
3 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 0df062d..57a410b 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -380,13 +380,6 @@ static struct pu_domain imx6q_pu_domain = {
.name = "PU",
.power_off = imx6q_pm_pu_power_off,
.power_on = imx6q_pm_pu_power_on,
- .states = {
- [0] = {
- .power_off_latency_ns = 25000,
- .power_on_latency_ns = 2000000,
- },
- },
- .state_count = 1,
},
};
@@ -430,6 +423,16 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
return 0;
+ imx6q_pu_domain.base.states = devm_kzalloc(dev,
+ sizeof(*imx6q_pu_domain.base.states),
+ GFP_KERNEL);
+ if (!imx6q_pu_domain.base.states)
+ return -ENOMEM;
+
+ imx6q_pu_domain.base.states[0].power_off_latency_ns = 25000;
+ imx6q_pu_domain.base.states[0].power_on_latency_ns = 2000000;
+ imx6q_pu_domain.base.state_count = 1;
+
pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
return of_genpd_add_provider_onecell(dev->of_node,
&imx_gpc_onecell_data);
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e023066..37ab7f1 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1282,6 +1282,21 @@ out:
}
EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
+static int genpd_set_default_power_state(struct generic_pm_domain *genpd)
+{
+ struct genpd_power_state *state;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ genpd->states = state;
+ genpd->state_count = 1;
+ genpd->free = state;
+
+ return 0;
+}
+
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
@@ -1293,6 +1308,8 @@ EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off)
{
+ int ret;
+
if (IS_ERR_OR_NULL(genpd))
return -EINVAL;
@@ -1325,19 +1342,12 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
genpd->dev_ops.start = pm_clk_resume;
}
- if (genpd->state_idx >= GENPD_MAX_NUM_STATES) {
- pr_warn("Initial state index out of bounds.\n");
- genpd->state_idx = GENPD_MAX_NUM_STATES - 1;
- }
-
- if (genpd->state_count > GENPD_MAX_NUM_STATES) {
- pr_warn("Limiting states to %d\n", GENPD_MAX_NUM_STATES);
- genpd->state_count = GENPD_MAX_NUM_STATES;
- }
-
/* Use only one "off" state if there were no states declared */
- if (genpd->state_count == 0)
- genpd->state_count = 1;
+ if (genpd->state_count == 0) {
+ ret = genpd_set_default_power_state(genpd);
+ if (ret)
+ return ret;
+ }
mutex_lock(&gpd_list_lock);
list_add(&genpd->gpd_list_node, &gpd_list);
@@ -1377,6 +1387,7 @@ static int genpd_remove(struct generic_pm_domain *genpd)
list_del(&genpd->gpd_list_node);
mutex_unlock(&genpd->lock);
cancel_work_sync(&genpd->power_off_work);
+ kfree(genpd->free);
pr_debug("%s: removed %s\n", __func__, genpd->name);
return 0;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index a09fe5c..de1d8f3 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -19,8 +19,6 @@
/* Defines used for the flags field in the struct generic_pm_domain */
#define GENPD_FLAG_PM_CLK (1U << 0) /* PM domain uses PM clk */
-#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power states */
-
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
GPD_STATE_POWER_OFF, /* PM domain is off */
@@ -70,9 +68,10 @@ struct generic_pm_domain {
void (*detach_dev)(struct generic_pm_domain *domain,
struct device *dev);
unsigned int flags; /* Bit field of configs for genpd */
- struct genpd_power_state states[GENPD_MAX_NUM_STATES];
+ struct genpd_power_state *states;
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
+ void *free; /* Free the state that was allocated for default */
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/9] PM / Domains: DT support for domain idle states & atomic PM domains
From: Lina Iyer @ 2016-10-24 22:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Changes since v3 [5] -
- Added "domain-idle-state" compatible to arm/idle-states.txt
- Updated documentation for defining PM domain idle states
- Updated documentation for devices and PM domains.
- Updated code to look for "domain-idle-state" instead of "arm,idle-state" compatible.
- The series is available at [6].
Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].
Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].
The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree
Thanks,
Lina
Lina Iyer (9):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states
PM / Domains: Allow domain power states to be read from DT
dt-bindings: add domain-idle-state compatible to arm,idle-state
dt-bindings: Update binding for PM domain idle states
PM / Domains: Save the fwnode in genpd_power_state
PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains
.../devicetree/bindings/arm/idle-states.txt | 3 +
.../devicetree/bindings/power/power_domain.txt | 44 +++
Documentation/power/devices.txt | 14 +-
arch/arm/mach-imx/gpc.c | 17 +-
drivers/base/power/domain.c | 358 +++++++++++++++++----
include/linux/pm_domain.h | 28 +-
6 files changed, 392 insertions(+), 72 deletions(-)
--
2.7.4
[1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
[2]. http://www.spinics.net/lists/arm-kernel/msg535106.html
[3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v2
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v3
[5]. http://www.spinics.net/lists/arm-kernel/msg536181.html
[6]. http://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v4
^ permalink raw reply
* [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Linus Torvalds @ 2016-10-24 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82ad10b1-32ab-3962-d5ab-e787e2c70130@gmail.com>
On Mon, Oct 24, 2016 at 2:27 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> Should we compare the headers added by lists.infradead.org
So for me, it didn't go through infraded.org, but I got it through the
kernel mailing list.
I'll send you the raw email data in private, you can compare it
against your good one.
Linus
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pali Rohár @ 2016-10-24 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024214152.GA32310@amd>
On Monday 24 October 2016 23:41:52 Pavel Machek wrote:
> On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> > Also, the shutdown voltage can depend on external devices
> > connected. It could be for example 3.3V depending on eMMC on some
> > devices while devices with no eMMC could have it at 3.0V.
>
> Actually, I'd like to shutdown at 3.3V or more (like 3.5V), because
> going below that is pretty mean to the battery. But if I set
> threshold too high, GSM activity will push it below that for a very
> short while, and I'll shutdown too soon.
>
> Ideas welcome...
bq27x00 has EDVF flag which means that battery is empty. Maemo with
bq27x00 driver is configured to issue system shutdown when EDVF is set.
Maybe kernel should issue emergency shutdown e.g. after minute or two
after EDVF flag is set?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/80b0cce7/attachment.sig>
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pavel Machek @ 2016-10-24 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024212932.uhjz752z2cy5hohl@atomide.com>
On Mon 2016-10-24 14:29:33, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161024 14:24]:
> > Hi!
> >
> > What about something like this? N900 will drain the battery down to
> > system crash, which is quite uncool.
>
> Can't we make that generic and configurable for the voltage somehow?
I was afraid someone would ask :-).
Yes, we probably need to create battery object in the device tree,
then add properties there.
> Also, the shutdown voltage can depend on external devices connected.
> It could be for example 3.3V depending on eMMC on some devices while
> devices with no eMMC could have it at 3.0V.
Actually, I'd like to shutdown at 3.3V or more (like 3.5V), because
going below that is pretty mean to the battery. But if I set threshold
too high, GSM activity will push it below that for a very short while,
and I'll shutdown too soon.
Ideas welcome...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/eff01459/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 [fix-2]] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-24 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477090375-13814-1-git-send-email-lina.iyer@linaro.org>
Update documentation to reflect the changes made to support IRQ safe PM
domains.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
---
Changes since:
- Updated the text per Rafael's suggestion.
- Updated commit text with signed-off-by
---
Documentation/power/devices.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..73ddea3 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -607,7 +607,9 @@ individually. Instead, a set of devices sharing a power resource can be put
into a low-power state together at the same time by turning off the shared
power resource. Of course, they also need to be put into the full-power state
together, by turning the shared power resource on. A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
Support for power domains is provided through the pm_domain field of struct
device. This field is a pointer to an object of type struct dev_pm_domain,
@@ -629,6 +631,16 @@ support for power domains into subsystem-level callbacks, for example by
modifying the platform bus type. Other platforms need not implement it or take
it into account in any way.
+Devices may be defined as IRQ-safe which indicates to the PM core that their
+runtime PM callbacks may be invoked with disabled interrupts (see
+Documentation/power/runtime_pm.txt for more information). If an IRQ-safe
+device belongs to a PM domain, the runtime PM of the domain will be
+disallowed, unless the domain itself is defined as IRQ-safe. However, it
+makes sense to define a PM domain as IRQ-safe only if all the devices in it
+are IRQ-safe. Moreover, if an IRQ-safe domain has a parent domain, the runtime
+PM of the parent is only allowed if the parent itself is IRQ-safe too with the
+additional restriction that all child domains of an IRQ-safe parent must also
+be IRQ-safe.
Device Low Power (suspend) States
---------------------------------
--
2.7.4
^ permalink raw reply related
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Tony Lindgren @ 2016-10-24 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024212250.GA31336@amd>
* Pavel Machek <pavel@ucw.cz> [161024 14:24]:
> Hi!
>
> What about something like this? N900 will drain the battery down to
> system crash, which is quite uncool.
Can't we make that generic and configurable for the voltage somehow?
Also, the shutdown voltage can depend on external devices connected.
It could be for example 3.3V depending on eMMC on some devices while
devices with no eMMC could have it at 3.0V.
Regards,
Tony
^ permalink raw reply
* [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Florian Fainelli @ 2016-10-24 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFwAZPJ+o0qkYjJziHofYvvsocHuWr1YUmVnzj6VTv_sgA@mail.gmail.com>
On 10/24/2016 01:14 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> The older setup was using smtphost.broadcom.com which we have now
>> documented as being invalid, here Jonathan used gmail directly (since
>> that's our mail provider now):
>>
>> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
>> by smtp.gmail.com with ESMTPSA id
>> s89sm8325746qkl.44.2016.10.24.12.12.00
>> (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
>> Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
>
> Hmm. I get that too, so if that's the right thing for a broadcom.com
> address, it's not the smtp server issue.
>
> We had a few cases of the kernel mailing list itself messing up emails
> sufficiently to fail dkim, but that shouldn't be an issue for the
> relaxed/relaxed model that broadcom uses (the vger mailing list
> software screws up whitespace, which "relaxed" ignores).
>
>> Is there something else we need to check? Here is what I read for the
>> cover-letter:
>>
>> Authentication-Results: mx.google.com;
>> dkim=pass header.i=@broadcom.com;
>> spf=pass (google.com: domain of ...
>
> Hmm. I get:
>
> Authentication-Results: mx.google.com;
> dkim=fail header.i=@broadcom.com;
>
> with the actual dkim signature looking like this:
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=broadcom.com; s=google;
> h=from:to:cc:subject:date:message-id;
> bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
> b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
> agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
> 67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=
>
> and those fields that it protects look like this:
>
> From: Jonathan Richardson <jonathan.richardson@broadcom.com>
> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Maxime
> Ripard <maxime.ripard@free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org,
> linux-kernel at vger.kernel.org, devicetree at vger.kernel.org, Mark Rutland
> <mark.rutland@arm.com>, Rob Herring <robh+dt@kernel.org>, Scott
> Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>,
> bcm-kernel-feedback-list at broadcom.com, Jonathan Richardson
> <jonathan.richardson@broadcom.com>
> Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
> Date: Mon, 24 Oct 2016 12:12:01 -0700
> Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>
>
> and I don't see anything obviously wrong anywhere - except for that
> "dkim=fail" thing, and the email being in my spam folder.
Should we compare the headers added by lists.infradead.org and see what
could possibly go wrong here? I can see that by being delivered to
lists.infradead.org and then back to my personal gmail.com (not my other
broadcom.com account), there are a bunch of extra headers:
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20161024_121226_013940_81319C20
X-CRM114-Status: GOOD ( 13.05 )
X-Spam-Score: -2.7 (--)
X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary:
Content analysis details: (-2.7 points)
pts rule name description
---- ----------------------
--------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at
http://www.dnswl.org/, low
trust [2607:f8b0:400d:c09:0:0:0:22f listed in] [list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
X-BeenThere: linux-arm-kernel at lists.infradead.org
X-Mailman-Version: 2.1.20
Precedence: list
Would those be used by your mail client to put this mail in spam, or was
that done by the linux-foundation.org (also gmail?) mail upon reception?
--
Florian
^ permalink raw reply
* [RFC] shutdown machine when li-ion battery goes below 3V
From: Pavel Machek @ 2016-10-24 21:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
What about something like this? N900 will drain the battery down to
system crash, which is quite uncool.
Pavel
diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
index 0fe278b..8eb2f8f 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -46,6 +46,7 @@
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
+#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/of.h>
@@ -740,6 +741,9 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
}
EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
+static int bq27xxx_battery_protect(struct bq27xxx_device_info *di);
+
+
static void bq27xxx_battery_poll(struct work_struct *work)
{
struct bq27xxx_device_info *di =
@@ -747,6 +751,7 @@ static void bq27xxx_battery_poll(struct work_struct *work)
work.work);
bq27xxx_battery_update(di);
+ bq27xxx_battery_protect(di);
if (poll_interval > 0)
schedule_delayed_work(&di->work, poll_interval * HZ);
@@ -958,6 +963,41 @@ static int bq27xxx_battery_get_property(struct power_supply *psy,
return ret;
}
+static int bq27xxx_battery_protect(struct bq27xxx_device_info *di)
+{
+ union power_supply_propval val;
+ int mV, mA, mOhm = 430, mVadj;
+ int res;
+
+ printk(KERN_INFO "Main battery check\n");
+
+ res = bq27xxx_battery_voltage(di, &val);
+ if (res)
+ return res;
+
+ mV = val.intval / 1000;
+
+ if (mV < 2950) {
+ printk(KERN_ALERT "Main battery below 2.95V, forcing shutdown.\n");
+ orderly_poweroff(true);
+ }
+
+ res = bq27xxx_battery_current(di, &val);
+ if (res)
+ return res;
+
+ mA = val.intval / 1000;
+ mVadj = mV + (mA * mOhm) / 1000;
+
+ if (mVadj < 3150) {
+ printk(KERN_ALERT "Main battery internal voltage below 3.15, shutdown.\n");
+ orderly_poweroff(true);
+ }
+ printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
+ mV, mVadj);
+ return 0;
+}
+
static void bq27xxx_external_power_changed(struct power_supply *psy)
{
struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 226b0b4ac..bcdc1f8 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -444,7 +444,7 @@ static void handle_critical_trips(struct thermal_zone_device *tz,
if (trip_type == THERMAL_TRIP_CRITICAL) {
dev_emerg(&tz->device,
- "critical temperature reached(%d C),shutting down\n",
+ "critical temperature reached(%d C), shutting down\n",
tz->temperature / 1000);
orderly_poweroff(true);
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/5e57183f/attachment.sig>
^ permalink raw reply related
* [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Rafael J. Wysocki @ 2016-10-24 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024161605.GD72940@linaro.org>
On Monday, October 24, 2016 10:16:05 AM Lina Iyer wrote:
> On Sat, Oct 22 2016 at 18:19 -0600, Rafael J. Wysocki wrote:
> >On Friday, October 21, 2016 03:52:55 PM Lina Iyer wrote:
> >> Update documentation to reflect the changes made to support IRQ safe PM
> >> domains.
> >>
> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> >> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> >> ---
> >> Changes since v3:
> >> - Moved para to the end of the section
> >> - Added clause for all IRQ safe devices in a domain
> >> - Cleanup explanation of nested domains
> >> ---
> >> Documentation/power/devices.txt | 11 ++++++++++-
> >> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
> >> index 8ba6625..9218ce6 100644
> >> --- a/Documentation/power/devices.txt
> >> +++ b/Documentation/power/devices.txt
> >> @@ -607,7 +607,9 @@ individually. Instead, a set of devices sharing a power resource can be put
> >> into a low-power state together at the same time by turning off the shared
> >> power resource. Of course, they also need to be put into the full-power state
> >> together, by turning the shared power resource on. A set of devices with this
> >> -property is often referred to as a power domain.
> >> +property is often referred to as a power domain. A power domain may also be
> >> +nested inside another power domain. The nested domain is referred to as the
> >> +sub-domain of the parent domain.
> >>
> >> Support for power domains is provided through the pm_domain field of struct
> >> device. This field is a pointer to an object of type struct dev_pm_domain,
> >> @@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
> >> modifying the platform bus type. Other platforms need not implement it or take
> >> it into account in any way.
> >>
> >> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
> >> +on/off even when the IRQs are disabled.
> >
> >What IRQ-safe means for devices is that their runtime PM callbacks may be
> >invoked with interrupts disabled on the local CPU. I guess the meaning of
> >IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.
> >
> >> An IRQ-safe device in a domain will
> >> +disallow power management on the domain, unless the domain is also defined as
> >> +IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
> >> +be defined as IRQ-safe. Another restriction this framework imposes on the
> >> +parent domain of an IRQ-safe domain is that the parent domain must also be
> >> +defined as IRQ-safe.
> >
> >What about this:
> >
> >"Devices may be defined as IRQ-safe which indicates to the PM core that their
> >runtime PM callbacks may be invoked with disabled interrupts (see
> >Documentation/power/runtime_pm.txt for more information). If an IRQ-safe
> >device belongs to a PM domain, the runtime PM of the domain will be disallowed,
> >unless the domain itself is defined as IRQ-safe. However, a PM domain can only
> >be defined as IRQ-safe if all of the devices in it are IRQ-safe.
> >
> This is correct. But the last line may need a bit of modification. If
> all devices in a PM domain are IRQ-safe and the domain is NOT, then it
> it is a valid combination just that the domain would never do runtime
> PM.
That doesn't contradict the last sentence of mine above. I guess what you mean
is that having a non-IRQ-safe device in an IRQ-safe domain is a valid
configuration. I wonder how it works then. :-)
In any case, what about changing that sentence to something like:
"However, it only makes sense to define a PM domain as IRQ-safe if all devices
in it are IRQ-safe."
Thanks,
Rafael
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-24 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b6cd3c47-0df8-266a-2b8d-13c82062b647@lechnology.com>
On 10/24/2016 02:50 PM, David Lechner wrote:
> On 10/24/2016 10:50 AM, David Lechner wrote:
>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>
>>>> +&ehrpwm1 {
>>>> + status = "disabled";
>>>
>>> Hmm, disabled? Can you add this node when you actually use it?
>>
>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>> via sysfs, so I would like to leave them.
>>
>
> Now I remember why these are disabled. The clock matching is broken.
> Only the first ehrpwm and the first ecap get clocks. The others fail.
>
> I can change these to "okay". It will just result in a kernel error
> message until the clocks are fixed.
>
correction: it is not the clocks that are broken. it is the device names.
In arch/arm/mach-davinci/da8xx-dt.c, we have...
OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
Which causes each device to have the same device node name. This causes
sysfs errors because it is trying to register a second device at the
same sysfs path.
If you change the names here, then the device do not work because the
clock lookup fails.
^ permalink raw reply
* [PATCH v3 [fix]] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-24 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3700155.5AlzjeyN5H@vostro.rjw.lan>
On Mon, Oct 24 2016 at 15:15 -0600, Rafael J. Wysocki wrote:
>On Monday, October 24, 2016 10:16:05 AM Lina Iyer wrote:
>> On Sat, Oct 22 2016 at 18:19 -0600, Rafael J. Wysocki wrote:
>> >On Friday, October 21, 2016 03:52:55 PM Lina Iyer wrote:
>> >> Update documentation to reflect the changes made to support IRQ safe PM
>> >> domains.
>> >>
>> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> >> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >> ---
>> >> Changes since v3:
>> >> - Moved para to the end of the section
>> >> - Added clause for all IRQ safe devices in a domain
>> >> - Cleanup explanation of nested domains
>> >> ---
>> >> Documentation/power/devices.txt | 11 ++++++++++-
>> >> 1 file changed, 10 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> >> index 8ba6625..9218ce6 100644
>> >> --- a/Documentation/power/devices.txt
>> >> +++ b/Documentation/power/devices.txt
>> >> @@ -607,7 +607,9 @@ individually. Instead, a set of devices sharing a power resource can be put
>> >> into a low-power state together at the same time by turning off the shared
>> >> power resource. Of course, they also need to be put into the full-power state
>> >> together, by turning the shared power resource on. A set of devices with this
>> >> -property is often referred to as a power domain.
>> >> +property is often referred to as a power domain. A power domain may also be
>> >> +nested inside another power domain. The nested domain is referred to as the
>> >> +sub-domain of the parent domain.
>> >>
>> >> Support for power domains is provided through the pm_domain field of struct
>> >> device. This field is a pointer to an object of type struct dev_pm_domain,
>> >> @@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
>> >> modifying the platform bus type. Other platforms need not implement it or take
>> >> it into account in any way.
>> >>
>> >> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> >> +on/off even when the IRQs are disabled.
>> >
>> >What IRQ-safe means for devices is that their runtime PM callbacks may be
>> >invoked with interrupts disabled on the local CPU. I guess the meaning of
>> >IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.
>> >
>> >> An IRQ-safe device in a domain will
>> >> +disallow power management on the domain, unless the domain is also defined as
>> >> +IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
>> >> +be defined as IRQ-safe. Another restriction this framework imposes on the
>> >> +parent domain of an IRQ-safe domain is that the parent domain must also be
>> >> +defined as IRQ-safe.
>> >
>> >What about this:
>> >
>> >"Devices may be defined as IRQ-safe which indicates to the PM core that their
>> >runtime PM callbacks may be invoked with disabled interrupts (see
>> >Documentation/power/runtime_pm.txt for more information). If an IRQ-safe
>> >device belongs to a PM domain, the runtime PM of the domain will be disallowed,
>> >unless the domain itself is defined as IRQ-safe. However, a PM domain can only
>> >be defined as IRQ-safe if all of the devices in it are IRQ-safe.
>> >
>> This is correct. But the last line may need a bit of modification. If
>> all devices in a PM domain are IRQ-safe and the domain is NOT, then it
>> it is a valid combination just that the domain would never do runtime
>> PM.
>
>That doesn't contradict the last sentence of mine above. I guess what you mean
>is that having a non-IRQ-safe device in an IRQ-safe domain is a valid
>configuration. I wonder how it works then. :-)
>
>In any case, what about changing that sentence to something like:
>
>"However, it only makes sense to define a PM domain as IRQ-safe if all devices
>in it are IRQ-safe."
>
That's precise. I will add your para instead of mine to the
documentation.
Thanks,
Lina
>
^ permalink raw reply
* [PATCH v3 3/8] PM / Domains: Allow domain power states to be read from DT
From: Lina Iyer @ 2016-10-24 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12435f67-bcb6-33b5-4399-f4f628f70be8@arm.com>
On Mon, Oct 24 2016 at 11:27 -0600, Sudeep Holla wrote:
>
>
>On 24/10/16 17:48, Lina Iyer wrote:
>>Hi Sudeep,
>>
>>On Mon, Oct 24 2016 at 07:39 -0600, Sudeep Holla wrote:
>>>
>>>
>>>On 14/10/16 18:47, Lina Iyer wrote:
>>>>This patch allows domains to define idle states in the DT. SoC's can
>>>>define domain idle states in DT using the "domain-idle-states" property
>>>>of the domain provider. Add API to read the idle states from DT that can
>>>>be set in the genpd object.
>>>>
>>>>This patch is based on the original patch by Marc Titinger.
>>>>
>>>>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>>>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>>>---
>>>>drivers/base/power/domain.c | 94
>>>>+++++++++++++++++++++++++++++++++++++++++++++
>>>>include/linux/pm_domain.h | 8 ++++
>>>>2 files changed, 102 insertions(+)
>>>>
>>>>diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>>>>index 37ab7f1..9af75ba 100644
>>>>--- a/drivers/base/power/domain.c
>>>>+++ b/drivers/base/power/domain.c
>>>>@@ -1916,6 +1916,100 @@ out:
>>>> return ret ? -EPROBE_DEFER : 0;
>>>>}
>>>>EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>>>>+
>>>>+static const struct of_device_id idle_state_match[] = {
>>>>+ { .compatible = "arm,idle-state", },
>>>>+ { }
>>>>+};
>>>>+
>>>
>>>I still think it's better to have another compatible to serve this
>>>purpose. We don't want to end up creating genpd domains just because
>>>they are "arm,idle-state" compatible IMO ?
>>>
>>>I agree you can prevent it checking for OSC mode support in the
>>>firmware. But I want to understand if you have any strong reasons for
>>>avoiding that approach.
>>>
>>Why are you still held up with OSI/PC PSCI modes?
>
>I am just pointing that out to make sure you are not defining these
>DT bindings with just QCOM platform and OSC in consideration.
>
>I am thinking about how can it be used/extended in other use-cases.
>
>>I repeat again this
>>series is not about any of that, it is just about PM domains.
>
>I completely understand that, no argument on that. What I worry is that
>if a system(in future) represents this power domains and domain idles
>states and doesn't want to create a genpd, do we have to handle it
>differently or even the way your CPUidle series would do or can we say
>those states need to specify that they are compatible with the new
>feature(the one being added in this series) with a new compatible.
>I prefer the latter than the former to avoid all possible workarounds
>in future.
>
>>PM domains
>>have idle states and the idle-state description is similar in definition
>>to arm,idle-state and therefore uses the same compatible. There is no
>>point re-defining something that already exists in the kernel.
>>
>
>Yes I understand that but "arm,idle-states" were not defined with this
>feature in mind and hence I am bit worried if it could cause any issue
>especially if deprecate cpu-idle-states and move to this model
>completely. I really don't like this mix and hence I am raising the
>concern here. I am trying to ease that migration.
>
>>I was able to find the original thread, where we discussed this [1].
>>
>>I suggest, you read about PM domains and its idle states and understand
>>this series in the context of PM domains.
>>
>
>Sure, will do that. Thanks for pointing that out. But the concern I am
>raising is entirely different. I am asking if this re-use will cause any
>issue in future as pointed out above.
>
>I re-iterate that I understand this series is independent of the CPUIdle
>and hence asking why not make it completely independent by just adding
>the new compatible.
>
>I am *not asking to redefine something completely*. What I am saying is
>*just* to add new compatible that may(for cpu devices)/may not(for
>other/non-CPU devices) be used along with "arm,idle-state".
>
I am fine with that, as long as the compatible string is an alternate
for "arm,idle-state" it shouldn't be a problem.
Any recommendations?
Thanks,
Lina
>I may be too paranoid here but I think that's safer. It helps to skip
>creating of genpd if required for some domains as I had explained before.
>
>--
>Regards,
>Sudeep
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-24 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024060226.4170-1-mugunthanvnm@ti.com>
> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>
> Increase ADC reference clock from 3MHz to 24MHz so that the
> sampling rates goes up from 100K samples per second to 800K
> samples per second on AM335x and AM437x SoC.
>
> Also increase opendelay for touchscreen configuration to
> equalize the increase in ADC reference clock frequency,
> which results in the same amount touch events reported via
> evtest on AM335x GP EVM.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
>
> This patch depends on ADC DMA patch series [1]
>
> Without DMA support, when ADC ref clock is set at 24MHz, I am
> seeing fifo overflow as CPU is not able to pull the ADC samples.
> This answers that DMA support is must for ADC to consume the
> samples generated at 24MHz with no open, step delay or
> averaging with patch [2].
>
> Measured the performance with the iio_generic_buffer with the
> patch [3] applied
>
> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
> [2] - http://pastebin.ubuntu.com/23357935/
> [3] - http://pastebin.ubuntu.com/23357939/
>
> ---
> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> index b9a53e0..96c4207 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -90,7 +90,7 @@
> /* Delay register */
> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
> #define STEPDELAY_OPEN(val) ((val) << 0)
> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
Wouldn?t this be better to add this to the devicetree?
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
Regards,
John
> +#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x500)
> #define STEPDELAY_SAMPLE_MASK (0xFF << 24)
> #define STEPDELAY_SAMPLE(val) ((val) << 24)
> #define STEPCONFIG_SAMPLEDLY STEPDELAY_SAMPLE(0)
> @@ -137,7 +137,7 @@
> #define SEQ_STATUS BIT(5)
> #define CHARGE_STEP 0x11
>
> -#define ADC_CLK 3000000
> +#define ADC_CLK 24000000
> #define TOTAL_STEPS 16
> #define TOTAL_CHANNELS 8
> #define FIFO1_THRESHOLD 19
> --
> 2.10.1.502.g6598894
>
^ permalink raw reply
* [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Thomas Gleixner @ 2016-10-24 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fbc51a32-aaba-0ee6-c0bd-07a02fb2a6b4@arm.com>
On Mon, 24 Oct 2016, Marc Zyngier wrote:
> On 22/10/16 05:54, Geetha sowjanya wrote:
> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> > index be3c34e..6add8da 100644
> > --- a/kernel/irq/chip.c
> > +++ b/kernel/irq/chip.c
> > @@ -585,6 +585,10 @@ void handle_fasteoi_irq(struct irq_desc *desc)
> > goto out;
> > }
> >
> > +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> > + if (chip->irq_ack)
> > + chip->irq_ack(&desc->irq_data);
> > +#endif
> > kstat_incr_irqs_this_cpu(desc);
> > if (desc->istate & IRQS_ONESHOT)
> > mask_irq(desc);
> >
>
> Overall, this workaround is not acceptable as it is.
Aside of being not acceptable this thing is completely broken.
If that erratum is enabled then a interrupt chip which implements both EOI
and ACK callbacks will issue irq_ack when using the fasteoi handler. While
this might work on that cavium trainwreck, it will just make other
platforms pretty unhappy.
Platform specific hacks have no place in the core code at all. We have
enough options to handle oddball hardware, you just have to use them.
Thanks,
tglx
^ permalink raw reply
* [PATCH V4 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Baicar, Tyler @ 2016-10-24 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da257bb4-48f3-b187-1d43-c68669427cef@arm.com>
On 10/24/2016 3:50 AM, Suzuki K Poulose wrote:
> On 21/10/16 18:30, Tyler Baicar wrote:
>> Currently when a RAS error is reported it is not timestamped.
>> The ACPI 6.1 spec adds the timestamp field to the generic error
>> data entry v3 structure. The timestamp of when the firmware
>> generated the error is now being reported.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> drivers/acpi/apei/ghes.c | 14 +++++++---
>> drivers/firmware/efi/cper.c | 67
>> +++++++++++++++++++++++++++++++++++++--------
>> include/acpi/ghes.h | 10 +++++++
>> include/linux/cper.h | 12 ++++++++
>> 4 files changed, 88 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 7d020b0..7610f08 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -419,7 +419,8 @@ static void ghes_handle_memory_failure(struct
>> acpi_hest_generic_data *gdata, int
>> int flags = -1;
>> int sec_sev = ghes_severity(gdata->error_severity);
>> struct cper_sec_mem_err *mem_err;
>> - mem_err = (struct cper_sec_mem_err *)(gdata + 1);
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>>
>> if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
>> return;
>> @@ -449,14 +450,18 @@ static void ghes_do_proc(struct ghes *ghes,
>> {
>> int sev, sec_sev;
>> struct acpi_hest_generic_data *gdata;
>> + uuid_le sec_type;
>>
>> sev = ghes_severity(estatus->error_severity);
>> apei_estatus_for_each_section(estatus, gdata) {
>> sec_sev = ghes_severity(gdata->error_severity);
>> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
>> + sec_type = *(uuid_le *)gdata->section_type;
>> +
>> + if (!uuid_le_cmp(sec_type,
>> CPER_SEC_PLATFORM_MEM)) {
>> struct cper_sec_mem_err *mem_err;
>> - mem_err = (struct cper_sec_mem_err *)(gdata+1);
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>> ghes_edac_report_mem_error(ghes, sev, mem_err);
>>
>> arch_apei_report_mem_error(sev, mem_err);
>> @@ -466,7 +471,8 @@ static void ghes_do_proc(struct ghes *ghes,
>> else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
>> CPER_SEC_PCIE)) {
>> struct cper_sec_pcie *pcie_err;
>> - pcie_err = (struct cper_sec_pcie *)(gdata+1);
>> +
>> + pcie_err = acpi_hest_generic_data_payload(gdata);
>> if (sev == GHES_SEV_RECOVERABLE &&
>> sec_sev == GHES_SEV_RECOVERABLE &&
>> pcie_err->validation_bits &
>> CPER_PCIE_VALID_DEVICE_ID &&
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index d425374..af7e1e9 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -32,6 +32,9 @@
>> #include <linux/acpi.h>
>> #include <linux/pci.h>
>> #include <linux/aer.h>
>> +#include <linux/printk.h>
>> +#include <linux/bcd.h>
>> +#include <acpi/ghes.h>
>>
>> #define INDENT_SP " "
>>
>> @@ -386,13 +389,37 @@ static void cper_print_pcie(const char *pfx,
>> const struct cper_sec_pcie *pcie,
>> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
>> }
>>
>> +static void cper_estatus_print_section_v300(const char *pfx,
>> + const struct acpi_hest_generic_data_v300 *gdata)
>> +{
>> + __u8 hour, min, sec, day, mon, year, century, *timestamp;
>> +
>> + if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
>> + timestamp = (__u8 *)&(gdata->time_stamp);
>> + sec = bcd2bin(timestamp[0]);
>> + min = bcd2bin(timestamp[1]);
>> + hour = bcd2bin(timestamp[2]);
>> + day = bcd2bin(timestamp[4]);
>> + mon = bcd2bin(timestamp[5]);
>> + year = bcd2bin(timestamp[6]);
>> + century = bcd2bin(timestamp[7]);
>> + printk("%stime: %7s %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
>> + 0x01 & *(timestamp + 3) ? "precise" : "", century,
>> + year, mon, day, hour, min, sec);
>> + }
>> +}
>> +
>> static void cper_estatus_print_section(
>> - const char *pfx, const struct acpi_hest_generic_data *gdata, int
>> sec_no)
>> + const char *pfx, struct acpi_hest_generic_data *gdata, int sec_no)
>> {
>> uuid_le *sec_type = (uuid_le *)gdata->section_type;
>> __u16 severity;
>> char newpfx[64];
>>
>> + if (acpi_hest_generic_data_version(gdata))
>> + cper_estatus_print_section_v300(pfx,
>> + (const struct acpi_hest_generic_data_v300 *)gdata);
>> +
>> severity = gdata->error_severity;
>> printk("%s""Error %d, type: %s\n", pfx, sec_no,
>> cper_severity_str(severity));
>> @@ -403,14 +430,18 @@ static void cper_estatus_print_section(
>>
>> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
>> - struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
>> + struct cper_sec_proc_generic *proc_err;
>> +
>> + proc_err = acpi_hest_generic_data_payload(gdata);
>> printk("%s""section_type: general processor error\n", newpfx);
>> if (gdata->error_data_length >= sizeof(*proc_err))
>> cper_print_proc_generic(newpfx, proc_err);
>> else
>> goto err_section_too_small;
>> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
>> - struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
>> + struct cper_sec_mem_err *mem_err;
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>> printk("%s""section_type: memory error\n", newpfx);
>> if (gdata->error_data_length >=
>> sizeof(struct cper_sec_mem_err_old))
>> @@ -419,7 +450,9 @@ static void cper_estatus_print_section(
>> else
>> goto err_section_too_small;
>> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
>> - struct cper_sec_pcie *pcie = (void *)(gdata + 1);
>> + struct cper_sec_pcie *pcie;
>> +
>> + pcie = acpi_hest_generic_data_payload(gdata);
>> printk("%s""section_type: PCIe error\n", newpfx);
>> if (gdata->error_data_length >= sizeof(*pcie))
>> cper_print_pcie(newpfx, pcie, gdata);
>> @@ -438,6 +471,7 @@ void cper_estatus_print(const char *pfx,
>> const struct acpi_hest_generic_status *estatus)
>> {
>> struct acpi_hest_generic_data *gdata;
>> + struct acpi_hest_generic_data_v300 *gdata_v3 = NULL;
>> unsigned int data_len, gedata_len;
>> int sec_no = 0;
>> char newpfx[64];
>> @@ -451,12 +485,22 @@ void cper_estatus_print(const char *pfx,
>> printk("%s""event severity: %s\n", pfx,
>> cper_severity_str(severity));
>> data_len = estatus->data_length;
>> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
>> + if (acpi_hest_generic_data_version(gdata))
>> + gdata_v3 = (struct acpi_hest_generic_data_v300 *)gdata;
>
> I think the acpi_hest_generic_data_version() doesn't check if the
> version is
> V3 or higher ?
Oops :) I need to make sure that returns 3.
>
>> +
>> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> +
>> while (data_len >= sizeof(*gdata)) {
>> gedata_len = gdata->error_data_length;
>> cper_estatus_print_section(newpfx, gdata, sec_no);
>> - data_len -= gedata_len + sizeof(*gdata);
>> - gdata = (void *)(gdata + 1) + gedata_len;
>> + if(gdata_v3) {
>> + data_len -= gedata_len + sizeof(*gdata_v3);
>> + gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
>> + gdata = (struct acpi_hest_generic_data *)gdata_v3;
>> + } else {
>> + data_len -= gedata_len + sizeof(*gdata);
>> + gdata = (void *)(gdata + 1) + gedata_len;
>> + }
>
> Could we not use the helpers we define below to unify the code here
> and avoid the
> switch ?
>
Yes, those helpers should be able to reduce the code here, I'll update this.
>
>> sec_no++;
>> }
>> }
>> @@ -486,12 +530,13 @@ int cper_estatus_check(const struct
>> acpi_hest_generic_status *estatus)
>> return rc;
>> data_len = estatus->data_length;
>> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
>> - while (data_len >= sizeof(*gdata)) {
>> - gedata_len = gdata->error_data_length;
>> - if (gedata_len > data_len - sizeof(*gdata))
>> +
>> + while (data_len >= acpi_hest_generic_data_size(gdata)) {
>> + gedata_len = acpi_hest_generic_data_error_length(gdata);
>> + if (gedata_len > data_len - acpi_hest_generic_data_size(gdata))
>> return -EINVAL;
>> - data_len -= gedata_len + sizeof(*gdata);
>> - gdata = (void *)(gdata + 1) + gedata_len;
>> + data_len -= gedata_len + acpi_hest_generic_data_size(gdata);
>> + gdata = acpi_hest_generic_data_next(gdata);
>> }
>> if (data_len)
>> return -EINVAL;
>> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
>> index 68f088a..56b9679 100644
>> --- a/include/acpi/ghes.h
>> +++ b/include/acpi/ghes.h
>> @@ -73,3 +73,13 @@ static inline void ghes_edac_unregister(struct
>> ghes *ghes)
>> {
>> }
>> #endif
>> +
>> +#define acpi_hest_generic_data_version(gdata) \
>> + (gdata->revision >> 8)
>> +
>
>
>>
>> +#define acpi_hest_generic_data_error_length(gdata) \
>> + (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
>> +#define acpi_hest_generic_data_size(gdata) \
>> + ((acpi_hest_generic_data_version(gdata) >= 3) ? \
>> + sizeof(struct acpi_hest_generic_data_v300) : \
>> + sizeof(struct acpi_hest_generic_data))
>> +#define acpi_hest_generic_data_record_size(gdata) \
>> + (acpi_hest_generic_data_size(gdata) + \
>> + acpi_hest_generic_data_error_length(gdata))
>> +#define acpi_hest_generic_data_next(gdata) \
>> + ((void *)(gdata) + acpi_hest_generic_data_record_size(gdata))
>> +
>
> Rest looks good
>
> Cheers
> Suzuki
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ahci: use pci_alloc_irq_vectors
From: David Daney @ 2016-10-24 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
On 10/22/2016 07:11 AM, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
>
> If so can you try the patch below?
>
After better understanding your request, I applied this against:
http://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/log/?h=for-4.9-fixes
(commit a478b097474cd9f2268ab1beaca74ff09e652b9b)
This is now working on my ThunderX CRB-2S system.
You can add:
Tested-by: David Daney <david.daney@cavium.com>
Thanks for taking the time to work through this.
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH V4 01/10] acpi: apei: read ack upon ghes record consumption
From: Baicar, Tyler @ 2016-10-24 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b4b69d66-ae37-a528-d64c-ee9b3fe7b02c@arm.com>
On 10/24/2016 2:51 AM, Suzuki K Poulose wrote:
> On 21/10/16 18:30, Tyler Baicar wrote:
>> A RAS (Reliability, Availability, Serviceability) controller
>> may be a separate processor running in parallel with OS
>> execution, and may generate error records for consumption by
>> the OS. If the RAS controller produces multiple error records,
>> then they may be overwritten before the OS has consumed them.
>>
>> The Generic Hardware Error Source (GHES) v2 structure
>> introduces the capability for the OS to acknowledge the
>> consumption of the error record generated by the RAS
>> controller. A RAS controller supporting GHESv2 shall wait for
>> the acknowledgment before writing a new error record, thus
>> eliminating the race condition.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> drivers/acpi/apei/ghes.c | 42
>> ++++++++++++++++++++++++++++++++++++++++++
>> drivers/acpi/apei/hest.c | 7 +++++--
>> include/acpi/ghes.h | 5 ++++-
>> 3 files changed, 51 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 60746ef..7d020b0 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -45,6 +45,7 @@
>> #include <linux/aer.h>
>> #include <linux/nmi.h>
>>
>> +#include <acpi/actbl1.h>
>> #include <acpi/ghes.h>
>> #include <acpi/apei.h>
>> #include <asm/tlbflush.h>
>> @@ -79,6 +80,10 @@
>> ((struct acpi_hest_generic_status *) \
>> ((struct ghes_estatus_node *)(estatus_node) + 1))
>>
>> +#define HEST_TYPE_GENERIC_V2(ghes) \
>> + ((struct acpi_hest_header *)ghes->generic)->type == \
>> + ACPI_HEST_TYPE_GENERIC_ERROR_V2
>> +
>> /*
>> * This driver isn't really modular, however for the time being,
>> * continuing to use module_param is the easiest way to remain
>> @@ -248,7 +253,15 @@ static struct ghes *ghes_new(struct
>> acpi_hest_generic *generic)
>> ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
>> if (!ghes)
>> return ERR_PTR(-ENOMEM);
>> +
>> ghes->generic = generic;
>> + if (HEST_TYPE_GENERIC_V2(ghes)) {
>> + rc = apei_map_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>> + if (rc)
>> + goto err_unmap;
>
> I think should be goto err_free, see more below.
>
>> + }
>> +
>> rc = apei_map_generic_address(&generic->error_status_address);
>> if (rc)
>> goto err_free;
>> @@ -270,6 +283,9 @@ static struct ghes *ghes_new(struct
>> acpi_hest_generic *generic)
>>
>> err_unmap:
>> apei_unmap_generic_address(&generic->error_status_address);
>> + if (HEST_TYPE_GENERIC_V2(ghes))
>> + apei_unmap_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>
> We might end up trying to unmap (error_status_address) which is not
> mapped
> if we hit the error in mapping read_ack_register. The
> read_ack_register unmap
> hunk should be moved below to err_free.
>
This needs to be changed, I'll add a separate label for unmapping
read_ack_register and error_status_address for the case that the
read_ack_register map succeeds but the error_status_address map fails.
err_unmap_status_addr:
apei_unmap_generic_address(&generic->error_status_address);
err_unmap_read_ack_addr:
if (HEST_TYPE_GENERIC_V2(ghes))
apei_unmap_generic_address(
&ghes->generic_v2->read_ack_register);
err_free:
kfree(ghes);
return ERR_PTR(rc);
If mapping read_ack_register fails, goto err_free.
If mapping read_ack_register is successful but mapping
error_status_address fails, goto err_unmap_read_ack_addr.
And if both mappings succeed but the kmalloc fails, then goto
err_unmap_status_addr.
>
>> err_free:
>> kfree(ghes);
>> return ERR_PTR(rc);
>> @@ -279,6 +295,9 @@ static void ghes_fini(struct ghes *ghes)
>> {
>> kfree(ghes->estatus);
>> apei_unmap_generic_address(&ghes->generic->error_status_address);
>> + if (HEST_TYPE_GENERIC_V2(ghes))
>> + apei_unmap_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>> }
>>
>> static inline int ghes_severity(int severity)
>> @@ -648,6 +667,23 @@ static void ghes_estatus_cache_add(
>> rcu_read_unlock();
>> }
>>
>
>> +static int ghes_do_read_ack(struct acpi_hest_generic_v2 *generic_v2)
>
> nit: We are actually writing something to the read_ack_register. The
> names
> read_ack_register (which may be as per standard) and more importantly the
> function name (ghes_do_read_ack) sounds a bit misleading.
It is called "Read Ack Register" in the spec (ACPI 6.1 table 18-344),
but I agree the function name can be improved.
Maybe ghes_acknowledge_error or ghes_ack_error.
Thanks,
Tyler
>
> Rest looks fine to me.
>
> Suzuki
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
From: Rafael J. Wysocki @ 2016-10-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZvUh0Z0kxu+WmvwqH3kuaOxaP1Cgxv0WUE2PT-eLs62w@mail.gmail.com>
On Mon, Oct 24, 2016 at 9:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Oct 19, 2016 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> I don't see any hard dependency here, so I'd suggest to merge the
>> two cpufreq patches through the subsystem tree, and the ARM patches
>> through arm-soc.
>
> That's right, Viresh can you merge patches 1 and 5 to the
> cpufreq tree please?
Well, that would be me.
Can you please resend the two as a separate series, with all tags
collected so far if any?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Linus Torvalds @ 2016-10-24 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e34f01b6-a059-9988-0f93-e5adb82a5436@gmail.com>
On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> The older setup was using smtphost.broadcom.com which we have now
> documented as being invalid, here Jonathan used gmail directly (since
> that's our mail provider now):
>
> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
> by smtp.gmail.com with ESMTPSA id
> s89sm8325746qkl.44.2016.10.24.12.12.00
> (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
> Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
Hmm. I get that too, so if that's the right thing for a broadcom.com
address, it's not the smtp server issue.
We had a few cases of the kernel mailing list itself messing up emails
sufficiently to fail dkim, but that shouldn't be an issue for the
relaxed/relaxed model that broadcom uses (the vger mailing list
software screws up whitespace, which "relaxed" ignores).
> Is there something else we need to check? Here is what I read for the
> cover-letter:
>
> Authentication-Results: mx.google.com;
> dkim=pass header.i=@broadcom.com;
> spf=pass (google.com: domain of ...
Hmm. I get:
Authentication-Results: mx.google.com;
dkim=fail header.i=@broadcom.com;
with the actual dkim signature looking like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=broadcom.com; s=google;
h=from:to:cc:subject:date:message-id;
bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=
and those fields that it protects look like this:
From: Jonathan Richardson <jonathan.richardson@broadcom.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Maxime
Ripard <maxime.ripard@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org,
linux-kernel at vger.kernel.org, devicetree at vger.kernel.org, Mark Rutland
<mark.rutland@arm.com>, Rob Herring <robh+dt@kernel.org>, Scott
Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>,
bcm-kernel-feedback-list at broadcom.com, Jonathan Richardson
<jonathan.richardson@broadcom.com>
Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
Date: Mon, 24 Oct 2016 12:12:01 -0700
Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>
and I don't see anything obviously wrong anywhere - except for that
"dkim=fail" thing, and the email being in my spam folder.
Linus
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-10-24 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKzfze9uvMvrF=gWph_HKFk_cH0qzRz6Wa2VJafK+H+wdnP0rg@mail.gmail.com>
On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
> Pavel + Sebastian this is the patchset that need I some input on :)
Better then previous one.
But my version of bq27xxx_battery.c already contains this:
static const struct kernel_param_ops param_ops_poll_interval = {
.get = param_get_uint,
.set = poll_interval_param_set,
};
...so it should be possible to set poll interval already.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/31406715/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox