[PATCH cgroup/for-4.4] cgroup: fix too early usage of static_branch_disable()
49d1dc4b8179 ("cgroup: implement static_key based
cgroup_subsys_enabled() and cgroup_subsys_on_dfl()") converted cgroup
enabled test to use static_key; however, cgroup_disable() is called
before static_key subsystem itself is initialized and thus leads to
the following warning when "cgroup_disable=" parameter is specified.
WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:99
static_key_slow_dec+0x44/0x60()
static_key_slow_dec used before call to jump_label_init
...
Call Trace:
[] dump_stack+0x44/0x62
[] warn_slowpath_common+0x82/0xc0
[] warn_slowpath_fmt+0x5c/0x80
[] static_key_slow_dec+0x44/0x60
[] cgroup_disable+0xaf/0xd6
[] unknown_bootoption+0x8c/0x194
[] parse_args+0x273/0x4a0
[] start_kernel+0x205/0x4b8
...
Fix it by making cgroup_disable() to record the subsystems to disable
in cgroup_disable_mask and moving the actual application to
cgroup_init() which is late enough and where the enabled state is
first used.
Signed-off-by: Tejun Heo
Reported-by: Andrey Wagin
Link:
http://lkml.kernel.org/g/canaxb-yfus4sa2znsvckro9l_cbhcihyw+o9bn8szj8er9f...@mail.gmail.com
Fixes: 49d1dc4b81797f88270832b11e9f73809e7e7209
---
kernel/cgroup.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f924158..ae23814 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5124,6 +5124,8 @@ int __init cgroup_init_early(void)
return 0;
}
+static unsigned long cgroup_disable_mask __initdata;
+
/**
* cgroup_init - cgroup initialization
*
@@ -5170,8 +5172,12 @@ int __init cgroup_init(void)
* disabled flag and cftype registration needs kmalloc,
* both of which aren't available during early_init.
*/
- if (!cgroup_ssid_enabled(ssid))
+ if (cgroup_disable_mask & (1 << ssid)) {
+ static_branch_disable(cgroup_subsys_enabled_key[ssid]);
+ printk(KERN_INFO "Disabling %s control group
subsystem\n",
+ ss->name);
continue;
+ }
cgrp_dfl_root.subsys_mask |= 1 << ss->id;
@@ -5595,11 +5601,7 @@ static int __init cgroup_disable(char *str)
if (strcmp(token, ss->name) &&
strcmp(token, ss->legacy_name))
continue;
-
- static_branch_disable(cgroup_subsys_enabled_key[i]);
- printk(KERN_INFO "Disabling %s control group
subsystem\n",
- ss->name);
- break;
+ cgroup_disable_mask |= 1 << i;
}
}
return 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 v3] Documentation: DT: twl-charger: document new iio properties
Document added iio properties to avoid using direct function call from
twl4030-madc
driver.
Signed-off-by: Marek Belisko
---
Documentation/devicetree/bindings/power/twl-charger.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/twl-charger.txt
b/Documentation/devicetree/bindings/power/twl-charger.txt
index 3b4ea1b..e198650 100644
--- a/Documentation/devicetree/bindings/power/twl-charger.txt
+++ b/Documentation/devicetree/bindings/power/twl-charger.txt
@@ -19,12 +19,18 @@ Required properties:
Optional properties:
- ti,bb-uvolt: microvolts for charging the backup battery.
- ti,bb-uamp: microamps for charging the backup battery.
+- io-channels: Should contain following: <_madc 11>
+- io-channel-names: Should contains following value:
+ * "vac" - ADC channel for measuring the voltage of the external AC
charger
+If io properties aren't provided then functionality of accesory charger
doesn't work.
Examples:
bci {
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
+ io-channels = <_madc 11>;
+ io-channel-name = "vac";
ti,bb-uvolt = <320>;
ti,bb-uamp = <150>;
};
--
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 v3] ARM: dts: twl4030: Add iio properties for bci subnode
Added new iio properties which are required for twl4030-charger driver and
allow to use twl4030-madc indirectly.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/twl4030.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 36ae916..482b7aa 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -22,6 +22,8 @@
charger: bci {
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
+ io-channels = <_madc 11>;
+ io-channel-name = "vac";
bci3v1-supply = <>;
};
--
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 v3] drivers: power: twl4030_charger: fix link problems when building as module
If either twl4030_charger or twl4030_madc is configured as MODULE,
we get build (link) errors.
To solve, the direct call of twl4030_get_madc_conversion() is replaced
by a call to iio_read_channel_processed().
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
changes from v2: make iio propries optional to keep functionality for old DT
also
changes from V1: added missing iio_channel_release + document and add new DT
bindings
drivers/power/twl4030_charger.c | 45 -
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index f4f2c1f..82e2a05 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,7 +22,7 @@
#include
#include
#include
-#include
+#include
#define TWL4030_BCIMDEN0x00
#define TWL4030_BCIMDKEY 0x01
@@ -91,21 +91,23 @@
#define TWL4030_MSTATEC_COMPLETE1 0x0b
#define TWL4030_MSTATEC_COMPLETE4 0x0e
-#if IS_ENABLED(CONFIG_TWL4030_MADC)
/*
* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
* then AC is available.
*/
-static inline int ac_available(void)
+static inline int ac_available(struct iio_channel *channel_vac)
{
- return twl4030_get_madc_conversion(11) > 4500;
-}
-#else
-static inline int ac_available(void)
-{
- return 0;
+ int val, err;
+
+ if (!channel_vac)
+ return 0;
+
+ err = iio_read_channel_processed(channel_vac, );
+ if (err < 0)
+ return 0;
+ return val > 4500;
}
-#endif
+
static bool allow_usb;
module_param(allow_usb, bool, 0644);
MODULE_PARM_DESC(allow_usb, "Allow USB charge drawing default current");
@@ -128,6 +130,7 @@ struct twl4030_bci {
*/
unsigned intichg_eoc, ichg_lo, ichg_hi;
unsigned intusb_cur, ac_cur;
+ struct iio_channel *channel_vac;
boolac_is_active;
int usb_mode, ac_mode; /* charging mode requested */
#defineCHARGE_OFF 0
@@ -278,7 +281,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
* and AC is enabled, set current for 'ac'
*/
- if (ac_available()) {
+ if (ac_available(bci->channel_vac)) {
cur = bci->ac_cur;
bci->ac_is_active = true;
} else {
@@ -1048,6 +1051,12 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
return ret;
}
+ bci->channel_vac = iio_channel_get(>dev, "vac");
+ if (IS_ERR(bci->channel_vac)) {
+ bci->channel_vac = NULL;
+ dev_warn(>dev, "could not request vac iio channel");
+ }
+
INIT_WORK(>work, twl4030_bci_usb_work);
INIT_DELAYED_WORK(>current_worker, twl4030_current_worker);
@@ -1061,8 +1070,10 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
bci->transceiver = devm_usb_get_phy_by_node(
bci->dev, phynode, >usb_nb);
if (IS_ERR(bci->transceiver) &&
- PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ PTR_ERR(bci->transceiver) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto fail;
+ }
}
}
@@ -1073,7 +1084,7 @@ static int twl4030_bci_probe(struct platform_device *pdev)
TWL4030_INTERRUPTS_BCIIMR1A);
if (ret < 0) {
dev_err(>dev, "failed to unmask interrupts: %d\n", ret);
- return ret;
+ goto fail;
}
reg = ~(u32)(TWL4030_VBATOV | TWL4030_VBUSOV | TWL4030_ACCHGOV);
@@ -1106,6 +1117,10 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
twl4030_charger_enable_backup(0, 0);
return 0;
+fail:
+ iio_channel_release(bci->channel_vac);
+
+ return ret;
}
static int __exit twl4030_bci_remove(struct platform_device *pdev)
@@ -1116,6 +1131,8 @@ static int __exit twl4030_bci_remove(struct
platform_device *pdev)
twl4030_charger_enable_usb(bci, false);
twl4030_charger_enable_backup(0, 0);
+ iio_channel_release(bci->channel_vac);
+
device_remove_file(>usb->dev, _attr_max_current);
device_remove_file(>usb->dev, _attr_mode);
device_remove_file(>ac->dev, _attr_max_current);
--
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: [RFC v7 25/41] richacl: Isolate the owner and group classes
On Fri, Sep 25, 2015 at 01:25:41PM +0200, Andreas Gruenbacher wrote:
> Here is another minor improvement that produces deny aces with fewer
> permissions in them and avoids creating unnecessary deny aces in some
> cases.
Looks good.--b.
>
> Andreas
>
> ---
> fs/richacl_compat.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c
> index 2f53394..bc0bcfe 100644
> --- a/fs/richacl_compat.c
> +++ b/fs/richacl_compat.c
> @@ -605,14 +605,13 @@ __richacl_isolate_who(struct richacl_alloc *alloc,
> struct richace *who,
> int n;
>
> /*
> - * Compute the permissions already denied to @who. There are no
> + * Compute the permissions already defined for @who. There are no
>* everyone@ deny aces left in the acl at this stage.
>*/
> richacl_for_each_entry(ace, acl) {
> if (richace_is_inherit_only(ace))
> continue;
> - if (richace_is_same_identifier(acl, ace, who) &&
> - richace_is_deny(ace))
> + if (richace_is_same_identifier(acl, ace, who))
> deny &= ~ace->e_mask;
> }
> if (!deny)
> --
> 2.4.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 v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC
On 09/25/2015 01:05 PM, Mark Brown wrote:
On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:
+static int tps65912_regulator_probe(struct platform_device *pdev)
+{
+ struct tps65912 *tps = dev_get_drvdata(pdev->dev.parent);
+ struct regulator_init_data *init_data;
+ const struct tps_info *template;
+ struct regulator_dev *rdev;
+ const struct of_device_id *match;
+ struct regulator_config config = { };
+ int id;
+
+ match = of_match_device(tps65912_regulator_of_match_table, >dev);
+ if (!match)
+ return -ENODEV;
+
+ template = match->data;
+ id = template->id;
+ init_data = of_get_regulator_init_data(>dev, pdev->dev.of_node,
+ [id]);
Don't open code this stuff, use the core DT matching in the
regulator_desc instead.
I assume you are referring to your additions in a0c7b164ad11? If so I'm not
sure that will save me anything as my probe function is called with a DT
match already, so no searching is needed.
Please also use subject lines mathcing the style for the subsystem.
I'm not sure I know what you mean? What is wrong with my subject line, it looks
like the others I've looked at?
--
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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote: > On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote: > > On 25-09-15, 20:49, Johannes Berg wrote: > > > Ok, then, but that means Rafael is completely wrong ... > > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived, > > > it can't be on the stack. You also don't get a call when it changes. > > > > Ahh, ofcourse. My bad as well... > > Well, sorry about the wrong suggestion. > > > I think we can change structure definition but will wait for Rafael's > > comment before that. > > OK, change the structure then. But here's a question. You're going to change that into bool in the next patch, right? So what if bool is a byte and the field is not word-aligned and changing that byte requires a read-modify-write. How do we ensure that things remain consistent in that case? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection
On Tue, Sep 22, 2015 at 12:10:18AM +0100, Julien Grall wrote: > Hi Konrad, > > On 09/09/2015 16:02, Konrad Rzeszutek Wilk wrote: > >>Konrad, would you like me to resend the patch with the modified commit > >>message, or do you plan to amend it yourself while committing? > > > >I will amend it. Thanks! > > What the status for this patch? Applied and sent the git pull. > > Regards, > > -- > Julien Grall -- 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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote: > On 25-09-15, 20:49, Johannes Berg wrote: > > Ok, then, but that means Rafael is completely wrong ... > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived, > > it can't be on the stack. You also don't get a call when it changes. > > Ahh, ofcourse. My bad as well... Well, sorry about the wrong suggestion. > I think we can change structure definition but will wait for Rafael's > comment before that. OK, change the structure then. Thanks, Rafael -- 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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote: > On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need to consider other 32 bits > > for big endian 64 bit systems. There are no such platforms yet, but the > > code needs to be robust for such a case. > > > > Fix that by passing a local variable to debugfs_create_bool() and > > assigning its value to global_lock later. > > > > Signed-off-by: Viresh Kumar > > Acked-by: Rafael J. Wysocki > > Greg, please take this one if the [2/2] looks good to you. Ouch, turns out it was a bad idea. Please scratch that. Thanks, Rafael -- 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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar
Acked-by: Rafael J. Wysocki
Greg, please take this one if the [2/2] looks good to you.
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
> - the series reaches them
> - mailing lists do not block the patchset due to long cc list
> - and we don't spam the BCC'd people for every reply
> ---
> drivers/acpi/ec_sys.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
> unsigned int ec_device_count)
> struct dentry *dev_dir;
> char name[64];
> umode_t mode = 0400;
> + u32 val;
>
> if (ec_device_count == 0) {
> acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
> unsigned int ec_device_count)
>
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
> goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
> goto error;
>
> + first_ec->global_lock = val;
> +
> if (write_support)
> mode = 0600;
> if (!debugfs_create_file("io", mode, dev_dir, ec, _ec_io_ops))
>
Thanks,
Rafael
--
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: [v3 2/8] dpaa_eth: add support for DPAA Ethernet
From: Madalin Bucur
Date: Thu, 24 Sep 2015 18:00:13 +0300
> +#define DPA_NAPI_WEIGHT 64
This is just the default, so simply use "NAPI_POLL_WEIGHT" rather
than defining your own macro unnecessarily for this.
> +static int dpa_eth_priv_stop(struct net_device *net_dev)
> +{
> + int err;
> + struct dpa_priv_s *priv;
> +
> + err = dpa_stop(net_dev);
> + /* Allow NAPI to consume any frame still in the Rx/TxConfirm
> + * ingress queues. This is to avoid a race between the current
> + * context and ksoftirqd which could leave NAPI disabled while
> + * in fact there's still Rx traffic to be processed.
> + */
> + usleep_range(5000, 1);
A wait never fixes a race. Instead you must use appropriate mutual
exclusion mechanisms to ensure that NAPI is really completed it's
run, and we definitely have a means by which to do that properly.
> + net_dev->hw_features |= (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> + NETIF_F_LLTX);
This second line should start exactly at the first column after the
openning parenthesis of the first line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag, > > but it isn't very useful, so I'd prefer to replace it with a "no remote > > wakeup" > > bit in struct dev_pm_info or something similar). > > > > That is actually quite important, because (a) we can save energy but not > > configuring the device to do remote wakeup in the first place and (b) that > > may involve more than just the driver (for example, disabling PCI or ACPI > > remote wakeup involves the bus type or similar). > > > > So it looks like we need to be able to distinguish between "runtime suspend > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > And if we do the latter, we may not even need the "inhibit" thing any more, > > because suspended devices without that are not configured to do remote > > wakeup > > cannot really signal anything in the majority of cases. > > That works only for drivers that use autosuspend to go to low power in > between events. It doesn't work for drivers that remain at full power > as long as the device file is open. That kind of driver does require > an "inhibit" interface. Or an interface allowing user space to trigger pm_request_idle() for them. So user space would change the "no remote wakeup" setting and then do the "try to suspend now" thing. Thanks, Rafael -- 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: x86_64: MAX_LOCAL_APIC way too big?
On 09/25/2015 06:56 PM, Jiang Liu wrote: > On 2015/9/26 0:16, Denys Vlasenko wrote: >> 32 thousand APICs? That's a lot. Especially >> considering that event with CONFIG_MAXSMP=y, >> NR_CPUS is "only" 8096. >> >> After a quick glance through code, it looks like >> such a big value causes several data arrays to be >> quite oversized: >> >> phys_cpu_present_map is 4 kbytes (one bit per apicid) >> __apicid_to_node is 64 kbytes >> apic_version is 128 kbytes (!!!) >> ... >> Maybe we can reduce MAX_LOCAL_APIC? >> Why it has to be this big in the first place? >> >> IIRC: APIC id at first was just a 8-bit quantity, >> then x2apic mode it was extended to 32 bits. >> >> On "usual" systems, apic ids simply go from zero >> to maximum logical CPU number, mirroring CPU ids. > Hi Denys, > The above assumption is risky with modern > x86 platforms. APIC ids are assigned by firmware, > and may be discrete. I guess it means a new CONFIG option will be needed then, for such machines. I'll send an RFC patch now. -- 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] UBI: Validate data_size
Am 24.09.2015 um 12:37 schrieb David Gstir:
>
>> On 22.09.2015, at 23:58, Richard Weinberger wrote:
>>
>> Make sure that data_size is less than LEB size.
>> Otherwise a handcrafted UBI image is able to trigger
>> an out of bounds memory access in ubi_compare_lebs().
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Richard Weinberger
>> ---
>> drivers/mtd/ubi/io.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
>> index 5bbd1f0..1fc23e4 100644
>> --- a/drivers/mtd/ubi/io.c
>> +++ b/drivers/mtd/ubi/io.c
>> @@ -926,6 +926,11 @@ static int validate_vid_hdr(const struct ubi_device
>> *ubi,
>> goto bad;
>> }
>>
>> +if (data_size > ubi->leb_size) {
>> +ubi_err(ubi, "bad data_size");
>> +goto bad;
>> +}
>> +
>
> Nice catch!
>
> Reviewed-by: David Gstir
Applied and queued for 4.3-rc.
Thanks,
//richard
--
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] net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected
From: Sergei Shtylyov Date: Fri, 25 Sep 2015 21:03:52 +0300 > Hello. > > On 9/24/2015 1:16 PM, Sudip Mukherjee wrote: > >> The builds of allmodconfig of avr32 is failing with: >> >> drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit >> declaration >> of function 'pci_iomap' [-Werror=implicit-function-declaration] >> drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit >> declaration >> of function 'pci_iounmap' [-Werror=implicit-function-declaration] >> >> The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI >> is not defined and CONFIG_GENERIC_PCI_IOMAP is defined. >> >> Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are >> getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP >> both >> are not defined. >> >> Signed-off-by: Sudip Mukherjee ... >> @@ -17,7 +17,7 @@ if NET_VENDOR_VIA >> >> config VIA_RHINE >> tristate "VIA Rhine support" >> -depends on (PCI || OF_IRQ) >> +depends on (PCI || (OF_IRQ && GENERIC_PCI_IOMAP)) > > Could you remove outer braces, while at it? I took care of this while applying this patch, thanks everyone. -- 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/pvhvm: add soft reset on kexec/kdump support
On Fri, Sep 25, 2015 at 03:19:57PM -0400, Boris Ostrovsky wrote:
> On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:
> >>On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:
> Also, I am not sure I see how this new op will be used in the
> hypervisor --- currently AFAICS it is only processed under
> is_hardware_domain(). Are there other patches that will support HVM
> guests?
> >>>Please see my Xen series:
> >>>http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
> >>>(last 'full' submission).
> >>>
> >>>All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
> >>>are already merged to xen.git (first 10 are already in 'master' and the
> >>>last one is in 'staging').
> >>>
> >>
> >>OK, so I was looking at the right tree. Then I don't understand how
> >>SHUTDOWN_soft_reset would be reached for a non-privileged domain. The only
> >>path that I see is
> >>
> >> domain_shutdown()
> >> {
> >> ...
> >> if ( is_hardware_domain(d) )
> >> hwdom_shutdown(reason);
> >> ...
> >> }
> >>
> >>Is there another path to handle this op?
> >Yes:
> > e1bd9812966de9a16f30a58e7162b80bd6af361b libxc: support
> > XEN_DOMCTL_soft_reset operation
> >and
> > c57e6ebd8c3e490e353e68d96abec1dad01e72f5 (lib)xl: soft reset support
> >
>
>
> That's toolstack issuing hypercalls from dom0.
>
> I am asking about (non-privileged) guest itself calling SCHEDOP_shutdown.
The hypervisor ends up calling:
__domain_finalise_shutdown which sends an VIRQ_DOM_EXC to dom0 which
makes the toolstack do all of those operations.
>
> -boris
--
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 net-next] net: remove unused argument of __netdev_find_adj()
From: Michal Kubecek Date: Thu, 24 Sep 2015 10:59:05 +0200 (CEST) > The __netdev_find_adj() helper does not use its first argument, only the > device to find and list to walk through. > > Signed-off-by: Michal Kubecek Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Add HCI support
Hi Loic,
> Add HCI support to the regmap API.
> Some HCI/BT devices provide register access via their HCI interface.
> (e.g. FM registers access for Intel BT/FM combo chip)
>
> Read/Write operations are performed via a HCI transaction composed of
> a HCI command (host->controller) followed by a HCI command complete
> event (controller->host). Read/Write Command opcodes can be specified
> to the regmap init function.
> We define data formats which are vendor specific. However, regmap-hci
> can be extended with any other implementation.
>
> Register Read/Write HCI command payload (Host):
> Field: | REG ADDR | MODE | DATA_LEN | DATA... |
> size: | 32b| 8b |8b| 8b*|
>
> Register Read HCI command complete event payload (Controller):
> Field: | CMD STATUS | REG ADDR | DATA... |
> size: | 8b | 32b| 8b*|
>
> Register Write HCI command complete event payload (Controller):
> Field: | CMD_STATUS |
> size: | 8b |
>
> Since this payload is HCI encapsulated, Little Endian byte order
> is used.
>
> Example:
>
> If we want to write 0x32001122 in the register 0x1142,
> with opcode_write 0xfc58, the resulting HCI transaction will be:
> ___ __ __ ___
>> 58 fc 0a 42 11 00 00 02 04 22 11 00 32
> CMD HDR REG ADDR MD SZDATA
> __ __
> < 0E 04 01 58 fc 00
>CC EVT HDR ST
>
> If we want to read the 32bit value stored in same register with
> opcode_read 0xfc59:
> ___ __ __
>> 59 fc 06 42 11 00 00 02 04
> CMD HDRREG ADDR MD SZ
> __ __ ___ ___
> < 0E 0c 01 59 fc 00 04 8c 00 00 22 11 00 32
>CC EVT HDR ST REG ADDR DATA
I wonder if an augmented btmon trace would be easier to read.
>
> Signed-off-by: Loic Poulain
> ---
> drivers/base/regmap/Kconfig | 6 +-
> drivers/base/regmap/Makefile | 1 +
> drivers/base/regmap/regmap-hci.c | 282 +++
> include/linux/regmap.h | 7 +
> 4 files changed, 295 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/regmap/regmap-hci.c
>
> diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
> index db9d00c3..b692b96 100644
> --- a/drivers/base/regmap/Kconfig
> +++ b/drivers/base/regmap/Kconfig
> @@ -3,7 +3,7 @@
> # subsystems should select the appropriate symbols.
>
> config REGMAP
> - default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_AC97 ||
> REGMAP_MMIO || REGMAP_IRQ)
> + default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_AC97 ||
> REGMAP_MMIO || REGMAP_IRQ || REGMAP_HCI)
> select LZO_COMPRESS
> select LZO_DECOMPRESS
> select IRQ_DOMAIN if REGMAP_IRQ
> @@ -29,3 +29,7 @@ config REGMAP_MMIO
>
> config REGMAP_IRQ
> bool
> +
> +config REGMAP_HCI
> + tristate
> + depends on BT
> \ No newline at end of file
> diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
> index 609e4c8..8cf31ea 100644
> --- a/drivers/base/regmap/Makefile
> +++ b/drivers/base/regmap/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
> obj-$(CONFIG_REGMAP_SPMI) += regmap-spmi.o
> obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
> obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o
> +obj-$(CONFIG_REGMAP_HCI) += regmap-hci.o
> diff --git a/drivers/base/regmap/regmap-hci.c
> b/drivers/base/regmap/regmap-hci.c
> new file mode 100644
> index 000..bcb91a8
> --- /dev/null
> +++ b/drivers/base/regmap/regmap-hci.c
> @@ -0,0 +1,282 @@
> +/*
> + * Register map access API - HCI support
I do not think we can consider this generic HCI since at the moment I do not
have enough information on what other manufactures are actually doing with
their FM radio support. So lets call this regmap-ibt.c since we are actually
using iBT as designation for Intel Bluetooth silicon.
> + *
> + * Copyright 2015 Intel Corporation
> + *
> + * Author: Loic Poulain
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "internal.h"
> +
> +#define DEFAULT_OP_WRITE 0xfc58
> +#define DEFAULT_OP_READ 0xfc59
> +
> +#define HCI_REG_MODE_8BIT 0x00
> +#define HCI_REG_MODE_16BIT 0x01
> +#define HCI_REG_MODE_32BIT 0x02
> +
Start here and name these IBT_REG_MODE_
> +struct regmap_hci_context {
Same here, start naming it regmap_ibt_context.
> + struct hci_dev *hdev;
> + __u16 op_write;
> + __u16 op_read;
> +};
> +
> +/**
> + * HCI Command payload for register read/write
> + *
> + * @reg: Register address (32bit only)
> + * @mode: Value access mode (8bit, 16bit, 32bit)
> + * @data_len: data len to read/write
> + * @data: data to write
> + */
> +struct hci_command_reg_hdr {
Lets name this ibt_cp_reg_access.
> + __le32 reg;
This should be addr and not reg.
Re: Multiple potential races on vma->vm_flags
On Wed, Sep 23, 2015 at 08:42:26PM -0400, Sasha Levin wrote: > On 09/23/2015 09:08 AM, Andrey Konovalov wrote: > > On Wed, Sep 23, 2015 at 3:39 AM, Hugh Dickins wrote: > >> > This is totally untested, and one of you may quickly prove me wrong; > >> > but I went in to fix your "Bad page state (mlocked)" by holding pte > >> > lock across the down_read_trylock of mmap_sem in try_to_unmap_one(), > >> > then couldn't see why it would need mmap_sem at all, given how mlock > >> > and munlock first assert intention by setting or clearing VM_LOCKED > >> > in vm_flags, then work their way up the vma, taking pte locks. > >> > > >> > Calling mlock_vma_page() under pte lock may look suspicious > >> > at first: but what it does is similar to clear_page_mlock(), > >> > which we regularly call under pte lock from page_remove_rmap(). > >> > > >> > I'd rather wait to hear whether this appears to work in practice, > >> > and whether you agree that it should work in theory, before writing > >> > the proper description. I'd love to lose that down_read_trylock. > > No, unfortunately it doesn't work, I still see "Bad page state (mlocked)". > > > > It seems that your patch doesn't fix the race from the report below, since > > pte > > lock is not taken when 'vma->vm_flags &= ~VM_LOCKED;' (mlock.c:425) > > is being executed. (Line numbers are from kernel with your patch applied.) > > I've fired up my HZ_1 patch, Can we make HZ_1 thing into upstream? Under KERNEL_DEBUG, or something? > and this seems to be a real race that is > somewhat easy to reproduce under those conditions. > > Here's a fresh backtrace from my VMs: > > [1935109.882343] BUG: Bad page state in process trinity-subchil pfn:3ca200 > [1935109.884000] page:ea000f288000 count:0 mapcount:0 mapping: > (null) index:0x1e00 compound_mapcount: 0 > [1935109.885772] flags: 0x22f80144008(uptodate|head|swapbacked|mlocked) > [1935109.887174] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set > [1935109.888197] bad because of flags: > [1935109.888759] flags: 0x10(mlocked) > [1935109.889525] Modules linked in: > [1935109.890165] CPU: 8 PID: 2615 Comm: trinity-subchil Not tainted > 4.3.0-rc2-next-20150923-sasha-00079-gec04207-dirty #2569 > [1935109.891876] 16445448 e5dca494 8803f7657708 > a70402da > [1935109.893504] ea000f288000 8803f7657738 a56e522b > 022f80144008 > [1935109.894947] ea000f288020 ea000f288000 > 8803f76577a8 > [1935109.896413] Call Trace: > [1935109.899102] [] dump_stack+0x4e/0x84 > [1935109.899821] [] bad_page+0x17b/0x210 > [1935109.900469] [] free_pages_prepare+0xb48/0x1110 > [1935109.902127] [] __free_pages_ok+0x21/0x260 > [1935109.904435] [] free_compound_page+0x63/0x80 > [1935109.905614] [] free_transhuge_page+0x6e/0x80 > [1935109.906752] [] __put_compound_page+0x76/0xa0 > [1935109.907884] [] release_pages+0x4d5/0x9f0 > [1935109.913027] [] tlb_flush_mmu_free+0x8a/0x120 > [1935109.913957] [] unmap_page_range+0xe73/0x1460 > [1935109.915737] [] unmap_single_vma+0x126/0x2f0 > [1935109.916646] [] unmap_vmas+0xdd/0x190 > [1935109.917454] [] exit_mmap+0x221/0x430 > [1935109.921176] [] mmput+0xb1/0x240 > [1935109.921919] [] do_exit+0x732/0x27c0 > [1935109.928561] [] do_group_exit+0xf9/0x300 > [1935109.929786] [] SyS_exit_group+0x1d/0x20 > [1935109.930617] [] entry_SYSCALL_64_fastpath+0x16/0x7a Would it make any difference if you'll add mmap_sem protection in exit_mmap? -- Kirill A. Shutemov -- 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 10/10] mm, page_alloc: Only enforce watermarks for order-0 allocations
On Mon, Sep 21, 2015 at 01:03:17PM +0100, Mel Gorman wrote: > The primary purpose of watermarks is to ensure that reclaim can always > make forward progress in PF_MEMALLOC context (kswapd and direct reclaim). > These assume that order-0 allocations are all that is necessary for > forward progress. > > High-order watermarks serve a different purpose. Kswapd > had no high-order awareness before they were introduced > (https://lkml.kernel.org/r/413aa7b2.4000...@yahoo.com.au). This was > particularly important when there were high-order atomic requests. > The watermarks both gave kswapd awareness and made a reserve for those > atomic requests. > > There are two important side-effects of this. The most important is that > a non-atomic high-order request can fail even though free pages are available > and the order-0 watermarks are ok. The second is that high-order watermark > checks are expensive as the free list counts up to the requested order must > be examined. > > With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary to > have high-order watermarks. Kswapd and compaction still need high-order > awareness which is handled by checking that at least one suitable high-order > page is free. > > With the patch applied, there was little difference in the allocation > failure rates as the atomic reserves are small relative to the number of > allocation attempts. The expected impact is that there will never be an > allocation failure report that shows suitable pages on the free lists. > > The one potential side-effect of this is that in a vanilla kernel, the > watermark checks may have kept a free page for an atomic allocation. Now, > we are 100% relying on the HighAtomic reserves and an early allocation to > have allocated them. If the first high-order atomic allocation is after > the system is already heavily fragmented then it'll fail. > > Signed-off-by: Mel Gorman > Acked-by: Michal Hocko Nice. This really is a great improvement over the way we used to ensure higher-order page availability. Acked-by: Johannes Weiner -- 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/
[PATCHv4 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.
At the moment it only supports ANX7814.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
This driver adds initial support and supports HDMI to DP pass-through mode.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/anx78xx/Kconfig |7 +
drivers/gpu/drm/bridge/anx78xx/Makefile |4 +
drivers/gpu/drm/bridge/anx78xx/anx78xx.h | 41 +
drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c| 228 ++
drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c | 3148 ++
drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h | 214 ++
drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h | 807 ++
9 files changed, 4452 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..aa6fe12 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+source "drivers/gpu/drm/bridge/anx78xx/Kconfig"
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..e5bd38b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANX78XX) += anx78xx/
diff --git a/drivers/gpu/drm/bridge/anx78xx/Kconfig
b/drivers/gpu/drm/bridge/anx78xx/Kconfig
new file mode 100644
index 000..08f9c08
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Kconfig
@@ -0,0 +1,7 @@
+config DRM_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ help
+ ANX78XX is a HD video transmitter chip over micro-USB
+ connector for smartphone device.
+
+
diff --git a/drivers/gpu/drm/bridge/anx78xx/Makefile
b/drivers/gpu/drm/bridge/anx78xx/Makefile
new file mode 100644
index 000..a843733
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Makefile
@@ -0,0 +1,4 @@
+obj-${CONFIG_DRM_ANX78XX} := anx78xx.o
+
+anx78xx-y += anx78xx_main.o
+anx78xx-y += slimport_tx_drv.o
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
new file mode 100644
index 000..f62c8e7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. 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.
+ *
+ */
+
+#ifndef __ANX78xx_H
+#define __ANX78xx_H
+
+#include
+#include
+#include
+#include
+#include
+
+struct anx78xx_platform_data {
+ struct gpio_desc *gpiod_pd;
+ struct gpio_desc *gpiod_reset;
+ spinlock_t lock;
+};
+
+struct anx78xx {
+ struct i2c_client *client;
+ struct anx78xx_platform_data *pdata;
+ struct delayed_work work;
+ struct workqueue_struct *workqueue;
+ struct mutex lock;
+};
+
+void anx78xx_poweron(struct anx78xx *data);
+void anx78xx_poweroff(struct anx78xx *data);
+
+#endif
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
new file mode 100644
index 000..1e4a87e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. 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
[PATCHv4 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.
Analogix Semiconductor develops analog and mixed-signal devices for digital media and communications interconnect applications. Signed-off-by: Enric Balletbo i Serra Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c3..e914a02 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -22,6 +22,7 @@ ampireAmpire Co., Ltd. amsAMS AG amstaosAMS-Taos Inc. apmApplied Micro Circuits Corporation (APM) +analogix Analogix Semiconductor, Inc. aptina Aptina Imaging arasan Arasan Chip Systems armARM Ltd. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
You can add support to your board with current binding.
Example:
anx7814: anx7814@38 {
compatible = "analogix,anx7814";
reg = <0x38>;
pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
};
Signed-off-by: Enric Balletbo i Serra
---
.../devicetree/bindings/video/bridge/anx7814.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..a8cc746
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,22 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx7814"
+ - reg : I2C address of the device
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Example:
+
+ anx7814: anx7814@38 {
+ compatible = "analogix,anx7814";
+ reg = <0x38>;
+ pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 0/3] Add initial support for slimport anx78xx
Hi all, This is the fouth version with fixes suggested by Nicolas Boichat and Dan Carpenter. See the changelog below for details. The following series add initial support for the Slimport ANX7814 transmitter, a ultra-low power Full-HD (1080p60) transmitter designed for portable device. The driver was originally created and based from the work of Junhua Xia from Analogix. This driver is a refactor of the original driver and fixes different coding style lines, and different errors/warnings reported by checkpatch. Also there were things that I noticed that we need to change like: - Convert the numbered GPIO API to the new descriptor based GPIO API. - Review the DT binding - Add missing MODULE_DEVICE_TABLE(of, ...); - Fix Makefiles and Kconfig to build conditionally. - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and .resume callbacks. - Move to use managed device resources. - Remove dead/unused code. - And others ... Changes since v3: Nicolas Boichat: - Integrate sp_edid_header_result with sp_check_edid_data - Fix loop forever. - Use meaningful messages and variable names - Replace some 'while' loops and use a for loop. - Might be clearer to say >= LINK_6P75G - Convert a function to void function because always return 0 - Remove some magic numbers and refactor sp_tx_pclk_calc - Replace sp_read_reg(SP_TX_LINK_BW_SET_REG) for sp_tx_get_link_bw. - Mask bits 4:0. Bit 5 has another purpose, and 7:6 are reserved. - Use ARRAY_SIZE. - Use memset for initialization. - Simply condition if (!(c1 & POLLING_EN) || (c & POLLING_ERR)) - Don not use a temporal variable write the value directly. - Fix various typos - Return directly PTR_ERR. Dan Carpenter: - Refactor while loop removing the earlier condition and do while (--c) instead - Simplify double negative and fix alignment - Remove the superflous casts to u16 and parens - Remove debug printks and use ftrace instead. - Flip this condition around and pull the code in one indent level. - Fix return value 'ret' that should be an int. It causes a signedness bug later. - Use better style for devm_kzalloc - Get rid of AUX_*. They aren't used much and we could easily use normal error codes instead. Enric Balletbo - Fix errors reported by scripts/checkpatch.pl --strict --subjective - Remove XTAL_CLK_M10 XTAL_CLK definitions - replace ulong for unsigned long - remove some magic numbers and refactor sp_tx_enable_audio_output - remove some magic numbers and refactor sp_tx_phy_auto_test Changes since v2 (requested by Daniel Kurtz): - clean up the typos, and little nits requested by Dan. - move to the drm/bridge directory - rename the files, variables, types, etc. to anx78xx - plumb through the context struct to all functions that act on the device - use proper messaging (dev_ rather than pr_, _dbg/_err rather than _info) Changes since v1: - As requested by Greg, move from staging to a subsystem. Best regards, Enric Balletbo i Serra (3): of: Add vendor prefix for Analogix Semiconductor, Inc. devicetree: Add new ANX7814 SlimPort transmitter binding. drm: bridge: anx78xx: Add anx78xx driver support by analogix. .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/anx7814.txt | 22 + drivers/gpu/drm/bridge/Kconfig |2 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/anx78xx/Kconfig |7 + drivers/gpu/drm/bridge/anx78xx/Makefile|4 + drivers/gpu/drm/bridge/anx78xx/anx78xx.h | 41 + drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c | 228 ++ drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c | 3148 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h | 214 ++ drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h | 807 + 11 files changed, 4475 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] gpio: omap: convert to use generic irq handler
This patch converts TI OMAP GPIO driver to use generic irq handler
instead of chained IRQ handler. This way OMAP GPIO driver will be
compatible with RT kernel where it will be forced thread IRQ handler
while in non-RT kernel it still will be executed in HW IRQ context.
As part of this change the IRQ wakeup configuration is applied to
GPIO Bank IRQ as it now will be under control of IRQ PM Core during
suspend.
There are also additional benefits:
- on-RT kernel there will be no complains any more about PM runtime usage
in atomic context "BUG: sleeping function called from invalid context";
- GPIO bank IRQs will appear in /proc/interrupts and its usage statistic
will be visible;
- GPIO bank IRQs could be configured through IRQ proc_fs interface and,
as result, could be a part of IRQ balancing process if needed;
- GPIO bank IRQs will be under control of IRQ PM Core during
suspend to RAM.
Disadvantage:
- additional runtime overhed as call chain till
omap_gpio_irq_handler() will be longer now
- necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning
in handle_irq_event_percpu()
WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149
handle_irq_event_percpu+0x51c/0x638()
This patch doesn't fully follows recommendations provided by Sebastian
Andrzej Siewior [1], because It's required to go through and check all
GPIO IRQ pin states as fast as possible and pass control to handle_level_irq
or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions
specific for IRQ triggering type and wakeup corresponding registered
threaded IRQ handler (at least it's expected to be threaded).
IRQs can be lost if handle_nested_irq() will be used, because excecution
time of some pin specific GPIO IRQ handler can be very significant and
require accessing ext. devices (I2C).
Idea of such kind reworking was also discussed in [2].
[1] http://www.spinics.net/lists/linux-omap/msg120665.html
[2] http://www.spinics.net/lists/linux-omap/msg119516.html
Tested-by: Tony Lindgren
Tested-by: Austin Schuh
Signed-off-by: Grygorii Strashko
---
drivers/gpio/gpio-omap.c | 55
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a254691..376827f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -59,6 +59,7 @@ struct gpio_bank {
u32 level_mask;
u32 toggle_mask;
raw_spinlock_t lock;
+ raw_spinlock_t wa_lock;
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
@@ -649,8 +650,13 @@ static int omap_gpio_wake_enable(struct irq_data *d,
unsigned int enable)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
unsigned offset = d->hwirq;
+ int ret;
+
+ ret = omap_set_gpio_wakeup(bank, offset, enable);
+ if (!ret)
+ ret = irq_set_irq_wake(bank->irq, enable);
- return omap_set_gpio_wakeup(bank, offset, enable);
+ return ret;
}
static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
@@ -704,26 +710,21 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
* line's interrupt handler has been run, we may miss some nested
* interrupts.
*/
-static void omap_gpio_irq_handler(struct irq_desc *desc)
+static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
{
void __iomem *isr_reg = NULL;
u32 isr;
unsigned int bit;
- struct gpio_bank *bank;
- int unmasked = 0;
- struct irq_chip *irqchip = irq_desc_get_chip(desc);
- struct gpio_chip *chip = irq_desc_get_handler_data(desc);
+ struct gpio_bank *bank = gpiobank;
+ unsigned long wa_lock_flags;
unsigned long lock_flags;
- chained_irq_enter(irqchip, desc);
-
- bank = container_of(chip, struct gpio_bank, chip);
isr_reg = bank->base + bank->regs->irqstatus;
- pm_runtime_get_sync(bank->dev);
-
if (WARN_ON(!isr_reg))
goto exit;
+ pm_runtime_get_sync(bank->dev);
+
while (1) {
u32 isr_saved, level_mask = 0;
u32 enabled;
@@ -745,13 +746,6 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
raw_spin_unlock_irqrestore(>lock, lock_flags);
- /* if there is only edge sensitive GPIO pin interrupts
- configured, we could unmask GPIO bank interrupt immediately */
- if (!level_mask && !unmasked) {
- unmasked = 1;
- chained_irq_exit(irqchip, desc);
- }
-
if (!isr)
break;
@@ -772,18 +766,18 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
raw_spin_unlock_irqrestore(>lock, lock_flags);
+ raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);
+
[PATCH 0/2] convert to use generic irq handler
This patch series contains patches which fixes wrong APIs usage in atomic context on RT-kernel. The final goal is to make TI OMAP GPIO driver compatible with -RT kernel as much as possible. Patch 1: required to be compatible with -RT kernel, because PM runtime's irq_safe mode is incompatible with -RT. Patch 2: This patch converts TI OMAP GPIO driver to use generic irq handler instead of chained IRQ handler. This way OMAP GPIO driver will be compatible with RT-kernel where it will be forced thread IRQ handler while in non-RT kernel it still will be executed in HW IRQ context. Boot, basic gpio functionality tested on: dra7-evm, BeagleBone(white), am43xx-gpevm, am437x-sk Manually tested on dra7-evm including suspend/resume and wakeup. Links on RFC: https://lkml.org/lkml/2015/8/18/161 https://lkml.org/lkml/2015/8/18/162 Grygorii Strashko (2): gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock gpio: omap: convert to use generic irq handler drivers/gpio/gpio-omap.c | 80 +--- 1 file changed, 42 insertions(+), 38 deletions(-) -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
The PM runtime API can't be used in atomic contex on -RT even if
it's configured as irqsafe. As result, below error report can
be seen when PM runtime API called from IRQ chip's callbacks
irq_startup/irq_shutdown/irq_set_type, because they are
protected by RAW spinlock:
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: insmod
3 locks held by insmod/96:
#0: (>mutex){..}, at: [] __driver_attach+0x54/0xa0
#1: (>mutex){..}, at: [] __driver_attach+0x60/0xa0
#2: (class){..}, at: [] __irq_get_desc_lock+0x60/0xa4
irq event stamp: 1834
hardirqs last enabled at (1833): []
_raw_spin_unlock_irqrestore+0x88/0x90
hardirqs last disabled at (1834): [] _raw_spin_lock_irqsave+0x2c/0x64
softirqs last enabled at (0): [] copy_process.part.52+0x410/0x19d8
softirqs last disabled at (0): [< (null)>] (null)
Preemption disabled at:[< (null)>] (null)
CPU: 1 PID: 96 Comm: insmod Tainted: GW O
4.1.3-rt3-00618-g57e2387-dirty #184
Hardware name: Generic DRA74X (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x88/0xdc)
[] (dump_stack) from [] (___might_sleep+0x198/0x2a8)
[] (___might_sleep) from [] (rt_spin_lock+0x30/0x70)
[] (rt_spin_lock) from [] (__pm_runtime_resume+0x68/0xa4)
[] (__pm_runtime_resume) from []
(omap_gpio_irq_type+0x188/0x1d8)
[] (omap_gpio_irq_type) from []
(__irq_set_trigger+0x68/0x130)
[] (__irq_set_trigger) from [] (irq_set_irq_type+0x44/0x6c)
[] (irq_set_irq_type) from []
(irq_create_of_mapping+0x120/0x174)
[] (irq_create_of_mapping) from [] (of_irq_get+0x48/0x58)
[] (of_irq_get) from [] (i2c_device_probe+0x54/0x15c)
[] (i2c_device_probe) from []
(driver_probe_device+0x184/0x2c8)
[] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0)
[] (__driver_attach) from [] (bus_for_each_dev+0x7c/0xb0)
[] (bus_for_each_dev) from [] (driver_attach+0x28/0x30)
[] (driver_attach) from [] (bus_add_driver+0x154/0x200)
[] (bus_add_driver) from [] (driver_register+0x88/0x108)
[] (driver_register) from [] (i2c_register_driver+0x3c/0x90)
[] (i2c_register_driver) from [] (pcf857x_init+0x18/0x24
[gpio_pcf857x])
[] (pcf857x_init [gpio_pcf857x]) from []
(do_one_initcall+0x128/0x1e8)
[] (do_one_initcall) from [] (do_init_module+0x6c/0x1bc)
[] (do_init_module) from [] (load_module+0x18e8/0x21c4)
[] (load_module) from [] (SyS_init_module+0xfc/0x158)
[] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x54)
The IRQ chip interface defines only two callbacks which are executed in
non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move
PM runtime calls there.
Tested-by: Tony Lindgren
Tested-by: Austin Schuh
Signed-off-by: Grygorii Strashko
---
drivers/gpio/gpio-omap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5236db1..a254691 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -496,9 +496,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
(type & (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
- if (!BANK_USED(bank))
- pm_runtime_get_sync(bank->dev);
-
raw_spin_lock_irqsave(>lock, flags);
retval = omap_set_gpio_triggering(bank, offset, type);
if (retval) {
@@ -521,8 +518,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
return 0;
error:
- if (!BANK_USED(bank))
- pm_runtime_put(bank->dev);
return retval;
}
@@ -797,9 +792,6 @@ static unsigned int omap_gpio_irq_startup(struct irq_data
*d)
unsigned long flags;
unsigned offset = d->hwirq;
- if (!BANK_USED(bank))
- pm_runtime_get_sync(bank->dev);
-
raw_spin_lock_irqsave(>lock, flags);
if (!LINE_USED(bank->mod_usage, offset))
@@ -815,8 +807,6 @@ static unsigned int omap_gpio_irq_startup(struct irq_data
*d)
return 0;
err:
raw_spin_unlock_irqrestore(>lock, flags);
- if (!BANK_USED(bank))
- pm_runtime_put(bank->dev);
return -EINVAL;
}
@@ -835,6 +825,19 @@ static void omap_gpio_irq_shutdown(struct irq_data *d)
omap_clear_gpio_debounce(bank, offset);
omap_disable_gpio_module(bank, offset);
raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void omap_gpio_irq_bus_lock(struct irq_data *data)
+{
+ struct gpio_bank *bank = omap_irq_data_get_bank(data);
+
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank->dev);
+}
+
+static void gpio_irq_bus_sync_unlock(struct irq_data *data)
+{
+ struct gpio_bank *bank = omap_irq_data_get_bank(data);
/*
* If this is the last IRQ to be freed in the bank,
@@ -1183,6 +1186,8 @@ static int omap_gpio_probe(struct platform_device *pdev)
irqc->irq_unmask =
Re: [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand
On Mon, Sep 21, 2015 at 11:52:41AM +0100, Mel Gorman wrote: > High-order watermark checking exists for two reasons -- kswapd high-order > awareness and protection for high-order atomic requests. Historically the > kernel depended on MIGRATE_RESERVE to preserve min_free_kbytes as high-order > free pages for as long as possible. This patch introduces MIGRATE_HIGHATOMIC > that reserves pageblocks for high-order atomic allocations on demand and > avoids using those blocks for order-0 allocations. This is more flexible > and reliable than MIGRATE_RESERVE was. > > A MIGRATE_HIGHORDER pageblock is created when an atomic high-order allocation > request steals a pageblock but limits the total number to 1% of the zone. > Callers that speculatively abuse atomic allocations for long-lived > high-order allocations to access the reserve will quickly fail. Note that > SLUB is currently not such an abuser as it reclaims at least once. It is > possible that the pageblock stolen has few suitable high-order pages and > will need to steal again in the near future but there would need to be > strong justification to search all pageblocks for an ideal candidate. > > The pageblocks are unreserved if an allocation fails after a direct > reclaim attempt. > > The watermark checks account for the reserved pageblocks when the allocation > request is not a high-order atomic allocation. > > The reserved pageblocks can not be used for order-0 allocations. This may > allow temporary wastage until a failed reclaim reassigns the pageblock. This > is deliberate as the intent of the reservation is to satisfy a limited > number of atomic high-order short-lived requests if the system requires them. > > The stutter benchmark was used to evaluate this but while it was running > there was a systemtap script that randomly allocated between 1 high-order > page and 12.5% of memory's worth of order-3 pages using GFP_ATOMIC. This > is much larger than the potential reserve and it does not attempt to be > realistic. It is intended to stress random high-order allocations from > an unknown source, show that there is a reduction in failures without > introducing an anomaly where atomic allocations are more reliable than > regular allocations. The amount of memory reserved varied throughout the > workload as reserves were created and reclaimed under memory pressure. The > allocation failures once the workload warmed up were as follows; > > 4.2-rc5-vanilla 70% > 4.2-rc5-atomic-reserve56% > > The failure rate was also measured while building multiple kernels. The > failure rate was 14% but is 6% with this patch applied. > > Overall, this is a small reduction but the reserves are small relative > to the number of allocation requests. In early versions of the patch, > the failure rate reduced by a much larger amount but that required much > larger reserves and perversely made atomic allocations seem more reliable > than regular allocations. > > Signed-off-by: Mel Gorman > Acked-by: Vlastimil Babka Cool, this is much more obvious than trusting the MIGRATE_RESERVE mechanism for higher order atomics. Acked-by: Johannes Weiner -- 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/pvhvm: add soft reset on kexec/kdump support
On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:
On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:
Also, I am not sure I see how this new op will be used in the
hypervisor --- currently AFAICS it is only processed under
is_hardware_domain(). Are there other patches that will support HVM
guests?
Please see my Xen series:
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
(last 'full' submission).
All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
are already merged to xen.git (first 10 are already in 'master' and the
last one is in 'staging').
OK, so I was looking at the right tree. Then I don't understand how
SHUTDOWN_soft_reset would be reached for a non-privileged domain. The only
path that I see is
domain_shutdown()
{
...
if ( is_hardware_domain(d) )
hwdom_shutdown(reason);
...
}
Is there another path to handle this op?
Yes:
e1bd9812966de9a16f30a58e7162b80bd6af361b libxc: support XEN_DOMCTL_soft_reset
operation
and
c57e6ebd8c3e490e353e68d96abec1dad01e72f5 (lib)xl: soft reset support
That's toolstack issuing hypercalls from dom0.
I am asking about (non-privileged) guest itself calling SCHEDOP_shutdown.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/3] RAS, mce_amd_inj: Return early on invalid input
Invalid input such as these are currently reported on dmesg-
$> echo sweet > flags
[ 122.079139] flags_write: Invalid flags value: et
Even if the 'flags' attribute has been updated correctly-
$> cat flags
sw
But the input as a whole is wrong and we should not be
writing anything to the file. Therefore, modifying the
behavior in this patch to return EINVAL on bad input strings
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/ras/mce_amd_inj.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/ras/mce_amd_inj.c b/arch/x86/ras/mce_amd_inj.c
index 17e35b5..4fd8bb9 100644
--- a/arch/x86/ras/mce_amd_inj.c
+++ b/arch/x86/ras/mce_amd_inj.c
@@ -129,12 +129,9 @@ static ssize_t flags_write(struct file *filp, const char
__user *ubuf,
{
char buf[MAX_FLAG_OPT_SIZE], *__buf;
int err;
- size_t ret;
if (cnt > MAX_FLAG_OPT_SIZE)
- cnt = MAX_FLAG_OPT_SIZE;
-
- ret = cnt;
+ return -EINVAL;
if (copy_from_user(, ubuf, cnt))
return -EFAULT;
@@ -150,9 +147,9 @@ static ssize_t flags_write(struct file *filp, const char
__user *ubuf,
return err;
}
- *ppos += ret;
+ *ppos += cnt;
- return ret;
+ return cnt;
}
static const struct file_operations flags_fops = {
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] RAS, mce_amd_inj: Inject errors on NBC for bank 4 errors
Bank 4 MCEs are logged and reported only on the node base core (NBC) in
a socket. Refer to the D18F3x44[NbMcaToMstCpuEn] field in Fam10h and
later BKDGs. The node base core (NBC) is the lowest numbered core in the
node.
This patch ensures that we inject the error on the NBC for bank 4
errors. Otherwise, triggering #MC or APIC interrupts on a core which is
not the NBC would not have any effect on the system, i.e we would not
see any relevant output on kernel logs for the error we just injected.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/ras/mce_amd_inj.c | 56 ++
1 file changed, 56 insertions(+)
diff --git a/arch/x86/ras/mce_amd_inj.c b/arch/x86/ras/mce_amd_inj.c
index 794ca1f..42ab672 100644
--- a/arch/x86/ras/mce_amd_inj.c
+++ b/arch/x86/ras/mce_amd_inj.c
@@ -17,7 +17,9 @@
#include
#include
#include
+#include
#include
+#include
#include "../kernel/cpu/mcheck/mce-internal.h"
@@ -30,6 +32,7 @@ static struct dentry *dfs_inj;
static u8 n_banks;
#define MAX_FLAG_OPT_SIZE 3
+#define NBCFG 0x44
enum injection_type {
SW_INJ = 0, /* SW injection, simply decode the error */
@@ -196,6 +199,45 @@ static void trigger_thr_int(void *info)
asm volatile("int %0" :: "i" (THRESHOLD_APIC_VECTOR));
}
+static u32 get_nbc_for_node(int node_id)
+{
+ struct cpuinfo_x86 *c = _cpu_data;
+ u32 cores_per_node;
+
+ cores_per_node = c->x86_max_cores / amd_get_nodes_per_socket();
+
+ return cores_per_node * node_id;
+}
+
+static void toggle_nb_mca_mst_cpu(u16 nid)
+{
+ struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
+ u32 val;
+ int err;
+
+ if (!F3)
+ return;
+
+ err = pci_read_config_dword(F3, NBCFG, );
+ if (err) {
+ pr_err("%s: Error reading F%dx%03x.\n",
+ __func__, PCI_FUNC(F3->devfn), NBCFG);
+ return;
+ }
+
+ if (val & BIT(27))
+ return;
+
+ pr_err("%s: Set D18F3x44[NbMcaToMstCpuEn] which BIOS hasn't done.\n",
+ __func__);
+
+ val |= BIT(27);
+ err = pci_write_config_dword(F3, NBCFG, val);
+ if (err)
+ pr_err("%s: Error writing F%dx%03x.\n",
+ __func__, PCI_FUNC(F3->devfn), NBCFG);
+}
+
static void do_inject(void)
{
u64 mcg_status = 0;
@@ -230,6 +272,20 @@ static void do_inject(void)
i_mce.status |= (i_mce.status & ~MCI_STATUS_UC);
}
+ /*
+* For multi node CPUs, logging and reporting of bank 4 errors happens
+* only on the node base core. Refer to D18F3x44[NbMcaToMstCpuEn] for
+* Fam10h and later BKDGs.
+*/
+ if (static_cpu_has(X86_FEATURE_AMD_DCM) && b == 4) {
+ /*
+* BIOS sets D18F3x44[NbMcaToMstCpuEn] by default. But make
+* sure of it here just in case.
+*/
+ toggle_nb_mca_mst_cpu(amd_get_nb_id(cpu));
+ cpu = get_nbc_for_node(amd_get_nb_id(cpu));
+ }
+
get_online_cpus();
if (!cpu_online(cpu))
goto err;
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/3] Updates to mce_amd_inj module
This patchset is mostly a resend of earlier patches which got acceptance into maintainer's tree but did not make it into upstream. Original versions of patches 2 and 3 of this patchset- a. http://marc.info/?l=linux-edac=143327679901253=2 b. http://marc.info/?l=linux-edac=143392472509250=2 Changes from original versions- Patch 2: Earlier version did not include the update to README file. That was because README attribute was introduced in separate patch (http://marc.info/?l=linux-edac=143327679301249=2) But subsequently, only parts of it made it upstream. Patch 3: NBCFG register offset definition exists already in drivers/edac/amd64_edac.h which was included in earlier version. But any dependency with drivers/edac/ was removed when the file moved to arch/x86/ras. So, I have redefined it here. I can move it to a different place if required. With changes to the location of the module, I am adapting the patches on top of latest tip. Patch 1: Abort write file operation on invalid input Patch 2: Extend flags attribute to accept values of 'df', 'th'. These values will be used to trigger deferred error/threshold error apic interrupts respectively. Patch 3: Modify injection mechanism for bank 4 errors. Since they are logged or reported only on NBC, we make sure that we inject on the correct core here. Changes from V1 (per Boris' comments) - Instead of ignoring unwanted characters, return early on wrong input from user as this way, we can save a copy from user input for bad values. - With above change, modified patch title and commit message a bit. - Use 2 letter strings to indicate error injection for Deferred/Threshold error interrupts too. Aravind Gopalakrishnan (3): RAS, mce_amd_inj: Return early on invalid input RAS, mce_amd_inj: Add capability to trigger apic interrupts RAS, mce_amd_inj: Inject errors on NBC for bank 4 errors arch/x86/ras/mce_amd_inj.c | 109 ++--- 1 file changed, 102 insertions(+), 7 deletions(-) -- 2.4.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/3] RAS, mce_amd_inj: Add capability to trigger apic interrupts
With this extension to the flags attribute, deferred error interrupts
and threshold interrupts can be triggered to test the apic interrupt
handler functionality for these type of errors
Update README section about the same too.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/ras/mce_amd_inj.c | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/arch/x86/ras/mce_amd_inj.c b/arch/x86/ras/mce_amd_inj.c
index 4fd8bb9..794ca1f 100644
--- a/arch/x86/ras/mce_amd_inj.c
+++ b/arch/x86/ras/mce_amd_inj.c
@@ -34,12 +34,16 @@ static u8 n_banks;
enum injection_type {
SW_INJ = 0, /* SW injection, simply decode the error */
HW_INJ, /* Trigger a #MC */
+ DFR_INT_INJ,/* Trigger Deferred error interrupt */
+ THR_INT_INJ,/* Trigger threshold interrupt */
N_INJ_TYPES,
};
static const char * const flags_options[] = {
[SW_INJ] = "sw",
[HW_INJ] = "hw",
+ [DFR_INT_INJ] = "df",
+ [THR_INT_INJ] = "th",
NULL
};
@@ -182,6 +186,16 @@ static void trigger_mce(void *info)
asm volatile("int $18");
}
+static void trigger_dfr_int(void *info)
+{
+ asm volatile("int %0" :: "i" (DEFERRED_ERROR_VECTOR));
+}
+
+static void trigger_thr_int(void *info)
+{
+ asm volatile("int %0" :: "i" (THRESHOLD_APIC_VECTOR));
+}
+
static void do_inject(void)
{
u64 mcg_status = 0;
@@ -202,6 +216,20 @@ static void do_inject(void)
if (!(i_mce.status & MCI_STATUS_PCC))
mcg_status |= MCG_STATUS_RIPV;
+ if (inj_type == DFR_INT_INJ) {
+ /*
+* Ensure necessary status bits for deferred errors:
+* a. MCx_STATUS[Deferred] is set -
+*This is to ensure the error will be handled by the
+*interrupt handler
+* b. unset MCx_STATUS[UC]
+*As deferred errors are _not_ UC
+*/
+
+ i_mce.status |= MCI_STATUS_DEFERRED;
+ i_mce.status |= (i_mce.status & ~MCI_STATUS_UC);
+ }
+
get_online_cpus();
if (!cpu_online(cpu))
goto err;
@@ -222,7 +250,16 @@ static void do_inject(void)
toggle_hw_mce_inject(cpu, false);
- smp_call_function_single(cpu, trigger_mce, NULL, 0);
+ switch (inj_type) {
+ case DFR_INT_INJ:
+ smp_call_function_single(cpu, trigger_dfr_int, NULL, 0);
+ break;
+ case THR_INT_INJ:
+ smp_call_function_single(cpu, trigger_thr_int, NULL, 0);
+ break;
+ default:
+ smp_call_function_single(cpu, trigger_mce, NULL, 0);
+ }
err:
put_online_cpus();
@@ -287,6 +324,11 @@ static const char readme_msg[] =
"\thandle the error. Be warned: might cause system panic if
MCi_STATUS[PCC] \n"
"\tis set. Therefore, consider setting (debugfs_mountpoint)/mce/fake_panic
\n"
"\tbefore injecting.\n"
+"\t - \"df\": Trigger APIC interrupt for Deferred error. Causes deferred \n"
+"\terror APIC interrupt handler to handle the error if the feature is \n"
+"\tis present in hardware. \n"
+"\t - \"th\": Trigger APIC interrupt for Threshold errors. Causes threshold
\n"
+"\tAPIC interrupt handler to handle the error. \n"
"\n";
static ssize_t
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
On 09/25/2015 11:50 AM, Lee Jones wrote:
On Thu, 24 Sep 2015, Andrew F. Davis wrote:
This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:
- Regulators
- GPIO controller
Signed-off-by: Andrew F. Davis
---
drivers/mfd/Kconfig | 24 +++
drivers/mfd/Makefile | 3 +
drivers/mfd/tps65912-core.c | 114 +
drivers/mfd/tps65912-i2c.c | 86 ++
drivers/mfd/tps65912-spi.c | 85 ++
include/linux/mfd/tps65912.h | 393 +++
6 files changed, 705 insertions(+)
create mode 100644 drivers/mfd/tps65912-core.c
create mode 100644 drivers/mfd/tps65912-i2c.c
create mode 100644 drivers/mfd/tps65912-spi.c
create mode 100644 include/linux/mfd/tps65912.h
[...]
+#define TPS65912_IRQ(_name, _reg, _offset) \
+ [TPS65912_IRQ_ ## _name] = {\
+ .mask = TPS65912_ ## _reg ## _ ## _name,\
+ .reg_offset = _offset, \
+ }
I told you about this already.
If you want this set to be merged for v4.3 then you'll need commit
b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
tree.
You asked me to submit this to Mark Brown, I didn't realize you also
wanted me to use the one in your tree. Using yours will make my lines
over 80 chars and so it kind of defeats the purpose but I'll do it
for v4.
[...]
+static struct i2c_driver tps65912_i2c_driver = {
+ .driver = {
+ .name = "tps65912",
+ .of_match_table = tps65912_i2c_of_match_table,
of_match_ptr()
Why? tps65912_i2c_of_match_table is always compiled in.
[...]
--
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 03/16] page-flags: introduce page flags policies wrt compound pages
On Fri, Sep 25, 2015 at 03:29:17PM +0300, Konstantin Khlebnikov wrote:
> On 24.09.2015 17:50, Kirill A. Shutemov wrote:
> >This patch adds a third argument to macros which create function
> >definitions for page flags. This argument defines how page-flags helpers
> >behave on compound functions.
> >
> >For now we define four policies:
> >
> >- PF_ANY: the helper function operates on the page it gets, regardless
> > if it's non-compound, head or tail.
> >
> >- PF_HEAD: the helper function operates on the head page of the compound
> > page if it gets tail page.
> >
> >- PF_NO_TAIL: only head and non-compond pages are acceptable for this
> > helper function.
> >
> >- PF_NO_COMPOUND: only non-compound pages are acceptable for this helper
> > function.
> >
> >For now we use policy PF_ANY for all helpers, which matches current
> >behaviour.
> >
> >We do not enforce the policy for TESTPAGEFLAG, because we have flags
> >checked for random pages all over the kernel. Noticeable exception to
> >this is PageTransHuge() which triggers VM_BUG_ON() for tail page.
> >
> >Signed-off-by: Kirill A. Shutemov
> >---
> > include/linux/page-flags.h | 154
> > ++---
> > 1 file changed, 90 insertions(+), 64 deletions(-)
> >
> >diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> >index 713d3f2c2468..1b3babe5ff69 100644
> >--- a/include/linux/page-flags.h
> >+++ b/include/linux/page-flags.h
> >@@ -154,49 +154,68 @@ static inline int PageCompound(struct page *page)
> > return test_bit(PG_head, >flags) || PageTail(page);
> > }
> >
> >+/* Page flags policies wrt compound pages */
> >+#define PF_ANY(page, enforce) page
> >+#define PF_HEAD(page, enforce) compound_head(page)
> >+#define PF_NO_TAIL(page, enforce) ({
> >\
> >+if (enforce)\
> >+VM_BUG_ON_PAGE(PageTail(page), page); \
> >+else\
> >+page = compound_head(page); \
> >+page;})
> >+#define PF_NO_COMPOUND(page, enforce) ({
> >\
> >+if (enforce)\
> >+VM_BUG_ON_PAGE(PageCompound(page), page); \
>
> Linux next-20150925 crashes here (at least in lkvm)
> if CONFIG_DEFERRED_STRUCT_PAGE_INIT=y
Hm. I don't see the crash in qemu. Could you share your config?
> [0.00] Kernel command line: noapic noacpi pci=conf1 reboot=k panic=1
> i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 console=ttyS0
> earlyprintk=serial i8042.noaux=1 root=/dev/root rw
> rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p init=/virt/init
> ip=dhcp
> [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes)
> [0.00] BUG: unable to handle kernel NULL pointer dereference at
> 000c
> [0.00] IP: [] dump_page_badflags+0x2b/0xe0
> [0.00] PGD 0
> [0.00] Oops: [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.3.0-rc2-next-20150925+ #2
> [0.00] task: 81c12580 ti: 81c0 task.ti:
> 81c0
> [0.00] RIP: 0010:[] []
> dump_page_badflags+0x2b/0xe0
> [0.00] RSP: :81c03ea8 EFLAGS: 00010002
> [0.00] RAX: 000c RBX: ea6dfd40 RCX:
> 0100
> [0.00] RDX: 0001 RSI: 81a4aeb8 RDI:
> ea6dfd40
> [0.00] RBP: 81c03ec0 R08: R09:
>
> [0.00] R10: 0001 R11: R12:
>
> [0.00] R13: 0001b7f7 R14: 81fe50c0 R15:
> 81c03fb0
> [0.00] FS: () GS:88001a40()
> knlGS:
> [0.00] CS: 0010 DS: ES: CR0: 80050033
> [0.00] CR2: 000c CR3: 01c0b000 CR4:
> 000406b0
> [0.00] DR0: DR1: DR2:
>
> [0.00] DR3: DR6: fffe0ff0 DR7:
> 0400
> [0.00] Stack:
> [0.00] 0001b7f5 ea6dfd40 0001b7f7
> 81c03ed0
> [0.00] 811aabc0 81c03ef8 81785eda
> 81c03f10
> [0.
[PATCH] Clk: tegra: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
Coccinelle patch used-
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Shraddha Barke
---
drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
index 6125333..88b4ef4 100644
--- a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
+++ b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
@@ -147,18 +147,7 @@ static struct platform_driver tegra124_dfll_fcpu_driver = {
.pm = _dfll_pm_ops,
},
};
-
-static int __init tegra124_dfll_fcpu_init(void)
-{
- return platform_driver_register(_dfll_fcpu_driver);
-}
-module_init(tegra124_dfll_fcpu_init);
-
-static void __exit tegra124_dfll_fcpu_exit(void)
-{
- platform_driver_unregister(_dfll_fcpu_driver);
-}
-module_exit(tegra124_dfll_fcpu_exit);
+module_platform_driver(tegra124_dfll_fcpu_driver);
MODULE_DESCRIPTION("Tegra124 DFLL clock source driver");
MODULE_LICENSE("GPL v2");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] mm, page_alloc: Delete the zonelist_cache
On Mon, Sep 21, 2015 at 11:52:39AM +0100, Mel Gorman wrote: > The zonelist cache (zlc) was introduced to skip over zones that were > recently known to be full. This avoided expensive operations such as the > cpuset checks, watermark calculations and zone_reclaim. The situation > today is different and the complexity of zlc is harder to justify. > > 1) The cpuset checks are no-ops unless a cpuset is active and in general >are a lot cheaper. > > 2) zone_reclaim is now disabled by default and I suspect that was a large >source of the cost that zlc wanted to avoid. When it is enabled, it's >known to be a major source of stalling when nodes fill up and it's >unwise to hit every other user with the overhead. > > 3) Watermark checks are expensive to calculate for high-order >allocation requests. Later patches in this series will reduce the cost >of the watermark checking. > > 4) The most important issue is that in the current implementation it >is possible for a failed THP allocation to mark a zone full for order-0 >allocations and cause a fallback to remote nodes. > > The last issue could be addressed with additional complexity but as the > benefit of zlc is questionable, it is better to remove it. If stalls > due to zone_reclaim are ever reported then an alternative would be to > introduce deferring logic based on a timeout inside zone_reclaim itself > and leave the page allocator fast paths alone. > > The impact on page-allocator microbenchmarks is negligible as they don't > hit the paths where the zlc comes into play. Most page-reclaim related > workloads showed no noticeable difference as a result of the removal. > > The impact was noticeable in a workload called "stutter". One part uses a > lot of anonymous memory, a second measures mmap latency and a third copies > a large file. In an ideal world the latency application would not notice > the mmap latency. On a 2-node machine the results of this patch are > > stutter > 4.3.0-rc1 4.3.0-rc1 > baseline nozlc-v4 > Min mmap 20.9243 ( 0.00%) 20.7716 ( 0.73%) > 1st-qrtle mmap 22.0612 ( 0.00%) 22.0680 ( -0.03%) > 2nd-qrtle mmap 22.3291 ( 0.00%) 22.3809 ( -0.23%) > 3rd-qrtle mmap 25.2244 ( 0.00%) 25.2396 ( -0.06%) > Max-90% mmap 48.0995 ( 0.00%) 28.3713 ( 41.02%) > Max-93% mmap 52.5557 ( 0.00%) 36.0170 ( 31.47%) > Max-95% mmap 55.8173 ( 0.00%) 47.3163 ( 15.23%) > Max-99% mmap 67.3781 ( 0.00%) 70.1140 ( -4.06%) > Max mmap 24447.6375 ( 0.00%) 12915.1356 ( 47.17%) > Meanmmap 33.7883 ( 0.00%) 27.7944 ( 17.74%) > Best99%Mean mmap 27.7825 ( 0.00%) 25.2767 ( 9.02%) > Best95%Mean mmap 26.3912 ( 0.00%) 23.7994 ( 9.82%) > Best90%Mean mmap 24.9886 ( 0.00%) 23.2251 ( 7.06%) > Best50%Mean mmap 22.0157 ( 0.00%) 22.0261 ( -0.05%) > Best10%Mean mmap 21.6705 ( 0.00%) 21.6083 ( 0.29%) > Best5%Mean mmap 21.5581 ( 0.00%) 21.4611 ( 0.45%) > Best1%Mean mmap 21.3079 ( 0.00%) 21.1631 ( 0.68%) > > Note that the maximum stall latency went from 24 seconds to 12 which is still > bad but an improvement. The milage varies considerably 2-node machine on an > earlier test went from 494 seconds to 47 seconds and a 4-node machine that > tested an earlier version of this patch went from a worst case stall time of > 6 seconds to 67ms. The nature of the benchmark is inherently unpredictable > as it is hammering the system and the milage will vary between machines. > > There is a secondary impact with potentially more direct reclaim because > zones are now being considered instead of being skipped by zlc. In this > particular test run it did not occur so will not be described. However, > in at least one test the following was observed > > 1. Direct reclaim rates were higher. This was likely due to direct reclaim > being entered instead of the zlc disabling a zone and busy looping. > Busy looping may have the effect of allowing kswapd to make more > progress and in some cases may be better overall. If this is found then > the correct action is to put direct reclaimers to sleep on a waitqueue > and allow kswapd make forward progress. Busy looping on the zlc is even > worse than when the allocator used to blindly call congestion_wait(). > > 2. There was higher swap activity as direct reclaim was active. > > 3. Direct reclaim efficiency was lower. This is related to 1 as more > scanning activity also encountered more pages that could not be > immediately reclaimed > > In that case, the direct page scan and reclaim rates are noticeable but > it is not considered a problem for a few reasons > > 1. The test is primarily concerned with latency. The mmap attempts are also >faulted which means there are THP allocation requests. The ZLC could >cause zones to
Re: [PATCH 1/3] Make /dev/urandom scalable
On 2015-09-25 07:41, Austin S Hemmelgarn wrote: On 2015-09-24 16:14, Theodore Ts'o wrote: On Thu, Sep 24, 2015 at 03:11:23PM -0400, Austin S Hemmelgarn wrote: That is a startling result. Please say what architecture, kernel version, dieharder version and commandline arguments you are using to get 10% WEAK or FAILED assessments from dieharder on /dev/urandom. I do not remember what exact dieharder version or command-line arguments (this was almost a decade ago), except that I compiled it from source myself, I do remember it was a 32-bit x86 processor (as that was sadly all I had to run Linux on at the time), and an early 2.6 series kernel (which if I remember correctly was already EOL by the time I was using it). It might have been nice if you had said this from the beginning instead of making an unqualified statement with the assumption that it was applicable to kernels likely to be used today in non-obsolete systems. Otherwise it risks generating a click-bait article on Phoronix that would get people really worried for no good reason... I sincerely apologize about this, I should have been more specific right from the beginning (I need to get better about that when talking to people, I'm so used to dealing with some of my friends who couldn't event tell you the difference between RAM and a hard drive, think a bus is only something you use for transportation, and get confused when I try to properly explain even relatively simple CS and statistics concepts). There was a bug a long, long time ago (which where we weren't doing sufficient locking and if two processes raced reading from /dev/urandom at the same time, it was possible that the two processes would get the same value read out from /dev/urandom). This was fixed a long time ago, though, and in fact the scalability problem which Andi is trying to fix was caused by that extra locking that was added. :-) It's possible that is what you saw. I don't know, since there was no reproduction information to back up your rather startling claim. I don't think this was what I hit, I'm pretty sure I had serialized the dieharder runs. If you can reproduce consistent Dieharder failures, please do let us know with detailed reproduction instructures. Will do. OK, just started a couple of runs in parallel using different generators using the following command line: dieharder -a -m 32 -k 1 -Y 1 -g XXX with one each for: /dev/urandom (502) AES_OFB (205) glibc random() (039) mt19937 (013) The above command line will run all dieharder tests with 12800 psamples, using a higher than default precision, and re-running tests that return WEAK until it gets a PASS or FAIL. Even on the relatively fast (at least, fast for a desktop) system I'm running them on, I expect it will take quite some time to finish (although regardless of that I'm probably not going to be getting back to it until Monday). Interestingly, based on what dieharder is already saying about performance, /dev/urandom is slower than AES_OFB (at least, on this particular system, happy to provide hardware specs if someone wants). smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] gpio: omap: fix static checker warning
This patch fixes below static checker warning by changing
type of irq field in struct gpio_bank from u16 to int.
drivers/gpio/gpio-omap.c:1191 omap_gpio_probe()
warn: assigning (-6) to unsigned variable 'bank->irq'
drivers/gpio/gpio-omap.c
1188 bank->irq = platform_get_irq(pdev, 0);
1189 if (bank->irq <= 0) {
bank->irq is u16.
1190 if (!bank->irq)
1191 bank->irq = -ENXIO;
Does not work.
1192 if (bank->irq != -EPROBE_DEFER)
Does not work.
1193 dev_err(dev,
1194 "can't get irq resource ret=%d\n",
bank->irq);
1195 return bank->irq;
1196 }
Fixes: commit 89d18e3af8b9: "gpio: omap: switch to use platform_get_irq"
Signed-off-by: Grygorii Strashko
---
drivers/gpio/gpio-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 376827f..56d2d02 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -51,7 +51,7 @@ struct gpio_regs {
struct gpio_bank {
struct list_head node;
void __iomem *base;
- u16 irq;
+ int irq;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
--
2.5.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 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM
On Mon, Sep 21, 2015 at 11:52:38AM +0100, Mel Gorman wrote: > __GFP_WAIT was used to signal that the caller was in atomic context and > could not sleep. Now it is possible to distinguish between true atomic > context and callers that are not willing to sleep. The latter should clear > __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing __GFP_WAIT > behaves differently, there is a risk that people will clear the wrong > flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly indicate > what it does -- setting it allows all reclaim activity, clearing them > prevents it. > > Signed-off-by: Mel Gorman > Acked-by: Michal Hocko > Acked-by: Vlastimil Babka Acked-by: Johannes Weiner -- 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 05/10] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
On Fri, Sep 25, 2015 at 01:51:06PM +0100, Mel Gorman wrote: > On Thu, Sep 24, 2015 at 04:55:09PM -0400, Johannes Weiner wrote: > > On Mon, Sep 21, 2015 at 11:52:37AM +0100, Mel Gorman wrote: > > > @@ -119,10 +134,10 @@ struct vm_area_struct; > > > #define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL) > > > #define GFP_HIGHUSER (GFP_USER | __GFP_HIGHMEM) > > > #define GFP_HIGHUSER_MOVABLE (GFP_HIGHUSER | __GFP_MOVABLE) > > > -#define GFP_IOFS (__GFP_IO | __GFP_FS) > > > -#define GFP_TRANSHUGE(GFP_HIGHUSER_MOVABLE | __GFP_COMP | \ > > > - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN | \ > > > - __GFP_NO_KSWAPD) > > > +#define GFP_IOFS (__GFP_IO | __GFP_FS | __GFP_KSWAPD_RECLAIM) > > > > These are some really odd semantics to be given a name like that. > > > > GFP_IOFS was introduced as a short-hand for testing/setting/clearing > > these two bits at the same time, not to be used for allocations. In > > fact, the only user for allocations is lustre, and it's not at all > > obious why those sites shouldn't include __GFP_WAIT as well. > > > > Removing this definition altogether would probably be best. > > Ok, I'll add a TODO to create a patch that removes GFP_IOFS entirely. It > can be tacked on to the end of the series. Okay, that makes sense to me. Thanks! Acked-by: Johannes Weiner -- 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/pvhvm: add soft reset on kexec/kdump support
On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:
> On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:
> >>Also, I am not sure I see how this new op will be used in the
> >>hypervisor --- currently AFAICS it is only processed under
> >>is_hardware_domain(). Are there other patches that will support HVM
> >>guests?
> >Please see my Xen series:
> >http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
> >(last 'full' submission).
> >
> >All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
> >are already merged to xen.git (first 10 are already in 'master' and the
> >last one is in 'staging').
> >
>
>
> OK, so I was looking at the right tree. Then I don't understand how
> SHUTDOWN_soft_reset would be reached for a non-privileged domain. The only
> path that I see is
>
> domain_shutdown()
> {
> ...
> if ( is_hardware_domain(d) )
> hwdom_shutdown(reason);
> ...
> }
>
> Is there another path to handle this op?
Yes:
e1bd9812966de9a16f30a58e7162b80bd6af361b libxc: support XEN_DOMCTL_soft_reset
operation
and
c57e6ebd8c3e490e353e68d96abec1dad01e72f5 (lib)xl: soft reset support
--
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 09/14] ARM: dts: ifc6410: Add missing pinctrl to gsbi7 uart
Hi Srini, On Fri, Sep 18, 2015 at 5:31 AM, Srinivas Kandagatla wrote: > This patch adds missing 2pin uart pinctrl property to gsbi7 uart on > IFC6410. > > Signed-off-by: Srinivas Kandagatla kernelci.org found some new boot failures in -next on 8064[1]. I bisected it down to this patch, which landed in linux next in the form of commit d3a578ed4310 ARM: dts: ifc6410: Add missing pinctrl to gsbi7 uart. Kevin [1] http://kernelci.org/boot/qcom-apq8064-ifc6410/job/next/kernel/next-20150925/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5605083c59b51466d26c3250 -- 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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On 25-09-15, 20:49, Johannes Berg wrote: > Ok, then, but that means Rafael is completely wrong ... > debugfs_create_bool() takes a *pointer* and it needs to be long-lived, > it can't be on the stack. You also don't get a call when it changes. Ahh, ofcourse. My bad as well... I think we can change structure definition but will wait for Rafael's comment before that. -- viresh -- 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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and
> > doing
> >
> > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
> > > *)_ec->gpe))
> > > goto error;
> > > if (!debugfs_create_bool("use_global_lock", 0444,
> > > dev_dir,
> > > - (u32 *)_ec->global_lock))
> > > + _ec->global_lock))
> >
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > ))
> >
> > > goto error;
> >
> > first_ec->global_lock = val;
> >
> > And then you can turn val into bool just fine without changing the
> > structure
> > definition.
Ok, then, but that means Rafael is completely wrong ...
debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
it can't be on the stack. You also don't get a call when it changes.
If you cannot change the struct definition then you must implement a
debugfs file with its own read/write handlers.
johannes
--
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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's clearly
> impossible to use a pointer to the stack, assign to it once, and the
> expect anything to wkr at all ...
Sorry, I am not sure on what wouldn't work with this patch but this is
what Rafael said, and I don't think I wrote it differently :)
Rafael wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > -(u32 *)_ec->global_lock))
> > +_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
--
viresh
--
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: No more new fbdev drivers, please
On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote: > > > On 25/09/15 13:41, Kamil Lulko wrote: > > Hi, > > > >> fbdev is (more or less) maintained, but it's a deprecated framework. All > >> new Linux display drivers should be done on DRM. > > > > What about no-mmu platforms? DRM has a big fat MMU dependency in the > > kconfig, is there a way to write DRM driver for such devices? > > I guess not. > > Then again, I don't see why DRM would have a hard dependency to MMU, if > the work is done to make DRM work optionally without MMU. How much work > that is, I have no idea. We have plenty drivers in drm without hw mmu, and yeah there's probably no reason at all why the drm subsystem has a hard depency on cpu MMUs. Might be some #ifdef fallout that needs to be done, but there shouldn't be anything fundamental. Maybe the old dri1 days code has something, but that's all historical cruft anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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] richacl: Possible other write-through fix
On Fri, Sep 25, 2015 at 06:45:59PM +0200, Andreas Gruenbacher wrote:
> 2015-09-24 20:33 GMT+02:00 J. Bruce Fields :
> > On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote:
> >> +int
> >> +richacl_apply_masks(struct richacl **acl, kuid_t owner)
> >> +{
> >> + if ((*acl)->a_flags & RICHACL_MASKED) {
> >> + struct richacl_alloc alloc = {
> >> + .acl = richacl_clone(*acl, GFP_KERNEL),
> >> + .count = (*acl)->a_count,
> >> + };
> >> + if (!alloc.acl)
> >> + return -ENOMEM;
> >> +
> >> + if (richacl_move_everyone_aces_down() ||
> >> + richacl_propagate_everyone() ||
> >> + __richacl_apply_masks(, owner) ||
> >> + richacl_set_owner_permissions() ||
> >> + richacl_set_other_permissions() ||
> >
> > Hm, I'm a little unsure about this step: it seems like the one step that
> > can actually change the permissions (making them more permissive, in
> > this case), whereas the others are neutral.
> >
> > The following two steps should fix that, but I'm not sure they do.
> >
> > E.g. if I have an ACL like
> >
> > mask 0777, WRITE_THROUGH
> > GROUP@:r--::allow
> >
> > I think it should result in
> >
> > OWNER@: rwx::allow
> > GROUP@: -wx::deny
> > GROUP@: r--::allow
> > EVERYONE@:rwx::allow
> >
> > But does the GROUP@ deny actually get in there? It looks to me like the
> > denies inserted by richacl_isolate_group_class only take into account
> > the group mask, not the actual permissions granted to any group class
> > user.
> >
> > I may be mising something.
>
> Thanks for the test case and analysis. The group@ deny ace that should be
> inserted here actually doesn't get inserted. I'm attaching a fix.
This looks correct with the fix, thanks!
One nit:
> if (richacl_move_everyone_aces_down() ||
> richacl_propagate_everyone() ||
> __richacl_apply_masks(, owner) ||
> + richacl_set_other_permissions(, ) ||
It's still the case that this step lacks the property shared by the
other step, that it leaves permissions unchanged. Instead it increases
permissions, then the following step fixes the problem. That
complicates review slightly.
But I'm not sure that matters much.
Reviewed-by: J. Bruce Fields
--b.
> + richacl_isolate_group_class(, added) ||
> richacl_set_owner_permissions() ||
> - richacl_set_other_permissions() ||
> - richacl_isolate_owner_class() ||
> - richacl_isolate_group_class()) {
> + richacl_isolate_owner_class()) {
> richacl_put(alloc.acl);
> return -ENOMEM;
> }
> --
> 2.4.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 v2] gpio: mention in DT binding doc that -gpio is deprecated
On Mon, Sep 21, 2015 at 7:57 AM, Javier Martinez Canillas
wrote:
> The gpiolib supports parsing DT properties of the form -gpio but it
> was only added for compatibility with older DT bindings that got it wrong
> and should not be used in newer bindings.
>
> The commit that added support for this was:
>
> dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names")
>
> but didn't update the documentation to explain this so it's been a source
> of confusion. So let's make this clear in the GPIO DT binding doc.
>
> Signed-off-by: Javier Martinez Canillas
Applied. Thanks.
Rob
>
> ---
>
> Changes in v2:
> - Explain that -gpio is deprecated instead of saying that is
> supported. Suggested by Alexandre Courbot.
>
> Documentation/devicetree/bindings/gpio/gpio.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 5788d5cf1252..82d40e2505f6 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
> GPIO properties should be named "[-]gpios", with being the
> purpose
> of this GPIO for the device. While a non-existent is considered valid
> for compatibility reasons (resolving to the "gpios" property), it is not
> allowed
> -for new bindings.
> +for new bindings. Also, GPIO properties named "[-]gpio" are valid and
> old
> +bindings use it, but are only supported for compatibility reasons and should
> not
> +be used for newer bindings since it has been deprecated.
>
> GPIO properties can contain one or more GPIO phandles, but only in
> exceptional
> cases should they contain more than one. If your device uses several GPIOs
> with
> --
> 2.4.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 V1 3/6] ASoC: tlv320aic26: Make SND_SOC_TLV320AIC26 user-visible
Allow SND_SOC_TLV320AIC26 to be built. Based on commit: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/011287.html Signed-off-by: Cormier, Jonathan --- sound/soc/codecs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index efaafce8ba38..a70b5a00dc5e 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -640,7 +640,7 @@ config SND_SOC_TLV320AIC23_SPI select SND_SOC_TLV320AIC23 config SND_SOC_TLV320AIC26 - tristate + tristate "Texas Instruments TLV320AIC26 Codec support" depends on SPI config SND_SOC_TLV320AIC31XX -- 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 V1 2/6] ASoC: tlv320aic26: Fix module autoload
Add the missing MODULE_DEVICE_TABLE() for OF and SPI to export
the information so modules have the correct aliases built-in and
autoloading works correctly.
A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519
https://lkml.org/lkml/2014/9/11/458
Signed-off-by: Cormier, Jonathan
---
sound/soc/codecs/tlv320aic26.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 65c2bfb02e76..bf3a9ec40e1e 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -370,10 +370,17 @@ static int aic26_spi_remove(struct spi_device *spi)
return 0;
}
+static const struct spi_device_id tlv320aic26_id_table[] = {
+ { "tlv320aic26" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, tlv320aic26_id_table);
+
static const struct of_device_id tlv320aic26_of_match[] = {
{ .compatible = "ti,tlv320aic26", },
{},
};
+MODULE_DEVICE_TABLE(of, tlv320aic26_of_match);
static struct spi_driver aic26_spi = {
.driver = {
@@ -383,6 +390,7 @@ static struct spi_driver aic26_spi = {
},
.probe = aic26_spi_probe,
.remove = aic26_spi_remove,
+ .id_table = tlv320aic26_id_table,
};
module_spi_driver(aic26_spi);
--
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 V1 1/6] ASoC: tlv320aic26: Add device tree binding
Signed-off-by: Cormier, Jonathan
---
.../devicetree/bindings/sound/tlv320aic26.txt | 65 ++
sound/soc/codecs/tlv320aic26.c | 6 ++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic26.txt
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic26.txt
b/Documentation/devicetree/bindings/sound/tlv320aic26.txt
new file mode 100644
index ..93aa0f76ec0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic26.txt
@@ -0,0 +1,65 @@
+Texas Instruments - tlv320aic26 Codec module
+
+The tlv320aic26 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+"ti,tlv320aic26" - TLV320AIC26
+- reg - - SPI chip select
+
+CODEC input pins:
+ * MICIN
+ * AUX
+
+CODEC output pins:
+ * HPL
+ * HPR
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+
+tlv320aic26: tlv320aic26@0 {
+ compatible = "ti,tlv320aic26";
+ reg = <0>;
+};
+
+ {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_sleep_pins>;
+
+ status = "okay";
+ ti,pindir-d0-out-d1-in = <1>;
+
+ tlv320aic26: tlv320aic26@1 {
+ compatible = "ti,tlv320aic26";
+ reg = <0x1>;
+ status = "okay";
+
+ spi-max-frequency = <200>;
+ spi-cpha;
+ };
+};
+
+sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "AM335x_SND";
+ simple-audio-card,format = "dsp_b";
+ /* SND_SOC_DAIFMT_CBM_CFM */
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ /* SND_SOC_DAIFMT_IB_NF */
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ system-clock-frequency = <24576000>;
+ };
+
+ tlv320aic26_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ system-clock-frequency = <24576000>;
+ };
+};
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 620ab9ea1ef0..65c2bfb02e76 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -370,10 +370,16 @@ static int aic26_spi_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id tlv320aic26_of_match[] = {
+ { .compatible = "ti,tlv320aic26", },
+ {},
+};
+
static struct spi_driver aic26_spi = {
.driver = {
.name = "tlv320aic26-codec",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(tlv320aic26_of_match),
},
.probe = aic26_spi_probe,
.remove = aic26_spi_remove,
--
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 V1 6/6] ASoC: tlv320aic26: Change Capture Mute to Capture Switch to match alsa documentation.
Signed-off-by: Cormier, Jonathan
---
sound/soc/codecs/tlv320aic26.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 7d2fbca068d0..f7629b17ee5b 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -269,7 +269,7 @@ static const struct snd_kcontrol_new aic26_snd_controls[] =
{
SOC_DOUBLE("PCM Playback Volume", AIC26_REG_DAC_GAIN, 8, 0, 0x7f, 1),
SOC_DOUBLE("PCM Playback Switch", AIC26_REG_DAC_GAIN, 15, 7, 1, 1),
SOC_SINGLE("PCM Capture Volume", AIC26_REG_ADC_GAIN, 8, 0x7f, 0),
- SOC_SINGLE("PCM Capture Mute", AIC26_REG_ADC_GAIN, 15, 1, 1),
+ SOC_SINGLE("PCM Capture Switch", AIC26_REG_ADC_GAIN, 15, 1, 1),
SOC_SINGLE("Keyclick activate", AIC26_REG_AUDIO_CTRL2, 15, 0x1, 0),
SOC_SINGLE("Keyclick amplitude", AIC26_REG_AUDIO_CTRL2, 12, 0x7, 0),
SOC_SINGLE("Keyclick frequency", AIC26_REG_AUDIO_CTRL2, 8, 0x7, 0),
--
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 V1 4/6] ASoC: tlv320aic26: Fix regmap by setting reg_defaults and reg_stride
tlv320aic26 codec wasn't being setup correctly on bootup due to misconfigured
regmap cache.
Fixes: b7e9f3973279 "ASoC: tlv320aic26: Convert to direct regmap API usage"
Signed-off-by: Cormier, Jonathan
---
sound/soc/codecs/tlv320aic26.c | 28
1 file changed, 28 insertions(+)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index bf3a9ec40e1e..8355f379d45d 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -41,6 +41,27 @@ struct aic26 {
int keyclick_len;
};
+static const struct reg_default aic26_reg[] = {
+ /* Page 0 */
+ { 0x00A0, 0x }, { 0x00C0, 0x }, { 0x00E0, 0x },
+ { 0x0120, 0x }, { 0x0140, 0x },
+ /* Page 1 */
+ { 0x0800, 0x }, { 0x0820, 0x8000 }, { 0x0860, 0x0002 },
+ { 0x0880, 0x },
+ /* Page 2 */
+ { 0x1000, 0x }, { 0x1020, 0x8000 }, { 0x1040, 0x },
+ { 0x1060, 0xC580 }, { 0x1080, 0x4410 }, { 0x10A0, 0xAFC0 },
+ { 0x10C0, 0x }, { 0x10E0, 27619 }, { 0x1100, -27034 },
+ { 0x1120, 26461 }, { 0x1140, 27619 }, { 0x1160, -27034 },
+ { 0x1180, 26461 }, { 0x11A0, 32131 }, { 0x11C0, -31506 },
+ { 0x11E0, 32131 }, { 0x1200, -31506 }, { 0x1220, 27619 },
+ { 0x1240, -27034 }, { 0x1260, 26461 }, { 0x1280, 27619 },
+ { 0x12A0, -27034 }, { 0x12C0, 26461 }, { 0x12E0, 32131 },
+ { 0x1300, -31506 }, { 0x1320, 32131 }, { 0x1340, -31506 },
+ { 0x1360, 0x1004 }, { 0x1380, 0x }, { 0x13A0, 0x },
+ { 0x13C0, 0xFE00 },
+};
+
static const struct snd_soc_dapm_widget tlv320aic26_dapm_widgets[] = {
SND_SOC_DAPM_INPUT("MICIN"),
SND_SOC_DAPM_INPUT("AUX"),
@@ -332,6 +353,13 @@ static struct snd_soc_codec_driver aic26_soc_codec_dev = {
static const struct regmap_config aic26_regmap = {
.reg_bits = 16,
.val_bits = 16,
+ /* AIC26_PAGE_ADDR(0, 0x01) */
+ .reg_stride = 0x20,
+
+ .max_register = AIC26_REG_AUDIO_CTRL5,
+ .reg_defaults = aic26_reg,
+ .num_reg_defaults = ARRAY_SIZE(aic26_reg),
+ .cache_type = REGCACHE_RBTREE,
};
/* -
--
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 V1 5/6] ASoC: tlv320aic26: hw_params was unintentionally clearing AIC26 master mode
Commit: 5b0959d472c2 "ASoC: tlv320aic26: Use snd_soc_update_bits()" broke setting AIC26_REG_AUDIO_CTRL3 in master mode when fsref happens to be 48000. The master mode bit was getting cleared. Also fix setting AIC26_REG_DAC_GAIN and AIC26_REG_AUDIO_CTRL2 which was broke by same commit. Fixes: 5b0959d472c2 "ASoC: tlv320aic26: Use snd_soc_update_bits()" Signed-off-by: Cormier, Jonathan --- sound/soc/codecs/tlv320aic26.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c index 8355f379d45d..7d2fbca068d0 100644 --- a/sound/soc/codecs/tlv320aic26.c +++ b/sound/soc/codecs/tlv320aic26.c @@ -138,11 +138,12 @@ static int aic26_hw_params(struct snd_pcm_substream *substream, snd_soc_write(codec, AIC26_REG_PLL_PROG2, reg); /* Audio Control 3 (master mode, fsref rate) */ + reg = 0; if (aic26->master) - reg = 0x0800; + reg |= 0x0800; if (fsref == 48000) - reg = 0x2000; - snd_soc_update_bits(codec, AIC26_REG_AUDIO_CTRL3, 0xf800, reg); + reg |= 0x2000; + snd_soc_update_bits(codec, AIC26_REG_AUDIO_CTRL3, 0x2800, reg); /* Audio Control 1 (FSref divisor) */ reg = wlen | aic26->datfm | (divisor << 3) | divisor; @@ -167,7 +168,7 @@ static int aic26_mute(struct snd_soc_dai *dai, int mute) reg = 0x8080; else reg = 0; - snd_soc_update_bits(codec, AIC26_REG_DAC_GAIN, 0x8000, reg); + snd_soc_update_bits(codec, AIC26_REG_DAC_GAIN, 0x8080, reg); return 0; } @@ -302,7 +303,7 @@ static ssize_t aic26_keyclick_set(struct device *dev, struct aic26 *aic26 = dev_get_drvdata(dev); snd_soc_update_bits(aic26->codec, AIC26_REG_AUDIO_CTRL2, - 0x8000, 0x800); + 0x8000, 0x8000); return count; } -- 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 V1 0/6] ASoC: tlv320aic26: Add device tree support and bug fixes
Hi, The following patches were created to get the tlv320aic26 working on our AM335x SoM. This patch series relies on commit 93d0ad8f374c "ASoC: tlv320aic26: Convert to params_width()" for proper operation. Changes since RFC: - Removed the unecessary "#if defined(CONFIG_OF)" - Dropped the DSP_B patch Thanks -Jonathan Cormier, Jonathan (6): ASoC: tlv320aic26: Add device tree binding ASoC: tlv320aic26: Fix module autoload ASoC: tlv320aic26: Make SND_SOC_TLV320AIC26 user-visible ASoC: tlv320aic26: Fix regmap by setting reg_defaults and reg_stride ASoC: tlv320aic26: hw_params was unintentionally clearing AIC26 master mode ASoC: tlv320aic26: Change Capture Mute to Capture Switch to match alsa documentation. .../devicetree/bindings/sound/tlv320aic26.txt | 65 ++ sound/soc/codecs/Kconfig | 2 +- sound/soc/codecs/tlv320aic26.c | 55 -- 3 files changed, 115 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic26.txt -- 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 0/5] kernel/cpu.c: eliminate some indirection
Maybe third time's the charm...
The four cpumasks cpu_{possible,online,present,active}_bits are
exposed readonly via the corresponding const variables
cpu_xyz_mask. But they are also accessible for arbitrary writing via
the exposed functions set_cpu_xyz. There's quite a bit of code
throughout the kernel which iterates over or otherwise accesses these
bitmaps, and having the access go via the cpu_xyz_mask variables is
simply a useless indirection.
It may be that any problem in CS can be solved by an extra level of
indirection, but that doesn't mean every extra indirection solves a
problem. In this case, it even necessitates some minor ugliness (see
3/5).
The first four patches eliminate the cpu_xyz_mask variables by simply
exposing the actual bitmaps, after renaming them to discourage direct
access - that still happens through cpu_xyz_mask, which are now simply
macros with the same type and value as they used to have.
After that, there's no longer any reason to have the setter functions
be out-of-line: The boolean parameter is almost always a literal true
or false, so by making them static inlines they will usually compile
to one or two instructions.
For a defconfig build, bloat-o-meter says we save ~3000 bytes.
Rasmus Villemoes (5):
kernel/cpu.c: change type of cpu_possible_bits and friends
kernel/cpu.c: export __cpu_*_mask
drivers/base/cpu.c: use __cpu_*_mask directly
kernel/cpu.c: eliminate cpu_*_mask
kernel/cpu.c: make set_cpu_* static inlines
drivers/base/cpu.c | 10
include/linux/cpumask.h | 55 +++---
kernel/cpu.c| 64 ++---
3 files changed, 65 insertions(+), 64 deletions(-)
--
2.1.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/5] kernel/cpu.c: export __cpu_*_mask
Exporting the cpumasks __cpu_possible_mask and friends will allow us
to remove the extra indirection through the cpu_*_mask variables. It
will also allow the set_cpu_* functions to become static inlines,
which will give a .text reduction.
Signed-off-by: Rasmus Villemoes
---
include/linux/cpumask.h | 4
kernel/cpu.c| 14 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 59915ea5373c..d4545a1852f2 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -89,6 +89,10 @@ extern const struct cpumask *const cpu_possible_mask;
extern const struct cpumask *const cpu_online_mask;
extern const struct cpumask *const cpu_present_mask;
extern const struct cpumask *const cpu_active_mask;
+extern struct cpumask __cpu_possible_mask;
+extern struct cpumask __cpu_online_mask;
+extern struct cpumask __cpu_present_mask;
+extern struct cpumask __cpu_active_mask;
#if NR_CPUS > 1
#define num_online_cpus() cpumask_weight(cpu_online_mask)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index fea4a3ce3011..e08db26d351b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -772,23 +772,27 @@ const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) =
CPU_BITS_ALL;
EXPORT_SYMBOL(cpu_all_bits);
#ifdef CONFIG_INIT_ALL_POSSIBLE
-static struct cpumask __cpu_possible_mask __read_mostly
+struct cpumask __cpu_possible_mask __read_mostly
= {CPU_BITS_ALL};
#else
-static struct cpumask __cpu_possible_mask __read_mostly;
+struct cpumask __cpu_possible_mask __read_mostly;
#endif
+EXPORT_SYMBOL(__cpu_possible_mask);
const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
EXPORT_SYMBOL(cpu_possible_mask);
-static struct cpumask __cpu_online_mask __read_mostly;
+struct cpumask __cpu_online_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_online_mask);
const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
EXPORT_SYMBOL(cpu_online_mask);
-static struct cpumask __cpu_present_mask __read_mostly;
+struct cpumask __cpu_present_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_present_mask);
const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
EXPORT_SYMBOL(cpu_present_mask);
-static struct cpumask __cpu_active_mask __read_mostly;
+struct cpumask __cpu_active_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_active_mask);
const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
EXPORT_SYMBOL(cpu_active_mask);
--
2.1.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] dax: fix deadlock in __dax_fault
On Fri, Sep 25, 2015 at 12:53:57PM +1000, Dave Chinner wrote: <> > We've already got block allocation serialisation at the filesystem > level, and the issue is the unserialised block zeroing being done by > the dax code. That can be fixed by moving the zeroing into the > filesystem code when it runs "complete_unwritten" and checks whether > the mapping has already been marked as written or not... > > I've recently pointed out in a different thread that this is the > solution to whatever that problem was (can't recall which > thread/problem is was now :/ ) and it the same solution here. We > already have the serialisation we need, we just need to move the > block zeroing operation into the appropriate places to make it work > correctly. I think perhaps this is the thread that you're remembering: https://lkml.org/lkml/2015/8/11/731 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] kernel/cpu.c: make set_cpu_* static inlines
Almost all callers of the set_cpu_* functions pass an explicit true
or false. Making them static inline thus replaces the function calls
with a simple set_bit/clear_bit, saving some .text.
Signed-off-by: Rasmus Villemoes
---
include/linux/cpumask.h | 43 +++
kernel/cpu.c| 34 --
2 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 52ab539aefce..fc14275ff34e 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -720,14 +720,49 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
#define for_each_present_cpu(cpu) for_each_cpu((cpu), cpu_present_mask)
/* Wrappers for arch boot code to manipulate normally-constant masks */
-void set_cpu_possible(unsigned int cpu, bool possible);
-void set_cpu_present(unsigned int cpu, bool present);
-void set_cpu_online(unsigned int cpu, bool online);
-void set_cpu_active(unsigned int cpu, bool active);
void init_cpu_present(const struct cpumask *src);
void init_cpu_possible(const struct cpumask *src);
void init_cpu_online(const struct cpumask *src);
+static inline void
+set_cpu_possible(unsigned int cpu, bool possible)
+{
+ if (possible)
+ cpumask_set_cpu(cpu, &__cpu_possible_mask);
+ else
+ cpumask_clear_cpu(cpu, &__cpu_possible_mask);
+}
+
+static inline void
+set_cpu_present(unsigned int cpu, bool present)
+{
+ if (present)
+ cpumask_set_cpu(cpu, &__cpu_present_mask);
+ else
+ cpumask_clear_cpu(cpu, &__cpu_present_mask);
+}
+
+static inline void
+set_cpu_online(unsigned int cpu, bool online)
+{
+ if (online) {
+ cpumask_set_cpu(cpu, &__cpu_online_mask);
+ cpumask_set_cpu(cpu, &__cpu_active_mask);
+ } else {
+ cpumask_clear_cpu(cpu, &__cpu_online_mask);
+ }
+}
+
+static inline void
+set_cpu_active(unsigned int cpu, bool active)
+{
+ if (active)
+ cpumask_set_cpu(cpu, &__cpu_active_mask);
+ else
+ cpumask_clear_cpu(cpu, &__cpu_active_mask);
+}
+
+
/**
* to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
* @bitmap: the bitmap
diff --git a/kernel/cpu.c b/kernel/cpu.c
index dd70f600442f..5210d80efc28 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -788,40 +788,6 @@ EXPORT_SYMBOL(__cpu_present_mask);
struct cpumask __cpu_active_mask __read_mostly;
EXPORT_SYMBOL(__cpu_active_mask);
-void set_cpu_possible(unsigned int cpu, bool possible)
-{
- if (possible)
- cpumask_set_cpu(cpu, &__cpu_possible_mask);
- else
- cpumask_clear_cpu(cpu, &__cpu_possible_mask);
-}
-
-void set_cpu_present(unsigned int cpu, bool present)
-{
- if (present)
- cpumask_set_cpu(cpu, &__cpu_present_mask);
- else
- cpumask_clear_cpu(cpu, &__cpu_present_mask);
-}
-
-void set_cpu_online(unsigned int cpu, bool online)
-{
- if (online) {
- cpumask_set_cpu(cpu, &__cpu_online_mask);
- cpumask_set_cpu(cpu, &__cpu_active_mask);
- } else {
- cpumask_clear_cpu(cpu, &__cpu_online_mask);
- }
-}
-
-void set_cpu_active(unsigned int cpu, bool active)
-{
- if (active)
- cpumask_set_cpu(cpu, &__cpu_active_mask);
- else
- cpumask_clear_cpu(cpu, &__cpu_active_mask);
-}
-
void init_cpu_present(const struct cpumask *src)
{
cpumask_copy(&__cpu_present_mask, src);
--
2.1.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 1/5] kernel/cpu.c: change type of cpu_possible_bits and friends
Change cpu_possible_bits and friends (online, present, active) from
being bitmaps that happen to have the right size to actually being
struct cpumasks. Also rename them to __cpu_xyz_mask. This is mostly a
small cleanup in preparation for exporting them and, eventually,
eliminating the extra indirection through the cpu_xyz_mask variables.
Signed-off-by: Rasmus Villemoes
---
kernel/cpu.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 82cf9dff4295..fea4a3ce3011 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -772,71 +772,71 @@ const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) =
CPU_BITS_ALL;
EXPORT_SYMBOL(cpu_all_bits);
#ifdef CONFIG_INIT_ALL_POSSIBLE
-static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly
- = CPU_BITS_ALL;
+static struct cpumask __cpu_possible_mask __read_mostly
+ = {CPU_BITS_ALL};
#else
-static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly;
+static struct cpumask __cpu_possible_mask __read_mostly;
#endif
-const struct cpumask *const cpu_possible_mask = to_cpumask(cpu_possible_bits);
+const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
EXPORT_SYMBOL(cpu_possible_mask);
-static DECLARE_BITMAP(cpu_online_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_online_mask = to_cpumask(cpu_online_bits);
+static struct cpumask __cpu_online_mask __read_mostly;
+const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
EXPORT_SYMBOL(cpu_online_mask);
-static DECLARE_BITMAP(cpu_present_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_present_mask = to_cpumask(cpu_present_bits);
+static struct cpumask __cpu_present_mask __read_mostly;
+const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
EXPORT_SYMBOL(cpu_present_mask);
-static DECLARE_BITMAP(cpu_active_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_active_mask = to_cpumask(cpu_active_bits);
+static struct cpumask __cpu_active_mask __read_mostly;
+const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
EXPORT_SYMBOL(cpu_active_mask);
void set_cpu_possible(unsigned int cpu, bool possible)
{
if (possible)
- cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
+ cpumask_set_cpu(cpu, &__cpu_possible_mask);
else
- cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
+ cpumask_clear_cpu(cpu, &__cpu_possible_mask);
}
void set_cpu_present(unsigned int cpu, bool present)
{
if (present)
- cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
+ cpumask_set_cpu(cpu, &__cpu_present_mask);
else
- cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
+ cpumask_clear_cpu(cpu, &__cpu_present_mask);
}
void set_cpu_online(unsigned int cpu, bool online)
{
if (online) {
- cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits));
- cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits));
+ cpumask_set_cpu(cpu, &__cpu_online_mask);
+ cpumask_set_cpu(cpu, &__cpu_active_mask);
} else {
- cpumask_clear_cpu(cpu, to_cpumask(cpu_online_bits));
+ cpumask_clear_cpu(cpu, &__cpu_online_mask);
}
}
void set_cpu_active(unsigned int cpu, bool active)
{
if (active)
- cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits));
+ cpumask_set_cpu(cpu, &__cpu_active_mask);
else
- cpumask_clear_cpu(cpu, to_cpumask(cpu_active_bits));
+ cpumask_clear_cpu(cpu, &__cpu_active_mask);
}
void init_cpu_present(const struct cpumask *src)
{
- cpumask_copy(to_cpumask(cpu_present_bits), src);
+ cpumask_copy(&__cpu_present_mask, src);
}
void init_cpu_possible(const struct cpumask *src)
{
- cpumask_copy(to_cpumask(cpu_possible_bits), src);
+ cpumask_copy(&__cpu_possible_mask, src);
}
void init_cpu_online(const struct cpumask *src)
{
- cpumask_copy(to_cpumask(cpu_online_bits), src);
+ cpumask_copy(&__cpu_online_mask, src);
}
--
2.1.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 4/5] kernel/cpu.c: eliminate cpu_*_mask
Replace the variables cpu_possible_mask, cpu_online_mask,
cpu_present_mask and cpu_active_mask with macros expanding to
expressions of the same type and value, eliminating some indirection.
Signed-off-by: Rasmus Villemoes
---
include/linux/cpumask.h | 8
kernel/cpu.c| 8
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index d4545a1852f2..52ab539aefce 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -85,14 +85,14 @@ extern int nr_cpu_ids;
*only one CPU.
*/
-extern const struct cpumask *const cpu_possible_mask;
-extern const struct cpumask *const cpu_online_mask;
-extern const struct cpumask *const cpu_present_mask;
-extern const struct cpumask *const cpu_active_mask;
extern struct cpumask __cpu_possible_mask;
extern struct cpumask __cpu_online_mask;
extern struct cpumask __cpu_present_mask;
extern struct cpumask __cpu_active_mask;
+#define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
+#define cpu_online_mask ((const struct cpumask *)&__cpu_online_mask)
+#define cpu_present_mask ((const struct cpumask *)&__cpu_present_mask)
+#define cpu_active_mask ((const struct cpumask *)&__cpu_active_mask)
#if NR_CPUS > 1
#define num_online_cpus() cpumask_weight(cpu_online_mask)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e08db26d351b..dd70f600442f 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -778,23 +778,15 @@ struct cpumask __cpu_possible_mask __read_mostly
struct cpumask __cpu_possible_mask __read_mostly;
#endif
EXPORT_SYMBOL(__cpu_possible_mask);
-const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
-EXPORT_SYMBOL(cpu_possible_mask);
struct cpumask __cpu_online_mask __read_mostly;
EXPORT_SYMBOL(__cpu_online_mask);
-const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
-EXPORT_SYMBOL(cpu_online_mask);
struct cpumask __cpu_present_mask __read_mostly;
EXPORT_SYMBOL(__cpu_present_mask);
-const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
-EXPORT_SYMBOL(cpu_present_mask);
struct cpumask __cpu_active_mask __read_mostly;
EXPORT_SYMBOL(__cpu_active_mask);
-const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
-EXPORT_SYMBOL(cpu_active_mask);
void set_cpu_possible(unsigned int cpu, bool possible)
{
--
2.1.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 3/5] drivers/base/cpu.c: use __cpu_*_mask directly
The only user of the lvalue-ness of the cpu_*_mask variables is in
drivers/base/cpu.c, and that is mostly a work-around for the fact that
not even const variables can be used in static initialization. Now
that the underlying struct cpumasks are exposed we can take their
address.
Signed-off-by: Rasmus Villemoes
---
drivers/base/cpu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 91bbb1959d8d..691eeea2f19a 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -200,7 +200,7 @@ static const struct attribute_group
*hotplugable_cpu_attr_groups[] = {
struct cpu_attr {
struct device_attribute attr;
- const struct cpumask *const * const map;
+ const struct cpumask *const map;
};
static ssize_t show_cpus_attr(struct device *dev,
@@ -209,7 +209,7 @@ static ssize_t show_cpus_attr(struct device *dev,
{
struct cpu_attr *ca = container_of(attr, struct cpu_attr, attr);
- return cpumap_print_to_pagebuf(true, buf, *ca->map);
+ return cpumap_print_to_pagebuf(true, buf, ca->map);
}
#define _CPU_ATTR(name, map) \
@@ -217,9 +217,9 @@ static ssize_t show_cpus_attr(struct device *dev,
/* Keep in sync with cpu_subsys_attrs */
static struct cpu_attr cpu_attrs[] = {
- _CPU_ATTR(online, _online_mask),
- _CPU_ATTR(possible, _possible_mask),
- _CPU_ATTR(present, _present_mask),
+ _CPU_ATTR(online, &__cpu_online_mask),
+ _CPU_ATTR(possible, &__cpu_possible_mask),
+ _CPU_ATTR(present, &__cpu_present_mask),
};
/*
--
2.1.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 v2 0/2] ASoC: atmel-classd: add driver for Atmel CLASSD
On Thu, Sep 24, 2015 at 01:41:25PM +0800, Songjun Wu wrote: > Songjun Wu (2): > ASoC: atmel-classd: add the Audio Class D Amplifier > ASoC: atmel-classd: DT binding for Class D audio amplifier driver I don't seem to have the second patch with the binding documentation. signature.asc Description: Digital signature
Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC
On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:
> +static int tps65912_regulator_probe(struct platform_device *pdev)
> +{
> + struct tps65912 *tps = dev_get_drvdata(pdev->dev.parent);
> + struct regulator_init_data *init_data;
> + const struct tps_info *template;
> + struct regulator_dev *rdev;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + int id;
> +
> + match = of_match_device(tps65912_regulator_of_match_table, >dev);
> + if (!match)
> + return -ENODEV;
> +
> + template = match->data;
> + id = template->id;
> + init_data = of_get_regulator_init_data(>dev, pdev->dev.of_node,
> +[id]);
Don't open code this stuff, use the core DT matching in the
regulator_desc instead.
Please also use subject lines mathcing the style for the subsystem.
signature.asc
Description: Digital signature
Re: [PATCH v4 4/7] fs: Limit file caps to the user namespace of the super block
Seth Forshee writes: > On Thu, Sep 24, 2015 at 04:59:35PM -0500, Eric W. Biederman wrote: >> Seth Forshee writes: >> >> > Capability sets attached to files must be ignored except in the >> > user namespaces where the mounter is privileged, i.e. s_user_ns >> > and its descendants. Otherwise a vector exists for gaining >> > privileges in namespaces where a user is not already privileged. >> > >> > Add a new helper function, in_user_ns(), to test whether a user >> > namespace is the same as or a descendant of another namespace. >> > Use this helper to determine whether a file's capability set >> > should be applied to the caps constructed during exec. >> >> No issues with this but given that we always pass current_user_ns() >> we may want to simplify the users of in_user_ns by renaming it >> current_in_user_ns() and hard codeing current_user_ns(). > > Sure, if that's what you prefer then I'll change it. I took your patch as is. This is a suggestion for a possible incremental improvement. Eric -- 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] f2fs: fix to correct freed section number during gc
On Fri, Sep 25, 2015 at 05:50:55PM +0800, Chao Yu wrote:
> This patch fixes to maintain the right section count freed in garbage
> collecting when triggering a foreground gc.
>
> Besides, when a foreground gc is running on current selected section, once
> we fail to gc one segment, it's better to abandon gcing the left segments
> in current section, because anyway we will select next victim for
> foreground gc, so gc on the left segments in previous section will become
> overhead and also cause the long latency for caller.
>
> Signed-off-by: Chao Yu
> ---
> v2:
> o avoid calc the wrong value when freed segments across sections.
> fs/f2fs/gc.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index e932740..256ebd4 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -802,7 +802,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi)
> unsigned int segno = NULL_SEGNO;
> unsigned int i;
> int gc_type = BG_GC;
> - int nfree = 0;
> + int sec_freed = 0, seg_freed;
> int ret = -1;
> struct cp_control cpc;
> struct gc_inode_list gc_list = {
> @@ -817,7 +817,7 @@ gc_more:
> if (unlikely(f2fs_cp_error(sbi)))
> goto stop;
>
> - if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
> + if (gc_type == BG_GC && has_not_enough_free_secs(sbi, sec_freed)) {
> gc_type = FG_GC;
> if (__get_victim(sbi, , gc_type) || prefree_segments(sbi))
> write_checkpoint(sbi, );
> @@ -833,13 +833,25 @@ gc_more:
> ra_meta_pages(sbi, GET_SUM_BLOCK(sbi, segno), sbi->segs_per_sec,
> META_SSA);
>
> - for (i = 0; i < sbi->segs_per_sec; i++)
> - nfree += do_garbage_collect(sbi, segno + i, _list, gc_type);
> + for (i = 0, seg_freed = 0; i < sbi->segs_per_sec; i++) {
> + /*
> + * for FG_GC case, halt gcing left segments once failed one
> + * of segments in selected section to avoid long latency.
> + */
> + if (!do_garbage_collect(sbi, segno + i, _list, gc_type) &&
> + gc_type == FG_GC)
> + break;
> + if (gc_type == FG_GC)
> + seg_freed++;
> + }
How about?
if (i == sbi->segs_per_sec && gc_type == FG_GC)
sec_free++;
> +
> + if (seg_freed == sbi->segs_per_sec)
> + sec_freed++;
>
> if (gc_type == FG_GC)
> sbi->cur_victim_sec = NULL_SEGNO;
>
> - if (has_not_enough_free_secs(sbi, nfree))
> + if (has_not_enough_free_secs(sbi, sec_freed))
> goto gc_more;
>
> if (gc_type == FG_GC)
> --
> 2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: Increase the max granular size
On 09/25/2015 07:45 AM, Robert Richter wrote: Will, On 22.09.15 19:29:02, Will Deacon wrote: On Tue, Sep 22, 2015 at 06:59:48PM +0100, Robert Richter wrote: From: Tirumalesh Chalamarla Increase the standard cacheline size to avoid having locks in the same cacheline. Cavium's ThunderX core implements cache lines of 128 byte size. With current granulare size of 64 bytes (L1_CACHE_SHIFT=6) two locks could share the same cache line leading a performance degradation. Increasing the size fixes that. Do you have an example of that happening? I did some 'poor man's kernel build all modules benchmarking' and could not find significant performance improvements so far (second part with the patch reverted): build-allmodules-4.2.0-01404-g5818d6e89783.log:real 7m10.490s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 6m59.747s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 6m59.264s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 7m0.435s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 6m59.569s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 6m59.274s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 7m0.507s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 7m1.551s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 6m59.073s build-allmodules-4.2.0-01404-g5818d6e89783.log:real 7m1.738s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m10.644s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 6m59.814s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m0.315s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 6m59.610s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 6m59.885s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 6m59.281s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m0.869s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m0.953s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m0.787s build-allmodules-4.2.0-01406-g638c69fddc40.log:real 7m0.656s I will check what kind of workloads this patch was written for. Tirumalesh, any idea? mainly for workloads where compiler optimizes based on cache line size, let me write a small bench mark Thanks, -Robert Increasing the size has no negative impact to cache invalidation on systems with a smaller cache line. There is an impact on memory usage, but that's not too important for arm64 use cases. Do you have any before/after numbers to show the impact of this change on other supported SoCs? -- 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] net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected
Hello. On 9/24/2015 1:16 PM, Sudip Mukherjee wrote: The builds of allmodconfig of avr32 is failing with: drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI is not defined and CONFIG_GENERIC_PCI_IOMAP is defined. Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both are not defined. Signed-off-by: Sudip Mukherjee --- Failed build log is at: https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188 An exactly similar patch has been posted earlier and relevant discussion is at: https://patchwork.ozlabs.org/patch/498722/ I posted a patch to include empty pci_iomap, pci_iounmap in avr32. That discussion is at: https://lkml.org/lkml/2015/9/19/100 drivers/net/ethernet/via/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig index 2f1264b..17831e5 100644 --- a/drivers/net/ethernet/via/Kconfig +++ b/drivers/net/ethernet/via/Kconfig @@ -17,7 +17,7 @@ if NET_VENDOR_VIA config VIA_RHINE tristate "VIA Rhine support" - depends on (PCI || OF_IRQ) + depends on (PCI || (OF_IRQ && GENERIC_PCI_IOMAP)) Could you remove outer braces, while at it? [...] MBR, Sergei -- 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 00/10] Add RPM/SMD Support for QCOM platforms
On Thu, Sep 24, 2015 at 02:18:49PM -0500, Andy Gross wrote: > This patch set cleans up the documentation that is currently in place for the > SMD, SMD-RPM, and SMD-RPM regulators. In addition, this patch set adds > support > for the PM8916 found on MSM8916 platforms and the PMA8084 found on APQ8084 > platforms. The regulator patches are fine but depend on the first patch moving the documentation around - I don't know how you want to handle this? signature.asc Description: Digital signature
[PATCH v2 2/8] spi: imx: replace fixed timeout with calculated one
Fixed timeout value can fire while transaction is ongoing. This may happen
because there are no strict requirements on SPI transaction duration.
Dynamic timeout value is generated based on SCLK and transaction size.
There is also 4 * SCLK delay between TX bursts related to CS change.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 49 +
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 165bc2c..6c98eda 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -59,7 +59,6 @@
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
-#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -95,6 +94,7 @@ struct spi_imx_data {
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
+ unsigned int spi_bus_clk;
unsigned int count;
void (*tx)(struct spi_imx_data *);
@@ -317,8 +317,7 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
{
u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
-
- u32 clk = config->speed_hz, delay;
+ u32 delay;
/*
* The hardware seems to have a race condition when changing modes. The
@@ -330,7 +329,9 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
/* set clock speed */
- ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz, );
+ spi_imx->spi_bus_clk = config->speed_hz;
+ ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz,
+ _imx->spi_bus_clk);
/* set chip select to use */
ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -363,7 +364,7 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
* the SPI communication as the device on the other end would consider
* the change of SCLK polarity as a clock tick already.
*/
- delay = (2 * 100) / clk;
+ delay = (2 * USEC_PER_SEC) / spi_imx->spi_bus_clk;
if (likely(delay < 10)) /* SCLK is faster than 100 kHz */
udelay(delay);
else/* SCLK is _very_ slow */
@@ -889,12 +890,40 @@ static void spi_imx_dma_tx_callback(void *cookie)
complete(_imx->dma_tx_completion);
}
+static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
+{
+ unsigned long coef1 = 1;
+ unsigned long coef2 = MSEC_PER_SEC;
+ unsigned long timeout = 0;
+
+ /* Swap coeficients to avoid div by 0 */
+ if (spi_imx->spi_bus_clk < MSEC_PER_SEC) {
+ coef1 = MSEC_PER_SEC;
+ coef2 = 1;
+ }
+
+ /* Time with actual data transfer */
+ timeout += DIV_ROUND_UP(8 * size * coef1,
+ spi_imx->spi_bus_clk / coef2);
+
+ /* Take CS change delay related to HW */
+ timeout += DIV_ROUND_UP((size - 1) * 4 * coef1,
+ spi_imx->spi_bus_clk / coef2);
+
+ /* Add extra second for scheduler related activities */
+ timeout += MSEC_PER_SEC;
+
+ /* Double calculated timeout */
+ return msecs_to_jiffies(2 * timeout);
+}
+
static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
struct spi_transfer *transfer)
{
struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
int ret;
unsigned long timeout;
+ unsigned long transfer_timeout;
const int left = transfer->len % spi_imx->wml;
struct spi_master *master = spi_imx->bitbang.master;
struct sg_table *tx = >tx_sg, *rx = >rx_sg;
@@ -947,9 +976,11 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
dma_async_issue_pending(master->dma_tx);
spi_imx->devtype_data->trigger(spi_imx);
+ transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
+
/* Wait SDMA to finish the data transfer.*/
timeout = wait_for_completion_timeout(_imx->dma_tx_completion,
- IMX_DMA_TIMEOUT);
+ transfer_timeout);
if (!timeout) {
pr_warn("%s %s: I/O Error in DMA TX\n",
dev_driver_string(>dev),
@@ -957,8 +988,10 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
dmaengine_terminate_all(master->dma_tx);
dmaengine_terminate_all(master->dma_rx);
} else {
+ transfer_timeout = spi_imx_calculate_timeout(spi_imx,
+spi_imx->wml * 2);
timeout = wait_for_completion_timeout(
-
[PATCH v2 5/8] spi: imx: Add support for loopback for ECSPI controllers
Support for ECSPI loopback for IMX51,IMX53 and IMX6Q using TEST register.
Signed-off-by: Mohsin Kazmi
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 41c9cef..4b3c16e 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -265,6 +265,9 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_STAT0x18
#define MX51_ECSPI_STAT_RR (1 << 3)
+#define MX51_ECSPI_TEST0x20
+#define MX51_ECSPI_LOOPBIT(31)
+
/* MX51 eCSPI */
static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
unsigned int *fres)
@@ -338,6 +341,7 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
u32 delay;
+ u32 lpb = 0;
/*
* The hardware seems to have a race condition when changing modes. The
@@ -370,8 +374,12 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
if (config->mode & SPI_CS_HIGH)
cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
+ if (config->mode & SPI_LOOP)
+ lpb |= MX51_ECSPI_LOOP;
+
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG);
+ writel(lpb, spi_imx->base + MX51_ECSPI_TEST);
/*
* Wait until the changes in the configuration register CONFIGREG
@@ -1252,6 +1260,9 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx = spi_master_get_devdata(master);
spi_imx->bitbang.master = master;
+ spi_imx->devtype_data = of_id ? of_id->data :
+ (struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
+
for (i = 0; i < master->num_chipselect; i++) {
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
if (!gpio_is_valid(cs_gpio) && mxc_platform_info)
@@ -1276,12 +1287,13 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->bitbang.master->cleanup = spi_imx_cleanup;
spi_imx->bitbang.master->prepare_message = spi_imx_prepare_message;
spi_imx->bitbang.master->unprepare_message = spi_imx_unprepare_message;
- spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
+ spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA |
+ SPI_CS_HIGH;
- init_completion(_imx->xfer_done);
+ if (is_imx5x_ecspi(spi_imx))
+ spi_imx->bitbang.master->mode_bits |= SPI_LOOP;
- spi_imx->devtype_data = of_id ? of_id->data :
- (struct spi_imx_devtype_data *) pdev->id_entry->driver_data;
+ init_completion(_imx->xfer_done);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
spi_imx->base = devm_ioremap_resource(>dev, res);
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/8] spi: imx: add selection for iMX53 and iMX6 controller type
ECSPI contorller for iMX53 and iMX6 has few hardware issues in slave
mode and (32*n+1) SPI word size handling comparing to iMX51.
The change add possibility to detect the SPI controller is use and apply
workarounds/limitations.
Documentation for device tree bindings updated
Signed-off-by: Anton Bondarenko
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 2 ++
drivers/spi/spi-imx.c | 36 --
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 523341a..425485f 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -9,6 +9,8 @@ Required properties:
- "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
- "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
- "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
+ - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53
+ - "fsl,imx6q-ecspi" for SPI compatible with the one integrated on i.MX6
family
- reg : Offset and length of the register set for the device
- interrupts : Should contain CSPI/eCSPI interrupt
- fsl,spi-num-chipselects : Contains the number of the chipselect
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d9b730d..41c9cef 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -72,7 +72,8 @@ enum spi_imx_devtype {
IMX27_CSPI,
IMX31_CSPI,
IMX35_CSPI, /* CSPI on all i.mx except above */
- IMX51_ECSPI,/* ECSPI on i.mx51 and later */
+ IMX51_ECSPI,/* ECSPI on i.mx51 */
+ IMX53_ECSPI,/* ECSPI on i.mx53 and later */
};
struct spi_imx_data;
@@ -129,9 +130,20 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
return d->devtype_data->devtype == IMX35_CSPI;
}
+static inline int is_imx53_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX53_ECSPI;
+}
+
+static inline int is_imx5x_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX51_ECSPI ||
+ d->devtype_data->devtype == IMX53_ECSPI;
+}
+
static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
{
- return (d->devtype_data->devtype == IMX51_ECSPI) ? 64 : 8;
+ return is_imx5x_ecspi(d) ? 64 : 8;
}
#define MXC_SPI_BUF_RX(type) \
@@ -680,6 +692,16 @@ static struct spi_imx_devtype_data
imx51_ecspi_devtype_data = {
.devtype = IMX51_ECSPI,
};
+static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
+ /* i.mx53 and later ecspi shares the functions with i.mx51 one */
+ .intctrl = mx51_ecspi_intctrl,
+ .config = mx51_ecspi_config,
+ .trigger = mx51_ecspi_trigger,
+ .rx_available = mx51_ecspi_rx_available,
+ .reset = mx51_ecspi_reset,
+ .devtype = IMX53_ECSPI,
+};
+
static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -697,6 +719,12 @@ static const struct platform_device_id spi_imx_devtype[] =
{
.name = "imx35-cspi",
.driver_data = (kernel_ulong_t) _cspi_devtype_data,
}, {
+ .name = "imx53-ecspi",
+ .driver_data = (kernel_ulong_t)_ecspi_devtype_data,
+ }, {
+ .name = "imx6q-ecspi",
+ .driver_data = (kernel_ulong_t)_ecspi_devtype_data,
+ }, {
.name = "imx51-ecspi",
.driver_data = (kernel_ulong_t) _ecspi_devtype_data,
}, {
@@ -710,6 +738,8 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx27-cspi", .data = _cspi_devtype_data, },
{ .compatible = "fsl,imx31-cspi", .data = _cspi_devtype_data, },
{ .compatible = "fsl,imx35-cspi", .data = _cspi_devtype_data, },
+ { .compatible = "fsl,imx53-ecspi", .data = _ecspi_devtype_data, },
+ { .compatible = "fsl,imx6q-ecspi", .data = _ecspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = _ecspi_devtype_data, },
{ /* sentinel */ }
};
@@ -1299,7 +1329,7 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx6 now, can remove the constrain if validated on
* other chips.
*/
- if (spi_imx->devtype_data == _ecspi_devtype_data &&
+ if (is_imx5x_ecspi(spi_imx) &&
spi_imx_sdma_init(>dev, spi_imx, master))
dev_err(>dev, "dma setup error,use pio instead\n");
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] ns: introduce proc_get_ns_by_fd()
On 09/25, Konstantin Khlebnikov wrote:
>
> +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
> {
> - struct file *file;
> + struct ns_common *ns;
> + struct fd f;
>
> - file = fget(fd);
> - if (!file)
> + f = fdget(fd);
> + if (!f.file)
> return ERR_PTR(-EBADF);
>
> - if (file->f_op != _file_operations)
> + if (f.file->f_op != _file_operations)
> + goto out_invalid;
> +
> + ns = get_proc_ns(file_inode(f.file));
> + if (nstype && (ns->ops->type != nstype))
> goto out_invalid;
>
> - return file;
> + *fd_ref = f;
> + return ns;
>
> out_invalid:
> - fput(file);
> + fdput(f);
> return ERR_PTR(-EINVAL);
> }
Well yes, fdget() makes sense but this is minor.
Honestly, I do not really like the new helper... I understand this
is subjective, so I won't insist. But how about 1/1? We do not need
fd/file at all. With this patch your sys_getvpid() can just use
proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().
Eric, what do you think?
See also "TODO" in the changelog.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/8] spi: imx: defer spi initialization, if DMA engine is pending
If SPI device supports DMA mode, but DMA controller is not yet
available due to e.g. a delay in the corresponding kernel module
initialization, retry to initialize SPI driver later on instead of
falling back into PIO only mode.
Signed-off-by: Vladimir Zapolskiy
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 44d3cf0..1bf0739a 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1343,9 +1343,15 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx6 now, can remove the constrain if validated on
* other chips.
*/
- if (is_imx5x_ecspi(spi_imx) &&
- spi_imx_sdma_init(>dev, spi_imx, master))
- dev_err(>dev, "dma setup error,use pio instead\n");
+ if (is_imx5x_ecspi(spi_imx)) {
+ ret = spi_imx_sdma_init(>dev, spi_imx, master);
+ if (ret == -EPROBE_DEFER)
+ goto out_clk_put;
+
+ if (ret < 0)
+ dev_err(>dev, "dma setup error %d, use pio\n",
+ ret);
+ }
spi_imx->devtype_data->reset(spi_imx);
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ns: introduce proc_get_ns_by_fd()
Introduce proc_get_ns_by_fd() so that get_net_ns_by_fd() becomes
one-liner. It will have another CLONE_NEWPID user soon.
TODO: proc_get_ns_by_fd() can share some code with proc_ns_fget().
Signed-off-by: Oleg Nesterov
---
fs/nsfs.c| 24
include/linux/proc_ns.h |3 +++
kernel/pid_namespace.c |6 ++
net/core/net_namespace.c | 23 +++
4 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/fs/nsfs.c b/fs/nsfs.c
index 99521e7..72474ca 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -136,6 +136,30 @@ out_invalid:
return ERR_PTR(-EINVAL);
}
+void *proc_get_ns_by_fd(int fd, int type)
+{
+ struct fd f;
+ struct ns_common *ns;
+ void *ret;
+
+ f = fdget(fd);
+ if (!f.file)
+ return ERR_PTR(-EBADF);
+
+ ret = ERR_PTR(-EINVAL);
+ if (f.file->f_op != _file_operations)
+ goto put;
+
+ ns = get_proc_ns(file_inode(f.file));
+ if (ns->ops->type != type || !ns->ops->get_type)
+ goto put;
+
+ ret = ns->ops->get_type(ns);
+put:
+ fdput(f);
+ return ret;
+}
+
static const struct super_operations nsfs_ops = {
.statfs = simple_statfs,
.evict_inode = nsfs_evict,
diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h
index 42dfc61..d956f89 100644
--- a/include/linux/proc_ns.h
+++ b/include/linux/proc_ns.h
@@ -16,6 +16,7 @@ struct proc_ns_operations {
struct ns_common *(*get)(struct task_struct *task);
void (*put)(struct ns_common *ns);
int (*install)(struct nsproxy *nsproxy, struct ns_common *ns);
+ void *(*get_type)(struct ns_common *ns);
};
extern const struct proc_ns_operations netns_operations;
@@ -66,6 +67,8 @@ static inline int ns_alloc_inum(struct ns_common *ns)
#define ns_free_inum(ns) proc_free_inum((ns)->inum)
extern struct file *proc_ns_fget(int fd);
+extern void *proc_get_ns_by_fd(int fd, int type);
+
#define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
extern void *ns_get_path(struct path *path, struct task_struct *task,
const struct proc_ns_operations *ns_ops);
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index a65ba13..0c87393 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -388,12 +388,18 @@ static int pidns_install(struct nsproxy *nsproxy, struct
ns_common *ns)
return 0;
}
+static void *pidns_get_type(struct ns_common *ns)
+{
+ return get_pid_ns(to_pid_ns(ns));
+}
+
const struct proc_ns_operations pidns_operations = {
.name = "pid",
.type = CLONE_NEWPID,
.get= pidns_get,
.put= pidns_put,
.install= pidns_install,
+ .get_type = pidns_get_type,
};
static __init int pid_namespaces_init(void)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 572af00..6465dc0 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -420,22 +420,7 @@ EXPORT_SYMBOL_GPL(__put_net);
struct net *get_net_ns_by_fd(int fd)
{
- struct file *file;
- struct ns_common *ns;
- struct net *net;
-
- file = proc_ns_fget(fd);
- if (IS_ERR(file))
- return ERR_CAST(file);
-
- ns = get_proc_ns(file_inode(file));
- if (ns->ops == _operations)
- net = get_net(container_of(ns, struct net, ns));
- else
- net = ERR_PTR(-EINVAL);
-
- fput(file);
- return net;
+ return proc_get_ns_by_fd(fd, CLONE_NEWNET);
}
#else
@@ -955,11 +940,17 @@ static int netns_install(struct nsproxy *nsproxy, struct
ns_common *ns)
return 0;
}
+static void *netns_get_type(struct ns_common *ns)
+{
+ return get_net(to_net_ns(ns));
+}
+
const struct proc_ns_operations netns_operations = {
.name = "net",
.type = CLONE_NEWNET,
.get= netns_get,
.put= netns_put,
.install= netns_install,
+ .get_type = netns_get_type,
};
#endif
--
1.5.5.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 v2 8/8] spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips
Currently i.MX SPI controller only works in Master mode.
This patch adds support to work also in Slave mode by adding
"fsl,spi-slave-mode" in corresponding ecspi node in devicetree.
Currently SPI Slave mode support patch has the following limitations:
1. The stale data in RXFIFO will be dropped when the Slave does any new
transfer.
2. One transfer can be finished only after all transfer->len data been
transferred to master device
3. Slave device only accepts transfer->len data. Any data longer than this
from master device will be dropped. Any data shorter than this from
master will cause SPI to stuck du to mentioned HW limitation 2.
Following HW limitation applies:
1. ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes
2. Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
Select (SS) signal in Slave mode is not functional" burst size must
be set exactly to the size of the transfer. This limit SPI transaction
with maximum 2^12 bits.
Signed-off-by: Jiada Wang
Signed-off-by: Muzaffar Mahmood
Signed-off-by: Anton Bondarenko
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 1 +
drivers/spi/spi-imx.c | 169 ++---
2 files changed, 146 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 425485f..ffe28f2 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -15,6 +15,7 @@ Required properties:
- interrupts : Should contain CSPI/eCSPI interrupt
- fsl,spi-num-chipselects : Contains the number of the chipselect
- cs-gpios : Specifies the gpio pins to be used for chipselects.
+- fsl,spi-slave-mode : Indicate the spi controller works in Slave mode.
- clocks : Clock specifiers for both ipg and per clocks.
- clock-names : Clock names should include both "ipg" and "per"
See the clock consumer binding,
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 1bf0739a..f271d1e 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -55,6 +55,7 @@
/* generic defines to abstract from the different register layouts */
#define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
#define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_RDRBIT(4) /* Receive date threshold interrupt */
#define MXC_INT_TCEN BIT(7) /* Transfer complete */
/* The maximum bytes that a sdma BD can transfer.*/
@@ -84,6 +85,7 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ void (*disable)(struct spi_imx_data *);
enum spi_imx_devtype devtype;
};
@@ -108,6 +110,10 @@ struct spi_imx_data {
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+ unsigned int slave_mode;
+ unsigned int slave_burst;
+ unsigned int total_count;
+
/* DMA */
unsigned int dma_is_inited;
unsigned int dma_finished;
@@ -248,6 +254,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_INT 0x10
#define MX51_ECSPI_INT_TEEN(1 << 0)
#define MX51_ECSPI_INT_RREN(1 << 3)
+#define MX51_ECSPI_INT_RDREN BIT(4)
#define MX51_ECSPI_INT_TCENBIT(7)
#define MX51_ECSPI_DMA 0x14
@@ -268,6 +275,52 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_TEST0x20
#define MX51_ECSPI_LOOPBIT(31)
+static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+
+ if (spi_imx->rx_buf) {
+ int shift = spi_imx->slave_burst % sizeof(val);
+
+ if (shift) {
+ memcpy(spi_imx->rx_buf,
+ ((u8 *)) + sizeof(val) - shift, shift);
+ } else {
+ *((u32 *)spi_imx->rx_buf) = val;
+ shift = sizeof(val);
+ }
+
+ spi_imx->rx_buf += shift;
+ spi_imx->slave_burst -= shift;
+ }
+}
+
+static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = 0;
+ int shift = spi_imx->count % sizeof(val);
+
+ if (spi_imx->tx_buf) {
+ if (shift) {
+ memcpy(((u8 *)) + sizeof(val) - shift,
+ spi_imx->tx_buf, shift);
+ } else {
+ val = *((u32 *)spi_imx->tx_buf);
+
[PATCH v2 6/8] spi: imx: return error from dma channel request
On SDMA initialization return exactly the same error, which is
reported by dma_request_slave_channel_reason(), it is a preceding
change to defer SPI DMA initialization, if SDMA module is not yet
available.
Signed-off-by: Vladimir Zapolskiy
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4b3c16e..44d3cf0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -929,18 +929,20 @@ static int spi_imx_sdma_init(struct device *dev, struct
spi_imx_data *spi_imx,
spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
/* Prepare for TX DMA: */
- master->dma_tx = dma_request_slave_channel(dev, "tx");
- if (!master->dma_tx) {
- dev_err(dev, "cannot get the TX DMA channel!\n");
- ret = -EINVAL;
+ master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
+ if (IS_ERR(master->dma_tx)) {
+ dev_info(dev, "cannot get the TX DMA channel!\n");
+ ret = PTR_ERR(master->dma_tx);
+ master->dma_tx = NULL;
goto err;
}
/* Prepare for RX : */
- master->dma_rx = dma_request_slave_channel(dev, "rx");
- if (!master->dma_rx) {
- dev_dbg(dev, "cannot get the DMA channel.\n");
- ret = -EINVAL;
+ master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
+ if (IS_ERR(master->dma_rx)) {
+ dev_info(dev, "cannot get the DMA channel.\n");
+ ret = PTR_ERR(master->dma_rx);
+ master->dma_rx = NULL;
goto err;
}
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/8] spi: imx: Fix DMA transfer
RX DMA tail data handling doesn't work correctly in many cases with
current implementation. It happens because SPI core was setup
to generates both RX watermark level and RX DATA TAIL events
incorrectly. SPI transfer triggering for DMA also done in wrong way.
SPI client wants to transfer 70 words for example. The old DMA
implementation setup RX DATA TAIL equal 6 words. In this case
RX DMA event will be generated after 6 words read from RX FIFO.
The garbage can be read out from RX FIFO because SPI HW does
not receive all required words to trigger RX watermark event.
New implementation change handling of RX data tail. DMA is used to process
all TX data and only full chunks of RX data with size aligned to FIFO/2.
Driver is waiting until both TX and RX DMA transaction done and all
TX data are pushed out. At that moment there is only RX data tail in
the RX FIFO. This data read out using PIO.
Transfer triggering changed to avoid RX data loss.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 105 +++---
1 file changed, 66 insertions(+), 39 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index f9deb84..165bc2c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -39,6 +39,8 @@
#include
#include
+#include
+
#include
#include
@@ -53,6 +55,7 @@
/* generic defines to abstract from the different register layouts */
#define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
#define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_TCEN BIT(7) /* Transfer complete */
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
@@ -104,9 +107,7 @@ struct spi_imx_data {
unsigned int dma_is_inited;
unsigned int dma_finished;
bool usedma;
- u32 rx_wml;
- u32 tx_wml;
- u32 rxt_wml;
+ u32 wml;
struct completion dma_rx_completion;
struct completion dma_tx_completion;
@@ -201,9 +202,8 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
- if (spi_imx->dma_is_inited
- && transfer->len > spi_imx->rx_wml * sizeof(u32)
- && transfer->len > spi_imx->tx_wml * sizeof(u32))
+ if (spi_imx->dma_is_inited &&
+ (transfer->len > spi_imx->wml * sizeof(u32)))
return true;
return false;
}
@@ -228,6 +228,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_INT 0x10
#define MX51_ECSPI_INT_TEEN(1 << 0)
#define MX51_ECSPI_INT_RREN(1 << 3)
+#define MX51_ECSPI_INT_TCENBIT(7)
#define MX51_ECSPI_DMA 0x14
#define MX51_ECSPI_DMA_TX_WML_OFFSET 0
@@ -292,6 +293,9 @@ static void __maybe_unused mx51_ecspi_intctrl(struct
spi_imx_data *spi_imx, int
if (enable & MXC_INT_RR)
val |= MX51_ECSPI_INT_RREN;
+ if (enable & MXC_INT_TCEN)
+ val |= MX51_ECSPI_INT_TCEN;
+
writel(val, spi_imx->base + MX51_ECSPI_INT);
}
@@ -311,8 +315,9 @@ static void __maybe_unused mx51_ecspi_trigger(struct
spi_imx_data *spi_imx)
static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
struct spi_imx_config *config)
{
- u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
- u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+ u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
+ u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
+
u32 clk = config->speed_hz, delay;
/*
@@ -369,19 +374,10 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
* and enable DMA request.
*/
if (spi_imx->dma_is_inited) {
- dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
- spi_imx->rxt_wml = spi_imx_get_fifosize(spi_imx) / 2;
- rx_wml_cfg = spi_imx->rx_wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
- tx_wml_cfg = spi_imx->tx_wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
- rxt_wml_cfg = spi_imx->rxt_wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
- dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
- & ~MX51_ECSPI_DMA_RX_WML_MASK
- & ~MX51_ECSPI_DMA_RXT_WML_MASK)
- | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
- |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
- |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
- |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
+ dma = (spi_imx->wml - 1) << MX51_ECSPI_DMA_RX_WML_OFFSET
+ | (spi_imx->wml - 1) << MX51_ECSPI_DMA_TX_WML_OFFSET
+ | (1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
+ | (1 << MX51_ECSPI_DMA_RXDEN_OFFSET);
writel(dma, spi_imx->base +
[PATCH v2 3/8] spi: imx: add support for all SPI word width for DMA transfer
DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support other BPW supported by HW.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 121 --
1 file changed, 87 insertions(+), 34 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6c98eda..d9b730d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -91,11 +91,15 @@ struct spi_imx_data {
struct completion xfer_done;
void __iomem *base;
+ unsigned long base_phys;
+
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
unsigned int spi_bus_clk;
+ unsigned int bpw_w;
+
unsigned int count;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
@@ -201,9 +205,13 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *transfer)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+ unsigned int bpw_w = transfer->bits_per_word;
- if (spi_imx->dma_is_inited &&
- (transfer->len > spi_imx->wml * sizeof(u32)))
+ if (!bpw_w)
+ bpw_w = spi->bits_per_word;
+
+ bpw_w = DIV_ROUND_UP(bpw_w, 8);
+ if (spi_imx->dma_is_inited && (transfer->len > spi_imx->wml * bpw_w))
return true;
return false;
}
@@ -761,11 +769,62 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int spi_imx_sdma_configure(struct spi_master *master)
+{
+ int ret;
+ enum dma_slave_buswidth dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ struct dma_slave_config slave_config = {};
+ struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+ switch (spi_imx->bpw_w) {
+ case 4:
+ dsb_default = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ break;
+ case 2:
+ dsb_default = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ break;
+ case 1:
+ dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ break;
+ default:
+ pr_err("Not supported word size %d\n", spi_imx->bpw_w);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ slave_config.direction = DMA_MEM_TO_DEV;
+ slave_config.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+ slave_config.dst_addr_width = dsb_default;
+ slave_config.dst_maxburst = spi_imx_get_fifosize(spi_imx)
+ - spi_imx->wml;
+ ret = dmaengine_slave_config(master->dma_tx, _config);
+ if (ret) {
+ pr_err("error in TX dma configuration.\n");
+ goto err;
+ }
+
+ memset(_config, 0, sizeof(slave_config));
+
+ slave_config.direction = DMA_DEV_TO_MEM;
+ slave_config.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+ slave_config.src_addr_width = dsb_default;
+ slave_config.src_maxburst = spi_imx_get_fifosize(spi_imx)
+ - spi_imx->wml;
+ ret = dmaengine_slave_config(master->dma_rx, _config);
+ if (ret)
+ pr_err("error in RX dma configuration.\n");
+
+err:
+ return ret;
+}
+
static int spi_imx_setupxfer(struct spi_device *spi,
struct spi_transfer *t)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
struct spi_imx_config config;
+ unsigned int bpw_w_new;
+ int ret = 0;
config.bpw = t ? t->bits_per_word : spi->bits_per_word;
config.speed_hz = t ? t->speed_hz : spi->max_speed_hz;
@@ -789,9 +848,18 @@ static int spi_imx_setupxfer(struct spi_device *spi,
spi_imx->tx = spi_imx_buf_tx_u32;
}
- spi_imx->devtype_data->config(spi_imx, );
+ bpw_w_new = DIV_ROUND_UP(config.bpw, 8);
+ if (spi_imx->dma_is_inited && spi_imx->bpw_w != bpw_w_new) {
+ spi_imx->bpw_w = bpw_w_new;
+ ret = spi_imx_sdma_configure(spi->master);
+ if (ret != 0)
+ pr_err("Can't configure SDMA, error %d\n", ret);
+ }
- return 0;
+ if (!ret)
+ ret = spi_imx->devtype_data->config(spi_imx, );
+
+ return ret;
}
static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
@@ -812,10 +880,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
}
static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-struct spi_master *master,
-const struct resource *res)
+struct spi_master *master)
{
- struct dma_slave_config slave_config = {};
int ret;
/* use pio mode for i.mx6dl chip TKT238285 */
@@ -832,17 +898,6 @@ static int
[PATCH v2 0/8] Improvements for SPI IMX driver for Freescale IMX53 and IMX6 families
A number of patches to impove or add the implementation for the spi-imx driver related to Freescale IMX53 and IMX6. It would also possible some of patches can be applied for other Freescale controllers using spi-imx driver but could not be tested due to lack of hardware. Anton Bondarenko (8): spi: imx: Fix DMA transfer spi: imx: replace fixed timeout with calculated one spi: imx: add support for all SPI word width for DMA transfer spi: imx: add selection for iMX53 and iMX6 controller type spi: imx: Add support for loopback for ECSPI controllers spi: imx: return error from dma channel request spi: imx: defer spi initialization, if DMA engine is pending spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips .../devicetree/bindings/spi/fsl-imx-cspi.txt | 3 + drivers/spi/spi-imx.c | 486 - 2 files changed, 388 insertions(+), 101 deletions(-) -- 2.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting
Seth Forshee writes: > On Fri, Sep 25, 2015 at 12:16:59PM -0500, Eric W. Biederman wrote: >> >> Argh. This looks like morning person meets night owl. > > Indded :-) > >> Seth Forshee writes: >> >> > On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote: >> >> Seth Forshee writes: >> >> >> >> > When mounting a filesystem on a block device there is currently >> >> > no verification that the user has appropriate access to the >> >> > device file passed to mount. This has not been an issue so far >> >> > since the user in question has always been root, but this must >> >> > be changed before allowing unprivileged users to mount in user >> >> > namespaces. >> >> > >> >> > To do this, a new version of lookup_bdev() is added named >> >> > lookup_bdev_perm(). Both of these functions become wrappers >> >> > around a common inner fucntion. The behavior of lookup_bdev() is >> >> > unchanged, but calling lookup_bdev_perm() will fail if the user >> >> > does not have the specified access rights to the supplied path. >> >> > The permission check is skipped if the user has CAP_SYS_ADMIN to >> >> > avoid any possible regressions in behavior. >> >> > >> >> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This >> >> > is used by mount_bdev() and mount_mtd(), so this will cause >> >> > mounts on block devices to fail when the user lacks the required >> >> > permissions. Other calls to blkdev_get_by_path() will all happen >> >> > with root privileges, so these calls will be unaffected. >> >> >> >> Good but buggy patch. >> >> >> >> In the mtd bits the flags are super flags, not file mode bits, >> >> which makes testing them against FMODE_READ and FMODE_WRITE is >> >> incorrect. >> > >> > Bah, yes. Fixed. >> > >> >> Further it looks like quite a few more possibly all of the lookup_bdev >> >> instances could use inode level permission checking. >> >> >> >> Certainly code such as quotactl makes me wonder. >> > >> > I opted to stick to places related to mounting, but let's take a look at >> > the other callers. >> > >> > bcache calls it in the context of sysfs writes, and those attributes are >> > writable only by root. In that case the inode permission check will be >> > skipped anyway, so it makes no difference either way. >> > >> > Device mapper calls it in dm_get_device, which is called from a bunch of >> > places. I had started trying to walk back through all the callers of >> > dm_get_device, but that rabbit hole got really deep really quickly so I >> > didn't feel confident that changing it wouldn't break anyone. >> > >> > quotactl gave me pause, as it seems to have done for you too. I was >> > surprised that inode permissions aren't checked, but >> > check_quotactl_permission does get called before actually doing >> > anything. I fear that adding a check of inode permissions could end up >> > breaking someone. >> >> My gut feel on all of this is that we should act like may_open and have >> have a flag of 0 for access mode mean don't check permissions. >> >> That way we can change all of the callers of lookup_bdev to pass an >> additional argument and make it explicit what is going on but we don't >> actually have to change the callers to actually perform an additional >> check. > > Sounds reasonable, I'll make that change. > >> Leaving stones unturned is a good way to introduce a security hole by >> accident so I don't want to leave dm_get_device unreviewed, but any >> changes can be in later patches. > > Unless I've made a mistake it shouldn't introduce security holes, > dm_get_device should behave exactly the same was as it behaves today. > Any security problems would already be present. *Nod* There are two parts to this. Splitting this into changes that are small enough to be correct. And just passing in a 0 for acc_mode seems good enough in that case. The other question is what happens when we start allowing unprivileged users to mount things, and in general what happens when we start relaxing permission checks. Frankly we need to understand how everything interacts if we are to relax permissions safely if we don't want to be chasing security issues for the next several years as things come to lite that we have overlooked. > I can take another crack at reviewing, but it might also be good if > someone who already knows the code commented as well. As I recall I gave > up after getting several levels deep in indirect function calls where the > names of the struct members which held the function pointers were > identical at a couple of levels, so I was having a hard time knowing if > I was keeping everything straight. For this patch I am not concerned but we do need to understand how all of the pieces interact and that is just plain challenging. Eric -- 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
Re: fuse scalability part 1
On 09/25/2015 05:11 AM, Miklos Szeredi wrote: On Thu, Sep 24, 2015 at 9:17 PM, Ashish Samant wrote: We did some performance testing without these patches and with these patches (with -o clone_fd option specified). We did 2 types of tests: 1. Throughput test : We did some parallel dd tests to read/write to FUSE based database fs on a system with 8 numa nodes and 288 cpus. The performance here is almost equal to the the per-numa patches we submitted a while back.Please find results attached. Interesting. This means, that serving the request on a different NUMA node as the one where the request originated doesn't appear to make the performance much worse. Thanks, Miklos Yes. The main performance gain is due to the reduced contention on one spinlock(fc->lock) , especially with a large number of requests. Splitting fc->fiq per cloned device will definitely improve performance further and we can experiment further with per numa / cpu cloned device. Thanks, Ashish -- 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] sched/fair: Skip wake_affine() for core siblings
We are not interested in actual target if both prev and curr cpus share CPU cache. select_idle_sibling() searches in top-down order; top level is the same for both of them, and the result will be the same. So, we can save a little CPU cycles and cache misses and skip wake_affine() calculations. tbench on 2 physical CPU Xeon (x 6 cores x 2 ht) inside cgroup: threads | Before | After --- 1 | 203.943 MB/sec | 211.524 MB/sec 2 | 407.211 MB/sec | 411.701 MB/sec 3 | 591.089 MB/sec | 608.404 MB/sec 4 | 743.768 MB/sec | 790.026 MB/sec (+ 6.2%) 5 | 914.237 MB/sec | 972.882 MB/sec (+ 6.4%) 6 | 1053.91 MB/sec | 1092.81 MB/sec 7 | 1208.24 MB/sec | 1281.1 MB/sec (+ 6.0%) 8 | 1357.53 MB/sec | 1385.79 MB/sec 9 | 1474.11 MB/sec | 1496.76 MB/sec 10 | 1586.89 MB/sec | 1616.76 MB/sec 11 | 1720.17 MB/sec | 1732.7 MB/sec 12 | 1835.4 MB/sec | 1868.77 MB/sec 13 | 1964.76 MB/sec | 2003.68 MB/sec 14 | 2117.01 MB/sec | 2128.16 MB/sec 15 | 2220.97 MB/sec | 2254.8 MB/sec 16 | 2326.52 MB/sec | 2378.38 MB/sec 17 | 2458.79 MB/sec | 2484.15 MB/sec 18 | 2473.59 MB/sec | 2591.01 MB/sec (+ 4.7%) Signed-off-by: Kirill Tkhai --- kernel/sched/fair.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 4df37a4..b378c34 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4666,6 +4666,9 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync) unsigned long weight; int balanced; + if (sd->flags & SD_SHARE_PKG_RESOURCES) + return 1; + idx = sd->wake_idx; this_cpu = smp_processor_id(); prev_cpu = task_cpu(p); -- 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] arm64: Add support for PTE contiguous bit.
On 21 September 2015 at 09:44, David Woods wrote: > > Steve, Hi Dave, > > Thanks for your review and comments. I take your points about the 16k > granule - it's helpful to know that support is in the works. However, I'm > not sure I agree with your reading of section 4.4.2. It's clear that for 16k > granules, the number of contiguous pages is different for the PTE and PMD > levels. But I don't see anywhere it says that for 4K and 64K that the > contig bit is not supported at the PMD level - just that the number of > contiguous pages is the same at each level. Many apologies, I appear to have led you down the garden path there. Having double checked at ARM, the valid contiguous page sizes are indeed: 4K granule: 16 x ptes = 64K 16 x pmds = 32M 16 x puds = 16G 16K granule: 128 x ptes = 2M 32 x pmds = 1G 64K granule: 32 x ptes = 2M 32 x pmds = 16G > > I tried using the tarmac trace module of the ARM simulator to support this > idea by turning on MMU tracing. Using 4k granule, I created 64k and 32m > pages and touched each location in the page. In both cases, the trace > recorded just one TLB fill (rather than the 16 you'd expect if the > contiguous bit were being ignored) and it indicated the expected page size. > > 1817498494 clk cpu2 TLB FILL cpu2.S1TLB 64K 0x20_NS vmid=0, nG > asid=303:0x08fa36_NS Normal InnerShareable Inner=WriteBackWriteAllocate > Outer=WriteBackWriteAllocate xn=0 pxn=1 ContiguousHint=1 > > 1263366314 clk cpu2 TLB FILL cpu2.UTLB 32M 0x20_NS vmid=0, nG > asid=300:0x08f600_NS Normal InnerShareable Inner=WriteBackWriteAllocate > Outer=WriteBackWriteAllocate xn=0 pxn=1 ContiguousHint=1 > > I'll try this with a 64k granule next. I'm not sure what will happen with > 16G pages since we are using an A53 model which I don't think supports such > large pages. The Cortex-A53 supported TLB sizes can be found in the TRM: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500f/Chddiifa.html My understanding is that the core is allowed to ignore the contiguous bit if it doesn't support the particular TLB entry size, or substitute in a slightly smaller TLB entry than hinted possible. Anyway, do give it a go :-). Cheers, -- Steve -- 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/
Applied "regmap: Add generic macro to define regmap_irq" to the regmap tree
The patch
regmap: Add generic macro to define regmap_irq
has been applied to the regmap tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b4fe8ba7a310da6a2b99e3abe67c7815198cde49 Mon Sep 17 00:00:00 2001
From: Qipeng Zha
Date: Tue, 15 Sep 2015 00:39:17 +0800
Subject: [PATCH] regmap: Add generic macro to define regmap_irq
Add REGMAP_IRQ_REG macro in regmap.h to define regmap_irq
structure easily for other driver module.
Signed-off-by: Qipeng Zha
Acked-by: Mark Brown
Signed-off-by: Lee Jones
---
include/linux/regmap.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 8fc0bfd..f622697 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -791,6 +791,9 @@ struct regmap_irq {
unsigned int mask;
};
+#define REGMAP_IRQ_REG(_irq, _off, _mask) \
+ [_irq] = { .reg_offset = (_off), .mask = (_mask) }
+
/**
* Description of a generic regmap irq_chip. This is not intended to
* handle every possible interrupt controller, but it should handle a
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] EDAC: Fix sysfs dimm_label store operation
On Thu, Sep 24, 2015 at 01:59:27PM -0600, Toshi Kani wrote: > On Thu, 2015-09-24 at 21:15 +0200, Borislav Petkov wrote: > > On Thu, Sep 24, 2015 at 01:06:04PM -0600, Toshi Kani wrote: > > > edac-utils(1) checks empty labels and shows them as "ch%d" [1]. So, > > > I think empty labels are supported today, and using 'echo "" >' seems > > > to be a legitimate way to set them empty if desired. > > > > What would be a sane use case to set a DIMM label to an empty string? > > Well, I guess there isn't a sane use case for it... :-) > > Attached is a patch (on top of patch 2/2) to disallow an empty string. > I prefer to make it as a separate patch in case someone comes up with > a valid use-case for it. > > Thanks, > -Toshi > > > Subject: [PATCH] EDAC: Fail empty string to sysfs dimm_label store > > Updating dimm_label to an empty string does not make much sense. > Change the sysfs dimm_label store option to fail a request when > an input string is empty. > > Suggested-by: Borislav Petkov > Signed-off-by: Toshi Kani > --- > drivers/edac/edac_mc_sysfs.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) All three applied. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- 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 2/7] tools build: Add test for missing include
Em Wed, Sep 23, 2015 at 12:33:57PM +0200, Jiri Olsa escreveu:
> The current build framework fails to cope with header file
> removal. The reason is the removed header file stays in the
> .cmd file target rule and force the build to fail.
So, where is this test hooked up, is the way to test this to do:
cd tools/build/tests/
./run.sh
less ex.out
?
> This issue is fixed and explained in following patches.
>
> Adding new build test that simulates header removal.
>
> Link: http://lkml.kernel.org/n/tip-580lv21jts6t9j15cosxg...@git.kernel.org
> Signed-off-by: Jiri Olsa
> ---
> tools/build/tests/ex/Build| 1 +
> tools/build/tests/ex/Makefile | 2 +-
> tools/build/tests/ex/ex.c | 2 ++
> tools/build/tests/ex/inc.c| 8
> tools/build/tests/run.sh | 27 +++
> 5 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100644 tools/build/tests/ex/inc.c
>
> diff --git a/tools/build/tests/ex/Build b/tools/build/tests/ex/Build
> index 429c7d452101..4d502f9b1a50 100644
> --- a/tools/build/tests/ex/Build
> +++ b/tools/build/tests/ex/Build
> @@ -4,6 +4,7 @@ ex-y += b.o
> ex-y += b.o
> ex-y += empty/
> ex-y += empty2/
> +ex-y += inc.o
>
> libex-y += c.o
> libex-y += d.o
> diff --git a/tools/build/tests/ex/Makefile b/tools/build/tests/ex/Makefile
> index a8f596e37fd2..f279b84cb859 100644
> --- a/tools/build/tests/ex/Makefile
> +++ b/tools/build/tests/ex/Makefile
> @@ -1,4 +1,4 @@
> -export srctree := ../../../..
> +export srctree := $(abspath ../../../..)
> export CC := gcc
> export LD := ld
> export AR := ar
> diff --git a/tools/build/tests/ex/ex.c b/tools/build/tests/ex/ex.c
> index dc42eb2e1a67..57de6074d252 100644
> --- a/tools/build/tests/ex/ex.c
> +++ b/tools/build/tests/ex/ex.c
> @@ -5,6 +5,7 @@ int c(void);
> int d(void);
> int e(void);
> int f(void);
> +int inc(void);
>
> int main(void)
> {
> @@ -14,6 +15,7 @@ int main(void)
> d();
> e();
> f();
> + inc();
>
> return 0;
> }
> diff --git a/tools/build/tests/ex/inc.c b/tools/build/tests/ex/inc.c
> new file mode 100644
> index ..c20f1e9033a3
> --- /dev/null
> +++ b/tools/build/tests/ex/inc.c
> @@ -0,0 +1,8 @@
> +#ifdef INCLUDE
> +#include "krava.h"
> +#endif
> +
> +int inc(void)
> +{
> + return 0;
> +}
> diff --git a/tools/build/tests/run.sh b/tools/build/tests/run.sh
> index 5494f8ea7567..44d2a0fade67 100755
> --- a/tools/build/tests/run.sh
> +++ b/tools/build/tests/run.sh
> @@ -34,9 +34,36 @@ function test_ex_suffix {
> make -C ex V=1 clean > /dev/null 2>&1
> rm -f ex.out
> }
> +
> +function test_ex_include {
> + make -C ex V=1 clean > ex.out 2>&1
> +
> + # build with krava.h include
> + touch ex/krava.h
> + make -C ex V=1 CFLAGS=-DINCLUDE >> ex.out 2>&1
> +
> + if [ ! -x ./ex/ex ]; then
> + echo FAILED
> + exit -1
> + fi
> +
> + # build without the include
> + rm -f ex/krava.h ex/ex
> + make -C ex V=1 >> ex.out 2>&1
> +
> + if [ ! -x ./ex/ex ]; then
> + echo FAILED
> + exit -1
> + fi
> +
> + make -C ex V=1 clean > /dev/null 2>&1
> + rm -f ex.out
> +}
> +
> echo -n Testing..
>
> test_ex
> test_ex_suffix
> +test_ex_include
>
> echo OK
> --
> 2.4.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] lib/vsprintf.c: also improve sanity check in bstr_printf()
Quoting from 2aa2f9e21e4e ("lib/vsprintf.c: improve sanity check in
vsnprintf()"):
On 64 bit, size may very well be huge even if bit 31 happens to be 0.
Somehow it doesn't feel right that one can pass a 5 GiB buffer but not a
3 GiB one. So cap at INT_MAX as was probably the intention all along.
This is also the made-up value passed by sprintf and vsprintf.
I should have seen this copy-pasted instance back then, but let's just
do it now.
Signed-off-by: Rasmus Villemoes
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index f2590a80937f..03fa10b4be96 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2294,7 +2294,7 @@ int bstr_printf(char *buf, size_t size, const char *fmt,
const u32 *bin_buf)
char *str, *end;
const char *args = (const char *)bin_buf;
- if (WARN_ON_ONCE((int) size < 0))
+ if (WARN_ON_ONCE(size > INT_MAX))
return 0;
str = buf;
--
2.1.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 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote: > Signed-off-by: Viresh Kumar > --- > V3->V4: > - Create a local variable instead of changing type of global_lock > (Rafael) Err, surely that wasn't what Rafael meant, since it's clearly impossible to use a pointer to the stack, assign to it once, and the expect anything to wkr at all ... johannes -- 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] lib/vsprintf.c: handle invalid format specifiers more robustly
If we meet any invalid or unsupported format specifier, 'handling' it
by just printing it as a literal string is not safe: Presumably the
format string and the arguments passed gcc's type checking, but that
means something like sprintf(buf, "%n %pd", , dentry) would end
up interpreting as a struct dentry*.
When the offending specifier was %n it used to be at the end of the
format string, but we can't rely on that always being the case. Also,
gcc doesn't complain about some more or less exotic qualifiers (or
'length modifiers' in posix-speak) such as 'j' or 'q', but being
unrecognized by the kernel's printf implementation, they'd be
interpreted as unknown specifiers, and the rest of arguments would be
interpreted wrongly.
So let's complain about anything we don't understand, not just %n, and
stop pretending that we'd be able to make sense of the rest of the
format/arguments. If the offending specifier is in a printk() call we
unfortunately only get a "BUG: recent printk recursion!", but at least
direct users of the sprintf family will be caught.
Signed-off-by: Rasmus Villemoes
---
lib/vsprintf.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 95cd63b43b99..f2590a80937f 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1769,14 +1769,14 @@ qualifier:
case 'n':
/*
-* Since %n poses a greater security risk than utility, treat
-* it as an invalid format specifier. Warn about its use so
-* that new instances don't get added.
+* Since %n poses a greater security risk than
+* utility, treat it as any other invalid or
+* unsupported format specifier.
*/
- WARN_ONCE(1, "Please remove ignored %%n in '%s'\n", fmt);
/* Fall-through */
default:
+ WARN_ONCE(1, "Please remove unsupported %%%c in format
string\n", *fmt);
spec->type = FORMAT_TYPE_INVALID;
return fmt - start;
}
@@ -1944,10 +1944,15 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
break;
case FORMAT_TYPE_INVALID:
- if (str < end)
- *str = '%';
- ++str;
- break;
+ /*
+* Presumably the arguments passed gcc's type
+* checking, but there is no safe or sane way
+* for us to continue parsing the format and
+* fetching from the va_list; the remaining
+* specifiers and arguments would be out of
+* sync.
+*/
+ goto out;
default:
switch (spec.type) {
@@ -1992,6 +1997,7 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
}
}
+out:
if (size > 0) {
if (str < end)
*str = '\0';
@@ -2189,9 +2195,10 @@ do {
\
switch (spec.type) {
case FORMAT_TYPE_NONE:
- case FORMAT_TYPE_INVALID:
case FORMAT_TYPE_PERCENT_CHAR:
break;
+ case FORMAT_TYPE_INVALID:
+ goto out;
case FORMAT_TYPE_WIDTH:
case FORMAT_TYPE_PRECISION:
@@ -2253,6 +2260,7 @@ do {
\
}
}
+out:
return (u32 *)(PTR_ALIGN(str, sizeof(u32))) - bin_buf;
#undef save_arg
}
@@ -2375,12 +2383,14 @@ int bstr_printf(char *buf, size_t size, const char
*fmt, const u32 *bin_buf)
break;
case FORMAT_TYPE_PERCENT_CHAR:
- case FORMAT_TYPE_INVALID:
if (str < end)
*str = '%';
++str;
break;
+ case FORMAT_TYPE_INVALID:
+ goto out;
+
default: {
unsigned long long num;
@@ -2423,6 +2433,7 @@ int bstr_printf(char *buf, size_t size, const char *fmt,
const u32 *bin_buf)
} /* switch(spec.type) */
} /* while(*fmt) */
+out:
if (size > 0) {
if (str < end)
*str = '\0';
--
2.1.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 0/4] printf stuff
A few printf-related patches I've been sitting on. I also have some documentation updates, but I'll wait until I see Martin's patch [1] in -next. There's also the %pb issue [2], but I'm not sure there's consensus on the best fix for that. [1] https://lkml.org/lkml/2015/9/24/256 [2] https://lkml.org/lkml/2015/9/16/769 Rasmus Villemoes (4): lib/vsprintf.c: handle invalid format specifiers more robustly lib/vsprintf.c: also improve sanity check in bstr_printf() lib/vsprintf.c: Remove SPECIAL handling in pointer() test_printf: test printf family at runtime lib/Kconfig.debug | 3 + lib/Makefile | 1 + lib/test_printf.c | 364 ++ lib/vsprintf.c| 35 -- 4 files changed, 391 insertions(+), 12 deletions(-) create mode 100644 lib/test_printf.c -- 2.1.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 4/4] test_printf: test printf family at runtime
This adds a simple module for testing the kernel's printf
facilities. Previously, some %p extensions have caused a wrong return
value in case the entire output didn't fit and/or been unusable in
kasprintf(). This should help catch such issues. Also, it should help
ensure that changes to the formatting algorithms don't break anything.
I'm not sure if we have a struct dentry or struct file lying around at
boot time or if we can fake one, but most %p extensions should be
testable, as should the ordinary number and string formatting.
The nature of vararg functions means we can't use a more conventional
table-driven approach.
For now, this is mostly a skeleton; contributions are very
welcome. Some tests are/will be slightly annoying to write, since the
expected output depends on stuff like CONFIG_*, sizeof(long), runtime
values etc.
Signed-off-by: Rasmus Villemoes
---
lib/Kconfig.debug | 3 +
lib/Makefile | 1 +
lib/test_printf.c | 364 ++
3 files changed, 368 insertions(+)
create mode 100644 lib/test_printf.c
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ab76b99adc85..c23fc42dc659 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1685,6 +1685,9 @@ config TEST_STRING_HELPERS
config TEST_KSTRTOX
tristate "Test kstrto*() family of functions at runtime"
+config TEST_PRINTF
+ tristate "Test printf() family of functions at runtime"
+
config TEST_RHASHTABLE
tristate "Perform selftest on resizable hash table"
default n
diff --git a/lib/Makefile b/lib/Makefile
index 13a7c6ae3fec..775de427ea92 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
+obj-$(CONFIG_TEST_PRINTF) += test_printf.o
ifeq ($(CONFIG_DEBUG_KOBJECT),y)
CFLAGS_kobject.o += -DDEBUG
diff --git a/lib/test_printf.c b/lib/test_printf.c
new file mode 100644
index ..d9a2741c2909
--- /dev/null
+++ b/lib/test_printf.c
@@ -0,0 +1,364 @@
+/*
+ * Test cases for printf facility.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define BUF_SIZE 256
+#define FILL_CHAR '$'
+
+#define PTR1 ((void*)0x01234567)
+#define PTR2 ((void*)(long)(int)0xfedcba98)
+
+#if BITS_PER_LONG == 64
+#define PTR1_ZEROES "0"
+#define PTR1_SPACES " "
+#define PTR1_STR "1234567"
+#define PTR2_STR "fedcba98"
+#define PTR_WIDTH 16
+#else
+#define PTR1_ZEROES "0"
+#define PTR1_SPACES " "
+#define PTR1_STR "1234567"
+#define PTR2_STR "fedcba98"
+#define PTR_WIDTH 8
+#endif
+#define PTR_WIDTH_STR stringify(PTR_WIDTH)
+
+static unsigned total_tests __initdata;
+static unsigned failed_tests __initdata;
+static char *test_buffer __initdata;
+
+static int __printf(4, 0) __init
+do_test(int bufsize, const char *expect, int elen,
+ const char *fmt, va_list ap)
+{
+ va_list aq;
+ int ret, written;
+
+ total_tests++;
+
+ memset(test_buffer, FILL_CHAR, BUF_SIZE);
+ va_copy(aq, ap);
+ ret = vsnprintf(test_buffer, bufsize, fmt, aq);
+ va_end(aq);
+
+ if (ret != elen) {
+ pr_warn("bad return value, expected %d, got %d, format was
'%s'\n",
+ elen, ret, fmt);
+ return 1;
+ }
+
+ if (!bufsize) {
+ if (memchr_inv(test_buffer, FILL_CHAR, BUF_SIZE)) {
+ pr_warn("vsnprintf(buf, 0, \"%s\", ...) wrote to
buffer\n",
+ fmt);
+ return 1;
+ }
+ return 0;
+ }
+
+ written = min(bufsize-1, elen);
+ if (test_buffer[written]) {
+ pr_warn("vsnprintf(buf, %d, \"%s\", ...) did not nul-terminate
buffer\n",
+ bufsize, fmt);
+ return 1;
+ }
+
+ if (memcmp(test_buffer, expect, written)) {
+ pr_warn("vsnprintf(buf, %d, \"%s\", ...) wrote '%s', expected
'%.*s'\n",
+ bufsize, fmt, test_buffer, written, expect);
+ return 1;
+ }
+ return 0;
+}
+
+
+static void __printf(3, 4) __init
+__test(const char *expect, int elen, const char *fmt, ...)
+{
+ va_list ap;
+ int rand;
+ char *p;
+
+ BUG_ON(elen >= BUF_SIZE);
+
+ va_start(ap, fmt);
+
+ /*
+* Every fmt+args is subjected to four tests: Three where we
+* tell vsnprintf varying buffer sizes (plenty, not quite
+* enough and 0), and then we also test that kvasprintf would
+* be able to print it as expected.
+*/
+ failed_tests += do_test(BUF_SIZE, expect, elen, fmt, ap);
+ rand = 1 + prandom_u32_max(elen+1);
+ /* Since elen < BUF_SIZE, we have 1
[PATCH 3/4] lib/vsprintf.c: Remove SPECIAL handling in pointer()
As a quick
git grep -E '%[ +0#-]*#[ +0#-]*(\*|[0-9]+)?(\.(\*|[0-9]+)?)?p'
shows, nobody uses the # flag with %p. Moreover, I think users are
unlikely to show up since gcc will complain with
warning: `#' flag used with ā%pā gnu_printf format [-Wformat]
Since default_width is effectively always 2*sizeof(void*), we can
simplify the prologue of pointer() and save a few instructions.
Signed-off-by: Rasmus Villemoes
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 03fa10b4be96..98b0d7be3fb7 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1457,7 +1457,7 @@ static noinline_for_stack
char *pointer(const char *fmt, char *buf, char *end, void *ptr,
struct printf_spec spec)
{
- int default_width = 2 * sizeof(void *) + (spec.flags & SPECIAL ? 2 : 0);
+ const int default_width = 2 * sizeof(void *);
if (!ptr && *fmt != 'K') {
/*
--
2.1.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 3/7] fs: Verify access of user towards block device file when mounting
On Fri, Sep 25, 2015 at 12:16:59PM -0500, Eric W. Biederman wrote: > > Argh. This looks like morning person meets night owl. Indded :-) > Seth Forshee writes: > > > On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote: > >> Seth Forshee writes: > >> > >> > When mounting a filesystem on a block device there is currently > >> > no verification that the user has appropriate access to the > >> > device file passed to mount. This has not been an issue so far > >> > since the user in question has always been root, but this must > >> > be changed before allowing unprivileged users to mount in user > >> > namespaces. > >> > > >> > To do this, a new version of lookup_bdev() is added named > >> > lookup_bdev_perm(). Both of these functions become wrappers > >> > around a common inner fucntion. The behavior of lookup_bdev() is > >> > unchanged, but calling lookup_bdev_perm() will fail if the user > >> > does not have the specified access rights to the supplied path. > >> > The permission check is skipped if the user has CAP_SYS_ADMIN to > >> > avoid any possible regressions in behavior. > >> > > >> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This > >> > is used by mount_bdev() and mount_mtd(), so this will cause > >> > mounts on block devices to fail when the user lacks the required > >> > permissions. Other calls to blkdev_get_by_path() will all happen > >> > with root privileges, so these calls will be unaffected. > >> > >> Good but buggy patch. > >> > >> In the mtd bits the flags are super flags, not file mode bits, > >> which makes testing them against FMODE_READ and FMODE_WRITE is > >> incorrect. > > > > Bah, yes. Fixed. > > > >> Further it looks like quite a few more possibly all of the lookup_bdev > >> instances could use inode level permission checking. > >> > >> Certainly code such as quotactl makes me wonder. > > > > I opted to stick to places related to mounting, but let's take a look at > > the other callers. > > > > bcache calls it in the context of sysfs writes, and those attributes are > > writable only by root. In that case the inode permission check will be > > skipped anyway, so it makes no difference either way. > > > > Device mapper calls it in dm_get_device, which is called from a bunch of > > places. I had started trying to walk back through all the callers of > > dm_get_device, but that rabbit hole got really deep really quickly so I > > didn't feel confident that changing it wouldn't break anyone. > > > > quotactl gave me pause, as it seems to have done for you too. I was > > surprised that inode permissions aren't checked, but > > check_quotactl_permission does get called before actually doing > > anything. I fear that adding a check of inode permissions could end up > > breaking someone. > > My gut feel on all of this is that we should act like may_open and have > have a flag of 0 for access mode mean don't check permissions. > > That way we can change all of the callers of lookup_bdev to pass an > additional argument and make it explicit what is going on but we don't > actually have to change the callers to actually perform an additional > check. Sounds reasonable, I'll make that change. > Leaving stones unturned is a good way to introduce a security hole by > accident so I don't want to leave dm_get_device unreviewed, but any > changes can be in later patches. Unless I've made a mistake it shouldn't introduce security holes, dm_get_device should behave exactly the same was as it behaves today. Any security problems would already be present. I can take another crack at reviewing, but it might also be good if someone who already knows the code commented as well. As I recall I gave up after getting several levels deep in indirect function calls where the names of the struct members which held the function pointers were identical at a couple of levels, so I was having a hard time knowing if I was keeping everything straight. Seth -- 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] Documentation: dt: keystone: provide SoC specific compatible flags
On 09/25/2015 11:15 AM, santosh shilimkar wrote: > 9/25/2015 9:01 AM, Nishanth Menon wrote: >> On 09/25/2015 10:18 AM, santosh shilimkar wrote: >>> On 9/25/2015 7:50 AM, Nishanth Menon wrote: >> [...] But, how about userspace needing to know which SoC they are on, without needing to depend on board->soc mapping? How do we help resolve that? >>> Why the user space should care about exact SOC ? >> >> examples vary - trivial one is: debug tools like omapconf[1] or testing >> tools like opentest[2] need some standard way to ensure Linux kernel is >> functional - trusting the least set of parameters is usually what we >> would prefer. while building a generic distro such as debian or yocto, >> one prefers NOT to need to do a package build per SoC/perboard - that >> never scales. instead, you'd like the same application run on different >> systems dynamically. >> > I guessed omapconf example is coming though Keystone has no such tool :) That is true - as of now. maynot be the case for future. > yet ;-). Opentest shouldn't need that info either. we did debate this on opentest, but we could not implement anything since we did not have a consistent solution yet. > I do agree that having a soc along with board is useful in > longer run to accommodation more boards and variants. > And only on that merit, I am willing to take these patches. > > Please refresh the series commit messages based on the > discussion so far and repost. Will pick it up then. > Thanks. I will do so (probably early next week).. -- Regards, Nishanth Menon -- 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 12/12] mtd: nand-bbt: move nand_bbt.c to mtd folder
Hi Peter, First of all, thanks for taking the time to try to address my long-delayed comments. I hope to give this a proper look soon. (I also hope you can fix the email threading soon! I know that's a pain...) But first, a simpler comment: On Fri, Sep 25, 2015 at 06:48:05AM +, Peter Pan ę½ę (peterpandong) wrote: > Since struct nand_chip is removed from nand_bbt.c, BBT is now > shareable. Both NAND and SPI NAND can use it. So move nand_bbt.c > from nand/ foler to mtd/ folder and create MTD_NAND_BBT config. > Both NAND and SPI NAND should depend on MTD_NAND_BBT. > > Signed-off-by: Peter Pan > --- > drivers/mtd/Kconfig |7 + > drivers/mtd/Makefile|1 + > drivers/mtd/nand/Kconfig|2 +- > drivers/mtd/nand/Makefile |2 +- > drivers/mtd/nand/nand_bbt.c | 1289 > --- > drivers/mtd/nand_bbt.c | 1289 > +++ > 6 files changed, 1299 insertions(+), 1291 deletions(-) > delete mode 100644 drivers/mtd/nand/nand_bbt.c > create mode 100644 drivers/mtd/nand_bbt.c > [...] > diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c > deleted file mode 100644 > index 47c1084..000 > --- a/drivers/mtd/nand/nand_bbt.c > +++ /dev/null > @@ -1,1289 +0,0 @@ [snip deleting entire file] > diff --git a/drivers/mtd/nand_bbt.c b/drivers/mtd/nand_bbt.c > new file mode 100644 > index 000..47c1084 > --- /dev/null > +++ b/drivers/mtd/nand_bbt.c > @@ -0,0 +1,1289 @@ [snip adding the whole file again -- exactly the same I hope?] When moving files, it helps if you can use the '-M' (or '--find-renames') option to git-format-patch. That will give much smaller output that's easier to review. And if you had to change anything in the move, it should also help highlight exactly what changed, instead of including the entire file "diff". Regards, Brian P.S. Incidentally, this should also work around your issues with the copyright symbol. But then, I suspect that some people have used these sorts of non-ASCII characters just to fish out issues with mail clients/MTAs like yours :) -- 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] dma-debug: Allow poisoning nonzero allocations
Hi Russell,
On 25/09/15 13:44, Russell King - ARM Linux wrote:
On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:
Since some dma_alloc_coherent implementations return a zeroed buffer
regardless of whether __GFP_ZERO is passed, there exist drivers which
are implicitly dependent on this and pass otherwise uninitialised
buffers to hardware. This can lead to subtle and awkward-to-debug issues
using those drivers on different platforms, where nonzero uninitialised
junk may for instance occasionally look like a valid command which
causes the hardware to start misbehaving. To help with debugging such
issues, add the option to make uninitialised buffers much more obvious.
The reason people started to do this is to stop a security leak in the
ALSA code: ALSA allocates the ring buffer with dma_alloc_coherent()
which used to grab pages and return them uninitialised. These pages
could contain anything - including the contents of /etc/shadow, or
your bank details.
ALSA then lets userspace mmap() that memory, which means any user process
which has access to the sound devices can read data leaked from kernel
memory.
I think I did bring it up at the time I found it, and decided that the
safest thing to do was to always return an initialised buffer - short of
constantly auditing every dma_alloc_coherent() user which also mmap()s
the buffer into userspace, I couldn't convince myself that it was safe
to avoid initialising the buffer.
I don't know whether the original problem still exists in ALSA or not,
but I do know that there are dma_alloc_coherent() implementations out
there which do not initialise prior to returning memory.
Indeed, I think we've discussed this before, and I don't imagine we'll
be changing the actual behaviour of the existing allocators any time soon.
[ I still don't see that as an excuse for callers not to be fixed,
though - anyone allocating something that may be exposed to userspace
has a responsibility to initialise it appropriately. After all, the DMA
API is just one source, what do we do if such a careless subsystem got
some uninitialised pages of leftover sensitive data from, say,
alloc_pages() instead? ]
That's a bit of a separate issue though. If a driver itself _needs_ a
zeroed buffer but doesn't specifically request one, or doesn't get one
even if it did, then that's just a regular bug, and it's what this patch
is intended to help weed out. We've no need for a special poison value
for data protection in the general case; zero is just fine for that.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 908fb35..40514ed 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1447,7 +1448,7 @@ void debug_dma_unmap_sg(struct device *dev, struct
scatterlist *sglist,
EXPORT_SYMBOL(debug_dma_unmap_sg);
void debug_dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t dma_addr, void *virt)
+ dma_addr_t dma_addr, void *virt, gfp_t flags)
{
struct dma_debug_entry *entry;
@@ -1457,6 +1458,9 @@ void debug_dma_alloc_coherent(struct device *dev, size_t
size,
if (unlikely(virt == NULL))
return;
+ if (IS_ENABLED(CONFIG_DMA_API_DEBUG_POISON) && !(flags & __GFP_ZERO))
+ memset(virt, DMA_ALLOC_POISON, size);
+
This is likely to be slow in the case of non-cached memory and large
allocations. The config option should come with a warning.
It depends on DMA_API_DEBUG, which already has a stern performance
warning, is additionally hidden behind EXPERT, and carries a slightly
flippant yet largely truthful warning that actually using it could break
pretty much every driver in your system; is that not enough?
If I was feeling particularly antagonistic, I'd also point out that as
discussed above you've already taken the hit of a memset(0) and cache
flush that you _didn't_ ask for, and there was no warning on that ;)
The intent is a specific troubleshooting tool - realistically it's
probably only usable at all when restricting DMA debug to a per-driver
basis. My hunch is that nobody's too fussed about the performance of a
driver that doesn't work properly, especially once they've reached the
point of dumping buffers in an attempt to figure out why, when seeing
the presence or not of uniform poison values could be helpful.
(Of course, sometimes you end up debugging the allocator itself - see
commit 7132813c3845 - which was one of the motivating factors for this
patch).
Robin.
--
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/5] UBI: switch the UBI device in read-only mode when mtd returns -EROFS
Am 25.09.2015 um 17:09 schrieb Boris Brezillon:
> The NAND layer is now able to forward power-cut emulation errors from
> a NAND driver to the MTD user.
> Check for this kind of errors in UBI and switch the UBI device in read-only
> mode if such an error occurs.
> The error will also be forwarded to the UBI user requesting the operation
> if any, thus allowing UBIFS to act accordingly.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/ubi/io.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 5bbd1f0..c5ebef7 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -303,6 +303,8 @@ int ubi_io_write(struct ubi_device *ubi, const void *buf,
> int pnum, int offset,
> len = ubi->peb_size - offset;
> if (len)
> err = ubi_self_check_all_ff(ubi, pnum, offset, len);
> + } else if (err == -EROFS) {
> + ubi_ro_mode(ubi);
> }
>
> return err;
> @@ -355,7 +357,7 @@ retry:
>
> err = mtd_erase(ubi->mtd, );
> if (err) {
> - if (retries++ < UBI_IO_RETRIES) {
> + if (err != -EROFS && retries++ < UBI_IO_RETRIES) {
Looks good! :)
One small nit, can you please add a comment above both lines that the EROFS
checks are
here because of emulators.
Thanks,
//richard
--
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/
