Re: [PATCH 20/21] mm: drop vmtruncate
2012/11/16 Jaegeuk Hanse : > On 11/03/2012 05:32 PM, Marco Stornelli wrote: >> >> Removed vmtruncate > > > Hi Marco, > > Could you explain me why vmtruncate need remove? What's the problem and how > to substitute it? > > Regards, > Jaegeuk > vmtruncate is a deprecated function so it'd be better to remove it. The truncate sequence is changed for several reasons. The documentation is clear: "This function is deprecated and truncate_setsize or truncate_pagecache should be used instead, together with filesystem specific block truncation." In addition, we can remove the truncate callback from the inode struct saving 4/8 bytes. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [SCSI] mvsas: fix shift in mvs_94xx_free_reg_set()
Hi, Xi > > About patch 3, I check the ffz code and found it will check ~0 conditions. > > Can you point me to the ~0 check in ffz code? I also feel like using > __ffs64 makes the code simpler. Yes, it seem to be ok > > Does patch 1 look good to you? Thanks. > Yes Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver
On 15.11.2012 23:28, Thierry Reding wrote: > This third version of the patch series cleans up some minor issues that > were found in the previous versions, such as deferred probe not working > properly and the display remaining enabled after the driver is removed. > > I've also put the two patches in this series into the tegra/drm/for-3.8 > branch of my repository on gitorious[0]. Excellent work. Thanks a lot Thierry! I tested this and the device tree patches on my Tegra20 board. For both: Acked-by: Terje Bergstrom Tested-by: Terje Bergstrom Best regards, Terje -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 1/3] Runtime Interpreted Power Sequences
Hi Alexandre,
The code looks neat, thanks for you work!
Just a couple of comments...
On Fri, Nov 16, 2012 at 03:38:21PM +0900, Alexandre Courbot wrote:
[...]
> +
> +#include "power_seq_delay.c"
> +#include "power_seq_regulator.c"
> +#include "power_seq_pwm.c"
> +#include "power_seq_gpio.c"
This is odd, although I remember you already explained why you have to
include the .c files, instead of linking them separately. But I forgot the
reason. :) I think this deserves a comment in the code.
> +static int of_power_seq_parse_step(struct device *dev,
> +struct device_node *node,
> +struct power_seq *seq,
> +unsigned int step_nbr,
> +struct list_head *resources)
> +{
> + struct power_seq_step *step = >steps[step_nbr];
> + struct power_seq_resource res, *res2;
> + const char *type;
> + int i, err;
nit: one variable declaration per line.
Thanks,
Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] memcg: get rid of once-per-second cache shrinking for dead memcgs
(2012/11/16 16:11), Glauber Costa wrote: > On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote: >> (2012/11/15 22:47), Glauber Costa wrote: >>> On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote: (2012/11/15 11:54), Glauber Costa wrote: > The idea is to synchronously do it, leaving it up to the shrinking > facilities in vmscan.c and/or others. Not actively retrying shrinking > may leave the caches alive for more time, but it will remove the ugly > wakeups. One would argue that if the caches have free objects but are > not being shrunk, it is because we don't need that memory yet. > > Signed-off-by: Glauber Costa > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Andrew Morton I agree this patch but can we have a way to see the number of unaccounted zombie cache usage for debugging ? Acked-by: KAMEZAWA Hiroyuki >>> Any particular interface in mind ? >>> >> >> Hmm, it's debug interface and having cgroup file may be bad. >> If it can be seen in bytes or some, /proc/vmstat ? >> >> out_of_track_slabs xxx. hm ? >> > > I particularly think that, being this a debug interface, it is also > useful to have an indication of which caches are still in place. This is > because the cache itself, is the best indication we have about the > specific workload that may be keeping it in memory. > > I first thought debugfs could help us probing useful information out of > it, but given all the abuse people inflicted in debugfs... maybe we > could have a file in the root memcg with that information for all > removed memcgs? If we do that, we can go further and list the memcgs > that are pending due to memsw as well. memory.dangling_memcgs ? > Hm, I'm ok with it... others ? Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tools: hv: Netlink source address validation allows DoS
- Original Message - > On Thu, Nov 08, 2012 at 10:53:29AM +0100, Tomas Hozza wrote: > > The source code without this patch caused hypervkvpd to exit when > > it processed > > a spoofed Netlink packet which has been sent from an untrusted > > local user. > > Now Netlink messages with a non-zero nl_pid source address are > > ignored > > and a warning is printed into the syslog. > > > > Signed-off-by: Tomas Hozza > > Acked-by: K. Y. Srinivasan > > --- > > tools/hv/hv_kvp_daemon.c | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c > > index 13c2a14..c1d9102 100755 > > Why are you setting a .c file to executable permissions? Something > is really wrong here... I'm sorry, this is a mistake and unfortunately I missed it. Permissions should be 0644. Will check more carefully next time. Regards, Tomas Hozza -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm: Add NVIDIA Tegra30 support
On 11/16/2012 03:11 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, Nov 16, 2012 at 02:48:55PM +0800, Mark Zhang wrote: >> On 11/16/2012 02:43 PM, Thierry Reding wrote: Old Signed by an unknown key >>> >>> On Fri, Nov 16, 2012 at 12:58:09PM +0800, Mark Zhang wrote: This patch is based on Thierry's drm patch for Tegra20: - [PATCH v2 0/6] Device tree updates for host1x support - [PATCH v3 0/2] NVIDIA Tegra DRM driver It adds the support for NVIDIA Tegra30. Signed-off-by: Mark Zhang >>> >>> Hi Mark, >>> >>> I already carry a similar patch in my tegra/next branch and was going to >>> post that once I get word back that tegra-drm actually works on Tegra30. >>> >> >> Sorry for that. Actually I didn't sync your tree yet. >> >>> You do have the hardware available, right? Did you test this patch on >>> top of the latest (v3) tegra-drm patches and arch/arm/mach-tegra (v2) >>> patches I sent a few hours ago? >>> >> >> Yes, I have a cardhu here. Yes, I made this patch on top of your v3 & v2 >> patches and it worked on my cardhu. > > Okay, that's great! The reason I wanted this to be tested again > explicitly is that I've made some minor modifications to bring the > Tegra30 code more in line with the Tegra20 code where clock setup is > concerned. > > Since everything works for you on Tegra30, I'll push the Tegra30 related > patches into the branch that David will pull from. > Great. Thanks! Hope to see the display of Tegra 2 and Tegra 3 works in kernel 3.8. > Thierry > > * Unknown Key > * 0x7F3EB3A1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] memcg: get rid of once-per-second cache shrinking for dead memcgs
On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote: > (2012/11/15 22:47), Glauber Costa wrote: >> On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote: >>> (2012/11/15 11:54), Glauber Costa wrote: The idea is to synchronously do it, leaving it up to the shrinking facilities in vmscan.c and/or others. Not actively retrying shrinking may leave the caches alive for more time, but it will remove the ugly wakeups. One would argue that if the caches have free objects but are not being shrunk, it is because we don't need that memory yet. Signed-off-by: Glauber Costa CC: Michal Hocko CC: Kamezawa Hiroyuki CC: Johannes Weiner CC: Andrew Morton >>> >>> I agree this patch but can we have a way to see the number of unaccounted >>> zombie cache usage for debugging ? >>> >>> Acked-by: KAMEZAWA Hiroyuki >>> >> Any particular interface in mind ? >> > > Hmm, it's debug interface and having cgroup file may be bad. > If it can be seen in bytes or some, /proc/vmstat ? > > out_of_track_slabs xxx. hm ? > I particularly think that, being this a debug interface, it is also useful to have an indication of which caches are still in place. This is because the cache itself, is the best indication we have about the specific workload that may be keeping it in memory. I first thought debugfs could help us probing useful information out of it, but given all the abuse people inflicted in debugfs... maybe we could have a file in the root memcg with that information for all removed memcgs? If we do that, we can go further and list the memcgs that are pending due to memsw as well. memory.dangling_memcgs ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm: Add NVIDIA Tegra30 support
On Fri, Nov 16, 2012 at 02:48:55PM +0800, Mark Zhang wrote: > On 11/16/2012 02:43 PM, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Fri, Nov 16, 2012 at 12:58:09PM +0800, Mark Zhang wrote: > >> This patch is based on Thierry's drm patch for Tegra20: > >> - [PATCH v2 0/6] Device tree updates for host1x support > >> - [PATCH v3 0/2] NVIDIA Tegra DRM driver > >> > >> It adds the support for NVIDIA Tegra30. > >> > >> Signed-off-by: Mark Zhang > > > > Hi Mark, > > > > I already carry a similar patch in my tegra/next branch and was going to > > post that once I get word back that tegra-drm actually works on Tegra30. > > > > Sorry for that. Actually I didn't sync your tree yet. > > > You do have the hardware available, right? Did you test this patch on > > top of the latest (v3) tegra-drm patches and arch/arm/mach-tegra (v2) > > patches I sent a few hours ago? > > > > Yes, I have a cardhu here. Yes, I made this patch on top of your v3 & v2 > patches and it worked on my cardhu. Okay, that's great! The reason I wanted this to be tested again explicitly is that I've made some minor modifications to bring the Tegra30 code more in line with the Tegra20 code where clock setup is concerned. Since everything works for you on Tegra30, I'll push the Tegra30 related patches into the branch that David will pull from. Thierry pgpFnv64tCYnf.pgp Description: PGP signature
Re: [PATCH] checkpatch: extend line continuation test
On Fri, 2012-11-16 at 08:02 +0100, Geert Uytterhoeven wrote: > On Fri, Nov 16, 2012 at 7:21 AM, Joe Perches wrote: > > Preprocessor directives and asm statements should be > > allowed to have a line continuation. > > For preprocessor directives I agree. > > But why do asm statements need it? They'r just strings, so just closing with > a double quote at the end of the first line, and opening again with a > double quote > on the next line works fine. I agree it does, but it's a pretty common existing style and I want to avoid people submitting unnecessary "fix" patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/14] pinctrl: SPEAr: Update error check for unsigned variables
On Fri, Nov 16, 2012 at 12:20 PM, Tushar Behera
wrote:
> Checking '< 0' for unsigned variables always returns false. For error
> codes, use IS_ERR_VALUE() instead.
>
> CC: Linus Walleij
> Signed-off-by: Tushar Behera
> ---
> drivers/pinctrl/spear/pinctrl-plgpio.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pinctrl/spear/pinctrl-plgpio.c
> b/drivers/pinctrl/spear/pinctrl-plgpio.c
> index 1044ad3..9e0c731 100644
> --- a/drivers/pinctrl/spear/pinctrl-plgpio.c
> +++ b/drivers/pinctrl/spear/pinctrl-plgpio.c
> @@ -283,7 +283,7 @@ static int plgpio_to_irq(struct gpio_chip *chip, unsigned
> offset)
> {
> struct plgpio *plgpio = container_of(chip, struct plgpio, chip);
>
> - if (plgpio->irq_base < 0)
> + if (IS_ERR_VALUE(plgpio->irq_base))
> return -EINVAL;
>
> return irq_find_mapping(plgpio->irq_domain, offset);
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFT RESEND linux-next] openrisc: dma-mapping: support debug_dma_mapping_error
On Thu, 2012-11-15 at 11:00 -0700, Shuah Khan wrote:
> On Fri, 2012-10-26 at 10:05 -0600, Shuah Khan wrote:
> > Add support for debug_dma_mapping_error() call to avoid warning from
> > debug_dma_unmap() interface when it checks for mapping error checked
> > status. Without this patch, device driver failed to check map error
> > warning is generated.
> >
> > Signed-off-by: Shuah Khan
> > ---
> > arch/openrisc/include/asm/dma-mapping.h |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/openrisc/include/asm/dma-mapping.h
> > b/arch/openrisc/include/asm/dma-mapping.h
> > index fab8628..f12de49 100644
> > --- a/arch/openrisc/include/asm/dma-mapping.h
> > +++ b/arch/openrisc/include/asm/dma-mapping.h
> > @@ -95,6 +95,7 @@ static inline int dma_supported(struct device *dev, u64
> > dma_mask)
> >
> > static inline int dma_mapping_error(struct device *dev, dma_addr_t
> > dma_addr)
> > {
> > + debug_dma_mapping_error(dev, dma_addr);
> > return 0;
> > }
> >
>
> Marek/Jonas,
>
> This one is for openrisc to go through Marek's tree with the other arch
> debug_dma_mapping_error() patches. Hoping it is ok with Jonas.
NAK... for a bunch of reasons.
i) You've sent this exact patch 4 times already... and this time
you're trying to bypass me altogether by going through some other tree.
First it was a PATCH, now it's an RFT... what do you want me to do with
this?
ii) There isn't enough information in the commit message to understand
what's going on here. Why do I suddenly need this when I never needed
it before?
iii) This doesn't compile... but I figured out that it depends on other
changes that seem to have snuck into linux-next already. linux-arch was
never included in that discussion, despite the fact that you have now
introduced warnings for everybody
iv) From what I can tell, you haven't even attempted to fix all
architectures... but I could be wrong, see next comment.
v) You've sent this patch series per-architecture which really only
serves to fragment the discussion. When a change is this
straight-forward (exact same change in each architecture), then it's
better to consolidate everything into a single patch to allow a single
discussion to take place. As it stands now, I have to go rummaging
through the threads of all 30 architectures to see what others think of
this; I'd say the silence is telling, but the few responses you did
receive all show the same confusion and you're answering the same
questions over and over. I realize that you can't inflate your patch
statistics this way and you'll probably just miss the top 10 of "Who
wrote 3.8" because of it, but you can always try to write something
witty in your commit message and hope to make "Quotes of the week"
instead.
vi) If you _had_ requested comment on your underlying dma-debug patch
on linux-arch, I think you would have found that:
1) introducing warnings without fixing them _at the same time_ isn't OK
when the fix is this simple
2) if you make changes to core code, you make it optional until all
arches have caught up
3) you are using get_dma_ops which isn't even implemented on every
architecture
4) this change probably doesn't belong in every architecture but should
be centralized in more generic code
/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: extend line continuation test
On Fri, Nov 16, 2012 at 7:21 AM, Joe Perches wrote:
> Preprocessor directives and asm statements should be
> allowed to have a line continuation.
For preprocessor directives I agree.
But why do asm statements need it? They'r just strings, so just closing with
a double quote at the end of the first line, and opening again with a
double quote
on the next line works fine.
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/
[PATCH] Correct description of SwapFree in Documentation/filesystems/proc.txt
After migrating most of the information in Documentation/filesystems/proc.txt to the proc(5) man page, Jim Paris pointed out to me that the description of SwapFree in the man page seemed wrong. I think Jim is right, but am given pause by fact that that text has been in Documentation/filesystems/proc.txt since at least 2.6.0. Anyway, I believe that the patch below fixes things. Signed-off-by: Michael Kerrisk diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a1793d6..cf4260f 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -778,8 +778,7 @@ AnonHugePages: 49152 kB other things, it is where everything from the Slab is allocated. Bad things happen when you're out of lowmem. SwapTotal: total amount of swap space available -SwapFree: Memory which has been evicted from RAM, and is temporarily - on the disk +SwapFree: Amount of swap space that is currently unused. Dirty: Memory which is waiting to get written back to the disk Writeback: Memory which is actively being written back to the disk AnonPages: Non-file backed pages mapped into userspace page tables -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/14] [media] meye: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0.
CC: Mauro Carvalho Chehab
CC: linux-me...@vger.kernel.org
Signed-off-by: Tushar Behera
---
drivers/media/pci/meye/meye.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index e5a76da..ae7d320 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -1945,7 +1945,7 @@ static struct pci_driver meye_driver = {
static int __init meye_init(void)
{
gbuffers = max(2, min((int)gbuffers, MEYE_MAX_BUFNBRS));
- if (gbufsize < 0 || gbufsize > MEYE_MAX_BUFSIZE)
+ if (gbufsize > MEYE_MAX_BUFSIZE)
gbufsize = MEYE_MAX_BUFSIZE;
gbufsize = PAGE_ALIGN(gbufsize);
printk(KERN_INFO "meye: using %d buffers with %dk (%dk total) "
--
1.7.4.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 08/14] xen: netback: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0. CC: Ian Campbell CC: xen-de...@lists.xensource.com CC: net...@vger.kernel.org Signed-off-by: Tushar Behera --- drivers/net/xen-netback/netback.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index aab8677..515e10c 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -190,14 +190,14 @@ static int get_page_ext(struct page *pg, group = ext.e.group - 1; - if (group < 0 || group >= xen_netbk_group_nr) + if (group >= xen_netbk_group_nr) return 0; netbk = _netbk[group]; idx = ext.e.idx; - if ((idx < 0) || (idx >= MAX_PENDING_REQS)) + if (idx >= MAX_PENDING_REQS) return 0; if (netbk->mmap_pages[idx] != pg) -- 1.7.4.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 07/14] pinctrl: SPEAr: Update error check for unsigned variables
Checking '< 0' for unsigned variables always returns false. For error
codes, use IS_ERR_VALUE() instead.
CC: Linus Walleij
Signed-off-by: Tushar Behera
---
drivers/pinctrl/spear/pinctrl-plgpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-plgpio.c
b/drivers/pinctrl/spear/pinctrl-plgpio.c
index 1044ad3..9e0c731 100644
--- a/drivers/pinctrl/spear/pinctrl-plgpio.c
+++ b/drivers/pinctrl/spear/pinctrl-plgpio.c
@@ -283,7 +283,7 @@ static int plgpio_to_irq(struct gpio_chip *chip, unsigned
offset)
{
struct plgpio *plgpio = container_of(chip, struct plgpio, chip);
- if (plgpio->irq_base < 0)
+ if (IS_ERR_VALUE(plgpio->irq_base))
return -EINVAL;
return irq_find_mapping(plgpio->irq_domain, offset);
--
1.7.4.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 06/14] pinctrl: samsung: Update error check for unsigned variables
Checking '< 0' for unsigned variables always returns false. For error
codes, use IS_ERR_VALUE() instead.
CC: Linus Walleij
Signed-off-by: Tushar Behera
---
drivers/pinctrl/pinctrl-samsung.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 81c9896..3b52c17 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -560,7 +560,7 @@ static int __devinit samsung_pinctrl_parse_dt_pins(struct
platform_device *pdev,
const char *pin_name;
*npins = of_property_count_strings(cfg_np, "samsung,pins");
- if (*npins < 0) {
+ if (IS_ERR_VALUE(*npins)) {
dev_err(dev, "invalid pin list in %s node", cfg_np->name);
return -EINVAL;
}
--
1.7.4.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 05/14] [media] atmel-isi: Update error check for unsigned variables
Checking '< 0' for unsigned variables always returns false. For error
codes, use IS_ERR_VALUE() instead.
CC: Mauro Carvalho Chehab
CC: linux-me...@vger.kernel.org
Signed-off-by: Tushar Behera
---
drivers/media/platform/soc_camera/atmel-isi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 6274a91..5bd65df 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -1020,7 +1020,7 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
+ if (IS_ERR_VALUE(irq)) {
ret = irq;
goto err_req_irq;
}
--
1.7.4.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 03/14] [media] saa7134: Remove redundant check on unsigned variable
No need to check whether the unsigned variable is less than 0. CC: Mauro Carvalho Chehab CC: linux-me...@vger.kernel.org Signed-off-by: Tushar Behera --- drivers/media/pci/saa7134/saa7134-video.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/pci/saa7134/saa7134-video.c b/drivers/media/pci/saa7134/saa7134-video.c index 4a77124..3abf527 100644 --- a/drivers/media/pci/saa7134/saa7134-video.c +++ b/drivers/media/pci/saa7134/saa7134-video.c @@ -2511,7 +2511,7 @@ int saa7134_video_init1(struct saa7134_dev *dev) /* sanitycheck insmod options */ if (gbuffers < 2 || gbuffers > VIDEO_MAX_FRAME) gbuffers = 2; - if (gbufsize < 0 || gbufsize > gbufsize_max) + if (gbufsize > gbufsize_max) gbufsize = gbufsize_max; gbufsize = (gbufsize + PAGE_SIZE - 1) & PAGE_MASK; -- 1.7.4.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 00/14] Modify signed comparisons of unsigned variables
The occurrences were identified through the coccinelle script at following location. http://www.emn.fr/z-info/coccinelle/rules/find_unsigned.cocci Signed checks for unsigned variables are removed if it is also checked for upper error limit. For error checks, IS_ERR_VALUE() macros is used. Tushar Behera (14): [media] ivtv: Remove redundant check on unsigned variable [media] meye: Remove redundant check on unsigned variable [media] saa7134: Remove redundant check on unsigned variable [media] tlg2300: Remove redundant check on unsigned variable [media] atmel-isi: Update error check for unsigned variables pinctrl: samsung: Update error check for unsigned variables pinctrl: SPEAr: Update error check for unsigned variables xen: netback: Remove redundant check on unsigned variable xen: events: Remove redundant check on unsigned variable atm: Removed redundant check on unsigned variable HID: hiddev: Remove redundant check on unsigned variable gru: Remove redundant check on unsigned variable misc: tsl2550: Remove redundant check on unsigned variable wlcore: Remove redundant check on unsigned variable drivers/atm/fore200e.c|2 +- drivers/hid/usbhid/hiddev.c |2 +- drivers/media/pci/ivtv/ivtv-ioctl.c |2 +- drivers/media/pci/meye/meye.c |2 +- drivers/media/pci/saa7134/saa7134-video.c |2 +- drivers/media/platform/soc_camera/atmel-isi.c |2 +- drivers/media/usb/tlg2300/pd-video.c |2 +- drivers/misc/sgi-gru/grukdump.c |2 +- drivers/misc/tsl2550.c|4 ++-- drivers/net/wireless/ti/wlcore/debugfs.c |2 +- drivers/net/xen-netback/netback.c |4 ++-- drivers/pinctrl/pinctrl-samsung.c |2 +- drivers/pinctrl/spear/pinctrl-plgpio.c|2 +- drivers/xen/events.c |2 +- 14 files changed, 16 insertions(+), 16 deletions(-) -- 1.7.4.1 CC: Mauro Carvalho Chehab CC: Linus Walleij CC: Ian Campbell CC: Konrad Rzeszutek Wilk CC: Jeremy Fitzhardinge CC: Chas Williams CC: Jack Steiner CC: Arnd Bergmann CC: Luciano Coelho CC: Jiri Kosina CC: ivtv-de...@ivtvdriver.org CC: linux-me...@vger.kernel.org CC: xen-de...@lists.xensource.com CC: net...@vger.kernel.org CC: virtualizat...@lists.linux-foundation.org CC: linux-atm-gene...@lists.sourceforge.net CC: linux-...@vger.kernel.org CC: linux-in...@vger.kernel.org CC: linux-wirel...@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/14] atm: Removed redundant check on unsigned variable
No need to check whether unsigned variable is less than 0.
CC: Chas Williams
CC: linux-atm-gene...@lists.sourceforge.net
CC: net...@vger.kernel.org
Signed-off-by: Tushar Behera
---
drivers/atm/fore200e.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 361f5ae..fdd3fe7 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -972,7 +972,7 @@ int bsq_audit(int where, struct host_bsq* bsq, int scheme,
int magn)
where, scheme, magn, buffer->index, buffer->scheme);
}
- if ((buffer->index < 0) || (buffer->index >= fore200e_rx_buf_nbr[
scheme ][ magn ])) {
+ if (buffer->index >= fore200e_rx_buf_nbr[ scheme ][ magn ]) {
printk(FORE200E "bsq_audit(%d): queue %d.%d, out of range buffer
index = %ld !\n",
where, scheme, magn, buffer->index);
}
--
1.7.4.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 12/14] gru: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0. CC: Jack Steiner Signed-off-by: Tushar Behera --- drivers/misc/sgi-gru/grukdump.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/sgi-gru/grukdump.c b/drivers/misc/sgi-gru/grukdump.c index 9b2062d..860733b 100644 --- a/drivers/misc/sgi-gru/grukdump.c +++ b/drivers/misc/sgi-gru/grukdump.c @@ -197,7 +197,7 @@ int gru_dump_chiplet_request(unsigned long arg) return -EFAULT; /* Currently, only dump by gid is implemented */ - if (req.gid >= gru_max_gids || req.gid < 0) + if (req.gid >= gru_max_gids) return -EINVAL; gru = GID_TO_GRU(req.gid); -- 1.7.4.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 14/14] wlcore: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0.
CC: Luciano Coelho
CC: linux-wirel...@vger.kernel.org
CC: net...@vger.kernel.org
Signed-off-by: Tushar Behera
---
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c
b/drivers/net/wireless/ti/wlcore/debugfs.c
index c86bb00..93f801d 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -993,7 +993,7 @@ static ssize_t sleep_auth_write(struct file *file,
return -EINVAL;
}
- if (value < 0 || value > WL1271_PSM_MAX) {
+ if (value > WL1271_PSM_MAX) {
wl1271_warning("sleep_auth must be between 0 and %d",
WL1271_PSM_MAX);
return -ERANGE;
--
1.7.4.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 13/14] misc: tsl2550: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0. CC: Arnd Bergmann Signed-off-by: Tushar Behera --- drivers/misc/tsl2550.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c index 0beb298..0438569 100644 --- a/drivers/misc/tsl2550.c +++ b/drivers/misc/tsl2550.c @@ -204,7 +204,7 @@ static ssize_t tsl2550_store_power_state(struct device *dev, unsigned long val = simple_strtoul(buf, NULL, 10); int ret; - if (val < 0 || val > 1) + if (val > 1) return -EINVAL; mutex_lock(>update_lock); @@ -236,7 +236,7 @@ static ssize_t tsl2550_store_operating_mode(struct device *dev, unsigned long val = simple_strtoul(buf, NULL, 10); int ret; - if (val < 0 || val > 1) + if (val > 1) return -EINVAL; if (data->power_state == 0) -- 1.7.4.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 11/14] HID: hiddev: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0. CC: Jiri Kosina CC: linux-...@vger.kernel.org CC: linux-in...@vger.kernel.org Signed-off-by: Tushar Behera --- drivers/hid/usbhid/hiddev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c index 14599e2..711c965 100644 --- a/drivers/hid/usbhid/hiddev.c +++ b/drivers/hid/usbhid/hiddev.c @@ -625,7 +625,7 @@ static long hiddev_ioctl(struct file *file, unsigned int cmd, unsigned long arg) break; case HIDIOCAPPLICATION: - if (arg < 0 || arg >= hid->maxapplication) + if (arg >= hid->maxapplication) break; for (i = 0; i < hid->maxcollection; i++) -- 1.7.4.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 09/14] xen: events: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0.
CC: Konrad Rzeszutek Wilk
CC: Jeremy Fitzhardinge
CC: xen-de...@lists.xensource.com
CC: virtualizat...@lists.linux-foundation.org
Signed-off-by: Tushar Behera
---
drivers/xen/events.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4293c57..cadd7d1 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -216,7 +216,7 @@ static void xen_irq_info_pirq_init(unsigned irq,
*/
static unsigned int evtchn_from_irq(unsigned irq)
{
- if (unlikely(WARN(irq < 0 || irq >= nr_irqs, "Invalid irq %d!\n", irq)))
+ if (unlikely(WARN(irq >= nr_irqs, "Invalid irq %d!\n", irq)))
return 0;
return info_for_irq(irq)->evtchn;
--
1.7.4.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 04/14] [media] tlg2300: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0. CC: Mauro Carvalho Chehab CC: linux-me...@vger.kernel.org Signed-off-by: Tushar Behera --- drivers/media/usb/tlg2300/pd-video.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/usb/tlg2300/pd-video.c b/drivers/media/usb/tlg2300/pd-video.c index 1f448ac..dd157e7 100644 --- a/drivers/media/usb/tlg2300/pd-video.c +++ b/drivers/media/usb/tlg2300/pd-video.c @@ -923,7 +923,7 @@ static int vidioc_s_input(struct file *file, void *fh, unsigned int i) struct poseidon *pd = front->pd; s32 ret, cmd_status; - if (i < 0 || i >= POSEIDON_INPUTS) + if (i >= POSEIDON_INPUTS) return -EINVAL; ret = send_set_req(pd, SGNL_SRC_SEL, pd_inputs[i].tlg_src, _status); -- 1.7.4.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 01/14] [media] ivtv: Remove redundant check on unsigned variable
No need to check whether unsigned variable is less than 0.
CC: Mauro Carvalho Chehab
CC: ivtv-de...@ivtvdriver.org
CC: linux-me...@vger.kernel.org
Signed-off-by: Tushar Behera
---
drivers/media/pci/ivtv/ivtv-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 949ae23..4b47b5c 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -993,7 +993,7 @@ int ivtv_s_input(struct file *file, void *fh, unsigned int
inp)
v4l2_std_id std;
int i;
- if (inp < 0 || inp >= itv->nof_inputs)
+ if (inp >= itv->nof_inputs)
return -EINVAL;
if (inp == itv->active_input) {
--
1.7.4.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 v2 1/3] gpio / ACPI: add ACPI support
On Fri, Nov 16, 2012 at 02:34:22AM +0100, Rafael J. Wysocki wrote:
> On Thursday, November 15, 2012 01:03:15 PM Mika Westerberg wrote:
> > From: Mathias Nyman
> >
> > Add support for translating ACPI GPIO pin numbers to Linux GPIO API pins.
> > Needs a gpio controller driver with the acpi handler hook set.
> >
> > Drivers can use acpi_get_gpio() to translate ACPI5 GpioIO and GpioInt
> > resources to Linux GPIO's.
> >
> > Signed-off-by: Mathias Nyman
> > Signed-off-by: Mika Westerberg
> > ---
> > drivers/gpio/Kconfig|4
> > drivers/gpio/Makefile |1 +
> > drivers/gpio/gpiolib-acpi.c | 56
> > +++
> > include/linux/acpi_gpio.h | 19 +++
> > 4 files changed, 80 insertions(+)
> > create mode 100644 drivers/gpio/gpiolib-acpi.c
> > create mode 100644 include/linux/acpi_gpio.h
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index f11d8e3..5c9b384 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -49,6 +49,10 @@ config OF_GPIO
> > def_bool y
> > depends on OF
> >
> > +config GPIO_ACPI
> > + def_bool y
> > + depends on ACPI
> > +
> > config DEBUG_GPIO
> > bool "Debug GPIO calls"
> > depends on DEBUG_KERNEL
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index 9aeed67..420dbac 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -4,6 +4,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
> >
> > obj-$(CONFIG_GPIOLIB) += gpiolib.o devres.o
> > obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
> > +obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
> >
> > # Device drivers. Generally keep list sorted alphabetically
> > obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
> > diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> > new file mode 100644
> > index 000..8ef9831
> > --- /dev/null
> > +++ b/drivers/gpio/gpiolib-acpi.c
> > @@ -0,0 +1,56 @@
> > +/*
> > + * ACPI helpers for GPIO API
> > + *
> > + * Copyright (C) 2012, Intel Corporation
> > + * Authors: Mathias Nyman
> > + * Mika Westerberg
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int acpi_gpiochip_find(struct gpio_chip *gc, void *data)
> > +{
> > + acpi_handle handle = data;
> > +
> > + if (!gc->dev)
> > + return false;
> > +
> > + return gc->dev->acpi_handle == handle;
>
> I'd prefer DEVICE_ACPI_HANDLE() to be used in such places, we may want to
> replace it with something else in the future or make it work differently.
Sure but then we need to make it available for drivers as well when
!CONFIG_ACPI. Something like below is needed.
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 2dca46f..01a26f9 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -416,7 +416,6 @@ acpi_handle acpi_get_child(acpi_handle, u64);
int acpi_is_root_bridge(acpi_handle);
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
struct acpi_pci_root *acpi_pci_find_root(acpi_handle handle);
-#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->acpi_handle))
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int state);
int acpi_disable_wakeup_device_power(struct acpi_device *dev);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b4c9984..c4c58ff 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -28,6 +28,8 @@
#include /* for struct resource */
#include
+#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->acpi_handle))
+
#ifdef CONFIG_ACPI
#ifndef _LINUX
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm: Add NVIDIA Tegra30 support
On 11/16/2012 02:43 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, Nov 16, 2012 at 12:58:09PM +0800, Mark Zhang wrote: >> This patch is based on Thierry's drm patch for Tegra20: >> - [PATCH v2 0/6] Device tree updates for host1x support >> - [PATCH v3 0/2] NVIDIA Tegra DRM driver >> >> It adds the support for NVIDIA Tegra30. >> >> Signed-off-by: Mark Zhang > > Hi Mark, > > I already carry a similar patch in my tegra/next branch and was going to > post that once I get word back that tegra-drm actually works on Tegra30. > Sorry for that. Actually I didn't sync your tree yet. > You do have the hardware available, right? Did you test this patch on > top of the latest (v3) tegra-drm patches and arch/arm/mach-tegra (v2) > patches I sent a few hours ago? > Yes, I have a cardhu here. Yes, I made this patch on top of your v3 & v2 patches and it worked on my cardhu. > Thierry > > * Unknown Key > * 0x7F3EB3A1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm: Add NVIDIA Tegra30 support
On Fri, Nov 16, 2012 at 12:58:09PM +0800, Mark Zhang wrote: > This patch is based on Thierry's drm patch for Tegra20: > - [PATCH v2 0/6] Device tree updates for host1x support > - [PATCH v3 0/2] NVIDIA Tegra DRM driver > > It adds the support for NVIDIA Tegra30. > > Signed-off-by: Mark Zhang Hi Mark, I already carry a similar patch in my tegra/next branch and was going to post that once I get word back that tegra-drm actually works on Tegra30. You do have the hardware available, right? Did you test this patch on top of the latest (v3) tegra-drm patches and arch/arm/mach-tegra (v2) patches I sent a few hours ago? Thierry pgp6X5vZHjRuc.pgp Description: PGP signature
Re: [PATCH] clk: mxs: Use a better name for the USB PHY clock
On Sat, Sep 22, 2012 at 01:54:55PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Use a better name for the USB PHY clock.
>
> Signed-off-by: Fabio Estevam
Mike,
I was planning send a pull-request to you with all mxs clock patches
collected for 3.8. It turns out this is the only one I queued for
this cycle. I do not bother to send you a pull-request containing
single patch, so can you please just apply it for 3.8? Thanks.
Shawn
> ---
> .../devicetree/bindings/clock/imx23-clock.txt |2 +-
> .../devicetree/bindings/clock/imx28-clock.txt |4 ++--
> drivers/clk/mxs/clk-imx23.c|6 +++---
> drivers/clk/mxs/clk-imx28.c| 10 +-
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt
> b/Documentation/devicetree/bindings/clock/imx23-clock.txt
> index a0b867e..baadbb1 100644
> --- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt
> @@ -52,7 +52,7 @@ clocks and IDs.
> lcdif 38
> etm 39
> usb 40
> - usb_pwr 41
> + usb_phy 41
>
> Examples:
>
> diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt
> b/Documentation/devicetree/bindings/clock/imx28-clock.txt
> index aa2af28..52a49a4 100644
> --- a/Documentation/devicetree/bindings/clock/imx28-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt
> @@ -73,8 +73,8 @@ clocks and IDs.
> can159
> usb060
> usb161
> - usb0_pwr62
> - usb1_pwr63
> + usb0_phy62
> + usb1_phy63
> enet_out64
>
> Examples:
> diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
> index f00dffb..8dd476e 100644
> --- a/drivers/clk/mxs/clk-imx23.c
> +++ b/drivers/clk/mxs/clk-imx23.c
> @@ -85,7 +85,7 @@ enum imx23_clk {
> cpu_xtal, hbus, xbus, lcdif_div, ssp_div, gpmi_div, emi_pll,
> emi_xtal, etm_div, saif_div, clk32k_div, rtc, adc, spdif_div,
> clk32k, dri, pwm, filt, uart, ssp, gpmi, spdif, emi, saif,
> - lcdif, etm, usb, usb_pwr,
> + lcdif, etm, usb, usb_phy,
> clk_max
> };
>
> @@ -143,8 +143,8 @@ int __init mx23_clocks_init(void)
> clks[saif] = mxs_clk_gate("saif", "saif_div", SAIF, 31);
> clks[lcdif] = mxs_clk_gate("lcdif", "lcdif_div", PIX, 31);
> clks[etm] = mxs_clk_gate("etm", "etm_div", ETM, 31);
> - clks[usb] = mxs_clk_gate("usb", "usb_pwr", DIGCTRL, 2);
> - clks[usb_pwr] = clk_register_gate(NULL, "usb_pwr", "pll", 0, PLLCTRL0,
> 18, 0, _lock);
> + clks[usb] = mxs_clk_gate("usb", "usb_phy", DIGCTRL, 2);
> + clks[usb_phy] = clk_register_gate(NULL, "usb_phy", "pll", 0, PLLCTRL0,
> 18, 0, _lock);
>
> for (i = 0; i < ARRAY_SIZE(clks); i++)
> if (IS_ERR(clks[i])) {
> diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
> index 42978f1b..db3af08 100644
> --- a/drivers/clk/mxs/clk-imx28.c
> +++ b/drivers/clk/mxs/clk-imx28.c
> @@ -140,7 +140,7 @@ enum imx28_clk {
> emi_xtal, lcdif_div, etm_div, ptp, saif0_div, saif1_div,
> clk32k_div, rtc, lradc, spdif_div, clk32k, pwm, uart, ssp0,
> ssp1, ssp2, ssp3, gpmi, spdif, emi, saif0, saif1, lcdif, etm,
> - fec, can0, can1, usb0, usb1, usb0_pwr, usb1_pwr, enet_out,
> + fec, can0, can1, usb0, usb1, usb0_phy, usb1_phy, enet_out,
> clk_max
> };
>
> @@ -218,10 +218,10 @@ int __init mx28_clocks_init(void)
> clks[fec] = mxs_clk_gate("fec", "hbus", ENET, 30);
> clks[can0] = mxs_clk_gate("can0", "ref_xtal", FLEXCAN, 30);
> clks[can1] = mxs_clk_gate("can1", "ref_xtal", FLEXCAN, 28);
> - clks[usb0] = mxs_clk_gate("usb0", "usb0_pwr", DIGCTRL, 2);
> - clks[usb1] = mxs_clk_gate("usb1", "usb1_pwr", DIGCTRL, 16);
> - clks[usb0_pwr] = clk_register_gate(NULL, "usb0_pwr", "pll0", 0,
> PLL0CTRL0, 18, 0, _lock);
> - clks[usb1_pwr] = clk_register_gate(NULL, "usb1_pwr", "pll1", 0,
> PLL1CTRL0, 18, 0, _lock);
> + clks[usb0] = mxs_clk_gate("usb0", "usb0_phy", DIGCTRL, 2);
> + clks[usb1] = mxs_clk_gate("usb1", "usb1_phy", DIGCTRL, 16);
> + clks[usb0_phy] = clk_register_gate(NULL, "usb0_phy", "pll0", 0,
> PLL0CTRL0, 18, 0, _lock);
> + clks[usb1_phy] = clk_register_gate(NULL, "usb1_phy", "pll1", 0,
> PLL1CTRL0, 18, 0, _lock);
> clks[enet_out] = clk_register_gate(NULL, "enet_out", "pll2", 0, ENET,
> 18, 0, _lock);
>
> for (i = 0; i < ARRAY_SIZE(clks); i++)
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tilegx: request_irq with a non-null device name
From: Simon Marchi Date: Thu, 15 Nov 2012 23:13:19 -0500 > This patch simply makes the tilegx net driver call request_irq with a > non-null name. It makes the output in /proc/interrupts more obvious, but > also helps tools that don't expect to find null there. > > Signed-off-by: Simon Marchi > Acked-by: Chris Metcalf Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/21] mm: drop vmtruncate
On 11/03/2012 05:32 PM, Marco Stornelli wrote:
Removed vmtruncate
Hi Marco,
Could you explain me why vmtruncate need remove? What's the problem and
how to substitute it?
Regards,
Jaegeuk
Signed-off-by: Marco Stornelli
---
include/linux/mm.h |1 -
mm/truncate.c | 23 ---
2 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index fa06804..95f70bb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -977,7 +977,6 @@ static inline void unmap_shared_mapping_range(struct
address_space *mapping,
extern void truncate_pagecache(struct inode *inode, loff_t old, loff_t new);
extern void truncate_setsize(struct inode *inode, loff_t newsize);
-extern int vmtruncate(struct inode *inode, loff_t offset);
void truncate_pagecache_range(struct inode *inode, loff_t offset, loff_t end);
int truncate_inode_page(struct address_space *mapping, struct page *page);
int generic_error_remove_page(struct address_space *mapping, struct page
*page);
diff --git a/mm/truncate.c b/mm/truncate.c
index d51ce92..c75b736 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -577,29 +577,6 @@ void truncate_setsize(struct inode *inode, loff_t newsize)
EXPORT_SYMBOL(truncate_setsize);
/**
- * vmtruncate - unmap mappings "freed" by truncate() syscall
- * @inode: inode of the file used
- * @newsize: file offset to start truncating
- *
- * This function is deprecated and truncate_setsize or truncate_pagecache
- * should be used instead, together with filesystem specific block truncation.
- */
-int vmtruncate(struct inode *inode, loff_t newsize)
-{
- int error;
-
- error = inode_newsize_ok(inode, newsize);
- if (error)
- return error;
-
- truncate_setsize(inode, newsize);
- if (inode->i_op->truncate)
- inode->i_op->truncate(inode);
- return 0;
-}
-EXPORT_SYMBOL(vmtruncate);
-
-/**
* truncate_pagecache_range - unmap and remove pagecache that is hole-punched
* @inode: inode
* @lstart: offset of beginning of hole
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] pwm_backlight: use power sequences
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
Signed-off-by: Alexandre Courbot
Reviewed-by: Stephen Warren
---
.../bindings/video/backlight/pwm-backlight.txt | 63 +++-
drivers/video/backlight/Kconfig| 1 +
drivers/video/backlight/pwm_bl.c | 160 -
include/linux/pwm_backlight.h | 18 ++-
4 files changed, 202 insertions(+), 40 deletions(-)
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..b20e98e 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -13,16 +13,73 @@ Required properties:
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
- "pwms" property (see PWM binding[0])
+ "pwms" property (see PWM binding[0]).
+ - power-sequences: Power sequences (see Power sequences[1]) used to bring the
+ backlight on and off. If this property is present, then two power
+ sequences named "power-on" and "power-off" must be defined to control how
+ the backlight is to be powered on and off. These sequences must reference
+ the PWM specified in the pwms property by its name, and can also
reference
+ other resources supported by the power sequences mechanism
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+[1]: Documentation/devicetree/bindings/power/power_seq.txt
Example:
backlight {
compatible = "pwm-backlight";
- pwms = < 0 500>;
-
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
+ low-threshold-brightness = <50>;
+
+ /* resources used by the power sequences */
+ pwms = < 0 500>;
+ pwm-names = "backlight";
+ power-supply = <_reg>;
+
+ power-sequences {
+ power-on {
+ step0 {
+ type = "regulator";
+ id = "power";
+ enable;
+ };
+ step1 {
+ type = "delay";
+ delay = <1>;
+ };
+ step2 {
+ type = "pwm";
+ id = "backlight";
+ enable;
+ };
+ step3 {
+ type = "gpio";
+ gpio = < 28 0>;
+ value = <1>;
+ };
+ };
+
+ power-off {
+ step0 {
+ type = "gpio";
+ gpio = < 28 0>;
+ value = <0>;
+ };
+ step1 {
+ type = "pwm";
+ id = "backlight";
+ disable;
+ };
+ step2 {
+ type = "delay";
+ delay = <1>;
+ };
+ step3 {
+ type = "regulator";
+ id = "power";
+ disable;
+ };
+ };
+ };
};
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..a6b0640 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -240,6 +240,7 @@ config BACKLIGHT_CARILLO_RANCH
config BACKLIGHT_PWM
tristate "Generic PWM based Backlight Driver"
depends on PWM
+ select POWER_SEQ
help
If you have a LCD backlight adjustable by PWM, say Y to enable
this driver.
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 069983c..cfc0780 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -27,6 +27,12 @@ struct pwm_bl_data {
unsigned intperiod;
unsigned intlth_brightness;
unsigned int*levels;
+ boolenabled;
+ struct
[PATCH v8 3/3] Take maintainership of power sequences
Add entry for power sequences into MAINTAINERS with all the needed contact and SCM info. Signed-off-by: Alexandre Courbot --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 59203e7..c86a93b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5696,6 +5696,16 @@ F: fs/timerfd.c F: include/linux/timer* F: kernel/*timer* +POWER SEQUENCES +M: Alexandre Courbot +S: Maintained +W: https://github.com/Gnurou/linux-power-seqs +T: git https://github.com/Gnurou/linux-power-seqs.git +F: Documentation/devicetree/bindings/power/power_seq.txt +F: Documentation/power/power_seq.txt +F: include/linux/power_seq.h +F: drivers/power/power_seq/ + POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS M: Anton Vorontsov M: David Woodhouse -- 1.8.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 v8 1/3] Runtime Interpreted Power Sequences
Some device drivers (e.g. panel or backlights) need to follow precise
sequences for powering on and off, involving GPIOs, regulators, PWMs
with a precise powering order and delays to respect between steps.
These sequences are device-specific, and do not belong to a particular
driver - therefore they have been performed by board-specific hook
functions to far.
With the advent of the device tree and of ARM kernels that are not
board-tied, we cannot rely on these board-specific hooks anymore but
need a way to implement these sequences in a portable manner. This patch
introduces a simple interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
Signed-off-by: Alexandre Courbot
Reviewed-by: Stephen Warren
Reviewed-by: Mark Brown
---
.../devicetree/bindings/power/power_seq.txt| 121 +++
Documentation/power/power_seq.txt | 253 ++
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/power/power_seq/Kconfig| 2 +
drivers/power/power_seq/Makefile | 1 +
drivers/power/power_seq/power_seq.c| 376 +
drivers/power/power_seq/power_seq_delay.c | 65
drivers/power/power_seq/power_seq_gpio.c | 94 ++
drivers/power/power_seq/power_seq_pwm.c| 82 +
drivers/power/power_seq/power_seq_regulator.c | 83 +
include/linux/power_seq.h | 203 +++
12 files changed, 1282 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_seq.txt
create mode 100644 Documentation/power/power_seq.txt
create mode 100644 drivers/power/power_seq/Kconfig
create mode 100644 drivers/power/power_seq/Makefile
create mode 100644 drivers/power/power_seq/power_seq.c
create mode 100644 drivers/power/power_seq/power_seq_delay.c
create mode 100644 drivers/power/power_seq/power_seq_gpio.c
create mode 100644 drivers/power/power_seq/power_seq_pwm.c
create mode 100644 drivers/power/power_seq/power_seq_regulator.c
create mode 100644 include/linux/power_seq.h
diff --git a/Documentation/devicetree/bindings/power/power_seq.txt
b/Documentation/devicetree/bindings/power/power_seq.txt
new file mode 100644
index 000..7880a6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_seq.txt
@@ -0,0 +1,121 @@
+Runtime Interpreted Power Sequences
+===
+
+Power sequences are sequential descriptions of actions to be performed on
+power-related resources. Having these descriptions in a well-defined data
format
+allows us to take much of the board- or device- specific power control code out
+of the kernel and place it into the device tree instead, making kernels less
+board-dependant.
+
+A device typically makes use of multiple power sequences, for different
purposes
+such as powering on and off. All the power sequences of a given device are
+grouped into a set. In the device tree, this set is a sub-node of the device
+node named "power-sequences".
+
+Power Sequences Structure
+-
+Every device that makes use of power sequences must have a "power-sequences"
+node into which individual power sequences are declared as sub-nodes. The name
+of the node becomes the name of the sequence within the power sequences
+framework.
+
+Similarly, each power sequence declares its steps as sub-nodes of itself. Steps
+must be named sequentially, with the first step named step0, the second step1,
+etc. Failure to follow this rule will result in a parsing error.
+
+Power Sequences Steps
+-
+Steps of a sequence describe an action to be performed on a resource. They
+always include a "type" property which indicates what kind of resource this
+step works on. Depending on the resource type, additional properties are
defined
+to control the action to be performed.
+
+"delay" type required properties:
+ - delay: delay to wait (in microseconds)
+
+"regulator" type required properties:
+ - id: name of the regulator to use.
+ - enable / disable: one of these two empty properties must be present to
+ enable or disable the resource
+
+"pwm" type required properties:
+ - id: name of the PWM to use.
+ - enable / disable: one of these two empty properties must be present to
+ enable or disable the resource
+
+"gpio" type required properties:
+ - gpio: phandle of the GPIO to use.
+ - value: value this GPIO should take. Must be 0 or 1.
+
+Example
+---
+Here are example sequences declared within a backlight device that use all the
+supported resources types:
+
+ backlight {
+ compatible = "pwm-backlight";
+ ...
+
+ /* resources used by the power sequences */
+ pwms = < 2 500>;
+ pwm-names = "backlight";
+
[PATCH v8 0/3] Runtime Interpreted Power Sequences
Hopefully the final series before the feature gets merged. Anton Vorontsov kindly accepted to take it into his tree, so this series is mostly a call for acks, tests and reviews notices before the merge window for 3.8 opens. If you are interested in seeing this feature, please add your name. This series also adds an entry for the subsystem into MAINTAINERS, setting me as the person in charge. Changes from v7: - fix bug reported by Tony Prisk - add MAINTAINERS entry Alexandre Courbot (3): Runtime Interpreted Power Sequences pwm_backlight: use power sequences Take maintainership of power sequences .../devicetree/bindings/power/power_seq.txt| 121 +++ .../bindings/video/backlight/pwm-backlight.txt | 63 +++- Documentation/power/power_seq.txt | 253 ++ MAINTAINERS| 10 + drivers/power/Kconfig | 1 + drivers/power/Makefile | 1 + drivers/power/power_seq/Kconfig| 2 + drivers/power/power_seq/Makefile | 1 + drivers/power/power_seq/power_seq.c| 376 + drivers/power/power_seq/power_seq_delay.c | 65 drivers/power/power_seq/power_seq_gpio.c | 94 ++ drivers/power/power_seq/power_seq_pwm.c| 82 + drivers/power/power_seq/power_seq_regulator.c | 83 + drivers/video/backlight/Kconfig| 1 + drivers/video/backlight/pwm_bl.c | 160 +++-- include/linux/power_seq.h | 203 +++ include/linux/pwm_backlight.h | 18 +- 17 files changed, 1494 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/power_seq.txt create mode 100644 Documentation/power/power_seq.txt create mode 100644 drivers/power/power_seq/Kconfig create mode 100644 drivers/power/power_seq/Makefile create mode 100644 drivers/power/power_seq/power_seq.c create mode 100644 drivers/power/power_seq/power_seq_delay.c create mode 100644 drivers/power/power_seq/power_seq_gpio.c create mode 100644 drivers/power/power_seq/power_seq_pwm.c create mode 100644 drivers/power/power_seq/power_seq_regulator.c create mode 100644 include/linux/power_seq.h -- 1.8.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] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
commit 392142 moved event buffer allocation out of dwc3_core_init() but
event buffer allocation uses the cached copy of hwparams to determine
the number of event buffers and the caching is done in dwc3_core_init.
So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so
that dwc3_alloc_event_buffers sees the correct number of event buffers.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..88e8d31 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -356,8 +356,6 @@ static int __devinit dwc3_core_init(struct dwc3 *dwc)
dwc3_core_soft_reset(dwc);
- dwc3_cache_hwparams(dwc);
-
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
reg &= ~DWC3_GCTL_DISSCRAMBLE;
@@ -498,6 +496,8 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
pm_runtime_get_sync(dev);
pm_runtime_forbid(dev);
+ dwc3_cache_hwparams(dwc);
+
ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
if (ret) {
dev_err(dwc->dev, "failed to allocate event buffers\n");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script
On Friday 16 November 2012 01:00 AM, Ralf Baechle wrote: > On Thu, Nov 15, 2012 at 05:49:57PM +, James Hogan wrote: > >> On 07/11/12 09:47, Vineet Gupta wrote: >>> +config ARC >> I just came across arch/mips/Kconfig which also defines ARC (and ARC32). >> It's only used within arch/mips/, however it's probably more likely that >> your ARC/CONFIG_ARC will find it's way into the generic bits of the >> kernel which could get hit when the other ARC is defined. >> >> Perhaps it's worth getting the other ARC renamed just in case? > The MIPS world surely isn't as attached to the CONFIG_ARC config symbol > as Synopsis so I'm going to rename CONFIG_ARC and a few other firmware > related config symbols to use a consistent prefix of CONFIG_FW_. Thanks Ralf ! -Vineet > Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: extend line continuation test
On Friday, November 16, 2012 3:21 PM, Joe Perches wrote
>
> Preprocessor directives and asm statements should be
> allowed to have a line continuation.
>
> Signed-off-by: Joe Perches
Hi Joe Perches,
It works properly. :)
Tested-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> scripts/checkpatch.pl |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d2d5ba1..019f9be 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3006,10 +3006,12 @@ sub process {
> }
> }
>
> -# check for line continuations outside of #defines
> +# check for line continuations outside of #defines, preprocessor #, and asm
>
> } else {
> if ($prevline !~ /^..*\\$/ &&
> + $line !~ /^\+\s*\#*.*\\$/ &&# preprocessor
> + $line !~ /^\+.*\b(__asm__|asm)\b.*\\$/ && # asm
> $line =~ /^\+.*\\$/) {
> WARN("LINE_CONTINUATIONS",
>"Avoid unnecessary line continuations\n" .
> $herecurr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] paride: enable extra verbose debugging
This debug settings here are:
0 - Off
1 - Some
2 - Lots
The module_param() was incorrectly set to bool and later the variable
was updated to be bool to match. Really they should both be int.
Signed-off-by: Dan Carpenter
diff --git a/drivers/block/paride/pg.c b/drivers/block/paride/pg.c
index 4a27b1d..ab99ac9 100644
--- a/drivers/block/paride/pg.c
+++ b/drivers/block/paride/pg.c
@@ -137,7 +137,7 @@
*/
-static bool verbose = 0;
+static int verbose;
static int major = PG_MAJOR;
static char *name = PG_NAME;
static int disable = 0;
@@ -168,7 +168,7 @@ enum {D_PRT, D_PRO, D_UNI, D_MOD, D_SLV, D_DLY};
#include
-module_param(verbose, bool, 0644);
+module_param(verbose, int, 0644);
module_param(major, int, 0);
module_param(name, charp, 0);
module_param_array(drive0, int, NULL, 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 7/8] ata: highbank: mark ahci_highbank_probe as __devinit
Hi Jeff, On Fri, Nov 16, 2012 at 2:44 AM, Jeff Garzik wrote: > On 11/06/2012 04:55 PM, Arnd Bergmann wrote: >> >> The ahci_highbank_probe function is incorrectly marked as __init, >> which means it can get discarded at boot time, which might be >> a problem if for some reason the device only becomes operational >> after loading another module. >> >> Using __devinit instead avoids seeing this warning for every build: >> >> WARNING: vmlinux.o(.data+0xf7b0): Section mismatch in reference from the >> variable ahci_highbank_driver to the function >> .init.text:ahci_highbank_probe() >> The variable ahci_highbank_driver references >> the function __init ahci_highbank_probe() >> If the reference is valid then annotate the >> variable with __init* or __refdata (see linux/init.h) or name the >> variable: >> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console >> >> Signed-off-by: Arnd Bergmann >> Cc: Mark Langsdorf >> Cc: Rob Herring >> Cc: Jeff Garzik >> --- >> drivers/ata/sata_highbank.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > applied I have also sent the same fix: https://patchwork.kernel.org/patch/1562141/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: extend line continuation test
Preprocessor directives and asm statements should be
allowed to have a line continuation.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d2d5ba1..019f9be 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3006,10 +3006,12 @@ sub process {
}
}
-# check for line continuations outside of #defines
+# check for line continuations outside of #defines, preprocessor #, and asm
} else {
if ($prevline !~ /^..*\\$/ &&
+ $line !~ /^\+\s*\#*.*\\$/ &&# preprocessor
+ $line !~ /^\+.*\b(__asm__|asm)\b.*\\$/ && # asm
$line =~ /^\+.*\\$/) {
WARN("LINE_CONTINUATIONS",
"Avoid unnecessary line continuations\n" .
$herecurr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v4+ hot_track 02/19] vfs: initialize and free data structures
On Wed, Nov 7, 2012 at 6:24 AM, David Sterba wrote:
> On Mon, Oct 29, 2012 at 12:30:44PM +0800, zwu.ker...@gmail.com wrote:
>> +/* Frees the entire hot_range_tree. */
>> +static void hot_inode_item_free(struct kref *kref)
>> +{
>> + struct hot_comm_item *comm_item = container_of(kref,
>> + struct hot_comm_item, refs);
>> + struct hot_inode_item *he = container_of(comm_item,
>> + struct hot_inode_item, hot_inode);
>> +
>> + hot_range_tree_free(he);
>> + radix_tree_delete(he->hot_inode_tree, he->i_ino);
>
> void *radix_tree_delete(struct radix_tree_root *root, unsigned long index)
>
> and he::i_ino is u64, this will not work when
> sizeof(unsigned long) != sizeof(u64) (iirc this is a known limitation of
> radix tree implementation). This will work on 64bit only, not sure if
> this is intentional.
Fixed, thanks.
>
>> + kmem_cache_free(hot_inode_item_cachep, he);
>> +}
>> +
>> +/* Frees the entire hot_inode_tree. */
>> +static void hot_inode_tree_exit(struct hot_info *root)
>> +{
>> + struct hot_inode_item *hi_nodes[8];
>> + u64 ino = 0;
>> + int i, n;
>
> nitpick, put the declarations on separate lines
>
>> +
>> + while (1) {
>> + spin_lock(>lock);
>> + n = radix_tree_gang_lookup(>hot_inode_tree,
>> +(void **)hi_nodes, ino,
>> +ARRAY_SIZE(hi_nodes));
>> + if (!n) {
>> + spin_unlock(>lock);
>> + break;
>> + }
>> +
>> + ino = hi_nodes[n - 1]->i_ino + 1;
>> + for (i = 0; i < n; i++)
>> + hot_inode_item_put(hi_nodes[i]);
>> + spin_unlock(>lock);
>> + }
>> +}
>> +
>> /*
>> * Initialize kmem cache for hot_inode_item and hot_range_item.
>> */
>> @@ -106,3 +197,36 @@ err:
>> kmem_cache_destroy(hot_inode_item_cachep);
>> }
>> EXPORT_SYMBOL_GPL(hot_cache_init);
>> +
>> +/*
>> + * Initialize the data structures for hot data tracking.
>> + */
>> +int hot_track_init(struct super_block *sb)
>> +{
>> + struct hot_info *root;
>> + int ret = -ENOMEM;
>> +
>> + root = kzalloc(sizeof(struct hot_info), GFP_NOFS);
>> + if (!root) {
>> + printk(KERN_ERR "%s: Failed to malloc memory for "
>> + "hot_info\n", __func__);
>> + return ret;
>
> minor: you can drop the variable ret and just reurn ENOMEM here
>
>> + }
>> +
>> + sb->s_hot_root = root;
>> + hot_inode_tree_init(root);
>> +
>> + printk(KERN_INFO "VFS: Turning on hot data tracking\n");
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hot_track_init);
>
> david
--
Regards,
Zhi Yong Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/17] cgroup: create directory before linking while creating a new cgroup
On 2012/11/15 3:04, Tejun Heo wrote: > Hello, Li. > > On Wed, Nov 14, 2012 at 11:20:47AM +0800, Li Zefan wrote: >>> It also removes the need to check whether cgroup->dentry is %NULL in >>> cgroup_path. If a cgroup is visible, its dentry is guaranteed to be >>> visible too. >> >> I'm afraid this isn't safe. >> >> The cgroup is visible to a controller soon after ss->create(), and then >> the controller might call cgroup_path() while cgrp->dentry is still NULL. > > Hmmm... I can't find any case where ss->create() is calling > cgroup_path(). Do you remember which one that was? > I meant cgroup_create() may race with cgroup_path(). We used to have this race: (cpu0) (cpu1) mkdir cat /proc/sched_debug cgroup_create() cpu_cgroup_create() register_fair_sched_group() list_add_rcu(...) print_cfs_stats() for_each_leaf_cfs_rq() print_cfs_rq() cgroup_path() css->cgroup = cgroup; cgroup->dentry = dentry; In this case, cgroup_path() might access NULL cgroup or NULL dentry. But I've looked the current scheduler code, no race anymore, because now the cfs_rq won't be added to the gloal list until there's task in the cgroup. (in the old time it was added to the list when creating a cgroup) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
As I mentioned, we are going to be rewriting this part of the code, so I would
rather wait to until then to make changes. However, this looks like a
reasonable approach to the error check, at first glance.
Thanks,
Bob
> -Original Message-
> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
> Sent: Thursday, November 15, 2012 9:47 PM
> To: Moore, Robert
> Cc: LKML
> Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit
> address of FACS/DSDT all have value but not equal to each other
>
> Bob,
> How about moving some checking code as following patch ?
>
> From f46d539d81c763aa4e3e98f9fc1e94e0af48bd15 Mon Sep 17 00:00:00
> 2001
> From: ethan.zhao
> Date: Sat, 17 Nov 2012 00:48:41 -0800
> Subject: [PATCH]acpica/tbfadt.c Move some checking and 32bit to 64bit
> assignment code from acpi_tb_validate_fadt() to acpi_tb_convert_fadt to
> make the logic clearer and void multiple same kind of warning.
>
>
> Signed-off-by: ethan.zhao
> ---
> drivers/acpi/acpica/tbfadt.c | 51 ++---
>
> 1 files changed, 18 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index f23f512..dd18aba 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -388,18 +388,30 @@ static void acpi_tb_convert_fadt(void)
>*/
> if (!acpi_gbl_FADT.Xfacs) {
> acpi_gbl_FADT.Xfacs = (u64) acpi_gbl_FADT.facs;
> - } else if (acpi_gbl_FADT.facs &&
> + } else if ((acpi_gbl_FADT.facs && acpi_gbl_FADT.Xfacs) &&
> (acpi_gbl_FADT.Xfacs != (u64) acpi_gbl_FADT.facs)) {
> - ACPI_WARNING((AE_INFO,
> - "32/64 FACS address mismatch in FADT - two FACS
> tables!"));
> + ACPI_BIOS_WARNING((AE_INFO,
> + "32/64X FACS address mismatch in FADT
> - "
> + "0x%8.8X/0x%8.8X%8.8X, using 32",
> + acpi_gbl_FADT.facs,
> +
> +ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
> +
> + acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
> +
> }
>
> if (!acpi_gbl_FADT.Xdsdt) {
> acpi_gbl_FADT.Xdsdt = (u64) acpi_gbl_FADT.dsdt;
> - } else if (acpi_gbl_FADT.dsdt &&
> + } else if ((acpi_gbl_FADT.dsdt && acpi_gbl_FADT.Xdsdt) &&
> (acpi_gbl_FADT.Xdsdt != (u64) acpi_gbl_FADT.dsdt)) {
> - ACPI_WARNING((AE_INFO,
> - "32/64 DSDT address mismatch in FADT - two DSDT
> tables!"));
> + ACPI_BIOS_WARNING((AE_INFO,
> + "32/64X DSDT address mismatch in FADT
> - "
> + "0x%8.8X/0x%8.8X%8.8X, using 32",
> + acpi_gbl_FADT.dsdt,
> +
> +ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
> +
> +acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
> +
> }
>
> /*
> @@ -507,33 +519,6 @@ static void acpi_tb_validate_fadt(void)
> u8 length;
> u32 i;
>
> - /*
> - * Check for FACS and DSDT address mismatches. An address mismatch
> between
> - * the 32-bit and 64-bit address fields
> (FIRMWARE_CTRL/X_FIRMWARE_CTRL and
> - * DSDT/X_DSDT) would indicate the presence of two FACS or two DSDT
> tables.
> - */
> - if (acpi_gbl_FADT.facs &&
> - (acpi_gbl_FADT.Xfacs != (u64)acpi_gbl_FADT.facs)) {
> - ACPI_BIOS_WARNING((AE_INFO,
> -"32/64X FACS address mismatch in FADT - "
> -"0x%8.8X/0x%8.8X%8.8X, using 32",
> -acpi_gbl_FADT.facs,
> -ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
> -
> - acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
> - }
> -
> - if (acpi_gbl_FADT.dsdt &&
> - (acpi_gbl_FADT.Xdsdt != (u64)acpi_gbl_FADT.dsdt)) {
> - ACPI_BIOS_WARNING((AE_INFO,
> -"32/64X DSDT address mismatch in FADT - "
> -"0x%8.8X/0x%8.8X%8.8X, using 32",
> -acpi_gbl_FADT.dsdt,
> -ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
> -
> - acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
> - }
> -
> /* If Hardware Reduced flag is set, we are all done */
>
> if (acpi_gbl_reduced_hardware) {
> --
> 1.7.1
>
>
> Thanks,
> Ethan
>
>
> On Fri, Nov 16, 2012 at 11:49 AM, Moore, Robert
> wrote:
> > No decision(s) yet, we are still investigating
> >
> >
> >> -Original Message-
> >> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
> >> Sent: Thursday, November 15, 2012 7:47 PM
> >> To: Moore, Robert
> >> Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit
> >> address of FACS/DSDT all have value but not equal to each other
> >>
> >> Bob,
> >> I read the discussion you have done
> >>
> >>
Re: [PATCH 1/5] ata: suspend/resume callbacks should be conditionally compiled on CONFIG_PM_SLEEP
On 10/16/2012 10:59 AM, Yuanhan Liu wrote: This will fix warnings like following when CONFIG_PM_SLEEP is not set: warning: 'xxx_suspend' defined but not used [-Wunused-function] warning: 'xxx_resume' defined but not used [-Wunused-function] Because SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) Only references the callbacks on CONFIG_PM_SLEEP (instead of CONFIG_PM). Cc: Jeff Garzik Cc: Viresh Kumar Cc: linux-...@vger.kernel.org Signed-off-by: Yuanhan Liu Signed-off-by: Fengguang Wu --- drivers/ata/ahci_platform.c |2 +- drivers/ata/pata_arasan_cf.c |2 +- drivers/ata/sata_highbank.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] drivers: uio_dmem_genirq: Don't mix address spaces for dynamic region vaddr
Assigning the virtual address returned from dma_alloc_coherent to the the
internal_addr element of uioinfo produces the following sparse errors since
internal_addr is a void __iomem * and dma_alloc_coherent returns void *.
+ drivers/uio/uio_dmem_genirq.c:65:39: sparse: incorrect type in assignment
(different address spaces)
drivers/uio/uio_dmem_genirq.c:65:39:expected void [noderef]
*internal_addr
drivers/uio/uio_dmem_genirq.c:65:39:got void *[assigned] addr
+ drivers/uio/uio_dmem_genirq.c:93:17: sparse: incorrect type in argument 3
(different address spaces)
drivers/uio/uio_dmem_genirq.c:93:17:expected void *vaddr
drivers/uio/uio_dmem_genirq.c:93:17:got void [noderef] *internal_addr
Store the void * in the driver's private data instead.
Reported-by: Fengguang Wu
Signed-off-by: Damian Hobson-Garcia
---
drivers/uio/uio_dmem_genirq.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index 4d4dd00..d8bbe07 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -37,6 +37,7 @@ struct uio_dmem_genirq_platdata {
struct platform_device *pdev;
unsigned int dmem_region_start;
unsigned int num_dmem_regions;
+ void *dmem_region_vaddr[MAX_UIO_MAPS];
struct mutex alloc_lock;
unsigned int refcnt;
};
@@ -46,6 +47,7 @@ static int uio_dmem_genirq_open(struct uio_info *info, struct
inode *inode)
struct uio_dmem_genirq_platdata *priv = info->priv;
struct uio_mem *uiomem;
int ret = 0;
+ int dmem_region = priv->dmem_region_start;
uiomem = >uioinfo->mem[priv->dmem_region_start];
@@ -61,8 +63,7 @@ static int uio_dmem_genirq_open(struct uio_info *info, struct
inode *inode)
ret = -ENOMEM;
break;
}
-
- uiomem->internal_addr = addr;
+ priv->dmem_region_vaddr[dmem_region++] = addr;
++uiomem;
}
priv->refcnt++;
@@ -77,6 +78,7 @@ static int uio_dmem_genirq_release(struct uio_info *info,
struct inode *inode)
{
struct uio_dmem_genirq_platdata *priv = info->priv;
struct uio_mem *uiomem;
+ int dmem_region = priv->dmem_region_start;
/* Tell the Runtime PM code that the device has become idle */
pm_runtime_put_sync(>pdev->dev);
@@ -91,7 +93,8 @@ static int uio_dmem_genirq_release(struct uio_info *info,
struct inode *inode)
break;
dma_free_coherent(>pdev->dev, uiomem->size,
- uiomem->internal_addr, uiomem->addr);
+ priv->dmem_region_vaddr[dmem_region++],
+ uiomem->addr);
uiomem->addr = DMA_ERROR_CODE;
++uiomem;
}
--
1.7.5.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 4/4] drivers: uio: Only allocate new private data when probing device tree node
The same condition should be used both when allocating and freeing the
driver private data. When dev.of_node is non NULL, allocate a new
private data structure, otherwise use the values from the platform data.
Reported-by: Fengguang Wu
Signed-off-by: Damian Hobson-Garcia
---
drivers/uio/uio_dmem_genirq.c |2 +-
drivers/uio/uio_pdrv_genirq.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index bbdf925..252434c 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -153,7 +153,7 @@ static int uio_dmem_genirq_probe(struct platform_device
*pdev)
int ret = -EINVAL;
int i;
- if (!uioinfo) {
+ if (pdev->dev.of_node) {
int irq;
/* alloc uioinfo for one device */
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index 42202cd..45fcceb 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/drivers/uio/uio_pdrv_genirq.c
@@ -102,7 +102,7 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
int ret = -EINVAL;
int i;
- if (!uioinfo) {
+ if (pdev->dev.of_node) {
int irq;
/* alloc uioinfo for one device */
--
1.7.5.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 3/4] drivers: uio_dmem_genirq: Allow partial success when opening device
The uio device should not fail on open just because one memory allocation
fails. The device might export several regions, the failure of some of
which may or may not be a problem for the user space driver. Failing
regions will remain unmapped, and successful regions will be mapped and
exported to user space. Also deals with the case where failing to map
a region after successfully allocating others would not unmap the
successfully allocated regions before dying.
Signed-off-by: Damian Hobson-Garcia
---
drivers/uio/uio_dmem_genirq.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index 7be8d04..bbdf925 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -62,8 +62,6 @@ static int uio_dmem_genirq_open(struct uio_info *info, struct
inode *inode)
(dma_addr_t *)>addr, GFP_KERNEL);
if (!addr) {
uiomem->addr = DMEM_MAP_ERROR;
- ret = -ENOMEM;
- break;
}
priv->dmem_region_vaddr[dmem_region++] = addr;
++uiomem;
@@ -93,11 +91,13 @@ static int uio_dmem_genirq_release(struct uio_info *info,
struct inode *inode)
while (!priv->refcnt && uiomem < >uioinfo->mem[MAX_UIO_MAPS]) {
if (!uiomem->size)
break;
-
- dma_free_coherent(>pdev->dev, uiomem->size,
- priv->dmem_region_vaddr[dmem_region++],
- uiomem->addr);
+ if (priv->dmem_region_vaddr[dmem_region]) {
+ dma_free_coherent(>pdev->dev, uiomem->size,
+ priv->dmem_region_vaddr[dmem_region],
+ uiomem->addr);
+ }
uiomem->addr = DMEM_MAP_ERROR;
+ ++dmem_region;
++uiomem;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] drivers: uio_dmem_genirq: Don't use DMA_ERROR_CODE to indicate unmapped regions
DMA_ERROR_CODE is not defined on all architectures and is architecture
specific. Instead, use the constant, ~0 to indicate unmapped regions.
Reported-by: Fengguang Wu
Reported-by: Geert Uytterhoeven
Signed-off-by: Damian Hobson-Garcia
---
Documentation/DocBook/uio-howto.tmpl |2 +-
drivers/uio/uio_dmem_genirq.c|6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/uio-howto.tmpl
b/Documentation/DocBook/uio-howto.tmpl
index fdbf86f..ddb05e9 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -771,7 +771,7 @@ framework to set up sysfs files for this region. Simply
leave it alone.
/sys/class/uio/uioX/maps/mapY/*.
The dynmaic memory regions will be freed when the UIO device file is
closed. When no processes are holding the device file open, the address
- returned to userspace is DMA_ERROR_CODE.
+ returned to userspace is ~0.
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index d8bbe07..7be8d04 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -29,6 +29,7 @@
#include
#define DRIVER_NAME "uio_dmem_genirq"
+#define DMEM_MAP_ERROR (~0)
struct uio_dmem_genirq_platdata {
struct uio_info *uioinfo;
@@ -60,6 +61,7 @@ static int uio_dmem_genirq_open(struct uio_info *info, struct
inode *inode)
addr = dma_alloc_coherent(>pdev->dev, uiomem->size,
(dma_addr_t *)>addr, GFP_KERNEL);
if (!addr) {
+ uiomem->addr = DMEM_MAP_ERROR;
ret = -ENOMEM;
break;
}
@@ -95,7 +97,7 @@ static int uio_dmem_genirq_release(struct uio_info *info,
struct inode *inode)
dma_free_coherent(>pdev->dev, uiomem->size,
priv->dmem_region_vaddr[dmem_region++],
uiomem->addr);
- uiomem->addr = DMA_ERROR_CODE;
+ uiomem->addr = DMEM_MAP_ERROR;
++uiomem;
}
@@ -238,7 +240,7 @@ static int uio_dmem_genirq_probe(struct platform_device
*pdev)
break;
}
uiomem->memtype = UIO_MEM_PHYS;
- uiomem->addr = DMA_ERROR_CODE;
+ uiomem->addr = DMEM_MAP_ERROR;
uiomem->size = pdata->dynamic_region_sizes[i];
++uiomem;
}
--
1.7.5.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 0/4] UIO platform device fixes
Here are a few fixes for the uio_dmem_genirq driver which allows for dynamic allocation/deallocation of UIO memory resources via the DMA-mapping API. Damian Hobson-Garcia (4): drivers: uio_dmem_genirq: Don't mix address spaces for dynamic region vaddr drivers: uio_dmem_genirq: Don't use DMA_ERROR_CODE to indicate unmapped regions drivers: uio_dmem_genirq: Allow partial success when opening device drivers: uio: Only allocate new private data when probing device tree node Documentation/DocBook/uio-howto.tmpl |2 +- drivers/uio/uio_dmem_genirq.c| 25 +++-- drivers/uio/uio_pdrv_genirq.c|2 +- 3 files changed, 17 insertions(+), 12 deletions(-) -- 1.7.5.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 ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Bob,
How about moving some checking code as following patch ?
From f46d539d81c763aa4e3e98f9fc1e94e0af48bd15 Mon Sep 17 00:00:00 2001
From: ethan.zhao
Date: Sat, 17 Nov 2012 00:48:41 -0800
Subject: [PATCH]acpica/tbfadt.c Move some checking and 32bit to 64bit
assignment code from acpi_tb_validate_fadt() to
acpi_tb_convert_fadt to make the logic clearer and void multiple same
kind of warning.
Signed-off-by: ethan.zhao
---
drivers/acpi/acpica/tbfadt.c | 51 ++---
1 files changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index f23f512..dd18aba 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -388,18 +388,30 @@ static void acpi_tb_convert_fadt(void)
*/
if (!acpi_gbl_FADT.Xfacs) {
acpi_gbl_FADT.Xfacs = (u64) acpi_gbl_FADT.facs;
- } else if (acpi_gbl_FADT.facs &&
+ } else if ((acpi_gbl_FADT.facs && acpi_gbl_FADT.Xfacs) &&
(acpi_gbl_FADT.Xfacs != (u64) acpi_gbl_FADT.facs)) {
- ACPI_WARNING((AE_INFO,
- "32/64 FACS address mismatch in FADT - two FACS tables!"));
+ ACPI_BIOS_WARNING((AE_INFO,
+ "32/64X FACS address mismatch in FADT - "
+ "0x%8.8X/0x%8.8X%8.8X, using 32",
+ acpi_gbl_FADT.facs,
+ ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
+
+ acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
+
}
if (!acpi_gbl_FADT.Xdsdt) {
acpi_gbl_FADT.Xdsdt = (u64) acpi_gbl_FADT.dsdt;
- } else if (acpi_gbl_FADT.dsdt &&
+ } else if ((acpi_gbl_FADT.dsdt && acpi_gbl_FADT.Xdsdt) &&
(acpi_gbl_FADT.Xdsdt != (u64) acpi_gbl_FADT.dsdt)) {
- ACPI_WARNING((AE_INFO,
- "32/64 DSDT address mismatch in FADT - two DSDT tables!"));
+ ACPI_BIOS_WARNING((AE_INFO,
+ "32/64X DSDT address mismatch in FADT - "
+ "0x%8.8X/0x%8.8X%8.8X, using 32",
+ acpi_gbl_FADT.dsdt,
+ ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
+
+acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
+
}
/*
@@ -507,33 +519,6 @@ static void acpi_tb_validate_fadt(void)
u8 length;
u32 i;
- /*
-* Check for FACS and DSDT address mismatches. An address mismatch
between
-* the 32-bit and 64-bit address fields (FIRMWARE_CTRL/X_FIRMWARE_CTRL
and
-* DSDT/X_DSDT) would indicate the presence of two FACS or two DSDT
tables.
-*/
- if (acpi_gbl_FADT.facs &&
- (acpi_gbl_FADT.Xfacs != (u64)acpi_gbl_FADT.facs)) {
- ACPI_BIOS_WARNING((AE_INFO,
- "32/64X FACS address mismatch in FADT - "
- "0x%8.8X/0x%8.8X%8.8X, using 32",
- acpi_gbl_FADT.facs,
- ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
-
- acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
- }
-
- if (acpi_gbl_FADT.dsdt &&
- (acpi_gbl_FADT.Xdsdt != (u64)acpi_gbl_FADT.dsdt)) {
- ACPI_BIOS_WARNING((AE_INFO,
- "32/64X DSDT address mismatch in FADT - "
- "0x%8.8X/0x%8.8X%8.8X, using 32",
- acpi_gbl_FADT.dsdt,
- ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
-
- acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
- }
-
/* If Hardware Reduced flag is set, we are all done */
if (acpi_gbl_reduced_hardware) {
--
1.7.1
Thanks,
Ethan
On Fri, Nov 16, 2012 at 11:49 AM, Moore, Robert wrote:
> No decision(s) yet, we are still investigating
>
>
>> -Original Message-
>> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
>> Sent: Thursday, November 15, 2012 7:47 PM
>> To: Moore, Robert
>> Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit
>> address of FACS/DSDT all have value but not equal to each other
>>
>> Bob,
>> I read the discussion you have done
>>
>> https://www.acpica.org/bugzilla/show_bug.cgi?id=885
>>
>> Why method do you prefer ?
>>
>> Thanks,
>> Ethan
>>
>> On Fri, Nov 16, 2012 at 11:38 AM, Ethan Zhao
>> wrote:
>> > Bob,
>> > In fact, you know if 32bit and 64bit address are all valid but not
>> > equal to each other, that does not follow ACPI 4&5 ,not follow 3 too.
>> > Do you mean we need to guess why they declare two different
>> > FACS/DSDT, and so kernel should collect some clue to figure out why ?
>> > that is amazing thing to keep system to work though its buggy BIOS.
>> >
>> > Ethan
>> >
>> >
>> > On Fri, Nov 16, 2012 at
Re: [PATCH v2 0/6] Device tree updates for host1x support
On Friday 16 November 2012 05:07:53 Thierry Reding wrote: > This second version of this patch series splits the patches up into more > logical chunks as requested by Stephen. Instead of renaming the matching > parameters in the clock driver, this version renames the AUXDATA entries > to match what the clock driver expects. Furthermore the host1x clock is > initialized to 150 MHz instead of the unsupported 144 MHz. Tested-and-acked-by: Alexandre Courbot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 16/31] ARC: Signal handling
> + if (insyscall) {
> + /* No handler for syscall: restart it */
> + if (regs->r0 == -ERESTARTNOHAND ||
> + regs->r0 == -ERESTARTSYS || regs->r0 == -ERESTARTNOINTR) {
> + regs->r0 = regs->orig_r0;
> + regs->ret -= 4;
> + } else if (regs->r0 == -ERESTART_RESTARTBLOCK) {
> + regs->r8 = __NR_restart_syscall;
> + regs->ret -= 4;
> + }
What's to prevent double decrement on ->ret if two signals arrive? Note
that e.g. x86 gets away with similar code only because it uses the same
register for syscall number and return value; since none of -ERESTART...
is a valid syscall number, we either won't get into an analog of that code at
all (-ENOSYS is not restart-worthy) or will revert to a value that is
a valid syscall number, so all subsequent do_signal() calls will not hit
that code. This is subtle and unfortunately not spelled out in the
architectures where it is enough.
You need to make sure that after the first restart in_syscall() will be false.
Same ought to be done in sigreturn(), BTW...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] memcg: get rid of once-per-second cache shrinking for dead memcgs
(2012/11/15 22:47), Glauber Costa wrote: > On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote: >> (2012/11/15 11:54), Glauber Costa wrote: >>> The idea is to synchronously do it, leaving it up to the shrinking >>> facilities in vmscan.c and/or others. Not actively retrying shrinking >>> may leave the caches alive for more time, but it will remove the ugly >>> wakeups. One would argue that if the caches have free objects but are >>> not being shrunk, it is because we don't need that memory yet. >>> >>> Signed-off-by: Glauber Costa >>> CC: Michal Hocko >>> CC: Kamezawa Hiroyuki >>> CC: Johannes Weiner >>> CC: Andrew Morton >> >> I agree this patch but can we have a way to see the number of unaccounted >> zombie cache usage for debugging ? >> >> Acked-by: KAMEZAWA Hiroyuki >> > Any particular interface in mind ? > Hmm, it's debug interface and having cgroup file may be bad. If it can be seen in bytes or some, /proc/vmstat ? out_of_track_slabs xxx. hm ? Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Add SystemBase Multi-2/PCI driver
On Thu, Nov 15, 2012 at 11:39:31PM -0500, Steven Rostedt wrote:
> I ported the driver supplied by SystemBase to mainline.
>
> As the driver had MODULE_LICENSE("GPL") it is declared as a GPL module
> and thus I have the right to distribute it upstream. Note, I did the
> bare minimum to get it working. It still needs a lot of loving.
Being in staging only requires 2 things, proper license, and it has to
build.
This fails on the second one:
In file included from drivers/staging/sb105x/sb_pci_mp.c:1:0:
drivers/staging/sb105x/sb_pci_mp.h:279:40: error: array type has incomplete
element type
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_startup’:
drivers/staging/sb105x/sb_pci_mp.c:546:26: error: invalid type argument of ‘->’
(have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_shutdown’:
drivers/staging/sb105x/sb_pci_mp.c:573:40: error: invalid type argument of ‘->’
(have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_change_speed’:
drivers/staging/sb105x/sb_pci_mp.c:596:14: error: wrong type argument to unary
exclamation mark
drivers/staging/sb105x/sb_pci_mp.c:599:10: error: incompatible types when
assigning to type ‘struct ktermios *’ from type ‘struct ktermios’
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_throttle’:
drivers/staging/sb105x/sb_pci_mp.c:734:18: error: invalid type argument of ‘->’
(have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_unthrottle’:
drivers/staging/sb105x/sb_pci_mp.c:750:18: error: invalid type argument of ‘->’
(have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_set_termios’:
drivers/staging/sb105x/sb_pci_mp.c:1277:35: error: invalid type argument of
‘->’ (have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c:1282:4: error: invalid type argument of ‘->’
(have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_update_termios’:
drivers/staging/sb105x/sb_pci_mp.c:1450:19: error: invalid type argument of
‘->’ (have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘mp_block_til_ready’:
drivers/staging/sb105x/sb_pci_mp.c:1476:24: error: invalid type argument of
‘->’ (have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c:1481:25: error: invalid type argument of
‘->’ (have ‘struct ktermios’)
drivers/staging/sb105x/sb_pci_mp.c: In function ‘multi_type’:
drivers/staging/sb105x/sb_pci_mp.c:2763:14: error: bit-field ‘’
width not an integer constant
In file included from drivers/staging/sb105x/sb_pci_mp.c:1:0:
drivers/staging/sb105x/sb_pci_mp.c: At top level:
drivers/staging/sb105x/sb_pci_mp.h:279:40: warning: ‘uart_config’ defined but
not used [-Wunused-variable]
drivers/staging/sb105x/sb_pci_mp.c: In function ‘multi_type’:
drivers/staging/sb105x/sb_pci_mp.c:2766:1: warning: control reaches end of
non-void function [-Wreturn-type]
make[3]: *** [drivers/staging/sb105x/sb_pci_mp.o] Error 1
make[2]: *** [drivers/staging/sb105x] Error 2
make[1]: *** [drivers/staging] Error 2
Care to redo this against my staging-next tree, or, even better,
linux-next, which contains a bunch of tty changes in it?
Or, if you want, I can take a whack at it to get it to build properly,
whichever is easier for you.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, all pretty normal, one TTM oops fix, one radeon, a few intel and a vmwgfx fix. Dave. The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7: Linux 3.7-rc5 (2012-11-11 13:44:33 +0100) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 6f755116c93ca35f496ccf1910dcd28cd16713e3: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-11-16 10:00:43 +1000) Akinobu Mita (1): drm/ttm: remove unneeded preempt_disable/enable Alex Deucher (1): drm/radeon: fix logic error in atombios_encoders.c Dan Carpenter (1): vmwgfx: return an -EFAULT if copy_to_user() fails Dave Airlie (2): Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Jani Nikula (3): drm/i915/crt: fix DPMS standby and suspend mode handling drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures drm/i915: do not ignore eDP bpc settings from vbt Zhao Yakui (1): ttm: Clear the ttm page allocated from high memory zone correctly drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 11 +++ drivers/gpu/drm/i915/intel_sdvo.c | 22 +++--- drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 - drivers/gpu/drm/ttm/ttm_tt.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 ++ 7 files changed, 38 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dt: tegra: cardhu: Add drm components
This patch adds the rgb and hdmi nodes which are necessary for
tegra drm driver.
Signed-off-by: Mark Zhang
---
arch/arm/boot/dts/tegra30-cardhu.dtsi | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index bdb2a66..9af6987 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -27,6 +27,25 @@
model = "NVIDIA Tegra30 Cardhu evaluation board";
compatible = "nvidia,cardhu", "nvidia,tegra30";
+ host1x {
+ dc@5420 {
+ rgb {
+ status = "okay";
+ nvidia,ddc-i2c-bus = <>;
+ };
+ };
+
+ hdmi {
+ status = "okay";
+
+ vdd-supply = <_3v3_reg>;
+ pll-supply = <_reg>;
+
+ nvidia,hpd-gpio = < 111 0>; /* PN7 */
+ nvidia,ddc-i2c-bus = <>;
+ };
+ };
+
memory {
reg = <0x8000 0x4000>;
};
@@ -114,7 +133,7 @@
clock-frequency = <40800>;
};
- i2c@7000c000 {
+ rgbddc: i2c@7000c000 {
status = "okay";
clock-frequency = <10>;
};
@@ -137,7 +156,7 @@
};
};
- i2c@7000c700 {
+ hdmiddc: i2c@7000c700 {
status = "okay";
clock-frequency = <10>;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: Add NVIDIA Tegra30 support
This patch is based on Thierry's drm patch for Tegra20:
- [PATCH v2 0/6] Device tree updates for host1x support
- [PATCH v3 0/2] NVIDIA Tegra DRM driver
It adds the support for NVIDIA Tegra30.
Signed-off-by: Mark Zhang
---
drivers/gpu/drm/tegra/dc.c |1 +
drivers/gpu/drm/tegra/host1x.c |3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 216cd0f..6e9f1b4 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -819,6 +819,7 @@ static int tegra_dc_remove(struct platform_device *pdev)
static struct of_device_id tegra_dc_of_match[] = {
{ .compatible = "nvidia,tegra20-dc", },
+ { .compatible = "nvidia,tegra30-dc", },
{ },
};
diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1x.c
index 3d02554..07b7e27 100644
--- a/drivers/gpu/drm/tegra/host1x.c
+++ b/drivers/gpu/drm/tegra/host1x.c
@@ -68,6 +68,8 @@ static int host1x_parse_dt(struct host1x *host1x)
static const char * const compat[] = {
"nvidia,tegra20-dc",
"nvidia,tegra20-hdmi",
+ "nvidia,tegra30-dc",
+ "nvidia,tegra30-hdmi",
};
unsigned int i;
int err;
@@ -269,6 +271,7 @@ int host1x_unregister_client(struct host1x *host1x,
static struct of_device_id tegra_host1x_of_match[] = {
{ .compatible = "nvidia,tegra20-host1x", },
+ { .compatible = "nvidia,tegra30-host1x", },
{ },
};
MODULE_DEVICE_TABLE(of, tegra_host1x_of_match);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 11/31] ARC: Low level IRQ/Trap/Exception(non-MMU) Handling
> + ; - check for signals/restore-sigmask > + bbit0 r9, TIF_SIGPENDING, chk_next_work > + > + ; save CALLEE Regs. > + ; (i) If this signal causes coredump - full regfile needed > + ; (ii) If signal is SIGTRAP/SIGSTOP, task is being traced thus > + ; tracer might call PEEKUSR for a CALLEE reg > + ; > + ; NOTE: SP will grow up by size of CALLEE Reg-File > + SAVE_CALLEE_SAVED_USER ; clobbers r12 > + > + ; save location of saved Callee Regs @ thread_struct->callee > + GET_CURR_TASK_FIELD_PTR TASK_THREAD, r10 > + st sp, [r10, THREAD_CALLEE_REG] > + > + bl @do_signal > + > + ; unwind SP for cheap discard of Callee saved Regs > + DISCARD_CALLEE_SAVED_USER Uh-oh... And what if tracer wanted to modify callee-saved regs? > + b resume_user_mode_begin ; loop back to start of U mode ret > + > + ; --- notify_resume --- > +chk_next_work: > + btst r9, TIF_NOTIFY_RESUME > + blnz @do_notify_resume > + > + ;- All things done, go back to Userland -- > + > + b restore_regs No. After NOTIFY_RESUME stuff you need to recheck SIGPENDING. This should go to resume_user_mode_begin, not restore regs. Another problem here is IRQ handling - you hit do_signal()/do_notify_resume() with IRQs disabled, which is broken - you need to re-enable it before going into either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs
The Medfield Platform implements a recovery procedure consisting in an
escalation
from simple and light recovery procedures to stronger ones with increased
visibility
and impact to end-user.After platform find some problem from Modem,such as no
response,
platform will try do modem warm reset.If several tries failed, platform will
try to
do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
blob (binary object containing PIN code and other necessary information).
Blob is stored in AP volatile memory. AP decides to read PIN code from cache
instead of
prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs.
Reset_modem can be read and write by user space.When read the reset_modem,user
space will
get the mdm_reset_state which used to avoid to run twice at once.When set the
reset_modem to
IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem
reset.
Hangup_reasons used to give one interface to user space to know and clear the
modem reset reasons.
Now there are four reasons:SPI timeout, modem initiative reset,modem
coredump,spi tranfer error.
Cc: Bi Chao
Cc: Liu chuansheng
Acked-by: Alan Cox
Signed-off-by: Chen Jun
---
drivers/tty/serial/Kconfig |2 +-
drivers/tty/serial/ifx6x60.c | 193 ++
drivers/tty/serial/ifx6x60.h |8 ++
3 files changed, 202 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2a53be5..640b36a 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1323,7 +1323,7 @@ config SERIAL_ALTERA_UART_CONSOLE
config SERIAL_IFX6X60
tristate "SPI protocol driver for Infineon 6x60 modem (EXPERIMENTAL)"
- depends on GPIOLIB && SPI
+ depends on GPIOLIB && SPI && X86_INTEL_MID && INTEL_SCU_IPC
help
Support for the IFX6x60 modem devices on Intel MID platforms.
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 5b9bc19..c17efc6 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
#include "ifx6x60.h"
@@ -72,6 +73,27 @@
#define IFX_SPI_HEADER_0 (-1)
#define IFX_SPI_HEADER_F (-2)
+
+/* Delays for powering up/resetting the modem, ms */
+#define PO_INTERLINE_DELAY 1
+#define PO_POST_DELAY 200
+
+#define IFX_COLD_RESET_REQ 1
+
+#define IFX_MDM_PWR_ON 3
+#define IFX_MDM_RST_PMU4
+
+/* For modem cold boot */
+#define V1P35CNT_W 0x0E0 /* PMIC register used to power off */
+/* the modem */
+#define V1P35_OFF 4
+#define V1P35_ON 6
+#define COLD_BOOT_DELAY_OFF_MIN2 /* 20 ms (use of usleep_range)
*/
+#define COLD_BOOT_DELAY_OFF_MAX25000 /* 25 ms (use of usleep_range)
*/
+#define COLD_BOOT_DELAY_ON_MIN 1 /* 10 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_ON_MAX 15000 /* 15 ms (use of usleep_range) */
+
+
/* forward reference */
static void ifx_spi_handle_srdy(struct ifx_spi_device *ifx_dev);
@@ -81,6 +103,35 @@ static struct tty_driver *tty_drv;
static struct ifx_spi_device *saved_ifx_dev;
static struct lock_class_key ifx_spi_key;
+
+/**
+ * do_modem_power - activity required to bring up modem
+ *
+ * Toggle gpios required to bring up modem power and start modem.
+ */
+static void do_modem_power(void)
+{
+ gpio_set_value(IFX_MDM_PWR_ON, 1);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_PWR_ON, 0);
+ msleep(PO_POST_DELAY);
+}
+
+/**
+ * do_modem_reset - activity required to reset modem
+ *
+ * Toggle gpios required to reset modem.
+ */
+static void do_modem_reset(void)
+{
+ gpio_set_value(IFX_MDM_RST_PMU, 0);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_RST_PMU, 1);
+ msleep(PO_POST_DELAY);
+}
+
+
+
/* GPIO/GPE settings */
/**
@@ -229,6 +280,7 @@ static void ifx_spi_timeout(unsigned long arg)
struct ifx_spi_device *ifx_dev = (struct ifx_spi_device *)arg;
dev_warn(_dev->spi_dev->dev, "*** SPI Timeout ***");
+ ifx_dev->hangup_reasons |= HU_TIMEOUT;
ifx_spi_ttyhangup(ifx_dev);
mrdy_set_low(ifx_dev);
clear_bit(IFX_SPI_STATE_TIMER_PENDING, _dev->flags);
@@ -881,6 +933,7 @@ static irqreturn_t ifx_spi_reset_interrupt(int irq, void
*dev)
/* exited reset */
clear_bit(MR_INPROGRESS, _dev->mdm_reset_state);
if (solreset) {
+ clear_bit(MR_START, _dev->mdm_reset_state);
set_bit(MR_COMPLETE, _dev->mdm_reset_state);
wake_up(_dev->mdm_reset_wait);
}
@@ -1405,6 +1458,146 @@ static int __init ifx_spi_init(void)
module_init(ifx_spi_init);
module_exit(ifx_spi_exit);
+/*
+ * Module parameters to manage the
Re: [PATCH] KVM: MMU: lazily drop large spte
On 11/16/2012 11:56 AM, Marcelo Tosatti wrote:
> On Fri, Nov 16, 2012 at 11:39:12AM +0800, Xiao Guangrong wrote:
>> On 11/16/2012 11:02 AM, Marcelo Tosatti wrote:
>>> On Thu, Nov 15, 2012 at 07:17:15AM +0800, Xiao Guangrong wrote:
On 11/14/2012 10:37 PM, Marcelo Tosatti wrote:
> On Tue, Nov 13, 2012 at 04:26:16PM +0800, Xiao Guangrong wrote:
>> Hi Marcelo,
>>
>> On 11/13/2012 07:10 AM, Marcelo Tosatti wrote:
>>> On Mon, Nov 05, 2012 at 05:59:26PM +0800, Xiao Guangrong wrote:
Do not drop large spte until it can be insteaded by small pages so that
the guest can happliy read memory through it
The idea is from Avi:
| As I mentioned before, write-protecting a large spte is a good idea,
| since it moves some work from protect-time to fault-time, so it
reduces
| jitter. This removes the need for the return value.
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 34 +-
1 files changed, 9 insertions(+), 25 deletions(-)
>>>
>>> Its likely that other 4k pages are mapped read-write in the 2mb range
>>> covered by a read-only 2mb map. Therefore its not entirely useful to
>>> map read-only.
>>>
>>
>> It needs a page fault to install a pte even if it is the read access.
>> After the change, the page fault can be avoided.
>>
>>> Can you measure an improvement with this change?
>>
>> I have a test case to measure the read time which has been attached.
>> It maps 4k pages at first (dirt-loggged), then switch to large sptes
>> (stop dirt-logging), at the last, measure the read access time after
>> write
>> protect sptes.
>>
>> Before: 23314111 ns After: 11404197 ns
>
> Ok, i'm concerned about cases similar to e49146dce8c3dc6f44 (with shadow),
> that is:
>
> - large page must be destroyed when write protecting due to
> shadowed page.
> - with shadow, it does not make sense to write protect
> large sptes as mentioned earlier.
>
This case is removed now, the code when e49146dce8c3dc6f44 was applied is:
|
|pt = sp->spt;
|for (i = 0; i < PT64_ENT_PER_PAGE; ++i)
|/* avoid RMW */
|if (is_writable_pte(pt[i]))
|update_spte([i], pt[i] &
~PT_WRITABLE_MASK);
|}
The real problem in this code is it would write-protect the spte even if
it is not a last spte that caused the middle-level shadow page table was
write-protected. So e49146dce8c3dc6f44 added this code:
|if (sp->role.level != PT_PAGE_TABLE_LEVEL)
|continue;
|
was good to fix this problem.
Now, the current code is:
| for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
| if (!is_shadow_present_pte(pt[i]) ||
|!is_last_spte(pt[i], sp->role.level))
| continue;
|
| spte_write_protect(kvm, [i], , false);
| }
It only write-protect the last spte. So, it allows large spte existent.
(the large spte can be broken by drop_large_spte() on the page-fault path.)
> So i wonder why is this part from your patch
>
> - if (level > PT_PAGE_TABLE_LEVEL &&
> - has_wrprotected_page(vcpu->kvm, gfn, level)) {
> - ret = 1;
> - drop_spte(vcpu->kvm, sptep);
> - goto done;
> - }
>
> necessary (assuming EPT is in use).
This is safe, we change these code to:
- if (mmu_need_write_protect(vcpu, gfn, can_unsync)) {
+ if ((level > PT_PAGE_TABLE_LEVEL &&
+ has_wrprotected_page(vcpu->kvm, gfn, level)) ||
+mmu_need_write_protect(vcpu, gfn, can_unsync)) {
pgprintk("%s: found shadow page for %llx, marking ro\n",
__func__, gfn);
ret = 1;
The spte become read-only which can ensure the shadow gfn can not be
changed.
Btw, the origin code allows to create readonly spte under this case if
!(pte_access & WRITEABBLE)
>>>
>>> Regarding shadow: it should be fine as long as fault path always deletes
>>> large mappings, when shadowed pages are present in the region.
>>
>> For hard mmu is also safe, in this patch i added these code:
>>
>> @@ -2635,6 +2617,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t
>> v, int write,
>> break;
>> }
>>
>> +drop_large_spte(vcpu, iterator.sptep);
>> +
>>
>> It can delete large mappings like soft mmu does.
>>
>>
Re: [PATCH 7/8] ata: highbank: mark ahci_highbank_probe as __devinit
On 11/06/2012 04:55 PM, Arnd Bergmann wrote: The ahci_highbank_probe function is incorrectly marked as __init, which means it can get discarded at boot time, which might be a problem if for some reason the device only becomes operational after loading another module. Using __devinit instead avoids seeing this warning for every build: WARNING: vmlinux.o(.data+0xf7b0): Section mismatch in reference from the variable ahci_highbank_driver to the function .init.text:ahci_highbank_probe() The variable ahci_highbank_driver references the function __init ahci_highbank_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Signed-off-by: Arnd Bergmann Cc: Mark Langsdorf Cc: Rob Herring Cc: Jeff Garzik --- drivers/ata/sata_highbank.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ethernet/intel/ixgbe/ixgbe_debugfs.c: fix error handling in ixgbe_dbg_reg_ops_read().
On Fri, 2012-11-16 at 04:26 +0100, Cyril Roelandt wrote: > > copy_to_user() cannot return a negative value: it returns the number > of bytes > that could not be copied. > > Return -EFAULT on failure rather than the number of bytes that could > not be > copied, as this seems more standard. > > Signed-off-by: Cyril Roelandt > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c |6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Actually, I already have a similar patch in my queue reported by Dan Carpenter, and created by Josh Hay which fixes this issue. I should be pushing the patch in my queue in the next week. Here is the patch I am referring to: ixgbe: eliminate Smatch warnings in ixgbe_debugfs.c This patch replaces calls to copy_to_user, copy_from_user, and the associated logic, with calls to simple_read_from_buffer and simple_write_to_buffer respectively. This was done to eliminate warnings generated by the Smatch static analysis tool. Reported-by: Dan Carpenter CC: Dan Carpenter Signed-off-by: Josh Hay Cheers, Jeff signature.asc Description: This is a digitally signed message part
Re: [PATCH] ata: pata_arasan: Initialize cf clock to 166MHz
On 11/08/2012 10:09 AM, Viresh Kumar wrote: From: Vipul Kumar Samar PATA arasan driver expects the clock to be set to 166 MHz for proper functioning. This patch sets clk to 166 MHz in probe. Signed-off-by: Vipul Kumar Samar Signed-off-by: Viresh Kumar --- drivers/ata/pata_arasan_cf.c | 6 ++ 1 file changed, 6 insertions(+) applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver
On Friday 16 November 2012 11:36:36 Alex Courbot wrote: > On Friday 16 November 2012 05:28:21 Thierry Reding wrote: > > This third version of the patch series cleans up some minor issues that > > were found in the previous versions, such as deferred probe not working > > properly and the display remaining enabled after the driver is removed. > > > > I've also put the two patches in this series into the tegra/drm/for-3.8 > > branch of my repository on gitorious[0]. > > Pulled from your branch and tried to test on my Ventana, but for some reason > nothing ever gets displayed. The only DRM-related message I ever get in my > log is > > [0.820483] [drm] Initialized drm 1.1.0 20060810 > > Things were working perfectly with v2 - has something changed with e.g. the > DT bindings? Argh, the patches that add host1x nodes into tegra20.dtsi were not into your for-3.8 branch. Things are fine now, therefore this series is Tested-and-acked-by: Alexandre Courbot Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch,v3 06/10] ata: use scsi_host_alloc_node
On 11/09/2012 02:18 PM, Jeff Moyer wrote: Signed-off-by: Jeff Moyer --- drivers/ata/libata-scsi.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Acked-by: Jeff Garzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ PATCH RESEND ] PCI-AER: Do not report successful error recovery for devices with AER-unaware drivers
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Thursday, November 15, 2012 5:09 PM
> To: Pandarathil, Vijaymohan R
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linasveps...@gmail.com; Myron Stowe; Ortiz, Lance E; Huang Ying; Hidetoshi
> Seto; Patterson, Andrew D (LeftHand Networks); Zhang Yanmin
> Subject: Re: [ PATCH RESEND ] PCI-AER: Do not report successful error
> recovery for devices with AER-unaware drivers
>
> On Thu, Nov 15, 2012 at 12:09 AM, Pandarathil, Vijaymohan R
> wrote:
> > Thanks for the comments. See my response below.
> >
> >> -Original Message-
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: Wednesday, November 14, 2012 4:51 PM
> >> To: Pandarathil, Vijaymohan R
> >> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> >> linasveps...@gmail.com; Myron Stowe; Ortiz, Lance E; Huang Ying;
> Hidetoshi
> >> Seto; Patterson, Andrew D (LeftHand Networks); Zhang Yanmin
> >> Subject: Re: [ PATCH RESEND ] PCI-AER: Do not report successful error
> >> recovery for devices with AER-unaware drivers
> >>
> >> [+cc Lance, Huang, Hidetoshi, Andrew, Zhang]
> >>
> >> On Sat, Nov 10, 2012 at 07:41:04AM +, Pandarathil, Vijaymohan R
> wrote:
> >> > When an error is detected on a PCIe device which does not have an
> >> > AER-aware driver, prevent AER infrastructure from reporting
> >> > successful error recovery.
> >> >
> >> > This is because the report_error_detected() function that gets
> >> > called in the first phase of recovery process allows forward
> >> > progress even when the driver for the device does not have AER
> >> > capabilities. It seems that all callbacks (in pci_error_handlers
> >> > structure) registered by drivers that gets called during error
> >> > recovery are not mandatory. So the intention of the infrastructure
> >> > design seems to be to allow forward progress even when a specific
> >> > callback has not been registered by a driver. However, if error
> >> > handler structure itself has not been registered, it doesn't make
> >> > sense to allow forward progress.
> >> >
> >> > As a result of the current design, in the case of a single device
> >> > having an AER-unaware driver or in the case of any function in a
> >> > multi-function card having an AER-unaware driver, a successful
> >> > recovery is reported.
> >> >
> >> > Typical scenario this happens is when a PCI device is detached
> >> > from a KVM host and the pci-stub driver on the host claims the
> >> > device. The pci-stub driver does not have error handling capabilities
> >> > but the AER infrastructure still reports that the device recovered
> >> > successfully.
> >> >
> >> > The changes proposed here leaves the device in an unrecovered state
> >> > if the driver for the device or for any function in a multi-function
> >> > card does not have error handler structure registered. This reflects
> >> > the true state of the device and prevents any partial recovery (or no
> >> > recovery at all) reported as successful.
> >> >
> >> > Please also see comments from Linas Vepstas at the following link
> >> > http://www.spinics.net/lists/linux-pci/msg18572.html
> >> >
> >> > Reviewed-by: Linas Vepstas gmail.com>
> >> > Reviewed-by: Myron Stowe redhat.com>
> >> > Signed-off-by: Vijay Mohan Pandarathil
> >> hp.com>
> >> >
> >> > ---
> >> >
> >> > drivers/pci/pcie/aer/aerdrv_core.c | 6 ++
> >> > 1 file changed, 6 insertions(+)
> >> >
> >> > diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
> >> b/drivers/pci/pcie/aer/aerdrv_core.c
> >> > index 06bad96..030b229 100644
> >> > --- a/drivers/pci/pcie/aer/aerdrv_core.c
> >> > +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> >> > @@ -215,6 +215,12 @@ static int report_error_detected(struct pci_dev
> >> *dev, void *data)
> >> >
> >> > dev->error_state = result_data->state;
> >> >
> >> > + if ((!dev->driver || !dev->driver->err_handler) &&
> >> > + !(dev->hdr_type & PCI_HEADER_TYPE_BRIDGE)) {
> >> > + dev_info(>dev, "AER: Error detected but no driver has
> >> claimed this device or the driver is AER-unaware\n");
> >> > + result_data->result = PCI_ERS_RESULT_NONE;
> >> > + return 1;
> >>
> >> This doesn't seem right because returning 1 here causes pci_walk_bus()
> >> to terminate, which means we won't set dev->error_state or notify
> >> drivers for any devices we haven't visited yet.
> >>
> >> > + }
> >> > if (!dev->driver ||
> >> > !dev->driver->err_handler ||
> >> > !dev->driver->err_handler->error_detected) {
> >>
> >> If none of the drivers in the affected hierarchy supports error
> handling,
> >> I think the call tree looks like this:
> >>
> >> do_recovery # uncorrectable only
> >> broadcast_error_message(dev, ..., report_error_detected)
> >> result_data.result = CAN_RECOVER
> >> pci_walk_bus(..., report_error_detected)
> >>
Re: [PATCH 2/2] dw_dmac: make usage of dw_dma_slave optional
On 15 November 2012 23:28, Andy Shevchenko wrote: > On Thu, Nov 15, 2012 at 5:38 PM, Viresh Kumar wrote: >> On 15 November 2012 20:57, Andy Shevchenko >> wrote: >>> Well, the prep_* should assign the value due to changes of check in the >>> dwc_descriptor_complete. Otherwise we will potentially skip some >>> important piece of code. >> >> What i meant to say was, set_runtime_config() must have already done this >> part. > > On one hand it is true. On the other - *_prep* functions use > explicitly passed parameter. I doubt there is a consistency between > value in slave config passed via dwc_control and value passed as > explicit function parameter. I believe it should be consistent. @Vinod: Why have we duplicated direction? Once in prep_* and then in slave_config? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pata_cs5536: add quirk for broken udma
On 11/15/2012 05:03 PM, Christian Gmeiner wrote: I am working on a device which uses the cs5536 pata driver. There are some broken hardware revisions out in the field, which can be detected via DMI. On older versions with an embedded BIOS I used libata.dma=0 to disable dma completely. Now we are switching to a coreboot/seabios based BIOS where we have DMI support and so I think its a good idea to get rid of all those hacky kernel parameters as the same image is used other devices where libata.dma=0 is not a good idea. Signed-off-by: Christian Gmeiner --- drivers/ata/pata_cs5536.c | 32 ++ +- 1 file changed, 31 insertions(+), 1 deletion(-) ACK, but patch is word-wrapped-mangled -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] autofs4 - use simple_empty() for empty directory check
From: Ian Kent
For direct (and offset) mounts, if an automounted mount is manually
umounted the trigger mount dentry can appear non-empty causing it to
not trigger mounts. This can also happen if there is a file handle
leak in a user space automounting application.
It happens because, when the ioctl control file handle is opened
on the mount, a cursor dentry is created which causes list_empty()
to see the dentry as non-empty. Since there is a case where listing
the directory of these dentrys is needed, the use of dcache_dir_*()
functions for .open() and .release() is needed.
Consequently simple_empty() must be used instead of list_empty()
when checking for an empty directory.
Signed-off-by: Ian Kent
---
fs/autofs4/autofs_i.h | 18 ++
fs/autofs4/root.c | 16
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 908e184..4c3f589 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -301,6 +301,24 @@ static inline int simple_positive(struct dentry *dentry)
return dentry->d_inode && !d_unhashed(dentry);
}
+static inline int __simple_empty(struct dentry *dentry)
+{
+ struct dentry *child;
+ int ret = 0;
+
+ list_for_each_entry(child, >d_subdirs, d_u.d_child) {
+ spin_lock_nested(>d_lock, DENTRY_D_LOCK_NESTED);
+ if (simple_positive(child)) {
+ spin_unlock(>d_lock);
+ goto out;
+ }
+ spin_unlock(>d_lock);
+ }
+ ret = 1;
+out:
+ return ret;
+}
+
static inline void __autofs4_add_expiring(struct dentry *dentry)
{
struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 91b1165..f39bf4b 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -124,13 +124,10 @@ static int autofs4_dir_open(struct inode *inode, struct
file *file)
* it.
*/
spin_lock(>lookup_lock);
- spin_lock(>d_lock);
- if (!d_mountpoint(dentry) && list_empty(>d_subdirs)) {
- spin_unlock(>d_lock);
+ if (!d_mountpoint(dentry) && simple_empty(dentry)) {
spin_unlock(>lookup_lock);
return -ENOENT;
}
- spin_unlock(>d_lock);
spin_unlock(>lookup_lock);
out:
@@ -382,12 +379,8 @@ static struct vfsmount *autofs4_d_automount(struct path
*path)
if (have_submounts(dentry))
goto done;
} else {
- spin_lock(>d_lock);
- if (!list_empty(>d_subdirs)) {
- spin_unlock(>d_lock);
+ if (!simple_empty(dentry))
goto done;
- }
- spin_unlock(>d_lock);
}
ino->flags |= AUTOFS_INF_PENDING;
spin_unlock(>fs_lock);
@@ -413,8 +406,7 @@ done:
* the follow.
*/
spin_lock(>d_lock);
- if ((!d_mountpoint(dentry) &&
- !list_empty(>d_subdirs)) ||
+ if ((!d_mountpoint(dentry) && !__simple_empty(dentry)) ||
(dentry->d_inode && S_ISLNK(dentry->d_inode->i_mode)))
__managed_dentry_clear_automount(dentry);
spin_unlock(>d_lock);
@@ -673,7 +665,7 @@ static int autofs4_dir_rmdir(struct inode *dir, struct
dentry *dentry)
spin_lock(>lookup_lock);
spin_lock(>d_lock);
- if (!list_empty(>d_subdirs)) {
+ if (!__simple_empty(dentry)) {
spin_unlock(>d_lock);
spin_unlock(>lookup_lock);
return -ENOTEMPTY;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tilegx: request_irq with a non-null device name
This patch simply makes the tilegx net driver call request_irq with a
non-null name. It makes the output in /proc/interrupts more obvious, but
also helps tools that don't expect to find null there.
Signed-off-by: Simon Marchi
Acked-by: Chris Metcalf
---
I am not sure if this patch will get picked up directly by David Miller
of it should go through Chris Metcalf's tree first. Hopefully it is
simple enough that it can get merged directly.
drivers/net/ethernet/tile/tilegx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 4e98100..66e025a 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -917,7 +917,7 @@ static int tile_net_setup_interrupts(struct net_device *dev)
ingress_irq = rc;
tile_irq_activate(ingress_irq, TILE_IRQ_PERCPU);
rc = request_irq(ingress_irq, tile_net_handle_ingress_irq,
-0, NULL, NULL);
+0, "tile_net", NULL);
if (rc != 0) {
netdev_err(dev, "request_irq failed: %d\n", rc);
destroy_irq(ingress_irq);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 30/31] ARC: switch to generic kernel_execve() and sys_execve()
On Wed, Nov 07, 2012 at 10:47:53AM +0100, Vineet Gupta wrote: > +; When we land here, pt_regs have already been updated in-place correctly > +; A pointer to them is also passed by kernel_execve, we just need to make > sure > +; that SP is set to point to them. > +ARC_ENTRY ret_from_kernel_execve > + ; Force SP to "normal" pt_regs just populated. > + b.d ret_from_system_call > + mov sp, r0 won't that splatter crap into regs->r0? IOW, why not branch to ret_from_exception here? > +ARC_EXIT ret_from_kernel_execve Another thing: why not fold that branch to ret_from_exception into the end of ret_from_kernel_thread() (instead of calling sys_exit()), select GENERIC_KERNEL_EXECVE and lose __ARCH_WANT_KERNEL_EXECVE. Actually, now that I look at your ret_from_kernel_thread... How the hell will it cope with kernel_thread() payload trying to return? AFAICS, this j.d [r1] will lose the return address, won't it? And while we are at it, I would suggest passing callback and its argument via callee-saved registers - makes for simpler life in ret_from_kernel_thread(), since switch_to() itself will take care of loading those... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver
Thierry, By the way, when do you plan to send drm patches for Tegra 3? I'm wondering if you don't have a Tegra 3 board for testing, I can do that for you. Mark On 11/16/2012 05:28 AM, Thierry Reding wrote: > This third version of the patch series cleans up some minor issues that > were found in the previous versions, such as deferred probe not working > properly and the display remaining enabled after the driver is removed. > > I've also put the two patches in this series into the tegra/drm/for-3.8 > branch of my repository on gitorious[0]. > > Thierry > > [0]: git://gitorious.org/thierryreding/linux.git > > Thierry Reding (2): > drm: Add NVIDIA Tegra20 support > drm: tegra: Add HDMI support > > .../bindings/gpu/nvidia,tegra20-host1x.txt | 191 +++ > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/tegra/Kconfig | 23 + > drivers/gpu/drm/tegra/Makefile |7 + > drivers/gpu/drm/tegra/dc.c | 833 > drivers/gpu/drm/tegra/dc.h | 388 ++ > drivers/gpu/drm/tegra/drm.c| 115 ++ > drivers/gpu/drm/tegra/drm.h| 234 > drivers/gpu/drm/tegra/fb.c | 56 + > drivers/gpu/drm/tegra/hdmi.c | 1334 > > drivers/gpu/drm/tegra/hdmi.h | 575 + > drivers/gpu/drm/tegra/host1x.c | 322 + > drivers/gpu/drm/tegra/output.c | 272 > drivers/gpu/drm/tegra/rgb.c| 228 > 15 files changed, 4581 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt > create mode 100644 drivers/gpu/drm/tegra/Kconfig > create mode 100644 drivers/gpu/drm/tegra/Makefile > create mode 100644 drivers/gpu/drm/tegra/dc.c > create mode 100644 drivers/gpu/drm/tegra/dc.h > create mode 100644 drivers/gpu/drm/tegra/drm.c > create mode 100644 drivers/gpu/drm/tegra/drm.h > create mode 100644 drivers/gpu/drm/tegra/fb.c > create mode 100644 drivers/gpu/drm/tegra/hdmi.c > create mode 100644 drivers/gpu/drm/tegra/hdmi.h > create mode 100644 drivers/gpu/drm/tegra/host1x.c > create mode 100644 drivers/gpu/drm/tegra/output.c > create mode 100644 drivers/gpu/drm/tegra/rgb.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver
Hi Thierry, Thank you for your hard work. The series, Acked-by: Mark Zhang Reviewed-by: Mark Zhang Tested-by: Mark Zhang On Ventana, LVDS and HDMI worked. PS: Alex's power sequence patch is needed to enable panel and backlight. Also we need to define dc and hdmi nodes in tegra20-ventana.dts. We may publish the patches for different boards next. Mark On 11/16/2012 05:28 AM, Thierry Reding wrote: > This third version of the patch series cleans up some minor issues that > were found in the previous versions, such as deferred probe not working > properly and the display remaining enabled after the driver is removed. > > I've also put the two patches in this series into the tegra/drm/for-3.8 > branch of my repository on gitorious[0]. > > Thierry > > [0]: git://gitorious.org/thierryreding/linux.git > > Thierry Reding (2): > drm: Add NVIDIA Tegra20 support > drm: tegra: Add HDMI support > > .../bindings/gpu/nvidia,tegra20-host1x.txt | 191 +++ > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/tegra/Kconfig | 23 + > drivers/gpu/drm/tegra/Makefile |7 + > drivers/gpu/drm/tegra/dc.c | 833 > drivers/gpu/drm/tegra/dc.h | 388 ++ > drivers/gpu/drm/tegra/drm.c| 115 ++ > drivers/gpu/drm/tegra/drm.h| 234 > drivers/gpu/drm/tegra/fb.c | 56 + > drivers/gpu/drm/tegra/hdmi.c | 1334 > > drivers/gpu/drm/tegra/hdmi.h | 575 + > drivers/gpu/drm/tegra/host1x.c | 322 + > drivers/gpu/drm/tegra/output.c | 272 > drivers/gpu/drm/tegra/rgb.c| 228 > 15 files changed, 4581 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt > create mode 100644 drivers/gpu/drm/tegra/Kconfig > create mode 100644 drivers/gpu/drm/tegra/Makefile > create mode 100644 drivers/gpu/drm/tegra/dc.c > create mode 100644 drivers/gpu/drm/tegra/dc.h > create mode 100644 drivers/gpu/drm/tegra/drm.c > create mode 100644 drivers/gpu/drm/tegra/drm.h > create mode 100644 drivers/gpu/drm/tegra/fb.c > create mode 100644 drivers/gpu/drm/tegra/hdmi.c > create mode 100644 drivers/gpu/drm/tegra/hdmi.h > create mode 100644 drivers/gpu/drm/tegra/host1x.c > create mode 100644 drivers/gpu/drm/tegra/output.c > create mode 100644 drivers/gpu/drm/tegra/rgb.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] KVM: MMU: lazily drop large spte
On Fri, Nov 16, 2012 at 11:39:12AM +0800, Xiao Guangrong wrote:
> On 11/16/2012 11:02 AM, Marcelo Tosatti wrote:
> > On Thu, Nov 15, 2012 at 07:17:15AM +0800, Xiao Guangrong wrote:
> >> On 11/14/2012 10:37 PM, Marcelo Tosatti wrote:
> >>> On Tue, Nov 13, 2012 at 04:26:16PM +0800, Xiao Guangrong wrote:
> Hi Marcelo,
>
> On 11/13/2012 07:10 AM, Marcelo Tosatti wrote:
> > On Mon, Nov 05, 2012 at 05:59:26PM +0800, Xiao Guangrong wrote:
> >> Do not drop large spte until it can be insteaded by small pages so that
> >> the guest can happliy read memory through it
> >>
> >> The idea is from Avi:
> >> | As I mentioned before, write-protecting a large spte is a good idea,
> >> | since it moves some work from protect-time to fault-time, so it
> >> reduces
> >> | jitter. This removes the need for the return value.
> >>
> >> Signed-off-by: Xiao Guangrong
> >> ---
> >> arch/x86/kvm/mmu.c | 34 +-
> >> 1 files changed, 9 insertions(+), 25 deletions(-)
> >
> > Its likely that other 4k pages are mapped read-write in the 2mb range
> > covered by a read-only 2mb map. Therefore its not entirely useful to
> > map read-only.
> >
>
> It needs a page fault to install a pte even if it is the read access.
> After the change, the page fault can be avoided.
>
> > Can you measure an improvement with this change?
>
> I have a test case to measure the read time which has been attached.
> It maps 4k pages at first (dirt-loggged), then switch to large sptes
> (stop dirt-logging), at the last, measure the read access time after
> write
> protect sptes.
>
> Before: 23314111 ns After: 11404197 ns
> >>>
> >>> Ok, i'm concerned about cases similar to e49146dce8c3dc6f44 (with shadow),
> >>> that is:
> >>>
> >>> - large page must be destroyed when write protecting due to
> >>> shadowed page.
> >>> - with shadow, it does not make sense to write protect
> >>> large sptes as mentioned earlier.
> >>>
> >>
> >> This case is removed now, the code when e49146dce8c3dc6f44 was applied is:
> >> |
> >> |pt = sp->spt;
> >> |for (i = 0; i < PT64_ENT_PER_PAGE; ++i)
> >> |/* avoid RMW */
> >> |if (is_writable_pte(pt[i]))
> >> |update_spte([i], pt[i] &
> >> ~PT_WRITABLE_MASK);
> >> |}
> >>
> >> The real problem in this code is it would write-protect the spte even if
> >> it is not a last spte that caused the middle-level shadow page table was
> >> write-protected. So e49146dce8c3dc6f44 added this code:
> >> |if (sp->role.level != PT_PAGE_TABLE_LEVEL)
> >> |continue;
> >> |
> >> was good to fix this problem.
> >>
> >> Now, the current code is:
> >> | for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
> >> | if (!is_shadow_present_pte(pt[i]) ||
> >> |!is_last_spte(pt[i], sp->role.level))
> >> | continue;
> >> |
> >> | spte_write_protect(kvm, [i], , false);
> >> | }
> >> It only write-protect the last spte. So, it allows large spte existent.
> >> (the large spte can be broken by drop_large_spte() on the page-fault path.)
> >>
> >>> So i wonder why is this part from your patch
> >>>
> >>> - if (level > PT_PAGE_TABLE_LEVEL &&
> >>> - has_wrprotected_page(vcpu->kvm, gfn, level)) {
> >>> - ret = 1;
> >>> - drop_spte(vcpu->kvm, sptep);
> >>> - goto done;
> >>> - }
> >>>
> >>> necessary (assuming EPT is in use).
> >>
> >> This is safe, we change these code to:
> >>
> >> - if (mmu_need_write_protect(vcpu, gfn, can_unsync)) {
> >> + if ((level > PT_PAGE_TABLE_LEVEL &&
> >> + has_wrprotected_page(vcpu->kvm, gfn, level)) ||
> >> +mmu_need_write_protect(vcpu, gfn, can_unsync)) {
> >>pgprintk("%s: found shadow page for %llx, marking ro\n",
> >> __func__, gfn);
> >>ret = 1;
> >>
> >> The spte become read-only which can ensure the shadow gfn can not be
> >> changed.
> >>
> >> Btw, the origin code allows to create readonly spte under this case if
> >> !(pte_access & WRITEABBLE)
> >
> > Regarding shadow: it should be fine as long as fault path always deletes
> > large mappings, when shadowed pages are present in the region.
>
> For hard mmu is also safe, in this patch i added these code:
>
> @@ -2635,6 +2617,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v,
> int write,
> break;
> }
>
> + drop_large_spte(vcpu, iterator.sptep);
> +
>
> It can delete large mappings like soft mmu does.
>
> Anything i missed?
>
> >
> > Ah, unshadowing from
Re: [PATCH v2 0/6] Device tree updates for host1x support
Hi Thierry, Thank you for your hard work. The series, Acked-by: Mark Zhang Reviewed-by: Mark Zhang Tested-by: Mark Zhang On Ventana, LVDS and HDMI worked. PS: Alex's power sequence patch is needed to enable panel and backlight. Also we need to define dc and hdmi nodes in tegra20-ventana.dts. We may publish the patches for different boards next. Mark On 11/16/2012 05:07 AM, Thierry Reding wrote: > This second version of this patch series splits the patches up into more > logical chunks as requested by Stephen. Instead of renaming the matching > parameters in the clock driver, this version renames the AUXDATA entries > to match what the clock driver expects. Furthermore the host1x clock is > initialized to 150 MHz instead of the unsupported 144 MHz. > > Thierry > > Thierry Reding (6): > ARM: tegra: Add Tegra20 host1x support > ARM: tegra: Add AUXDATA for Tegra20 host1x > ARM: tegra: Add Tegra20 host1x clock support > ARM: tegra: Add Tegra30 host1x support > ARM: tegra: Add AUXDATA for Tegra30 host1x > ARM: tegra: Add Tegra30 host1x clock support > > arch/arm/boot/dts/tegra20.dtsi| 87 > +++ > arch/arm/boot/dts/tegra30.dtsi| 87 > +++ > arch/arm/mach-tegra/board-dt-tegra20.c| 9 > arch/arm/mach-tegra/board-dt-tegra30.c| 9 > arch/arm/mach-tegra/tegra20_clocks_data.c | 11 ++-- > arch/arm/mach-tegra/tegra30_clocks_data.c | 5 +- > 6 files changed, 203 insertions(+), 5 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc,sdio: Fix the panic due to devname NULL when calling pm_runtime_set_active()
Subject: [PATCH] mmc,sdio: Fix the panic due to devname NULL when calling
pm_runtime_set_active()
Meet one panic as the below:
<1>[ 15.067350] BUG: unable to handle kernel NULL pointer dereference at
(null)
<1>[ 15.074455] IP: [] strlen+0x12/0x20
<4>[ 15.078803] *pde =
<0>[ 15.081674] Oops: [#1] PREEMPT SMP
<4>[ 15.101676] Pid: 5, comm: kworker/u:0 Tainted: G C
3.0.34-140729-g7f9d5c5 #1 Intel Corporation Medfield/BKB2
<4>[ 15.112282] EIP: 0060:[] EFLAGS: 00010046 CPU: 0
<4>[ 15.117760] EIP is at strlen+0x12/0x20
<4>[ 15.121496] EAX: EBX: f344cc04 ECX: EDX: f344cc04
<4>[ 15.127754] ESI: c12bcee0 EDI: EBP: f586fe74 ESP: f586fe70
<4>[ 15.134013] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
<0>[ 15.139406] Process kworker/u:0 (pid: 5, ti=f586e000 task=f585b440
task.ti=f586e000)
<0>[ 15.147140] Stack:
<4>[ 15.149141] f344cc04 f586feb0 c12bcf12 f586fe9c
0007 0082
<4>[ 15.156877] 0092 0002 c1b01ee4 f586feb8 c1635f31 f3b42330
c12bcee0 f344cc04
<4>[ 15.164616] f586fed0 c152f815 f3b42330 f3b42328 f344cc04
f589b804
<0>[ 15.172351] Call Trace:
<4>[ 15.174810] [] ftrace_raw_event_runtime_pm_status+0x32/0x140
<4>[ 15.181411] [] ? sdio_enable_wide.part.8+0x61/0x80
<4>[ 15.187145] [] ? perf_trace_runtime_pm_usage+0x1a0/0x1a0
<4>[ 15.193407] [] __update_runtime_status+0x65/0x90
<4>[ 15.198968] [] __pm_runtime_set_status+0xe0/0x1b0
<4>[ 15.204621] [] mmc_attach_sdio+0x2f6/0x410
<4>[ 15.209666] [] mmc_rescan+0x240/0x2b0
<4>[ 15.214270] [] process_one_work+0xfe/0x3f0
<4>[ 15.219311] [] ? wake_up_process+0x14/0x20
<4>[ 15.224357] [] ? mmc_detect_card_removed+0x80/0x80
<4>[ 15.230091] [] worker_thread+0x121/0x2f0
<4>[ 15.234958] [] ? rescuer_thread+0x1e0/0x1e0
<4>[ 15.240091] [] kthread+0x6d/0x80
<4>[ 15.244264] [] ? __init_kthread_worker+0x30/0x30
<4>[ 15.245485] [] kernel_thread_helper+0x6/0x10
The reason is pm_runtime_set_active() is called before the device name
is set, and the dev name setting is done at mmc_add_card() laterly.
So when calling pm_runtime_set_active(), it will hit the strlen(devname==0)
which trigger the panic.
Here before calling pm_runtime_set_active(), set the dev name, although
it is duplicated with mmc_add_card(), but it do not break the original
design(commit 81968561b).
Signed-off-by: liu chuansheng
---
drivers/mmc/core/sdio.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 2273ce6..73746af 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -1104,6 +1104,15 @@ int mmc_attach_sdio(struct mmc_host *host)
*/
if (host->caps & MMC_CAP_POWER_OFF_CARD) {
/*
+* pm_runtime_set_active will use strlen(dev_name),
+* we must set it in advance to avoid crash,
+* although it is the duplication in mmc_add_card
+* laterly.
+*/
+ dev_set_name(>dev, "%s:%04x", mmc_hostname(card->host),
+ card->rca);
+
+ /*
* Let runtime PM core know our card is active
*/
err = pm_runtime_set_active(>dev);
--
1.7.0.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] KVM: MMU: lazily drop large spte
On 11/16/2012 11:02 AM, Marcelo Tosatti wrote:
> On Thu, Nov 15, 2012 at 07:17:15AM +0800, Xiao Guangrong wrote:
>> On 11/14/2012 10:37 PM, Marcelo Tosatti wrote:
>>> On Tue, Nov 13, 2012 at 04:26:16PM +0800, Xiao Guangrong wrote:
Hi Marcelo,
On 11/13/2012 07:10 AM, Marcelo Tosatti wrote:
> On Mon, Nov 05, 2012 at 05:59:26PM +0800, Xiao Guangrong wrote:
>> Do not drop large spte until it can be insteaded by small pages so that
>> the guest can happliy read memory through it
>>
>> The idea is from Avi:
>> | As I mentioned before, write-protecting a large spte is a good idea,
>> | since it moves some work from protect-time to fault-time, so it reduces
>> | jitter. This removes the need for the return value.
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>> arch/x86/kvm/mmu.c | 34 +-
>> 1 files changed, 9 insertions(+), 25 deletions(-)
>
> Its likely that other 4k pages are mapped read-write in the 2mb range
> covered by a read-only 2mb map. Therefore its not entirely useful to
> map read-only.
>
It needs a page fault to install a pte even if it is the read access.
After the change, the page fault can be avoided.
> Can you measure an improvement with this change?
I have a test case to measure the read time which has been attached.
It maps 4k pages at first (dirt-loggged), then switch to large sptes
(stop dirt-logging), at the last, measure the read access time after write
protect sptes.
Before: 23314111 nsAfter: 11404197 ns
>>>
>>> Ok, i'm concerned about cases similar to e49146dce8c3dc6f44 (with shadow),
>>> that is:
>>>
>>> - large page must be destroyed when write protecting due to
>>> shadowed page.
>>> - with shadow, it does not make sense to write protect
>>> large sptes as mentioned earlier.
>>>
>>
>> This case is removed now, the code when e49146dce8c3dc6f44 was applied is:
>> |
>> |pt = sp->spt;
>> |for (i = 0; i < PT64_ENT_PER_PAGE; ++i)
>> |/* avoid RMW */
>> |if (is_writable_pte(pt[i]))
>> |update_spte([i], pt[i] &
>> ~PT_WRITABLE_MASK);
>> |}
>>
>> The real problem in this code is it would write-protect the spte even if
>> it is not a last spte that caused the middle-level shadow page table was
>> write-protected. So e49146dce8c3dc6f44 added this code:
>> |if (sp->role.level != PT_PAGE_TABLE_LEVEL)
>> |continue;
>> |
>> was good to fix this problem.
>>
>> Now, the current code is:
>> |for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
>> |if (!is_shadow_present_pte(pt[i]) ||
>> | !is_last_spte(pt[i], sp->role.level))
>> |continue;
>> |
>> |spte_write_protect(kvm, [i], , false);
>> |}
>> It only write-protect the last spte. So, it allows large spte existent.
>> (the large spte can be broken by drop_large_spte() on the page-fault path.)
>>
>>> So i wonder why is this part from your patch
>>>
>>> - if (level > PT_PAGE_TABLE_LEVEL &&
>>> - has_wrprotected_page(vcpu->kvm, gfn, level)) {
>>> - ret = 1;
>>> - drop_spte(vcpu->kvm, sptep);
>>> - goto done;
>>> - }
>>>
>>> necessary (assuming EPT is in use).
>>
>> This is safe, we change these code to:
>>
>> -if (mmu_need_write_protect(vcpu, gfn, can_unsync)) {
>> +if ((level > PT_PAGE_TABLE_LEVEL &&
>> + has_wrprotected_page(vcpu->kvm, gfn, level)) ||
>> + mmu_need_write_protect(vcpu, gfn, can_unsync)) {
>> pgprintk("%s: found shadow page for %llx, marking ro\n",
>> __func__, gfn);
>> ret = 1;
>>
>> The spte become read-only which can ensure the shadow gfn can not be changed.
>>
>> Btw, the origin code allows to create readonly spte under this case if
>> !(pte_access & WRITEABBLE)
>
> Regarding shadow: it should be fine as long as fault path always deletes
> large mappings, when shadowed pages are present in the region.
For hard mmu is also safe, in this patch i added these code:
@@ -2635,6 +2617,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v,
int write,
break;
}
+ drop_large_spte(vcpu, iterator.sptep);
+
It can delete large mappings like soft mmu does.
Anything i missed?
>
> Ah, unshadowing from reexecute_instruction does not handle
> large pages. I suppose that is what "simplification" refers
> to.
reexecute_instruction did not directly handle last spte, it just
removes all shadow pages, then let cpu retry the instruction, the
page can become writable when encounter #PF again, large spte
Re: [PATCH v3 0/2] NVIDIA Tegra DRM driver
On Friday 16 November 2012 05:28:21 Thierry Reding wrote: > This third version of the patch series cleans up some minor issues that > were found in the previous versions, such as deferred probe not working > properly and the display remaining enabled after the driver is removed. > > I've also put the two patches in this series into the tegra/drm/for-3.8 > branch of my repository on gitorious[0]. Pulled from your branch and tried to test on my Ventana, but for some reason nothing ever gets displayed. The only DRM-related message I ever get in my log is [0.820483] [drm] Initialized drm 1.1.0 20060810 Things were working perfectly with v2 - has something changed with e.g. the DT bindings? Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/ethernet/intel/ixgbe/ixgbe_debugfs.c: fix error handling in ixgbe_dbg_reg_ops_read().
copy_to_user() cannot return a negative value: it returns the number of bytes
that could not be copied.
Return -EFAULT on failure rather than the number of bytes that could not be
copied, as this seems more standard.
Signed-off-by: Cyril Roelandt
---
drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
index 8d3a218..77a3598 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
@@ -62,7 +62,6 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char
__user *buffer,
{
struct ixgbe_adapter *adapter = filp->private_data;
char buf[256];
- int bytes_not_copied;
int len;
/* don't allow partial reads */
@@ -73,9 +72,8 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char
__user *buffer,
adapter->netdev->name, ixgbe_dbg_reg_ops_buf);
if (count < len)
return -ENOSPC;
- bytes_not_copied = copy_to_user(buffer, buf, len);
- if (bytes_not_copied < 0)
- return bytes_not_copied;
+ if (copy_to_user(buffer, buf, len) > 0)
+ return -EFAULT;
*ppos = len;
return len;
--
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: [RFC PATCH 0/2] kvm/vmx: Output TSC offset
On Wed, Nov 14, 2012 at 10:36:21AM +0900, Yoshihiro YUNOMAE wrote: > Hi All, > > The following patch set can make disordered trace data of a guest and a host > sorted in chronological order. > > In a virtualization environment, it is difficult to analyze performance > problems, such as a delay of I/O request on a guest. This is because multiple > guests operate on the host. One of approaches for solving such kind of > problems > is to sort trace data of guests and the host in chronological order. > > After we applied the patch set(https://lkml.org/lkml/2012/11/13/588), raw TSC > can be chosen as a timestamp of ftrace. TSC is useful for merging trace data > in chronological order by two reasons. One of the reasons is that guests can > directly read raw TSC from the CPU using rdtsc operation. This means that raw > TSC value is not software clock like sched_clock, so we don't need to consider > about how the timestamp is calculated. The other is that TSC of recent x86 > CPUs > is constantly incremented. This means that we don't need to worry about pace > of > the timestamp. Therefore, choosing TSC as a timestamp for tracing is > reasonable > to integrate trace data of guests and a host. > > Here, we need to consider about just one matter for using TSC on guests. TSC > value on a guest is always the host TSC plus the guest's "TSC offset". In > other > words, to merge trace data using TSC as timestamp in chronological order, we > need to consider TSC offset of the guest. > > However, only the host kernel can read the TSC offset from VMCS and TSC offset > is not output in anywhere now. In other words, tools in userland cannot get > the TSC offset value, so we cannot merge trace data of guest and the host in > chronological order. Therefore, the TSC offset should be exported for userland > tools. > > In this patch set, TSC offset is exported by printk() on the host. I also > attached a tool for merging trace data of a guest and a host in chronological > order. > > > We assume that wakeup-latency for a command is big on a guest. Normally > we will use ftrace's wakeup-latency tracer or event tracer on the guest, but > we > may not be able to solve this problem. This is because guests often exit to > the host for several reasons. In the next, we will use TSC as ftrace's > timestamp > and record the trace data on the guest and the host. Then, we get following > data: > > /* guest data */ > comm-3826 [000] d...49836825726903: sched_wakeup: [detail] > comm-3826 [000] d...49836832225344: sched_switch: [detail] > /* host data */ > qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] > > Since TSC offset is not considered, these data cannot be merged. If this trace > data is shown like as follows, we will be able to understand the reason: > > qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > comm-3826 [000] d.h.49836825726903: sched_wakeup: [detail] <= > qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] > comm-3826 [000] d...49836832225344: sched_switch: [detail] <= > qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] > > In this case, we can understand wakeup-latency was big due to exit to host > twice. Getting this data sorted in chronological order is our goal. > > To merge the data like previous pattern, we apply this patch set. Then, we can > get TSC offset of the guest as follows: > > $ dmesg | grep kvm > [ 57.717180] kvm: (2687) write TSC offset 18446743360465545001, now clock ## > | > PID TSC offset | >HOST TSC value --+ > > We use this TSC offset value to a merge script and obtain the following data: > > $ ./trace-merge.pl 18446743360465545001 host.data guest.data > hqemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > hqemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > gcomm-3826 [000]
RE: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Basically, the flow goes like this: 1) We convert the original FADT (multiple versions) to a common internal FADT. 2) Then we check the common internal FADT for errors/inconsistencies. In this way, we don't need to have different error checking for different versions of the FADT, and this is probably not going to change. One thing we are going to add is to make a decision on whether to favor a 32-bit address or a 64-bit address (if they are different) based upon the age of the machine/BIOS. This is for Windows compatibility. Bob > -Original Message- > From: Ethan Zhao [mailto:ethan.ker...@gmail.com] > Sent: Thursday, November 15, 2012 6:29 PM > To: Moore, Robert > Cc: Brown, Len; Zheng, Lv; LKML > Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit > address of FACS/DSDT all have value but not equal to each other > > Bob, >Thanks for your detailed reviewing about the whole possible > conditions. >I.C. So that is impossible zero value for Xfacs /Xdsdt if > facs/dsdt >0, for they are assigned in acpi_tb_convert_fadt(), I need to > move my eyes one line code higher to see why it yelled twice but not using > the 32bit address at once in acpi_tb_convert_fadt(). >Do you agree to move the checking code warning and into > acpi_tb_convert_fadt to make the code more simple and clear ? Or just keep > it for more rework, more bug? > > > Thanks, > Ethan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
StyreneButadiene Rubbe r- shared photos with you
Hello Sir/Mam: Happy to contact you ! We would like to introudce our company.Our company is a large scale pertrochemical enterprise with synthetic rubber as the main product. We could supply SBR 1502 and 1712. It is manufactured by SINOPEC YANGZI. The following is the SBR quotation : * SBR 1502: USD 2500.00/TON FOB China port SBR 1712: USD 2350.00/TON FOB China port * packing : 35kg ppbag * quantity: 21ton/20'container * price validity: within 3 days . * payment terms : TT in advance or LC at sight . * delivery time: within 20 days . Any other question, contact me freely ! best wishes Adelle Liang rXuzhou Yizhengyuan Chemical Technology Co., Ltd <>
IRQ_FORCED_THREADING - possible build issue?
While trying to clean old cruft out of grub.conf, I
chased down a 'threadirqs' parameter.
kernel/irq/manage.c has this in it:
#ifdef CONFIG_IRQ_FORCED_THREADING
__read_mostly bool force_irqthreads;
static int __init setup_forced_irqthreads(char *arg)
{
force_irqthreads = true;
return 0;
}
early_param("threadirqs", setup_forced_irqthreads);
#endif
but the references to that variable in irq_thread() and
irq_setup_forced_threading() and elsewhere don't seem to
be similarly guarded. This can lead to a compile error if
IRQ_FORCED_THREADING isn't in the .config. Is this actually
being forced on all archs now? If so, the ifdef/endif is
probably superfluous. If not, what happens on archs that
don't force it?
(I tried to build-test it for myself and see, but apparently X86
selects the symbol and I haven't managed to figure out how to
get a compile that doesn't define it. Kbuild kept re-running config
and re-setting it. 'make ARCH=something allnoconfig' for some
value of something that doesn't do it?)
pgpaEJCJikKGA.pgp
Description: PGP signature
Re: [3.6.6] panic on reboot / khungtaskd blocked? (WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule)
On Fri 16-11-12 10:50:43, Michael Wang wrote: > On 11/15/2012 05:40 PM, Jan Kara wrote: > > On Thu 15-11-12 09:41:40, Michael Wang wrote: > >> On 11/15/2012 05:10 AM, Paweł Sikora wrote: > >>> On Wednesday 14 of November 2012 10:32:41 Michael Wang wrote: > On 11/13/2012 05:40 PM, Paweł Sikora wrote: > > On Monday 12 of November 2012 13:33:39 Paweł Sikora wrote: > >> On Monday 12 of November 2012 11:22:47 Paweł Sikora wrote: > >>> On Monday 12 of November 2012 15:40:31 Michael Wang wrote: > On 11/12/2012 03:16 PM, Paweł Sikora wrote: > > On Monday 12 of November 2012 11:04:12 Michael Wang wrote: > >> On 11/09/2012 09:48 PM, Paweł Sikora wrote: > >>> Hi, > >>> > >>> during playing with new ups i've caught an nice oops on reboot: > >>> > >>> http://imgbin.org/index.php?page=image=10253 > >>> > >>> probably the upstream is also affected. > >> > >> Hi, Paweł > >> > >> Are you using a clean 3.6.6 without any modify? > > > > yes, pure 3.6.6 form git tree with modular config. > > > >> Looks like some threads has set itself to be UNINTERRUPTIBLE with > >> out > >> any design on switch itself back later(or the time is too long), > >> are you > >> accidentally using some bad designed module? > > > > hmm, hard to say. mostly all modules are loaded automatically by > > kernel. > > Could you please provide the whole dmesg in text? your picture lost > the > print info of the hung task. > >>> > >>> i've grabbed the console via rs232 but there's no more info (see > >>> attached txt). > >> > >> hmm, i have one observation. > >> > >> during rc.shutdown there're messages on console like this: Cannot stat > >> file /proc/$pid/fd/1: Connection timed out > >> afaics this file descriptor points to vnc log file on a remote > >> machine, e.g.: > >> > >> # ps aux|grep xfwm4 > >> eda 1748 0.0 0.0 320220 11224 ?S13:08 0:00 xfwm4 > >> > >> # readlink -m /proc/1748/fd/1 > >> /remote/dragon/ahome/eda/.vnc/odra:11.log > >> > >> # mount|grep ahome > >> dragon:/home/users/ on /remote/dragon/ahome type nfs > >> (rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.2.121,mountvers=3,mountport=45251,mountproto=udp,local_lock=none,addr=10.0.2.121) > >> > >> > >> so, probably during `killall5 -TERM/-KILL` on shutdown stage something > >> sometimes go wrong > >> and these processes (xfce4/vncserver) survive the signal and hang on > >> the nfs i/o. > >> > > > > ok, now i have full sysrq+w backtraces from shutdown process. i hope > > i'll help you. > > This can only tell us what's the task in UNINTERRUPTABLE state, but with > out time info, we can't find out which one is the hung task... > >> > >> So it's blocked on __lock_page() for too long? > >> Add more experts in mm aspect to cc. > > It's really NFS related. E.g. in trace > > https://lkml.org/lkml/2012/11/14/657 we are waiting on PageWriteback bit > > in fact - i.e. we have submitted data to the NFS server and are waiting for > > its response that the data was written. > > Do you mean, NFS lock some page, then wait on a respond which not come in? Well, in that particular trace we are not waiting for PageLock but on PageWriteback bit as I wrote. But otherwise yes, NFS set PageWriteback bit and sent the data from the page to the server. When the server responds, the PageWriteback bit will get cleared and could continue. But the response didn't come. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX] PM: Fix active child counting when disabled and forbidden
On Thu, 2012-11-15 at 10:51 +0100, Rafael J. Wysocki wrote: > On Thursday, November 15, 2012 09:03:44 AM Huang Ying wrote: > > On Thu, 2012-11-15 at 00:10 +0100, Rafael J. Wysocki wrote: > > > On Wednesday, November 14, 2012 04:45:01 PM Alan Stern wrote: > > > > On Wed, 14 Nov 2012, Rafael J. Wysocki wrote: > > > > > > > > > > This has the side effect that when a driver unbinds, it can't leave > > > > > > the > > > > > > device in a special low-power state. The device will always end up > > > > > > in > > > > > > the generic low-power state supported by the PCI core. > > > > > > > > > > Well, I'm not sure I'd like that. > > > > > > > > > > Let's just go back even one step more and think what we'd like to > > > > > have in > > > > > general terms and then how to implement it. :-) > > > > > > > > > > Suppose that pci_pm_init() calls pm_runtime_enable() for all devices > > > > > (in > > > > > addition to what it does currently). The runtime PM status of each > > > > > device is > > > > > RPM_SUSPENDED at this point. Then: > > > > > > > > Wait a moment. When the device is detected and initialized, it is in > > > > D0, right? Currently we don't care much because the device starts out > > > > disabled for runtime PM. But now you are going to enable it. While > > > > the device is enabled, its runtime status should match the physical > > > > power level. > > > > > > OK > > > > If my memory were correct, RPM_SUSPENDED just means device stop working, > > but need not be put into low-power state. So for RPM_ACTIVE, PCI > > devices should be in D0, but for RPM_SUSPENDED, PCI devices can in any > > power state. > > Yes, that's correct and I was wrong when I thought we could require the > status to be RPM_ACTIVE all the time when there's no driver, because that > would prevent parents from being suspended. And we want them to be able to > suspend for driverless children, _unless_ user space has its attribute set > to "on" (i.e. the default). > > So it looks like what we want to do is: > > (1) Enable runtime PM in pci_pm_init() and set the status to RPM_ACTIVE right > before, so that it is in agreement with the pm_runtime_forbid() we do in > there. > > (2) If user space switches its attribute to "off" later, but before any > drivers are probed, we want the status to switch to RPM_SUSPENDED > _without_ actually changing the devices power state. For that, > I think, we can make the PCI bus type's runtime PM callback ignore > devices without drivers (i.e. return 0 for them). > > (3) When local_pci_probe() starts, after we've resumed the parent, > the device will be in D0 (it may be D0-uninitialized, though). But the pci_dev->current_state may be PCI_UNKNOWN, although the real state should be D0, because of commit: 2449e06a5696b7af1c8a369b04c97f3b139cf3bb. Best Regards, Huang Ying > If the user space's attribute is "on" at this point, the parent's > resume doesn't change anything. If it is "auto", the parent's > resume may actually transition the device, although its status > will still be RPM_SUSPENDED. For consistency _and_ compatibility > with the current code, the driver's .probe() routine needs to see > the device RPM_ACTIVE and usage_count incremented, but we don't > want to run its PM callbacks _before_ .probe() runs. For that > to work, I think, we can do something like > pm_runtime_get_skip_callbacks(), > treating the device as though it had the power.no_callbacks flag set, > right before calling ddi->drv->probe(). > > If the device has been RPM_ACTIVE at that point (i.e. user space has > had its attribute set to "on") it will just bump up usage_count (which > is what we want). If the device has been RPM_SUSPENDED, it will > bump up usage_count _and_ change the status to RPM_ACTIVE without > executing any callbacks (the device is in D0 anyway, right?), which > is what we want too. > > (4) If ddi->drv->probe() succeeds, we don't want to change anything, so > as not to confuse the driver, which is now in control of the device. > > (5) If ddi->drv->probe() fails, we need to restore the situation from > before calling local_pci_probe(), but we want the pm_runtime_put(parent) > at the end of it to actually suspend the parent if user space has > its attribute (for the child!) set to "auto". > > Assume that the driver is not buggy and the failing ddi->drv->probe() > leaves the device in the same configuration as it's received it in. > Then, the device is RPM_ACTIVE and in D0 (which may be uninitialized). > For the parent's suspend to work, we need to transition it to > RPM_SUSPENDED, but again we don't want the driver's PM callbacks to > run at this point. Moreover, we don't want the PCI bus type's > callbacks to run at this point, because dev->driver is still set. > So again, doing something like pm_runtime_put_skip_callbacks(), >
[PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
This patch check whether the fifo lenth is empty before writing new data to
fifo.If condition
is true,ifx_spi_write need to trigger one mrdy_assert. If condition is
false,the mrdy_assert
will be trigger by the next ifx_spi_io.
Cc: Bi Chao
Signed-off-by: Chen Jun
---
drivers/tty/serial/ifx6x60.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 5b9bc19..aa01989 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -469,9 +469,17 @@ static int ifx_spi_write(struct tty_struct *tty, const
unsigned char *buf,
{
struct ifx_spi_device *ifx_dev = tty->driver_data;
unsigned char *tmp_buf = (unsigned char *)buf;
- int tx_count = kfifo_in_locked(_dev->tx_fifo, tmp_buf, count,
- _dev->fifo_lock);
- mrdy_assert(ifx_dev);
+ int tx_count;
+ unsigned long flags;
+ bool is_fifo_empty;
+
+ spin_lock_irqsave(_dev->fifo_lock, flags);
+ is_fifo_empty = kfifo_is_empty(_dev->tx_fifo);
+ tx_count = kfifo_in(_dev->tx_fifo, tmp_buf, count);
+ spin_unlock_irqrestore(_dev->fifo_lock, flags);
+ if (is_fifo_empty)
+ mrdy_assert(ifx_dev);
+
return tx_count;
}
--
1.7.4.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] KVM: MMU: lazily drop large spte
On Thu, Nov 15, 2012 at 07:17:15AM +0800, Xiao Guangrong wrote:
> On 11/14/2012 10:37 PM, Marcelo Tosatti wrote:
> > On Tue, Nov 13, 2012 at 04:26:16PM +0800, Xiao Guangrong wrote:
> >> Hi Marcelo,
> >>
> >> On 11/13/2012 07:10 AM, Marcelo Tosatti wrote:
> >>> On Mon, Nov 05, 2012 at 05:59:26PM +0800, Xiao Guangrong wrote:
> Do not drop large spte until it can be insteaded by small pages so that
> the guest can happliy read memory through it
>
> The idea is from Avi:
> | As I mentioned before, write-protecting a large spte is a good idea,
> | since it moves some work from protect-time to fault-time, so it reduces
> | jitter. This removes the need for the return value.
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c | 34 +-
> 1 files changed, 9 insertions(+), 25 deletions(-)
> >>>
> >>> Its likely that other 4k pages are mapped read-write in the 2mb range
> >>> covered by a read-only 2mb map. Therefore its not entirely useful to
> >>> map read-only.
> >>>
> >>
> >> It needs a page fault to install a pte even if it is the read access.
> >> After the change, the page fault can be avoided.
> >>
> >>> Can you measure an improvement with this change?
> >>
> >> I have a test case to measure the read time which has been attached.
> >> It maps 4k pages at first (dirt-loggged), then switch to large sptes
> >> (stop dirt-logging), at the last, measure the read access time after write
> >> protect sptes.
> >>
> >> Before: 23314111 nsAfter: 11404197 ns
> >
> > Ok, i'm concerned about cases similar to e49146dce8c3dc6f44 (with shadow),
> > that is:
> >
> > - large page must be destroyed when write protecting due to
> > shadowed page.
> > - with shadow, it does not make sense to write protect
> > large sptes as mentioned earlier.
> >
>
> This case is removed now, the code when e49146dce8c3dc6f44 was applied is:
> |
> |pt = sp->spt;
> |for (i = 0; i < PT64_ENT_PER_PAGE; ++i)
> |/* avoid RMW */
> |if (is_writable_pte(pt[i]))
> |update_spte([i], pt[i] &
> ~PT_WRITABLE_MASK);
> |}
>
> The real problem in this code is it would write-protect the spte even if
> it is not a last spte that caused the middle-level shadow page table was
> write-protected. So e49146dce8c3dc6f44 added this code:
> |if (sp->role.level != PT_PAGE_TABLE_LEVEL)
> |continue;
> |
> was good to fix this problem.
>
> Now, the current code is:
> | for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
> | if (!is_shadow_present_pte(pt[i]) ||
> | !is_last_spte(pt[i], sp->role.level))
> | continue;
> |
> | spte_write_protect(kvm, [i], , false);
> | }
> It only write-protect the last spte. So, it allows large spte existent.
> (the large spte can be broken by drop_large_spte() on the page-fault path.)
>
> > So i wonder why is this part from your patch
> >
> > - if (level > PT_PAGE_TABLE_LEVEL &&
> > - has_wrprotected_page(vcpu->kvm, gfn, level)) {
> > - ret = 1;
> > - drop_spte(vcpu->kvm, sptep);
> > - goto done;
> > - }
> >
> > necessary (assuming EPT is in use).
>
> This is safe, we change these code to:
>
> - if (mmu_need_write_protect(vcpu, gfn, can_unsync)) {
> + if ((level > PT_PAGE_TABLE_LEVEL &&
> +has_wrprotected_page(vcpu->kvm, gfn, level)) ||
> + mmu_need_write_protect(vcpu, gfn, can_unsync)) {
> pgprintk("%s: found shadow page for %llx, marking ro\n",
>__func__, gfn);
> ret = 1;
>
> The spte become read-only which can ensure the shadow gfn can not be changed.
>
> Btw, the origin code allows to create readonly spte under this case if
> !(pte_access & WRITEABBLE)
Regarding shadow: it should be fine as long as fault path always deletes
large mappings, when shadowed pages are present in the region.
Ah, unshadowing from reexecute_instruction does not handle
large pages. I suppose that is what "simplification" refers
to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] audit: catch possible NULL buffers
It's possible for audit_log_start() to return NULL. Handle it in various
callers.
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
kernel/audit.c |4
kernel/audit_tree.c | 26 +-
kernel/audit_watch.c |2 ++
kernel/auditsc.c |8 ++--
4 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 40414e9..a219998 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -272,6 +272,8 @@ static int audit_log_config_change(char *function_name, int
new, int old,
int rc = 0;
ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
+ if (unlikely(!ab))
+ return rc;
audit_log_format(ab, "%s=%d old=%d auid=%u ses=%u", function_name, new,
old, from_kuid(_user_ns, loginuid), sessionid);
if (sid) {
@@ -619,6 +621,8 @@ static int audit_log_common_recv_msg(struct audit_buffer
**ab, u16 msg_type,
}
*ab = audit_log_start(NULL, GFP_KERNEL, msg_type);
+ if (unlikely(!*ab))
+ return rc;
audit_log_format(*ab, "pid=%d uid=%u auid=%u ses=%u",
task_tgid_vnr(current),
from_kuid(_user_ns, current_uid()),
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index ed206fd..29dc061 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -449,11 +449,26 @@ static int tag_chunk(struct inode *inode, struct
audit_tree *tree)
return 0;
}
+static void audit_log_remove_rule(struct audit_krule *rule)
+{
+ struct audit_buffer *ab;
+
+ ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
+ if (unlikely(!ab))
+ return;
+ audit_log_format(ab, "op=");
+ audit_log_string(ab, "remove rule");
+ audit_log_format(ab, " dir=");
+ audit_log_untrustedstring(ab, rule->tree->pathname);
+ audit_log_key(ab, rule->filterkey);
+ audit_log_format(ab, " list=%d res=1", rule->listnr);
+ audit_log_end(ab);
+}
+
static void kill_rules(struct audit_tree *tree)
{
struct audit_krule *rule, *next;
struct audit_entry *entry;
- struct audit_buffer *ab;
list_for_each_entry_safe(rule, next, >rules, rlist) {
entry = container_of(rule, struct audit_entry, rule);
@@ -461,14 +476,7 @@ static void kill_rules(struct audit_tree *tree)
list_del_init(>rlist);
if (rule->tree) {
/* not a half-baked one */
- ab = audit_log_start(NULL, GFP_KERNEL,
AUDIT_CONFIG_CHANGE);
- audit_log_format(ab, "op=");
- audit_log_string(ab, "remove rule");
- audit_log_format(ab, " dir=");
- audit_log_untrustedstring(ab, rule->tree->pathname);
- audit_log_key(ab, rule->filterkey);
- audit_log_format(ab, " list=%d res=1", rule->listnr);
- audit_log_end(ab);
+ audit_log_remove_rule(rule);
rule->tree = NULL;
list_del_rcu(>list);
list_del(>rule.list);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 9a9ae6e..3e29b7a 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -240,6 +240,8 @@ static void audit_watch_log_rule_change(struct audit_krule
*r, struct audit_watc
if (audit_enabled) {
struct audit_buffer *ab;
ab = audit_log_start(NULL, GFP_NOFS, AUDIT_CONFIG_CHANGE);
+ if (unlikely(!ab))
+ return;
audit_log_format(ab, "auid=%u ses=%u op=",
from_kuid(_user_ns,
audit_get_loginuid(current)),
audit_get_sessionid(current));
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 2f186ed..9a836b8 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1481,14 +1481,14 @@ static void show_special(struct audit_context *context,
int *call_panic)
audit_log_end(ab);
ab = audit_log_start(context, GFP_KERNEL,
AUDIT_IPC_SET_PERM);
+ if (unlikely(!ab))
+ return;
audit_log_format(ab,
"qbytes=%lx ouid=%u ogid=%u mode=%#ho",
context->ipc.qbytes,
context->ipc.perm_uid,
context->ipc.perm_gid,
context->ipc.perm_mode);
- if (!ab)
- return;
}
break; }
case AUDIT_MQ_OPEN: {
@@ -2775,6 +2775,8 @@ void audit_core_dumps(long signr)
return;
ab = audit_log_start(NULL,
Re: [PART3 Patch v2 13/14] page_alloc: use N_MEMORY instead N_HIGH_MEMORY change the node_states initialization
At 11/16/2012 08:29 AM, Andrew Morton Wrote:
> On Thu, 15 Nov 2012 16:57:36 +0800
> Wen Congyang wrote:
>
>> N_HIGH_MEMORY stands for the nodes that has normal or high memory.
>> N_MEMORY stands for the nodes that has any memory.
>>
>> The code here need to handle with the nodes which have memory, we should
>> use N_MEMORY instead.
>>
>> Since we introduced N_MEMORY, we update the initialization of node_states.
>
> reset_zone_present_pages() has been removed by the recently-queued
> revert-mm-fix-up-zone-present-pages.patch, so I dropped that hunk.
>
> We still have
>
> akpm:/usr/src/25> grep N_HIGH_MEMORY mm/page_alloc.c
> [N_HIGH_MEMORY] = { { [0] = 1UL } },
> node_set_state(nid, N_HIGH_MEMORY);
> if (N_NORMAL_MEMORY != N_HIGH_MEMORY &&
>
> which I hope is correct. Can you please check it?
>
Yes, it is correct.
We will introduce N_MEMORY nodemask in part4, and N_MEMORY is N_HIGH_MEMORY
in this patchset. So we don't init and update N_MEMORY nodemask in this
patchset.
Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [3.6.6] panic on reboot / khungtaskd blocked? (WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule)
On 11/15/2012 05:40 PM, Jan Kara wrote: > On Thu 15-11-12 09:41:40, Michael Wang wrote: >> On 11/15/2012 05:10 AM, Paweł Sikora wrote: >>> On Wednesday 14 of November 2012 10:32:41 Michael Wang wrote: On 11/13/2012 05:40 PM, Paweł Sikora wrote: > On Monday 12 of November 2012 13:33:39 Paweł Sikora wrote: >> On Monday 12 of November 2012 11:22:47 Paweł Sikora wrote: >>> On Monday 12 of November 2012 15:40:31 Michael Wang wrote: On 11/12/2012 03:16 PM, Paweł Sikora wrote: > On Monday 12 of November 2012 11:04:12 Michael Wang wrote: >> On 11/09/2012 09:48 PM, Paweł Sikora wrote: >>> Hi, >>> >>> during playing with new ups i've caught an nice oops on reboot: >>> >>> http://imgbin.org/index.php?page=image=10253 >>> >>> probably the upstream is also affected. >> >> Hi, Paweł >> >> Are you using a clean 3.6.6 without any modify? > > yes, pure 3.6.6 form git tree with modular config. > >> Looks like some threads has set itself to be UNINTERRUPTIBLE with out >> any design on switch itself back later(or the time is too long), are >> you >> accidentally using some bad designed module? > > hmm, hard to say. mostly all modules are loaded automatically by > kernel. Could you please provide the whole dmesg in text? your picture lost the print info of the hung task. >>> >>> i've grabbed the console via rs232 but there's no more info (see >>> attached txt). >> >> hmm, i have one observation. >> >> during rc.shutdown there're messages on console like this: Cannot stat >> file /proc/$pid/fd/1: Connection timed out >> afaics this file descriptor points to vnc log file on a remote machine, >> e.g.: >> >> # ps aux|grep xfwm4 >> eda 1748 0.0 0.0 320220 11224 ?S13:08 0:00 xfwm4 >> >> # readlink -m /proc/1748/fd/1 >> /remote/dragon/ahome/eda/.vnc/odra:11.log >> >> # mount|grep ahome >> dragon:/home/users/ on /remote/dragon/ahome type nfs >> (rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.2.121,mountvers=3,mountport=45251,mountproto=udp,local_lock=none,addr=10.0.2.121) >> >> >> so, probably during `killall5 -TERM/-KILL` on shutdown stage something >> sometimes go wrong >> and these processes (xfce4/vncserver) survive the signal and hang on the >> nfs i/o. >> > > ok, now i have full sysrq+w backtraces from shutdown process. i hope i'll > help you. This can only tell us what's the task in UNINTERRUPTABLE state, but with out time info, we can't find out which one is the hung task... >> >> So it's blocked on __lock_page() for too long? >> Add more experts in mm aspect to cc. > It's really NFS related. E.g. in trace > https://lkml.org/lkml/2012/11/14/657 we are waiting on PageWriteback bit > in fact - i.e. we have submitted data to the NFS server and are waiting for > its response that the data was written. Do you mean, NFS lock some page, then wait on a respond which not come in? Regards, Michael Wang > > Honza > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dt/platform: Use cell-index for device naming if available
On 11/15/2012 8:10 AM, Grant Likely wrote:
On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko
wrote:
On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote:
On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring
wrote:
On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
Use the cell-index property to construct names for platform
devices, falling back on the existing scheme of using the
device register address if cell-index is not specified.
The cell-index property is a more useful device identifier,
especially in systems containing several numbered instances
of a particular hardware block, since it more easily
illustrates how devices relate to each other.
Additionally, userspace software may rely on the classic
. naming scheme to access device attributes in
sysfs, without having to know the physical addresses of
that device on every platform the userspace software may
support. Using cell-index for device naming allows the
device addresses to be hidden from userspace and to be
exposed by logical device number without having to rely on
auxdata to perform name overrides. This allows userspace to
make assumptions about which sysfs nodes map to which
logical instance of a specific hardware block.
Signed-off-by: Stepan Moskovchenko
---
I had also considered using something like the linux,label property to
allow
custom names for platform devices without resorting to auxdata, but the
cell-index approach seems more in line with what cell-index was
intended for
and with what the pre-DT platform device naming scheme used to be.
Please let
me know if you think there is a better way to accomplish this.
This is just being sent out as an RFC for now. If there are no
objections, I
will send this out as an official patch, along with (or combined with)
a patch
to fix up the device names in things like clock tables of any affected
platforms.
cell-index is basically deprecated. This has been discussed multiple
times in the past. You can use auxdata if you really need to have the
old name.
Actually, I think it would be fine to use an /aliases entry to set the
device name. That's the place to put global namespace information.
g.
Ah, thank you. I would prefer to stay away from auxdata, since it involves
placing more platform-specific data into the kernel, and it is my
understanding that auxdata is intended as a temporary measure. The
/aliases approach looks interesting, and I'll see what I can do with it -
hopefully I can have an RFC / patch soon. It looks like we would want an
"inverse" alias lookup- that is, we would need to know which alias
corresponds to a given node. Is it possible for a node to have multiple
aliases?
yes
If so, which shall we use to create the device name? Anyway, I
will further look into how these aliases work.
Well, why exactly do you want to control the names of devices? Is it so
that devices match up with what they are, or is it to make things match
up with things like clocks and regulators. If it is the latter, then no,
don't do this. Use auxdata. When the kernel requires a specific name for
a device it is very much a kernel *internal* detail. It does not make
sense to encode that into the device tree when it isn't something part
of the binding.
Steve
Hi Grant,
Looking through the alias code, I see that the stem and the alias ID are
stored and parsed separately. For the current way of using aliases, this
makes sense. However, can you please clarify what you meant by using an
/aliases entry to set the device name?
The first and most straightforward approach would be to use the entire
alias name as the device name, making no distinction between the alias
stem and ID. However, since it is possible to have multiple aliases to
the same device, which of the aliases shall we use to construct the
device name? Additionally, this may cause possible problems for legacy
software that expects names in the format of ., since '.' is
not a valid character for alias names as defined by the DT spec,
although strictly speaking this approach would successfully solve the
problem of giving devices predictable and controllable names.
Another way an /aliases entry could be used to set the device name is to
have a . naming scheme, where the name comes from node->name
(as is done in of_device_make_bus_id) and the ID gets queried using
of_alias_get_id(). We would need to create a new alias stem for this
purpose, and suppose that something like "platform" would work. The
name-setting code would then roughly look as follows:
+ alias_id = of_alias_get_id(node, "platform");
+ if (alias_id != -ENODEV) {
+ dev_set_name(dev, "%s.%d", node->name, alias_id);
+ return;
+ }
The downside to this approach is that it imposes the restriction that
device ID numbers now have to be unique throughout the system, whereas
before only the . combinations had to be unique. This is the
result of only the ID number being present in the alias table, with each
such ID number
[PATCH] Autoselect more relevant frontends for EM28XX DVB stick
Compiling up 3.6.6 for my media box recently I noticed that the EM28XX DVB driver doesn't auto select all of the appropriate DVB tuner modules required. In particular I needed DVB_LGDT3305 for my a340, but it looks like DVB_MT352 + DVB_S5H1409 were missing as well. Patch below adds the appropriate select lines to the Kconfig and is against Linus' current mainline. Signed-Off-By: Jonathan McDowell - diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig index 7a5bd61..617c6e4 100644 --- a/drivers/media/usb/em28xx/Kconfig +++ b/drivers/media/usb/em28xx/Kconfig @@ -34,6 +34,7 @@ config VIDEO_EM28XX_DVB tristate "DVB/ATSC Support for em28xx based TV cards" depends on VIDEO_EM28XX && DVB_CORE select DVB_LGDT330X if MEDIA_SUBDRV_AUTOSELECT + select DVB_LGDT3305 if MEDIA_SUBDRV_AUTOSELECT select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT select DVB_TDA10023 if MEDIA_SUBDRV_AUTOSELECT select DVB_S921 if MEDIA_SUBDRV_AUTOSELECT @@ -43,6 +44,8 @@ config VIDEO_EM28XX_DVB select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT select DVB_A8293 if MEDIA_SUBDRV_AUTOSELECT + select DVB_MT352 if MEDIA_SUBDRV_AUTOSELECT + select DVB_S5H1409 if MEDIA_SUBDRV_AUTOSELECT select VIDEOBUF_DVB ---help--- This adds support for DVB cards based on the - J. -- Revd Jonathan McDowell, ULC | This screen intentionally left blank. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tty: Added a CONFIG_TTY option to allow removal of TTY
The option allows you to remove TTY and compile without errors. This saves space on systems that won't support TTY interfaces anyway. bloat-o-meter output is below. The bulk of this patch consists of Kconfig changes adding "depends on TTY" to various serial devices and similar drivers that require the TTY layer. Ideally, these dependencies would occur on a common intermediate symbol such as SERIO, but most drivers "select SERIO" rather than "depends on SERIO", and "select" does not respect dependencies. bloat-o-meter output filtered to not show removed entries with awk '$3 != "-"' as the list was very long. add/remove: 0/385 grow/shrink: 2/18 up/down: 14/-54016 (-54002) function old new delta chr_dev_init 193 205 +12 selinux_setprocattr 11671169 +2 static.__warned 557 556 -1 start_kernel 840 835 -5 proc_root_init 167 162 -5 unregister_console 165 157 -8 sys_setsid 213 205 -8 sys_vhangup 37 21 -16 daemonize689 673 -16 t_stop72 54 -18 t_next 129 108 -21 static.do_acct_process 838 806 -32 release_task11571125 -32 do_exit 23252288 -37 t_start 269 221 -48 static.__func__18289 18219 -70 do_task_stat29622892 -70 flush_unauthorized_files 740 614-126 static._rs 14401280-160 static.__key85608384-176 Signed-off-by: Joe Millenbach Reviewed-by: Josh Triplett --- v3: Incorporated feedback from Jiri Slaby: fixed compilation issues on non x86/x64 platforms by finding all calls to alloc_tty_driver and tty_alloc_driver, then added "depends on" or "selects" TTY to config options that enabled compilation of those files. Also rebased to newer kernel sources. v2: Incorporated feedback from Alan Cox: used "if TTY ... endif" to wrap long runs of symbols that all need "depends on TTY"; grouped all the stubbed-out functions together in linux/tty.h. arch/alpha/Kconfig|2 ++ arch/ia64/hp/sim/Kconfig |1 + arch/m68k/Kconfig.devices |2 +- arch/parisc/Kconfig |1 + arch/tile/Kconfig |1 + arch/um/Kconfig.common|1 + arch/xtensa/Kconfig |1 + drivers/bluetooth/Kconfig |1 + drivers/char/Kconfig |7 +++--- drivers/char/pcmcia/Kconfig |4 +-- drivers/i2c/busses/Kconfig|2 +- drivers/input/joystick/Kconfig|4 +++ drivers/input/keyboard/Kconfig| 10 +++- drivers/input/mouse/Kconfig |3 +++ drivers/input/serio/Kconfig |1 + drivers/input/touchscreen/Kconfig | 24 +- drivers/isdn/Kconfig |1 + drivers/isdn/capi/Kconfig |1 + drivers/isdn/gigaset/Kconfig |1 + drivers/isdn/hardware/mISDN/Kconfig |1 + drivers/lguest/Kconfig|2 +- drivers/media/radio/wl128x/Kconfig|2 +- drivers/misc/Kconfig |2 +- drivers/misc/ti-st/Kconfig|2 +- drivers/mmc/card/Kconfig |1 + drivers/net/caif/Kconfig |2 +- drivers/net/can/Kconfig |2 +- drivers/net/hamradio/Kconfig |4 +-- drivers/net/irda/Kconfig |2 +- drivers/net/ppp/Kconfig |3 +++ drivers/net/slip/Kconfig |1 + drivers/net/usb/Kconfig |4 +-- drivers/net/wan/Kconfig |2 +- drivers/pps/clients/Kconfig |2 +- drivers/s390/char/Kconfig |8 +++--- drivers/staging/ccg/Kconfig |2 +- drivers/staging/dgrp/Kconfig |2 +- drivers/staging/ipack/devices/Kconfig |2 +- drivers/tty/Kconfig | 13 ++ drivers/tty/Makefile |2 +- drivers/tty/hvc/Kconfig |3 +++ drivers/tty/serial/Kconfig|4 +++ drivers/usb/class/Kconfig |2 +- drivers/usb/gadget/Kconfig|6 + drivers/usb/serial/Kconfig|2 +- fs/proc/Makefile |3 ++- include/linux/console.h |5 include/linux/proc_fs.h
Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Bob, Thanks for your detailed reviewing about the whole possible conditions. I.C. So that is impossible zero value for Xfacs /Xdsdt if facs/dsdt >0, for they are assigned in acpi_tb_convert_fadt(), I need to move my eyes one line code higher to see why it yelled twice but not using the 32bit address at once in acpi_tb_convert_fadt(). Do you agree to move the checking code warning and into acpi_tb_convert_fadt to make the code more simple and clear ? Or just keep it for more rework, more bug? Thanks, Ethan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] irq_work: Remove CONFIG_HAVE_IRQ_WORK
irq work can run on any arch even without IPI support because of the hook on update_process_times(). So lets remove HAVE_IRQ_WORK because it doesn't reflect any backend requirement. Signed-off-by: Frederic Weisbecker Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Andrew Morton Cc: Steven Rostedt Cc: Paul Gortmaker --- arch/alpha/Kconfig |1 - arch/arm/Kconfig|1 - arch/arm64/Kconfig |1 - arch/blackfin/Kconfig |1 - arch/frv/Kconfig|1 - arch/hexagon/Kconfig|1 - arch/mips/Kconfig |1 - arch/parisc/Kconfig |1 - arch/powerpc/Kconfig|1 - arch/s390/Kconfig |1 - arch/sh/Kconfig |1 - arch/sparc/Kconfig |1 - arch/x86/Kconfig|1 - drivers/staging/iio/trigger/Kconfig |1 - init/Kconfig|4 15 files changed, 0 insertions(+), 18 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 5dd7f5d..e56c2d1 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -5,7 +5,6 @@ config ALPHA select HAVE_IDE select HAVE_OPROFILE select HAVE_SYSCALL_WRAPPERS - select HAVE_IRQ_WORK select HAVE_PCSPKR_PLATFORM select HAVE_PERF_EVENTS select HAVE_DMA_ATTRS diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ade7e92..22d378b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -36,7 +36,6 @@ config ARM select HAVE_GENERIC_HARDIRQS select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)) select HAVE_IDE if PCI || ISA || PCMCIA - select HAVE_IRQ_WORK select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZMA select HAVE_KERNEL_LZO diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index ef54a59..dd50d72 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -17,7 +17,6 @@ config ARM64 select HAVE_GENERIC_DMA_COHERENT select HAVE_GENERIC_HARDIRQS select HAVE_HW_BREAKPOINT if PERF_EVENTS - select HAVE_IRQ_WORK select HAVE_MEMBLOCK select HAVE_PERF_EVENTS select HAVE_SPARSE_IRQ diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index b6f3ad5..86f891f 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -24,7 +24,6 @@ config BLACKFIN select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_TRACE_MCOUNT_TEST select HAVE_IDE - select HAVE_IRQ_WORK select HAVE_KERNEL_GZIP if RAMKERNEL select HAVE_KERNEL_BZIP2 if RAMKERNEL select HAVE_KERNEL_LZMA if RAMKERNEL diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index df2eb4b..c44fd6e 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -3,7 +3,6 @@ config FRV default y select HAVE_IDE select HAVE_ARCH_TRACEHOOK - select HAVE_IRQ_WORK select HAVE_PERF_EVENTS select HAVE_UID16 select HAVE_GENERIC_HARDIRQS diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index 0744f7d..40a3185 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -14,7 +14,6 @@ config HEXAGON # select HAVE_CLK # select IRQ_PER_CPU # select GENERIC_PENDING_IRQ if SMP - select HAVE_IRQ_WORK select GENERIC_ATOMIC64 select HAVE_PERF_EVENTS select HAVE_GENERIC_HARDIRQS diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index dba9390..3d86d69 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -4,7 +4,6 @@ config MIPS select HAVE_GENERIC_DMA_COHERENT select HAVE_IDE select HAVE_OPROFILE - select HAVE_IRQ_WORK select HAVE_PERF_EVENTS select PERF_USE_VMALLOC select HAVE_ARCH_KGDB diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 11def45..8f0df47 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -9,7 +9,6 @@ config PARISC select RTC_DRV_GENERIC select INIT_ALL_POSSIBLE select BUG - select HAVE_IRQ_WORK select HAVE_PERF_EVENTS select GENERIC_ATOMIC64 if !64BIT select HAVE_GENERIC_HARDIRQS diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a902a5c..a90f0c9 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -118,7 +118,6 @@ config PPC select HAVE_SYSCALL_WRAPPERS if PPC64 select GENERIC_ATOMIC64 if PPC32 select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE - select HAVE_IRQ_WORK select HAVE_PERF_EVENTS select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64 diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 5dba755..0816ff0 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -78,7 +78,6 @@ config S390 select HAVE_KVM if 64BIT select
