Re: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 8:45 PM, David Ahern wrote:
> On 3/27/15 9:19 PM, Yinghai Lu wrote:
>>
>> Good. But we still have annoying warning about "no compatible window".
>>
>> Please try attached patch that support 64bit pci mem space for sparc.
>>
>> BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your
>> .config.
>> otherwise we should more verbose print out.
>> Or did you have DYNAMIC_DEBUG enabled ?
>> If it is that case, can you remove that?
>>
>
> done. attached.
>
ok, we are almost there.
[99510.956337] pci_sun4v f02dbcfc: PCI host bridge to bus :00
[99511.025812] pci_bus :00: root bus resource [io
0x8040-0x80400fff] (bus address [0x-0xfff])
[99511.151039] pci_bus :00: root bus resource [mem
0x8000-0x80007eff] (bus address [0x-0x7eff])
[99511.282693] pci_bus :00: root bus resource [mem
0x8001-0x8007] (bus address [0x-0x6])
[99511.414878] pci_bus :00: root bus resource [bus 00-77]
looks like the offset for mem64 is not right.
Please try attached v2.
Thanks
Yinghai
Subject: [RFC PATCH v2] sparc/PCI: Add mem64 resource parsing for root bus
Found no compatible bridge window warning in boot log from T5-8.
pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no compatible bridge window
and root bus only report io and mem32.
pci_sun4v f02dbcfc: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus address [0x-0x7eff])
pci_bus :00: root bus resource [bus 00-77]
Add mem64 handling in pci_common for sparc, so we can have 64bit resource
registered for bus at first.
Signed-off-by: Yinghai Lu
---
-v2: mem64_space should use mem_space.start as offset.
---
arch/sparc/kernel/pci.c|3 +++
arch/sparc/kernel/pci_common.c | 15 +--
arch/sparc/kernel/pci_impl.h |1 +
3 files changed, 17 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/sparc/kernel/pci.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci.c
+++ linux-2.6/arch/sparc/kernel/pci.c
@@ -663,6 +663,9 @@ struct pci_bus *pci_scan_one_pbm(struct
pbm->io_space.start);
pci_add_resource_offset(, >mem_space,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ pci_add_resource_offset(, >mem64_space,
+ pbm->mem_space.start);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
Index: linux-2.6/arch/sparc/kernel/pci_common.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci_common.c
+++ linux-2.6/arch/sparc/kernel/pci_common.c
@@ -406,6 +406,7 @@ void pci_determine_mem_io_space(struct p
}
num_pbm_ranges = i / sizeof(*pbm_ranges);
+ memset(>mem64_space, 0, sizeof(struct resource));
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = _ranges[i];
@@ -451,7 +452,11 @@ void pci_determine_mem_io_space(struct p
break;
case 3:
- /* XXX 64-bit MEM handling XXX */
+ /* 64-bit MEM handling */
+ pbm->mem64_space.start = a;
+ pbm->mem64_space.end = a + size - 1UL;
+ pbm->mem64_space.flags = IORESOURCE_MEM;
+ break;
default:
break;
@@ -465,15 +470,21 @@ void pci_determine_mem_io_space(struct p
prom_halt();
}
- printk("%s: PCI IO[%llx] MEM[%llx]\n",
+ printk("%s: PCI IO[%llx] MEM[%llx]",
pbm->name,
pbm->io_space.start,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ printk(" MEM64[%llx]",
+ pbm->mem64_space.start);
+ printk("\n");
pbm->io_space.name = pbm->mem_space.name = pbm->name;
request_resource(_resource, >io_space);
request_resource(_resource, >mem_space);
+ if (pbm->mem64_space.flags)
+ request_resource(_resource, >mem64_space);
pci_register_legacy_regions(>io_space,
>mem_space);
Index: linux-2.6/arch/sparc/kernel/pci_impl.h
===
--- linux-2.6.orig/arch/sparc/kernel/pci_impl.h
+++ linux-2.6/arch/sparc/kernel/pci_impl.h
@@ -97,6 +97,7 @@ struct pci_pbm_info {
/* PBM I/O and Memory space resources. */
struct resource io_space;
struct resource mem_space;
+ struct resource mem64_space;
struct resource busn;
/* Base of PCI Config space, can be per-PBM or shared. */
Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work
On 27 March 2015 at 19:49, Michal Hocko wrote: > Wouldn't something like I was suggesting few months back > (http://article.gmane.org/gmane.linux.kernel.mm/127569) solve this > problem as well? Scheduler should be idle aware, no? I mean it shouldn't > wake up an idle CPU if the task might run on another one. Probably yes. Lets see what others have to say about it.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work
On 27 March 2015 at 17:32, Peter Zijlstra wrote: > What's not clear to me is why that thing is allocated at all, AFAICT > something like: > > static DEFINE_PER_CPU(struct tvec_base, tvec_bases); > > Should do the right thing and be much simpler. Does this comment from timers.c answers your query ? /* * This is for the boot CPU - we use compile-time * static initialisation because per-cpu memory isn't * ready yet and because the memory allocators are not * initialised either. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/16 v2] iommu: Move domain allocation into drivers
On Thu, 2015-03-26 at 13:43 +0100, Joerg Roedel wrote: > Changes v1-v2: > > * Rebased to v4.0-rc5 > * Converted domain-types to a bit-field > > Hi, > > here is patch-set to replace the existing domain_init and > domain_destroy iommu-ops with the new domain_alloc and > domain_free callbacks > > The new callbacks move the allocation of iommu domains into > the iommu driver, allowing them to put a generic > iommu_domain struct into their own domain struct. This makes > domain handling in the drivers more cache efficient and > prepares the introduction of default domains in another > patch-set. > > While at it, this patch-set also introduces domain types. > These are internal to the iommu core code for now, there are > three of them: > > * DMA-API domains > * Identity mapped domains > * Domains unmanaged by the iommu-core, used for > iommu-api so that the users can create their own > mappings > > The patches have been compile tested for x86, ARM and PPC > and runtime tested on x86 (Intel VT-d and AMD IOMMU). > > Please review. For 1-5,16 Reviewed-by: Alex Williamson My only comment/question is whether you'd want to consider using ERR_PTR() return values from domain_alloc(). It's an alloc functions, so NULL == -ENOMEM is pretty standard, but we could at least have the interface to the iommu driver return more info even if we continue to mask that as NULL out to the IOMMU API users for now. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work
On Fri, Mar 27, 2015 at 3:00 PM, Peter Zijlstra wrote: > On Fri, Mar 27, 2015 at 10:16:13AM +0100, Peter Zijlstra wrote: >> So the issue seems to be that we need base->running_timer in order to >> tell if a callback is running, right? >> >> We could align the base on 8 bytes to gain an extra bit in the pointer >> and use that bit to indicate the running state. Then these sites can >> spin on that bit while we can change the actual base pointer. > > Even though tvec_base has cacheline_aligned stuck on, most are > allocated using kzalloc_node() which does not actually respect that but > already guarantees a minimum u64 alignment, so I think we can use that > third bit without too much magic. Right. So what I tried earlier was very much similar to you are suggesting. The only difference was that I haven't made much attempts towards saving memory. But Thomas didn't like it for sure and I believe that Rant will hold true for what you are suggesting as well, isn't it ? http://lists.linaro.org/pipermail/linaro-kernel/2013-November/008866.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 2/2] show nohz_full cpus in sysfs
On Fri, 2015-03-27 at 17:50 -0400, r...@redhat.com wrote: > From: Rik van Riel > > Currently there is no way to query which CPUs are in nohz_full > mode from userspace. Hm, they're both (as of your last set) invariant. Is this so an HPC app can automatically bind itself or something? You can't have more than one such app, or rather if you did, they'd need more than which CPUs are HPC capable, they'd need occupancy too, so the query mechanism seems kinda useless. Box driver has to allocate CPUs, and presumably knows the configuration of the box (those who don't become ex box drivers). -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 3/5] dmaengine: bcm2835-dma: Fix memory leak when stopping a running transfer
On 03/27/2015 05:35 AM, Peter Ujfalusi wrote: > The vd->node is removed from the lists when the transfer started so the > vchan_get_all_descriptors() will not find it. This results memory leak. Acked-by: Stephen Warren (I'm just assuming the explanation makes sense and is correct; more of a not-a-NAK so it doesn't look like a lack of response!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On 3/27/15 9:19 PM, Yinghai Lu wrote: Good. But we still have annoying warning about "no compatible window". Please try attached patch that support 64bit pci mem space for sparc. BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your .config. otherwise we should more verbose print out. Or did you have DYNAMIC_DEBUG enabled ? If it is that case, can you remove that? done. attached. sshlab root@ca-qasparc24 dmesg [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.36.2 2014/10/24 08:15' [0.00] PROMLIB: Root node compatible: sun4v [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.0-rc5+ (root@ca-qasparc24) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4.0.9) (GCC) ) #1 SMP Fri Mar 27 23:32:21 EDT 2015 [0.00] debug: skip boot console de-registration. [0.00] debug: ignoring loglevel setting. [0.00] bootconsole [earlyprom0] enabled [0.00] ARCH: SUN4V [0.00] Ethernet address: 00:10:e0:35:15:f6 [0.00] MM: PAGE_OFFSET is 0xfff8 (max_phys_bits == 47) [0.00] MM: VMALLOC [0x0001 --> 0x0006] [0.00] MM: VMEMMAP [0x0006 --> 0x000c] [0.00] Kernel: Using 3 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] OF stdout device is: /virtual-devices@100/console@1 [0.00] PROM: Built device tree with 1478492 bytes of memory. [0.00] MDESC: Size is 774368 bytes. [0.00] PLATFORM: banner-name [SPARC T5-8] [0.00] PLATFORM: name [ORCL,SPARC-T5-8] [0.00] PLATFORM: hostid [863515f6] [0.00] PLATFORM: serial# [003515f6] [0.00] PLATFORM: stick-frequency [3b9aca00] [0.00] PLATFORM: mac-address [10e03515f6] [0.00] PLATFORM: watchdog-resolution [1000 ms] [0.00] PLATFORM: watchdog-max-timeout [3153600 ms] [0.00] PLATFORM: max-cpus [1024] [0.00] Allocated 81920 bytes for kernel page tables. [0.00] Zone ranges: [0.00] DMA [mem 0x3040-0x] [0.00] Normal [mem 0x-0x383fffd11fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x3040-0x003fddee] [0.00] node 0: [mem 0x003fddef6000-0x003fddef7fff] [0.00] node 1: [mem 0x0800-0x083f] [0.00] node 2: [mem 0x1000-0x103f] [0.00] node 3: [mem 0x1800-0x183f] [0.00] node 4: [mem 0x2000-0x203f] [0.00] node 5: [mem 0x2800-0x283f] [0.00] node 6: [mem 0x3000-0x303f] [0.00] node 7: [mem 0x3800-0x383fffcddfff] [0.00] node 7: [mem 0x383fffcee000-0x383fffd11fff] [0.00] Initmem setup node 0 [mem 0x3040-0x003fddef7fff] [0.00] On node 0 totalpages: 33385849 [0.00] Normal zone: 293431 pages used for memmap [0.00] Normal zone: 33385849 pages, LIFO batch:15 [0.00] Initmem setup node 1 [mem 0x0800-0x083f] [0.00] On node 1 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 2 [mem 0x1000-0x103f] [0.00] On node 2 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 3 [mem 0x1800-0x183f] [0.00] On node 3 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 4 [mem 0x2000-0x203f] [0.00] On node 4 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 5 [mem 0x2800-0x283f] [0.00] On node 5 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 6 [mem 0x3000-0x303f] [0.00] On node 6 totalpages: 33554432 [0.00] Normal zone: 294912 pages used for memmap [0.00] Normal zone: 33554432 pages, LIFO batch:15 [0.00] Initmem setup node 7 [mem 0x3800-0x383fffd11fff] [0.00] On node 7 totalpages: 33554049 [0.00] Normal zone: 294909 pages used for memmap [0.00]
Re: [PATCH] Input: ALPS - Detect trackstick presence for v7 protocol
On Sat, Mar 28, 2015 at 01:30:58AM +, Santiago Gala wrote: > The behaviour is the same with 3.19.1 as with 4.0.0-rc5 + the patched > psmouse you give me. The difference in lsinput is just name and current > position: > > $ diff -u alps06.txt alps11-new.txt > --- alps06.txt 2015-03-18 07:21:08.827315595 +0100 > +++ alps11-new.txt 2015-03-27 21:24:44.285503438 +0100 > @@ -1,5 +1,5 @@ > # EVEMU 1.2 > -# Input device name: "AlpsPS/2 ALPS DualPoint TouchPad" > +# Input device name: "AlpsPS/2 ALPS GlidePoint" > # Input device ID: bus 0x11 vendor 0x02 product 0x08 version 0x700 > # Supported events: > # Event type 0 (EV_SYN) > @@ -15,14 +15,14 @@ > # Event code 335 (BTN_TOOL_QUADTAP) > # Event type 3 (EV_ABS) > # Event code 0 (ABS_X) > -# Value 1076 > +# Value 1549 > # Min0 > # Max 4095 > # Fuzz 0 > # Flat 0 > # Resolution 42 > # Event code 1 (ABS_Y) > -# Value869 > +# Value877 > # Min0 > # Max 2047 > # Fuzz 0 > @@ -59,7 +59,7 @@ > # Properties: > # Property type 0 (INPUT_PROP_POINTER) > # Property type 2 (INPUT_PROP_BUTTONPAD) > -N: AlpsPS/2 ALPS DualPoint TouchPad > +N: AlpsPS/2 ALPS GlidePoint > I: 0011 0002 0008 0700 > P: 05 00 00 00 00 00 00 00 > B: 00 0b 00 00 00 00 00 00 00 Hmm, if resolution is the same I wonder if we are dropping some packets... Is there any messages from psmouse module in dmesg? Thanks. > > > El vie., 27 de marzo de 2015 a las 21:56, Pali Rohár () > escribió: > > > On Friday 27 March 2015 21:32:12 Santiago Gala wrote: > > > I guess the difference is more due to new limits reported. > > > > > > Now I get only one device: > > > > > > /dev/input/event11 > > >bustype : BUS_I8042 > > >vendor : 0x2 > > >product : 0x8 > > >version : 1792 > > >name: "AlpsPS/2 ALPS GlidePoint" > > >phys: "isa0060/serio1/input0" > > >bits ev : EV_SYN EV_KEY EV_ABS > > > > > > > Ok, it means that trackstick detection patch detected that you do > > not have trackstick (and you have only touchpad device). > > > > And also that psmouse.ko is really using ALPS driver. > > > > > And it produces different output in evemu-describe. I attach > > > alps11-new.txt (the new one). See fragment of difference with > > > relevant previous one: > > > > > > @@ -38,17 +38,17 @@ > > > # Event code 53 (ABS_MT_POSITION_X) > > > # Value 0 > > > # Min0 > > > -# Max 448 > > > +# Max 4095 > > > # Fuzz 0 > > > # Flat 0 > > > -# Resolution 4 > > > +# Resolution 42 > > > # Event code 54 (ABS_MT_POSITION_Y) > > > # Value 0 > > > # Min0 > > > -# Max0 > > > +# Max 2047 > > > # Fuzz 0 > > > # Flat 0 > > > -# Resolution 0 > > > +# Resolution 38 > > > # Event code 57 (ABS_MT_TRACKING_ID) > > > # Value 0 > > > # Min0 > > > > > > So resolutions are reported clearly different than with the > > > broken patch. > > > > > > > Can you look at difference between old 3.19 kernel version and > > this new one? To check if there is no regression. > > > > > Regards > > > Santiago > > > > > > El vie., 27 de marzo de 2015 a las 21:09, Pali Rohár > > > () > > > > > > escribió: > > > > Hello, > > > > > > > > there should no functional changes (e.g. acceleration speed, > > > > etc.). And if yes, there is probably some side effect which > > > > should be investigated. > > > > > > > > Please can you provide output from dmesg (grep for psmouse > > > > or input) and also output from lsinput? > > > > > > > > That changed acceleration/speed sounds like psmouse > > > > fallbacks to some ImPS/2 relative protocol and not ALPS... > > > > > > > > On Friday 27 March 2015 20:46:59 Santiago Gala wrote: > > > > > It works quite well! :) > > > > > > > > > > I got some issues: at first it didn't work after I mv'ed > > > > > the original and put the unzipped new in its place. After > > > > > reboot it failed exactly the same, but after I "sudo > > > > > /etc/init.d/lightdm stop; sudo modprobe -r psmouse; sudo > > > > > modprobe psmouse; sudo /etc/init.d/lightdm start" it > > > > > worked. Then I remembered about the initrd.img which > > > > > should contain it. So I did "sudo dpkg-reconfigure > > > > > linux-image-4.0.0-04rc5-generic", rebooted again and > > > > > here I am. > > > > > > > > > > > > > > > Things seem to work all right. The only thing I notice is > > > > > that the old driver moved fast in console mode (with gpm) > > > > > while the new one is rather slow, would need to tweak the > > > > > acceleration configuration. even after adding > > > > > "responsiveness=15" to the configuration, as the sample > > > > > /etc/gpm.conf says, it is slower than the previous kernel > > > > > with the stock configuration. > > > > > > > > > > > > >
[PATCH] pstore/ram: verify ramoops header before saving record
On some devices the persistent memory contains junk after a cold boot,
and /dev/pstore/dmesg-ramoops-* are created with random data which is
not the result of a kernel crash.
This patch adds a ramoops header check and skips any
persistent_ram_zone that does not have a valid header.
Signed-off-by: Ben Zhang
---
fs/pstore/ram.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 44a549b..e16af43 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -186,12 +186,34 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
pstore_type_id *type,
ssize_t size;
ssize_t ecc_notice_size;
struct ramoops_context *cxt = psi->data;
- struct persistent_ram_zone *prz;
- int header_length;
+ struct persistent_ram_zone *prz = NULL;
+ int header_length = 0;
+
+ /* Ramoops headers provide time stamps for PSTORE_TYPE_DMESG, but
+* PSTORE_TYPE_CONSOLE and PSTORE_TYPE_FTRACE don't currently have
+* valid time stamps, so it is initialized to zero.
+*/
+ time->tv_sec = 0;
+ time->tv_nsec = 0;
+ *compressed = false;
+
+ /* Find the next valid persistent_ram_zone for DMESG */
+ while (cxt->dump_read_cnt < cxt->max_dump_cnt && !prz) {
+ prz = ramoops_get_next_prz(cxt->przs, >dump_read_cnt,
+ cxt->max_dump_cnt, id, type,
+ PSTORE_TYPE_DMESG, 1);
+ if (!prz_ok(prz))
+ continue;
+ header_length = ramoops_read_kmsg_hdr(persistent_ram_old(prz),
+ time, compressed);
+ /* Clear and skip this DMESG record if it has no valid header */
+ if (!header_length) {
+ persistent_ram_free_old(prz);
+ persistent_ram_zap(prz);
+ prz = NULL;
+ }
+ }
- prz = ramoops_get_next_prz(cxt->przs, >dump_read_cnt,
- cxt->max_dump_cnt, id, type,
- PSTORE_TYPE_DMESG, 1);
if (!prz_ok(prz))
prz = ramoops_get_next_prz(>cprz, >console_read_cnt,
1, id, type, PSTORE_TYPE_CONSOLE, 0);
@@ -204,13 +226,7 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
pstore_type_id *type,
if (!prz_ok(prz))
return 0;
- if (!persistent_ram_old(prz))
- return 0;
-
- size = persistent_ram_old_size(prz);
- header_length = ramoops_read_kmsg_hdr(persistent_ram_old(prz), time,
- compressed);
- size -= header_length;
+ size = persistent_ram_old_size(prz) - header_length;
/* ECC correction notice */
ecc_notice_size = persistent_ram_ecc_string(prz, NULL, 0);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 8:22 PM, David Ahern wrote: > On 3/27/15 9:19 PM, Yinghai Lu wrote: >> >> Good. But we still have annoying warning about "no compatible window". >> >> Please try attached patch that support 64bit pci mem space for sparc. > > > in place of or on top of the previous patch? on top of the previous patch. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: arm/ksm: Unable to handle kernel paging request in get_ksm_page() and ksm_scan_thread()
On 2015/3/26 21:23, Xishi Qiu wrote: > Here are two panic logs from smart phone test, and the kernel version is > v3.10. > > log1 is "Unable to handle kernel paging request at virtual address > c0704da020", it should be ffc0704da020, right? > and log2 is "Unable to handle kernel paging request at virtual address > 1e000796", it should be ffc01e000796, right? > > I cann't repeat the panic by test, so could anyone tell me this is the > bug of ksm or other reason? > > Thanks, > Xishi Qiu > Here is another one. [145556.775726s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Unable to handle kernel paging request at virtual address ff18 [145556.775817s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]pgd = ffc07f5e4000 [145556.775817s][2015:03:24 20:07:00][pid:864,cpu0,ksmd][ff18] *pgd=80808003, *pmd= [145556.775878s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Internal error: Oops: 9606 [#1] PREEMPT SMP [145556.775909s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Modules linked in: [145556.776000s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]CPU: 0 PID: 864 Comm: ksmd Tainted: GW3.10.61-g2aca0a6-dirty #2 [145556.776031s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]task: ffc0bc06ee00 ti: ffc0baae4000 task.ti: ffc0baae4000 [145556.776092s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]PC is at ksm_scan_thread+0x4ac/0xce0 [145556.776123s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]LR is at ksm_scan_thread+0x49c/0xce0 [145556.776153s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]pc : [] lr : [] pstate: 8145 [145556.776153s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]sp : ffc0baae7d50 [145556.776184s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x29: ffc0baae7d50 x28: 75a4 [145556.776214s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x27: ffbc02308260 x26: ffc0010ab000 [145556.776245s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x25: ffc0599392a0 x24: ffc0baae4000 [145556.776306s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x23: ffc001a0aa90 x22: ffc0baae7df8 [145556.776336s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x21: ffc084150080 x20: ff00 [145556.776367s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x19: ffc0018ddb88 x18: [145556.776397s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x17: 007f7f28a974 x16: ffc0007ca16c [145556.776428s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x15: 0873 x14: 0001 [145556.776458s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x13: 0001 x12: 0848 [145556.776489s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x11: 0848 x10: 6995fcb1 [145556.776519s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x9 : c72311f7 x8 : 09050501 [145556.776550s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x7 : 05aeda8e x6 : fa9a48df [145556.776611s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x5 : ffc095e7abb0 x4 : 000b [145556.776641s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x3 : 0001 x2 : 0001 [145556.776672s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x1 : 00100051 x0 : ffbc02308260 [145556.776702s][2015:03:24 20:07:00][pid:864,cpu0,ksmd] [145556.776702s]PC: 0xffc00077a364: [145556.776733s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a364 f9400b00 f9400400 f940 3607fdc0 91028260 aa1603e1 97fd11f3 f9400b01 [145556.776794s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a384 b9401420 12017800 b9001420 d5033bbf f940fb5a f9400b00 b9400341 34ffdfc1 [145556.776855s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a3a4 97fda3a6 53001c00 34ffdf60 5280 97fda3c1 17fffef8 f0008120 b945b800 [145556.776947s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a3c4 97fc9985 94249bbc 17fffef3 97fc6abc f9400a75 f940067c f94002b4 b4002a14 [145556.777008s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a3e4 f9400e80 9274cc01 eb01039f 540019a0 eb00039f 54002943 90009480 f9003fa0 [145556.777069s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a404 1407 f9400e80 9274cc01 eb01039f 54001860 eb00039f 540001c3 f9400281 [145556.777130s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a424 aa1403e0 f90002a1 97fffb83 f9000a9f f94002e2 aa1403e1 f9401ee0 d1000442 [145556.777191s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a444 f90002e2 94001772 f94002b4 b5fffdd4 f9403fa0 52901a01 912a4000 f9401c00 [145556.777252s][2015:03:24 20:07:00][pid:864,cpu0,ksmd] [145556.777252s]LR: 0xffc00077a354: [145556.777282s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a354 54000101 97fd0e12 53001c00 35a0 f9400b00 f9400400 f940 3607fdc0 [145556.777343s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a374 91028260 aa1603e1 97fd11f3 f9400b01 b9401420 12017800 b9001420 d5033bbf [145556.777404s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a394 f940fb5a f9400b00 b9400341 34ffdfc1 97fda3a6 53001c00 34ffdf60 5280 [145556.777465s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]a3b4 97fda3c1 17fffef8 f0008120 b945b800 97fc9985 94249bbc 17fffef3
Re: [PATCH] cpufreq: exynos: remove dead ->need_apll_change method
On 27 March 2015 at 22:02, Bartlomiej Zolnierkiewicz
wrote:
> Commit 26ab1c62b6e1 ("cpufreq: exynos5250: Set APLL rate
> using CCF API") removed the last user of ->need_apll_change
> method. Remove it and then cleanup exynos_cpufreq_scale()
> accordingly.
>
> This patch was tested on Exynos4412 SoC based Trats2 board.
>
> There should be no functional changes caused by this patch.
>
> Cc: Sachin Kamat
> Cc: Lukasz Majewski
> Cc: Kukjin Kim
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/cpufreq/exynos-cpufreq.c | 30 +++---
> drivers/cpufreq/exynos-cpufreq.h |1 -
> 2 files changed, 3 insertions(+), 28 deletions(-)
Acked-by: Viresh Kumar
@Kukjin: please take it through your tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On 3/27/15 9:19 PM, Yinghai Lu wrote: Good. But we still have annoying warning about "no compatible window". Please try attached patch that support 64bit pci mem space for sparc. in place of or on top of the previous patch? BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your .config. otherwise we should more verbose print out. # zcat /proc/config.gz | grep PCI_DEBUG CONFIG_PCI_DEBUG=y Or did you have DYNAMIC_DEBUG enabled ? # zcat /proc/config.gz | grep DYNAMIC CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_DYNAMIC_DEBUG=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE=y If it is that case, can you remove that? will do; wasn't aware of it before now. Let me know about the patch ordering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 5:36 PM, David Ahern wrote:
>>>
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with "debug ignore_loglevel", so we check if
pci :00:01.0 really have resource assigned.
>>>
>>>
>>> Please check attached patch and send out boot log with above config.
>>
>>
>> patched applied. PCI_DEBUG enabled. options added. log attached. This is
>> with d63e2e1f3df reverted still.
>>
>
> oops lied about that last one; I forgot to revert the patch this round. That
> the system booted with it applied is progress.
Good. But we still have annoying warning about "no compatible window".
Please try attached patch that support 64bit pci mem space for sparc.
BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your .config.
otherwise we should more verbose print out.
Or did you have DYNAMIC_DEBUG enabled ?
If it is that case, can you remove that?
Thanks
Yinghai
Subject: [RFC PATCH] sparc/PCI: Add mem64 resource parsing for root bus
Found no compatible bridge window warning in boot log from T5-8.
pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no compatible bridge window
and root bus only report io and mem32.
pci_sun4v f02dbcfc: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus address [0x-0x7eff])
pci_bus :00: root bus resource [bus 00-77]
Add mem64 handling in pci_common for sparc, so we can have 64bit resource
registered for bus at first.
Signed-off-by: Yinghai Lu
---
arch/sparc/kernel/pci.c|3 +++
arch/sparc/kernel/pci_common.c | 15 +--
arch/sparc/kernel/pci_impl.h |1 +
3 files changed, 17 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/sparc/kernel/pci.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci.c
+++ linux-2.6/arch/sparc/kernel/pci.c
@@ -663,6 +663,9 @@ struct pci_bus *pci_scan_one_pbm(struct
pbm->io_space.start);
pci_add_resource_offset(, >mem_space,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ pci_add_resource_offset(, >mem64_space,
+ pbm->mem64_space.start);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
Index: linux-2.6/arch/sparc/kernel/pci_common.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci_common.c
+++ linux-2.6/arch/sparc/kernel/pci_common.c
@@ -406,6 +406,7 @@ void pci_determine_mem_io_space(struct p
}
num_pbm_ranges = i / sizeof(*pbm_ranges);
+ memset(>mem64_space, 0, sizeof(struct resource));
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = _ranges[i];
@@ -451,7 +452,11 @@ void pci_determine_mem_io_space(struct p
break;
case 3:
- /* XXX 64-bit MEM handling XXX */
+ /* 64-bit MEM handling */
+ pbm->mem64_space.start = a;
+ pbm->mem64_space.end = a + size - 1UL;
+ pbm->mem64_space.flags = IORESOURCE_MEM;
+ break;
default:
break;
@@ -465,15 +470,21 @@ void pci_determine_mem_io_space(struct p
prom_halt();
}
- printk("%s: PCI IO[%llx] MEM[%llx]\n",
+ printk("%s: PCI IO[%llx] MEM[%llx]",
pbm->name,
pbm->io_space.start,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ printk(" MEM64[%llx]",
+ pbm->mem64_space.start);
+ printk("\n");
pbm->io_space.name = pbm->mem_space.name = pbm->name;
request_resource(_resource, >io_space);
request_resource(_resource, >mem_space);
+ if (pbm->mem64_space.flags)
+ request_resource(_resource, >mem64_space);
pci_register_legacy_regions(>io_space,
>mem_space);
Index: linux-2.6/arch/sparc/kernel/pci_impl.h
===
--- linux-2.6.orig/arch/sparc/kernel/pci_impl.h
+++ linux-2.6/arch/sparc/kernel/pci_impl.h
@@ -97,6 +97,7 @@ struct pci_pbm_info {
/* PBM I/O and Memory space resources. */
struct resource io_space;
struct resource mem_space;
+ struct resource mem64_space;
struct resource busn;
/* Base of PCI Config space, can be per-PBM or shared. */
Re: [PATCH 3/3] Documentation/ABI: Update sysfs-driver-toshiba_acpi entry
On Fri, Mar 27, 2015 at 03:10:29PM -0600, Azael Avalos wrote: > This patch updates the sysfs-driver-toshiba_acpi entry, adding the > missing entries for USB Sleep functions. > > And also, while at the neighborhood, fix some typos and add a note > that some features require a reboot. > > Signed-off-by: Azael Avalos Looks good. But I'll pull it in with the reset of the series in v2. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] toshiba_acpi: Fix typos in pr_* messages from USB Fleep Functions
On Fri, Mar 27, 2015 at 03:09:25PM -0600, Azael Avalos wrote:
> This patch fixes typos in the pr_* messages from the USB Sleep
> Functions.
>
> Signed-off-by: Azael Avalos
> ---
> drivers/platform/x86/toshiba_acpi.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/platform/x86/toshiba_acpi.c
> b/drivers/platform/x86/toshiba_acpi.c
> index 595f12c..3bb456c 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -955,11 +955,11 @@ static int toshiba_usb_rapid_charge_get(struct
> toshiba_acpi_dev *dev,
> status = tci_raw(dev, in, out);
> sci_close(dev);
> if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
> - pr_err("ACPI call to get USB S battery level failed\n");
> + pr_err("ACPI call to get USB Rapid Charge failed\n");
> return -EIO;
> } else if (out[0] == TOS_NOT_SUPPORTED ||
> out[0] == TOS_INPUT_DATA_ERROR) {
> - pr_info("USB Sleep and Charge not supported\n");
> + pr_info("USB Rapid Charge not supported\n");
This is a name change, not a typo fix. You added a comment in 1/3 using Sleep
and Charge, should this patch perhaps come first?
Or... hrm... this is using the correct name for each state, and 1/3 added Sleep
and Charge to the correct one... right, probably just need a better commit
message. Not a type, but fixing the messages reporting the wrong states.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] toshiba_acpi: Update and fix USB Sleep and Charge modes
On Fri, Mar 27, 2015 at 03:09:24PM -0600, Azael Avalos wrote:
> This patch fixes the USB Sleep and Charge mode on certain models
> where the value returned by the BIOS is different, and thus, making
> this feature not to work for those models.
>
> Also, the "Typical" charging mode was added as a supported mode.
What does typical mean?
>
> Signed-off-by: Azael Avalos
> ---
> drivers/platform/x86/toshiba_acpi.c | 61
> +++--
> 1 file changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/platform/x86/toshiba_acpi.c
> b/drivers/platform/x86/toshiba_acpi.c
> index 17a259e..595f12c 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -150,9 +150,10 @@ MODULE_LICENSE("GPL");
> #define SCI_KBD_MODE_OFF 0x10
> #define SCI_KBD_TIME_MAX 0x3c001a
> #define SCI_USB_CHARGE_MODE_MASK 0xff
> -#define SCI_USB_CHARGE_DISABLED 0x3
> -#define SCI_USB_CHARGE_ALTERNATE 0x30009
> -#define SCI_USB_CHARGE_AUTO 0x30021
> +#define SCI_USB_CHARGE_DISABLED 0x00
> +#define SCI_USB_CHARGE_ALTERNATE 0x09
> +#define SCI_USB_CHARGE_TYPICAL 0x11
> +#define SCI_USB_CHARGE_AUTO 0x21
> #define SCI_USB_CHARGE_BAT_MASK 0x7
> #define SCI_USB_CHARGE_BAT_LVL_OFF 0x1
> #define SCI_USB_CHARGE_BAT_LVL_ON0x4
> @@ -177,6 +178,7 @@ struct toshiba_acpi_dev {
> int kbd_mode;
> int kbd_time;
> int usbsc_bat_level;
> + int usbsc_mode_base;
> int hotkey_event_type;
>
> unsigned int illumination_supported:1;
> @@ -800,6 +802,44 @@ static int toshiba_accelerometer_get(struct
> toshiba_acpi_dev *dev,
> }
>
> /* Sleep (Charge and Music) utilities support */
> +static void toshiba_usb_sleep_charge_available(struct toshiba_acpi_dev *dev)
> +{
> + u32 in[TCI_WORDS] = { SCI_GET, SCI_USB_SLEEP_CHARGE, 0, 0, 0, 0 };
> + u32 out[TCI_WORDS];
> + acpi_status status;
> +
> + if (!sci_open(dev))
> + return;
> +
Hrm, might be a good idea to set usb_sleep_charge_supported to 0 first so if we
error out here, it is disabled.
> + status = tci_raw(dev, in, out);
> + if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
> + pr_err("ACPI call to get USB S mode failed\n");
> + sci_close(dev);
> + return;
> + } else if (out[0] == TOS_NOT_SUPPORTED) {
> + pr_info("USB Sleep and Charge not supported\n");
> + sci_close(dev);
> + return;
> + }
> + dev->usbsc_mode_base = out[4];
> +
> + in[5] = SCI_USB_CHARGE_BAT_LVL;
> + status = tci_raw(dev, in, out);
> + if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
> + pr_err("ACPI call to get USB S battery level failed\n");
Sleep and Charge here too please. This keeps it consistent with the other
messages as well as explicit for those who may not map S to Sleep and Charge.
> + sci_close(dev);
> + return;
> + } else if (out[0] == TOS_NOT_SUPPORTED) {
> + pr_info("USB Sleep and Charge not supported\n");
> + sci_close(dev);
> + return;
> + }
> + dev->usbsc_bat_level = out[2];
> + dev->usb_sleep_charge_supported = 1;
> +
> + sci_close(dev);
> +}
> +
> static int toshiba_usb_sleep_charge_get(struct toshiba_acpi_dev *dev,
> u32 *mode)
> {
> @@ -1976,17 +2016,21 @@ static ssize_t usb_sleep_charge_store(struct device
> *dev,
>* 0 - Disabled
>* 1 - Alternate (Non USB conformant devices that require more power)
>* 2 - Auto (USB conformant devices)
> + * 3 - Typical
>*/
> - if (state != 0 && state != 1 && state != 2)
> + if (state != 0 && state != 1 && state != 2 && state != 3)
> return -EINVAL;
>
> /* Set the USB charging mode to internal value */
> + mode = toshiba->usbsc_mode_base;
> if (state == 0)
> - mode = SCI_USB_CHARGE_DISABLED;
> + mode |= SCI_USB_CHARGE_DISABLED;
> else if (state == 1)
> - mode = SCI_USB_CHARGE_ALTERNATE;
> + mode |= SCI_USB_CHARGE_ALTERNATE;
> else if (state == 2)
> - mode = SCI_USB_CHARGE_AUTO;
> + mode |= SCI_USB_CHARGE_AUTO;
> + else if (state == 3)
> + mode |= SCI_USB_CHARGE_TYPICAL;
>
> ret = toshiba_usb_sleep_charge_set(toshiba, mode);
> if (ret)
> @@ -2756,8 +2800,7 @@ static int toshiba_acpi_add(struct acpi_device
> *acpi_dev)
> ret = toshiba_accelerometer_supported(dev);
> dev->accelerometer_supported = !ret;
>
> - ret = toshiba_usb_sleep_charge_get(dev, );
> - dev->usb_sleep_charge_supported = !ret;
> + toshiba_usb_sleep_charge_available(dev);
>
> ret = toshiba_usb_rapid_charge_get(dev, );
> dev->usb_rapid_charge_supported = !ret;
The rest looks good.
--
Darren
Re: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board
On Thursday 26 March 2015, Robert Jarzmik wrote: > > Greg Kroah-Hartman writes: > > > On Fri, Feb 20, 2015 at 05:02:57PM +0100, Robert Jarzmik wrote: > >> If there is no solution, I'll fallback through arch/arm/plat-pxa, not very > >> nice, > >> but it has to land somewhere, I don't want lubbock to remain broken. > > > > drivers/platform/arm ? > Most certainly. > > I'll submit that to drivers/platform/arm/pxa, and maintain that pxa tree. As > for > drivers/platform/arm, do you want also maintainers to step up, or will you > take > the review/merge burden ? > I'd much prefer not to add drivers/platform/arm, which would make it too easy to add random stuff there. What is the problem with leaving it in mach-pxa? 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 1/2] spi: fsl-dspi: Fix clock rate scale values
On Fri, Mar 27, 2015 at 02:51:42PM -0700, Aaron Brice wrote: > Update baud rate scaling algorithm to get better scaling values. Can we have a better changelog please? What is better about the new algorithm? signature.asc Description: Digital signature
Re: [PATCH] regulator: Ensure unique regulator debugfs directory names
On Fri, Oct 17, 2014 at 08:17:03AM -0700, Guenter Roeck wrote: > If multiple regulator devices of the same type exist in a system, > the regulator driver assigns generic names for the regulators it > provides, and debugfs is enabled, the regulator subsystem attempts > to create multiple entries with the same name in the regulator debugfs > directory. This fails for all but the first regulator, resulting in > multiple "Failed to create debugfs directory" log entries. Applied, thanks. signature.asc Description: Digital signature
Re: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 6:05 PM, Sam Ravnborg wrote: >> >> Index: linux-2.6/arch/alpha/Kconfig >> === >> --- linux-2.6.orig/arch/alpha/Kconfig >> +++ linux-2.6/arch/alpha/Kconfig >> @@ -66,6 +66,9 @@ config ZONE_DMA >> config ARCH_DMA_ADDR_T_64BIT >> def_bool y >> >> +config ARCH_PCI_BUS_ADDR_T_64BIT >> + def_bool y >> + > For alpha you define a new symbol with a default value. > >> config NEED_DMA_MAP_STATE >> def_bool y >> >> Index: linux-2.6/arch/arm/Kconfig >> === >> --- linux-2.6.orig/arch/arm/Kconfig >> +++ linux-2.6/arch/arm/Kconfig >> @@ -1779,6 +1779,7 @@ config XEN >> depends on !GENERIC_ATOMIC64 >> depends on MMU >> select ARCH_DMA_ADDR_T_64BIT >> + select ARCH_PCI_BUS_ADDR_T_64BIT >> select ARM_PSCI >> select SWIOTLB_XEN >> help > For arm you use select ... > > As the actual definition of the Kconfig symbol is already > present in mm/Kconfig please use select in all cases. > >> Index: linux-2.6/arch/arm/mm/Kconfig >> === >> --- linux-2.6.orig/arch/arm/mm/Kconfig >> +++ linux-2.6/arch/arm/mm/Kconfig >> @@ -630,6 +630,9 @@ config ARCH_PHYS_ADDR_T_64BIT >> config ARCH_DMA_ADDR_T_64BIT >> bool >> >> +config ARCH_PCI_BUS_ADDR_T_64BIT >> + bool >> + > Here it would have been nice with a comment that explains the use of ths > symbol. just duplicate the ARCH_DMA_ADDR_T_64BIT above > >> config ARM_THUMB >> bool "Support Thumb user binaries" if !CPU_THUMBONLY >> depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || >> \ >> Index: linux-2.6/arch/arm64/Kconfig >> === >> --- linux-2.6.orig/arch/arm64/Kconfig >> +++ linux-2.6/arch/arm64/Kconfig >> @@ -125,6 +125,9 @@ config HAVE_GENERIC_RCU_GUP >> config ARCH_DMA_ADDR_T_64BIT >> def_bool y >> >> +config ARCH_PCI_BUS_ADDR_T_64BIT >> + def_bool y >> + > Use select ... I was trying to keep the style to be consistent with old one in each Kconfig. So do we just need to make sure new added lines to use new style? > >> Index: linux-2.6/include/linux/types.h >> === >> --- linux-2.6.orig/include/linux/types.h >> +++ linux-2.6/include/linux/types.h >> @@ -146,6 +146,13 @@ typedef u64 dma_addr_t; >> typedef u32 dma_addr_t; >> #endif /* dma_addr_t */ >> >> +/* A pci_bus_addr_t can hold pci bus address for the platform */ >> +#ifdef CONFIG_ARCH_PCI_BUS_ADDR_T_64BIT >> +typedef u64 pci_bus_addr_t; >> +#else >> +typedef u32 pci_bus_addr_t; >> +#endif /* pci_bus_addr_t */ >> + > Looking att all the Kconfig logic I get the impression that > the type of pci_bus_addr_t equals unsigned long. > If this is correct then you can skip that and things > gets much simpler. For x86 32bit with PAE support, we could use 64bit for bus address. but unsigned long is 32bit. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] selftests/mount: Make git ignore all binaries in mount test suite
This patch includes the mount test binaries into the .gitignore file listing in their respective directories. This will make sure that git ignores all of these test binaries when displaying status. Signed-off-by: Zhang Zhen --- tools/testing/selftests/mount/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/testing/selftests/mount/.gitignore diff --git a/tools/testing/selftests/mount/.gitignore b/tools/testing/selftests/mount/.gitignore new file mode 100644 index 000..856ad41 --- /dev/null +++ b/tools/testing/selftests/mount/.gitignore @@ -0,0 +1 @@ +unprivileged-remount-test -- 1.8.5.5 . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/7] dmaengine: of_dma: Support for DMA routers
On Friday 27 March 2015, Peter Ujfalusi wrote: > +Required property: > +- dma-device: phandle of the DMA controller. The router is modifying > + the DMA requests for this controller. This property seems rather specific to the case at hand, I would expect that one might also see routers like this that are connected to more than one dma-device, so maybe make it a list? It might also be better to name this as 'dma-controllers' or 'dma-masters', as it is not entirely obvious (without referencing the binding document) whether a dma device refers to the slave or the master. 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 1/2] mm, doc: cleanup and clarify munmap behavior for hugetlb memory
On Fri, 27 Mar 2015, Eric B Munson wrote: > > munmap(2) of hugetlb memory requires a length that is hugepage aligned, > > otherwise it may fail. Add this to the documentation. > > > > This also cleans up the documentation and separates it into logical > > units: one part refers to MAP_HUGETLB and another part refers to > > requirements for shared memory segments. > > > > Signed-off-by: David Rientjes > > --- > > If this is the route we are going to take, this behavoir needs to be > called out prominently in the mmap/munmap man page. > Yeah, that was my next step, but before we get mtk involved I was trying to get this merged since man2/mmap.2 already has a .I Documentation/vm/hugetlbpage.txt for MAP_HUGETLB so the man page patch can simply reference this addition to the file as justification. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Move zone lock to a different cache line than order-0 free page lists
On Fri, 27 Mar 2015, Mel Gorman wrote:
> Huang Ying reported the following problem due to commit 3484b2de9499
> ("mm: rearrange zone fields into read-only, page alloc, statistics and
> page reclaim lines") from the Intel performance tests
>
> 24b7e5819ad5cbef 3484b2de9499df23c4604a513b
> --
> %stddev %change %stddev
> \ |\
> 152288 \261 0% -46.2% 81911 \261 0% aim7.jobs-per-min
>237 \261 0% +85.6%440 \261 0% aim7.time.elapsed_time
>237 \261 0% +85.6%440 \261 0%
> aim7.time.elapsed_time.max
> 25026 \261 0% +70.7% 42712 \261 0% aim7.time.system_time
>2186645 \261 5% +32.0%2885949 \261 4%
> aim7.time.voluntary_context_switches
>4576561 \261 1% +24.9%5715773 \261 0%
> aim7.time.involuntary_context_switches
>
> The problem is specific to very large machines under stress. It was not
> reproducible with the machines I had used to justify the original patch
> because large numbers of CPUs are required. When pressure is high enough,
> the cache line is bouncing between CPUs trying to acquire the lock and
> the holder of the lock adjusting free lists. The intention was that the
> acquirer of the lock would automatically have the cache line holding the
> free lists but according to Huang, this is not a universal win.
>
> One possibility is to move the zone lock to its own cache line but it
> increases the size of the zone. This patch moves the lock to the other
> end of the free lists where they do not contend under high pressure. It
> does mean the page allocator paths now require more cache lines but Huang
> reports that it restores performance to previous levels on large machines
>
> %stddev %change %stddev
> \ |\
> 84568 \261 1% +94.3% 164280 \261 1% aim7.jobs-per-min
>2881944 \261 2% -35.1%1870386 \261 8%
> aim7.time.voluntary_context_switches
>681 \261 1% -3.4%658 \261 0% aim7.time.user_time
>5538139 \261 0% -12.1%4867884 \261 0%
> aim7.time.involuntary_context_switches
> 44174 \261 1% -46.0% 23848 \261 1% aim7.time.system_time
>426 \261 1% -48.4%219 \261 1% aim7.time.elapsed_time
>426 \261 1% -48.4%219 \261 1%
> aim7.time.elapsed_time.max
>468 \261 1% -43.1%266 \261 2% uptime.boot
>
> Reported-and-tested-by: Huang Ying
> Signed-off-by: Mel Gorman
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Bugfix v2] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716
On Wednesday, March 25, 2015 03:17:23 PM Jiang Liu wrote:
> Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
> interfaces to simplify implementation"), arch/x86/pci/acpi.c applies
> following rules when parsing ACPI resources for PCI host bridge:
> 1) Ignore IO port resources defined by acpi_resource_io and
>acpi_resource_fixed_io, which should be used to define resource
>for PCI device instead of PCI bridge.
> 2) Accept IOMEM resource defined by acpi_resource_memory24,
>acpi_resource_memory32 and acpi_resource_fixed_memory32.
>These IOMEM resources are accepted to workaround some BIOS issue,
>though they should be ignored. For example, PC Engines APU.1C
>platform defines PCI host bridge IOMEM resources as:
> Memory32Fixed (ReadOnly,
> 0x000A, // Address Base
> 0x0002, // Address Length
> )
> Memory32Fixed (ReadOnly,
> 0x, // Address Base
> 0x, // Address Length
> _Y00)
> 3) Accept all IO port and IOMEM resources defined by
>acpi_resource_address{16,32,64,extended64}, no matter it's marked as
>ACPI_CONSUMER or ACPI_PRODUCER.
>
> Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces
> to simplify implementation") accept all IO port and IOMEM resources
> defined by acpi_resource_io, acpi_resource_fixed_io,
> acpi_resource_memory24, acpi_resource_memory32,
> acpi_resource_fixed_memory32 and
> acpi_resource_address{16,32,64,extended64}, which causes IO port
> resources consumed by host bridge itself are listed in host bridge
> resource list.
>
> Then commit 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
> host bridge itself") ignores resources consumed by host bridge itself
> by checking IORESOURCE_WINDOW flag, which accidently removed the
> workaround for BIOS bug in 2) listed above.
>
> It's really costed us much time to figure out this whole picture.
> So we will refine interface acpi_dev_filter_resource_type as below,
> which should be much easier for maintence:
> 1) Caller specifies IORESOURCE_WINDOW flag to explicitly query resource
>for bridge(PRODUCER), otherwise it's querying resource for
>device(CONSUMER).
> 2) Ignore IO port resources defined by acpi_resource_io and
>acpi_resource_fixed_io if IORESOURCE_WINDOW is specified.
> 3) Accpet IOMEM resource defined by acpi_resource_memory24,
>acpi_resource_memory32 and acpi_resource_fixed_memory32 to work
>around BIOS bugs, with comment to state it's workaround for BIOS bug.
> 4) Accept IO port and IOMEM defined by acpi_resource_addressxx if
>a) IORESOURCE_WINDOW is specified and ACPI_PRODUCER is true
>b) IORESOURCE_WINDOW is not specified and ACPI_PRODUCER is false
>
> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
>
> Sample ACPI table needing the workaround are archived at:
> https://bugzilla.kernel.org/show_bug.cgi?id=94221
>
> Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
> Reported-by: Bernhard Thaler
> Signed-off-by: Jiang Liu
> ---
> Hi Bjorn and Rafael,
> Great thanks to you two:) Now I think I have fully understand
> the whole picture and the final code should be much easier for
> understanding and maintenance.
It all makes sense to me, but one minor nit below. ->
> ---
> arch/x86/pci/acpi.c |5 ++---
> drivers/acpi/resource.c | 38 ++
> 2 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index e4695985f9de..8c4b1201f340 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -337,7 +337,7 @@ static void probe_pci_root_info(struct pci_root_info
> *info,
> info->bridge = device;
> ret = acpi_dev_get_resources(device, list,
>acpi_dev_filter_resource_type_cb,
> - (void *)(IORESOURCE_IO | IORESOURCE_MEM));
> + (void *)(IORESOURCE_IO | IORESOURCE_MEM |
> IORESOURCE_WINDOW));
> if (ret < 0)
> dev_warn(>dev,
>"failed to parse _CRS method, error code %d\n", ret);
> @@ -346,8 +346,7 @@ static void probe_pci_root_info(struct pci_root_info
> *info,
> "no IO and memory resources present in _CRS\n");
> else
> resource_list_for_each_entry_safe(entry, tmp, list) {
> - if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
> - (entry->res->flags & IORESOURCE_DISABLED))
> + if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> else
>
Re: [PATCH v3] led/led-class: Handle LEDs with the same name
+ Kees Cook On Fri, Mar 27, 2015 at 10:24:53AM -0700, Bryan Wu wrote: > On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado > wrote: > > Hi Sakari > > > > cc: adding Greg (core and FormatGuard) and Chistopher (sparse) > >> > >> I just realised there was another issue --- the name is now interpreted as > >> format string. Bad things will happen if there's e.g. %s in the name itself > >> --- perhaps unlikely, but possible. > > > > Good catch! > > > > Would it be possible to add a sparse check to avoid this in all the kernel? > > > > And what about a macro protection like FormatGuard? > > > > https://www.usenix.org/legacy/events/sec01/full_papers/cowanbarringer/cowanbarringer.pdf > > > > > > I think Fengguang's 0-DAY kernel test infrastructure can help this. Kees' format-security branch has a check on dynamic printf format string, which has been effective in finding errors like: drivers/tty/serial/sb1250-duart.c: In function 'sbd_map_port': >> drivers/tty/serial/sb1250-duart.c:680:3: error: format not a string literal >> and no format arguments [-Werror=format-security] printk(err); ^ I wonder if Kees has the plan to include the patch into upstream and make it a kconfig option. For your convenience, the patch is pasted below. Thanks, Fengguang --- commit 95420c349194d1b570270ba1b1567d85461761c3 Author: Kees Cook AuthorDate: Mon Sep 16 11:15:54 2013 -0700 Commit: Kees Cook CommitDate: Wed Mar 4 14:07:18 2015 -0800 Make all format string problems fail the build In an effort to stop format strings from leaking into various callers, have gcc stop the build when this gets detected. Signed-off-by: Kees Cook diff --git a/Makefile b/Makefile index e6a9b1b..b7684d2 100644 --- a/Makefile +++ b/Makefile @@ -402,7 +402,6 @@ KBUILD_CPPFLAGS := -D__KERNEL__ KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ - -Wno-format-security \ -std=gnu89 KBUILD_AFLAGS_KERNEL := @@ -752,6 +751,11 @@ endif NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) CHECKFLAGS += $(NOSTDINC_FLAGS) +# Enable format-security when it can stop the build, otherwise disable. +KBUILD_CFLAGS += $(call cc-option,\ + -Wformat -Wformat-security -Werror=format-security,\ + -Wno-format-security) + # warn about C99 declaration after statement KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
> > Index: linux-2.6/arch/alpha/Kconfig > === > --- linux-2.6.orig/arch/alpha/Kconfig > +++ linux-2.6/arch/alpha/Kconfig > @@ -66,6 +66,9 @@ config ZONE_DMA > config ARCH_DMA_ADDR_T_64BIT > def_bool y > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y > + For alpha you define a new symbol with a default value. > config NEED_DMA_MAP_STATE > def_bool y > > Index: linux-2.6/arch/arm/Kconfig > === > --- linux-2.6.orig/arch/arm/Kconfig > +++ linux-2.6/arch/arm/Kconfig > @@ -1779,6 +1779,7 @@ config XEN > depends on !GENERIC_ATOMIC64 > depends on MMU > select ARCH_DMA_ADDR_T_64BIT > + select ARCH_PCI_BUS_ADDR_T_64BIT > select ARM_PSCI > select SWIOTLB_XEN > help For arm you use select ... As the actual definition of the Kconfig symbol is already present in mm/Kconfig please use select in all cases. > Index: linux-2.6/arch/arm/mm/Kconfig > === > --- linux-2.6.orig/arch/arm/mm/Kconfig > +++ linux-2.6/arch/arm/mm/Kconfig > @@ -630,6 +630,9 @@ config ARCH_PHYS_ADDR_T_64BIT > config ARCH_DMA_ADDR_T_64BIT > bool > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + bool > + Here it would have been nice with a comment that explains the use of ths symbol. > config ARM_THUMB > bool "Support Thumb user binaries" if !CPU_THUMBONLY > depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || \ > Index: linux-2.6/arch/arm64/Kconfig > === > --- linux-2.6.orig/arch/arm64/Kconfig > +++ linux-2.6/arch/arm64/Kconfig > @@ -125,6 +125,9 @@ config HAVE_GENERIC_RCU_GUP > config ARCH_DMA_ADDR_T_64BIT > def_bool y > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y > + Use select > config NEED_DMA_MAP_STATE > def_bool y > > Index: linux-2.6/arch/ia64/Kconfig > === > --- linux-2.6.orig/arch/ia64/Kconfig > +++ linux-2.6/arch/ia64/Kconfig > @@ -74,6 +74,9 @@ config MMU > config ARCH_DMA_ADDR_T_64BIT > def_bool y > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y > + Use select > config NEED_DMA_MAP_STATE > def_bool y > > Index: linux-2.6/arch/mips/Kconfig > === > --- linux-2.6.orig/arch/mips/Kconfig > +++ linux-2.6/arch/mips/Kconfig > @@ -984,6 +984,9 @@ config FW_CFE > config ARCH_DMA_ADDR_T_64BIT > def_bool (HIGHMEM && ARCH_PHYS_ADDR_T_64BIT) || 64BIT > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool (HIGHMEM && ARCH_PHYS_ADDR_T_64BIT) || 64BIT Use select ... if > === > --- linux-2.6.orig/arch/powerpc/Kconfig > +++ linux-2.6/arch/powerpc/Kconfig > @@ -23,6 +23,9 @@ config ARCH_PHYS_ADDR_T_64BIT > config ARCH_DMA_ADDR_T_64BIT > def_bool ARCH_PHYS_ADDR_T_64BIT > > +config ARCH_PCI_ADDR_T_64BIT > + def_bool ARCH_PHYS_ADDR_T_64BIT > + Use select > Index: linux-2.6/arch/sparc/Kconfig > === > --- linux-2.6.orig/arch/sparc/Kconfig > +++ linux-2.6/arch/sparc/Kconfig > @@ -143,6 +143,9 @@ config GENERIC_ISA_DMA > bool > default y if SPARC32 > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y if SPARC64 > + Use select ... > config ARCH_SUPPORTS_DEBUG_PAGEALLOC > def_bool y if SPARC64 > > Index: linux-2.6/arch/tile/Kconfig > === > --- linux-2.6.orig/arch/tile/Kconfig > +++ linux-2.6/arch/tile/Kconfig > @@ -86,6 +86,9 @@ config ARCH_PHYS_ADDR_T_64BIT > config ARCH_DMA_ADDR_T_64BIT > def_bool y > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y > + Use select ... > Index: linux-2.6/arch/x86/Kconfig > === > --- linux-2.6.orig/arch/x86/Kconfig > +++ linux-2.6/arch/x86/Kconfig > @@ -1295,6 +1295,10 @@ config ARCH_DMA_ADDR_T_64BIT > def_bool y > depends on X86_64 || HIGHMEM64G > > +config ARCH_PCI_BUS_ADDR_T_64BIT > + def_bool y > + depends on X86_64 || HIGHMEM64G Use select ... > + > config X86_DIRECT_GBPAGES > def_bool y > depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK > Index: linux-2.6/include/linux/types.h > === > --- linux-2.6.orig/include/linux/types.h > +++ linux-2.6/include/linux/types.h > @@ -146,6 +146,13 @@ typedef u64 dma_addr_t; > typedef u32 dma_addr_t; > #endif /* dma_addr_t */ > > +/* A pci_bus_addr_t can hold pci bus address for the platform */ > +#ifdef CONFIG_ARCH_PCI_BUS_ADDR_T_64BIT > +typedef u64 pci_bus_addr_t; > +#else > +typedef u32 pci_bus_addr_t; > +#endif /*
Re: [PATCH v1 1/2] thermal: hisilicon: add new hisilicon thermal sensor driver
在 2015/3/27 16:30, Xinwei Kong 写道:
On 2015/3/26 17:14, YiPing Xu wrote:
在 2015/3/25 15:50, Xinwei Kong 写道:
From: kongxinwei
This patch adds the support for hisilicon thermal sensor, within
hisilicon SoC. there will register sensors for thermal framework
and use device tree to bind cooling device.
Signed-off-by: Leo Yan
Signed-off-by: kongxinwei
---
drivers/thermal/Kconfig| 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/hisi_thermal.c | 526
+
3 files changed, 535 insertions(+)
create mode 100644 drivers/thermal/hisi_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index af40db0..81aee01 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,6 +136,14 @@ config THERMAL_EMULATION
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
+config HISI_THERMAL
+tristate "Hisilicon thermal driver"
+depends on ARCH_HISI && CPU_THERMAL && OF
+help
+ Enable this to plug hisilicon's thermal sensor driver into the Linux
+ thermal framework. cpufreq is used as the cooling device to throttle
+ CPUs when the passive trip is crossed.
+
config IMX_THERMAL
tristate "Temperature sensor driver for Freescale i.MX SoCs"
depends on CPU_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index fa0dc48..08ae7ac 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal/
obj-$(CONFIG_INT340X_THERMAL) += int340x_thermal/
obj-$(CONFIG_ST_THERMAL)+= st/
obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra_soctherm.o
+obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
new file mode 100644
index 000..8edf83a
--- /dev/null
+++ b/drivers/thermal/hisi_thermal.c
are you sure all the SOCs in hisilicon use the same thermal IP ?
if not, this driver should not use the "hisi_" prefix.
We can use this hisi thermal driver framework to satisfy diff thermal
IP, all of SoC will use this drvier by adding a struct about diff IP.
We may talk about hisi thermal diff IP how to satisfy this driver.
Thanks
Xinwei
@@ -0,0 +1,526 @@
+/*
+ * Hisilicon thermal sensor driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Copyright (c) 2014-2015 Linaro Limited.
+ *
+ * Xinwei Kong
+ * Leo Yan
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define TEMP0_LAG(0x0)
+#define TEMP0_TH(0x4)
+#define TEMP0_RST_TH(0x8)
+#define TEMP0_CFG(0xC)
+#define TEMP0_EN(0x10)
+#define TEMP0_INT_EN(0x14)
+#define TEMP0_INT_CLR(0x18)
+#define TEMP0_RST_MSK(0x1C)
+#define TEMP0_RAW_INT(0x20)
+#define TEMP0_MSK_INT(0x24)
+#define TEMP0_VALUE(0x28)
+
+#define HISI_TEMP_BASE(-60)
+#define HISI_TEMP_RESET(10)
+#define HISI_TEMP_PASSIVE(85000)
+
+#define HISI_MAX_SENSORS4
+
+struct hisi_thermal_sensor {
+struct hisi_thermal_data *thermal;
+struct thermal_zone_device *tzd;
+const struct thermal_trip *trip;
+
+uint32_t id;
+uint32_t thres_temp, reset_temp;
+};
+
+struct hisi_thermal_data {
+struct platform_device *pdev;
+struct clk *clk;
+
+int irq, irq_bind_sensor;
+bool irq_enabled;
+
+unsigned int sensors_num;
+long sensor_temp[HISI_MAX_SENSORS];
+struct hisi_thermal_sensor sensors[HISI_MAX_SENSORS];
+
+void __iomem *regs;
+};
+
+static DEFINE_SPINLOCK(thermal_lock);
+
"thermal_lock" should be defined in "hisi_thermal_data" to support multi
device instance.
ok,good comments
+/* in millicelsius */
+static inline int _step_to_temp(int step)
+{
+/*
+ * Every step equals (1 * 200) / 255 celsius, and finally
+ * need convert to millicelsius.
+ */
+return (HISI_TEMP_BASE + (step * 200 / 255)) * 1000;
+}
+
+static inline int _temp_to_step(int temp)
+{
+return ((temp / 1000 - HISI_TEMP_BASE) * 255 / 200);
+}
+
+static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
+ struct hisi_thermal_sensor *sensor)
+{
+unsigned
Re: [PATCH 2/2] xen/grant: introduce func gnttab_unmap_refs_async_wait_completion()
On Thu, Mar 26, 2015 at 04:32:45PM +0100, Roger Pau Monné wrote: > El 26/03/15 a les 13.16, Bob Liu ha escrit: > > There are several place using gnttab async unmap and wait for > > completion, so move the common code to a function > > gnttab_unmap_refs_async_wait_completion(). > > > > Signed-off-by: Bob Liu > > For the blkback parts: > > Acked-by: Roger Pau Monné > > Although, as David already said, I think we should do better than BUG_ON > on error. Have an 'stuck deferred pages' list and an timer to occasionally flush them out? Something similar to 569ca5b3f94cd0b3295ec5943aa457cf4a4f6a3a "xen/gnttab: add deferred freeing logic" ? > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Input: Add binding document for a generic ADC keypad
Add a binding document for a generic ADC keypad. Buttons on an ADC
keypad are connected in a resistor ladder to an ADC. The binding
describes the mapping of ADC channel and voltage ranges to buttons.
Signed-off-by: Andrew Bresticker
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../devicetree/bindings/input/adc-keys.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt
b/Documentation/devicetree/bindings/input/adc-keys.txt
new file mode 100644
index 000..c9a57de
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adc-keys.txt
@@ -0,0 +1,43 @@
+Generic ADC keypad
+==
+
+Required properties:
+ - compatible: "adc-keys"
+ - poll-interval: Polling interval time in ms.
+ - io-channels: List of IIO channels used by the keypad.
+ See ../iio/iio-bindings.txt for details.
+
+Optional properties:
+ - autorepeat: Enable auto-repeat.
+
+Each button on the ADC keypad is represented by a sub-node.
+
+Required sub-node properties:
+ - label: Descriptive name for the key.
+ - linux,code: Keycode to emit.
+ - channel: IIO channel (index into the 'io-channels' above) to which this
+ button is attached.
+ - min-voltage: Minimum voltage in uV when this key is pressed.
+ - max-voltage: Maximum voltage in uV when this key is pressed.
+
+Optional sub-node properties:
+ - linux,input-type: Event type this key generates. Defaults to 1 (EV_KEY) if
+ not specified.
+
+Example:
+
+adc-keypad {
+ compatible = "adc-keys";
+ poll-interval = <100>;
+ io-channels = < 0>, < 1>;
+
+ vol-up-button {
+ label = "Volume Up";
+ linux,code = ;
+ channel = <0>;
+ min-voltage = <160>;
+ max-voltage = <164>;
+ };
+
+ ...
+};
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Input: Add driver for a generic ADC keypad
Add a polled input driver for a keypad in which the buttons are connected
in resistor ladders to an ADC. The IIO framework is used to claim and
read the ADC channels.
Signed-off-by: Andrew Bresticker
---
drivers/input/keyboard/Kconfig| 13 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/adc-keys.c | 291 ++
3 files changed, 305 insertions(+)
create mode 100644 drivers/input/keyboard/adc-keys.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a89ba7c..bbaff9e 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -12,6 +12,19 @@ menuconfig INPUT_KEYBOARD
if INPUT_KEYBOARD
+config KEYBOARD_ADC
+ tristate "ADC Keypad"
+ depends on IIO
+ select INPUT_POLLDEV
+ help
+ This driver supports generic ADC keypads using IIO.
+
+ Say Y here if your device has buttons connected in a resistor ladder
+ to an ADC.
+
+ To compile this driver as a module, choose M here: the module will
+ be called adc-keys.
+
config KEYBOARD_ADP5520
tristate "Keypad Support for ADP5520 PMIC"
depends on PMIC_ADP5520
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 4707678..888fa62 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -4,6 +4,7 @@
# Each configuration option enables a list of files.
+obj-$(CONFIG_KEYBOARD_ADC) += adc-keys.o
obj-$(CONFIG_KEYBOARD_ADP5520) += adp5520-keys.o
obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
diff --git a/drivers/input/keyboard/adc-keys.c
b/drivers/input/keyboard/adc-keys.c
new file mode 100644
index 000..1b9bcad
--- /dev/null
+++ b/drivers/input/keyboard/adc-keys.c
@@ -0,0 +1,291 @@
+/*
+ * ADC keypad driver
+ *
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * Based on /drivers/input/keybaord/gpio_keys_polled.c:
+ * Copyright (C) 2007-2010 Gabor Juhos
+ * Copyright (C) 2010 Nuno Goncalves
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct adc_key {
+ const char *desc;
+ unsigned int type;
+ unsigned int code;
+ unsigned int min_uV;
+ unsigned int max_uV;
+};
+
+struct adc_chan_map {
+ struct adc_key *keys;
+ unsigned int num_keys;
+ int last_key;
+};
+
+struct adc_keypad {
+ struct device *dev;
+ struct input_polled_dev *poll_dev;
+ unsigned int poll_interval;
+ bool autorepeat;
+ struct iio_channel *iio_chans;
+ unsigned int num_chans;
+ struct adc_chan_map *chan_map;
+};
+
+static void adc_keypad_poll_chan(struct adc_keypad *keypad, unsigned int chan)
+{
+ struct adc_chan_map *chan_map = >chan_map[chan];
+ struct input_dev *input = keypad->poll_dev->input;
+ struct adc_key *key;
+ unsigned int adc_uV;
+ int ret, val, i;
+
+ ret = iio_read_channel_processed(>iio_chans[chan], );
+ if (ret < 0) {
+ dev_err(keypad->dev, "Failed to read ADC: %d\n", ret);
+ return;
+ }
+ adc_uV = val * 1000;
+
+ for (i = 0; i < chan_map->num_keys; i++) {
+ if (adc_uV >= chan_map->keys[i].min_uV &&
+ adc_uV <= chan_map->keys[i].max_uV)
+ break;
+ }
+ if (i >= chan_map->num_keys)
+ i = -1;
+
+ if (i != chan_map->last_key) {
+ if (chan_map->last_key >= 0) {
+ key = _map->keys[chan_map->last_key];
+ input_event(input, key->type, key->code, 0);
+ }
+ if (i >= 0) {
+ key = _map->keys[i];
+ input_event(input, key->type, key->code, 1);
+ }
+ input_sync(input);
+ chan_map->last_key = i;
+ }
+}
+
+static void adc_keypad_poll(struct input_polled_dev *poll_dev)
+{
+ struct adc_keypad *keypad = poll_dev->private;
+ unsigned int i;
+
+ for (i = 0; i < keypad->num_chans; i++)
+ adc_keypad_poll_chan(keypad, i);
+}
+
+static int adc_keypad_of_parse_chan(struct adc_keypad *keypad,
+ unsigned int chan)
+{
+ struct device_node *child, *np = keypad->dev->of_node;
+ struct adc_key *keys;
+ unsigned int i = 0;
+ int ret;
+
+ for_each_child_of_node(np, child) {
+ unsigned int c;
+
+ ret = of_property_read_u32(child, "channel", );
+ if (ret < 0)
+ continue;
+ if (c != chan)
+ continue;
+
Re: [PATCH 00/16 v2] iommu: Move domain allocation into drivers
Am Donnerstag, 26. März 2015, 13:43:03 schrieb Joerg Roedel: > Changes v1-v2: > > * Rebased to v4.0-rc5 > * Converted domain-types to a bit-field > > Hi, > > here is patch-set to replace the existing domain_init and > domain_destroy iommu-ops with the new domain_alloc and > domain_free callbacks > > The new callbacks move the allocation of iommu domains into > the iommu driver, allowing them to put a generic > iommu_domain struct into their own domain struct. This makes > domain handling in the drivers more cache efficient and > prepares the introduction of default domains in another > patch-set. > > While at it, this patch-set also introduces domain types. > These are internal to the iommu core code for now, there are > three of them: > > * DMA-API domains > * Identity mapped domains > * Domains unmanaged by the iommu-core, used for > iommu-api so that the users can create their own > mappings > > The patches have been compile tested for x86, ARM and PPC > and runtime tested on x86 (Intel VT-d and AMD IOMMU). > > Please review. core and Rockchip bits Tested-by: Heiko Stuebner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On 3/27/15 6:32 PM, David Ahern wrote: On 3/27/15 5:57 PM, Yinghai Lu wrote: On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote: On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote: Also please make sure your config have CONFIG_PCI_DEBUG=y and capture serial console with "debug ignore_loglevel", so we check if pci :00:01.0 really have resource assigned. Please check attached patch and send out boot log with above config. patched applied. PCI_DEBUG enabled. options added. log attached. This is with d63e2e1f3df reverted still. oops lied about that last one; I forgot to revert the patch this round. That the system booted with it applied is progress. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ia32_sysenter_target does not preserve EFLAGS
On Fri, Mar 27, 2015 at 9:00 PM, Linus Torvalds wrote: > On Fri, Mar 27, 2015 at 7:25 AM, Denys Vlasenko wrote: >> >> Apparently, users *don't* depend on arithmetic flags >> to survive over syscall. They also okay with DF flag >> being cleared. > > Generally, users probably dont' care about many registers at all being > saved, but it's worth noting that the reason system calls save/restore > even caller-saved registers is at least partly in order to avoid any > kernel information leaks. > > I don't believe that user mode will ever reasonably care about the > arithmetic flags being changed, but at the same time I also don't it > is something we should ever consider a "feature" we should try to take > advantage of. Generally we should try to not mess with the flag state, > and I'd *much* rather make the rule be that all the system call return > paths restore flags as much as possible. "We don't clobber anything" ABI has its appeal. OTOH, fulfilling ABI's promises has cost which hast to be paid on every syscall, regardless whether userspace needed it or not. Example. This is the uclibc implementation of write(): 004acfc4 <__libc_write>: 4acfc4: 53 push %rbx 4acfc5: 48 63 ffmovslq %edi,%rdi 4acfc8: b8 01 00 00 00 mov$0x1,%eax 4acfcd: 0f 05 syscall 4acfcf: 48 89 c3mov%rax,%rbx 4acfd2: 48 81 fb 00 f0 ff ffcmp$0xf000,%rbx 4acfd9: 76 0f jbe4acfea <__libc_write+0x26> 4acfdb: e8 64 15 00 00 callq 4ae544 <__GI___errno_location> 4acfe0: 89 da mov%ebx,%edx 4acfe2: f7 da neg%edx 4acfe4: 89 10 mov%edx,(%rax) 4acfe6: 48 83 c8 ff or $0x,%rax 4acfea: 5b pop%rbx 4acfeb: c3 retq This is a C function. Therefore any its caller assumes that C-clobbered registers can be, indeed, clobbered here, so if that caller uses any of them, it saves/restores them. All efforts by kernel code to save/restore C-clobbered registers, eight of them, are in vain. It's just useless work. Userspace does not benefit from that effort. If our syscall ABI would say that those regs are not preserved, we could have a bit faster syscalls. Any userspace code which really had to have those registers preserved across a particular syscall, could push/pop them itself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] vt: add cursor blink interval escape sequence
On 26 Mar 2015 13:54, Scot Doyle wrote: > Add an escape sequence to specify the current console's cursor blink > interval. The interval is specified as a number of milliseconds until > the next cursor display state toggle, from 50 to 65535. /proc/loadavg > did not show a difference with a one msec interval, but the lower > bound is set to 50 msecs since slower hardware wasn't tested. if they want to be crazy, why not let them ? it's not like we generally prevent the user from destroying their machine. i.e. just require the value to be > 0 (unless you want to let 0 disable things). -mike signature.asc Description: Digital signature
Re: d63e2e1f3df breaks sparc/T5-8
On 3/27/15 5:57 PM, Yinghai Lu wrote: On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote: On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote: Also please make sure your config have CONFIG_PCI_DEBUG=y and capture serial console with "debug ignore_loglevel", so we check if pci :00:01.0 really have resource assigned. Please check attached patch and send out boot log with above config. patched applied. PCI_DEBUG enabled. options added. log attached. This is with d63e2e1f3df reverted still. PROMLIB: Sun IEEE Boot Prom 'OBP 4.36.2 2014/10/24 08:15' PROMLIB: Root node compatible: sun4v Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct Linux version 4.0.0-rc5+ (root@ca-qasparc24) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4.0.9) (GCC) ) #2 SMP Fri Mar 27 20:12:10 EDT 2015 debug: skip boot console de-registration. debug: ignoring loglevel setting. bootconsole [earlyprom0] enabled ARCH: SUN4V Ethernet address: 00:10:e0:35:15:f6 MM: PAGE_OFFSET is 0xfff8 (max_phys_bits == 47) MM: VMALLOC [0x0001 --> 0x0006] MM: VMEMMAP [0x0006 --> 0x000c] Kernel: Using 3 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /virtual-devices@100/console@1 PROM: Built device tree with 1478490 bytes of memory. MDESC: Size is 774368 bytes. PLATFORM: banner-name [SPARC T5-8] PLATFORM: name [ORCL,SPARC-T5-8] PLATFORM: hostid [863515f6] PLATFORM: serial# [003515f6] PLATFORM: stick-frequency [3b9aca00] PLATFORM: mac-address [10e03515f6] PLATFORM: watchdog-resolution [1000 ms] PLATFORM: watchdog-max-timeout [3153600 ms] PLATFORM: max-cpus [1024] Allocated 81920 bytes for kernel page tables. Zone ranges: DMA [mem 0x3040-0x] Normal [mem 0x-0x383fffd11fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x3040-0x003fddee] node 0: [mem 0x003fddef6000-0x003fddef7fff] node 1: [mem 0x0800-0x083f] node 2: [mem 0x1000-0x103f] node 3: [mem 0x1800-0x183f] node 4: [mem 0x2000-0x203f] node 5: [mem 0x2800-0x283f] node 6: [mem 0x3000-0x303f] node 7: [mem 0x3800-0x383fffcddfff] node 7: [mem 0x383fffcee000-0x383fffd11fff] Initmem setup node 0 [mem 0x3040-0x003fddef7fff] On node 0 totalpages: 33385849 Normal zone: 293431 pages used for memmap Normal zone: 33385849 pages, LIFO batch:15 Initmem setup node 1 [mem 0x0800-0x083f] On node 1 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 2 [mem 0x1000-0x103f] On node 2 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 3 [mem 0x1800-0x183f] On node 3 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 4 [mem 0x2000-0x203f] On node 4 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 5 [mem 0x2800-0x283f] On node 5 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 6 [mem 0x3000-0x303f] On node 6 totalpages: 33554432 Normal zone: 294912 pages used for memmap Normal zone: 33554432 pages, LIFO batch:15 Initmem setup node 7 [mem 0x3800-0x383fffd11fff] On node 7 totalpages: 33554049 Normal zone: 294909 pages used for memmap Normal zone: 33554049 pages, LIFO batch:15 Booting Linux... CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c] PERCPU: Embedded 8 pages/cpu @fff8003f4d00 s27776 r8192 d29568 u65536 pcpu-alloc: s27776 r8192 d29568 u65536 alloc=1*4194304 pcpu-alloc: [0] 0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 0041 0042 0043 0044 0045 0046 0047 0048 0049 0050 0051 0052 0053 0054 0055 0056 0057 0058 0059 0060 0061 0062 0063 pcpu-alloc: [0] 0064 0065 0066 0067 0068 0069 0070 0071 0072 0073 0074 0075 0076 0077 0078 0079 0080 0081 0082 0083 0084 0085 0086 0087 0088 0089 0090 0091 0092 0093 0094 0095 0096 0097 0098 0099 0100 0101 0102 0103 0104 0105 0106 0107 0108 0109 0110 0111 0112 0113 0114 0115 0116 0117 0118 0119
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
Thanks for supporting the JSON format too. > (c) If not, given we don't know how to get us out of the current > status quo, can this patchseries still be applied, given the > original complaint was the size of our events-list.h (whereas The Intel core event lists are far larger even (and will grow even more when uncore gets added) > power7-events-list.h is almost twice the size)? If not, patch 3/3 > in this series is still valid, no matter what, and it should still > be applied (let us know if we need to resubmit). Could also just leave out the downloader for now, so that you have to get your own event file and set it up with export EVENTMAP=... That's basically the patchkit, minus one patch. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
> >> On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
> >> > On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez
> >> > wrote:
> >> > > On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
> >> > >> On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
> >> > >> > diff --git a/drivers/video/fbdev/aty/atyfb_base.c
> >> > >> > b/drivers/video/fbdev/aty/atyfb_base.c
> >> > >> > index 8025624..8875e56 100644
> >> > >> > --- a/drivers/video/fbdev/aty/atyfb_base.c
> >> > >> > +++ b/drivers/video/fbdev/aty/atyfb_base.c
> >> > >> > @@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
> >> > >> >
> >> > >> > #ifdef CONFIG_MTRR
> >> > >> > par->mtrr_aper = -1;
> >> > >> > - par->mtrr_reg = -1;
> >> > >> > if (!nomtrr) {
> >> > >> > - /* Cover the whole resource. */
> >> > >> > - par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
> >> > >> > + par->mtrr_aper = mtrr_add(info->fix.smem_start,
> >> > >> > + info->fix.smem_len,
> >> > >> > MTRR_TYPE_WRCOMB, 1);
> >> > >>
> >> > >> MTRRs need power of two size, so how is this supposed to work?
> >> > >
> >> > > As per mtrr_add_page() [0] the base and size are just supposed to be
> >> > > in units
> >> > > of 4 KiB, although the practice is to use powers of 2 in *some*
> >> > > drivers this
> >> > > is not standardized and by no means recorded as a requirement.
> >> > > Obviously
> >> > > powers of 2 will work too and you'd end up neatly aligned as well.
> >> > > mtrr_add()
> >> > > will use mtrr_check() to verify the the same requirement. Furthermore,
> >> > > as per my commit log message:
> >> >
> >> > Whatever the code may or may not do, the x86 architecture uses
> >> > power-of-two MTRR sizes. So I'm confused.
> >>
> >> There should be no confusion, I simply did not know that *was* the
> >> requirement for x86, if that is the case we should add a check for that
> >> and perhaps generalize a helper that does the power of two helper changes,
> >> the cleanest I found was the vesafb driver solution.
> >>
> >> Thoughts?
> >
> > The vesafb solution is bad since you'll only end up covering only
> > the first 4MB of the framebuffer instead of the almost 8MB you want.
> > Which in practice will mean throwing away half the VRAM since you really
> > don't want the massive performance hit from accessing it as UC. And that
> > would mean giving up decent display resolutions as well :(
> >
> > And the other option of trying to cover the remainder with multiple ever
> > smaller MTRRs doesn't work either since you'll run out of MTRRs very
> > quickly.
> >
> > This is precisely why I used the hole method in atyfb in the first
> > place.
> >
> > I don't really like the idea of any new mtrr code not supporting that
> > use case, especially as these things tend to be present in older machines
> > where PAT isn't an option.
>
> According to the Intel SDM, volume 3, section 11.5.2.1, table 11-6,
> non-PAT CPUs that have a WC MTRR, PCD = 1, and PWT = 1 (aka UC) have
> an effective memory type of UC. Hence my suggestion to add
> ioremap_x86_uc and/or set_memory_x86_uc to punch a UC hole in an
> otherwise WC MTRR-covered region.
OK I think I get it now.
And I take it this would hopefully only be used for non-PAT systems?
Would there be a use case for PAT systems? I wonder if we can wrap
this under some APIs to make it clean and hide this dirty thing
behind the scenes, it seems a fragile and error prone and my hope
would be that we won't need more specialization in this area for
PAT systems.
> ioremap_nocache is UC- (even on non-PAT unless I misunderstood how
> this stuff works), so ioremap_nocache by itself isn't good enough.
Thanks for the clarification.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] phy: add Broadcom SATA3 PHY driver for Broadcom STB SoCs
Hi Kishon,
On Thu, Mar 26, 2015 at 03:29:44AM +0530, Kishon Vijay Abraham I wrote:
> On Thursday 19 March 2015 06:53 AM, Brian Norris wrote:
> > Supports up to two ports which can each be powered on/off and configured
> > independently.
> >
> > Signed-off-by: Brian Norris
> > ---
> > drivers/phy/Kconfig| 9 ++
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-brcmstb-sata.c | 333
> > +
> > 3 files changed, 343 insertions(+)
> > create mode 100644 drivers/phy/phy-brcmstb-sata.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 2962de205ba7..c8b22074bcf6 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -291,4 +291,13 @@ config PHY_QCOM_UFS
> > help
> > Support for UFS PHY on QCOM chipsets.
> >
> > +config PHY_BRCMSTB_SATA
> > + tristate "Broadcom STB SATA PHY driver"
> > + depends on ARCH_BRCMSTB
> > + depends on OF
> > + select GENERIC_PHY
> > + help
> > + Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
> > + Likely useful only with CONFIG_SATA_BRCMSTB enabled.
> > +
> > endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index f080e1bb2a74..28a10804b4f4 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -38,3 +38,4 @@ obj-$(CONFIG_PHY_STIH41X_USB) +=
> > phy-stih41x-usb.o
> > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
> > +obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
> > diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
> > new file mode 100644
> > index ..413bc94225ac
> > --- /dev/null
> > +++ b/drivers/phy/phy-brcmstb-sata.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Broadcom SATA3 AHCI Controller PHY Driver
> > + *
> > + * Copyright © 2009-2015 Broadcom Corporation
> > + *
> > + * 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
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define SATA_MDIO_BANK_OFFSET 0x23c
> > +#define SATA_MDIO_REG_OFFSET(ofs) ((ofs) * 4)
> > +#define SATA_MDIO_REG_SPACE_SIZE 0x1000
> > +#define SATA_MDIO_REG_LENGTH 0x1f00
> > +
> > +#define SATA_TOP_CTRL_PHY_CTRL_1 0x0
> > + #define SATA_TOP_CTRL_1_PHY_DEFAULT_POWER_STATE BIT(14)
> > +
> > +#define SATA_TOP_CTRL_PHY_CTRL_2 0x4
> > + #define SATA_TOP_CTRL_2_SW_RST_MDIOREGBIT(0)
> > + #define SATA_TOP_CTRL_2_SW_RST_OOBBIT(1)
> > + #define SATA_TOP_CTRL_2_SW_RST_RX BIT(2)
> > + #define SATA_TOP_CTRL_2_SW_RST_TX BIT(3)
> > + #define SATA_TOP_CTRL_2_PHY_GLOBAL_RESET BIT(14)
> > +
> > +#define MAX_PORTS 2
> > +/* Register offset between PHYs in port-ctrl */
> > +#define SATA_TOP_CTRL_PHY_CTRL_LEN 0x8
> > +/* Register offset between PHYs in PCB space */
> > +#define SATA_MDIO_REG_SPACE_SIZE 0x1000
> > +
> > +struct brcm_sata_port {
> > + int portnum;
> > + struct phy *phy;
> > + struct brcm_sata_phy *phy_priv;
> > + bool ssc_en;
> > +};
> > +
> > +struct brcm_sata_phy {
> > + struct device *dev;
> > + void __iomem *port_ctrl;
> > + void __iomem *phy_base;
> > +
> > + struct brcm_sata_port phys[MAX_PORTS];
>
> Can't we allocate memory for the PHYs dynamically?
Yes, but I don't see a lot of point for an IP that supports exactly 2
ports...
> > +};
> > +
> > +enum sata_mdio_phy_regs_28nm {
> > + PLL_REG_BANK_0 = 0x50,
> > + PLL_REG_BANK_0_PLLCONTROL_0 = 0x81,
> > +
> > + TXPMD_REG_BANK = 0x1a0,
> > + TXPMD_CONTROL1 = 0x81,
> > + TXPMD_CONTROL1_TX_SSC_EN_FRC= BIT(0),
> > + TXPMD_CONTROL1_TX_SSC_EN_FRC_VAL= BIT(1),
> > + TXPMD_TX_FREQ_CTRL_CONTROL1 = 0x82,
> > + TXPMD_TX_FREQ_CTRL_CONTROL2 = 0x83,
> > + TXPMD_TX_FREQ_CTRL_CONTROL2_FMIN_MASK = 0x3ff,
> > + TXPMD_TX_FREQ_CTRL_CONTROL3 = 0x84,
> > + TXPMD_TX_FREQ_CTRL_CONTROL3_FMAX_MASK = 0x3ff,
> > +};
> > +
> > +static inline void
Re: [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around
On Fri, Mar 27, 2015 at 11:56:55PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
> > On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
> > > On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez
> > > wrote:
> > > > On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
> > > >> On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
> > > >> > diff --git a/drivers/video/fbdev/aty/atyfb_base.c
> > > >> > b/drivers/video/fbdev/aty/atyfb_base.c
> > > >> > index 8025624..8875e56 100644
> > > >> > --- a/drivers/video/fbdev/aty/atyfb_base.c
> > > >> > +++ b/drivers/video/fbdev/aty/atyfb_base.c
> > > >> > @@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
> > > >> >
> > > >> > #ifdef CONFIG_MTRR
> > > >> > par->mtrr_aper = -1;
> > > >> > - par->mtrr_reg = -1;
> > > >> > if (!nomtrr) {
> > > >> > - /* Cover the whole resource. */
> > > >> > - par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
> > > >> > + par->mtrr_aper = mtrr_add(info->fix.smem_start,
> > > >> > + info->fix.smem_len,
> > > >> > MTRR_TYPE_WRCOMB, 1);
> > > >>
> > > >> MTRRs need power of two size, so how is this supposed to work?
> > > >
> > > > As per mtrr_add_page() [0] the base and size are just supposed to be in
> > > > units
> > > > of 4 KiB, although the practice is to use powers of 2 in *some* drivers
> > > > this
> > > > is not standardized and by no means recorded as a requirement. Obviously
> > > > powers of 2 will work too and you'd end up neatly aligned as well.
> > > > mtrr_add()
> > > > will use mtrr_check() to verify the the same requirement. Furthermore,
> > > > as per my commit log message:
> > >
> > > Whatever the code may or may not do, the x86 architecture uses
> > > power-of-two MTRR sizes. So I'm confused.
> >
> > There should be no confusion, I simply did not know that *was* the
> > requirement for x86, if that is the case we should add a check for that
> > and perhaps generalize a helper that does the power of two helper changes,
> > the cleanest I found was the vesafb driver solution.
> >
> > Thoughts?
>
> The vesafb solution is bad since you'll only end up covering only
> the first 4MB of the framebuffer instead of the almost 8MB you want.
OK so the power of 2 requirement implicates us *having* to use a large
MTRR that includes the MMIo region in the shared PCI case?
Andy, Ville, are we 100% certain about this power of two requirement?
Is that for the base and size or just the size?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote:
> On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
> Also please make sure your config have
>
> CONFIG_PCI_DEBUG=y
>
> and capture serial console with "debug ignore_loglevel", so we check if
> pci :00:01.0 really have resource assigned.
Please check attached patch and send out boot log with above config.
Thanks
Yinghai
Subject: [RFC PATCH] PCI: Introduce pci_bus_addr_t
David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") broke sparc/T5-8.
In the boot log, there is
pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
0x110204000)
but that only could happen when dma_addr_t is 32-bit.
According to David Miller, all DMA occurs behind an IOMMU and these
IOMMUs only support 32-bit addressing, therefore dma_addr_t is
32-bit on sparc64.
Let's introduce pci_bus_addr instead of using dma_addr_t.
Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern
Signed-off-by: Yinghai Lu
---
arch/alpha/Kconfig |3 +++
arch/arm/Kconfig |1 +
arch/arm/mach-axxia/Kconfig|1 +
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-highbank/Kconfig |1 +
arch/arm/mach-shmobile/Kconfig |1 +
arch/arm/mm/Kconfig|3 +++
arch/arm64/Kconfig |3 +++
arch/ia64/Kconfig |3 +++
arch/mips/Kconfig |3 +++
arch/powerpc/Kconfig |3 +++
arch/sparc/Kconfig |3 +++
arch/tile/Kconfig |3 +++
arch/x86/Kconfig |4
drivers/pci/bus.c |8
drivers/pci/probe.c| 12 ++--
include/linux/pci.h|6 +++---
include/linux/types.h |7 +++
18 files changed, 53 insertions(+), 13 deletions(-)
Index: linux-2.6/arch/alpha/Kconfig
===
--- linux-2.6.orig/arch/alpha/Kconfig
+++ linux-2.6/arch/alpha/Kconfig
@@ -66,6 +66,9 @@ config ZONE_DMA
config ARCH_DMA_ADDR_T_64BIT
def_bool y
+config ARCH_PCI_BUS_ADDR_T_64BIT
+ def_bool y
+
config NEED_DMA_MAP_STATE
def_bool y
Index: linux-2.6/arch/arm/Kconfig
===
--- linux-2.6.orig/arch/arm/Kconfig
+++ linux-2.6/arch/arm/Kconfig
@@ -1779,6 +1779,7 @@ config XEN
depends on !GENERIC_ATOMIC64
depends on MMU
select ARCH_DMA_ADDR_T_64BIT
+ select ARCH_PCI_BUS_ADDR_T_64BIT
select ARM_PSCI
select SWIOTLB_XEN
help
Index: linux-2.6/arch/arm/mach-axxia/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-axxia/Kconfig
+++ linux-2.6/arch/arm/mach-axxia/Kconfig
@@ -1,6 +1,7 @@
config ARCH_AXXIA
bool "LSI Axxia platforms" if (ARCH_MULTI_V7 && ARM_LPAE)
select ARCH_DMA_ADDR_T_64BIT
+ select ARCH_PCI_BUS_ADDR_T_64BIT
select ARM_AMBA
select ARM_GIC
select ARM_TIMER_SP804
Index: linux-2.6/arch/arm/mach-exynos/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-exynos/Kconfig
+++ linux-2.6/arch/arm/mach-exynos/Kconfig
@@ -106,6 +106,7 @@ config SOC_EXYNOS5440
default y
depends on ARCH_EXYNOS5
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+ select ARCH_PCI_BUS_ADDR_T_64BIT if ARM_LPAE
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
select MIGHT_HAVE_PCI
Index: linux-2.6/arch/arm/mach-highbank/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-highbank/Kconfig
+++ linux-2.6/arch/arm/mach-highbank/Kconfig
@@ -1,6 +1,7 @@
config ARCH_HIGHBANK
bool "Calxeda ECX-1000/2000 (Highbank/Midway)" if ARCH_MULTI_V7
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+ select ARCH_PCI_BUS_ADDR_T_64BIT if ARM_LPAE
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_SUPPORTS_BIG_ENDIAN
select ARM_AMBA
Index: linux-2.6/arch/arm/mach-shmobile/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-shmobile/Kconfig
+++ linux-2.6/arch/arm/mach-shmobile/Kconfig
@@ -36,6 +36,7 @@ menuconfig ARCH_SHMOBILE_MULTI
select HAVE_ARM_TWD if SMP
select ARM_GIC
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+ select ARCH_PCI_BUS_ADDR_T_64BIT if ARM_LPAE
select NO_IOPORT_MAP
select PINCTRL
select ARCH_REQUIRE_GPIOLIB
Index: linux-2.6/arch/arm/mm/Kconfig
===
--- linux-2.6.orig/arch/arm/mm/Kconfig
+++ linux-2.6/arch/arm/mm/Kconfig
@@ -630,6 +630,9 @@ config ARCH_PHYS_ADDR_T_64BIT
config ARCH_DMA_ADDR_T_64BIT
bool
+config ARCH_PCI_BUS_ADDR_T_64BIT
+ bool
+
config ARM_THUMB
bool "Support
Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote:
> On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote:
> :
> > @@ -734,6 +742,7 @@ void __init mtrr_bp_init(void)
> > }
> >
> > if (mtrr_if) {
> > + mtrr_enabled = true;
> > set_num_var_ranges();
> > init_table();
> > if (use_intel()) {
> get_mtrr_state();
>
> After setting mtrr_enabled to true, get_mtrr_state() reads
> MSR_MTRRdefType and sets 'mtrr_state.enabled', which also indicates if
> MTRRs are enabled or not on the system. So, potentially, we could have
> a case that mtrr_enabled is set to true, but mtrr_state.enabled is set
> to disabled when MTRRs are disabled by BIOS.
Thanks for the review, in this case then we should update mtrr_enabled to false.
> ps.
> I recently cleaned up this part of the MTRR code in the patch below,
> which is currently available in the -mm & -next trees.
> https://lkml.org/lkml/2015/3/24/1063
Great I will rebase and work with that and try to address this
consideration you have raised.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 04:10:03PM -0700, Andy Lutomirski wrote: > On Fri, Mar 27, 2015 at 4:04 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote: > >> On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez wrote: > >> > On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: > >> >> On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez > >> >> wrote: > >> >> > On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: > >> >> >> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez > >> >> >> wrote: > >> >> >> > From: "Luis R. Rodriguez" > >> >> >> > > >> >> >> > Ideally on systems using PAT we can expect a swift > >> >> >> > transition away from MTRR. There can be a few exceptions > >> >> >> > to this, one is where device drivers are known to exist > >> >> >> > on PATs with errata, another situation is observed on > >> >> >> > old device drivers where devices had combined MMIO > >> >> >> > register access with whatever area they typically > >> >> >> > later wanted to end up using MTRR for on the same > >> >> >> > PCI BAR. This situation can still be addressed by > >> >> >> > splitting up ioremap'd PCI BAR into two ioremap'd > >> >> >> > calls, one for MMIO registers, and another for whatever > >> >> >> > is desirable for write-combining -- in order to > >> >> >> > accomplish this though quite a bit of driver > >> >> >> > restructuring is required. > >> >> >> > > >> >> >> > Device drivers which are known to require large > >> >> >> > amount of re-work in order to split ioremap'd areas > >> >> >> > can use __arch_phys_wc_add() to avoid regressions > >> >> >> > when PAT is enabled. > >> >> >> > > >> >> >> > For a good example driver where things are neatly > >> >> >> > split up on a PCI BAR refer the infiniband qib > >> >> >> > driver. For a good example of a driver where good > >> >> >> > amount of work is required refer to the infiniband > >> >> >> > ipath driver. > >> >> >> > > >> >> >> > This is *only* a transitive API -- and as such no new > >> >> >> > drivers are ever expected to use this. > >> >> >> > >> >> >> What's the exact layout that this helps? I'm sceptical that this can > >> >> >> ever be correct. > >> >> >> > >> >> >> Is there some awful driver that has a large ioremap that's supposed > >> >> >> to > >> >> >> contain multiple different memtypes? > >> >> > > >> >> > Yes, I cc'd you just now on one where I made changes on a driver > >> >> > which uses one > >> >> > PCI with mixed memtypes and uses MTRR to hole in WC. A transition to > >> >> > arch_phys_wc_add() is therefore not possible if PAT is enabled as it > >> >> > would > >> >> > regress those drivers by making the MTRR WC hole trick non functional. > >> >> > The changes are non trivial and so in this series I supplied changes > >> >> > on > >> >> > one driver only to show the effort required. The other drivers which > >> >> > required this were: > >> >> > > >> >> > Driver File > >> >> > > >> >> > fusion drivers/message/fusion/mptbase.c > >> >> > ivtvdrivers/media/pci/ivtv/ivtvfb.c > >> >> > ipath drivers/infiniband/hw/ipath/ipath_driver.c > >> >> > > >> >> > This series makes those drivers use __arch_phys_wc_add() more as a > >> >> > transitory phase in hopes we can address the proper split as with the > >> >> > atyfb illustrates. For ipath the changes required have a nice template > >> >> > with the qib driver as they share very similar driver structure, the > >> >> > qib driver *did* do the nice split. > >> >> > > >> >> >> If so, can we ioremap + set_page_xyz instead? > >> >> > > >> >> > I'm not sure I see which call we'd use. Care to provide an example > >> >> > patch > >> >> > alternative for the atyfb as a case in point alternative to the work > >> >> > required > >> >> > to do the split? > >> >> > > >> >> > >> >> I'm still confused. Would it be insufficient to ioremap_nocache the > >> >> whole thing and then call set_memory_wc on parts of it? (Sorry, > >> >> set_page_xyz was a typo.) > >> > > >> > I think that would be a sexy alternative. > >> > > >> > In this driver's case the thing is a bit messy as it not only used > >> > the WC MTRR for a hole but it also then used a UC MTRR on top of > >> > it all, so since I already tried to address the split, and if we address > >> > the power of 2 woes, I think it'd be best to try to remove the UC MTRR > >> > and just avoid set_page_wc() in this driver's case, but for the other > >> > cases > >> > (fusion, ivtv, ipath) I think this makes sense. > >> > > >> > Thoughts? > >> > >> Once that WC MTRR is in place, I think you really need UC and not UC- > >> if you want to override it. Otherwise I agree with all of this. > > > > Do you mean that the UC MTRR work around that was in place might not > > have really been effective? Not quite sure what you mean. I don't think > > I follow. > > I mean that the UC MTRR that
Re: [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around
On Fri, Mar 27, 2015 at 02:21:34PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 27, 2015 at 1:12 PM, Luis R. Rodriguez wrote:
> > On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
> >> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
> >> wrote:
> >> > diff --git a/drivers/video/fbdev/aty/atyfb_base.c
> >> > b/drivers/video/fbdev/aty/atyfb_base.c
> >> > index 8025624..8875e56 100644
> >> > --- a/drivers/video/fbdev/aty/atyfb_base.c
> >> > +++ b/drivers/video/fbdev/aty/atyfb_base.c
> >> > @@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
> >> >
> >> > #ifdef CONFIG_MTRR
> >> > par->mtrr_aper = -1;
> >> > - par->mtrr_reg = -1;
> >> > if (!nomtrr) {
> >> > - /* Cover the whole resource. */
> >> > - par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
> >> > + par->mtrr_aper = mtrr_add(info->fix.smem_start,
> >> > + info->fix.smem_len,
> >> > MTRR_TYPE_WRCOMB, 1);
> >> > - if (par->mtrr_aper >= 0 && !par->aux_start) {
> >> > - /* Make a hole for mmio. */
> >> > - par->mtrr_reg = mtrr_add(par->res_start +
> >> > 0x80 -
> >> > -GUI_RESERVE,
> >> > GUI_RESERVE,
> >> > -MTRR_TYPE_UNCACHABLE,
> >> > 1);
> >> > - if (par->mtrr_reg < 0) {
> >> > - mtrr_del(par->mtrr_aper, 0, 0);
> >> > - par->mtrr_aper = -1;
> >> > - }
> >> > - }
> >> > }
> >> > #endif
> >> >
> >> > @@ -2776,10 +2765,6 @@ aty_init_exit:
> >> > par->pll_ops->set_pll(info, >saved_pll);
> >> >
> >> > #ifdef CONFIG_MTRR
> >> > - if (par->mtrr_reg >= 0) {
> >> > - mtrr_del(par->mtrr_reg, 0, 0);
> >> > - par->mtrr_reg = -1;
> >> > - }
> >> > if (par->mtrr_aper >= 0) {
> >> > mtrr_del(par->mtrr_aper, 0, 0);
> >> > par->mtrr_aper = -1;
> >> > @@ -3466,7 +3451,7 @@ static int atyfb_setup_generic(struct pci_dev
> >> > *pdev, struct fb_info *info,
> >> > }
> >> >
> >> > info->fix.mmio_start = raddr;
> >> > - par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000);
> >> > + par->ati_regbase = ioremap_nocache(info->fix.mmio_start, 0x1000);
> >>
> >> Double-check me, but I think that ioremap_nocache + WC MTRR = WC.
> >
> > Precicely, in this case the WC hole was obtained by using MTRR WC. This
> > patch removes that WC hole trick and now we can be explciit about
> > only wanting ioremap_nocache() on the registers, that is WC is not
> > desired here and is not used. The patch does not highlight the fact
> > that there was left in place another ioremap() call for the framebuffer:
> >
> > info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
> >
> > That is the one that later after this patch we use ioremap_wc() for.
> > This patch just removes the hole solution. That's all.
> >
>
> I don't understand.
>
> If I read it right, there's a 2^n byte BAR. You're requesting WC for
> the whole think using arch_phys_wc_add.
I believe there is a misunderstanding of order of changes.
Let's split when we use mtrr_add() Vs arch_phys_wc_add() to avoid
confusion as in this patch we don't yet use arch_phys_wc_add(). That
is done in the next patch.
The commit log describes best the state of affairs prior to this
patch:
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full framebuffer
including the MMIO space *and* ___then___ use an MTRR with
MTRR_TYPE_WRCOMB on the full PCI BAR... and finally "hole"
in an MTRR_TYPE_UNCACHABLE MTRR only for MMIO.
Then this patch drops the MTRR_TYPE_UNCACHABLE rewrite thing
and instead corrects the ioremap() call for the framebuffer
to only be called for the framebuffer alone. For the MMIO
area we adjust to use then ioremap_nocache(). The MTRR left
is now only *for the framebuffer* and it should not be touching
the MMIO area. So the MMIO area has its own ioremap_nocache()
area alone, the framebuffer is left with an ioremap() followed
by an mtrr_add() call.
The next patch replaces the mtrr_add() with arch_phys_wc_add()
and then also uses ioremap_wc().
> On a PAT system that has no effect and all is well.
Yeah we're not doing arch_phys_wc_add() on the entire PCI BAR.
That was dumb, this fixes that, and on this patch mtrr_add()
is still used.
> On a non-PAT system, it adds an MTRR. That
> means that you need to override the MTRR somehow for the mmio regs,
> and UC- won't do the trick.
We don't need to
Re: [PATCH V2 1/3] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform
On Mon, Mar 23, 2015 at 11:31 AM, Wolfram Sang wrote:
> On Wed, Feb 18, 2015 at 11:34:01AM -0800, Feng Kan wrote:
>> Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
>> device driver use the SLIMpro Mailbox driver to tunnel message to
>> the SLIMpro coprocessor to do the work of accessing I2C components.
>>
>> Signed-off-by: Feng Kan
>> Signed-off-by: Hieu Le
>
> Sigh, I lost my first review, so here we go again...
> It looks mostly good. Using checkpatch with '--strict' will show some
> whitespace issues. Please fix these.
>
>> +config I2C_XGENE_SLIMPRO
>> + tristate "APM X-Gene SoC I2C SLIMpro devices support"
>> + depends on ARCH_XGENE && MAILBOX
>
> COMPILE_TEST?
>
>> +static int start_i2c_msg_xfer(struct slimpro_i2c_dev *ctx)
>> +{
>> + if (ctx->mbox_client.tx_block) {
>> + if (!wait_for_completion_timeout(>rd_complete,
>> + msecs_to_jiffies
>> + (MAILBOX_OP_TIMEOUT)))
>
> Don't be too strict with the 80 char limit IMHO. I think it is more
> readable to combine the last two lines into one.
>
>> + msg[0] = SLIMPRO_IIC_ENCODE_MSG(SLIMPRO_IIC_BUS, chip,
>> + SLIMPRO_IIC_READ, protocol, addrlen,
>> + readlen);
>
> ditto
>
>> + msg[0] = SLIMPRO_IIC_ENCODE_MSG(SLIMPRO_IIC_BUS, chip,
>> + SLIMPRO_IIC_WRITE, protocol, addrlen,
>> + writelen);
>
> ditto
>
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, readlen,
>> +DMA_FROM_DEVICE);
>
> The device should be the device of the dma channel.
The device is not visible on linux, DMA is done by the helper processor.
Perhaps you cah give me some idea how to do this. Thanks
>
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, writelen,
>> +DMA_TO_DEVICE);
>
> ditto
>
>> + rc = dma_mapping_error(ctx->dev, paddr);
>> + if (dma_mapping_error(ctx->dev, paddr)) {
>
> if (rc)
>
>> +static struct i2c_algorithm xgene_slimpro_i2c_algorithm = {
>> + .smbus_xfer = xgene_slimpro_i2c_xfer,
>
> Might be a tad less confusing to name this function
> xgene_slimpro_smbus_xfer. You decide.
>
>> + rc = i2c_add_adapter(adapter);
>> + if (rc) {
>> + dev_err(>dev, "Adapter registeration failed\n");
>> + return rc;
>> + }
>> +
>> + rc = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
>> + if (rc)
>> + dev_warn(>dev, "Unable to set dma mask\n");
>
> Shouldn't that be before i2c_add_adapter?
>
>> +static struct platform_driver xgene_slimpro_i2c_driver = {
>> + .probe = xgene_slimpro_i2c_probe,
>> + .remove = xgene_slimpro_i2c_remove,
>> + .driver = {
>> + .name = "xgene-slimpro-i2c",
>> + .of_match_table = of_match_ptr(xgene_slimpro_i2c_id)
>
> You are DT only, do we need of_match_ptr?
>
>> +MODULE_DESCRIPTION("APM X-Gene SLIMpro I2C driver");
>> +MODULE_LICENSE("GPL");
>
> MODULE_AUTHOR left out intentionally?
>
> Thanks,
>
>Wolfram
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 16/20] crypto: mark NEON bit sliced AES helper ciphers
Flag all NEON bit sliced AES helper ciphers as internal ciphers to
prevent them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/arm/crypto/aesbs-glue.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/aesbs-glue.c b/arch/arm/crypto/aesbs-glue.c
index 15468fb..6d68529 100644
--- a/arch/arm/crypto/aesbs-glue.c
+++ b/arch/arm/crypto/aesbs-glue.c
@@ -301,7 +301,8 @@ static struct crypto_alg aesbs_algs[] = { {
.cra_name = "__cbc-aes-neonbs",
.cra_driver_name= "__driver-cbc-aes-neonbs",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct aesbs_cbc_ctx),
.cra_alignmask = 7,
@@ -319,7 +320,8 @@ static struct crypto_alg aesbs_algs[] = { {
.cra_name = "__ctr-aes-neonbs",
.cra_driver_name= "__driver-ctr-aes-neonbs",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct aesbs_ctr_ctx),
.cra_alignmask = 7,
@@ -337,7 +339,8 @@ static struct crypto_alg aesbs_algs[] = { {
.cra_name = "__xts-aes-neonbs",
.cra_driver_name= "__driver-xts-aes-neonbs",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct aesbs_xts_ctx),
.cra_alignmask = 7,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 17/20] crypto: mark ARMv8 AES helper ciphers
Flag all ARMv8 AES helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/arm/crypto/aes-ce-glue.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index d2ee591..b445a5d 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -354,7 +354,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__ecb-aes-ce",
.cra_driver_name= "__driver-ecb-aes-ce",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -372,7 +373,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__cbc-aes-ce",
.cra_driver_name= "__driver-cbc-aes-ce",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -390,7 +392,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__ctr-aes-ce",
.cra_driver_name= "__driver-ctr-aes-ce",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -408,7 +411,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__xts-aes-ce",
.cra_driver_name= "__driver-xts-aes-ce",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_xts_ctx),
.cra_alignmask = 7,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 20/20] crypto: mark Multi buffer SHA1 helper cipher
Flag all Multi buffer SHA1 helper ciphers as internal ciphers
to prevent them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/sha-mb/sha1_mb.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-mb/sha1_mb.c
index 9414fd9..e510b1c 100644
--- a/arch/x86/crypto/sha-mb/sha1_mb.c
+++ b/arch/x86/crypto/sha-mb/sha1_mb.c
@@ -694,7 +694,8 @@ static struct shash_alg sha1_mb_shash_alg = {
* use ASYNC flag as some buffers in multi-buffer
* algo may not have completed before hashing thread sleep
*/
- .cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_ASYNC,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SHA1_BLOCK_SIZE,
.cra_module = THIS_MODULE,
.cra_list=
LIST_HEAD_INIT(sha1_mb_shash_alg.base.cra_list),
@@ -770,7 +771,9 @@ static int sha1_mb_async_init_tfm(struct crypto_tfm *tfm)
struct sha1_mb_ctx *ctx = crypto_tfm_ctx(tfm);
struct mcryptd_hash_ctx *mctx;
- mcryptd_tfm = mcryptd_alloc_ahash("__intel_sha1-mb", 0, 0);
+ mcryptd_tfm = mcryptd_alloc_ahash("__intel_sha1-mb",
+ CRYPTO_ALG_INTERNAL,
+ CRYPTO_ALG_INTERNAL);
if (IS_ERR(mcryptd_tfm))
return PTR_ERR(mcryptd_tfm);
mctx = crypto_ahash_ctx(_tfm->base);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 4:04 PM, Luis R. Rodriguez wrote: > On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote: >> On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez wrote: >> > On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: >> >> On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez >> >> wrote: >> >> > On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: >> >> >> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez >> >> >> wrote: >> >> >> > From: "Luis R. Rodriguez" >> >> >> > >> >> >> > Ideally on systems using PAT we can expect a swift >> >> >> > transition away from MTRR. There can be a few exceptions >> >> >> > to this, one is where device drivers are known to exist >> >> >> > on PATs with errata, another situation is observed on >> >> >> > old device drivers where devices had combined MMIO >> >> >> > register access with whatever area they typically >> >> >> > later wanted to end up using MTRR for on the same >> >> >> > PCI BAR. This situation can still be addressed by >> >> >> > splitting up ioremap'd PCI BAR into two ioremap'd >> >> >> > calls, one for MMIO registers, and another for whatever >> >> >> > is desirable for write-combining -- in order to >> >> >> > accomplish this though quite a bit of driver >> >> >> > restructuring is required. >> >> >> > >> >> >> > Device drivers which are known to require large >> >> >> > amount of re-work in order to split ioremap'd areas >> >> >> > can use __arch_phys_wc_add() to avoid regressions >> >> >> > when PAT is enabled. >> >> >> > >> >> >> > For a good example driver where things are neatly >> >> >> > split up on a PCI BAR refer the infiniband qib >> >> >> > driver. For a good example of a driver where good >> >> >> > amount of work is required refer to the infiniband >> >> >> > ipath driver. >> >> >> > >> >> >> > This is *only* a transitive API -- and as such no new >> >> >> > drivers are ever expected to use this. >> >> >> >> >> >> What's the exact layout that this helps? I'm sceptical that this can >> >> >> ever be correct. >> >> >> >> >> >> Is there some awful driver that has a large ioremap that's supposed to >> >> >> contain multiple different memtypes? >> >> > >> >> > Yes, I cc'd you just now on one where I made changes on a driver which >> >> > uses one >> >> > PCI with mixed memtypes and uses MTRR to hole in WC. A transition to >> >> > arch_phys_wc_add() is therefore not possible if PAT is enabled as it >> >> > would >> >> > regress those drivers by making the MTRR WC hole trick non functional. >> >> > The changes are non trivial and so in this series I supplied changes on >> >> > one driver only to show the effort required. The other drivers which >> >> > required this were: >> >> > >> >> > Driver File >> >> > >> >> > fusion drivers/message/fusion/mptbase.c >> >> > ivtvdrivers/media/pci/ivtv/ivtvfb.c >> >> > ipath drivers/infiniband/hw/ipath/ipath_driver.c >> >> > >> >> > This series makes those drivers use __arch_phys_wc_add() more as a >> >> > transitory phase in hopes we can address the proper split as with the >> >> > atyfb illustrates. For ipath the changes required have a nice template >> >> > with the qib driver as they share very similar driver structure, the >> >> > qib driver *did* do the nice split. >> >> > >> >> >> If so, can we ioremap + set_page_xyz instead? >> >> > >> >> > I'm not sure I see which call we'd use. Care to provide an example >> >> > patch >> >> > alternative for the atyfb as a case in point alternative to the work >> >> > required >> >> > to do the split? >> >> > >> >> >> >> I'm still confused. Would it be insufficient to ioremap_nocache the >> >> whole thing and then call set_memory_wc on parts of it? (Sorry, >> >> set_page_xyz was a typo.) >> > >> > I think that would be a sexy alternative. >> > >> > In this driver's case the thing is a bit messy as it not only used >> > the WC MTRR for a hole but it also then used a UC MTRR on top of >> > it all, so since I already tried to address the split, and if we address >> > the power of 2 woes, I think it'd be best to try to remove the UC MTRR >> > and just avoid set_page_wc() in this driver's case, but for the other cases >> > (fusion, ivtv, ipath) I think this makes sense. >> > >> > Thoughts? >> >> Once that WC MTRR is in place, I think you really need UC and not UC- >> if you want to override it. Otherwise I agree with all of this. > > Do you mean that the UC MTRR work around that was in place might not > have really been effective? Not quite sure what you mean. I don't think > I follow. I mean that the UC MTRR that overrides the WC MTRR was probably fine (I hope smaller MTRRs override larger MTRRs). But we should just ditch UC MTRRs entirely, and setting UC in the page tables would work on all CPUs *if we supported that*. We'd need to add a couple trivial helpers to do that. --Andy > > Luis -- Andy
[PATCH v2 18/20] crypto: mark 64 bit ARMv8 AES helper ciphers
Flag all 64 bit ARMv8 AES helper ciphers as internal ciphers to
prevent them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/arm64/crypto/aes-glue.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index b1b5b89..05d9e16 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -284,7 +284,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__ecb-aes-" MODE,
.cra_driver_name= "__driver-ecb-aes-" MODE,
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -302,7 +303,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__cbc-aes-" MODE,
.cra_driver_name= "__driver-cbc-aes-" MODE,
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -320,7 +322,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__ctr-aes-" MODE,
.cra_driver_name= "__driver-ctr-aes-" MODE,
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx),
.cra_alignmask = 7,
@@ -338,7 +341,8 @@ static struct crypto_alg aes_algs[] = { {
.cra_name = "__xts-aes-" MODE,
.cra_driver_name= "__driver-xts-aes-" MODE,
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_xts_ctx),
.cra_alignmask = 7,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/20] crypto: mark CAST5 helper ciphers
Flag all CAST5 helper ciphers as internal ciphers to prevent them
from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/cast5_avx_glue.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/crypto/cast5_avx_glue.c b/arch/x86/crypto/cast5_avx_glue.c
index 60ada67..236c809 100644
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -341,7 +341,8 @@ static struct crypto_alg cast5_algs[6] = { {
.cra_name = "__ecb-cast5-avx",
.cra_driver_name= "__driver-ecb-cast5-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST5_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast5_ctx),
.cra_alignmask = 0,
@@ -360,7 +361,8 @@ static struct crypto_alg cast5_algs[6] = { {
.cra_name = "__cbc-cast5-avx",
.cra_driver_name= "__driver-cbc-cast5-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST5_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast5_ctx),
.cra_alignmask = 0,
@@ -379,7 +381,8 @@ static struct crypto_alg cast5_algs[6] = { {
.cra_name = "__ctr-cast5-avx",
.cra_driver_name= "__driver-ctr-cast5-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct cast5_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 15/20] crypto: mark Twofish AVX helper ciphers
Flag all Twofish AVX helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/twofish_avx_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/twofish_avx_glue.c
b/arch/x86/crypto/twofish_avx_glue.c
index 1ac531e..b5e2d56 100644
--- a/arch/x86/crypto/twofish_avx_glue.c
+++ b/arch/x86/crypto/twofish_avx_glue.c
@@ -340,7 +340,8 @@ static struct crypto_alg twofish_algs[10] = { {
.cra_name = "__ecb-twofish-avx",
.cra_driver_name= "__driver-ecb-twofish-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = TF_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct twofish_ctx),
.cra_alignmask = 0,
@@ -359,7 +360,8 @@ static struct crypto_alg twofish_algs[10] = { {
.cra_name = "__cbc-twofish-avx",
.cra_driver_name= "__driver-cbc-twofish-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = TF_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct twofish_ctx),
.cra_alignmask = 0,
@@ -378,7 +380,8 @@ static struct crypto_alg twofish_algs[10] = { {
.cra_name = "__ctr-twofish-avx",
.cra_driver_name= "__driver-ctr-twofish-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct twofish_ctx),
.cra_alignmask = 0,
@@ -398,7 +401,8 @@ static struct crypto_alg twofish_algs[10] = { {
.cra_name = "__lrw-twofish-avx",
.cra_driver_name= "__driver-lrw-twofish-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = TF_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct twofish_lrw_ctx),
.cra_alignmask = 0,
@@ -421,7 +425,8 @@ static struct crypto_alg twofish_algs[10] = { {
.cra_name = "__xts-twofish-avx",
.cra_driver_name= "__driver-xts-twofish-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = TF_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct twofish_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/20] crypto: mark CAST6 helper ciphers
Flag all CAST6 helper ciphers as internal ciphers to prevent them
from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/cast6_avx_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/cast6_avx_glue.c b/arch/x86/crypto/cast6_avx_glue.c
index 0160f68..f448810 100644
--- a/arch/x86/crypto/cast6_avx_glue.c
+++ b/arch/x86/crypto/cast6_avx_glue.c
@@ -372,7 +372,8 @@ static struct crypto_alg cast6_algs[10] = { {
.cra_name = "__ecb-cast6-avx",
.cra_driver_name= "__driver-ecb-cast6-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST6_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast6_ctx),
.cra_alignmask = 0,
@@ -391,7 +392,8 @@ static struct crypto_alg cast6_algs[10] = { {
.cra_name = "__cbc-cast6-avx",
.cra_driver_name= "__driver-cbc-cast6-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST6_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast6_ctx),
.cra_alignmask = 0,
@@ -410,7 +412,8 @@ static struct crypto_alg cast6_algs[10] = { {
.cra_name = "__ctr-cast6-avx",
.cra_driver_name= "__driver-ctr-cast6-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct cast6_ctx),
.cra_alignmask = 0,
@@ -430,7 +433,8 @@ static struct crypto_alg cast6_algs[10] = { {
.cra_name = "__lrw-cast6-avx",
.cra_driver_name= "__driver-lrw-cast6-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST6_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast6_lrw_ctx),
.cra_alignmask = 0,
@@ -453,7 +457,8 @@ static struct crypto_alg cast6_algs[10] = { {
.cra_name = "__xts-cast6-avx",
.cra_driver_name= "__driver-xts-cast6-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAST6_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct cast6_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] kselftest: Add exit code defines
On 3/27/15 3:59 PM, Michael Ellerman wrote:
> On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
>> Define the exit codes with KSFT_PASS and similar so tests can use these
>> directly if they choose. Also enable harnesses and other tooling to use
>> the defines instead of hardcoding the return codes.
>
> +1
>
>> diff --git a/tools/testing/selftests/kselftest.h
>> b/tools/testing/selftests/kselftest.h
>> index 572c888..ef1c80d 100644
>> --- a/tools/testing/selftests/kselftest.h
>> +++ b/tools/testing/selftests/kselftest.h
>> @@ -13,6 +13,13 @@
>> #include
>> #include
>>
>> +/* define kselftest exit codes */
>> +#define KSFT_PASS 0
>> +#define KSFT_FAIL 1
>> +#define KSFT_XFAIL 2
>> +#define KSFT_XPASS 3
>> +#define KSFT_SKIP 4
>> +
>> /* counters */
>> struct ksft_count {
>> unsigned int ksft_pass;
>> @@ -40,23 +47,23 @@ static inline void ksft_print_cnts(void)
>>
>> static inline int ksft_exit_pass(void)
>> {
>> -exit(0);
>> +exit(KSFT_PASS);
>> }
>
> Am I the only person who's bothered by the fact that these don't actually
> return int?
That bothered me to, but I couldn't be bothered to go read the manuals
apparently to come up with a compelling argument :-)
I also think the ksft_exit* routines should go ahead and increment the
counters (at least optionally) so we don't have to call two functions.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 19/20] crypto: mcryptd to process CRYPTO_ALG_INTERNAL
The mcryptd is used as a wrapper around internal ciphers. Therefore,
the mcryptd must process the internal cipher by marking mcryptd as
internal if the underlying cipher is an internal cipher.
Signed-off-by: Stephan Mueller
---
crypto/mcryptd.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index a8e8704..fe5b495a 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -258,6 +258,20 @@ out_free_inst:
goto out;
}
+static inline void mcryptd_check_internal(struct rtattr **tb, u32 *type,
+ u32 *mask)
+{
+ struct crypto_attr_type *algt;
+
+ algt = crypto_get_attr_type(tb);
+ if (IS_ERR(algt))
+ return;
+ if ((algt->type & CRYPTO_ALG_INTERNAL))
+ *type |= CRYPTO_ALG_INTERNAL;
+ if ((algt->mask & CRYPTO_ALG_INTERNAL))
+ *mask |= CRYPTO_ALG_INTERNAL;
+}
+
static int mcryptd_hash_init_tfm(struct crypto_tfm *tfm)
{
struct crypto_instance *inst = crypto_tfm_alg_instance(tfm);
@@ -480,9 +494,13 @@ static int mcryptd_create_hash(struct crypto_template
*tmpl, struct rtattr **tb,
struct ahash_instance *inst;
struct shash_alg *salg;
struct crypto_alg *alg;
+ u32 type = 0;
+ u32 mask = 0;
int err;
- salg = shash_attr_alg(tb[1], 0, 0);
+ mcryptd_check_internal(tb, , );
+
+ salg = shash_attr_alg(tb[1], type, mask);
if (IS_ERR(salg))
return PTR_ERR(salg);
@@ -502,7 +520,10 @@ static int mcryptd_create_hash(struct crypto_template
*tmpl, struct rtattr **tb,
if (err)
goto out_free_inst;
- inst->alg.halg.base.cra_flags = CRYPTO_ALG_ASYNC;
+ type = CRYPTO_ALG_ASYNC;
+ if (alg->cra_flags & CRYPTO_ALG_INTERNAL)
+ type |= CRYPTO_ALG_INTERNAL;
+ inst->alg.halg.base.cra_flags = type;
inst->alg.halg.digestsize = salg->digestsize;
inst->alg.halg.base.cra_ctxsize = sizeof(struct mcryptd_hash_ctx);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/20] crypto: mark AVX Camellia helper ciphers
Flag all AVX Camellia helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/camellia_aesni_avx_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/camellia_aesni_avx_glue.c
b/arch/x86/crypto/camellia_aesni_avx_glue.c
index ed38d95..78818a1 100644
--- a/arch/x86/crypto/camellia_aesni_avx_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx_glue.c
@@ -335,7 +335,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__ecb-camellia-aesni",
.cra_driver_name= "__driver-ecb-camellia-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -354,7 +355,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__cbc-camellia-aesni",
.cra_driver_name= "__driver-cbc-camellia-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -373,7 +375,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__ctr-camellia-aesni",
.cra_driver_name= "__driver-ctr-camellia-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -393,7 +396,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__lrw-camellia-aesni",
.cra_driver_name= "__driver-lrw-camellia-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_lrw_ctx),
.cra_alignmask = 0,
@@ -416,7 +420,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__xts-camellia-aesni",
.cra_driver_name= "__driver-xts-camellia-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/20] crypto: mark GHASH ARMv8 vmull.p64 helper ciphers
Flag all GHASH ARMv8 vmull.p64 helper ciphers as internal ciphers
to prevent them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/arm/crypto/ghash-ce-glue.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 8c959d1..03a39fe 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -141,7 +141,7 @@ static struct shash_alg ghash_alg = {
.cra_name = "ghash",
.cra_driver_name = "__driver-ghash-ce",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_INTERNAL,
.cra_blocksize = GHASH_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct ghash_key),
.cra_module = THIS_MODULE,
@@ -248,7 +248,9 @@ static int ghash_async_init_tfm(struct crypto_tfm *tfm)
struct cryptd_ahash *cryptd_tfm;
struct ghash_async_ctx *ctx = crypto_tfm_ctx(tfm);
- cryptd_tfm = cryptd_alloc_ahash("__driver-ghash-ce", 0, 0);
+ cryptd_tfm = cryptd_alloc_ahash("__driver-ghash-ce",
+ CRYPTO_ALG_INTERNAL,
+ CRYPTO_ALG_INTERNAL);
if (IS_ERR(cryptd_tfm))
return PTR_ERR(cryptd_tfm);
ctx->cryptd_tfm = cryptd_tfm;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/20] crypto: mark AES-NI Camellia helper ciphers
Flag all AES-NI Camellia helper ciphers as internal ciphers to
prevent them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/camellia_aesni_avx2_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/camellia_aesni_avx2_glue.c
b/arch/x86/crypto/camellia_aesni_avx2_glue.c
index 9a07faf..baf0ac2 100644
--- a/arch/x86/crypto/camellia_aesni_avx2_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx2_glue.c
@@ -343,7 +343,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__ecb-camellia-aesni-avx2",
.cra_driver_name= "__driver-ecb-camellia-aesni-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -362,7 +363,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__cbc-camellia-aesni-avx2",
.cra_driver_name= "__driver-cbc-camellia-aesni-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -381,7 +383,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__ctr-camellia-aesni-avx2",
.cra_driver_name= "__driver-ctr-camellia-aesni-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct camellia_ctx),
.cra_alignmask = 0,
@@ -401,7 +404,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__lrw-camellia-aesni-avx2",
.cra_driver_name= "__driver-lrw-camellia-aesni-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_lrw_ctx),
.cra_alignmask = 0,
@@ -424,7 +428,8 @@ static struct crypto_alg cmll_algs[10] = { {
.cra_name = "__xts-camellia-aesni-avx2",
.cra_driver_name= "__driver-xts-camellia-aesni-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = CAMELLIA_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct camellia_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/20] crypto: mark ghash clmulni helper ciphers
Flag all ash clmulni helper ciphers as internal ciphers to prevent them
from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/ghash-clmulni-intel_glue.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c
b/arch/x86/crypto/ghash-clmulni-intel_glue.c
index 8253d85..2079baf 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -154,7 +154,8 @@ static struct shash_alg ghash_alg = {
.cra_name = "__ghash",
.cra_driver_name= "__ghash-pclmulqdqni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = GHASH_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct ghash_ctx),
.cra_module = THIS_MODULE,
@@ -261,7 +262,9 @@ static int ghash_async_init_tfm(struct crypto_tfm *tfm)
struct cryptd_ahash *cryptd_tfm;
struct ghash_async_ctx *ctx = crypto_tfm_ctx(tfm);
- cryptd_tfm = cryptd_alloc_ahash("__ghash-pclmulqdqni", 0, 0);
+ cryptd_tfm = cryptd_alloc_ahash("__ghash-pclmulqdqni",
+ CRYPTO_ALG_INTERNAL,
+ CRYPTO_ALG_INTERNAL);
if (IS_ERR(cryptd_tfm))
return PTR_ERR(cryptd_tfm);
ctx->cryptd_tfm = cryptd_tfm;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/20] crypto: mark Serpent AVX2 helper ciphers
Flag all Serpent AVX2 helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/serpent_avx2_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/serpent_avx2_glue.c
b/arch/x86/crypto/serpent_avx2_glue.c
index 437e47a..2f63dc8 100644
--- a/arch/x86/crypto/serpent_avx2_glue.c
+++ b/arch/x86/crypto/serpent_avx2_glue.c
@@ -309,7 +309,8 @@ static struct crypto_alg srp_algs[10] = { {
.cra_name = "__ecb-serpent-avx2",
.cra_driver_name= "__driver-ecb-serpent-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -329,7 +330,8 @@ static struct crypto_alg srp_algs[10] = { {
.cra_name = "__cbc-serpent-avx2",
.cra_driver_name= "__driver-cbc-serpent-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -349,7 +351,8 @@ static struct crypto_alg srp_algs[10] = { {
.cra_name = "__ctr-serpent-avx2",
.cra_driver_name= "__driver-ctr-serpent-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -370,7 +373,8 @@ static struct crypto_alg srp_algs[10] = { {
.cra_name = "__lrw-serpent-avx2",
.cra_driver_name= "__driver-lrw-serpent-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_lrw_ctx),
.cra_alignmask = 0,
@@ -394,7 +398,8 @@ static struct crypto_alg srp_algs[10] = { {
.cra_name = "__xts-serpent-avx2",
.cra_driver_name= "__driver-xts-serpent-avx2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/20] crypto: mark Serpent AVX helper ciphers
Flag all Serpent AVX helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/serpent_avx_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/serpent_avx_glue.c
b/arch/x86/crypto/serpent_avx_glue.c
index 7e21739..c8d478a 100644
--- a/arch/x86/crypto/serpent_avx_glue.c
+++ b/arch/x86/crypto/serpent_avx_glue.c
@@ -378,7 +378,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__ecb-serpent-avx",
.cra_driver_name= "__driver-ecb-serpent-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -397,7 +398,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__cbc-serpent-avx",
.cra_driver_name= "__driver-cbc-serpent-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -416,7 +418,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__ctr-serpent-avx",
.cra_driver_name= "__driver-ctr-serpent-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -436,7 +439,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__lrw-serpent-avx",
.cra_driver_name= "__driver-lrw-serpent-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_lrw_ctx),
.cra_alignmask = 0,
@@ -459,7 +463,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__xts-serpent-avx",
.cra_driver_name= "__driver-xts-serpent-avx",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/20] crypto: cryptd to process CRYPTO_ALG_INTERNAL
The cryptd is used as a wrapper around internal ciphers. Therefore, the
cryptd must process the internal cipher by marking cryptd as internal if
the underlying cipher is an internal cipher.
Signed-off-by: Stephan Mueller
---
crypto/ablk_helper.c | 3 ++-
crypto/cryptd.c | 49 +
2 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/crypto/ablk_helper.c b/crypto/ablk_helper.c
index ffe7278..e1fcf53 100644
--- a/crypto/ablk_helper.c
+++ b/crypto/ablk_helper.c
@@ -124,7 +124,8 @@ int ablk_init_common(struct crypto_tfm *tfm, const char
*drv_name)
struct async_helper_ctx *ctx = crypto_tfm_ctx(tfm);
struct cryptd_ablkcipher *cryptd_tfm;
- cryptd_tfm = cryptd_alloc_ablkcipher(drv_name, 0, 0);
+ cryptd_tfm = cryptd_alloc_ablkcipher(drv_name, CRYPTO_ALG_INTERNAL,
+CRYPTO_ALG_INTERNAL);
if (IS_ERR(cryptd_tfm))
return PTR_ERR(cryptd_tfm);
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 650afac1..b0602ba 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -168,6 +168,20 @@ static inline struct cryptd_queue *cryptd_get_queue(struct
crypto_tfm *tfm)
return ictx->queue;
}
+static inline void cryptd_check_internal(struct rtattr **tb, u32 *type,
+u32 *mask)
+{
+ struct crypto_attr_type *algt;
+
+ algt = crypto_get_attr_type(tb);
+ if (IS_ERR(algt))
+ return;
+ if ((algt->type & CRYPTO_ALG_INTERNAL))
+ *type |= CRYPTO_ALG_INTERNAL;
+ if ((algt->mask & CRYPTO_ALG_INTERNAL))
+ *mask |= CRYPTO_ALG_INTERNAL;
+}
+
static int cryptd_blkcipher_setkey(struct crypto_ablkcipher *parent,
const u8 *key, unsigned int keylen)
{
@@ -321,10 +335,13 @@ static int cryptd_create_blkcipher(struct crypto_template
*tmpl,
struct cryptd_instance_ctx *ctx;
struct crypto_instance *inst;
struct crypto_alg *alg;
+ u32 type = CRYPTO_ALG_TYPE_BLKCIPHER;
+ u32 mask = CRYPTO_ALG_TYPE_MASK;
int err;
- alg = crypto_get_attr_alg(tb, CRYPTO_ALG_TYPE_BLKCIPHER,
- CRYPTO_ALG_TYPE_MASK);
+ cryptd_check_internal(tb, , );
+
+ alg = crypto_get_attr_alg(tb, type, mask);
if (IS_ERR(alg))
return PTR_ERR(alg);
@@ -341,7 +358,10 @@ static int cryptd_create_blkcipher(struct crypto_template
*tmpl,
if (err)
goto out_free_inst;
- inst->alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ type = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+ if (alg->cra_flags & CRYPTO_ALG_INTERNAL)
+ type |= CRYPTO_ALG_INTERNAL;
+ inst->alg.cra_flags = type;
inst->alg.cra_type = _ablkcipher_type;
inst->alg.cra_ablkcipher.ivsize = alg->cra_blkcipher.ivsize;
@@ -577,9 +597,13 @@ static int cryptd_create_hash(struct crypto_template
*tmpl, struct rtattr **tb,
struct ahash_instance *inst;
struct shash_alg *salg;
struct crypto_alg *alg;
+ u32 type = 0;
+ u32 mask = 0;
int err;
- salg = shash_attr_alg(tb[1], 0, 0);
+ cryptd_check_internal(tb, , );
+
+ salg = shash_attr_alg(tb[1], type, mask);
if (IS_ERR(salg))
return PTR_ERR(salg);
@@ -598,7 +622,10 @@ static int cryptd_create_hash(struct crypto_template
*tmpl, struct rtattr **tb,
if (err)
goto out_free_inst;
- inst->alg.halg.base.cra_flags = CRYPTO_ALG_ASYNC;
+ type = CRYPTO_ALG_ASYNC;
+ if (alg->cra_flags & CRYPTO_ALG_INTERNAL)
+ type |= CRYPTO_ALG_INTERNAL;
+ inst->alg.halg.base.cra_flags = type;
inst->alg.halg.digestsize = salg->digestsize;
inst->alg.halg.base.cra_ctxsize = sizeof(struct cryptd_hash_ctx);
@@ -719,10 +746,13 @@ static int cryptd_create_aead(struct crypto_template
*tmpl,
struct aead_instance_ctx *ctx;
struct crypto_instance *inst;
struct crypto_alg *alg;
+ u32 type = CRYPTO_ALG_TYPE_AEAD;
+ u32 mask = CRYPTO_ALG_TYPE_MASK;
int err;
- alg = crypto_get_attr_alg(tb, CRYPTO_ALG_TYPE_AEAD,
- CRYPTO_ALG_TYPE_MASK);
+ cryptd_check_internal(tb, , );
+
+ alg = crypto_get_attr_alg(tb, type, mask);
if (IS_ERR(alg))
return PTR_ERR(alg);
@@ -739,7 +769,10 @@ static int cryptd_create_aead(struct crypto_template *tmpl,
if (err)
goto out_free_inst;
- inst->alg.cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC;
+ type = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC;
+ if (alg->cra_flags & CRYPTO_ALG_INTERNAL)
+ type |= CRYPTO_ALG_INTERNAL;
+ inst->alg.cra_flags = type;
inst->alg.cra_type = alg->cra_type;
inst->alg.cra_ctxsize =
Re: [PATCH] perf, record: Add clockid parameter
On Fri, Mar 27, 2015 at 1:15 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, Mar 27, 2015 at 11:35:25AM -0600, David Ahern escreveu: >> On 3/27/15 11:20 AM, Peter Zijlstra wrote: >> >>This is a new feature which means use_clockid on older kernels will fail. >> >>So >> >>need to catch that and throw an error -- perhaps yet another probe >> >>function. > >> >How does that work? What do I grep to find an example? I figured if the >> >kernel didn't support the syscall will fail and we'll terminate >> >someplace. > >> Look at __perf_evsel__open(). In this case you probably do not want >> to fallback but tell the user the clock id option is not supported. >> The problem is deciphering the failure is due to the clock id versus >> all the other failure reasons. > > I.e. we're back to the sys_perf_event_open() error reporting suckz rockz > thing, this time with PeterZ trying to find a way to avoid getting back > to that discussion... /me runz... ;-P > Why not have the kernel advertise the perf capabilities (in procfs or sysfs) instead this guessing game with the return values? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/20] crypto: mark Serpent SSE2 helper ciphers
Flag all Serpent SSE2 helper ciphers as internal ciphers to prevent
them from being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/serpent_sse2_glue.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/serpent_sse2_glue.c
b/arch/x86/crypto/serpent_sse2_glue.c
index bf025ad..3643dd5 100644
--- a/arch/x86/crypto/serpent_sse2_glue.c
+++ b/arch/x86/crypto/serpent_sse2_glue.c
@@ -387,7 +387,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__ecb-serpent-sse2",
.cra_driver_name= "__driver-ecb-serpent-sse2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -406,7 +407,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__cbc-serpent-sse2",
.cra_driver_name= "__driver-cbc-serpent-sse2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -425,7 +427,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__ctr-serpent-sse2",
.cra_driver_name= "__driver-ctr-serpent-sse2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct serpent_ctx),
.cra_alignmask = 0,
@@ -445,7 +448,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__lrw-serpent-sse2",
.cra_driver_name= "__driver-lrw-serpent-sse2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_lrw_ctx),
.cra_alignmask = 0,
@@ -468,7 +472,8 @@ static struct crypto_alg serpent_algs[10] = { {
.cra_name = "__xts-serpent-sse2",
.cra_driver_name= "__driver-xts-serpent-sse2",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = SERPENT_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct serpent_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/20] crypto: mark AES-NI helper ciphers
Flag all AES-NI helper ciphers as internal ciphers to prevent them from
being called by normal users.
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/aesni-intel_glue.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 6893f49..f9a78f3 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -797,7 +797,9 @@ static int rfc4106_init(struct crypto_tfm *tfm)
PTR_ALIGN((u8 *)crypto_tfm_ctx(tfm), AESNI_ALIGN);
struct crypto_aead *cryptd_child;
struct aesni_rfc4106_gcm_ctx *child_ctx;
- cryptd_tfm = cryptd_alloc_aead("__driver-gcm-aes-aesni", 0, 0);
+ cryptd_tfm = cryptd_alloc_aead("__driver-gcm-aes-aesni",
+ CRYPTO_ALG_INTERNAL,
+ CRYPTO_ALG_INTERNAL);
if (IS_ERR(cryptd_tfm))
return PTR_ERR(cryptd_tfm);
@@ -1262,7 +1264,7 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__aes-aesni",
.cra_driver_name= "__driver-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER | CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx) +
AESNI_ALIGN - 1,
@@ -1281,7 +1283,8 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__ecb-aes-aesni",
.cra_driver_name= "__driver-ecb-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx) +
AESNI_ALIGN - 1,
@@ -1301,7 +1304,8 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__cbc-aes-aesni",
.cra_driver_name= "__driver-cbc-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct crypto_aes_ctx) +
AESNI_ALIGN - 1,
@@ -1365,7 +1369,8 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__ctr-aes-aesni",
.cra_driver_name= "__driver-ctr-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct crypto_aes_ctx) +
AESNI_ALIGN - 1,
@@ -1409,7 +1414,7 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__gcm-aes-aesni",
.cra_driver_name= "__driver-gcm-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_AEAD,
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_INTERNAL,
.cra_blocksize = 1,
.cra_ctxsize= sizeof(struct aesni_rfc4106_gcm_ctx) +
AESNI_ALIGN,
@@ -1479,7 +1484,8 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__lrw-aes-aesni",
.cra_driver_name= "__driver-lrw-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct aesni_lrw_ctx),
.cra_alignmask = 0,
@@ -1500,7 +1506,8 @@ static struct crypto_alg aesni_algs[] = { {
.cra_name = "__xts-aes-aesni",
.cra_driver_name= "__driver-xts-aes-aesni",
.cra_priority = 0,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
+ .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ CRYPTO_ALG_INTERNAL,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize= sizeof(struct aesni_xts_ctx),
.cra_alignmask = 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v2 02/20] crypto: testmgr to use CRYPTO_ALG_INTERNAL
If a cipher allocation fails with -ENOENT, the testmgr now retries
to allocate the cipher with CRYPTO_ALG_INTERNAL flag.
As all ciphers, including the internal ciphers will be processed by
the testmgr, it needs to be able to allocate those ciphers.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 1f879ad..609bafa 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1506,6 +1506,9 @@ static int alg_test_aead(const struct alg_test_desc
*desc, const char *driver,
int err = 0;
tfm = crypto_alloc_aead(driver, type, mask);
+ if (PTR_ERR(tfm) == -ENOENT)
+ tfm = crypto_alloc_aead(driver, type | CRYPTO_ALG_INTERNAL,
+ mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(tfm)) {
printk(KERN_ERR "alg: aead: Failed to load transform for %s: "
"%ld\n", driver, PTR_ERR(tfm));
@@ -1535,6 +1538,9 @@ static int alg_test_cipher(const struct alg_test_desc
*desc,
int err = 0;
tfm = crypto_alloc_cipher(driver, type, mask);
+ if (PTR_ERR(tfm) == -ENOENT)
+ tfm = crypto_alloc_cipher(driver, type | CRYPTO_ALG_INTERNAL,
+ mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(tfm)) {
printk(KERN_ERR "alg: cipher: Failed to load transform for "
"%s: %ld\n", driver, PTR_ERR(tfm));
@@ -1564,6 +1570,10 @@ static int alg_test_skcipher(const struct alg_test_desc
*desc,
int err = 0;
tfm = crypto_alloc_ablkcipher(driver, type, mask);
+ if (PTR_ERR(tfm) == -ENOENT)
+ tfm = crypto_alloc_ablkcipher(driver,
+ type | CRYPTO_ALG_INTERNAL,
+ mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(tfm)) {
printk(KERN_ERR "alg: skcipher: Failed to load transform for "
"%s: %ld\n", driver, PTR_ERR(tfm));
@@ -1637,6 +1647,9 @@ static int alg_test_hash(const struct alg_test_desc
*desc, const char *driver,
int err;
tfm = crypto_alloc_ahash(driver, type, mask);
+ if (PTR_ERR(tfm) == -ENOENT)
+ tfm = crypto_alloc_ahash(driver, type | CRYPTO_ALG_INTERNAL,
+mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(tfm)) {
printk(KERN_ERR "alg: hash: Failed to load transform for %s: "
"%ld\n", driver, PTR_ERR(tfm));
@@ -1665,6 +1678,9 @@ static int alg_test_crc32c(const struct alg_test_desc
*desc,
goto out;
tfm = crypto_alloc_shash(driver, type, mask);
+ if (PTR_ERR(tfm) == -ENOENT)
+ tfm = crypto_alloc_shash(driver, type | CRYPTO_ALG_INTERNAL,
+mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(tfm)) {
printk(KERN_ERR "alg: crc32c: Failed to load transform for %s: "
"%ld\n", driver, PTR_ERR(tfm));
@@ -1707,6 +1723,9 @@ static int alg_test_cprng(const struct alg_test_desc
*desc, const char *driver,
int err;
rng = crypto_alloc_rng(driver, type, mask);
+ if (PTR_ERR(rng) == -ENOENT)
+ rng = crypto_alloc_rng(driver, type | CRYPTO_ALG_INTERNAL,
+ mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(rng)) {
printk(KERN_ERR "alg: cprng: Failed to load transform for %s: "
"%ld\n", driver, PTR_ERR(rng));
@@ -1734,6 +1753,9 @@ static int drbg_cavs_test(struct drbg_testvec *test, int
pr,
return -ENOMEM;
drng = crypto_alloc_rng(driver, type, mask);
+ if (PTR_ERR(drng) == -ENOENT)
+ drng = crypto_alloc_rng(driver, type | CRYPTO_ALG_INTERNAL,
+ mask | CRYPTO_ALG_INTERNAL);
if (IS_ERR(drng)) {
printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for "
"%s\n", driver);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/20] crypto: restrict usage of helper ciphers
Hi, Based on the discussion in the thread [1], a flag is added to the kernel crypto API to allow ciphers to be marked as internal. The patch set is tested in FIPS and non-FIPS mode. In addition, the enforcement that the helper cipher of __driver-gcm-aes-aesni cannot be loaded, but the wrapper of rfc4106-gcm-aesni can be used is tested to demonstrate that the patch works. The testing also shows that of__driver-gcm-aes-aesni is subject to the testmgr self test an can therefore be used in FIPS mode. All cipher implementation whose definition has a cra_priority of 0 as well as the ciphers that are wrapped by cryptd and mcryptd are marked as internal ciphers to prevent them from being called by users. The testing also includes the invocation of normal crypto operations from user space via AF_ALG and libkcapi showing that all of them work unaffected. [1] http://comments.gmane.org/gmane.linux.kernel.cryptoapi/13705 Changes v2: * Overhaul enforcement of the internal flag as suggested by Herbert: a cipher marked as internal can only be invoked if the caller instantiates it with the internal flag set in the type and mask field. * The overhaul implies that cryptd and mcryptd instances are marked as internal if the underlying cipher is marked as internal. * The overhaul implies that the testmgr must try to allocate a cipher again with the internal flag in case the first allocation failed with -ENOENT. * Mark internal cipher in arch/x86/crypto/sha-mb/sha1_mb.c. Stephan Mueller (20): crypto: prevent helper ciphers from being used crypto: testmgr to use CRYPTO_ALG_INTERNAL crypto: cryptd to process CRYPTO_ALG_INTERNAL crypto: /proc/crypto: identify internal ciphers crypto: mark AES-NI helper ciphers crypto: mark ghash clmulni helper ciphers crypto: mark GHASH ARMv8 vmull.p64 helper ciphers crypto: mark AES-NI Camellia helper ciphers crypto: mark CAST5 helper ciphers crypto: mark AVX Camellia helper ciphers crypto: mark CAST6 helper ciphers crypto: mark Serpent AVX2 helper ciphers crypto: mark Serpent AVX helper ciphers crypto: mark Serpent SSE2 helper ciphers crypto: mark Twofish AVX helper ciphers crypto: mark NEON bit sliced AES helper ciphers crypto: mark ARMv8 AES helper ciphers crypto: mark 64 bit ARMv8 AES helper ciphers crypto: mcryptd to process CRYPTO_ALG_INTERNAL crypto: mark Multi buffer SHA1 helper cipher arch/arm/crypto/aes-ce-glue.c | 12 +--- arch/arm/crypto/aesbs-glue.c | 9 -- arch/arm/crypto/ghash-ce-glue.c| 6 ++-- arch/arm64/crypto/aes-glue.c | 12 +--- arch/x86/crypto/aesni-intel_glue.c | 23 +- arch/x86/crypto/camellia_aesni_avx2_glue.c | 15 ++--- arch/x86/crypto/camellia_aesni_avx_glue.c | 15 ++--- arch/x86/crypto/cast5_avx_glue.c | 9 -- arch/x86/crypto/cast6_avx_glue.c | 15 ++--- arch/x86/crypto/ghash-clmulni-intel_glue.c | 7 +++-- arch/x86/crypto/serpent_avx2_glue.c| 15 ++--- arch/x86/crypto/serpent_avx_glue.c | 15 ++--- arch/x86/crypto/serpent_sse2_glue.c| 15 ++--- arch/x86/crypto/sha-mb/sha1_mb.c | 7 +++-- arch/x86/crypto/twofish_avx_glue.c | 15 ++--- crypto/ablk_helper.c | 3 +- crypto/api.c | 6 crypto/cryptd.c| 49 +- crypto/mcryptd.c | 25 +-- crypto/proc.c | 3 ++ crypto/testmgr.c | 22 ++ include/linux/crypto.h | 6 22 files changed, 230 insertions(+), 74 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/20] crypto: /proc/crypto: identify internal ciphers
With ciphers that now cannot be accessed via the kernel crypto API,
callers shall be able to identify the ciphers that are not callable. The
/proc/crypto file is added a boolean field identifying that such
internal ciphers.
Signed-off-by: Stephan Mueller
---
crypto/proc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/proc.c b/crypto/proc.c
index 4a0a7aa..4ffe73b 100644
--- a/crypto/proc.c
+++ b/crypto/proc.c
@@ -89,6 +89,9 @@ static int c_show(struct seq_file *m, void *p)
seq_printf(m, "selftest : %s\n",
(alg->cra_flags & CRYPTO_ALG_TESTED) ?
"passed" : "unknown");
+ seq_printf(m, "internal : %s\n",
+ (alg->cra_flags & CRYPTO_ALG_INTERNAL) ?
+ "yes" : "no");
if (alg->cra_flags & CRYPTO_ALG_LARVAL) {
seq_printf(m, "type : larval\n");
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/20] crypto: prevent helper ciphers from being used
Several hardware related cipher implementations are implemented as follows: a "helper" cipher implementation is registered with the kernel crypto API. Such helper ciphers are never intended to be called by normal users. In some cases, calling them via the normal crypto API may even cause failures including kernel crashes. In a normal case, the "wrapping" ciphers that use the helpers ensure that these helpers are invoked such that they cannot cause any calamity. Considering the AF_ALG user space interface, unprivileged users can call all ciphers registered with the crypto API, including these helper ciphers that are not intended to be called directly. That means, with AF_ALG user space may invoke these helper ciphers and may cause undefined states or side effects. To avoid any potential side effects with such helpers, the patch prevents the helpers to be called directly. A new cipher type flag is added: CRYPTO_ALG_INTERNAL. This flag shall be used to mark helper ciphers. These ciphers can only be used if the caller invoke the cipher with CRYPTO_ALG_INTERNAL in the type and mask field. Signed-off-by: Stephan Mueller --- crypto/api.c | 6 ++ include/linux/crypto.h | 6 ++ 2 files changed, 12 insertions(+) diff --git a/crypto/api.c b/crypto/api.c index 2a81e98..e45d37a 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -257,6 +257,12 @@ struct crypto_alg *crypto_alg_mod_lookup(const char *name, u32 type, u32 mask) mask |= CRYPTO_ALG_TESTED; } + /* +* If the internal flag is set for a cipher, require a caller to +* to invoke the cipher with the internal flag to use that cipher. +*/ + mask |= CRYPTO_ALG_INTERNAL; + larval = crypto_larval_lookup(name, type, mask); if (IS_ERR(larval) || !crypto_is_larval(larval)) return larval; diff --git a/include/linux/crypto.h b/include/linux/crypto.h index fb5ef16..10df5d2 100644 --- a/include/linux/crypto.h +++ b/include/linux/crypto.h @@ -95,6 +95,12 @@ #define CRYPTO_ALG_KERN_DRIVER_ONLY0x1000 /* + * Mark a cipher as a service implementation only usable by another + * cipher and never by a normal user of the kernel crypto API + */ +#define CRYPTO_ALG_INTERNAL0x2000 + +/* * Transform masks and values (for crt_flags). */ #define CRYPTO_TFM_REQ_MASK0x000fff00 -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote: > On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: > >> On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez > >> wrote: > >> > On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: > >> >> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez > >> >> wrote: > >> >> > From: "Luis R. Rodriguez" > >> >> > > >> >> > Ideally on systems using PAT we can expect a swift > >> >> > transition away from MTRR. There can be a few exceptions > >> >> > to this, one is where device drivers are known to exist > >> >> > on PATs with errata, another situation is observed on > >> >> > old device drivers where devices had combined MMIO > >> >> > register access with whatever area they typically > >> >> > later wanted to end up using MTRR for on the same > >> >> > PCI BAR. This situation can still be addressed by > >> >> > splitting up ioremap'd PCI BAR into two ioremap'd > >> >> > calls, one for MMIO registers, and another for whatever > >> >> > is desirable for write-combining -- in order to > >> >> > accomplish this though quite a bit of driver > >> >> > restructuring is required. > >> >> > > >> >> > Device drivers which are known to require large > >> >> > amount of re-work in order to split ioremap'd areas > >> >> > can use __arch_phys_wc_add() to avoid regressions > >> >> > when PAT is enabled. > >> >> > > >> >> > For a good example driver where things are neatly > >> >> > split up on a PCI BAR refer the infiniband qib > >> >> > driver. For a good example of a driver where good > >> >> > amount of work is required refer to the infiniband > >> >> > ipath driver. > >> >> > > >> >> > This is *only* a transitive API -- and as such no new > >> >> > drivers are ever expected to use this. > >> >> > >> >> What's the exact layout that this helps? I'm sceptical that this can > >> >> ever be correct. > >> >> > >> >> Is there some awful driver that has a large ioremap that's supposed to > >> >> contain multiple different memtypes? > >> > > >> > Yes, I cc'd you just now on one where I made changes on a driver which > >> > uses one > >> > PCI with mixed memtypes and uses MTRR to hole in WC. A transition to > >> > arch_phys_wc_add() is therefore not possible if PAT is enabled as it > >> > would > >> > regress those drivers by making the MTRR WC hole trick non functional. > >> > The changes are non trivial and so in this series I supplied changes on > >> > one driver only to show the effort required. The other drivers which > >> > required this were: > >> > > >> > Driver File > >> > > >> > fusion drivers/message/fusion/mptbase.c > >> > ivtvdrivers/media/pci/ivtv/ivtvfb.c > >> > ipath drivers/infiniband/hw/ipath/ipath_driver.c > >> > > >> > This series makes those drivers use __arch_phys_wc_add() more as a > >> > transitory phase in hopes we can address the proper split as with the > >> > atyfb illustrates. For ipath the changes required have a nice template > >> > with the qib driver as they share very similar driver structure, the > >> > qib driver *did* do the nice split. > >> > > >> >> If so, can we ioremap + set_page_xyz instead? > >> > > >> > I'm not sure I see which call we'd use. Care to provide an example patch > >> > alternative for the atyfb as a case in point alternative to the work > >> > required > >> > to do the split? > >> > > >> > >> I'm still confused. Would it be insufficient to ioremap_nocache the > >> whole thing and then call set_memory_wc on parts of it? (Sorry, > >> set_page_xyz was a typo.) > > > > I think that would be a sexy alternative. > > > > In this driver's case the thing is a bit messy as it not only used > > the WC MTRR for a hole but it also then used a UC MTRR on top of > > it all, so since I already tried to address the split, and if we address > > the power of 2 woes, I think it'd be best to try to remove the UC MTRR > > and just avoid set_page_wc() in this driver's case, but for the other cases > > (fusion, ivtv, ipath) I think this makes sense. > > > > Thoughts? > > Once that WC MTRR is in place, I think you really need UC and not UC- > if you want to override it. Otherwise I agree with all of this. Do you mean that the UC MTRR work around that was in place might not have really been effective? Not quite sure what you mean. I don't think I follow. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] perf tui: Annotate entries in callchains
On Mon, Mar 23, 2015 at 9:56 AM, Arnaldo Carvalho de Melo wrote: > > > Le 23 mars 2015 13:49:24 GMT-03:00, Stephane Eranian a > écrit : >>On Sun, Mar 22, 2015 at 5:27 PM, Namhyung Kim >>wrote:(). >>> >>> Did you play with acme/perf/core not tip/perf/core? I got same >>> problem but then I realize it's not the Arnaldo's tree. When I >>> changed to acme/perf/core the problem disappeared. :) >>> >>I was only trying it with tip.git. The patch looke simple enough to >>apply >>to tip.git but clearly it relies on some other infrastructure changes >>which >>I don't know about. In my case =, I care about getting this feature in >>tip.git >>or older versions of perf. > > It is all in tip.git by now. > >>> But unfortunately I got this segfault instead.. > > Needs a patch that is in perf/urgent > If I pull tip.git now. Does it have what is needed to work? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[net] Intel Wired LAN Driver Updates
The veil has been lifted... No more having patches submitted against Intel wired Ethernet drivers to be applied to a mysterious queue and not knowing what the status or how many patches are in the queue. We have created a new mailing list (intel-wired-...@lists.osuosl.org) for all Linux kernel patches and kernel development, which anyone can subscribe to. Also we have a public patchwork project on patchwork.ozlabs.org, where all the patches reside and their current status. This change was made on part of the multiple requests for the community and to also benefit from the various community testers. Developers may also notice we have removed e1000-de...@lists.sourceforge.net and the linux.n...@intel.com mailing lists from the MAINTAINERS file. These mailing lists are not going away, their removal is an attempt to focus their usage for their intended purpose. The e1000-de...@lists.sourceforge.net mailing list will be used only for our out-of-tree driver work and linux.n...@intel.com customer issues and related work. We had a "soft opening" March 24th, but now we are "officially" open publicly for business. :-)` The following are changes since commit dde93dfea53c72b07907d9e44a6e4b1545f6bdc4: cxgb4: Fix frame size warning for 32 bit arch and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master Jeff Kirsher (1): MAINTAINERS: Update Intel Wired Ethernet Driver info MAINTAINERS | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ocfs2-devel] [PATCH 2/2] ocfs2: Neaten do_error, ocfs2_error and ocfs2_abort
On Fri, 2015-03-27 at 15:16 -0700, Andrew Morton wrote: > On Thu, 26 Mar 2015 20:07:08 -0700 Joe Perches wrote: > > > These uses sometimes do and sometimes don't have '\n' terminations. > > Make the uses consistently use '\n' terminations and remove the > > newline from the functions. > > This is going to take a while to merge, as it's backed up behind a pile > of needs-more-reviewing ocfs2 patches. Thanks, no worries, this one's a trivial neatening patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[net] MAINTAINERS: Update Intel Wired Ethernet Driver info
Update the git tree info with a recent change in tree names. Also add our new mailing list created solely for Linux kernel patches and kernel development, as well as the new patchwork project for tracking patches. Lastly update the list of "reviewers" since a couple of developers have moved on to different projects. Made an update to the section header so that it is more manageable going forward as we add new drivers. Signed-off-by: Jeff Kirsher --- MAINTAINERS | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 358eb01..9508870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5128,22 +5128,21 @@ M: Deepak Saxena S: Maintained F: drivers/char/hw_random/ixp4xx-rng.c -INTEL ETHERNET DRIVERS (e100/e1000/e1000e/fm10k/igb/igbvf/ixgb/ixgbe/ixgbevf/i40e/i40evf) +INTEL ETHERNET DRIVERS M: Jeff Kirsher -M: Jesse Brandeburg -M: Bruce Allan -M: Carolyn Wyborny -M: Don Skidmore -M: Greg Rose -M: Matthew Vick -M: John Ronciak -M: Mitch Williams -M: Linux NICS -L: e1000-de...@lists.sourceforge.net +R: Jesse Brandeburg +R: Shannon Nelson +R: Carolyn Wyborny +R: Don Skidmore +R: Matthew Vick +R: John Ronciak +R: Mitch Williams +L: intel-wired-...@lists.osuosl.org W: http://www.intel.com/support/feedback.htm W: http://e1000.sourceforge.net/ -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git +Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git S: Supported F: Documentation/networking/e100.txt F: Documentation/networking/e1000.txt -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] net/macb: fix capabilities configuration
Hi Nicolas, On Fri, 27 Mar 2015 16:34:11 +0100 Nicolas Ferre wrote: > Capabilities configuration by macb_configure_caps() was moved far too late by > 421d9df0628b (net/macb: merge at91_ether driver into macb driver) which would > lead to badly configured hardware. Indeed, the macb_configure_caps function is called a bit too late, but ... > So, move this function to early probe and modify its prototype to re-gain its > original behavior. > DT data retrieval is also moved to simplify the probe code flow. ... I'm not happy with these changes. I tried to keep specific init steps of macb and at91_ether separated and you're moving macb_configure_caps call (not required on at91_ether HW) into macb_probe (the common probe part). How about moving macb_configure_caps a bit earlier in the macb_init function [1] ? Best Regards, Boris [1]http://code.bulix.org/8gyi6b-88141 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] kselftest: Add exit code defines
On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
> Define the exit codes with KSFT_PASS and similar so tests can use these
> directly if they choose. Also enable harnesses and other tooling to use
> the defines instead of hardcoding the return codes.
+1
> diff --git a/tools/testing/selftests/kselftest.h
> b/tools/testing/selftests/kselftest.h
> index 572c888..ef1c80d 100644
> --- a/tools/testing/selftests/kselftest.h
> +++ b/tools/testing/selftests/kselftest.h
> @@ -13,6 +13,13 @@
> #include
> #include
>
> +/* define kselftest exit codes */
> +#define KSFT_PASS 0
> +#define KSFT_FAIL 1
> +#define KSFT_XFAIL 2
> +#define KSFT_XPASS 3
> +#define KSFT_SKIP 4
> +
> /* counters */
> struct ksft_count {
> unsigned int ksft_pass;
> @@ -40,23 +47,23 @@ static inline void ksft_print_cnts(void)
>
> static inline int ksft_exit_pass(void)
> {
> - exit(0);
> + exit(KSFT_PASS);
> }
Am I the only person who's bothered by the fact that these don't actually
return int?
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: d63e2e1f3df breaks sparc/T5-8
On Fri, Mar 27, 2015 at 2:50 PM, David Miller wrote: > All DMA occurs behind an IOMMU and these IOMMUs only > support 32-bit addressing, therefore dma_addr_t is > 32-bit on sparc64. > > If you want to represent PCI address in some way, you > absolutely cannot use dma_addr_t as your data type. Oh no, we missed that for a while. Hi Bjorn, I would suggest that we introduce pci_bus_addr_t or pci_addr_t. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs: show locked and lock_ro options in mountinfo
Hi! Am 27.03.2015 um 23:35 schrieb Andrey Wagin: > 2015-03-28 0:42 GMT+03:00 Richard Weinberger : >> On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin wrote: >>> I don't see any reasons to hide them. This information can help to >>> understand errors. >> >> Because these flags are set/read only internally by the VFS. In contrast >> to the other flags shown by mountinfo MNT_LOCKED is not a mount option. > > But this flag is set as a result of the specified user action, when he > unshares userns and mntns. This flag affects visiable behaviour. It is a implicit result. Used by the VFS internally. If you expose it it becomes ABI and changing the behavior will be tricky or impossible. >> >> Why does it help to debug errors? >> How would a user know that mount() with MS_BIND returns EINVAL because >> the mount source is MNT_LOCKED? This information is useless for her. > > If I see lock_ro, I can be sure that mount -o remount,bind,rw /XXX will fail. > If I see locked, I know that this mount can't be umounted or moved > and can be bind-mounted only recursively. > > If a user see these flags, he can check that a mount namespace is > configured correctly without security issues. > > Sorry but I don't understand why you think that this information is > useless for users. You can only know if you know how the VFS works internally. If know that EINVAL from mount(2) with MS_BIND can be caused by MNT_LOCKED because I know the source. I bet you know the source too. But not Joey random admin who looks into mountinfo to figure out why something does not work. If you expose MNT_LOCKED to userspace you'll have to update also the mount(2) manpage with all glory details of that flag. >> If you argue like that you'd have to expose the whole VFS state to userland. > > I have not noticed other MNT_LOCK_* flags. I should think more about > what information are a really required for dumping mount namespaces. > >> >>> And this information is required for correct checkpoint/restore of mount >>> namespaces. >> >> Why especially MNT_LOCKED and not all the other flags used by VFS? > > My goal is to dump enough information about a mount namespace to be > able to restore it back later. I don't know how to do this without > knowledge about locked mounts. I will think. How do you plan to restore a MNT_LOCKED mount? IIRC we have currently no way to directly set MNT_LOCKED from userspace. >> Say MNT_DOOMED? > > Mounts with MNT_DOOMED are never shown in mountinfo, are they? It was just an example. There are other flags too, did you double check which ones you really need? To make the story short, my concern is that exposing such flags to userspace has to be well thought. :-) As long they are just internal we can change them as we like, as soon userspace depends somehow on it the pain begins. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf, record: Add clockid parameter
Em Fri, Mar 27, 2015 at 11:35:25AM -0600, David Ahern escreveu: > On 3/27/15 11:20 AM, Peter Zijlstra wrote: > >>This is a new feature which means use_clockid on older kernels will fail. So > >>need to catch that and throw an error -- perhaps yet another probe function. > >How does that work? What do I grep to find an example? I figured if the > >kernel didn't support the syscall will fail and we'll terminate > >someplace. > Look at __perf_evsel__open(). In this case you probably do not want > to fallback but tell the user the clock id option is not supported. > The problem is deciphering the failure is due to the clock id versus > all the other failure reasons. I.e. we're back to the sys_perf_event_open() error reporting suckz rockz thing, this time with PeterZ trying to find a way to avoid getting back to that discussion... /me runz... ;-P - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] usbvision: fix leak of usb_dev on failure paths in usbvision_probe()
There is no usb_put_dev() on failure paths in usbvision_probe().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/usb/usbvision/usbvision-video.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/usbvision/usbvision-video.c
b/drivers/media/usb/usbvision/usbvision-video.c
index cd2fbf11e3b4..239d0e0ca087 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1525,7 +1525,7 @@ static int usbvision_probe(struct usb_interface *intf,
const struct usb_host_interface *interface;
struct usb_usbvision *usbvision = NULL;
const struct usb_endpoint_descriptor *endpoint;
- int model, i;
+ int model, i, ret;
PDEBUG(DBG_PROBE, "VID=%#04x, PID=%#04x, ifnum=%u",
dev->descriptor.idVendor,
@@ -1534,7 +1534,8 @@ static int usbvision_probe(struct usb_interface *intf,
model = devid->driver_info;
if (model < 0 || model >= usbvision_device_data_size) {
PDEBUG(DBG_PROBE, "model out of bounds %d", model);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_usb;
}
printk(KERN_INFO "%s: %s found\n", __func__,
usbvision_device_data[model].model_string);
@@ -1549,18 +1550,21 @@ static int usbvision_probe(struct usb_interface *intf,
__func__, ifnum);
dev_err(>dev, "%s: Endpoint attributes %d",
__func__, endpoint->bmAttributes);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_usb;
}
if (usb_endpoint_dir_out(endpoint)) {
dev_err(>dev, "%s: interface %d. has ISO OUT endpoint!\n",
__func__, ifnum);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_usb;
}
usbvision = usbvision_alloc(dev, intf);
if (usbvision == NULL) {
dev_err(>dev, "%s: couldn't allocate USBVision struct\n",
__func__);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_usb;
}
if (dev->descriptor.bNumConfigurations > 1)
@@ -1579,8 +1583,8 @@ static int usbvision_probe(struct usb_interface *intf,
usbvision->alt_max_pkt_size = kmalloc(32 * usbvision->num_alt,
GFP_KERNEL);
if (usbvision->alt_max_pkt_size == NULL) {
dev_err(>dev, "usbvision: out of memory!\n");
- usbvision_release(usbvision);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_pkt;
}
for (i = 0; i < usbvision->num_alt; i++) {
@@ -1615,6 +1619,12 @@ static int usbvision_probe(struct usb_interface *intf,
PDEBUG(DBG_PROBE, "success");
return 0;
+
+err_pkt:
+ usbvision_release(usbvision);
+err_usb:
+ usb_put_dev(dev);
+ return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf, record: Add clockid parameter
On Fri, Mar 27, 2015 at 2:59 PM, Peter Zijlstra wrote:
> On Fri, Mar 27, 2015 at 05:15:34PM -0300, Arnaldo Carvalho de Melo wrote:
>> I.e. we're back to the sys_perf_event_open() error reporting suckz rockz
>> thing, this time with PeterZ trying to find a way to avoid getting back
>> to that discussion... /me runz... ;-P
>
> :-)
>
> Not entirely, its just that I've not seen this userspace code in years
> and I'm pretty clueless.
>
> How about so then?
>
> ---
> Subject: perf, record: Add clockid parameter
> From: Peter Zijlstra
> Date: Fri, 27 Mar 2015 15:32:01 +0100
>
> Teach perf-record about the new perf_event_attr::{use_clockid, clockid}
> fields. Add a simple parameter to set the clock (if any) to be used for
> the events to be recorded into the data file.
>
> Since we store the entire perf_event_attr in the EVENT_DESC section we
> also already store the used clockid in the data file.
>
> Cc: a...@redhat.com
> Signed-off-by: Peter Zijlstra (Intel)
> ---
>
> tools/perf/Documentation/perf-record.txt |5 +++
> tools/perf/builtin-record.c |3 ++
> tools/perf/perf.h|1
> tools/perf/util/evsel.c | 44
> ---
> 4 files changed, 49 insertions(+), 4 deletions(-)
>
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -250,6 +250,11 @@ is off by default.
> --running-time::
> Record running and enabled time for read events (:S)
>
> +-k::
> +--clockid::
> +Sets the clock id to use for the various time fields in the perf_event_type
> +records. See clock_gettime().
> +
> SEE ALSO
>
> linkperf:perf-stat[1], linkperf:perf-list[1]
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -739,6 +739,7 @@ static struct record record = {
> .uses_mmap = true,
> .default_per_cpu = true,
> },
> + .clockid = -1,
> },
> .tool = {
> .sample = process_sample_event,
> @@ -842,6 +843,8 @@ struct option __record_options[] = {
> "Sample machine registers on interrupt"),
> OPT_BOOLEAN(0, "running-time", _time,
> "Record running/enabled time of read (:S) events"),
> + OPT_INTEGER('k', "clockid", ,
> + "clockid to use for events"),
I think you'd want a symbolic name for the clock to make this easier
on the user.
> OPT_END()
> };
>
> --- a/tools/perf/perf.h
> +++ b/tools/perf/perf.h
> @@ -62,6 +62,7 @@ struct record_opts {
> u64 user_interval;
> bool sample_transaction;
> unsigned initial_delay;
> + clockid_tclockid;
> };
>
> struct option;
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -32,6 +32,7 @@ static struct {
> bool exclude_guest;
> bool mmap2;
> bool cloexec;
> + bool clockid;
> } perf_missing_features;
>
> static int perf_evsel__no_extra_init(struct perf_evsel *evsel __maybe_unused)
> @@ -761,6 +762,11 @@ void perf_evsel__config(struct perf_evse
> attr->disabled = 0;
> attr->enable_on_exec = 0;
> }
> +
> + if (opts->clockid >= 0) {
> + attr->use_clockid = 1;
> + attr->clockid = opts->clockid;
> + }
> }
>
> static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int
> nthreads)
> @@ -1036,7 +1042,6 @@ static size_t perf_event_attr__fprintf(s
> ret += PRINT_ATTR2(exclude_user, exclude_kernel);
> ret += PRINT_ATTR2(exclude_hv, exclude_idle);
> ret += PRINT_ATTR2(mmap, comm);
> - ret += PRINT_ATTR2(mmap2, comm_exec);
> ret += PRINT_ATTR2(freq, inherit_stat);
> ret += PRINT_ATTR2(enable_on_exec, task);
> ret += PRINT_ATTR2(watermark, precise_ip);
> @@ -1044,6 +1049,8 @@ static size_t perf_event_attr__fprintf(s
> ret += PRINT_ATTR2(exclude_host, exclude_guest);
> ret += PRINT_ATTR2N("excl.callchain_kern", exclude_callchain_kernel,
> "excl.callchain_user", exclude_callchain_user);
> + ret += PRINT_ATTR2(mmap2, comm_exec);
> + ret += __PRINT_ATTR("%u",,use_clockid);
>
> ret += PRINT_ATTR_U32(wakeup_events);
> ret += PRINT_ATTR_U32(wakeup_watermark);
> @@ -1055,6 +1062,7 @@ static size_t perf_event_attr__fprintf(s
> ret += PRINT_ATTR_X64(branch_sample_type);
> ret += PRINT_ATTR_X64(sample_regs_user);
> ret += PRINT_ATTR_U32(sample_stack_user);
> + ret += PRINT_ATTR_U32(clockid);
> ret += PRINT_ATTR_X64(sample_regs_intr);
>
> ret += fprintf(fp, "%.60s\n", graph_dotted_line);
> @@ -1085,6 +1093,8 @@ static int __perf_evsel__open(struct per
> }
>
> fallback_missing_features:
> + if (perf_missing_features.clockid)
> + evsel->attr.use_clockid = 0;
Re: [PATCH 1/4] net/macb: only probe queues once and use stored values
Hi Nicolas,
On Fri, 27 Mar 2015 16:34:09 +0100
Nicolas Ferre wrote:
> When merging at91_ether and macb driver during 421d9df0628b (net/macb: merge
> at91_ether driver into macb driver) the probe function has been split. The
> code
> dealing with initialization of queues is now moved in macb_init() which needs
> information computed in the parent macb_probe() function.
> So, add the queue_mask information to the private structure and use it when
> needed in macb_init().
Just to be sure: this is not a bug fix, right ?
It just improves the initialization process by calling
macb_probe_queues only once (in macb_probe).
Anyway, once you've addressed Cyrille's comment, you can add my
Acked-by: Boris Brezillon
>
> Signed-off-by: Nicolas Ferre
> Cc: Cyrille Pitchen
> Cc: Boris Brezillon
> ---
> drivers/net/ethernet/cadence/macb.c | 9 -
> drivers/net/ethernet/cadence/macb.h | 1 +
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index a0a04b3638e6..b710768172d9 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2180,7 +2180,7 @@ static void macb_probe_queues(void __iomem *mem,
> static int macb_init(struct platform_device *pdev)
> {
> struct net_device *dev = platform_get_drvdata(pdev);
> - unsigned int hw_q, queue_mask, q, num_queues;
> + unsigned int hw_q, q;
> struct macb *bp = netdev_priv(dev);
> struct macb_queue *queue;
> int err;
> @@ -2226,10 +2226,8 @@ static int macb_init(struct platform_device *pdev)
>* register mapping but we don't want to test the queue index then
>* compute the corresponding register offset at run time.
>*/
> - macb_probe_queues(bp->regs, _mask, _queues);
> -
> - for (hw_q = 0, q = 0; hw_q < MACB_MAX_QUEUES; ++hw_q) {
> - if (!(queue_mask & (1 << hw_q)))
> + for (hw_q = 0, q = 0; hw_q < bp->num_queues; ++hw_q) {
> + if (!(bp->queue_mask & (1 << hw_q)))
> continue;
>
> queue = >queues[q];
> @@ -2715,6 +2713,7 @@ static int macb_probe(struct platform_device *pdev)
> bp->dev = dev;
> bp->regs = mem;
> bp->num_queues = num_queues;
> + bp->queue_mask = queue_mask;
> spin_lock_init(>lock);
>
> platform_set_drvdata(pdev, dev);
> diff --git a/drivers/net/ethernet/cadence/macb.h
> b/drivers/net/ethernet/cadence/macb.h
> index bc6e35c40822..0b6afac91bfe 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -785,6 +785,7 @@ struct macb {
> size_t rx_buffer_size;
>
> unsigned intnum_queues;
> + unsigned intqueue_mask;
> struct macb_queue queues[MACB_MAX_QUEUES];
>
> spinlock_t lock;
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: show locked and lock_ro options in mountinfo
2015-03-28 0:42 GMT+03:00 Richard Weinberger : > On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin wrote: >> I don't see any reasons to hide them. This information can help to >> understand errors. > > Because these flags are set/read only internally by the VFS. In contrast > to the other flags shown by mountinfo MNT_LOCKED is not a mount option. But this flag is set as a result of the specified user action, when he unshares userns and mntns. This flag affects visiable behaviour. > > Why does it help to debug errors? > How would a user know that mount() with MS_BIND returns EINVAL because > the mount source is MNT_LOCKED? This information is useless for her. If I see lock_ro, I can be sure that mount -o remount,bind,rw /XXX will fail. If I see locked, I know that this mount can't be umounted or moved and can be bind-mounted only recursively. If a user see these flags, he can check that a mount namespace is configured correctly without security issues. Sorry but I don't understand why you think that this information is useless for users. > If you argue like that you'd have to expose the whole VFS state to userland. I have not noticed other MNT_LOCK_* flags. I should think more about what information are a really required for dumping mount namespaces. > >> And this information is required for correct checkpoint/restore of mount >> namespaces. > > Why especially MNT_LOCKED and not all the other flags used by VFS? My goal is to dump enough information about a mount namespace to be able to restore it back later. I don't know how to do this without knowledge about locked mounts. I will think. > Say MNT_DOOMED? Mounts with MNT_DOOMED are never shown in mountinfo, are they? Thank you for looking at this patch. > > -- > Thanks, > //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Drivers: hv: hv_balloon: two additional corner cases in balloon_up()
On 03/27/15 17:02, Vitaly Kuznetsov wrote: > PATCH 1/2 addresses a real issue introduced by the 'Drivers: hv: hv_balloon: > refuse to balloon below the floor' fix, > > PATCH 2/2 addresses a currently impossible issue (as Hyper-V host never asks > to balloon more than INT_MAX pages) and is rather a cleanup. The patch is > supposed to be applied on top of previously sent 'Drivers: hv: hv_balloon: > survive ballooning request with num_pages=0'. > > Both issues were found by Laszlo Ersek during code review. > > Vitaly Kuznetsov (2): > Drivers: hv: hv_balloon: correctly handle val.freeram Drivers: hv: hv_balloon: correctly handle num_pages>INT_MAX case > > drivers/hv/hv_balloon.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > series Reviewed-by: Laszlo Ersek Thanks, Vitaly! Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mm: vmscan: do not throttle based on pfmemalloc reserves if node has no reclaimable pages
On 27.03.2015 [13:17:59 -0700], Dave Hansen wrote:
> On 03/27/2015 12:28 PM, Nishanth Aravamudan wrote:
> > @@ -2585,7 +2585,7 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
> >
> > for (i = 0; i <= ZONE_NORMAL; i++) {
> > zone = >node_zones[i];
> > - if (!populated_zone(zone))
> > + if (!populated_zone(zone) || !zone_reclaimable(zone))
> > continue;
> >
> > pfmemalloc_reserve += min_wmark_pages(zone);
>
> Do you really want zone_reclaimable()? Or do you want something more
> direct like "zone_reclaimable_pages(zone) == 0"?
Yeah, I guess in my testing this worked out to be the same, since
zone_reclaimable_pages(zone) is 0 and so zone_reclaimable(zone) will
always be false. Thanks!
Based upon 675becce15 ("mm: vmscan: do not throttle based on pfmemalloc
reserves if node has no ZONE_NORMAL") from Mel.
We have a system with the following topology:
# numactl -H
available: 3 nodes (0,2-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31
node 0 size: 28273 MB
node 0 free: 27323 MB
node 2 cpus:
node 2 size: 16384 MB
node 2 free: 0 MB
node 3 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
node 3 size: 30533 MB
node 3 free: 13273 MB
node distances:
node 0 2 3
0: 10 20 20
2: 20 10 20
3: 20 20 10
Node 2 has no free memory, because:
# cat /sys/devices/system/node/node2/hugepages/hugepages-16777216kB/nr_hugepages
1
This leads to the following zoneinfo:
Node 2, zone DMA
pages free 0
min 1840
low 2300
high 2760
scanned 0
spanned 262144
present 262144
managed 262144
...
all_unreclaimable: 1
If one then attempts to allocate some normal 16M hugepages via
echo 37 > /proc/sys/vm/nr_hugepages
The echo never returns and kswapd2 consumes CPU cycles.
This is because throttle_direct_reclaim ends up calling
wait_event(pfmemalloc_wait, pfmemalloc_watermark_ok...).
pfmemalloc_watermark_ok() in turn checks all zones on the node if there
are any reserves, and if so, then indicates the watermarks are ok, by
seeing if there are sufficient free pages.
675becce15 added a condition already for memoryless nodes. In this case,
though, the node has memory, it is just all consumed (and not
reclaimable). Effectively, though, the result is the same on this call
to pfmemalloc_watermark_ok() and thus seems like a reasonable additional
condition.
With this change, the afore-mentioned 16M hugepage allocation attempt
succeeds and correctly round-robins between Nodes 1 and 3.
Signed-off-by: Nishanth Aravamudan
---
v1 -> v2:
Check against zone_reclaimable_pages, rather zone_reclaimable, based
upon feedback from Dave Hansen.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5e8eadd71bac..c627fa4c991f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2646,7 +2646,8 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
for (i = 0; i <= ZONE_NORMAL; i++) {
zone = >node_zones[i];
- if (!populated_zone(zone))
+ if (!populated_zone(zone) ||
+ zone_reclaimable_pages(zone) == 0)
continue;
pfmemalloc_reserve += min_wmark_pages(zone);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] parisc fixes for v4.0
Hi Linus, Please pull three patches for kernel-4.0 for the parisc architecture from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.0-1 One patch from Mikulas fixes a bug on parisc by artifically incrementing the counter in pmd_free when the kernel tries to free the preallocated pmd. Other than that we now prevent that syscalls gets added without incrementing __NR_Linux_syscalls and fix the initial pmd setup code if a default page size greater than 4k has been selected. Thanks, Helge Helge Deller (2): parisc: Add compile-time check when adding new syscalls parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT Mikulas Patocka (1): parisc: mm: don't count preallocated pmds arch/parisc/include/asm/pgalloc.h | 17 ++--- arch/parisc/kernel/syscall_table.S | 9 ++--- 2 files changed, 16 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] selftest: Add futex tests to the top-level Makefile
Enable futex tests to be built and run with the make kselftest and associated targets. Most of the tests require escalated privileges. These return ERROR, and run.sh continues. Cc: Shuah Khan Cc: linux-...@vger.kernel.org Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Davidlohr Bueso Cc: KOSAKI Motohiro Signed-off-by: Darren Hart --- tools/testing/selftests/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 9af1df2..6eef08a 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -4,6 +4,7 @@ TARGETS += efivarfs TARGETS += exec TARGETS += firmware TARGETS += ftrace +TARGETS += futex TARGETS += kcmp TARGETS += memfd TARGETS += memory-hotplug -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] selftests: Add futex functional tests
The futextest testsuite [1] provides functional, stress, and performance tests for the various futex op codes. Those tests will be of more use to futex developers if they are included with the kernel source. Copy the core infrastructure and the functional tests into selftests. Remove reference to the performance and stress tests from the contributed sources. Remove the Free Software Foundation address paragraph from all contributed files to avoid checkpatch complaints. A future effort will explore moving the performance and stress tests into the kernel. 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git Cc: Shuah Khan Cc: linux-...@vger.kernel.org Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Davidlohr Bueso Cc: KOSAKI Motohiro Signed-off-by: Darren Hart --- tools/testing/selftests/futex/Makefile | 8 + tools/testing/selftests/futex/README | 62 tools/testing/selftests/futex/functional/Makefile | 21 ++ .../selftests/futex/functional/futex_requeue_pi.c | 402 + .../functional/futex_requeue_pi_mismatched_ops.c | 136 +++ .../functional/futex_requeue_pi_signal_restart.c | 220 +++ .../functional/futex_wait_private_mapped_file.c| 126 +++ .../futex/functional/futex_wait_timeout.c | 85 + .../functional/futex_wait_uninitialized_heap.c | 124 +++ .../futex/functional/futex_wait_wouldblock.c | 79 tools/testing/selftests/futex/functional/run.sh| 79 tools/testing/selftests/futex/include/atomic.h | 83 + tools/testing/selftests/futex/include/futextest.h | 266 ++ tools/testing/selftests/futex/include/logging.h| 147 tools/testing/selftests/futex/run.sh | 33 ++ 15 files changed, 1871 insertions(+) create mode 100644 tools/testing/selftests/futex/Makefile create mode 100644 tools/testing/selftests/futex/README create mode 100644 tools/testing/selftests/futex/functional/Makefile create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi.c create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_timeout.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_wouldblock.c create mode 100755 tools/testing/selftests/futex/functional/run.sh create mode 100644 tools/testing/selftests/futex/include/atomic.h create mode 100644 tools/testing/selftests/futex/include/futextest.h create mode 100644 tools/testing/selftests/futex/include/logging.h create mode 100755 tools/testing/selftests/futex/run.sh diff --git a/tools/testing/selftests/futex/Makefile b/tools/testing/selftests/futex/Makefile new file mode 100644 index 000..8629187 --- /dev/null +++ b/tools/testing/selftests/futex/Makefile @@ -0,0 +1,8 @@ +SUBDIRS := functional + +.PHONY: all clean +all: + for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done + +clean: + for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done diff --git a/tools/testing/selftests/futex/README b/tools/testing/selftests/futex/README new file mode 100644 index 000..3224a04 --- /dev/null +++ b/tools/testing/selftests/futex/README @@ -0,0 +1,62 @@ +Futex Test +== +Futex Test is intended to thoroughly test the Linux kernel futex system call +API. + +Functional tests shall test the documented behavior of the futex operation +code under test. This includes checking for proper behavior under normal use, +odd corner cases, regression tests, and abject abuse and misuse. + +Futextest will also provide example implementation of mutual exclusion +primitives. These can be used as is in user applications or can serve as +examples for system libraries. These will likely be added to either a new lib/ +directory or purely as header files under include/, I'm leaning toward the +latter. + +Quick Start +--- +# make +# ./run.sh + +Design and Implementation Goals +--- +o Tests should be as self contained as is practical so as to facilitate sharing + the individual tests on mailing list discussions and bug reports. +o The build system shall remain as simple as possible, avoiding any archive or + shared object building and linking. +o Where possible, any helper functions or other package-wide code shall be + implemented in header files, avoiding the need to compile intermediate object + files. +o External dependendencies shall remain as minimal as possible. Currently gcc + and glibc are the only dependencies. +o Tests return 0 for success and < 0 for failure. + +Output Formatting +- +Test
[PATCH 3/5] selftest/futex: Increment ksft pass and fail counters
Add kselftest.h to logging.h and increment the pass and fail counters as
part of the print_result routine which is called by all futex tests.
Cc: Shuah Khan
Cc: linux-...@vger.kernel.org
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Davidlohr Bueso
Cc: KOSAKI Motohiro
Signed-off-by: Darren Hart
---
tools/testing/selftests/futex/functional/Makefile | 2 +-
tools/testing/selftests/futex/include/logging.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/futex/functional/Makefile
b/tools/testing/selftests/futex/functional/Makefile
index fb96927..e64d43b 100644
--- a/tools/testing/selftests/futex/functional/Makefile
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -1,4 +1,4 @@
-INCLUDES := -I../include
+INCLUDES := -I../include -I../../
CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE $(INCLUDES)
LDFLAGS := $(LDFLAGS) -lpthread -lrt
diff --git a/tools/testing/selftests/futex/include/logging.h
b/tools/testing/selftests/futex/include/logging.h
index 3220b90..1d0cfcd 100644
--- a/tools/testing/selftests/futex/include/logging.h
+++ b/tools/testing/selftests/futex/include/logging.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include "kselftest.h"
/*
* Define PASS, ERROR, and FAIL strings with and without color escape
@@ -108,12 +109,14 @@ void print_result(int ret)
switch (ret) {
case RET_PASS:
+ ksft_inc_pass_cnt();
result = PASS;
break;
case RET_ERROR:
result = ERROR;
break;
case RET_FAIL:
+ ksft_inc_fail_cnt();
result = FAIL;
break;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] kselftest: Add exit code defines
Define the exit codes with KSFT_PASS and similar so tests can use these
directly if they choose. Also enable harnesses and other tooling to use
the defines instead of hardcoding the return codes.
Cc: Shuah Khan
Cc: linux-...@vger.kernel.org
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Davidlohr Bueso
Cc: KOSAKI Motohiro
Signed-off-by: Darren Hart
---
tools/testing/selftests/kselftest.h | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/kselftest.h
b/tools/testing/selftests/kselftest.h
index 572c888..ef1c80d 100644
--- a/tools/testing/selftests/kselftest.h
+++ b/tools/testing/selftests/kselftest.h
@@ -13,6 +13,13 @@
#include
#include
+/* define kselftest exit codes */
+#define KSFT_PASS 0
+#define KSFT_FAIL 1
+#define KSFT_XFAIL 2
+#define KSFT_XPASS 3
+#define KSFT_SKIP 4
+
/* counters */
struct ksft_count {
unsigned int ksft_pass;
@@ -40,23 +47,23 @@ static inline void ksft_print_cnts(void)
static inline int ksft_exit_pass(void)
{
- exit(0);
+ exit(KSFT_PASS);
}
static inline int ksft_exit_fail(void)
{
- exit(1);
+ exit(KSFT_FAIL);
}
static inline int ksft_exit_xfail(void)
{
- exit(2);
+ exit(KSFT_XFAIL);
}
static inline int ksft_exit_xpass(void)
{
- exit(3);
+ exit(KSFT_XPASS);
}
static inline int ksft_exit_skip(void)
{
- exit(4);
+ exit(KSFT_SKIP);
}
#endif /* __KSELFTEST_H */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] selftest/futex: Update Makefile to use lib.mk
Adapt the futextest Makefiles to use lib.mk macros for RUN_TESTS and EMIT_TESTS. For now, we reuse the run.sh mechanism provided by futextest. This doesn't provide the standard selftests: [PASS|FAIL] format, but the tests provide very similar output already. This results in the run_kselftest.sh script for futexes including a single line: ./run.sh Cc: Shuah Khan Cc: linux-...@vger.kernel.org Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Davidlohr Bueso Cc: KOSAKI Motohiro Signed-off-by: Darren Hart --- tools/testing/selftests/futex/Makefile| 21 + tools/testing/selftests/futex/functional/Makefile | 4 2 files changed, 25 insertions(+) diff --git a/tools/testing/selftests/futex/Makefile b/tools/testing/selftests/futex/Makefile index 8629187..6a17529 100644 --- a/tools/testing/selftests/futex/Makefile +++ b/tools/testing/selftests/futex/Makefile @@ -1,8 +1,29 @@ SUBDIRS := functional +TEST_PROGS := run.sh + .PHONY: all clean all: for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done +include ../lib.mk + +override define RUN_TESTS + ./run.sh +endef + +override define INSTALL_RULE + mkdir -p $(INSTALL_PATH) + install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) $(TEST_FILES) + + @for SUBDIR in $(SUBDIRS); do \ + $(MAKE) -C $$SUBDIR INSTALL_PATH=$(INSTALL_PATH)/$$SUBDIR install; \ + done; +endef + +override define EMIT_TESTS + echo "./run.sh" +endef + clean: for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile index 6ecb42c..fb96927 100644 --- a/tools/testing/selftests/futex/functional/Makefile +++ b/tools/testing/selftests/futex/functional/Makefile @@ -12,10 +12,14 @@ TARGETS := \ futex_wait_uninitialized_heap \ futex_wait_private_mapped_file +TEST_PROGS := $(TARGETS) run.sh + .PHONY: all clean all: $(TARGETS) $(TARGETS): $(HEADERS) +include ../../lib.mk + clean: rm -f $(TARGETS) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] selftest: Add futex functional tests
Hi Shuah, This series begins the process of migrating my futextest tests into kselftest. I've started with only the functional tests, as the performance and stress may not be appropriate for kselftest as they stand. I cleaned up various complaints from checkpatch, but I ignored others that would require significant rework of the testcases, such as not using volatile and not creating new typedefs. The patches will follow, but I'm providing a pull request for your convenience as well. The following changes since commit 0b63accf87225b5eb7e52814c374cf02d733d4bb: tools, update rtctest.c to verify passage of time (2015-03-24 22:02:59 -0600) are available in the git repository at: git://git.infradead.org/users/dvhart/linux.git futextest Darren Hart (5): selftests: Add futex functional tests selftest/futex: Update Makefile to use lib.mk selftest/futex: Increment ksft pass and fail counters selftest: Add futex tests to the top-level Makefile kselftest: Add exit code defines tools/testing/selftests/Makefile | 1 + tools/testing/selftests/futex/Makefile | 29 ++ tools/testing/selftests/futex/README | 62 tools/testing/selftests/futex/functional/Makefile | 25 ++ .../selftests/futex/functional/futex_requeue_pi.c | 402 + .../functional/futex_requeue_pi_mismatched_ops.c | 136 +++ .../functional/futex_requeue_pi_signal_restart.c | 220 +++ .../functional/futex_wait_private_mapped_file.c| 126 +++ .../futex/functional/futex_wait_timeout.c | 85 + .../functional/futex_wait_uninitialized_heap.c | 124 +++ .../futex/functional/futex_wait_wouldblock.c | 79 tools/testing/selftests/futex/functional/run.sh| 79 tools/testing/selftests/futex/include/atomic.h | 83 + tools/testing/selftests/futex/include/futextest.h | 266 ++ tools/testing/selftests/futex/include/logging.h| 150 tools/testing/selftests/futex/run.sh | 33 ++ tools/testing/selftests/kselftest.h| 17 +- 17 files changed, 1912 insertions(+), 5 deletions(-) create mode 100644 tools/testing/selftests/futex/Makefile create mode 100644 tools/testing/selftests/futex/README create mode 100644 tools/testing/selftests/futex/functional/Makefile create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi.c create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_timeout.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c create mode 100644 tools/testing/selftests/futex/functional/futex_wait_wouldblock.c create mode 100755 tools/testing/selftests/futex/functional/run.sh create mode 100644 tools/testing/selftests/futex/include/atomic.h create mode 100644 tools/testing/selftests/futex/include/futextest.h create mode 100644 tools/testing/selftests/futex/include/logging.h create mode 100755 tools/testing/selftests/futex/run.sh -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ring-buffer: More precise time stamps for nested writes
On Sat, 28 Mar 2015 09:14:30 +1100 Paul Mackerras wrote: > > It can be done cleanly if you encapsulate it properly. > > Sure, but what is the advantage to using a static branch? When would > you ever want a single kernel image that could run either way > depending on what machine it was running on? For x86 you don't want it, unless you want to see interrupts serialized, where some times you do. It's not just an arch thing. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ocfs2-devel] [PATCH 2/2] ocfs2: Neaten do_error, ocfs2_error and ocfs2_abort
On Thu, 26 Mar 2015 20:07:08 -0700 Joe Perches wrote: > These uses sometimes do and sometimes don't have '\n' terminations. > Make the uses consistently use '\n' terminations and remove the > newline from the functions. This is going to take a while to merge, as it's backed up behind a pile of needs-more-reviewing ocfs2 patches. Namely: #ocfs2-trusted-xattr-missing-cap_sys_admin-check.patch: breaks userspace? ocfs2-trusted-xattr-missing-cap_sys_admin-check.patch # ocfs2-flush-inode-data-to-disk-and-free-inode-when-i_count-becomes-zero.patch # add-errors=continue.patch acknowledge-return-value-of-ocfs2_error.patch clear-the-rest-of-the-buffers-on-error.patch # ocfs2-fix-a-tiny-case-that-inode-can-not-removed.patch # #ocfs2-use-64bit-variables-to-track-heartbeat-time.patch: acks? ocfs2-use-64bit-variables-to-track-heartbeat-time.patch # #ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch: acks? Mark wants changes. Mark has list of notes ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch # #ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch: acks? Mark has issues ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages-v3.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ring-buffer: More precise time stamps for nested writes
On Fri, Mar 27, 2015 at 12:04:15PM -0400, Steven Rostedt wrote: > On Fri, 27 Mar 2015 00:38:43 -0500 > "Suresh E. Warrier" wrote: > > > > But for now, what can be done is to have > > > a flag that is set that will implement this or not. Using > > > static_branch() to implement it such that when its off it has no effect. > > > > > > > Are you recommending that for now I use a static_branch() instead > > of a CONFIG option to fix this? I could do that but the resulting > > code will either be messier to read (with several if condition checks) > > or will require some duplication of code. My assumption is that the > > new CONFIG option when disabled should have negligible impact since > > the compiler inlines the functions. > > It can be done cleanly if you encapsulate it properly. Sure, but what is the advantage to using a static branch? When would you ever want a single kernel image that could run either way depending on what machine it was running on? > Too bad I'm not going on any trips soon. This is a project I would work > on on the plane. :) Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] KVM fixes for 4.0-rc5
Linus, Please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git master To receive the following PPC KVM bug fixes Marcelo Tosatti (1): Merge tag 'signed-for-4.0' of git://github.com/agraf/linux-2.6 Paul Mackerras (3): KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr() KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count KVM: PPC: Book3S HV: Fix instruction emulation arch/powerpc/kvm/book3s_hv.c|8 arch/powerpc/kvm/book3s_hv_rmhandlers.S |1 + 2 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä wrote:
> On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
>> On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
>> > On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez
>> > wrote:
>> > > On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
>> > >> On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
>> > >> > diff --git a/drivers/video/fbdev/aty/atyfb_base.c
>> > >> > b/drivers/video/fbdev/aty/atyfb_base.c
>> > >> > index 8025624..8875e56 100644
>> > >> > --- a/drivers/video/fbdev/aty/atyfb_base.c
>> > >> > +++ b/drivers/video/fbdev/aty/atyfb_base.c
>> > >> > @@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
>> > >> >
>> > >> > #ifdef CONFIG_MTRR
>> > >> > par->mtrr_aper = -1;
>> > >> > - par->mtrr_reg = -1;
>> > >> > if (!nomtrr) {
>> > >> > - /* Cover the whole resource. */
>> > >> > - par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
>> > >> > + par->mtrr_aper = mtrr_add(info->fix.smem_start,
>> > >> > + info->fix.smem_len,
>> > >> > MTRR_TYPE_WRCOMB, 1);
>> > >>
>> > >> MTRRs need power of two size, so how is this supposed to work?
>> > >
>> > > As per mtrr_add_page() [0] the base and size are just supposed to be in
>> > > units
>> > > of 4 KiB, although the practice is to use powers of 2 in *some* drivers
>> > > this
>> > > is not standardized and by no means recorded as a requirement. Obviously
>> > > powers of 2 will work too and you'd end up neatly aligned as well.
>> > > mtrr_add()
>> > > will use mtrr_check() to verify the the same requirement. Furthermore,
>> > > as per my commit log message:
>> >
>> > Whatever the code may or may not do, the x86 architecture uses
>> > power-of-two MTRR sizes. So I'm confused.
>>
>> There should be no confusion, I simply did not know that *was* the
>> requirement for x86, if that is the case we should add a check for that
>> and perhaps generalize a helper that does the power of two helper changes,
>> the cleanest I found was the vesafb driver solution.
>>
>> Thoughts?
>
> The vesafb solution is bad since you'll only end up covering only
> the first 4MB of the framebuffer instead of the almost 8MB you want.
> Which in practice will mean throwing away half the VRAM since you really
> don't want the massive performance hit from accessing it as UC. And that
> would mean giving up decent display resolutions as well :(
>
> And the other option of trying to cover the remainder with multiple ever
> smaller MTRRs doesn't work either since you'll run out of MTRRs very
> quickly.
>
> This is precisely why I used the hole method in atyfb in the first
> place.
>
> I don't really like the idea of any new mtrr code not supporting that
> use case, especially as these things tend to be present in older machines
> where PAT isn't an option.
According to the Intel SDM, volume 3, section 11.5.2.1, table 11-6,
non-PAT CPUs that have a WC MTRR, PCD = 1, and PWT = 1 (aka UC) have
an effective memory type of UC. Hence my suggestion to add
ioremap_x86_uc and/or set_memory_x86_uc to punch a UC hole in an
otherwise WC MTRR-covered region.
ioremap_nocache is UC- (even on non-PAT unless I misunderstood how
this stuff works), so ioremap_nocache by itself isn't good enough.
--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] perf, record: Add clockid parameter
On Fri, Mar 27, 2015 at 05:15:34PM -0300, Arnaldo Carvalho de Melo wrote:
> I.e. we're back to the sys_perf_event_open() error reporting suckz rockz
> thing, this time with PeterZ trying to find a way to avoid getting back
> to that discussion... /me runz... ;-P
:-)
Not entirely, its just that I've not seen this userspace code in years
and I'm pretty clueless.
How about so then?
---
Subject: perf, record: Add clockid parameter
From: Peter Zijlstra
Date: Fri, 27 Mar 2015 15:32:01 +0100
Teach perf-record about the new perf_event_attr::{use_clockid, clockid}
fields. Add a simple parameter to set the clock (if any) to be used for
the events to be recorded into the data file.
Since we store the entire perf_event_attr in the EVENT_DESC section we
also already store the used clockid in the data file.
Cc: a...@redhat.com
Signed-off-by: Peter Zijlstra (Intel)
---
tools/perf/Documentation/perf-record.txt |5 +++
tools/perf/builtin-record.c |3 ++
tools/perf/perf.h|1
tools/perf/util/evsel.c | 44 ---
4 files changed, 49 insertions(+), 4 deletions(-)
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -250,6 +250,11 @@ is off by default.
--running-time::
Record running and enabled time for read events (:S)
+-k::
+--clockid::
+Sets the clock id to use for the various time fields in the perf_event_type
+records. See clock_gettime().
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -739,6 +739,7 @@ static struct record record = {
.uses_mmap = true,
.default_per_cpu = true,
},
+ .clockid = -1,
},
.tool = {
.sample = process_sample_event,
@@ -842,6 +843,8 @@ struct option __record_options[] = {
"Sample machine registers on interrupt"),
OPT_BOOLEAN(0, "running-time", _time,
"Record running/enabled time of read (:S) events"),
+ OPT_INTEGER('k', "clockid", ,
+ "clockid to use for events"),
OPT_END()
};
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -62,6 +62,7 @@ struct record_opts {
u64 user_interval;
bool sample_transaction;
unsigned initial_delay;
+ clockid_tclockid;
};
struct option;
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -32,6 +32,7 @@ static struct {
bool exclude_guest;
bool mmap2;
bool cloexec;
+ bool clockid;
} perf_missing_features;
static int perf_evsel__no_extra_init(struct perf_evsel *evsel __maybe_unused)
@@ -761,6 +762,11 @@ void perf_evsel__config(struct perf_evse
attr->disabled = 0;
attr->enable_on_exec = 0;
}
+
+ if (opts->clockid >= 0) {
+ attr->use_clockid = 1;
+ attr->clockid = opts->clockid;
+ }
}
static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int
nthreads)
@@ -1036,7 +1042,6 @@ static size_t perf_event_attr__fprintf(s
ret += PRINT_ATTR2(exclude_user, exclude_kernel);
ret += PRINT_ATTR2(exclude_hv, exclude_idle);
ret += PRINT_ATTR2(mmap, comm);
- ret += PRINT_ATTR2(mmap2, comm_exec);
ret += PRINT_ATTR2(freq, inherit_stat);
ret += PRINT_ATTR2(enable_on_exec, task);
ret += PRINT_ATTR2(watermark, precise_ip);
@@ -1044,6 +1049,8 @@ static size_t perf_event_attr__fprintf(s
ret += PRINT_ATTR2(exclude_host, exclude_guest);
ret += PRINT_ATTR2N("excl.callchain_kern", exclude_callchain_kernel,
"excl.callchain_user", exclude_callchain_user);
+ ret += PRINT_ATTR2(mmap2, comm_exec);
+ ret += __PRINT_ATTR("%u",,use_clockid);
ret += PRINT_ATTR_U32(wakeup_events);
ret += PRINT_ATTR_U32(wakeup_watermark);
@@ -1055,6 +1062,7 @@ static size_t perf_event_attr__fprintf(s
ret += PRINT_ATTR_X64(branch_sample_type);
ret += PRINT_ATTR_X64(sample_regs_user);
ret += PRINT_ATTR_U32(sample_stack_user);
+ ret += PRINT_ATTR_U32(clockid);
ret += PRINT_ATTR_X64(sample_regs_intr);
ret += fprintf(fp, "%.60s\n", graph_dotted_line);
@@ -1085,6 +1093,8 @@ static int __perf_evsel__open(struct per
}
fallback_missing_features:
+ if (perf_missing_features.clockid)
+ evsel->attr.use_clockid = 0;
if (perf_missing_features.cloexec)
flags &= ~(unsigned long)PERF_FLAG_FD_CLOEXEC;
if (perf_missing_features.mmap2)
@@ -1122,6 +1132,16 @@ static int __perf_evsel__open(struct per
goto try_fallback;
}
set_rlimit = NO_CHANGE;
+
+ /*
+
