[PATCH 1/2] groups: Factor out a function to set a pre-sorted group list
This way, functions that already need to sort the group list need not do
so twice.
The new set_groups_sorted is intentionally not exported.
Signed-off-by: Josh Triplett
---
kernel/groups.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f..f0667e7 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -154,16 +154,26 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
}
/**
+ * set_groups_sorted - Change a group subscription in a set of credentials
+ * @new: The newly prepared set of credentials to alter
+ * @group_info: The group list to install; must be sorted
+ */
+static void set_groups_sorted(struct cred *new, struct group_info *group_info)
+{
+ put_group_info(new->group_info);
+ get_group_info(group_info);
+ new->group_info = group_info;
+}
+
+/**
* set_groups - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
* @group_info: The group list to install
*/
void set_groups(struct cred *new, struct group_info *group_info)
{
- put_group_info(new->group_info);
groups_sort(group_info);
- get_group_info(group_info);
- new->group_info = group_info;
+ set_groups_sorted(new, group_info);
}
EXPORT_SYMBOL(set_groups);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
Currently, unprivileged processes (without CAP_SETGID) cannot call
setgroups at all. In particular, processes with a set of supplementary
groups cannot further drop permissions without obtaining elevated
permissions first.
Allow unprivileged processes to call setgroups with a subset of their
current groups; only require CAP_SETGID to add a group the process does
not currently have.
The kernel already maintains the list of supplementary group IDs in
sorted order, and setgroups already needs to sort the new list, so this
just requires a linear comparison of the two sorted lists.
This moves the CAP_SETGID test from setgroups into set_current_groups.
Tested via the following test program:
#include
#include
#include
#include
#include
void run_id(void)
{
pid_t p = fork();
switch (p) {
case -1:
err(1, "fork");
case 0:
execl("/usr/bin/id", "id", NULL);
err(1, "exec");
default:
if (waitpid(p, NULL, 0) < 0)
err(1, "waitpid");
}
}
int main(void)
{
gid_t list1[] = { 1, 2, 3, 4, 5 };
gid_t list2[] = { 2, 3, 4 };
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 1");
run_id();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
run_id();
if (setgroups(3, list2) < 0)
err(1, "setgroups 2");
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 3");
run_id();
return 0;
}
Without this patch, the test program gets EPERM from the second
setgroups call, after dropping root privileges. With this patch, the
test program successfully drops groups 1 and 5, but then gets EPERM from
the third setgroups call, since that call attempts to add groups the
process does not currently have.
Signed-off-by: Josh Triplett
---
kernel/groups.c | 33 ++---
kernel/uid16.c | 2 --
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index f0667e7..fe7367d 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -153,6 +153,29 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
return 0;
}
+/* Compare two sorted group lists; return true if the first is a subset of the
+ * second.
+ */
+static bool is_subset(const struct group_info *g1, const struct group_info *g2)
+{
+ unsigned int i, j;
+
+ for (i = 0, j = 0; i < g1->ngroups; i++) {
+ kgid_t gid1 = GROUP_AT(g1, i);
+ kgid_t gid2;
+ for (; j < g2->ngroups; j++) {
+ gid2 = GROUP_AT(g2, j);
+ if (gid_lte(gid1, gid2))
+ break;
+ }
+ if (j >= g2->ngroups || !gid_eq(gid1, gid2))
+ return false;
+ j++;
+ }
+
+ return true;
+}
+
/**
* set_groups_sorted - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
@@ -189,11 +212,17 @@ int set_current_groups(struct group_info *group_info)
{
struct cred *new;
+ groups_sort(group_info);
new = prepare_creds();
if (!new)
return -ENOMEM;
+ if (!ns_capable(current_user_ns(), CAP_SETGID)
+ && !is_subset(group_info, new->group_info)) {
+ abort_creds(new);
+ return -EPERM;
+ }
- set_groups(new, group_info);
+ set_groups_sorted(new, group_info);
return commit_creds(new);
}
@@ -233,8 +262,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *,
grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bb..b27e167 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t
__user *, grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH manpages] getgroups.2: Document unprivileged setgroups calls
Signed-off-by: Josh Triplett --- This should probably also include appropriate documentation for what kernel introduces this behavior. man2/getgroups.2 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/man2/getgroups.2 b/man2/getgroups.2 index 373c204..edca37c 100644 --- a/man2/getgroups.2 +++ b/man2/getgroups.2 @@ -81,9 +81,10 @@ to be used in a further call to .PP .BR setgroups () sets the supplementary group IDs for the calling process. -Appropriate privileges (Linux: the +Any process may drop groups from its list, but adding groups requires +appropriate privileges (Linux: the .B CAP_SETGID -capability) are required. +capability). The .I size argument specifies the number of supplementary group IDs -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: rely on the bi_end_io for zram_rw_page fails
Hi,
On (11/14/14 09:49), Minchan Kim wrote:
> When I tested zram, I found processes got segfaulted.
> The reason was zram_rw_page doesn't make the page dirty
> again when swap write failed, and even it doesn't return
> error by [1].
>
> If error by zram internal happens, zram_rw_page should return
> non-zero without calling page_endio.
> It causes resubmit the IO with bio so that it ends up calling
> bio->bi_end_io.
>
> The reason is zram could be used for a block device for FS and
> swap, which they uses different bio complete callback, which
> works differently. So, we should rely on the bio I/O complete
> handler rather than zram_bvec_rw itself in case of I/O fail.
>
> This patch fixes the segfault issue as well one [1]'s
> mentioned
>
> [1] zram: make rw_page opeartion return 0
>
> Cc: Matthew Wilcox
> Cc: Karam Lee
> Cc: Dave Chinner
> Signed-off-by: Minchan Kim
> ---
> drivers/block/zram/zram_drv.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 4b4f4dbc3cfd..0e0650feab2a 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -978,12 +978,10 @@ static int zram_rw_page(struct block_device *bdev,
> sector_t sector,
> out_unlock:
> up_read(&zram->init_lock);
> out:
> - page_endio(page, rw, err);
> + if (unlikely(err))
> + return err;
this unlikely() case can be turned into a likely() one:
if (err == 0)
page_endio(page, rw, 0);
return err;
> - /*
> - * Return 0 prevents I/O fallback trial caused by rw_page fail
> - * and upper layer can handle this IO error via page error.
> - */
> + page_endio(page, rw, 0);
> return 0;
> }
seems like we also can drop at least one goto (jump-to-return) for
invalid request.
(not sure about `goto out_unblock', yet another up_read(&zram->init_lock)
just will make function bigger).
Signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/zram_drv.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0e0650f..decca6f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -956,8 +956,7 @@ static int zram_rw_page(struct block_device *bdev, sector_t
sector,
zram = bdev->bd_disk->private_data;
if (!valid_io_request(zram, sector, PAGE_SIZE)) {
atomic64_inc(&zram->stats.invalid_io);
- err = -EINVAL;
- goto out;
+ return -EINVAL;
}
down_read(&zram->init_lock);
@@ -974,15 +973,11 @@ static int zram_rw_page(struct block_device *bdev,
sector_t sector,
bv.bv_offset = 0;
err = zram_bvec_rw(zram, &bv, index, offset, rw);
-
out_unlock:
up_read(&zram->init_lock);
-out:
- if (unlikely(err))
- return err;
-
- page_endio(page, rw, 0);
- return 0;
+ if (err == 0)
+ page_endio(page, rw, 0);
+ return err;
}
static const struct block_device_operations zram_devops = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86, mm: set NX across entire PMD at boot
On Fri, Nov 14, 2014 at 7:38 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 6:46 PM, Kees Cook wrote:
>> Is this correct? It sounded like tglx wanted the pmd split, like this:
>>
>> 0x8220-0x82c010M RW PSE GLB NX pmd
>> 0x82c0-0x82df5000 2004K RW GLB NX pte
>> 0x82df5000-0x82e044K RW NX pte
>> 0x82e0-0xc000 978M pmd
>
> Need to remove GLB ?
Please check attached one that clean up the highmap tail...
Subject: [RFC PATCH] x86, 64bit: cleanup highmap tail near partial 2M range
1. should use _brk_end instead of &end, as we only use partial of
brk.
2. [_brk_end, pm_end) page range is already converted mem. and
is not wasted.
3. add cleanup_highmap_tail for [_brk_end, pm_end).
Kernel Layout:
[0.00] .text: [0x0100-0x0200d5c8]
[0.00] .rodata: [0x0220-0x02a1cfff]
[0.00] .data: [0x02c0-0x02e50e7f]
[0.00] .init: [0x02e52000-0x03212fff]
[0.00].bss: [0x03221000-0x0437bfff]
[0.00].brk: [0x0437c000-0x043a1fff]
Actually used brk:
[0.272959] memblock_reserve: [0x000437c000-0x0004382fff]
flags 0x0 BRK
Before patch:
---[ High Kernel Mapping ]---
0x8000-0x8100 16M pmd
0x8100-0x8220 18M ro PSE GLB x pmd
0x8220-0x82c0 10M ro PSE GLB NX pmd
0x82c0-0x82e0 2M RW PSE GLB NX pmd
0x82e0-0x8300 2M RW GLB NX pte
0x8300-0x8320 2M RW PSE GLB NX pmd
0x8320-0x8340 2M RW GLB NX pte
0x8340-0x8420 14M RW PSE GLB NX pmd
0x8420-0x843a20001672K RW GLB NX pte
0x843a2000-0x8440 376K RW GLB x pte
0x8440-0xa000 444M pmd
After patch:
---[ High Kernel Mapping ]---
0x8000-0x8100 16M pmd
0x8100-0x8220 18M ro PSE GLB x pmd
0x8220-0x82c0 10M ro PSE GLB NX pmd
0x82c0-0x82e0 2M RW PSE GLB NX pmd
0x82e0-0x8300 2M RW GLB NX pte
0x8300-0x8320 2M RW PSE GLB NX pmd
0x8320-0x8340 2M RW GLB NX pte
0x8340-0x8420 14M RW PSE GLB NX pmd
0x8420-0x843830001548K RW GLB NX pte
0x84383000-0x8440 500K pte
0x8440-0xa000 444M pmd
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init_64.c | 23 ++-
arch/x86/mm/pageattr.c |2 +-
2 files changed, 23 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/mm/init_64.c
===
--- linux-2.6.orig/arch/x86/mm/init_64.c
+++ linux-2.6/arch/x86/mm/init_64.c
@@ -375,6 +375,7 @@ void __init init_extra_mapping_uc(unsign
__init_extra_mapping(phys, size, PAGE_KERNEL_LARGE_NOCACHE);
}
+static pmd_t *last_pmd;
/*
* The head.S code sets up the kernel high mapping:
*
@@ -408,9 +409,26 @@ void __init cleanup_highmap(void)
continue;
if (vaddr < (unsigned long) _text || vaddr > end)
set_pmd(pmd, __pmd(0));
+else
+last_pmd = pmd;
}
}
+static void __init cleanup_highmap_tail(unsigned long addr)
+{
+int i;
+pte_t *pte;
+
+if (!last_pmd || pmd_none(*last_pmd))
+return;
+
+pte = (pte_t *)pmd_page_vaddr(*last_pmd);
+pte += pte_index(addr);
+
+for (i = pte_index(addr); i < PTRS_PER_PTE; i++, pte++)
+set_pte(pte, __pte(0));
+}
+
static unsigned long __meminit
phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned long end,
pgprot_t prot)
@@ -1124,7 +1142,8 @@ void mark_rodata_ro(void)
unsigned long end = (unsigned long) &__end_rodata_hpage_align;
unsigned long text_end = PFN_ALIGN(&__stop___ex_table);
unsigned long rodata_end = PFN_ALIGN(&__end_rodata);
-unsigned long all_end = PFN_ALIGN(&_end);
+unsigned long all_end = PFN_ALIGN(_brk_end);
+unsigned long pmd_end = roundup(all_end, PMD_SIZE);
printk(KERN_INFO "Write protecting the kernel read-only data: %luk\n",
(end - start) >> 10);
@@ -1137,6 +1156,8 @@ void mark_rodata_ro(void)
* should also be not-executable.
*/
set_memory_nx(
Re: [PATCH v10 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel wrote: > > > On 14/11/14 11:08, Andy Yan wrote: >> >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote: >>> >>> On 14/11/14 10:53, Andy Yan wrote: Hi ZubairLK: Thanks for your review. On 2014年11月14日 18:19, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > Nice work on this patch series. Its getting better and better :). > > On 14/11/14 03:27, Andy Yan wrote: >> hdmi phy clock symbol and transmission termination value >> can adjust platform specific to get the best SI > ^Is this signal integrity? yes , SI is signal integrity, such as eye diagram measurement > Are these two disjoint features in separate patches? > >> also add mode_valid interface for some platform may not support >> all the display mode > Sounds like another separate patch to me. :) they can seperate > Also, This series is becoming quite large. With major changes and fixes > mixed together. > > Patch 3 splits imx-drm. > Patch 4 moves dw-drm out of imx-drm folder. > Patch 7 adds binding > Patch 9 converts to drm bridge. > > Can these be placed together easily? > And in the start. i.e. patch 1, 2, 3, 4, > > Then all fixes etc can come afterwards? > > It helps when checking histories later as to how a driver was made and > how fixes happened. > > Especially when file moves happen.. Do you mean we can rearrange the patch series? put patch 3, 4 ,7, 9 together one bye one than followed by the fixes patches 5 ,6, 8, 11 ? >>> Yes. Rearrange so that the split imx-drm/imx-hdmi and conversion to >>> drm-bridge is at the start of the series. >>> Then the rest are bug fixes and feature additions. >> Can I put patch#1(make checkpatch happy) and patch#2 (defer probe) as the >> first two patch. >> Daniel from Google chromium think it's better to put the two slightly >> changes in the front for easy review. Sorry, I didn't see this conversation before my earlier emails. I was suggesting to Andy to arrange his patches like this: (1) fixes that directly apply to imx-drm as it is today. (2) split out the "generic dw_hdmi" parts from imx-hdmi into dw_hdmi.c (3) convert dw_hdmi.c to a drm_bridge (4) move the dw_hdmi.c bridge implementation to drm/bridge (5) modifications to dw_hdmi.c required to support hdmi on rk3288 (5) add rk3288-hdmi.c to drm/rockchip (at least whenever drm/rockchip lands) The idea being that we can start landing the patches for (1) even while we are still debating / reviewing (2)+ upstream. > Sure. > > I am not the maintainer. They have to make the final decision. imx-drm is still in staging. I do not see anyone listed explicitly under MAINTAINERS for drivers/staging/imx-drm, so by default I guess it falls back to gregkh (drivers/staging/)? The "Commit" field in git log seems to back this up. Although, based on Author, I think we also want the opinions of Philipp Zabel and Russel King. Thanks, -djk > > ZubairLK -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Sat, Nov 15, 2014 at 06:07:50PM +0800, Daniel Kurtz wrote: > On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel > wrote: > > > > > > On 14/11/14 11:08, Andy Yan wrote: > >> > >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote: > >>> > >>> On 14/11/14 10:53, Andy Yan wrote: > Hi ZubairLK: > Thanks for your review. > On 2014年11月14日 18:19, Zubair Lutfullah Kakakhel wrote: > > Hi Andy, > > > > Nice work on this patch series. Its getting better and better :). > > > > On 14/11/14 03:27, Andy Yan wrote: > >> hdmi phy clock symbol and transmission termination value > >> can adjust platform specific to get the best SI > > ^Is this signal integrity? > yes , SI is signal integrity, such as eye diagram measurement > > Are these two disjoint features in separate patches? > > > >> also add mode_valid interface for some platform may not support > >> all the display mode > > Sounds like another separate patch to me. :) > they can seperate > > Also, This series is becoming quite large. With major changes and fixes > > mixed together. > > > > Patch 3 splits imx-drm. > > Patch 4 moves dw-drm out of imx-drm folder. > > Patch 7 adds binding > > Patch 9 converts to drm bridge. > > > > Can these be placed together easily? > > And in the start. i.e. patch 1, 2, 3, 4, > > > > Then all fixes etc can come afterwards? > > > > It helps when checking histories later as to how a driver was made and > > how fixes happened. > > > > Especially when file moves happen.. > Do you mean we can rearrange the patch series? > put patch 3, 4 ,7, 9 together one bye one > than followed by the fixes patches 5 ,6, 8, 11 ? > >>> Yes. Rearrange so that the split imx-drm/imx-hdmi and conversion to > >>> drm-bridge is at the start of the series. > >>> Then the rest are bug fixes and feature additions. > >> Can I put patch#1(make checkpatch happy) and patch#2 (defer probe) as > >> the first two patch. > >> Daniel from Google chromium think it's better to put the two slightly > >> changes in the front for easy review. > > Sorry, I didn't see this conversation before my earlier emails. > > I was suggesting to Andy to arrange his patches like this: > (1) fixes that directly apply to imx-drm as it is today. > (2) split out the "generic dw_hdmi" parts from imx-hdmi into dw_hdmi.c > (3) convert dw_hdmi.c to a drm_bridge > (4) move the dw_hdmi.c bridge implementation to drm/bridge > (5) modifications to dw_hdmi.c required to support hdmi on rk3288 > (5) add rk3288-hdmi.c to drm/rockchip (at least whenever drm/rockchip lands) > > The idea being that we can start landing the patches for (1) even > while we are still debating / reviewing (2)+ upstream. > > > Sure. > > > > I am not the maintainer. They have to make the final decision. > > imx-drm is still in staging. I do not see anyone listed explicitly > under MAINTAINERS for drivers/staging/imx-drm, so by default I guess > it falls back to gregkh (drivers/staging/)? > The "Commit" field in git log seems to back this up. > > Although, based on Author, I think we also want the opinions of > Philipp Zabel and Russel King. Once the wranglings on the patch series are complete, I do intend to test it on the platforms I have - and remember that I do have the ALSA based audio and CEC bits as well, some of which will probably need a little bit of re-work. All in all, I welcome the renaming of this to include a reference to DesignWare - I've always thought it's a mistake that the HDMI interface in iMX6 was not named with a "dw" prefix as the docs contain references to it being a DesignWare IP module. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[x86, mm] BUG: Bad page state in process swapper/0 pfn:020c0
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git x86/pmd-nx commit 3622dcc2b4f4eaf23bae2511a30fc449d0e5f0d9 Author: Kees Cook AuthorDate: Fri Nov 14 11:36:17 2014 -0800 Commit: Kees Cook CommitDate: Fri Nov 14 13:36:37 2014 -0800 x86, mm: set NX across entire PMD at boot When setting up permissions on kernel memory at boot, the end of the PMD that was split from bss remained executable. It should be NX like the rest. This performs a PMD alignment instead of a PAGE alignment to get the correct span of memory, and should be freed. Before: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW GLB x pte 0x82e0-0xc000 978M pmd After: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW NX pte 0x82e0-0xc000 978M pmd Signed-off-by: Kees Cook +--++++ | | b23dc5a7cc | 3622dcc2b4 | 192495a3a4 | +--++++ | boot_successes | 64 | 0 | 0 | | boot_failures| 1 | 20 | 14 | | BUG:kernel_boot_hang | 1 || | | BUG:Bad_page_state_in_process| 0 | 20 | 14 | | BUG:Bad_page_map_in_process | 0 | 15 | 10 | | backtrace:free_reserved_area | 0 | 20 | 14 | | backtrace:free_init_pages| 0 | 20 | 14 | | backtrace:mark_rodata_ro | 0 | 20 | 14 | | backtrace:do_execve_common | 0 | 3 | 2 | | backtrace:SyS_execve | 0 | 3 | 2 | | backtrace:do_group_exit | 0 | 13 | 7 | | backtrace:SyS_exit_group | 0 | 13 | 7 | | general_protection_fault | 0 | 7 | 6 | | RIP:release_pages| 0 | 5 | 5 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 10 | 5 | | backtrace:vfs_read | 0 | 4 | 3 | | backtrace:SyS_read | 0 | 4 | 3 | | BUG:unable_to_handle_kernel | 0 | 3 | | | Oops | 0 | 3 | | | RIP:__delete_from_page_cache | 0 | 2 | | | backtrace:SYSC_renameat2 | 0 | 2 | | | backtrace:SyS_rename | 0 | 2 | | | RIP:__page_cache_release | 0 | 2 | | | RIP:free_pcppages_bulk | 0 | 1 | | | backtrace:vfs_write | 0 | 0 | 1 | | backtrace:SyS_write | 0 | 0 | 1 | +--++++ [2.615868] #3: Internal PC-Speaker at port 0x61 [2.617590] Freeing unused kernel memory: 924K (81f15000 - 81ffc000) [2.619355] Write protecting the kernel read-only data: 14336k [2.621361] BUG: Bad page state in process swapper/0 pfn:020c0 [2.622959] page:880012f69000 count:0 mapcount:-127 mapping: (null) index:0x2 [2.624982] flags: 0x800() [2.626452] page dumped because: nonzero mapcount [2.627529] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc4-g3622dcc2 #1477 [2.629672] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [2.630904] 81caf350 88001289fd78 819360c5 [2.633079] 880012f69000 88001289fda8 8113046b 0001 [2.635141] 880012f69000 880012f69040 88001289fdf8 [2.637254] Call Trace: [
[x86, mm] kernel BUG at include/linux/mm.h:548!
Hi Kees, Here is another bisect result. git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git x86/pmd-nx commit 3622dcc2b4f4eaf23bae2511a30fc449d0e5f0d9 Author: Kees Cook AuthorDate: Fri Nov 14 11:36:17 2014 -0800 Commit: Kees Cook CommitDate: Fri Nov 14 13:36:37 2014 -0800 x86, mm: set NX across entire PMD at boot When setting up permissions on kernel memory at boot, the end of the PMD that was split from bss remained executable. It should be NX like the rest. This performs a PMD alignment instead of a PAGE alignment to get the correct span of memory, and should be freed. Before: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW GLB x pte 0x82e0-0xc000 978M pmd After: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW NX pte 0x82e0-0xc000 978M pmd Signed-off-by: Kees Cook +--++++ | | b23dc5a7cc | 3622dcc2b4 | 3622dcc2b4 | +--++++ | boot_successes | 102| 3 | 3 | | boot_failures| 1 | 182| 182 | | BUG:kernel_boot_hang | 1 || | | kernel_BUG_at_include/linux/mm.h | 0 | 182| 182 | | invalid_opcode | 0 | 182| 182 | | RIP:__rmqueue| 0 | 182| 182 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 182| 182 | | backtrace:iterate_dir| 0 | 1 | 1 | | backtrace:SyS_getdents | 0 | 1 | 1 | +--++++ [2.033203] flags: 0x8080068(uptodate|lru|active|swapbacked) [2.033347] page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_mapcount) != -1) [2.033347] [ cut here ] [2.033347] kernel BUG at include/linux/mm.h:548! [2.033347] invalid opcode: [#1] SMP [2.033347] Modules linked in: [2.033347] CPU: 0 PID: 284 Comm: udevd Not tainted 3.18.0-rc4-g3622dcc2 #1438 [2.033347] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [2.033347] task: 881022e0 ti: 880010bbc000 task.ti: 880010bbc000 [2.033347] RIP: 0010:[] [] __rmqueue+0x230/0x770 [2.033347] RSP: :880010bbf978 EFLAGS: 00010046 [2.033347] RAX: 0006 RBX: 880012fb4000 RCX: 0003 [2.033347] RDX: RSI: RDI: 0046 [2.033347] RBP: 880010bbf9f8 R08: 0001 R09: [2.033347] R10: 81b1f800 R11: 81b1f8c0 R12: 820d4d80 [2.033347] R13: 880012fb5000 R14: 0020 R15: 880012fb4020 [2.033347] FS: 7f5c34ad4700() GS:880013a0() knlGS: [2.033347] CS: 0010 DS: ES: CR0: 80050033 [2.033347] CR2: 01b80b40 CR3: 10bae000 CR4: 000406b0 [2.033347] Stack: [2.033347] 880010bbf9d8 0096 0096 820d5078 [2.033347] 0006 0101 0001 0002 [2.033347] 0040 0002 820d6280 880013bd6ec8 [2.033347] Call Trace: [2.033347] [] get_page_from_freelist+0x34f/0xbde [2.033347] [] ? pvclock_clocksource_read+0x12c/0x140 [2.033347] [] __alloc_pages_nodemask+0x2c3/0x1095 [2.033347] [] ? sched_clock_cpu+0x14d/0x16a [2.033347] [] do_wp_page+0x94b/0x101e [2.033347] [] handle_pte_fault+0x7c6/0x833 [2.033347] [] handle_mm_fault+0x4a0/0x4d2 [2.033347] [] __do_page_fault+0x867/0xace [2.033347] [] ? rcu_eqs_enter_common+0x362/0x371 [2.033347] [] ? rcu_eqs_exit_common+0xf1/0x326 [2.033347] [] ? rcu_eqs_enter+0x124/0x138 [2.033347] [] ? rcu_eqs_exit+0x12a/0x139 [2.033347] [] trace_do_page_fault+0x1f3/0x25f [2.033347] [] do_async_page_fault+0x3a/0x131 [2.033347] [] async_page_fault+0x28/0x30
[x86, mm] WARNING: CPU: 0 PID: 1 at arch/x86/mm/pageattr.c:1086 __cpa_process_fault()
Hi Kees, FYI, one more warning message and call trace. git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git x86/pmd-nx commit 3622dcc2b4f4eaf23bae2511a30fc449d0e5f0d9 Author: Kees Cook AuthorDate: Fri Nov 14 11:36:17 2014 -0800 Commit: Kees Cook CommitDate: Fri Nov 14 13:36:37 2014 -0800 x86, mm: set NX across entire PMD at boot When setting up permissions on kernel memory at boot, the end of the PMD that was split from bss remained executable. It should be NX like the rest. This performs a PMD alignment instead of a PAGE alignment to get the correct span of memory, and should be freed. Before: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW GLB x pte 0x82e0-0xc000 978M pmd After: ---[ High Kernel Mapping ]--- ... 0x8202d000-0x8220 1868K RW GLB NX pte 0x8220-0x82c010M RW PSE GLB NX pmd 0x82c0-0x82df5000 2004K RW GLB NX pte 0x82df5000-0x82e044K RW NX pte 0x82e0-0xc000 978M pmd Signed-off-by: Kees Cook +-++++ | | b23dc5a7cc | 3622dcc2b4 | 082b92dbde | +-++++ | boot_successes | 60 | 0 | 0 | | boot_failures | 0 | 20 | 12 | | WARNING:at_arch/x86/mm/pageattr.c:__cpa_process_fault() | 0 | 20 | 12 | | backtrace:set_memory_np | 0 | 20 | 12 | | backtrace:free_init_pages | 0 | 20 | 12 | | backtrace:mark_rodata_ro| 0 | 20 | 12 | | Kernel_panic-not_syncing:No_working_init_found | 0 | 0 | 12 | | backtrace:panic | 0 | 0 | 12 | +-++++ [ 16.701884] Write protecting the kernel read-only data: 16384k [ 16.703198] debug: unmapping init [mem 0x8385d000-0x839f] [ 16.703893] [ cut here ] [ 16.704426] WARNING: CPU: 0 PID: 1 at arch/x86/mm/pageattr.c:1086 __cpa_process_fault+0x2be/0x2e3() [ 16.705450] CPA: called for zero pte. vaddr = 8385d000 cpa->vaddr = 8385d000 [ 16.706259] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc4-g3622dcc2 #13 [ 16.706965] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 16.707528] 0009 8818bbc8 819252f3 8818bc18 [ 16.708301] 0009 8818bc08 8108806b 8818bc28 [ 16.709121] 810358fe 8818bdf8 8385d000 [ 16.709898] Call Trace: [ 16.710157] [] dump_stack+0x51/0xaa [ 16.710659] [] warn_slowpath_common+0x7c/0x96 [ 16.711231] [] ? __cpa_process_fault+0x2be/0x2e3 [ 16.711831] [] warn_slowpath_fmt+0x46/0x48 [ 16.712398] [] __cpa_process_fault+0x2be/0x2e3 [ 16.713001] [] ? lookup_address_in_pgd+0x6e/0xd9 [ 16.713608] [] __change_page_attr_set_clr+0xe0/0x73e [ 16.714264] [] ? vm_unmap_aliases+0x169/0x178 [ 16.714852] [] change_page_attr_set_clr+0x1e1/0x428 [ 16.715476] [] change_page_attr_clear+0x21/0x23 [ 16.716109] [] set_memory_np+0x21/0x23 [ 16.716620] [] free_init_pages+0xbb/0xca [ 16.717157] [] mark_rodata_ro+0xb1/0x125 [ 16.717698] [] ? rest_init+0xc1/0xc1 [ 16.718202] [] kernel_init+0x1d/0xda [ 16.718717] [] ret_from_fork+0x7c/0xb0 [ 16.719234] [] ? rest_init+0xc1/0xc1 [ 16.719820] ---[ end trace 98571e0ac619c2b1 ]--- [ 16.720325] debug: unmapping init [mem 0x880001939000-0x8800019f] git bisect start 082b92dbdee2006706aff377ae38d6ceacea91c5 206c5f60a3d902bc4b56dab2de3e88de5eb06108 -- git bisect bad 156311ecaa588b59a508951a62431e24786e284e # 12:57 0- 1 Merge 'kees/nak/fw-relative' into devel-snb-smoke-201411151150 git bisect good cbb20c815bbd7b0c37f68ac038ebda2ffe0072d3 # 13:13 20+ 0 Merge 'linuxtv-media/master' into devel-snb-smoke-201411151150 git bisect good 00276f48b04f0d099b954197e86f9535d915cf28 # 13:42 20+ 0 Merge 'kees/yama/extras' in
Re: SOLO6x10: fix a race in IRQ handler.
Hi Andrey,
Please always prefix the subject line with [PATCH] when you post a patch. That
way it
will be picked up by patchwork
(https://patchwork.linuxtv.org/project/linux-media/list/)
and the patch won't be lost.
Can you repost with such a prefix?
Thanks!
Hans
On 11/15/2014 11:34 AM, Andrey Utkin wrote:
> From: khal...@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
>
> The IRQs have to be acknowledged before they are serviced, otherwise some
> events
> may be skipped. Also, acknowledging IRQs just before returning from the
> handler
> doesn't leave enough time for the device to deassert the INTx line, and for
> bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
> dual core CPU.
>
> Signed-off-by: Krzysztof Hałasa
> Acked-by: Andrey Utkin
> Tested-by: Andrey Utkin
>
> --- a/drivers/media/pci/solo6x10/solo6x10-core.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-core.c
> @@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data)
> if (!status)
> return IRQ_NONE;
>
> - if (status & ~solo_dev->irq_mask) {
> - solo_reg_write(solo_dev, SOLO_IRQ_STAT,
> -status & ~solo_dev->irq_mask);
> - status &= solo_dev->irq_mask;
> - }
> + /* Acknowledge all interrupts immediately */
> + solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
>
> if (status & SOLO_IRQ_PCI_ERR)
> solo_p2m_error_isr(solo_dev);
> @@ -132,9 +129,6 @@ static irqreturn_t solo_isr(int irq, void *data)
> if (status & SOLO_IRQ_G723)
> solo_g723_isr(solo_dev);
>
> - /* Clear all interrupts handled */
> - solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
> -
> return IRQ_HANDLED;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI/MSI: Allow an msi_chip to be associated to an irq domain
With the new stacked irq domains, it becomes pretty tempting
to allocate an MSI domain per PCI bus, which would remove
the requirement of either relying on arch-specific code, or
a default PCI MSI domain.
By allowing the msi_chip structure to carry a pointer to
an irq_domain, we can easily use this in pci_msi_setup_msi_irqs.
The existing code can still be used as a fallback if the MSI driver
does not populate the domain field.
Tested on arm64 with the GICv3 ITS driver.
Signed-off-by: Marc Zyngier
---
drivers/pci/msi.c | 16 +++-
include/linux/msi.h | 3 +++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index af66b95..aa3b720 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -84,11 +84,25 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
return 0;
}
+static struct irq_domain *pci_msi_get_domain(struct pci_dev *dev)
+{
+ struct irq_domain *domain = NULL;
+
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+ if (dev->bus->msi)
+ domain = dev->bus->msi->domain;
+#endif
+ if (!domain)
+ domain = arch_get_pci_msi_domain(dev);
+
+ return domain;
+}
+
static int pci_msi_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct irq_domain *domain;
- domain = arch_get_pci_msi_domain(dev);
+ domain = pci_msi_get_domain(dev);
if (domain)
return pci_msi_domain_alloc_irqs(domain, type, dev);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 8b4a69b..a8d309a 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -89,6 +89,9 @@ struct msi_chip {
struct device *dev;
struct device_node *of_node;
struct list_head list;
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+ struct irq_domain *domain;
+#endif
int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
struct msi_desc *desc);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Stacked domains and MSI improvements
This short series builds upon Jiang Liu's MSI stacked domain and tries to clean up a couple of points: - Patch 1 allows an msi_chip to carry a pointer to its irq domain. When populated by the MSI driver, this allow the PCI bus to be associated with an irq domain, removing most of the need for arch specific code in the case of multiple PCI busses. - Patch 2 tries to work around a limitation of __irq_set_handler when called with an interrupt belongging to a stacked domain. This has been tested on arm64, together with the GICv3 ITS. Marc Zyngier (2): PCI/MSI: Allow an msi_chip to be associated to an irq domain genirq: Work around __irq_set_handler vs stacked domains ordering issues drivers/pci/msi.c | 16 +++- include/linux/msi.h | 3 +++ kernel/irq/chip.c | 11 ++- 3 files changed, 28 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] genirq: Work around __irq_set_handler vs stacked domains ordering issues
With the introduction of stacked domains, we have the issue that,
depending on where in the stack this is called, __irq_set_handler
will succeed or fail: If this is called from the inner irqchip,
__irq_set_handler() will fail, as it will look at the outer domain
as the (desc->irq_data.chip == &no_irq_chip) test fails (we haven't
set the top level yet).
This patch implements the following: "If there is at least one
valid irqchip in the domain, it will probably sort itself out".
This is clearly not ideal, but it is far less confusing then
crashing because the top-level domain is not up yet.
Signed-off-by: Marc Zyngier
---
kernel/irq/chip.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index d028b34..cad4f62 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -731,7 +731,16 @@ __irq_set_handler(unsigned int irq, irq_flow_handler_t
handle, int is_chained,
if (!handle) {
handle = handle_bad_irq;
} else {
- if (WARN_ON(desc->irq_data.chip == &no_irq_chip))
+ struct irq_data *irq_data = &desc->irq_data;
+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+ while (irq_data) {
+ if (irq_data->chip != &no_irq_chip)
+ break;
+ irq_data = irq_data->parent_data;
+ }
+#endif
+
+ if (WARN_ON(!irq_data || irq_data->chip == &no_irq_chip))
goto out;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] solo6x10: fix a race in IRQ handler
From: Krzysztof Hałasa
The IRQs have to be acknowledged before they are serviced, otherwise some events
may be skipped. Also, acknowledging IRQs just before returning from the handler
doesn't leave enough time for the device to deassert the INTx line, and for
bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
dual core CPU.
Signed-off-by: Krzysztof Hałasa
Acked-by: Andrey Utkin
Tested-by: Andrey Utkin
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data)
if (!status)
return IRQ_NONE;
- if (status & ~solo_dev->irq_mask) {
- solo_reg_write(solo_dev, SOLO_IRQ_STAT,
- status & ~solo_dev->irq_mask);
- status &= solo_dev->irq_mask;
- }
+ /* Acknowledge all interrupts immediately */
+ solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
if (status & SOLO_IRQ_PCI_ERR)
solo_p2m_error_isr(solo_dev);
@@ -132,9 +129,6 @@ static irqreturn_t solo_isr(int irq, void *data)
if (status & SOLO_IRQ_G723)
solo_g723_isr(solo_dev);
- /* Clear all interrupts handled */
- solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
-
return IRQ_HANDLED;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/11] drm: bridge/dw_hdmi:split some phy configuration to platform driver
On Sat, Nov 15, 2014 at 10:12:18AM +, Russell King - ARM Linux wrote: > Once the wranglings on the patch series are complete, I do intend to test > it on the platforms I have - and remember that I do have the ALSA based > audio and CEC bits as well, some of which will probably need a little bit > of re-work. > > All in all, I welcome the renaming of this to include a reference to > DesignWare - I've always thought it's a mistake that the HDMI interface > in iMX6 was not named with a "dw" prefix as the docs contain references > to it being a DesignWare IP module. One thing I would ask is that the subsequent submissions do not thread onto the previous submission. It may seem a good idea (people claim that it allows the previous reviews to be trivially found) but these people forget an important side effect from this behaviour - when looking at the message index in a threaded mail reader (like mutt), each reply to a thread moves the subject line by three characters to the right. What this means is that after about five or six iterations of the submission, there is no longer any subject line visible. Moreover, it means that with lesser iterations, it becomes much more difficult to see /any/ of the review thread structure. I would suggest that if you do want to "connect" the subsequent submissions, please use the same reference message for each submission. In other words, rather than: v1 0/2 +-> v1 1/2 +-> v1 2/2 +-> v2 0/2 +-> v2 1/2 +-> v2 2/2 +-> v3 0/2 +-> v3 1/2 +-> v3 2/2 ... This is done instead: v1 0/2 +-> v1 1/2 +-> v1 2/2 +-> v2 0/2 | +-> v2 1/2 | +-> v2 2/2 +-> v3 0/2 | +-> v3 1/2 | +-> v3 2/2 ... which is a compromise between threading the messages together, and keeping stopping the thread pushing the subject line completely off the right hand side of the screen. In this case, I'd suggest a reference of: 1415793593-5075-1-git-send-email-andy@rock-chips.com which is the v8 covering message which started this big thread. Thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] dmaengine: Add driver for IMG MDC
On Friday 14 November 2014 13:59:43 Andrew Bresticker wrote: > Add support for the IMG Multi-threaded DMA Controller (MDC) found on > certain IMG SoCs. Currently this driver supports the variant present > on the MIPS-based Pistachio SoC. > > Signed-off-by: Andrew Bresticker > Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] dmaengine: Add binding document for IMG MDC
On Friday 14 November 2014 13:59:42 Andrew Bresticker wrote: > Add a binding document for the IMG Multi-threaded DMA Controller (MDC) > present on the MIPS-based Pistachio and other IMG SoCs. > > Signed-off-by: Andrew Bresticker > Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] genirq: Add IRQ 0 to domain debug file
Currently irq_domain_mapping debugfs file dumps IRQ information starting
from IRQ 1. IRQ 0 is missing from that file. Add it to have the complete
picture of IRQ/domains mappings.
Signed-off-by: Dmitry Eremin-Solenikov
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 6534ff6..0e0c7a8 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -585,7 +585,7 @@ static int virq_debug_show(struct seq_file *m, void
*private)
"chip name", (int)(2 * sizeof(void *) + 2), "chip data",
"active", "type", "domain");
- for (i = 1; i < nr_irqs; i++) {
+ for (i = 0; i < nr_irqs; i++) {
desc = irq_to_desc(i);
if (!desc)
continue;
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/4] ARM: rockchip: add suspend and resume for RK3288
It's a basic version of suspend and resume for rockchip,
it only support RK3288 now.
Signed-off-by: Tony Xie
Signed-off-by: Chris Zhong
Tested-by: Doug Anderson
Reviewed-by: Doug Anderson
---
Changes in v8:
- use enum for define sleep mode
- move rk3288_config_bootdata to the front of sram memcpy
Changes in v7:
- get rid all of unused code
Changes in v6:
- get rid of the save/restore of SRAM
- doing the copy of resume code once at init time
- remove ROCKCHIP_ARM_OFF_LOGIC_DEEP from rk3288_fill_in_bootram
- add of_platform_populate in rockchip_dt_init
Changes in v5:
- use rk3288_bootram_sz for memcpy size
- fixed error of sram save and restore
Changes in v4:
- remove grf regmap
Changes in v3:
- move the pinmux of gpio6_c6 save and restore to pinctrl-rockchip
Changes in v2:
- add the regulator calls in prepare and finish.
- add the pinmux of gpio6_c6 save and restore
arch/arm/mach-rockchip/Makefile | 1 +
arch/arm/mach-rockchip/pm.c | 264 ++
arch/arm/mach-rockchip/pm.h | 99 ++
arch/arm/mach-rockchip/rockchip.c | 2 +
arch/arm/mach-rockchip/sleep.S| 73 +++
5 files changed, 439 insertions(+)
create mode 100644 arch/arm/mach-rockchip/pm.c
create mode 100644 arch/arm/mach-rockchip/pm.h
create mode 100644 arch/arm/mach-rockchip/sleep.S
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index b29d8ea..5c3a9b2 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1,4 +1,5 @@
CFLAGS_platsmp.o := -march=armv7-a
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/pm.c b/arch/arm/mach-rockchip/pm.c
new file mode 100644
index 000..e059b84
--- /dev/null
+++ b/arch/arm/mach-rockchip/pm.c
@@ -0,0 +1,264 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Tony Xie
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 "pm.h"
+
+/* These enum are option of low power mode */
+enum {
+ ROCKCHIP_ARM_OFF_LOGIC_NORMAL = 0,
+ ROCKCHIP_ARM_OFF_LOGIC_DEEP = 1,
+};
+
+struct rockchip_pm_device_id {
+ const char *compatible;
+ const struct platform_suspend_ops *ops;
+ int (*init)(void);
+};
+
+static void __iomem *rk3288_bootram_base;
+static phys_addr_t rk3288_bootram_phy;
+
+static struct regmap *pmu_regmap;
+static struct regmap *sgrf_regmap;
+
+static u32 rk3288_pmu_pwr_mode_con;
+static u32 rk3288_sgrf_soc_con0;
+
+static inline u32 rk3288_l2_config(void)
+{
+ u32 l2ctlr;
+
+ asm("mrc p15, 1, %0, c9, c0, 2" : "=r" (l2ctlr));
+ return l2ctlr;
+}
+
+static void rk3288_config_bootdata(void)
+{
+ rkpm_bootdata_cpusp = rk3288_bootram_phy + (SZ_4K - 8);
+ rkpm_bootdata_cpu_code = virt_to_phys(cpu_resume);
+
+ rkpm_bootdata_l2ctlr_f = 1;
+ rkpm_bootdata_l2ctlr = rk3288_l2_config();
+}
+
+static void rk3288_slp_mode_set(int level)
+{
+ u32 mode_set, mode_set1;
+
+ regmap_read(sgrf_regmap, RK3288_SGRF_SOC_CON0, &rk3288_sgrf_soc_con0);
+
+ regmap_read(pmu_regmap, RK3288_PMU_PWRMODE_CON,
+ &rk3288_pmu_pwr_mode_con);
+
+ /* set bit 8 so that system will resume to FAST_BOOT_ADDR */
+ regmap_write(sgrf_regmap, RK3288_SGRF_SOC_CON0,
+SGRF_FAST_BOOT_EN | SGRF_FAST_BOOT_EN_WRITE);
+
+ /* booting address of resuming system is from this register value */
+ regmap_write(sgrf_regmap, RK3288_SGRF_FAST_BOOT_ADDR,
+rk3288_bootram_phy);
+
+ regmap_write(pmu_regmap, RK3288_PMU_WAKEUP_CFG1,
+PMU_ARMINT_WAKEUP_EN);
+
+ mode_set = BIT(PMU_GLOBAL_INT_DISABLE) | BIT(PMU_L2FLUSH_EN) |
+ BIT(PMU_SREF0_ENTER_EN) | BIT(PMU_SREF1_ENTER_EN) |
+ BIT(PMU_DDR0_GATING_EN) | BIT(PMU_DDR1_GATING_EN) |
+ BIT(PMU_PWR_MODE_EN) | BIT(PMU_CHIP_PD_EN) |
+ BIT(PMU_SCU_EN);
+
+ mode_set1 = BIT(PMU_CLR_CORE) | BIT(PMU_CLR_CPUP);
+
+ if (level == ROCKCHIP_ARM_OFF_LOGIC_DEEP) {
+ /* arm off, logic deep sleep */
+ mode_set |= BIT(PMU_BUS_PD_EN) |
+ BIT(PMU_DDR1IO_RET_EN) | BIT(PMU_DDR0IO_RET_EN) |
+ BIT(PMU_OSC_24M_DIS) | BIT(PMU_PMU_USE_LF) |
+ B
[PATCH v8 0/4] This is the 1st version of suspend for RK3288.
This suspend patch is only support cut off the power of cpu and some external devices, since we still lack power_domain driver, so the other power rail of rk3288 need keep power on. I have tested it on rk3288-evb board, atop next-20141112. goto suspend by type "echo mem > /sys/power/state", vdd_cpu is about 0mv by measuring, so it can be determined in sleep mode, then press power button to wakeup it. Based on: [v5,1/6] ARM: rockchip: convert to regmap and use pmu syscon if available https://patchwork.kernel.org/patch/5086341/ [v5,2/6] ARM: rockchip: add option to access the pmu via a phandle in smp_operations https://patchwork.kernel.org/patch/5086441/ [v5,3/6] ARM: dts: rockchip: add pmu references to cpus nodes https://patchwork.kernel.org/patch/5086351/ [v5,4/6] ARM: rockchip: add basic smp support for rk3288 https://patchwork.kernel.org/patch/5086371/ [v5,5/6] ARM: dts: rockchip: add intmem node for rk3288 smp support https://patchwork.kernel.org/patch/5086361/ [v5,6/6] ARM: dts: rockchip: add reset for CPU nodes https://patchwork.kernel.org/patch/5086381/ [v3] usb: dwc2: add bus suspend/resume for dwc2 https://patchwork.kernel.org/patch/5266281/ Changes in v8: - use enum for define sleep mode - move rk3288_config_bootdata to the front of sram memcpy - add ddr pinctrl for suspend - keep all except cpu&tp power rail on during suspend - add regulator-on-in-suspend before set suspend voltage - add a reference of ddrio_pwroff and ddr0_retention Changes in v7: - get rid all of unused code - add regulator-state-mem sub node for suspend Changes in v6: - get rid of the save/restore of SRAM - doing the copy of resume code once at init time - remove ROCKCHIP_ARM_OFF_LOGIC_DEEP from rk3288_fill_in_bootram - add of_platform_populate in rockchip_dt_init - change pmu_intmem@ff72 to sram@ff72 - change pmu_intmem@ff72 to sram@ff72 Changes in v5: - use rk3288_bootram_sz for memcpy size - fixed error of sram save and restore - change the size of sram in example - change size to 4k Changes in v4: - remove grf regmap Changes in v3: - move the pinmux of gpio6_c6 save and restore to pinctrl-rockchip Changes in v2: - add the regulator calls in prepare and finish. - add the pinmux of gpio6_c6 save and restore - put "rockchip,rk3288-pmu-sram" to first Chris Zhong (4): ARM: rockchip: add suspend and resume for RK3288 ARM: rockchip: Add pmu-sram binding ARM: dts: add RK3288 suspend support ARM: dts: add suspend voltage setting for RK808 .../devicetree/bindings/arm/rockchip/pmu-sram.txt | 16 ++ arch/arm/boot/dts/rk3288-evb-rk808.dts | 55 - arch/arm/boot/dts/rk3288-evb.dtsi | 12 + arch/arm/boot/dts/rk3288.dtsi | 23 ++ arch/arm/mach-rockchip/Makefile| 1 + arch/arm/mach-rockchip/pm.c| 264 + arch/arm/mach-rockchip/pm.h| 99 arch/arm/mach-rockchip/rockchip.c | 2 + arch/arm/mach-rockchip/sleep.S | 73 ++ 9 files changed, 544 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt create mode 100644 arch/arm/mach-rockchip/pm.c create mode 100644 arch/arm/mach-rockchip/pm.h create mode 100644 arch/arm/mach-rockchip/sleep.S -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 4/4] ARM: dts: add suspend voltage setting for RK808
global_pwroff would be pull to high when RK3288 entering suspend,
this pin is a sleep signal for RK808, so RK808 could goto sleep
mode, and some regulators would be disable.
Signed-off-by: Chris Zhong
---
Changes in v8:
- keep all except cpu&tp power rail on during suspend
- add regulator-on-in-suspend before set suspend voltage
- add a reference of ddrio_pwroff and ddr0_retention
Changes in v7:
- add regulator-state-mem sub node for suspend
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/rk3288-evb-rk808.dts | 55 +-
arch/arm/boot/dts/rk3288-evb.dtsi | 12
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index d8c775e6..e4a8884 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -31,7 +31,7 @@
interrupt-parent = <&gpio0>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <&pmic_int>;
+ pinctrl-0 = <&pmic_int &global_pwroff>;
rockchip,system-power-controller;
wakeup-source;
#clock-cells = <1>;
@@ -50,6 +50,9 @@
regulator-min-microvolt = <75>;
regulator-max-microvolt = <135>;
regulator-name = "vdd_arm";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
vdd_gpu: DCDC_REG2 {
@@ -58,12 +61,20 @@
regulator-min-microvolt = <85>;
regulator-max-microvolt = <125>;
regulator-name = "vdd_gpu";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <100>;
+ };
};
vcc_ddr: DCDC_REG3 {
regulator-always-on;
regulator-boot-on;
regulator-name = "vcc_ddr";
+ regulator-suspend-mem-enabled;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
vcc_io: DCDC_REG4 {
@@ -72,6 +83,10 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc_io";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <330>;
+ };
};
vccio_pmu: LDO_REG1 {
@@ -80,6 +95,10 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vccio_pmu";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <330>;
+ };
};
vcc_tp: LDO_REG2 {
@@ -88,6 +107,9 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc_tp";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
vdd_10: LDO_REG3 {
@@ -96,6 +118,10 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-name = "vdd_10";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <100>;
+ };
};
vcc18_lcd: LDO_REG4 {
@@ -104,6 +130,10 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-name = "vcc18_lcd";
+
[PATCH v8 3/4] ARM: dts: add RK3288 suspend support
add pmu sram node for suspend, add global_pwroff pinctrl.
The pmu sram is used to store the resume code.
global_pwroff is held low level at work, it would be pull to high
when entering suspend. reference this in the board DTS file since
some boards need it.
ddrio_pwroff is power switch of ddr_controller, if you want to cut off
power rail of ddr_controller during suspend, please reference it.
ddr0_retention/ddr1_retention are the retention mode switches, if you
want to use the retention mode during suspend, please reference them.
Signed-off-by: Tony Xie
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
---
Changes in v8:
- add ddr pinctrl for suspend
Changes in v7: None
Changes in v6:
- change pmu_intmem@ff72 to sram@ff72
Changes in v5:
- change size to 4k
Changes in v4: None
Changes in v3: None
Changes in v2:
- put "rockchip,rk3288-pmu-sram" to first
arch/arm/boot/dts/rk3288.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index df30437..60bccff 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -482,6 +482,11 @@
};
};
+ sram@ff72 {
+ compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
+ reg = <0xff72 0x1000>;
+ };
+
pmu: power-management@ff73 {
compatible = "rockchip,rk3288-pmu", "syscon";
reg = <0xff73 0x100>;
@@ -687,6 +692,24 @@
bias-disable;
};
+ sleep {
+ global_pwroff: global-pwroff {
+ rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ ddrio_pwroff: ddrio-pwroff {
+ rockchip,pins = <0 1 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ ddr0_retention: ddr0-retention {
+ rockchip,pins = <0 2 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ ddr1_retention: ddr1-retention {
+ rockchip,pins = <0 3 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 15 RK_FUNC_1
&pcfg_pull_none>,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/4] ARM: rockchip: Add pmu-sram binding
The pmu-sram is used to store resume code, suspend/resume need get the
address of it. Therefore add a binding and documentation for it.
Signed-off-by: Tony Xie
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
---
Changes in v8: None
Changes in v7: None
Changes in v6:
- change pmu_intmem@ff72 to sram@ff72
Changes in v5:
- change the size of sram in example
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/arm/rockchip/pmu-sram.txt| 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
new file mode 100644
index 000..6b42fda
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
@@ -0,0 +1,16 @@
+Rockchip SRAM for pmu:
+--
+
+The sram of pmu is used to store the function of resume from maskrom(the 1st
+level loader). This is a common use of the "pmu-sram" because it keeps power
+even in low power states in the system.
+
+Required node properties:
+- compatible : should be "rockchip,rk3288-pmu-sram"
+- reg : physical base address and the size of the registers window
+
+Example:
+ sram@ff72 {
+ compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
+ reg = <0xff72 0x1000>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Hi Kevin,
On Fri, Nov 14, 2014 at 6:36 PM, Kevin Hilman wrote:
>> On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman wrote:
>>> It makes little sense to use generic power domains without runtime PM.
>>
>> Does it?
>> It still powers down the PM domains on system suspend (at least on my
>> boards ;-)
>
> Sure, but your devices are also using runtime PM, so I'm not sure how
> does that change my statement above?
I do mean with CONFIG_PM_RUNTIME turned off.
If PM domain support is disabled, s2ram will not power down the PM domains.
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] genirq: Add IRQ 0 to domain debug file
On 2014/11/15 19:27, Dmitry Eremin-Solenikov wrote:
> Currently irq_domain_mapping debugfs file dumps IRQ information starting
> from IRQ 1. IRQ 0 is missing from that file. Add it to have the complete
> picture of IRQ/domains mappings.
Hi Dmitry,
For most irqdomain interfaces, they treat irq0 as invalid
interrupt. But on x86, it's possible to use irq0 for timer. It causes
may confusion when enabling irqdomain for x86.
Regards!
Gerry
>
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> kernel/irq/irqdomain.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 6534ff6..0e0c7a8 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -585,7 +585,7 @@ static int virq_debug_show(struct seq_file *m, void
> *private)
> "chip name", (int)(2 * sizeof(void *) + 2), "chip data",
> "active", "type", "domain");
>
> - for (i = 1; i < nr_irqs; i++) {
> + for (i = 0; i < nr_irqs; i++) {
> desc = irq_to_desc(i);
> if (!desc)
> continue;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zsmalloc: correct fragile [kmap|kunmap]_atomic use
On (11/14/14 09:07), Seth Jennings wrote:
> On Fri, Nov 14, 2014 at 10:11:01AM +0900, Minchan Kim wrote:
> > The kunmap_atomic should use virtual address getting by kmap_atomic.
> > However, some pieces of code in zsmalloc uses modified address,
> > not the one got by kmap_atomic for kunmap_atomic.
> >
> > It's okay for working because zsmalloc modifies the address
> > inner PAGE_SIZE bounday so it works with current kmap_atomic's
> > implementation. But it's still fragile with potential changing
> > of kmap_atomic so let's correct it.
>
> Seems like you could just use PAGE_MASK to get the base page address
> from link like this:
>
both solutions look good to me:
Acked-by: Sergey Senozhatsky
-ss
> ---
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index b3b57ef..d6ca05a 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -654,7 +654,7 @@ static void init_zspage(struct page *first_page, struct
> size_class *class)
> */
> next_page = get_next_page(page);
> link->next = obj_location_to_handle(next_page, 0);
> - kunmap_atomic(link);
> + kunmap_atomic((void *)((unsigned long)link & PAGE_MASK));
> page = next_page;
> off %= PAGE_SIZE;
> }
> @@ -1087,7 +1087,7 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
> size)
> m_offset / sizeof(*link);
> first_page->freelist = link->next;
> memset(link, POISON_INUSE, sizeof(*link));
> - kunmap_atomic(link);
> + kunmap_atomic((void *)((unsigned long)link & PAGE_MASK));
>
> first_page->inuse++;
> /* Now move the zspage to another fullness group, if required */
> @@ -1124,7 +1124,7 @@ void zs_free(struct zs_pool *pool, unsigned long obj)
> link = (struct link_free *)((unsigned char *)kmap_atomic(f_page)
> + f_offset);
> link->next = first_page->freelist;
> - kunmap_atomic(link);
> + kunmap_atomic((void *)((unsigned long)link & PAGE_MASK));
> first_page->freelist = (void *)obj;
>
> first_page->inuse--;
> ---
>
> This seems cleaner, but, at the same time, it isn't obvious that we are
> passing the same value to kunmap_atomic() that we got from
> kmap_atomic(). Just a thought.
>
> Either way:
>
> Reviewed-by: Seth Jennings
>
> >
> > Signed-off-by: Minchan Kim
> > ---
> > mm/zsmalloc.c | 21 -
> > 1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index b3b57ef85830..85e14f584048 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -629,6 +629,7 @@ static void init_zspage(struct page *first_page, struct
> > size_class *class)
> > struct page *next_page;
> > struct link_free *link;
> > unsigned int i = 1;
> > + void *vaddr;
> >
> > /*
> > * page->index stores offset of first object starting
> > @@ -639,8 +640,8 @@ static void init_zspage(struct page *first_page, struct
> > size_class *class)
> > if (page != first_page)
> > page->index = off;
> >
> > - link = (struct link_free *)kmap_atomic(page) +
> > - off / sizeof(*link);
> > + vaddr = kmap_atomic(page);
> > + link = (struct link_free *)vaddr + off / sizeof(*link);
> >
> > while ((off += class->size) < PAGE_SIZE) {
> > link->next = obj_location_to_handle(page, i++);
> > @@ -654,7 +655,7 @@ static void init_zspage(struct page *first_page, struct
> > size_class *class)
> > */
> > next_page = get_next_page(page);
> > link->next = obj_location_to_handle(next_page, 0);
> > - kunmap_atomic(link);
> > + kunmap_atomic(vaddr);
> > page = next_page;
> > off %= PAGE_SIZE;
> > }
> > @@ -1055,6 +1056,7 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
> > size)
> > unsigned long obj;
> > struct link_free *link;
> > struct size_class *class;
> > + void *vaddr;
> >
> > struct page *first_page, *m_page;
> > unsigned long m_objidx, m_offset;
> > @@ -1083,11 +1085,11 @@ unsigned long zs_malloc(struct zs_pool *pool,
> > size_t size)
> > obj_handle_to_location(obj, &m_page, &m_objidx);
> > m_offset = obj_idx_to_offset(m_page, m_objidx, class->size);
> >
> > - link = (struct link_free *)kmap_atomic(m_page) +
> > - m_offset / sizeof(*link);
> > + vaddr = kmap_atomic(m_page);
> > + link = (struct link_free *)vaddr + m_offset / sizeof(*link);
> > first_page->freelist = link->next;
> > memset(link, POISON_INUSE, sizeof(*link));
> > - kunmap_atomic(link);
> > + kunmap_atomic(vaddr);
> >
> > first_page->inuse++;
> > /* Now move the zspage t
Re: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
On Wed, Nov 12, 2014 at 12:17:57PM +, Bruno Thomsen wrote: > Hi Johan, > > > As you may have seen by now, I've been working on refactoring the > > micrel phy driver to be able to use common initialisation code. > > > > Specifically, I've added generic support for disabling the broadcast > > address, which is what the MII_KSZPHY_OMSO write above does. > > > > Generally you want this to be the first thing you do in order to > > avoid unnecessary reconfigurations. If we ever were to allow > > concurrent probing this would also be a requirement. > > > > Could you provide some detail about the setup were you find that the > > PHY becomes unresponsive without your patch? Do you have more than > > one PHY on the bus? Using what addresses? And using what clock modes > > (i.e. 25 MHz or 50 MHz)? > > > > Also, what exactly do you mean by "unresponsive"? Are you still able > > to read the PHY registers for example? > > I think it sounds like a good idea to refactor the init code. > > My setup: > iMX28 processor with dual Ethernet MAC; FEC0 (enabled) and FEC1 (disabled). > There is a single KSZ8031 PHY that receives 50MHz RMII clock from the MAC. > I am unable to read PHY registers from both user-land tools and extra > debug PHY reads in driver code. Did you specify a led-mode as well, or was the Operation Mode Strap Override (OMSO) write the first access after the soft reset? Did you try any other workarounds besides setting the clock mode before doing the OMSO write? And REF_CLK (pin 16) is not connected? > Boot trace: > [ 22.277785] fec 800f.ethernet eth0: Freescale FEC PHY driver [Micrel > KSZ8031] (mii_bus:phy_addr=800f.etherne:00, irq=-1) > [ 22.292527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 24.276217] libphy: 800f.etherne:00 - Link is Up - 100/Full > [ 24.285094] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Ok, so you use a single PHY strapped to address 0. Would you able to test my series on your setup, and possibly a couple of diagnostic patches on top? Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] Refine generic/PCI MSI irqodmian interfaces
This patch set is based on tip/irq/irqdomain and tries to refine
interfaces to support irqdomain for generic MSI and PCI MSI.
Patch 1 is just minor fixes for tip/irq/irqdomain.
Patch 2-4 introduce mechanisms to help reduce irqdomain users' code size.
When converting XEN to use hierarchy irqdomain, I found the code size
increases about 100 lines. So we still need helpers to reduce code size.
Patch 5 introduces some helpers to hide struct msi_desc implementation
details, so later we could move msi_list from struct pci_dev into
struct device to enable generic MSI support.
Patch 6 introduces msi_domain_{alloc|free}_irqs() which generalize
pci_msi_domain_alloc_irqs() to support generic MSI.
Patch 7 introduces default data structures and callback implementations
to support msi_domain_alloc_irqs(), so reduce burden on generic MSI
users.
Patch 8 converts PCI MSI to use generic MSI interfaces, and also
implement default callbacks for PCI MSI.
Patch 9 introduces a mechanism to replace arch_setup_msi_irq()/
arch_setup_msi_irqs()/arch_teardown_msi_irq()/arch_teardown_msi_irqs().
With this patch set applied, the generic MSI and PCI MSI interfaces
are much easier to use. For extreme case, you only need to define
a "struct msi_domain_info" and don't need to implement any callbacks,
just using the default callbacks is OK:)
This patch set is also a preparation for:
1) Kill all weak functions in drivers/pci/msi.c
2) Implement support for non-PCI-compliant MSI device
It has been tested on x86 platforms, comments are welcomed!
V1->V2:
1) Fix bugs reported by Marc
2) Rename MSI_FLAG_USE_DEF_OPS as MSI_FLAG_USE_DEF_DOM_OPS
3) Add support of MSI_FLAG_USE_DEF_CHIP_OPS
4) Include linxu/irqhandler.h to use irq_flow_handler_t instead of "void *"
5) Change iterfaces to pass in "nvect" to msi_domain_ops.msi_prepare()
6) Add new interfaces/flags to help reduce irqdomain users' code size
Jiang Liu (8):
PCI, MSI: Fix errors caused by commit e5f1a59c4e12
irqdomain: Implement a method to automatically call parent domain's
alloc/free
irqdomain: Introduce helper function irq_domain_add_hierarchy()
PCI, MSI: Introduce helpers to hide struct msi_desc implementation
details
genirq: Introduce msi_domain_{alloc|free}_irqs()
genirq: Provide default callbacks for msi_domain_ops
PCI, MSI: Refine irqdomain interfaces to simplify its usage
PCI, MSI: Provide mechanism to alloc/free MSI/MSIX interrupt from
irqdomain
Yingjoe Chen (1):
irqdomain: Use consistent prototype for irq_domain_free_irqs_*
drivers/pci/msi.c | 181 -
include/linux/irqdomain.h | 33 -
include/linux/msi.h | 99 ++---
kernel/irq/irqdomain.c| 93 +--
kernel/irq/msi.c | 169 --
5 files changed, 502 insertions(+), 73 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch V2 4/9] irqdomain: Introduce helper function irq_domain_add_hierarchy()
Introduce helper function irq_domain_add_hierarchy(), which creates
a linear irqdomain if parameter 'size' is not zero, otherwise creates
a tree irqdomain.
Signed-off-by: Jiang Liu
---
include/linux/irqdomain.h |4
kernel/irq/irqdomain.c| 19 +++
2 files changed, 23 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index ad92b0b15945..30e8c753fa98 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -248,6 +248,10 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
struct device_node *ctrlr,
extern struct irq_data *irq_domain_get_irq_data(struct irq_domain *domain,
unsigned int virq);
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+extern struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *parent,
+ unsigned int flags, unsigned int size,
+ struct device_node *node,
+ const struct irq_domain_ops *ops, void *host_data);
extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
unsigned int nr_irqs, int node, void *arg,
bool realloc);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 03fc7d018324..73c66d6f9ffc 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -742,6 +742,25 @@ static int irq_domain_alloc_descs(int virq, unsigned int
cnt,
}
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *parent,
+ unsigned int flags, unsigned int size,
+ struct device_node *node,
+ const struct irq_domain_ops *ops, void *host_data)
+{
+ struct irq_domain *domain;
+
+ if (size)
+ domain = irq_domain_add_linear(node, size, ops, host_data);
+ else
+ domain = irq_domain_add_tree(node, ops, host_data);
+ if (domain) {
+ domain->parent = parent;
+ domain->flags |= flags;
+ }
+
+ return domain;
+}
+
static void irq_domain_insert_irq(int virq)
{
struct irq_data *data;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch V2 1/9] PCI, MSI: Fix errors caused by commit e5f1a59c4e12
Better to fold into commit e5f1a59c4e12 ("PCI/MSI: Rename write_msi_msg()
to pci_write_msi_msg()").
Signed-off-by: Jiang Liu
---
drivers/pci/msi.c |2 +-
include/linux/msi.h |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 564850b1316e..9c53b865cb1b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1084,7 +1084,7 @@ void pci_msi_domain_write_msg(struct irq_data *irq_data,
struct msi_msg *msg)
* MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
*/
if (desc->irq == irq_data->irq)
- pci_write_msi_msg(desc, msg);
+ __pci_write_msi_msg(desc, msg);
}
/*
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 8112a17cdca1..190c7abbec84 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -44,11 +44,9 @@ struct msi_desc {
struct msi_msg msg;
};
-#ifdef CONFIG_PCI_MSI
void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void pci_write_msi_msg(unsigned int irq, struct msi_msg *msg);
-#endif
/*
* The arch hooks to setup up msi irqs. Those functions are
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch V2 3/9] irqdomain: Implement a method to automatically call parent domain's alloc/free
Add a flags to irq_domain.flags to control whether the irqdomain core
should automatically call parent irqdomain's alloc/free callbacks. It
help to reduce hierarchy irqdomains users' code size.
Signed-off-by: Jiang Liu
---
include/linux/irqdomain.h | 24 ++---
kernel/irq/irqdomain.c| 66 +++--
2 files changed, 72 insertions(+), 18 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index fbe542967c20..ad92b0b15945 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -130,6 +130,8 @@ struct irq_domain {
};
#defineIRQ_DOMAIN_FLAG_HIERARCHY 0x1
+/* Framework automatically calls parent domain's alloc()/free() */
+#defineIRQ_DOMAIN_FLAG_AUTO_RECURSIVE 0x2
#defineIRQ_DOMAIN_FLAG_ARCH1 0x1
#ifdef CONFIG_IRQ_DOMAIN
@@ -274,22 +276,12 @@ extern void irq_domain_free_irqs_common(struct irq_domain
*domain,
unsigned int nr_irqs);
extern void irq_domain_free_irqs_top(struct irq_domain *domain,
unsigned int virq, unsigned int nr_irqs);
-
-static inline int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
- unsigned int irq_base, unsigned int nr_irqs, void *arg)
-{
- if (domain->parent && domain->parent->ops->alloc)
- return domain->parent->ops->alloc(domain->parent, irq_base,
- nr_irqs, arg);
- return -ENOSYS;
-}
-
-static inline void irq_domain_free_irqs_parent(struct irq_domain *domain,
- unsigned int irq_base, unsigned int nr_irqs)
-{
- if (domain->parent && domain->parent->ops->free)
- domain->parent->ops->free(domain->parent, irq_base, nr_irqs);
-}
+extern int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
+ unsigned int irq_base,
+ unsigned int nr_irqs, void *arg);
+extern void irq_domain_free_irqs_parent(struct irq_domain *domain,
+ unsigned int irq_base,
+ unsigned int nr_irqs);
static inline bool irq_domain_is_hierarchy(struct irq_domain *domain)
{
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 705fb573e509..03fc7d018324 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -925,6 +925,43 @@ void irq_domain_free_irqs_top(struct irq_domain *domain,
unsigned int virq,
irq_domain_free_irqs_common(domain, virq, nr_irqs);
}
+static bool irq_domain_is_auto_recursive(struct irq_domain *domain)
+{
+ return domain->flags & IRQ_DOMAIN_FLAG_AUTO_RECURSIVE;
+}
+
+static void irq_domain_free_irqs_recursive(struct irq_domain *domain,
+ unsigned int irq_base,
+ unsigned int nr_irqs)
+{
+ domain->ops->free(domain, irq_base, nr_irqs);
+ if (irq_domain_is_auto_recursive(domain)) {
+ BUG_ON(!domain->parent);
+ irq_domain_free_irqs_recursive(domain->parent, irq_base,
+ nr_irqs);
+ }
+}
+
+static int irq_domain_alloc_irqs_recursive(struct irq_domain *domain,
+ unsigned int irq_base,
+ unsigned int nr_irqs, void *arg)
+{
+ int ret = 0;
+ struct irq_domain *parent = domain->parent;
+ bool recursive = irq_domain_is_auto_recursive(domain);
+
+ BUG_ON(recursive && !parent);
+ if (recursive)
+ ret = irq_domain_alloc_irqs_recursive(parent, irq_base,
+ nr_irqs, arg);
+ if (ret >= 0)
+ ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
+ if (ret < 0 && recursive)
+ irq_domain_free_irqs_recursive(parent, irq_base, nr_irqs);
+
+ return ret;
+}
+
/**
* __irq_domain_alloc_irqs - Allocate IRQs from domain
* @domain: domain to allocate from
@@ -981,7 +1018,7 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int
irq_base,
}
mutex_lock(&irq_domain_mutex);
- ret = domain->ops->alloc(domain, virq, nr_irqs, arg);
+ ret = irq_domain_alloc_irqs_recursive(domain, virq, nr_irqs, arg);
if (ret < 0) {
mutex_unlock(&irq_domain_mutex);
goto out_free_irq_data;
@@ -1016,13 +1053,38 @@ void irq_domain_free_irqs(unsigned int virq, unsigned
int nr_irqs)
mutex_lock(&irq_domain_mutex);
for (i = 0; i < nr_irqs; i++)
irq_domain_remove_irq(virq + i);
- data->domain->ops->free(data->domain, virq, nr_irqs);
+ irq_domain_free_irqs_recursive(data->domain, virq, nr_irqs);
mutex_unlock(&irq_domain_mutex);
irq_domain_free_irq_data(vi
[Patch V2 9/9] PCI, MSI: Provide mechanism to alloc/free MSI/MSIX interrupt from irqdomain
Provide mechanism to directly alloc/free MSI/MSIX interrupt from
irqdomain, which will be used to replace arch_setup_msi_irq()/
arch_setup_msi_irqs()/arch_teardown_msi_irq()/arch_teardown_msi_irqs().
To kill weak functions, this patch introduce a new weak function
arch_get_pci_msi_domain(), which is to retrieve the MSI irqdomain
for a PCI device. This weak function could be killed once we get
a common way to associate MSI domain with PCI device.
Signed-off-by: Jiang Liu
---
drivers/pci/msi.c | 60 +++
include/linux/msi.h |3 +++
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 1dd5d93bd4b8..a66a4eaf8111 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -27,8 +27,41 @@ static int pci_msi_enable = 1;
#define msix_table_size(flags) ((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
-/* Arch hooks */
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+static struct irq_domain *pci_msi_default_domain;
+
+struct irq_domain * __weak arch_get_pci_msi_domain(struct pci_dev *dev)
+{
+ return pci_msi_default_domain;
+}
+
+static int pci_msi_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ struct irq_domain *domain;
+ domain = arch_get_pci_msi_domain(dev);
+ if (domain)
+ return pci_msi_domain_alloc_irqs(domain, dev, nvec, type);
+
+ return arch_setup_msi_irqs(dev, nvec, type);
+}
+
+static void pci_msi_teardown_msi_irqs(struct pci_dev *dev)
+{
+ struct irq_domain *domain;
+
+ domain = arch_get_pci_msi_domain(dev);
+ if (domain)
+ pci_msi_domain_free_irqs(domain, dev);
+ else
+ arch_teardown_msi_irqs(dev);
+}
+#else
+#define pci_msi_setup_msi_irqs arch_setup_msi_irqs
+#define pci_msi_teardown_msi_irqs arch_teardown_msi_irqs
+#endif
+
+/* Arch hooks */
int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
struct msi_chip *chip = dev->bus->msi;
@@ -329,7 +362,7 @@ static void free_msi_irqs(struct pci_dev *dev)
for (i = 0; i < entry->nvec_used; i++)
BUG_ON(irq_has_action(entry->irq + i));
- arch_teardown_msi_irqs(dev);
+ pci_msi_teardown_msi_irqs(dev);
list_for_each_entry_safe(entry, tmp, &dev->msi_list, list) {
if (entry->msi_attrib.is_msix) {
@@ -581,7 +614,7 @@ static int msi_capability_init(struct pci_dev *dev, int
nvec)
list_add_tail(&entry->list, &dev->msi_list);
/* Configure MSI capability structure */
- ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
+ ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
if (ret) {
msi_mask_irq(entry, mask, ~mask);
free_msi_irqs(dev);
@@ -696,7 +729,7 @@ static int msix_capability_init(struct pci_dev *dev,
if (ret)
return ret;
- ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
+ ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
if (ret)
goto out_avail;
@@ -1194,4 +1227,23 @@ void pci_msi_domain_free_irqs(struct irq_domain *domain,
struct pci_dev *dev)
{
msi_domain_free_irqs(domain, &dev->dev);
}
+
+struct irq_domain *pci_msi_create_default_irq_domain(struct device_node *node,
+struct msi_domain_info *info, struct irq_domain *parent)
+{
+ struct irq_domain *domain;
+ static DEFINE_MUTEX(pci_msi_domain_lock);
+
+ mutex_lock(&pci_msi_domain_lock);
+ if (pci_msi_default_domain) {
+ pr_err("PCI: default irq domain for PCI MSI has already been
created.\n");
+ domain = NULL;
+ } else {
+ domain = pci_msi_create_irq_domain(node, info, parent);
+ pci_msi_default_domain = domain;
+ }
+ mutex_unlock(&pci_msi_domain_lock);
+
+ return domain;
+}
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 0463e361fef8..ba173a6a007e 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -192,6 +192,9 @@ struct irq_domain *pci_msi_create_irq_domain(struct
device_node *node,
int pci_msi_domain_alloc_irqs(struct irq_domain *domain, struct pci_dev *dev,
int nvec, int type);
void pci_msi_domain_free_irqs(struct irq_domain *domain, struct pci_dev *dev);
+struct irq_domain *pci_msi_create_default_irq_domain(struct device_node *node,
+struct msi_domain_info *info, struct irq_domain *parent);
+
irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev *dev,
struct msi_desc *desc);
int pci_msi_domain_check_cap(struct irq_domain *domain,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
[Patch V2 8/9] PCI, MSI: Refine irqdomain interfaces to simplify its usage
Refine irqdomain interfaces to simplify its usage.
Signed-off-by: Jiang Liu
---
drivers/pci/msi.c | 119 ++-
include/linux/msi.h | 13 +++---
2 files changed, 98 insertions(+), 34 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 9c53b865cb1b..1dd5d93bd4b8 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1099,38 +1099,99 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct
pci_dev *dev,
(pci_domain_nr(dev->bus) & 0x) << 27;
}
-int pci_msi_domain_alloc_irqs(struct irq_domain *domain, int type,
- struct pci_dev *dev, void *arg)
+static inline bool pci_msi_desc_is_multi_msi(struct msi_desc *desc)
{
- struct msi_domain_info *info = domain->host_data;
- int node = dev_to_node(&dev->dev);
- struct msi_desc *desc;
- int i, virq;
-
- list_for_each_entry(desc, &dev->msi_list, list) {
- if (info->ops->calc_hwirq)
- info->ops->calc_hwirq(info, arg, desc);
-
- virq = irq_domain_alloc_irqs(domain, desc->nvec_used,
-node, arg);
- if (virq < 0) {
- /* Special handling for pci_enable_msi_range(). */
- if (type == PCI_CAP_ID_MSI && desc->nvec_used > 1)
- return 1;
- else
- return -ENOSPC;
- }
- for (i = 0; i < desc->nvec_used; i++)
- irq_set_msi_desc_off(virq, i, desc);
- }
+ return !desc->msi_attrib.is_msix && desc->nvec_used > 1;
+}
- list_for_each_entry(desc, &dev->msi_list, list)
- if (desc->nvec_used == 1)
- dev_dbg(&dev->dev, "irq %d for MSI/MSI-X\n", virq);
- else
- dev_dbg(&dev->dev, "irq [%d-%d] for MSI/MSI-X\n",
- virq, virq + desc->nvec_used - 1);
+int pci_msi_domain_check_cap(struct irq_domain *domain,
+struct msi_domain_info *info, struct device *dev)
+{
+ struct msi_desc *desc = first_pci_msi_entry(to_pci_dev(dev));
+
+ /* Special handling to support pci_enable_msi_range() */
+ if (pci_msi_desc_is_multi_msi(desc) &&
+ !(info->flags & MSI_FLAG_MULTI_PCI_MSI))
+ return 1;
+ else if (desc->msi_attrib.is_msix && !(info->flags & MSI_FLAG_PCI_MSIX))
+ return -ENOTSUPP;
return 0;
}
+
+static int pci_msi_domain_handle_error(struct irq_domain *domain,
+ struct msi_desc *desc, int error)
+{
+ /* Special handling to support pci_enable_msi_range() */
+ if (pci_msi_desc_is_multi_msi(desc) && error == -ENOSPC)
+ return 1;
+
+ return error;
+}
+
+#ifndef msi_alloc_info_t
+static void pci_msi_domain_set_desc(struct msi_alloc_info *arg,
+ struct msi_desc *desc)
+{
+ arg->desc = desc;
+ arg->hwirq = pci_msi_domain_calc_hwirq(msi_desc_to_pci_dev(desc),
+ desc);
+}
+#else
+#define pci_msi_domain_set_descNULL
+#endif
+
+static struct msi_domain_ops pci_msi_domain_ops_default = {
+ .set_desc = pci_msi_domain_set_desc,
+ .msi_check = pci_msi_domain_check_cap,
+ .handle_error = pci_msi_domain_handle_error,
+};
+
+static void pci_msi_domain_update_dom_ops(struct msi_domain_info *info)
+{
+ struct msi_domain_ops *ops = info->ops;
+
+ if (ops == NULL) {
+ info->ops = &pci_msi_domain_ops_default;
+ } else {
+ if (ops->set_desc == NULL)
+ ops->set_desc = pci_msi_domain_set_desc;
+ if (ops->msi_check == NULL)
+ ops->msi_check = pci_msi_domain_check_cap;
+ if (ops->handle_error == NULL)
+ ops->handle_error = pci_msi_domain_handle_error;
+ }
+}
+
+static void pci_msi_domain_update_chip_ops(struct msi_domain_info *info)
+{
+ struct irq_chip *chip = info->chip;
+
+ BUG_ON(!chip);
+ if (!chip->irq_write_msi_msg)
+ chip->irq_write_msi_msg = pci_msi_domain_write_msg;
+}
+
+struct irq_domain *pci_msi_create_irq_domain(struct device_node *node,
+struct msi_domain_info *info,
+struct irq_domain *parent)
+{
+ if (info->flags & MSI_FLAG_USE_DEF_DOM_OPS)
+ pci_msi_domain_update_dom_ops(info);
+ if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
+ pci_msi_domain_update_chip_ops(info);
+
+ return msi_create_irq_domain(node, info, parent);
+}
+
+int pci_msi_domain_alloc_irqs(struct irq_domain *domain, struct pci_dev *dev,
+ int nvec, int type)
+{
+ re
[Patch V2 7/9] genirq: Provide default callbacks for msi_domain_ops
Extend struct msi_domain_info and provide default callbacks for
msi_domain_ops.
Signed-off-by: Jiang Liu
---
include/linux/msi.h | 29 ++---
kernel/irq/msi.c| 113 +++
2 files changed, 129 insertions(+), 13 deletions(-)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 7283e155afef..96ee8c3b98cc 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -3,6 +3,7 @@
#include
#include
+#include
#include /* for msi_alloc_info_t */
struct msi_msg {
@@ -124,13 +125,15 @@ typedef struct msi_alloc_info msi_alloc_info_t;
struct msi_domain_ops {
/* Callbacks for msi_create_irq_domain() */
- void(*calc_hwirq)(struct msi_domain_info *info, void *arg,
+ void(*calc_hwirq)(struct msi_domain_info *info,
+ msi_alloc_info_t *arg,
struct msi_desc *desc);
- irq_hw_number_t (*get_hwirq)(struct msi_domain_info *info, void *arg);
+ irq_hw_number_t (*get_hwirq)(struct msi_domain_info *info,
+msi_alloc_info_t *arg);
int (*msi_init)(struct irq_domain *domain,
struct msi_domain_info *info,
unsigned int virq, irq_hw_number_t hwirq,
- void *arg);
+ msi_alloc_info_t *arg);
void(*msi_free)(struct irq_domain *domain,
struct msi_domain_info *info,
unsigned int virq);
@@ -150,15 +153,31 @@ struct msi_domain_ops {
};
struct msi_domain_info {
+ u32 flags;
struct msi_domain_ops *ops;
struct irq_chip *chip;
- void*data;
+ void*chip_data; /* optional chip data */
+ irq_flow_handler_t handler;/* optional flow handler */
+ void*handler_data; /* optional handler data */
+ const char *handler_name; /* optional handler name */
+ void*data; /* optional private data */
};
+/* Use default MSI domain ops if possible */
+#define MSI_FLAG_USE_DEF_DOM_OPS 0x1
+/* Use default MSI chip ops if possible */
+#define MSI_FLAG_USE_DEF_CHIP_OPS 0x2
+/* Build identity map between hwirq and irq */
+#define MSI_FLAG_IDENTITY_MAP 0x10
+/* Support multiple PCI MSI interrupts */
+#define MSI_FLAG_MULTI_PCI_MSI 0x100
+/* Support PCI MSIX interrupts */
+#define MSI_FLAG_PCI_MSIX 0x200
+
int msi_domain_set_affinity(struct irq_data *data, const struct cpumask *mask,
bool force);
-struct irq_domain *msi_create_irq_domain(struct device_node *of_node,
+struct irq_domain *msi_create_irq_domain(struct device_node *node,
struct msi_domain_info *info,
struct irq_domain *parent);
int msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ce054566edf5..ff15fd643b3d 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -9,6 +9,8 @@
* This file contains common code to support Message Signalled Interrupt for
* PCI compatible and non PCI compatible devices.
*/
+#include
+#include
#include
#include
#include
@@ -114,17 +116,108 @@ static struct irq_domain_ops msi_domain_ops = {
.deactivate = msi_domain_deactivate,
};
-struct irq_domain *msi_create_irq_domain(struct device_node *of_node,
+#ifndef msi_alloc_info_t
+static irq_hw_number_t msi_domain_ops_get_hwirq(struct msi_domain_info *info,
+ struct msi_alloc_info *arg)
+{
+ return arg->hwirq;
+}
+
+static int msi_domain_ops_prepare(struct irq_domain *domain, struct device
*dev,
+ int nvec, struct msi_alloc_info *arg)
+{
+ memset(arg, 0, sizeof(*arg));
+
+ return 0;
+}
+
+static void msi_domain_ops_set_desc(struct msi_alloc_info *arg,
+ struct msi_desc *desc)
+{
+ arg->desc = desc;
+}
+#else
+#define msi_domain_ops_get_hwirq NULL
+#define msi_domain_ops_prepare NULL
+#define msi_domain_ops_set_descNULL
+#endif /* msi_alloc_info_t */
+
+static int msi_domain_ops_init(struct irq_domain *domain,
+ struct msi_domain_info *info,
+ unsigned int virq, irq_hw_number_t hwirq,
+ msi_alloc_info_t *arg)
+{
+ irq_domain_set_hwirq_and_chip(domain, virq, hwirq, info->chip,
+ info->chip_data);
+ if (info->handler && info->handler_name) {
+ __irq_set_handler(virq,
[Patch V2 6/9] genirq: Introduce msi_domain_{alloc|free}_irqs()
Introduce msi_domain_{alloc|free}_irqs() to alloc/free interrupts
from generic MSI irqdomain.
Signed-off-by: Jiang Liu
---
include/linux/msi.h | 39 +
kernel/irq/msi.c| 60 +++
2 files changed, 99 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 714716a3ffdd..7283e155afef 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -3,6 +3,7 @@
#include
#include
+#include /* for msi_alloc_info_t */
struct msi_msg {
u32 address_lo; /* low 32 bits of msi message address */
@@ -100,7 +101,29 @@ struct irq_chip;
struct device_node;
struct msi_domain_info;
+#ifndef NUM_MSI_ALLOC_SCRATCHPAD_REGS
+#define NUM_MSI_ALLOC_SCRATCHPAD_REGS 2
+#endif
+
+/*
+ * Default structure for MSI interrupt allocation.
+ * Arch may overwrite it by defining msi_alloc_info_t.
+ */
+struct msi_alloc_info {
+ struct msi_desc *desc;
+ irq_hw_number_t hwirq;
+ union {
+ unsigned long ul;
+ void*ptr;
+ } scratchpad[NUM_MSI_ALLOC_SCRATCHPAD_REGS];
+};
+
+#ifndef msi_alloc_info_t
+typedef struct msi_alloc_info msi_alloc_info_t;
+#endif
+
struct msi_domain_ops {
+ /* Callbacks for msi_create_irq_domain() */
void(*calc_hwirq)(struct msi_domain_info *info, void *arg,
struct msi_desc *desc);
irq_hw_number_t (*get_hwirq)(struct msi_domain_info *info, void *arg);
@@ -111,6 +134,19 @@ struct msi_domain_ops {
void(*msi_free)(struct irq_domain *domain,
struct msi_domain_info *info,
unsigned int virq);
+
+ /* Callbacks for msi_irq_domain_alloc_irqs() based on msi_descs */
+ int (*msi_check)(struct irq_domain *domain,
+struct msi_domain_info *info,
+struct device *dev);
+ int (*msi_prepare)(struct irq_domain *domain,
+ struct device *dev, int nvec,
+ msi_alloc_info_t *arg);
+ void(*msi_finish)(msi_alloc_info_t *arg, int retval);
+ void(*set_desc)(msi_alloc_info_t *arg,
+ struct msi_desc *desc);
+ int (*handle_error)(struct irq_domain *domain,
+ struct msi_desc *desc, int error);
};
struct msi_domain_info {
@@ -125,6 +161,9 @@ int msi_domain_set_affinity(struct irq_data *data, const
struct cpumask *mask,
struct irq_domain *msi_create_irq_domain(struct device_node *of_node,
struct msi_domain_info *info,
struct irq_domain *parent);
+int msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
+ int nvec);
+void msi_domain_free_irqs(struct irq_domain *domain, struct device *dev);
struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain);
#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 94d6d87ee23e..ce054566edf5 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -13,6 +13,9 @@
#include
#include
+/* Temparory solution for building, will be removed later */
+#include
+
void __get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
*msg = entry->msg;
@@ -124,6 +127,63 @@ struct irq_domain *msi_create_irq_domain(struct
device_node *of_node,
return domain;
}
+int msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
+ int nvec)
+{
+ int i, ret, virq = -1;
+ msi_alloc_info_t arg;
+ struct msi_desc *desc;
+ struct msi_domain_info *info = domain->host_data;
+ struct msi_domain_ops *ops = info->ops;
+
+ ret = ops->msi_check(domain, info, dev);
+ if (ret == 0)
+ ret = ops->msi_prepare(domain, dev, nvec, &arg);
+ if (ret)
+ return ret;
+
+ for_each_msi_entry(desc, dev) {
+ ops->set_desc(&arg, desc);
+
+ virq = __irq_domain_alloc_irqs(domain, -1, desc->nvec_used,
+ dev_to_node(dev), &arg, false);
+ if (virq < 0) {
+ ret = -ENOSPC;
+ if (ops->handle_error)
+ ret = ops->handle_error(domain, desc, ret);
+ if (ops->msi_finish)
+ ops->msi_finish(&arg, ret);
+ return ret;
+ }
+
+ for (i = 0; i < desc->nvec_used; i++)
+ irq_set_msi_desc_off(virq, i, desc);
+ }
+
+ if (ops->msi_finish)
+
[Patch V2 5/9] PCI, MSI: Introduce helpers to hide struct msi_desc implementation details
Introduce helpers to hide struct msi_desc implementation details,
so we could easily support non-PCI-compliant MSI devices later by
moving msi_list into struct device.
Signed-off-by: Jiang Liu
---
include/linux/msi.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 190c7abbec84..714716a3ffdd 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -44,6 +44,25 @@ struct msi_desc {
struct msi_msg msg;
};
+/* Helpers to hide struct msi_desc implementation details */
+#define msi_desc_to_dev(desc) (&(desc)->dev.dev)
+#define dev_to_msi_list(dev) (&to_pci_dev((dev))->msi_list)
+#define first_msi_entry(dev) \
+ list_first_entry(dev_to_msi_list((dev)), struct msi_desc, list)
+#define for_each_msi_entry(desc, dev) \
+ list_for_each_entry((desc), dev_to_msi_list((dev)), list)
+
+#ifdef CONFIG_PCI_MSI
+#define first_pci_msi_entry(pdev) first_msi_entry(&(pdev)->dev)
+#define for_each_pci_msi_entry(desc, pdev) \
+ for_each_msi_entry((desc), &(pdev)->dev)
+
+static inline struct pci_dev *msi_desc_to_pci_dev(struct msi_desc *desc)
+{
+ return desc->dev;
+}
+#endif /* CONFIG_PCI_MSI */
+
void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void pci_write_msi_msg(unsigned int irq, struct msi_msg *msg);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch V2 2/9] irqdomain: Use consistent prototype for irq_domain_free_irqs_*
From: Yingjoe Chen
When using irq_domain_free_irqs_top() directly in irq_domain_ops, gcc
generate the following warnings:
../drivers/irqchip/irq-gic.c:879:2: warning: initialization from incompatible
pointer type [enabled by default]
../drivers/irqchip/irq-gic.c:879:2: warning: (near initialization for
'gic_irq_domain_hierarchy_ops.free') [enabled by default]
Change to use consistent prototype for all irq_domain_free_irqs*
Better to fold this into "irqdomain: Introduce new interfaces to
support hierarchy irqdomains".
Signed-off-by: Yingjoe Chen
Signed-off-by: Jiang Liu
---
include/linux/irqdomain.h |9 +
kernel/irq/irqdomain.c|8
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 640a1ec54772..fbe542967c20 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -270,12 +270,13 @@ extern void irq_domain_set_info(struct irq_domain
*domain, unsigned int virq,
void *handler_data, const char *handler_name);
extern void irq_domain_reset_irq_data(struct irq_data *irq_data);
extern void irq_domain_free_irqs_common(struct irq_domain *domain,
- int virq, int nr_irqs);
+ unsigned int virq,
+ unsigned int nr_irqs);
extern void irq_domain_free_irqs_top(struct irq_domain *domain,
-int virq, int nr_irqs);
+unsigned int virq, unsigned int nr_irqs);
static inline int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
- int irq_base, unsigned int nr_irqs, void *arg)
+ unsigned int irq_base, unsigned int nr_irqs, void *arg)
{
if (domain->parent && domain->parent->ops->alloc)
return domain->parent->ops->alloc(domain->parent, irq_base,
@@ -284,7 +285,7 @@ static inline int irq_domain_alloc_irqs_parent(struct
irq_domain *domain,
}
static inline void irq_domain_free_irqs_parent(struct irq_domain *domain,
- int irq_base, unsigned int nr_irqs)
+ unsigned int irq_base, unsigned int nr_irqs)
{
if (domain->parent && domain->parent->ops->free)
domain->parent->ops->free(domain->parent, irq_base, nr_irqs);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8b0eddee0b21..705fb573e509 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -899,8 +899,8 @@ void irq_domain_reset_irq_data(struct irq_data *irq_data)
irq_data->chip_data = NULL;
}
-void irq_domain_free_irqs_common(struct irq_domain *domain, int virq,
-int nr_irqs)
+void irq_domain_free_irqs_common(struct irq_domain *domain, unsigned int virq,
+unsigned int nr_irqs)
{
int i;
struct irq_data *irq_data;
@@ -913,8 +913,8 @@ void irq_domain_free_irqs_common(struct irq_domain *domain,
int virq,
irq_domain_free_irqs_parent(domain, virq, nr_irqs);
}
-void irq_domain_free_irqs_top(struct irq_domain *domain, int virq,
- int nr_irqs)
+void irq_domain_free_irqs_top(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs)
{
int i;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk-divider: Fix READ_ONLY when divider > 1
Hi James, Am Freitag, 14. November 2014, 15:32:09 schrieb James Hogan: > Commit 79c6ab509558 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in > v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the > recalc_rate() and round_rate() clock callbacks to be omitted. > > However using this flag has the unfortunate side effect of causing the > clock recalculation code when a clock rate change is attempted to always > treat it as a pass-through clock, i.e. with a fixed divide of 1, which > may not be the case. Child clock rates are then recalculated using the > wrong parent rate. > > Therefore instead of dropping the recalc_rate() and round_rate() > callbacks, alter clk_divider_bestdiv() to always report the current > divider as the best divider so that it is never altered. > > For me the read only clock was the system clock, which divided the PLL > rate by 2, from which both the UART and the SPI clocks were divided. > Initial setting of the UART rate set it correctly, but when the SPI > clock was set, the other child clocks were miscalculated. The UART clock > was recalculated using the PLL rate as the parent rate, resulting in a > UART new_rate of double what it should be, and a UART which spewed forth > garbage when the rate changes were propagated. > > Signed-off-by: James Hogan > Cc: Mike Turquette > Cc: Heiko Stuebner > Cc: Thomas Abraham > Cc: Tomasz Figa > Cc: Max Schwarz > Cc: # v3.16+ Yep, your solution is much better I think. Reviewed-by: Heiko Stuebner Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: rtl8712: fix coding style warning
Simple style fix ("else is not generally useful after a break or return").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index c653ad6..cc3a446 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -126,26 +126,24 @@ static void crc32_init(void)
{
if (bcrc32initialized == 1)
return;
- else {
- sint i, j;
- u32 c;
- u8 *p = (u8 *)&c, *p1;
- u8 k;
-
- c = 0x1234;
- for (i = 0; i < 256; ++i) {
- k = crc32_reverseBit((u8)i);
- for (c = ((u32)k) << 24, j = 8; j > 0; --j)
- c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
- (c << 1);
- p1 = (u8 *)&crc32_table[i];
- p1[0] = crc32_reverseBit(p[3]);
- p1[1] = crc32_reverseBit(p[2]);
- p1[2] = crc32_reverseBit(p[1]);
- p1[3] = crc32_reverseBit(p[0]);
- }
- bcrc32initialized = 1;
+ sint i, j;
+ u32 c;
+ u8 *p = (u8 *)&c, *p1;
+ u8 k;
+
+ c = 0x1234;
+ for (i = 0; i < 256; ++i) {
+ k = crc32_reverseBit((u8)i);
+ for (c = ((u32)k) << 24, j = 8; j > 0; --j)
+ c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
+ (c << 1);
+ p1 = (u8 *)&crc32_table[i];
+ p1[0] = crc32_reverseBit(p[3]);
+ p1[1] = crc32_reverseBit(p[2]);
+ p1[2] = crc32_reverseBit(p[1]);
+ p1[3] = crc32_reverseBit(p[0]);
}
+ bcrc32initialized = 1;
}
static u32 getcrc32(u8 *buf, u32 len)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Hi Boris, Boris Brezillon wrote: > Hi Sakari, > > On Fri, 14 Nov 2014 15:58:31 +0200 > Sakari Ailus wrote: > >> Hi Boris, >> >> On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote: ... >>> diff --git a/include/uapi/linux/media-bus-format.h >>> b/include/uapi/linux/media-bus-format.h >>> index 23b4090..cc7b79e 100644 >>> --- a/include/uapi/linux/media-bus-format.h >>> +++ b/include/uapi/linux/media-bus-format.h >>> @@ -33,7 +33,7 @@ >>> >>> #define MEDIA_BUS_FMT_FIXED0x0001 >>> >>> -/* RGB - next is 0x100e */ >>> +/* RGB - next is 0x1010 */ >>> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 >>> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 >>> #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 >>> @@ -47,6 +47,8 @@ >>> #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b >>> #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c >>> #define MEDIA_BUS_FMT_ARGB_1X320x100d >>> +#define MEDIA_BUS_FMT_RGB444_1X12 0x100e >>> +#define MEDIA_BUS_FMT_RGB565_1X16 0x100f >> >> I'd arrange these according to BPP and bits per sample, both in the header >> and documentation. > > I cannot keep both macro values and BPP/bits per sample in incrementing > order. Are you sure you prefer to order macros in BPP/bits per sample > order ? If you take a look elsewhere in the header, you'll notice that the ordering has preferred the BPP value (and other values with semantic significance) over the numeric value of the definition. I'd just prefer to keep it that way. This is also why the "next is" comments are there. -- Kind regards, Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] genirq: Add IRQ 0 to domain debug file
Hello, 2014-11-15 16:01 GMT+03:00 Jiang Liu : > On 2014/11/15 19:27, Dmitry Eremin-Solenikov wrote: >> Currently irq_domain_mapping debugfs file dumps IRQ information starting >> from IRQ 1. IRQ 0 is missing from that file. Add it to have the complete >> picture of IRQ/domains mappings. > Hi Dmitry, > For most irqdomain interfaces, they treat irq0 as invalid > interrupt. But on x86, it's possible to use irq0 for timer. It causes > may confusion when enabling irqdomain for x86. I encountered with this issue when enabling IRQ domains support for one of ARM sub-architectures. -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: rtl8712: fix coding style warning
On 11/15/2014 08:25 AM, Christian Resell wrote:
Simple style fix ("else is not generally useful after a break or return").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
This patch leads to the following build warnings:
CC [M] drivers/staging/rtl8712/rtl871x_security.o
In file included from drivers/staging/rtl8712/osdep_service.h:43:0,
from drivers/staging/rtl8712/rtl871x_security.c:45:
drivers/staging/rtl8712/rtl871x_security.c: In function ‘crc32_init’:
drivers/staging/rtl8712/basic_types.h:35:14: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
#define sint signed int
^
drivers/staging/rtl8712/rtl871x_security.c:129:2: note: in expansion of macro
‘sint’
sint i, j;
^
The previous code had braces around the code in question. Either you need to
leave those braces, or you need to move the declarations.
Please compile test your patches!
Larry
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index c653ad6..cc3a446 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -126,26 +126,24 @@ static void crc32_init(void)
{
if (bcrc32initialized == 1)
return;
- else {
- sint i, j;
- u32 c;
- u8 *p = (u8 *)&c, *p1;
- u8 k;
-
- c = 0x1234;
- for (i = 0; i < 256; ++i) {
- k = crc32_reverseBit((u8)i);
- for (c = ((u32)k) << 24, j = 8; j > 0; --j)
- c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
- (c << 1);
- p1 = (u8 *)&crc32_table[i];
- p1[0] = crc32_reverseBit(p[3]);
- p1[1] = crc32_reverseBit(p[2]);
- p1[2] = crc32_reverseBit(p[1]);
- p1[3] = crc32_reverseBit(p[0]);
- }
- bcrc32initialized = 1;
+ sint i, j;
+ u32 c;
+ u8 *p = (u8 *)&c, *p1;
+ u8 k;
+
+ c = 0x1234;
+ for (i = 0; i < 256; ++i) {
+ k = crc32_reverseBit((u8)i);
+ for (c = ((u32)k) << 24, j = 8; j > 0; --j)
+ c = c & 0x8000 ? (c << 1) ^ CRC32_POLY :
+ (c << 1);
+ p1 = (u8 *)&crc32_table[i];
+ p1[0] = crc32_reverseBit(p[3]);
+ p1[1] = crc32_reverseBit(p[2]);
+ p1[2] = crc32_reverseBit(p[1]);
+ p1[3] = crc32_reverseBit(p[0]);
}
+ bcrc32initialized = 1;
}
static u32 getcrc32(u8 *buf, u32 len)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Creating a new platform_bus inside a spi_driver
On 11/13/2014 06:52 AM, Stanimir Varbanov wrote: > Hi Grant, Arnd and Erico > > On 11/11/2014 01:07 PM, Grant Likely wrote: >> On Fri, 07 Nov 2014 18:04:35 +0100 >> , Arnd Bergmann >> wrote: >>> On Friday 07 November 2014 14:37:26 DATACOM - Érico Nunes wrote: Hello Arnd and all, On 11/07/2014 08:04 AM, Arnd Bergmann wrote: > On Thursday 06 November 2014 18:02:52 DATACOM - Érico Nunes wrote: >> The idea is that "fpga-spi" is a spi_driver which instantiates all of the >> "fpga-deviceN" as platform_devices, through the use of >> of_platform_populate(dev->of_node, NULL, NULL, dev). >> >> The visible problem we're facing with this approach is that, as the >> internal >> platform_devices have a "reg" property, of_platform_populate() eventually >> triggers an address translation which is apparently trying to translate >> the >> addresses of the internal platform_bus to addresses of the processor >> memory >> map. >> This translation is however not part of our intention, as we intend to >> have an >> internal bus with its own memory map. >> This fails when __of_translate_address() reaches the spi-master boundary >> because (as it seems to make sense) it isn't possible to translate them >> past >> that. >> A KERN_ERR rated message like >> "prom_parse: Bad cell count for /soc@f000/spi@2000/fpga@1" >> is thrown by __of_translate_address() and later it is not possible to >> obtain >> the "reg" address with platform_get_resource(). >> >> On this scenario, we have a few questions and, depending on the outcome >> of >> these, possibly a patch. >> >> 1. Is it possible to have an internal platform_bus with a different >> memory map >> as we intended? Or are platform_busses and platform_devices supposed to >> always >> be mapped on the processor memory map? > It's inconsistent. We have some code that assumes that platform devices > are always memory mapped, and some other code that breaks this assumption. By this I take that the platform subsystem could be made generic so it can be used in both ways (mapped to processor memory map or mapped to a private memory map). There seems to be no strict requirement enforcing it to be processor memory map. Is this correct? >>> >>> It could be, but I'm sure if that is a good idea or not. It might complicate >>> things elsewhere, so it would at least need careful testing and consensus >>> among a broader group of developers. >> >> I don't think it is a good idea. I would prefer to make the behaviour of >> of_platform_populate() generic so it could work for multiple bus >> types rather than reusing/abusing platform_device in this way. >> >> If the devices on the FPGA were memory mapped, it would be a different >> situation, but being behind an SPI bus where the access to those devices >> must always be mediated by the SPI controller, it would be better to >> have a separate bus type and a separate pool of drivers for those >> devices. >> Grant, could you please elaborate a little on "making the behaviour of of_platform_populate() generic so it could work for multiple bus types without reusing/abusing platform_device"? Initially we thought of having a separate bus type, but that felt such a duplication of a platform_bus that we decided to try to reuse. On the other thread line about the patch posted in my opening comment, it was suggested that we could change __of_translate_address(), for example to allow a translation end-point to be passed it. This seems like a good idea to me, however with this comment here it is still not clear to me whether this change would be likely accepted or not. > > This is exactly the same problem that we have on Qualcomm SPMI PMIC mfd > driver. We had a discussion at [1] where we tried to solve it by > IORESOURCE_REG. Unfortunately there is no conclusion yet. > > I'm glad to see that someone else have the same issue, maybe it is time > to restart the discussion. The last proposal from Grant was to implement > dev_get_localbus_address() API in drivers/base. I took the time to read through your thread and indeed a lot of this discussion is common. It is now clear that we should not be using IORESOURCE_MEM as it was assumed in the original patch, which was one of my original questions. We are still not using the mfd framework because of the need to maintain the table of "compatible" drivers in code, and this requires double maintenance of code instead of adding a new device to the dts. Nevertheless, I tested your "RFC: add function for localbus address" patch, and your solution worked right away for my case too (without mfd) by just changing my drivers to get IORESOURCE_REG instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info
Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
Josh Triplett writes:
> Currently, unprivileged processes (without CAP_SETGID) cannot call
> setgroups at all. In particular, processes with a set of supplementary
> groups cannot further drop permissions without obtaining elevated
> permissions first.
>
> Allow unprivileged processes to call setgroups with a subset of their
> current groups; only require CAP_SETGID to add a group the process does
> not currently have.
A couple of questions.
- Is there precedence in other unix flavors for this?
- What motiviates this change?
- Have you looked to see if anything might for bug compatibilty
require applications not to be able to drop supplementary groups?
> The kernel already maintains the list of supplementary group IDs in
> sorted order, and setgroups already needs to sort the new list, so this
> just requires a linear comparison of the two sorted lists.
>
> This moves the CAP_SETGID test from setgroups into set_current_groups.
>
> Tested via the following test program:
>
> #include
> #include
> #include
> #include
> #include
>
> void run_id(void)
> {
> pid_t p = fork();
> switch (p) {
> case -1:
> err(1, "fork");
> case 0:
> execl("/usr/bin/id", "id", NULL);
> err(1, "exec");
> default:
> if (waitpid(p, NULL, 0) < 0)
> err(1, "waitpid");
> }
> }
>
> int main(void)
> {
> gid_t list1[] = { 1, 2, 3, 4, 5 };
> gid_t list2[] = { 2, 3, 4 };
> run_id();
> if (setgroups(5, list1) < 0)
> err(1, "setgroups 1");
> run_id();
> if (setresgid(1, 1, 1) < 0)
> err(1, "setresgid");
> if (setresuid(1, 1, 1) < 0)
> err(1, "setresuid");
> run_id();
> if (setgroups(3, list2) < 0)
> err(1, "setgroups 2");
> run_id();
> if (setgroups(5, list1) < 0)
> err(1, "setgroups 3");
> run_id();
>
> return 0;
> }
>
> Without this patch, the test program gets EPERM from the second
> setgroups call, after dropping root privileges. With this patch, the
> test program successfully drops groups 1 and 5, but then gets EPERM from
> the third setgroups call, since that call attempts to add groups the
> process does not currently have.
>
> Signed-off-by: Josh Triplett
> ---
> kernel/groups.c | 33 ++---
> kernel/uid16.c | 2 --
> 2 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/groups.c b/kernel/groups.c
> index f0667e7..fe7367d 100644
> --- a/kernel/groups.c
> +++ b/kernel/groups.c
> @@ -153,6 +153,29 @@ int groups_search(const struct group_info *group_info,
> kgid_t grp)
> return 0;
> }
>
> +/* Compare two sorted group lists; return true if the first is a subset of
> the
> + * second.
> + */
> +static bool is_subset(const struct group_info *g1, const struct group_info
> *g2)
> +{
> + unsigned int i, j;
> +
> + for (i = 0, j = 0; i < g1->ngroups; i++) {
> + kgid_t gid1 = GROUP_AT(g1, i);
> + kgid_t gid2;
> + for (; j < g2->ngroups; j++) {
> + gid2 = GROUP_AT(g2, j);
> + if (gid_lte(gid1, gid2))
> + break;
> + }
> + if (j >= g2->ngroups || !gid_eq(gid1, gid2))
> + return false;
> + j++;
> + }
> +
> + return true;
> +}
> +
> /**
> * set_groups_sorted - Change a group subscription in a set of credentials
> * @new: The newly prepared set of credentials to alter
> @@ -189,11 +212,17 @@ int set_current_groups(struct group_info *group_info)
> {
> struct cred *new;
>
> + groups_sort(group_info);
> new = prepare_creds();
> if (!new)
> return -ENOMEM;
> + if (!ns_capable(current_user_ns(), CAP_SETGID)
> + && !is_subset(group_info, new->group_info)) {
> + abort_creds(new);
> + return -EPERM;
> + }
>
> - set_groups(new, group_info);
> + set_groups_sorted(new, group_info);
> return commit_creds(new);
> }
>
> @@ -233,8 +262,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user
> *, grouplist)
> struct group_info *group_info;
> int retval;
>
> - if (!ns_capable(current_user_ns(), CAP_SETGID))
> - return -EPERM;
> if ((unsigned)gidsetsize > NGROUPS_MAX)
> return -EINVAL;
>
> diff --git a/kernel/uid16.c b/kernel/uid16.c
> index 602e5bb..b27e167 100644
> --- a/kernel/uid16.c
> +++ b/kernel/uid16.c
> @@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t
> __user *, grouplist)
> struct group_info *group_info;
> int retval;
>
> - if (!ns_capable(current_user_ns(), CAP_SETGID))
> - return -EPERM;
> if ((unsigned)gidsetsize > NGROUPS_MAX)
> return -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
[PATCH] staging: comedi: me4000: Fixed code style issue
Fixed checkpatch.pl error message. Space prohibited before that ',' Signed-off-by: Marcus Hufvudsson --- drivers/staging/comedi/drivers/me4000.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/me4000.c b/drivers/staging/comedi/drivers/me4000.c index ae6ac49..fc67419 100644 --- a/drivers/staging/comedi/drivers/me4000.c +++ b/drivers/staging/comedi/drivers/me4000.c @@ -416,7 +416,7 @@ static void me4000_reset(struct comedi_device *dev) val |= PLX9052_CNTRL_PCI_RESET; outl(val, info->plx_regbase + PLX9052_CNTRL); val &= ~PLX9052_CNTRL_PCI_RESET; - outl(val , info->plx_regbase + PLX9052_CNTRL); + outl(val, info->plx_regbase + PLX9052_CNTRL); /* 0x8000 to the DACs means an output voltage of 0V */ for (chan = 0; chan < 4; chan++) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iio: adc: Add module device table for autoloading
On 11/11/14 19:30, Jacob Pan wrote:
> From: Aaron Lu
>
> Add the module device id table so that the driver can be automatically
> loaded once the platform device is created.
>
> Signed-off-by: Aaron Lu
> Signed-off-by: Jacob Pan
Acked-by: Jonathan Cameron
> ---
> drivers/iio/adc/axp288_adc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
> index 4800286..4a6cf43 100644
> --- a/drivers/iio/adc/axp288_adc.c
> +++ b/drivers/iio/adc/axp288_adc.c
> @@ -238,15 +238,23 @@ static int axp288_adc_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static struct platform_device_id axp288_adc_id_table[] = {
> + { .name = "axp288_adc" },
> + {},
> +};
> +
> static struct platform_driver axp288_adc_driver = {
> .probe = axp288_adc_probe,
> .remove = axp288_adc_remove,
> + .id_table = axp288_adc_id_table,
> .driver = {
> .name = "axp288_adc",
> .owner = THIS_MODULE,
> },
> };
>
> +MODULE_DEVICE_TABLE(platform, axp288_adc_id_table);
> +
> module_platform_driver(axp288_adc_driver);
>
> MODULE_AUTHOR("Jacob Pan ");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio/axp288_adc: remove THIS_MODULE owner
On 11/11/14 19:30, Jacob Pan wrote:
> This is no longer needed in that platform driver_register will do it.
>
> Signed-off-by: Jacob Pan
Acked-by: Jonathan Cameron
> ---
> drivers/iio/adc/axp288_adc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
> index 4a6cf43..08bcfb0 100644
> --- a/drivers/iio/adc/axp288_adc.c
> +++ b/drivers/iio/adc/axp288_adc.c
> @@ -249,7 +249,6 @@ static struct platform_driver axp288_adc_driver = {
> .id_table = axp288_adc_id_table,
> .driver = {
> .name = "axp288_adc",
> - .owner = THIS_MODULE,
> },
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask
On 11/11/14 14:07, Cristina Ciocan wrote:
> The direction field is set on 7 bits, thus we need to AND it with 0111 111
> mask
> in order to retrieve it, that is 0x7F, not 0xCF as it is now.
>
> Fixes: ade7ef7ba (staging:iio: Differential channel handling)
> Signed-off-by: Cristina Ciocan
Applied to the fixes togreg branch of iio,git.
Thanks,
Jonathan
> ---
> include/linux/iio/events.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/iio/events.h b/include/linux/iio/events.h
> index 8bbd7bc..03fa332 100644
> --- a/include/linux/iio/events.h
> +++ b/include/linux/iio/events.h
> @@ -72,7 +72,7 @@ struct iio_event_data {
>
> #define IIO_EVENT_CODE_EXTRACT_TYPE(mask) ((mask >> 56) & 0xFF)
>
> -#define IIO_EVENT_CODE_EXTRACT_DIR(mask) ((mask >> 48) & 0xCF)
> +#define IIO_EVENT_CODE_EXTRACT_DIR(mask) ((mask >> 48) & 0x7F)
>
> #define IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(mask) ((mask >> 32) & 0xFF)
>
> --
> 1.8.1.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] iio: accel: kxcjk-1013: Fix kxcjk10013_set_range
On 10/11/14 08:20, Daniel Baluta wrote: > Currently, we get the new GSEL bits by OR-ing the old values > with the new ones. This only works first time when the old > values are 0. > > Startup: > * GSEL0 = 0, GSEL1 = 0 > > Set range to 4G: (GSEL0 = 1, GSEL1 = 0) > * GSEL0 = 0 | 1 = 1 > * GSEL1 = 0 | 0 = 0 > * correct > > Change range to 2G: (GSEL0 = 0, GSEL1 = 0) > * GSEL0 = 1 | 0 = 1 > * GSEL1 = 0 | 0 = 0 > * wrong, GSEL0 should be 0 > > This has the nice effect that we can use the full scale range, > exported in in_accel_scale_available. > > Fixes: a735e3d7f03 (iio: accel: kxcjk-1013: Set adjustable range) > Signed-off-by: Daniel Baluta > Reviewed-by: Srinivas Pandruvada Applied to the fixes-togreg branch of iio.git and marked for stable. Thanks, > --- > drivers/iio/accel/kxcjk-1013.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c > index 98909a9..21f1279 100644 > --- a/drivers/iio/accel/kxcjk-1013.c > +++ b/drivers/iio/accel/kxcjk-1013.c > @@ -269,6 +269,8 @@ static int kxcjk1013_set_range(struct kxcjk1013_data > *data, int range_index) > return ret; > } > > + ret &= ~(KXCJK1013_REG_CTRL1_BIT_GSEL0 | > + KXCJK1013_REG_CTRL1_BIT_GSEL1); > ret |= (KXCJK1013_scale_table[range_index].gsel_0 << 3); > ret |= (KXCJK1013_scale_table[range_index].gsel_1 << 4); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: do not overwrite reserved pages counter at show_mem()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2014 01:34 PM, Rafael Aquini wrote: > Minor fixlet to perform the reserved pages counter aggregation for > each node, at show_mem() > > Signed-off-by: Rafael Aquini Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUZ4kbAAoJEM553pKExN6DtgUH/32t89g4pK7Tqgj6jSs2nzGq AHLma8dL12/JABVPBBqHxwSXCRDF6klCuQPx9v1RMiaksGf4TNNjDnEwDJ65Out4 I0ckZoc2bXRZi9i4IGZEuaAoBjN2CUL2tbgxqQLjO17nLlS+NDJuhtqQzFTE2EyO uO3wtLBPEtQa7HaBNsElzdauU/pKgT/67s0PtExCTdQAIjLDEqjSI8pT0ltPx0xk UG9l1ffFy5UhScugoSJDOfbWoZ3YjBZeWwZZ4so4u503TyNOPbucMi8lYyMDMxKd 67SyN2hWb6eKm1d4MXZZwibrbx/YGg/Ngc8kqoC1IDS7Xsl1jPgD3K5IeDMIFFs= =yglK -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] fs-ext4: Deletion of an unnecessary check before the function call "iput"
From: Markus Elfring
Date: Sat, 15 Nov 2014 19:04:06 +0100
The iput() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
fs/ext4/mballoc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8b0f9ef..e1a2521 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2712,8 +2712,7 @@ int ext4_mb_release(struct super_block *sb)
}
kfree(sbi->s_mb_offsets);
kfree(sbi->s_mb_maxs);
- if (sbi->s_buddy_cache)
- iput(sbi->s_buddy_cache);
+ iput(sbi->s_buddy_cache);
if (sbi->s_mb_stats) {
ext4_msg(sb, KERN_INFO,
"mballoc: %u blocks %u reqs (%u success)",
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Request for help: what did I do wrong with idtentry?
> I'm not > completely thrilled with what it does to double_fault, though. If we > somehow get a double fault caused by an interrupt hitting userspace > with a bad kernel_stack, then we'll end up page faulting in the > double_fault prologue. I'm not convinced that this is worth worrying > about. It would be easy enough to fix, though, even if it would > further uglify the code. If you're "cleaning up" good and working code the functionality should be the same as before. The old code handled this situation fine. So your new code should handle this too. In general yes handling all the corner cases makes code ugly. That is how the existing code got how it became. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ntfs: Deletion of unnecessary checks before the function call "iput"
From: Markus Elfring Date: Sat, 15 Nov 2014 19:35:05 +0100 The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- fs/ntfs/super.c | 21 +++-- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c index 6c3296e..8f22a47 100644 --- a/fs/ntfs/super.c +++ b/fs/ntfs/super.c @@ -2204,17 +2204,12 @@ get_ctx_vol_failed: return true; #ifdef NTFS_RW iput_usnjrnl_err_out: - if (vol->usnjrnl_j_ino) - iput(vol->usnjrnl_j_ino); - if (vol->usnjrnl_max_ino) - iput(vol->usnjrnl_max_ino); - if (vol->usnjrnl_ino) - iput(vol->usnjrnl_ino); + iput(vol->usnjrnl_j_ino); + iput(vol->usnjrnl_max_ino); + iput(vol->usnjrnl_ino); iput_quota_err_out: - if (vol->quota_q_ino) - iput(vol->quota_q_ino); - if (vol->quota_ino) - iput(vol->quota_ino); + iput(vol->quota_q_ino); + iput(vol->quota_ino); iput(vol->extend_ino); #endif /* NTFS_RW */ iput_sec_err_out: @@ -2223,8 +2218,7 @@ iput_root_err_out: iput(vol->root_ino); iput_logfile_err_out: #ifdef NTFS_RW - if (vol->logfile_ino) - iput(vol->logfile_ino); + iput(vol->logfile_ino); iput_vol_err_out: #endif /* NTFS_RW */ iput(vol->vol_ino); @@ -2254,8 +2248,7 @@ iput_mftbmp_err_out: iput(vol->mftbmp_ino); iput_mirr_err_out: #ifdef NTFS_RW - if (vol->mftmirr_ino) - iput(vol->mftmirr_ino); + iput(vol->mftmirr_ino); #endif /* NTFS_RW */ return false; } -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for help: what did I do wrong with idtentry?
On Sat, Nov 15, 2014 at 10:28 AM, Andi Kleen wrote: >> I'm not >> completely thrilled with what it does to double_fault, though. If we >> somehow get a double fault caused by an interrupt hitting userspace >> with a bad kernel_stack, then we'll end up page faulting in the >> double_fault prologue. I'm not convinced that this is worth worrying >> about. It would be easy enough to fix, though, even if it would >> further uglify the code. > > If you're "cleaning up" good and working code the functionality should > be the same as before. The old code handled this situation fine. > So your new code should handle this too. First, this failure mode should be almost impossible. We'd really have to screw up to have the kernel stack point to a bad address. (This isn't the stack *pointer* being bad -- it's the value in the TSS.) If this happens, the existing code will die (no recovery possible unlike with normal OOPSes). The new code will log a kernel-mode page fault on the DF stack (as shown on the stack trace, assuming that logic works), complain some more in do_exit, and make some sort of effort to recover, which might even work. In other words, I'd be happy to "fix" it, but I'm not entirely convinced that this change should count as a regression in the first place. If we go for the fix-it approach, we could add a fixup in sync_regs and probe the kernel_stack or we could add a paranoid=2 mode for double_fault. > > In general yes handling all the corner cases makes code ugly. > That is how the existing code got how it became. Most of those corner cases are at least in code paths that are supposed to work. This particular corner case is in a handler that's just trying to print something useful rather than silently rebooting, and it should still work well enough to print something useful. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote: > From: Brad Griffis > > TSC interrupt handler had udelay to avoid reporting of false pen-up > interrupt to user space. This patch implements workaround suggesting in > Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay > and touchscreen lag. This also improves performance of touchscreen and > eliminates sudden jump of cursor at touch release. I back ported this series onto v3.15.1 in order to try this out on a custom, beaglebone-like board. With this series, the touch is really broken. (I had fixed the pen up problem in a totally different way for a customer, and so I wanted to try out your solution.) I will try to port the board code to a more recent kernel to try your series again. With which kernel version did you test your patches? And which board? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote: > Josh Triplett writes: > > > Currently, unprivileged processes (without CAP_SETGID) cannot call > > setgroups at all. In particular, processes with a set of supplementary > > groups cannot further drop permissions without obtaining elevated > > permissions first. > > > > Allow unprivileged processes to call setgroups with a subset of their > > current groups; only require CAP_SETGID to add a group the process does > > not currently have. > > A couple of questions. > - Is there precedence in other unix flavors for this? I found a few references to now-nonexistent pages at MIT about a system with this property, but other than that no. I've also found more than a few references to people wanting this functionality. > - What motiviates this change? I have a series of patches planned to add more ways to drop elevated privileges without requiring a transition through root to do so. That would improve the ability for unprivileged users to run programs sandboxed with even *less* privileges. (Among other things, that would also allow programs running with no_new_privs to further *reduce* their privileges, which they can't currently do in this case.) > - Have you looked to see if anything might for bug compatibilty > require applications not to be able to drop supplementary groups? I haven't found any such case; that doesn't mean such a case does not exist. Feedback welcome. The only case I can think of (and I don't know of any examples of such a system): some kind of quota system that limits the members of a group to a certain amount of storage, but places no such limit on non-members. However, the idea of *holding* a credential (a supplementary group ID) giving *less* privileges, and *dropping* a credential giving *more* privileges, would completely invert normal security models. (The sane way to design such a system would be to have a privileged group for "users who can exceed the quota".) If it turns out that a real case exists that people care about, I could easily make this configurable, either at compile time or via a sysctl. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map
2014-11-14 14:16 GMT-08:00 Dmitry Torokhov :
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov
Acked-by: Florian Fainelli
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm7120-l2.c
> b/drivers/irqchip/irq-bcm7120-l2.c
> index e7c6155..8eec8e1 100644
> --- a/drivers/irqchip/irq-bcm7120-l2.c
> +++ b/drivers/irqchip/irq-bcm7120-l2.c
> @@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node
> *dn,
> unsigned int idx;
>
> parent_irq = irq_of_parse_and_map(dn, irq);
> - if (parent_irq < 0) {
> + if (!parent_irq) {
> pr_err("failed to map interrupt %d\n", irq);
> - return parent_irq;
> + return -EINVAL;
> }
>
> /* For multiple parent IRQs with multiple words, this looks like:
> --
> 2.1.0.rc2.206.gedb03e5
>
>
> --
> Dmitry
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map
2014-11-14 14:16 GMT-08:00 Dmitry Torokhov :
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov
Acked-by: Florian Fainelli
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/irqchip/irq-brcmstb-l2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-brcmstb-l2.c
> b/drivers/irqchip/irq-brcmstb-l2.c
> index 4aa653a..313c2c6 100644
> --- a/drivers/irqchip/irq-brcmstb-l2.c
> +++ b/drivers/irqchip/irq-brcmstb-l2.c
> @@ -139,9 +139,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
> writel(0x, data->base + CPU_CLEAR);
>
> data->parent_irq = irq_of_parse_and_map(np, 0);
> - if (data->parent_irq < 0) {
> + if (!data->parent_irq) {
> pr_err("failed to find parent interrupt\n");
> - ret = data->parent_irq;
> + ret = -EINVAL;
> goto out_unmap;
> }
>
> --
> 2.1.0.rc2.206.gedb03e5
>
>
> --
> Dmitry
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map
On Fri, Nov 14, 2014 at 2:16 PM, Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm7120-l2.c
> b/drivers/irqchip/irq-bcm7120-l2.c
> index e7c6155..8eec8e1 100644
> --- a/drivers/irqchip/irq-bcm7120-l2.c
> +++ b/drivers/irqchip/irq-bcm7120-l2.c
> @@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node
> *dn,
> unsigned int idx;
>
> parent_irq = irq_of_parse_and_map(dn, irq);
> - if (parent_irq < 0) {
> + if (!parent_irq) {
> pr_err("failed to map interrupt %d\n", irq);
> - return parent_irq;
> + return -EINVAL;
> }
>
> /* For multiple parent IRQs with multiple words, this looks like:
Hi Dmitry,
Thanks for the review. For this patch and for your irq-brcmstb-l2.c
patch, I'll add:
Tested-by: Kevin Cernekee
The same bug also showed up in my new irq-bcm7038-l1.c driver; it will
be fixed in the initial submission.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: media: bcm2048: fix coding style error
Simple style fix (checkpatch.pl: "space prohibited before that ','").
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { "bcm2048" , 0 },
+ { "bcm2048", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Cocci] [PATCH 1/1] ntfs: Deletion of unnecessary checks before the function call "iput"
On Sat, 15 Nov 2014, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 15 Nov 2014 19:35:05 +0100 > > The iput() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > fs/ntfs/super.c | 21 +++-- > 1 file changed, 7 insertions(+), 14 deletions(-) > > diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c > index 6c3296e..8f22a47 100644 > --- a/fs/ntfs/super.c > +++ b/fs/ntfs/super.c > @@ -2204,17 +2204,12 @@ get_ctx_vol_failed: > return true; > #ifdef NTFS_RW > iput_usnjrnl_err_out: I don't have time to look at the code now, but since there is an exit label here, have you checked whether you could improve the gotos in these cases? julia > - if (vol->usnjrnl_j_ino) > - iput(vol->usnjrnl_j_ino); > - if (vol->usnjrnl_max_ino) > - iput(vol->usnjrnl_max_ino); > - if (vol->usnjrnl_ino) > - iput(vol->usnjrnl_ino); > + iput(vol->usnjrnl_j_ino); > + iput(vol->usnjrnl_max_ino); > + iput(vol->usnjrnl_ino); > iput_quota_err_out: > - if (vol->quota_q_ino) > - iput(vol->quota_q_ino); > - if (vol->quota_ino) > - iput(vol->quota_ino); > + iput(vol->quota_q_ino); > + iput(vol->quota_ino); > iput(vol->extend_ino); > #endif /* NTFS_RW */ > iput_sec_err_out: > @@ -2223,8 +2218,7 @@ iput_root_err_out: > iput(vol->root_ino); > iput_logfile_err_out: > #ifdef NTFS_RW > - if (vol->logfile_ino) > - iput(vol->logfile_ino); > + iput(vol->logfile_ino); > iput_vol_err_out: > #endif /* NTFS_RW */ > iput(vol->vol_ino); > @@ -2254,8 +2248,7 @@ iput_mftbmp_err_out: > iput(vol->mftbmp_ino); > iput_mirr_err_out: > #ifdef NTFS_RW > - if (vol->mftmirr_ino) > - iput(vol->mftmirr_ino); > + iput(vol->mftmirr_ino); > #endif /* NTFS_RW */ > return false; > } > -- > 2.1.3 > > > ___ > Cocci mailing list > co...@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: t7l66xb: prepare/unprepare clocks
Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unrepapre(). Signed-off-by: Dmitry Eremin-Solenikov --- drivers/mfd/t7l66xb.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c index 9e04a74..439d905 100644 --- a/drivers/mfd/t7l66xb.c +++ b/drivers/mfd/t7l66xb.c @@ -87,7 +87,7 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc) unsigned long flags; u8 dev_ctl; - clk_enable(t7l66xb->clk32k); + clk_prepare_enable(t7l66xb->clk32k); spin_lock_irqsave(&t7l66xb->lock, flags); @@ -118,7 +118,7 @@ static int t7l66xb_mmc_disable(struct platform_device *mmc) spin_unlock_irqrestore(&t7l66xb->lock, flags); - clk_disable(t7l66xb->clk32k); + clk_disable_unprepare(t7l66xb->clk32k); return 0; } @@ -285,7 +285,7 @@ static int t7l66xb_suspend(struct platform_device *dev, pm_message_t state) if (pdata && pdata->suspend) pdata->suspend(dev); - clk_disable(t7l66xb->clk48m); + clk_disable_unprepare(t7l66xb->clk48m); return 0; } @@ -295,7 +295,7 @@ static int t7l66xb_resume(struct platform_device *dev) struct t7l66xb *t7l66xb = platform_get_drvdata(dev); struct t7l66xb_platform_data *pdata = dev_get_platdata(&dev->dev); - clk_enable(t7l66xb->clk48m); + clk_prepare_enable(t7l66xb->clk48m); if (pdata && pdata->resume) pdata->resume(dev); @@ -369,7 +369,7 @@ static int t7l66xb_probe(struct platform_device *dev) goto err_ioremap; } - clk_enable(t7l66xb->clk48m); + clk_prepare_enable(t7l66xb->clk48m); if (pdata && pdata->enable) pdata->enable(dev); @@ -414,9 +414,9 @@ static int t7l66xb_remove(struct platform_device *dev) int ret; ret = pdata->disable(dev); - clk_disable(t7l66xb->clk48m); + clk_disable_unprepare(t7l66xb->clk48m); clk_put(t7l66xb->clk48m); - clk_disable(t7l66xb->clk32k); + clk_disable_unprepare(t7l66xb->clk32k); clk_put(t7l66xb->clk32k); t7l66xb_detach_irq(dev); iounmap(t7l66xb->scr); -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mfd: tc6387xb: prepare/unprepare clocks
Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unrepapre(). Signed-off-by: Dmitry Eremin-Solenikov --- drivers/mfd/tc6387xb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/tc6387xb.c b/drivers/mfd/tc6387xb.c index e71f880..85fab37 100644 --- a/drivers/mfd/tc6387xb.c +++ b/drivers/mfd/tc6387xb.c @@ -52,7 +52,7 @@ static int tc6387xb_suspend(struct platform_device *dev, pm_message_t state) if (pdata && pdata->suspend) pdata->suspend(dev); - clk_disable(tc6387xb->clk32k); + clk_disable_unprepare(tc6387xb->clk32k); return 0; } @@ -62,7 +62,7 @@ static int tc6387xb_resume(struct platform_device *dev) struct tc6387xb *tc6387xb = platform_get_drvdata(dev); struct tc6387xb_platform_data *pdata = dev_get_platdata(&dev->dev); - clk_enable(tc6387xb->clk32k); + clk_prepare_enable(tc6387xb->clk32k); if (pdata && pdata->resume) pdata->resume(dev); @@ -100,7 +100,7 @@ static int tc6387xb_mmc_enable(struct platform_device *mmc) struct platform_device *dev = to_platform_device(mmc->dev.parent); struct tc6387xb *tc6387xb = platform_get_drvdata(dev); - clk_enable(tc6387xb->clk32k); + clk_prepare_enable(tc6387xb->clk32k); tmio_core_mmc_enable(tc6387xb->scr + 0x200, 0, tc6387xb_mmc_resources[0].start & 0xfffe); @@ -113,7 +113,7 @@ static int tc6387xb_mmc_disable(struct platform_device *mmc) struct platform_device *dev = to_platform_device(mmc->dev.parent); struct tc6387xb *tc6387xb = platform_get_drvdata(dev); - clk_disable(tc6387xb->clk32k); + clk_disable_unprepare(tc6387xb->clk32k); return 0; } @@ -214,7 +214,7 @@ static int tc6387xb_remove(struct platform_device *dev) mfd_remove_devices(&dev->dev); iounmap(tc6387xb->scr); release_resource(&tc6387xb->rscr); - clk_disable(tc6387xb->clk32k); + clk_disable_unprepare(tc6387xb->clk32k); clk_put(tc6387xb->clk32k); kfree(tc6387xb); -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] fs-fat: Less function calls in fat_fill_super() after error detection
From: Markus Elfring
Date: Sat, 15 Nov 2014 20:55:23 +0100
The iput() function was called in an inefficient way by the implementation
of the fat_fill_super() function in case of an allocation failure.
The corresponding source code was improved by deletion of two unnecessary
null pointer checks and a few adjustments for jump labels.
Signed-off-by: Markus Elfring
---
fs/fat/inode.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 756aead..138ab9a 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void *data,
int silent, int isvfat,
fsinfo_inode = new_inode(sb);
if (!fsinfo_inode)
- goto out_fail;
+ goto fsinfo_inode_failure;
fsinfo_inode->i_ino = MSDOS_FSINFO_INO;
sbi->fsinfo_inode = fsinfo_inode;
insert_inode_hash(fsinfo_inode);
root_inode = new_inode(sb);
if (!root_inode)
- goto out_fail;
+ goto other_failure;
root_inode->i_ino = MSDOS_ROOT_INO;
root_inode->i_version = 1;
error = fat_read_root(root_inode);
if (error < 0) {
iput(root_inode);
- goto out_fail;
+ goto other_failure;
}
error = -ENOMEM;
insert_inode_hash(root_inode);
@@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data,
int silent, int isvfat,
sb->s_root = d_make_root(root_inode);
if (!sb->s_root) {
fat_msg(sb, KERN_ERR, "get root inode failed");
- goto out_fail;
+ goto other_failure;
}
if (sbi->options.discard) {
@@ -1756,11 +1756,13 @@ out_invalid:
if (!silent)
fat_msg(sb, KERN_INFO, "Can't find a valid FAT filesystem");
+other_failure:
+ iput(fsinfo_inode);
+
+fsinfo_inode_failure:
+ iput(fat_inode);
+
out_fail:
- if (fsinfo_inode)
- iput(fsinfo_inode);
- if (fat_inode)
- iput(fat_inode);
unload_nls(sbi->nls_io);
unload_nls(sbi->nls_disk);
if (sbi->options.iocharset != fat_default_iocharset)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
On Sat, Nov 15, 2014 at 11:29 AM, Josh Triplett wrote: > On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote: >> Josh Triplett writes: >> >> > Currently, unprivileged processes (without CAP_SETGID) cannot call >> > setgroups at all. In particular, processes with a set of supplementary >> > groups cannot further drop permissions without obtaining elevated >> > permissions first. >> > >> > Allow unprivileged processes to call setgroups with a subset of their >> > current groups; only require CAP_SETGID to add a group the process does >> > not currently have. >> >> A couple of questions. >> - Is there precedence in other unix flavors for this? > > I found a few references to now-nonexistent pages at MIT about a system > with this property, but other than that no. > > I've also found more than a few references to people wanting this > functionality. > >> - What motiviates this change? > > I have a series of patches planned to add more ways to drop elevated > privileges without requiring a transition through root to do so. That > would improve the ability for unprivileged users to run programs > sandboxed with even *less* privileges. (Among other things, that would > also allow programs running with no_new_privs to further *reduce* their > privileges, which they can't currently do in this case.) > >> - Have you looked to see if anything might for bug compatibilty >> require applications not to be able to drop supplementary groups? > > I haven't found any such case; that doesn't mean such a case does not > exist. Feedback welcome. > > The only case I can think of (and I don't know of any examples of such a > system): some kind of quota system that limits the members of a group to > a certain amount of storage, but places no such limit on non-members. > > However, the idea of *holding* a credential (a supplementary group ID) > giving *less* privileges, and *dropping* a credential giving *more* > privileges, would completely invert normal security models. (The sane > way to design such a system would be to have a privileged group for > "users who can exceed the quota".) Agreed. And, if you want to bypass quotas by dropping a supplementary group, you already can by unsharing your user namespace. However, sudoers seems to allow negative group matches. So maybe allowing this only with no_new_privs already set would make sense. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: media: bcm2048: fix coding style error
On 11/15, Christian Resell wrote:
> Simple style fix (checkpatch.pl: "space prohibited before that ','").
> For the eudyptula challenge (http://eudyptula-challenge.org/).
Nice, however we do not need the information about the 'eudyptula
challenge' in the commit message.
If you want to include extra information please do it after the '---'
line (just below the signed-off). You will find more details in the
SubmittingPatches (chapter 15) of the kernel documentation.
Thanks,
Konrad
> Signed-off-by: Christian F. Resell
> ---
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 2bba370..bdc6854 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> i2c_client *client)
> * bcm2048_i2c_driver - i2c driver interface
> */
> static const struct i2c_device_id bcm2048_id[] = {
> - { "bcm2048" , 0 },
> + { "bcm2048", 0 },
> { },
> };
> MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] fs-fat: Less function calls in fat_fill_super() after error detection
On Sat, 15 Nov 2014, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 15 Nov 2014 20:55:23 +0100
>
> The iput() function was called in an inefficient way by the implementation
> of the fat_fill_super() function in case of an allocation failure.
> The corresponding source code was improved by deletion of two unnecessary
> null pointer checks and a few adjustments for jump labels.
>
> Signed-off-by: Markus Elfring
> ---
> fs/fat/inode.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index 756aead..138ab9a 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void
> *data, int silent, int isvfat,
>
> fsinfo_inode = new_inode(sb);
> if (!fsinfo_inode)
> - goto out_fail;
> + goto fsinfo_inode_failure;
> fsinfo_inode->i_ino = MSDOS_FSINFO_INO;
> sbi->fsinfo_inode = fsinfo_inode;
> insert_inode_hash(fsinfo_inode);
>
> root_inode = new_inode(sb);
> if (!root_inode)
> - goto out_fail;
> + goto other_failure;
Other_failure is not such a good name. The one above is better.
julia
> root_inode->i_ino = MSDOS_ROOT_INO;
> root_inode->i_version = 1;
> error = fat_read_root(root_inode);
> if (error < 0) {
> iput(root_inode);
> - goto out_fail;
> + goto other_failure;
> }
> error = -ENOMEM;
> insert_inode_hash(root_inode);
> @@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data,
> int silent, int isvfat,
> sb->s_root = d_make_root(root_inode);
> if (!sb->s_root) {
> fat_msg(sb, KERN_ERR, "get root inode failed");
> - goto out_fail;
> + goto other_failure;
> }
>
> if (sbi->options.discard) {
> @@ -1756,11 +1756,13 @@ out_invalid:
> if (!silent)
> fat_msg(sb, KERN_INFO, "Can't find a valid FAT filesystem");
>
> +other_failure:
> + iput(fsinfo_inode);
> +
> +fsinfo_inode_failure:
> + iput(fat_inode);
> +
> out_fail:
> - if (fsinfo_inode)
> - iput(fsinfo_inode);
> - if (fat_inode)
> - iput(fat_inode);
> unload_nls(sbi->nls_io);
> unload_nls(sbi->nls_disk);
> if (sbi->options.iocharset != fat_default_iocharset)
> --
> 2.1.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
On Sat, Nov 15, 2014 at 12:06:20PM -0800, Andy Lutomirski wrote: > On Sat, Nov 15, 2014 at 11:29 AM, Josh Triplett wrote: > > On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote: > >> Josh Triplett writes: > >> > >> > Currently, unprivileged processes (without CAP_SETGID) cannot call > >> > setgroups at all. In particular, processes with a set of supplementary > >> > groups cannot further drop permissions without obtaining elevated > >> > permissions first. > >> > > >> > Allow unprivileged processes to call setgroups with a subset of their > >> > current groups; only require CAP_SETGID to add a group the process does > >> > not currently have. > >> > >> A couple of questions. > >> - Is there precedence in other unix flavors for this? > > > > I found a few references to now-nonexistent pages at MIT about a system > > with this property, but other than that no. > > > > I've also found more than a few references to people wanting this > > functionality. > > > >> - What motiviates this change? > > > > I have a series of patches planned to add more ways to drop elevated > > privileges without requiring a transition through root to do so. That > > would improve the ability for unprivileged users to run programs > > sandboxed with even *less* privileges. (Among other things, that would > > also allow programs running with no_new_privs to further *reduce* their > > privileges, which they can't currently do in this case.) > > > >> - Have you looked to see if anything might for bug compatibilty > >> require applications not to be able to drop supplementary groups? > > > > I haven't found any such case; that doesn't mean such a case does not > > exist. Feedback welcome. > > > > The only case I can think of (and I don't know of any examples of such a > > system): some kind of quota system that limits the members of a group to > > a certain amount of storage, but places no such limit on non-members. > > > > However, the idea of *holding* a credential (a supplementary group ID) > > giving *less* privileges, and *dropping* a credential giving *more* > > privileges, would completely invert normal security models. (The sane > > way to design such a system would be to have a privileged group for > > "users who can exceed the quota".) > > Agreed. And, if you want to bypass quotas by dropping a supplementary > group, you already can by unsharing your user namespace. Good point! Given that a process can run with a new user namespace and no other namespaces, and then drop all its other privileges that way, the ability to drop privileges without using a user namespace seems completely harmless, with one exception that you noted: > However, sudoers seems to allow negative group matches. So maybe > allowing this only with no_new_privs already set would make sense. Sigh, bad sudo. Sure, restricting this to no_new_privs only seems fine. I'll do that in v2, and document that in the manpage. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: rockchip: enable PWM on Radxa Rock
Am Freitag, 14. November 2014, 16:32:25 schrieb Julien CHAUVEAU: > This enables user space access to the 3 PWM available on the Radxa Rock > headers. > > Signed-off-by: Julien CHAUVEAU added to my v3.19-armsoc/dts branch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] lib/mpi: Deletion of unnecessary checks before the function call "mpi_free_limb_space"
From: Markus Elfring
Date: Sat, 15 Nov 2014 21:33:26 +0100
The mpi_free_limb_space() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
lib/mpi/mpi-pow.c | 15 +--
lib/mpi/mpih-mul.c | 21 +++--
2 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/lib/mpi/mpi-pow.c b/lib/mpi/mpi-pow.c
index 5464c87..c28882f 100644
--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -308,16 +308,11 @@ leave:
enomem:
if (assign_rp)
mpi_assign_limb_space(res, rp, size);
- if (mp_marker)
- mpi_free_limb_space(mp_marker);
- if (bp_marker)
- mpi_free_limb_space(bp_marker);
- if (ep_marker)
- mpi_free_limb_space(ep_marker);
- if (xp_marker)
- mpi_free_limb_space(xp_marker);
- if (tspace)
- mpi_free_limb_space(tspace);
+ mpi_free_limb_space(mp_marker);
+ mpi_free_limb_space(bp_marker);
+ mpi_free_limb_space(ep_marker);
+ mpi_free_limb_space(xp_marker);
+ mpi_free_limb_space(tspace);
return rc;
}
EXPORT_SYMBOL_GPL(mpi_powm);
diff --git a/lib/mpi/mpih-mul.c b/lib/mpi/mpih-mul.c
index 7c84171..ff021cc 100644
--- a/lib/mpi/mpih-mul.c
+++ b/lib/mpi/mpih-mul.c
@@ -339,8 +339,7 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
mpi_limb_t cy;
if (!ctx->tspace || ctx->tspace_size < vsize) {
- if (ctx->tspace)
- mpi_free_limb_space(ctx->tspace);
+ mpi_free_limb_space(ctx->tspace);
ctx->tspace = mpi_alloc_limb_space(2 * vsize);
if (!ctx->tspace)
return -ENOMEM;
@@ -354,12 +353,10 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
usize -= vsize;
if (usize >= vsize) {
if (!ctx->tp || ctx->tp_size < vsize) {
- if (ctx->tp)
- mpi_free_limb_space(ctx->tp);
+ mpi_free_limb_space(ctx->tp);
ctx->tp = mpi_alloc_limb_space(2 * vsize);
if (!ctx->tp) {
- if (ctx->tspace)
- mpi_free_limb_space(ctx->tspace);
+ mpi_free_limb_space(ctx->tspace);
ctx->tspace = NULL;
return -ENOMEM;
}
@@ -407,16 +404,12 @@ void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx
*ctx)
{
struct karatsuba_ctx *ctx2;
- if (ctx->tp)
- mpi_free_limb_space(ctx->tp);
- if (ctx->tspace)
- mpi_free_limb_space(ctx->tspace);
+ mpi_free_limb_space(ctx->tp);
+ mpi_free_limb_space(ctx->tspace);
for (ctx = ctx->next; ctx; ctx = ctx2) {
ctx2 = ctx->next;
- if (ctx->tp)
- mpi_free_limb_space(ctx->tp);
- if (ctx->tspace)
- mpi_free_limb_space(ctx->tspace);
+ mpi_free_limb_space(ctx->tp);
+ mpi_free_limb_space(ctx->tspace);
kfree(ctx);
}
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NFC: st21nfca: fix error handling of irq_of_parse_and_map
Hi Dmitry,
Thank you for your feedback.
A patch got already pushed earlier this month:
https://lists.01.org/pipermail/linux-nfc/2014-November/003123.html
The i2c-core is already running the i2c_of_parse_and_map function when
registering the slave device when using dts. This step got removed for
this reason.
However, i will take into account your second point in order to report
devm_gpio_request_one instead of -ENODEV in a future patchset.
Best Regards
Christophe
On Fri, 14 Nov 2014 14:32:24 -0800
Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Also report error returned by devm_gpio_request_one instead of
> clobbering it with -ENODEV.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/nfc/st21nfca/i2c.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
> index 0ea756b..6d6d282 100644
> --- a/drivers/nfc/st21nfca/i2c.c
> +++ b/drivers/nfc/st21nfca/i2c.c
> @@ -531,20 +531,19 @@ static int
> st21nfca_hci_i2c_of_request_resources(struct i2c_client *client)
> "clf_enable"); if (r) {
> nfc_err(&client->dev, "Failed to request enable
> pin\n");
> - return -ENODEV;
> + return r;
> }
>
> phy->gpio_ena = gpio;
>
> /* IRQ */
> - r = irq_of_parse_and_map(pp, 0);
> - if (r < 0) {
> - nfc_err(&client->dev, "Unable to get irq, error:
> %d\n", r);
> - return r;
> + client->irq = irq_of_parse_and_map(pp, 0);
> + if (!client->irq) {
> + nfc_err(&client->dev, "Unable to get irq\n");
> + return -EINVAL;
> }
>
> phy->irq_polarity = irq_get_trigger_type(r);
> - client->irq = r;
>
> return 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] NFC: st21nfcb: fix error handling of irq_of_parse_and_map
Hi Dmitry,
Thank you for your feedback.
A patch got already pushed earlier this month:
https://lists.01.org/pipermail/linux-nfc/2014-November/003126.html
The i2c-core is already running the i2c_of_parse_and_map function when
registering the slave device when using dts. This step got removed for
this reason.
However, i will take into account your second point in order to report
devm_gpio_request_one instead of -ENODEV in a future patchset.
Best Regards
Christophe
On Fri, 14 Nov 2014 14:35:27 -0800
Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Also report error returned by devm_gpio_request_one instead of
> clobbering it with -ENODEV.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/nfc/st21nfcb/i2c.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/nfc/st21nfcb/i2c.c b/drivers/nfc/st21nfcb/i2c.c
> index c5d2427..abe73ec 100644
> --- a/drivers/nfc/st21nfcb/i2c.c
> +++ b/drivers/nfc/st21nfcb/i2c.c
> @@ -258,19 +258,18 @@ static int
> st21nfcb_nci_i2c_of_request_resources(struct i2c_client *client)
> GPIOF_OUT_INIT_HIGH, "clf_reset"); if (r) {
> nfc_err(&client->dev, "Failed to request reset
> pin\n");
> - return -ENODEV;
> + return r;
> }
> phy->gpio_reset = gpio;
>
> /* IRQ */
> - r = irq_of_parse_and_map(pp, 0);
> - if (r < 0) {
> - nfc_err(&client->dev, "Unable to get irq, error:
> %d\n", r);
> - return r;
> + client->irq = irq_of_parse_and_map(pp, 0);
> + if (!client->irq) {
> + nfc_err(&client->dev, "Unable to get irq\n");
> + return -EINVAL;
> }
>
> phy->irq_polarity = irq_get_trigger_type(r);
> - client->irq = r;
>
> return 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] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
On Fri 2014-11-14 23:41:15, Rafael J. Wysocki wrote: > On Friday, November 14, 2014 09:36:17 AM Kevin Hilman wrote: > > Geert Uytterhoeven writes: > > > > > Hi Kevin, > > > > > > On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman wrote: > > >> It makes little sense to use generic power domains without runtime PM. > > > > > > Does it? > > > It still powers down the PM domains on system suspend (at least on my > > > boards ;-) > > > > Sure, but your devices are also using runtime PM, so I'm not sure how > > does that change my statement above? > > Questions here are (1) how many users will actually want to disable PM_RUNTIME > for systems using genpd (my sort of educated guess is "none") and Well. Developers sometimes want to disable power management so that they don't have to debug it just now... disabling PM_RUNTIME is a way to do that. OTOH making code more complex to make new board bring-up easier may not be good idea.. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: media: bcm2048: fix coding style error
On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> On 11/15, Christian Resell wrote:
> > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > For the eudyptula challenge (http://eudyptula-challenge.org/).
>
> Nice, however we do not need the information about the 'eudyptula
> challenge' in the commit message.
>
> If you want to include extra information please do it after the '---'
> line (just below the signed-off). You will find more details in the
> SubmittingPatches (chapter 15) of the kernel documentation.
Greg is staging tree maintainer... And if single extra space is all
you can fix in the driver, perhaps it is not worth the patch?
Pavel
> Thanks,
> Konrad
>
> > Signed-off-by: Christian F. Resell
> > ---
> > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > index 2bba370..bdc6854 100644
> > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> > i2c_client *client)
> > * bcm2048_i2c_driver - i2c driver interface
> > */
> > static const struct i2c_device_id bcm2048_id[] = {
> > - { "bcm2048" , 0 },
> > + { "bcm2048", 0 },
> > { },
> > };
> > MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > ___
> > devel mailing list
> > de...@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCHv2 1/2] groups: Factor out a function to set a pre-sorted group list
This way, functions that already need to sort the group list need not do
so twice.
The new set_groups_sorted is intentionally not exported.
Signed-off-by: Josh Triplett
---
kernel/groups.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f..f0667e7 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -154,16 +154,26 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
}
/**
+ * set_groups_sorted - Change a group subscription in a set of credentials
+ * @new: The newly prepared set of credentials to alter
+ * @group_info: The group list to install; must be sorted
+ */
+static void set_groups_sorted(struct cred *new, struct group_info *group_info)
+{
+ put_group_info(new->group_info);
+ get_group_info(group_info);
+ new->group_info = group_info;
+}
+
+/**
* set_groups - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
* @group_info: The group list to install
*/
void set_groups(struct cred *new, struct group_info *group_info)
{
- put_group_info(new->group_info);
groups_sort(group_info);
- get_group_info(group_info);
- new->group_info = group_info;
+ set_groups_sorted(new, group_info);
}
EXPORT_SYMBOL(set_groups);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
Currently, unprivileged processes (without CAP_SETGID) cannot call
setgroups at all. In particular, processes with a set of supplementary
groups cannot further drop permissions without obtaining elevated
permissions first.
Allow unprivileged processes to call setgroups with a subset of their
current groups; only require CAP_SETGID to add a group the process does
not currently have.
Since some privileged programs (such as sudo) allow tests for
non-membership in a group, require no_new_privs to drop group
privileges.
The kernel already maintains the list of supplementary group IDs in
sorted order, and setgroups already needs to sort the new list, so this
just requires a linear comparison of the two sorted lists.
This moves the CAP_SETGID test from setgroups into set_current_groups.
Tested via the following test program:
void run_id(void)
{
pid_t p = fork();
switch (p) {
case -1:
err(1, "fork");
case 0:
execl("/usr/bin/id", "id", NULL);
err(1, "exec");
default:
if (waitpid(p, NULL, 0) < 0)
err(1, "waitpid");
}
}
int main(void)
{
gid_t list1[] = { 1, 2, 3, 4, 5 };
gid_t list2[] = { 2, 3, 4 };
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 1");
run_id();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
run_id();
if (setgroups(3, list2) < 0)
err(1, "setgroups 2");
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 3");
run_id();
return 0;
}
Without this patch, the test program gets EPERM from the second
setgroups call, after dropping root privileges. With this patch, the
test program successfully drops groups 1 and 5, but then gets EPERM from
the third setgroups call, since that call attempts to add groups the
process does not currently have.
Signed-off-by: Josh Triplett
---
v2: Require no_new_privs.
kernel/groups.c | 34 +++---
kernel/uid16.c | 2 --
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index f0667e7..f7fb8dd 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -153,6 +153,29 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
return 0;
}
+/* Compare two sorted group lists; return true if the first is a subset of the
+ * second.
+ */
+static bool is_subset(const struct group_info *g1, const struct group_info *g2)
+{
+ unsigned int i, j;
+
+ for (i = 0, j = 0; i < g1->ngroups; i++) {
+ kgid_t gid1 = GROUP_AT(g1, i);
+ kgid_t gid2;
+ for (; j < g2->ngroups; j++) {
+ gid2 = GROUP_AT(g2, j);
+ if (gid_lte(gid1, gid2))
+ break;
+ }
+ if (j >= g2->ngroups || !gid_eq(gid1, gid2))
+ return false;
+ j++;
+ }
+
+ return true;
+}
+
/**
* set_groups_sorted - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
@@ -189,11 +212,18 @@ int set_current_groups(struct group_info *group_info)
{
struct cred *new;
+ groups_sort(group_info);
new = prepare_creds();
if (!new)
return -ENOMEM;
+ if (!(ns_capable(current_user_ns(), CAP_SETGID)
+ || (task_no_new_privs(current)
+ && is_subset(group_info, new->group_info {
+ abort_creds(new);
+ return -EPERM;
+ }
- set_groups(new, group_info);
+ set_groups_sorted(new, group_info);
return commit_creds(new);
}
@@ -233,8 +263,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *,
grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bb..b27e167 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t
__user *, grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 manpages] getgroups.2: Document unprivileged setgroups calls
Signed-off-by: Josh Triplett --- v2: Document requirement for no_new_privs. (If this doesn't end up going into 3.18, the version number in the patch will need updating.) man2/getgroups.2 | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/man2/getgroups.2 b/man2/getgroups.2 index 373c204..3f3d330 100644 --- a/man2/getgroups.2 +++ b/man2/getgroups.2 @@ -81,9 +81,11 @@ to be used in a further call to .PP .BR setgroups () sets the supplementary group IDs for the calling process. -Appropriate privileges (Linux: the +As of Linux 3.18, any process that has enabled PR_SET_NO_NEW_PRIVS may drop +supplementary groups, but may not add new groups. Adding groups, or making any +change at all without no_new_privs enabled, requires the .B CAP_SETGID -capability) are required. +capability. The .I size argument specifies the number of supplementary group IDs -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead
Alexander Duyck : > On 11/13/2014 01:30 PM, Francois Romieu wrote: > > Alexander Duyck : > > [...] > >> In addition the r8169 uses a rmb() however I believe it is placed > >> incorrectly > >> as I assume it supposed to be ordering descriptor reads after the check for > >> ownership. > > Not exactly. It's a barrier against compiler optimization from 2004. > > It should not matter. > > Okay. Do you recall the kind of problem it was you were seeing ? Mildly, I had to grep the local archives. The relevant code used to be included in the irq handler at that time (napi support for this driver took place in may 2004). One did not want a runaway loop in the Tx reaper. Compiler optimization was suggested by Manfred Spraul in the thread below: http://marc.info/?l=linux-kernel&m=108096868119004 > The origin of the rmb() for the Intel drivers was a PowerPC issue in > which it was fetching the length of a buffer before it checked the DD > bit (equivalent of DescOwn). I'm wondering if the issue you were seeing > was something similar where it had reordered reads in the descriptor to > cause that type of result. The problem was only reported on Intel 32 bit + slackware + gcc 3.2.3. Adam Nielsen - Cc: added - did not return for this bug. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Nov 14
On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote: > Hi all, > > Changes since 20141113: > > New tree: overlayfs > > The idle tree gained a conflict against Linus' tree. > > The scsi tree gained a conflict against the usb tree. > > Non-merge commits (relative to Linus' tree): 6264 > 6509 files changed, 209171 insertions(+), 167101 deletions(-) > I bisected the x86-nosmp qemu runtime failure I have seen for the last few days. Here is the result: bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb Author: Jiang Liu Date: Mon Oct 27 16:12:06 2014 +0800 x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC Detailed log: git bisect start 'HEAD' 'v3.18-rc4' # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 'sound-asoc/for-next' git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44 # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 'usb-serial/usb-next' git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 'kvm/linux-next' git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0 # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 'audit/next' git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4 # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso' git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent' git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot' git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7 # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect __clear_irq_vector() with vector_lock git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22 # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to access irq_cfg data structure associated with IRQ git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494 # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ related code from io_apic.c into htirq.c git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065 # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ initialization routines from io_apic.c into vector.c git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC I'll be happy to provide the configuration if needed. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ipc/mqueue.c: Drag unneeded code out of locks
On Sat, 2014-11-15 at 04:44 +, Steven Stewart-Gallus wrote:
> > What's the benefit here? Seems very risky at very little gain.
> >
> > The juice ain't worth the squeeze. NAK
>
> Hello,
>
> It is fair to argue that these changes are too tiny to be very
> meaningful for performance but the other goal of this patch was also
> to make the code look cleaner and easier for me and other people to
> understand. I hope that is a reasonable desire.
I don't see how on earth you consider your patch makes things easier to
understand. For instance, adding local variables from structures passed
to a function does *not* make things more clearer:
+ bool too_many_open_files;
+ long msgqueue_lim;
+ unsigned long u_bytes;
+
+ msgqueue_lim = rlimit(RLIMIT_MSGQUEUE);
+
+ spin_lock(&mq_lock);
+
+ u_bytes = u->mq_bytes;
+ too_many_open_files = u_bytes + mq_bytes < u_bytes ||
+ u_bytes + mq_bytes > msgqueue_lim;
+ if (!too_many_open_files)
Plus you add context specific regions within the function (code around
{ }), ugly and something we've been removing!
In fact it makes it *harder* to read: Now you have to keep in mind where
each variable came from, ie: u_bytes.
> It is not fair to argue that these changes are risky.
Oh no? Andrew already found issues with the patch. But you claim there
is no risk. But hey, not getting the patch right the first time is fine,
except that the patch (i) has no tangible effects on performance, (ii)
as a cleanup, it does not make it any easier to read, (iii) can
potentially introduce bugs (yes, extra risk in subtleties when changing
critical regions and goto statements... we have had similar regressions
in ipc in the past).
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: media: bcm2048: fix coding style error
On Sat, Nov 15, 2014 at 09:59:34PM +0100, Pavel Machek wrote: > On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote: > > On 11/15, Christian Resell wrote: > > > Simple style fix (checkpatch.pl: "space prohibited before that ','"). > > > For the eudyptula challenge (http://eudyptula-challenge.org/). > > > > Nice, however we do not need the information about the 'eudyptula > > challenge' in the commit message. > > > > If you want to include extra information please do it after the '---' > > line (just below the signed-off). You will find more details in the > > SubmittingPatches (chapter 15) of the kernel documentation. > > Greg is staging tree maintainer... And if single extra space is all > you can fix in the driver, perhaps it is not worth the patch? I am not the maintainer of drivers/staging/media/ please look at MAINTAINERS before you make statements like that. And yes, one space fixes is just fine, that's why the code is in staging. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
On Fri, 14 Nov 2014, Sean O. Stalley wrote: > To summarize the spec: > MA USB groups a host & connected devices into MA service sets (MSS). > The architectural limit is 254 MA devices per MSS. > > If the host needs to connect more devices than that, It can start a > new MSS and connect to 254 more MA devices. > > > > Is supporting up to 254 devices on one machine sufficient? It's probably more than enough. > Would it make sense (and does the usb stack support) having 254 root > ports on one host controller? If so, we could make our host > controller instance have 254 ports. I'm guessing the hub driver may have > a problem with this (especially for superspeed). The USB stack is likely to have problems if there are more than 31 ports on any hub. > If that doesn't make sense (or isn't supported), we can have 1 host > controller instance per MA device. Would that be preferred? It doesn't make much difference. Whatever you think will be easier to support. You might check and see how usbip does it. > > Also, I noticed that your patch adds a new bus type for these MA host > > controllers. It really seems like overkill to have a whole new bus > > type if there's only going to be one device on it. > > The bus was added when we were quickly trying to replace the platform > device code. It's probably not the right thing to do. > > I'm still not sure why we can't make our hcd a platform device, > especially since dummy_hcd & the usbip's hcd are both platform devices. A platform device is the right way to go. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: media: bcm2048: fix coding style error
On 11/15, Pavel Machek wrote:
> On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> > On 11/15, Christian Resell wrote:
> > > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > > For the eudyptula challenge (http://eudyptula-challenge.org/).
> >
> > Nice, however we do not need the information about the 'eudyptula
> > challenge' in the commit message.
> >
> > If you want to include extra information please do it after the '---'
> > line (just below the signed-off). You will find more details in the
> > SubmittingPatches (chapter 15) of the kernel documentation.
>
> Greg is staging tree maintainer... And if single extra space is all
> you can fix in the driver, perhaps it is not worth the patch?
I think that every contribution, as long as it acctually fixes
something, is worth the patch. The beauty of the open source community
is that we do when we have time as much as we are able to do - totally
no stress.
You, Pavel, are more experienced however those who are not have to learn
somehow and one of the options is to start with something very simple.
Sometimes the 'simple' means oneliner however as long as it compiles, is
inline with the coding standard and in general is an improvement then it
is good.
Regards,
Konrad
> Pavel
>
> > Thanks,
> > Konrad
> >
> > > Signed-off-by: Christian F. Resell
> > > ---
> > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > index 2bba370..bdc6854 100644
> > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
> > > i2c_client *client)
> > > * bcm2048_i2c_driver - i2c driver interface
> > > */
> > > static const struct i2c_device_id bcm2048_id[] = {
> > > - { "bcm2048" , 0 },
> > > + { "bcm2048", 0 },
> > > { },
> > > };
> > > MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > > ___
> > > devel mailing list
> > > de...@linuxdriverproject.org
> > > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: frequent lockups in 3.18rc4
On Fri, Nov 14, 2014 at 02:01:27PM -0800, Linus Torvalds wrote: > But since you say "several times a day", just for fun, can you test > the follow-up patch to that one-liner fix that Will Deacon posted > today (Subject: "[PATCH] mmu_gather: move minimal range calculations > into generic code"). That does some further cleanup in this area. A few hours ago it hit the NMI watchdog again with that patch applied. Incomplete trace, but it looks different based on what did make it over. Different RIP at least. [65155.054155] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [trinity-c127:12559] [65155.054573] irq event stamp: 296752 [65155.054589] hardirqs last enabled at (296751): [] _raw_spin_unlock_irqrestore+0x5d/0x80 [65155.054625] hardirqs last disabled at (296752): [] apic_timer_interrupt+0x6a/0x80 [65155.054657] softirqs last enabled at (296188): [] bdi_queue_work+0x83/0x270 [65155.054688] softirqs last disabled at (296184): [] bdi_queue_work+0x60/0x270 [65155.054721] CPU: 1 PID: 12559 Comm: trinity-c127 Not tainted 3.18.0-rc4+ #84 [loadavg: 209.68 187.90 185.33 34/431 17515] [65155.054795] task: 88023f664680 ti: 8801649f task.ti: 8801649f [65155.054820] RIP: 0010:[] [] _raw_spin_unlock_irqrestore+0x5f/0x80 [65155.054852] RSP: 0018:8801649f3be8 EFLAGS: 0292 [65155.054872] RAX: 88023f664680 RBX: 0007 RCX: 0007 [65155.054895] RDX: 29e0 RSI: 88023f664ea0 RDI: 88023f664680 [65155.054919] RBP: 8801649f3bf8 R08: R09: [65155.055956] R10: R11: R12: [65155.056985] R13: 8801649f3b58 R14: 9d3e7d0e R15: 03e0 [65155.058037] FS: 7f0dc957c700() GS:88024420() knlGS: [65155.059083] CS: 0010 DS: ES: CR0: 80050033 [65155.060121] CR2: 7f0dc958e000 CR3: 00022f31e000 CR4: 001407e0 [65155.061152] DR0: 7f54162bc000 DR1: 7feb92c3d000 DR2: [65155.062180] DR3: DR6: fffe0ff0 DR7: 0600 [65155.063202] Stack: And that's all she wrote. > If Will's patch doesn't make a difference, what about reverting that > ce9ec37bddb6? Although it really *is* a "obvious bugfix", and I really > don't see why any of this would be noticeable on x86 (it triggered > issues on ARM64, but that was because ARM64 cared much more about the > exact range). I'll try that next, and check in on it tomorrow. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] parisc architecture patches for v3.18
Hi Linus, please pull some patches for the parisc architecture for kernel 3.18 from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.18-2 Changes include: - wire up the bpf syscall - Remove CONFIG_64BIT usage from some userspace-exported header files - Use compat functions for msgctl, shmat, shmctl and semtimedop syscalls Thanks, Helge Helge Deller (4): parisc: Wire up bpf syscall parisc: Use BUILD_BUG() instead of undefined functions parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls parisc: Avoid using CONFIG_64BIT in userspace exported headers arch/parisc/include/asm/uaccess.h | 19 +++- arch/parisc/include/uapi/asm/bitsperlong.h | 8 +-- arch/parisc/include/uapi/asm/msgbuf.h | 8 --- arch/parisc/include/uapi/asm/sembuf.h | 6 +++-- arch/parisc/include/uapi/asm/shmbuf.h | 35 +- arch/parisc/include/uapi/asm/signal.h | 2 +- arch/parisc/include/uapi/asm/unistd.h | 3 ++- arch/parisc/kernel/syscall_table.S | 9 8 files changed, 41 insertions(+), 49 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: rockchip: fix clk_usbphy480m_gate bit location in register
Am Donnerstag, 13. November 2014, 15:19:21 schrieb Kever Yang: > According to rk3288 trm, the clk_usbphy480m_gate is locate at > bit 14 of CRU_CLKGATE5_CON register. > > Signed-off-by: Kever Yang applied this to my clk branch. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/8] x86, microcode, intel: guard against misaligned microcode data
On Thu, 13 Nov 2014, Borislav Petkov wrote: > On Wed, Nov 12, 2014 at 10:18:47PM -0200, Henrique de Moraes Holschuh wrote: > > The detail is that: since most Intel microcodes are bigger than the kmalloc > > cache, most of the time kmalloc will return page-aligned addresses, which > > don't need any alignment. > > Yeah, you keep saying that. Do you have an actual proof too? I believe so, from documention gathered through google... but I could be wrong about this. And since I have learned my lesson, I took your comment to mean "look deeper". I took the time to both try to understand somewhat the mm/ code AND write a kernel module to do empiric testing before I wrote this reply, instead of trusting the documentation. And it turns out I failed at proving myself wrong, either because I am not wrong, or by sheer unluckyness. Important detail: intel microcodes have 1KiB size granularity, are never smaller than 2048 bytes, and so far the largest ones are close to 64KiB. For SLUB: kmalloc() will do kmalloc_large() for anything > 8192 bytes and that should return page-aligned data since it calls alloc_kmem_pages()/alloc_pages(). For 2048 bytes to 8192 bytes, we will get memory from one of the following slabs: kmalloc-2048, kmalloc-4096 or kmalloc-8192. As far as I could understand (and here I could easily be wrong as the mm/ slab cache code is not trivial to grok), those are going to be object-size aligned, because the allocation size will be rounded up to the slab's object size (i.e. 2048/4096/8192 bytes). The objects are allocated from the start of the slab (which is page-aligned), back-to-back. Thus SLUB would always return 16-byte aligned memory for the size range of Intel microcode. In fact, it will return 2048-byte aligned memory in the worst case (2048-byte microcode). Empiric testing in x86-64 resulted in data compatible with the above reasoning. For SLAB: SLAB is nasty to grok with a first look due to the whole complexity re. its queues and cpu caches, and I don't think I understood the code properly. intel microcode sized allocations end up in slabs with large objects that are all of the same 2^n size (i.e. 2048 bytes, 4096 bytes, etc). I could not grok the code enough to assert what real alignment I could expect for 2KiB to 64KiB objects. Empiric testing in x86-64 SLAB, done by allocating 63 objects of the same size in a row, for all possible microcode sizes, did not result in a single kmalloc() that was not sufficiently aligned, and in fact all of them were object-size aligned, even for the smallest microcodes (2048 bytes). I even tried it with CONFIG_DEBUG_SLAB turned on and off to see if it changed anything (it didn't). So, while I didn't understand the code enough to prove that we'd mostly get good microcode alignment out of SLAB, I couldn't get it to return pointers that would require extra alignment either. The worst case was 2048-byte alignment, for microcodes with 2048 bytes. For SLOB: SLOB will call the page allocator for anything bigger than 4095 bytes, so all microcodes from 4096 bytes and above will be page-aligned. Only 2048-byte and 3072-byte microcode wouldn't go directly to the page allocator. This is microcode for ancient processors: Pentium M and earlier, and the first NetBurst processors. I didn't bother to test, but from the code, I expect that 2048-byte and 3072-byte sized microcode would *not* be aligned to 16 bytes. However, we have very few users of these ancient processors left. Calling kmalloc(s); kfree(); kmalloc(s+15); for these rare processors doesn't look like too much of an issue IMHO. SLOB was the only allocator that could result in microcode that needs further alignment in my testing, and only for the small microcode (2KiB and 3KiB) of ancient processors. > Because if this turns out wrong, we'll end up doing two allocations > instead of one, which is dumb. My suggestion was to do one allocation > only. See above. As far as I could verify, we wouldn't be doing two allocations in the common cases. I really don't like the idea of increasing the allocation order by one for 4KiB, 8KiB, 16KiB, 32KiB and 64KiB microcodes just to alocate 15 bytes of extra padding that, at least as far as I could check, seem to be most often not needed. Note that I did not do any empiric testing on 32 bits. > > Your version also needs to keep the original pointer around for kfree, which > > is going to be annoying. > > > > My version has the drawback that it requires the use of INTEL_UCODE_PTR(p) > > Yeah, just drop that macro - use simply PTR_ALIGN and > INTEL_MICROCODE_MINALIGN. I will do that. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info a
Re: [PATCH] clk: rockchip: fix clock select order for usbphy480m_src
Am Donnerstag, 13. November 2014, 16:11:49 schrieb Kever Yang: > According to rk3288 trm, the mux selector locate at bit[12:11] > of CRU_CLKSEL13_CON shows: > 2'b00: select HOST0 USB pll clock (clk_otgphy1) > 2'b01: select HOST1 USB pll clock (clk_otgphy2) > 2'b10: select OTG USB pll clock (clk_otgphy0) > > The clock map is in Fig. 3-4 CRU Clock Architecture Diagram 3 > - clk_otgphy0 -> USB PHY OTG > - clk_otgphy1 -> USB PHY host0 > - clk_otgphy2 -> USB PHY host1 > > Signed-off-by: Kever Yang applied this to my clk branch for 3.19 Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 2/2] groups: Allow unprivileged processes to use setgroups to drop groups
Currently, unprivileged processes (without CAP_SETGID) cannot call
setgroups at all. In particular, processes with a set of supplementary
groups cannot further drop permissions without obtaining elevated
permissions first.
Allow unprivileged processes to call setgroups with a subset of their
current groups; only require CAP_SETGID to add a group the process does
not currently have (either as a supplementary group, or as its gid,
egid, or sgid).
Since some privileged programs (such as sudo) allow tests for
non-membership in a group, require no_new_privs to drop group
privileges.
The kernel already maintains the list of supplementary group IDs in
sorted order, and setgroups already needs to sort the new list, so this
just requires a linear comparison of the two sorted lists.
This moves the CAP_SETGID test from setgroups into set_current_groups.
Tested via the following test program:
void run_id(void)
{
pid_t p = fork();
switch (p) {
case -1:
err(1, "fork");
case 0:
execl("/usr/bin/id", "id", NULL);
err(1, "exec");
default:
if (waitpid(p, NULL, 0) < 0)
err(1, "waitpid");
}
}
int main(void)
{
gid_t list1[] = { 1, 2, 3, 4, 5 };
gid_t list2[] = { 2, 3, 4 };
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 1");
run_id();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
run_id();
if (setgroups(3, list2) < 0)
err(1, "setgroups 2");
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 3");
run_id();
return 0;
}
Without this patch, the test program gets EPERM from the second
setgroups call, after dropping root privileges. With this patch, the
test program successfully drops groups 1 and 5, but then gets EPERM from
the third setgroups call, since that call attempts to add groups the
process does not currently have.
Signed-off-by: Josh Triplett
---
v3: Allow gid, egid, or sgid.
v2: Require no_new_privs.
kernel/groups.c | 42 +++---
kernel/uid16.c | 2 --
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index f0667e7..5114155 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -153,6 +153,37 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
return 0;
}
+/* Return true if the group_info is a subset of the group_info of the specified
+ * credentials. Also allow the first group_info to contain the gid, egid, or
+ * sgid of the credentials.
+ */
+static bool group_subset(const struct group_info *g1,
+const struct cred *cred2)
+{
+ const struct group_info *g2 = cred2->group_info;
+ unsigned int i, j;
+
+ for (i = 0, j = 0; i < g1->ngroups; i++) {
+ kgid_t gid1 = GROUP_AT(g1, i);
+ kgid_t gid2;
+ for (; j < g2->ngroups; j++) {
+ gid2 = GROUP_AT(g2, j);
+ if (gid_lte(gid1, gid2))
+ break;
+ }
+ if (j >= g2->ngroups || !gid_eq(gid1, gid2)) {
+ if (!gid_eq(gid1, cred2->gid)
+ && !gid_eq(gid1, cred2->egid)
+ && !gid_eq(gid1, cred2->sgid))
+ return false;
+ } else {
+ j++;
+ }
+ }
+
+ return true;
+}
+
/**
* set_groups_sorted - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
@@ -189,11 +220,18 @@ int set_current_groups(struct group_info *group_info)
{
struct cred *new;
+ groups_sort(group_info);
new = prepare_creds();
if (!new)
return -ENOMEM;
+ if (!(ns_capable(current_user_ns(), CAP_SETGID)
+ || (task_no_new_privs(current)
+ && group_subset(group_info, new {
+ abort_creds(new);
+ return -EPERM;
+ }
- set_groups(new, group_info);
+ set_groups_sorted(new, group_info);
return commit_creds(new);
}
@@ -233,8 +271,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *,
grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bb..b27e167 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t
__user *, grouplist)
struct group_info *group_info;
int retval;
- if (!ns_capable(current_user_ns(), CAP_SETGID))
- return -EPERM;
if ((unsigned)gidsetsi
[PATCH] getgroups.2: Document unprivileged setgroups calls
Signed-off-by: Josh Triplett --- v3: Document use of gid/egid/sgid. v2: Document requirement for no_new_privs. (If this doesn't end up going into 3.18, the version number in the patch will need updating.) man2/getgroups.2 | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/man2/getgroups.2 b/man2/getgroups.2 index 373c204..e2b834e 100644 --- a/man2/getgroups.2 +++ b/man2/getgroups.2 @@ -81,9 +81,16 @@ to be used in a further call to .PP .BR setgroups () sets the supplementary group IDs for the calling process. -Appropriate privileges (Linux: the +A process with the .B CAP_SETGID -capability) are required. +capability may change its supplementary group IDs arbitrarily. +As of Linux 3.18, any process that has enabled PR_SET_NO_NEW_PRIVS (see +.BR prctl (2)) +may drop supplementary groups, or add any of the current real UID, the current +effective UID, or the current saved set-user-ID; adding any other group ID +requires the +.B CAP_SETGID +capability. The .I size argument specifies the number of supplementary group IDs -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 1/2] groups: Factor out a function to set a pre-sorted group list
This way, functions that already need to sort the group list need not do
so twice.
The new set_groups_sorted is intentionally not exported.
Signed-off-by: Josh Triplett
---
v2, v3: No changes to patch 1/2.
kernel/groups.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f..f0667e7 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -154,16 +154,26 @@ int groups_search(const struct group_info *group_info,
kgid_t grp)
}
/**
+ * set_groups_sorted - Change a group subscription in a set of credentials
+ * @new: The newly prepared set of credentials to alter
+ * @group_info: The group list to install; must be sorted
+ */
+static void set_groups_sorted(struct cred *new, struct group_info *group_info)
+{
+ put_group_info(new->group_info);
+ get_group_info(group_info);
+ new->group_info = group_info;
+}
+
+/**
* set_groups - Change a group subscription in a set of credentials
* @new: The newly prepared set of credentials to alter
* @group_info: The group list to install
*/
void set_groups(struct cred *new, struct group_info *group_info)
{
- put_group_info(new->group_info);
groups_sort(group_info);
- get_group_info(group_info);
- new->group_info = group_info;
+ set_groups_sorted(new, group_info);
}
EXPORT_SYMBOL(set_groups);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/33] thermal: exynos: convert the driver to use per-SoC type operations
Hello Bartlomiej, On Thu, Nov 13, 2014 at 04:00:55PM +0100, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series replaces the hardware registers abstractions in > the Exynos thermal driver by the usage of per-SoC type operations. Good! I think the driver is a bit confusing because it has two ways of checking features: soc based and feature flag based. Thus, removing one is a good step. > Such solution provides simpler, easier to understand code and Well, that is arguable. IMO, the feature based solution is naturally easier to understand as while reading the code, you think about the feature not about chip / IP/ SoC versions. Besides, having soc based approach spreads many if's in your code base. Anyways, so far no one working in the Exynos code base has nacked your proposal. Apart from that, the issue I had with it, as I mentioned, was the fact that it currently has two ways of representing / checking features. That is for sure the major issue. > allows removal of ~250 LOCs (~11% of the whole source code) from > the driver. Some other driver improvements are now also possible > thanks to these changes but are scheduled at later time (like > consolidating code for clearing IRQs using INTCLEAR register). > I am not sure I get your point here. I understand you are basing new changes in the code on top of this series, but I don't see how this refactoring could enable other feature implementions. > The patchset should not cause any functionality changes. This > means that unless there are some bugs in the patches itself there > should be no behavior changes for the driver (this also includes > lack of changes in the way hardware is accessed by the driver). > > All testing was done on (Exynos4412 SoC based) ODROID U3 board > (some additional patches are needed to make the Exynos thermal > driver work on this hardware). Is it possible to spread testing here? I would like to have coverage for all supported chip versions. The reasoning is because the driver supports more than Exynos4412, and the amount of changes are considerably big. One thing I can do is to start testing in linux-next on this code. Thus, I can merge it in my -next branch (which includes my -linus and -fixes branches). But so far, it would not be queued. My proposal is that these changes will be sent only for the 3.19 merge window though. For 3.18 -rc's I believe it is too late. However, to get it into 3.19, I request you to provide the testing in all supported chips, as I mentioned. Do you think it is doable before Linus opens 3.19 merge window? > > Depends on: > - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo > Thanks for attending my request. > Changes since v1 (https://lkml.org/lkml/2014/9/18/305): > - rebased on top of the current linux-soc-thermal kernel > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (33): > thermal: exynos: remove needless triminfo_data abstraction > thermal: exynos: remove needless tmu_status abstraction > thermal: exynos: remove needless threshold_temp abstraction > thermal: exynos: remove needless triminfo_ctrl abstraction > thermal: exynos: remove needless test_mux_addr_shift abstraction > thermal: exynos: remove needless therm_trip_[mode,mask]_shift > abstractions > thermal: exynos: remove needless therm_trip_en_shift abstraction > thermal: exynos: remove needless emul_temp_shift abstraction > thermal: exynos: remove needless emul_time_shift abstraction > thermal: exynos: replace tmu_irqstatus check by Exynos5440 one > thermal: exynos: replace tmu_pmin check by Exynos5440 one > thermal: exynos: simplify HW_TRIP level setting > thermal: exynos: replace threshold_falling check by Exynos SoC type > one > thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag > thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag > thermal: exynos: add sanitize_temp_error() helper > thermal: exynos: add get_th_reg() helper > thermal: exynos: add ->tmu_initialize method > thermal: exynos: add get_con_reg() helper > thermal: exynos: add ->tmu_control method > thermal: exynos: add ->tmu_read method > thermal: exynos: add get_emul_con_reg() helper > thermal: exynos: add ->tmu_set_emulation method > thermal: exynos: add ->tmu_clear_irqs method > thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag > thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag > thermal: exynos: remove TMU_SUPPORT_EMULATION flag > thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag > thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag > thermal: exynos: remove test_mux pdata field > thermal: exynos: remove SoC type ifdefs > thermal: exynos: remove __EXYNOS5420_TMU_DATA macro > thermal: exynos: remove exynos_tmu_data.h include > > drivers/thermal/samsung/exynos_thermal_common.h | 1 - > drivers/thermal/samsung/exynos_tmu.c| 692 > +++
re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
forwarding to lkml, as no response on netdev list so far. maybe someone has a clue how to properly fix this timing issue. the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly. inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress. sorry, i`m not good at programming, but now as the problem is "basically" fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted. hi, as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it. it`s a little bit academic, as i can do ifconfig eth0 hw ether. as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it. apparently the problem is being caused by a timing issue in the natsemi driver. i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away. there is a hint about timing sensitivity in the code: /* Delay between EEPROM clock transitions. No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is deprecated. */ looking at the source of natsemi-diag.c made me wonder why that utility is using #define eeprom_delay(ee_addr) inl(ee_addr) instead of #define eeprom_delay(ee_addr) readl(ee_addr) and apparently, that also fixes the problem (but gives a compile warning): drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ: drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default] In file included from include/linux/io.h:22:0, from include/linux/pci.h:54, from drivers/net/ethernet/natsemi/natsemi.c:38: looking at a more recent version of natsemi-diag.c , i even found this one: ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c /* Delay between EEPROM clock transitions. This flushes the write buffer to prevent quick double-writes. */ #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr) The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !? "The in*() functions return data read from the specified I/O port" "The read*() functions read data from device memory previously mapped by map_memory()" regards roland ps: CC driver maintainer from Kernel Maintainers file. Roland Kletzing | 17 Dec 13:38 2012 bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load Hello, i recently played with my older evo t20/wyse 3235le thin clients and flashed a linux kernel into those, apparently there seems an issue with the natsemi driver. after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and ifconfig shows just zero`s: 00:00:00:00:00:00. despite that , the nic is working fine for me (in this test setup i set the mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef ) apparently, the driver fails to read the proper mac from the eeprom, as "natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see below) looks like a driver bug !? does anybody have a clue what`s going wrong here? regards roland #lspci 00:00.0 Host bridge: Cyrix Corporation PCI Master 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30) 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) #dmesg |egrep "natsemi|eth" natsemi dp8381x driver, version 2.1, Sept 11, 2006 natsemi :00:0f.0: setting latency timer to 64 natsemi eth0: NatSemi DP8381[56] at 0x401 (:00:0f.0), 00:00:00:00:00:00, IRQ 10, port TP. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. #natsemi-diag -aa natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a NatSemi DP83815 adapter at 0xf800. Natsemi 83815 series with station address de:ad:be:
[PATCH V2 00/22] Multiplatform BMIPS kernel
This patch series implements a multiplatform target that runs on a
variety of different Broadcom chipsets based on the BMIPS CPUs. It
evolved out of the "BMIPS updates and BCM3384 platform support"
RFC posted earlier.
V1->V2:
- Add several more DTS files so the same kernel can boot on multiple
chips: BCM6328, BCM6368, BCM7125, BCM7346, BCM7360, BCM7420, BCM7425,
and as a very special bonus, the BCM3384 Viper CPU.
- Add irq-bcm7038-l1.c to support the BCM7xxx chipsets.
- Rename target from "bcm3384" to "bmips".
- Change L1_CACHE_SHIFT fix so it works correctly when multiple BMIPS
CPU types are selected.
- Drop dependency on rejected EARLYCON_FORCE changes.
- Delete most of my new irq.c, in favor of using the refactored
irq-bcm7120-l2.c.
- Add flush for BMIPS3300/BMIPS43xx readahead caches, to avoid
non-coherency after DMA_FROM_DEVICE operations.
- Utilize the new MIPS IRQ APIs from mips-for-linux-next.
- Tweak docs/copyrights/maintainership.
This series is based on 3.18-rc4, plus:
http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v2-deps/?state=*
http://marc.info/?l=linux-usb&m=141305106215886&w=2 (all 3/3)
These are all queued for tty-next / irqchip-next / usb-next. Notably,
the proposed serial/pxa/ttyBCM coexistence changes are not required at
this time.
A couple of sample boot logs are posted here:
https://gist.github.com/cernekee/e53a6ff05292c3a78a94
checkpatch status:
The checkpatch warnings fall into two categories:
- Undocumented DT bindings. These SoCs use mostly-standard-looking
peripherals (OHCI/EHCI controllers, ethernet PHYs), but it may be
necessary to add extra code in the future to compensate for
hardware quirks. So the compatible string in the DTS file lists
both the generic device name (documented) and a more specific
identifier for the hardware present on the chip (undocumented).
- extern declarations for the __dtb_* symbols.
Known issues:
If the lockdep checks are enabled, I see a weird IRQ state mismatch
returning from e.g. sys_execve(). CP0 STATUS shows IE disabled, but
current->hardirqs_enabled == 1. Not sure if this is a problem with
my new code or something more general. It only shows up on
SMP && !PREEMPT builds.
Booting a HIGHMEM MIPS kernel on a system with cache aliases may fail
if the system has >256MB of memory. AFAICT this is a general problem
with the fallback logic in arch/mips/mm/init.c.
Many of the BCM63xx bootloaders impose severe restrictions on the kernel
size. This tends to cause a lot of trouble booting images that include
an initramfs (because we're still missing MTD support). One workaround
is to set CONFIG_PHYSICAL_START to a higher value, like 0x8100_.
Future work:
Many BCM7xxx boards can be freely switched between big endian and little
endian modes, with the latter being the default. It would be nice if we
could use identical DTS files for both configurations, since the LE/BE
setting mostly doesn't affect how the peripherals work. But currently a
few assumptions are hardcoded in there ("big-endian" USB register
properties and a hack to get the 16550 register addresses correct). I
submitted a patch to the DT/serial lists which adds a "native-endian"
property; if this is accepted and utilized by the drivers in question, it
will go a long way toward solving this problem.
Lots of peripherals are still missing, especially flash and bcm63xx_enet.
The lack of a reboot handler is annoying; syscon-reboot probably won't work
on STB (because it requires two writes). Some peripherals, like USB on
certain boards, need more work (possibly PHY drivers) and were left
disabled.
There are ways to retrieve other information from the legacy non-DT
bootloaders, but they're pretty hacky. The flash configuration is among
the worst of the bunch, because these chips can have up to 4 different
flash controllers, more than one can be active at a time, and the
bootloader just passes "hints" rather than explicit partition maps. For
specific boards it is sometimes OK to hardcode the map into the DTS file,
although most of the supported boards are user-reconfigurable and the
flash layouts may change from one bootloader version to the next.
There is currently no way to distinguish between different bcm63xx
board types (i.e. we can only identify the SoC, not the board). There
is a way to distinguish different bcm7xxx board types, although in
practice the data source is somewhat unreliable and doesn't always convey
all of the information needed to distinguish boards with different
capabilities.
The kernel makes a few assumptions about how the bootloader has set up
Broadcom-specific registers for e.g. USB. If/when power management
features are added, these registers will revert to their default settings
on resume, and somehow need to be set up again by Linux.
irq-bcm7120-l2.c is getting a little bloated and I'm not entirely happy
with the latest round of changes. In particular it would be r
[PATCH V2 04/22] irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT offsets
Currently the driver assumes that REG_BASE+0x00 is the IRQ enable mask,
and REG_BASE+0x04 is the IRQ status mask. This is true on BCM3384 and
BCM7xxx, but it is not true for some of the controllers found on BCM63xx
chips. So we will change a couple of key assumptions:
- Don't assume that both the IRQEN and IRQSTAT registers will be
covered by a single ioremap() operation.
- Don't assume any particular ordering (IRQSTAT might show up before
IRQEN on some chips).
- For an L2 controller with >=64 IRQs, don't assume that every
IRQEN/IRQSTAT pair will use the same register spacing.
This patch changes the "plumbing" but doesn't yet provide a way for users
to instantiate a controller with arbitrary IRQEN/IRQSTAT offsets.
Signed-off-by: Kevin Cernekee
---
drivers/irqchip/irq-bcm7120-l2.c | 41 +++-
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 8eec8e1..e8441ee 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -34,11 +34,15 @@
#define IRQSTAT0x04
#define MAX_WORDS 4
+#define MAX_MAPPINGS MAX_WORDS
#define IRQS_PER_WORD 32
struct bcm7120_l2_intc_data {
unsigned int n_words;
- void __iomem *base[MAX_WORDS];
+ void __iomem *map_base[MAX_MAPPINGS];
+ void __iomem *pair_base[MAX_WORDS];
+ int en_offset[MAX_WORDS];
+ int stat_offset[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
@@ -61,7 +65,8 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq,
struct irq_desc *desc)
int hwirq;
irq_gc_lock(gc);
- pending = irq_reg_readl(gc, IRQSTAT) & gc->mask_cache;
+ pending = irq_reg_readl(gc, b->stat_offset[idx]) &
+ gc->mask_cache;
irq_gc_unlock(gc);
for_each_set_bit(hwirq, &pending, IRQS_PER_WORD) {
@@ -76,21 +81,24 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq,
struct irq_desc *desc)
static void bcm7120_l2_intc_suspend(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct bcm7120_l2_intc_data *b = gc->private;
irq_gc_lock(gc);
if (b->can_wake)
- irq_reg_writel(gc, gc->mask_cache | gc->wake_active, IRQEN);
+ irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
+ ct->regs.mask);
irq_gc_unlock(gc);
}
static void bcm7120_l2_intc_resume(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
/* Restore the saved mask */
irq_gc_lock(gc);
- irq_reg_writel(gc, gc->mask_cache, IRQEN);
+ irq_reg_writel(gc, gc->mask_cache, ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -137,9 +145,14 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
return -ENOMEM;
for (idx = 0; idx < MAX_WORDS; idx++) {
- data->base[idx] = of_iomap(dn, idx);
- if (!data->base[idx])
+ data->map_base[idx] = of_iomap(dn, idx);
+ if (!data->map_base[idx])
break;
+
+ data->pair_base[idx] = data->map_base[idx];
+ data->en_offset[idx] = IRQEN;
+ data->stat_offset[idx] = IRQSTAT;
+
data->n_words = idx + 1;
}
if (!data->n_words) {
@@ -157,7 +170,8 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
if (ret == 0 || ret == -EINVAL) {
for (idx = 0; idx < data->n_words; idx++)
__raw_writel(data->irq_fwd_mask[idx],
-data->base[idx] + IRQEN);
+data->pair_base[idx] +
+data->en_offset[idx]);
} else {
/* property exists but has the wrong number of words */
pr_err("invalid int-fwd-mask property\n");
@@ -215,11 +229,12 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
gc = irq_get_domain_generic_chip(data->domain, irq);
gc->unused = 0x & ~data->irq_map_mask[idx];
- gc->reg_base = data->base[idx];
gc->private = data;
ct = gc->chip_types;
- ct->regs.mask = IRQEN;
+ gc->reg_base = data->pair_base[idx];
+ ct->regs.mask = data->en_offset[idx];
+
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_ack = irq_gc_noop;
@@ -237,16 +252,16 @@ int __init bcm7120_l2_intc_of_init(struct
[PATCH V2 09/22] MIPS: BMIPS: Introduce helper function to change the reset vector
This will need to be called from a few different places, and the logic
is starting to get a bit hairy (with the need for IPIs, CPU bug
workarounds, and hazards).
Signed-off-by: Kevin Cernekee
---
arch/mips/kernel/smp-bmips.c | 65 +++-
1 file changed, 58 insertions(+), 7 deletions(-)
diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 4e56911..8383fa4 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
static int __maybe_unused max_cpus = 1;
@@ -43,6 +44,9 @@ int bmips_smp_enabled = 1;
int bmips_cpu_offset;
cpumask_t bmips_booted_mask;
+#define RESET_FROM_KSEG0 0x80080800
+#define RESET_FROM_KSEG1 0xa0080800
+
#ifdef CONFIG_SMP
/* initial $sp, $gp - used by arch/mips/kernel/bmips_vec.S */
@@ -463,10 +467,61 @@ static inline void bmips_nmi_handler_setup(void)
&bmips_smp_int_vec_end);
}
+struct reset_vec_info {
+ int cpu;
+ u32 val;
+};
+
+static void bmips_set_reset_vec_remote(void *vinfo)
+{
+ struct reset_vec_info *info = vinfo;
+ int shift = info->cpu & 0x01 ? 16 : 0;
+ u32 mask = ~(0x << shift), val = info->val >> 16;
+
+ preempt_disable();
+ if (smp_processor_id() > 0) {
+ smp_call_function_single(0, &bmips_set_reset_vec_remote,
+info, 1);
+ } else {
+ if (info->cpu & 0x02) {
+ /* BMIPS5200 "should" use mask/shift, but it's buggy */
+ bmips_write_zscm_reg(0xa0, (val << 16) | val);
+ bmips_read_zscm_reg(0xa0);
+ } else {
+ write_c0_brcm_bootvec((read_c0_brcm_bootvec() & mask) |
+ (val << shift));
+ }
+ }
+ preempt_enable();
+}
+
+static void bmips_set_reset_vec(int cpu, u32 val)
+{
+ struct reset_vec_info info;
+
+ if (current_cpu_type() == CPU_BMIPS5000) {
+ /* this needs to run from CPU0 (which is always online) */
+ info.cpu = cpu;
+ info.val = val;
+ bmips_set_reset_vec_remote(&info);
+ } else {
+ void __iomem *cbr = BMIPS_GET_CBR();
+
+ if (cpu == 0)
+ __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
+ else {
+ if (current_cpu_type() != CPU_BMIPS4380)
+ return;
+ __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+ }
+ }
+ __sync();
+ back_to_back_c0_hazard();
+}
+
void bmips_ebase_setup(void)
{
unsigned long new_ebase = ebase;
- void __iomem __maybe_unused *cbr;
BUG_ON(ebase != CKSEG0);
@@ -492,9 +547,7 @@ void bmips_ebase_setup(void)
* 0x8000_0400: normal vectors
*/
new_ebase = 0x8400;
- cbr = BMIPS_GET_CBR();
- __raw_writel(0x80080800, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
- __raw_writel(0xa0080800, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+ bmips_set_reset_vec(0, RESET_FROM_KSEG0);
break;
case CPU_BMIPS5000:
/*
@@ -502,10 +555,8 @@ void bmips_ebase_setup(void)
* 0x8000_1000: normal vectors
*/
new_ebase = 0x80001000;
- write_c0_brcm_bootvec(0xa0088008);
+ bmips_set_reset_vec(0, RESET_FROM_KSEG0);
write_c0_ebase(new_ebase);
- if (max_cpus > 2)
- bmips_write_zscm_reg(0xa0, 0xa008a008);
break;
default:
return;
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 01/22] irqchip: Update docs regarding irq_domain_add_tree()
Several drivers now use this API, including the ARM GIC driver, so remove the outdated comment. Signed-off-by: Kevin Cernekee --- Documentation/IRQ-domain.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 8a8b82c..0ccd7b7 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the largest hwirq number. The disadvantage is that hwirq to IRQ number lookup is dependent on how many entries are in the table. -Very few drivers should need this mapping. At the moment, powerpc -iseries is the only user. +Very few drivers should need this mapping. No Map ===- irq_domain_add_nomap() -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 19/22] Documentation: DT: Add "mti" vendor prefix
We have a bunch of platforms using "mti,cpu-interrupt-controller" but the "mti" prefix isn't documented. Fix this. Signed-off-by: Kevin Cernekee --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..b2114de 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -96,6 +96,7 @@ mitsubishiMitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa mplMPL AG +mtiImagination Technologies Ltd. (formerly MIPS Technologies Inc.) mundoreaderMundo Reader S.L. murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 17/22] MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)
This is a dual core (quad thread) BMIPS5000. It needs a little extra code to boot the second core (CPU2/CPU3), but for now we can treat it the same as a single core BMIPS5000. Signed-off-by: Kevin Cernekee --- arch/mips/include/asm/cpu.h | 1 + arch/mips/kernel/cpu-probe.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h index dfdc77e..de9ca43 100644 --- a/arch/mips/include/asm/cpu.h +++ b/arch/mips/include/asm/cpu.h @@ -142,6 +142,7 @@ #define PRID_IMP_BMIPS3300_BUG 0x #define PRID_IMP_BMIPS43XX 0xa000 #define PRID_IMP_BMIPS5000 0x5a00 +#define PRID_IMP_BMIPS5200 0x5b00 #define PRID_REV_BMIPS4380_LO 0x0040 #define PRID_REV_BMIPS4380_HI 0x006f diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 94c4a0c..5477d91 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -1024,6 +1024,7 @@ static inline void cpu_probe_broadcom(struct cpuinfo_mips *c, unsigned int cpu) break; } case PRID_IMP_BMIPS5000: + case PRID_IMP_BMIPS5200: c->cputype = CPU_BMIPS5000; __cpu_name[cpu] = "Broadcom BMIPS5000"; set_elf_platform(cpu, "bmips5000"); -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
