your patch "mm: Remove false WARN_ON from pagecache_isize_extended()"
Jan,
having run into that warning too, I looked into it a little, and now
having found that patch am pretty uncertain: Both truncate_setsize()
and pagecache_isize_extended() document that they want to be
called with i_mutex held, so removing the WARN_ON() alone seems
either incomplete or wrong. What I found to work without violating
this documented requirement is the patch below.
Jan
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -797,7 +797,7 @@ xfs_file_fallocate(
FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE))
return -EOPNOTSUPP;
- xfs_ilock(ip, XFS_IOLOCK_EXCL);
+ xfs_rw_ilock(ip, XFS_IOLOCK_EXCL);
if (mode & FALLOC_FL_PUNCH_HOLE) {
error = xfs_free_file_space(ip, offset, len);
if (error)
@@ -877,7 +877,7 @@ xfs_file_fallocate(
}
out_unlock:
- xfs_iunlock(ip, XFS_IOLOCK_EXCL);
+ xfs_rw_iunlock(ip, XFS_IOLOCK_EXCL);
return error;
}
--
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] extcon: gpio: Add support for using cable names
On Mon, Nov 03, 2014 at 10:32:30AM -0600, Felipe Balbi wrote:
> From: George Cherian
>
> Add support for using cable names. Enables other drivers to register interest
> and get notified using extcon provided notifier call backs.
>
> Signed-off-by: George Cherian
> Signed-off-by: Sekhar Nori
Signed-off-by: Felipe Balbi
> ---
> Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++
> drivers/extcon/extcon-gpio.c | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> index 5fe6846..f19aeb4 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> @@ -7,6 +7,7 @@ Required Properties:
> - compatible: should be:
> * "linux,extcon-gpio"
> - gpios: specifies the gpio pin used.
> + - cable-name: Name of the cable used.
>
> Optional Properties:
> - debounce: Debounce time for GPIO IRQ in ms
> @@ -18,4 +19,5 @@ Eg:
> compatible = "linux,extcon-gpio";
> gpios = < 12 GPIO_ACTIVE_HIGH>;
> debounce = <20>;
> + cable-name = "USB-HOST";
> };
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 7191d28..cbe35af 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -42,6 +42,7 @@ struct gpio_extcon_data {
> struct delayed_work work;
> unsigned long debounce_jiffies;
> bool check_on_resume;
> + const char *cable_name[1];
> };
>
> static void gpio_extcon_work(struct work_struct *work)
> @@ -112,6 +113,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> of_property_read_u32(np, "debounce", );
> irq = gpiod_to_irq(extcon_data->gpiod);
> irq_flags = irq_get_trigger_type(irq);
> + of_property_read_string_index(np, "cable-name", 0,
> + extcon_data->cable_name);
> + extcon_data->edev->supported_cable = extcon_data->cable_name;
> } else {
> if (!pdata)
> return -EBUSY;
> --
> 2.1.0.GIT
>
> --
> 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/
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 2/4] pmem: Add support for getgeo()
I agree that there should be a generic fake getgeo routine; but fixing that is
a topic for a different patchset and it doesn't need to get folded into this
driver submission process.
-Original Message-
From: Elliott, Robert (Server Storage) [mailto:elli...@hp.com]
Sent: Saturday, November 01, 2014 8:28 PM
To: Ross Zwisler; Jens Axboe; Wilcox, Matthew R; Boaz Harrosh; Nick Piggin;
Kani, Toshimitsu; Knippers, Linda; linux-fsde...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-nvd...@lists.01.org
Subject: RE: [PATCH 2/4] pmem: Add support for getgeo()
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Ross Zwisler
> Sent: Wednesday, 27 August, 2014 4:12 PM
> To: Jens Axboe; Matthew Wilcox; Boaz Harrosh; Nick Piggin; linux-
> fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> nvd...@lists.01.org
> Cc: Ross Zwisler
> Subject: [PATCH 2/4] pmem: Add support for getgeo()
>
> Some programs require HDIO_GETGEO work, which requires we implement
> getgeo. Based off of the work done to the NVMe driver in this
> commit:
>
> commit 4cc09e2dc4cb ("NVMe: Add getgeo to block ops")
>
> Signed-off-by: Ross Zwisler
> ---
> drivers/block/pmem.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
> index d366b9b..60bbe0d 100644
> --- a/drivers/block/pmem.c
> +++ b/drivers/block/pmem.c
> @@ -50,6 +50,15 @@ struct pmem_device {
> size_t size;
> };
>
> +static int pmem_getgeo(struct block_device *bd, struct hd_geometry
> *geo)
> +{
> + /* some standard values */
> + geo->heads = 1 << 6;
> + geo->sectors = 1 << 5;
> + geo->cylinders = get_capacity(bd->bd_disk) >> 11;
Just stuffing the result of get_capacity into the 16-bit
cylinders field will overflow/wrap on large capacities.
0x << 11 = 0x7FF_F800 = 64 GiB (68.7 GB)
How many programs still need these meaningless fields?
Could the bogus information be created elsewhere so
each block driver doesn't need to do this?
> + return 0;
> +}
> +
> /*
> * direct translation from (pmem,sector) => void*
> * We do not require that sector be page aligned.
> @@ -176,6 +185,7 @@ out:
>
> static const struct block_device_operations pmem_fops = {
> .owner =THIS_MODULE,
> + .getgeo = pmem_getgeo,
> };
>
> /* Kernel module stuff */
> --
---
Rob ElliottHP Server Storage
--
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] mfd: db8500-prcmu: Provide sane error path values
On Mon, Nov 3, 2014 at 2:15 PM, Lee Jones wrote:
> /* Clean up the mailbox interrupts after pre-kernel code. */
> @@ -3179,15 +3179,14 @@ static int db8500_prcmu_probe(struct platform_device
> *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq <= 0) {
Shouldn't this be if (irq < 0) then?
> dev_err(>dev, "no prcmu irq provided\n");
> - return -ENOENT;
> + return irq;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] extcon: gpio: Add dt support for the driver.
From: George Cherian
Add device tree support to extcon-gpio driver.
Add devicetree binding documentation
Cc: devicet...@vger.kernel.org
Signed-off-by: George Cherian
Signed-off-by: Sekhar Nori
Signed-off-by: Felipe Balbi
---
.../devicetree/bindings/extcon/extcon-gpio.txt | 21 ++
drivers/extcon/extcon-gpio.c | 75 +++---
2 files changed, 73 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index 000..5fe6846
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,21 @@
+GPIO based EXTCON
+
+EXTCON GPIO
+---
+
+Required Properties:
+ - compatible: should be:
+ * "linux,extcon-gpio"
+ - gpios: specifies the gpio pin used.
+
+Optional Properties:
+ - debounce: Debounce time for GPIO IRQ in ms
+
+
+Eg:
+
+ extcon1: am43_usbid_extcon1 {
+ compatible = "linux,extcon-gpio";
+ gpios = < 12 GPIO_ACTIVE_HIGH>;
+ debounce = <20>;
+ };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 70e3fc7..9571e1f 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -25,8 +25,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -80,16 +82,12 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
static int gpio_extcon_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
struct gpio_extcon_platform_data *pdata = dev_get_platdata(>dev);
struct gpio_extcon_data *extcon_data;
int ret;
-
- if (!pdata)
- return -EBUSY;
- if (!pdata->irq_flags) {
- dev_err(>dev, "IRQ flag is not specified.\n");
- return -EINVAL;
- }
+ unsigned int irq_flags;
+ unsigned int debounce = 0;
extcon_data = devm_kzalloc(>dev, sizeof(struct gpio_extcon_data),
GFP_KERNEL);
@@ -101,26 +99,51 @@ static int gpio_extcon_probe(struct platform_device *pdev)
dev_err(>dev, "failed to allocate extcon device\n");
return -ENOMEM;
}
- extcon_data->edev->name = pdata->name;
-
- extcon_data->gpiod = gpio_to_desc(pdata->gpio);
- extcon_data->state_on = pdata->state_on;
- extcon_data->state_off = pdata->state_off;
- extcon_data->check_on_resume = pdata->check_on_resume;
- if (pdata->state_on && pdata->state_off)
- extcon_data->edev->print_state = extcon_gpio_print_state;
- ret = devm_gpio_request_one(>dev, pdata->gpio, GPIOF_DIR_IN,
- pdev->name);
- if (ret < 0)
- return ret;
+ if (np) {
+ int irq;
+
+ extcon_data->gpiod = devm_gpiod_get(>dev, NULL);
+ if (IS_ERR(extcon_data->gpiod))
+ return PTR_ERR(extcon_data->gpiod);
+
+ extcon_data->edev->name = np->name;
+ extcon_data->edev->dev.parent = >dev;
+ of_property_read_u32(np, "debounce", );
+ irq = gpiod_to_irq(extcon_data->gpiod);
+ irq_flags = irq_get_trigger_type(irq);
+ } else {
+ if (!pdata)
+ return -EBUSY;
+
+ if (!pdata->irq_flags) {
+ dev_err(>dev, "IRQ flag is not specified.\n");
+ return -EINVAL;
+ }
+
+ extcon_data->edev->name = pdata->name;
+
+ extcon_data->gpiod = gpio_to_desc(pdata->gpio);
+ extcon_data->state_on = pdata->state_on;
+ extcon_data->state_off = pdata->state_off;
+ extcon_data->check_on_resume = pdata->check_on_resume;
+ if (pdata->state_on && pdata->state_off)
+ extcon_data->edev->print_state =
extcon_gpio_print_state;
+
+ ret = devm_gpio_request_one(>dev, pdata->gpio,
GPIOF_DIR_IN,
+ pdev->name);
+ if (ret < 0)
+ return ret;
+ irq_flags = pdata->irq_flags;
+ debounce = pdata->debounce;
+ }
- if (pdata->debounce) {
+ if (debounce) {
ret = gpiod_set_debounce(extcon_data->gpiod,
- pdata->debounce * 1000);
+debounce * 1000);
if (ret < 0)
extcon_data->debounce_jiffies =
- msecs_to_jiffies(pdata->debounce);
+ msecs_to_jiffies(debounce);
}
ret = devm_extcon_dev_register(>dev,
[PATCH 0/4] extcon: gpio: add DT support
Hi, this series has been tested with v3.18-rc2 with a yet-to-be-released board (called X15). That board is DT-only and we use extcon-gpio to decide which USB mode should be used (host or peripheral). George Cherian (4): extcon: gpio: Convert the driver to use gpio desc API's extcon: gpio: Add dt support for the driver. extcon: gpio: Always use gpio_get_value_cansleep extcon: gpio: Add support for using cable names .../devicetree/bindings/extcon/extcon-gpio.txt | 23 ++ drivers/extcon/extcon-gpio.c | 93 ++ 2 files changed, 84 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt -- 2.1.0.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] extcon: gpio: Always use gpio_get_value_cansleep
From: George Cherian Some gpio's can sleep while reading, so always use gpio_get_value_cansleep to get data. This fixes warning from gpiolib due to wrong API usage. Reviewed-by: Roger Quadros Signed-off-by: George Cherian Signed-off-by: Sekhar Nori Signed-off-by: Felipe Balbi --- drivers/extcon/extcon-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 9571e1f..7191d28 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -51,7 +51,7 @@ static void gpio_extcon_work(struct work_struct *work) container_of(to_delayed_work(work), struct gpio_extcon_data, work); - state = gpiod_get_value(data->gpiod); + state = gpiod_get_value_cansleep(data->gpiod); extcon_set_state(data->edev, state); } -- 2.1.0.GIT -- 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] extcon: gpio: Add support for using cable names
From: George Cherian
Add support for using cable names. Enables other drivers to register interest
and get notified using extcon provided notifier call backs.
Signed-off-by: George Cherian
Signed-off-by: Sekhar Nori
---
Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++
drivers/extcon/extcon-gpio.c | 4
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
index 5fe6846..f19aeb4 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -7,6 +7,7 @@ Required Properties:
- compatible: should be:
* "linux,extcon-gpio"
- gpios: specifies the gpio pin used.
+ - cable-name: Name of the cable used.
Optional Properties:
- debounce: Debounce time for GPIO IRQ in ms
@@ -18,4 +19,5 @@ Eg:
compatible = "linux,extcon-gpio";
gpios = < 12 GPIO_ACTIVE_HIGH>;
debounce = <20>;
+ cable-name = "USB-HOST";
};
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7191d28..cbe35af 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -42,6 +42,7 @@ struct gpio_extcon_data {
struct delayed_work work;
unsigned long debounce_jiffies;
bool check_on_resume;
+ const char *cable_name[1];
};
static void gpio_extcon_work(struct work_struct *work)
@@ -112,6 +113,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
of_property_read_u32(np, "debounce", );
irq = gpiod_to_irq(extcon_data->gpiod);
irq_flags = irq_get_trigger_type(irq);
+ of_property_read_string_index(np, "cable-name", 0,
+ extcon_data->cable_name);
+ extcon_data->edev->supported_cable = extcon_data->cable_name;
} else {
if (!pdata)
return -EBUSY;
--
2.1.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] extcon: gpio: Convert the driver to use gpio desc API's
From: George Cherian
Convert the driver to use gpiod_* API's.
Reviewed-by: Roger Quadros
Signed-off-by: George Cherian
Signed-off-by: Sekhar Nori
Signed-off-by: Felipe Balbi
---
drivers/extcon/extcon-gpio.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 72f19a3..70e3fc7 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -33,8 +33,7 @@
struct gpio_extcon_data {
struct extcon_dev *edev;
- unsigned gpio;
- bool gpio_active_low;
+ struct gpio_desc *gpiod;
const char *state_on;
const char *state_off;
int irq;
@@ -50,9 +49,7 @@ static void gpio_extcon_work(struct work_struct *work)
container_of(to_delayed_work(work), struct gpio_extcon_data,
work);
- state = gpio_get_value(data->gpio);
- if (data->gpio_active_low)
- state = !state;
+ state = gpiod_get_value(data->gpiod);
extcon_set_state(data->edev, state);
}
@@ -106,21 +103,20 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
extcon_data->edev->name = pdata->name;
- extcon_data->gpio = pdata->gpio;
- extcon_data->gpio_active_low = pdata->gpio_active_low;
+ extcon_data->gpiod = gpio_to_desc(pdata->gpio);
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
extcon_data->edev->print_state = extcon_gpio_print_state;
- ret = devm_gpio_request_one(>dev, extcon_data->gpio, GPIOF_DIR_IN,
+ ret = devm_gpio_request_one(>dev, pdata->gpio, GPIOF_DIR_IN,
pdev->name);
if (ret < 0)
return ret;
if (pdata->debounce) {
- ret = gpio_set_debounce(extcon_data->gpio,
+ ret = gpiod_set_debounce(extcon_data->gpiod,
pdata->debounce * 1000);
if (ret < 0)
extcon_data->debounce_jiffies =
@@ -133,7 +129,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(_data->work, gpio_extcon_work);
- extcon_data->irq = gpio_to_irq(extcon_data->gpio);
+ extcon_data->irq = gpiod_to_irq(extcon_data->gpiod);
if (extcon_data->irq < 0)
return extcon_data->irq;
--
2.1.0.GIT
--
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] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.
From: Clemens Ladisch Date: Mon, 03 Nov 2014 10:44:40 +0100 > David Miller wrote: >> I'd also rather the kernel use Kconfig based symbols to detect for >> arch availability of feature X or Y, assuming things are CPP symbols >> is very fragile at best. > > It is certainly possible to use Kconfig-based symbols. However, this > would have its own fragility: adding, e.g., PAGE_KERNEL_SO to an arch > requires that one remembers to update Kconfig, and if one forgets, > a check like this: > > #ifndef CONFIG_ARCH_HAS_PAGE_KERNEL_RO > #define PAGE_KERNEL_RO PAGE_KERNEL /* fallback for this code */ > #endif > > will not detect the error on sparc64 (if PAGE_KERNEL_RO were a CPP > symbol, the compiler would complain about the redefinition). > > So even if PAGE_KERNEL_RO is a variable, making it into a CPP symbol > is beneficial. And once it is a CPP symbol, introducing a separate > Kconfig-based symbol is not necessary and just increases the chances > of an error. I'd rather code then use the symbol unconditionally, and we declare that it's something every architecture must provide in some shape or form. This CPP check business is fragile as hell and I'm not going to promote it in the architectures I maintainer by applying patches like your's. Sorry. -- 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: s390/net: Deletion of unnecessary checks before two function calls
On Mon, Nov 03, 2014 at 05:10:35PM +0100, SF Markus Elfring wrote: > > I agree with your proposed debug_unregister() changes, but not with your > > kfree_fsm() change. > > Why do you want to keep an additional null pointer check before the call > of the kfree_fsm() function within the implementation of the > netiucv_free_netdevice() function? Think about how long it takes you to figure this out what the bug is and then remember that we have to spend that same amount of time multiplied by the number of patches you have sent. regards, dan carpenter -- 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/2] Add DRA7xx CPSW Ethernet support in Device Tree
On Tue, Oct 21, 2014 at 12:22:23PM -0500, Nishanth Menon wrote: > On 15:37-20141021, Mugunthan V N wrote: > > Nishanth > > > > On Tuesday 21 October 2014 03:30 PM, Mugunthan V N wrote: > > > Adding device tree entry for CPSW to make it work in Dual EMAC mode. > > > These patches were tested with DRA7 hwmod patches on top of linux-next. > > > Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed > > > my tree to [2]. > > > > > > Did a boot test with CPSW and ping test with suspend/resume, the boot logs > > > on DRA7xx EVM are posted at [3] > > > > > > [1] git://github.com/nmenon/linux-2.6-playground.git > > > testing/v3.17/cpu-idle-suspend-dra7-omap5-framework > > > [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git > > > v3.17/dra7-evm-cpsw-v3 > > > [3] http://pastebin.ubuntu.com/8613072/ > > > > > > Changes from v2: > > > * Changed pinctrl comments to hold mode0-name.mode-selected-name > > > * Changes slave numbers in the pinctrl comments > > > * Added cpsw and cpts clocks > > > > > > > I have not added support for dra72x-evm as it has only slave no 2 pinned > > out and having issues with bringing up the interface, need some more > > time to submit the patch, in the mean time I have submitted dra7-evm > > support only so that people can use dra7-evm on linux-next. > > Quickly tested as well: > http://slexy.org/raw/s2vISJxYrR > > Please feel free to add: > Tested-by: Nishanth Menon > Acked-by: Nishanth Menon I've used these patches with X15 (DRA7xx-based yet-to-be-released board) with v3.18-rc2. Tested-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v8 1/5] PM / Runtime: Add getter for querying the IRQ safe option
On Sat, Nov 01, 2014 at 02:29:42AM +0200, Laurent Pinchart wrote: > Hi Krzysztof, > > On Friday 31 October 2014 15:40:16 Krzysztof Kozlowski wrote: > > On pią, 2014-10-31 at 15:22 +0100, Pavel Machek wrote: > > > On Fri 2014-10-31 10:14:55, Krzysztof Kozlowski wrote: > > >> On pon, 2014-10-20 at 11:04 +0200, Krzysztof Kozlowski wrote: > > >>> Add a simple getter pm_runtime_is_irq_safe() for querying whether > > >>> runtime PM IRQ safe was set or not. > > >>> > > >>> Various bus drivers implementing runtime PM may use choose to suspend > > >>> differently based on IRQ safeness status of child driver (e.g. do not > > >>> unprepare the clock if IRQ safe is not set). > > >>> > > >>> Signed-off-by: Krzysztof Kozlowski > > >>> Reviewed-by: Ulf Hansson > > >> > > >> Rafael, Len, Pavel, > > >> > > >> Is proposed API ok? Do you have any comments? > > >> > > >> I'll upload whole patchset to Russell's patch tracking system. However > > >> an ack from PM maintainer is probably needed. > > > > > > I don't like the API. Having callbacks work in different context (irq > > > / noirq) based on what another function reports is ugly. > > > > > > What is the penalty if we always decide callbacks are not IRQ safe? > > > > Then pm_runtime_get_sync() could not be called in atomic context. The > > pl330 runtime PM would have to be completely reworked because one > > pm_runtime_get_sync() is called in device_issue_pending which cannot > > sleep (at least in non preemptible kernels). Probably this can be solved > > some way... > > Many other drivers suffer from the same problem. While I won't reject your > proposed fix, I would prefer a more generic approach. > > One option that has been discussed previously was to use a work queue to > delay > starting the DMA transfer to an interruptible context where > pm_runtime_get_sync() could be called. However, as Russell pointed out [1], > even that won't work in all cases as the DMA slave might need the transfer to > be started before enabling part of its hardware (OMAP audio seem to be such a > case). > > I've heard a rumor of a possible DMA engine rework to forbid calling the > descriptor preparation API from atomic context. This could be used as a base > to implement runtime PM, as DMA slave drivers should not prepare descriptors > if they don't need to use them. However that's a long term plan, and we need > a > solution sooner than that. Well it is not a rumour :) I have been contemplating that now that async_tx will be killed so we dont have to worry about that usage. For the slave dma usage, we can change the prepare API to be non atomic. I think the users will be okay with approach. This way drivers can use runtime pm calls in prepare. -- ~Vinod > > I've been toying with the idea of adding explicit open/close (or whatever we > would call them) operations to the DMA engine API. Those would be used by DMA > slave drivers to signal that they will start/stop using the DMA engine. > > If (1) we must start the DMA synchronously with a DMA slave call, (2) need to > sleep to handle PM, and (3) don't want to keep the DMA engine powered for as > long as one channel is requested, then we need to turn at least preparation > as > not callable in atomic context, or introduce a new operation. > > [1] http://www.spinics.net/lists/dmaengine/msg01548.html > > > >>> --- a/Documentation/power/runtime_pm.txt > > >>> +++ b/Documentation/power/runtime_pm.txt > > >>> > > >>> @@ -468,6 +468,10 @@ drivers/base/power/runtime.c and > > >>> include/linux/pm_runtime.h: > > >>> - set the power.irq_safe flag for the device, causing the > > >>> runtime-PM > > >>> > > >>>callbacks to be invoked with interrupts off > > >>> > > >>> + bool pm_runtime_is_irq_safe(struct device *dev); > > >>> +- return true if power.irq_safe flag was set for the device, > > >>> causing > > >>> + the runtime-PM callbacks to be invoked with interrupts off > > >>> + > > >>> > > >>>void pm_runtime_mark_last_busy(struct device *dev); > > >>> > > >>> - set the power.last_busy field to the current time > > -- > Regards, > > Laurent Pinchart > -- -- 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: s390/net: Deletion of unnecessary checks before two function calls
On Mon, Nov 03, 2014 at 04:55:12PM +0100, SF Markus Elfring wrote: > > This one is buggy. > > I am still interested to clarify this opinion a bit more. > After your patch then it will print warning messages. The truth is I think that all these patches are bad and they make the code harder to read. Before: The code is clear and there is no NULL dereference. After: You have to remember that rtw_free_netdev() accepts NULL pointers but free_netdev() does not accept NULL pointers. The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code. Even for kfree(), just removing the if statement is not really the right fix. We do it because everyone knows kfree(), but what Julia Lawall said is the real correct way change the code and make it simpler for people to understand: https://lkml.org/lkml/2014/10/31/452 I know it's fun to send automated patches but these make the code worse and they waste reviewer time. regards, dan carpenter -- 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: [RFD] perf syscall error handling
Em Sat, Nov 01, 2014 at 01:30:39AM -0400, Vince Weaver escreveu: > On Fri, 31 Oct 2014, Stephane Eranian wrote: > > > On Fri, Oct 31, 2014 at 1:28 PM, Matt Fleming > > wrote: > > > > > > I guess we'd run into a problem if userspace doesn't want to just print > > > the kernel string but instead wants to parse it in some fashion. > If the string interface went in it would be a help when debugging > perf_event_open(). The way that peterz suggested, i.e. returning information about which perf_event_attr and which of the parameters was invalid/had issues could help with fallbacking/capability querying, i.e. tooling may want to use some features if available automagically, fallbacking to something else when that fails. We already do that to some degree in various cases, but for some if the only way that becomes available to disambiguate some EINVAL return is a string, code will start having strcmps :-\ > Support would probably get added to PAPI, but PAPI has its own error > reporting issues and it's not always easy to pass a string the whole way > back to the user. Having the last resort being an string instead of EINVAL is indeed much better than what we have now. > Also with PAPI many of the users reporting obscure perf_event_open() > problems are often running 2.6.32-vendor-patched kernels, so sadly it will > be years before any improved error handling filters down to many of the > users. > This proposal also doesn't help with other weird failure modes in the > interface, the most annoying of which is the watchdog stealing a counter > so event groups perf_event_open() and start just fine but fail at read > time. > > > That may or may not be a problem in practice, Vince can probably comment > > > on that. I'm just thinking along the lines of making the perf syscall > > > interface as useful as possible for tools other than tools/perf. > > Maybe I missed something in the earlier thread, but I am trying to > > understand > > why perf_event_open() would need such extended error retrieval system when > > no other syscall does. > well perf_event_open() is so complex, with it's 40+ different parameters. > Having a wrong value in any one of those (or one of the combinations of > those) can trigger EINVAL and it's not clear where the issue is. > I think other system calls tend to have slighly more straightforward > interfaces. Yes, it is a PITA to figure out which codepath returned -EINVAL. Its just a "No comprendo", we're left wondering what is it that is not being understood or accepted... - Arnaldo -- 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] hwmon: (ibmpowernv) Quieten when probing finds no device
On Fri, Oct 31, 2014 at 10:41:47AM +0100, Jean Delvare wrote:
> Hi Michael,
>
> On Fri, 31 Oct 2014 17:45:22 +1100, Michael Ellerman wrote:
> > Because we build kernels with drivers built in for many platforms, it's
> > normal for the ibmpowernv driver to be loaded on systems that don't have
> > the appropriate hardware.
> >
> > Currently the driver spams the log with:
> >
> > ibmpowernv ibmpowernv.0: Opal node 'sensors' not found
> > ibmpowernv: Platfrom driver probe failed
> >
> > But there is no error, this machine is not a powernv and doesn't have
> > the hardware. So change the sensors message to dev_dbg(), and only print
> > an error about the probe failing if it's not ENODEV.
> >
> > Also fix the spelling of "Platfrom" and print the actual error value.
> >
> > Signed-off-by: Michael Ellerman
> > ---
> > drivers/hwmon/ibmpowernv.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> > index d2bf2c97ae70..6a30eeea94be 100644
> > --- a/drivers/hwmon/ibmpowernv.c
> > +++ b/drivers/hwmon/ibmpowernv.c
> > @@ -181,7 +181,7 @@ static int __init populate_attr_groups(struct
> > platform_device *pdev)
> >
> > opal = of_find_node_by_path("/ibm,opal/sensors");
> > if (!opal) {
> > - dev_err(>dev, "Opal node 'sensors' not found\n");
> > + dev_dbg(>dev, "Opal node 'sensors' not found\n");
> > return -ENODEV;
> > }
> >
> > @@ -335,7 +335,9 @@ static int __init ibmpowernv_init(void)
> >
> > err = platform_driver_probe(_driver, ibmpowernv_probe);
> > if (err) {
> > - pr_err("Platfrom driver probe failed\n");
> > + if (err != -ENODEV)
> > + pr_err("Platform driver probe failed (%d)\n", err);
> > +
> > goto exit_device_del;
> > }
> >
>
> Looks reasonable.
>
> Reviewed-by: Jean Delvare
>
Applied.
Neelesh, please base your patch on top of this one.
Thanks,
Guenter
--
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/4] pmem: Initial version of persistent memory driver
I really wish people wouldn't use my Exchange email address for patches. It's
completely impossible to have a meaningful conversation this way. I've
resorted to inserting extra quotation marks by hand so people can stand at
least some chance of understanding what the hell's going on.
> > +config BLK_DEV_PMEM_COUNT
> > + int "Default number of PMEM disks"
> > + default "4"
>
> For real use I think a default of 1 would be better.
For real use, you need at least two to run xfstests. This whole configuration
mechanism is going away soon anyway.
> > + size_t page_offset = sector >> PAGE_SECTORS_SHIFT;
> > + size_t offset = page_offset << PAGE_SHIFT;
> > +
>
> Since page_offset is only used to calculate offset, they
> could be joined to avoid relying on the compiler to
> optimize it away:
> size_t offset = sector >> PAGE_SECTORS_SHIFT << PAGE_SHIFT;
If you insist on doing the compiler's job for it, why not:
size_t offset = sector >> (PAGE_SECTORS_SHIFT - PAGE_SHIFT);
I actually think the original is clearer.
> > + BUG_ON(offset >= pmem->size);
>
> BUG_ON is severe... should this function be designed to return
> an error instead?
No ... upper levels should have prevented an out of range I/O from being
communicated down to the driver. Finding the I/O is out of range here
indicates something is horribly wrong, and BUG_ON is the appropriate response.
> > + if (rw == READ) {
> > + copy_from_pmem(mem + off, pmem, sector, len);
> > + flush_dcache_page(page);
>
> Why does READ flush the dcache after reading? It's fine to
> leave data in dcache.
You misunderstand the purpose of flush_dcache_page(); see
Documentation/cachetlb.txt. It is to handle D-cache aliasing between user
views of pages and kernel views of pages. So we have to flush it after reading
so that userspace sees the newly written data, and flush it before writing from
it, so that the kernel sees all the data thast userspace has written to it.
These macros are no-ops on x86, but on CPUs like PA-RISC, they perform
important work.
> If a read or write of a pmem address gets an uncorrectable
> error, the system should not crash; just report this IO is bad.
> That reflects a difference in storage philosophy vs. memory
> philosophy. All the rest of the data in the pmem might be
> fine, and many users prefer to recover 99% of their data
> than lose it all.
>
> pmem_do_bvec needs a way to turn off normal DRAM "crash on
> error" handling for its accesses, and provide a return value
> indicating success or failure.
This is on our longer-term TODO list. It requires integration with the MCE
handler.
> Also, most storage devices automatically remap bad sectors
> when they are overwritten or remap them on command (e.g.,
> REASSIGN BLOCKS in SCSI), rather than leave that sector
> bad forever. I don't know how many filesystems and
> applications rely on that feature now, vs. maintain their
> own bad block tables; this may be something that pmem
> needs to provide.
At least ext4 supports the concept of bad blocks. XFS doesn't (due to it being
a bad idea for modern hard drives), but it's pretty trivial to add (a special
inode that owns all of the bad blocks; no changes to any data structures).
> > + BUG_ON(bio->bi_rw & REQ_DISCARD);
> > +
>
> Since discard (i.e., unmap, trip) is just a hint, it could just
> be ignored rather than trigger a drastic BUG.
Again, upper layers should have not sent down a DISCARD request since the
driver didn't indicate support for them. Personally, I would have not put this
line in, but it's Ross' driver and I wasn't going to argue with him.
> Related suggestion: keep track of each sector that has been
> discarded, and whether it has been written after discard.
> This would tell flash-backed DRAM which sectors don't need
> to be flushed to flash on a power failure.
How would we communicate that info to the DIMM? We're not opposed to putting
in DISCARd support, but it needs to provide some value.
> Related suggestion: Adding WRITE SAME support would be useful
> for some software (for at least the writing zeros subset) -
> that command is not just a hint. It would result in a memset.
At this point, it's no more efficient in the Linux stack than having the
filesystem send down I/Os full of zeroes. The NVMe WRITE ZEROES command would
be more efficient, but that's not yet supported by the Linux stack.
> These modparam variable names and description scripts use gb
> and GB when they mean GiB. The storage market generally uses
> correct SI units; please don't follow JEDEC's misuse. The
> Kconfig descriptions use the right IEC binary units.
These are also going away.
> > +/* FIXME: move phys_addr, virt_addr, size calls up to caller */
>
> It is unclear what that wants to fix.
Also part of the configuration interface that is being replaced.
> > + size_t disk_size = total_size / pmem_count;
>
> There is no protection for
Re: [PATCH] hwmon: (pwm-fan) Fix suspend/resume behavior
On Mon, Nov 03, 2014 at 03:42:55PM +0100, Kamil Debski wrote: > The state of a PWM output is not clearly defined after resume. Some PWM > drivers do not restore the duty cycle upon resume, thus it is necessary to > manually restore the correct value. > > Signed-off-by: Kamil Debski Applied. Thanks, Guenter -- 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: Re: [PATCH perf/core 0/6] perf-probe: Bugfix and add new options for cache
Em Mon, Nov 03, 2014 at 09:11:18PM +0900, Masami Hiramatsu escreveu: > (2014/10/31 21:13), Arnaldo Carvalho de Melo wrote: > > Em Fri, Oct 31, 2014 at 02:51:29PM -0400, Masami Hiramatsu escreveu: > >> p:probe/reset_early_page_tables _text+12980741 > >> p:probe/copy_bootdata _text+12980830 real_mode_data=%di:u64 > >> p:probe/exit_amd_microcode _text+14692680 > >> p:probe/early_make_pgtable _text+12981274 address=%di:u64 > >> p:probe/x86_64_start_reservations _text+12981700 real_mode_data=%di:u64 > >> p:probe/x86_64_start_kernel _text+12981744 real_mode_data=%di:u64 > >> p:probe/reserve_ebda_region _text+12982117 > >> This event.cache file will be big (but much smaller than native > >> debuginfo :) ) if your kernel have many option embedded. > >> Anyway, you can compress it too. > > How do you validate that the cache can be used against some kernel? I.e. > > is this that the user has to do? Isn't this prone to errors? > Actually, kprobe event itself can reject command if the given address > is not in the kernel text nor instruction boundary (perhaps, uprobes > may have a problem...), so for the kernel level, it is safe. No, it is not necessarily safe. What if you specify function foo() that has address 0x1234 for kernel v3.16 and then run the cached probe on kernel v3.18 and on that kernel the function foo() maps to address 0x2345 and function bar() instead maps to address 0x1234? Oops. The build-id was designed to uniquely identify a DSO, we need to use it. I think that at some point not using it should be left to a, in systemtap parlance, "guru" mode, with tooling warning profusely when build ids are not available and requiring even more forcing when it doesn't matches. > > Perhaps you could pick the build-id and store it into the event cache > > file, in the first lines, somethings like: > Agreed, build-id should be the best way to check that. > For kprobes, user can easy to get and compare it with local one as below :) > > RLOGIN=root@$REMOTE > rid=`ssh $RLOGIN "od -j16 -w48 -An -t x1 /sys/kernel/notes | tr -d ' '"` > lid=`od -j16 -w48 -An -t x1 /sys/kernel/notes | tr -d ' '` > if [ $rid != $lid ]; then > echo "Error: Build-id mis-matched!" > exit 1; > fi > echo "Setting up $EVENTNAME at $REMOTE" > zcat event.cache.gz | grep $EVENTNAME |\ > ssh $RLOGIN "tee -a /sys/kernel/debug/tracing/kprobe_events" > echo "Done" > > With this script, you don't need to install perf at remote hosts. > (This is what enterprise people called "agent-less") This is only sufficient (and a cool feature!) if you will immediataly use the cached info (i.e. using just two systems: one development machine, with all debugging info, devel tools, etc, and the other the machine to observe, that is bare bones, no debugging info, etc)), but the moment you store that event.cache.gz (that has no build id embedded from what I can see from the above example) then you lose the build id for those cached events. You need to tightly associate whatever symbol resolution is done with the build id, at symbol resolution/caching time. Then, before using the cached symbol resolution, we need to check if the target kernel/DSO build id is the same as the cached symbol kernel/DSO build id. > > [acme@zoo ~]$ printf "buildid: %s\n" $(perf buildid-list --kernel) > > buildid: a4cacca49391fc4f42ac8f58990f4e97042efae8 > > [acme@zoo ~]$ printf "buildid: %s\n" $(perf buildid-list --kernel) > > buildid: a4cacca49391fc4f42ac8f58990f4e97042efae8 > > Maybe this would be nice to have integrated with 'perf archive' somehow > > and then store this into ~/.debug/[probe]//dso-name > > where dso-name would be [kernel] for the kernel and the full path for > > userspace stuff, and then when adding a new probe we would look there > > for a pre-built/cached event definition, only looking for the debuginfo > > (which is done using the build-id already, right) and would insert the > > probe definitions there, etc. > This will be good for SDT too. Perhaps, both of SDT and cached probes > should share the same file. Right, what is in ~/.debug/ may be used by multiple tools, just like debuginfo files are, by keying the content by its build id. And also by having separate subdirectory trees for different kinds of symbol information, i.e. the ~/.debug/.build-id/ links may point to either ELF files or to kallsyms data. What we are discussing here is to make it also point to the [ku]probes_tracer cached probes files. The way that DSO files are cached may by the same that you end up adding the [ku]probes_tracer cached files, take a look at the example of caching for the '/usr/bin/gcc' DSO on a test maachine here at my home lab: [root@zoo ~]# ls -la ~/.debug/usr/bin/gcc/ total 2268 drwxr-xr-x. 2 root root 4096 Oct 15 16:54 . drwxr-xr-x. 53 root root 4096 Oct 21 18:06 .. -rwxr-xr-x. 1 root root 768576 Jun 24 14:08 07f4c7f58a6e7ce9177d45f71d9698e906168096 -rwxr-xr-x. 3 root root 772672 Sep 11
[PATCH v2 1/1] spi: spi-gpio: Add dt support for a single device with no chip select
From: Torsten Fleischer
In order to describe a single slave device that has no chip select line
the 'num-chipselects' property has to be <0> and the 'cs-gpios' property
doesn't need to be set.
Signed-off-by: Torsten Fleischer
---
Documentation/devicetree/bindings/spi/spi-gpio.txt | 6 --
drivers/spi/spi-gpio.c | 21 +++--
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt
b/Documentation/devicetree/bindings/spi/spi-gpio.txt
index 8a824be..a95603b 100644
--- a/Documentation/devicetree/bindings/spi/spi-gpio.txt
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt
@@ -8,8 +8,10 @@ Required properties:
- gpio-sck: GPIO spec for the SCK line to use
- gpio-miso: GPIO spec for the MISO line to use
- gpio-mosi: GPIO spec for the MOSI line to use
- - cs-gpios: GPIOs to use for chipselect lines
- - num-chipselects: number of chipselect lines
+ - cs-gpios: GPIOs to use for chipselect lines.
+ Not needed if num-chipselects = <0>.
+ - num-chipselects: Number of chipselect lines. Should be <0> if a single
device
+with no chip select is connected.
Example:
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 9f59553..f0492c9 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -413,6 +413,7 @@ static int spi_gpio_probe(struct platform_device *pdev)
struct spi_gpio_platform_data *pdata;
u16 master_flags = 0;
bool use_of = 0;
+ int num_devices;
status = spi_gpio_probe_dt(pdev);
if (status < 0)
@@ -422,16 +423,21 @@ static int spi_gpio_probe(struct platform_device *pdev)
pdata = dev_get_platdata(>dev);
#ifdef GENERIC_BITBANG
- if (!pdata || !pdata->num_chipselect)
+ if (!pdata || (!use_of && !pdata->num_chipselect))
return -ENODEV;
#endif
+ if (use_of && !SPI_N_CHIPSEL)
+ num_devices = 1;
+ else
+ num_devices = SPI_N_CHIPSEL;
+
status = spi_gpio_request(pdata, dev_name(>dev), _flags);
if (status < 0)
return status;
master = spi_alloc_master(>dev, sizeof(*spi_gpio) +
- (sizeof(int) * SPI_N_CHIPSEL));
+ (sizeof(int) * num_devices));
if (!master) {
status = -ENOMEM;
goto gpio_free;
@@ -446,7 +452,7 @@ static int spi_gpio_probe(struct platform_device *pdev)
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32);
master->flags = master_flags;
master->bus_num = pdev->id;
- master->num_chipselect = SPI_N_CHIPSEL;
+ master->num_chipselect = num_devices;
master->setup = spi_gpio_setup;
master->cleanup = spi_gpio_cleanup;
#ifdef CONFIG_OF
@@ -461,9 +467,12 @@ static int spi_gpio_probe(struct platform_device *pdev)
* property of the node.
*/
- for (i = 0; i < SPI_N_CHIPSEL; i++)
- spi_gpio->cs_gpios[i] =
- of_get_named_gpio(np, "cs-gpios", i);
+ if (!SPI_N_CHIPSEL)
+ spi_gpio->cs_gpios[0] = SPI_GPIO_NO_CHIPSELECT;
+ else
+ for (i = 0; i < SPI_N_CHIPSEL; i++)
+ spi_gpio->cs_gpios[i] =
+ of_get_named_gpio(np, "cs-gpios", i);
}
#endif
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
randconfig build error with next-20141103, in fs/open.c
Building with the attached random configuration file, fs/open.c: In function ‘SYSC_fchmod’: fs/open.c:530:3: error: implicit declaration of function ‘audit_file’ [-Werror=implicit-function-declaration] audit_file(f.file); ^ cc1: some warnings being treated as errors make[1]: *** [fs/open.o] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.18.0-rc3 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_ADVISE_SYSCALLS is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set # CONFIG_VM_EVENT_COUNTERS is not
[PATCH] mfd: db8500-prcmu: Provide sane error path values
Also rid superfluous gotos and label.
Cc: Linus Walleij
Signed-off-by: Lee Jones
---
drivers/mfd/db8500-prcmu.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 89ae8bf..a820473 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -3150,27 +3150,27 @@ static int db8500_prcmu_probe(struct platform_device
*pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "prcmu");
if (!res) {
dev_err(>dev, "no prcmu memory region provided\n");
- return -ENOENT;
+ return -EINVAL;
}
prcmu_base = devm_ioremap(>dev, res->start, resource_size(res));
if (!prcmu_base) {
dev_err(>dev,
"failed to ioremap prcmu register memory\n");
- return -ENOENT;
+ return -ENOMEM;
}
init_prcm_registers();
dbx500_fw_version_init(pdev, pdata->version_offset);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "prcmu-tcdm");
if (!res) {
dev_err(>dev, "no prcmu tcdm region provided\n");
- return -ENOENT;
+ return -EINVAL;
}
tcdm_base = devm_ioremap(>dev, res->start,
resource_size(res));
if (!tcdm_base) {
dev_err(>dev,
"failed to ioremap prcmu-tcdm register memory\n");
- return -ENOENT;
+ return -ENOMEM;
}
/* Clean up the mailbox interrupts after pre-kernel code. */
@@ -3179,15 +3179,14 @@ static int db8500_prcmu_probe(struct platform_device
*pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
dev_err(>dev, "no prcmu irq provided\n");
- return -ENOENT;
+ return irq;
}
err = request_threaded_irq(irq, prcmu_irq_handler,
prcmu_irq_thread_fn, IRQF_NO_SUSPEND, "prcmu", NULL);
if (err < 0) {
pr_err("prcmu: Failed to allocate IRQ_DB8500_PRCMU1.\n");
- err = -EBUSY;
- goto no_irq_return;
+ return err;
}
db8500_irq_init(np);
@@ -3211,7 +3210,7 @@ static int db8500_prcmu_probe(struct platform_device
*pdev)
if (err) {
mfd_remove_devices(>dev);
pr_err("prcmu: Failed to add subdevices\n");
- goto no_irq_return;
+ return err;
}
}
@@ -3219,12 +3218,10 @@ static int db8500_prcmu_probe(struct platform_device
*pdev)
if (err) {
mfd_remove_devices(>dev);
pr_err("prcmu: Failed to add ab8500 subdevice\n");
- goto no_irq_return;
+ return err;
}
pr_info("DB8500 PRCMU initialized\n");
-
-no_irq_return:
return err;
}
static const struct of_device_id db8500_prcmu_match[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 10/10] sched: make scale_rt invariant with frequency
On 3 November 2014 16:51, Peter Zijlstra wrote: > On Fri, Oct 31, 2014 at 09:47:32AM +0100, Vincent Guittot wrote: >> The call to arch_scale_frequency_capacity in the rt scheduling path might be >> a concern for RT folks because I'm not sure whether we can rely on >> arch_scale_freq_capacity to be short and efficient ? > > Well, you put it in quite a hot path on the CFS side too, so it had > better be blazing fast anyhow. > > > That said, can you move all the running + invariance bits at the > beginning of the patch set, these appear to be the least controversial > bits and 'desired' by quite a few people, so we'll try and get those > agreed upon and merged first. ok I'm going to resend with the following order sched: add utilization_avg_contrib sched: Track group sched_entity usage contributions sched: remove frequency scaling from cpu_capacity sched: Make sched entity usage tracking scale-invariant sched: make scale_rt invariant with frequency sched: add per rq cpu_capacity_orig sched: get CPU's usage statistic sched: replace capacity_factor by usage sched: add SD_PREFER_SIBLING for SMT level sched: move cfs task on a CPU with higher capacity -- 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: s390/net: Deletion of unnecessary checks before two function calls
> I agree with your proposed debug_unregister() changes, but not with your > kfree_fsm() change. Why do you want to keep an additional null pointer check before the call of the kfree_fsm() function within the implementation of the netiucv_free_netdevice() function? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] PM / Domains: Power on domain early during system resume
Andrzej Hajda writes:
> On 10/30/2014 08:36 AM, Krzysztof Kozlowski wrote:
>> On śro, 2014-10-29 at 10:46 -0700, Kevin Hilman wrote:
>>> Krzysztof Kozlowski writes:
>>>
When resuming the system the power domain has to be powered on early so
any runtime PM aware devices could resume.
This fixes following scenario reproduced on Exynos DRM:
1. Power domain is off before suspending the system.
2. System is suspended to RAM.
3. Resuming starts. The Exynos DRM driver resume callback is called.
4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
>>> Dumb Q: if the device (and power domain) were off before (and during)
>>> suspend, why are they being resumed?
>>>
>>> Shouldn't the resume path restore things to the same state they were
>>> before suspend?
>> One could expect that... but the Exynos DRM driver behaves differently
>> (and some other drivers also). In resume method it calls
>> drm_helper_resume_force_mode() which forces restoring mode setting
>> configuration. Apparently setting a mode needs DPMS on:
>> static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>> {
>> ...
>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> ...
>>
>> The previous DPMS status (status during suspend) is completely ignored
>> here.
>
> Suspend callback switches off all connectors (thus all other devs in
> their pipeline) by calling dpms_off,
> in restore callback all devs are restored to their previous state by
> calling appropriate dpms.
> So I guess drm_helper_resume_force_mode() call at the end of resume is
> incorrect.
Though I'm not terribly familiar with DRM, it seems incorrect because I
expect resume to restore the state of things when suspend happened, not
forcibly resume everything.
> On the other side it is present in many other drivers, so I am also
> little bit confused.
Many other DRM drivers? or other drivers too?
Kevin
--
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 03/14] regulator: of: Add regulator desc param to of_get_regulator_init_data()
On 11/03/2014 04:59 PM, Mark Brown wrote: > No, it's only *currently* used for that. If we don't bother passing the > descriptor in then future additions which make use of it (including > adding mode operations to existing drivers) won't work and it might not > be obvious why. > fair enough. > You're already going through and modifying every single driver and all > of those I looked at already had references to the descriptor in > adjacent code or a global descriptor for the one regulator supported by > the driver. > Ok, I'll make sure that all drivers passes the descriptor. 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/
[PATCH v4] tty: serial: men_z135_uart: Fix driver for changes in hardware
16z135 IP Core has changed so the driver needs to be updated to respect
these changes. The following changes have been made:
* Don't invert the 16z135 modem status register when reading.
* Add module parameter to configure the (baud rate dependent) RX timeout.
Character timeout in seconds = (timeout_reg * baud_reg * 4)/freq_reg.
* Enable the handling of UART core's automatic flow control feature.
When AFE is active disable generation of modem status IRQs.
* Rework the handling of IRQs to be conform with newer FPGA versions and
take precautions not to miss an interrupt because of the destructive read
of the IIR register.
* Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not
stat_reg[7:0]
* Correct calling of uart_handle_{dcd,cts}_change()
* Correct handling of hardware's automode
Signed-off-by: Johannes Thumshirn
---
Changes to v1:
Incorporated comments of Jiri Slaby:
* Timeout value is documented in module parameter description
* rx_timeout variable is uint
* Changed IRQ handled variable to bool
* Changed if statement for RDA or CTI IRQ
Changes to v2:
Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not stat_reg[7:0]
Changes to v3:
Correct calling of uart_handle_{dcd,cts}_change()
Correct handling of hardware's automode
drivers/tty/serial/men_z135_uart.c | 154 ++---
1 file changed, 108 insertions(+), 46 deletions(-)
diff --git a/drivers/tty/serial/men_z135_uart.c
b/drivers/tty/serial/men_z135_uart.c
index 30e9e60..90104c4 100644
--- a/drivers/tty/serial/men_z135_uart.c
+++ b/drivers/tty/serial/men_z135_uart.c
@@ -23,7 +23,6 @@
#define MEN_Z135_MAX_PORTS 12
#define MEN_Z135_BASECLK 29491200
#define MEN_Z135_FIFO_SIZE 1024
-#define MEN_Z135_NUM_MSI_VECTORS 2
#define MEN_Z135_FIFO_WATERMARK1020
#define MEN_Z135_STAT_REG 0x0
@@ -34,12 +33,11 @@
#define MEN_Z135_CONF_REG 0x808
#define MEN_Z135_UART_FREQ 0x80c
#define MEN_Z135_BAUD_REG 0x810
-#define MENZ135_TIMEOUT0x814
+#define MEN_Z135_TIMEOUT 0x814
#define MEN_Z135_MEM_SIZE 0x818
-#define IS_IRQ(x) ((x) & 1)
-#define IRQ_ID(x) (((x) >> 1) & 7)
+#define IRQ_ID(x) ((x) & 0x1f)
#define MEN_Z135_IER_RXCIEN BIT(0) /* RX Space IRQ */
#define MEN_Z135_IER_TXCIEN BIT(1) /* TX Space IRQ */
@@ -94,11 +92,11 @@
#define MEN_Z135_LSR_TEXP BIT(6)
#define MEN_Z135_LSR_RXFIFOERR BIT(7)
-#define MEN_Z135_IRQ_ID_MST 0
-#define MEN_Z135_IRQ_ID_TSA 1
-#define MEN_Z135_IRQ_ID_RDA 2
-#define MEN_Z135_IRQ_ID_RLS 3
-#define MEN_Z135_IRQ_ID_CTI 6
+#define MEN_Z135_IRQ_ID_RLS BIT(0)
+#define MEN_Z135_IRQ_ID_RDA BIT(1)
+#define MEN_Z135_IRQ_ID_CTI BIT(2)
+#define MEN_Z135_IRQ_ID_TSA BIT(3)
+#define MEN_Z135_IRQ_ID_MST BIT(4)
#define LCR(x) (((x) >> MEN_Z135_LCR_SHIFT) & 0xff)
@@ -118,12 +116,18 @@ static int align;
module_param(align, int, S_IRUGO);
MODULE_PARM_DESC(align, "Keep hardware FIFO write pointer aligned, default 0");
+static uint rx_timeout;
+module_param(rx_timeout, uint, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX timeout. "
+ "Timeout in seconds = (timeout_reg * baud_reg * 4) / freq_reg");
+
struct men_z135_port {
struct uart_port port;
struct mcb_device *mdev;
unsigned char *rxbuf;
u32 stat_reg;
spinlock_t lock;
+ bool automode;
};
#define to_men_z135(port) container_of((port), struct men_z135_port, port)
@@ -180,12 +184,16 @@ static inline void men_z135_reg_clr(struct men_z135_port
*uart,
*/
static void men_z135_handle_modem_status(struct men_z135_port *uart)
{
- if (uart->stat_reg & MEN_Z135_MSR_DDCD)
+ u8 msr;
+
+ msr = (uart->stat_reg >> 8) & 0xff;
+
+ if (msr & MEN_Z135_MSR_DDCD)
uart_handle_dcd_change(>port,
- uart->stat_reg & ~MEN_Z135_MSR_DCD);
- if (uart->stat_reg & MEN_Z135_MSR_DCTS)
+ msr & MEN_Z135_MSR_DCD);
+ if (msr & MEN_Z135_MSR_DCTS)
uart_handle_cts_change(>port,
- uart->stat_reg & ~MEN_Z135_MSR_CTS);
+ msr & MEN_Z135_MSR_CTS);
}
static void men_z135_handle_lsr(struct men_z135_port *uart)
@@ -322,7 +330,8 @@ static void men_z135_handle_tx(struct men_z135_port *uart)
txfree = MEN_Z135_FIFO_WATERMARK - txc;
if (txfree <= 0) {
- pr_err("Not enough room in TX FIFO have %d, need %d\n",
+ dev_err(>mdev->dev,
+ "Not enough room in TX FIFO have %d, need %d\n",
txfree, qlen);
goto irq_en;
}
@@ -373,43 +382,54 @@ out:
* @irq: The IRQ number
* @data: Pointer to UART port
*
- * Check IIR register to see which tasklet to start.
+ * Check IIR register to find the cause of the interrupt and handle it.
+ * It
Re: [RFC v4] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
Hi,
On Fri, Oct 31, 2014 at 09:27:43AM +0530, Kiran Raparthy wrote:
> >>> Thank you very much for taking time in reviewing the patch.
> >>> I will try to improve the patch as per your suggestions.
> >>> however,i have few queries which i wanted to understand from you.
> >>
> >> sure thing.
> >>
> >>> On 7 October 2014 19:55, Felipe Balbi wrote:
> >>> >> +static int otg_wakeupsource_init(void)
> >>> >> +{
> >>> >> + int ret_usb2;
> >>> >> + int ret_usb3;
> >>> >> + char wsource_name_usb2[40];
> >>> >> + char wsource_name_usb3[40];
> >>> >> + static struct usb_phy *otgws_xceiv_usb2;
> >>> >> + static struct usb_phy *otgws_xceiv_usb3;
> >>> >> +
> >>> >> + otgws_xceiv_usb2 = usb_get_phy(USB_PHY_TYPE_USB2);
> >>> >> + otgws_xceiv_usb3 = usb_get_phy(USB_PHY_TYPE_USB3);
> >>> >> +
> >>> >> + if (IS_ERR(otgws_xceiv_usb2) && IS_ERR(otgws_xceiv_usb3)) {
> >>> >> + pr_err("%s: No OTG transceiver found\n", __func__);
> >>> >> + return PTR_ERR(otgws_xceiv_usb2);
> >>> >> + }
> >>> >> +
> >>> >> + spin_lock_init(_xceiv_usb2->otgws_slock);
> >>> >> + spin_lock_init(_xceiv_usb3->otgws_slock);
> >>> >> +
> >>> >> + snprintf(wsource_name_usb2, sizeof(wsource_name_usb2),
> >>> >> "vbus-%s",
> >>> >> + dev_name(otgws_xceiv_usb2->dev));
> >>> >> + wakeup_source_init(_xceiv_usb2->wsource,
> >>> >> wsource_name_usb2);
> >>> >> +
> >>> >> + snprintf(wsource_name_usb3, sizeof(wsource_name_usb3),
> >>> >> "vbus-%s",
> >>> >> + dev_name(otgws_xceiv_usb3->dev));
> >>> >> + wakeup_source_init(_xceiv_usb3->wsource,
> >>> >> wsource_name_usb3);
> >>> >> +
> >>> >> + otgws_xceiv_usb2->otgws_nb.notifier_call =
> >>> >> otgws_otg_usb2_notifications;
> >>> >> + ret_usb2 = usb_register_notifier(otgws_xceiv_usb2,
> >>> >> + _xceiv_usb2->otgws_nb);
> >>> >> +
> >>> >> + otgws_xceiv_usb3->otgws_nb.notifier_call =
> >>> >> otgws_otg_usb3_notifications;
> >>> >> + ret_usb3 = usb_register_notifier(otgws_xceiv_usb3,
> >>> >> + _xceiv_usb3->otgws_nb);
> >>> >> +
> >>> >> + if (ret_usb2 && ret_usb3) {
> >>> >> + pr_err("%s: usb_register_notifier on transceiver
> >>> >> failed\n",
> >>> >> + __func__);
> >>> >> + wakeup_source_trash(_xceiv_usb2->wsource);
> >>> >> + wakeup_source_trash(_xceiv_usb3->wsource);
> >>> >> + otgws_xceiv_usb2 = NULL;
> >>> >> + otgws_xceiv_usb3 = NULL;
> >>> >> + return ret_usb2 | ret_usb3;
> >>> >> + }
> >>> >> +
> >>> >> + return 0;
> >>> >> +}
> >>> >> +
> >>> >> +late_initcall(otg_wakeupsource_init);
> >>> >
> >>> > you guys are really not getting what I mean. I asked for this to be
> >>> > built into the core itself. This means that you shouldn't need to use
> >>> > notifications nor should you need to call usb_get_phy(). You're part of
> >>> > the PHY framework.
> >>> >
> >>> > All this late_initcall() nonsense should go.
> >>> >
> >>> > This code won't even work if we have more than one phy of the same type
> >>> > (AM437x SoC, for example, has up to 4 instances of dwc3, so that's 4
> >>> > USB2 PHYs), because you can't grab the PHY you want.
> >>>
> >>> Apologies,I am new to usb sub system,so i missed this point before i
> >>> posted my patch,Thanks for the information.
> >>
> >> np.
> >>
> >>> > What you need is to:
> >>> >
> >>> > 1) make PHY notifiers generic (move all of that phy-core.c)
> >>> From the above points,you mentioned that "if we built it into core,we
> >>> shouldn't need to use notifications"
> >>> and your first point here says that make phy notifiers generic in
> >>> phy-core.c
> >>> can you help me understanding it better so that there wont be any
> >>> understanding gap.
> >>
> >> yeah, notifiers should go but if you really must use them, then at least
> >> make all of that generic ;-)
> >>
> >>> > 2) introduce usb_phy_set_event(phy, event) (which just sets the even to
> >>> > a
> >>> > phy->event member for now)
> >>> > 3) make all PHY drivers use usb_phy_set_event()
> >>> > 4) add the following to usb_phy_set_event()
> >>> >
> >>> > switch (event) {
> >>> > case USB_EVENT_ENUMERATED:
> >>> > pm_stay_awake(_xceiv->wsource);
> >>> > break;
> >>> >
> >>> > case USB_EVENT_NONE:
> >>> > case USB_EVENT_VBUS:
> >>> > case USB_EVENT_ID:
> >>> > case USB_EVENT_CHARGER:
> >>> > pm_wakeup_event(_xceiv->wsource,
> >>> > msecs_to_jiffies(TEMPORARY_HOLD_TIME));
> >>> > break;
> >>> >
> >>> > default:
> >>> > break;
> >>> > }
> >>> >
> >>> Once the phy drivers receives per-PHY event notification(if we use
> >>> notifier,else "for any event") we can call usb_phy_set_event from phy
> >>> driver to hold the wakeup source.
> >>>
Re: [PATCH v4] usb: gadget: f_fs: add "no_disconnect" mode
Hi,
On Thu, Oct 09, 2014 at 03:21:51PM +0200, Robert Baldyga wrote:
> Since we can compose gadgets from many functions, there is the problem
> related to gadget breakage while FunctionFS daemon being closed. FFS
> function is userspace code so there is no way to know when it will close
> files (it doesn't matter what is the reason of this situation, it can
> be daemon logic, program breakage, process kill or any other). So when
> we have another function in gadget which, for example, sends some amount
> of data, does some software update or implements some real-time functionality,
> we may want to keep the gadget connected despite FFS function is no longer
> functional.
>
> We can't just remove one of functions from gadget since it has been
> enumerated, so the only way to keep entire gadget working is to make
> broken FFS function deactivated but still visible to host. For this
> purpose this patch introduces "no_disconnect" mode. It can be enabled
> by setting mount option "no_disconnect=1", and results with defering
> function disconnect to the moment of reopen ep0 file or filesystem
> unmount. After closing all endpoint files, FunctionFS is set to state
> FFS_DEACTIVATED.
>
> When ffs->state == FFS_DEACTIVATED:
> - function is still bound and visible to host,
> - setup requests are automatically stalled,
> - transfers on other endpoints are refused,
> - epfiles, except ep0, are deleted from the filesystem,
> - opening ep0 causes the function to be closes, and then FunctionFS
> is ready for descriptors and string write,
> - unmounting of the FunctionFS instance causes the function to be closed.
>
> Signed-off-by: Robert Baldyga
David, you have been messing with ffs lately, can I get a Tested-by from
you on this patch ?
> ---
>
> Changelog:
>
> v4:
> - use ffs_data_reset() instead of ffs_data_clear() to reset ffs data
> properly after ffs->ref refcount reach 0 (or under in no_disconnect
> mode) in ffs_data_put() function
>
> v3: https://lkml.org/lkml/2014/10/9/170
> - change option name to more descriptive and less scary,
> - fix cleaning up on unmount (call ffs_data_closed() in ffs_fs_kill_sb(),
> and ffs_data_clear() in ffs_data_closed() if ffs->opened is negative).
>
> v2: https://lkml.org/lkml/2014/10/7/109
> - delete epfiles, excepting ep0, when FFS is in "zombie" mode,
> - add description of FFS_ZOMBIE state,
> - minor cleanups.
>
> v1: https://lkml.org/lkml/2014/10/6/128
>
> drivers/usb/gadget/function/f_fs.c | 42
> +++---
> drivers/usb/gadget/function/u_fs.h | 22
> 2 files changed, 57 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 12dbdaf..2d47d4a 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -606,6 +606,8 @@ static unsigned int ffs_ep0_poll(struct file *file,
> poll_table *wait)
> }
> case FFS_CLOSING:
> break;
> + case FFS_DEACTIVATED:
> + break;
> }
>
> mutex_unlock(>mutex);
> @@ -1152,6 +1154,7 @@ struct ffs_sb_fill_data {
> struct ffs_file_perms perms;
> umode_t root_mode;
> const char *dev_name;
> + bool no_disconnect;
> struct ffs_data *ffs_data;
> };
>
> @@ -1222,6 +1225,12 @@ static int ffs_fs_parse_opts(struct ffs_sb_fill_data
> *data, char *opts)
>
> /* Interpret option */
> switch (eq - opts) {
> + case 13:
> + if (!memcmp(opts, "no_disconnect", 13))
> + data->no_disconnect = !!value;
> + else
> + goto invalid;
> + break;
> case 5:
> if (!memcmp(opts, "rmode", 5))
> data->root_mode = (value & 0555) | S_IFDIR;
> @@ -1286,6 +1295,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
> .gid = GLOBAL_ROOT_GID,
> },
> .root_mode = S_IFDIR | 0500,
> + .no_disconnect = false,
> };
> struct dentry *rv;
> int ret;
> @@ -1302,6 +1312,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
> if (unlikely(!ffs))
> return ERR_PTR(-ENOMEM);
> ffs->file_perms = data.perms;
> + ffs->no_disconnect = data.no_disconnect;
>
> ffs->dev_name = kstrdup(dev_name, GFP_KERNEL);
> if (unlikely(!ffs->dev_name)) {
> @@ -1333,6 +1344,7 @@ ffs_fs_kill_sb(struct super_block *sb)
> kill_litter_super(sb);
> if (sb->s_fs_info) {
> ffs_release_dev(sb->s_fs_info);
> + ffs_data_closed(sb->s_fs_info);
> ffs_data_put(sb->s_fs_info);
> }
> }
> @@ -1389,7 +1401,9 @@ static void ffs_data_opened(struct ffs_data *ffs)
> ENTER();
>
> atomic_inc(>ref);
> - atomic_inc(>opened);
> + if
Re: [PATCH v7 7/8] xen/arm/arm64: introduce xen_arch_need_swiotlb
On Mon, Nov 03, 2014 at 10:45:14AM +, Stefano Stabellini wrote:
> On Mon, 27 Oct 2014, Stefano Stabellini wrote:
> > Introduce an arch specific function to find out whether a particular dma
> > mapping operation needs to bounce on the swiotlb buffer.
> >
> > On ARM and ARM64, if the page involved is a foreign page and the device
> > is not coherent, we need to bounce because at unmap time we cannot
> > execute any required cache maintenance operations (we don't know how to
> > find the pfn from the mfn).
> >
> > No change of behaviour for x86.
> >
> > Signed-off-by: Stefano Stabellini
> > Acked-by: Ian Campbell
>
> Konrad, David, are you OK with the swiotlb-xen changes?
I am OK.
>
>
>
> > Changes in v6:
> > - fix ts.
> >
> > Changes in v5:
> > - fix indentation.
> > ---
> > arch/arm/include/asm/xen/page.h |4
> > arch/arm/xen/mm.c |7 +++
> > arch/x86/include/asm/xen/page.h |7 +++
> > drivers/xen/swiotlb-xen.c |5 -
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/xen/page.h
> > b/arch/arm/include/asm/xen/page.h
> > index 135c24a..68c739b 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long
> > pfn, unsigned long mfn)
> > #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
> > #define xen_unmap(cookie) iounmap((cookie))
> >
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > + unsigned long pfn,
> > + unsigned long mfn);
> > +
> > #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index ff413a8..28396aa 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -139,6 +139,13 @@ void xen_dma_sync_single_for_device(struct device
> > *hwdev,
> > __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
> > }
> >
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > + unsigned long pfn,
> > + unsigned long mfn)
> > +{
> > + return ((pfn != mfn) && !is_device_dma_coherent(dev));
> > +}
> > +
> > int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> > unsigned int address_bits,
> > dma_addr_t *dma_handle)
> > diff --git a/arch/x86/include/asm/xen/page.h
> > b/arch/x86/include/asm/xen/page.h
> > index c949923..f58ef6c 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
> > #define xen_remap(cookie, size) ioremap((cookie), (size));
> > #define xen_unmap(cookie) iounmap((cookie))
> >
> > +static inline bool xen_arch_need_swiotlb(struct device *dev,
> > +unsigned long pfn,
> > +unsigned long mfn)
> > +{
> > + return false;
> > +}
> > +
> > #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index ebd8f21..ac5d41b 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev,
> > struct page *page,
> > * buffering it.
> > */
> > if (dma_capable(dev, dev_addr, size) &&
> > - !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> > + !range_straddles_page_boundary(phys, size) &&
> > + !xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr))
> > &&
> > + !swiotlb_force) {
> > /* we are not interested in the dma_addr returned by
> > * xen_dma_map_page, only in the potential cache flushes
> > executed
> > * by the function. */
> > @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct
> > scatterlist *sgl,
> > dma_addr_t dev_addr = xen_phys_to_bus(paddr);
> >
> > if (swiotlb_force ||
> > + xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr),
> > PFN_DOWN(dev_addr)) ||
> > !dma_capable(hwdev, dev_addr, sg->length) ||
> > range_straddles_page_boundary(paddr, sg->length)) {
> > phys_addr_t map = swiotlb_tbl_map_single(hwdev,
> > --
> > 1.7.10.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] powernv: powerpc: Add winkle support for offline cpus
Winkle is a deep idle state supported in power8 chips. A core enters
winkle when all the threads of the core enter winkle. In this state
power supply to the entire chiplet i.e core, private L2 and private L3
is turned off. As a result it gives higher powersavings compared to
sleep.
But entering winkle results in a total hypervisor state loss. Hence the
hypervisor context has to be preserved before entering winkle and
restored upon wake up.
Power-on Reset Engine (PORE) is a dedicated engine which is responsible
for powering on the chiplet during wake up. It can be programmed to
restore the register contests of a few specific registers. This patch
uses PORE to restore register state wherever possible and uses stack to
save and restore rest of the necessary registers.
With hypervisor state restore things fall under three categories-
per-core state, per-subcore state and per-thread state. To manage this,
extend the infrastructure introduced for sleep. Mainly we add a paca
variable subcore_sibling_mask. Using this and the core_idle_state we can
distingush first thread in core and subcore.
Signed-off-by: Shreyas B. Prabhu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/opal.h| 3 +
arch/powerpc/include/asm/paca.h| 2 +
arch/powerpc/include/asm/ppc-opcode.h | 2 +
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/include/asm/reg.h | 2 +
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/cpu_setup_power.S | 4 +
arch/powerpc/kernel/exceptions-64s.S | 10 ++
arch/powerpc/kernel/idle_power7.S | 161 ++---
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +
arch/powerpc/platforms/powernv/setup.c | 73 +++
arch/powerpc/platforms/powernv/smp.c | 4 +-
arch/powerpc/platforms/powernv/subcore.c | 34 ++
arch/powerpc/platforms/powernv/subcore.h | 1 +
14 files changed, 285 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index bef7fbc..f0ca2d9 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -153,6 +153,7 @@ struct opal_sg_list {
#define OPAL_PCI_EEH_FREEZE_SET97
#define OPAL_HANDLE_HMI98
#define OPAL_CONFIG_CPU_IDLE_STATE 99
+#define OPAL_SLW_SET_REG 100
#define OPAL_REGISTER_DUMP_REGION 101
#define OPAL_UNREGISTER_DUMP_REGION102
@@ -163,6 +164,7 @@ struct opal_sg_list {
*/
#define OPAL_PM_NAP_ENABLED0x0001
#define OPAL_PM_SLEEP_ENABLED 0x0002
+#define OPAL_PM_WINKLE_ENABLED 0x0004
#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008
#ifndef __ASSEMBLY__
@@ -972,6 +974,7 @@ int64_t opal_sensor_read(uint32_t sensor_hndl, int token,
__be32 *sensor_data);
int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
+int64_t opal_slw_set_reg(uint64_t cpu_pir, uint64_t sprn, uint64_t val);
int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
/* Internal functions */
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 85aeedb..c2e51b7 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -162,6 +162,8 @@ struct paca_struct {
/* Per-core mask tracking idle threads and a lock bit-[L][] */
u32 *core_idle_state_ptr;
u8 thread_idle_state; /* ~Idle[0]/Nap[1]/Sleep[2]/Winkle[3] */
+ /* Mask to denote subcore sibling threads */
+ u8 subcore_sibling_mask;
#endif
#ifdef CONFIG_PPC_BOOK3S_64
/* Exclusive emergency stack pointer for machine check exception. */
diff --git a/arch/powerpc/include/asm/ppc-opcode.h
b/arch/powerpc/include/asm/ppc-opcode.h
index 6f85362..5155be7 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -194,6 +194,7 @@
#define PPC_INST_NAP 0x4c000364
#define PPC_INST_SLEEP 0x4c0003a4
+#define PPC_INST_WINKLE0x4c0003e4
/* A2 specific instructions */
#define PPC_INST_ERATWE0x7c0001a6
@@ -374,6 +375,7 @@
#define PPC_NAPstringify_in_c(.long PPC_INST_NAP)
#define PPC_SLEEP stringify_in_c(.long PPC_INST_SLEEP)
+#define PPC_WINKLE stringify_in_c(.long PPC_INST_WINKLE)
/* BHRB instructions */
#define PPC_CLRBHRBstringify_in_c(.long PPC_INST_CLRBHRB)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index dda7ac4..c076842 100644
--- a/arch/powerpc/include/asm/processor.h
+++
[PATCH 1/4] powerpc: powernv: Switch off MMU before entering nap/sleep/rvwinkle mode
From: Paul Mackerras Currently, when going idle, we set the flag indicating that we are in nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap (or sleep or rvwinkle) instruction, all with the MMU on. This is bad for two reasons: (a) the architecture specifies that those instructions must be executed with the MMU off, and in fact with only the SF, HV, ME and possibly RI bits set, and (b) this introduces a race, because as soon as we set the flag, another thread can switch the MMU to a guest context. If the race is lost, this thread will typically start looping on relocation-on ISIs at 0xc...4400. This fixes it by setting the MSR as required by the architecture before setting the flag or executing the nap/sleep/rvwinkle instruction. [ shre...@linux.vnet.ibm.com: Edited to handle LE ] Signed-off-by: Paul Mackerras Signed-off-by: Shreyas B. Prabhu Cc: Benjamin Herrenschmidt Cc: Michael Ellerman Cc: linuxppc-...@lists.ozlabs.org --- arch/powerpc/include/asm/reg.h| 2 ++ arch/powerpc/kernel/idle_power7.S | 18 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index c998279..a68ee15 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -118,8 +118,10 @@ #define __MSR (MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_ISF |MSR_HV) #ifdef __BIG_ENDIAN__ #define MSR_ __MSR +#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV) #else #define MSR_ (__MSR | MSR_LE) +#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV | MSR_LE) #endif #define MSR_KERNEL (MSR_ | MSR_64BIT) #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index c0754bb..283c603 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -101,7 +101,23 @@ _GLOBAL(power7_powersave_common) std r9,_MSR(r1) std r1,PACAR1(r13) -_GLOBAL(power7_enter_nap_mode) + /* +* Go to real mode to do the nap, as required by the architecture. +* Also, we need to be in real mode before setting hwthread_state, +* because as soon as we do that, another thread can switch +* the MMU context to the guest. +*/ + LOAD_REG_IMMEDIATE(r5, MSR_IDLE) + li r6, MSR_RI + andcr6, r9, r6 + LOAD_REG_ADDR(r7, power7_enter_nap_mode) + mtmsrd r6, 1 /* clear RI before setting SRR0/1 */ + mtspr SPRN_SRR0, r7 + mtspr SPRN_SRR1, r5 + rfid + + .globl power7_enter_nap_mode +power7_enter_nap_mode: #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE /* Tell KVM we're napping */ li r4,KVM_HWTHREAD_IN_NAP -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states
From: "Preeti U. Murthy"
The secondary threads should enter deep idle states so as to gain maximum
powersavings when the entire core is offline. To do so the offline path
must be made aware of the available deepest idle state. Hence probe the
device tree for the possible idle states in powernv core code and
expose the deepest idle state through flags.
Since the device tree is probed by the cpuidle driver as well, move
the parameters required to discover the idle states into an appropriate
common place to both the driver and the powernv core code.
Another point is that fastsleep idle state may require workarounds in
the kernel to function properly. This workaround is introduced in the
subsequent patches. However neither the cpuidle driver or the hotplug
path need be bothered about this workaround.
They will be taken care of by the core powernv code.
Originally-by: Srivatsa S. Bhat
Signed-off-by: Preeti U. Murthy
Signed-off-by: Shreyas B. Prabhu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/opal.h | 8 ++
arch/powerpc/platforms/powernv/powernv.h | 2 ++
arch/powerpc/platforms/powernv/setup.c | 49
arch/powerpc/platforms/powernv/smp.c | 7 -
drivers/cpuidle/cpuidle-powernv.c| 9 ++
5 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9124b0e..f8b95c0 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -155,6 +155,14 @@ struct opal_sg_list {
#define OPAL_REGISTER_DUMP_REGION 101
#define OPAL_UNREGISTER_DUMP_REGION102
+/* Device tree flags */
+
+/* Flags set in power-mgmt nodes in device tree if
+ * respective idle states are supported in the platform.
+ */
+#define OPAL_PM_NAP_ENABLED0x0001
+#define OPAL_PM_SLEEP_ENABLED 0x0002
+
#ifndef __ASSEMBLY__
#include
diff --git a/arch/powerpc/platforms/powernv/powernv.h
b/arch/powerpc/platforms/powernv/powernv.h
index 6c8e2d1..604c48e 100644
--- a/arch/powerpc/platforms/powernv/powernv.h
+++ b/arch/powerpc/platforms/powernv/powernv.h
@@ -29,6 +29,8 @@ static inline u64 pnv_pci_dma_get_required_mask(struct
pci_dev *pdev)
}
#endif
+extern u32 pnv_get_supported_cpuidle_states(void);
+
extern void pnv_lpc_init(void);
bool cpu_core_split_required(void);
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 3f9546d..34c6665 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -290,6 +290,55 @@ static void __init pnv_setup_machdep_rtas(void)
}
#endif /* CONFIG_PPC_POWERNV_RTAS */
+static u32 supported_cpuidle_states;
+
+u32 pnv_get_supported_cpuidle_states(void)
+{
+ return supported_cpuidle_states;
+}
+
+static int __init pnv_init_idle_states(void)
+{
+ struct device_node *power_mgt;
+ int dt_idle_states;
+ const __be32 *idle_state_flags;
+ u32 len_flags, flags;
+ int i;
+
+ supported_cpuidle_states = 0;
+
+ if (cpuidle_disable != IDLE_NO_OVERRIDE)
+ return 0;
+
+ if (!firmware_has_feature(FW_FEATURE_OPALv3))
+ return 0;
+
+ power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
+ if (!power_mgt) {
+ pr_warn("opal: PowerMgmt Node not found\n");
+ return 0;
+ }
+
+ idle_state_flags = of_get_property(power_mgt,
+ "ibm,cpu-idle-state-flags", _flags);
+ if (!idle_state_flags) {
+ pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
+ return 0;
+ }
+
+ dt_idle_states = len_flags / sizeof(u32);
+
+ for (i = 0; i < dt_idle_states; i++) {
+ flags = be32_to_cpu(idle_state_flags[i]);
+ supported_cpuidle_states |= flags;
+ }
+
+ return 0;
+}
+
+subsys_initcall(pnv_init_idle_states);
+
+
static int __init pnv_probe(void)
{
unsigned long root = of_get_flat_dt_root();
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index 4753958..3dc4cec 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -149,6 +149,7 @@ static int pnv_smp_cpu_disable(void)
static void pnv_smp_cpu_kill_self(void)
{
unsigned int cpu;
+ u32 idle_states;
/* Standard hot unplug procedure */
local_irq_disable();
@@ -159,13 +160,17 @@ static void pnv_smp_cpu_kill_self(void)
generic_set_cpu_dead(cpu);
smp_wmb();
+ idle_states = pnv_get_supported_cpuidle_states();
/* We don't want to take decrementer interrupts while we are offline,
* so clear LPCR:PECE1. We keep PECE2 enabled.
*/
mtspr(SPRN_LPCR,
[PATCH 3/4] powernv: cpuidle: Redesign idle states management
Deep idle states like sleep and winkle are per core idle states. A core
enters these states only when all the threads enter either the
particular idle state or a deeper one. There are tasks like fastsleep
hardware bug workaround and hypervisor core state save which have to be
done only by the last thread of the core entering deep idle state and
similarly tasks like timebase resync, hypervisor core register restore
that have to be done only by the first thread waking up from these
state.
The current idle state management does not have a way to distinguish the
first/last thread of the core waking/entering idle states. Tasks like
timebase resync are done for all the threads. This is not only is
suboptimal, but can cause functionality issues when subcores and kvm is
involved.
This patch adds the necessary infrastructure to track idle states of
threads in a per-core structure. It uses this info to perform tasks like
fastsleep workaround and timebase resync only once per core.
Signed-off-by: Shreyas B. Prabhu
Originally-by: Preeti U. Murthy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/cpuidle.h | 14 ++
arch/powerpc/include/asm/opal.h| 2 +
arch/powerpc/include/asm/paca.h| 4 +
arch/powerpc/kernel/asm-offsets.c | 4 +
arch/powerpc/kernel/exceptions-64s.S | 20 ++-
arch/powerpc/kernel/idle_power7.S | 183 +++--
arch/powerpc/platforms/powernv/opal-wrappers.S | 37 +
arch/powerpc/platforms/powernv/setup.c | 52 ++-
arch/powerpc/platforms/powernv/smp.c | 3 +-
drivers/cpuidle/cpuidle-powernv.c | 3 +-
10 files changed, 267 insertions(+), 55 deletions(-)
create mode 100644 arch/powerpc/include/asm/cpuidle.h
diff --git a/arch/powerpc/include/asm/cpuidle.h
b/arch/powerpc/include/asm/cpuidle.h
new file mode 100644
index 000..8c82850
--- /dev/null
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_POWERPC_CPUIDLE_H
+#define _ASM_POWERPC_CPUIDLE_H
+
+#ifdef CONFIG_PPC_POWERNV
+/* Used in powernv idle state management */
+#define PNV_THREAD_RUNNING 0
+#define PNV_THREAD_NAP 1
+#define PNV_THREAD_SLEEP2
+#define PNV_THREAD_WINKLE 3
+#define PNV_CORE_IDLE_LOCK_BIT 0x100
+#define PNV_CORE_IDLE_THREAD_BITS 0x0FF
+#endif
+
+#endif
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index f8b95c0..bef7fbc 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -152,6 +152,7 @@ struct opal_sg_list {
#define OPAL_PCI_ERR_INJECT96
#define OPAL_PCI_EEH_FREEZE_SET97
#define OPAL_HANDLE_HMI98
+#define OPAL_CONFIG_CPU_IDLE_STATE 99
#define OPAL_REGISTER_DUMP_REGION 101
#define OPAL_UNREGISTER_DUMP_REGION102
@@ -162,6 +163,7 @@ struct opal_sg_list {
*/
#define OPAL_PM_NAP_ENABLED0x0001
#define OPAL_PM_SLEEP_ENABLED 0x0002
+#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index a5139ea..85aeedb 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -158,6 +158,10 @@ struct paca_struct {
* early exception handler for use by high level C handler
*/
struct opal_machine_check_event *opal_mc_evt;
+
+ /* Per-core mask tracking idle threads and a lock bit-[L][] */
+ u32 *core_idle_state_ptr;
+ u8 thread_idle_state; /* ~Idle[0]/Nap[1]/Sleep[2]/Winkle[3] */
#endif
#ifdef CONFIG_PPC_BOOK3S_64
/* Exclusive emergency stack pointer for machine check exception. */
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 9d7dede..50f299e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -731,6 +731,10 @@ int main(void)
DEFINE(OPAL_MC_SRR0, offsetof(struct opal_machine_check_event, srr0));
DEFINE(OPAL_MC_SRR1, offsetof(struct opal_machine_check_event, srr1));
DEFINE(PACA_OPAL_MC_EVT, offsetof(struct paca_struct, opal_mc_evt));
+ DEFINE(PACA_CORE_IDLE_STATE_PTR,
+ offsetof(struct paca_struct, core_idle_state_ptr));
+ DEFINE(PACA_THREAD_IDLE_STATE,
+ offsetof(struct paca_struct, thread_idle_state));
#endif
return 0;
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 72e783e..3311c8d 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
/*
* We layout
Re: [PATCH v4 12/14] regulator: max77802: Use unsigned int for modes in max77802_map_mode()
On Mon, Nov 03, 2014 at 03:40:47PM +0100, Javier Martinez Canillas wrote: > All function dealing with operating modes use unsigned int for modes > so change max77802_map_mode() function signature for consistency. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v4 00/14] Add max77802 regulator operating mode support
On Mon, Nov 03, 2014 at 03:54:43PM +, Mark Brown wrote: > On Mon, Nov 03, 2014 at 03:40:35PM +0100, Javier Martinez Canillas wrote: > > Hello Mark, > > > > This is the fourth version of the series that adds operating modes > > support for the regulators in the max77802 PMIC. This version uses > No, it's not. This is a a patch series doing a whole bunch of different > things, there's at least bug fixes to existing drivers, new features and > also this new driver in what I've glanced at so far. These things s/new driver/new driver support/ sorry Point being that operating mode support in the driver is mostly orthogonal to DT bindings is mostly orthogonal to random bug fixes. signature.asc Description: Digital signature
Re: [PATCH] usb: musb: replace hard coded registers with defines
On Mon, Oct 27, 2014 at 09:48:39PM +0100, Roman Byshko wrote: > musb registers can be dumped using the file regdump > which is created in debugfs. Up to now hard coded > register addresses are used for that. Different glue > layers however have different register addresses. The > patch addresses this issue by substituting bare register > addresses with defines. missing Signed-off-by, can't accept. Sorry. -- balbi signature.asc Description: Digital signature
Re: [PATCH] mfd: twl4030-power: Fix regression with missing compatible flag
On Sun, 02 Nov 2014, Tony Lindgren wrote:
> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> configuration") accidentally removed the compatible flag for
> "ti,twl4030-power" that should be there as documented in the
> binding.
>
> If "ti,twl4030-power" only the poweroff configuration is done
> by the driver.
>
> Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
> Cc: sta...@vger.kernel.org # v3.16+
> Reported-by: "Dr. H. Nikolaus Schaller"
> Signed-off-by: Tony Lindgren
Applied, thanks.
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -831,6 +831,9 @@ static struct twl4030_power_data osc_off_idle = {
>
> static struct of_device_id twl4030_power_of_match[] = {
> {
> + .compatible = "ti,twl4030-power",
> + },
> + {
> .compatible = "ti,twl4030-power-reset",
> .data = _reset,
> },
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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 0/4] powernv: cpuidle: Redesign idle states management
Deep idle states like sleep and winkle are per core idle states. A core enters these states only when all the threads enter either the particular idle state or a deeper one. There are tasks like fastsleep hardware bug workaround and hypervisor core state save which have to be done only by the last thread of the core entering deep idle state and similarly tasks like timebase resync, hypervisor core register restore that have to be done only by the first thread waking up from these states. The current idle state management does not have a way to distinguish the first/last thread of the core waking/entering idle states. Tasks like timebase resync are done for all the threads. This is not only is suboptimal, but can cause functionality issues when subcores are involved. Winkle is deeper idle state compared to fastsleep. In this state the power supply to the chiplet, i.e core, private L2 and private L3 is turned off. This results in a total hypervisor state loss. This patch set adds support for winkle and provides a way to track the idle states of the threads of the core and use it for idle state management of idle states sleep and winkle. TODO: - Handle the case where a thread enters nap and wakes up with supervisor/ hypervisor state loss. This can only happen due to a bug in the hardware or the kernel. One way to handle this can be restore the state, switch to the kernel process context and trigger a panic or a warning. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rafael J. Wysocki Cc: linux...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: Vaidyanathan Srinivasan Cc: Preeti U Murthy Paul Mackerras (1): powerpc: powernv: Switch off MMU before entering nap/sleep/rvwinkle mode Preeti U. Murthy (1): powerpc/powernv: Enable Offline CPUs to enter deep idle states Shreyas B. Prabhu (2): powernv: cpuidle: Redesign idle states management powernv: powerpc: Add winkle support for offline cpus arch/powerpc/include/asm/cpuidle.h | 14 ++ arch/powerpc/include/asm/opal.h| 13 + arch/powerpc/include/asm/paca.h| 6 + arch/powerpc/include/asm/ppc-opcode.h | 2 + arch/powerpc/include/asm/processor.h | 1 + arch/powerpc/include/asm/reg.h | 2 + arch/powerpc/kernel/asm-offsets.c | 6 + arch/powerpc/kernel/cpu_setup_power.S | 4 + arch/powerpc/kernel/exceptions-64s.S | 30 ++- arch/powerpc/kernel/idle_power7.S | 326 + arch/powerpc/platforms/powernv/opal-wrappers.S | 39 +++ arch/powerpc/platforms/powernv/powernv.h | 2 + arch/powerpc/platforms/powernv/setup.c | 170 + arch/powerpc/platforms/powernv/smp.c | 10 +- arch/powerpc/platforms/powernv/subcore.c | 35 +++ arch/powerpc/platforms/powernv/subcore.h | 1 + drivers/cpuidle/cpuidle-powernv.c | 10 +- 17 files changed, 611 insertions(+), 60 deletions(-) create mode 100644 arch/powerpc/include/asm/cpuidle.h -- 1.9.3 -- 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 00/14] Add max77802 regulator operating mode support
On 11/03/2014 04:54 PM, Mark Brown wrote: > > No, it's not. This is a a patch series doing a whole bunch of different > things, there's at least bug fixes to existing drivers, new features and > also this new driver in what I've glanced at so far. These things > shouldn't just be being thrown together into a single patch series, and > the patch series shouldn't then be described as just being what is in > the end a minor part of the collection. > Ok, sorry. Next time I'll take care to split fixes from new features and also better explain what the series really does. 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: [PATCH v2 01/11] crypto: Documentation - crypto API high level spec
On 11/03/2014 08:49 AM, Herbert Xu wrote: On Mon, Nov 03, 2014 at 03:18:29PM +0100, Stephan Mueller wrote: + * CRYPTO_ALG_TYPE_DIGEST Raw message digest + * CRYPTO_ALG_TYPE_HASHAlias for CRYPTO_ALG_TYPE_DIGEST + * CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash + * CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash + * CRYPTO_ALG_TYPE_RNG Random Number Generation + * CRYPTO_ALG_TYPE_PCOMPRESS What's that last one? Same here. pcompress is an enhanced version of compress allowing for piece-meal compression/decompression rather than having to shove everything in all at once. Eventually pcompress should replace the compress interface once everything is converted across. Herbert, I was looking at adding async support for ALG_TYPE_COMPRESS since the CCP device will support compression/decompression but only as an everything at once invocation. Given what you're saying about pcompress replacing compress, would this be something you'd even consider though? Thanks, Tom Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: db8500-prcmu: check return of devm_ioremap for error
On Thu, 30 Oct 2014, Pramod Gurav wrote:
> Error check around return value of devm_ioremap is missing. Add the same
> to avoid NULL pointer dereference.
>
> Cc: Linus Walleij
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Pramod Gurav
> ---
> drivers/mfd/db8500-prcmu.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> index 193cf16..89ae8bf 100644
> --- a/drivers/mfd/db8500-prcmu.c
> +++ b/drivers/mfd/db8500-prcmu.c
> @@ -3167,6 +3167,11 @@ static int db8500_prcmu_probe(struct platform_device
> *pdev)
> }
> tcdm_base = devm_ioremap(>dev, res->start,
> resource_size(res));
> + if (!tcdm_base) {
> + dev_err(>dev,
> + "failed to ioremap prcmu-tcdm register memory\n");
> + return -ENOENT;
No such file or directory? I think not.
Changed to -ENOMEM and applied with Linus' Ack.
> + }
>
> /* Clean up the mailbox interrupts after pre-kernel code. */
> writel(ALL_MBOX_BITS, PRCM_ARM_IT1_CLR);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/6] hw_random: place mutex around read functions and buffers.
From: Rusty Russell
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading. This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)
This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.
Signed-off-by: Rusty Russell
---
drivers/char/hw_random/core.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..b1b6042 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
static struct hwrng *current_rng;
static struct task_struct *hwrng_fill;
static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
+ mutex_lock(_mutex);
bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+ mutex_unlock(_mutex);
if (bytes_read > 0)
add_device_randomness(bytes, bytes_read);
}
@@ -128,6 +133,7 @@ static inline int rng_get_data(struct hwrng *rng, u8
*buffer, size_t size,
int wait) {
int present;
+ BUG_ON(!mutex_is_locked(_mutex));
if (rng->read)
return rng->read(rng, (void *)buffer, size, wait);
@@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
goto out_unlock;
}
+ mutex_lock(_mutex);
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
err = bytes_read;
- goto out_unlock;
+ goto out_unlock_reading;
}
data_avail = bytes_read;
}
@@ -174,7 +181,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user
*buf,
if (!data_avail) {
if (filp->f_flags & O_NONBLOCK) {
err = -EAGAIN;
- goto out_unlock;
+ goto out_unlock_reading;
}
} else {
len = data_avail;
@@ -186,7 +193,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user
*buf,
if (copy_to_user(buf + ret, rng_buffer + data_avail,
len)) {
err = -EFAULT;
- goto out_unlock;
+ goto out_unlock_reading;
}
size -= len;
@@ -194,6 +201,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user
*buf,
}
mutex_unlock(_mutex);
+ mutex_unlock(_mutex);
if (need_resched())
schedule_timeout_interruptible(1);
@@ -208,6 +216,9 @@ out:
out_unlock:
mutex_unlock(_mutex);
goto out;
+out_unlock_reading:
+ mutex_unlock(_mutex);
+ goto out_unlock;
}
@@ -348,13 +359,16 @@ static int hwrng_fillfn(void *unused)
while (!kthread_should_stop()) {
if (!current_rng)
break;
+ mutex_lock(_mutex);
rc = rng_get_data(current_rng, rng_fillbuf,
rng_buffer_size(), 1);
+ mutex_unlock(_mutex);
if (rc <= 0) {
pr_warn("hwrng: no data available\n");
msleep_interruptible(1);
continue;
}
+ /* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
rc * current_quality * 8 >> 10);
}
--
1.9.3
--
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/6] hw_random: don't double-check old_rng.
From: Rusty Russell
Interesting anti-pattern.
Signed-off-by: Rusty Russell
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index c31bf91..fc5de7d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -480,14 +480,13 @@ int hwrng_register(struct hwrng *rng)
}
old_rng = current_rng;
+ err = 0;
if (!old_rng) {
err = hwrng_init(rng);
if (err)
goto out_unlock;
set_current_rng(rng);
- }
- err = 0;
- if (!old_rng) {
+
err = register_miscdev();
if (err) {
drop_current_rng();
--
1.9.3
--
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/6] hw_random: fix unregister race.
From: Rusty Russell
The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered. Add a wait for zero
in the hwrng_unregister path.
v4: add cleanup_done flag to insure that cleanup is done
Signed-off-by: Rusty Russell
Signed-off-by: Amos Kong
---
drivers/char/hw_random/core.c | 8
include/linux/hw_random.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 27ad6b4..c31bf91 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
+static DECLARE_WAIT_QUEUE_HEAD(rng_done);
static unsigned short current_quality;
static unsigned short default_quality; /* = 0; default to "off" */
@@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
if (rng->cleanup)
rng->cleanup(rng);
+ rng->cleanup_done = true;
+ wake_up_all(_done);
}
static void set_current_rng(struct hwrng *rng)
@@ -536,6 +539,11 @@ void hwrng_unregister(struct hwrng *rng)
kthread_stop(hwrng_fill);
} else
mutex_unlock(_mutex);
+
+ /* Just in case rng is reading right now, wait. */
+ wait_event(rng_done, rng->cleanup_done &&
+ atomic_read(>ref.refcount) == 0);
+
}
EXPORT_SYMBOL_GPL(hwrng_unregister);
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index c212e71..7832e50 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -46,6 +46,7 @@ struct hwrng {
/* internal. */
struct list_head list;
struct kref ref;
+ bool cleanup_done;
};
/** Register a new Hardware Random Number Generator driver. */
--
1.9.3
--
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 03/14] regulator: of: Add regulator desc param to of_get_regulator_init_data()
On Mon, Nov 03, 2014 at 04:48:34PM +0100, Javier Martinez Canillas wrote:
> On 11/03/2014 04:33 PM, Mark Brown wrote:
> > On Mon, Nov 03, 2014 at 03:40:38PM +0100, Javier Martinez Canillas wrote:
> >>if (!of_node_cmp(np->name, info->desc.name)) {
> >>config->init_data =
> >> - of_get_regulator_init_data(>dev, np);
> >> + of_get_regulator_init_data(>dev, np,
> >> + NULL);
> > This looks buggy, we're not passing in a descriptor.
> The descriptor is only used when extracting the init_data to map the
> modes and since it was not a parameter before, some drivers needs to
> be refactored to pass that information.
No, it's only *currently* used for that. If we don't bother passing the
descriptor in then future additions which make use of it (including
adding mode operations to existing drivers) won't work and it might not
be obvious why.
> I thought that instead of adding intrusive changes in drivers that I
> don't have hw to test, that parameter could be optional so the patch
> that use that information check if the descriptor and the map_modes
> function pointer are not NULL.
You're already going through and modifying every single driver and all
of those I looked at already had references to the descriptor in
adjacent code or a global descriptor for the one regulator supported by
the driver.
signature.asc
Description: Digital signature
[PATCH v4 2/6] hw_random: move some code out mutex_lock for avoiding underlying deadlock
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b1b6042..a0905c8 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -474,12 +474,12 @@ void hwrng_unregister(struct hwrng *rng)
}
}
if (list_empty(_list)) {
+ mutex_unlock(_mutex);
unregister_miscdev();
if (hwrng_fill)
kthread_stop(hwrng_fill);
- }
-
- mutex_unlock(_mutex);
+ } else
+ mutex_unlock(_mutex);
}
EXPORT_SYMBOL_GPL(hwrng_unregister);
--
1.9.3
--
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 09/14] regulator: s2mpa01: zero-initialize regulator match table array
On Mon, Nov 03, 2014 at 03:40:44PM +0100, Javier Martinez Canillas wrote: > The struct of_regulator_match rmatch[] is declared as a non-static local > variable so the structure members are not auto-initialized. Applied, thanks. signature.asc Description: Digital signature
[PATCH v4 6/6] hw_random: don't init list element we're about to add to list.
From: Rusty Russell
Another interesting anti-pattern.
Signed-off-by: Rusty Russell
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index fc5de7d..b2cc8a1 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -493,7 +493,6 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
}
- INIT_LIST_HEAD(>list);
list_add_tail(>list, _list);
if (old_rng && !rng->init) {
--
1.9.3
--
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 08/14] regulator: max8660: zero-initialize regulator match table array
On Mon, Nov 03, 2014 at 03:40:43PM +0100, Javier Martinez Canillas wrote: > The struct of_regulator_match rmatch[] is declared as a non-static local > variable so the structure members are not auto-initialized. Applied, thanks. signature.asc Description: Digital signature
[PATCH v4 0/6] fix hw_random stuck
When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test 4: | guest) # dd if=/dev/hwrng of=/dev/null & | cat /sys/devices/virtual/misc/hw_random/rng_* | | test 5: | guest) # dd if=/dev/hwrng of=/dev/null | cancel dd process after 10 seconds | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 6: | use a fifo as rng backend, execute test 0 ~ 5 with no input of fifo V4: update patch 4 to fix corrupt, decrease last reference for triggering the cleanup, fix unregister race pointed by Herbert V3: initialize kref to 1 V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference counting issue Amos Kong (1): hw_random: move some code out mutex_lock for avoiding underlying deadlock Rusty Russell (5): hw_random: place mutex around read functions and buffers. hw_random: use reference counts on each struct hwrng. hw_random: fix unregister race. hw_random: don't double-check old_rng. hw_random: don't init list element we're about to add to list. drivers/char/hw_random/core.c | 176 ++ include/linux/hw_random.h | 3 + 2 files changed, 129 insertions(+), 50 deletions(-) -- 1.9.3 -- 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/6] hw_random: use reference counts on each struct hwrng.
From: Rusty Russell
current_rng holds one reference, and we bump it every time we want
to do a read from it.
This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.
v4: decrease last reference for triggering the cleanup
v3: initialize kref (thanks Amos Kong)
v2: fix missing put_rng() on exit path (thanks Amos Kong)
Signed-off-by: Rusty Russell
Signed-off-by: Amos Kong
---
drivers/char/hw_random/core.c | 142 +-
include/linux/hw_random.h | 2 +
2 files changed, 101 insertions(+), 43 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index a0905c8..27ad6b4 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -91,6 +92,65 @@ static void add_early_randomness(struct hwrng *rng)
add_device_randomness(bytes, bytes_read);
}
+static inline void cleanup_rng(struct kref *kref)
+{
+ struct hwrng *rng = container_of(kref, struct hwrng, ref);
+
+ if (rng->cleanup)
+ rng->cleanup(rng);
+}
+
+static void set_current_rng(struct hwrng *rng)
+{
+ BUG_ON(!mutex_is_locked(_mutex));
+ kref_get(>ref);
+ current_rng = rng;
+}
+
+static void drop_current_rng(void)
+{
+ struct hwrng *rng = current_rng;
+
+ BUG_ON(!mutex_is_locked(_mutex));
+ if (!current_rng)
+ return;
+
+ /* release current_rng reference */
+ kref_put(_rng->ref, cleanup_rng);
+ current_rng = NULL;
+
+ /* decrease last reference for triggering the cleanup */
+ kref_put(>ref, cleanup_rng);
+}
+
+/* Returns ERR_PTR(), NULL or refcounted hwrng */
+static struct hwrng *get_current_rng(void)
+{
+ struct hwrng *rng;
+
+ if (mutex_lock_interruptible(_mutex))
+ return ERR_PTR(-ERESTARTSYS);
+
+ rng = current_rng;
+ if (rng)
+ kref_get(>ref);
+
+ mutex_unlock(_mutex);
+ return rng;
+}
+
+static void put_rng(struct hwrng *rng)
+{
+ /*
+* Hold rng_mutex here so we serialize in case they set_current_rng
+* on rng again immediately.
+*/
+ mutex_lock(_mutex);
+ if (rng)
+ kref_put(>ref, cleanup_rng);
+ mutex_unlock(_mutex);
+}
+
static inline int hwrng_init(struct hwrng *rng)
{
if (rng->init) {
@@ -110,13 +170,9 @@ static inline int hwrng_init(struct hwrng *rng)
if (current_quality > 0 && !hwrng_fill)
start_khwrngd();
- return 0;
-}
+ kref_init(>ref);
-static inline void hwrng_cleanup(struct hwrng *rng)
-{
- if (rng && rng->cleanup)
- rng->cleanup(rng);
+ return 0;
}
static int rng_dev_open(struct inode *inode, struct file *filp)
@@ -154,21 +210,22 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
ssize_t ret = 0;
int err = 0;
int bytes_read, len;
+ struct hwrng *rng;
while (size) {
- if (mutex_lock_interruptible(_mutex)) {
- err = -ERESTARTSYS;
+ rng = get_current_rng();
+ if (IS_ERR(rng)) {
+ err = PTR_ERR(rng);
goto out;
}
-
- if (!current_rng) {
+ if (!rng) {
err = -ENODEV;
- goto out_unlock;
+ goto out;
}
mutex_lock(_mutex);
if (!data_avail) {
- bytes_read = rng_get_data(current_rng, rng_buffer,
+ bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
@@ -200,8 +257,8 @@ static ssize_t rng_dev_read(struct file *filp, char __user
*buf,
ret += len;
}
- mutex_unlock(_mutex);
mutex_unlock(_mutex);
+ put_rng(rng);
if (need_resched())
schedule_timeout_interruptible(1);
@@ -213,12 +270,11 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
}
out:
return ret ? : err;
-out_unlock:
- mutex_unlock(_mutex);
- goto out;
+
out_unlock_reading:
mutex_unlock(_mutex);
- goto out_unlock;
+ put_rng(rng);
+ goto out;
}
@@ -257,8 +313,8 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
Re: [PATCH v4 06/14] regulator: max77686: zero-initialize regulator match table
On Mon, Nov 03, 2014 at 03:40:41PM +0100, Javier Martinez Canillas wrote: > The struct of_regulator_match is declared as a non-static local variable > so the structure members are not auto-initialized. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v4 07/14] regulator: max77802: zero-initialize regulator match table
On Mon, Nov 03, 2014 at 03:40:42PM +0100, Javier Martinez Canillas wrote: > The struct of_regulator_match is declared as a non-static local variable > so the structure members are not auto-initialized. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v4 00/14] Add max77802 regulator operating mode support
On Mon, Nov 03, 2014 at 03:40:35PM +0100, Javier Martinez Canillas wrote: > Hello Mark, > > This is the fourth version of the series that adds operating modes > support for the regulators in the max77802 PMIC. This version uses No, it's not. This is a a patch series doing a whole bunch of different things, there's at least bug fixes to existing drivers, new features and also this new driver in what I've glanced at so far. These things shouldn't just be being thrown together into a single patch series, and the patch series shouldn't then be described as just being what is in the end a minor part of the collection. Doing this makes things more manageable from the review side, avoids pointless dependencies and avoids setting off alarm bells. My first thought when seeing this was "how can a regulator driver be so complex as to need 14 patches, there must be something seriously wrong here". The whole thing about making sure that what you're doing makes sense beyond just giving the correct test results also applies to sending the patches - think if what's being said to the people reviewing the patches is sensible. signature.asc Description: Digital signature
Re: s390/net: Deletion of unnecessary checks before two function calls
> This one is buggy. I am still interested to clarify this opinion a bit more. > I'm sorry, but please stop sending these. I am going to improve more implementation details in affected source files. > But for this one: > 1) I don't know what the functions do so I have to look at the code. I hope that static source code analysis can help here. > 2) It's in a arch that I don't compile so cscope isn't set up meaning >it's hard to find the functions. Do you find the Coccinelle software also useful for your area? > You're sending a lot of patches and they are all hard to review and some > of them are buggy and none of them really add any value. Thanks for your feedback. The suggested source code clean-up might result in a measurable effect depending on the call frequency for the changed functions. Can I help you in any ways to make corresponding review easier? > It's a waste of your time and it's a waste of my time. It can be your choice to reject my update suggestion. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 10/10] sched: make scale_rt invariant with frequency
On Fri, Oct 31, 2014 at 09:47:32AM +0100, Vincent Guittot wrote: > The call to arch_scale_frequency_capacity in the rt scheduling path might be > a concern for RT folks because I'm not sure whether we can rely on > arch_scale_freq_capacity to be short and efficient ? Well, you put it in quite a hot path on the CFS side too, so it had better be blazing fast anyhow. That said, can you move all the running + invariance bits at the beginning of the patch set, these appear to be the least controversial bits and 'desired' by quite a few people, so we'll try and get those agreed upon and merged first. -- 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 05/14] regulator: max1586: zero-initialize regulator match table array
On 11/03/2014 04:41 PM, Mark Brown wrote: > On Mon, Nov 03, 2014 at 03:40:40PM +0100, Javier Martinez Canillas wrote: >> The struct of_regulator_match rmatch[] is declared as a non-static local >> variable so the structure members are not auto-initialized. > > Applied, thanks. > > This is a bug fix not *that* closely related to the rest of the series, > if it's being included in a series like this it should've been at the > start of the series not after substantial new feature additions so that > the fixes don't get ignored due to problems with the features and so > that the fixes can be sent to Linus without dependencies. > True, I added in the series since of_get_regulation_constraints() checks if the struct regulator_desc * pointer is not NULL and so drivers that don't initialize the struct of_regulator_match containing that pointer will make that check to fail and the pointer be wrongly dereferenced. Sorry, next time I'll post fixes separately and make the series depend on that instead. 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: [PATCH 1/4] pmem: Initial version of persistent memory driver
"Elliott, Robert (Server Storage)" writes: >> +config BLK_DEV_PMEM_COUNT >> +int "Default number of PMEM disks" >> +default "4" > > For real use I think a default of 1 would be better. For "real" use, it will be the number of actual DIMMs, not a config option, I would think. I don't take any issue with defaulting to 4. This will go away. >> +pmem->pmem_queue = blk_alloc_queue(GFP_KERNEL); >> +if (!pmem->pmem_queue) >> +goto out_free_dev; >> + > > General comment: > This driver should be blk-mq based. Not doing so loses > out on a number of SMP and NUMA performance improvements. > For example, blk_alloc_queue calls blk_alloc_queue_node > with NUMA_NO_NODE. If it called blk_mq_init_queue, then > each CPU would get structures located on its node. No need to use blk-mq just to set the numa node, as the driver could just call blk_alloc_queue_node itself. I'd chalk this up to another thing that could be fixed when the driver is used for actual hardware that describes its own proximity domain. Further, there is no DMA engine, here, so what is the benefit of using blk-mq? I/O completes in the submission path, and I don't see any locking that's preventing parallelism. > >> +blk_queue_make_request(pmem->pmem_queue, pmem_make_request); >> +blk_queue_max_hw_sectors(pmem->pmem_queue, 1024); > > Many storage controllers support 1 MiB IOs now, and increasing > amounts of software feel comfortable generating those sizes. > That means this should be at least 2048. > >> +blk_queue_bounce_limit(pmem->pmem_queue, BLK_BOUNCE_ANY); >> + > > It might be appropriate to call blk_queue_rq_timeout > and set up a very short timeout, since persistent memory is > very fast. I'm not sure what the default is for non-blk-mq > drivers; for blk-mq, I think it is 30 seconds, which is > far too long for memory based storage. If you timeout on a memcpy, then we've definitely got problems. :) Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
Hi, On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote: > On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote: > > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote: > > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote: > > > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote: > > > > > > I think adding the module exit + allowing this driver to be a module > > > > > > would be a good approach. Then we don't need to force generic x86 > > > > > > kernel > > > > > > binaries to always have this driver. Unless Mathias or Mika knows a > > > > > > constraint to force this driver to be builtin only. > > > > > > > > > > It helps if I CC them when asking for feedback :) > > > > > > > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail > > > > > to be bool? > > > > > > > > The only constraint that has been keeping this driver as bool is that > > > > some machines like, Asus T100, uses ACPI GPIO operation regions for > > > > toggling GPIOs to get things like sensor hub powered on. The GPIO > > > > operation region code does not yet handle -EPROBE_DEFER so only way to > > > > ensure that the operation region is there is to have the driver compiled > > > > in to the kernel. > > > > > > But that's not enough excuse to have every single x86 in the market > > > shipping with this driver. Think about a distro kernel, most likely this > > > gets enabled and it's wrong in 80% of the cases. > > > > True, but see below. > > > > > It would be nicer to add EPROBE_DEFER support, convert this into > > > tristate and have default = M if BAYTRAIL, or something. > > > > If it were simple as that we would have done that already. Please check > > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me > > how we can do that. > > Actually the above is not the problem because we already have registered > the GPIO chip and hence we have the GPIO available to the firmware code. what happens before you registered the gpio chip ? It takes some time from head.S to gpiochip_irqchip_add(). Anywhere between that time, firmware could try to access gpios and the same problem would occur. > The real problem is that if the ACPI GPIO operation handler is not there > at the time firmware decides to do something it will just skip things > that depend on the operation region. So if it has a GPIO that is used to > turn on sensor hub or touch panel or whatever, this will not be done and > it results that the device in question might not work properly. that's an issue that needs solving, but forcing every x86 kernel to ship with this driver, is not a proper solution. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 03/14] regulator: of: Add regulator desc param to of_get_regulator_init_data()
On 11/03/2014 04:33 PM, Mark Brown wrote:
> On Mon, Nov 03, 2014 at 03:40:38PM +0100, Javier Martinez Canillas wrote:
>
>> for_each_child_of_node(nproot, np) {
>> if (!of_node_cmp(np->name, info->desc.name)) {
>> config->init_data =
>> -of_get_regulator_init_data(>dev, np);
>> +of_get_regulator_init_data(>dev, np,
>> + NULL);
>
> This looks buggy, we're not passing in a descriptor.
>
The descriptor is only used when extracting the init_data to map the
modes and since it was not a parameter before, some drivers needs to
be refactored to pass that information.
I thought that instead of adding intrusive changes in drivers that I
don't have hw to test, that parameter could be optional so the patch
that use that information check if the descriptor and the map_modes
function pointer are not NULL.
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: [PATCH] xen/blkfront: improve protection against issuing unsupported REQ_FUA
On 11/03/2014 07:22 AM, Laszlo Ersek wrote:
On 10/27/14 14:44, Vitaly Kuznetsov wrote:
Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
in d11e61583 and was factored out into blkif_request_flush_valid() in
0f1ca65ee. However:
1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
will still pass the check.
2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
the request is invalid.
3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
-EOPNOTSUPP is more appropriate here.
Fix all of the above issues.
This patch is based on the original patch by Laszlo Ersek and a comment by
Jeff Moyer.
Signed-off-by: Vitaly Kuznetsov
---
drivers/block/xen-blkfront.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5ac312f..2e6c103 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info
*info)
notify_remote_via_irq(info->irq);
}
-static inline bool blkif_request_flush_valid(struct request *req,
-struct blkfront_info *info)
+static inline bool blkif_request_flush_invalid(struct request *req,
+ struct blkfront_info *info)
{
return ((req->cmd_type != REQ_TYPE_FS) ||
- ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
- !info->flush_op));
+ ((req->cmd_flags & REQ_FLUSH) &&
+!(info->feature_flush & REQ_FLUSH)) ||
+ ((req->cmd_flags & REQ_FUA) &&
+!(info->feature_flush & REQ_FUA)));
Somewhat unrelated to the patch, but I am wondering whether we actually
need flush_op field at all as it seems that it is unambiguously defined
by REQ_FLUSH/REQ_FUA.
-boris
}
/*
@@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
blk_start_request(req);
- if (blkif_request_flush_valid(req, info)) {
- __blk_end_request_all(req, -EIO);
+ if (blkif_request_flush_invalid(req, info)) {
+ __blk_end_request_all(req, -EOPNOTSUPP);
continue;
}
Not sure if there has been some feedback yet (I can't see anything
threaded with this message in my inbox).
FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
this review. Apparently, REQ_FLUSH forces out "previously completed
write requests", whereas REQ_FUA delays the IO completion signal for
*this* request until "the data has been committed to non-volatile
storage". So, indeed, support for REQ_FLUSH only does not guarantee that
REQ_FUA can be served.
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
--
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] powerpc: use device_online/offline() instead of cpu_up/down()
On 10/31/2014 02:41 PM, Dan Streetman wrote:
> In powerpc pseries platform dlpar operations, Use device_online() and
> device_offline() instead of cpu_up() and cpu_down().
>
> Calling cpu_up/down directly does not update the cpu device offline
> field, which is used to online/offline a cpu from sysfs. Calling
> device_online/offline instead keeps the sysfs cpu online value correct.
> The hotplug lock, which is required to be held when calling
> device_online/offline, is already held when dlpar_online/offline_cpu
> are called, since they are called only from cpu_probe|release_store.
>
> This patch fixes errors on PowerVM systems that have cpu(s) added/removed
> using dlpar operations; without this patch, the
> /sys/devices/system/cpu/cpuN/online nodes do not correctly show the
> online state of added/removed cpus.
>
> Signed-off-by: Dan Streetman
> Cc: Nathan Fontenot
Acked-by: Nathan Fontenot
> ---
>
> Previous discussion for this:
> https://lkml.org/lkml/2014/10/29/839
>
> arch/powerpc/platforms/pseries/dlpar.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index 6ad83bd..c22bb1b 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -382,7 +382,7 @@ static int dlpar_online_cpu(struct device_node *dn)
> BUG_ON(get_cpu_current_state(cpu)
> != CPU_STATE_OFFLINE);
> cpu_maps_update_done();
> - rc = cpu_up(cpu);
> + rc = device_online(get_cpu_device(cpu));
> if (rc)
> goto out;
> cpu_maps_update_begin();
> @@ -467,7 +467,7 @@ static int dlpar_offline_cpu(struct device_node *dn)
> if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
> set_preferred_offline_state(cpu,
> CPU_STATE_OFFLINE);
> cpu_maps_update_done();
> - rc = cpu_down(cpu);
> + rc = device_offline(get_cpu_device(cpu));
> if (rc)
> goto out;
> cpu_maps_update_begin();
>
--
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 v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote: > Bear in mind, however, that once the irq_safe flag has been set, the > runtime PM core offers no way to turn it off again. Ah, I thought it did permit it to change both ways. In that case, we don't need to validate that it doesn't change state on each call, and we can just get away with checking its value. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] fs: add O_BENEATH flag to openat(2)
On Mon, Nov 3, 2014 at 7:20 AM, Al Viro wrote: > On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote: >> Add a new O_BENEATH flag for openat(2) which restricts the >> provided path, rejecting (with -EACCES) paths that are not beneath >> the provided dfd. In particular, reject: >> - paths that contain .. components >> - paths that begin with / >> - symlinks that have paths as above. > > Yecch... The degree of usefulness aside (and I'm not convinced that it > is non-zero), This is extremely useful in conjunction with seccomp. > WTF pass one bit out of nameidata->flags in a separate argument? > Through the mutual recursion, no less... And then you are not even attempting > to detect symlinks that are not followed by interpretation of _any_ pathname. How many symlinks like that are there? Is there anything except nd_jump_link users? All of those are in /proc. Arguably O_BENEATH should prevent traversal of all of those links. --Andy -- 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 05/14] regulator: max1586: zero-initialize regulator match table array
On Mon, Nov 03, 2014 at 03:40:40PM +0100, Javier Martinez Canillas wrote: > The struct of_regulator_match rmatch[] is declared as a non-static local > variable so the structure members are not auto-initialized. Applied, thanks. This is a bug fix not *that* closely related to the rest of the series, if it's being included in a series like this it should've been at the start of the series not after substantial new feature additions so that the fixes don't get ignored due to problems with the features and so that the fixes can be sent to Linus without dependencies. signature.asc Description: Digital signature
[PATCH v4 0/9] ARM: shmobile: R-Mobile: DT PM domain support
Hi Rafael, Simon, Magnus,
This patch series enables DT support for PM domains on Renesas R-Mobile SoCs.
Currently it's limited to R-Mobile A1 (r8a7740), but given the similarity of
the SYSC System-Controller on the various SH-Mobile/R-Mobile SoCs, and the
abstraction of PM domains in DT, it should be sufficiently generic to handle
other SoCs in the future (e.g. SH-Mobile AP4 (sh7372), SH-Mobile AG5 (sh73a0),
R-Mobile APE6 (r8a73a4)).
Functionality-wise, this behaves the same as the legacy (non-DT) version
(modulo missing DT support in some device drivers).
Dependencies:
- This is based on Simon Horman's renesas-devel-20141030-v3.18-rc2, and
Rafael J. Wysocki's linux-pm.git#linux-next,
- This depends on "PM / Domains: Change prototype for the ->attach_dev()
callback" from Ulf hanson, which is intended to still enter v3.18-rcX
through the linux-pm tree.
As this is a one-line change, I included this patch as the first patch of
this series. Perhaps it's even acceptable for Simon to (also) apply it, so
we don't have to wait for the v3.18-rcX that will include it?
For your convenience, I've also pushed this to
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#rmobile-genpd
Changes compared to v3 (more detailed changelogs in the individual patches):
- I dropped the patch to add preliminary PM domain latencies, as I want to do
more measurements for PM domains that are currently never powered off.
Values seem to range between 8.5 and 26 us, depending on the PM domain.
- I dropped all patches related to QoS device latencies, as these need more
discussion,
- The power-{on,off}-latency properties have been changed from a single value
to a list,
- Device save/restore state latencies have been dropped, as they're Linux
driver-specific, and thus don't belong in DT,
- Use proper pm_clk_create()/pm_clk_destroy(), and update for attach_dev()
returning an error code again,
- New patch to enable module clocks if !CONFIG_PM_RUNTIME,
- Always keep D4 powered, until the new Coresight code handles runtime
PM,
- Remove bogus power-domains properties from clock nodes, as these will not
be instantiated as platform devices,
- Add power-domains properties to the recently added TMU nodes,
- Added Acked-by, Reviewed-by.
Changes compared to v2 (more detailed changelogs in the individual patches):
- Minor changes to attach/detach callbacks,
- Really add the A4MP and D4 PM domains, as fixes are available (see
dependencies below),
- Scan DT topology to identify special PM domains (CPUs and console),
- Move PM domain power-on/off latencies to a separate patch.
Changes compared to v1 (more detailed changelogs in the individual patches):
- Several new patches: PM QoS device latencies in DT, attach/detach
callbacks,
- Run-Time management of the module clocks, making the hack in
drivers/sh/pm_runtime.c obsolete for DT platforms using genpd,
- Addition of PM QoS device latencies, specified from DT,
- Addition of build glue, so this builds and runs without additional
changes, incl. s2ram.
Thanks!
Geert Uytterhoeven (8):
PM / Domains: Add DT bindings for power-on/off latencies
PM / Domains: Add DT bindings for the R-Mobile System Controller
ARM: shmobile: R-Mobile: Use generic_pm_domain.attach_dev() for pm_clk
setup
ARM: shmobile: R-Mobile: Enable module clocks if !CONFIG_PM_RUNTIME
ARM: shmobile: R-Mobile: Store SYSC base address in rmobile_pm_domain
ARM: shmobile: R-Mobile: Add DT support for PM domains
ARM: shmobile: r8a7740 dtsi: Add PM domain support
drivers: sh: Disable PM runtime for multi-platform r8a7740 with genpd
Ulf Hansson (1):
PM / Domains: Change prototype for the ->attach_dev() callback
.../devicetree/bindings/power/power_domain.txt | 14 +-
.../bindings/power/renesas,sysc-rmobile.txt| 107
arch/arm/boot/dts/r8a7740.dtsi | 99 +++
arch/arm/mach-shmobile/Kconfig | 3 +-
arch/arm/mach-shmobile/pm-r8a7740.c| 14 +
arch/arm/mach-shmobile/pm-rmobile.c| 284 +++--
arch/arm/mach-shmobile/pm-rmobile.h| 3 +-
arch/arm/mach-shmobile/pm-sh7372.c | 11 +
drivers/sh/pm_runtime.c| 2 +
include/linux/pm_domain.h | 2 +-
10 files changed, 519 insertions(+), 20 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote: > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote: > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote: > > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote: > > > > > I think adding the module exit + allowing this driver to be a module > > > > > would be a good approach. Then we don't need to force generic x86 > > > > > kernel > > > > > binaries to always have this driver. Unless Mathias or Mika knows a > > > > > constraint to force this driver to be builtin only. > > > > > > > > It helps if I CC them when asking for feedback :) > > > > > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail > > > > to be bool? > > > > > > The only constraint that has been keeping this driver as bool is that > > > some machines like, Asus T100, uses ACPI GPIO operation regions for > > > toggling GPIOs to get things like sensor hub powered on. The GPIO > > > operation region code does not yet handle -EPROBE_DEFER so only way to > > > ensure that the operation region is there is to have the driver compiled > > > in to the kernel. > > > > But that's not enough excuse to have every single x86 in the market > > shipping with this driver. Think about a distro kernel, most likely this > > gets enabled and it's wrong in 80% of the cases. > > True, but see below. > > > It would be nicer to add EPROBE_DEFER support, convert this into > > tristate and have default = M if BAYTRAIL, or something. > > If it were simple as that we would have done that already. Please check > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me > how we can do that. Actually the above is not the problem because we already have registered the GPIO chip and hence we have the GPIO available to the firmware code. The real problem is that if the ACPI GPIO operation handler is not there at the time firmware decides to do something it will just skip things that depend on the operation region. So if it has a GPIO that is used to turn on sensor hub or touch panel or whatever, this will not be done and it results that the device in question might not work properly. -- 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 v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote: > That makes it pretty horrid from the point of view of having bus > management code, because we now have the management of the bus clock > split between the bus layer and the device driver. > > This is /really/ a problem for runtime PM. Runtime PM permits there > to be a bus layer involved - and runtime PM can also be coupled up > to PM domains as well. For all this stuff, the context which the > callbacks are called in depends on whether the driver itself has > marked the device as having IRQ-safe callbacks. > > That's fine, but the bus and PM domain level code then /really/ needs > to know what context they're being called in, so they know whether > they can sleep or not, or they must to be written to always use > non-sleeping functions so they work in both contexts. If we assume > the former, then that implies that the irq-safe flag must never change > state between a suspend and a resume. If a bus subsystem or PM domain is going to allow its drivers to choose between IRQ-safe and non-IRQ-safe runtime PM, then it is up to the subsystem to come up with a way for drivers to indicate their choice. I tend to agree with Rafael that testing dev->power.irq_safe should be good enough, with no real need for a wrapper. But the subsystem can use a different mechanism if it wants. Bear in mind, however, that once the irq_safe flag has been set, the runtime PM core offers no way to turn it off again. Alan Stern -- 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 v6 02/12] Driver core: Unified device properties interface for platform firmware
Hi Rafael,
While reviewing and testing these patches I ran into serious bugs in
the string parsers (in both the existing code and the new functions
here). It took me a number of days, but I've got a fix now which I'll
be posting shortly and I want to get into mainline right away. I'll cc
you when I post it.
The fix will conflict with this patch. Mostly as a side effect of the
fix, the of_property_*string* function changes will no longer be
needed in this patch. It will either need to be respun, or we'll need
to give Linus some guidance on resolving the conflicts when merging.
Other comments below...
On Tue, Oct 21, 2014 at 10:15 PM, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki"
>
> Add a uniform interface by which device drivers can request device
> properties from the platform firmware by providing a property name
> and the corresponding data type. The purpose of it is to help to
> write portable code that won't depend on any particular platform
> firmware interface.
>
> The following general helper functions are added:
[...]
> +/**
> + * device_property_read_u8_array - return a u8 array property of a device
> + * @dev: Device to get the property of
> + * @propname: Name of the property
> + * @val: The values are stored here
> + * @nval: Size of the @val array
> + *
> + * Function reads an array of u8 properties with @propname from the device
> + * firmware description and stores them to @val if found.
> + *
> + * Return: %0 if the property was found (success),
> + *%-EINVAL if given arguments are not valid,
> + *%-ENODATA if the property does not have a value,
> + *%-EPROTO if the property is not an array of numbers,
> + *%-EOVERFLOW if the size of the property is not as expected.
> + */
> +int device_property_read_u8_array(struct device *dev, const char *propname,
> + u8 *val, size_t nval)
> +{
> + return DEV_PROP_READ_ARRAY(dev, propname, u8, DEV_PROP_U8, val, nval);
> +}
> +EXPORT_SYMBOL_GPL(device_property_read_u8_array);
Yup, I'm a lot happier with this approach. :-)
> +
> +/**
> + * device_property_read_u16_array - return a u16 array property of a device
> + * @dev: Device to get the property of
> + * @propname: Name of the property
> + * @val: The values are stored here
> + * @nval: Size of the @val array
> + *
> + * Function reads an array of u16 properties with @propname from the device
> + * firmware description and stores them to @val if found.
> + *
> + * Return: %0 if the property was found (success),
> + *%-EINVAL if given arguments are not valid,
> + *%-ENODATA if the property does not have a value,
> + *%-EPROTO if the property is not an array of numbers,
> + *%-EOVERFLOW if the size of the property is not as expected.
> + */
> +int device_property_read_u16_array(struct device *dev, const char *propname,
> + u16 *val, size_t nval)
> +{
> + return DEV_PROP_READ_ARRAY(dev, propname, u16, DEV_PROP_U16, val,
> nval);
> +}
> +EXPORT_SYMBOL_GPL(device_property_read_u16_array);
> +
> +/**
> + * device_property_read_u32_array - return a u32 array property of a device
> + * @dev: Device to get the property of
> + * @propname: Name of the property
> + * @val: The values are stored here
> + * @nval: Size of the @val array
> + *
> + * Function reads an array of u32 properties with @propname from the device
> + * firmware description and stores them to @val if found.
> + *
> + * Return: %0 if the property was found (success),
> + *%-EINVAL if given arguments are not valid,
> + *%-ENODATA if the property does not have a value,
> + *%-EPROTO if the property is not an array of numbers,
> + *%-EOVERFLOW if the size of the property is not as expected.
> + */
> +int device_property_read_u32_array(struct device *dev, const char *propname,
> + u32 *val, size_t nval)
> +{
> + return DEV_PROP_READ_ARRAY(dev, propname, u32, DEV_PROP_U32, val,
> nval);
> +}
> +EXPORT_SYMBOL_GPL(device_property_read_u32_array);
> +
> +/**
> + * device_property_read_u64_array - return a u64 array property of a device
> + * @dev: Device to get the property of
> + * @propname: Name of the property
> + * @val: The values are stored here
> + * @nval: Size of the @val array
> + *
> + * Function reads an array of u64 properties with @propname from the device
> + * firmware description and stores them to @val if found.
> + *
> + * Return: %0 if the property was found (success),
> + *%-EINVAL if given arguments are not valid,
> + *%-ENODATA if the property does not have a value,
> + *%-EPROTO if the property is not an array of numbers,
> + *%-EOVERFLOW if the size of the property is not as expected.
> + */
> +int device_property_read_u64_array(struct device *dev, const char *propname,
> + u64 *val, size_t nval)
> +{
> + return
[PATCH v4 2/9] PM / Domains: Add DT bindings for power-on/off latencies
PM domain power on/off-latencies are properties of the hardware.
In legacy code, they're specified from platform code.
On DT platforms, their values should come from DT.
Signed-off-by: Geert Uytterhoeven
Acked-by: Kevin Hilman
Reviewed-by: Ulf Hansson
---
v4:
- Add Reviewed-by,
- Replace single latency value by list of latencies,
v3:
- No changes,
v2:
- Add Acked-by.
---
Documentation/devicetree/bindings/power/power_domain.txt | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
index 98c16672ab5f49e0..c4a4afb2ac3b0500 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -19,16 +19,26 @@ Required properties:
providing multiple PM domains (e.g. power controllers), but can be any value
as specified by device tree binding documentation of particular provider.
+Optional properties:
+ - power-on-latency: List of power-on latencies (in ns), one for each PM
+ domain. If all power-on latencies are identical, the list may be shortened
+ to a single value.
+ - power-off-latency: List of power-off latencies (in ns), one for each PM
+ domain. If all power-off latencies are identical, the list may be shortened
+ to a single value.
+
Example:
power: power-controller@1234 {
compatible = "foo,power-controller";
reg = <0x1234 0x1000>;
#power-domain-cells = <1>;
+ power-on-latency = <25 40 18>;
+ power-off-latency = <25 40 30>;
};
-The node above defines a power controller that is a PM domain provider and
-expects one cell as its phandle argument.
+The node above defines a power controller that is a PM domain provider for
+3 PM domains, and expects one cell as its phandle argument.
==PM domain consumers==
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
Hi, On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote: > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote: > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote: > > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote: > > > > > I think adding the module exit + allowing this driver to be a module > > > > > would be a good approach. Then we don't need to force generic x86 > > > > > kernel > > > > > binaries to always have this driver. Unless Mathias or Mika knows a > > > > > constraint to force this driver to be builtin only. > > > > > > > > It helps if I CC them when asking for feedback :) > > > > > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail > > > > to be bool? > > > > > > The only constraint that has been keeping this driver as bool is that > > > some machines like, Asus T100, uses ACPI GPIO operation regions for > > > toggling GPIOs to get things like sensor hub powered on. The GPIO > > > operation region code does not yet handle -EPROBE_DEFER so only way to > > > ensure that the operation region is there is to have the driver compiled > > > in to the kernel. > > > > But that's not enough excuse to have every single x86 in the market > > shipping with this driver. Think about a distro kernel, most likely this > > gets enabled and it's wrong in 80% of the cases. > > True, but see below. > > > It would be nicer to add EPROBE_DEFER support, convert this into > > tristate and have default = M if BAYTRAIL, or something. > > If it were simple as that we would have done that already. Please check > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me > how we can do that. > > The problem is that it is *firmware* code that decides to use the GPIO > at some random point in time and we have no way to tell it to retry > later when the GPIO is available. which means that even with the driver built-in, there is still the possibility that firmware will try to access it before pinctrl-baytrail's init function is called and you'd end up in the same situation. The fact is that currently you're forcing every x86 (even non-Intel) to ship with this driver statically linked into it just because a small percent of x86 systems might need to have this ready-to-go early enough. Unfortunately I don't know ACPI enough to tell you if there is a way to tell firmware "hey, you can use GPIOs now", so I'l refrain from commenting on that. But that doesn't change the fact that this is wrong. -- balbi signature.asc Description: Digital signature
[PATCH v4 7/9] ARM: shmobile: R-Mobile: Add DT support for PM domains
Populate the PM domains from DT, and provide support to hook up devices
to their respective PM domain.
The always-on power area (e.g. C5 on r8a7740) is created as a PM domain
without software control, to allow Run-Time management of module clocks
for hardware blocks inside this area.
Power-on/off latencies are supported.
Special cases like PM domains containing CPUs, the console device, or
Coresight-ETM, are handled by scanning the DT topology.
As long as the ARM debug/perf code doesn't use resource management with
runtime PM support, the power area containing Coresight-ETM (e.g. D4 on
r8a7740) must be kept powered to avoid a crash during resume from s2ram
(dbg_cpu_pm_notify() calls reset_ctrl_regs() unconditionally, causing an
undefined instruction oops).
Initialization is done from core_initcall(), as the
"renesas,intc-irqpin" driver uses postcore_initcall().
Signed-off-by: Geert Uytterhoeven
---
v4:
- Always keep D4 powered, until the new Coresight code handles runtime
PM,
v3:
- Remove limitations, as fixes for the interrupt storm (A4MP) and
crash (D4) are available,
- Scan DT topology to identify special PM domains,
- Add dependency on chosen/stdout-path,
v2:
- Fix typo "CPU is _not_ in use",
- Include build glue,
- Remove paragraph about missing functionality compared to the legacy
case, as it is no longer missing (runtime management of module
clocks, device latencies).
---
arch/arm/mach-shmobile/Kconfig | 3 +-
arch/arm/mach-shmobile/pm-rmobile.c | 220 +++-
arch/arm/mach-shmobile/pm-rmobile.h | 2 +-
3 files changed, 221 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 7cb0a484da536d58..f96528bb45f6389e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -7,6 +7,7 @@ config PM_RCAR
config PM_RMOBILE
bool
+ select PM_GENERIC_DOMAINS
config ARCH_RCAR_GEN1
bool
@@ -22,7 +23,7 @@ config ARCH_RCAR_GEN2
config ARCH_RMOBILE
bool
- select PM_RMOBILE if PM && !ARCH_SHMOBILE_MULTI
+ select PM_RMOBILE if PM
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index f07e994141685baa..e779fd874e006f7b 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2012 Renesas Solutions Corp.
* Copyright (C) 2012 Kuninori Morimoto
+ * Copyright (C) 2014 Glider bvba
*
* based on pm-sh7372.c
* Copyright (C) 2011 Magnus Damm
@@ -13,10 +14,16 @@
*/
#include
#include
+#include
+#include
+#include
#include
#include
#include
+#include
+
#include
+
#include "pm-rmobile.h"
/* SYSC */
@@ -30,8 +37,12 @@
static int rmobile_pd_power_down(struct generic_pm_domain *genpd)
{
struct rmobile_pm_domain *rmobile_pd = to_rmobile_pd(genpd);
- unsigned int mask = 1 << rmobile_pd->bit_shift;
+ unsigned int mask;
+
+ if (rmobile_pd->bit_shift == ~0)
+ return -EBUSY;
+ mask = 1 << rmobile_pd->bit_shift;
if (rmobile_pd->suspend) {
int ret = rmobile_pd->suspend();
@@ -61,10 +72,14 @@ static int rmobile_pd_power_down(struct generic_pm_domain
*genpd)
static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd,
bool do_resume)
{
- unsigned int mask = 1 << rmobile_pd->bit_shift;
+ unsigned int mask;
unsigned int retry_count;
int ret = 0;
+ if (rmobile_pd->bit_shift == ~0)
+ return 0;
+
+ mask = 1 << rmobile_pd->bit_shift;
if (__raw_readl(rmobile_pd->base + PSTR) & mask)
goto out;
@@ -155,6 +170,8 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain
*rmobile_pd)
__rmobile_pd_power_up(rmobile_pd, false);
}
+#ifdef CONFIG_ARCH_SHMOBILE_LEGACY
+
void rmobile_init_domains(struct rmobile_pm_domain domains[], int num)
{
int j;
@@ -187,3 +204,202 @@ void rmobile_add_devices_to_domains(struct
pm_domain_device data[],
rmobile_add_device_to_domain_td(data[j].domain_name,
data[j].pdev, );
}
+
+#else /* !CONFIG_ARCH_SHMOBILE_LEGACY */
+
+static int rmobile_pd_suspend_cpu(void)
+{
+ /*
+* This domain contains the CPU core and therefore it should
+* only be turned off if the CPU is not in use.
+*/
+ return -EBUSY;
+}
+
+static int rmobile_pd_suspend_console(void)
+{
+ /*
+* Serial consoles make use of SCIF hardware located in this domain,
+* hence keep the power domain on if "no_console_suspend" is set.
+*/
+ return console_suspend_enabled ? 0 : -EBUSY;
+}
+
+static int rmobile_pd_suspend_debug(void)
+{
+ /*
+* This domain contains the Coresight-ETM
[PATCH v4 9/9] drivers: sh: Disable PM runtime for multi-platform r8a7740 with genpd
If the default PM domain using PM_CLK is used for PM runtime, the real PM
domain(s) cannot be registered from DT later.
Hence do not enable it when running a multi-platform kernel with genpd
support on an r8a7740. The R-Mobile PM domain driver will take care of
PM runtime management of the module clocks.
The default PM domain is still needed for:
- platforms without genpd support,
- the legacy (non-DT) case, where genpd may take over later, except
for the C5 "always on" PM domain.
Signed-off-by: Geert Uytterhoeven
---
v4:
- No changes,
v3:
- Reword,
v2:
- New.
---
drivers/sh/pm_runtime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index fe2c2d595f599b2f..85cc89fd3e7d7cb7 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -81,7 +81,9 @@ static int __init sh_pm_runtime_init(void)
if (!of_machine_is_compatible("renesas,emev2") &&
!of_machine_is_compatible("renesas,r7s72100") &&
!of_machine_is_compatible("renesas,r8a73a4") &&
+#ifndef CONFIG_PM_GENERIC_DOMAINS_OF
!of_machine_is_compatible("renesas,r8a7740") &&
+#endif
!of_machine_is_compatible("renesas,r8a7778") &&
!of_machine_is_compatible("renesas,r8a7779") &&
!of_machine_is_compatible("renesas,r8a7790") &&
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 6/9] ARM: shmobile: R-Mobile: Store SYSC base address in rmobile_pm_domain
Replace the hardcoded addresses for accessing the SYSC PM domain
registers by register offsets, relative to the SYSC base address stored
in struct rmobile_pm_domain.
In the future, the SYSC base address will come from DT.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
---
v4:
- Add Reviewed-by,
- Restore SYSC register definition alignment,
v3:
- No changes,
v2:
- No changes.
---
arch/arm/mach-shmobile/pm-r8a7740.c | 14 ++
arch/arm/mach-shmobile/pm-rmobile.c | 24 +---
arch/arm/mach-shmobile/pm-rmobile.h | 1 +
arch/arm/mach-shmobile/pm-sh7372.c | 11 +++
4 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c
b/arch/arm/mach-shmobile/pm-r8a7740.c
index ac2eecd6f5ea5d9f..34608fcf064808b8 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -9,10 +9,14 @@
* for more details.
*/
#include
+#include
#include
+
#include "common.h"
#include "pm-rmobile.h"
+#define SYSC_BASE IOMEM(0xe618)
+
#if defined(CONFIG_PM) && !defined(CONFIG_ARCH_MULTIPLATFORM)
static int r8a7740_pd_a3sm_suspend(void)
{
@@ -45,41 +49,51 @@ static int r8a7740_pd_d4_suspend(void)
static struct rmobile_pm_domain r8a7740_pm_domains[] = {
{
.genpd.name = "A4LC",
+ .base = SYSC_BASE,
.bit_shift = 1,
}, {
.genpd.name = "A4MP",
+ .base = SYSC_BASE,
.bit_shift = 2,
}, {
.genpd.name = "D4",
+ .base = SYSC_BASE,
.bit_shift = 3,
.gov= _domain_always_on_gov,
.suspend= r8a7740_pd_d4_suspend,
}, {
.genpd.name = "A4R",
+ .base = SYSC_BASE,
.bit_shift = 5,
}, {
.genpd.name = "A3RV",
+ .base = SYSC_BASE,
.bit_shift = 6,
}, {
.genpd.name = "A4S",
+ .base = SYSC_BASE,
.bit_shift = 10,
.no_debug = true,
}, {
.genpd.name = "A3SP",
+ .base = SYSC_BASE,
.bit_shift = 11,
.gov= _domain_always_on_gov,
.no_debug = true,
.suspend= r8a7740_pd_a3sp_suspend,
}, {
.genpd.name = "A3SM",
+ .base = SYSC_BASE,
.bit_shift = 12,
.gov= _domain_always_on_gov,
.suspend= r8a7740_pd_a3sm_suspend,
}, {
.genpd.name = "A3SG",
+ .base = SYSC_BASE,
.bit_shift = 13,
}, {
.genpd.name = "A4SU",
+ .base = SYSC_BASE,
.bit_shift = 20,
},
};
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 6fb86cdb9fa2b3a7..f07e994141685baa 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -20,9 +20,9 @@
#include "pm-rmobile.h"
/* SYSC */
-#define SPDCR IOMEM(0xe6180008)
-#define SWUCR IOMEM(0xe6180014)
-#define PSTR IOMEM(0xe6180080)
+#define SPDCR 0x08/* SYS Power Down Control Register */
+#define SWUCR 0x14/* SYS Wakeup Control Register */
+#define PSTR 0x80/* Power Status Register */
#define PSTR_RETRIES 100
#define PSTR_DELAY_US 10
@@ -39,12 +39,12 @@ static int rmobile_pd_power_down(struct generic_pm_domain
*genpd)
return ret;
}
- if (__raw_readl(PSTR) & mask) {
+ if (__raw_readl(rmobile_pd->base + PSTR) & mask) {
unsigned int retry_count;
- __raw_writel(mask, SPDCR);
+ __raw_writel(mask, rmobile_pd->base + SPDCR);
for (retry_count = PSTR_RETRIES; retry_count; retry_count--) {
- if (!(__raw_readl(SPDCR) & mask))
+ if (!(__raw_readl(rmobile_pd->base + SPDCR) & mask))
break;
cpu_relax();
}
@@ -52,7 +52,8 @@ static int rmobile_pd_power_down(struct generic_pm_domain
*genpd)
if (!rmobile_pd->no_debug)
pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n",
-genpd->name, mask, __raw_readl(PSTR));
+genpd->name, mask,
+__raw_readl(rmobile_pd->base + PSTR));
return 0;
}
@@ -64,13 +65,13 @@ static int __rmobile_pd_power_up(struct rmobile_pm_domain
*rmobile_pd,
unsigned int retry_count;
int ret = 0;
-
[PATCH v4 4/9] ARM: shmobile: R-Mobile: Use generic_pm_domain.attach_dev() for pm_clk setup
Use the just introduced genpd attach/detach callbacks to register the
devices' module clocks, instead of doing it directly, to make it
DT-proof.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
---
v4:
- Add Reviewed-by,
- Add missing pm_clk_create()/pm_clk_destroy() calls,
- Update for attach_dev() returning an error code again,
v3:
- Update for callback signature changes,
v2:
- New.
---
arch/arm/mach-shmobile/pm-rmobile.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 717e6413d29cb998..068608d5f54a9a64 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -101,6 +101,34 @@ static bool rmobile_pd_active_wakeup(struct device *dev)
return true;
}
+static int rmobile_pd_attach_dev(struct device *dev)
+{
+ int error;
+
+ error = pm_clk_create(dev);
+ if (error) {
+ dev_err(dev, "pm_clk_create failed %d\n", error);
+ return error;
+ }
+
+ error = pm_clk_add(dev, NULL);
+ if (error) {
+ dev_err(dev, "pm_clk_add failed %d\n", error);
+ goto fail;
+ }
+
+ return 0;
+
+fail:
+ pm_clk_destroy(dev);
+ return error;
+}
+
+static void rmobile_pd_detach_dev(struct device *dev)
+{
+ pm_clk_destroy(dev);
+}
+
static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
{
struct generic_pm_domain *genpd = _pd->genpd;
@@ -112,6 +140,8 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain
*rmobile_pd)
genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup;
genpd->power_off= rmobile_pd_power_down;
genpd->power_on = rmobile_pd_power_up;
+ genpd->attach_dev = rmobile_pd_attach_dev;
+ genpd->detach_dev = rmobile_pd_detach_dev;
__rmobile_pd_power_up(rmobile_pd, false);
}
@@ -130,8 +160,6 @@ void rmobile_add_device_to_domain_td(const char
*domain_name,
struct device *dev = >dev;
__pm_genpd_name_add_device(domain_name, dev, td);
- if (pm_clk_no_clocks(dev))
- pm_clk_add(dev, NULL);
}
void rmobile_add_devices_to_domains(struct pm_domain_device data[],
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 8/9] ARM: shmobile: r8a7740 dtsi: Add PM domain support
Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up all devices to their respective PM domains.
Add a minimal device node for the Coresight-ETM hardware block, and hook
it up to the D4 PM domain, so the R-Mobile System Controller driver can
keep the domain powered, until the new Coresight code handles runtime
PM.
Signed-off-by: Geert Uytterhoeven
---
v4:
- Remove power-domains properties from clocks, as these will not be
instantiated as platform devices,
- Fix indentation of power-domains property in pfc node,
- Add minimal node for Coresight-ETM,
- Add power-domains properties to the recently added TMU nodes,
v3:
- Move power-on/off latencies to a separate patch,
- Add dependencies,
v2:
- Insert power-domains property after clock-names property in the cmt1
node.
---
arch/arm/boot/dts/r8a7740.dtsi | 99 ++
1 file changed, 99 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index aec8da89ef9ac766..20d2b56773fbf069 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -25,6 +25,7 @@
device_type = "cpu";
reg = <0x0>;
clock-frequency = <8>;
+ power-domains = <_a3sm>;
};
};
@@ -41,12 +42,18 @@
interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>;
};
+ ptm {
+ compatible = "arm,coresight-etm3x";
+ power-domains = <_d4>;
+ };
+
cmt1: timer@e6138000 {
compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
reg = <0xe6138000 0x170>;
interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_CMT1>;
clock-names = "fck";
+ power-domains = <_c5>;
renesas,channels-mask = <0x3f>;
@@ -72,6 +79,7 @@
0 149 IRQ_TYPE_LEVEL_HIGH
0 149 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_INTCA>;
+ power-domains = <_a4s>;
};
/* irqpin1: IRQ8 - IRQ15 */
@@ -93,6 +101,7 @@
0 149 IRQ_TYPE_LEVEL_HIGH
0 149 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_INTCA>;
+ power-domains = <_a4s>;
};
/* irqpin2: IRQ16 - IRQ23 */
@@ -114,6 +123,7 @@
0 149 IRQ_TYPE_LEVEL_HIGH
0 149 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_INTCA>;
+ power-domains = <_a4s>;
};
/* irqpin3: IRQ24 - IRQ31 */
@@ -135,6 +145,7 @@
0 149 IRQ_TYPE_LEVEL_HIGH
0 149 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_INTCA>;
+ power-domains = <_a4s>;
};
ether: ethernet@e9a0 {
@@ -143,6 +154,7 @@
<0xe9a01800 0x800>;
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_GETHER>;
+ power-domains = <_a4s>;
phy-mode = "mii";
#address-cells = <1>;
#size-cells = <0>;
@@ -159,6 +171,7 @@
0 203 IRQ_TYPE_LEVEL_HIGH
0 204 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_IIC0>;
+ power-domains = <_a4r>;
status = "disabled";
};
@@ -172,6 +185,7 @@
0 72 IRQ_TYPE_LEVEL_HIGH
0 73 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_IIC1>;
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -181,6 +195,7 @@
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_SCIFA0>;
clock-names = "sci_ick";
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -190,6 +205,7 @@
interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_SCIFA1>;
clock-names = "sci_ick";
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -199,6 +215,7 @@
interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_SCIFA2>;
clock-names = "sci_ick";
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -208,6 +225,7 @@
interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7740_CLK_SCIFA3>;
clock-names = "sci_ick";
+ power-domains = <_a3sp>;
[PATCH v4 5/9] ARM: shmobile: R-Mobile: Enable module clocks if !CONFIG_PM_RUNTIME
If CONFIG_PM_RUNTIME is not set, the clocks must be enabled before the
devices can be used.
Currently these clocks are enabled by the !CONFIG_PM_RUNTIME version of
pm_clk_notify, activated by the hack in drivers/sh/pm_runtime.c, but
this will go away soon (at least for DT).
On detach, disabling the clocks is already handled by pm_clk_destroy().
On system suspend/resume, disabling/enabling clocks is already handled
from the genpd->dev_ops.{start,stop}() callbacks.
Signed-off-by: Geert Uytterhoeven
---
v4:
- New.
---
arch/arm/mach-shmobile/pm-rmobile.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 068608d5f54a9a64..6fb86cdb9fa2b3a7 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -117,6 +117,14 @@ static int rmobile_pd_attach_dev(struct device *dev)
goto fail;
}
+ if (!IS_ENABLED(CONFIG_PM_RUNTIME)) {
+ error = pm_clk_resume(dev);
+ if (error) {
+ dev_err(dev, "pm_clk_resume failed %d\n", error);
+ goto fail;
+ }
+ }
+
return 0;
fail:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/9] PM / Domains: Change prototype for the ->attach_dev() callback
From: Ulf Hansson
Convert the prototype to return and int. This is just an initial step,
needed to support error handling.
Signed-off-by: Ulf Hansson
Acked-by: Geert Uytterhoeven
Acked-by: Pavel Machek
Acked-by: Kevin Hilman
Signed-off-by: Geert Uytterhoeven
---
Prerequisite
Ulf wrote:
This patch is intended as fix for 3.18 rc[n]. Why?
There are other SOC specific patches around that adds genpd support and which
implements the ->attach_dev() callback. To prevent having an "atomic" patch
during the next release cycle, let's change the prototype now instead.
Further patches will add the actual error handling in genpd and these can then
be reviewed and tested thoroughly.
---
include/linux/pm_domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 73e938b7e9374c68..d44f071988a861ff 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -72,7 +72,7 @@ struct generic_pm_domain {
bool max_off_time_changed;
bool cached_power_down_ok;
struct gpd_cpuidle_data *cpuidle_data;
- void (*attach_dev)(struct device *dev);
+ int (*attach_dev)(struct device *dev);
void (*detach_dev)(struct device *dev);
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/9] PM / Domains: Add DT bindings for the R-Mobile System Controller
The Renesas R-Mobile System Controller provides a.o. power management
support, following the generic PM domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
For now this supports the R-Mobile A1 (r8a7740) only, but it should be
sufficiently generic to handle other members of the SH-Mobile/R-Mobile
family in the future.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
---
v4:
- Drop device save/restore state latencies, as they're Linux driver-specific,
- Drop PM QoS device latencies, as they're put on hold,
v3:
- Reword,
v2:
- Fix copy-and-paste s/#address-cells/#size-cells/,
- Add optional PM QoS device latencies.
---
.../bindings/power/renesas,sysc-rmobile.txt| 107 +
1 file changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
new file mode 100644
index ..89ca3f35aec69750
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
@@ -0,0 +1,107 @@
+DT bindings for the Renesas R-Mobile System Controller
+
+== System Controller Node ==
+
+The R-Mobile System Controller provides the following functions:
+ - Boot mode management,
+ - Reset generation,
+ - Power management.
+
+Required properties:
+- compatible: Should be "renesas,sysc-", "renesas,sysc-rmobile" as
+ fallback.
+ Examples with soctypes are:
+ - "renesas,sysc-r8a7740" (R-Mobile A1)
+- reg: Two address start and address range blocks for the device:
+ - The first block refers to the normally accessible registers,
+ - the second block refers to the registers protected by the HPB
+ semaphore.
+
+Optional nodes:
+- pm-domains: This node contains a hierarchy of PM domain nodes, which should
+ match the Power Area Hierarchy in the Power Domain Specifications section of
+ the device's datasheet.
+
+
+== PM Domain Nodes ==
+
+Each of the PM domain nodes represents a PM domain, as documented by the
+generic PM domain bindings in
+Documentation/devicetree/bindings/power/power_domain.txt.
+
+The nodes should be named by the real power area names, and thus their names
+should be unique.
+
+Required properties:
+ - #power-domain-cells: Must be 0.
+
+Optional properties:
+- reg: If the PM domain is not always-on, this property must contain the bit
+ index number for the corresponding power area in the various Power
+ Control and Status Registers. The parent's node must contain the
+ following two properties:
+- #address-cells: Must be 1,
+- #size-cells: Must be 0.
+ If the PM domain is always-on, this property must be omitted.
+- power-on-latency: Power-on latency of the PM domain, in ns,
+- power-off-latency: Power-off latency of the PM domain, in ns.
+
+
+Example:
+
+This shows a subset of the r8a7740 PM domain hierarchy, containing the
+C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP domain,
+which is a subdomain of A4S.
+
+ sysc: system-controller@e618 {
+ compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile";
+ reg = <0xe618 8000>, <0xe6188000 8000>;
+
+ pm-domains {
+ pd_c5: c5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #power-domain-cells = <0>;
+
+ pd_a4s: a4s@10 {
+ reg = <10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #power-domain-cells = <0>;
+ power-on-latency = <25>;
+ power-off-latency = <25>;
+
+ pd_a3sp: a3sp@11 {
+ reg = <11>;
+ #power-domain-cells = <0>;
+ power-on-latency = <25>;
+ power-off-latency = <25>;
+ };
+ };
+
+ pd_a4su: a4su@20 {
+ reg = <20>;
+ #power-domain-cells = <0>;
+ power-on-latency = <25>;
+ power-off-latency = <25>;
+ };
+ };
+ };
+ };
+
+
+== PM Domain Consumers ==
+
+Hardware blocks belonging to a PM domain should contain a "power-domains"
+property that is a phandle pointing
Re: [PATCH v4 03/14] regulator: of: Add regulator desc param to of_get_regulator_init_data()
On Mon, Nov 03, 2014 at 03:40:38PM +0100, Javier Martinez Canillas wrote:
> for_each_child_of_node(nproot, np) {
> if (!of_node_cmp(np->name, info->desc.name)) {
> config->init_data =
> - of_get_regulator_init_data(>dev, np);
> + of_get_regulator_init_data(>dev, np,
> +NULL);
This looks buggy, we're not passing in a descriptor.
signature.asc
Description: Digital signature
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Fri, Oct 31, 2014 at 2:20 PM, Felipe Balbi wrote:
> [Me]
>> But another way to get rid of the dilemma is to set
>> .suppress_bind_attrs = true on the .driver field of the
>> device driver. The one can't unbind it through sysfs anymore.
>>
>> .driver = {
>> .name = "foo",
>> .suppress_bind_attrs = true,
>> },
>>
>> So one of them need to be done.
>>
>> I suspect this is a kind of common problem...
>
> so instead of taking of taking a three-liner which just makes sure this
> can be used as "intended" you prefer to:
>
> diff --git a/drivers/pinctrl/pinctrl-baytrail.c
> b/drivers/pinctrl/pinctrl-baytrail.c
> index e12e5b0..254ba81 100644
> --- a/drivers/pinctrl/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/pinctrl-baytrail.c
> @@ -587,16 +587,6 @@ static const struct acpi_device_id byt_gpio_acpi_match[]
> = {
> };
> MODULE_DEVICE_TABLE(acpi, byt_gpio_acpi_match);
>
> -static int byt_gpio_remove(struct platform_device *pdev)
> -{
> - struct byt_gpio *vg = platform_get_drvdata(pdev);
> -
> - pm_runtime_disable(>dev);
> - gpiochip_remove(>chip);
> -
> - return 0;
> -}
> -
> static struct platform_driver byt_gpio_driver = {
> .probe = byt_gpio_probe,
> .remove = byt_gpio_remove,
> @@ -605,6 +595,7 @@ static struct platform_driver byt_gpio_driver = {
> .owner = THIS_MODULE,
> .pm = _gpio_pm_ops,
> .acpi_match_table = ACPI_PTR(byt_gpio_acpi_match),
> + .suppress_bind_attrs = true,
> },
> };
I don't know, if the driver *really* cannot be removed from sysfs
it is actually the right solution don't you think?
Else we're just leaving a nicely designed self-destruct
mechanism around.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
On Sun, 02 Nov 2014, Tony Lindgren wrote:
> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> configuration") enabled configuring the PM features for twl4030.
>
> This caused poweroff command to fail on devices that have the
> BCI charger on twl4030 wired, or have power wired for VBUS.
> Instead of powering off, the device reboots. This is because
> voltage is detected on charger or VBUS with the default bits
> enabled for the power transition registers.
>
> To fix the issue, let's just clear VBUS and CHG bits as we want
> poweroff command to keep the system powered off.
>
> Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
> Cc: sta...@vger.kernel.org # v3.16+
> Reported-by: Russell King
It would be good to have Russell to review this to ensure he is happy
with the implementation.
> Signed-off-by: Tony Lindgren
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] ipv4: avoid divide 0 error in tcp_incr_quickack
On Mon, 2014-11-03 at 13:31 +0800, chenweilong wrote: > Hi Eric, > > I check the code and find that: > > 1.In function "tcp_rcv_state_process", > the "tcp_initialize_rcv_mss" is called at "step 5: check the ACK field" when > the sk->sk_state is TCP_SYN_RECV > and there is a "tcp_validate_incoming" just before it. > So when we call "tcp_validate_incoming", the rcv_mss may not been initialized. > > 2.In function "tcp_validate_incoming", > the "Step 1: check sequence number", according to RFC793 page 69, > If an incoming segment is not acceptable,an acknowledgment should be sent in > reply (unless the RST > bit is set, if so drop the segment and return). > So we may call "tcp_send_dupack" while the rcv_mss hasn't been initialized. > > 3.In function "tcp_send_dupack", > when the condition is suitable, it'll enter quick ack mode. Notice it only > check the seq ! > So I think add another state check should be OK. > > Any suggestion ? > You did find what immediate conditions for the crash (rcv_mss = 0, state = TCP_SYN_RCV) were. Your patch avoids the zero divide, but leaves other issues. rcv_mss = 0 here is a sign some logic is wrong in the stack. Given this potential zero divide had been there for years, I believe we should take the time for a more complete fix, instead of papering over the immediate problem. We have been working with Neal to reproduce the issue with packetdrill, we'll post our results when we manage to get our first crash ;) Thanks ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 087/102] nEPT: Nested INVEPT
On 03/11/2014 14:44, Ben Hutchings wrote:
>> You can just use the same scheme as your patch 88/102:
> Why is that? Why should I not use the upstream version?
Because it makes no sense to invalidate nested EPT page tables, if the
kernel cannot make nested EPT page tables in the first place.
I think that this "if" in your patch should always trigger, thus making
your large patch equivalent to my small patch:
+ if (!(nested_vmx_secondary_ctls_high & SECONDARY_EXEC_ENABLE_EPT) ||
+ !(nested_vmx_ept_caps & VMX_EPT_INVEPT_BIT)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
... but without looking at the entire source of vmx.c in the relatively
old 3.2 kernel, I'd rather play it safe and avoid introducing bugs in case
the above turns out not to be true.
Paolo
--
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 v8 07/10] sched: replace capacity_factor by usage
On Fri, Oct 31, 2014 at 09:47:29AM +0100, Vincent Guittot wrote:
> @@ -6414,11 +6399,12 @@ static inline void calculate_imbalance(struct lb_env
> *env, struct sd_lb_stats *s
>*/
> if (busiest->group_type == group_overloaded &&
> local->group_type == group_overloaded) {
> - load_above_capacity =
> - (busiest->sum_nr_running -
> busiest->group_capacity_factor);
> -
> - load_above_capacity *= (SCHED_LOAD_SCALE *
> SCHED_CAPACITY_SCALE);
> - load_above_capacity /= busiest->group_capacity;
> + load_above_capacity = busiest->sum_nr_running *
> + SCHED_LOAD_SCALE;
> + if (load_above_capacity > busiest->group_capacity)
> + load_above_capacity -= busiest->group_capacity;
> + else
> + load_above_capacity = ~0UL;
> }
>
> /*
It seems to me we no longer have need to assume each task contributes
SCHED_LOAD_SCALE, do we?
But as it stands I tihnk this patch already does too much -- it could do
with a splitting, but let me stare at is a wee bit more.
--
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 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really express dependencies that only their > (current instances of) corresponding userspace components need? > Something seems wrong about that. uvesafb will always need X86_IOPORT. It's kind of implicit in the design. I'm not suggesting that fbdev should select X86_IOPORT but in the uvesafb case at least it's completely useless to have one and not the other. > IO_BITMAP_LONGS already gets defined to (0/sizeof(long)). And as far as > I can tell, that would only work for init_tss_io, not anything else. > Even then, that would only work with a zero-size array left around in > tss_struct, which doesn't seem appropriate. The remaining ifdefs wrap > code that GCC could not constant-fold away, and making that code > constant-foldable seems significantly more invasive than the ifdefs. OK -- 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: memcontrol: remove stale page_cgroup_lock comment
On Sat 01-11-14 23:14:20, Johannes Weiner wrote: > There is no cgroup-specific page lock anymore. > > Signed-off-by: Johannes Weiner Acked-by: Michal Hocko > --- > mm/memcontrol.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 38f0647a2f12..d20928597a07 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2467,10 +2467,6 @@ static void commit_charge(struct page *page, struct > mem_cgroup *memcg, > int isolated; > > VM_BUG_ON_PAGE(pc->mem_cgroup, page); > - /* > - * we don't need page_cgroup_lock about tail pages, becase they are not > - * accessed by any other context at this point. > - */ > > /* >* In some cases, SwapCache and FUSE(splice_buf->radixtree), the page > -- > 2.1.3 > -- 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: [PATCHv6 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node
Hi,
On Fri, Oct 31, 2014 at 02:31:31PM -0500, Dinh Nguyen wrote:
> On 10/31/2014 12:42 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Oct 31, 2014 at 10:20:06AM -0500, Dinh Nguyen wrote:
> @@ -339,7 +339,8 @@ static void dwc2_handle_wakeup_detected_intr(struct
> dwc2_hsotg *hsotg)
> }
> /* Change to L0 state */
> hsotg->lx_state = DWC2_L0;
> -call_gadget(hsotg, resume);
> +if (!IS_ERR(hsotg->clk))
> +call_gadget(hsotg, resume);
> >>>
> >>> instead of exposing the clock detail to the entire driver, add IS_ERR()
> >>> checks to resume and suspend instead. In fact, NULL is a valid clock, so
> >>> you might as well:
> >>>
> >>> clk = clk_get(foo, bar);
> >>> if (IS_ERR(clk))
> >>> dwc->clk = NULL;
> >>> else
> >>> dwc->clk = clk;
> >>>
> >>> Then you don't need any IS_ERR() checks sprinkled around the driver.
> >>
> >> But we would still need to check for the clock before accessing gadget
> >> functionality right?
> >>
> >>if (dwc2->clk)
> >>call_gadget();
> >
> > Read my comment again. "NULL is a valid clock". Look at what
> > clk_enable() does when a NULL pointer is passed:
> >
> > static int __clk_enable(struct clk *clk)
> > {
> > int ret = 0;
> >
> > if (!clk)
> > return 0;
> >
> > if (WARN_ON(clk->prepare_count == 0))
> > return -ESHUTDOWN;
> >
> > if (clk->enable_count == 0) {
> > ret = __clk_enable(clk->parent);
> >
> > if (ret)
> > return ret;
> >
> > if (clk->ops->enable) {
> > ret = clk->ops->enable(clk->hw);
> > if (ret) {
> > __clk_disable(clk->parent);
> > return ret;
> > }
> > }
> > }
> >
> > clk->enable_count++;
> > return 0;
> > }
> >
> > int clk_enable(struct clk *clk)
> > {
> > unsigned long flags;
> > int ret;
> >
> > flags = clk_enable_lock();
> > ret = __clk_enable(clk);
> > clk_enable_unlock(flags);
> >
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(clk_enable);
>
> Ah yes, thanks for the explanation. So if clk=NULL, it just return 0.
> But what I'm saying is that if the driver is configured for dual-role
> mode, and no clock is specified, then the driver should not be accessing
> any gadget functionality.
why ? Why only for gadget and why can't it work on platforms without
clk? What if Paul wants to run the gadget side on his HAPS-5x platform
configured as a PCIe card ?
You haven't explained why gadget has this hard-dependency on clk and why
*only* gadget has it. This sounds really, really wrong. Why can host
side run without clk but gadget can't ?
Moreover, if you really want to prevent people from using gadget
without clock, fail dwc2_gadget_init() and have the core fallback to
host-only, then print a warning message.
> So as the patch series stands right now, if I swap out an A connector to
> a B-connector, then I get a connect_id_status change interrupt. The
> status would show a device and I would initialize the gadget portion of
> the driver.
that's fine, but why the hard-dependency on clk ?
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 44c609f..96810f7 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1371,7 +1371,8 @@ static void dwc2_conn_id_status_change(struct
> work_struct *work)
> hsotg->op_state = OTG_STATE_B_PERIPHERAL;
> dwc2_core_init(hsotg, false, -1);
> dwc2_enable_global_interrupts(hsotg);
> - s3c_hsotg_core_init(hsotg);
> + if (hsotg->clk)
> + s3c_hsotg_core_init(hsotg);
>
> So if I don't have a valid clock, I'll be accessing the peripheral
> portion of the IP.
so what ?
> But I guess not having the check for the valid clock here should be fine
> as I don't see a case where there can be 2 different clocks for host and
> peripheral?
probably the same thing.
> @@ -400,7 +401,8 @@ static void dwc2_handle_usb_suspend_intr(struct
> dwc2_hsotg *hsotg)
> "DSTS.Suspend Status=%d HWCFG4.Power
> Optimize=%d\n",
> !!(dsts & DSTS_SUSPSTS),
> hsotg->hw_params.power_optimized);
> -call_gadget(hsotg, suspend);
> +if (!IS_ERR(hsotg->clk))
> +call_gadget(hsotg, suspend);
> } else {
> if (hsotg->op_state == OTG_STATE_A_PERIPHERAL) {
> dev_dbg(hsotg->dev, "a_peripheral->a_host\n");
> @@ -477,7 +479,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void
> *dev)
> spin_lock(>lock);
>
> if
Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote: > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote: > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote: > > > > I think adding the module exit + allowing this driver to be a module > > > > would be a good approach. Then we don't need to force generic x86 kernel > > > > binaries to always have this driver. Unless Mathias or Mika knows a > > > > constraint to force this driver to be builtin only. > > > > > > It helps if I CC them when asking for feedback :) > > > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail > > > to be bool? > > > > The only constraint that has been keeping this driver as bool is that > > some machines like, Asus T100, uses ACPI GPIO operation regions for > > toggling GPIOs to get things like sensor hub powered on. The GPIO > > operation region code does not yet handle -EPROBE_DEFER so only way to > > ensure that the operation region is there is to have the driver compiled > > in to the kernel. > > But that's not enough excuse to have every single x86 in the market > shipping with this driver. Think about a distro kernel, most likely this > gets enabled and it's wrong in 80% of the cases. True, but see below. > It would be nicer to add EPROBE_DEFER support, convert this into > tristate and have default = M if BAYTRAIL, or something. If it were simple as that we would have done that already. Please check drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me how we can do that. The problem is that it is *firmware* code that decides to use the GPIO at some random point in time and we have no way to tell it to retry later when the GPIO is available. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: stmpe: add pull up/down register offsets for STMPE
On Mon, Nov 3, 2014 at 1:57 PM, Lee Jones wrote: > On Mon, 03 Nov 2014, Linus Walleij wrote: > >> Lee, can Dmitry take these through input? > > That was weird, I replied at the same as as you sent this. Synchronicity... :) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver
From: Stanimir Varbanov The voltage ADC is peripheral of Qualcomm SPMI PMIC chips. It has 15 bits resolution and register space inside PMIC accessible across SPMI bus. The vadc driver registers itself through IIO interface. Signed-off-by: Stanimir Varbanov Signed-off-by: Ivan T. Ivanov --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile |1 + drivers/iio/adc/qcom-spmi-vadc.c | 1015 ++ 3 files changed, 1030 insertions(+) create mode 100644 drivers/iio/adc/qcom-spmi-vadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 88bdc8f..af6e10b 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -206,6 +206,20 @@ config NAU7802 To compile this driver as a module, choose M here: the module will be called nau7802. +config QCOM_SPMI_VADC + tristate "Qualcomm SPMI PMIC voltage ADC" + depends on SPMI + select REGMAP_SPMI + help + This is the IIO Voltage ADC driver for Qualcomm QPNP VADC Chip. + + The driver supports multiple channels read. The VADC is a 15-bit + sigma-delta ADC. Some of the channels are internally used for + calibration. + + To compile this driver as a module, choose M here: the module will + be called qcom-spmi-vadc. + config ROCKCHIP_SARADC tristate "Rockchip SARADC driver" depends on ARCH_ROCKCHIP || (ARM && COMPILE_TEST) diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index cb88a6a..479b457 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o obj-$(CONFIG_MCP3422) += mcp3422.o obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o obj-$(CONFIG_NAU7802) += nau7802.o +obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c new file mode 100644 index 000..6e6881c --- /dev/null +++ b/drivers/iio/adc/qcom-spmi-vadc.c @@ -0,0 +1,1015 @@ +/* + * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* VADC register and bit definitions */ +#define VADC_REVISION2 0x1 +#define VADC_REVISION2_SUPPORTED_VADC 1 + +#define VADC_PERPH_TYPE0x4 +#define VADC_PERPH_TYPE_ADC8 + +#define VADC_PERPH_SUBTYPE 0x5 +#define VADC_PERPH_SUBTYPE_VADC1 + +#define VADC_STATUS1 0x8 +#define VADC_STATUS1_OP_MODE 4 +#define VADC_STATUS1_REQ_STS BIT(1) +#define VADC_STATUS1_EOC BIT(0) +#define VADC_STATUS1_REQ_STS_EOC_MASK 0x3 + +#define VADC_MODE_CTL 0x40 +#define VADC_OP_MODE_SHIFT 3 +#define VADC_OP_MODE_NORMAL0 +#define VADC_AMUX_TRIM_EN BIT(1) +#define VADC_ADC_TRIM_EN BIT(0) + +#define VADC_EN_CTL1 0x46 +#define VADC_EN_CTL1_SET BIT(7) + +#define VADC_ADC_CH_SEL_CTL0x48 + +#define VADC_ADC_DIG_PARAM 0x50 +#define VADC_ADC_DIG_DEC_RATIO_SEL_SHIFT 2 + +#define VADC_HW_SETTLE_DELAY 0x51 + +#define VADC_CONV_REQ 0x52 +#define VADC_CONV_REQ_SET BIT(7) + +#define VADC_FAST_AVG_CTL 0x5a +#define VADC_FAST_AVG_EN 0x5b +#define VADC_FAST_AVG_EN_SET BIT(7) + +#define VADC_ACCESS0xd0 +#define VADC_ACCESS_DATA 0xa5 + +#define VADC_PERH_RESET_CTL3 0xda +#define VADC_FOLLOW_WARM_RBBIT(2) + +#define VADC_DATA 0x60/* 16 bits */ + +#define VADC_CONV_TIME_MIN_US 2000 +#define VADC_CONV_TIME_MAX_US 2100 + +/* Min ADC code represents 0V */ +#define VADC_MIN_ADC_CODE 0x6000 +/* Max ADC code represents full-scale range of 1.8V */ +#define VADC_MAX_ADC_CODE 0xa800 +
Re: [PATCH 3/5] hw_random: fix unregister race.
On Tue, Oct 21, 2014 at 10:15:23PM +0800, Herbert Xu wrote: > On Thu, Sep 18, 2014 at 12:18:24PM +0930, Rusty Russell wrote: > > The previous patch added one potential problem: we can still be > > reading from a hwrng when it's unregistered. Add a wait for zero > > in the hwrng_unregister path. > > > > Signed-off-by: Rusty Russell > > --- > > drivers/char/hw_random/core.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > > index dc9092a1075d..b4a21e9521cf 100644 > > --- a/drivers/char/hw_random/core.c > > +++ b/drivers/char/hw_random/core.c > > @@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex); > > static DEFINE_MUTEX(reading_mutex); > > static int data_avail; > > static u8 *rng_buffer, *rng_fillbuf; > > +static DECLARE_WAIT_QUEUE_HEAD(rng_done); > > static unsigned short current_quality; > > static unsigned short default_quality; /* = 0; default to "off" */ > > > > @@ -98,6 +99,7 @@ static inline void cleanup_rng(struct kref *kref) > > > > if (rng->cleanup) > > rng->cleanup(rng); rng->cleanup_done = true; > > + wake_up_all(_done); > > } > > > > static void set_current_rng(struct hwrng *rng) > > @@ -529,6 +531,9 @@ void hwrng_unregister(struct hwrng *rng) > > } > > > > mutex_unlock(_mutex); > > + > > + /* Just in case rng is reading right now, wait. */ > > + wait_event(rng_done, atomic_read(>ref.refcount) == 0); Hi Rusty, After initializing (kref_init()), the refcount is 1, so we need one more kref_put() after each drop_current_rng() to release last reference count, then cleanup function will be called. > While it's obviously better than what we have now, I don't believe > this is 100% safe as the cleanup function might still be running > even after the ref count hits zero. Once we return from this function > the module may be unloaded so we need to ensure that nothing is > running at this point. I found wait_event() can still pass and finish unregister even cleanup function isn't called (wake_up_all() isn't called). So I added a flag cleanup_done to indicate that the rng device is cleaned up. + /* Just in case rng is reading right now, wait. */ + wait_event(rng_done, rng->cleanup_done && + atomic_read(>ref.refcount) == 0); I will post the new v4 later. > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Amos. -- 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/2] Initial support for voltage ADC
Hi, This is the forth version of this driver. V3 could be found here [1]. Changes since v3. - Addressed review comments from Hartmut Knaack and Mark Rutland: Better description of 'reg' property. Add # to address-cells and size-cells DT document. Dropped interrupt-names property, it was not actually used by driver. DT header file, which contain channels names definitions, is part of documentation patch now. Clarified 'qcom,decimation' property. Hopefully it make sense now. Make more explicit that all reference channels configuration nodes have to be defined in DT. - Promote dev_dbg to dev_err in error paths. Stan, I hope you are ok with this :-) - Use 32 bit calculations in calibration routine. - Read ADC result with one regmap call. - Show status and state registers if ADC conversin fails. Errors should not normally happen, so I will like to see content of this registers in such cases. - Use new struct iio_info::of_xlate for channel number translation. - Removed device wakeup initialization code, which didn't make sense to me for such kind of device. Patches depend on "iio: inkern: Add of_xlate function to struct iio_info" patch, which is included in IIO testing branch [2]. [1] http://comments.gmane.org/gmane.linux.ports.arm.msm/9741 [2] http://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/log/?h=testing Stanimir Varbanov (2): DT: iio: vadc: document dt binding iio: vadc: Qualcomm SPMI PMIC voltage ADC driver .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 129 +++ drivers/iio/adc/Kconfig| 14 + drivers/iio/adc/Makefile |1 + drivers/iio/adc/qcom-spmi-vadc.c | 1015 include/dt-bindings/iio/qcom,spmi-vadc.h | 119 +++ 5 files changed, 1278 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt create mode 100644 drivers/iio/adc/qcom-spmi-vadc.c create mode 100644 include/dt-bindings/iio/qcom,spmi-vadc.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] DT: iio: vadc: document dt binding
From: Stanimir Varbanov
Document DT binding for Qualcomm SPMI PMIC voltage ADC
driver.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 129 +
include/dt-bindings/iio/qcom,spmi-vadc.h | 119 +++
2 files changed, 248 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
create mode 100644 include/dt-bindings/iio/qcom,spmi-vadc.h
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
new file mode 100644
index 000..2253813
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
@@ -0,0 +1,129 @@
+Qualcomm's SPMI PMIC voltage ADC
+
+SPMI PMIC voltage ADC (VADC) provides interface to clients to read
+voltage. The VADC is a 15-bit sigma-delta ADC.
+
+VADC node:
+
+- compatible:
+Usage: required
+Value type:
+Definition: Should contain "qcom,spmi-vadc".
+
+- reg:
+Usage: required
+Value type:
+Definition: VADC base address and length in the SPMI PMIC register map.
+
+- #address-cells:
+Usage: required
+Value type:
+Definition: Must be one. Child node 'reg' property should define ADC
+channel number.
+
+- #size-cells:
+Usage: required
+Value type:
+Definition: Must be zero.
+
+- #io-channel-cells:
+Usage: required
+Value type:
+Definition: Must be one. For details about IIO bindings see:
+Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+- interrupts:
+Usage: optional
+Value type:
+Definition: End of conversion interrupt.
+
+Channel node properties:
+
+- reg:
+Usage: required
+Value type:
+Definition: ADC channel number.
+See include/dt-bindings/iio/qcom,spmi-vadc.h
+
+- qcom,decimation:
+Usage: optional
+Value type:
+Definition: This parameters is used to decrease ADC sampling rate.
+Quicker measurements can be made by reducing decimation ratio.
+Valid values are 512, 1024, 2048, 4096.
+If property is not found, default value of 512 will be used.
+
+- qcom,pre-scaling:
+Usage: optional
+Value type:
+Definition: Used for scaling the channel input signal before the signal is
+fed to VADC. The configuration for this node is to know the
+pre-determined ratio and use it for post scaling. Select one from
+the following options.
+<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10>
+If property is not found default value depending of chip will be
used.
+
+- qcom,ratiometric:
+Usage: optional
+Value type:
+Definition: Channel calibration type. If this property is specified
+VADC will use the VDD reference (1.8V) and GND for channel
+calibration. If property is not found, channel will be
+calibrated with 0.625V and 1.25V reference channels, also
+known as absolute calibration.
+
+- qcom,hw-settle-time:
+Usage: optional
+Value type:
+Definition: Time between AMUX getting configured and the ADC starting
+conversion. Delay = 100us * (value) for value < 11, and
+2ms * (value - 10) otherwise.
+Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800,
+900 us and 1, 2, 4, 6, 8, 10 ms
+If property is not found, channel will use 0us.
+
+- qcom,avg-samples:
+Usage: optional
+Value type:
+Definition: Number of samples to be used for measurement.
+Averaging provides the option to obtain a single measurement
+from the ADC that is an average of multiple samples. The value
+selected is 2^(value).
+Valid values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512
+If property is not found, 1 sample will be used.
+
+NOTE:
+
+Following channels, also know as reference points channels, are used for
+result calibration and their channel configuration nodes should be defined:
+VADC_REF_625MV and/or VADC_SPARE1, based on PMIC version, VADC_REF_1250MV,
+VADC_GND_REF and VADC_VDD_VADC.
+
+Example:
+
+ /* VADC node */
+ pmic_vadc: vadc@3100 {
+ compatible = "qcom,spmi-vadc";
+ reg = <0x3100 0x100>;
+ interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+
+ /* Channel node */
+ usb_id_nopull {
+ reg = ;
+ qcom,decimation = <512>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,avg-samples = <1>;
+ qcom,pre-scaling = <1 3>;
+ };
+ };
+
Re: [PATCH v6] kernel, add panic_on_warn
On Mon, Nov 03, 2014 at 09:32:23AM -0500, Prarit Bhargava wrote:
[..]
> +
> +static int __init panic_on_warn_setup(char *s)
> +{
> + /* Enabling this on a kdump kernel could cause a bogus panic. */
> + if (!is_kdump_kernel())
> + panic_on_warn = 1;
I think it would be better if we leave it to user space to remove
panic_on_warn from command line of second kernel.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] fs: add O_BENEATH flag to openat(2)
On Mon, Nov 03, 2014 at 11:48:23AM +, David Drysdale wrote: > Add a new O_BENEATH flag for openat(2) which restricts the > provided path, rejecting (with -EACCES) paths that are not beneath > the provided dfd. In particular, reject: > - paths that contain .. components > - paths that begin with / > - symlinks that have paths as above. Yecch... The degree of usefulness aside (and I'm not convinced that it is non-zero), WTF pass one bit out of nameidata->flags in a separate argument? Through the mutual recursion, no less... And then you are not even attempting to detect symlinks that are not followed by interpretation of _any_ pathname. -- 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 1/2] ALSA: echoaudio: add reference of struct echoaudio
At Mon, 03 Nov 2014 07:08:08 -0800, Joe Perches wrote: > > On Mon, 2014-11-03 at 15:17 +0100, Takashi Iwai wrote: > > At Mon, 3 Nov 2014 16:04:12 +0530, > > Sudip Mukherjee wrote: > > > > > > added reference of struct echoaudio to free_firmware function. > > > this structure will be later used to get a reference of the card > > > when converting snd_printk to dev_* in the next patch of the series. > > > > > > Signed-off-by: Sudip Mukherjee > > > > Thanks, now applied both. Though, I noticed that there is also a > > dev_notice() usage that should be also dev_dbg(). Corrected such > > lines in my side. > > Are any of these changes going to cause a > null pointer dereference of chip->card->dev? All look OK at a quick glance. There was a recent change to make card->dev mandatory, so it's there from the very beginning. > ftrace exists and is generic. > > Several of these seem to be function tracing > style uses and should just be deleted instead. True. Further cleanup patches appreciated. thanks, Takashi -- 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] kernel, add panic_on_warn
On Mon, Nov 03, 2014 at 08:32:42AM -0500, Prarit Bhargava wrote: > > > On 10/30/2014 09:58 PM, Hedi Berriche wrote: > > On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote: > > | There have been several times where I have had to rebuild a kernel to > > | cause a panic when hitting a WARN() in the code in order to get a crash > > | dump from a system. Sometimes this is easy to do, other times (such as > > | in the case of a remote admin) it is not trivial to send new images to the > > | user. > > | > > | A much easier method would be a switch to change the WARN() over to a > > | panic. This makes debugging easier in that I can now test the actual > > | image the WARN() was seen on and I do not have to engage in remote > > | debugging. > > > > Do we want to leave it to usersspace[1] to ensure panic_on_warn is out > > of the way in when the kdump kernel boots? or would a self-contained > > approach be more preferable i.e. test whether we're a kdump kernel > > before bothering with panic_on_warn? > > Hmm ... this is a good point. Vivek, do you have a preference? I'm willing > to > code it either way. I should be able to put in a is_kdump_kernel() check > without any problems but I'm not sure if that is the right thing to do here. > I think it will make sense to modify user space scripts to get rid of panic_on_warn for kdump kernel. Thanks Vivek -- 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] [media] solo6x10: don't turn off/on encoder interrupt in processing loop
Hi Andrey, On 10/29/2014 05:03 PM, Andrey Utkin wrote: > The used approach actually cannot prevent new encoder interrupt to > appear, because interrupt handler can execute in different thread, and > in current implementation there is still race condition regarding this. I don't understand what you mean with 'interrupt handler can execute in different thread'. Can you elaborate? Note that I do think that this change makes sense, but I do like to have a better explanation. Regards, Hans > Also from practice the code with this change seems to work as stable as > before. > > Signed-off-by: Andrey Utkin > --- > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > index b9b61b9..30e09d9 100644 > --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > @@ -703,9 +703,7 @@ static int solo_ring_thread(void *data) > > if (timeout == -ERESTARTSYS || kthread_should_stop()) > break; > - solo_irq_off(solo_dev, SOLO_IRQ_ENCODER); > solo_handle_ring(solo_dev); > - solo_irq_on(solo_dev, SOLO_IRQ_ENCODER); > try_to_freeze(); > } > > -- 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/
