Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wed, Dec 02, 2015 at 07:28:25PM +, Russell King - ARM Linux wrote: > The first is easy to solve, and the second by replacing it with dove.h. > The next problem is this: > > arch/arm/plat-orion/common.c:25:30: fatal error: mach/bridge-regs.h: No such > file or directory > > which is impossible to solve, because plat-orion/common.c wants > mach-dove/bridge-regs.h. Another few breakages which is going to be difficult to solve: drivers/hwmon/dove.c:35:30: fatal error: mach/bridge-regs.h: No such file or directory drivers/soc/dove/pmu.c: In function 'dove_init_pmu_legacy': drivers/soc/dove/pmu.c:404:46: error: 'IRQ_DOVE_PMU_START' undeclared (first use in this function) drivers/soc/dove/pmu.c:404:46: note: each undeclared identifier is reported only once for each function it appears in So, all in all this series gets a NAK from me as it totally destroys my ability to do any further work on Dove. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/8] android_pipe: Pin pages to memory while copying and other cleanups
From: Christoffer Dall
The existing code had a troubling TODO statement concerning the fact
that it just did a check if the page that the QEMU backend was going to
read from / write to was there before the call to the QEMU backend and
then relying on the fact that the page stayed around, even in a
preemptible SMP kernel. Obviously the page could go away or be
reassigned, and strange things may happen.
Further, writes were not tracked, so any use of COW or KSM-like
features would break completely. Probably that was never used by adbd
(the only current active user of the pipe), but could prove much more
dangerous for the GPU passthrough mechanism.
Instead, use get_user_pages() as the comment suggested and cleanup the
error path and add the set_page_dirt() call on a successful read
operation.
Also clarify the count used to return from successful read/write calls
and use Linux style commentary in various places of the file.
Note: The "just ignore error and return whatever we read so far" error
handling is really quite horrific. I cannot change it without a more
careful study of all user space ABIs reliance on this 'feature'.
Signed-off-by: Christoffer Dall
Signed-off-by: Jin Qian
---
drivers/platform/goldfish/goldfish_pipe.c | 129 +-
1 file changed, 72 insertions(+), 57 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 0fb3a34..20a9337 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -2,6 +2,7 @@
* Copyright (C) 2011 Google, Inc.
* Copyright (C) 2012 Intel, Inc.
* Copyright (C) 2013 Intel, Inc.
+ * Copyright (C) 2014 Linaro Limited
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -57,6 +58,7 @@
#include
#include
#include
+#include
/*
* IMPORTANT: The following constants must match the ones used and defined
@@ -257,17 +259,14 @@ static int access_with_param(struct goldfish_pipe_dev
*dev, const int cmd,
return 0;
}
-/* This function is used for both reading from and writing to a given
- * pipe.
- */
static ssize_t goldfish_pipe_read_write(struct file *filp, char __user *buffer,
- size_t bufflen, int is_write)
+ size_t bufflen, int is_write)
{
unsigned long irq_flags;
struct goldfish_pipe *pipe = filp->private_data;
struct goldfish_pipe_dev *dev = pipe->dev;
unsigned long address, address_end;
- int ret = 0;
+ int count = 0, ret = -EINVAL;
/* If the emulator already closed the pipe, no need to go further */
if (test_bit(BIT_CLOSED_ON_HOST, &pipe->flags))
@@ -290,30 +289,23 @@ static ssize_t goldfish_pipe_read_write(struct file
*filp, char __user *buffer,
address_end = address + bufflen;
while (address < address_end) {
- unsigned long page_end = (address & PAGE_MASK) + PAGE_SIZE;
- unsigned long next = page_end < address_end ? page_end
-: address_end;
- unsigned long avail= next - address;
+ unsigned long page_end = (address & PAGE_MASK) + PAGE_SIZE;
+ unsigned long next = page_end < address_end ? page_end
+ : address_end;
+ unsigned long avail= next - address;
int status, wakeBit;
-
- /* Ensure that the corresponding page is properly mapped */
- /* FIXME: this isn't safe or sufficient - use get_user_pages */
- if (is_write) {
- char c;
- /* Ensure that the page is mapped and readable */
- if (__get_user(c, (char __user *)address)) {
- if (!ret)
- ret = -EFAULT;
- break;
- }
- } else {
- /* Ensure that the page is mapped and writable */
- if (__put_user(0, (char __user *)address)) {
- if (!ret)
- ret = -EFAULT;
- break;
- }
- }
+ struct page *page;
+
+ /*
+* We grab the pages on a page-by-page basis in case user
+* space gives us a potentially huge buffer but the read only
+* returns a small amount, then there's no need to pin that
+* much memory to the process.
+*/
+ ret = get_user_pages(current, current->mm, address, 1,
+!is_write, 0, &page, NULL);
+
[PATCH] USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
after registration. At that time, pdev->dev.platform_data is not yet set,
leading to a NULL pointer dereference.
Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in
ohci_hcd_at91_drv_probe)
Reported-by: Peter Rosin
Tested-by: Peter Rosin
Signed-off-by: Alexandre Belloni
---
drivers/usb/host/ohci-at91.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 342ffd140122..8c6e15bd6ff0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -473,6 +473,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
if (!pdata)
return -ENOMEM;
+ pdev->dev.platform_data = pdata;
+
if (!of_property_read_u32(np, "num-ports", &ports))
pdata->ports = ports;
@@ -483,6 +485,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
*/
if (i >= pdata->ports) {
pdata->vbus_pin[i] = -EINVAL;
+ pdata->overcurrent_pin[i] = -EINVAL;
continue;
}
@@ -513,10 +516,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
at91_for_each_port(i) {
- if (i >= pdata->ports) {
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
+ if (i >= pdata->ports)
+ break;
pdata->overcurrent_pin[i] =
of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
@@ -552,8 +553,6 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
}
- pdev->dev.platform_data = pdata;
-
device_init_wakeup(&pdev->dev, 1);
return usb_hcd_at91_probe(&ohci_at91_hc_driver, pdev);
}
--
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 (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On Wed, Dec 2, 2015 at 8:05 PM, Brian Norris wrote: > + Broadcom list + Kamal > > On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote: >> Add device tree binding for NAND on the BCM63268. >> >> The BCM63268 has a NAND interrupt register with combined status and enable >> registers. >> >> Signed-off-by: Simon Arlott >> --- >> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 >> ++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> index 4ff7128..f2a71c8 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and >> associated register resources w >> and enable registers >> - reg-names: (required) "nand-int-base" >> >> + * "brcm,nand-bcm63268" >> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268" > > Looks like you're aiming to support bcm63168? Is bcm63268 the first > chip to include this style of register then? The numbering seems > backwards, but that may just be reality. There are four chip variants, bcm63168, bcm63268, bcm63169 and bcm63269, and they were all introduced at the same time. the *16x have less features than *26x (IIRC only two rgmii ports instead of four, no hw crypto, maybe no dect?), and the *9 ones have no xDSL support. >From a registers location/layout, clocks, etc standpoint, there is no difference between bcm63168 and bcm63268 (and the x9's). As a reference, Broadcom uses bcm63268 as the "generic" name for the chip family in their code, but on their website only advertise the bcm63168. Both chips do exist though, and at least the bcm63169, I have devices with these three here. Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
2015-12-02 11:05 GMT-08:00 Brian Norris : > + Broadcom list + Kamal > > On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote: >> Add device tree binding for NAND on the BCM63268. >> >> The BCM63268 has a NAND interrupt register with combined status and enable >> registers. >> >> Signed-off-by: Simon Arlott >> --- >> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 >> ++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> index 4ff7128..f2a71c8 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and >> associated register resources w >> and enable registers >> - reg-names: (required) "nand-int-base" >> >> + * "brcm,nand-bcm63268" >> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268" > > Looks like you're aiming to support bcm63168? Is bcm63268 the first > chip to include this style of register then? The numbering seems > backwards, but that may just be reality. 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7, 2009) and 6328 (v2.1, can't find release date) are earlier chips that have an identical combined interrupt enable + status register and a NAND controller within the same 32-bits word, so these would qualify as a better compatible string for this specific addition integration stub here. I would gowith 6368 here then? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On 02/12/15 19:05, Brian Norris wrote:
> + Broadcom list + Kamal
>
> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
>> Add device tree binding for NAND on the BCM63268.
>>
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers.
>>
>> Signed-off-by: Simon Arlott
>> ---
>> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35
>> ++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> index 4ff7128..f2a71c8 100644
>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and
>> associated register resources w
>> and enable registers
>> - reg-names: (required) "nand-int-base"
>>
>> + * "brcm,nand-bcm63268"
>> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"
>
> Looks like you're aiming to support bcm63168? Is bcm63268 the first
> chip to include this style of register then? The numbering seems
> backwards, but that may just be reality.
Yes, I have a BCM963168VX (BCM63168) but all the Broadcom code refers to
this SoC as BCM63268. This is the only one with these registers in the
source code of similar MIPS that I have.
https://github.com/lp0/bcm963xx_4.12L.06B_consumer/blob/master/bcmdrivers/opensource/char/board/bcm963xx/impl1/board.c#L6595
int kerSysGetChipId() {
...
/* Force BCM63168, BCM63169, and BCM63269 to be BCM63268) */
if( ( (r & 0xe) == 0x63168 )
|| ( (r & 0xe) == 0x63268 ))
r = 0x63268;
>> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined
>> status
>> + and enable registers, and boot address registers
>> + - reg-names: (required) "nand-intr-base"
>> + - clock: (required) reference to the clock for the NAND controller
>> + - clock-names: (required) "nand"
>> +
>> * "brcm,nand-iproc"
>> - reg: (required) the "IDM" register range, for interrupt enable and
>> APB
>> bus access endianness configuration, and the "EXT" register range,
>> @@ -148,3 +156,30 @@ nand@f0442800 {
>> };
>> };
>> };
>> +
>> +nand@1200 {
>> +compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268",
>> +"brcm,brcmnand-v4.0", "brcm,brcmnand";
>> +reg = <0x1200 0x180>,
>> + <0x1600 0x200>,
>> + <0x10b0 0x10>;
>> +reg-names = "nand", "nand-cache", "nand-intr-base";
>> +interrupt-parent = <&periph_intc>;
>> +interrupts = <50>;
>> +clocks = <&periph_clk 20>;
>> +clock-names = "nand";
>> +
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +nand0: nandcs@0 {
>> +compatible = "brcm,nandcs";
>> +reg = <0>;
>> +nand-on-flash-bbt;
>> +nand-ecc-strength = <1>;
>> +nand-ecc-step-size = <512>;
>> +
>> +#address-cells = <0>;
>> +#size-cells = <0>;
>
> What are these {address,size}-cells for? If you need them for
> partitioning, then those are wrong -- they shouldn't be zero. Maybe just
> drop them? (I can cut them out when applying, if that's the only change
> to make.)
This is the correct way to do partitioning, there would be a
"partitions" block with no address/size that contains the partitions as
child nodes. [Documentation/devicetree/bindings/mtd/partition.txt]
I think they're also implicit so you can just remove those two lines.
I've created a bcm963268part driver so there won't need to be any
partitions in DT for bcm63268.
>> +};
>> +};
>
> Brian
>
--
Simon Arlott
--
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 2/8] android_pipe: don't be clever with #define offsets
From: Alex Bennée
You just make it harder to figure out when commands are being used.
Signed-off-by: Alex Bennée
Signed-off-by: Jin Qian
---
drivers/platform/goldfish/goldfish_pipe.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..0fb3a34 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -90,12 +90,6 @@
#define CMD_WRITE_BUFFER 4 /* send a user buffer to the emulator */
#define CMD_WAKE_ON_WRITE 5 /* tell the emulator to wake us when writing
is possible */
-
-/* The following commands are related to read operations, they must be
- * listed in the same order than the corresponding write ones, since we
- * will use (CMD_READ_BUFFER - CMD_WRITE_BUFFER) as a special offset
- * in goldfish_pipe_read_write() below.
- */
#define CMD_READ_BUFFER6 /* receive a user buffer from the emulator */
#define CMD_WAKE_ON_READ 7 /* tell the emulator to wake us when reading
* is possible */
@@ -272,8 +266,6 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
unsigned long irq_flags;
struct goldfish_pipe *pipe = filp->private_data;
struct goldfish_pipe_dev *dev = pipe->dev;
- const int cmd_offset = is_write ? 0
- : (CMD_READ_BUFFER - CMD_WRITE_BUFFER);
unsigned long address, address_end;
int ret = 0;
@@ -325,7 +317,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
/* Now, try to transfer the bytes in the current page */
spin_lock_irqsave(&dev->lock, irq_flags);
- if (access_with_param(dev, CMD_WRITE_BUFFER + cmd_offset,
+ if (access_with_param(dev,
+ is_write ? CMD_WRITE_BUFFER : CMD_READ_BUFFER,
address, avail, pipe, &status)) {
gf_write_ptr(pipe, dev->base + PIPE_REG_CHANNEL,
dev->base + PIPE_REG_CHANNEL_HIGH);
@@ -333,7 +326,7 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
gf_write_ptr((void *)address,
dev->base + PIPE_REG_ADDRESS,
dev->base + PIPE_REG_ADDRESS_HIGH);
- writel(CMD_WRITE_BUFFER + cmd_offset,
+ writel(is_write ? CMD_WRITE_BUFFER : CMD_READ_BUFFER,
dev->base + PIPE_REG_COMMAND);
status = readl(dev->base + PIPE_REG_STATUS);
}
@@ -370,7 +363,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
set_bit(wakeBit, &pipe->flags);
/* Tell the emulator we're going to wait for a wake event */
- goldfish_cmd(pipe, CMD_WAKE_ON_WRITE + cmd_offset);
+ goldfish_cmd(pipe,
+ is_write ? CMD_WAKE_ON_WRITE : CMD_WAKE_ON_READ);
/* Unlock the pipe, then wait for the wake signal */
mutex_unlock(&pipe->lock);
--
2.6.0.rc2.230.g3dd15c0
--
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/5] spi: introduce accelerated read support for spi flash devices
On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote: > In addition to providing direct access to SPI bus, some spi controller > hardwares (like ti-qspi) provide special port (like memory mapped port) > that are optimized to improve SPI flash read performance. I'm reasonably OK with this from the SPI side but I'd really like to see people working on MTD say that this makes sense. signature.asc Description: PGP signature
[PATCH v3 8/8] goldfish: Enable ACPI-based enumeration for android pipe
From: Jason Hu
Add ACPI binding to the android pipe driver
Signed-off-by: Jason Hu
Signed-off-by: Jin Qian
---
drivers/platform/goldfish/goldfish_pipe.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index c214434..e3fab9a 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
/*
* IMPORTANT: The following constants must match the ones used and defined
@@ -650,6 +651,12 @@ static int goldfish_pipe_remove(struct platform_device
*pdev)
return 0;
}
+static const struct acpi_device_id goldfish_pipe_acpi_match[] = {
+ { "GFSH0003", 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, goldfish_pipe_acpi_match);
+
static const struct of_device_id goldfish_pipe_of_match[] = {
{ .compatible = "google,android-pipe", },
{},
@@ -663,6 +670,7 @@ static struct platform_driver goldfish_pipe = {
.name = "goldfish_pipe",
.owner = THIS_MODULE,
.of_match_table = goldfish_pipe_of_match,
+ .acpi_match_table = ACPI_PTR(goldfish_pipe_acpi_match),
}
};
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 net-next 5/5] net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"
Hello.
On 12/02/2015 07:52 PM, Salil Mehta wrote:
This patch adds the initializzation code to disable the hardware
vlan support for VLAN Tag stripping by default for now.
Proper support of "hardware VLAN assitance" feature would
soon come in the next coming patches.
Signed-off-by: Salil Mehta
---
PATCH V6:
- No change over the earlier patch
PATCH V5:
- Minor merge/reject change resolved to application of previous patch
PATCH V4/V3/V2:
- No change over the initial floated patch
PATCH V1:
- Initial code to disable the hardware VLAN assist for now
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |7 +++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index b5e4c44..f302ef9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -176,6 +176,11 @@ static void hns_ppe_cnt_clr_ce(struct hns_ppe_cb *ppe_cb)
PPE_CNT_CLR_CE_B, 1);
}
+static void hns_ppe_set_vlan_strip(struct hns_ppe_cb *ppe_cb, int en)
+{
+ dsaf_write_dev(ppe_cb, PPEV2_VLAN_STRIP_EN_REG, en);
Why not call it directly?
+}
+
/**
* hns_ppe_checksum_hw - set ppe checksum caculate
* @ppe_device: ppe device
@@ -336,6 +341,8 @@ static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb)
hns_ppe_cnt_clr_ce(ppe_cb);
if (!AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+ hns_ppe_set_vlan_strip(ppe_cb, 0);
+
/* set default RSS key in h/w */
hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 98c163e..6c18ca9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -318,6 +318,7 @@
#define PPE_CFG_PARSE_TAG_REG 0x94
#define PPE_CFG_PRO_CHECK_EN_REG 0x98
#define PPEV2_CFG_TSO_EN_REG0xA0
+#define PPEV2_VLAN_STRIP_EN_REG 0xAC
Please indent with tabs, like all the surrounding #define's are indented
(except PPEV2_CFG_TSO_EN_REG).
#define PPE_INTEN_REG 0x100
#define PPE_RINT_REG 0x104
#define PPE_INTSTS_REG0x108
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 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wednesday 02 December 2015 19:28:25 Russell King - ARM Linux wrote: > > As I said above, that's not the problem, the problem is merging it into > the rest of my tree. > > Having done most of that merge, I'm now tripping up on: > > arch/arm/mach-dove/common.c: In function 'dove_wdt_init': > arch/arm/mach-dove/common.c:538:2: error: implicit declaration of function > 'orion_wdt_init' [-Werror=implicit-function-declaration] > > which I guess is because you've deleted the legacy orion watchdog stuff. > So I'm going to have to revert that. That then gives me: > > arch/arm/mach-dove/clock.c:19:21: fatal error: mach/pm.h: No such file or > directory > arch/arm/mach-dove/clock.c:20:27: fatal error: mach/hardware.h: No such file > or directory > > The first is easy to solve, and the second by replacing it with dove.h. > The next problem is this: > > arch/arm/plat-orion/common.c:25:30: fatal error: mach/bridge-regs.h: No such > file or directory > > which is impossible to solve, because plat-orion/common.c wants > mach-dove/bridge-regs.h. Ok, I can try to work around that, either by duplicating the device definition, or passing the address into orion_wdt_init. > I also have arch/arm/mach-dove/include/mach/sdhci.h to pass the GPIO > for card detection to the SDHCI driver, which is going to break unless > it's moved to include/linux/platform-data. Right, a platform_data file seems the right approach there. Possibly just passing the gpio number by casting it to a pointer, though that's a bit ugly. > Everything else seems mostly happy, but I've no way to tell whether > what would be the resulting kernel would work as it's impossible to > know without fixing the wreckage above. > > I'm sure I don't have to repeat my position over what I'm going to do if > these petty mainline changes which are totally unnecessary break the only > setup I have which works. Making mach-dove multi-platform is a "wouldn't > it be nice if", it's not an absolute necessity. I'm mostly interested in it because it's the only ARMv7 platform that is left after my other patches, and I just want to be done with it after spending 5 years on it ;-) Arnd -- 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: linux-next: build failure after merge of the modules tree
Mark Brown writes: > Hi Rusty, > > After merging the modules tree, today's linux-next x86 allmodconfig build > (20151201) failed like this: > > /home/broonie/next/next/arch/x86/kernel/livepatch.c: In function > 'klp_write_module_reloc': > /home/broonie/next/next/arch/x86/kernel/livepatch.c:75:22: error: 'struct > module' has no member named 'core_ro_size' > if (loc < core + mod->core_ro_size) Yep, I missed that one. I also missed an ARM case, so I'll rebase the tree (it's near the top anyway). Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wednesday 02 December 2015 19:37:08 Russell King - ARM Linux wrote: > On Wed, Dec 02, 2015 at 07:28:25PM +, Russell King - ARM Linux wrote: > > The first is easy to solve, and the second by replacing it with dove.h. > > The next problem is this: > > > > arch/arm/plat-orion/common.c:25:30: fatal error: mach/bridge-regs.h: No > > such file or directory > > > > which is impossible to solve, because plat-orion/common.c wants > > mach-dove/bridge-regs.h. > > Another few breakages which is going to be difficult to solve: > > drivers/hwmon/dove.c:35:30: fatal error: mach/bridge-regs.h: No such file or > directory > > drivers/soc/dove/pmu.c: In function 'dove_init_pmu_legacy': > drivers/soc/dove/pmu.c:404:46: error: 'IRQ_DOVE_PMU_START' undeclared (first > use in this function) > drivers/soc/dove/pmu.c:404:46: note: each undeclared identifier is reported > only once for each function it appears in > > So, all in all this series gets a NAK from me as it totally destroys > my ability to do any further work on Dove. > Ok, I'll try to take out the dove specific parts that get in the way here but would still do the whole series for mv78xx0 and orion5x unless someone finds problems. Arnd -- 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 (v7) 2/2] mtd: brcmnand: Add support for the BCM63268
On 02/12/15 19:18, Brian Norris wrote:
> + Broadcom list + Kamal
>
> Hi Simon,
>
> On Wed, Nov 25, 2015 at 07:49:13PM +, Simon Arlott wrote:
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers. It also has a clock for the NAND controller that needs to be
>> enabled.
>>
>> Set up the device by enabling the clock, disabling and acking all
>> interrupts, then handle the CTRL_READY interrupt.
>>
>> Add a brcmnand_get_socdata() function so that bcm63268_nand can obtain its
>> data and disable the clock when the device is removed.
>>
>> Signed-off-by: Simon Arlott
>> ---
>> Added EXPORT_SYMBOL_GPL(brcmnand_get_socdata)
>>
>> (As the brcmnand module must be loaded first its compatible string will
>> apply to any existing devices before the soc-specific module can be
>> loaded.)
>
> What's this comment supposed to mean? The brcmnand module will not
> directly probe any devices. It doesn't register any driver structs by
> itself.
I didn't notice that it didn't actually probe devices. In that case the
documentation should not require "brcm,brcmnand" for soc-specific
variants because the hardware's not really compatible with it.
> (BTW given that, it probably doesn't need its MODULE_DEVICE_TABLE.)
>
>> drivers/mtd/nand/brcmnand/Makefile| 1 +
>> drivers/mtd/nand/brcmnand/bcm63268_nand.c | 179
>> ++
>> drivers/mtd/nand/brcmnand/brcmnand.c | 8 ++
>> drivers/mtd/nand/brcmnand/brcmnand.h | 1 +
>> 4 files changed, 189 insertions(+)
>> create mode 100644 drivers/mtd/nand/brcmnand/bcm63268_nand.c
>>
>> diff --git a/drivers/mtd/nand/brcmnand/Makefile
>> b/drivers/mtd/nand/brcmnand/Makefile
>> index 3b1fbfd..b83a9ae 100644
>> --- a/drivers/mtd/nand/brcmnand/Makefile
>> +++ b/drivers/mtd/nand/brcmnand/Makefile
>> @@ -2,5 +2,6 @@
>> # more specific iproc_nand.o, for instance
>> obj-$(CONFIG_MTD_NAND_BRCMNAND) += iproc_nand.o
>> obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63138_nand.o
>> +obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63268_nand.o
>> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmstb_nand.o
>> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand.o
>> diff --git a/drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> new file mode 100644
>> index 000..70ad907
>> --- /dev/null
>> +++ b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> @@ -0,0 +1,179 @@
>> +/*
>> + * Copyright 2015 Simon Arlott
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Derived from bcm63138_nand.c:
>> + * Copyright © 2015 Broadcom Corporation
>> + *
>> + * Derived from
>> bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
>> + * Copyright 2000-2010 Broadcom Corporation
>> + *
>> + * Derived from
>> bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
>> + * Copyright 2000-2010 Broadcom Corporation
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "brcmnand.h"
>> +
>> +struct bcm63268_nand_soc {
>> +struct brcmnand_soc soc;
>> +void __iomem *base;
>> +struct clk *clk;
>> +};
>> +
>> +#define BCM63268_NAND_INT 0x00
>> +#define BCM63268_NAND_STATUS_SHIFT 0
>> +#define BCM63268_NAND_STATUS_MASK (0xfff << BCM63268_NAND_STATUS_SHIFT)
>> +#define BCM63268_NAND_ENABLE_SHIFT 16
>> +#define BCM63268_NAND_ENABLE_MASK (0x << BCM63268_NAND_ENABLE_SHIFT)
>> +#define BCM63268_NAND_BASE_ADDR00x04
>> +#define BCM63268_NAND_BASE_ADDR10x0c
>> +
>> +enum {
>> +BCM63268_NP_READ= BIT(0),
>> +BCM63268_BLOCK_ERASE= BIT(1),
>> +BCM63268_COPY_BACK = BIT(2),
>> +BCM63268_PAGE_PGM = BIT(3),
>> +BCM63268_CTRL_READY = BIT(4),
>> +BCM63268_DEV_RBPIN = BIT(5),
>> +BCM63268_ECC_ERR_UNC= BIT(6),
>> +BCM63268_ECC_ERR_CORR = BIT(7),
>> +};
>> +
>> +static bool bcm63268_nand_intc_ack(struct brcmnand_soc *soc)
>> +{
>> +struct bcm63268_nand_soc *priv =
>> +container_of(soc, struct bcm63268_nand_soc, soc);
>> +void __iomem *mmio = priv->base + BCM63268_NAND_INT;
>> +u32 val = brcmnand_readl(mmio);
>> +
>> +if (val & (BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT)) {
>> +/* Ack interrupt */
>> +val &= ~BCM63268_NAND_STATUS_MASK;
>> +val |= BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT;
>> +brcmnand_writel(val, mmio);
>> +
Re: [PATCH v2 3/3] sched/fair: Disable tg load_avg update for root_task_group
Waiman Long writes:
> Currently, the update_tg_load_avg() function attempts to update the
> tg's load_avg value whenever the load changes even for root_task_group
> where the load_avg value will never be used. This patch will disable
> the load_avg update when the given task group is the root_task_group.
>
> Running a Java benchmark with noautogroup and a 4.3 kernel on a
> 16-socket IvyBridge-EX system, the amount of CPU time (as reported by
> perf) consumed by task_tick_fair() which includes update_tg_load_avg()
> decreased from 0.71% to 0.22%, a more than 3X reduction. The Max-jOPs
> results also increased slightly from 983015 to 986449.
>
> Signed-off-by: Waiman Long
Reviewed-by: Ben Segall
> ---
> kernel/sched/fair.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8f1eccc..4607cb7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2670,6 +2670,12 @@ static inline void update_tg_load_avg(struct cfs_rq
> *cfs_rq, int force)
> {
> long delta = cfs_rq->avg.load_avg - cfs_rq->tg_load_avg_contrib;
>
> + /*
> + * No need to update load_avg for root_task_group as it is not used.
> + */
> + if (cfs_rq->tg == &root_task_group)
> + return;
> +
> if (force || abs(delta) > cfs_rq->tg_load_avg_contrib / 64) {
> atomic_long_add(delta, &cfs_rq->tg->load_avg);
> cfs_rq->tg_load_avg_contrib = cfs_rq->avg.load_avg;
--
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: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt
On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: > These are the benchmarks for request based dm-crypt. Please check it. Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this? People aren't going to take a request-based solution seriously until you can explain in full detail *why* bio-based is slower AND why it's impossible to improve its performance. > For request based things, some sequential bios/requests can merged > into one request to expand the IO size to be a big block handled by > hardware engine at one time. Bio-based also merges I/O so that does not provide justification. Investigate in much more detail the actual merging and scheduling involved in the cases you need to optimise. See if blktrace gives you any clues, or add your own instrumentation. You could even look at some of the patches we've had in the list archives for optimising bio-based crypt in different situations. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
On Wed, Dec 2, 2015 at 12:12 PM, Toshi Kani wrote:
> On Wed, 2015-12-02 at 13:02 -0700, Toshi Kani wrote:
>> On Wed, 2015-12-02 at 11:00 -0800, Dan Williams wrote:
>> > On Wed, Dec 2, 2015 at 11:26 AM, Toshi Kani wrote:
>> > > On Wed, 2015-12-02 at 10:06 -0800, Dan Williams wrote:
>> > > > On Wed, Dec 2, 2015 at 9:01 AM, Dan Williams
>> > > > wrote:
>> > > > > On Wed, Dec 2, 2015 at 9:43 AM, Toshi Kani
>> > > > > wrote:
>> > > > > > Oh, I see. I will setup the memmap array and run the tests again.
>> > > > > >
>> > > > > > But, why does the PMD mapping depend on the memmap array? We have
>> > > > > > observed major performance improvement with PMD. This feature
>> > > > > > should always be enabled with DAX regardless of the option to
>> > > > > > allocate the memmap array.
>> > > > > >
>> > > > >
>> > > > > Several factors drove this decision, I'm open to considering
>> > > > > alternatives but here's the reasoning:
>> > > > >
>> > > > > 1/ DAX pmd mappings caused crashes in the get_user_pages path leading
>> > > > > to commit e82c9ed41e8 "dax: disable pmd mappings". The reason pte
>> > > > > mappings don't crash and instead trigger -EFAULT is due to the
>> > > > > _PAGE_SPECIAL pte bit.
>> > > > >
>> > > > > 2/ To enable get_user_pages for DAX, in both the page and huge-page
>> > > > > case, we need a new pte bit _PAGE_DEVMAP.
>> > > > >
>> > > > > 3/ Given the pte bits are hard to come I'm assuming we won't get two,
>> > > > > i.e. both _PAGE_DEVMAP and a new _PAGE_SPECIAL for pmds. Even if we
>> > > > > could get a _PAGE_SPECIAL for pmds I'm not in favor of pursuing it.
>> > > >
>> > > > Actually, Dave says they aren't that hard to come by for pmds, so we
>> > > > could go add _PMD_SPECIAL if we really wanted to support the limited
>> > > > page-less DAX-pmd case.
>> > > >
>> > > > But I'm still of the opinion that we run away from the page-less case
>> > > > until it can be made a full class citizen with O_DIRECT for pfn
>> > > > support.
>> > >
>> > > I may be missing something, but per vm_normal_page(), I think
>> > > _PAGE_SPECIAL can be substituted by the following check when we do not
>> > > have the memmap.
>> > >
>> > > if ((vma->vm_flags & VM_PFNMAP) ||
>> > > ((vma->vm_flags & VM_MIXEDMAP) && (!pfn_valid(pfn {
>> > >
>> > > This is what I did in this patch for follow_trans_huge_pmd(), although I
>> > > missed the pfn_valid() check.
>> >
>> > That works for __get_user_pages but not __get_user_pages_fast where we
>> > don't have access to the vma.
>>
>> __get_user_page_fast already refers current->mm, so we should be able to get
>> the vma, and pass it down to gup_pud_range().
>
> Alternatively, we can obtain the vma from current->mm in gup_huge_pmd() when
> the
> !pfn_valid() condition is met, so that we do not add the code to the main path
> of __get_user_pages_fast.
The whole point of __get_user_page_fast() is to avoid the overhead of
taking the mm semaphore to access the vma. _PAGE_SPECIAL simply tells
__get_user_pages_fast that it needs to fallback to the
__get_user_pages slow path.
--
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] ia64: bitvector_process could read out of bounds
The units[] array could be accessed out of its bounds due the lack of
verification of the max vector value.
To make this function not prone to error "P" and "E" suffixes were added.
Despite the new suffixes are unrelated to current ia64 vm magnitudes, they
make the code ready for it and avoid misleadings.
Caught using static analysis (cppcheck).
Signed-off-by: Geyslan G. Bem
---
arch/ia64/kernel/palinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index c39c3cd..bb499102 100644
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -126,7 +126,7 @@ static const char *mem_attrib[]={
static void bitvector_process(struct seq_file *m, u64 vector)
{
int i,j;
- static const char *units[]={ "", "K", "M", "G", "T" };
+ static const char *units[] = { "", "K", "M", "G", "T", "P", "E" };
for (i=0, j=0; i < 64; i++ , j=i/10) {
if (vector & 0x1)
--
2.6.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 (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
Hi,
On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> + nand0: nandcs@0 {
> >> + compatible = "brcm,nandcs";
> >> + reg = <0>;
> >> + nand-on-flash-bbt;
> >> + nand-ecc-strength = <1>;
> >> + nand-ecc-step-size = <512>;
> >> +
> >> + #address-cells = <0>;
> >> + #size-cells = <0>;
> >
> > What are these {address,size}-cells for? If you need them for
> > partitioning, then those are wrong -- they shouldn't be zero. Maybe just
> > drop them? (I can cut them out when applying, if that's the only change
> > to make.)
>
> This is the correct way to do partitioning, there would be a
> "partitions" block with no address/size that contains the partitions as
> child nodes. [Documentation/devicetree/bindings/mtd/partition.txt]
That doc says nothing about {address,size}-cells = 0. When using the new
binding with a 'partitions' subnode, I'm not sure the address
translation specification really matters anyway; the flash space is a
new address space unrelated to the parents, and we don't do any
translation from the 'flash' node to the 'partitions' node. So you don't
need #{address,size}-cells in the flash node, but you do in the
'partitions' node.
> I think they're also implicit so you can just remove those two lines.
>From ePAPR: "The #address-cells and #size-cells properties are not
inherited from ancestors in the device tree. They shall be explicitly
defined."
But we don't want to define them. I'd drop them, at least from the
example, as they're not relevant.
> I've created a bcm963268part driver so there won't need to be any
> partitions in DT for bcm63268.
Just curious, do you plan to submit this driver? We're working on
matching up partition parsers to flash devices via device tree
of_match_table's, so you could do something like this:
nand0: nandcs@0 {
compatible = "brcm,nandcs";
...
partitions {
compatible = "brcm,bcm963268-partitions";
...
};
};
FYI.
> >> + };
> >> +};
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/5] crypto: Multi-buffer encryption infrastructure support
In this patch, the infrastructure needed to support multibuffer
encryption implementation is added:
a) Enhace mcryptd daemon to support blkcipher requests.
b) Update configuration to include multi-buffer encryption build support.
For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
crypto/Kconfig | 16 +++
crypto/mcryptd.c | 256 ++-
include/crypto/algapi.h | 1 +
include/crypto/mcryptd.h | 36 +++
4 files changed, 308 insertions(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 7240821..6b51084 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -888,6 +888,22 @@ config CRYPTO_AES_NI_INTEL
ECB, CBC, LRW, PCBC, XTS. The 64 bit version has additional
acceleration for CTR.
+config CRYPTO_AES_CBC_MB
+ tristate "AES CBC algorithm (x86_64 Multi-Buffer, Experimental)"
+ depends on X86 && 64BIT
+ select CRYPTO_ABLK_HELPER
+ select CRYPTO_MCRYPTD
+ help
+ AES CBC encryption implemented using multi-buffer technique.
+ This algorithm computes on multiple data lanes concurrently with
+ SIMD instructions for better throughput. It should only be
+ used when there is significant work to generate many separate
+ crypto requests that keep all the data lanes filled to get
+ the performance benefit. If the data lanes are unfilled, a
+ flush operation will be initiated after some delay to process
+ the exisiting crypto jobs, adding some extra latency at low
+ load case.
+
config CRYPTO_AES_SPARC64
tristate "AES cipher algorithms (SPARC64)"
depends on SPARC64
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index fe5b495a..01f747c 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -116,8 +116,28 @@ static int mcryptd_enqueue_request(struct mcryptd_queue
*queue,
return err;
}
+static int mcryptd_enqueue_blkcipher_request(struct mcryptd_queue *queue,
+ struct crypto_async_request *request,
+ struct mcryptd_blkcipher_request_ctx *rctx)
+{
+ int cpu, err;
+ struct mcryptd_cpu_queue *cpu_queue;
+
+ cpu = get_cpu();
+ cpu_queue = this_cpu_ptr(queue->cpu_queue);
+ rctx->tag.cpu = cpu;
+
+ err = crypto_enqueue_request(&cpu_queue->queue, request);
+ pr_debug("enqueue request: cpu %d cpu_queue %p request %p\n",
+cpu, cpu_queue, request);
+ queue_work_on(cpu, kcrypto_wq, &cpu_queue->work);
+ put_cpu();
+
+ return err;
+}
+
/*
- * Try to opportunisticlly flush the partially completed jobs if
+ * Try to opportunistically flush the partially completed jobs if
* crypto daemon is the only task running.
*/
static void mcryptd_opportunistic_flush(void)
@@ -225,6 +245,130 @@ static inline struct mcryptd_queue
*mcryptd_get_queue(struct crypto_tfm *tfm)
return ictx->queue;
}
+static int mcryptd_blkcipher_setkey(struct crypto_ablkcipher *parent,
+ const u8 *key, unsigned int keylen)
+{
+ struct mcryptd_blkcipher_ctx *ctx = crypto_ablkcipher_ctx(parent);
+ struct crypto_blkcipher *child = ctx->child;
+ int err;
+
+ crypto_blkcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+ crypto_blkcipher_set_flags(child, crypto_ablkcipher_get_flags(parent) &
+ CRYPTO_TFM_REQ_MASK);
+ err = crypto_blkcipher_setkey(child, key, keylen);
+ crypto_ablkcipher_set_flags(parent, crypto_blkcipher_get_flags(child) &
+ CRYPTO_TFM_RES_MASK);
+ return err;
+}
+
+static void mcryptd_blkcipher_crypt(struct ablkcipher_request *req,
+ struct crypto_blkcipher *child,
+ int err,
+ int (*crypt)(struct blkcipher_desc *desc,
+ struct scatterlist *dst,
+ struct scatterlist *src,
+ unsigned int len))
+{
+ struct mcryptd_blkcipher_request_ctx *rctx;
+ struct blkcipher_desc desc;
+
+ rctx = ablkcipher_request_ctx(req);
+
+ if (unlikely(err == -EINPROGRESS))
+ goto out;
+
+ /* set up the blkcipher request to work on */
+ desc.tfm = child;
+ desc.info = req->info;
+ desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ rctx->desc = desc;
+
+ /*
+* pass addr of descriptor stored in the request context
+* so that the callee can get to the request context
+*/
+ err = crypt(&rctx->desc, req->dst, req->src, req->nbytes);
+ if
[PATCH v4 0/5] crypto: x86 AES-CBC encryption with multibuffer
In this patch series, we introduce AES CBC encryption that is parallelized on x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data streams in parallel with SIMD instructions. Decryption is handled as in the existing AESNI Intel CBC implementation which can already parallelize decryption even for a single data stream. Please see the multi-buffer whitepaper for details of the technique: http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html It is important that any driver uses this algorithm properly for scenarios where we have many data streams that can fill up the data lanes most of the time. It shouldn't be used when only a single data stream is expected mostly. Otherwise we may incurr extra delays when we have frequent gaps in data lanes, causing us to wait till data come in to fill the data lanes before initiating encryption. We may have to wait for flush operations to commence when no new data come in after some wait time. However we keep this extra delay to a minimum by opportunistically flushing the unfinished jobs if crypto daemon is the only active task running on a cpu. By using this technique, we saw a throughput increase of up to 5.7x under optimal conditions when we have fully loaded encryption jobs filling up all the data lanes. Change Log: v4 1. Make the decrypt path also use ablkcpher walk. v3 1. Use ablkcipher_walk helpers to walk the scatter gather list and eliminated needs to modify blkcipher_walk for multibuffer cipher v2 1. Update cpu feature check to make sure SSE is supported 2. Fix up unloading of aes-cbc-mb module to properly free memory Tim Chen (5): crypto: Multi-buffer encryption infrastructure support crypto: AES CBC multi-buffer data structures crypto: AES CBC multi-buffer scheduler crypto: AES CBC by8 encryption crypto: AES CBC multi-buffer glue code arch/x86/crypto/Makefile | 1 + arch/x86/crypto/aes-cbc-mb/Makefile| 22 + arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S| 774 +++ arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c| 835 + arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +++ arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +++ arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 ++ arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416 ++ arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125 +++ crypto/Kconfig | 16 + crypto/mcryptd.c | 256 ++- include/crypto/algapi.h| 1 + include/crypto/mcryptd.h | 36 + 15 files changed, 3345 insertions(+), 1 deletion(-) create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/5] crypto: AES CBC multi-buffer data structures
This patch introduces the data structures and prototypes of functions
needed for doing AES CBC encryption using multi-buffer. Included are
the structures of the multi-buffer AES CBC job, job scheduler in C and
data structure defines in x86 assembly code.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125
4 files changed, 622 insertions(+)
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
new file mode 100644
index 000..5493f83
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
@@ -0,0 +1,96 @@
+/*
+ * Header file for multi buffer AES CBC algorithm manager
+ * that deals with 8 buffers at a time
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2015 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License 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.
+ *
+ * Contact Information:
+ * James Guilford
+ * Sean Gulley
+ * Tim Chen
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+#ifndef __AES_CBC_MB_CTX_H
+#define __AES_CBC_MB_CTX_H
+
+
+#include
+
+#include "aes_cbc_mb_mgr.h"
+
+#define CBC_ENCRYPT0x01
+#define CBC_DECRYPT0x02
+#define CBC_START 0x04
+#define CBC_DONE 0x08
+
+#define CBC_CTX_STS_IDLE 0x00
+#define CBC_CTX_STS_PROCESSING 0x01
+#define CBC_CTX_STS_LAST 0x02
+#define CBC_CTX_STS_COMPLETE 0x04
+
+enum cbc_ctx_error {
+ CBC_CTX_ERROR_NONE = 0,
+ CBC_CTX_ERROR_INVALID_FLAGS = -1,
+ CBC_CTX_ERROR_ALREADY_PROCESSING = -2,
+ CBC_CTX_ERROR_ALREADY_COMPLETED = -3,
+};
+
+#define cbc_ctx_init(ctx, nbytes, op) \
+ do { \
+ (ctx)->flag = (op) | CBC_START; \
+ (ctx)->nbytes = nbytes; \
+ } while (0)
+
+/* AESNI routines to perform cbc decrypt and key expansion */
+
+asmlinkage void aesni_cbc_dec(struct crypto_aes_ctx *ctx, u8 *out,
+ const u8 *in, unsigned int len, u8 *iv);
+asmlinkage int aesni_set_key(struct crypto_aes_ctx *ctx, const u8 *in_key,
+unsigned int key_len);
+
+#endif /* __AES_CBC_MB_CTX_H */
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
new file mode 100644
index 000..0def82e
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
@@ -0,0 +1,131 @@
+/*
+ * Header file for multi buffer AES CBC algorithm manager
+ *
Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline
Waiman Long writes:
> If a system with large number of sockets was driven to full
> utilization, it was found that the clock tick handling occupied a
> rather significant proportion of CPU time when fair group scheduling
> and autogroup were enabled.
>
> Running a java benchmark on a 16-socket IvyBridge-EX system, the perf
> profile looked like:
>
> 10.52% 0.00% java [kernel.vmlinux] [k] smp_apic_timer_interrupt
>9.66% 0.05% java [kernel.vmlinux] [k] hrtimer_interrupt
>8.65% 0.03% java [kernel.vmlinux] [k] tick_sched_timer
>8.56% 0.00% java [kernel.vmlinux] [k] update_process_times
>8.07% 0.03% java [kernel.vmlinux] [k] scheduler_tick
>6.91% 1.78% java [kernel.vmlinux] [k] task_tick_fair
>5.24% 5.04% java [kernel.vmlinux] [k] update_cfs_shares
>
> In particular, the high CPU time consumed by update_cfs_shares()
> was mostly due to contention on the cacheline that contained the
> task_group's load_avg statistical counter. This cacheline may also
> contains variables like shares, cfs_rq & se which are accessed rather
> frequently during clock tick processing.
>
> This patch moves the load_avg variable into another cacheline
> separated from the other frequently accessed variables. It also
> creates a cacheline aligned kmemcache for task_group to make sure
> that all the allocated task_group's are cacheline aligned.
>
> By doing so, the perf profile became:
>
>9.44% 0.00% java [kernel.vmlinux] [k] smp_apic_timer_interrupt
>8.74% 0.01% java [kernel.vmlinux] [k] hrtimer_interrupt
>7.83% 0.03% java [kernel.vmlinux] [k] tick_sched_timer
>7.74% 0.00% java [kernel.vmlinux] [k] update_process_times
>7.27% 0.03% java [kernel.vmlinux] [k] scheduler_tick
>5.94% 1.74% java [kernel.vmlinux] [k] task_tick_fair
>4.15% 3.92% java [kernel.vmlinux] [k] update_cfs_shares
>
> The %cpu time is still pretty high, but it is better than before. The
> benchmark results before and after the patch was as follows:
>
> Before patch - Max-jOPs: 907533Critical-jOps: 134877
> After patch - Max-jOPs: 916011Critical-jOps: 142366
>
> Signed-off-by: Waiman Long
> ---
> kernel/sched/core.c | 36 ++--
> kernel/sched/sched.h |7 ++-
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 4d568ac..e39204f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7331,6 +7331,11 @@ int in_sched_functions(unsigned long addr)
> */
> struct task_group root_task_group;
> LIST_HEAD(task_groups);
> +
> +#ifdef CONFIG_FAIR_GROUP_SCHED
> +/* Cacheline aligned slab cache for task_group */
> +static struct kmem_cache *task_group_cache __read_mostly;
> +#endif
> #endif
>
> DECLARE_PER_CPU(cpumask_var_t, load_balance_mask);
> @@ -7356,6 +7361,7 @@ void __init sched_init(void)
> root_task_group.cfs_rq = (struct cfs_rq **)ptr;
> ptr += nr_cpu_ids * sizeof(void **);
>
> + task_group_cache = KMEM_CACHE(task_group, SLAB_HWCACHE_ALIGN);
The KMEM_CACHE macro suggests instead adding
cacheline_aligned_in_smp to the struct definition instead.
> #endif /* CONFIG_FAIR_GROUP_SCHED */
> #ifdef CONFIG_RT_GROUP_SCHED
> root_task_group.rt_se = (struct sched_rt_entity **)ptr;
> @@ -7668,12 +7674,38 @@ void set_curr_task(int cpu, struct task_struct *p)
> /* task_group_lock serializes the addition/removal of task groups */
> static DEFINE_SPINLOCK(task_group_lock);
>
> +/*
> + * Make sure that the task_group structure is cacheline aligned when
> + * fair group scheduling is enabled.
> + */
> +#ifdef CONFIG_FAIR_GROUP_SCHED
> +static inline struct task_group *alloc_task_group(void)
> +{
> + return kmem_cache_alloc(task_group_cache, GFP_KERNEL | __GFP_ZERO);
> +}
> +
> +static inline void free_task_group(struct task_group *tg)
> +{
> + kmem_cache_free(task_group_cache, tg);
> +}
> +#else /* CONFIG_FAIR_GROUP_SCHED */
> +static inline struct task_group *alloc_task_group(void)
> +{
> + return kzalloc(sizeof(struct task_group), GFP_KERNEL);
> +}
> +
> +static inline void free_task_group(struct task_group *tg)
> +{
> + kfree(tg);
> +}
> +#endif /* CONFIG_FAIR_GROUP_SCHED */
> +
> static void free_sched_group(struct task_group *tg)
> {
> free_fair_sched_group(tg);
> free_rt_sched_group(tg);
> autogroup_free(tg);
> - kfree(tg);
> + free_task_group(tg);
> }
>
> /* allocate runqueue etc for a new task group */
> @@ -7681,7 +7713,7 @@ struct task_group *sched_create_group(struct task_group
> *parent)
> {
> struct task_group *tg;
>
> - tg = kzalloc(sizeof(*tg), GFP_KERNEL);
> + tg = alloc_task_group();
> if (!tg)
> return ERR_PTR(-ENOMEM);
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index efd3bfc..e679895 100644
> --- a/kernel/sched/sched.h
> ++
[PATCH v4 5/5] crypto: AES CBC multi-buffer glue code
This patch introduces the multi-buffer job manager which is responsible for submitting scatter-gather buffers from several AES CBC jobs to the multi-buffer algorithm. The glue code interfaces with the underlying algorithm that handles 8 data streams of AES CBC encryption in parallel. AES key expansion and CBC decryption requests are performed in a manner similar to the existing AESNI Intel glue driver. The outline of the algorithm for AES CBC encryption requests is sketched below: Any driver requesting the crypto service will place an async crypto request on the workqueue. The multi-buffer crypto daemon will pull an AES CBC encryption request from work queue and put each request in an empty data lane for multi-buffer crypto computation. When all the empty lanes are filled, computation will commence on the jobs in parallel and the job with the shortest remaining buffer will get completed and be returned. To prevent prolonged stall, when no new jobs arrive, we will flush workqueue of jobs after a maximum allowable delay has elapsed. To accommodate the fragmented nature of scatter-gather, we will keep submitting the next scatter-buffer fragment for a job for multi-buffer computation until a job is completed and no more buffer fragments remain. At that time we will pull a new job to fill the now empty data slot. We check with the multibuffer scheduler to see if there are other completed jobs to prevent extraneous delay in returning any completed jobs. This multi-buffer algorithm should be used for cases where we get at least 8 streams of crypto jobs submitted at a reasonably high rate. For low crypto job submission rate and low number of data streams, this algorithm will not be beneficial. The reason is at low rate, we do not fill out the data lanes before flushing the jobs instead of processing them with all the data lanes full. We will miss the benefit of parallel computation, and adding delay to the processing of the crypto job at the same time. Some tuning of the maximum latency parameter may be needed to get the best performance. Originally-by: Chandramouli Narayanan Signed-off-by: Tim Chen --- arch/x86/crypto/Makefile| 1 + arch/x86/crypto/aes-cbc-mb/Makefile | 22 + arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 835 3 files changed, 858 insertions(+) create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index b9b912a..000db49 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_CRYPTO_CRC32_PCLMUL) += crc32-pclmul.o obj-$(CONFIG_CRYPTO_SHA256_SSSE3) += sha256-ssse3.o obj-$(CONFIG_CRYPTO_SHA512_SSSE3) += sha512-ssse3.o obj-$(CONFIG_CRYPTO_CRCT10DIF_PCLMUL) += crct10dif-pclmul.o +obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb/ obj-$(CONFIG_CRYPTO_POLY1305_X86_64) += poly1305-x86_64.o # These modules require assembler to support AVX. diff --git a/arch/x86/crypto/aes-cbc-mb/Makefile b/arch/x86/crypto/aes-cbc-mb/Makefile new file mode 100644 index 000..b642bd8 --- /dev/null +++ b/arch/x86/crypto/aes-cbc-mb/Makefile @@ -0,0 +1,22 @@ +# +# Arch-specific CryptoAPI modules. +# + +avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no) + +# we need decryption and key expansion routine symbols +# if either AESNI_NI_INTEL or AES_CBC_MB is a module + +ifeq ($(CONFIG_CRYPTO_AES_NI_INTEL),m) + dec_support := ../aesni-intel_asm.o +endif +ifeq ($(CONFIG_CRYPTO_AES_CBC_MB),m) + dec_support := ../aesni-intel_asm.o +endif + +ifeq ($(avx_supported),yes) + obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb.o + aes-cbc-mb-y := $(dec_support) aes_cbc_mb.o aes_mb_mgr_init.o \ + mb_mgr_inorder_x8_asm.o mb_mgr_ooo_x8_asm.o \ + aes_cbc_enc_x8.o +endif diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c new file mode 100644 index 000..4d16a5d --- /dev/null +++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c @@ -0,0 +1,835 @@ +/* + * Multi buffer AES CBC algorithm glue code + * + * + * This file is provided under a dual BSD/GPLv2 license. When using or + * redistributing this file, you may do so under either license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2015 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License 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. + * + * Contact Information: + * James Guilford + * Sean Gulley + * Tim Chen + */ + +#define pr_fmt(fmt)KBUILD_MODNAME "
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On 02/12/15 19:38, Florian Fainelli wrote: > 2015-12-02 11:05 GMT-08:00 Brian Norris : >> + Broadcom list + Kamal >> >> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote: >>> Add device tree binding for NAND on the BCM63268. >>> >>> The BCM63268 has a NAND interrupt register with combined status and enable >>> registers. >>> >>> Signed-off-by: Simon Arlott >>> --- >>> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 >>> ++ >>> 1 file changed, 35 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> index 4ff7128..f2a71c8 100644 >>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and >>> associated register resources w >>> and enable registers >>> - reg-names: (required) "nand-int-base" >>> >>> + * "brcm,nand-bcm63268" >>> + - compatible: should contain "brcm,nand-bcm", >>> "brcm,nand-bcm63268" >> >> Looks like you're aiming to support bcm63168? Is bcm63268 the first >> chip to include this style of register then? The numbering seems >> backwards, but that may just be reality. > > 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7, > 2009) and 6328 (v2.1, can't find release date) are earlier chips that > have an identical combined interrupt enable + status register and a > NAND controller within the same 32-bits word, so these would qualify > as a better compatible string for this specific addition integration > stub here. I would gowith 6368 here then? > I could change it to 6368 but there's no documented NAND_INTR_BASE for it. Only the 63268 and 6818 have a #define for NAND_INTR_BASE. -- Simon Arlott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/5] crypto: AES CBC multi-buffer scheduler
This patch implements in-order scheduler for encrypting multiple buffers in parallel supporting AES CBC encryption with key sizes of 128, 192 and 256 bits. It uses 8 data lanes by taking advantage of the SIMD instructions with XMM registers. The multibuffer manager and scheduler is mostly written in assembly and the initialization support is written C. The AES CBC multibuffer crypto driver support interfaces with the multibuffer manager and scheduler to support AES CBC encryption in parallel. The scheduler supports job submissions, job flushing and and job retrievals after completion. The basic flow of usage of the CBC multibuffer scheduler is as follows: - The caller allocates an aes_cbc_mb_mgr_inorder_x8 object and initializes it once by calling aes_cbc_init_mb_mgr_inorder_x8(). - The aes_cbc_mb_mgr_inorder_x8 structure has an array of JOB_AES objects. Allocation and scheduling of JOB_AES objects are managed by the multibuffer scheduler support routines. The caller allocates a JOB_AES using aes_cbc_get_next_job_inorder_x8(). - The returned JOB_AES must be filled in with parameters for CBC encryption (eg: plaintext buffer, ciphertext buffer, key, iv, etc) and submitted to the manager object using aes_cbc_submit_job_inorder_xx(). - If the oldest JOB_AES is completed during a call to aes_cbc_submit_job_inorder_x8(), it is returned. Otherwise, NULL is returned. - A call to aes_cbc_flush_job_inorder_x8() always returns the oldest job, unless the multibuffer manager is empty of jobs. - A call to aes_cbc_get_completed_job_inorder_x8() returns a completed job. This routine is useful to process completed jobs instead of waiting for the flusher to engage. - When a job is returned from submit or flush, the caller extracts the useful data and returns it to the multibuffer manager implicitly by the next call to aes_cbc_get_next_job_xx(). Jobs are always returned from submit or flush routines in the order they were submitted (hence "inorder").A job allocated using aes_cbc_get_next_job_inorder_x8() must be filled in and submitted before another call. A job returned by aes_cbc_submit_job_inorder_x8() or aes_cbc_flush_job_inorder_x8() is 'deallocated' upon the next call to get a job structure. Calls to get_next_job() cannot fail. If all jobs are allocated after a call to get_next_job(), the subsequent call to submit always returns the oldest job in a completed state. Originally-by: Chandramouli Narayanan Signed-off-by: Tim Chen --- arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 +++ arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 +++ arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416 + 3 files changed, 783 insertions(+) create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S diff --git a/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c new file mode 100644 index 000..7a7f8a1 --- /dev/null +++ b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c @@ -0,0 +1,145 @@ +/* + * Initialization code for multi buffer AES CBC algorithm + * + * + * This file is provided under a dual BSD/GPLv2 license. When using or + * redistributing this file, you may do so under either license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2015 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License 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. + * + * Contact Information: + * James Guilford + * Sean Gulley + * Tim Chen + * + * BSD LICENSE + * + * Copyright(c) 2015 Intel Corporation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE
[PATCH v4 4/5] crypto: AES CBC by8 encryption
This patch introduces the assembly routine to do a by8 AES CBC encryption in support of the AES CBC multi-buffer implementation. Encryption of 8 data streams of a key size are done simultaneously. Originally-by: Chandramouli Narayanan Signed-off-by: Tim Chen --- arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S | 774 1 file changed, 774 insertions(+) create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S new file mode 100644 index 000..eaffc28 --- /dev/null +++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S @@ -0,0 +1,774 @@ +/* + * AES CBC by8 multibuffer optimization (x86_64) + * This file implements 128/192/256 bit AES CBC encryption + * + * + * This file is provided under a dual BSD/GPLv2 license. When using or + * redistributing this file, you may do so under either license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2015 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License 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. + * + * Contact Information: + * James Guilford + * Sean Gulley + * Tim Chen + * + * BSD LICENSE + * + * Copyright(c) 2015 Intel Corporation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + */ +#include + +/* stack size needs to be an odd multiple of 8 for alignment */ + +#define AES_KEYSIZE_12816 +#define AES_KEYSIZE_19224 +#define AES_KEYSIZE_25632 + +#define XMM_SAVE_SIZE 16*10 +#define GPR_SAVE_SIZE 8*9 +#define STACK_SIZE (XMM_SAVE_SIZE + GPR_SAVE_SIZE) + +#define GPR_SAVE_REG %rsp +#define GPR_SAVE_AREA %rsp + XMM_SAVE_SIZE +#define LEN_AREA_OFFSETXMM_SAVE_SIZE + 8*8 +#define LEN_AREA_REG %rsp +#define LEN_AREA %rsp + XMM_SAVE_SIZE + 8*8 + +#define IN_OFFSET 0 +#define OUT_OFFSET 8*8 +#define KEYS_OFFSET16*8 +#define IV_OFFSET 24*8 + + +#define IDX%rax +#define TMP%rbx +#define ARG%rdi +#define LEN%rsi + +#define KEYS0 %r14 +#define KEYS1 %r15 +#define KEYS2 %rbp +#define KEYS3 %rdx +#define KEYS4 %rcx +#define KEYS5 %r8 +#define KEYS6 %r9 +#define KEYS7 %r10 + +#define IN0%r11 +#define IN2%r12 +#define IN4%r13 +#define IN6LEN + +#define XDATA0 %xmm0 +#define XDATA1 %xmm1 +#define XDATA2 %xmm2 +#define XDATA3 %xmm3 +#define XDATA4 %xmm4 +#define XDATA5 %xmm5 +#define XDATA6 %xmm6 +#define XDATA7 %xmm7 + +#define XKEY0_3%xmm8 +#define XKEY1_4%xmm9 +#define XKEY2_5%xmm10 +#define XKEY3_6%xmm11 +#define XKEY4_7%xmm12 +#define XKEY5_8%xmm13 +#define XKEY6_9%xmm14 +#define XTMP %xmm15 + +#defineMOVDQ movdqu /* assume buffers not aligned */ +#define CONCAT(a, b) a##b +#define INPUT_REG_SUFX 1 /* IN */ +#define XDATA_REG_SUFX 2 /* XDAT */ +#define KEY_REG_SUFX 3 /* KEY */ +#define XMM_REG_SUFX 4 /* XMM */ + +/* + * To avoid positional parameter errors while compiling + * three registers need to be passed + */ +.text + +.macro pxor2 x, y, z + MOVDQ (\x,\y), XTMP + pxorXTMP, \z +.endm + +.macro inreg n
Re: [PATCH Resend] VMW_PVSCSI: Fix the issue of DMA-API related warnings.
The suggestions look reasonable to me too.
>Arvind, since I was originally just resending your patch, do you want
>to make the changes Johannes suggests, or should I proceed with that?
> josh
Hi Josh,
Feel free to send out the updated patch if you would like.
Thanks!
Arvind
From: jwbo...@gmail.com on behalf of Josh Boyer
Sent: Wednesday, December 2, 2015 5:47 AM
To: Johannes Thumshirn
Cc: Jej B; Arvind Kumar; Thomas Hellstrom; linux-s...@vger.kernel.org; VMware
PV-Drivers; Linux-Kernel@Vger. Kernel. Org
Subject: Re: [PATCH Resend] VMW_PVSCSI: Fix the issue of DMA-API related
warnings.
On Wed, Dec 2, 2015 at 3:42 AM, Johannes Thumshirn wrote:
> Hi Josh,
>
> On Tue, 2015-12-01 at 11:34 -0500, Josh Boyer wrote:
>> The driver is missing calls to pci_dma_mapping_error() after
>> performing the DMA mapping, which caused DMA-API warning to
>> show up in dmesg's output. Though that happens only when
>> DMA_API_DEBUG option is enabled. This change fixes the issue
>> and makes pvscsi_map_buffers() function more robust.
>>
>> Signed-off-by: Arvind Kumar
>> Cc: Josh Boyer
>> Reviewed-by: Thomas Hellstrom
>> Signed-off-by: Josh Boyer
>> ---
>>
>> - Resend of patch that was never committed for some reason
>>
>> drivers/scsi/vmw_pvscsi.c | 45 +++--
>> drivers/scsi/vmw_pvscsi.h | 2 +-
>> 2 files changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
>> index 0f133c1817de..19734494f9ec 100644
>> --- a/drivers/scsi/vmw_pvscsi.c
>> +++ b/drivers/scsi/vmw_pvscsi.c
>> @@ -349,9 +349,9 @@ static void pvscsi_create_sg(struct pvscsi_ctx *ctx,
>> * Map all data buffers for a command into PCI space and
>> * setup the scatter/gather list if needed.
>> */
>> -static void pvscsi_map_buffers(struct pvscsi_adapter *adapter,
>> -struct pvscsi_ctx *ctx, struct scsi_cmnd
>> *cmd,
>> -struct PVSCSIRingReqDesc *e)
>> +static int pvscsi_map_buffers(struct pvscsi_adapter *adapter,
>> + struct pvscsi_ctx *ctx, struct scsi_cmnd *cmd,
>> + struct PVSCSIRingReqDesc *e)
>> {
>> unsigned count;
>> unsigned bufflen = scsi_bufflen(cmd);
>> @@ -360,18 +360,30 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
>> *adapter,
>> e->dataLen = bufflen;
>> e->dataAddr = 0;
>> if (bufflen == 0)
>> - return;
>> + return 0;
>>
>> sg = scsi_sglist(cmd);
>> count = scsi_sg_count(cmd);
>> if (count != 0) {
>> int segs = scsi_dma_map(cmd);
>> - if (segs > 1) {
>> +
>> + if (segs == -ENOMEM) {
>> + scmd_printk(KERN_ERR, cmd,
>> + "vmw_pvscsi: Failed to map cmd sglist
>> for DMA.\n");
>> + return -1;
>
> Please return -ENOMEM instead of -1
>
>> + } else if (segs > 1) {
>> pvscsi_create_sg(ctx, sg, segs);
>>
>> e->flags |= PVSCSI_FLAG_CMD_WITH_SG_LIST;
>> ctx->sglPA = pci_map_single(adapter->dev, ctx->sgl,
>> SGL_SIZE,
>> PCI_DMA_TODEVICE);
>> + if (pci_dma_mapping_error(adapter->dev, ctx->sglPA))
>> {
>> + scmd_printk(KERN_ERR, cmd,
>> + "vmw_pvscsi: Failed to map ctx
>> sglist for DMA.\n");
>> + scsi_dma_unmap(cmd);
>> + ctx->sglPA = 0;
>> + return -1;
>
> Same here.
>
>> + }
>> e->dataAddr = ctx->sglPA;
>> } else
>> e->dataAddr = sg_dma_address(sg);
>> @@ -382,8 +394,15 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
>> *adapter,
>>*/
>> ctx->dataPA = pci_map_single(adapter->dev, sg, bufflen,
>>cmd->sc_data_direction);
>> + if (pci_dma_mapping_error(adapter->dev, ctx->dataPA)) {
>> + scmd_printk(KERN_ERR, cmd,
>> + "vmw_pvscsi: Failed to map direct data
>> buffer for DMA.\n");
>> + return -1;
>
> And here.
>
>> + }
>> e->dataAddr = ctx->dataPA;
>> }
>> +
>> + return 0;
>> }
>>
>> static void pvscsi_unmap_buffers(const struct pvscsi_adapter *adapter,
>> @@ -690,6 +709,12 @@ static int pvscsi_queue_ring(struct pvscsi_adapter
>> *adapter,
>> ctx->sensePA = pci_map_single(adapter->dev, cmd-
>> >sense_buffer,
>> SCSI_SENSE_BUFFERSIZE,
>> PCI_DMA_FROMDEVICE);
>> + if (pci_dma_mapping_error(adapter->dev, ctx->sensePA)) {
>> +
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Brian Norris [151202 10:14]: > On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote: > > * Roger Quadros [151201 21:13]: > > > On 02/12/15 08:56, Brian Norris wrote: > > > > > > > > I'll take another pass over your patch set, but if things are looking > > > > better, how do you expect to merge this? There are significant portions > > > > that touch at least 2 or 3 different subsystem trees, AFAICT. > > > > > > Tony could create an immutable branch with all the dts and memory changes. > > > You could base the mtd changes on top of that? > > > > If we all agree on that it will be immutable Roger can set up the branch > > with our acks and we can all merge it in as needed. I believe v4.4-rc1 > > should work as a base for us all? > > There are oustanding comments about the NAND ready/busy GPIO naming in > patch 18, which I'd like addressed. I'll re-review the rest before the > end of the day (West Coast U.S.A.). I'm not sure my acks are worth much > beyond the MTD stuff. OK, I'm happy with the gpmc related parts. > Regarding branches, 4.4-rc1 is fine with me. OK Thanks, Tony -- 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 5/5] crypto: AES CBC multi-buffer glue code
On Tue, 2015-12-01 at 09:19 -0800, Tim Chen wrote: > On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote: > > On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote: > > > > > > On the decrypt path, we don't need to use multi-buffer algorithm > > > as aes-cbc decrypt can be parallelized inherently on a single > > > request. So most of the time the outer layer algorithm > > > cbc_mb_async_ablk_decrypt can bypass mcryptd and > > > invoke mb_aes_cbc_decrypt synchronously > > > to do aes_cbc_dec when fpu is available. > > > This avoids the overhead of going through mcryptd. Hence > > > the use of blkcipher on the inner layer. For the mcryptd > > > path, we will complete a decrypt request in one shot so > > > blkcipher usage should be fine. > > > > I think there is a misunderstanding here. Just because you're > > using/exporting through the ablkcipher interface doesn't mean > > that you are asynchrounous. For example, all blkcipher algorithms > > can be accessed through the ablkcipher interface and they of course > > remain synchrounous. > > > > So I don't see how using an ablkcipher in the inner layer changes > > anything at all. You can still return immediately and not bother > > with completion functions when you are synchrounous. > > > > Cheers, > > OK, I'll try to see if I can cast things back to the original ablkcipher > request and use that to walk the sg list. > Herbert, I've sent out a new version of this series to use ablkcipher on the inner layer of decrypt. Thanks. Tim -- 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/
Skylake (XPS 13 9350) TSC is way off
[0.00] tsc: PIT calibration matches HPET. 2 loops [0.00] tsc: Detected 2399.975 MHz processor [0.090897] TSC deadline timer enabled [1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz [1.960039] clocksource: tsc: mask: 0x max_cycles: 0x22983e30402, max_idle_ns: 440795260848 ns [2.959936] clocksource: Switched to clocksource tsc [ 87.168211] Adjusting tsc more than 11% (5941981 vs 7759439) This is more or less Linus' latest tree (v4.4-rc3 plus some unrelated platform driver patches). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/8] android_pipe: don't be clever with #define offsets
On Wed, 2015-12-02 at 11:35 -0800, Jin Qian wrote:
> From: Alex Bennée
>
> You just make it harder to figure out when commands are being used.
>
> Signed-off-by: Alex Bennée
> Signed-off-by: Jin Qian
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> b/drivers/platform/goldfish/goldfish_pipe.c
> index e7a29e2..0fb3a34 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -90,12 +90,6 @@
> #define CMD_WRITE_BUFFER 4 /* send a user buffer to the emulator */
> #define CMD_WAKE_ON_WRITE5 /* tell the emulator to wake us when writing
> is possible */
> -
> -/* The following commands are related to read operations, they must be
> - * listed in the same order than the corresponding write ones, since we
> - * will use (CMD_READ_BUFFER - CMD_WRITE_BUFFER) as a special offset
> - * in goldfish_pipe_read_write() below.
> - */
> #define CMD_READ_BUFFER6 /* receive a user buffer from the emulator
> */
> #define CMD_WAKE_ON_READ 7 /* tell the emulator to wake us when
> reading
> * is possible */
> @@ -272,8 +266,6 @@ static ssize_t goldfish_pipe_read_write(struct file
> *filp, char __user *buffer,
> unsigned long irq_flags;
> struct goldfish_pipe *pipe = filp->private_data;
> struct goldfish_pipe_dev *dev = pipe->dev;
> - const int cmd_offset = is_write ? 0
> - : (CMD_READ_BUFFER - CMD_WRITE_BUFFER);
This one could be
int cmd_type = is_write ? CMD_WRITE_BUFFER : CMD_READ_BUFFER;
@@ -325,7 +317,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
>
> /* Now, try to transfer the bytes in the current page */
> spin_lock_irqsave(&dev->lock, irq_flags);
> - if (access_with_param(dev, CMD_WRITE_BUFFER + cmd_offset,
> + if (access_with_param(dev,
> + is_write ? CMD_WRITE_BUFFER : CMD_READ_BUFFER,
> address, avail, pipe, &status)) {
> gf_write_ptr(pipe, dev->base + PIPE_REG_CHANNEL,
> dev->base + PIPE_REG_CHANNEL_HIGH);
> @@ -333,7 +326,7 @@ static ssize_t goldfish_pipe_read_write(struct file
> *filp, char __user *buffer,
> gf_write_ptr((void *)address,
> dev->base + PIPE_REG_ADDRESS,
> dev->base + PIPE_REG_ADDRESS_HIGH);
> - writel(CMD_WRITE_BUFFER + cmd_offset,
> + writel(is_write ? CMD_WRITE_BUFFER : CMD_READ_BUFFER,
> dev->base + PIPE_REG_COMMAND);
> status = readl(dev->base + PIPE_REG_STATUS);
> }
and the loop could use cmd_type instead of the ?:
> @@ -370,7 +363,8 @@ static ssize_t goldfish_pipe_read_write(struct file
> *filp, char __user *buffer,
> set_bit(wakeBit, &pipe->flags);
>
> /* Tell the emulator we're going to wait for a wake event */
> - goldfish_cmd(pipe, CMD_WAKE_ON_WRITE + cmd_offset);
> + goldfish_cmd(pipe,
> + is_write ? CMD_WAKE_ON_WRITE : CMD_WAKE_ON_READ);
>
> /* Unlock the pipe, then wait for the wake signal */
> mutex_unlock(&pipe->lock);
--
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 "regulator: wm831x-ldo: Use platform_register/unregister_drivers()" to the regulator tree
The patch
regulator: wm831x-ldo: Use platform_register/unregister_drivers()
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 92a513b79f942dd86f906512352e2c6d7eca1d8b Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 2 Dec 2015 17:32:53 +0100
Subject: [PATCH] regulator: wm831x-ldo: Use
platform_register/unregister_drivers()
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding
Signed-off-by: Mark Brown
---
drivers/regulator/wm831x-ldo.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/wm831x-ldo.c b/drivers/regulator/wm831x-ldo.c
index 5a7b65e8a529..9ad2a29617e2 100644
--- a/drivers/regulator/wm831x-ldo.c
+++ b/drivers/regulator/wm831x-ldo.c
@@ -653,32 +653,21 @@ static struct platform_driver wm831x_alive_ldo_driver = {
},
};
+static struct platform_driver * const drivers[] = {
+ &wm831x_gp_ldo_driver,
+ &wm831x_aldo_driver,
+ &wm831x_alive_ldo_driver,
+};
+
static int __init wm831x_ldo_init(void)
{
- int ret;
-
- ret = platform_driver_register(&wm831x_gp_ldo_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x GP LDO driver: %d\n", ret);
-
- ret = platform_driver_register(&wm831x_aldo_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x ALDO driver: %d\n", ret);
-
- ret = platform_driver_register(&wm831x_alive_ldo_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x alive LDO driver: %d\n",
- ret);
-
- return 0;
+ return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
}
subsys_initcall(wm831x_ldo_init);
static void __exit wm831x_ldo_exit(void)
{
- platform_driver_unregister(&wm831x_alive_ldo_driver);
- platform_driver_unregister(&wm831x_aldo_driver);
- platform_driver_unregister(&wm831x_gp_ldo_driver);
+ platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
}
module_exit(wm831x_ldo_exit);
--
2.6.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/
Applied "regulator: wm831x-dcdc: Use platform_register/unregister_drivers()" to the regulator tree
The patch
regulator: wm831x-dcdc: Use platform_register/unregister_drivers()
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 55e03e9c2d6909fd449cdcec9e933f6907f4820e Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 2 Dec 2015 17:32:52 +0100
Subject: [PATCH] regulator: wm831x-dcdc: Use
platform_register/unregister_drivers()
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding
Signed-off-by: Mark Brown
---
drivers/regulator/wm831x-dcdc.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 8cbb82ceec40..05f69d1ede19 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -884,35 +884,22 @@ static struct platform_driver wm831x_epe_driver = {
},
};
+static struct platform_driver * const drivers[] = {
+ &wm831x_buckv_driver,
+ &wm831x_buckp_driver,
+ &wm831x_boostp_driver,
+ &wm831x_epe_driver,
+};
+
static int __init wm831x_dcdc_init(void)
{
- int ret;
- ret = platform_driver_register(&wm831x_buckv_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x BUCKV driver: %d\n", ret);
-
- ret = platform_driver_register(&wm831x_buckp_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x BUCKP driver: %d\n", ret);
-
- ret = platform_driver_register(&wm831x_boostp_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x BOOST driver: %d\n", ret);
-
- ret = platform_driver_register(&wm831x_epe_driver);
- if (ret != 0)
- pr_err("Failed to register WM831x EPE driver: %d\n", ret);
-
- return 0;
+ return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
}
subsys_initcall(wm831x_dcdc_init);
static void __exit wm831x_dcdc_exit(void)
{
- platform_driver_unregister(&wm831x_epe_driver);
- platform_driver_unregister(&wm831x_boostp_driver);
- platform_driver_unregister(&wm831x_buckp_driver);
- platform_driver_unregister(&wm831x_buckv_driver);
+ platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
}
module_exit(wm831x_dcdc_exit);
--
2.6.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: xfstests failures with xfs, dax and v4.4-rc3
On Wed, Dec 2, 2015 at 10:34 AM, Ross Zwisler wrote: > I'm hitting a few more test failures in my testing setup with v4.4-rc3, xfs > and DAX. My test setup is a pair of 4GiB PMEM partitions in a KVM virtual > machine. Here are the failures: > Is this a passing test with a v4.3 baseline? git bisect? -- 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 "regulator: core: Fix nested locking of supplies" to the regulator tree
The patch
regulator: core: Fix nested locking of supplies
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 2 Dec 2015 16:54:50 +0100
Subject: [PATCH] regulator: core: Fix nested locking of supplies
Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning")
introduced a subtle change in how supplies are locked. Where previously
code was always locking the regulator of the current iteration, the new
implementation only locks the regulator if it has a supply. For any
given power tree that means that the root will never get locked.
On the other hand the regulator_unlock_supply() will still release all
the locks, which in turn causes the lock debugging code to warn about a
mutex being unlocked which wasn't locked.
Cc: Mark Brown
Cc: Arnd Bergmann
Fixes: Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning")
Signed-off-by: Thierry Reding
Signed-off-by: Mark Brown
---
drivers/regulator/core.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f71db02fcb71..732ac71b82cd 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -132,6 +132,14 @@ static bool have_full_constraints(void)
return has_full_constraints || of_have_populated_dt();
}
+static inline struct regulator_dev *rdev_get_supply(struct regulator_dev *rdev)
+{
+ if (rdev && rdev->supply)
+ return rdev->supply->rdev;
+
+ return NULL;
+}
+
/**
* regulator_lock_supply - lock a regulator and its supplies
* @rdev: regulator source
@@ -140,8 +148,7 @@ static void regulator_lock_supply(struct regulator_dev
*rdev)
{
int i;
- mutex_lock(&rdev->mutex);
- for (i = 1; rdev; rdev = rdev->supply->rdev, i++)
+ for (i = 0; rdev; rdev = rdev_get_supply(rdev), i++)
mutex_lock_nested(&rdev->mutex, i);
}
--
2.6.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/
Applied "regulator: lp8788-ldo: Use platform_register/unregister_drivers()" to the regulator tree
The patch
regulator: lp8788-ldo: Use platform_register/unregister_drivers()
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 7629cef11200bccb63ce5a629a4d0602e7f8 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 2 Dec 2015 17:32:51 +0100
Subject: [PATCH] regulator: lp8788-ldo: Use
platform_register/unregister_drivers()
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding
Signed-off-by: Mark Brown
---
drivers/regulator/lp8788-ldo.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index 9f22d079c8cc..30e28b131126 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -613,22 +613,20 @@ static struct platform_driver lp8788_aldo_driver = {
},
};
+static struct platform_driver * const drivers[] = {
+ &lp8788_dldo_driver,
+ &lp8788_aldo_driver,
+};
+
static int __init lp8788_ldo_init(void)
{
- int ret;
-
- ret = platform_driver_register(&lp8788_dldo_driver);
- if (ret)
- return ret;
-
- return platform_driver_register(&lp8788_aldo_driver);
+ return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
}
subsys_initcall(lp8788_ldo_init);
static void __exit lp8788_ldo_exit(void)
{
- platform_driver_unregister(&lp8788_aldo_driver);
- platform_driver_unregister(&lp8788_dldo_driver);
+ platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
}
module_exit(lp8788_ldo_exit);
--
2.6.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 (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On 02/12/15 20:00, Brian Norris wrote:
> Hi,
>
> On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
>> >> + nand0: nandcs@0 {
>> >> + compatible = "brcm,nandcs";
>> >> +
>> >> + #address-cells = <0>;
>> >> + #size-cells = <0>;
>
>> I think they're also implicit so you can just remove those two lines.
>
> From ePAPR: "The #address-cells and #size-cells properties are not
> inherited from ancestors in the device tree. They shall be explicitly
> defined."
>
> But we don't want to define them. I'd drop them, at least from the
> example, as they're not relevant.
Ok.
>> I've created a bcm963268part driver so there won't need to be any
>> partitions in DT for bcm63268.
>
> Just curious, do you plan to submit this driver? We're working on
Yes, it's just the most recent one I've been working on. I still have
USBH and IUDMA to submit
> matching up partition parsers to flash devices via device tree
> of_match_table's, so you could do something like this:
>
> nand0: nandcs@0 {
> compatible = "brcm,nandcs";
> ...
>
> partitions {
> compatible = "brcm,bcm963268-partitions";
> ...
> };
> };
I modified brcmnand to look for a machine matching "brcm,bcm963268", but
that way is ok with me. Presumably "ofpart" defers to another matching
partition parser?
Is there a patch for that method of parser detection available?
--
Simon Arlott
--
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 (v7) 2/2] mtd: brcmnand: Add support for the BCM63268
Hi,
On Wed, Dec 02, 2015 at 07:54:49PM +, Simon Arlott wrote:
> On 02/12/15 19:18, Brian Norris wrote:
> > On Wed, Nov 25, 2015 at 07:49:13PM +, Simon Arlott wrote:
> >> +static int bcm63268_nand_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = &pdev->dev;
> >> + struct bcm63268_nand_soc *priv;
> >> + struct brcmnand_soc *soc;
> >> + struct resource *res;
> >> + int ret;
> >> +
> >> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> >> + if (!priv)
> >> + return -ENOMEM;
> >> + soc = &priv->soc;
> >> +
> >> + res = platform_get_resource_byname(pdev,
> >> + IORESOURCE_MEM, "nand-intr-base");
> >> + if (!res)
> >> + return -EINVAL;
> >> +
> >> + priv->base = devm_ioremap_resource(dev, res);
> >> + if (IS_ERR(priv->base))
> >> + return PTR_ERR(priv->base);
> >> +
> >> + priv->clk = devm_clk_get(&pdev->dev, "nand");
> >> + if (IS_ERR(priv->clk))
> >> + return PTR_ERR(priv->clk);
> >
> > Perhaps we should put this clock handling in brcmnand.c? Just have it
> > treat the clock as optional (i.e., ignore errors except for
> > EPROBE_DEFER?), so we don't fail if no clock was provided? This could
> > help other platforms too, if they gain clock support.
>
> Unless most soc variants have clocks I'd prefer to leave it in this
> module.
I'm quite confident your SoC is not the only one with clocks.
> > If we do this, you'll want to document the clock in the common binding,
> > not the bcm63268-specific part.
> >
> > Also, could it help to disable/enable the clock during suspend/resume?
> > If you move it to brcmnand.c, this would also be pretty simple.
>
> Alternatively, it could proxy the brcmnand_pm_ops functions. I don't
> have any way to test suspend/resume.
OK, no need to add it now then. It can be added if/when it's needed.
> >> +
> >> + ret = clk_prepare_enable(priv->clk);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + soc->ctlrdy_ack = bcm63268_nand_intc_ack;
> >> + soc->ctlrdy_set_enabled = bcm63268_nand_intc_set;
> >> +
> >> + /* Disable and ack all interrupts */
> >> + brcmnand_writel(0, priv->base + BCM63268_NAND_INT);
> >> + brcmnand_writel(BCM63268_NAND_STATUS_MASK,
> >> + priv->base + BCM63268_NAND_INT);
> >> +
> >> + ret = brcmnand_probe(pdev, soc);
> >> + if (ret)
> >> + clk_disable_unprepare(priv->clk);
> >> +
> >> + return ret;
> >> +}
> >> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> >> b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> index 2c8f67f..5f26b8a 100644
> >> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> @@ -2262,6 +2262,14 @@ int brcmnand_probe(struct platform_device *pdev,
> >> struct brcmnand_soc *soc)
> >> }
> >> EXPORT_SYMBOL_GPL(brcmnand_probe);
> >>
> >> +struct brcmnand_soc *brcmnand_get_socdata(struct platform_device *pdev)
> >> +{
> >> + struct brcmnand_controller *ctrl = dev_get_drvdata(&pdev->dev);
> >> +
> >> + return ctrl ? ctrl->soc : NULL;
> >> +}
> >> +EXPORT_SYMBOL_GPL(brcmnand_get_socdata);
> >
> > If you move the clk handling to the core brcmnand.c, then you won't need
> > this still.
>
> Would you prefer a clock name in the soc data structure that is used to
> call devm_clk_get()?
Not really. If we specify a clock name now, we can suggest other SoC's
to use the same name (where possible). So we wouldn't need any new code
or documentation, and we definitely don't need each snowflake sub-driver
to pass a new name.
Brian
--
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 "regulator: core: Ensure we lock all regulators" to the regulator tree
The patch regulator: core: Ensure we lock all regulators has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 49a6bb7a1c0963f260e4b0dcc2c0e56ec65a28b2 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Tue, 1 Dec 2015 15:51:52 + Subject: [PATCH] regulator: core: Ensure we lock all regulators The latest workaround for the lockdep interface's not using the second argument of mutex_lock_nested() changed the loop missed locking the last regulator due to a thinko with the loop termination condition exiting one regulator too soon. Reported-by: Tyler Baker Signed-off-by: Mark Brown --- drivers/regulator/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index da83ced2..f71db02fcb71 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -141,7 +141,7 @@ static void regulator_lock_supply(struct regulator_dev *rdev) int i; mutex_lock(&rdev->mutex); - for (i = 1; rdev->supply; rdev = rdev->supply->rdev, i++) + for (i = 1; rdev; rdev = rdev->supply->rdev, i++) mutex_lock_nested(&rdev->mutex, i); } -- 2.6.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 v2] Input: atmel_mxt_ts - Add maxtouch to I2C table for module autoload
Hello Dmitry,
On 11/20/2015 04:46 PM, Javier Martinez Canillas wrote:
> On 11/20/2015 04:32 PM, Javier Martinez Canillas wrote:
>
> [snip]
>
>>
>> But is not complete because the .driver_data in i2c_device_id is an
>> kernel_ulong_t while the .data in of_device_id is a const void * so
>> some casting will be needed to add an OF table in some drivers that
>
> Some casting in the tables *and* some logic to get the .data from the
> OF table entries, so something like the following will be needed:
>
> static int foo_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> struct of_device_id *match;
> kernel_ulong_t data;
>
> if (i2c->dev.of_node) {
>match = of_match_node(of_match, i2c->dev.of_node);
> if (!match)
> return -EINVAL;
>
>data = (kernel_ulong_t)match->data;
> } else {
>data = id->driver_data;
> }
> ...
> }
>
> while currently I2C drivers just rely on the model part of the compatible
> string to match with the entry in the I2C device ID table and the core
> always passing the correct .driver_data to the probe function.
>
> So as you can see, converting all the drivers to not rely on the I2C table
> requires some refactoring before proper OF modalias reporting can be used.
>
Any comments about this? I'm planning to address all this at some point but
for now I think we would need $SUBJECT to have module autoloading working
on this driver when the device is registered via OF.
> Best regards,
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/4] dm verity: separate function for parsing opt args
On Wed, Nov 04 2015 at 9:02P -0500,
Sami Tolvanen wrote:
> Move optional argument parsing into a separate function to make it
> easier to add more of them without making verity_ctr even longer.
>
> Signed-off-by: Sami Tolvanen
I've taken this patch, for Linux 4.5, but I've applied the following
incremental patch ontop to make verity's optional argument parsing
follow establish DM patterns (the code is very similar to
dm-mpath.c:parse_features). Your follow-on patches will obviously need
to be rebased on this, but the code will be much cleaner.
diff --git a/drivers/md/dm-verity.c b/drivers/md/dm-verity.c
index 3b09e50..2b0008f 100644
--- a/drivers/md/dm-verity.c
+++ b/drivers/md/dm-verity.c
@@ -723,19 +723,42 @@ static void verity_dtr(struct dm_target *ti)
kfree(v);
}
-static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,
-const char *opt_string)
+static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v)
{
- if (!strcasecmp(opt_string, DM_VERITY_OPT_LOGGING)) {
- v->mode = DM_VERITY_MODE_LOGGING;
- return 0;
- } else if (!strcasecmp(opt_string, DM_VERITY_OPT_RESTART)) {
- v->mode = DM_VERITY_MODE_RESTART;
+ int r;
+ unsigned argc;
+ struct dm_target *ti = v->ti;
+ const char *arg_name;
+
+ static struct dm_arg _args[] = {
+ {0, DM_VERITY_OPTS_MAX, "Invalid number of feature args"},
+ };
+
+ r = dm_read_arg_group(_args, &as, &argc, &ti->error);
+ if (r)
+ return -EINVAL;
+
+ if (!argc)
return 0;
- }
- v->ti->error = "Invalid feature arguments";
- return -EINVAL;
+ do {
+ arg_name = dm_shift_arg(&as);
+ argc--;
+
+ if (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING)) {
+ v->mode = DM_VERITY_MODE_LOGGING;
+ continue;
+
+ } else if (!strcasecmp(arg_name, DM_VERITY_OPT_RESTART)) {
+ v->mode = DM_VERITY_MODE_RESTART;
+ continue;
+ }
+
+ ti->error = "Unrecognized verity feature request";
+ return -EINVAL;
+ } while (argc && !r);
+
+ return r;
}
/*
@@ -757,17 +780,13 @@ static int verity_ctr(struct dm_target *ti, unsigned
argc, char **argv)
struct dm_verity *v;
struct dm_arg_set as;
const char *opt_string;
- unsigned int num, opt_params;
+ unsigned int num;
unsigned long long num_ll;
int r;
int i;
sector_t hash_position;
char dummy;
- static struct dm_arg _args[] = {
- {0, DM_VERITY_OPTS_MAX, "Invalid number of feature args"},
- };
-
v = kzalloc(sizeof(struct dm_verity), GFP_KERNEL);
if (!v) {
ti->error = "Cannot allocate verity structure";
@@ -912,25 +931,9 @@ static int verity_ctr(struct dm_target *ti, unsigned argc,
char **argv)
as.argc = argc;
as.argv = argv;
- r = dm_read_arg_group(_args, &as, &opt_params, &ti->error);
- if (r)
+ r = verity_parse_opt_args(&as, v);
+ if (r < 0)
goto bad;
-
- while (opt_params) {
- opt_params--;
- opt_string = dm_shift_arg(&as);
- if (!opt_string) {
- ti->error = "Not enough feature arguments";
- r = -EINVAL;
- goto bad;
- }
-
- r = verity_parse_opt_args(&as, v, opt_string);
- if (r < 0)
- goto bad;
-
- opt_params -= r;
- }
}
v->hash_per_block_bits =
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the staging tree with the tree
Hi Greg, Today's linux-next merge of the staging tree got a conflict in drivers/staging/rtl8188eu/include/phy.h between Linus' tree and commit "staging: rtl8188eu: using unique names is good" from the staging tree. It looks like the patch is already applied so I skipped it. pgpZt49LSNUZq.pgp Description: PGP signature
Re: [PATCH] mtd: brcmnand: Workaround false ECC uncorrectable errors
On 01/12/15 10:41, Jonas Gorski wrote: > On Sat, Nov 28, 2015 at 8:23 PM, Simon Arlott wrote: >> + >> + /* Go to start of buffer */ >> + buf -= FC_WORDS; >> + >> + /* Erased if all data bytes are 0xFF */ >> + buf_erased = memchr_inv(buf, 0xFF, FC_WORDS) == NULL; >> + >> + if (!buf_erased) >> + goto out_free; > > We now have a function exactly for that use case in 4.4, > nand_check_erased_buf [1], consider using that. This also has the > benefit of treating bit flips as correctable as long as the ECC scheme > is strong enough. I have no idea whether or not it's appropriate to specify bitflips_threshold > 0 so it'd just be a more complex way to do a memchr_inv() search for 0xFF. The code also has to check for the hamming code bytes being all 0x00, because according to the comments [2], the controller also has difficulty with the non-erased all-0xFFs scenario too. [2] https://github.com/lp0/bcm963xx_4.12L.06B_consumer/blob/dd8fcb13046f738c311507dc2fcfd3e5d57a88e0/kernel/linux/drivers/mtd/brcmnand/brcmnand_base.c#L2459 > > Jonas > > [1] > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/nand/nand_base.c#n1110 > -- Simon Arlott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
Hi Simon,
On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
> On 02/12/15 20:00, Brian Norris wrote:
> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> I've created a bcm963268part driver so there won't need to be any
> >> partitions in DT for bcm63268.
> >
> > Just curious, do you plan to submit this driver? We're working on
>
> Yes, it's just the most recent one I've been working on. I still have
> USBH and IUDMA to submit
>
> > matching up partition parsers to flash devices via device tree
> > of_match_table's, so you could do something like this:
> >
> > nand0: nandcs@0 {
> > compatible = "brcm,nandcs";
> > ...
> >
> > partitions {
> > compatible = "brcm,bcm963268-partitions";
> > ...
> > };
> > };
>
> I modified brcmnand to look for a machine matching "brcm,bcm963268", but
Like this?
http://patchwork.ozlabs.org/patch/473180/
I'd like to avoid that (hence the "Rejected" status).
> that way is ok with me. Presumably "ofpart" defers to another matching
> partition parser?
Yes, "ofpart" is for specifying the entire partition table in the device
tree as subnodes of either the flash node or of the flash's "partitions"
subnode. It's not the most flexible, but it does work generically.
> Is there a patch for that method of parser detection available?
I have something working here, but I haven't had time to finish cleaning
it up and submitting it. There's an older patch that works similarly,
though it has some deficiencies:
http://patchwork.ozlabs.org/patch/475988/
The main difference between that and my (yet-to-be-submitted) proposal
is that I'd like parsers to opt in by adding a proper of_match_table
with non-Linux-specific DT bindings, and then we can drop the
"linux,..." naming and make it a reasonably generic property.
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] dm verity: add support for error correction
On Mon, Nov 09 2015 at 2:19P -0500, Sami Tolvanen wrote: > On Mon, Nov 09, 2015 at 11:37:35AM -0500, Mike Snitzer wrote: > > I'm left wondering: can the new error correction code be made an > > optional feature that is off by default? -- so as to preserve some > > isolation of this new code from the old dm-verity behaviour. > > It's optional in the sense that you must specify error correction > parameters in the table to turn it on. Otherwise, verity_dec_decode > returns -1 and dm-verity handles errors as before. > > > might be good to add a wrapper like verity_fec_is_enabled(). > > Sure. I can do this in v2 and address the other feedback and build > issues as well. Hi Sami, Any progress on v2 that takes into account previous review feedback? Note I've staged the first 2 patches in this series for Linux 4.5 inclusion, see: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-4.5 Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wed, Dec 02, 2015 at 08:51:04PM +0100, Arnd Bergmann wrote: > I'm mostly interested in it because it's the only ARMv7 platform that is > left after my other patches, and I just want to be done with it after > spending 5 years on it ;-) My understanding is that the long term goal is to delete mach-dove once everyone has settled down into the mvebu DT world. Right now we have mvebu which covers Dove using DT. We have mach-dove which is legacy non-DT Dove. It seems to me to be completely crazy to want to bring legacy code, which is ultimately destined to be deleted, into multiplatform. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On Wed, Dec 02, 2015 at 12:21:27PM -0800, Brian Norris wrote: > On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote: > > Is there a patch for that method of parser detection available? > > I have something working here, but I haven't had time to finish cleaning > it up and submitting it. There's an older patch that works similarly, > though it has some deficiencies: > > http://patchwork.ozlabs.org/patch/475988/ > > The main difference between that and my (yet-to-be-submitted) proposal > is that I'd like parsers to opt in by adding a proper of_match_table > with non-Linux-specific DT bindings, and then we can drop the > "linux,..." naming and make it a reasonably generic property. For other related work: Linus Walleij attempted something similar here: http://lists.infradead.org/pipermail/linux-mtd/2015-October/062899.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding
On 02/12/15 12:53, Mark Brown wrote: > On Wed, Dec 02, 2015 at 12:45:50PM -, Simon Arlott wrote: >> On Tue, December 1, 2015 22:16, Mark Brown wrote: > >> > Why are these in the DT, I would expect that if this is a driver for a >> > specific SoC all these properties would be known as a result of that. > >> This is a driver for multiple SoCs with the same regulator control in >> different places on different SoCs, so the location of it within the misc >> register needs to be provided in the DT: > >> BCM6362: >> #define MISC_BASE 0xb0001800 /* Miscellaneous Registers */ >> uint32 miscIddqCtrl; /* 0x48 */ > > This is the sort of thing you can pick up from the SoC compatible > strings. As things stand there is zero content in this driver that > relates to this SoC. There's always going to be very little content in the driver that relates to this SoC, given that a single bit flip enables/disables power. All other device tree drivers allow a register address to be specified for the device, how is an offset in the regmap any different? >> The mask is used as there's one bit per regulator in the register, but >> there's more than one way to express this in the DT: > > I wouldn't expect to see it in the device tree at all for a device > specific driver. If there isn't an individual entry in DT for each regulator, how is it supposed to work? There's no #regulator-cells property. -- Simon Arlott -- 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] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of kernel self-protection: http://www.openwall.com/lists/kernel-hardening/2015/11/30/13 Additionally, its name has grown to mean things beyond just rodata. To get ARM closer to this, we ought to rearrange the names of the configs that control how the kernel protects its memory. What was called CONFIG_ARM_KERNMEM_PERMS is really doing the work that other architectures call CONFIG_DEBUG_RODATA. This redefines CONFIG_DEBUG_RODATA to actually do the bulk of the ROing (and NXing). In the place of the old CONFIG_DEBUG_RODATA, use CONFIG_DEBUG_ALIGN_RODATA, since that's what the option does: adds section alignment for making rodata explicitly NX, as arm does not split the page tables like arm64 does without _ALIGN_RODATA. Also adds human readable names to the sections so I could more easily debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7. Results in /sys/kernel/debug/kernel_page_tables for each config state: # CONFIG_DEBUG_RODATA is not set # CONFIG_DEBUG_ALIGN_RODATA is not set ---[ Kernel Mapping ]--- 0x8000-0x8090 9M RW x SHD 0x8090-0xa000 503M RW NX SHD CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_ALIGN_RODATA=y ---[ Kernel Mapping ]--- 0x8000-0x8010 1M RW NX SHD 0x8010-0x8070 6M ro x SHD 0x8070-0x80a0 3M ro NX SHD 0x80a0-0xa000 502M RW NX SHD CONFIG_DEBUG_RODATA=y # CONFIG_DEBUG_ALIGN_RODATA is not set ---[ Kernel Mapping ]--- 0x8000-0x8010 1M RW NX SHD 0x8010-0x80a0 9M ro x SHD 0x80a0-0xa000 502M RW NX SHD Signed-off-by: Kees Cook --- Depends on 8464/1 "Update all mm structures with section adjustments" --- arch/arm/kernel/vmlinux.lds.S | 10 +- arch/arm/mm/Kconfig | 34 ++ arch/arm/mm/init.c| 19 ++- 3 files changed, 33 insertions(+), 30 deletions(-) diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 8b60fde5ce48..a6e395c53a48 100644 --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -8,7 +8,7 @@ #include #include #include -#ifdef CONFIG_ARM_KERNMEM_PERMS +#ifdef CONFIG_DEBUG_RODATA #include #endif @@ -94,7 +94,7 @@ SECTIONS HEAD_TEXT } -#ifdef CONFIG_ARM_KERNMEM_PERMS +#ifdef CONFIG_DEBUG_RODATA . = ALIGN(1
Re: xfstests failures with xfs, dax and v4.4-rc3
On Wed, Dec 02, 2015 at 11:34:38AM -0700, Ross Zwisler wrote:
> I'm hitting a few more test failures in my testing setup with v4.4-rc3, xfs
> and DAX. My test setup is a pair of 4GiB PMEM partitions in a KVM virtual
> machine. Here are the failures:
Which are caused by commit 1ca1915 ("xfs: Don't use unwritten extents
for DAX") because of this code for unwritten extent conversion in
get_blocks:
tp->t_flags |= XFS_TRANS_RESERVE;
It's a minor problem compared to all the other issues DAX has right
now, so I ignored it to get the bigger problem solved first.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver
Hi, On 10/20/2015 11:18 AM, Tony Lindgren wrote: Hi all, * Dave Gerlach [150922 17:20]: Hi, This series is version 3 of the code to introduce a wkup_m3_ipc driver to handle communication between the MPU and Cortex M3 present on TI AM335x and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3 has been changed based on a request from Tony and a few cleanups: - Rather than exporting all of the functionality of the driver, added wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle containing an ops structure for use. - Changed all ops (previously exported functions) to take pointer to struct wkup_m3_ipc as an argument now that user code will get this from wkup_m3_ipc_get. - General cleanup to probe function - Added MODULE_DEVICE_TABLE so driver can probe automatically. The series containing the DT nodes can be found here [2]. The actual dt nodes for wkup_m3_ipc (last two patches) have been merged but discussion is still open for the ti,mbox-send-noirq flag patches and depends on the comments provided for the omap-mailbox change presented in patch 1 of this series. A full branch containing all necessary PM code for both am335x and am437x has been pushed here [3] to provide a big picture view of the plan for this series. This driver relies on the firmware at [4] in the next-upstream branch being present in /lib/firmware in the rootfs or built in to the kernel. Anybody got comments on this one? Should I pick up this series or what's the plan? Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? These apply cleanly on v4.4-rc3. Regards, Dave [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7 Regards, Tony [1] https://lkml.org/lkml/2015/7/17/797 [2] https://lkml.org/lkml/2015/7/17/813 [3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend [4] https://git.ti.com/ti-cm3-pm-firmware Dave Gerlach (3): mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle Documentation: dt: add bindings for TI Wakeup M3 IPC device soc: ti: Add wkup_m3_ipc driver .../devicetree/bindings/mailbox/omap-mailbox.txt | 8 + .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 57 +++ drivers/mailbox/omap-mailbox.c | 49 +- drivers/soc/ti/Kconfig | 10 + drivers/soc/ti/Makefile| 1 + drivers/soc/ti/wkup_m3_ipc.c | 508 + include/linux/wkup_m3_ipc.h| 55 +++ 7 files changed, 684 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt create mode 100644 drivers/soc/ti/wkup_m3_ipc.c create mode 100644 include/linux/wkup_m3_ipc.h -- 2.4.6 -- 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 net 0/6] Marvell Armada XP/370/38X Neta fixes
From: Gregory CLEMENT Date: Wed, 02 Dec 2015 09:16:06 +0100 > Hi David, > > On mer., déc. 02 2015, David Miller wrote: > >> From: Marcin Wojtas >> Date: Mon, 30 Nov 2015 13:27:40 +0100 >> >>> I'm sending v4 with corrected commit log of the last patch, in order >>> to avoid possible conflicts between the branches as suggested by >>> Gregory Clement. >> >> Series applied, thanks. > > Could you confirm that you don't apply the last patch? If I say it's applied then it's applied, and if you don't like it then you'll have to submit a revert patch against my tree or similar. You know you could just check my tree instead of asking. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm, printk: introduce new format string for flags
On 12/02/2015 12:01 PM, Rasmus Villemoes wrote:
> On Mon, Nov 30 2015, Vlastimil Babka wrote:
>
> I'd prefer to have the formatting code in vsprintf.c, so that we'd avoid
> having to call vsnprintf recursively (and repeatedly - not that this is
> going to be used in hot paths, but if the box is going down it might be
> nice to get the debug info out a few thousand cycles earlier). That'll
> also make it easier to avoid the bugs below.
OK, I'll try.
>> diff --git a/Documentation/printk-formats.txt
>> b/Documentation/printk-formats.txt
>> index b784c270105f..4b5156e74b09 100644
>> --- a/Documentation/printk-formats.txt
>> +++ b/Documentation/printk-formats.txt
>> @@ -292,6 +292,20 @@ Raw pointer value SHOULD be printed with %p. The kernel
>> supports
>>
>> Passed by reference.
>>
>> +Flags bitfields such as page flags, gfp_flags:
>> +
>> +%pgp0x1f886c(referenced|uptodate|lru|active|private)
>> +%pgg0x24202c4(GFP_USER|GFP_DMA32|GFP_NOWARN)
>> +%pgv0x875(read|exec|mayread|maywrite|mayexec|denywrite)
>> +
>
> I think it would be better (and more flexible) if %pg* only stood for
> printing the | chain of strings. Let people pass the flags twice if they
> also want the numeric value; then they're also able to choose 0-padding
> and whatnot, can use other kinds of parentheses, etc., etc. So
>
> pr_emerg("flags: 0x%08lu [%pgp]\n", printflags, &printflags)
I had it initially like this, but then thought it was somewhat repetitive and
all current users did use the same format. But I agree it's more generic to do
it as you say so I'll change it.
>> @@ -1361,6 +1362,29 @@ char *clock(char *buf, char *end, struct clk *clk,
>> struct printf_spec spec,
>> }
>> }
>>
>> +static noinline_for_stack
>> +char *flags_string(char *buf, char *end, void *flags_ptr,
>> +struct printf_spec spec, const char *fmt)
>> +{
>> +unsigned long flags;
>> +gfp_t gfp_flags;
>> +
>> +switch (fmt[1]) {
>> +case 'p':
>> +flags = *(unsigned long *)flags_ptr;
>> +return format_page_flags(flags, buf, end);
>> +case 'v':
>> +flags = *(unsigned long *)flags_ptr;
>> +return format_vma_flags(flags, buf, end);
>> +case 'g':
>> +gfp_flags = *(gfp_t *)flags_ptr;
>> +return format_gfp_flags(gfp_flags, buf, end);
>> +default:
>> +WARN_ONCE(1, "Unsupported flags modifier: %c\n", fmt[1]);
>> +return 0;
>> +}
>> +}
>> +
>
> That return 0 aka return NULL will lead to an oops when the next thing
> is printed. Did you mean 'return buf;'?
Uh, right.
>>
>> -static void dump_flag_names(unsigned long flags,
>> -const struct trace_print_flags *names, int count)
>> +static char *format_flag_names(unsigned long flags, unsigned long mask_out,
>> +const struct trace_print_flags *names, int count,
>> +char *buf, char *end)
>> {
>> const char *delim = "";
>> unsigned long mask;
>> int i;
>>
>> -pr_cont("(");
>> +buf += snprintf(buf, end - buf, "%#lx(", flags);
>
> Sorry, you can't do it like this. The buf you've been passed from inside
> vsnprintf may be beyond end
Ah, didn't realize that :/
> , so end-buf is a negative number which will
> (get converted to a huge positive size_t and) trigger a WARN_ONCE and
> get you a return value of 0.
>
>
>> +flags &= ~mask_out;
>>
>> for (i = 0; i < count && flags; i++) {
>> +if (buf >= end)
>> +break;
>
> Even if you fix the above, this is also wrong. We have to return the
> length of the string that would be generated if there was room enough,
> so we cannot make an early return like this. As I said above, the
> easiest way to do that is to do it inside vsprintf.c, where we have
> e.g. string() available. So I'd do something like
>
>
> char *format_flags(char *buf, char *end, unsigned long flags,
>const struct trace_print_flags *names)
> {
> unsigned long mask;
> const struct printf_spec strspec = {/* appropriate defaults*/}
> const struct printf_spec numspec = {/* appropriate defaults*/}
>
> for ( ; flags && names->mask; names++) {
> mask = names->mask;
> if ((flags & mask) != mask)
> continue;
> flags &= ~mask;
> buf = string(buf, end, names->name, strspec);
> if (flags) {
> if (buf < end)
> *buf = '|';
> buf++;
> }
> }
> if (flags)
> buf = number(buf, end, flags, numspec);
> return buf;
> }
Thanks a lot for your review and suggestions!
> [where I've assumed that the trace_print_flags array is terminated with
> an entry with 0 mask. Passing its length is also possible, but maybe a
> little awkward if the arrays are defined in mm/ and contents depend on
> .config.]
> Then flags_string() would call this directly with an appropriate array
> for names, and we avoid the individual tiny helper
> functions. flags_string
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On 02/12/15 20:21, Brian Norris wrote:
> Hi Simon,
>
> On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
>> On 02/12/15 20:00, Brian Norris wrote:
>> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
>> >> I've created a bcm963268part driver so there won't need to be any
>> >> partitions in DT for bcm63268.
>> >
>> > Just curious, do you plan to submit this driver? We're working on
>>
>> Yes, it's just the most recent one I've been working on. I still have
>> USBH and IUDMA to submit
>>
>> > matching up partition parsers to flash devices via device tree
>> > of_match_table's, so you could do something like this:
>> >
>> >nand0: nandcs@0 {
>> >compatible = "brcm,nandcs";
>> >...
>> >
>> >partitions {
>> >compatible = "brcm,bcm963268-partitions";
>> >...
>> >};
>> >};
>>
>> I modified brcmnand to look for a machine matching "brcm,bcm963268", but
>
> Like this?
>
> http://patchwork.ozlabs.org/patch/473180/
>
> I'd like to avoid that (hence the "Rejected" status).
I exported default_mtd_part_types, copied it, and then added to it:
+ for (i = 0; i < nr_types; i++)
+ part_types[i] = default_mtd_part_types[i];
+
+ /* Add partition type based on machine */
+ if (of_machine_is_compatible("brcm,bcm963268"))
+ part_types[i++] = "bcm963268part";
+ else
+ part_types[i++] = NULL;
+
+ part_types[i++] = NULL;
>> that way is ok with me. Presumably "ofpart" defers to another matching
>> partition parser?
>
> Yes, "ofpart" is for specifying the entire partition table in the device
> tree as subnodes of either the flash node or of the flash's "partitions"
> subnode. It's not the most flexible, but it does work generically.
>
>> Is there a patch for that method of parser detection available?
>
> I have something working here, but I haven't had time to finish cleaning
> it up and submitting it. There's an older patch that works similarly,
> though it has some deficiencies:
>
> http://patchwork.ozlabs.org/patch/475988/
>
> The main difference between that and my (yet-to-be-submitted) proposal
> is that I'd like parsers to opt in by adding a proper of_match_table
> with non-Linux-specific DT bindings, and then we can drop the
> "linux,..." naming and make it a reasonably generic property.
I'll submit my parser without any means of using it, let me know if you
want me to work on a patch for a match table.
> Regards,
> Brian
>
--
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wed, Dec 02, 2015 at 08:22:40PM +, Russell King - ARM Linux wrote: > On Wed, Dec 02, 2015 at 08:51:04PM +0100, Arnd Bergmann wrote: > > I'm mostly interested in it because it's the only ARMv7 platform that is > > left after my other patches, and I just want to be done with it after > > spending 5 years on it ;-) > > My understanding is that the long term goal is to delete mach-dove once > everyone has settled down into the mvebu DT world. > > Right now we have mvebu which covers Dove using DT. We have mach-dove > which is legacy non-DT Dove. > > It seems to me to be completely crazy to want to bring legacy code, which > is ultimately destined to be deleted, into multiplatform. I agree. We have multiplatform dove already, it is in mach-mvebu. Do we really need both mach-dove and mach-mvebu dove in one kernel? Andrew -- 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/
[REGRESSION] b8b2c7d845 breaks suspend/resume in qemu
Hey Uwe, So I recently noticed that my alarmtimer suspend/resume tests (selftests/timers/alartimer-suspend.c) were getting stuck testing w/ 4.4-rc kernels when running under qemu (x86_64). I've bisected this back to: b8b2c7d845 (base/platform: assert that dev_pm_domain callbacks are called unconditionally). I've not yet spent done any further analysis (bisecting it down, after some user-error, ate up my morning). But I wanted to see if there were any initial suggestions for solving this. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
On Wed, 2015-12-02 at 11:57 -0800, Dan Williams wrote:
> On Wed, Dec 2, 2015 at 12:12 PM, Toshi Kani wrote:
> > On Wed, 2015-12-02 at 13:02 -0700, Toshi Kani wrote:
> > > On Wed, 2015-12-02 at 11:00 -0800, Dan Williams wrote:
> > > > On Wed, Dec 2, 2015 at 11:26 AM, Toshi Kani wrote:
> > > > > On Wed, 2015-12-02 at 10:06 -0800, Dan Williams wrote:
> > > > > > On Wed, Dec 2, 2015 at 9:01 AM, Dan Williams <
> > > > > > dan.j.willi...@intel.com>
> > > > > > wrote:
> > > > > > > On Wed, Dec 2, 2015 at 9:43 AM, Toshi Kani
> > > > > > > wrote:
> > > > > > > > Oh, I see. I will setup the memmap array and run the tests
> > > > > > > > again.
> > > > > > > >
> > > > > > > > But, why does the PMD mapping depend on the memmap array? We
> > > > > > > > have observed major performance improvement with PMD. This
> > > > > > > > feature should always be enabled with DAX regardless of the
> > > > > > > > option to allocate the memmap array.
> > > > > > > >
> > > > > > >
> > > > > > > Several factors drove this decision, I'm open to considering
> > > > > > > alternatives but here's the reasoning:
> > > > > > >
> > > > > > > 1/ DAX pmd mappings caused crashes in the get_user_pages path
> > > > > > > leading to commit e82c9ed41e8 "dax: disable pmd mappings". The
> > > > > > > reason pte mappings don't crash and instead trigger -EFAULT is
> > > > > > > due
> > > > > > > to the _PAGE_SPECIAL pte bit.
> > > > > > >
> > > > > > > 2/ To enable get_user_pages for DAX, in both the page and huge
> > > > > > > -page case, we need a new pte bit _PAGE_DEVMAP.
> > > > > > >
> > > > > > > 3/ Given the pte bits are hard to come I'm assuming we won't get
> > > > > > > two, i.e. both _PAGE_DEVMAP and a new _PAGE_SPECIAL for pmds.
> > > > > > > Even if we could get a _PAGE_SPECIAL for pmds I'm not in favor
> > > > > > > of
> > > > > > > pursuing it.
> > > > > >
> > > > > > Actually, Dave says they aren't that hard to come by for pmds, so we
> > > > > > could go add _PMD_SPECIAL if we really wanted to support the limited
> > > > > > page-less DAX-pmd case.
> > > > > >
> > > > > > But I'm still of the opinion that we run away from the page-less
> > > > > > case until it can be made a full class citizen with O_DIRECT for pfn
> > > > > > support.
> > > > >
> > > > > I may be missing something, but per vm_normal_page(), I think
> > > > > _PAGE_SPECIAL can be substituted by the following check when we do not
> > > > > have the memmap.
> > > > >
> > > > > if ((vma->vm_flags & VM_PFNMAP) ||
> > > > > ((vma->vm_flags & VM_MIXEDMAP) && (!pfn_valid(pfn {
> > > > >
> > > > > This is what I did in this patch for follow_trans_huge_pmd(),
> > > > > although
> > > > > I missed the pfn_valid() check.
> > > >
> > > > That works for __get_user_pages but not __get_user_pages_fast where we
> > > > don't have access to the vma.
> > >
> > > __get_user_page_fast already refers current->mm, so we should be able to
> > > get the vma, and pass it down to gup_pud_range().
> >
> > Alternatively, we can obtain the vma from current->mm in gup_huge_pmd()
> > when
> > the !pfn_valid() condition is met, so that we do not add the code to the
> > main path of __get_user_pages_fast.
>
> The whole point of __get_user_page_fast() is to avoid the overhead of
> taking the mm semaphore to access the vma. _PAGE_SPECIAL simply tells
> __get_user_pages_fast that it needs to fallback to the
> __get_user_pages slow path.
I see. Then, I think gup_huge_pmd() can simply return 0 when !pfn_valid(),
instead of VM_BUG_ON.
Thanks,
-Toshi
--
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/3] usb: uhci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc. Caught by coccinelle. Signed-off-by: Geyslan G. Bem --- drivers/usb/host/uhci-q.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/uhci-q.c b/drivers/usb/host/uhci-q.c index da6f56d..c17ea15 100644 --- a/drivers/usb/host/uhci-q.c +++ b/drivers/usb/host/uhci-q.c @@ -248,11 +248,10 @@ static struct uhci_qh *uhci_alloc_qh(struct uhci_hcd *uhci, dma_addr_t dma_handle; struct uhci_qh *qh; - qh = dma_pool_alloc(uhci->qh_pool, GFP_ATOMIC, &dma_handle); + qh = dma_pool_zalloc(uhci->qh_pool, GFP_ATOMIC, &dma_handle); if (!qh) return NULL; - memset(qh, 0, sizeof(*qh)); qh->dma_handle = dma_handle; qh->element = UHCI_PTR_TERM(uhci); -- 2.6.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: [RESEND PATCH] arm64: bpf: add 'store immediate' instruction
From: Will Deacon Date: Wed, 2 Dec 2015 09:15:18 + > On Tue, Dec 01, 2015 at 02:20:40PM -0800, Shi, Yang wrote: >> On 11/30/2015 2:24 PM, Yang Shi wrote: >> >aarch64 doesn't have native store immediate instruction, such operation >> >has to be implemented by the below instruction sequence: >> > >> >Load immediate to register >> >Store register >> > >> >Signed-off-by: Yang Shi >> >CC: Zi Shen Lim >> >> Had email exchange offline with Zi Shen Lim since he is traveling and cannot >> send text-only mail, quoted below for his reply: >> >> "I've given reviewed-by in response to original posting. Unless something >> has changed, feel free to add it." >> >> Since there is nothing changed, added his reviewed-by. >> >> Reviewed-by: Zi Shen Lim > > I assume David will take this via netdev. Yes, I will, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc. Caught by coccinelle. Signed-off-by: Geyslan G. Bem --- drivers/usb/host/whci/qset.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/whci/qset.c b/drivers/usb/host/whci/qset.c index dc31c42..3297473 100644 --- a/drivers/usb/host/whci/qset.c +++ b/drivers/usb/host/whci/qset.c @@ -30,10 +30,9 @@ struct whc_qset *qset_alloc(struct whc *whc, gfp_t mem_flags) struct whc_qset *qset; dma_addr_t dma; - qset = dma_pool_alloc(whc->qset_pool, mem_flags, &dma); + qset = dma_pool_zalloc(whc->qset_pool, mem_flags, &dma); if (qset == NULL) return NULL; - memset(qset, 0, sizeof(struct whc_qset)); qset->qset_dma = dma; qset->whc = whc; -- 2.6.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 2/2] reset: bcm63xx: Add support for the BCM63xx soft-reset controller
On 02/12/15 18:03, Florian Fainelli wrote:
> 2015-11-30 12:58 GMT-08:00 Simon Arlott :
>> The BCM63xx contains a soft-reset controller activated by setting
>> a bit (that must previously have cleared).
>>
>> Signed-off-by: Simon Arlott
>> ---
>> MAINTAINERS | 1 +
>> drivers/reset/Kconfig | 9 +++
>> drivers/reset/Makefile| 1 +
>> drivers/reset/reset-bcm63xx.c | 134
>> ++
>> 4 files changed, 145 insertions(+)
>> create mode 100644 drivers/reset/reset-bcm63xx.c
>
>
> Could you create a bcm directory and then add your reset-bcm63xx.c
> file there? I have a pending submission for the BCM63138 reset
> controller which is not at all using the same structure and will share
> nothing with your driver.
>
Ok, I'll call it reset-bcm6345.c to avoid confusion.
>
>> +static int bcm63xx_reset_xlate(struct reset_controller_dev *rcdev,
>> + const struct of_phandle_args *reset_spec)
>> +{
>> + struct bcm63xx_reset_priv *priv = to_bcm63xx_reset_priv(rcdev);
>> +
>> + if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
>> + return -EINVAL;
>> +
>> + if (reset_spec->args[0] >= rcdev->nr_resets)
>> + return -EINVAL;
>
> Should not these two things be moved to the core reset controller code
> based on the #reset-cells value?
>
This has already been removed from the next version of the patch.
>
>> + if (of_property_read_u32(np, "offset", &priv->offset))
>> + return -EINVAL;
>> +
>> + /* valid reset bits */
>> + if (of_property_read_u32(np, "mask", &priv->mask))
>> + priv->mask = 0x;
>> +
>> + priv->rcdev.owner = THIS_MODULE;
>> + priv->rcdev.ops = &bcm63xx_reset_ops;
>> + priv->rcdev.nr_resets = 32;
>
> Should not that come from Device Tree, or be computed based on the
> mask property, like hweight_long() or something along these lines?
The "mask" property has been removed. It will assume 32 resets and rely
on the rest of the DT to only refer to valid bits.
--
Simon Arlott
--
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/3] usb: xhci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/xhci-mem.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c48cbe7..d034f92 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -47,13 +47,12 @@ static struct xhci_segment *xhci_segment_alloc(struct
xhci_hcd *xhci,
if (!seg)
return NULL;
- seg->trbs = dma_pool_alloc(xhci->segment_pool, flags, &dma);
+ seg->trbs = dma_pool_zalloc(xhci->segment_pool, flags, &dma);
if (!seg->trbs) {
kfree(seg);
return NULL;
}
- memset(seg->trbs, 0, TRB_SEGMENT_SIZE);
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
if (cycle_state == 0) {
for (i = 0; i < TRBS_PER_SEGMENT; i++)
@@ -517,12 +516,12 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
if (type == XHCI_CTX_TYPE_INPUT)
ctx->size += CTX_SIZE(xhci->hcc_params);
- ctx->bytes = dma_pool_alloc(xhci->device_pool, flags, &ctx->dma);
+ ctx->bytes = dma_pool_zalloc(xhci->device_pool, flags, &ctx->dma);
if (!ctx->bytes) {
kfree(ctx);
return NULL;
}
- memset(ctx->bytes, 0, ctx->size);
+
return ctx;
}
--
2.6.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] mtd: brcmnand: Workaround false ECC uncorrectable errors
On Wed, Dec 2, 2015 at 9:17 PM, Simon Arlott wrote: > On 01/12/15 10:41, Jonas Gorski wrote: >> On Sat, Nov 28, 2015 at 8:23 PM, Simon Arlott wrote: >>> + >>> + /* Go to start of buffer */ >>> + buf -= FC_WORDS; >>> + >>> + /* Erased if all data bytes are 0xFF */ >>> + buf_erased = memchr_inv(buf, 0xFF, FC_WORDS) == NULL; >>> + >>> + if (!buf_erased) >>> + goto out_free; >> >> We now have a function exactly for that use case in 4.4, >> nand_check_erased_buf [1], consider using that. This also has the >> benefit of treating bit flips as correctable as long as the ECC scheme >> is strong enough. > > I have no idea whether or not it's appropriate to specify > bitflips_threshold > 0 so it'd just be a more complex way to do > a memchr_inv() search for 0xFF. The threshold would be the amount of bitflips the code can correct, so basically ecc.strength (at least that is my understanding). > The code also has to check for the hamming code bytes being all 0x00, > because according to the comments [2], the controller also has > difficulty with the non-erased all-0xFFs scenario too. According to brcmnand.c hamming can fix up to fifteen bitflips, but in the current code you would fail a hamming protected all-0xff-page for even a single bitflip in the data or in the ecc bytes, which means that all-0xff-pages wouldn't be protected at all. Jonas -- 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: xfstests failures with xfs, dax and v4.4-rc3
On Thu, Dec 03, 2015 at 07:29:10AM +1100, Dave Chinner wrote:
> On Wed, Dec 02, 2015 at 11:34:38AM -0700, Ross Zwisler wrote:
> > I'm hitting a few more test failures in my testing setup with v4.4-rc3, xfs
> > and DAX. My test setup is a pair of 4GiB PMEM partitions in a KVM virtual
> > machine. Here are the failures:
>
> Which are caused by commit 1ca1915 ("xfs: Don't use unwritten extents
> for DAX") because of this code for unwritten extent conversion in
> get_blocks:
>
> tp->t_flags |= XFS_TRANS_RESERVE;
>
> It's a minor problem compared to all the other issues DAX has right
> now, so I ignored it to get the bigger problem solved first.
Patch to fix the problem below.
-Dave.
--
Dave Chinner
da...@fromorbit.com
xfs: Don't use reserved blocks for data blocks with DAX
From: Dave Chinner
Commit 1ca1915 ("xfs: Don't use unwritten extents for DAX") enabled
the DAX allocation call to dip into the reserve pool in case it was
converting unwritten extents rather than allocating blocks. This was
a direct copy of the unwritten extent conversion code, but had an
unintended side effect of allowing normal data block allocation to
use the reserve pool. Hence normal block allocation could deplete
the reserve pool and prevent unwritten extent conversion at ENOSPC,
hence violating fallocate guarantees on preallocated space.
Fix it by checking whether the incoming map from __xfs_get_blocks()
spans an unwritten extent and only use the reserve pool if the
allocation covers an unwritten extent.
Signed-off-by: Dave Chinner
---
fs/xfs/xfs_iomap.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index f4f5b43..9ed146b 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -203,15 +203,20 @@ xfs_iomap_write_direct(
* this outside the transaction context, but if we commit and then crash
* we may not have zeroed the blocks and this will be exposed on
* recovery of the allocation. Hence we must zero before commit.
+*
* Further, if we are mapping unwritten extents here, we need to zero
* and convert them to written so that we don't need an unwritten extent
* callback for DAX. This also means that we need to be able to dip into
-* the reserve block pool if there is no space left but we need to do
-* unwritten extent conversion.
+* the reserve block pool for bmbt block allocation if there is no space
+* left but we need to do unwritten extent conversion.
*/
+
if (IS_DAX(VFS_I(ip))) {
bmapi_flags = XFS_BMAPI_CONVERT | XFS_BMAPI_ZERO;
- tp->t_flags |= XFS_TRANS_RESERVE;
+ if (ISUNWRITTEN(imap)) {
+ tp->t_flags |= XFS_TRANS_RESERVE;
+ resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0) << 1;
+ }
}
error = xfs_trans_reserve(tp, &M_RES(mp)->tr_write,
resblks, resrtextents);
--
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: [REGRESSION] b8b2c7d845 breaks suspend/resume in qemu
On Wed, Dec 2, 2015 at 12:39 PM, John Stultz wrote: > Hey Uwe, > > So I recently noticed that my alarmtimer suspend/resume tests > (selftests/timers/alartimer-suspend.c) were getting stuck testing w/ > 4.4-rc kernels when running under qemu (x86_64). > > I've bisected this back to: b8b2c7d845 (base/platform: assert that > dev_pm_domain callbacks are called unconditionally). > > I've not yet spent done any further analysis (bisecting it down, after > some user-error, ate up my morning). But I wanted to see if there were > any initial suggestions for solving this. Just one other quick note: Reverting this commit against 4.4-rc3 seems to work as well. thanks -john -- 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/5] net: thunderx: Miscellaneous fixes
I'm not even looking at this patch series while it still causes unresolved bugs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding
On Wed, Dec 02, 2015 at 08:34:38PM +, Simon Arlott wrote:
> On 02/12/15 20:21, Brian Norris wrote:
> > On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
> >> On 02/12/15 20:00, Brian Norris wrote:
> >> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> >> I've created a bcm963268part driver so there won't need to be any
> >> >> partitions in DT for bcm63268.
> >> >
> >> > Just curious, do you plan to submit this driver? We're working on
> >>
> >> Yes, it's just the most recent one I've been working on. I still have
> >> USBH and IUDMA to submit
> >>
> >> > matching up partition parsers to flash devices via device tree
> >> > of_match_table's, so you could do something like this:
> >> >
> >> > nand0: nandcs@0 {
> >> > compatible = "brcm,nandcs";
> >> > ...
> >> >
> >> > partitions {
> >> > compatible = "brcm,bcm963268-partitions";
> >> > ...
> >> > };
> >> > };
> >>
> >> I modified brcmnand to look for a machine matching "brcm,bcm963268", but
> >
> > Like this?
> >
> > http://patchwork.ozlabs.org/patch/473180/
> >
> > I'd like to avoid that (hence the "Rejected" status).
>
> I exported default_mtd_part_types, copied it, and then added to it:
> + for (i = 0; i < nr_types; i++)
> + part_types[i] = default_mtd_part_types[i];
> +
> + /* Add partition type based on machine */
> + if (of_machine_is_compatible("brcm,bcm963268"))
> + part_types[i++] = "bcm963268part";
> + else
> + part_types[i++] = NULL;
> +
> + part_types[i++] = NULL;
OK, so even uglier :)
> >> that way is ok with me. Presumably "ofpart" defers to another matching
> >> partition parser?
> >
> > Yes, "ofpart" is for specifying the entire partition table in the device
> > tree as subnodes of either the flash node or of the flash's "partitions"
> > subnode. It's not the most flexible, but it does work generically.
> >
> >> Is there a patch for that method of parser detection available?
> >
> > I have something working here, but I haven't had time to finish cleaning
> > it up and submitting it. There's an older patch that works similarly,
> > though it has some deficiencies:
> >
> > http://patchwork.ozlabs.org/patch/475988/
> >
> > The main difference between that and my (yet-to-be-submitted) proposal
> > is that I'd like parsers to opt in by adding a proper of_match_table
> > with non-Linux-specific DT bindings, and then we can drop the
> > "linux,..." naming and make it a reasonably generic property.
>
> I'll submit my parser without any means of using it,
Sounds fine.
> let me know if you
> want me to work on a patch for a match table.
If you're interested, I may CC you on my patches for testing/review.
Brian
--
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 RFC 3/8] Input: atmel_mxt_ts - read touchscreen position in matrix
The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 41
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index a96fec4..9bc42f4 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -100,6 +100,8 @@ struct t7_config {
/* MXT_TOUCH_MULTI_T9 field */
#define MXT_T9_CTRL0
+#define MXT_T9_XSIZE 3
+#define MXT_T9_YSIZE 4
#define MXT_T9_ORIENT 9
#define MXT_T9_RANGE 18
@@ -145,7 +147,9 @@ struct t37_debug {
#define MXT_T100_CTRL 0
#define MXT_T100_CFG1 1
#define MXT_T100_TCHAUX3
+#define MXT_T100_XSIZE 9
#define MXT_T100_XRANGE13
+#define MXT_T100_YSIZE 20
#define MXT_T100_YRANGE24
#define MXT_T100_CFG_SWITCHXY BIT(5)
@@ -243,6 +247,8 @@ struct mxt_data {
unsigned int max_x;
unsigned int max_y;
bool xy_switch;
+ u8 xsize;
+ u8 ysize;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1688,6 +1694,18 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return -EINVAL;
error = __mxt_read_reg(client,
+ object->start_address + MXT_T9_XSIZE,
+ sizeof(data->xsize), &data->xsize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T9_YSIZE,
+ sizeof(data->ysize), &data->ysize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
object->start_address + MXT_T9_RANGE,
sizeof(range), &range);
if (error)
@@ -1737,6 +1755,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
data->max_y = get_unaligned_le16(&range_y);
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T100_XSIZE,
+ sizeof(data->xsize), &data->xsize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T100_YSIZE,
+ sizeof(data->ysize), &data->ysize);
+ if (error)
+ return error;
+
/* read orientation config */
error = __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
@@ -2077,7 +2107,7 @@ static u16 mxt_get_debug_value(struct mxt_data *data,
unsigned int x,
struct mxt_dbg *dbg = &data->dbg;
unsigned int ofs, page;
- ofs = (y + (x * (data->info.matrix_ysize))) * sizeof(u16);
+ ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
@@ -2095,7 +2125,7 @@ static void mxt_convert_debug_pages(struct mxt_data *data)
dbg->debug_buf[i] = mxt_get_debug_value(data, x, y);
/* Next value */
- if (++x >= data->info.matrix_xsize) {
+ if (++x >= data->xsize) {
x = 0;
y++;
}
@@ -2213,9 +2243,10 @@ static void mxt_debugfs_init(struct mxt_data *data)
}
/* Calculate size of data and allocate buffer */
- dbg->t37_nodes = data->info.matrix_xsize * data->info.matrix_ysize;
- dbg->t37_pages = dbg->t37_nodes * sizeof(u16)
- / sizeof(dbg->t37_buf->data) + 1;
+ dbg->t37_nodes = data->xsize * data->ysize;
+ dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
+ * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
+
dbg->debug_buf = devm_kzalloc(&data->client->dev,
dbg->t37_nodes * sizeof(u16),
GFP_KERNEL);
--
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/
[PATCH RFC 1/8] Input: atmel_mxt_ts - improve touchscreen size/orientation handling
Both T100 and T9 handle range and orientation in a similar fashion.
Reduce duplication between the two implementations.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 68
1 file changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index c562205..4a1d218 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -113,8 +113,8 @@ struct t7_config {
#define MXT_T9_DETECT (1 << 7)
struct t9_range {
- u16 x;
- u16 y;
+ __le16 x;
+ __le16 y;
} __packed;
/* MXT_TOUCH_MULTI_T9 orient */
@@ -216,6 +216,7 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+ bool xy_switch;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1665,8 +1666,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
if (error)
return error;
- le16_to_cpus(&range.x);
- le16_to_cpus(&range.y);
+ data->max_x = get_unaligned_le16(&range.x);
+ data->max_y = get_unaligned_le16(&range.y);
error = __mxt_read_reg(client,
object->start_address + MXT_T9_ORIENT,
@@ -1674,23 +1675,7 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
if (error)
return error;
- /* Handle default values */
- if (range.x == 0)
- range.x = 1023;
-
- if (range.y == 0)
- range.y = 1023;
-
- if (orient & MXT_T9_ORIENT_SWITCH) {
- data->max_x = range.y;
- data->max_y = range.x;
- } else {
- data->max_x = range.x;
- data->max_y = range.y;
- }
-
- dev_dbg(&client->dev,
- "Touchscreen size X%uY%u\n", data->max_x, data->max_y);
+ data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
return 0;
}
@@ -1708,13 +1693,14 @@ static int mxt_read_t100_config(struct mxt_data *data)
if (!object)
return -EINVAL;
+ /* read touchscreen dimensions */
error = __mxt_read_reg(client,
object->start_address + MXT_T100_XRANGE,
sizeof(range_x), &range_x);
if (error)
return error;
- le16_to_cpus(&range_x);
+ data->max_x = get_unaligned_le16(&range_x);
error = __mxt_read_reg(client,
object->start_address + MXT_T100_YRANGE,
@@ -1722,36 +1708,24 @@ static int mxt_read_t100_config(struct mxt_data *data)
if (error)
return error;
- le16_to_cpus(&range_y);
+ data->max_y = get_unaligned_le16(&range_y);
+ /* read orientation config */
error = __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
1, &cfg);
if (error)
return error;
+ data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+
+ /* allocate aux bytes */
error = __mxt_read_reg(client,
object->start_address + MXT_T100_TCHAUX,
1, &tchaux);
if (error)
return error;
- /* Handle default values */
- if (range_x == 0)
- range_x = 1023;
-
- if (range_y == 0)
- range_y = 1023;
-
- if (cfg & MXT_T100_CFG_SWITCHXY) {
- data->max_x = range_y;
- data->max_y = range_x;
- } else {
- data->max_x = range_x;
- data->max_y = range_y;
- }
-
- /* allocate aux bytes */
aux = 6;
if (tchaux & MXT_T100_TCHAUX_VECT)
@@ -1767,9 +1741,6 @@ static int mxt_read_t100_config(struct mxt_data *data)
"T100 aux mappings vect:%u ampl:%u area:%u\n",
data->t100_aux_vect, data->t100_aux_ampl, data->t100_aux_area);
- dev_info(&client->dev,
-"T100 Touchscreen size X%uY%u\n", data->max_x, data->max_y);
-
return 0;
}
@@ -1828,6 +1799,19 @@ static int mxt_initialize_input_device(struct mxt_data
*data)
return -EINVAL;
}
+ /* Handle default values and orientation switch */
+ if (data->max_x == 0)
+ data->max_x = 1023;
+
+ if (data->max_y == 0)
+ data->max_y = 1023;
+
+ if (data->xy_switch)
+ swap(data->max_x, data->max_y);
+
+ dev_info(dev, "Touchscreen size X%uY%u\n", data->max_x, data->max_y);
+
+ /* Register input device */
input_dev = input_allocate_device();
if (!input_dev) {
dev_err(dev, "Failed to allocate memory\n");
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
[PATCH RFC 5/8] Input: atmel_mxt_ts - add diagnostic data support for mXT1386
The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 3b1a938..6c9fbc0 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -134,6 +134,10 @@ struct t9_range {
#define MXT_DIAGNOSTIC_DELTAS 0x10
#define MXT_DIAGNOSTIC_SIZE128
+#define MXT_FAMILY_1386160
+#define MXT1386_COLUMNS3
+#define MXT1386_PAGES_PER_COLUMN 8
+
struct t37_debug {
u8 mode;
u8 page;
@@ -2114,13 +2118,27 @@ recheck:
static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
unsigned int y)
{
+ struct mxt_info *info = &data->info;
struct mxt_dbg *dbg = &data->dbg;
unsigned int ofs, page;
+ unsigned int col = 0;
+ unsigned int col_width;
+
+ if (info->family_id == MXT_FAMILY_1386) {
+ col_width = info->matrix_ysize / MXT1386_COLUMNS;
+ col = y / col_width;
+ y = y % col_width;
+ } else {
+ col_width = info->matrix_ysize;
+ }
- ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+ ofs = (y + (x * col_width)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
+ if (info->family_id == MXT_FAMILY_1386)
+ page += col * MXT1386_PAGES_PER_COLUMN;
+
return get_unaligned_le16(&dbg->t37_buf[page].data[ofs]);
}
@@ -2227,6 +2245,7 @@ static void mxt_debugfs_remove(struct mxt_data *data)
static void mxt_debugfs_init(struct mxt_data *data)
{
+ struct mxt_info *info = &data->info;
struct mxt_dbg *dbg = &data->dbg;
struct mxt_object *object;
char dirname[50];
@@ -2260,8 +2279,13 @@ static void mxt_debugfs_init(struct mxt_data *data)
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
- dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
- * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
+
+ if (info->family_id == MXT_FAMILY_1386)
+ dbg->t37_pages = MXT1386_COLUMNS * MXT1386_PAGES_PER_COLUMN;
+ else
+ dbg->t37_pages = ((data->xsize * info->matrix_ysize)
+ * sizeof(u16) / sizeof(dbg->t37_buf->data))
+ + 1;
dbg->debug_buf = devm_kzalloc(&data->client->dev,
dbg->t37_nodes * sizeof(u16),
--
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/
[PATCH RFC 4/8] Input: atmel_mxt_ts - handle diagnostic data orientation
Invert the diagnostic data to match the orientation of the input device.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 9bc42f4..3b1a938 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -122,6 +122,8 @@ struct t9_range {
/* MXT_TOUCH_MULTI_T9 orient */
#define MXT_T9_ORIENT_SWITCH (1 << 0)
+#define MXT_T9_ORIENT_INVERTX (1 << 1)
+#define MXT_T9_ORIENT_INVERTY (1 << 2)
/* MXT_SPT_COMMSCONFIG_T18 */
#define MXT_COMMS_CTRL 0
@@ -153,6 +155,8 @@ struct t37_debug {
#define MXT_T100_YRANGE24
#define MXT_T100_CFG_SWITCHXY BIT(5)
+#define MXT_T100_CFG_INVERTY BIT(6)
+#define MXT_T100_CFG_INVERTX BIT(7)
#define MXT_T100_TCHAUX_VECT BIT(0)
#define MXT_T100_TCHAUX_AMPL BIT(1)
@@ -246,6 +250,8 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+ bool invertx;
+ bool inverty;
bool xy_switch;
u8 xsize;
u8 ysize;
@@ -1721,6 +1727,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return error;
data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
+ data->invertx = orient & MXT_T9_ORIENT_INVERTX;
+ data->inverty = orient & MXT_T9_ORIENT_INVERTY;
return 0;
}
@@ -1775,6 +1783,8 @@ static int mxt_read_t100_config(struct mxt_data *data)
return error;
data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+ data->invertx = cfg & MXT_T100_CFG_INVERTX;
+ data->inverty = cfg & MXT_T100_CFG_INVERTY;
/* allocate aux bytes */
error = __mxt_read_reg(client,
@@ -2119,13 +2129,19 @@ static void mxt_convert_debug_pages(struct mxt_data
*data)
struct mxt_dbg *dbg = &data->dbg;
unsigned int x = 0;
unsigned int y = 0;
- unsigned int i;
+ unsigned int i, rx, ry;
for (i = 0; i < dbg->t37_nodes; i++) {
- dbg->debug_buf[i] = mxt_get_debug_value(data, x, y);
+ /* Handle orientation */
+ rx = data->xy_switch ? y : x;
+ ry = data->xy_switch ? x : y;
+ rx = data->invertx ? (data->xsize - 1 - rx) : rx;
+ ry = data->inverty ? (data->ysize - 1 - ry) : ry;
+
+ dbg->debug_buf[i] = mxt_get_debug_value(data, rx, ry);
/* Next value */
- if (++x >= data->xsize) {
+ if (++x >= (data->xy_switch ? data->ysize : data->xsize)) {
x = 0;
y++;
}
--
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/
[PATCH RFC 8/8] Input: atmel_mxt_ts - create debugfs info file
Add a file in debugfs directory with info about the chip.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 14 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 22 ++
2 files changed, 36 insertions(+)
diff --git a/Documentation/ABI/testing/debugfs-heatmap
b/Documentation/ABI/testing/debugfs-heatmap
index 9246340..95668a5 100644
--- a/Documentation/ABI/testing/debugfs-heatmap
+++ b/Documentation/ABI/testing/debugfs-heatmap
@@ -6,6 +6,13 @@ Description:
A directory will be created under heatmap for each device which
provides heatmap data.
+What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/info
+Date:
+KernelVersion:
+Contact:
+Description:
+Info relating to the device, eg hardware/firmware version
+
What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/datatype/
Date:
KernelVersion:
@@ -48,6 +55,13 @@ Contact:
Description:
Display name for the data.
+What: /sys/kernel/debug/heatmap-xxx/datatype/input_name
+Date:
+KernelVersion:
+Contact:
+Description:
+ The name of the corresponding input device, if relevant.
+
What: /sys/kernel/debug/heatmap-xxx/datatype/data
Date:
KernelVersion:
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index dbe9ebb..34f3d86 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -277,7 +277,10 @@ struct mxt_dbg {
struct dentry *debugfs_dir;
struct dentry *deltas_file;
struct dentry *refs_file;
+ struct debugfs_blob_wrapper input_name_wrapper;
struct mxt_debug_datatype_meta dt_meta[ARRAY_SIZE(datatypes)];
+ char info[50];
+ struct debugfs_blob_wrapper info_wrapper;
};
#endif
@@ -2319,6 +2322,18 @@ static void mxt_debugfs_init(struct mxt_data *data)
return;
}
+ dbg->info_wrapper.data = dbg->info;
+ dbg->info_wrapper.size = sizeof(dbg->info);
+ scnprintf(dbg->info, sizeof(dbg->info),
+"Family: %u Variant: %u Firmware V%u.%u.%02X",
+info->family_id, info->variant_id, info->version >> 4,
+info->version & 0xf, info->build);
+
+ dent = debugfs_create_blob("info", S_IRUGO, dbg->debugfs_dir,
+ &dbg->info_wrapper);
+ if (!dent)
+ goto error;
+
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
@@ -2383,6 +2398,13 @@ static void mxt_debugfs_init(struct mxt_data *data)
if (!dent)
goto error;
+ dbg->input_name_wrapper.data = (void *)data->input_dev->name;
+ dbg->input_name_wrapper.size = strlen(data->input_dev->name);
+ dent = debugfs_create_blob("input_name", S_IRUGO,
+ dir, &dbg->input_name_wrapper);
+ if (!dent)
+ goto error;
+
dtm->dent = dent;
dent->d_inode->i_size = dbg->t37_nodes * sizeof(u16);
}
--
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/
[PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs
Hello- This is a series of patches to add diagnostic data support to the Atmel maXTouch driver. There's an existing implementation in the open-source mxt-app tool, however there are performance advantages to moving this code into the driver. The algorithm for retrieving the data has been fairly consistent across a range of chips, with the exception of the mXT1386 series (see patch). The intention is to open-source a utility which can read/display this data, this should be available very shortly. It would be good if we could agree a single debugfs interface which could be supported by all touchscreen chips that have this kind of feature, so I've attempted to keep that part of this vendor neutral. This patch sequence is also available from https://github.com/ndyer/linux/commits/diagnostic-debug Any feedback appreciated. Best regards Nick Dyer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies
On 2015-12-02 00:13, Shawn Guo wrote:
> On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
>> Linux on Vybrid used several different L2 latencies so far, none
>> of them seem to be the right ones. According to the application note
>> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
>> on CPU clock and is inside the L2 cache controller, whereas the data
>> portion is stored in the external SRAM running on platform clock.
>> Hence it is likely that the correct value requires a higher data
>> latency then tag latency.
>>
>> These are the values which have been used so far:
>> - The mainline values:
>> arm,data-latency = <1 1 1>;
>> arm,tag-latency = <2 2 2>;
>> Those values have lead to problems on higher clocks. They look
>> like a poor translation from the reset values (missing +1 offset
>> and a mix up between tag/latency values).
>> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
>> arm,data-latency = <4 2 3>
>> arm,tag-latency = <4 2 3>
>> The cache initialization function along with the value matches the
>> i.MX6 code from the same kernel, so it seems that those values have
>> just been copied.
>> - The Colibri values:
>> arm,data-latency = <2 1 2>;
>> arm,tag-latency = <3 2 3>;
>> Those were a mix between the values of the Linux 3.0 based BSP and
>> the mainline values above.
>> - The SoC Reset values (converted to DT notation):
>> arm,data-latency = <3 3 3>;
>> arm,tag-latency = <2 2 2>;
>>
>> So far there is no official statement on what the correct values are.
>> See also the related Freescale community thread:
>> https://community.freescale.com/message/579785#579785
>>
>> For now, the reset values seem to be the best bet. Remove all other
>> "bogus" values and use the reset value on vf610.dtsi level.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> Hi Shawn,
>>
>> Any chance to get this into 4.4?
>
> I can try. Generally, upstream maintainers are becoming more strict for
> -rc inclusion after -rc3 phase. Do you have any user stories about why
> this is a critical/urgent fix? If we send this a critical fix for 4.4-rc
> inclusion, do we need to Cc stable?
It came up a while ago on Freescale community, but I think that user
used downstream BSP's:
https://community.freescale.com/thread/332326
The Colibri VF61 board overwrites the latency, so it is not really
critical for this board.
The Freescale Tower runs at 400MHz by default, but has a CPU which would
support up to 500MHz. I am pretty sure with 500MHz CPU clock, things
will go south with current settings.
Regarding stable: Would probably be consistent...
--
Stefan
>
> Shawn
>
>>
>> --
>> Stefan
>>
>> arch/arm/boot/dts/vf610-colibri.dtsi | 5 -
>> arch/arm/boot/dts/vf610.dtsi | 2 +-
>> 2 files changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi
>> b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 19fe045..2d7eab7 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -18,8 +18,3 @@
>> reg = <0x8000 0x1000>;
>> };
>> };
>> -
>> -&L2 {
>> -arm,data-latency = <2 1 2>;
>> -arm,tag-latency = <3 2 3>;
>> -};
>> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
>> index 5f8eb1b..58bc6e4 100644
>> --- a/arch/arm/boot/dts/vf610.dtsi
>> +++ b/arch/arm/boot/dts/vf610.dtsi
>> @@ -19,7 +19,7 @@
>> reg = <0x40006000 0x1000>;
>> cache-unified;
>> cache-level = <2>;
>> -arm,data-latency = <1 1 1>;
>> +arm,data-latency = <3 3 3>;
>> arm,tag-latency = <2 2 2>;
>> };
>> };
>> --
>> 2.6.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 RFC 7/8] Input: atmel_mxt_ts - add metadata to debugfs
Add information to debugfs to allow a generic utility to retrieve
screen parameters and info.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 60 +++
drivers/input/touchscreen/atmel_mxt_ts.c | 46 ++--
2 files changed, 103 insertions(+), 3 deletions(-)
create mode 100644 Documentation/ABI/testing/debugfs-heatmap
diff --git a/Documentation/ABI/testing/debugfs-heatmap
b/Documentation/ABI/testing/debugfs-heatmap
new file mode 100644
index 000..9246340
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-heatmap
@@ -0,0 +1,60 @@
+What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/
+Date:
+KernelVersion:
+Contact:
+Description:
+ A directory will be created under heatmap for each device which
+ provides heatmap data.
+
+What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/datatype/
+Date:
+KernelVersion:
+Contact:
+Description:
+ The device can have multiple heatmap data types. A directory is created
+ for each one.
+
+What: /sys/kernel/debug/heatmap-xxx/datatype/format
+Date:
+KernelVersion:
+Contact:
+Description:
+ Specifies the type of each data value, one of:
+ uint8
+ uint16
+ uint32
+ int8
+ int16
+ int32
+
+What: /sys/kernel/debug/heatmap-xxx/datatype/width
+Date:
+KernelVersion:
+Contact:
+Description:
+ The width of the data.
+
+What: /sys/kernel/debug/heatmap-xxx/datatype/height
+Date:
+KernelVersion:
+Contact:
+Description:
+ The height of the data.
+
+What: /sys/kernel/debug/heatmap-xxx/datatype/name
+Date:
+KernelVersion:
+Contact:
+Description:
+ Display name for the data.
+
+What: /sys/kernel/debug/heatmap-xxx/datatype/data
+Date:
+KernelVersion:
+Contact:
+Description:
+ Binary attribute for the data.
+
+ The orientation of the data should correspond to the co-ordinates
+ reported to the input layer. Starting at the top left hand corner, rows
+ then columns. The endianness of data values will be as per host cpu.
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 49fbe2a..dbe9ebb 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -236,23 +236,33 @@ struct mxt_object {
struct mxt_debug_datatype {
u8 mode;
char *name;
+ char *desc;
+ char *format;
};
struct mxt_debug_datatype_meta {
struct mxt_data *data;
const struct mxt_debug_datatype *datatype;
struct dentry *dent;
+ u16 width;
+ u16 height;
void *buf;
+ struct debugfs_blob_wrapper format_wrapper;
+ struct debugfs_blob_wrapper desc_wrapper;
};
static const struct mxt_debug_datatype datatypes[] = {
{
.mode = MXT_DIAGNOSTIC_REFS,
.name = "refs",
+ .desc = "Mutual Capacitance References",
+ .format = "uint16",
},
{
.mode = MXT_DIAGNOSTIC_DELTAS,
.name = "deltas",
+ .format = "int16",
+ .desc = "Mutual Capacitance Deltas",
}
};
@@ -2277,6 +2287,7 @@ static void mxt_debugfs_init(struct mxt_data *data)
struct mxt_dbg *dbg = &data->dbg;
struct mxt_object *object;
struct dentry *dent;
+ struct dentry *dir;
struct mxt_debug_datatype_meta *dtm;
char dirname[50];
int i;
@@ -2333,13 +2344,42 @@ static void mxt_debugfs_init(struct mxt_data *data)
for (i = 0; i < ARRAY_SIZE(datatypes); i++) {
dtm = &data->dbg.dt_meta[i];
+ dir = debugfs_create_dir(datatypes[i].name, dbg->debugfs_dir);
+ if (!dir)
+ goto error;
+
dtm->data = data;
dtm->datatype = datatypes + i;
+ dtm->width = data->xy_switch ? data->ysize : data->xsize;
+ dtm->height = data->xy_switch ? data->xsize: data->ysize;
dtm->buf = dbg->debug_buf;
- dent = debugfs_create_file(datatypes[i].name,
- S_IRUGO, dbg->debugfs_dir,
- dtm, &atmel_mxt_dbg_fops);
+ dtm->format_wrapper.data = (void *)dtm->datatype->format;
+ dtm->format_wrapper.size = strlen(dtm->datatype->format);
+ dent = debugfs_create_blob("format", S_IRUGO,
+ dir, &dtm->format_wrapper);
+ if (!dent)
+ goto error;
+
+ dtm->desc_wrapper.data = (void *)dtm->datatype->desc;
+ dtm->desc_wrapper.size = strlen(dtm->datatype->desc);
+ dent = debugfs_create_blob("name", S_IRUGO,
+ dir, &dtm->desc_wrapper);
+
Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
On Wed, Dec 2, 2015 at 1:37 PM, Toshi Kani wrote: > On Wed, 2015-12-02 at 11:57 -0800, Dan Williams wrote: [..] >> The whole point of __get_user_page_fast() is to avoid the overhead of >> taking the mm semaphore to access the vma. _PAGE_SPECIAL simply tells >> __get_user_pages_fast that it needs to fallback to the >> __get_user_pages slow path. > > I see. Then, I think gup_huge_pmd() can simply return 0 when !pfn_valid(), > instead of VM_BUG_ON. Is pfn_valid() a reliable check? It seems to be based on a max_pfn per node... what happens when pmem is located below that point. I haven't been able to convince myself that we won't get false positives, but maybe I'm missing something. -- 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 RFC 2/8] Input: atmel_mxt_ts - add diagnostic data retrieval via debugfs
Retrieve refs data from the T37 diagnostic data object and expose it via
a binary attribute in debugfs.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 212 +++
1 file changed, 212 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 4a1d218..a96fec4 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/* Firmware files */
#define MXT_FW_NAME"maxtouch.fw"
@@ -124,6 +125,17 @@ struct t9_range {
#define MXT_COMMS_CTRL 0
#define MXT_COMMS_CMD 1
+/* MXT_DEBUG_DIAGNOSTIC_T37 */
+#define MXT_DIAGNOSTIC_PAGEUP 0x01
+#define MXT_DIAGNOSTIC_DELTAS 0x10
+#define MXT_DIAGNOSTIC_SIZE128
+
+struct t37_debug {
+ u8 mode;
+ u8 page;
+ u8 data[MXT_DIAGNOSTIC_SIZE];
+};
+
/* Define for MXT_GEN_COMMAND_T6 */
#define MXT_BOOT_VALUE 0xa5
#define MXT_RESET_VALUE0x01
@@ -205,6 +217,20 @@ struct mxt_object {
u8 num_report_ids;
} __packed;
+#ifdef CONFIG_DEBUG_FS
+struct mxt_dbg {
+ u16 t37_address;
+ u16 diag_cmd_address;
+ struct t37_debug *t37_buf;
+ u16 *debug_buf;
+ unsigned int t37_pages;
+ unsigned int t37_nodes;
+
+ struct dentry *debugfs_dir;
+ struct dentry *deltas_file;
+};
+#endif
+
/* Each client has this additional data */
struct mxt_data {
struct i2c_client *client;
@@ -233,6 +259,7 @@ struct mxt_data {
u8 num_touchids;
u8 multitouch;
struct t7_config t7_cfg;
+ struct mxt_dbg dbg;
/* Cached parameters from object table */
u16 T5_address;
@@ -2043,6 +2070,188 @@ recheck:
return 0;
}
+#ifdef CONFIG_DEBUG_FS
+static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
+ unsigned int y)
+{
+ struct mxt_dbg *dbg = &data->dbg;
+ unsigned int ofs, page;
+
+ ofs = (y + (x * (data->info.matrix_ysize))) * sizeof(u16);
+ page = ofs / MXT_DIAGNOSTIC_SIZE;
+ ofs %= MXT_DIAGNOSTIC_SIZE;
+
+ return get_unaligned_le16(&dbg->t37_buf[page].data[ofs]);
+}
+
+static void mxt_convert_debug_pages(struct mxt_data *data)
+{
+ struct mxt_dbg *dbg = &data->dbg;
+ unsigned int x = 0;
+ unsigned int y = 0;
+ unsigned int i;
+
+ for (i = 0; i < dbg->t37_nodes; i++) {
+ dbg->debug_buf[i] = mxt_get_debug_value(data, x, y);
+
+ /* Next value */
+ if (++x >= data->info.matrix_xsize) {
+ x = 0;
+ y++;
+ }
+ }
+}
+
+static int mxt_open_deltas(struct inode *inode, struct file *file)
+{
+ struct mxt_data *data = inode->i_private;
+ struct mxt_dbg *dbg = &data->dbg;
+ int retries = 0;
+ int page;
+ int ret;
+ u8 mode = MXT_DIAGNOSTIC_DELTAS;
+ u8 cmd = mode;
+ struct t37_debug *p;
+
+ for (page = 0; page < dbg->t37_pages; page++) {
+ p = dbg->t37_buf + page;
+
+ ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
+ cmd);
+ if (ret)
+ return ret;
+
+ retries = 0;
+
+ /* Poll until command is actioned */
+ msleep(20);
+wait_cmd:
+ /* Read first two bytes only */
+ ret = __mxt_read_reg(data->client, dbg->t37_address,
+2, p);
+ if (ret)
+ return ret;
+
+ if ((p->mode != mode) || (p->page != page)) {
+ if (retries++ > 100)
+ return -EINVAL;
+
+ msleep(20);
+ goto wait_cmd;
+ }
+
+ /* Read entire T37 page */
+ ret = __mxt_read_reg(data->client, dbg->t37_address,
+ sizeof(struct t37_debug), p);
+ if (ret)
+ return ret;
+
+ dev_dbg(&data->client->dev, "%s page:%d retries:%d\n",
+ __func__, page, retries);
+
+ /* For remaining pages, write PAGEUP rather than mode */
+ cmd = MXT_DIAGNOSTIC_PAGEUP;
+ }
+
+ mxt_convert_debug_pages(data);
+ file->private_data = data;
+
+ return 0;
+}
+
+static ssize_t mxt_read_deltas(struct file *file, char __user *ubuf,
+ size_t count, loff_t *offp)
+{
+ struct mxt_data *data = file->private_data;
+
+ return simple_read_from_buffer(ubuf, count, offp,
+ data->dbg.debug_buf,
+ data->dbg.t37_nodes * sizeof(u16));
+}
+
+static const struct file_operations atmel_mxt_deltas_fops = {
+ .open = mxt_open_deltas,
+
[PATCH RFC 6/8] Input: atmel_mxt_ts - Add support for reference data
There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 78
1 file changed, 60 insertions(+), 18 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 6c9fbc0..49fbe2a 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -132,6 +132,7 @@ struct t9_range {
/* MXT_DEBUG_DIAGNOSTIC_T37 */
#define MXT_DIAGNOSTIC_PAGEUP 0x01
#define MXT_DIAGNOSTIC_DELTAS 0x10
+#define MXT_DIAGNOSTIC_REFS 0x11
#define MXT_DIAGNOSTIC_SIZE128
#define MXT_FAMILY_1386160
@@ -211,6 +212,8 @@ enum t100_type {
#define MXT_PIXELS_PER_MM 20
+struct mxt_data;
+
struct mxt_info {
u8 family_id;
u8 variant_id;
@@ -230,6 +233,29 @@ struct mxt_object {
} __packed;
#ifdef CONFIG_DEBUG_FS
+struct mxt_debug_datatype {
+ u8 mode;
+ char *name;
+};
+
+struct mxt_debug_datatype_meta {
+ struct mxt_data *data;
+ const struct mxt_debug_datatype *datatype;
+ struct dentry *dent;
+ void *buf;
+};
+
+static const struct mxt_debug_datatype datatypes[] = {
+ {
+ .mode = MXT_DIAGNOSTIC_REFS,
+ .name = "refs",
+ },
+ {
+ .mode = MXT_DIAGNOSTIC_DELTAS,
+ .name = "deltas",
+ }
+};
+
struct mxt_dbg {
u16 t37_address;
u16 diag_cmd_address;
@@ -240,6 +266,8 @@ struct mxt_dbg {
struct dentry *debugfs_dir;
struct dentry *deltas_file;
+ struct dentry *refs_file;
+ struct mxt_debug_datatype_meta dt_meta[ARRAY_SIZE(datatypes)];
};
#endif
@@ -2166,14 +2194,15 @@ static void mxt_convert_debug_pages(struct mxt_data
*data)
}
}
-static int mxt_open_deltas(struct inode *inode, struct file *file)
+static int mxt_dbg_open(struct inode *inode, struct file *file)
{
- struct mxt_data *data = inode->i_private;
+ struct mxt_debug_datatype_meta *dtm = inode->i_private;
+ struct mxt_data *data = dtm->data;
struct mxt_dbg *dbg = &data->dbg;
int retries = 0;
int page;
int ret;
- u8 mode = MXT_DIAGNOSTIC_DELTAS;
+ u8 mode = dtm->datatype->mode;
u8 cmd = mode;
struct t37_debug *p;
@@ -2218,24 +2247,23 @@ wait_cmd:
}
mxt_convert_debug_pages(data);
- file->private_data = data;
+ file->private_data = dtm;
return 0;
}
-static ssize_t mxt_read_deltas(struct file *file, char __user *ubuf,
- size_t count, loff_t *offp)
+static ssize_t mxt_dbg_read(struct file *file, char __user *ubuf,
+size_t count, loff_t *offp)
{
- struct mxt_data *data = file->private_data;
+ struct mxt_debug_datatype_meta *dtm = file->private_data;
- return simple_read_from_buffer(ubuf, count, offp,
- data->dbg.debug_buf,
- data->dbg.t37_nodes * sizeof(u16));
+ return simple_read_from_buffer(ubuf, count, offp, dtm->buf,
+ dtm->dent->d_inode->i_size);
}
-static const struct file_operations atmel_mxt_deltas_fops = {
- .open = mxt_open_deltas,
- .read = mxt_read_deltas,
+static const struct file_operations atmel_mxt_dbg_fops = {
+ .open = mxt_dbg_open,
+ .read = mxt_dbg_read,
};
static void mxt_debugfs_remove(struct mxt_data *data)
@@ -2248,7 +2276,10 @@ static void mxt_debugfs_init(struct mxt_data *data)
struct mxt_info *info = &data->info;
struct mxt_dbg *dbg = &data->dbg;
struct mxt_object *object;
+ struct dentry *dent;
+ struct mxt_debug_datatype_meta *dtm;
char dirname[50];
+ int i;
object = mxt_get_object(data, MXT_GEN_COMMAND_T6);
if (!object)
@@ -2299,11 +2330,22 @@ static void mxt_debugfs_init(struct mxt_data *data)
if (!dbg->t37_buf)
goto error;
- dbg->deltas_file = debugfs_create_file("deltas", S_IRUGO,
- dbg->debugfs_dir, data,
- &atmel_mxt_deltas_fops);
- if (!dbg->deltas_file)
- goto error;
+ for (i = 0; i < ARRAY_SIZE(datatypes); i++) {
+ dtm = &data->dbg.dt_meta[i];
+
+ dtm->data = data;
+ dtm->datatype = datatypes + i;
+ dtm->buf = dbg->debug_buf;
+
+ dent = debugfs_create_file(datatypes[i].name,
+ S_IRUGO, dbg->debugfs_dir,
+ dtm, &atmel_mxt_dbg_fops);
+ if (!dent)
+ goto error;
+
+ dtm->dent = dent;
+ dent->d_inode->i_size = dbg->t37_nodes * sizeof(u16);
+ }
Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
On Wed, Dec 2, 2015 at 11:11 AM, Akshay Bhat wrote: > > > On 11/06/2015 05:02 PM, Guenter Roeck wrote: >> >> On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote: >>> >>> On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck wrote: On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote: > > From: Tim Harvey > > The IMX6 watchdog supports assertion of a signal (WDOG_B) which > can be pinmux'd to an external pin. This is typically used for boards > that > have PMIC's in control of the IMX6 power rails. In fact, failure to use > such an external reset on boards with external PMIC's can result in > various > hangs due to the IMX6 not being fully reset [1] as well as the board > failing > to reset because its PMIC has not been reset to provide adequate > voltage for > the CPU when coming out of reset at 800Mhz. > > This uses a new device-tree property 'ext-reset-output' to indicate the > board has such a reset and to cause the watchdog to be configured to > assert > WDOG_B instead of an internal reset both on a watchdog timeout and in > system_restart. > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html > > Cc: Lucas Stach > Signed-off-by: Tim Harvey > --- > .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++ > drivers/watchdog/imx2_wdt.c | 20 > ++-- > 2 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > index 8dab6fd..9b89b3a 100644 > --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > @@ -9,6 +9,8 @@ Optional property: properties ? > - big-endian: If present the watchdog device's registers are > implemented > in big endian mode, otherwise in native mode(same with CPU), for > more > detail please see: > Documentation/devicetree/bindings/regmap/regmap.txt. > +- ext-reset-output: If present the watchdog device is configured to > assert its Should that have a vendor prefix ? Also, not sure if "-output" has any real value in the property name. "fsl,external-reset", maybe ? >>> >>> >>> Hi Guenter, >>> >>> I don't see why a vendor prefix is necessary - its a feature of the >>> IMX6 watchdog supported by this driver to be able to trigger an >>> internal chip-level reset and/or an external signal that can be hooked >>> to additional hardware. >>> >> Sounded like vendor specific to me, but then I am not a devicetree >> maintainer, >> so I am not an authority on the subject. > > > Devicetree maintainers, > > Any thoughts? > > Tim, > > After looking at all the other watchdog drivers, it does not appear that > there is any other processor which uses a similar feature. Since imx is the > only processor that appears to support this feature, it might make sense in > making this vendor specific. If in the future it is found more processors > support a similar functionality, it can be revisited and moved out from > being vendor specific? > I'm certainly no expert on device-tree policy. I understand your point, but realize that the driver in question is imx2_wdt.c (compatible = "fsl,imx21-wdt"). This is an IP block inside the silicon of only Freescale chips, so its not like a future omap chip would be using this driver - only fsl devices. So why would it need a 'vendor' property any more than its other properties? Regards, Tim -- 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] mtd: brcmnand: Workaround false ECC uncorrectable errors
Hi, On Wed, Dec 02, 2015 at 09:44:04PM +0100, Jonas Gorski wrote: > On Wed, Dec 2, 2015 at 9:17 PM, Simon Arlott wrote: > > On 01/12/15 10:41, Jonas Gorski wrote: > >> On Sat, Nov 28, 2015 at 8:23 PM, Simon Arlott wrote: > >>> + > >>> + /* Go to start of buffer */ > >>> + buf -= FC_WORDS; > >>> + > >>> + /* Erased if all data bytes are 0xFF */ > >>> + buf_erased = memchr_inv(buf, 0xFF, FC_WORDS) == NULL; > >>> + > >>> + if (!buf_erased) > >>> + goto out_free; > >> > >> We now have a function exactly for that use case in 4.4, > >> nand_check_erased_buf [1], consider using that. This also has the > >> benefit of treating bit flips as correctable as long as the ECC scheme > >> is strong enough. > > > > I have no idea whether or not it's appropriate to specify > > bitflips_threshold > 0 so it'd just be a more complex way to do > > a memchr_inv() search for 0xFF. > > The threshold would be the amount of bitflips the code can correct, so > basically ecc.strength (at least that is my understanding). > > > The code also has to check for the hamming code bytes being all 0x00, > > because according to the comments [2], the controller also has > > difficulty with the non-erased all-0xFFs scenario too. > > According to brcmnand.c hamming can fix up to fifteen bitflips, but in Hamming only protects 1 bitflip. The '15' is the value used by the controller to represent Hamming (i.e., there is no BCH-15). > the current code you would fail a hamming protected all-0xff-page for > even a single bitflip in the data or in the ecc bytes, which means > that all-0xff-pages wouldn't be protected at all. BTW, I think Kamal had code to handle protecting bitflips in erased pages code in the Broadcom STB Linux BSP. Perhaps he can port that to upstream with nand_check_erased_ecc_chunk()? IIUC, that would probably handle your case too, Simon, although it wouldn't be optimal for an all-0xff check (i.e., bitflip_threshold == 0). If that's really an issue (i.e., we have an implementation + data), I'm sure we could add optimization to nand_check_erased_ecc_chunk() to support the bitflip_threshold == 0 case. Brian -- 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] sysctl: enable strict writes
SYSCTL_WRITES_WARN was added in f4aacea2f5d1a ("sysctl: allow for strict
write position handling"), and released in v3.16 in August of 2014. Since
then I can find only 1 instance of non-zero offset writing[1], and it
was fixed immediately in CRIU[2]. As such, it appears safe to flip this
to the strict state now.
[1] https://www.google.com/search?q="when%20file%20position%20was%20not%200";
[2] http://lists.openvz.org/pipermail/criu/2015-April/019819.html
Signed-off-by: Kees Cook
---
Documentation/sysctl/kernel.txt | 15 +++
kernel/sysctl.c | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index af70d1541d3a..be61d53e997f 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -810,14 +810,13 @@ via the /proc/sys interface:
Each write syscall must fully contain the sysctl value to be
written, and multiple writes on the same sysctl file descriptor
will rewrite the sysctl value, regardless of file position.
- 0 - (default) Same behavior as above, but warn about processes that
- perform writes to a sysctl file descriptor when the file position
- is not 0.
- 1 - Respect file position when writing sysctl strings. Multiple writes
- will append to the sysctl value buffer. Anything past the max length
- of the sysctl value buffer will be ignored. Writes to numeric sysctl
- entries must always be at file position 0 and the value must be
- fully contained in the buffer sent in the write syscall.
+ 0 - Same behavior as above, but warn about processes that perform writes
+ to a sysctl file descriptor when the file position is not 0.
+ 1 - (default) Respect file position when writing sysctl strings. Multiple
+ writes will append to the sysctl value buffer. Anything past the max
+ length of the sysctl value buffer will be ignored. Writes to numeric
+ sysctl entries must always be at file position 0 and the value must
+ be fully contained in the buffer sent in the write syscall.
==
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index dc6858d6639e..081873afba6b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -173,7 +173,7 @@ extern int no_unaligned_warning;
#define SYSCTL_WRITES_WARN 0
#define SYSCTL_WRITES_STRICT1
-static int sysctl_writes_strict = SYSCTL_WRITES_WARN;
+static int sysctl_writes_strict = SYSCTL_WRITES_STRICT;
static int proc_do_cad_pid(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos);
--
1.9.1
--
Kees Cook
Chrome OS & Brillo Security
--
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 4/5] net: thunderx: Switchon carrier only upon interface link up
From: Pavel Fedin Date: Wed, 02 Dec 2015 14:30:37 +0300 > Hello again! > >> Subject: RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon >> interface link up >> >> Just a reminder, we have issue with this one too, which is not addressed >> yet. > > I have examined the problem thoroughly and discovered that it is a problem > with experimental BGX driver patches on my 4.2 host > kernel build. It fails to send NIC_MBOX_MSG_BGX_LINK_CHANGE, so nothing works. > I have retested this series on top of 4.3 running on ThunderX. It has good > BGX driver and everything works fine. Therefore, the > whole series can be safely applied and... > > Tested-by: Pavel Fedin Ok, thanks for confirming things are fine now. I'll apply this series. -- 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: [REGRESSION] b8b2c7d845 breaks suspend/resume in qemu
On Wed, Dec 02, 2015 at 12:46:10PM -0800, John Stultz wrote: > On Wed, Dec 2, 2015 at 12:39 PM, John Stultz wrote: > > Hey Uwe, > > > > So I recently noticed that my alarmtimer suspend/resume tests > > (selftests/timers/alartimer-suspend.c) were getting stuck testing w/ > > 4.4-rc kernels when running under qemu (x86_64). > > > > I've bisected this back to: b8b2c7d845 (base/platform: assert that > > dev_pm_domain callbacks are called unconditionally). > > > > I've not yet spent done any further analysis (bisecting it down, after > > some user-error, ate up my morning). But I wanted to see if there were > > any initial suggestions for solving this. > > Just one other quick note: Reverting this commit against 4.4-rc3 seems > to work as well. There's a proposed patch to resolve this on the mailing list, "Subject: [PATCH] base/platform: fix panic when probe function is NULL" from Martin, but I think he's going to send me an updated version before I forward it on to Linus. It should resolve your issue, can you verify that? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
On Wed, 2015-12-02 at 12:54 -0800, Dan Williams wrote: > On Wed, Dec 2, 2015 at 1:37 PM, Toshi Kani wrote: > > On Wed, 2015-12-02 at 11:57 -0800, Dan Williams wrote: > [..] > > > The whole point of __get_user_page_fast() is to avoid the overhead of > > > taking the mm semaphore to access the vma. _PAGE_SPECIAL simply tells > > > __get_user_pages_fast that it needs to fallback to the > > > __get_user_pages slow path. > > > > I see. Then, I think gup_huge_pmd() can simply return 0 when !pfn_valid(), > > instead of VM_BUG_ON. > > Is pfn_valid() a reliable check? It seems to be based on a max_pfn > per node... what happens when pmem is located below that point. I > haven't been able to convince myself that we won't get false > positives, but maybe I'm missing something. I believe we use the version of pfn_valid() in linux/mmzone.h. Thanks, -Toshi -- 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 v16 00/22] Richacls (Core and Ext4)
Here is another update to the richacl patch queue. I still think these patches are ready for the next merge window. In reply to the previous posting (https://lkml.org/lkml/2015/11/11/60), Christoph has commented that richacls should use new syscalls as their user-space interface instead of xattrs; the arguments didn't seem very convincing though. So instead, I started looking into things that can be improved in the xattr code (see https://lkml.org/lkml/2015/12/2/343). Changes since the last posting: * Fix a typo (https://lkml.org/lkml/2015/11/10/681) that was causing getxattr to return 95 instead of failing with error EOPNOTSUPP when richacls were disabled. * The user namespace conversions for richacls have moved from the VFS into the get and set operations of richacl_xattr_handler; the VFS doesn't have to bother anymore. (POSIX ACLs arguably should behave the same way, but fixing that without breaking anything is tricky.) The complete patch queue is available in git form here: git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \ richacl-2015-11-09 The richacl user-space utilitites, man pages, and test suite are available here: https://github.com/andreas-gruenbacher/richacl Changes to other user-space packages for richacl are available here: https://github.com/andreas-gruenbacher/coreutils https://github.com/andreas-gruenbacher/e2fsprogs https://github.com/andreas-gruenbacher/xfsprogs-dev https://github.com/andreas-gruenbacher/nfs-utils Please see the richacl homepage for more information: http://www.bestbits.at/richacl/ Thanks, Andreas Andreas Gruenbacher (20): vfs: Add IS_ACL() and IS_RICHACL() tests vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags vfs: Make the inode passed to inode_change_ok non-const vfs: Add permission flags for setting file attributes richacl: In-memory representation and helper functions richacl: Permission mapping functions richacl: Compute maximum file masks from an acl richacl: Permission check algorithm posix_acl: Unexport acl_by_type and make it static vfs: Cache base_acl objects in inodes vfs: Add get_richacl and set_richacl inode operations vfs: Cache richacl in struct inode richacl: Update the file masks in chmod() richacl: Check if an acl is equivalent to a file mode richacl: Create-time inheritance richacl: Automatic Inheritance richacl: xattr mapping functions richacl: Add richacl xattr handler vfs: Add richacl permission checking Aneesh Kumar K.V (2): ext4: Add richacl support ext4: Add richacl feature flag drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +- fs/Kconfig | 3 + fs/Makefile | 2 + fs/attr.c | 81 +++- fs/ext4/Kconfig | 11 + fs/ext4/Makefile| 1 + fs/ext4/ext4.h | 6 +- fs/ext4/file.c | 3 + fs/ext4/ialloc.c| 11 +- fs/ext4/inode.c | 12 +- fs/ext4/namei.c | 5 + fs/ext4/richacl.c | 142 ++ fs/ext4/richacl.h | 40 ++ fs/ext4/super.c | 49 +- fs/ext4/xattr.c | 7 + fs/f2fs/acl.c | 4 +- fs/inode.c | 15 +- fs/jffs2/acl.c | 10 +- fs/namei.c | 118 +++-- fs/posix_acl.c | 50 +-- fs/richacl_base.c | 564 fs/richacl_inode.c | 333 ++ fs/richacl_xattr.c | 298 + fs/xattr.c | 34 +- include/linux/fs.h | 60 ++- include/linux/posix_acl.h | 13 +- include/linux/richacl.h | 208 + include/linux/richacl_xattr.h | 44 ++ include/uapi/linux/Kbuild | 2 + include/uapi/linux/fs.h | 3 +- include/uapi/linux/richacl.h| 152 +++ include/uapi/linux/richacl_xattr.h | 44 ++ include/uapi/linux/xattr.h | 2 + 33 files changed, insertions(+), 107 deletions(-) create mode 100644 fs/ext4/richacl.c create mode 100644 fs/ext4/richacl.h create mode 100644 fs/richacl_base.c create mode 100644 fs/richacl_inode.c create mode 100644 fs/richacl_xattr.c create mode 100644 include/linux/richacl.h create mode 100644 include/linux/richac
[PATCH v16 03/22] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags
Normally, deleting a file requires MAY_WRITE access to the parent
directory. With richacls, a file may be deleted with MAY_DELETE_CHILD access
to the parent directory or with MAY_DELETE_SELF access to the file.
To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission()
when checking for delete access inside a directory, and MAY_DELETE_SELF
when checking for delete access to a file itelf.
The MAY_DELETE_SELF permission overrides the sticky directory check.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/namei.c | 20
include/linux/fs.h | 2 ++
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 3216e73..1284157 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -453,9 +453,9 @@ static int sb_permission(struct super_block *sb, struct
inode *inode, int mask)
* this, letting us set arbitrary permissions for filesystem access without
* changing the "normal" UIDs which are used for other things.
*
- * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE, or
- * MAY_CREATE_DIR are set. That way, file systems that don't support these
- * permissions will check for MAY_WRITE instead.
+ * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE,
+ * MAY_CREATE_DIR, or MAY_DELETE_CHILD are set. That way, file systems that
+ * don't support these permissions will check for MAY_WRITE instead.
*/
int inode_permission(struct inode *inode, int mask)
{
@@ -2561,14 +2561,18 @@ static int may_delete_or_replace(struct inode *dir,
struct dentry *victim,
BUG_ON(victim->d_parent->d_inode != dir);
audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
- error = inode_permission(dir, mask);
+ error = inode_permission(dir, mask | MAY_WRITE | MAY_DELETE_CHILD);
+ if (!error && check_sticky(dir, inode))
+ error = -EPERM;
+ if (error && IS_RICHACL(inode) &&
+ inode_permission(inode, MAY_DELETE_SELF) == 0 &&
+ inode_permission(dir, mask) == 0)
+ error = 0;
if (error)
return error;
if (IS_APPEND(dir))
return -EPERM;
-
- if (check_sticky(dir, inode) || IS_APPEND(inode) ||
- IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
+ if (IS_APPEND(inode) || IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
return -EPERM;
if (isdir) {
if (!d_is_dir(victim))
@@ -2586,7 +2590,7 @@ static int may_delete_or_replace(struct inode *dir,
struct dentry *victim,
static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
{
- return may_delete_or_replace(dir, victim, isdir, MAY_WRITE | MAY_EXEC);
+ return may_delete_or_replace(dir, victim, isdir, MAY_EXEC);
}
static int may_replace(struct inode *dir, struct dentry *victim, bool isdir)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index c0d5760..7a45120 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -84,6 +84,8 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int
uptodate);
#define MAY_NOT_BLOCK 0x0080
#define MAY_CREATE_FILE0x0100
#define MAY_CREATE_DIR 0x0200
+#define MAY_DELETE_CHILD 0x0400
+#define MAY_DELETE_SELF0x0800
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
--
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/
[PATCH v16 01/22] vfs: Add IS_ACL() and IS_RICHACL() tests
The vfs does not apply the umask for file systems that support acls. The
test used for this used to be called IS_POSIXACL(). Switch to a new
IS_ACL() test to check for either posix acls or richacls instead. Add a new
MS_RICHACL flag and IS_RICHACL() test for richacls alone. The IS_POSIXACL()
test is still needed by nfsd.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
Reviewed-by: Andreas Dilger
---
fs/Kconfig | 3 +++
fs/namei.c | 8
include/linux/fs.h | 12
include/uapi/linux/fs.h | 3 ++-
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/fs/Kconfig b/fs/Kconfig
index 6ce72d8..379d83e 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -62,6 +62,9 @@ endif # BLOCK
config FS_POSIX_ACL
def_bool n
+config FS_RICHACL
+ def_bool n
+
config EXPORTFS
tristate
diff --git a/fs/namei.c b/fs/namei.c
index d84d7c7..8573e7a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2795,7 +2795,7 @@ static int atomic_open(struct nameidata *nd, struct
dentry *dentry,
}
mode = op->mode;
- if ((open_flag & O_CREAT) && !IS_POSIXACL(dir))
+ if ((open_flag & O_CREAT) && !IS_ACL(dir))
mode &= ~current_umask();
excl = (open_flag & (O_EXCL | O_CREAT)) == (O_EXCL | O_CREAT);
@@ -2979,7 +2979,7 @@ static int lookup_open(struct nameidata *nd, struct path
*path,
/* Negative dentry, just create the file */
if (!dentry->d_inode && (op->open_flag & O_CREAT)) {
umode_t mode = op->mode;
- if (!IS_POSIXACL(dir->d_inode))
+ if (!IS_ACL(dir->d_inode))
mode &= ~current_umask();
/*
* This write is needed to ensure that a
@@ -3550,7 +3550,7 @@ retry:
if (IS_ERR(dentry))
return PTR_ERR(dentry);
- if (!IS_POSIXACL(path.dentry->d_inode))
+ if (!IS_ACL(path.dentry->d_inode))
mode &= ~current_umask();
error = security_path_mknod(&path, dentry, mode, dev);
if (error)
@@ -3619,7 +3619,7 @@ retry:
if (IS_ERR(dentry))
return PTR_ERR(dentry);
- if (!IS_POSIXACL(path.dentry->d_inode))
+ if (!IS_ACL(path.dentry->d_inode))
mode &= ~current_umask();
error = security_path_mkdir(&path, dentry, mode);
if (!error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..58e0a19 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1766,6 +1766,12 @@ struct super_operations {
#define IS_IMMUTABLE(inode)((inode)->i_flags & S_IMMUTABLE)
#define IS_POSIXACL(inode) __IS_FLG(inode, MS_POSIXACL)
+#ifdef CONFIG_FS_RICHACL
+#define IS_RICHACL(inode) __IS_FLG(inode, MS_RICHACL)
+#else
+#define IS_RICHACL(inode) 0
+#endif
+
#define IS_DEADDIR(inode) ((inode)->i_flags & S_DEAD)
#define IS_NOCMTIME(inode) ((inode)->i_flags & S_NOCMTIME)
#define IS_SWAPFILE(inode) ((inode)->i_flags & S_SWAPFILE)
@@ -1779,6 +1785,12 @@ struct super_operations {
(inode)->i_rdev == WHITEOUT_DEV)
/*
+ * IS_ACL() tells the VFS to not apply the umask
+ * and use check_acl for acl permission checks when defined.
+ */
+#define IS_ACL(inode) __IS_FLG(inode, MS_POSIXACL | MS_RICHACL)
+
+/*
* Inode state bits. Protected by inode->i_lock
*
* Three bits determine the dirty state of the inode, I_DIRTY_SYNC,
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index f15d980..324f438 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -81,7 +81,7 @@ struct inodes_stat_t {
#define MS_VERBOSE 32768 /* War is peace. Verbosity is silence.
MS_VERBOSE is deprecated. */
#define MS_SILENT 32768
-#define MS_POSIXACL(1<<16) /* VFS does not apply the umask */
+#define MS_POSIXACL(1<<16) /* Supports POSIX ACLs */
#define MS_UNBINDABLE (1<<17) /* change to unbindable */
#define MS_PRIVATE (1<<18) /* change to private */
#define MS_SLAVE (1<<19) /* change to slave */
@@ -91,6 +91,7 @@ struct inodes_stat_t {
#define MS_I_VERSION (1<<23) /* Update inode I_version field */
#define MS_STRICTATIME (1<<24) /* Always perform atime updates */
#define MS_LAZYTIME(1<<25) /* Update the on-disk [acm]times lazily */
+#define MS_RICHACL (1<<26) /* Supports richacls */
/* These sb flags are internal to the kernel */
#define MS_NOSEC (1<<28)
--
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/
[PATCH v16 02/22] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags
Richacls distinguish between creating non-directories and directories. To
support that, add an isdir parameter to may_create(). When checking
inode_permission() for create permission, pass in an additional
MAY_CREATE_FILE or MAY_CREATE_DIR mask flag.
Add may_replace() to allow checking for delete and create access when
replacing an existing file in vfs_rename().
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
Reviewed-by: Andreas Dilger
---
fs/namei.c | 49 +
include/linux/fs.h | 2 ++
2 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 8573e7a..3216e73 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -453,7 +453,9 @@ static int sb_permission(struct super_block *sb, struct
inode *inode, int mask)
* this, letting us set arbitrary permissions for filesystem access without
* changing the "normal" UIDs which are used for other things.
*
- * When checking for MAY_APPEND, MAY_WRITE must also be set in @mask.
+ * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE, or
+ * MAY_CREATE_DIR are set. That way, file systems that don't support these
+ * permissions will check for MAY_WRITE instead.
*/
int inode_permission(struct inode *inode, int mask)
{
@@ -2546,7 +2548,8 @@ EXPORT_SYMBOL(__check_sticky);
* 10. We don't allow removal of NFS sillyrenamed files; it's handled by
* nfs_async_unlink().
*/
-static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
+static int may_delete_or_replace(struct inode *dir, struct dentry *victim,
+bool isdir, int mask)
{
struct inode *inode = d_backing_inode(victim);
int error;
@@ -2558,7 +2561,7 @@ static int may_delete(struct inode *dir, struct dentry
*victim, bool isdir)
BUG_ON(victim->d_parent->d_inode != dir);
audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
- error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
+ error = inode_permission(dir, mask);
if (error)
return error;
if (IS_APPEND(dir))
@@ -2581,6 +2584,18 @@ static int may_delete(struct inode *dir, struct dentry
*victim, bool isdir)
return 0;
}
+static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
+{
+ return may_delete_or_replace(dir, victim, isdir, MAY_WRITE | MAY_EXEC);
+}
+
+static int may_replace(struct inode *dir, struct dentry *victim, bool isdir)
+{
+ int mask = isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE;
+
+ return may_delete_or_replace(dir, victim, isdir, mask | MAY_WRITE |
MAY_EXEC);
+}
+
/* Check whether we can create an object with dentry child in directory
* dir.
* 1. We can't do it if child already exists (open has special treatment for
@@ -2589,14 +2604,16 @@ static int may_delete(struct inode *dir, struct dentry
*victim, bool isdir)
* 3. We should have write and exec permissions on dir
* 4. We can't do it if dir is immutable (done in permission())
*/
-static inline int may_create(struct inode *dir, struct dentry *child)
+static inline int may_create(struct inode *dir, struct dentry *child, bool
isdir)
{
+ int mask = isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE;
+
audit_inode_child(dir, child, AUDIT_TYPE_CHILD_CREATE);
if (child->d_inode)
return -EEXIST;
if (IS_DEADDIR(dir))
return -ENOENT;
- return inode_permission(dir, MAY_WRITE | MAY_EXEC);
+ return inode_permission(dir, MAY_WRITE | MAY_EXEC | mask);
}
/*
@@ -2646,7 +2663,7 @@ EXPORT_SYMBOL(unlock_rename);
int vfs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
bool want_excl)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
@@ -3491,7 +3508,7 @@ EXPORT_SYMBOL(user_path_create);
int vfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, dev_t
dev)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
@@ -3583,7 +3600,7 @@ SYSCALL_DEFINE3(mknod, const char __user *, filename,
umode_t, mode, unsigned, d
int vfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, true);
unsigned max_links = dir->i_sb->s_max_links;
if (error)
@@ -3664,7 +3681,7 @@ EXPORT_SYMBOL(dentry_unhash);
int vfs_rmdir(struct inode *dir, struct dentry *dentry)
{
- int error = may_delete(dir, dentry, 1);
+ int error = may_delete(dir, dentry, true);
if (error)
return error;
@@ -3786,7 +3803,7 @@ SYSCALL_DEFINE1(rmdir, const char __user *, pathname)
int vfs_unlink(struct inode *dir, struct dentry *dentry, struct inode
**delegated_inode)
{
[PATCH v16 04/22] vfs: Make the inode passed to inode_change_ok non-const
We will need to call iop->permission and iop->get_acl from
inode_change_ok() for additional permission checks, and both take a
non-const inode.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
Reviewed-by: Andreas Dilger
---
fs/attr.c | 2 +-
include/linux/fs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 6530ced..328be71 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -28,7 +28,7 @@
* Should be called as the first thing in ->setattr implementations,
* possibly after taking additional locks.
*/
-int inode_change_ok(const struct inode *inode, struct iattr *attr)
+int inode_change_ok(struct inode *inode, struct iattr *attr)
{
unsigned int ia_valid = attr->ia_valid;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7a45120..65cebcb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2857,7 +2857,7 @@ extern int buffer_migrate_page(struct address_space *,
#define buffer_migrate_page NULL
#endif
-extern int inode_change_ok(const struct inode *, struct iattr *);
+extern int inode_change_ok(struct inode *, struct iattr *);
extern int inode_newsize_ok(const struct inode *, loff_t offset);
extern void setattr_copy(struct inode *inode, const struct iattr *attr);
--
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/
[PATCH v16 05/22] vfs: Add permission flags for setting file attributes
Richacls support permissions that allow to take ownership of a file,
change the file permissions, and set the file timestamps. Support that
by introducing new permission mask flags and by checking for those mask
flags in inode_change_ok().
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/attr.c | 79 +-
include/linux/fs.h | 3 +++
2 files changed, 70 insertions(+), 12 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 328be71..85483e0 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -17,6 +17,65 @@
#include
/**
+ * inode_extended_permission - permissions beyond read/write/execute
+ *
+ * Check for permissions that only richacls can currently grant.
+ */
+static int inode_extended_permission(struct inode *inode, int mask)
+{
+ if (!IS_RICHACL(inode))
+ return -EPERM;
+ return inode_permission(inode, mask);
+}
+
+static bool inode_uid_change_ok(struct inode *inode, kuid_t ia_uid)
+{
+ if (uid_eq(current_fsuid(), inode->i_uid) &&
+ uid_eq(ia_uid, inode->i_uid))
+ return true;
+ if (uid_eq(current_fsuid(), ia_uid) &&
+ inode_extended_permission(inode, MAY_TAKE_OWNERSHIP) == 0)
+ return true;
+ if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ return true;
+ return false;
+}
+
+static bool inode_gid_change_ok(struct inode *inode, kgid_t ia_gid)
+{
+ int in_group = in_group_p(ia_gid);
+ if (uid_eq(current_fsuid(), inode->i_uid) &&
+ (in_group || gid_eq(ia_gid, inode->i_gid)))
+ return true;
+ if (in_group && inode_extended_permission(inode, MAY_TAKE_OWNERSHIP) ==
0)
+ return true;
+ if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ return true;
+ return false;
+}
+
+/**
+ * inode_owner_permitted_or_capable
+ *
+ * Check for permissions implicitly granted to the owner, like MAY_CHMOD or
+ * MAY_SET_TIMES. Equivalent to inode_owner_or_capable for file systems
+ * without support for those permissions.
+ */
+static bool inode_owner_permitted_or_capable(struct inode *inode, int mask)
+{
+ struct user_namespace *ns;
+
+ if (uid_eq(current_fsuid(), inode->i_uid))
+ return true;
+ if (inode_extended_permission(inode, mask) == 0)
+ return true;
+ ns = current_user_ns();
+ if (ns_capable(ns, CAP_FOWNER) && kuid_has_mapping(ns, inode->i_uid))
+ return true;
+ return false;
+}
+
+/**
* inode_change_ok - check if attribute changes to an inode are allowed
* @inode: inode to check
* @attr: attributes to change
@@ -47,22 +106,18 @@ int inode_change_ok(struct inode *inode, struct iattr
*attr)
return 0;
/* Make sure a caller can chown. */
- if ((ia_valid & ATTR_UID) &&
- (!uid_eq(current_fsuid(), inode->i_uid) ||
-!uid_eq(attr->ia_uid, inode->i_uid)) &&
- !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
- return -EPERM;
+ if (ia_valid & ATTR_UID)
+ if (!inode_uid_change_ok(inode, attr->ia_uid))
+ return -EPERM;
/* Make sure caller can chgrp. */
- if ((ia_valid & ATTR_GID) &&
- (!uid_eq(current_fsuid(), inode->i_uid) ||
- (!in_group_p(attr->ia_gid) && !gid_eq(attr->ia_gid, inode->i_gid)))
&&
- !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
- return -EPERM;
+ if (ia_valid & ATTR_GID)
+ if (!inode_gid_change_ok(inode, attr->ia_gid))
+ return -EPERM;
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
- if (!inode_owner_or_capable(inode))
+ if (!inode_owner_permitted_or_capable(inode, MAY_CHMOD))
return -EPERM;
/* Also check the setgid bit! */
if (!in_group_p((ia_valid & ATTR_GID) ? attr->ia_gid :
@@ -73,7 +128,7 @@ int inode_change_ok(struct inode *inode, struct iattr *attr)
/* Check for setting the inode time. */
if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET | ATTR_TIMES_SET)) {
- if (!inode_owner_or_capable(inode))
+ if (!inode_owner_permitted_or_capable(inode, MAY_SET_TIMES))
return -EPERM;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 65cebcb..e9e1139 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -86,6 +86,9 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int
uptodate);
#define MAY_CREATE_DIR 0x0200
#define MAY_DELETE_CHILD 0x0400
#define MAY_DELETE_SELF0x0800
+#define MAY_TAKE_OWNERSHIP 0x1000
+#define MAY_CHMOD 0x2000
+#define MAY_SET_TIMES 0x4000
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must co
[PATCH v16 07/22] richacl: Permission mapping functions
We need to map from POSIX permissions to NFSv4 permissions when a
chmod() is done, from NFSv4 permissions to POSIX permissions when an acl
is set (which implicitly sets the file permission bits), and from the
MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when
doing an access check in a richacl.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c| 118 +++
include/linux/richacl.h | 3 ++
include/uapi/linux/richacl.h | 44
3 files changed, 165 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index c3ec928..a393001 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -65,3 +65,121 @@ richace_copy(struct richace *to, const struct richace *from)
{
memcpy(to, from, sizeof(struct richace));
}
+
+/*
+ * richacl_mask_to_mode - compute the file permission bits from mask
+ * @mask: %RICHACE_* permission mask
+ *
+ * Compute the file permission bits corresponding to a particular set of
+ * richacl permissions.
+ *
+ * See richacl_masks_to_mode().
+ */
+static int
+richacl_mask_to_mode(unsigned int mask)
+{
+ int mode = 0;
+
+ if (mask & RICHACE_POSIX_MODE_READ)
+ mode |= S_IROTH;
+ if (mask & RICHACE_POSIX_MODE_WRITE)
+ mode |= S_IWOTH;
+ if (mask & RICHACE_POSIX_MODE_EXEC)
+ mode |= S_IXOTH;
+
+ return mode;
+}
+
+/**
+ * richacl_masks_to_mode - compute file permission bits from file masks
+ *
+ * When setting a richacl, we set the file permission bits to indicate maximum
+ * permissions: for example, we set the Write permission when a mask contains
+ * RICHACE_APPEND_DATA even if it does not also contain RICHACE_WRITE_DATA.
+ *
+ * Permissions which are not in RICHACE_POSIX_MODE_READ,
+ * RICHACE_POSIX_MODE_WRITE, or RICHACE_POSIX_MODE_EXEC cannot be represented
+ * in the file permission bits. Such permissions can still be effective, but
+ * not for new files or after a chmod(); they must be explicitly enabled in the
+ * richacl.
+ */
+int
+richacl_masks_to_mode(const struct richacl *acl)
+{
+ return richacl_mask_to_mode(acl->a_owner_mask) << 6 |
+ richacl_mask_to_mode(acl->a_group_mask) << 3 |
+ richacl_mask_to_mode(acl->a_other_mask);
+}
+EXPORT_SYMBOL_GPL(richacl_masks_to_mode);
+
+/**
+ * richacl_mode_to_mask - compute a file mask from the lowest three mode bits
+ * @mode: mode to convert to richacl permissions
+ *
+ * When the file permission bits of a file are set with chmod(), this specifies
+ * the maximum permissions that processes will get. All permissions beyond
+ * that will be removed from the file masks, and become ineffective.
+ */
+unsigned int
+richacl_mode_to_mask(umode_t mode)
+{
+ unsigned int mask = 0;
+
+ if (mode & S_IROTH)
+ mask |= RICHACE_POSIX_MODE_READ;
+ if (mode & S_IWOTH)
+ mask |= RICHACE_POSIX_MODE_WRITE;
+ if (mode & S_IXOTH)
+ mask |= RICHACE_POSIX_MODE_EXEC;
+
+ return mask;
+}
+
+/**
+ * richacl_want_to_mask - convert the iop->permission want argument to a mask
+ * @want: @want argument of the permission inode operation
+ *
+ * When checking for append, @want is (MAY_WRITE | MAY_APPEND).
+ *
+ * Richacls use the iop->may_create and iop->may_delete hooks which are used
+ * for checking if creating and deleting files is allowed. These hooks do not
+ * use richacl_want_to_mask(), so we do not have to deal with mapping MAY_WRITE
+ * to RICHACE_ADD_FILE, RICHACE_ADD_SUBDIRECTORY, and RICHACE_DELETE_CHILD
+ * here.
+ */
+unsigned int
+richacl_want_to_mask(unsigned int want)
+{
+ unsigned int mask = 0;
+
+ if (want & MAY_READ)
+ mask |= RICHACE_READ_DATA;
+ if (want & MAY_DELETE_SELF)
+ mask |= RICHACE_DELETE;
+ if (want & MAY_TAKE_OWNERSHIP)
+ mask |= RICHACE_WRITE_OWNER;
+ if (want & MAY_CHMOD)
+ mask |= RICHACE_WRITE_ACL;
+ if (want & MAY_SET_TIMES)
+ mask |= RICHACE_WRITE_ATTRIBUTES;
+ if (want & MAY_EXEC)
+ mask |= RICHACE_EXECUTE;
+ /*
+* differentiate MAY_WRITE from these request
+*/
+ if (want & (MAY_APPEND |
+ MAY_CREATE_FILE | MAY_CREATE_DIR |
+ MAY_DELETE_CHILD)) {
+ if (want & MAY_APPEND)
+ mask |= RICHACE_APPEND_DATA;
+ if (want & MAY_CREATE_FILE)
+ mask |= RICHACE_ADD_FILE;
+ if (want & MAY_CREATE_DIR)
+ mask |= RICHACE_ADD_SUBDIRECTORY;
+ if (want & MAY_DELETE_CHILD)
+ mask |= RICHACE_DELETE_CHILD;
+ } else if (want & MAY_WRITE)
+ mask |= RICHACE_WRITE_DATA;
+ return mask;
+}
+EXPORT_SYMBOL_GPL(richacl_want_to_mask);
diff --git a/include/linux/richacl.h b/in
[PATCH v16 06/22] richacl: In-memory representation and helper functions
A richacl consists of an NFSv4 acl and an owner, group, and other mask.
These three masks correspond to the owner, group, and other file
permission bits, but they contain NFSv4 permissions instead of POSIX
permissions.
Each entry in the NFSv4 acl applies to the file owner (OWNER@), the
owning group (GROUP@), everyone (EVERYONE@), or to a specific uid or
gid.
As in the standard POSIX file permission model, each process is the
owner, group, or other file class. A richacl grants a requested access
only if the NFSv4 acl in the richacl grants the access (according to the
NFSv4 permission check algorithm), and the file mask that applies to the
process includes the requested permissions.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/Makefile | 2 +
fs/richacl_base.c| 67
include/linux/richacl.h | 179 +++
include/uapi/linux/Kbuild| 1 +
include/uapi/linux/richacl.h | 99
5 files changed, 348 insertions(+)
create mode 100644 fs/richacl_base.c
create mode 100644 include/linux/richacl.h
create mode 100644 include/uapi/linux/richacl.h
diff --git a/fs/Makefile b/fs/Makefile
index 79f5225..e5994c4 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_COREDUMP)+= coredump.o
obj-$(CONFIG_SYSCTL) += drop_caches.o
obj-$(CONFIG_FHANDLE) += fhandle.o
+obj-$(CONFIG_FS_RICHACL) += richacl.o
+richacl-y := richacl_base.o
obj-y += quota/
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
new file mode 100644
index 000..c3ec928
--- /dev/null
+++ b/fs/richacl_base.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2006, 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * 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
+
+MODULE_LICENSE("GPL");
+
+/**
+ * richacl_alloc - allocate a richacl
+ * @count: number of entries
+ */
+struct richacl *
+richacl_alloc(int count, gfp_t gfp)
+{
+ size_t size = sizeof(struct richacl) + count * sizeof(struct richace);
+ struct richacl *acl = kzalloc(size, gfp);
+
+ if (acl) {
+ atomic_set(&acl->a_refcount, 1);
+ acl->a_count = count;
+ }
+ return acl;
+}
+EXPORT_SYMBOL_GPL(richacl_alloc);
+
+/**
+ * richacl_clone - create a copy of a richacl
+ */
+struct richacl *
+richacl_clone(const struct richacl *acl, gfp_t gfp)
+{
+ int count = acl->a_count;
+ size_t size = sizeof(struct richacl) + count * sizeof(struct richace);
+ struct richacl *dup = kmalloc(size, gfp);
+
+ if (dup) {
+ memcpy(dup, acl, size);
+ atomic_set(&dup->a_refcount, 1);
+ }
+ return dup;
+}
+
+/**
+ * richace_copy - copy an acl entry
+ */
+void
+richace_copy(struct richace *to, const struct richace *from)
+{
+ memcpy(to, from, sizeof(struct richace));
+}
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
new file mode 100644
index 000..edb8480
--- /dev/null
+++ b/include/linux/richacl.h
@@ -0,0 +1,179 @@
+/*
+ * Copyright (C) 2006, 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * 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 __RICHACL_H
+#define __RICHACL_H
+
+#include
+
+struct richace {
+ unsigned short e_type;
+ unsigned short e_flags;
+ unsigned inte_mask;
+ union {
+ kuid_t uid;
+ kgid_t gid;
+ unsigned intspecial;
+ } e_id;
+};
+
+struct richacl {
+ atomic_ta_refcount;
+ unsigned inta_owner_mask;
+ unsigned inta_group_mask;
+ unsigned inta_other_mask;
+ unsigned short a_count;
+ unsigned short a_flags;
+ struct richace a_entries[0];
+};
+
+#define richacl_for_each_entry(_ace, _acl)
[PATCH v16 09/22] richacl: Permission check algorithm
A richacl roughly grants a requested access if the NFSv4 acl in the
richacl grants the requested permissions according to the NFSv4
permission check algorithm and the file mask that applies to the process
includes the requested permissions.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: "J. Bruce Fields"
---
fs/Makefile | 2 +-
fs/richacl_inode.c | 149
include/linux/richacl.h | 3 +
3 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 fs/richacl_inode.c
diff --git a/fs/Makefile b/fs/Makefile
index e5994c4..d5b45ca 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_SYSCTL) += drop_caches.o
obj-$(CONFIG_FHANDLE) += fhandle.o
obj-$(CONFIG_FS_RICHACL) += richacl.o
-richacl-y := richacl_base.o
+richacl-y := richacl_base.o richacl_inode.o
obj-y += quota/
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
new file mode 100644
index 000..99b3c93
--- /dev/null
+++ b/fs/richacl_inode.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (C) 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * 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
+
+/**
+ * richacl_permission - richacl permission check algorithm
+ * @inode: inode to check
+ * @acl: rich acl of the inode
+ * @want: requested access (MAY_* flags)
+ *
+ * Checks if the current process is granted @mask flags in @acl.
+ */
+int
+richacl_permission(struct inode *inode, const struct richacl *acl,
+ int want)
+{
+ const struct richace *ace;
+ unsigned int mask = richacl_want_to_mask(want);
+ unsigned int requested = mask, denied = 0;
+ int in_owning_group = in_group_p(inode->i_gid);
+ int in_owner_or_group_class = in_owning_group;
+
+ /*
+* A process is
+* - in the owner file class if it owns the file,
+* - in the group file class if it is in the file's owning group or
+* it matches any of the user or group entries, and
+* - in the other file class otherwise.
+* The file class is only relevant for determining which file mask to
+* apply, which only happens for masked acls.
+*/
+ if (acl->a_flags & RICHACL_MASKED) {
+ if ((acl->a_flags & RICHACL_WRITE_THROUGH) &&
+ uid_eq(current_fsuid(), inode->i_uid)) {
+ denied = requested & ~acl->a_owner_mask;
+ goto out;
+ }
+ } else {
+ /*
+* When the acl is not masked, there is no need to determine if
+* the process is in the group class and we can break out
+* earlier of the loop below.
+*/
+ in_owner_or_group_class = 1;
+ }
+
+ /*
+* Check if the acl grants the requested access and determine which
+* file class the process is in.
+*/
+ richacl_for_each_entry(ace, acl) {
+ unsigned int ace_mask = ace->e_mask;
+
+ if (richace_is_inherit_only(ace))
+ continue;
+ if (richace_is_owner(ace)) {
+ if (!uid_eq(current_fsuid(), inode->i_uid))
+ continue;
+ goto entry_matches_owner;
+ } else if (richace_is_group(ace)) {
+ if (!in_owning_group)
+ continue;
+ } else if (richace_is_unix_user(ace)) {
+ if (!uid_eq(current_fsuid(), ace->e_id.uid))
+ continue;
+ if (uid_eq(current_fsuid(), inode->i_uid))
+ goto entry_matches_owner;
+ } else if (richace_is_unix_group(ace)) {
+ if (!in_group_p(ace->e_id.gid))
+ continue;
+ } else
+ goto entry_matches_everyone;
+
+ /*
+* Apply the group file mask to entries other than owner@ and
+* everyone@ or user entries matching the owner. This ensures
+* that we grant the same permissions as the acl computed by
+* richacl_apply_masks().
+*
+* Without this restri
[PATCH v16 10/22] posix_acl: Unexport acl_by_type and make it static
acl_by_type(inode, type) returns a pointer to either inode->i_acl or
inode->i_default_acl depending on type. This is useful in
fs/posix_acl.c, but should never have been visible outside that file.
Signed-off-by: Andreas Gruenbacher
---
fs/posix_acl.c| 3 +--
include/linux/posix_acl.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 4adde1e..aa890e5 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -21,7 +21,7 @@
#include
#include
-struct posix_acl **acl_by_type(struct inode *inode, int type)
+static struct posix_acl **acl_by_type(struct inode *inode, int type)
{
switch (type) {
case ACL_TYPE_ACCESS:
@@ -32,7 +32,6 @@ struct posix_acl **acl_by_type(struct inode *inode, int type)
BUG();
}
}
-EXPORT_SYMBOL(acl_by_type);
struct posix_acl *get_cached_acl(struct inode *inode, int type)
{
diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
index 3e96a6a..5b5a80c 100644
--- a/include/linux/posix_acl.h
+++ b/include/linux/posix_acl.h
@@ -99,7 +99,6 @@ extern int posix_acl_create(struct inode *, umode_t *, struct
posix_acl **,
extern int simple_set_acl(struct inode *, struct posix_acl *, int);
extern int simple_acl_create(struct inode *, struct inode *);
-struct posix_acl **acl_by_type(struct inode *inode, int type);
struct posix_acl *get_cached_acl(struct inode *inode, int type);
struct posix_acl *get_cached_acl_rcu(struct inode *inode, int type);
void set_cached_acl(struct inode *inode, int type, struct posix_acl *acl);
--
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/
[PATCH v16 08/22] richacl: Compute maximum file masks from an acl
Compute upper bound owner, group, and other file masks with as few
permissions as possible without denying any permissions that the NFSv4
acl in a richacl grants.
This algorithm is used when a file inherits an acl at create time and
when an acl is set via a mechanism that does not provide file masks
(such as setting an acl via nfsd). When user-space sets an acl via
setxattr, the extended attribute already includes the file masks.
Setting an acl also sets the file mode permission bits: they are
determined by the file masks; see richacl_masks_to_mode().
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c | 157
include/linux/richacl.h | 1 +
2 files changed, 158 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index a393001..69b806c 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -183,3 +183,160 @@ richacl_want_to_mask(unsigned int want)
return mask;
}
EXPORT_SYMBOL_GPL(richacl_want_to_mask);
+
+/*
+ * Note: functions like richacl_allowed_to_who(),
richacl_group_class_allowed(),
+ * and richacl_compute_max_masks() iterate through the entire acl in reverse
+ * order as an optimization.
+ *
+ * In the standard algorithm, aces are considered in forward order. When a
+ * process matches an ace, the permissions in the ace are either allowed or
+ * denied depending on the ace type. Once a permission has been allowed or
+ * denied, it is no longer considered in further aces.
+ *
+ * By iterating through the acl in reverse order, we can compute the same
+ * result without having to keep track of which permissions have been allowed
+ * and denied already.
+ */
+
+/**
+ * richacl_allowed_to_who - permissions allowed to a specific who value
+ *
+ * Compute the maximum mask values allowed to a specific who value, taking
+ * everyone@ aces into account.
+ */
+static unsigned int richacl_allowed_to_who(struct richacl *acl,
+ struct richace *who)
+{
+ struct richace *ace;
+ unsigned int allowed = 0;
+
+ richacl_for_each_entry_reverse(ace, acl) {
+ if (richace_is_inherit_only(ace))
+ continue;
+ if (richace_is_same_identifier(ace, who) ||
+ richace_is_everyone(ace)) {
+ if (richace_is_allow(ace))
+ allowed |= ace->e_mask;
+ else if (richace_is_deny(ace))
+ allowed &= ~ace->e_mask;
+ }
+ }
+ return allowed;
+}
+
+/**
+ * richacl_group_class_allowed - maximum permissions of the group class
+ *
+ * Compute the maximum mask values allowed to a process in the group class
+ * (i.e., a process which is not the owner but is in the owning group or
+ * matches a user or group acl entry). This includes permissions granted or
+ * denied by everyone@ aces.
+ *
+ * See richacl_compute_max_masks().
+ */
+static unsigned int richacl_group_class_allowed(struct richacl *acl)
+{
+ struct richace *ace;
+ unsigned int everyone_allowed = 0, group_class_allowed = 0;
+ int had_group_ace = 0;
+
+ richacl_for_each_entry_reverse(ace, acl) {
+ if (richace_is_inherit_only(ace) ||
+ richace_is_owner(ace))
+ continue;
+
+ if (richace_is_everyone(ace)) {
+ if (richace_is_allow(ace))
+ everyone_allowed |= ace->e_mask;
+ else if (richace_is_deny(ace))
+ everyone_allowed &= ~ace->e_mask;
+ } else {
+ group_class_allowed |=
+ richacl_allowed_to_who(acl, ace);
+
+ if (richace_is_group(ace))
+ had_group_ace = 1;
+ }
+ }
+ /*
+* If the acl doesn't contain any group@ aces, richacl_allowed_to_who()
+* wasn't called for the owning group. We could make that call now, but
+* we already know the result (everyone_allowed).
+*/
+ if (!had_group_ace)
+ group_class_allowed |= everyone_allowed;
+ return group_class_allowed;
+}
+
+/**
+ * richacl_compute_max_masks - compute upper bound masks
+ *
+ * Computes upper bound owner, group, and other masks so that none of the
+ * permissions allowed by the acl are disabled.
+ *
+ * We don't make assumptions about who the owner is so that the owner can
+ * change with no effect on the file masks or file mode permission bits; this
+ * means that we must assume that all entries can match the owner.
+ */
+void richacl_compute_max_masks(struct richacl *acl)
+{
+ unsigned int gmask = ~0;
+ struct richace *ace;
+
+ /*
+* @gmask contains all permissions which the group class is ever
+* allowed. We use it to avoid addin
[PATCH v16 14/22] richacl: Update the file masks in chmod()
Doing a chmod() sets the file mode, which includes the file permission
bits. When a file has a richacl, the permissions that the richacl
grants need to be limited to what the new file permission bits allow.
This is done by setting the file masks in the richacl to what the file
permission bits map to. The richacl access check algorithm takes the
file masks into account, which ensures that the richacl cannot grant too
many permissions.
It is possible to explicitly add permissions to the file masks which go
beyond what the file permission bits can grant (like the
RICHACE_WRITE_ACL permission). The POSIX.1 standard calls this an
alternate file access control mechanism. A subsequent chmod() would
ensure that those permissions are disabled again.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c | 42 ++
fs/richacl_inode.c | 30 ++
include/linux/richacl.h | 2 ++
3 files changed, 74 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index 5826842..e4dd779 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -340,3 +340,45 @@ restart:
acl->a_flags &= ~(RICHACL_WRITE_THROUGH | RICHACL_MASKED);
}
EXPORT_SYMBOL_GPL(richacl_compute_max_masks);
+
+/**
+ * __richacl_chmod - update the file masks to reflect the new mode
+ * @acl: access control list
+ * @mode: new file permission bits including the file type
+ *
+ * Return a copy of @acl where the file masks have been replaced by the file
+ * masks corresponding to the file permission bits in @mode, or returns @acl
+ * itself if the file masks are already up to date. Takes over a reference
+ * to @acl.
+ */
+struct richacl *
+__richacl_chmod(struct richacl *acl, umode_t mode)
+{
+ unsigned int x = S_ISDIR(mode) ? 0 : RICHACE_DELETE_CHILD;
+ unsigned int owner_mask, group_mask, other_mask;
+ struct richacl *clone;
+
+ owner_mask = richacl_mode_to_mask(mode >> 6) & ~x;
+ group_mask = richacl_mode_to_mask(mode >> 3) & ~x;
+ other_mask = richacl_mode_to_mask(mode) & ~x;
+
+ if (acl->a_owner_mask == owner_mask &&
+ acl->a_group_mask == group_mask &&
+ acl->a_other_mask == other_mask &&
+ (acl->a_flags & RICHACL_MASKED) &&
+ (acl->a_flags & RICHACL_WRITE_THROUGH))
+ return acl;
+
+ clone = richacl_clone(acl, GFP_KERNEL);
+ richacl_put(acl);
+ if (!clone)
+ return ERR_PTR(-ENOMEM);
+
+ clone->a_flags |= (RICHACL_WRITE_THROUGH | RICHACL_MASKED);
+ clone->a_owner_mask = owner_mask;
+ clone->a_group_mask = group_mask;
+ clone->a_other_mask = other_mask;
+
+ return clone;
+}
+EXPORT_SYMBOL_GPL(__richacl_chmod);
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
index 52c1595..e329826 100644
--- a/fs/richacl_inode.c
+++ b/fs/richacl_inode.c
@@ -224,3 +224,33 @@ out:
return denied ? -EACCES : 0;
}
EXPORT_SYMBOL_GPL(richacl_permission);
+
+/**
+ * richacl_chmod - filesystem chmod helper
+ * @inode: inode whose file permission bits to change
+ * @mode: new file permission bits including the file type
+ *
+ * Helper for filesystems to use to perform a chmod on the richacl of an inode.
+ */
+int
+richacl_chmod(struct inode *inode, umode_t mode)
+{
+ struct richacl *acl;
+ int retval;
+
+ if (S_ISLNK(mode))
+ return -EOPNOTSUPP;
+ if (!inode->i_op->set_richacl)
+ return -EOPNOTSUPP;
+ acl = get_richacl(inode);
+ if (IS_ERR_OR_NULL(acl))
+ return PTR_ERR(acl);
+ acl = __richacl_chmod(acl, mode);
+ if (IS_ERR(acl))
+ return PTR_ERR(acl);
+ retval = inode->i_op->set_richacl(inode, acl);
+ richacl_put(acl);
+
+ return retval;
+}
+EXPORT_SYMBOL(richacl_chmod);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index 7bf912b6..a2d5600 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -184,8 +184,10 @@ extern int richacl_masks_to_mode(const struct richacl *);
extern unsigned int richacl_mode_to_mask(umode_t);
extern unsigned int richacl_want_to_mask(unsigned int);
extern void richacl_compute_max_masks(struct richacl *);
+extern struct richacl *__richacl_chmod(struct richacl *, umode_t);
/* richacl_inode.c */
extern int richacl_permission(struct inode *, const struct richacl *, int);
+extern int richacl_chmod(struct inode *, umode_t);
#endif /* __RICHACL_H */
--
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/
[PATCH v16 13/22] vfs: Cache richacl in struct inode
Cache richacls in struct inode so that this doesn't have to be done
individually in each filesystem. This is similar to POSIX ACLs.
Signed-off-by: Andreas Gruenbacher
---
fs/inode.c | 11 +--
fs/posix_acl.c | 2 +-
fs/richacl_inode.c | 77 +
include/linux/fs.h | 5 +++-
include/linux/richacl.h | 6
5 files changed, 96 insertions(+), 5 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 1d6d035..3459bc9 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -174,8 +174,11 @@ int inode_init_always(struct super_block *sb, struct inode
*inode)
inode->i_private = NULL;
inode->i_mapping = mapping;
INIT_HLIST_HEAD(&inode->i_dentry); /* buggered by rcu freeing */
-#ifdef CONFIG_FS_POSIX_ACL
- inode->i_acl = inode->i_default_acl = ACL_NOT_CACHED;
+#if defined(CONFIG_FS_POSIX_ACL) || defined(CONFIG_FS_RICHACL)
+ inode->i_acl = ACL_NOT_CACHED;
+# if defined(CONFIG_FS_POSIX_ACL)
+ inode->i_default_acl = ACL_NOT_CACHED;
+# endif
#endif
#ifdef CONFIG_FSNOTIFY
@@ -231,11 +234,13 @@ void __destroy_inode(struct inode *inode)
atomic_long_dec(&inode->i_sb->s_remove_count);
}
-#ifdef CONFIG_FS_POSIX_ACL
+#if defined(CONFIG_FS_POSIX_ACL) || defined(CONFIG_FS_RICHACL)
if (inode->i_acl && inode->i_acl != ACL_NOT_CACHED)
base_acl_put(inode->i_acl);
+# if defined(CONFIG_FS_POSIX_ACL)
if (inode->i_default_acl && inode->i_default_acl != ACL_NOT_CACHED)
base_acl_put(inode->i_default_acl);
+# endif
#endif
this_cpu_dec(nr_inodes);
}
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index df2673f..9e2195a 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -37,7 +37,7 @@ struct posix_acl *get_cached_acl(struct inode *inode, int
type)
{
struct base_acl **p = acl_by_type(inode, type);
struct base_acl *acl = ACCESS_ONCE(*p);
- if (acl) {
+ if (acl && IS_POSIXACL(inode)) {
spin_lock(&inode->i_lock);
acl = *p;
if (acl != ACL_NOT_CACHED)
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
index 99b3c93..52c1595 100644
--- a/fs/richacl_inode.c
+++ b/fs/richacl_inode.c
@@ -20,6 +20,83 @@
#include
#include
+struct richacl *get_cached_richacl(struct inode *inode)
+{
+ struct base_acl *acl;
+
+ acl = ACCESS_ONCE(inode->i_acl);
+ if (acl && IS_RICHACL(inode)) {
+ spin_lock(&inode->i_lock);
+ acl = inode->i_acl;
+ if (acl != ACL_NOT_CACHED)
+ base_acl_get(acl);
+ spin_unlock(&inode->i_lock);
+ }
+ return container_of(acl, struct richacl, a_base);
+}
+EXPORT_SYMBOL_GPL(get_cached_richacl);
+
+struct richacl *get_cached_richacl_rcu(struct inode *inode)
+{
+ struct base_acl *acl = rcu_dereference(inode->i_acl);
+
+ return container_of(acl, struct richacl, a_base);
+}
+EXPORT_SYMBOL_GPL(get_cached_richacl_rcu);
+
+void set_cached_richacl(struct inode *inode, struct richacl *acl)
+{
+ struct base_acl *old = NULL;
+
+ spin_lock(&inode->i_lock);
+ old = inode->i_acl;
+ rcu_assign_pointer(inode->i_acl, &richacl_get(acl)->a_base);
+ spin_unlock(&inode->i_lock);
+ if (old != ACL_NOT_CACHED)
+ base_acl_put(old);
+}
+EXPORT_SYMBOL_GPL(set_cached_richacl);
+
+void forget_cached_richacl(struct inode *inode)
+{
+ struct base_acl *old = NULL;
+
+ spin_lock(&inode->i_lock);
+ old = inode->i_acl;
+ inode->i_acl = ACL_NOT_CACHED;
+ spin_unlock(&inode->i_lock);
+ if (old != ACL_NOT_CACHED)
+ base_acl_put(old);
+}
+EXPORT_SYMBOL_GPL(forget_cached_richacl);
+
+struct richacl *get_richacl(struct inode *inode)
+{
+ struct richacl *acl;
+
+ acl = get_cached_richacl(inode);
+ if (acl != ACL_NOT_CACHED)
+ return acl;
+
+ if (!IS_RICHACL(inode))
+ return NULL;
+
+ /*
+* A filesystem can force a ACL callback by just never filling the
+* ACL cache. But normally you'd fill the cache either at inode
+* instantiation time, or on the first ->get_richacl call.
+*
+* If the filesystem doesn't have a get_richacl() function at all,
+* we'll just create the negative cache entry.
+*/
+ if (!inode->i_op->get_richacl) {
+ set_cached_richacl(inode, NULL);
+ return NULL;
+ }
+ return inode->i_op->get_richacl(inode);
+}
+EXPORT_SYMBOL_GPL(get_richacl);
+
/**
* richacl_permission - richacl permission check algorithm
* @inode: inode to check
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4847417..76d71b2 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -583,6 +583,7 @@ struct base_acl {
};
};
struct posix_acl;
+struct richacl;
#define ACL_NOT_CACHED ((void *)(-1))
#define IOP
Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
On Wed, Dec 02, 2015 at 09:38:10PM +0100, Andrew Lunn wrote: > I agree. We have multiplatform dove already, it is in mach-mvebu. Do > we really need both mach-dove and mach-mvebu dove in one kernel? Only to support my efforts in adding further Dove support. As you know, we've recently added PMU support, and I've recently sent you patches for the remaining clocks. Both of those are laying the foundations for the next big piece, which is support for the GPU on Dove. Most of the effort that's been going on recently has been for the GPU support has been invisible to most people, because much of that is around hammering out the DRM API for it, and getting the thing stable. This is a bigger project than just Dove, other SoCs also have the same GPU family in them, even having multiple separate GPU cores. It's taken a lot of effort and time to hammer this out between three people Lucas, Christian, and myself. Some of the problems are only visible using the graphics stack which I have: xf86-video-armada (which is 2D GPU accelerated for any of these GPUs which support it) vs Christian's MESA (which obviously uses the 3D GPU.) On Dove, it's fairly simple, because the GPU core there is a combined 2D/3D affair, but iMX6 has separate cores, so I've had to come up with a way to synchronise between the cores (which obviously can have an effect on the user API, and therefore must be resolved prior to the initial submission.) The mach-dove code is key to my involvement with this. So, please realise that things have been _real_ busy on Dove, even though you have not seen much from me: that'll be quite normal when most of the effort is going on outside of something being Dove platform specific. What Lucas and myself have been working towards since 4.2 is to get the kernel GPU driver into a state where we can get it merged: we've had the DRM people review it, and they've provided feedback. It's taken a long time to work through that feedback, which included totally ripping out the existing locking and replacing it with a completely new locking scheme - which is never an easy thing to do. (Lucas had a few goes, I also had a few goes, and eventually we ended up with something that is fairly sane but has one very hairy place which was difficult to solve.) Getting this sorted so I can then drop the galcore chunk of code out of my dove tree will be a major step forwards for me, and will allow me to eliminate the reason that I've not been willing to publish the tree in full (because, despite galcore being a supposedly open source kernel driver which lots of people - including companies - seem happy to distribute, there is at least one file in it which do not carry the open source boilerplate, but instead carry a more restrictive license, which as far as I'm concerned makes me unable to publish this code.) Talking about publishing... I do wonder what use that would be. A while back, people were asking me to publish it, and I arranged to publish as much as I could, which included BMM, vmeta, PMU and other associated components. The result of that came to nothing at all, except a more complicated git tree for me to manage which has added to my workload, and thus slowed me down more... in hind sight, I don't know why I bothered. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH (v2) 1/2] reset: Add brcm,bcm6345-reset device tree binding
Add device tree binding for the BCM6345 soft reset controller.
The BCM6345 contains a soft-reset controller activated by setting
a bit (that must previously have cleared).
Signed-off-by: Simon Arlott
---
Renamed to bcm6345, removed "mask" property.
.../bindings/reset/brcm,bcm6345-reset.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
new file mode 100644
index 000..bb9ca6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
@@ -0,0 +1,33 @@
+Broadcom BCM6345 reset controller
+
+The BCM6345 contains a basic soft reset controller in the perf register
+set which resets components using a bit in a register.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "brcm,bcm-reset", "brcm,bcm6345-reset"
+- regmap: The register map phandle
+- offset: Offset in the register map for the reset register (in bytes)
+- #reset-cells:Must be set to 1
+
+Example:
+
+periph_soft_rst: reset-controller {
+ compatible = "brcm,bcm63168-reset", "brcm,bcm6345-reset";
+ regmap = <&periph_cntl>;
+ offset = <0x10>;
+
+ #reset-cells = <1>;
+};
+
+usbh: usbphy@10002700 {
+ compatible = "brcm,bcm63168-usbh";
+ reg = <0x10002700 0x38>;
+ clocks = <&periph_clk 13>, <&timer_clk 18>;
+ resets = <&periph_soft_rst 6>;
+ power-supply = <&power_usbh>;
+ #phy-cells = <0>;
+};
+
--
2.1.4
--
Simon Arlott
--
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/
