Re: [ovirt-devel] Networking fails for VM running on Centos6.7.Works on Centos6.5
On Sat, Nov 28, 2015 at 08:10:06PM +0530, mad Engineer wrote: > hello all i am having strange network issue with vms that are running on > centos 6.7 ovirt nodes. > > I recently added one more ovirt node which is running centos6.7 and > upgraded from centos6.5 to centos6.7 on all other nodes. > > All VMs running on nodes with centos6.7 as host Operating system fail to > reach network gateway,but if i reboot that same host to centos6.5 kernel > everything works fine(with out changing any network configuration). > > Initially i thought it as configuration issue but its there on all nodes.if > i reboot to old kernel everything is working. > > I am aware about ghost vlan0 issue in centos6.6 kernel.Not aware about any > issue in centos6.7 Also all my servers are up to date. > > > All physical interfaces are in access mode VLAN connected to nexus 5k > switches. > > > working kernel- 2.6.32-431.20.3.el6.x86_64 > > non working kernel- 2.6.32-573.8.1.el6.x86_64 Can you provide the topology of your VM network config (vlan, bond, bond options, bridge options)? Do you have an IP address on the bridge? (I have not seen this happen myself) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/platform] x86/platform/calgary: Constify cal_chipset_ops structures
Commit-ID: d6b56b0bc68ba7927b286da86eda1d4d4dbe63f6
Gitweb: http://git.kernel.org/tip/d6b56b0bc68ba7927b286da86eda1d4d4dbe63f6
Author: Julia Lawall
AuthorDate: Sat, 28 Nov 2015 16:58:15 +0100
Committer: Ingo Molnar
CommitDate: Sun, 29 Nov 2015 08:50:58 +0100
x86/platform/calgary: Constify cal_chipset_ops structures
The cal_chipset_ops structures are never modified, so declare
them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Jon D. Mason
Cc: Linus Torvalds
Cc: Muli Ben-Yehuda
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1448726295-10959-1-git-send-email-julia.law...@lip6.fr
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/calgary.h | 2 +-
arch/x86/kernel/pci-calgary_64.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/calgary.h b/arch/x86/include/asm/calgary.h
index 0d467b3..a8303eb 100644
--- a/arch/x86/include/asm/calgary.h
+++ b/arch/x86/include/asm/calgary.h
@@ -31,7 +31,7 @@
#include
struct iommu_table {
- struct cal_chipset_ops *chip_ops; /* chipset specific funcs */
+ const struct cal_chipset_ops *chip_ops; /* chipset specific funcs */
unsigned long it_base; /* mapped address of tce table */
unsigned long it_hint; /* Hint for next alloc */
unsigned long *it_map; /* A simple allocation bitmap for now */
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 0497f71..833b1d3 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -180,13 +180,13 @@ static void calioc2_dump_error_regs(struct iommu_table
*tbl);
static void calgary_init_bitmap_from_tce_table(struct iommu_table *tbl);
static void get_tce_space_from_tar(void);
-static struct cal_chipset_ops calgary_chip_ops = {
+static const struct cal_chipset_ops calgary_chip_ops = {
.handle_quirks = calgary_handle_quirks,
.tce_cache_blast = calgary_tce_cache_blast,
.dump_error_regs = calgary_dump_error_regs
};
-static struct cal_chipset_ops calioc2_chip_ops = {
+static const struct cal_chipset_ops calioc2_chip_ops = {
.handle_quirks = calioc2_handle_quirks,
.tce_cache_blast = calioc2_tce_cache_blast,
.dump_error_regs = calioc2_dump_error_regs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
* Andy Lutomirski wrote: > >> - print a warning and a backtrace, and just mark the page read-write > >> so that the machine survives, but we get notified and can fix whatever > >> broken code > > > > This seems very easy to add. Should I basically reverse the effects of > > mark_rodata_ro(), or should I only make the new ro-after-init section as > > RW? > > (I think the former would be easier.) > > I'd suggest verifying that the page in question is .data..ro_after_init and, > if > so, marking that one page RW. Yes, this was PaX's suggestion as well, and I agree: doing that turns a quite possibly unrecoverable boot/shutdown time or suspend/resume time (suspend is really a special category of 'bootup') crasher oops into a more informative stack dump. These ro related faults tend to trigger when init/deinit is running, and oopsing in those sequences is typically a lot less survivable than say oopsing in a high level system call while not holding locks. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
* PaX Team wrote: > i don't see the compile time vs. runtime detection as 'competing' approaches, > both have their own role. [...] That's true - but only as long as 'this can be solved in tooling!' is not used as an excuse to oppose the runtime solution and we end up doing neither. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL v4 0/6] EFI page table isolation
* Matt Fleming wrote: > Folks, > > This patch series is a response to the report that the EFI region > mappings trigger warnings when booting with CONFIG_DEBUG_WX enabled. > They allocate a new page table structure and ensure that all the > mappings we require during EFI runtime calls are only setup there. > > It turns out that it still makes sense to share some page table > entries with 'swapper_pg_dir', just not the entries where we need to > allow security lax permissions. Sharing entries is useful for memory > hotplug, for example. > > When writing this series I discovered a number of bugs in the existing > code that only became apparent when we stopped using 'trampoline_pgd' > which already mapped a bunch of things for us. I've put those bug > fixes at the start of the series. > > Further testing would be very much appreciated as this is a > notoriously funky area of the EFI code. Ok, this series looks great to me - I've applied this to tip:x86/efi and will push it out to linux-next after it passes some local testing. There should be time enough before v4.5 to figure out potential bugs. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[char-misc for v4.4] mei: fix fasync return value on error
fasync should return a negative value on error
and not poll mask POLLERR.
Cc: # 4.3+
Reported-by: Al Viro
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index b2f2486b3d75..677d0362f334 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -657,7 +657,9 @@ out:
* @file: pointer to file structure
* @band: band bitmap
*
- * Return: poll mask
+ * Return: negative on error,
+ * 0 if it did no changes,
+ * and positive a process was added or deleted
*/
static int mei_fasync(int fd, struct file *file, int band)
{
@@ -665,7 +667,7 @@ static int mei_fasync(int fd, struct file *file, int band)
struct mei_cl *cl = file->private_data;
if (!mei_cl_is_connected(cl))
- return POLLERR;
+ return -ENODEV;
return fasync_helper(fd, file, band, &cl->ev_async);
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers:pci:hotplug Fix space prohibited between function name and open parenthesis '('
> On Nov 26, 2015, at 8:36 PM, Joe Perches wrote:
>
> On Thu, 2015-11-26 at 16:50 +0100, Bogicevic Sasa wrote:
>> This fixes all errors "space prohibited between function name and
>> open parenthesis '(' " in all files in drivers/pci/hotplug folder
>
> It's good when sending this sort of patch to add a bit of
> description like "git diff -w shows no differences" and that
> using scripts/objdiff also shows no difference.
>
> Doing so shows that you've done a bit more than a mechanical
> transformation using something like:
>
> $ ./scripts/checkpatch -f --types=spacing --fix-inplace
>
> and that you have verified your changes too.
> Ah ok, thanks for the info. Ill explore some more on what else can
> checkpatch.pl can do and resend all that needs to be corrected in that folder.
Thanks, Sasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/efi] x86/mm/pat: Ensure cpa-> pfn only contains page frame numbers
Commit-ID: edc3b9129cecd0f0857112136f5b8b1bc1d45918
Gitweb: http://git.kernel.org/tip/edc3b9129cecd0f0857112136f5b8b1bc1d45918
Author: Matt Fleming
AuthorDate: Fri, 27 Nov 2015 21:09:31 +
Committer: Ingo Molnar
CommitDate: Sun, 29 Nov 2015 09:15:42 +0100
x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
The x86 pageattr code is confused about the data that is stored
in cpa->pfn, sometimes it's treated as a page frame number,
sometimes it's treated as an unshifted physical address, and in
one place it's treated as a pte.
The result of this is that the mapping functions do not map the
intended physical address.
This isn't a problem in practice because most of the addresses
we're mapping in the EFI code paths are already mapped in
'trampoline_pgd' and so the pageattr mapping functions don't
actually do anything in this case. But when we move to using a
separate page table for the EFI runtime this will be an issue.
Signed-off-by: Matt Fleming
Reviewed-by: Borislav Petkov
Acked-by: Borislav Petkov
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sai Praneeth Prakhya
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1448658575-17029-3-git-send-email-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar
---
arch/x86/mm/pageattr.c | 17 ++---
arch/x86/platform/efi/efi_64.c | 16 ++--
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index a3137a4..c70e420 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -905,15 +905,10 @@ static void populate_pte(struct cpa_data *cpa,
pte = pte_offset_kernel(pmd, start);
while (num_pages-- && start < end) {
-
- /* deal with the NX bit */
- if (!(pgprot_val(pgprot) & _PAGE_NX))
- cpa->pfn &= ~_PAGE_NX;
-
- set_pte(pte, pfn_pte(cpa->pfn >> PAGE_SHIFT, pgprot));
+ set_pte(pte, pfn_pte(cpa->pfn, pgprot));
start+= PAGE_SIZE;
- cpa->pfn += PAGE_SIZE;
+ cpa->pfn++;
pte++;
}
}
@@ -969,11 +964,11 @@ static int populate_pmd(struct cpa_data *cpa,
pmd = pmd_offset(pud, start);
- set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
+ set_pmd(pmd, __pmd(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
massage_pgprot(pmd_pgprot)));
start += PMD_SIZE;
- cpa->pfn += PMD_SIZE;
+ cpa->pfn += PMD_SIZE >> PAGE_SHIFT;
cur_pages += PMD_SIZE >> PAGE_SHIFT;
}
@@ -1042,11 +1037,11 @@ static int populate_pud(struct cpa_data *cpa, unsigned
long start, pgd_t *pgd,
* Map everything starting from the Gb boundary, possibly with 1G pages
*/
while (end - start >= PUD_SIZE) {
- set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
+ set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
massage_pgprot(pud_pgprot)));
start += PUD_SIZE;
- cpa->pfn += PUD_SIZE;
+ cpa->pfn += PUD_SIZE >> PAGE_SHIFT;
cur_pages += PUD_SIZE >> PAGE_SHIFT;
pud++;
}
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index a0ac0f9..5aa186d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -143,7 +143,7 @@ void efi_sync_low_kernel_mappings(void)
int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
{
- unsigned long text;
+ unsigned long pfn, text;
struct page *page;
unsigned npages;
pgd_t *pgd;
@@ -160,7 +160,8 @@ int __init efi_setup_page_tables(unsigned long pa_memmap,
unsigned num_pages)
* and ident-map those pages containing the map before calling
* phys_efi_set_virtual_address_map().
*/
- if (kernel_map_pages_in_pgd(pgd, pa_memmap, pa_memmap, num_pages,
_PAGE_NX)) {
+ pfn = pa_memmap >> PAGE_SHIFT;
+ if (kernel_map_pages_in_pgd(pgd, pfn, pa_memmap, num_pages, _PAGE_NX)) {
pr_err("Error ident-mapping new memmap (0x%lx)!\n", pa_memmap);
return 1;
}
@@ -185,8 +186,9 @@ int __init efi_setup_page_tables(unsigned long pa_memmap,
unsigned num_pages)
npages = (_end - _text) >> PAGE_SHIFT;
text = __pa(_text);
+ pfn = text >> PAGE_SHIFT;
- if (kernel_map_pages_in_pgd(pgd, text >> PAGE_SHIFT, text, npages, 0)) {
+ if (kernel_map_pages_in_pgd(pgd, pfn, text, npages, 0)) {
pr_err("Failed to map kernel text 1:1\n");
return 1;
}
@@ -204,12 +206,14 @@ void __init efi_cleanu
[tip:x86/efi] x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
Commit-ID: 21cdb6b568435738cc0b303b2b3b82742396310c Gitweb: http://git.kernel.org/tip/21cdb6b568435738cc0b303b2b3b82742396310c Author: Matt Fleming AuthorDate: Fri, 27 Nov 2015 21:09:30 + Committer: Ingo Molnar CommitDate: Sun, 29 Nov 2015 09:15:42 +0100 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs Ingo noted that if we can guarantee _end is aligned to PAGE_SIZE we can automatically avoid bugs along the lines of, size = _end - _text >> PAGE_SHIFT which is missing a call to PFN_ALIGN(). The EFI mixed mode contains this bug, for example. _text is already aligned to PAGE_SIZE through the use of LOAD_PHYSICAL_ADDR, and the BSS and BRK sections are explicitly aligned in the linker script, so it makes sense to align _end to match. Reported-by: Ingo Molnar Signed-off-by: Matt Fleming Acked-by: Borislav Petkov Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1448658575-17029-2-git-send-email-m...@codeblueprint.co.uk Signed-off-by: Ingo Molnar --- arch/x86/kernel/vmlinux.lds.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 74e4bf1..4f19942 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -325,6 +325,7 @@ SECTIONS __brk_limit = .; } + . = ALIGN(PAGE_SIZE); _end = .; STABS_DEBUG -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/efi] x86/efi: Map RAM into the identity page table for mixed mode
Commit-ID: b61a76f8850d2979550abc42d7e09154ebb8d785
Gitweb: http://git.kernel.org/tip/b61a76f8850d2979550abc42d7e09154ebb8d785
Author: Matt Fleming
AuthorDate: Fri, 27 Nov 2015 21:09:32 +
Committer: Ingo Molnar
CommitDate: Sun, 29 Nov 2015 09:15:42 +0100
x86/efi: Map RAM into the identity page table for mixed mode
We are relying on the pre-existing mappings in 'trampoline_pgd'
when accessing function arguments in the EFI mixed mode thunking
code.
Instead let's map memory explicitly so that things will continue
to work when we move to a separate page table in the future.
Signed-off-by: Matt Fleming
Reviewed-by: Borislav Petkov
Acked-by: Borislav Petkov
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sai Praneeth Prakhya
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1448658575-17029-4-git-send-email-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar
---
arch/x86/platform/efi/efi_64.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 5aa186d..102976d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -144,6 +144,7 @@ void efi_sync_low_kernel_mappings(void)
int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
{
unsigned long pfn, text;
+ efi_memory_desc_t *md;
struct page *page;
unsigned npages;
pgd_t *pgd;
@@ -177,6 +178,25 @@ int __init efi_setup_page_tables(unsigned long pa_memmap,
unsigned num_pages)
if (!IS_ENABLED(CONFIG_EFI_MIXED))
return 0;
+ /*
+* Map all of RAM so that we can access arguments in the 1:1
+* mapping when making EFI runtime calls.
+*/
+ for_each_efi_memory_desc(&memmap, md) {
+ if (md->type != EFI_CONVENTIONAL_MEMORY &&
+ md->type != EFI_LOADER_DATA &&
+ md->type != EFI_LOADER_CODE)
+ continue;
+
+ pfn = md->phys_addr >> PAGE_SHIFT;
+ npages = md->num_pages;
+
+ if (kernel_map_pages_in_pgd(pgd, pfn, md->phys_addr, npages,
0)) {
+ pr_err("Failed to map 1:1 memory\n");
+ return 1;
+ }
+ }
+
page = alloc_page(GFP_KERNEL|__GFP_DMA32);
if (!page)
panic("Unable to allocate EFI runtime stack < 4GB\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/efi] x86/efi: Hoist page table switching code into efi_call_virt()
Commit-ID: c9f2a9a65e4855b74d92cdad688f6ee4a1a323ff
Gitweb: http://git.kernel.org/tip/c9f2a9a65e4855b74d92cdad688f6ee4a1a323ff
Author: Matt Fleming
AuthorDate: Fri, 27 Nov 2015 21:09:33 +
Committer: Ingo Molnar
CommitDate: Sun, 29 Nov 2015 09:15:42 +0100
x86/efi: Hoist page table switching code into efi_call_virt()
This change is a prerequisite for pending patches that switch to
a dedicated EFI page table, instead of using 'trampoline_pgd'
which shares PGD entries with 'swapper_pg_dir'. The pending
patches make it impossible to dereference the runtime service
function pointer without first switching %cr3.
It's true that we now have duplicated switching code in
efi_call_virt() and efi_call_phys_{prolog,epilog}() but we are
sacrificing code duplication for a little more clarity and the
ease of writing the page table switching code in C instead of
asm.
Signed-off-by: Matt Fleming
Reviewed-by: Borislav Petkov
Acked-by: Borislav Petkov
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Jones
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sai Praneeth Prakhya
Cc: Stephen Smalley
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1448658575-17029-5-git-send-email-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/efi.h | 25 +
arch/x86/platform/efi/efi_64.c | 24 ++---
arch/x86/platform/efi/efi_stub_64.S | 43 -
3 files changed, 36 insertions(+), 56 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 0010c78..347eeac 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -3,6 +3,7 @@
#include
#include
+#include
/*
* We map the EFI regions needed for runtime services non-contiguously,
@@ -64,6 +65,17 @@ extern u64 asmlinkage efi_call(void *fp, ...);
#define efi_call_phys(f, args...) efi_call((f), args)
+/*
+ * Scratch space used for switching the pagetable in the EFI stub
+ */
+struct efi_scratch {
+ u64 r15;
+ u64 prev_cr3;
+ pgd_t *efi_pgt;
+ booluse_pgd;
+ u64 phys_stack;
+} __packed;
+
#define efi_call_virt(f, ...) \
({ \
efi_status_t __s; \
@@ -71,7 +83,20 @@ extern u64 asmlinkage efi_call(void *fp, ...);
efi_sync_low_kernel_mappings(); \
preempt_disable(); \
__kernel_fpu_begin(); \
+ \
+ if (efi_scratch.use_pgd) { \
+ efi_scratch.prev_cr3 = read_cr3(); \
+ write_cr3((unsigned long)efi_scratch.efi_pgt); \
+ __flush_tlb_all(); \
+ } \
+ \
__s = efi_call((void *)efi.systab->runtime->f, __VA_ARGS__);\
+ \
+ if (efi_scratch.use_pgd) { \
+ write_cr3(efi_scratch.prev_cr3);\
+ __flush_tlb_all(); \
+ } \
+ \
__kernel_fpu_end(); \
preempt_enable(); \
__s;\
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 102976d..b19cdac 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -47,16 +47,7 @@
*/
static u64 efi_va = EFI_VA_START;
-/*
- * Scratch space used for switching the pagetable in the EFI stub
- */
-struct efi_scratch {
- u64 r15;
- u64 prev_cr3;
- pgd_t *efi_pgt;
- bool use_pgd;
- u64 phys_stack;
-} __packed;
+struct efi_scratch efi_scratch;
static void __init early_code_mapping_set_exec(int executable)
{
@@ -83,8 +74,11 @@ pgd_t * __init efi_call_phys_prolog(void)
int pgd;
int n_pgds;
- if (!efi_enabled(EFI_OLD_MEMMAP))
- return NULL;
+ if (!efi_enabled(EFI_OLD_MEMMAP)) {
+ save_pgd = (pgd_t *)read_cr3();
+ write_cr3((unsigned long)efi_scratc
[tip:x86/efi] Documentation/x86: Update EFI memory region description
Commit-ID: ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c Gitweb: http://git.kernel.org/tip/ff3d0a12fb2dc123e2b46e9524ebf4e08de5c59c Author: Matt Fleming AuthorDate: Fri, 27 Nov 2015 21:09:35 + Committer: Ingo Molnar CommitDate: Sun, 29 Nov 2015 09:15:43 +0100 Documentation/x86: Update EFI memory region description Make it clear that the EFI page tables are only available during EFI runtime calls since that subject has come up a fair numbers of times in the past. Additionally, add the EFI region start and end addresses to the table so that it's possible to see at a glance where they fall in relation to other regions. Signed-off-by: Matt Fleming Reviewed-by: Borislav Petkov Acked-by: Borislav Petkov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Jones Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Stephen Smalley Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1448658575-17029-7-git-send-email-m...@codeblueprint.co.uk Signed-off-by: Ingo Molnar --- Documentation/x86/x86_64/mm.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index 05712ac..c518dce 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -16,6 +16,8 @@ ec00 - fc00 (=44 bits) kasan shadow memory (16TB) ... unused hole ... ff00 - ff7f (=39 bits) %esp fixup stacks ... unused hole ... +ffef - (=64 GB) EFI region mapping space +... unused hole ... 8000 - a000 (=512 MB) kernel text mapping, from phys 0 a000 - ff5f (=1525 MB) module mapping space ff60 - ffdf (=8 MB) vsyscalls @@ -32,11 +34,9 @@ reference. Current X86-64 implementations only support 40 bits of address space, but we support up to 46 bits. This expands into MBZ space in the page tables. -->trampoline_pgd: - -We map EFI runtime services in the aforementioned PGD in the virtual -range of 64Gb (arbitrarily set, can be raised if needed) - -0xffef - 0x +We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual +memory window (this size is arbitrary, it can be raised later if needed). +The mappings are not part of any other kernel PGD and are only available +during EFI runtime calls. -Andi Kleen, Jul 2004 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/efi] x86/efi: Build our own page table structures
Commit-ID: 67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
Gitweb: http://git.kernel.org/tip/67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
Author: Matt Fleming
AuthorDate: Fri, 27 Nov 2015 21:09:34 +
Committer: Ingo Molnar
CommitDate: Sun, 29 Nov 2015 09:15:42 +0100
x86/efi: Build our own page table structures
With commit e1a58320a38d ("x86/mm: Warn on W^X mappings") all
users booting on 64-bit UEFI machines see the following warning,
[ cut here ]
WARNING: CPU: 7 PID: 1 at arch/x86/mm/dump_pagetables.c:225
note_page+0x5dc/0x780()
x86/mm: Found insecure W+X mapping at address
8805f000/0x8805f000
...
x86/mm: Checked W+X mappings: FAILED, 165660 W+X pages found.
...
This is caused by mapping EFI regions with RWX permissions.
There isn't much we can do to restrict the permissions for these
regions due to the way the firmware toolchains mix code and
data, but we can at least isolate these mappings so that they do
not appear in the regular kernel page tables.
In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual
mapping") we started using 'trampoline_pgd' to map the EFI
regions because there was an existing identity mapping there
which we use during the SetVirtualAddressMap() call and for
broken firmware that accesses those addresses.
But 'trampoline_pgd' shares some PGD entries with
'swapper_pg_dir' and does not provide the isolation we require.
Notably the virtual address for __START_KERNEL_map and
MODULES_START are mapped by the same PGD entry so we need to be
more careful when copying changes over in
efi_sync_low_kernel_mappings().
This patch doesn't go the full mile, we still want to share some
PGD entries with 'swapper_pg_dir'. Having completely separate
page tables brings its own issues such as synchronising new
mappings after memory hotplug and module loading. Sharing also
keeps memory usage down.
Signed-off-by: Matt Fleming
Reviewed-by: Borislav Petkov
Acked-by: Borislav Petkov
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Jones
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sai Praneeth Prakhya
Cc: Stephen Smalley
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1448658575-17029-6-git-send-email-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform/efi/efi.c| 39 ++---
arch/x86/platform/efi/efi_32.c | 5 +++
arch/x86/platform/efi/efi_64.c | 97 +++---
4 files changed, 102 insertions(+), 40 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 347eeac..8fd9e63 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -136,6 +136,7 @@ extern void __init efi_memory_uc(u64 addr, unsigned long
size);
extern void __init efi_map_region(efi_memory_desc_t *md);
extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
+extern int __init efi_alloc_page_tables(void);
extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned
num_pages);
extern void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned
num_pages);
extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ad28540..3c1f3cd 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -869,7 +869,7 @@ static void __init kexec_enter_virtual_mode(void)
* This function will switch the EFI runtime services to virtual mode.
* Essentially, we look through the EFI memmap and map every region that
* has the runtime attribute bit set in its memory descriptor into the
- * ->trampoline_pgd page table using a top-down VA allocation scheme.
+ * efi_pgd page table.
*
* The old method which used to update that memory descriptor with the
* virtual address obtained from ioremap() is still supported when the
@@ -879,8 +879,8 @@ static void __init kexec_enter_virtual_mode(void)
*
* The new method does a pagetable switch in a preemption-safe manner
* so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PGDs of the
- * kernel page table into ->trampoline_pgd prior to each call.
+ * function. For function arguments passing we do copy the PUDs of the
+ * kernel page table into efi_pgd prior to each call.
*
* Specially for kexec boot, efi runtime maps in previous kernel should
* be passed in via setup_data. In that case runtime ranges will be mapped
@@ -895,6 +895,12 @@ static void __init __efi_enter_virtual_mode(void)
efi.systab = NULL;
+ if (efi_alloc_page_tables()) {
+ pr_err("Failed to allocate EFI page tables\n");
+ clear_bit(EFI_RUNTIME_SERVICE
Re: [PATCH 22/71] ncr5380: Eliminate selecting state
On Sunday 29 November 2015 01:46:03 Finn Thain wrote:
>
> On Sun, 29 Nov 2015, Ondrej Zary wrote:
>
> > > [...] I think that this should solve the problem:
> >
> > Yes, it does!
> >
> > [ 48.119367] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> > n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> > 128, this_id 7, flags { NO_DMA_FIXUP }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > [ 49.715388] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X
> > 4.6 PQ: 0 ANSI: 2 CCS
>
> That still takes about 1.6 seconds to scan a vacant bus ID. It should be
> more like 0.25 seconds. Did you have the entire patch series applied?
>
> The code presently in mainline spins for 500 iterations in the relevant
> busy-wait loop, with the comment, "8uS a cycle for the cpu access". That
> doesn't help me much. Does that refer to an ISA bus cycle? Or one
> iteration of the loop? Electrical conductance?
>
> If we knew how many loops_per_jiffy your machine gets, and your CONFIG_HZ
> value, we could figure out how long a chip register access takes (which
> might be 8 us).
loops_per_jiffy=4797252
CONFIG_HZ=250
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Celeron(TM) CPU1200MHz
stepping: 1
microcode : 0x1c
cpu MHz : 1199.313
cache size : 256 KB
physical id : 0
siblings: 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pse36 mmx fxsr sse
bugs:
bogomips: 2398.62
clflush size: 32
cache_alignment : 32
address sizes : 36 bits physical, 32 bits virtual
power management:
# cat iotest.c
#include
#include
int main(void) {
if (iopl(3)) {
perror("iopl");
return 1;
}
for (int i = 0; i < 1000; i++)
inb(0x280);
return 0;
}
# cc --std=c99 iotest.c -o iotest
# time ./iotest
real0m16.938s
user0m16.932s
sys 0m0.000s
outb() instead of inb():
# time ./iotest
real0m17.210s
user0m17.204s
sys 0m0.000s
> I'll try to figure out a similar timing for my Domex PCI card to see if
> there is some sort of compromise to be found.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] introduce new evdev interface type
Hi, Arnd > 在 2015年11月28日，00:58，Arnd Bergmann 写道： > > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: >> To solve the y2038 problem in input_event, I had some attempts before [1], >> and this is the second one. >> >> We can force userspace to use monotonic time in event timestamp, so the >> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we >> can not find a way to make kernel compatible with old binaries, which use >> realtime, and there are still some devices, which depend on realtime. >> >> So I get a idea to add a new evdev interface, which is y2038 safe. And >> userspace can switch between the old and new interface via ioctl. >> >> The patch series add three evdev interface type: >> >> - EV_IF_LEGACY >> send event by input_event. This is the default option, keep kernel >> backward compatible. > > The problem I see with this approach is that it still breaks any > legacy source code that is compiled with a new libc that uses 64-bit > time_t. If we are requiring source code changes for building users > of input devices with a new libc, we can easily get them to handle > the overflow (they normally only care about the microsecond portion > anyway, so it doesn't matter in most cases), or to use monotonic time. I don’t think so. Actually, from the view of userspace, EV_IF_LEGACY interface is work exactly the same as old evdev. We didn’t change anything in input_event and input_event_compat. And the problem you said will still be there, even without those patches. Pingbo-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] input: evdev: add new ioctl EVIOCSIFTYPE / EVIOCGIFTYPE
> 在 2015年11月28日，00:59，Arnd Bergmann 写道： > > On Friday 27 November 2015 18:00:31 WEN Pingbo wrote: >> This patch depends on 'introduce new evdev interface'. >> >> Userspace cat set / get evdev interface type via the two ioctl >> commands. And default interface type is EV_IF_LEGACY, so the old binary >> will work normal with new kernel. Maybe we should change this default >> option to encourage people to move to new interface. >> >> And since all events are stored as input_value in evdev, there are no >> need to flush evdev_client's buffer if we change clk_type and if_type. > > I would split out the change to evdev_set_clk_type into a separate patch. Agreed. > >> +case EVIOCSIFTYPE: >> +if (get_user(if_type, ip)) >> +return -EFAULT; >> + >> +return evdev_set_if_type(client, if_type); >> +case EVIOCGIFTYPE: >> +return put_user(client->if_type, ip); >> } > > This look asymmetric: EVIOCSIFTYPE uses a EVDEV_* constant, while > EVIOCGIFTYPE returns a EV_IF_* constant. Should those just > be the same constants anyway? Yes, thanks for pointing it out. I need add evdev_get_if_type() here. Pingbo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 22/71] ncr5380: Eliminate selecting state
Hi Finn,
On Thu, Nov 26, 2015 at 11:32 PM, Finn Thain wrote:
>> The timekeeping warning does not appear when all 71 patches are applied.
>> Reverse-bisected it - the warning disappears after:
>> [PATCH 50/71] ncr5380: Change instance->host_lock to hostdata->lock
>>
>
> Makes sense. I think that this should solve the problem:
>
> Index: linux/drivers/scsi/NCR5380.c
> ===
> --- linux.orig/drivers/scsi/NCR5380.c 2015-11-27 09:21:40.0 +1100
> +++ linux/drivers/scsi/NCR5380.c2015-11-27 09:25:36.0 +1100
> @@ -230,7 +230,7 @@ static int NCR5380_poll_politely2(struct
> unsigned long n;
>
> /* Busy-wait for up to 1 jiffy */
> - n = loops_per_jiffy;
> + n = 1 + loops_per_jiffy / 10;
> do {
> if ((NCR5380_read(reg1) & bit1) == val1)
> return 0;
This still heavily depends on the processing time spent in NCR5380_read().
You should never use a value derived from loops_per_jiffy for a non-empty loop,
as it may take much longer. Always compare with an maximum end time instead.
E.g.:
end = jiffies + 2;/* 1 jiffie + 1 safeguard */
do {
if ((NCR5380_read(reg1) & bit1) == val1)
return 0;
cpu_relax();
} while (time_before(jiffies, end);
And a similar loop for "Busy-wait for up to 20 ms".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] IB/iser: constify iser_reg_ops structure
On 28/11/2015 17:52, Julia Lawall wrote: The iser_reg_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall Thanks, Acked-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] m68k updates for 4.4 (take two)
Hi Linus,
The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
for you to fetch changes up to 21d380e54c30b5b15aa4167e2458bfe4e4862427:
m68k: Wire up mlock2 (2015-11-22 11:35:26 +0100)
Summary:
- Add missing initialization of max_pfn, which is needed to make
selftests/vm/mlock2-tests succeed,
- Wire up new mlock2 syscall.
Geert Uytterhoeven (5):
m68k/mm: motorola - Add missing initialization of max_pfn
m68k/mm: m54xx - Add missing initialization of max_pfn
m68k/mm: sun3 - Add missing initialization of max_pfn and
{min,max}_low_pfn
m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
m68k: Wire up mlock2
arch/m68k/coldfire/m54xx.c | 2 +-
arch/m68k/include/asm/unistd.h | 2 +-
arch/m68k/include/uapi/asm/unistd.h | 1 +
arch/m68k/kernel/setup_no.c | 9 ++---
arch/m68k/kernel/syscalltable.S | 1 +
arch/m68k/mm/motorola.c | 2 +-
arch/m68k/sun3/config.c | 4 ++--
7 files changed, 13 insertions(+), 8 deletions(-)
Thanks for pulling!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 74/71] ncr5380: Enable PDMA for NCR53C400A
Add I/O register mapping for NCR53C400A and enable PDMA mode to
improve performance and fix non-working IRQ.
Tested with HP C2502 (and user-space enabler).
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_NCR5380.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index ce444da..c3abe48 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -324,7 +324,10 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
#endif
break;
case BOARD_NCR53C400A:
+ flags = FLAG_NO_DMA_FIXUP;
+#ifndef PSEUDO_DMA
flags = FLAG_NO_PSEUDO_DMA;
+#endif
ports = ncr_53c400a_ports;
break;
case BOARD_DTC3181E:
@@ -412,6 +415,11 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
hostdata->c400_blk_cnt = 1;
hostdata->c400_host_buf = 4;
}
+ if (overrides[current_override].board == BOARD_NCR53C400A) {
+ hostdata->c400_ctl_status = 9;
+ hostdata->c400_blk_cnt = 10;
+ hostdata->c400_host_buf = 8;
+ }
#else
instance->base = overrides[current_override].NCR5380_map_name;
hostdata->iomem = iomem;
@@ -425,7 +433,8 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
if (NCR5380_init(instance, flags))
goto out_unregister;
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400 ||
+ overrides[current_override].board == BOARD_NCR53C400A)
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 73/71] ncr5380: Use runtime register mapping
Convert compile-time C400_ register mapping to runtime mapping.
This removes the weird negative register offsets and allows adding
additional mappings.
Signed-off-by: Ondrej Zary
---
drivers/scsi/NCR5380.h | 13 +-
drivers/scsi/g_NCR5380.c | 61 ++
drivers/scsi/g_NCR5380.h | 12 ++---
3 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 36779df..0d8ec43 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -163,8 +163,7 @@
/* Write any value to this register to start an ini mode DMA receive */
#define START_DMA_INITIATOR_RECEIVE_REG 7 /* wo */
-#define C400_CONTROL_STATUS_REG NCR53C400_register_offset-8/* rw */
-
+/* C400_CONTROL_STATUS_REG */
#define CSR_RESET 0x80/* wo Resets 53c400 */
#define CSR_53C80_REG 0x80/* ro 5380 registers busy */
#define CSR_TRANS_DIR 0x40/* rw Data transfer direction */
@@ -181,16 +180,6 @@
#define CSR_BASE CSR_53C80_INTR
#endif
-/* Number of 128-byte blocks to be transferred */
-#define C400_BLOCK_COUNTER_REG NCR53C400_register_offset-7 /* rw */
-
-/* Resume transfer after disconnect */
-#define C400_RESUME_TRANSFER_REG NCR53C400_register_offset-6 /* wo */
-
-/* Access to host buffer stack */
-#define C400_HOST_BUFFER NCR53C400_register_offset-4 /* rw */
-
-
/* Note : PHASE_* macros are based on the values of the STATUS register */
#define PHASE_MASK (SR_MSG | SR_CD | SR_IO)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index a9a237f..ce444da 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -253,6 +253,7 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
};
int flags;
struct Scsi_Host *instance;
+ struct NCR5380_hostdata *hostdata;
#ifdef SCSI_G_NCR5380_MEM
unsigned long base;
void __iomem *iomem;
@@ -395,6 +396,7 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
instance = scsi_register(tpnt, sizeof(struct NCR5380_hostdata));
if (instance == NULL)
goto out_release;
+ hostdata = shost_priv(instance);
#ifndef SCSI_G_NCR5380_MEM
instance->io_port =
overrides[current_override].NCR5380_map_name;
@@ -404,18 +406,27 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
* On NCR53C400 boards, NCR5380 registers are mapped 8 past
* the base address.
*/
- if (overrides[current_override].board == BOARD_NCR53C400)
+ if (overrides[current_override].board == BOARD_NCR53C400) {
instance->io_port += 8;
+ hostdata->c400_ctl_status = 0;
+ hostdata->c400_blk_cnt = 1;
+ hostdata->c400_host_buf = 4;
+ }
#else
instance->base = overrides[current_override].NCR5380_map_name;
- ((struct NCR5380_hostdata *)instance->hostdata)->iomem = iomem;
+ hostdata->iomem = iomem;
+ if (overrides[current_override].board == BOARD_NCR53C400) {
+ hostdata->c400_ctl_status = 0x100;
+ hostdata->c400_blk_cnt = 0x101;
+ hostdata->c400_host_buf = 0x104;
+ }
#endif
if (NCR5380_init(instance, flags))
goto out_unregister;
if (overrides[current_override].board == BOARD_NCR53C400)
- NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE);
+ NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_maybe_reset_bus(instance);
@@ -523,30 +534,28 @@ generic_NCR5380_biosparam(struct scsi_device *sdev,
struct block_device *bdev,
static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char
*dst, int len)
{
-#ifdef SCSI_G_NCR5380_MEM
struct NCR5380_hostdata *hostdata = shost_priv(instance);
-#endif
int blocks = len / 128;
int start = 0;
int bl;
- NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE | CSR_TRANS_DIR);
- NCR5380_write(C400_BLOCK_COUNTER_REG, blocks);
+ NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
+ NCR5380_write(hostdata->c400_blk_cnt, blocks);
while (1) {
- if ((bl = NCR5380_read(C400_BLOCK_COUNTER_REG)) == 0) {
+ if ((bl = NCR5380_read(hostdata->c400_blk_cnt)) == 0) {
break;
}
- if (NCR5380_read(C400_CONTROL_STATUS_REG) &
CSR_GATED_53C80_IRQ) {
+ if (NCR5380_read(hostdata->c400_ctl_status) &
CSR_GATED_53C80_IRQ) {
printk(KERN_ERR "53C400r: Got 53C80_IRQ start=%d,
blocks=%d\n", s
Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL
Hello Jarkko,
On Sat, Nov 28, 2015 at 06:34:47PM +0200, Jarkko Sakkinen wrote:
> On Thu, Nov 26, 2015 at 08:01:34PM +0100, martin.wi...@ts.fujitsu.com wrote:
> > From: Martin Wilck
> >
> > Since b8b2c7d845d5, platform_drv_probe() is called for all platform
> > devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
> > platform_drv_probe() will return the error code from dev_pm_domain_attach().
> >
> > This causes real_probe() to enter the "probe_failed" path and set
> > dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume
> > success if both dev->bus->probe and drv->probe are missing.
> >
> > This may cause a panic later. For example, inserting the tpm_tis
> > driver with parameter "force=1" (i.e. registering tpm_tis as a platform
> > driver) will panic in tpmm_chip_alloc() because dev->driver is NULL:
> >
> > chip->cdev.owner = chip->pdev->driver->owner;
> >
> > This patch fixes this by returning success in platform_drv_probe() if
> > "just" dev_pm_domain_attach() had failed. This restores the semantics
> > of platform_device_register_XXX() if the associated platform driver has
> > no "probe" function.
> >
> > Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain
> > callbacks are called unconditionally")
> >
> > Signed-off-by: Martin Wilck
>
> Acked-by: Jarkko Sakkinen
While the patch is fine, the commit log is not. It blames b8b2c7d845d5
to be responsible for a panic, but in fact it only breaks the wrong
assumption of the tpm_tis driver.
So I'm not sure how to interpret your Ack, IMHO it should not make
gregkh pick up the patch as is.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 75/71] ncr5380: Remove FLAG_DTC3181E
The FLAG_DTC3181E is used to activate a work-around for arbitration lost
condition that these chips see when ICR is written during arbitration.
Move the ICR write (to set SEL and BSY) after the arbitration loss check
and remove FLAG_DTC3181E.
Signed-off-by: Ondrej Zary
---
Weird, we now have two consecutive checks for ICR_ARBITRATION_LOST and
do different things when they fail...
drivers/scsi/NCR5380.c | 23 +--
drivers/scsi/NCR5380.h |1 -
drivers/scsi/atari_NCR5380.c | 23 +--
drivers/scsi/dmx3191d.c |2 +-
drivers/scsi/g_NCR5380.c |2 +-
5 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index acb359a..b617f99 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -482,14 +482,13 @@ static void prepare_info(struct Scsi_Host *instance)
"base 0x%lx, irq %d, "
"can_queue %d, cmd_per_lun %d, "
"sg_tablesize %d, this_id %d, "
-"flags { %s%s%s%s}, "
+"flags { %s%s%s}, "
"options { %s} ",
instance->hostt->name, instance->io_port, instance->n_io_port,
instance->base, instance->irq,
instance->can_queue, instance->cmd_per_lun,
instance->sg_tablesize, instance->this_id,
hostdata->flags & FLAG_NO_DMA_FIXUP ? "NO_DMA_FIXUP " : "",
-hostdata->flags & FLAG_DTC3181E ? "DTC3181E " : "",
hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY " : "",
#ifdef AUTOPROBE_IRQ
@@ -1078,18 +1077,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host
*instance,
goto out;
}
- /* After/during arbitration, BSY should be asserted.
-* IBM DPES-31080 Version S31Q works now
-* Tnx to thomas_roe...@m2.maus.de for finding this! (Roman)
-*/
- NCR5380_write(INITIATOR_COMMAND_REG,
- ICR_BASE | ICR_ASSERT_SEL | ICR_ASSERT_BSY);
-
- /* RvC: DTC3181E has some trouble with this so we simply removed it.
-* Seems to work with only Mustek scanner attached.
-*/
- if (!(hostdata->flags & FLAG_DTC3181E) &&
- (NCR5380_read(INITIATOR_COMMAND_REG) & ICR_ARBITRATION_LOST)) {
+ if (NCR5380_read(INITIATOR_COMMAND_REG) & ICR_ARBITRATION_LOST) {
NCR5380_write(MODE_REG, MR_BASE);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
dsprintk(NDEBUG_ARBITRATION, instance, "arbitration lost,
negating SEL\n");
@@ -1097,6 +1085,13 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host
*instance,
goto out;
}
+ /* After/during arbitration, BSY should be asserted.
+* IBM DPES-31080 Version S31Q works now
+* Tnx to thomas_roe...@m2.maus.de for finding this! (Roman)
+*/
+ NCR5380_write(INITIATOR_COMMAND_REG,
+ ICR_BASE | ICR_ASSERT_SEL | ICR_ASSERT_BSY);
+
/*
* Again, bus clear + bus settle time is 1.2us, however, this is
* a minimum so we'll udelay ceil(1.2)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 0d8ec43..5092580 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -222,7 +222,6 @@
#define FLAG_NO_DMA_FIXUP 1 /* No DMA errata workarounds */
#define FLAG_NO_PSEUDO_DMA 8 /* Inhibit DMA */
-#define FLAG_DTC3181E 16 /* DTC3181E */
#define FLAG_LATE_DMA_SETUP32 /* Setup NCR before DMA H/W */
#define FLAG_TAGGED_QUEUING64 /* as X3T9.2 spelled it */
#define FLAG_TOSHIBA_DELAY 128 /* Allow for borken CD-ROMs */
diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index d04374d..7640110 100644
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -586,13 +586,12 @@ static void prepare_info(struct Scsi_Host *instance)
"base 0x%lx, irq %d, "
"can_queue %d, cmd_per_lun %d, "
"sg_tablesize %d, this_id %d, "
-"flags { %s%s%s}, "
+"flags { %s%s}, "
"options { %s} ",
instance->hostt->name, instance->io_port, instance->n_io_port,
instance->base, instance->irq,
instance->can_queue, instance->cmd_per_lun,
instance->sg_tablesize, instance->this_id,
-hostdata->flags & FLAG_DTC3181E ? "DTC3181E " : "",
hostdata->flags & FLAG_TAGGED_QUEUING ? "TAGGED_QUEUING " : "",
hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY " : "",
#ifdef DIFFERENTIAL
@@ -1279,18 +1278,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host
Re: [PATCH 3/4] gpio: pxa: change the interrupt management
kbuild test robot writes:
> Hi Robert,
>
> [auto build test ERROR on: gpio/for-next]
> [also build test ERROR on: v4.4-rc2 next-20151127]
>
> url:
> https://github.com/0day-ci/linux/commits/Robert-Jarzmik/gpio-pxa-integrate-with-pincontrol/20151129-054738
> base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> for-next
> config: arm-pxa910_defconfig (attached as .config)
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>drivers/gpio/gpio-pxa.c: In function 'pxa_gpio_probe':
>>> drivers/gpio/gpio-pxa.c:625:12: error: 'pxa_irq_domain_ops' undeclared
>>> (first use in this function)
>0, &pxa_irq_domain_ops, pchip);
>^
>drivers/gpio/gpio-pxa.c:625:12: note: each undeclared identifier is
> reported only once for each function it appears in
>drivers/gpio/gpio-pxa.c: At top level:
>drivers/gpio/gpio-pxa.c:500:24: warning: 'pxa_muxed_gpio_chip' defined but
> not used [-Wunused-variable]
> static struct irq_chip pxa_muxed_gpio_chip = {
Ok, that one is a matter of "#ifdef CONFIG_OF" englobbing pxa_irq_domain_ops and
pxa_irq_domain_map().
Didn't see it as the platform_data based test has CONFIG_OF activated in my
kernel. That will be for v2, and tested without the CONFIG_OF to be sure.
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 22/71] ncr5380: Eliminate selecting state
On Sun, 29 Nov 2015, Geert Uytterhoeven wrote:
> This still heavily depends on the processing time spent in
> NCR5380_read(). You should never use a value derived from
> loops_per_jiffy for a non-empty loop,
Sure but the time-out condition isn't supposed to be precise.
Plus/minus a jiffy is no problem. Plus/minus a second is no good.
> as it may take much longer. Always compare with an maximum end time
> instead.
That can't work with interrupts disabled, which was the problem I was
trying to solve by use of loops_per_jiffy.
NCR5380_poll_politely() in mainline doesn't work with interrupts disabled
either, hence patch 21.
>
> E.g.:
>
> end = jiffies + 2;/* 1 jiffie + 1 safeguard */
> do {
> if ((NCR5380_read(reg1) & bit1) == val1)
> return 0;
> cpu_relax();
> } while (time_before(jiffies, end);
>
> And a similar loop for "Busy-wait for up to 20 ms".
Interrupts may be disabled during that loop also. Please refer to (and/or
respond to) patch 21, "ncr5380: Sleep when polling, if possible", in which
these changes were made.
--
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hid: usbhid: hid-core: fix recursive deadlock
On Fri, 20 Nov 2015 22:19:02 +0200
Ioan-Adrian Ratiu wrote:
> The critical section protected by usbhid->lock in hid_ctrl() is too
> big and because of this it causes a recursive deadlock. "Too big" means
> the case statement and the call to hid_input_report() do not need to be
> protected by the spinlock (no URB operations are done inside them).
>
> The deadlock happens because in certain rare cases drivers try to grab
> the lock while handling the ctrl irq which grabs the lock before them
> as described above. For example newer wacom tablets like 056a:033c try
> to reschedule proximity reads from wacom_intuos_schedule_prox_event()
> calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
> which tries to grab the usbhid lock already held by hid_ctrl().
>
> There are two ways to get out of this deadlock:
> 1. Make the drivers work "around" the ctrl critical region, in the
> wacom case for ex. by delaying the scheduling of the proximity read
> request itself to a workqueue.
> 2. Shrink the critical region so the usbhid lock protects only the
> instructions which modify usbhid state, calling hid_input_report()
> with the spinlock unlocked, allowing the device driver to grab the
> lock first, finish and then grab the lock afterwards in hid_ctrl().
>
> This patch implements the 2nd solution.
>
> Signed-off-by: Ioan-Adrian Ratiu
> ---
> drivers/hid/usbhid/hid-core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 36712e9..5dd426f 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -477,8 +477,6 @@ static void hid_ctrl(struct urb *urb)
> struct usbhid_device *usbhid = hid->driver_data;
> int unplug = 0, status = urb->status;
>
> - spin_lock(&usbhid->lock);
> -
> switch (status) {
> case 0: /* success */
> if (usbhid->ctrl[usbhid->ctrltail].dir == USB_DIR_IN)
> @@ -498,6 +496,8 @@ static void hid_ctrl(struct urb *urb)
> hid_warn(urb->dev, "ctrl urb status %d received\n", status);
> }
>
> + spin_lock(&usbhid->lock);
> +
> if (unplug) {
> usbhid->ctrltail = usbhid->ctrlhead;
> } else {
Hello again
Can this please be merged in the 4.4? There are quite a few people who have
their tablets deadlock and don't know how to patch their kernels so are stuck
waiting for a new release.
The severity of this issue is much bigger than I initially thought. Since I've
posted on the wacom mailing list that I have a fix for this deadlock I've
recived lots of email from people complaining of the same problem on a wide
range of tablets.
Some of those people know how to patch a kernel, some found this patch on the
mailing list and tested it and confirmed that it works on the wacom mailing
list (you can verify the deadlock + fix on that mailing list).
Thank you,
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
overriding ACPI _CRS method
In firmware that is loaded after the BIOS, I need to trim the root bus resource (0x4000-0xdfff) covering the MMIO window [1], so I can attach further PCI domains. One strategy is to override the BIOS's DSDT [2] _SB.PCI0._CRS method; even when my firmware appends the bytecode for a new _CRS method [3], alas I see AE_ALREADY_EXISTS [4]. I understood methods were overrideable within the same table (eg not from an SSDT), but perhaps am missing something? Or any better approach to reduce the scope of the PCI domain root bus? Thanks! Daniel -- [1] pci_bus :00: root bus resource [io 0x-0x03af window] pci_bus :00: root bus resource [io 0x03e0-0x0cf7 window] pci_bus :00: root bus resource [io 0x03b0-0x03bb window] pci_bus :00: root bus resource [io 0x03c0-0x03df window] pci_bus :00: root bus resource [io 0x8000-0xdfff window] pci_bus :00: root bus resource [mem 0x000a-0x000b window] pci_bus :00: root bus resource [mem 0xf000-0x window] pci_bus :00: root bus resource [mem 0x000d-0x000d window] pci_bus :00: root bus resource [mem 0x4000-0xdfff window] pci_bus :00: root bus resource [bus 00-04] [2] https://resources.numascale.com/DSDT.dsl [3] https://resources.numascale.com/DSDT-extra.dsl -- [4] ACPI: Core revision 20150930 ACPI Error: [_CRS] Namespace lookup failure, AE_ALREADY_EXISTS (20150930/dswload-378) ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20150930/psobject-227) ACPI Exception: AE_ALREADY_EXISTS, [DSDT] table load failed (20150930/tbxfload-163) ACPI Error: [\_PR_.P001] Namespace lookup failure, AE_NOT_FOUND (20150930/dswload-210) ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150930/psobject-227) ACPI Exception: AE_NOT_FOUND, (SSDT:POWERNOW) while loading table (20150930/tbxfload-193) ACPI Error: 2 table load failures, 0 successful (20150930/tbxfload-214) -- Daniel J Blueman Principal Software Engineer, Numascale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > * PaX Team wrote: > > > i don't see the compile time vs. runtime detection as 'competing' > > approaches, > > both have their own role. [...] > > That's true - but only as long as 'this can be solved in tooling!' is not > used as > an excuse to oppose the runtime solution and we end up doing neither. actually, i already voiced my opinion elsewhere in the constify thread on the kernel hardening list that adding/using __read_only is somewhat premature without also adding the compile time verification part (as part of the constify plugin for example). right now its use on the embedded vdso image is simple and easy to verify but once people begin to add it to variables that the compiler knows and cares about (say, the ops structures) then things can become fragile without compile checking. so yes, i'd also advise to get such tooling in *before* more __read_only usage is added. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: block: Always check queue limits for cloned requests
On 2015.11.26 at 08:11 -0500, Mike Snitzer wrote:
> On Thu, Nov 26 2015 at 2:46am -0500,
> Hannes Reinecke wrote:
>
> > When a cloned request is retried on other queues it always needs
> > to be checked against the queue limits of that queue.
> > Otherwise the calculations for nr_phys_segments might be wrong,
> > leading to a crash in scsi_init_sgtable().
> >
> > To clarify this the patch renames blk_rq_check_limits()
> > to blk_cloned_rq_check_limits() and removes the symbol
> > export, as the new function should only be used for
> > cloned requests and never exported.
> >
> > Cc: Mike Snitzer
> > Cc: Ewan Milne
> > Cc: Jeff Moyer
> > Signed-off-by: Hannes Reinecke
>
> Patch looks good. Thanks for getting to the bottom of this.
>
> Jens, please add these extra tags when you pick this up:
>
> Fixes: e2a60da74 ("block: Clean up special command handling logic")
> Cc: sta...@vger.kernel.org # 3.7+
> Acked-by: Mike Snitzer
I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even
with this patch applied.
markus@x4 linux % git describe
v4.4-rc2-215-g081f3698e606
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM: sunxi: Introduce Allwinner for A83T support
Hello, Sorry for delayed response. On Fri, Oct 23, 2015 at 9:37 AM, Chen-Yu Tsai wrote: > On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar > wrote: >> Allwinner A83T is octa-core cortex-a7 based SoC. >> It's clock control unit and prcm, pinmux are different from previous sun8i >> series. >> Its processor cores are arragned in two clusters 4 cores each, >> similar to A80. >> >> Signed-off-by: Vishnu Patekar > > Could you also update Documentation/arm/sunxi/README, so it says A83T > is supported? I'll update and send next version. > > Otherwise, > > Acked-by: Chen-Yu Tsai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
Acked-by: Rob Herring
---
Changes for v11:
-> Changed data types of bridge, pcie controller and ecam base address
-> Added programming of E_BREG_BASE_HI, E_ECAM_BASE_HI registers
-> Removed MSI_ADDRESS macro, and using value from device tree
-> Removed unneccessary type casting in nwl_pcie_bridge_init function.
-> Removed mdelay and using msleep in nwl_pcie_bridge_init function.
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1072
4 files changed, 1151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+ configuration sapce, and length
+- reg-names: Must include the following entries:
+ "breg": bridge registers
+ "pcireg": PCIe controller registers
+ "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+ "msi1, msi0": interrupt asserted when msi is received
+ "intx": interrupt that is asserted when an legacy interrupt is received
+ "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+ mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+ Please refer to the standard PCI bus binding document for a more
+ detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent: MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy
interrupts
+ - interrupt-controller: identifies the node as an interrupt controller
+ - #interrupt-cells: should be set to 1
+ - #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "xlnx,nwl-pcie-2.11";
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+ interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+ msi-parent = <&nwl_pcie>;
+ reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x0200 0x 0xe100 0x 0xe100 0
0x0f00>;
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
+config PCIE_XILINX_NWL
+ bool "NWL PCIe Core"
+ depends on ARCH_ZYNQMP
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
config PCIE_DW
bool
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ767650805给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec
Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5) and SRQ notifications with fasync (2/5) and poll/select (3/5) in order to be able to synchronize with variable duration instrument operations. Add ioctls for other USB488 requests: REN_CONTROL, GOTO_LOCAL and LOCAL_LOCKOUT. (4/5) Add convenience ioctl to return all device capabilities (5/5) PATCH Changelog: v6 - Remove more excess newlines Rearrange declaration blocks aesthetically Remove __func__ parameter from dev_xxx calls Simplify tests for interrupt-in notifications Propagate return code from usb_submit_urb() v5 - Remove excess newlines and parens - Move dev variable initialisations to declaration - Add comment on interrupt btag wrap - simplify test in usbtmc_free_int() v4 - Remove excess newlines and parens - simplify some expressions v3 - Split into multiple patches as per gregkh request V2 - Fix V1 bug: not waking sleepers on disconnect. - Correct sparse warnings. V1 - Original patch Testing: All functions tested ok on an USBTMC-USB488 compliant oscilloscope Dave Penkler (5): Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation. Add support for USBTMC USB488 SRQ notification with fasync Add support for receiving USBTMC USB488 SRQ notifications via poll/select Add ioctl to retrieve USBTMC-USB488 capabilities Add ioctls to enable and disable local controls on an instrument drivers/usb/class/usbtmc.c | 330 +++ include/uapi/linux/usb/tmc.h | 29 +++- 2 files changed, 356 insertions(+), 3 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/5] Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.
Background:
When performing a read on an instrument that is executing a function
that runs longer than the USB timeout the instrument may hang and
require a device reset to recover. The READ_STATUS_BYTE operation
always returns even when the instrument is busy permitting to poll
for the appropriate condition. This capability is referred to in
instrument application notes on synchronizing acquisitions for other
platforms.
Signed-off-by: Dave Penkler
---
drivers/usb/class/usbtmc.c | 200 +++
include/uapi/linux/usb/tmc.h | 2 +
2 files changed, 202 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 7a11a82..89456df9 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -87,6 +87,19 @@ struct usbtmc_device_data {
u8 bTag_last_write; /* needed for abort */
u8 bTag_last_read; /* needed for abort */
+ /* data for interrupt in endpoint handling */
+ u8 bNotify1;
+ u8 bNotify2;
+ u16ifnum;
+ u8 iin_bTag;
+ u8*iin_buffer;
+ atomic_t iin_data_valid;
+ unsigned int iin_ep;
+ intiin_ep_present;
+ intiin_interval;
+ struct urb*iin_urb;
+ u16iin_wMaxPacketSize;
+
u8 rigol_quirk;
/* attributes from the USB TMC spec for this device */
@@ -99,6 +112,7 @@ struct usbtmc_device_data {
struct usbtmc_dev_capabilities capabilities;
struct kref kref;
struct mutex io_mutex; /* only one i/o function running at a time */
+ wait_queue_head_t waitq;
};
#define to_usbtmc_data(d) container_of(d, struct usbtmc_device_data, kref)
@@ -373,6 +387,83 @@ exit:
return rv;
}
+static int usbtmc488_ioctl_read_stb(struct usbtmc_device_data *data,
+ unsigned long arg)
+{
+ struct device *dev = &data->intf->dev;
+ u8 *buffer;
+ u8 tag, stb;
+ int rv;
+
+ dev_dbg(dev, "Enter ioctl_read_stb iin_ep_present: %d\n",
+ data->iin_ep_present);
+
+ buffer = kmalloc(8, GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
+
+ atomic_set(&data->iin_data_valid, 0);
+
+ rv = usb_control_msg(data->usb_dev,
+ usb_rcvctrlpipe(data->usb_dev, 0),
+ USBTMC488_REQUEST_READ_STATUS_BYTE,
+ USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ data->iin_bTag,
+ data->ifnum,
+ buffer, 0x03, USBTMC_TIMEOUT);
+ if (rv < 0) {
+ dev_err(dev, "stb usb_control_msg returned %d\n", rv);
+ goto exit;
+ }
+
+ if (buffer[0] != USBTMC_STATUS_SUCCESS) {
+ dev_err(dev, "control status returned %x\n", buffer[0]);
+ rv = -EIO;
+ goto exit;
+ }
+
+ if (data->iin_ep_present) {
+ rv = wait_event_interruptible_timeout(
+ data->waitq,
+ atomic_read(&data->iin_data_valid) != 0,
+ USBTMC_TIMEOUT);
+ if (rv < 0) {
+ dev_dbg(dev, "wait interrupted %d\n", rv);
+ goto exit;
+ }
+
+ if (rv == 0) {
+ dev_dbg(dev, "wait timed out\n");
+ rv = -ETIME;
+ goto exit;
+ }
+
+ tag = data->bNotify1 & 0x7f;
+ if (tag != data->iin_bTag) {
+ dev_err(dev, "expected bTag %x got %x\n",
+ data->iin_bTag, tag);
+ }
+
+ stb = data->bNotify2;
+ } else {
+ stb = buffer[2];
+ }
+
+ rv = copy_to_user((void __user *)arg, &stb, sizeof(stb));
+ if (rv)
+ rv = -EFAULT;
+
+ exit:
+ /* bump interrupt bTag */
+ data->iin_bTag += 1;
+ if (data->iin_bTag > 127)
+ /* 1 is for SRQ see USBTMC-USB488 subclass spec section 4.3.1 */
+ data->iin_bTag = 2;
+
+ kfree(buffer);
+ return rv;
+}
+
/*
* Sends a REQUEST_DEV_DEP_MSG_IN message on the Bulk-IN endpoint.
* @transfer_size: number of bytes to request from the device.
@@ -1069,6 +1160,10 @@ static long usbtmc_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case USBTMC_IOCTL_ABORT_BULK_IN:
retval = usbtmc_ioctl_abort_bulk_in(data);
break;
+
+ case USBTMC488_IOCTL_READ_STB:
+ retval = usbtmc488_ioctl_read_stb(data, arg);
+ break;
}
skip_io_on_zombie:
@@ -1092,6 +1187,57 @@ static struct usb_class_driver usbtmc_class = {
.minor_base = USBTMC_MINOR_BASE,
};
+static void usbtmc_interrupt(struct urb *urb)
+{
+ struc
[PATCH v6 2/5] Add support for USBTMC USB488 SRQ notification with fasync
Background:
By configuring an instrument's event status register various
conditions can be reported via an SRQ notification. This complements
the synchronous polling approach using the READ_STATUS_BYTE ioctl
with an asynchronous notification.
Signed-off-by: Dave Penkler
---
drivers/usb/class/usbtmc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 89456df9..7bfd6ec 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -99,6 +99,7 @@ struct usbtmc_device_data {
intiin_interval;
struct urb*iin_urb;
u16iin_wMaxPacketSize;
+ atomic_t srq_asserted;
u8 rigol_quirk;
@@ -113,6 +114,7 @@ struct usbtmc_device_data {
struct kref kref;
struct mutex io_mutex; /* only one i/o function running at a time */
wait_queue_head_t waitq;
+ struct fasync_struct *fasync;
};
#define to_usbtmc_data(d) container_of(d, struct usbtmc_device_data, kref)
@@ -404,6 +406,9 @@ static int usbtmc488_ioctl_read_stb(struct
usbtmc_device_data *data,
atomic_set(&data->iin_data_valid, 0);
+ /* must issue read_stb before using poll or select */
+ atomic_set(&data->srq_asserted, 0);
+
rv = usb_control_msg(data->usb_dev,
usb_rcvctrlpipe(data->usb_dev, 0),
USBTMC488_REQUEST_READ_STATUS_BYTE,
@@ -1171,6 +1176,13 @@ skip_io_on_zombie:
return retval;
}
+static int usbtmc_fasync(int fd, struct file *file, int on)
+{
+ struct usbtmc_device_data *data = file->private_data;
+
+ return fasync_helper(fd, file, on, &data->fasync);
+}
+
static const struct file_operations fops = {
.owner = THIS_MODULE,
.read = usbtmc_read,
@@ -1178,6 +1190,7 @@ static const struct file_operations fops = {
.open = usbtmc_open,
.release= usbtmc_release,
.unlocked_ioctl = usbtmc_ioctl,
+ .fasync = usbtmc_fasync,
.llseek = default_llseek,
};
@@ -1207,6 +1220,16 @@ static void usbtmc_interrupt(struct urb *urb)
wake_up_interruptible(&data->waitq);
goto exit;
}
+ /* check for SRQ notification */
+ if (data->iin_buffer[0] == 0x81) {
+ if (data->fasync)
+ kill_fasync(&data->fasync,
+ SIGIO, POLL_IN);
+
+ atomic_set(&data->srq_asserted, 1);
+ wake_up_interruptible(&data->waitq);
+ goto exit;
+ }
dev_warn(dev, "invalid notification: %x\n",
data->iin_buffer[0]);
break;
case -EOVERFLOW:
@@ -1262,6 +1285,7 @@ static int usbtmc_probe(struct usb_interface *intf,
mutex_init(&data->io_mutex);
init_waitqueue_head(&data->waitq);
atomic_set(&data->iin_data_valid, 0);
+ atomic_set(&data->srq_asserted, 0);
data->zombie = 0;
/* Determine if it is a Rigol or not */
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/5] Add support for receiving USBTMC USB488 SRQ notifications via poll/select
Background:
In many situations operations on multiple instruments need to be
synchronized. poll/select provide a convenient way of waiting on a
number of different instruments and other peripherals
simultaneously.
Signed-off-by: Dave Penkler
---
drivers/usb/class/usbtmc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 7bfd6ec..3b85ef5 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1183,6 +1184,27 @@ static int usbtmc_fasync(int fd, struct file *file, int
on)
return fasync_helper(fd, file, on, &data->fasync);
}
+static unsigned int usbtmc_poll(struct file *file, poll_table *wait)
+{
+ struct usbtmc_device_data *data = file->private_data;
+ unsigned int mask;
+
+ mutex_lock(&data->io_mutex);
+
+ if (data->zombie) {
+ mask = POLLHUP | POLLERR;
+ goto no_poll;
+ }
+
+ poll_wait(file, &data->waitq, wait);
+
+ mask = (atomic_read(&data->srq_asserted)) ? POLLIN | POLLRDNORM : 0;
+
+no_poll:
+ mutex_unlock(&data->io_mutex);
+ return mask;
+}
+
static const struct file_operations fops = {
.owner = THIS_MODULE,
.read = usbtmc_read,
@@ -1191,6 +1213,7 @@ static const struct file_operations fops = {
.release= usbtmc_release,
.unlocked_ioctl = usbtmc_ioctl,
.fasync = usbtmc_fasync,
+ .poll = usbtmc_poll,
.llseek = default_llseek,
};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 4/5] Add ioctl to retrieve USBTMC-USB488 capabilities
This is a convenience function to obtain an instrument's
capabilities from its file descriptor without having to access sysfs
from the user program.
Signed-off-by: Dave Penkler
---
drivers/usb/class/usbtmc.c | 12
include/uapi/linux/usb/tmc.h | 21 ++---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 3b85ef5..3a3264c 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -102,6 +102,9 @@ struct usbtmc_device_data {
u16iin_wMaxPacketSize;
atomic_t srq_asserted;
+ /* coalesced usb488_caps from usbtmc_dev_capabilities */
+ u8 usb488_caps;
+
u8 rigol_quirk;
/* attributes from the USB TMC spec for this device */
@@ -992,6 +995,7 @@ static int get_capabilities(struct usbtmc_device_data *data)
data->capabilities.device_capabilities = buffer[5];
data->capabilities.usb488_interface_capabilities = buffer[14];
data->capabilities.usb488_device_capabilities = buffer[15];
+ data->usb488_caps = (buffer[14] & 0x07) | ((buffer[15] & 0x0f) << 4);
rv = 0;
err_out:
@@ -1167,6 +1171,14 @@ static long usbtmc_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
retval = usbtmc_ioctl_abort_bulk_in(data);
break;
+ case USBTMC488_IOCTL_GET_CAPS:
+ retval = copy_to_user((void __user *)arg,
+ &data->usb488_caps,
+ sizeof(data->usb488_caps));
+ if (retval)
+ retval = -EFAULT;
+ break;
+
case USBTMC488_IOCTL_READ_STB:
retval = usbtmc488_ioctl_read_stb(data, arg);
break;
diff --git a/include/uapi/linux/usb/tmc.h b/include/uapi/linux/usb/tmc.h
index 7e5ced8..1dc3af1 100644
--- a/include/uapi/linux/usb/tmc.h
+++ b/include/uapi/linux/usb/tmc.h
@@ -2,12 +2,14 @@
* Copyright (C) 2007 Stefan Kopp, Gechingen, Germany
* Copyright (C) 2008 Novell, Inc.
* Copyright (C) 2008 Greg Kroah-Hartman
+ * Copyright (C) 2015 Dave Penkler
*
* This file holds USB constants defined by the USB Device Class
- * Definition for Test and Measurement devices published by the USB-IF.
+ * and USB488 Subclass Definitions for Test and Measurement devices
+ * published by the USB-IF.
*
- * It also has the ioctl definitions for the usbtmc kernel driver that
- * userspace needs to know about.
+ * It also has the ioctl and capability definitions for the
+ * usbtmc kernel driver that userspace needs to know about.
*/
#ifndef __LINUX_USB_TMC_H
@@ -40,6 +42,19 @@
#define USBTMC_IOCTL_ABORT_BULK_IN _IO(USBTMC_IOC_NR, 4)
#define USBTMC_IOCTL_CLEAR_OUT_HALT_IO(USBTMC_IOC_NR, 6)
#define USBTMC_IOCTL_CLEAR_IN_HALT _IO(USBTMC_IOC_NR, 7)
+#define USBTMC488_IOCTL_GET_CAPS _IO(USBTMC_IOC_NR, 17)
#define USBTMC488_IOCTL_READ_STB _IOR(USBTMC_IOC_NR, 18, unsigned char)
+/* Driver encoded usb488 capabilities */
+#define USBTMC488_CAPABILITY_TRIGGER 1
+#define USBTMC488_CAPABILITY_SIMPLE 2
+#define USBTMC488_CAPABILITY_REN_CONTROL 2
+#define USBTMC488_CAPABILITY_GOTO_LOCAL 2
+#define USBTMC488_CAPABILITY_LOCAL_LOCKOUT 2
+#define USBTMC488_CAPABILITY_488_DOT_2 4
+#define USBTMC488_CAPABILITY_DT1 16
+#define USBTMC488_CAPABILITY_RL1 32
+#define USBTMC488_CAPABILITY_SR1 64
+#define USBTMC488_CAPABILITY_FULL_SCPI 128
+
#endif
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 5/5] Add ioctls to enable and disable local controls on an instrument
These ioctls provide support for the USBTMC-USB488 control requests
for REN_CONTROL, GO_TO_LOCAL and LOCAL_LOCKOUT
Signed-off-by: Dave Penkler
---
drivers/usb/class/usbtmc.c | 71
include/uapi/linux/usb/tmc.h | 6
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 3a3264c..f04a086 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -473,6 +473,62 @@ static int usbtmc488_ioctl_read_stb(struct
usbtmc_device_data *data,
return rv;
}
+static int usbtmc488_ioctl_simple(struct usbtmc_device_data *data,
+ unsigned long arg,
+ unsigned int cmd)
+{
+ struct device *dev = &data->intf->dev;
+ unsigned int val;
+ u8 *buffer;
+ u16 wValue;
+ int rv;
+
+ if (!(data->usb488_caps & USBTMC488_CAPABILITY_SIMPLE))
+ return -EINVAL;
+
+ buffer = kmalloc(8, GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
+
+ if (cmd == USBTMC488_REQUEST_REN_CONTROL) {
+ rv = copy_from_user(&val, (void __user *)arg, sizeof(val));
+ if (rv) {
+ rv = -EFAULT;
+ goto exit;
+ }
+ wValue = val ? 1 : 0;
+ } else {
+ wValue = 0;
+ }
+
+ rv = usb_control_msg(data->usb_dev,
+ usb_rcvctrlpipe(data->usb_dev, 0),
+ cmd,
+ USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ wValue,
+ data->ifnum,
+ buffer, 0x01, USBTMC_TIMEOUT);
+ if (rv < 0) {
+ dev_err(dev, "simple usb_control_msg failed %d\n", rv);
+ goto exit;
+ } else if (rv != 1) {
+ dev_warn(dev, "simple usb_control_msg returned %d\n", rv);
+ rv = -EIO;
+ goto exit;
+ }
+
+ if (buffer[0] != USBTMC_STATUS_SUCCESS) {
+ dev_err(dev, "simple control status returned %x\n", buffer[0]);
+ rv = -EIO;
+ goto exit;
+ }
+ rv = 0;
+
+ exit:
+ kfree(buffer);
+ return rv;
+}
+
/*
* Sends a REQUEST_DEV_DEP_MSG_IN message on the Bulk-IN endpoint.
* @transfer_size: number of bytes to request from the device.
@@ -1182,6 +1238,21 @@ static long usbtmc_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case USBTMC488_IOCTL_READ_STB:
retval = usbtmc488_ioctl_read_stb(data, arg);
break;
+
+ case USBTMC488_IOCTL_REN_CONTROL:
+ retval = usbtmc488_ioctl_simple(data, arg,
+ USBTMC488_REQUEST_REN_CONTROL);
+ break;
+
+ case USBTMC488_IOCTL_GOTO_LOCAL:
+ retval = usbtmc488_ioctl_simple(data, arg,
+ USBTMC488_REQUEST_GOTO_LOCAL);
+ break;
+
+ case USBTMC488_IOCTL_LOCAL_LOCKOUT:
+ retval = usbtmc488_ioctl_simple(data, arg,
+
USBTMC488_REQUEST_LOCAL_LOCKOUT);
+ break;
}
skip_io_on_zombie:
diff --git a/include/uapi/linux/usb/tmc.h b/include/uapi/linux/usb/tmc.h
index 1dc3af1..0d852c9 100644
--- a/include/uapi/linux/usb/tmc.h
+++ b/include/uapi/linux/usb/tmc.h
@@ -33,6 +33,9 @@
#define USBTMC_REQUEST_GET_CAPABILITIES7
#define USBTMC_REQUEST_INDICATOR_PULSE 64
#define USBTMC488_REQUEST_READ_STATUS_BYTE 128
+#define USBTMC488_REQUEST_REN_CONTROL 160
+#define USBTMC488_REQUEST_GOTO_LOCAL 161
+#define USBTMC488_REQUEST_LOCAL_LOCKOUT162
/* Request values for USBTMC driver's ioctl entry point */
#define USBTMC_IOC_NR 91
@@ -44,6 +47,9 @@
#define USBTMC_IOCTL_CLEAR_IN_HALT _IO(USBTMC_IOC_NR, 7)
#define USBTMC488_IOCTL_GET_CAPS _IO(USBTMC_IOC_NR, 17)
#define USBTMC488_IOCTL_READ_STB _IOR(USBTMC_IOC_NR, 18, unsigned char)
+#define USBTMC488_IOCTL_REN_CONTROL_IOW(USBTMC_IOC_NR, 19, unsigned char)
+#define USBTMC488_IOCTL_GOTO_LOCAL _IO(USBTMC_IOC_NR, 20)
+#define USBTMC488_IOCTL_LOCAL_LOCKOUT _IO(USBTMC_IOC_NR, 21)
/* Driver encoded usb488 capabilities */
#define USBTMC488_CAPABILITY_TRIGGER 1
--
2.6.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 RESEND 2/2] drm/i915: prevent the vgacon from ever reloading
On Fri, Nov 27, 2015 at 07:37:53PM -0500, Ilia Mirkin wrote: > On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov > wrote: > > On 27 November 2015 at 15:10, Daniel Vetter wrote: > >> It only leads to bloodshed and tears - we don't bother to restore a > >> working legacy vga hw setup. > >> > >> On haswell with the new dynamic power well code this leads to even > >> more hilarity since for some configurations the hardware is simply no > >> longer there. > >> > >> The actual implementation is a bit a hack - we realy on fbcon to kick > >> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n) > >> and VGA_CONSOLE=y i915 already unregisters the vga console manually > >> early in the driver load sequence. > >> > > Interesting... nv50 and later GPUs are in a roughly similar shame > > afaict. They lack the dedicated hardware and no one really bothered > > figuring out how to restore things to a working shape [1]. > > > > Then again, upon sequential load of the nouveau module the GPU gets > > initialised properly, where you can get X (weston?) up and running > > without issues. Am I thinking about a different thing ? > > > > I take it that you guys do less of the (re)initialisation dance, to > > ensure faster boot times ? > > > > Thanks, > > Emil > > > > [1] > > http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau > > FWIW it's possible to unload nouveau, at which point your screen turns > off (because we can't restore the vga emulation junk... haven't the > faintest clue how it works), and then reload it, at which point fbcon > gets rebound and is completely happy. I can't tell what this patch is > doing, but for your own sanity, you should support unloading/reloading > i915 as well. We do of course support unloading/reloading. And we do the same "shut everything down" like nouveau seems to do. The problem though on some hw is that if vgacon then tries to access the registers the hw dies. So the problem we have with not restoring VGA functionality isn't that the screen is black when i915.ko is unloaded, but that the machine dies. This patch fixes that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/2] vgacon: dummy implementation for vgacon_text_force
On Fri, Nov 27, 2015 at 03:29:52PM +, Emil Velikov wrote: > On 27 November 2015 at 15:10, Daniel Vetter wrote: > > This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset > > drivers. > > > > v2: Make the dummy function actually return a sane value, spotted by > > Ville. > > > > Cc: Ville Syrjälä > > Cc: Andrew Morton > > Cc: Greg Kroah-Hartman > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/ast/ast_drv.c | 2 -- > > drivers/gpu/drm/cirrus/cirrus_drv.c | 2 -- > > drivers/gpu/drm/i915/i915_drv.c | 2 -- > > drivers/gpu/drm/mgag200/mgag200_drv.c | 2 -- > > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 -- > > drivers/gpu/drm/qxl/qxl_drv.c | 2 -- > > drivers/gpu/drm/radeon/radeon_drv.c | 2 -- > > include/linux/console.h | 2 ++ > > The new drivers seems to be missing the conversion. Namely amdgpu and > virtio_gpu. Just shows how old this patch is ;-) And it's not going to cause a problem since this patch simply makes the #ifdef redundant. Greg, do you prefer a respin or a fixup patch? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mailbox: constify mbox_chan_ops structure
This mbox_chan_ops structure is never modified, so declare it as const,
like all the other mbox_chan_ops structures.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/mailbox/mailbox-sti.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 4835817..2394cfe 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -384,7 +384,7 @@ static struct mbox_chan *sti_mbox_xlate(struct
mbox_controller *mbox,
return chan;
}
-static struct mbox_chan_ops sti_mbox_ops = {
+static const struct mbox_chan_ops sti_mbox_ops = {
.startup= sti_mbox_startup_chan,
.shutdown = sti_mbox_shutdown_chan,
.send_data = sti_mbox_send_data,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clkdev: Fix of_clk_get_by_name() for consistent return values
When of_clk_get_by_name() is called without name it returns -ENOENT
when the 'clocks' property doesn't exists or is an empty entry.
However when a name is given and the 'clock-names' property doesn't
exists or doesn't contains the requested name it returns -EINVAL.
To get a consistent return value with both code paths we must return
-ENOENT when of_property_match_string() fails.
Signed-off-by: Alban Bedel
---
drivers/clk/clkdev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 779b6ff..99a8803 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -72,7 +72,10 @@ static struct clk *__of_clk_get_by_name(struct device_node
*np,
*/
if (name)
index = of_property_match_string(np, "clock-names",
name);
- clk = __of_clk_get(np, index, dev_id, name);
+ if (index >= 0)
+ clk = __of_clk_get(np, index, dev_id, name);
+ else
+ clk = ERR_PTR(-ENOENT);
if (!IS_ERR(clk)) {
break;
} else if (name && index >= 0) {
--
2.0.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/
undefined reference to `nf_conntrack_untracked'
Hi Pablo, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8003a573560ae96540bce2a698347c6d502e2997 commit: bbde9fc1824aab58bc78c084163007dd6c03fe5b netfilter: factor out packet duplication for IPv4/IPv6 date: 4 months ago config: x86_64-randconfig-s3-11292003 (attached as .config) reproduce: git checkout bbde9fc1824aab58bc78c084163007dd6c03fe5b # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): net/built-in.o: In function `nf_dup_ipv4': >> (.text+0x124cf4): undefined reference to `nf_conntrack_untracked' net/built-in.o: In function `nf_dup_ipv4': (.text+0x124d0d): undefined reference to `nf_conntrack_untracked' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [GIT PULL 00/10] perf/core improvements and fixes
Hi Ingo, On Sat, Nov 28, 2015 at 10:50:19AM +0100, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > > > From: Arnaldo Carvalho de Melo > > > > Hi Ingo, > > > > Please consider applying, > > > > - Arnaldo > > > > The following changes since commit 3f3b1a46bfdbce97dd3f9594d8a95db82baa554b: > > > > Merge tag 'perf-core-for-mingo' of > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > > (2015-11-27 08:28:44 +0100) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > > tags/perf-core-for-mingo > > > > for you to fetch changes up to 0bb93490170477224f8bd4cc9ce8920517461643: > > > > perf bpf: Rename bpf config to program config (2015-11-27 22:00:46 -0300) > > > > > > perf/core improvements and fixes: > > > > User visible: > > > > - Fix 'perf list' segfault due to lack of support for > > PERF_CONF_SW_BPF_OUTPUT > > in an array used just for printing available events, robustify the code > > involved (Arnaldo Carvalho de Melo) > > > > - 'perf test unwind' should create kernel maps, now that entry works and the > > test passes (Jiri Olsa) > > > > - Fix showing the running kernel build id in 'perf buildid-list' (Michael > > Petlan) > > > > - Fix command line symbol filtering in 'perf report' (Namhyung Kim) > > > > Infrastructure: > > > > - Extract and collect map info from BPF object files in libbpf (Wang Nan) > > > > Signed-off-by: Arnaldo Carvalho de Melo > > > > > > Arnaldo Carvalho de Melo (2): > > perf list: Add support for PERF_COUNT_SW_BPF_OUT > > perf list: Robustify event printing routine > > > > Jiri Olsa (1): > > perf test: 'unwind' test should create kernel maps > > > > Michael Petlan (1): > > perf buildid-list: Show running kernel build id fix > > > > Namhyung Kim (3): > > perf report: Show error message when processing sample fails > > perf hists: Do not skip elided fields when processing samples > > perf hists browser: Update nr entries regardless of min percent > > > > Wang Nan (3): > > tools lib bpf: Collect map definition in bpf_object > > tools lib bpf: Extract and collect map names from BPF object file > > perf bpf: Rename bpf config to program config > > > > tools/lib/bpf/libbpf.c | 252 > > ++-- > > tools/lib/bpf/libbpf.h | 24 > > tools/perf/builtin-report.c | 12 +- > > tools/perf/tests/dwarf-unwind.c | 5 + > > tools/perf/ui/browsers/hists.c | 5 +- > > tools/perf/util/bpf-loader.c| 65 +-- > > tools/perf/util/bpf-loader.h| 2 +- > > tools/perf/util/build-id.c | 2 +- > > tools/perf/util/hist.c | 6 - > > tools/perf/util/parse-events.c | 6 +- > > 10 files changed, 268 insertions(+), 111 deletions(-) > > Pulled, thanks a lot Arnaldo! > > Should any of the above fixes be cherry-picked over into perf/urgent, or are > these > all new regressions? At least my changes should go into perf/urgent and probably stable too. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm: Fix of_pwm_get() for consistent return values
When of_pwm_get() is called without connection ID it returns
-ENOENT when the 'pwms' property doesn't exists or is an empty entry.
However when a connection ID is given and the 'pwm-names' property
doesn't exists or doesn't contains the requested name it returns
-ENODATA or -EINVAL.
To get a consistent return value with both code paths we must return
-ENOENT when of_property_match_string() fails.
Signed-off-by: Alban Bedel
---
drivers/pwm/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..3b4dcb6 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -578,7 +578,7 @@ struct pwm_device *of_pwm_get(struct device_node *np, const
char *con_id)
if (con_id) {
index = of_property_match_string(np, "pwm-names", con_id);
if (index < 0)
- return ERR_PTR(index);
+ return ERR_PTR(-ENOENT);
}
err = of_parse_phandle_with_args(np, "pwms", "#pwm-cells", index,
--
2.0.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/
user-controllable kmalloc size in bpf syscall
Hello,
The following program triggers a WARNING in kmalloc:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#define SYS_bpf 321
#define BPF_MAP_CREATE0
#define BPF_MAP_UPDATE_ELEM2
union bpf_attr {
struct {
uint32_tmap_type;/* one of enum bpf_map_type */
uint32_tkey_size;/* size of key in bytes */
uint32_tvalue_size;/* size of value in bytes */
uint32_tmax_entries;/* max number of
entries in a map */
};
struct {
uint32_tmap_fd;
uint64_tkey;
uint64_tval;
uint64_tflags;
};
};
int main()
{
union bpf_attr ca;
memset(&ca, 0, sizeof(ca));
ca.map_type = 1;
ca.key_size = 1;
ca.value_size = 0xfff9;
ca.max_entries = 10;
int fd = syscall(SYS_bpf, BPF_MAP_CREATE, &ca, sizeof(ca));
memset(&ca, 0, sizeof(ca));
ca.map_fd = fd;
ca.key = &ca;
ca.val = &ca;
ca.flags = 0;
syscall(SYS_bpf, BPF_MAP_UPDATE_ELEM, &ca, sizeof(ca));
return 0;
}
[ cut here ]
WARNING: CPU: 2 PID: 11122 at mm/page_alloc.c:2989
__alloc_pages_nodemask+0x695/0x14e0()
Modules linked in:
CPU: 2 PID: 11122 Comm: syzkaller_execu Tainted: GB 4.4.0-rc2+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880039aefa30 82743b56
88003b2a 85a8d0e0 880039aefa70 81244ec9
81554e95 85a8d0e0 0bad
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x68/0x92 lib/dump_stack.c:50
[] warn_slowpath_common+0xd9/0x140 kernel/panic.c:460
[] warn_slowpath_null+0x29/0x30 kernel/panic.c:493
[< inline >] __alloc_pages_slowpath mm/page_alloc.c:2989
[] __alloc_pages_nodemask+0x695/0x14e0 mm/page_alloc.c:3235
[] alloc_pages_current+0xee/0x340 mm/mempolicy.c:2055
[< inline >] alloc_pages include/linux/gfp.h:451
[] alloc_kmem_pages+0x16/0xf0 mm/page_alloc.c:3414
[] kmalloc_order+0x19/0x60 mm/slab_common.c:1007
[] kmalloc_order_trace+0x1f/0xa0 mm/slab_common.c:1018
[< inline >] kmalloc_large include/linux/slab.h:390
[] __kmalloc+0x234/0x250 mm/slub.c:3525
[< inline >] kmalloc include/linux/slab.h:463
[< inline >] map_update_elem kernel/bpf/syscall.c:288
[< inline >] SYSC_bpf kernel/bpf/syscall.c:744
[] SyS_bpf+0xfd4/0x1a20 kernel/bpf/syscall.c:695
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace f00640b4d448df95 ]---
On commit 78c4a49a69e910a162b05e4e8727b9bdbf948f13 (Now 25).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/13] mvneta Buffer Management and enhancements
Hi Florian, > > Looking at your patches, it was not entirely clear to me how the buffer > manager on these Marvell SoCs work, but other networking products have > something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and > maybe Freescale's FMAN/DPAA seems to do something similar. > > Does the buffer manager allocation work by giving you a reference/token > to a buffer as opposed to its address? If that is the case, it would be > good to design support for such hardware in a way that it can be used by > more drivers. It does not operate on a reference/token but buffer pointers (physical adresses). It's a ring and you cannot control which buffer will be taken at given moment. > > Eric Dumazet suggested a while ago to me that you could get abstract > such allocation using hardware-assisted buffer allocation by either > introducing a new mm zone (instead of ZONE_NORMAL/DMA/HIGHMEM etc.), or > using a different NUMA node id, such that SKB allocation and freeing > helpers could deal with the specifics, and your networking stack and > driver would be mostly unaware of the buffer manager underlying > implementation. The purpose would be to get a 'struct page' reference to > your buffer pool allocation object, so it becomes mostly transparent to > other areas of the kernel, and you could further specialize everything > that needs to be based on this node id or zone. As this buffer manager is pretty tightly coupled with NIC (please see below) and the solution is very platform specific, I'm not sure if it wouldn't be an overdesign, to provide such generic, paralel to DMA mechanism. > > Finally, these hardware-assisted allocation schemes typically work very > well when there is a forwarding/routing workload involved, because you > can easily steal packets and SKBs from the network stack, but that does > not necessarily play nicely with host-terminated/initiated traffic which > wants to have good feedback on what's happening at the NIC level > (queueing, buffering, etc.). Sure, I can imagine developing some applications that are developed on top of the proposed patches, but I'm not sure if such things like cutting network stack in half should be a part of original support. > >> >> Known issues: >> - problems with obtaining all mapped buffers from internal SRAM, when >> destroying the buffer pointer pool >> - problems with unmapping chunk of SRAM during driver removal >> Above do not have an impact on the operation, as they are called during >> driver removal or in error path. > > Humm, what is the reason for using the on-chip SRAM here, is it because > that's the only storage location the Buffer Manager can allocate from, > or is it because it is presumably faster or with constant access times > than DRAM? Would be nice to explain a bit more in details how the buffer > manager works and its interfacing with the network controllers. Each pool of pointers is a ring maintained in DRAM (called buffer pointers' pool external). SRAM (called buffer pointers' pool internal memory, BPPI) ensures smaller latency, but is also the only way to allocate/fetch buffer pointers from DRAM ring. Transfers between those two memories are controlled by buffer manager itself. In the beginning the external pool has to be filled with desired amount of pointers. NIC (controlled by mvneta driver) has to be informed, which pools it can use for longer and shorter packets, their size and also SRAM physical address has to be written to one of NETA registers. Moreover, in order to be able to provide direct access between NETA and buffer manager SRAM, special, Marvell-specific settings have to be configured (so called opening of MBUS window). After enabling ingress, incoming packet is automatically placed in next-to-be-used buffer from buffer manager resources and the controller updates NIC's descriptor contents with pool's number and buffer addresses. Once the packet is processed, a new buffer has to be allocated and it's address written to SRAM - this way the pool of pointers gets refilled. > > Can I use the buffer manager with other peripherals as well? Like if I > wanted to do zero-copy or hardware-assisted memcpy DMA, would that be a > suitable scheme? Other peripherals cannot access SRAM directly - only DMA-based access to DRAM. If one would like to access buffers using SRAM from other drivers, it has to be done by read/write operations performed by CPU. Moreover I see a limitation, which is a lack of control over the current buffer index. Best regards, Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dm: constify crypt_iv_operations structures
The crypt_iv_operations are never modified, so declare them
as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/md/dm-crypt.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 3147c8d..c7058fc 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -141,7 +141,7 @@ struct crypt_config {
char *cipher;
char *cipher_string;
- struct crypt_iv_operations *iv_gen_ops;
+ const struct crypt_iv_operations *iv_gen_ops;
union {
struct iv_essiv_private essiv;
struct iv_benbi_private benbi;
@@ -756,15 +756,15 @@ static int crypt_iv_tcw_post(struct crypt_config *cc, u8
*iv,
return r;
}
-static struct crypt_iv_operations crypt_iv_plain_ops = {
+static const struct crypt_iv_operations crypt_iv_plain_ops = {
.generator = crypt_iv_plain_gen
};
-static struct crypt_iv_operations crypt_iv_plain64_ops = {
+static const struct crypt_iv_operations crypt_iv_plain64_ops = {
.generator = crypt_iv_plain64_gen
};
-static struct crypt_iv_operations crypt_iv_essiv_ops = {
+static const struct crypt_iv_operations crypt_iv_essiv_ops = {
.ctr = crypt_iv_essiv_ctr,
.dtr = crypt_iv_essiv_dtr,
.init = crypt_iv_essiv_init,
@@ -772,17 +772,17 @@ static struct crypt_iv_operations crypt_iv_essiv_ops = {
.generator = crypt_iv_essiv_gen
};
-static struct crypt_iv_operations crypt_iv_benbi_ops = {
+static const struct crypt_iv_operations crypt_iv_benbi_ops = {
.ctr = crypt_iv_benbi_ctr,
.dtr = crypt_iv_benbi_dtr,
.generator = crypt_iv_benbi_gen
};
-static struct crypt_iv_operations crypt_iv_null_ops = {
+static const struct crypt_iv_operations crypt_iv_null_ops = {
.generator = crypt_iv_null_gen
};
-static struct crypt_iv_operations crypt_iv_lmk_ops = {
+static const struct crypt_iv_operations crypt_iv_lmk_ops = {
.ctr = crypt_iv_lmk_ctr,
.dtr = crypt_iv_lmk_dtr,
.init = crypt_iv_lmk_init,
@@ -791,7 +791,7 @@ static struct crypt_iv_operations crypt_iv_lmk_ops = {
.post = crypt_iv_lmk_post
};
-static struct crypt_iv_operations crypt_iv_tcw_ops = {
+static const struct crypt_iv_operations crypt_iv_tcw_ops = {
.ctr = crypt_iv_tcw_ctr,
.dtr = crypt_iv_tcw_dtr,
.init = crypt_iv_tcw_init,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 22/71] ncr5380: Eliminate selecting state
Hi Finn,
On Sun, Nov 29, 2015 at 11:25 AM, Finn Thain wrote:
> On Sun, 29 Nov 2015, Geert Uytterhoeven wrote:
>> This still heavily depends on the processing time spent in
>> NCR5380_read(). You should never use a value derived from
>> loops_per_jiffy for a non-empty loop,
>
> Sure but the time-out condition isn't supposed to be precise.
> Plus/minus a jiffy is no problem. Plus/minus a second is no good.
If an ISA access takes 8 µs, while the CPU runs at 1 GHz, i.e. 500M loops/s,
the difference will be huge.
>> as it may take much longer. Always compare with an maximum end time
>> instead.
>
> That can't work with interrupts disabled, which was the problem I was
> trying to solve by use of loops_per_jiffy.
Then you indeed can't use jiffies.
Perhaps you can calibrate an NCR5380_read() loop at driver init time,
and use the calibration value later?
> NCR5380_poll_politely() in mainline doesn't work with interrupts disabled
> either, hence patch 21.
>
>> E.g.:
>>
>> end = jiffies + 2;/* 1 jiffie + 1 safeguard */
>> do {
>> if ((NCR5380_read(reg1) & bit1) == val1)
>> return 0;
>> cpu_relax();
>> } while (time_before(jiffies, end);
>>
>> And a similar loop for "Busy-wait for up to 20 ms".
>
> Interrupts may be disabled during that loop also. Please refer to (and/or
> respond to) patch 21, "ncr5380: Sleep when polling, if possible", in which
> these changes were made.
So the above loop may never terminate. Oops...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] arch/ia64/kernel/palinfo.c: bitvector_process reading out of bounds
Hello,
I'm doing some static analysis and stumbled in this function
static void bitvector_process(struct seq_file *m, u64 vector)
{
int i,j;
static const char *units[]={ "", "K", "M", "G", "T" };
for (i=0, j=0; i < 64; i++ , j=i/10) {
if (vector & 0x1)
seq_printf(m, "%d%s ", 1 << (i-j*10), units[j]);
vector >>= 1;
}
}
It appears that units[] (5 elements) can be accessed out of bounds in
seq_printf call
seq_printf(m, "%d%s ", 1 << (i-j*10), units[j]);
once j is being set to i/10.
i goes from 0 to 63 (u64 bits length), and when vector & 1 (odd),
units[j] will calculate outside the boundaries when vector get close
to Petabyte magnitude.
Well, as bitvector_process doesn't control the max size of vector and
the future is knocking on door, I would suggest this change
-static const char *units[]={ "", "K", "M", "G", "T" };
+static const char *units[]={ "", "K", "M", "G", "T", "P", "E" };
then if the u64 max value (18446744073709551615) is used the array
will provide the correct (E) suffix.
If that change is not pertinent I would like to know why.
--
Regards,
Geyslan G. Bem
hackingbits.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/
[PATCH v2 2/2] um: Use race-free temporary file creation
Open the memory mapped file with the O_TMPFILE flag when available. Signed-off-by: Mickaël Salaün --- arch/um/os-Linux/mem.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/mem.c index 798aeb4..6ee4233 100644 --- a/arch/um/os-Linux/mem.c +++ b/arch/um/os-Linux/mem.c @@ -106,6 +106,17 @@ static int __init make_tempfile(const char *template) } } +#ifdef O_TMPFILE + fd = open(tempdir, O_CLOEXEC | O_RDWR | O_EXCL | O_TMPFILE, 0700); + /* +* If the running system does not support O_TMPFILE flag then retry +* without it. +*/ + if (fd != -1 || (errno != EINVAL && errno != EISDIR && + errno != EOPNOTSUPP)) + return fd; +#endif + tempname = malloc(strlen(tempdir) + strlen(template) + 1); if (tempname == NULL) return -1; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] um: Set secure access mode for temporary file
Replace the insecure mode 0777 with 0700 for temporary file to prohibit
other users to change the executable mapped code.
An attacker could gain access to the mapped file descriptor from the
temporary file (before it is unlinked) in a read-only mode but it should
not be accessible in write mode to avoid arbitrary code execution.
Signed-off-by: Mickaël Salaün
---
arch/um/os-Linux/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/mem.c
index 897e9ad..798aeb4 100644
--- a/arch/um/os-Linux/mem.c
+++ b/arch/um/os-Linux/mem.c
@@ -142,7 +142,7 @@ static int __init create_tmp_file(unsigned long long len)
if (fd < 0)
exit(1);
- err = fchmod(fd, 0777);
+ err = fchmod(fd, 0700);
if (err < 0) {
perror("fchmod");
exit(1);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading
On 29 November 2015 at 12:47, Daniel Vetter wrote: > On Fri, Nov 27, 2015 at 07:37:53PM -0500, Ilia Mirkin wrote: >> On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov >> wrote: >> > On 27 November 2015 at 15:10, Daniel Vetter wrote: >> >> It only leads to bloodshed and tears - we don't bother to restore a >> >> working legacy vga hw setup. >> >> >> >> On haswell with the new dynamic power well code this leads to even >> >> more hilarity since for some configurations the hardware is simply no >> >> longer there. >> >> >> >> The actual implementation is a bit a hack - we realy on fbcon to kick >> >> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n) >> >> and VGA_CONSOLE=y i915 already unregisters the vga console manually >> >> early in the driver load sequence. >> >> >> > Interesting... nv50 and later GPUs are in a roughly similar shame >> > afaict. They lack the dedicated hardware and no one really bothered >> > figuring out how to restore things to a working shape [1]. >> > >> > Then again, upon sequential load of the nouveau module the GPU gets >> > initialised properly, where you can get X (weston?) up and running >> > without issues. Am I thinking about a different thing ? >> > >> > I take it that you guys do less of the (re)initialisation dance, to >> > ensure faster boot times ? >> > >> > Thanks, >> > Emil >> > >> > [1] >> > http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau >> >> FWIW it's possible to unload nouveau, at which point your screen turns >> off (because we can't restore the vga emulation junk... haven't the >> faintest clue how it works), and then reload it, at which point fbcon >> gets rebound and is completely happy. I can't tell what this patch is >> doing, but for your own sanity, you should support unloading/reloading >> i915 as well. > > We do of course support unloading/reloading. And we do the same "shut > everything down" like nouveau seems to do. The problem though on some hw > is that if vgacon then tries to access the registers the hw dies. So the > problem we have with not restoring VGA functionality isn't that the screen > is black when i915.ko is unloaded, but that the machine dies. This patch > fixes that. I see. Thank you for the explanation! -Emil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iio: adc: mcp3422: Add mcp3421 support
On 27/11/15 13:52, Sascha Hauer wrote:
> The mcp3421 is the single channel variant of the mcp342x family. Support
> is straight forward, only the channels array has to be added for this
> chip.
>
> Signed-off-by: Sascha Hauer
Thanks
Applied to the togreg branch of iio.git - initially pushed out as testing.
Note that the branch will get rebased once the previous pull has unwound
itself.
Jonathan
> ---
> drivers/iio/adc/mcp3422.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/iio/adc/mcp3422.c b/drivers/iio/adc/mcp3422.c
> index 3555122..6eca7ae 100644
> --- a/drivers/iio/adc/mcp3422.c
> +++ b/drivers/iio/adc/mcp3422.c
> @@ -305,6 +305,10 @@ static const struct attribute_group
> mcp3422_attribute_group = {
> .attrs = mcp3422_attributes,
> };
>
> +static const struct iio_chan_spec mcp3421_channels[] = {
> + MCP3422_CHAN(0),
> +};
> +
> static const struct iio_chan_spec mcp3422_channels[] = {
> MCP3422_CHAN(0),
> MCP3422_CHAN(1),
> @@ -352,6 +356,10 @@ static int mcp3422_probe(struct i2c_client *client,
> indio_dev->info = &mcp3422_info;
>
> switch (adc->id) {
> + case 1:
> + indio_dev->channels = mcp3421_channels;
> + indio_dev->num_channels = ARRAY_SIZE(mcp3421_channels);
> + break;
> case 2:
> case 3:
> case 6:
> @@ -383,6 +391,7 @@ static int mcp3422_probe(struct i2c_client *client,
> }
>
> static const struct i2c_device_id mcp3422_id[] = {
> + { "mcp3421", 1 },
> { "mcp3422", 2 },
> { "mcp3423", 3 },
> { "mcp3424", 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 v2 0/2] um: Protect memory mapped file
This series protect the memory mapped file. Changes since v1; addressed Richard Weinberger's comments: * add attacker model to the patch description [1/2] * remove errno reset [2/2] Regards, Mickaël Mickaël Salaün (2): um: Set secure access mode for temporary file um: Use race-free temporary file creation arch/um/os-Linux/mem.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dt-bindings: iio: adc: Update mcp342x binding for the mcp3421
On 27/11/15 20:15, Rob Herring wrote: > On Fri, Nov 27, 2015 at 02:52:52PM +0100, Sascha Hauer wrote: >> The mcp3421 is the single channel variant of the mcp342x family and >> can be supported by the mcp342x driver. >> >> Signed-off-by: Sascha Hauer >> Cc: devicet...@vger.kernel.org > > Acked-by: Rob Herring Applied. Thanks, Jonathan > >> --- >> Documentation/devicetree/bindings/iio/adc/mcp3422.txt | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt >> b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt >> index 333139c..dcae4cc 100644 >> --- a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt >> +++ b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt >> @@ -1,7 +1,8 @@ >> -* Microchip mcp3422/3/4/6/7/8 chip family (ADC) >> +* Microchip mcp3421/2/3/4/6/7/8 chip family (ADC) >> >> Required properties: >> - compatible: Should be >> +"microchip,mcp3421" or >> "microchip,mcp3422" or >> "microchip,mcp3423" or >> "microchip,mcp3424" or >> -- >> 2.6.2 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.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/
[PATCH] perf report: Change default to use event group view
The event group view feature is to see related events together. To use
the group view, events should be recorded as a group with a dedicated
syntax of surrounding events by braces (-e '{ evt1, evt2, ... }').
Also 'perf report' also requires the --group option to enable it.
However it's almost always beneficial to use the group view to see the
group events as it's more expressive. And I think it's more natural to
see events together if they are recorded as a group.
Thus this patch changes the default value to enable it. If users don't
want to see like it and keep the original behavior, they can set the
report.group config variable to false and/or use --no-group option in
the 'perf report' command line.
Requested-by: Ingo Molnar
Cc: Stephane Eranian
Cc: Taeung Song
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d51abd2e7865..3b2de6eb3376 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -39,6 +39,7 @@ struct symbol_conf symbol_conf = {
.cumulate_callchain = true,
.show_hist_headers = true,
.symfs = "",
+ .event_group= true,
};
static enum dso_binary_type binary_type_symtab[] = {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] Save SMBIOS Type 9 System Slots during DMI Scan
Hi Jordan, On Fri, 27 Nov 2015 20:45:55 -0600, Jordan Hargrave wrote: > commit fdf6d7e7cf448b9482062d73a48895afaf38a458 > Author: Jordan Hargrave > Date: Fri Nov 27 20:39:59 2015 -0600 > > Fix spacing > Check invalid slot entry according to spec > > commit 8a7fe87241b93c72cfd6ef818a680a2c7fc2f1c7 > Author: Jordan Hargrave > Date: Thu Nov 26 15:57:24 2015 -0600 > > Save SMBIOS Type 9 System Slots during DMI Scan > > PCI address of onboard devices is currently saved but not for slots. > > Cleaned up some code, verify clean patch > > PCI address of onboard devices is currently saved but not for slots. > > Cleaned up some code, verify clean patch > > Signed-off-by: Jordan Hargrave > --- > drivers/firmware/dmi_scan.c | 53 > +++-- > include/linux/dmi.h | 1 + > 2 files changed, 38 insertions(+), 16 deletions(-) > (...) Format is awful but result is correct. Next time please rebase cleanly your patch. For this time I'll do it, I must adjust it due to my own patches anyway. So consider it applied. Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] iio: light: us5182d: Add property for choosing default power mode
On 24/11/15 10:59, Adriana Reus wrote:
> This chip supports two power modes.
> 1. "one-shot" mode - the chip activates and executes one complete
> conversion loop and then shuts itself down. This is the default mode
> chosen for raw reads.
> 2. "continuous" mode - the chip takes continuous measurements.
>
> Continuous mode is more expensive power-wise but may be more reliable.
> Add a property so that if preferred, the default power mode for raw
> reads can be set to continuous.
> Separate one-shot enabling in a separate function that will be used
> depending on the chosen power mode. Also create a function for
> powering the chip on and off.
>
> Signed-off-by: Adriana Reus
A couple of nitpicks inline... I've fixed them up when applying to the
togreg branch of iio.git - initially pushed out as testing for the autobuilders
to play with them.
Thanks,
Jonathan
> ---
> drivers/iio/light/us5182d.c | 90
> +++--
> 1 file changed, 78 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 49dab3c..7993014 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -99,6 +99,11 @@ enum mode {
> US5182D_PX_ONLY
> };
>
> +enum pmode {
> + US5182D_CONTINUOUS,
> + US5182D_ONESHOT
> +};
> +
> struct us5182d_data {
> struct i2c_client *client;
> struct mutex lock;
> @@ -112,6 +117,9 @@ struct us5182d_data {
> u16 *us5182d_dark_ths;
>
> u8 opmode;
> + u8 power_mode;
> +
> + bool default_continuous;
> };
>
> static IIO_CONST_ATTR(in_illuminance_scale_available,
> @@ -130,13 +138,11 @@ static const struct {
> u8 reg;
> u8 val;
> } us5182d_regvals[] = {
> - {US5182D_REG_CFG0, (US5182D_CFG0_SHUTDOWN_EN |
> - US5182D_CFG0_WORD_ENABLE)},
> + {US5182D_REG_CFG0, US5182D_CFG0_WORD_ENABLE},
> {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
> {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
> US5182D_CFG2_PXGAIN_DEFAULT)},
> {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> - {US5182D_REG_MODE_STORE, US5182D_STORE_MODE},
> {US5182D_REG_CFG4, 0x00},
> };
>
> @@ -169,7 +175,7 @@ static int us5182d_get_als(struct us5182d_data *data)
> return result;
> }
>
> -static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +static int us5182d_oneshot_en(struct us5182d_data *data)
> {
> int ret;
>
> @@ -182,6 +188,20 @@ static int us5182d_set_opmode(struct us5182d_data *data,
> u8 mode)
>* required measurement.
>*/
> ret = ret | US5182D_CFG0_ONESHOT_EN;
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
Unwanted extra blank line here...
> +
> +}
> +
> +static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +{
> + int ret;
> +
> + if (mode == data->opmode)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
>
> /* update mode */
> ret = ret & ~US5182D_OPMODE_MASK;
> @@ -196,9 +216,6 @@ static int us5182d_set_opmode(struct us5182d_data *data,
> u8 mode)
> if (ret < 0)
> return ret;
>
> - if (mode == data->opmode)
> - return 0;
> -
> ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_MODE_STORE,
> US5182D_STORE_MODE);
> if (ret < 0)
> @@ -210,6 +227,23 @@ static int us5182d_set_opmode(struct us5182d_data *data,
> u8 mode)
> return 0;
> }
>
> +static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
Stray space above.. Checkpatch would have highlighted this for you, please
do run it as a sanity check before you send a series out.
> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
> +
> + ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
> + ret = ret | state;
> +
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> +}
> +
> static int us5182d_read_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan, int *val,
> int *val2, long mask)
> @@ -222,6 +256,11 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> switch (chan->type) {
> case IIO_LIGHT:
> mutex_lock(&data->lock);
> + if (data->power_mode == US5182D_ONESHOT) {
> + ret = us5182d_oneshot_en(data);
> + if (ret < 0)
> + goto out_err;
> + }
> ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
> if (ret <
Re: [PATCH 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash
Sebastian, Adding Ezequiel Garcia in Cc. On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote: > The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. > Add the corresponding properties to the NAND node. If the ONFI information from the NAND flash say that it requires 4 bits per 512, then there should be no need to add this information to the Device Tree as the pxa3xx_nand driver by default uses the ONFI information. Those properties are only needed when for some reason the vendor has chosen to use a ECC strength that doesn't match with the one advertised by the flash in its ONFI information (either stronger or weaker). But in this case, your commit log is confusing, because it says that the "NAND device ... uses 4-bit BCH ECC protection". If it really does, then the patch is not needed :-) Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android 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 2/5] Documentation: devicetree: Add property for controlling power saving mode for the us5182 als sensor
On 25/11/15 23:55, Rob Herring wrote: > On Wed, Nov 25, 2015 at 11:50:30AM +0200, Adriana Reus wrote: >> >> >> On 25.11.2015 02:01, Rob Herring wrote: >>> On Tue, Nov 24, 2015 at 12:59:49PM +0200, Adriana Reus wrote: Add a property to allow changing the default power-saving mode. By default, at read raw the chip will activate and provide one measurent, then it will shut itself down. However, the chip can also work in "continuous" mode which may be more reliable but is also more power consuming. Signed-off-by: Adriana Reus --- Documentation/devicetree/bindings/iio/light/us5182d.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt index 6f0a530..a619799 100644 --- a/Documentation/devicetree/bindings/iio/light/us5182d.txt +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt @@ -7,13 +7,24 @@ Required properties: Optional properties: - upisemi,glass-coef: glass attenuation factor - compensation factor of resolution 1000 for material transmittance. + - upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc counts) corresponding to every scale. + - upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4 fractional bits - Q4.4) applied when light > threshold + - upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4 fractional bits - Q4.4) applied when light < threshold +- upisemi,continuous: This chip has two power modes: one-shot (chip takes one + measurement and then shuts itself down) and continuous ( + chip takes continuous measurements). The one-shot mode is + more power-friendly but the continuous mode may be more + reliable. If this property is specified the continuous + mode will be used instead of the default one-shot one for + raw reads. >>> >>> I could imagine an OS may want to decide this on its own or use a >>> mixture of the modes. >>> >>> Rob >>> >> >> There is no possibility of mixing them up (at the same time), so for example >> proximity cannot work in one mode and als the other. >> >> The one-shot mode can only be used for raw reads (for example when >> user-space polls in_[proximity|light]_raw). If user-space wants to enable >> events (activate interrupts when certain thresholds are met - patch 5 of the >> series), then the chip has to switch to continuous nonetheless because it >> needs to be active all the time. So one work-flow scenario would be: >> >> Consumer1 starts polling the raw interface - default_mode >> Consumer2 activates events - continuous mode >> Consumer2 deactivates events - back to default_mode >> >> The only choice here is the default mode for raw reads, it currently is >> one-shot, this patch allows for continuous to be used if preferred. > > Okay, then: > > Acked-by: Rob Herring Applied to the togreg branch of iio.git - initially pushed out as testing. Thanks, Jonathan > >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.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: gigaset: freeing an active object
On Sat, Nov 28, 2015 at 2:27 AM, Sasha Levin wrote: > On 11/27/2015 08:20 PM, Peter Hurley wrote: >> It would really help if you included the syzkaller-generated applet with >> the bug reports; state previously established by the applet can be >> crucial in understanding why the call stack looks the way it does. >> >> Also, every generated applet that triggers a report should become >> a future regression test; I'm collecting the ones pertinent to tty/serial/ >> ldisc (so that includes this one; if you could send me the x25 one too >> would be great). > > I went in to look for the 'crashers' that I thought are generated when > syzkaller manages to crash a kernel, but none appear for me. > > Dmitry, is there magic required to generate those? There is a little bit of magic, but mostly hard muscle labor. I've outlined how I create reproducers here: https://github.com/google/syzkaller/wiki/Crash-reproducer-programs The description is not super detailed, but should be give you some clue. Ideally it is all automated, but somebody needs to write some code for that... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v12 10/30] tracing: Add 'hist' event trigger command
Hi Tom,
On Mon, Nov 23, 2015 at 01:51:25PM -0600, Tom Zanussi wrote:
> 'hist' triggers allow users to continually aggregate trace events,
> which can then be viewed afterwards by simply reading a 'hist' file
> containing the aggregation in a human-readable format.
>
> The basic idea is very simple and boils down to a mechanism whereby
> trace events, rather than being exhaustively dumped in raw form and
> viewed directly, are automatically 'compressed' into meaningful tables
> completely defined by the user.
>
> This is done strictly via single-line command-line commands and
> without the aid of any kind of programming language or interpreter.
>
> A surprising number of typical use cases can be accomplished by users
> via this simple mechanism. In fact, a large number of the tasks that
> users typically do using the more complicated script-based tracing
> tools, at least during the initial stages of an investigation, can be
> accomplished by simply specifying a set of keys and values to be used
> in the creation of a hash table.
>
> The Linux kernel trace event subsystem happens to provide an extensive
> list of keys and values ready-made for such a purpose in the form of
> the event format files associated with each trace event. By simply
> consulting the format file for field names of interest and by plugging
> them into the hist trigger command, users can create an endless number
> of useful aggregations to help with investigating various properties
> of the system. See Documentation/trace/events.txt for examples.
>
> hist triggers are implemented on top of the existing event trigger
> infrastructure, and as such are consistent with the existing triggers
> from a user's perspective as well.
>
> The basic syntax follows the existing trigger syntax. Users start an
> aggregation by writing a 'hist' trigger to the event of interest's
> trigger file:
>
> # echo hist:keys=xxx [ if filter] > event/trigger
>
> Once a hist trigger has been set up, by default it continually
> aggregates every matching event into a hash table using the event key
> and a value field named 'hitcount'.
>
> To view the aggregation at any point in time, simply read the 'hist'
> file in the same directory as the 'trigger' file:
>
> # cat event/hist
>
> The detailed syntax provides additional options for user control, and
> is described exhaustively in Documentation/trace/events.txt and in the
> virtual tracing/README file in the tracing subsystem.
>
> Signed-off-by: Tom Zanussi
> Tested-by: Masami Hiramatsu
> ---
[SNIP]
> +static struct hist_trigger_data *
> +create_hist_data(unsigned int map_bits,
> + struct hist_trigger_attrs *attrs,
> + struct trace_event_file *file)
> +{
> + struct hist_trigger_data *hist_data;
> + int ret = 0;
> +
> + hist_data = kzalloc(sizeof(*hist_data), GFP_KERNEL);
> + if (!hist_data)
> + return ERR_PTR(-ENOMEM);
> +
> + hist_data->attrs = attrs;
> +
> + ret = create_hist_fields(hist_data, file);
> + if (ret < 0)
> + goto free;
> +
> + ret = create_sort_keys(hist_data);
> + if (ret < 0)
> + goto free;
> +
> + hist_data->map = tracing_map_create(map_bits, hist_data->key_size,
> + NULL, hist_data);
> + if (IS_ERR(hist_data->map)) {
> + ret = PTR_ERR(hist_data->map);
> + hist_data->map = NULL;
> + goto free;
> + }
> +
> + ret = create_tracing_map_fields(hist_data);
> + if (ret)
> + goto free;
> +
> + ret = tracing_map_init(hist_data->map);
> + if (ret)
> + goto free;
> +
> + hist_data->event_file = file;
> + out:
> + return hist_data;
> + free:
> + hist_data->attrs = NULL;
> +
> + destroy_hist_data(hist_data);
> + if (ret)
> + hist_data = ERR_PTR(ret);
> + else
> + hist_data = NULL;
Is this else part really needed? It seems that all code path to here
set the 'ret' non-zero. Otherwise ...
> +
> + goto out;
> +}
[SNIP]
> +static int event_hist_trigger_func(struct event_command *cmd_ops,
> +struct trace_event_file *file,
> +char *glob, char *cmd, char *param)
> +{
> + unsigned int hist_trigger_bits = TRACING_MAP_BITS_DEFAULT;
> + struct event_trigger_data *trigger_data;
> + struct hist_trigger_attrs *attrs;
> + struct event_trigger_ops *trigger_ops;
> + struct hist_trigger_data *hist_data;
> + char *trigger;
> + int ret = 0;
> +
> + if (!param)
> + return -EINVAL;
> +
> + /* separate the trigger from the filter (k:v [if filter]) */
> + trigger = strsep(¶m, " \t");
> + if (!trigger)
> + return -EINVAL;
> +
> + attrs = parse_hist_trigger_attrs(trigger);
> + if (IS_ERR(attrs))
> + return PTR_ERR(attrs);
> +
> + if (attrs->map_bits)
> + hist_trigger_bit
Re: [PATCH 5/5] iio: light: us5182d: Add interrupt support and events
On 24/11/15 10:59, Adriana Reus wrote:
> Add interrupt support and events for proximity.
> Add two threshold events to signal rising and falling directions.
>
> Signed-off-by: Adriana Reus
A few bits and bobs inline...
> ---
> drivers/iio/light/us5182d.c | 272
> +++-
> 1 file changed, 271 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 60cab4a..4d1f80d 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -20,7 +20,10 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -30,6 +33,8 @@
> #define US5182D_CFG0_ONESHOT_EN BIT(6)
> #define US5182D_CFG0_SHUTDOWN_EN BIT(7)
> #define US5182D_CFG0_WORD_ENABLE BIT(0)
> +#define US5182D_CFG0_PROXBIT(3)
> +#define US5182D_CFG0_PX_IRQ BIT(2)
>
> #define US5182D_REG_CFG1 0x01
> #define US5182D_CFG1_ALS_RES16 BIT(4)
> @@ -41,6 +46,7 @@
>
> #define US5182D_REG_CFG3 0x03
> #define US5182D_CFG3_LED_CURRENT100 (BIT(4) | BIT(5))
> +#define US5182D_CFG3_INT_SOURCE_PX BIT(3)
>
> #define US5182D_REG_CFG4 0x10
>
> @@ -55,6 +61,13 @@
> #define US5182D_REG_AUTO_LDARK_GAIN 0x29
> #define US5182D_REG_AUTO_HDARK_GAIN 0x2a
>
> +/* Thresholds for events: px low (0x08-l, 0x09-h), px high (0x0a-l 0x0b-h) */
> +#define US5182D_REG_PXL_TH 0x08
> +#define US5182D_REG_PXH_TH 0x0a
> +
> +#define US5182D_REG_PXL_TH_DEFAULT 1000
> +#define US5182D_REG_PXH_TH_DEFAULT 3
> +
> #define US5182D_OPMODE_ALS 0x01
> #define US5182D_OPMODE_PX0x02
> #define US5182D_OPMODE_SHIFT 4
> @@ -84,6 +97,8 @@
> #define US5182D_READ_WORD2
> #define US5182D_OPSTORE_SLEEP_TIME 20 /* ms */
> #define US5182D_SLEEP_MS 3000 /* ms */
> +#define US5182D_PXH_TH_DISABLE 0x
> +#define US5182D_PXL_TH_DISABLE 0x
>
> /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
> static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600,
> 7600,
> @@ -119,6 +134,12 @@ struct us5182d_data {
> u8 upper_dark_gain;
> u16 *us5182d_dark_ths;
>
> + u16 px_low_th;
> + u16 px_high_th;
> +
> + int rising_en;
> + int falling_en;
> +
> u8 opmode;
> u8 power_mode;
>
> @@ -148,10 +169,26 @@ static const struct {
> {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
> {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
> US5182D_CFG2_PXGAIN_DEFAULT)},
> - {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> + {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100 |
> +US5182D_CFG3_INT_SOURCE_PX},
> {US5182D_REG_CFG4, 0x00},
> };
>
> +static const struct iio_event_spec us5182d_events[] = {
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> +};
> +
> static const struct iio_chan_spec us5182d_channels[] = {
> {
> .type = IIO_LIGHT,
> @@ -161,6 +198,8 @@ static const struct iio_chan_spec us5182d_channels[] = {
> {
> .type = IIO_PROXIMITY,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .event_spec = us5182d_events,
> + .num_event_specs = ARRAY_SIZE(us5182d_events),
> }
> };
>
> @@ -477,11 +516,199 @@ static int us5182d_write_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
>
> +static int us5182d_setup_prox(struct iio_dev *indio_dev,
> + enum iio_event_direction dir, u16 val)
> +{
> + struct us5182d_data *data = iio_priv(indio_dev);
> + int ret = 0;
> +
> + if (dir == IIO_EV_DIR_FALLING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXL_TH, val);
> +
> + if (dir == IIO_EV_DIR_RISING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXH_TH, val);
> +
> + return ret;
return directly above, no need for the local ret variable and return
0 here.
> +}
> +
> +static int us5182d_read_thresh(struct iio_dev
Re: [PATCH 4/5] iio: light: us8152d: Add power management support
On 24/11/15 10:59, Adriana Reus wrote:
> Add power management for sleep as well as runtime pm.
>
> Signed-off-by: Adriana Reus
Mostly fine, but a comment on a possible future tidy up inline.
Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.
> ---
> drivers/iio/light/us5182d.c | 95
> +
> 1 file changed, 88 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 3d959f3..60cab4a 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #define US5182D_REG_CFG0 0x00
> #define US5182D_CFG0_ONESHOT_EN BIT(6)
> @@ -81,6 +83,7 @@
> #define US5182D_READ_BYTE1
> #define US5182D_READ_WORD2
> #define US5182D_OPSTORE_SLEEP_TIME 20 /* ms */
> +#define US5182D_SLEEP_MS 3000 /* ms */
>
> /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
> static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600,
> 7600,
> @@ -298,6 +301,26 @@ static int us5182d_shutdown_en (struct us5182d_data
> *data, u8 state)
> return ret;
> }
>
> +
> +static int us5182d_set_power_state(struct us5182d_data *data, bool on)
> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + if (on) {
> + ret = pm_runtime_get_sync(&data->client->dev);
> + if (ret < 0)
> + pm_runtime_put_noidle(&data->client->dev);
> + } else {
> + pm_runtime_mark_last_busy(&data->client->dev);
> + ret = pm_runtime_put_autosuspend(&data->client->dev);
> + }
> +
> + return ret;
> +}
> +
> static int us5182d_read_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan, int *val,
> int *val2, long mask)
> @@ -315,15 +338,20 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> if (ret < 0)
> goto out_err;
> }
> - ret = us5182d_als_enable(data);
> + ret = us5182d_set_power_state(data, true);
> if (ret < 0)
> goto out_err;
> -
> + ret = us5182d_als_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
> ret = us5182d_get_als(data);
> if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
> goto out_err;
> mutex_unlock(&data->lock);
> - *val = ret;
> return IIO_VAL_INT;
> case IIO_PROXIMITY:
I'd argue the complexity of this has reached the point where ideally you'd
break it out to a function. The jumps out of the switch statement are
particularly nasty from a readability point of view.
Perhaps a job for a followup patch?
> mutex_lock(&data->lock);
> @@ -332,17 +360,22 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> if (ret < 0)
> goto out_err;
> }
> - ret = us5182d_px_enable(data);
> + ret = us5182d_set_power_state(data, true);
> if (ret < 0)
> goto out_err;
> -
> + ret = us5182d_px_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
> ret = i2c_smbus_read_word_data(data->client,
> US5182D_REG_PDL);
> if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
> goto out_err;
> mutex_unlock(&data->lock);
> - *val = ret;
> - return IIO_VAL_INT;
> + return IIO_VAL_INT;
This is a little bit of noise that should have been dealt with separately...
> default:
> return -EINVAL;
> }
> @@ -361,6 +394,9 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> }
>
> return -EINVAL;
> +
> +out_poweroff:
> + us5182d_set_power_state(data, false);
> out_err:
> mutex_unlock(&data->lock);
>
[PATCH 2/2] crypto: cryptd - Assign statesize properly
cryptd_create_hash() fails by returning -EINVAL. It is because after
8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers must have a non-zero statesize.
This patch fixes the problem by properly assigning the statesize.
Signed-off-by: Rui Wang
---
crypto/cryptd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index c81861b..8b40db8 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -637,6 +637,7 @@ static int cryptd_create_hash(struct crypto_template *tmpl,
struct rtattr **tb,
inst->alg.halg.base.cra_flags = type;
inst->alg.halg.digestsize = salg->digestsize;
+ inst->alg.halg.statesize = salg->statesize;
inst->alg.halg.base.cra_ctxsize = sizeof(struct cryptd_hash_ctx);
inst->alg.halg.base.cra_init = cryptd_hash_init_tfm;
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] crypto: Fix driver load failure
ghash_clmulni_intel fails to load on Linux 4.3+ with the following message: "modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument" These two patches need to go together, for the driver to load correctly. Rui Wang (2): crypto: ghash-clmulni - Fix load failure crypto: cryptd - Assign statesize properly arch/x86/crypto/ghash-clmulni-intel_glue.c | 26 ++ crypto/cryptd.c| 1 + 2 files changed, 27 insertions(+) -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] crypto: ghash-clmulni - Fix load failure
ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"
After 8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers are required to implement import()/export(), and must have a non-
zero statesize.
This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.
Signed-off-by: Rui Wang
---
arch/x86/crypto/ghash-clmulni-intel_glue.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c
b/arch/x86/crypto/ghash-clmulni-intel_glue.c
index 440df0c..a69321a 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -219,6 +219,29 @@ static int ghash_async_final(struct ahash_request *req)
}
}
+static int ghash_async_import(struct ahash_request *req, const void *in)
+{
+ struct ahash_request *cryptd_req = ahash_request_ctx(req);
+ struct shash_desc *desc = cryptd_shash_desc(cryptd_req);
+ struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
+
+ ghash_async_init(req);
+ memcpy(dctx, in, sizeof(*dctx));
+ return 0;
+
+}
+
+static int ghash_async_export(struct ahash_request *req, void *out)
+{
+ struct ahash_request *cryptd_req = ahash_request_ctx(req);
+ struct shash_desc *desc = cryptd_shash_desc(cryptd_req);
+ struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
+
+ memcpy(out, dctx, sizeof(*dctx));
+ return 0;
+
+}
+
static int ghash_async_digest(struct ahash_request *req)
{
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
@@ -288,8 +311,11 @@ static struct ahash_alg ghash_async_alg = {
.final = ghash_async_final,
.setkey = ghash_async_setkey,
.digest = ghash_async_digest,
+ .export = ghash_async_export,
+ .import = ghash_async_import,
.halg = {
.digestsize = GHASH_DIGEST_SIZE,
+ .statesize = sizeof(struct ghash_desc_ctx),
.base = {
.cra_name = "ghash",
.cra_driver_name= "ghash-clmulni",
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power Monitors
On 23/11/15 16:15, Marc Titinger wrote: > On 21/11/2015 19:13, Jonathan Cameron wrote: >> On 18/11/15 14:38, Marc Titinger wrote: >>> Basic support or direct IO raw read, with averaging attribute. >>> Values are RAW, INT_PLUS_MICRO (Volt/Ampere/Watt). >>> >>> Output of iio_info: >>> >>> iio:device0: ina226 >>>4 channels found: >>> power3: (input) >>> 1 channel-specific attributes found: >>> attr 0: raw value: 1.15 >>> voltage0: (input) >>> 1 channel-specific attributes found: >>> attr 0: raw value: 0.03 >>> voltage1: (input) >>> 1 channel-specific attributes found: >>> attr 0: raw value: 4.277500 >>> current2: (input) >>> 1 channel-specific attributes found: >>> attr 0: raw value: 0.268000 >>> 4 device-specific attributes found: >>> attr 0: sampling_frequency_available value: 61 120 236... >>> attr 1: in_averaging_steps value: 4 >>> attr 2: in_calibscale value: 1 >>> attr 3: in_sampling_frequency value: 1506 >>> >>> Tested with ina226, on BeagleBoneBlack. >>> >>> Datasheet: http://www.ti.com/lit/gpn/ina226 >>> >>> Signed-off-by: Marc Titinger >> You have added some new ABI in here, but I'm not seeing any documentation >> for averaging_steps. Does this map onto the existing oversampling_ratio? >> > > I am not sure normal averaging maps well with oversampling. Normal > averaging will provide one value every N samples (this is what this > chip does), while oversampling will interpolate N value between > sample 'k' and 'k-1', and decimate to provide a less-noisy version of > sample 'k', the resulting sampling frequency is not lower. > Oversampling is wonderfully badly defined as a term. Often it is use precisely for the method or noise reduction that is infact just an average. Usually it implies: 1) Sampling at a higher rate than the eventual output will be provided at. This is the oversampling bit. 2) Sometimes adding carefully controlled noise - effectively dithering but ensuring the noise is not at a frequency of interest so it can be removed later without effecting what we are after - this allows obtaining a theoretically higher bit rate signal than what you are measuring with - in extreme cases it allows the one bit adc trick - more commonly it's just about reducing the noise as a result of the measurement process. 3) ADC conversion - post noise addition if we are deliberately adding some. 4) Applying digital filters as desired. 5) Finally outputing at the reduced data rate. So - in the simplest form we actually have a straight forward average filter just like the one your device is applying. Now you are correct that the data goes digital at a much higher rate than the output rate in oversampling - however if we assume a chip is providing an oversampling function inherently it must then be dropping it down to a more reasonable level in chip (rather than leaving it to the CPU) Hence if we have an iio chip with oversampling it's applying a filter - whether that is a simple average filter, or something a touch more clever is the only real question. Now I've probably confused this discussion even more ;) Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: iio: adc: use dev_get_platdata()
On 23/11/15 17:33, Nizam Haider wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly.
>
> Signed-off-by: Nizam Haider
The 7780 platform data has gone away in the meantime.
Applied for the other 3.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 2 +-
> drivers/staging/iio/adc/ad7280a.c | 2 +-
> drivers/staging/iio/adc/ad7780.c | 2 +-
> drivers/staging/iio/adc/ad7816.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index bb40f37..9221103 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -609,7 +609,7 @@ static const struct iio_chan_spec ad7192_channels[] = {
>
> static int ad7192_probe(struct spi_device *spi)
> {
> - const struct ad7192_platform_data *pdata = spi->dev.platform_data;
> + const struct ad7192_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct ad7192_state *st;
> struct iio_dev *indio_dev;
> int ret, voltage_uv = 0;
> diff --git a/drivers/staging/iio/adc/ad7280a.c
> b/drivers/staging/iio/adc/ad7280a.c
> index 35acb1a..f45ebed 100644
> --- a/drivers/staging/iio/adc/ad7280a.c
> +++ b/drivers/staging/iio/adc/ad7280a.c
> @@ -833,7 +833,7 @@ static const struct ad7280_platform_data
> ad7793_default_pdata = {
>
> static int ad7280_probe(struct spi_device *spi)
> {
> - const struct ad7280_platform_data *pdata = spi->dev.platform_data;
> + const struct ad7280_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct ad7280_state *st;
> int ret;
> const unsigned short tACQ_ns[4] = {465, 1010, 1460, 1890};
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 3abc778..9baa703 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -163,7 +163,7 @@ static const struct iio_info ad7780_info = {
>
> static int ad7780_probe(struct spi_device *spi)
> {
> - struct ad7780_platform_data *pdata = spi->dev.platform_data;
> + struct ad7780_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct ad7780_state *st;
> struct iio_dev *indio_dev;
> int ret, voltage_uv = 0;
> diff --git a/drivers/staging/iio/adc/ad7816.c
> b/drivers/staging/iio/adc/ad7816.c
> index c8e1566..2226051 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -345,7 +345,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
> {
> struct ad7816_chip_info *chip;
> struct iio_dev *indio_dev;
> - unsigned short *pins = spi_dev->dev.platform_data;
> + unsigned short *pins = dev_get_platdata(&spi_dev->dev);
> int ret = 0;
> int i;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging: iio: light: tsl2x7x_core: use dev_get_platdata()
On 23/11/15 17:48, Nizam Haider wrote: > Use the wrapper function for retrieving the platform data instead of > accessing dev->platform_data directly. > > Signed-off-by: Nizam Haider Applied to the togreg branch of iio.git - initially pushed out as testing. Note that branch will get rebased shortly to catch up with Greg's staging-next. Thanks, Jonathan > --- > drivers/staging/iio/light/tsl2x7x_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/light/tsl2x7x_core.c > b/drivers/staging/iio/light/tsl2x7x_core.c > index 9dfd048..5b1c165 100644 > --- a/drivers/staging/iio/light/tsl2x7x_core.c > +++ b/drivers/staging/iio/light/tsl2x7x_core.c > @@ -1898,7 +1898,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp, > mutex_init(&chip->prox_mutex); > > chip->tsl2x7x_chip_status = TSL2X7X_CHIP_UNKNOWN; > - chip->pdata = clientp->dev.platform_data; > + chip->pdata = dev_get_platdata(&clientp->dev); > chip->id = id->driver_data; > chip->chip_info = > &tsl2x7x_chip_info_tbl[device_channel_config[id->driver_data]]; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/30] tracing: 'hist' triggers
On Mon, Nov 23, 2015 at 01:51:15PM -0600, Tom Zanussi wrote: > This is v12 of the 'hist triggers' patchset, incorporating suggestions > and fixing problems pointed out by Namhyung. Thanks for doing this work! This version looks good to me although I have a small nitpick in the 10/30. With that fixed, you can add my Reviewed-by: Namhyung Kim to this patchset. Thanks, Namhyung > > Changes from v11: > > - Added tracing_map_lookup(). > - Changed tracing_map_insert() to incorporate the hits/drops counter > updating. The changes allow clients to continue calling > tracing_map_insert() and update existing entries if desired, or > stop on the first drop, since the return value is still NULL in > that case. > - Changed the hist trigger code to continue calling > tracing_map_insert() rather than stopping on the first drop. The > idea is that there's no harm in continuing after the first drop - > if the user can't tolerate any drops, they'll still see a non-zero > drop count and can retry with a larger table, but if the user > doesn't care, the hit and drop counts are an accurate reflection > of how many events were tallied vs dropped. > - Added a new unreg_all() callback to event_command, and code to > call it when the trigger file is opened for truncate. Implemented > unreg_all() for hist triggers, which allows them to honor the > truncate flag while leaving existing triggers intact. This means > that '>>' should now be used for adding multiple hist triggers as > well as to clear/pause/cont an existing hist trigger. > - Included Namhyung's log2 patch. > - Fixed one of Masami's test cases which now requires using '>>' due > to the truncate changes. > - 'cont' and 'clear' no longer create a trigger if one doesn't exist. > - Rebased to latest trace/for-next. > - Various other smaller fixes and Documentation updates as noted by > Namhyung. > > Changes from v10: > > - Rebased to latest trace/for-next. > - Added Masami's ftrace/hist triggers kselftest patches. > - Added Masami's Tested-by: to the series. > > Changes from v9: > > v10 adds some major new features - 'named' hist triggers and support > for multiple hist triggers on a single event - basically all of the > features and suggestions suggested by Masami, except for one: I > decided after all not to implement the 'pause/continue/clear' commands > on the hist file. I've gotten so used to the habit of calling up the > previous trigger-setting command in the command history and simply > appending a 'pause/cont/clear' command to it (and later removing it by > prepending a '!') that making the user change the command doesn't seem > as naturally usable. Masami, if you disagree, let me know and I'll > reconsider it but at this point I'd rather not make that change. > > In addition, I think I've fixed all the other various smaller problems > mentioned in the previous review, please let me know if I missed any... > > - Added support for 'named' hist triggers > - Added support for multiple hist triggers on a single trace event > - Added documentation and examples for the above new features > - Streamlined the README to only include the essentials for hist triggers > - Fixed the 'hex' modifier for values, which was previously ignored > - Replaced the kmalloc of large arrays with a simple page-based scheme > - Fixed the tracing_map_insert() case where jhash returns 0 > - Fixed various other small problems noted along the way > > Changes from v8: > > Same as v8, but with the RFC patch [ftrace: Add function_hist tracer] > removed, and rebased to latest trace/for-next. > > Changes from v7: > > This version refactors the commits as suggested by Masami. There are > now more commits, but the result should be much more reviewable. The > ending code is the same as before, modulo a couple minor bug fixes I > discovered while refactoring and testing. > > I've also reviewed and fixed a number of shortcomings and errors in > the comments, and have added a new discussion of the tracing_map data > structures after Steve mentioned he found them confusing and/or > insufficiently documented. > > Also, I kept Namhyung's string patch [tracing: Support string type key > properly] as submitted, but added a follow-on patch that refactors it > and fixes a problem I found with it that enabled static string keys to > contain random chars and therefore incorrect map insertions. > > Changes from v6: > > This version adds a new 'sym-offset' modifier as requested by Masami. > I implemented it as a modifier rather than using the trace option as > suggested, in part because I wanted to keep it all self-contained and > it seemed more consistent to just add it alongside the 'sym' modifier. > Also, hist triggers arent't really a tracer and therefore don't > directly tie into the option update/callback mechanism so making use > of it isn't as simple as a normal tracer.
Re: [PATCH] Staging: iio: frequency: use dev_get_platdata()
On 23/11/15 18:07, Nizam Haider wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly.
>
> Signed-off-by: Nizam Haider
applied
> ---
> drivers/staging/iio/frequency/ad9832.c | 2 +-
> drivers/staging/iio/frequency/ad9834.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 2b65faa..18b27a1 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -201,7 +201,7 @@ static const struct iio_info ad9832_info = {
>
> static int ad9832_probe(struct spi_device *spi)
> {
> - struct ad9832_platform_data *pdata = spi->dev.platform_data;
> + struct ad9832_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct iio_dev *indio_dev;
> struct ad9832_state *st;
> struct regulator *reg;
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 6464f2c..6366216 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -318,7 +318,7 @@ static const struct iio_info ad9833_info = {
>
> static int ad9834_probe(struct spi_device *spi)
> {
> - struct ad9834_platform_data *pdata = spi->dev.platform_data;
> + struct ad9834_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct ad9834_state *st;
> struct iio_dev *indio_dev;
> struct regulator *reg;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: gigaset: freeing an active object
Hi Sasha, thanks for the report. As the original author of the code in question, I am somewhat at a loss what to make of it. Am 27.11.2015 um 16:19 schrieb Sasha Levin: > Fuzzing with syzkaller on the latest -next kernel produced this error: Is there a way to know the actual sequence of events that triggered this warning? > [ 413.536749] WARNING: CPU: 6 PID: 25400 at lib/debugobjects.c:263 > debug_print_object+0x1c4/0x1e0() > [ 413.538111] ODEBUG: free active (active state 0) object type: timer_list > hint: delayed_work_timer_fn+0x0/0x90 This message seems to indicate that an object of type timer_list was freed which was still active. However the driver in question (ser_gigaset) does not use any timers. What are the exact conditions for producing this message? IOW how does the ODEBUG code determine that an object of type timer_list is being freed, and that it is still in use? Are there any messages from ser_gigaset or another one of the gigaset drivers before that warning? > [ 413.539598] Modules linked > in:3470693efef57268844f02f5de3ab392d8cf5e209671ddd87163cb964c510659 This message does not tell me anything. What does that hex string after the colon mean? > [ 413.540448] CPU: 6 PID: 25400 Comm: syzkaller_execu Not tainted > 4.4.0-rc2-next-20151126-sasha-5-g00d303e-dirty #2653 > [ 413.547614] Call Trace: > [ 413.548077] [] dump_stack+0x72/0xb7 > [ 413.548765] [] warn_slowpath_common+0x113/0x140 > [ 413.551151] [] warn_slowpath_fmt+0xcb/0x100 > [ 413.554295] [] debug_print_object+0x1c4/0x1e0 > [ 413.556592] [] __debug_check_no_obj_freed+0x215/0x7a0 > [ 413.560526] [] debug_check_no_obj_freed+0x2c/0x40 > [ 413.561328] [] kfree+0x1fc/0x2f0 Judging from the backtrace below this must be the call kfree(cs->hw.ser); in drivers/isdn/gigaset/ser-gigaset.c line 375. cs->hw.ser is of type struct ser_cardstate *. struct ser_cardstate consists of a struct platform_device, a struct completion, an atomic_t and a pointer. No timer_list. > [ 413.561970] [] gigaset_freecshw+0xe1/0x120 There are functions by this name in all three Gigaset hardware dependent modules (bas_gigaset, ser_gigaset and usb_gigaset), but ... > [ 413.562723] [] gigaset_freecs+0x2ad/0x600 > [ 413.564240] [] gigaset_tty_close+0x210/0x280 this function only exists in ser_gigaset. Thanks, Tilman -- Tilman Schmidt E-Mail: til...@imap.cc Bonn, Germany Nous, on a des fleurs et des bougies pour nous protéger. signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/4] iio: adc: add IMX7D ADC driver support
On 25/11/15 03:52, Stefan Agner wrote: > Hi Haibo, > > Some comments below: > > On 2015-11-20 07:48, Haibo Chen wrote: >> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC >> driver support, and the driver only support ADC software trigger. >> >> Signed-off-by: Haibo Chen >> --- >> drivers/iio/adc/Kconfig | 9 + >> drivers/iio/adc/Makefile| 1 + >> drivers/iio/adc/imx7d_adc.c | 570 >> >> 3 files changed, 580 insertions(+) >> create mode 100644 drivers/iio/adc/imx7d_adc.c >> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig >> index 7868c74..bf0611c 100644 >> --- a/drivers/iio/adc/Kconfig >> +++ b/drivers/iio/adc/Kconfig >> @@ -194,6 +194,15 @@ config HI8435 >>This driver can also be built as a module. If so, the module will be >>called hi8435. >> >> +config IMX7D_ADC >> +tristate "IMX7D ADC driver" >> +depends on OF > > Hm, not sure, but shouldn't we use a proper depends here? Otherwise this > will show up as modules in all kinds of distributions. usual trick is a depends on the platform or COMPILE_TEST (so that autobuilders will hit it) > >> +help >> + Say yes here to build support for IMX7D ADC. >> + >> + This driver can also be built as a module. If so, the module will be >> + called imx7d_adc. >> + >> config LP8788_ADC >> tristate "LP8788 ADC driver" >> depends on MFD_LP8788 >> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile >> index 99b37a9..282ffc01 100644 >> --- a/drivers/iio/adc/Makefile >> +++ b/drivers/iio/adc/Makefile >> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o >> obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o >> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o >> obj-$(CONFIG_HI8435) += hi8435.o >> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o >> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o >> obj-$(CONFIG_MAX1027) += max1027.o >> obj-$(CONFIG_MAX1363) += max1363.o >> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c >> new file mode 100644 >> index 000..d9547bf >> --- /dev/null >> +++ b/drivers/iio/adc/imx7d_adc.c >> @@ -0,0 +1,570 @@ >> +/* >> + * Freescale i.MX7D ADC driver >> + * >> + * Copyright (C) 2015 Freescale Semiconductor, Inc. >> + * >> + * 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 of the License, or >> + * (at your option) any later version. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > > Can you sort these alphabetically > >> + >> +#include >> +#include >> +#include >> + >> +/* ADC register */ >> +#define IMX7D_REG_ADC_CH_A_CFG1 0x00 >> +#define IMX7D_REG_ADC_CH_A_CFG2 0x10 >> +#define IMX7D_REG_ADC_CH_B_CFG1 0x20 >> +#define IMX7D_REG_ADC_CH_B_CFG2 0x30 >> +#define IMX7D_REG_ADC_CH_C_CFG1 0x40 >> +#define IMX7D_REG_ADC_CH_C_CFG2 0x50 >> +#define IMX7D_REG_ADC_CH_D_CFG1 0x60 >> +#define IMX7D_REG_ADC_CH_D_CFG2 0x70 >> +#define IMX7D_REG_ADC_CH_SW_CFG 0x80 >> +#define IMX7D_REG_ADC_TIMER_UNIT0x90 >> +#define IMX7D_REG_ADC_DMA_FIFO 0xa0 >> +#define IMX7D_REG_ADC_FIFO_STATUS 0xb0 >> +#define IMX7D_REG_ADC_INT_SIG_EN0xc0 >> +#define IMX7D_REG_ADC_INT_EN0xd0 >> +#define IMX7D_REG_ADC_INT_STATUS0xe0 >> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT0xf0 >> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT0x100 >> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT0x110 >> +#define IMX7D_REG_ADC_DMA_FIFO_DAT 0x120 >> +#define IMX7D_REG_ADC_ADC_CFG 0x130 >> + >> +#define IMX7D_EACH_CHANNEL_REG_SHIF 0x20 > > I would call that OFFSET, SHIFT is typically used for a bit offset > within a register. > >> + >> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN(0x1 << 31) >> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_DISABLE (0x0 << >> 31) > > I would just define the _EN definition (along with using BIT). > Bitshifting a 0 is not really useful. > >> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLEBIT(30) >> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_ENBIT(29) >> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL_SHIF 24 >> + >> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4 (0x0 << >> 12) >> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8 (0x1 << >> 12) >> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16(0x2 << 12) >> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
* PaX Team wrote: > On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > > > > i don't see the compile time vs. runtime detection as 'competing' > > > approaches, > > > both have their own role. [...] > > > > That's true - but only as long as 'this can be solved in tooling!' is not > > used as > > an excuse to oppose the runtime solution and we end up doing neither. > > actually, i already voiced my opinion elsewhere in the constify thread on the > kernel hardening list that adding/using __read_only is somewhat premature > without also adding the compile time verification part (as part of the > constify > plugin for example). right now its use on the embedded vdso image is simple > and > easy to verify but once people begin to add it to variables that the compiler > knows and cares about (say, the ops structures) then things can become > fragile > without compile checking. so yes, i'd also advise to get such tooling in > *before* more __read_only usage is added. I think you are mistaken there: if we add the page fault fixup to make sure we don't crash if a read-only variable is accessed, then we'll have most of the benefits of read-only mappings and no fragility - without having to wait for tooling. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: block: Always check queue limits for cloned requests
On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote:
> On 2015.11.26 at 08:11 -0500, Mike Snitzer wrote:
>> On Thu, Nov 26 2015 at 2:46am -0500,
>> Hannes Reinecke wrote:
>>
>>> When a cloned request is retried on other queues it always needs
>>> to be checked against the queue limits of that queue.
>>> Otherwise the calculations for nr_phys_segments might be wrong,
>>> leading to a crash in scsi_init_sgtable().
>>>
>>> To clarify this the patch renames blk_rq_check_limits()
>>> to blk_cloned_rq_check_limits() and removes the symbol
>>> export, as the new function should only be used for
>>> cloned requests and never exported.
>>>
>>> Cc: Mike Snitzer
>>> Cc: Ewan Milne
>>> Cc: Jeff Moyer
>>> Signed-off-by: Hannes Reinecke
>>
>> Patch looks good. Thanks for getting to the bottom of this.
>>
>> Jens, please add these extra tags when you pick this up:
>>
>> Fixes: e2a60da74 ("block: Clean up special command handling logic")
>> Cc: sta...@vger.kernel.org # 3.7+
>> Acked-by: Mike Snitzer
>
> I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even
> with this patch applied.
>
> markus@x4 linux % git describe
> v4.4-rc2-215-g081f3698e606
>
Can you generate a crashdump?
I would need to cross-check with the other dumps I'm having to figure
out if this really is the same issue.
There have been other reports (and fixes) which show we're fighting
several distinct issues here.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ALSA: pcm: constify action_ops structures
The action_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
sound/core/pcm_native.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index a8b27cd..fadd3eb 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -875,7 +875,7 @@ struct action_ops {
* Note: the stream state might be changed also on failure
* Note2: call with calling stream lock + link lock
*/
-static int snd_pcm_action_group(struct action_ops *ops,
+static int snd_pcm_action_group(const struct action_ops *ops,
struct snd_pcm_substream *substream,
int state, int do_lock)
{
@@ -932,7 +932,7 @@ static int snd_pcm_action_group(struct action_ops *ops,
/*
* Note: call with stream lock
*/
-static int snd_pcm_action_single(struct action_ops *ops,
+static int snd_pcm_action_single(const struct action_ops *ops,
struct snd_pcm_substream *substream,
int state)
{
@@ -952,7 +952,7 @@ static int snd_pcm_action_single(struct action_ops *ops,
/*
* Note: call with stream lock
*/
-static int snd_pcm_action(struct action_ops *ops,
+static int snd_pcm_action(const struct action_ops *ops,
struct snd_pcm_substream *substream,
int state)
{
@@ -984,7 +984,7 @@ static int snd_pcm_action(struct action_ops *ops,
/*
* Note: don't use any locks before
*/
-static int snd_pcm_action_lock_irq(struct action_ops *ops,
+static int snd_pcm_action_lock_irq(const struct action_ops *ops,
struct snd_pcm_substream *substream,
int state)
{
@@ -998,7 +998,7 @@ static int snd_pcm_action_lock_irq(struct action_ops *ops,
/*
*/
-static int snd_pcm_action_nonatomic(struct action_ops *ops,
+static int snd_pcm_action_nonatomic(const struct action_ops *ops,
struct snd_pcm_substream *substream,
int state)
{
@@ -1056,7 +1056,7 @@ static void snd_pcm_post_start(struct snd_pcm_substream
*substream, int state)
snd_pcm_timer_notify(substream, SNDRV_TIMER_EVENT_MSTART);
}
-static struct action_ops snd_pcm_action_start = {
+static const struct action_ops snd_pcm_action_start = {
.pre_action = snd_pcm_pre_start,
.do_action = snd_pcm_do_start,
.undo_action = snd_pcm_undo_start,
@@ -1107,7 +1107,7 @@ static void snd_pcm_post_stop(struct snd_pcm_substream
*substream, int state)
wake_up(&runtime->tsleep);
}
-static struct action_ops snd_pcm_action_stop = {
+static const struct action_ops snd_pcm_action_stop = {
.pre_action = snd_pcm_pre_stop,
.do_action = snd_pcm_do_stop,
.post_action = snd_pcm_post_stop
@@ -1224,7 +1224,7 @@ static void snd_pcm_post_pause(struct snd_pcm_substream
*substream, int push)
}
}
-static struct action_ops snd_pcm_action_pause = {
+static const struct action_ops snd_pcm_action_pause = {
.pre_action = snd_pcm_pre_pause,
.do_action = snd_pcm_do_pause,
.undo_action = snd_pcm_undo_pause,
@@ -1273,7 +1273,7 @@ static void snd_pcm_post_suspend(struct snd_pcm_substream
*substream, int state)
wake_up(&runtime->tsleep);
}
-static struct action_ops snd_pcm_action_suspend = {
+static const struct action_ops snd_pcm_action_suspend = {
.pre_action = snd_pcm_pre_suspend,
.do_action = snd_pcm_do_suspend,
.post_action = snd_pcm_post_suspend
@@ -1375,7 +1375,7 @@ static void snd_pcm_post_resume(struct snd_pcm_substream
*substream, int state)
snd_pcm_timer_notify(substream, SNDRV_TIMER_EVENT_MRESUME);
}
-static struct action_ops snd_pcm_action_resume = {
+static const struct action_ops snd_pcm_action_resume = {
.pre_action = snd_pcm_pre_resume,
.do_action = snd_pcm_do_resume,
.undo_action = snd_pcm_undo_resume,
@@ -1478,7 +1478,7 @@ static void snd_pcm_post_reset(struct snd_pcm_substream
*substream, int state)
snd_pcm_playback_silence(substream, ULONG_MAX);
}
-static struct action_ops snd_pcm_action_reset = {
+static const struct action_ops snd_pcm_action_reset = {
.pre_action = snd_pcm_pre_reset,
.do_action = snd_pcm_do_reset,
.post_action = snd_pcm_post_reset
@@ -1522,7 +1522,7 @@ static void snd_pcm_post_prepare(struct snd_pcm_substream
*substream, int state)
snd_pcm_set_state(substream, SNDRV_PCM_STATE_PREPARED);
}
-static struct action_ops snd_pcm_action_prepare = {
+static const struct action_ops snd_pcm_action_prepare = {
.pre_action = snd_pcm_pre_prepare,
.do_action = snd_pcm_do_prepare,
.post_action = snd_pcm_post_prepare
@@ -1618,7 +1618,7 @@ static void snd_pcm_post_drain_init(struct
Re: [PATCH 3/5] iio: light: us5182d: Add functions for selectively enabling als and proximity
On 24/11/15 10:59, Adriana Reus wrote:
> Keep track of the als and px enabled/disabled status in
> order to enable them selectively.
>
> Signed-off-by: Adriana Reus
Couple more nitpicks, but again fixed up during apply.
> ---
> drivers/iio/light/us5182d.c | 64
> ++---
> 1 file changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 7993014..3d959f3 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -119,6 +119,9 @@ struct us5182d_data {
> u8 opmode;
> u8 power_mode;
>
> + bool als_enabled;
> + bool px_enabled;
> +
> bool default_continuous;
> };
>
> @@ -227,6 +230,48 @@ static int us5182d_set_opmode(struct us5182d_data *data,
> u8 mode)
> return 0;
> }
>
> +static int us5182d_als_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_ALS_ONLY);
> +
> + if (data->als_enabled)
> + return 0;
> +
> + mode = data->px_enabled ? US5182D_ALS_PX : US5182D_ALS_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->als_enabled = true;
Blank line here ideally.
> + return 0;
> +}
> +
> +static int us5182d_px_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_PX_ONLY);
> +
> + if (data->px_enabled)
> + return 0;
> +
> + mode = data->als_enabled ? US5182D_ALS_PX : US5182D_PX_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->px_enabled = true;
And here...
> + return 0;
> +}
> +
> static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
> {
> int ret;
> @@ -241,7 +286,16 @@ static int us5182d_shutdown_en (struct us5182d_data
> *data, u8 state)
> ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
> ret = ret | state;
>
> - return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + if (ret < 0)
> + return ret;
> +
> + if (state & US5182D_CFG0_SHUTDOWN_EN) {
> + data->als_enabled = false;
> + data->px_enabled = false;
> + }
> +
> + return ret;
> }
>
> static int us5182d_read_raw(struct iio_dev *indio_dev,
> @@ -261,7 +315,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> if (ret < 0)
> goto out_err;
> }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
> + ret = us5182d_als_enable(data);
> if (ret < 0)
> goto out_err;
>
> @@ -278,7 +332,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
> if (ret < 0)
> goto out_err;
> }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_PX);
> + ret = us5182d_px_enable(data);
> if (ret < 0)
> goto out_err;
>
> @@ -421,6 +475,9 @@ static int us5182d_init(struct iio_dev *indio_dev)
> return ret;
> }
>
> + data->als_enabled = true;
> + data->px_enabled = true;
> +
> if (!data->default_continuous) {
> ret = us5182d_shutdown_en(data, US5182D_CFG0_SHUTDOWN_EN);
> if (ret < 0)
> @@ -428,7 +485,6 @@ static int us5182d_init(struct iio_dev *indio_dev)
> data->power_mode = US5182D_ONESHOT;
> }
>
> -
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/13] bpf tools: Extract and collect map names from BPF object file
Hi Wang,
On Fri, Nov 27, 2015 at 08:47:36AM +, Wang Nan wrote:
> This patch collects name of maps in BPF object files and saves them into
> 'maps' field in 'struct bpf_object'. 'bpf_object__get_map_by_name' is
> introduced to retrive fd and definitions of a map through its name.
>
> Signed-off-by: Wang Nan
> Signed-off-by: He Kuang
> Cc: Alexei Starovoitov
> Cc: Arnaldo Carvalho de Melo
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Zefan Li
> Cc: pi3or...@163.com
> ---
> tools/lib/bpf/libbpf.c | 65
> +++---
> tools/lib/bpf/libbpf.h | 3 +++
> 2 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index f509825..a298614 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -165,6 +165,7 @@ struct bpf_program {
>
> struct bpf_map {
> int fd;
> + char *name;
> struct bpf_map_def def;
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> @@ -526,12 +527,46 @@ bpf_object__init_maps(struct bpf_object *obj, void
> *data,
> return 0;
> }
>
> +static void
> +bpf_object__init_maps_name(struct bpf_object *obj, int maps_shndx)
> +{
> + int i;
> + Elf_Data *symbols = obj->efile.symbols;
> +
> + if (!symbols || maps_shndx < 0)
> + return;
> +
> + for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
> + GElf_Sym sym;
> + size_t map_idx;
> + const char *map_name;
> +
> + if (!gelf_getsym(symbols, i, &sym))
> + continue;
> + if (sym.st_shndx != maps_shndx)
> + continue;
> +
> + map_name = elf_strptr(obj->efile.elf,
> + obj->efile.ehdr.e_shstrndx,
> + sym.st_name);
It means that each map name is saved in section header string table?
> + map_idx = sym.st_value / sizeof(struct bpf_map_def);
> + if (map_idx >= obj->nr_maps) {
> + pr_warning("index of map \"%s\" is buggy: %zu > %zu\n",
> +map_name, map_idx, obj->nr_maps);
> + continue;
> + }
> + obj->maps[map_idx].name = strdup(map_name);
You need to check the return value.
thanks,
Namhyung
> + pr_debug("map %zu is \"%s\"\n", map_idx,
> + obj->maps[map_idx].name);
> + }
> +}
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: block: Always check queue limits for cloned requests
On 2015.11.29 at 16:43 +0100, Hannes Reinecke wrote:
> On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote:
> > On 2015.11.26 at 08:11 -0500, Mike Snitzer wrote:
> >> On Thu, Nov 26 2015 at 2:46am -0500,
> >> Hannes Reinecke wrote:
> >>
> >>> When a cloned request is retried on other queues it always needs
> >>> to be checked against the queue limits of that queue.
> >>> Otherwise the calculations for nr_phys_segments might be wrong,
> >>> leading to a crash in scsi_init_sgtable().
> >>>
> >>> To clarify this the patch renames blk_rq_check_limits()
> >>> to blk_cloned_rq_check_limits() and removes the symbol
> >>> export, as the new function should only be used for
> >>> cloned requests and never exported.
> >>>
> >>> Cc: Mike Snitzer
> >>> Cc: Ewan Milne
> >>> Cc: Jeff Moyer
> >>> Signed-off-by: Hannes Reinecke
> >>
> >> Patch looks good. Thanks for getting to the bottom of this.
> >>
> >> Jens, please add these extra tags when you pick this up:
> >>
> >> Fixes: e2a60da74 ("block: Clean up special command handling logic")
> >> Cc: sta...@vger.kernel.org # 3.7+
> >> Acked-by: Mike Snitzer
> >
> > I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even
> > with this patch applied.
> >
> > markus@x4 linux % git describe
> > v4.4-rc2-215-g081f3698e606
> >
> Can you generate a crashdump?
> I would need to cross-check with the other dumps I'm having to figure
> out if this really is the same issue.
> There have been other reports (and fixes) which show we're fighting
> several distinct issues here.
Unfortunately no. The crash happens on the disk where I store my log
files. And after it happened the magic SysRq keys don't work anymore.
The crash only happens on my spinning rust drive that uses the cfq
scheduler. The SSDs (deadline) are fine.
The BUG happens reproducibly when building http://www.sagemath.org/ on
that drive.
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC Re: [PATCH v2 04/13] perf tools: Add API to config maps in bpf object
Hi Arnaldo, On Fri, Nov 27, 2015 at 10:10:54PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Nov 27, 2015 at 08:47:38AM +, Wang Nan escreveu: > > bpf__config_obj() is introduced as a core API to config BPF object > > after loading. One configuration option of maps is introduced. After > > this patch BPF object can accept configuration like: > > > > maps:my_map:value=1234 > > > > (maps.my_map.value looks pretty. However, there's a small but hard > > to fixed problem related to flex's greedy matching. Please see [1]. > > Choose ':' to avoid it in a simpler way.) > > Understood the issues, but I would like to hear from Ingo, Jiri, > Namhyung, Brian and others here, since we're setting up syntax, and yes, > using: > > maps.my_map.value[0,3...6]=1234; > > or even: > > maps->my_map->value[0,3...6]=1234; > > Looks more natural than: > > maps:my_map:value[0,3...6]=1234; Do we have to use only single separator? What about this? maps:my_map.value[0,3...6]=1234; Thanks, Namhyung > > I'll think harder about this, maybe we can find a way to use the more > familiar dot notation somehow. > > And I have to anyway test this more extensively, so I'll push the > patches I have and try this as soon as I can. > > - Arnaldo > > > > This patch is more complex than the work it really does because the > > consideration of extension. In designing of BPF map configuration, > > following things should be considered: > > > > 1. Array indics selection: perf should allow user setting different > > indices :-) > > > value to different slots in an array, with syntax like: > > maps:my_map:value[0,3...6]=1234; > > > > 2. A map can be config by different config terms, each for a part > > of it. For example, set each slot to pid of a thread; > > > > 3. Type of value: integer is not the only valid value type. Perf > > event can also be put into a map after commit 35578d7984003097af2b1e3 > > (bpf: Implement function bpf_perf_event_read() that get the selected > > hardware PMU conuter); > > > > 4. For hash table, it is possible to use string or other as key; > > > > 5. It is possible that map configuration is unable to be setup > > during parsing. Perf event is an example. > > > > Therefore, this patch does following: > > > > 1. Instead of updating map element during parsing, this patch stores > > map config options in 'struct bpf_map_priv'. Following patches > > would apply those configs at proper time; > > > > 2. Link map operations to a list so a map can have multiple config > > terms attached, so different parts can be configured separately; > > > > 3. Make 'struct bpf_map_priv' extensible so following patches can > > add new types of keys and operations; > > > > 4. Use bpf_config_map_funcs array to support more maps config options. > > > > Since the patch changing event parser to parse BPF object config is > > relative large, I put in another commit. Code in this patch > > could be tested after applying next patch. > > > > [1] http://lkml.kernel.org/g/564ed621.4050...@huawei.com > > > Signed-off-by: Wang Nan > > Signed-off-by: He Kuang > > Cc: Alexei Starovoitov > > Cc: Arnaldo Carvalho de Melo > > Cc: Masami Hiramatsu > > Cc: Namhyung Kim > > Cc: Zefan Li > > Cc: pi3or...@163.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/
[PATCH] drm/radeon: constify radeon_asic_ring structures
The radeon_asic_ring structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/radeon/radeon.h |2 -
drivers/gpu/drm/radeon/radeon_asic.c | 38 +--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b6cbd81..cf09102 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1889,7 +1889,7 @@ struct radeon_asic {
void (*pad_ib)(struct radeon_ib *ib);
} vm;
/* ring specific callbacks */
- struct radeon_asic_ring *ring[RADEON_NUM_RINGS];
+ const struct radeon_asic_ring *ring[RADEON_NUM_RINGS];
/* irqs */
struct {
int (*set)(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 1d4d452..7d5a36d 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -179,7 +179,7 @@ void radeon_agp_disable(struct radeon_device *rdev)
* ASIC
*/
-static struct radeon_asic_ring r100_gfx_ring = {
+static const struct radeon_asic_ring r100_gfx_ring = {
.ib_execute = &r100_ring_ib_execute,
.emit_fence = &r100_fence_ring_emit,
.emit_semaphore = &r100_semaphore_ring_emit,
@@ -329,7 +329,7 @@ static struct radeon_asic r200_asic = {
},
};
-static struct radeon_asic_ring r300_gfx_ring = {
+static const struct radeon_asic_ring r300_gfx_ring = {
.ib_execute = &r100_ring_ib_execute,
.emit_fence = &r300_fence_ring_emit,
.emit_semaphore = &r100_semaphore_ring_emit,
@@ -343,7 +343,7 @@ static struct radeon_asic_ring r300_gfx_ring = {
.set_wptr = &r100_gfx_set_wptr,
};
-static struct radeon_asic_ring rv515_gfx_ring = {
+static const struct radeon_asic_ring rv515_gfx_ring = {
.ib_execute = &r100_ring_ib_execute,
.emit_fence = &r300_fence_ring_emit,
.emit_semaphore = &r100_semaphore_ring_emit,
@@ -901,7 +901,7 @@ static struct radeon_asic r520_asic = {
},
};
-static struct radeon_asic_ring r600_gfx_ring = {
+static const struct radeon_asic_ring r600_gfx_ring = {
.ib_execute = &r600_ring_ib_execute,
.emit_fence = &r600_fence_ring_emit,
.emit_semaphore = &r600_semaphore_ring_emit,
@@ -914,7 +914,7 @@ static struct radeon_asic_ring r600_gfx_ring = {
.set_wptr = &r600_gfx_set_wptr,
};
-static struct radeon_asic_ring r600_dma_ring = {
+static const struct radeon_asic_ring r600_dma_ring = {
.ib_execute = &r600_dma_ring_ib_execute,
.emit_fence = &r600_dma_fence_ring_emit,
.emit_semaphore = &r600_dma_semaphore_ring_emit,
@@ -999,7 +999,7 @@ static struct radeon_asic r600_asic = {
},
};
-static struct radeon_asic_ring rv6xx_uvd_ring = {
+static const struct radeon_asic_ring rv6xx_uvd_ring = {
.ib_execute = &uvd_v1_0_ib_execute,
.emit_fence = &uvd_v1_0_fence_emit,
.emit_semaphore = &uvd_v1_0_semaphore_emit,
@@ -1198,7 +1198,7 @@ static struct radeon_asic rs780_asic = {
},
};
-static struct radeon_asic_ring rv770_uvd_ring = {
+static const struct radeon_asic_ring rv770_uvd_ring = {
.ib_execute = &uvd_v1_0_ib_execute,
.emit_fence = &uvd_v2_2_fence_emit,
.emit_semaphore = &uvd_v2_2_semaphore_emit,
@@ -1305,7 +1305,7 @@ static struct radeon_asic rv770_asic = {
},
};
-static struct radeon_asic_ring evergreen_gfx_ring = {
+static const struct radeon_asic_ring evergreen_gfx_ring = {
.ib_execute = &evergreen_ring_ib_execute,
.emit_fence = &r600_fence_ring_emit,
.emit_semaphore = &r600_semaphore_ring_emit,
@@ -1318,7 +1318,7 @@ static struct radeon_asic_ring evergreen_gfx_ring = {
.set_wptr = &r600_gfx_set_wptr,
};
-static struct radeon_asic_ring evergreen_dma_ring = {
+static const struct radeon_asic_ring evergreen_dma_ring = {
.ib_execute = &evergreen_dma_ring_ib_execute,
.emit_fence = &evergreen_dma_fence_ring_emit,
.emit_semaphore = &r600_dma_semaphore_ring_emit,
@@ -1612,7 +1612,7 @@ static struct radeon_asic btc_asic = {
},
};
-static struct radeon_asic_ring cayman_gfx_ring = {
+static const struct radeon_asic_ring cayman_gfx_ring = {
.ib_execute = &cayman_ring_ib_execute,
.ib_parse = &evergreen_ib_parse,
.emit_fence = &cayman_fence_ring_emit,
@@ -1627,7 +1627,7 @@ static struct radeon_asic_ring cayman_gfx_ring = {
.set_wptr = &cayman_gfx_set_wptr,
};
-static struct radeon_asic_ring cayman_dma_ring = {
+static const struct radeon_asic_ring cayman_dma_ring = {
.ib_execute = &cayman_dma_ring_ib_execute,
.ib_parse = &evergreen_dma_ib_parse,
.emit_fence = &evergreen_dma_fence_ring_emit,
@@ -1642,7 +1642,7 @@ static struct radeon_asic_ring cayman_dma_ring = {
.s
[PATCH v2] backlight: tps65217_bl: Add MODULE_DEVICE_TABLE.
The device table is required to load modules based on modaliases.
Signed-off-by: Enric Balletbo i Serra
---
Changes since last version:
- Use of_match_ptr (Lee Jones)
drivers/video/backlight/tps65217_bl.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
index 61d72bf..fd524ad 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -320,10 +320,19 @@ static int tps65217_bl_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id tps65217_bl_of_match[] = {
+ { .compatible = "ti,tps65217-bl", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65217_bl_of_match);
+#endif
+
static struct platform_driver tps65217_bl_driver = {
.probe = tps65217_bl_probe,
.driver = {
.name = "tps65217-bl",
+ .of_match_table = of_match_ptr(tps65217_bl_of_match),
},
};
--
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 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors
On 25/11/15 11:28, Marc Titinger wrote:
> in SOFTWARE buffer mode, a kthread will capture the active scan_elements
> into a kfifo, then compute the remaining time until the next capture tick
> and do an active wait (udelay).
>
> This will produce a stream of up to fours channels plus a 64bits
> timestamps (ns).
>
> Tested with ina226, on BeagleBoneBlack.
>
> Datasheet: http://www.ti.com/lit/gpn/ina226
>
> Signed-off-by: Marc Titinger
A few more bits from me, but basically looking good.
We do however, need to make the hwmon guys aware this is going on.
Please cc their list on the next version.
Last thing we want is for this to turn up as a surprise!
Jonathan
> ---
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ina2xx-iio.c | 684
> +++
> 3 files changed, 695 insertions(+)
> create mode 100644 drivers/iio/adc/ina2xx-iio.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index eb0cd89..9b87372 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -170,6 +170,16 @@ config EXYNOS_ADC
> of SoCs for drivers such as the touchscreen and hwmon to use to share
> this resource.
>
> +config INA2XX_IIO
> + tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> + depends on I2C
> + select REGMAP_I2C
> + select IIO_BUFFER
> + help
> + Say yes here to build support for TI INA2xx familly Power Monitors.
> +
> + Note that this is not the existing hwmon interface for this device.
> +
> config LP8788_ADC
> tristate "LP8788 ADC driver"
> depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..74e4341 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> +obj-$(CONFIG_INA2XX_IIO) += ina2xx-iio.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/ina2xx-iio.c b/drivers/iio/adc/ina2xx-iio.c
> new file mode 100644
> index 000..4a0026c
> --- /dev/null
> +++ b/drivers/iio/adc/ina2xx-iio.c
> @@ -0,0 +1,684 @@
> +/*
> + * INA2XX Current and Power Monitors
> + *
> + * Copyright 2015 Baylibre SAS.
> + *
> + * 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.
> + *
> + * Based on linux/drivers/iio/adc/ad7291.c
> + * Copyright 2010-2011 Analog Devices Inc.
> + *
> + * Based on linux/drivers/hwmon/ina2xx.c
> + * Copyright 2012 Lothar Felten
> + *
> + * Licensed under the GPL-2 or later.
> + *
> + * IIO driver for INA219-220-226-230-231
> + *
> + * Configurable 7-bit I2C slave address from 0x40 to 0x4F
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> + * INA2XX registers definition
> + */
> +/* common register definitions */
> +#define INA2XX_CONFIG 0x00
> +#define INA2XX_SHUNT_VOLTAGE0x01 /* readonly */
> +#define INA2XX_BUS_VOLTAGE 0x02 /* readonly */
> +#define INA2XX_POWER0x03 /* readonly */
> +#define INA2XX_CURRENT 0x04 /* readonly */
> +#define INA2XX_CALIBRATION 0x05
> +
> +#define INA226_ALERT_MASK0x06
> +#define INA266_CVRF BIT(3)
> +
> +/* register count */
> +#define INA219_REGISTERS6
> +#define INA226_REGISTERS8
> +#define INA2XX_MAX_REGISTERS8
> +
> +/* settings - depend on use case */
> +#define INA219_CONFIG_DEFAULT 0x399F /* PGA=8 */
> +#define INA226_CONFIG_DEFAULT 0x4327
> +#define INA226_DEFAULT_AVG 4
> +#define INA226_DEFAULT_IT1110
> +
> +#define INA2XX_RSHUNT_DEFAULT 1
> +
> +/*
> + * bit mask for reading the averaging setting in the configuration register
> + * FIXME: use regmap_fields.
> + */
> +#define INA2XX_MODE_MASK GENMASK(3, 0)
> +
> +#define INA226_AVG_MASK GENMASK(11, 9)
> +#define INA226_SHIFT_AVG(val)((val) << 9)
> +
> +/* Integration time for VBus */
> +#define INA226_ITB_MASK GENMASK(8, 6)
> +#define INA226_SHIFT_ITB(val)((val) << 6)
> +
> +/*Integration Time for VShunt */
> +#define INA226_ITS_MASK GENMASK(5, 3)
> +#define INA226_SHIFT_ITS(val)((val) << 3)
> +
> +
> +static bool ina2xx_is_writeable_reg(struct device *dev, unsigned int reg)
> +{
> + return (reg == INA2XX_CONFIG) || (reg > INA2XX_CURRENT);
> +}
> +
> +static bool ina2xx_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> +
[PATCH v2] gpio: Add GPIO support for the ACCES 104-IDI-48
The ACCES 104-IDI-48 family of PC/104 utility boards feature 48
individually optically isolated digital inputs. Enabled inputs feature
change-of-state detection capability; if change-of-state detection is
enabled, an interrupt is fired off if a change of input level
(low-to-high or high-to-low) is detected. Change-of-state IRQs are
enabled/disabled on 8-bit boundaries, for a total of six boundaries.
This driver provides GPIO and IRQ support for these 48 channels of
digital input. The base port address for the device may be configured
via the idi_48_base module parameter. The interrupt line number for the
device may be configured via the idi_48_irq module parameter.
Signed-off-by: William Breathitt Gray
---
Changes in v2:
- Reimplement irq_ack callback as a NOOP since status register read in
idi_48_irq_handler clears all pending interrupts.
MAINTAINERS| 6 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-104-idi-48.c | 340 +
4 files changed, 356 insertions(+)
create mode 100644 drivers/gpio/gpio-104-idi-48.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 629727e..f04fb49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -240,6 +240,12 @@ L: lm-sens...@lm-sensors.org
S: Maintained
F: drivers/hwmon/abituguru3.c
+ACCES 104-IDI-48 GPIO DRIVER
+M: "William Breathitt Gray"
+L: linux-g...@vger.kernel.org
+S: Maintained
+F: drivers/gpio/gpio-104-idi-48.c
+
ACCES 104-IDIO-16 GPIO DRIVER
M: "William Breathitt Gray"
L: linux-g...@vger.kernel.org
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 18e1aa0..30d8bd3 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -503,6 +503,15 @@ config GPIO_104_IDIO_16
parameter. The interrupt line number for the device may be set via the
idio_16_irq module parameter.
+config GPIO_104_IDI_48
+ tristate "ACCES 104-IDI-48 GPIO support"
+ select GPIOLIB_IRQCHIP
+ help
+ Enables GPIO support for the ACCES 104-IDI-48 family. The base port
+ address for the device may be configured via the idi_48_base module
+ parameter. The interrupt line number for the device may be configured
+ via the idi_48_irq module parameter.
+
config GPIO_F7188X
tristate "F71869, F71869A, F71882FG and F71889F GPIO support"
help
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 986dbd8..548e9b5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o
obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
obj-$(CONFIG_GPIO_104_IDIO_16) += gpio-104-idio-16.o
+obj-$(CONFIG_GPIO_104_IDI_48) += gpio-104-idi-48.o
obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_74XX_MMIO) += gpio-74xx-mmio.o
obj-$(CONFIG_GPIO_ADNP)+= gpio-adnp.o
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
new file mode 100644
index 000..61860e7
--- /dev/null
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -0,0 +1,340 @@
+/*
+ * GPIO driver for the ACCES 104-IDI-48 family
+ * Copyright (C) 2015 William Breathitt Gray
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static unsigned idi_48_base;
+module_param(idi_48_base, uint, 0);
+MODULE_PARM_DESC(idi_48_base, "ACCES 104-IDI-48 base address");
+static unsigned idi_48_irq;
+module_param(idi_48_irq, uint, 0);
+MODULE_PARM_DESC(idi_48_irq, "ACCES 104-IDI-48 interrupt line number");
+
+/**
+ * struct idi_48_gpio - GPIO device private data structure
+ * @chip: instance of the gpio_chip
+ * @lock: synchronization lock to prevent I/O race conditions
+ * @irq_mask: input bits affected by interrupts
+ * @base: base port address of the GPIO device
+ * @extent:extent of port address region of the GPIO device
+ * @irq: Interrupt line number
+ * @cos_enb: Change-Of-State IRQ enable boundaries mask
+ */
+struct idi_48_gpio {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ unsigned char irq_mask[6];
+ unsigned base;
+ unsigned extent;
+ unsigned irq;
+ unsigned char cos_enb;
+};
+
+static int idi_48_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ return 1;
+}
+
+static int idi_48_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+ return 0
Re: [PATCH 2/2] iio: ina2xx: provide a sysfs parameter to allow async readout of the ADCs
On 25/11/15 11:28, Marc Titinger wrote:
> This can lead to repeated or skipped samples depending on the clock beat
> between the capture thread and the chip sampling clock, but will also spare
> reading/waiting for the Capture Ready Flag and improve the available i2c
> bandwidth for reading measurements.
>
> Output of iio_info:
> ...snip...
> 4 device-specific attributes found:
> attr 0: in_oversampling_ratio value: 4
> attr 1: in_allow_async_readout value: 0
> attr 2: integration_time_available value: 140 204 332 588 1100 2116 4156
> 8244
> attr 3: in_sampling_frequency value: 114
>
This is a good compromise if it is needed to get the rates as high as
you need.
One suggestion inline.
Jonathan
> Signed-off-by: Marc Titinger
> ---
> drivers/iio/adc/ina2xx-iio.c | 48
> ++--
> 1 file changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/adc/ina2xx-iio.c b/drivers/iio/adc/ina2xx-iio.c
> index 4a0026c..c153164 100644
> --- a/drivers/iio/adc/ina2xx-iio.c
> +++ b/drivers/iio/adc/ina2xx-iio.c
> @@ -114,6 +114,7 @@ struct ina2xx_chip_info {
> int avg;
> int itb; /* Bus voltage integration time uS */
> int its; /* Shunt voltage integration tim uS */
> + bool allow_async_readout;
> };
>
> static const struct ina2xx_config ina2xx_config[] = {
> @@ -335,6 +336,33 @@ _err:
> }
>
>
> +static ssize_t ina2xx_allow_async_readout_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + struct ina2xx_chip_info *chip = iio_priv(dev_to_iio_dev(dev));
> +
> + return sprintf(buf, "%d\n", chip->allow_async_readout);
> +}
> +
> +static ssize_t ina2xx_allow_async_readout_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct ina2xx_chip_info *chip = iio_priv(dev_to_iio_dev(dev));
> + unsigned long val;
> + int ret;
> +
strtobool would simplify this.
> + ret = kstrtoul((const char *) buf, 10, &val);
> + if (ret)
> + return -EINVAL;
> +
> + chip->allow_async_readout = !!val;
> +
> + return len;
> +}
> +
> +
> #define INA2XX_CHAN(_type, _index, _address) { \
> .type = _type, \
> .address = _address, \
> @@ -402,11 +430,12 @@ static int ina2xx_work_buffer(struct iio_dev *indio_dev)
>* GPIO a triggered buffer could be used instead.
>* For now, we pay for that extra read of the ALERT register
>*/
> - do {
> - ret = regmap_read(chip->regmap, INA226_ALERT_MASK,
> - &alert);
> - if (ret < 0)
> - goto _err;
> + if (!chip->allow_async_readout)
> + do {
> + ret = regmap_read(chip->regmap, INA226_ALERT_MASK,
> + &alert);
> + if (ret < 0)
> + goto _err;
>
> alert &= INA266_CVRF;
> trace_printk("Conversion ready: %d\n", !!alert);
> @@ -457,7 +486,8 @@ static int ina2xx_capture_thread(void *data)
>* Poll a bit faster than the chip internal Fs, in case
>* we wish to sync with the conversion ready flag.
>*/
> - sampling_us -= 200;
> + if (!chip->allow_async_readout)
> + sampling_us -= 200;
>
> do {
> buffer_us = ina2xx_work_buffer(indio_dev);
> @@ -480,6 +510,7 @@ int ina2xx_buffer_enable(struct iio_dev *indio_dev)
>100/sampling_us, chip->avg);
>
> trace_printk("Expected work period: %u us\n", sampling_us);
> + trace_printk("Async readout mode: %d\n", chip->allow_async_readout);
>
> prev_ns = iio_get_time_ns();
>
> @@ -519,7 +550,12 @@ static int ina2xx_debug_reg(struct iio_dev *indio_dev,
> /* frequencies matching the cummulated integration times for vshunt and vbus
> */
> static IIO_CONST_ATTR_INT_TIME_AVAIL("140 204 332 588 1100 2116 4156 8244");
>
> +static IIO_DEVICE_ATTR(in_allow_async_readout, S_IRUGO | S_IWUSR,
> +ina2xx_allow_async_readout_show,
> +ina2xx_allow_async_readout_store, 0);
> +
> static struct attribute *ina2xx_attributes[] = {
> + &iio_dev_attr_in_allow_async_readout.dev_attr.attr,
> &iio_const_attr_integration_time_available.dev_attr.attr,
> NULL,
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: block: Always check queue limits for cloned requests
On Sun, Nov 29 2015 at 11:15am -0500, Markus Trippelsdorf wrote: > On 2015.11.29 at 16:43 +0100, Hannes Reinecke wrote: > > On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote: > > > > > > I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even > > > with this patch applied. > > > > > > markus@x4 linux % git describe > > > v4.4-rc2-215-g081f3698e606 > > > > > Can you generate a crashdump? > > I would need to cross-check with the other dumps I'm having to figure > > out if this really is the same issue. > > There have been other reports (and fixes) which show we're fighting > > several distinct issues here. > > Unfortunately no. The crash happens on the disk where I store my log > files. And after it happened the magic SysRq keys don't work anymore. > > The crash only happens on my spinning rust drive that uses the cfq > scheduler. The SSDs (deadline) are fine. > > The BUG happens reproducibly when building http://www.sagemath.org/ on > that drive. Are you using DM multipath? If unsure, please let us know which device(s) map to the "spinning rust drive", and provide output from: lsblk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] serial: imx: fix a possible NULL dereference
On Tue, Nov 24, 2015 at 03:36:57PM +0100, LABBE Corentin wrote: > of_match_device could return NULL, and so cause a NULL pointer > dereference later. > Even if the probability of this case is very low, fixing it made > static analyzers happy. > Solving this with of_device_get_match_data made also code simplier. > > Signed-off-by: LABBE Corentin Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: block: Always check queue limits for cloned requests
On 2015.11.29 at 11:49 -0500, Mike Snitzer wrote: > On Sun, Nov 29 2015 at 11:15am -0500, > Markus Trippelsdorf wrote: > > > On 2015.11.29 at 16:43 +0100, Hannes Reinecke wrote: > > > On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote: > > > > > > > > I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even > > > > with this patch applied. > > > > > > > > markus@x4 linux % git describe > > > > v4.4-rc2-215-g081f3698e606 > > > > > > > Can you generate a crashdump? > > > I would need to cross-check with the other dumps I'm having to figure > > > out if this really is the same issue. > > > There have been other reports (and fixes) which show we're fighting > > > several distinct issues here. > > > > Unfortunately no. The crash happens on the disk where I store my log > > files. And after it happened the magic SysRq keys don't work anymore. > > > > The crash only happens on my spinning rust drive that uses the cfq > > scheduler. The SSDs (deadline) are fine. > > > > The BUG happens reproducibly when building http://www.sagemath.org/ on > > that drive. > > Are you using DM multipath? If unsure, please let us know which > device(s) map to the "spinning rust drive", and provide output from: > lsblk No, I'm not using DM multipath. /dev/sdb2 on /var type btrfs (rw,relatime,compress=lzo,noacl,space_cache) /dev/sdb2 btrfs 1.9T 904G 944G 49% /var scsi 1:0:0:0: Direct-Access ATA ST2000DM001-1CH1 CC29 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) sd 1:0:0:0: [sdb] 4096-byte physical blocks sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Model Family: Seagate Barracuda 7200.14 (AF) Device Model: ST2000DM001-1CH164 -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/5] configfs: Allow dynamic group creation
On 18/11/15 07:33, Jonathan Cameron wrote: > > > On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton > wrote: >> On Sun, 15 Nov 2015 10:39:08 + Jonathan Cameron >> wrote: >> >>> On 11/11/15 06:43, Jonathan Cameron wrote: On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton >> wrote: > On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig > wrote: > >> is this simple addition something you could still send on to >> Linus >> for this merge window? I would make my life easier to have it in >> so I could start using it in patches for various trees in the >> next >> merge window. > > It's super late, but the configfs changes are obviously safe to > existing code. > > What about the IIO changes? Will someone be merging them for >> 4.5-rc1, > or something else? Yes. I'll take the IIO bits and ultimately they'll go through Greg >> KH for the 4.5 merge window. >>> Hi Andrew, >>> >>> Just taken a quick look at your mmotm list and see this ended up in >> the >>> mainline later group (fair enough given the timing!). >>> As such shall we fall back to plan b) a special git branch pulled >> into the trees >>> of anyone who cares? >>> >>> I'll base such a tree on some obvious point in Linus' tree (either >> 4.4 or 4.5-rc1) >>> That way I can get the IIO stuff queued up asap and we can build on >> that going >>> forward during this cycle. >> >> I plan to send configfs-allow-dynamic-group-creation.patch to Linus >> this week. I'll retain >> >> iio-core-introduce-iio-configfs-support.patch >> iio-core-introduce-iio-software-triggers.patch >> iio-core-introduce-iio-software-triggers-fix.patch >> iio-trigger-introduce-iio-hrtimer-based-trigger.patch >> iio-documentation-add-iio-configfs-documentation.patch >> >> with a view to dropping them once I see them turn up in linux-next. > > That's great. Thanks. I've now applied the rest of the series to my local togreg branch and pushed out as testing for the autobuilders to play with them. This branch will get rebased once Greg has picked up the previous PULL request. Thanks, Jonathan > > Jonathan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 BUGFIX 1/3] null_blk: set a separate timer for each command
Hi Jens, this is just to ask you whether you made any decision about these patches, including just not to apply them. Thanks, Paolo Il giorno 03/nov/2015, alle ore 10:01, Paolo Valente ha scritto: > > Il giorno 02/nov/2015, alle ore 17:14, Jens Axboe ha scritto: > >> On 11/02/2015 07:31 AM, Paolo Valente wrote: >>> For the Timer IRQ mode (i.e., when command completions are delayed), >>> there is one timer for each CPU. Each of these timers >>> . has a completion queue associated with it, containing all the >>> command completions to be executed when the timer fires; >>> . is set, and a new completion-to-execute is inserted into its >>> completion queue, every time the dispatch code for a new command >>> happens to be executed on the CPU related to the timer. >>> >>> This implies that, if the dispatch of a new command happens to be >>> executed on a CPU whose timer has already been set, but has not yet >>> fired, then the timer is set again, to the completion time of the >>> newly arrived command. When the timer eventually fires, all its queued >>> completions are executed. >>> >>> This way of handling delayed command completions entails the following >>> problem: if more than one command completion is inserted into the >>> queue of a timer before the timer fires, then the expiration time for >>> the timer is moved forward every time each of these completions is >>> enqueued. As a consequence, only the last completion enqueued enjoys a >>> correct execution time, while all previous completions are unjustly >>> delayed until the last completion is executed (and at that time they >>> are executed all together). >>> >>> Specifically, if all the above completions are enqueued almost at the >>> same time, then the problem is negligible. On the opposite end, if >>> every completion is enqueued a while after the previous completion was >>> enqueued (in the extreme case, it is enqueued only right before the >>> timer would have expired), then every enqueued completion, except for >>> the last one, experiences an inflated delay, proportional to the number >>> of completions enqueued after it. In the end, commands, and thus I/O >>> requests, may be completed at an arbitrarily lower rate than the >>> desired one. >>> >>> This commit addresses this issue by replacing per-CPU timers with >>> per-command timers, i.e., by associating an individual timer with each >>> command. >> >> Functionally the patch looks fine. My only worry is that a timer per command >> would be an unnecessary slowdown compared to pushing one timer forward. The >> problem should be fixable by still doing that, just maintaining next-expire >> instead. Maybe something that would still roughly be precise enough, while >> still getting some completion batching going? Or maybe that would be slower, >> and the individual timers are still better. >> >> Comments? >> > > I have tried to think about these questions. Unfortunately I was not able to > go beyond the following general considerations. > > Given that: > 1) hrtimer_start is very efficient; > 2) to implement a batch-by-batch execution of command completions, a more > complex code would of course be needed in null_blk; > I think that, to get a perceptible improvement, command completions should > probably be executed in batches of at least 3 or 4 commands each. > > In this respect, commands can accumulate in a batch only if the time > granularity with which delayed commands are guaranteed to be executed, i.e, > the granularity with which timers eventually fire, happens to be coarser than > completion_nsec. But this would lead to the exact uncontrolled > throughput-loss problem addressed by this patch, although at a lesser extent. > The reason is as follows. > > Consider a batch of 3 or 4 commands, executed at a certain timer expiration. > If the arrival time of these commands is close to the timer expiration, then > the commands happen to be executed with a delay close to the expected one. > If, on the other hand, their arrival time is far from the timer expiration, > then they are completed with a larger delay. In the worst case, their delay > is inflated by a factor proportional to the size of the batch, namely 3 or 4. > > In the end, depending on the command arrival pattern, the throughput of the > emulated device may vary by 3 or 4 times. This would be a reduced version of > the issue addressed by this patch. In fact, with the current implementation > of delayed completions (per-cpu timers), the throughput may vary, in the > worst case, by a factor equal to the queue depth (64 by default). > > Finally, a side note: as for whether the increased efficiency of batched > delayed completions is worth additional code complexity as well as throughput > losses/fluctuations, the low delays for which this efficiency becomes > important match the latencies of new very fast devices (or are at least in > the same order). But, exactly for the high speed of the
[PATCH] ALSA: i2c: constify snd_i2c_ops structures
The snd_i2c_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
include/sound/i2c.h |2 +-
sound/i2c/i2c.c |2 +-
sound/pci/ice1712/delta.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/sound/i2c.h b/include/sound/i2c.h
index d125ff8..835254d 100644
--- a/include/sound/i2c.h
+++ b/include/sound/i2c.h
@@ -66,7 +66,7 @@ struct snd_i2c_bus {
struct snd_i2c_bit_ops *bit;
void *ops;
} hw_ops; /* lowlevel operations */
- struct snd_i2c_ops *ops;/* midlevel operations */
+ const struct snd_i2c_ops *ops; /* midlevel operations */
unsigned long private_value;
void *private_data;
diff --git a/sound/i2c/i2c.c b/sound/i2c/i2c.c
index 4677037..ef2a9af 100644
--- a/sound/i2c/i2c.c
+++ b/sound/i2c/i2c.c
@@ -39,7 +39,7 @@ static int snd_i2c_bit_readbytes(struct snd_i2c_device
*device,
static int snd_i2c_bit_probeaddr(struct snd_i2c_bus *bus,
unsigned short addr);
-static struct snd_i2c_ops snd_i2c_bit_ops = {
+static const struct snd_i2c_ops snd_i2c_bit_ops = {
.sendbytes = snd_i2c_bit_sendbytes,
.readbytes = snd_i2c_bit_readbytes,
.probeaddr = snd_i2c_bit_probeaddr,
diff --git a/sound/pci/ice1712/delta.c b/sound/pci/ice1712/delta.c
index 496dbd0..3bfdc78 100644
--- a/sound/pci/ice1712/delta.c
+++ b/sound/pci/ice1712/delta.c
@@ -174,7 +174,7 @@ static int ap_cs8427_probeaddr(struct snd_i2c_bus *bus,
unsigned short addr)
return -ENOENT;
}
-static struct snd_i2c_ops ap_cs8427_i2c_ops = {
+static const struct snd_i2c_ops ap_cs8427_i2c_ops = {
.sendbytes = ap_cs8427_sendbytes,
.readbytes = ap_cs8427_readbytes,
.probeaddr = ap_cs8427_probeaddr,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ina2xx: add support for TI INA2xx Power Monitors
On 11/29/2015 08:31 AM, Jonathan Cameron wrote:
On 25/11/15 11:28, Marc Titinger wrote:
in SOFTWARE buffer mode, a kthread will capture the active scan_elements
into a kfifo, then compute the remaining time until the next capture tick
and do an active wait (udelay).
This will produce a stream of up to fours channels plus a 64bits
timestamps (ns).
Tested with ina226, on BeagleBoneBlack.
Datasheet: http://www.ti.com/lit/gpn/ina226
Signed-off-by: Marc Titinger
A few more bits from me, but basically looking good.
We do however, need to make the hwmon guys aware this is going on.
Please cc their list on the next version.
Last thing we want is for this to turn up as a surprise!
I have seen the original patch, so no surprise here. Just not sure
if we should remove the hwmon driver after the iio driver is accepted.
Even though the stated goal is different, it seems to me that having
two drivers really does not make sense. Any thoughts ?
Guenter
Jonathan
---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ina2xx-iio.c | 684 +++
3 files changed, 695 insertions(+)
create mode 100644 drivers/iio/adc/ina2xx-iio.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..9b87372 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -170,6 +170,16 @@ config EXYNOS_ADC
of SoCs for drivers such as the touchscreen and hwmon to use to share
this resource.
+config INA2XX_IIO
+ tristate "Texas Instruments INA2xx Power Monitors IIO driver"
+ depends on I2C
+ select REGMAP_I2C
+ select IIO_BUFFER
+ help
+ Say yes here to build support for TI INA2xx familly Power Monitors.
+
+ Note that this is not the existing hwmon interface for this device.
+
config LP8788_ADC
tristate "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..74e4341 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_INA2XX_IIO) += ina2xx-iio.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/ina2xx-iio.c b/drivers/iio/adc/ina2xx-iio.c
new file mode 100644
index 000..4a0026c
--- /dev/null
+++ b/drivers/iio/adc/ina2xx-iio.c
@@ -0,0 +1,684 @@
+/*
+ * INA2XX Current and Power Monitors
+ *
+ * Copyright 2015 Baylibre SAS.
+ *
+ * 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.
+ *
+ * Based on linux/drivers/iio/adc/ad7291.c
+ * Copyright 2010-2011 Analog Devices Inc.
+ *
+ * Based on linux/drivers/hwmon/ina2xx.c
+ * Copyright 2012 Lothar Felten
+ *
+ * Licensed under the GPL-2 or later.
+ *
+ * IIO driver for INA219-220-226-230-231
+ *
+ * Configurable 7-bit I2C slave address from 0x40 to 0x4F
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * INA2XX registers definition
+ */
+/* common register definitions */
+#define INA2XX_CONFIG 0x00
+#define INA2XX_SHUNT_VOLTAGE0x01 /* readonly */
+#define INA2XX_BUS_VOLTAGE 0x02 /* readonly */
+#define INA2XX_POWER0x03 /* readonly */
+#define INA2XX_CURRENT 0x04 /* readonly */
+#define INA2XX_CALIBRATION 0x05
+
+#define INA226_ALERT_MASK 0x06
+#define INA266_CVRFBIT(3)
+
+/* register count */
+#define INA219_REGISTERS6
+#define INA226_REGISTERS8
+#define INA2XX_MAX_REGISTERS8
+
+/* settings - depend on use case */
+#define INA219_CONFIG_DEFAULT 0x399F /* PGA=8 */
+#define INA226_CONFIG_DEFAULT 0x4327
+#define INA226_DEFAULT_AVG 4
+#define INA226_DEFAULT_IT 1110
+
+#define INA2XX_RSHUNT_DEFAULT 1
+
+/*
+ * bit mask for reading the averaging setting in the configuration register
+ * FIXME: use regmap_fields.
+ */
+#define INA2XX_MODE_MASK GENMASK(3, 0)
+
+#define INA226_AVG_MASKGENMASK(11, 9)
+#define INA226_SHIFT_AVG(val) ((val) << 9)
+
+/* Integration time for VBus */
+#define INA226_ITB_MASKGENMASK(8, 6)
+#define INA226_SHIFT_ITB(val) ((val) << 6)
+
+/*Integration Time for VShunt */
+#define INA226_ITS_MASKGENMASK(5, 3)
+#define INA226_SHIFT_ITS(val) ((val) << 3)
+
+
+static bool ina2xx_is_writeable_reg(struct device *dev, unsigned int reg)
+{
+ return (reg == INA2XX_CONFIG) || (reg > INA2XX_CURRENT);
+}
+
+static b
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
On 29 November 2015 at 16:39, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team wrote: >> > >> > > i don't see the compile time vs. runtime detection as 'competing' >> > > approaches, >> > > both have their own role. [...] >> > >> > That's true - but only as long as 'this can be solved in tooling!' is not >> > used as >> > an excuse to oppose the runtime solution and we end up doing neither. >> >> actually, i already voiced my opinion elsewhere in the constify thread on the >> kernel hardening list that adding/using __read_only is somewhat premature >> without also adding the compile time verification part (as part of the >> constify >> plugin for example). right now its use on the embedded vdso image is simple >> and >> easy to verify but once people begin to add it to variables that the compiler >> knows and cares about (say, the ops structures) then things can become >> fragile >> without compile checking. so yes, i'd also advise to get such tooling in >> *before* more __read_only usage is added. > > I think you are mistaken there: if we add the page fault fixup to make sure we > don't crash if a read-only variable is accessed, then we'll have most of the > benefits of read-only mappings and no fragility - without having to wait for > tooling. I guess the point PaX Team (and me earlier in this thread) wanted to make is that having misuse detection *only* at run-time will make those kind of bugs visible too late -- as late as on the wrong write attempt actually happening. It would be much better to have the compiler complain about invalid write statements already during compilation, much like it does when one wants to assign some value to a const object. Having the page fault handler being able to recover from __ro_after_init faults is a nice feature to support users, actually being able to report bugs. But it shouldn't be the only way to detect those kinds of bugs. In fact, we've tools in our toolchain that try to detect and flag wrong usage of __init / __exit, so why not cover __ro_after_init as well? Admitted, that won't be possible with modpost in its current state, but would require a compiler extension instead. Its current non-existence shouldn't be a show-stopper for __ro_after_init but the very next step to take care of before extending the usage of that annotation. Just my 2ct, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi
Hello Maxime,
Sorry for delayed response.
On Mon, Oct 26, 2015 at 4:20 AM, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Oct 23, 2015 at 07:46:16AM +0800, Vishnu Patekar wrote:
>> + memory {
>> + reg = <0x4000 0x8000>;
>> + };
>> +
>> + timer {
>> + compatible = "arm,armv7-timer";
>> + interrupts = > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>;
>
> Shouldn't the number of CPUs be 8?
Yes, It should be 8, also need to change in gic node to 8 CPUs.
No, smp support till now, still I'll change it in next patch version.
>
>> + clock-frequency = <2400>;
>> + arm,cpu-registers-not-fw-configured;
>> + };
>
> Is there some u-boot support for this SoC yet?
recently, I've posted the v2 of u-boot patch.
>
> If so, both the memory node and the clock-frequency and
> arm,cpu-registers-not-fw-configured properties are useless (and
> harmful for the latter).
Correct, As, timer support is added in u-boot, I'll remove these two.
>
>> + soc@01c0 {
>
> Please remove the address. It's both wrong and useless.
>
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + gic: interrupt-controller@01c81000 {
>> + compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
>> + reg = <0x01c81000 0x1000>,
>> + <0x01c82000 0x1000>,
>> + <0x01c84000 0x2000>,
>> + <0x01c86000 0x2000>;
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>> + };
>> +
>> + pio: pinctrl@01c20800 {
>> + compatible = "allwinner,sun8i-a83t-pinctrl";
>> + interrupts = ,
>> + ,
>> + ;
>
> Please align these lines with the first one, like you did for the
> GIC's reg for example.
Okie.
>
>> + reg = <0x01c20800 0x400>;
>> + clocks = <&osc24M>;
>> + gpio-controller;
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + #gpio-cells = <3>;
>> +
>> + i2c0_pins_a: i2c0@0 {
>> + allwinner,pins = "PH0", "PH1";
>> + allwinner,function = "i2c0";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + i2c1_pins_a: i2c1@0 {
>> + allwinner,pins = "PH2", "PH3";
>> + allwinner,function = "i2c1";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + i2c2_pins_a: i2c2@0 {
>> + allwinner,pins = "PH4", "PH5";
>> + allwinner,function = "i2c2";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc0_pins_a: mmc0@0 {
>> + allwinner,pins = "PF0", "PF1", "PF2",
>> + "PF3", "PF4", "PF5";
>> + allwinner,function = "mmc0";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc1_pins_a: mmc1@0 {
>> + allwinner,pins = "PG0", "PG1", "PG2",
>> + "PG3", "PG4", "PG5";
>> + allwinner,function = "mmc1";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc2_8bit_pins: mmc2_8bit {
>> + allwinner,pins = "PC5", "PC6", "PC8",
>> + "PC9", "PC10", "PC11",
>> + "PC12", "PC13", "PC14",
>> + "PC15";
>> + allwinner,function = "mmc2";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + uart0_pins_a: uart0@0 {
>> + allwinner,pins = "PF2", "PF4";
>> + allwinner,function = "uart0";
>> + allwinner,drive = ;
>> +
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > Good. And Arnd likes the idea too. So we might be converging at last > which is a good thing. I disagree with the idea that there is convergence. There might be convergence towards an idea, but... Here's a mail extract, from July 7th, from earlier in this very thread: Pali: > Me: > > Are the ATAGs at a fixed address on the N900? > > Yes, in board-rx51.c is: > > .atag_offset= 0x100 > > and Nokia Bootloader (proprietary) store them to that address. > > > Can that be handled in > > some kind of legacy file for the N900 which calls save_atags() on it, so > > we don't end up introducing yet more stuff that we have to maintain into > > the distant future? If not, what about copying a known working atag > > structure into a legacy file for the N900? > > > > I already asked question if it is possible to read ATAGs from DT booted > kernel. And somebody (do not remember who) wrote to ML, that it is not > possible and it can be done in that uncompress code. So you're converging on an idea that has already been rejected. That's not a good thing, IMHO. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: skein: Adds test vectors & cleans up maros
On Sun, Nov 29, 2015 at 12:51:30PM +, jp...@tutanota.de wrote: > The patch for cleaning up the Skein hash implementation is included below. > > The test & pass vectors for the hash function have been included, but not > checked as the competition is still ongoing,as the final specification is > unknown at this time. > > The files are verbatim lifted from the author's website (https:// > www.schneier.com/code/skein_NIST_CD_102610.zip). > The changes provide by me are moving all macros in the .c files to their > repective .h files. As this was strictly a cosmetic change, I have not tested > it with a rebuild. > > This patch helps move the Skein driver along towards completion. > > A signed version of this patch is included in the attachments. > Also, please sign my attached GPG Key, if possible. > Thank you. > Signed-off-by: Sanidhya Solanki > Lots of this should be below in the changelog itself, the patch should be "self-contained" and not need to be hand-edited in order to be applied. > > commit 6d50eca21b913f47899d9b91413968b8bccb6e31 > Author: Sanidhya Solanki > Date: Fri Nov 27 01:54:23 2015 -0500 Why is this all here? Please use git send-email to send a patch if your email client can't just send them directly. > > - Added Test files. > - Moved macros to appropriate Header Files. > - Cleaned up TODO & added contact information. > - Passing Test Vectors remains. > - Adding module support remains. That's a lot of different things all at once, please break this up into a patch series, each one doing only one thing. > > Changes to be committed: > modified: drivers/staging/skein/TODO > modified: drivers/staging/skein/skein_block.c > copied: drivers/staging/skein/skein_block.c -> drivers/staging/ > skein/skein_block.h > new file: drivers/staging/skein/skein_test.c > new file: drivers/staging/skein/skein_test.h What is all of these lines for? And you don't have a signed-off-by in the patch body itself. My scripts warned you about all of the above last time, why didn't you pay attention to them? And finally, please use scripts/get_maintainer.pl to determine the correct people and mailing lists to send a patch to. hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] RTC fixes for 4.4
Hi Linus, Here are two fixes for the ds1307 driver. I don't expect much more for this cycle. The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4: Linux 4.4-rc2 (2015-11-22 16:45:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.4-2 for you to fetch changes up to 3abb1ada21a4fb5b2920457a2e5c8483abb09a45: rtc: ds1307: fix alarm reading at probe time (2015-11-26 18:11:26 +0100) RTC fixes for 4.4 Two fixes for the ds1307 alarm and wakeup. Felipe Balbi (1): rtc: ds1307: fix kernel splat due to wakeup irq handling Simon Guinot (1): rtc: ds1307: fix alarm reading at probe time arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 + drivers/rtc/rtc-ds1307.c| 44 ++--- 2 files changed, 9 insertions(+), 36 deletions(-) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android 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] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote: > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > Good. And Arnd likes the idea too. So we might be converging at > > last which is a good thing. > > I disagree with the idea that there is convergence. There might be > convergence towards an idea, but... Here's a mail extract, from July > 7th, from earlier in this very thread: > > Pali: > > Me: > > > Are the ATAGs at a fixed address on the N900? > > > > Yes, in board-rx51.c is: > > > > .atag_offset= 0x100 > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > Can that be handled in > > > some kind of legacy file for the N900 which calls save_atags() on > > > it, so we don't end up introducing yet more stuff that we have > > > to maintain into the distant future? If not, what about copying > > > a known working atag structure into a legacy file for the N900? > > > > I already asked question if it is possible to read ATAGs from DT > > booted kernel. And somebody (do not remember who) wrote to ML, > > that it is not possible and it can be done in that uncompress > > code. > > So you're converging on an idea that has already been rejected. > That's not a good thing, IMHO. Or in other case show that such implementation is possible... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
