Re: [PATCH 10/10] PCI, sparc: clip firmware assigned resource under parent bridge's
Hi,
Am I missing something or is this just code to get the the resource
subsystem to accept the bus resources, not caring if the resources are
actually usable? PCI BARs usually have a given size for a reason?
-
Kjetil Oftedal
On 12/01/2015, Yinghai Lu wrote:
> Some bios put range that is not fully coverred by root bus resources.
> Try to clip them and update them in pci bridge bars.
>
> We'd like to fix other arches instead of just x86.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
> Reported-by: Marek Kordik
> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
> 64-bit resources")
> Signed-off-by: Yinghai Lu
> Cc: "David S. Miller"
> Cc: Paul Gortmaker
> Cc: Yijing Wang
> Cc: Sam Ravnborg
> Cc: sparcli...@vger.kernel.org
> ---
> arch/sparc/kernel/pci.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
> index b36365f..0e391e5 100644
> --- a/arch/sparc/kernel/pci.c
> +++ b/arch/sparc/kernel/pci.c
> @@ -623,6 +623,7 @@ static void pci_claim_bus_resources(struct pci_bus
> *bus)
> struct pci_dev *dev;
>
> list_for_each_entry(dev, &bus->devices, bus_list) {
> + bool changed = false;
> int i;
>
> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> @@ -639,8 +640,25 @@ static void pci_claim_bus_resources(struct pci_bus
> *bus)
> (unsigned long long)r->end,
> (unsigned int)r->flags);
>
> - pci_claim_resource(dev, i);
> + if (pci_claim_resource(dev, i) >= 0)
> + continue;
> +
> + if (dev->subordinate &&
> + i >= PCI_BRIDGE_RESOURCES &&
> + i < PCI_NUM_RESOURCES &&
> + (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
> + pci_bus_clip_resource(dev, r)) {
> + changed = true;
> + pci_claim_resource(dev, i);
> + } else if (i < PCI_BRIDGE_RESOURCES &&
> +i != PCI_ROM_RESOURCE &&
> +pci_bus_clip_resource(dev, r)) {
> + pci_update_resource(dev, i);
> + pci_claim_resource(dev, i);
> + }
> }
> + if (changed)
> + pci_setup_bridge(dev->subordinate);
> }
>
> list_for_each_entry(child_bus, &bus->children, node)
> --
> 1.8.4.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/2] mm: vmscan: init reclaim_state in do_try_to_free_pages
On Mon, Jan 12, 2015 at 12:30:38PM +0300, Vladimir Davydov wrote: > All users of do_try_to_free_pages() want to have current->reclaim_state > set in order to account reclaimed slab pages. So instead of duplicating > the reclaim_state initialization code in each call site, let's do it > directly in do_try_to_free_pages(). Couldn't this be contained in shrink_slab() directly? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.18 regression]: machine hangs on s2ram
> Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do > s2ram. For me it looks like the preparations work, but the machine is then > not switched off. The only way to recover is a hard powercycle. Since the > machine has no serial port I can't look what's happening then, but the logs > do not contain anything suspicious until the point when the machine locks > up. Meanwhile I see this on a different machine (Core i7 desktop), too. I'll see if I can dig out any more information there. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH -mm 1/2] mm: vmscan: account slab pages on memcg reclaim
On Mon, Jan 12, 2015 at 12:30:37PM +0300, Vladimir Davydov wrote:
> Since try_to_free_mem_cgroup_pages() can now call slab shrinkers, we
> should initialize reclaim_state and account reclaimed slab pages in
> scan_control->nr_reclaimed.
>
> Signed-off-by: Vladimir Davydov
> ---
> mm/vmscan.c | 33 ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 16f3e45742d6..b2c041139a51 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -367,13 +367,16 @@ static unsigned long do_shrink_slab(struct
> shrink_control *shrinkctl,
> * the ->seeks setting of the shrink function, which indicates the
> * cost to recreate an object relative to that of an LRU page.
> *
> - * Returns the number of reclaimed slab objects.
> + * Returns the number of reclaimed slab objects. The number of reclaimed
> + * pages is added to *@ret_nr_reclaimed.
>
> static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>struct mem_cgroup *memcg,
>unsigned long nr_scanned,
> - unsigned long nr_eligible)
> + unsigned long nr_eligible,
> + unsigned long *ret_nr_reclaimed)
Can't we just return the number of pages directly from this function?
> @@ -426,7 +434,7 @@ void drop_slab_node(int nid)
> freed = 0;
> do {
> freed += shrink_slab(GFP_KERNEL, nid, memcg,
> - 1000, 1000);
> + 1000, 1000, &nr_reclaimed);
> } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> } while (freed > 10);
This is the only caller that cares about the return value, and it's a
magic number that could probably be changed to comparing with a magic
number of pages instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Edited kexec_load(2) [kexec_file_load()] man page for review
On Wed, Jan 07, 2015 at 10:17:56PM +0100, Michael Kerrisk (man-pages) wrote:
[..]
> >> .BR KEXEC_ON_CRASH " (since Linux 2.6.13)"
> >> Execute the new kernel automatically on a system crash.
> >> .\" FIXME Explain in more detail how KEXEC_ON_CRASH is actually used
>
> I wasn't expecting that you would respond to the FIXMEs that were
> not labeled "kexec_file_load", but I was hoping you might ;-). Thanks!
> I have a few additional questions to your nice notes.
>
> > Upon boot first kernel reserves a chunk of contiguous memory (if
> > crashkernel=<> command line paramter is passed). This memory is
> > is used to load the crash kernel (Kernel which will be booted into
> > if first kernel crashes).
>
Hi Michael,
> Can I just confirm: is it in all cases only possible to use kexec_load()
> and kexec_file_load() if the kernel was booted with the 'crashkernel'
> parameter set?
As of now, only kexec_load() and kexec_file_load() system calls can
make use of memory reserved by crashkernel=<> kernel parameter. And
this is used only if we are trying to load a crash kernel (KEXEC_ON_CRASH
flag specified).
>
> > Location of this reserved memory is exported to user space through
> > /proc/iomem file.
>
> Is that export via an entry labeled "Crash kernel" in the
> /proc/iomem file?
Yes.
>
> > User space can parse it and prepare list of segments
> > specifying this reserved memory as destination.
>
> I'm not quite clear on "specifying this reserved memory as destination".
> Is that done by specifying the address in the kexec_segment.mem fields?
You are absolutely right. User space can specify in kexec_segment.mem
field the memory location where it expecting a particular segment to
be loaded by kernel.
>
> > Once kernel sees the flag KEXEC_ON_CRASH, it makes sure that all the
> > segments are destined for reserved memory otherwise kernel load operation
> > fails.
>
> Could you point me to where this checking is done? Also, what is the
> error (errno) that occurs when the load operation fails? (I think the
> answers to these questions are "at the start of kimage_alloc_init()"
> and "EADDRNOTAVAIL", but I'd like to confirm.)
This checking happens in sanity_check_segment_list() which is called
by kimage_alloc_init().
And yes, error code returned is -EADDRNOTAVAIL.
>
> > [..]
> >> struct kexec_segment {
> >> void *buf;/* Buffer in user space */
> >> size_t bufsz; /* Buffer length in user space */
> >> void *mem;/* Physical address of kernel */
> >> size_t memsz; /* Physical address length */
> >> };
> >> .fi
> >> .in
> >> .PP
> >> .\" FIXME Explain the details of how the kernel image defined by segments
> >> .\" is copied from the calling process into previously reserved memory.
> >
> > Kernel image defined by segments is copied into kernel either in regular
> > memory
>
> Could you clarify what you mean by "regular memory"?
I meant memory which is not reserved memory.
>
> > or in reserved memory (if KEXEC_ON_CRASH is set). Kernel first
> > copies list of segments in kernel memory and then goes does various
> > sanity checks on the segments. If everything looks line, kernel copies
> > segment data to kernel memory.
> >
> > In case of normal kexec, segment data is loaded in any available memory
> > and segment data is moved to final destination at the kexec reboot time.
>
> By "moved to final destination", do you mean "moved from user space to the
> final kernel-space destination"?
No. Segment data moves from user space to kernel space once kexec_load()
call finishes successfully. But when user does reboot (kexec -e), at that
time kernel moves that segment data to its final location. Kernel could
not place the segment at its final location during kexec_load() time as
that memory is already in use by running kernel. But once we are about
to reboot to new kernel, we can overwrite the old kernel's memory.
>
> > In case of kexec on panic (KEXEC_ON_CRASH flag set), segment data is
> > directly loaded to reserved memory and after crash kexec simply jumps
>
> By "directly", I assume you mean "at the time of the kexec_laod() call",
> right?
Yes.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: >> >> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart >> >> wrote: >> >> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: >> >> >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: >> >> >> > thinkpad-acpi using software mute simplifies the driver and the user >> >> >> > experience >> >> >> > significantly. >> >> >> >> >> >> Except when it doesn't. >> >> >> >> >> >> I'm probably in minority, but I don't use fancy userspace to mess with >> >> >> my >> >> >> mixer and the mute button worked just fine for me before the change. >> >> >> Wasted half an hour to find out what happened is not a pure win from >> >> >> user >> >> >> experience point of view. >> >> >> >> >> >> Is it really necessary to have software_mute_requested == true by >> >> >> default? >> >> >> Can fancy userspace ask for desired behaviour instead and change >> >> >> kernel to >> >> >> not send hotkeys change notification until software_mute is enabled? >> >> >> >> >> >> -- >> >> >> Kirill A. Shutemov >> >> >> >> >> > >> >> > Thanks for the report Kirill, >> >> > >> >> > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only >> >> > have a >> >> > couple weeks to do so. >> >> > >> >> > Kirill, to define the scope of the problem, if you specify >> >> > software_mute_requested as false on the kernel command line, does your >> >> > system >> >> > function as expected? >> >> >> >> If I understood Kirill's email correctly, the only issue is that he >> >> liked the old behavior. Kirill, is that correct? >> > >> > Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour. >> > >> >> What aspect of the old behavior is better than the new default behavior? > > It's not necessary better. The new behavior just broke my use-case. > > I don't have anything in my system what would react on KEY_MUTE and I used > the functionality platform provides until it suddenly stopped working. > > I personally can live with new thinkpad_acpi. I'll probably update my > configuration to react on the software button. > > But who else will get frustrated after update to v3.19? Can you try the equivalent of: bindsym XF86AudioMute exec amixer -q set Master toggle for your desktop environment? Note that this is exactly what you'd do if you were using any laptop that wasn't a thinkpad. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memcg: add BUILD_BUG_ON() for string tables
On Mon, Jan 12, 2015 at 10:54:23AM -0800, Greg Thelen wrote: > Use BUILD_BUG_ON() to compile assert that memcg string tables are in > sync with corresponding enums. There aren't currently any issues with > these tables. This is just defensive. > > Signed-off-by: Greg Thelen Looks good to me, thanks Greg. Acked-by: Johannes Weiner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE()
On Mon, Jan 12, 2015 at 09:59:57AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 09, 2015 at 10:58:50PM +0100, Christian Borntraeger wrote:
> > Am 09.01.2015 um 14:56 schrieb Peter Zijlstra:
> > > On Fri, Jan 09, 2015 at 05:49:54AM -0800, Paul E. McKenney wrote:
> > >>> That reminds me, I think the new conversion for stores will most likely
> > >>> introduce silly arg bugs:
> > >>>
> > >>> - ACCESS_ONCE(a) = b;
> > >>> + ASSIGN_ONCE(b, a);
> > >>
> > >> I was planning to do mine by hand for this sort of reason.
> > >>
> > >> Or are you thinking of something more subtle than the case where
> > >> "b" is an unparenthesized comma-separated expression?
> > >
> > > I think he's revering to the wrong way around-ness of the thing.
> > >
> > > Its a bit of a mixed bag on assignments, but for instance
> > > rcu_assign_pointer() takes them the right way around, as does
> > > atomic_set().
> > >
> > > So yes, I think the ASSIGN_ONCE() thing got the arguments the wrong way
> > > around.
> > >
> > > We could maybe still change it, before its in too long ?
> >
> > Linus initial proposal was inspired by put_user model which is (val,
> > ptr) and I took that.
>
> Yeah, like I said, its a bit of a mixed bag. We've got plenty examples
> of the wrong way around.
>
> > As my focus was on avoiding the volatile bug,
> > all my current conversions are READ_ONCE as no potential ASSIGN_ONCE
> > user was done on a non-scalar type, so I have no first hand
> > experience.
>
> So the implication there is that we'd preserve ACCESS_ONCE() for use on
> scalar types. I don't think we should do that, I think we should just
> en-mass convert to {READ,WRITE}/{LOAD,STORE}_ONCE() and kill off
> ACCESS_ONCE().
Yep. For one thing, the proposed replacements work much better with
C11 than does ACCESS_ONCE().
> > I am fine with changing that, though, both ways have pros
> > and cons. Last time I checked in Linus tree there was no ASSIGN_ONCE
> > user.
>
> Right, so Davidlohr just introduced a few in my tree :-), which is how I
> came to know we even had this stuff..
>
> > When we talk about changing the parameters it might make sense to also
> > think about some comments from George Spelvin and consider a rename to
> > WRITE_ONCE or STORE_ONCE (READ_ONCE --> LOAD_ONCE).
>
> I'd be OK with that.
>
> > Unfortunately
> > there doesnt seem to be a variant that is fool proof (in the sense of
> > Rustys guideline that a good interface cannot be used wrong). So any
> > proposal in that regard would be very welcome.
>
> If you want fool proof, I think we should discard C ;-) Then again, I've
> yet to see a programming language that would not let a human make a
> proper idiot out of himself.
Limit NR_CPUS to zero! It is the only way!!!
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: fixes for 3.19 #1 (ter)
On Mon, Jan 12, 2015 at 04:27:52PM +0100, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > Here is the fixes pull-request for 3.19 that supersedes the ones already sent. > It collects all the fixes that I have currently for this kernel revision. > > Thanks, best regards, > > The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: > > Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-fixes > > for you to fetch changes up to b8659752c37ec157ee254cff443b1c9d523aea22: > > ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree (2015-01-12 > 15:50:23 +0100) Thanks Nicolas, now merged! -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 net-net 0/2] Increase the limit of tuntap queues
From: Pankaj Gupta Date: Mon, 12 Jan 2015 11:41:27 +0530 > Networking under KVM works best if we allocate a per-vCPU rx and tx > queue in a virtual NIC. This requires a per-vCPU queue on the host side. > Modern physical NICs have multiqueue support for large number of queues. > To scale vNIC to run multiple queues parallel to maximum number of vCPU's > we need to increase number of queues support in tuntap. Series applied, thanks for following up on this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: sched: sch_teql: Remove unused function
From: Rickard Strandqvist Date: Sun, 11 Jan 2015 15:08:46 +0100 > Remove the function teql_neigh_release() that is not used anywhere. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist 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-next v1] net: bnx2x: avoid macro redefinition
From: David Decotigny Date: Sun, 11 Jan 2015 11:42:37 -0800 > From: David Decotigny > > Signed-off-by: David Decotigny 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: xfrm: xfrm_algo: Remove unused function
From: Rickard Strandqvist Date: Sun, 11 Jan 2015 14:03:35 +0100 > Remove the function aead_entries() that is not used anywhere. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist 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: [3.16.y-ckt stable] Linux 3.16.7-ckt4 stable review
On Mon, Jan 12, 2015 at 09:30:45PM +0100, Thomas Voegtle wrote: > On Mon, 12 Jan 2015, Luis Henriques wrote: > > >This is the start of the review cycle for the Linux 3.16.7-ckt4 stable > >kernel. > > > >This version contains 216 new patches, summarized below. The new patches are > >posted as replies to this message and also available in this git branch: > > > >http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.16.y-review;a=shortlog > > > >git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y-review > > > >The review period for version 3.16.7-ckt4 will be open for the next three > >days. > >To report a problem, please reply to the relevant follow-up patch message. > > > >For more information about the Linux 3.16.y-ckt extended stable kernel > >version, > >see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable . > > > Something is wrong with drm/i915 (I guess). I had a terrible memleak on Xorg > when using mplayer using more and more RAM, and then the system is swapping > itself to death. > > I'm using a openSUSE 13.1 (x86_64) on a Baytrail J1900 (this is Intel HD > Gen7). > > Thank you for reporting, Thomas. Can you please confirm that this is actually a regression in 3.16.7-ckt4 (i.e., that you can't reproduce it in 3.16.7-ckt3)? If so, is it possible to bisecting it? Cheers, -- Luís > Thomas > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 22/40] tile: fix put_user sparse errors
Nack for this patch as-is.
On 1/6/2015 10:44 AM, Michael S. Tsirkin wrote:
virtio wants to write bitwise types to userspace using put_user.
At the moment this triggers sparse errors, since the value is passed
through an integer.
For example:
__le32 __user *p;
__le32 x;
put_user(x, p);
is safe, but currently triggers a sparse warning on tile.
The reason has to do with this code:
__typeof((x)-(x))
which seems to be a way to force check for an integer type.
No, it's purely a way to avoid
warning: cast from pointer to integer of different size
at every place we invoke put_user() with a pointer - which is
in fact pretty frequent throughout the kernel. The idiom of
casting to the difference of the type converts it to a type
of the same size as the input (whether integral or pointer),
but guaranteed to be an integral type. Then from there it's safe
to cast it on to a u64 without generating a warning.
I agree that letting sparse work correctly in this case seems
like an important goal. But I don't think we can tolerate
adding a raft of warnings to the standard kernel build for this
case, and we also can't just delete the put_user_8 case altogether,
since it's used for various things even in 32-bit kernels.
I suppose we could do something like the following. It's mildly
unfortunate that we'd lose out on some inlining optimization, though:
--- a/arch/tile/include/asm/uaccess.h
+++ b/arch/tile/include/asm/uaccess.h
@@ -244,24 +244,8 @@ extern int __get_user_bad(void)
#define __put_user_1(x, ptr, ret) __put_user_asm(sb, x, ptr, ret)
#define __put_user_2(x, ptr, ret) __put_user_asm(sh, x, ptr, ret)
#define __put_user_4(x, ptr, ret) __put_user_asm(sw, x, ptr, ret)
-#define __put_user_8(x, ptr, ret) \
- ({ \
- u64 __x = (__typeof((x)-(x)))(x); \
- int __lo = (int) __x, __hi = (int) (__x >> 32); \
- asm volatile("1: { sw %1, %2; addi %0, %1, 4 }\n" \
-"2: { sw %0, %3; movei %0, 0 }\n" \
-".pushsection .fixup,\"ax\"\n" \
-"0: { movei %0, %4; j 9f }\n" \
-".section __ex_table,\"a\"\n" \
-".align 4\n" \
-".word 1b, 0b\n" \
-".word 2b, 0b\n" \
-".popsection\n"\
-"9:" \
-: "=&r" (ret) \
-: "r" (ptr), "r" (__lo32(__lo, __hi)), \
-"r" (__hi32(__lo, __hi)), "i" (-EFAULT)); \
- })
+#define __put_user_8(x, ptr, ret) \
+ (ret = __copy_to_user_inatomic(ptr, &x, 8) == 0 ? 0 : -EFAULT)
#endif
extern int __put_user_bad(void)
Since this is part of __put_user_8 which is only ever used
for unsigned and signed char types, this seems unnecessary -
I also note that no other architecture has such protections.
Maybe because none of the other 32-bit kernel architectures provide
a 64-bit inline for put_user().
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] GPIO fixes for the v3.19 series
Hi Linus, here are some GPIO fixes, mainly affecting the DLN2 IRQ handling. Nothing special about them, just fixes. Please pull them in! Yours, Linus Walleij The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6: Linux 3.19-rc2 (2014-12-28 16:49:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v3.19-3 for you to fetch changes up to 96b932b84409a5c1037827b4432a2b53adc09a61: gpio: dln2: use bus_sync_unlock instead of scheduling work (2015-01-09 07:57:35 +0100) Some GPIO fixes for the v3.19 series: - Three patches fixing IRQ handling for the DLN2 - Null pointer handling for grgpio Axel Lin (2): gpio: dln2: Fix gpio output value in dln2_gpio_direction_output() gpio: grgpio: Avoid potential NULL pointer dereference Octavian Purdila (2): gpio: dln2: fix issue when an IRQ is unmasked then enabled gpio: dln2: use bus_sync_unlock instead of scheduling work drivers/gpio/gpio-dln2.c | 156 +++-- drivers/gpio/gpio-grgpio.c | 3 +- 2 files changed, 69 insertions(+), 90 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] x86,fpu: document the data structures a little
On 01/11/2015 01:46 PM, r...@redhat.com wrote:
> +/*
> + * The FPU state used depends on the capabilities of the hardware; the
> + * registers used for vector instructions on newer hardware are included
> + * in the FPU state.
> + */
> union thread_xstate {
Tiny nit, if you happen to revise this set at some point...
While you probably don't need/want to have an exhaustive list of
everything that gets saved in there, we should probably still mention
that it's a lot more than just vector instructions.
I'd say:
The FPU state used depends on the capabilities of the
hardware. This state increasingly contains things
not related to the FPU itself, like registers used for
vector instructions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] fpga manager: add sysfs interface document
On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote: > There are plenty of people today who treat the FPGA as an entirely > dynamic resource. It's not like flashing a controller, its near > immediate. But this is a completely different use case. Remember, there are *megabytes* of internal state in a FPGA, and it isn't really feasible to dump/restore that state. It is one thing to context switch a maths algorithm that is built to be stateless, it is quite another to context switch between, say an ethernet core with an operating Linux Net driver doing DMA and a maths algorithm. A DT overlay approach where the overlay has to be unloaded to 'free' the FPGA makes alot of sense to me for the stateful kernel driver environment, and open/close/etc makes alot of sense for the stateless switchable userspace environment - other than sharing configuration code, is there any overlap between these use cases > Its completely dynamic and it will get more so as we switch from the > painful world of VHDL and friends to high level parallel aware language > compilers for FPGAs and everyone will be knocking up quick FPGA hacks. Only for some users. In my world FPGAs are filled with bus interface logic, ethernet controllers, memory controllers, packet processing engines, etc. This is all incredibly stateful - both in the FPGA itself, and in the Linux side w/ drviers. It certainly will not ever work in the model you are talking about. Even if the digital state could somehow be frozen, dumped and restored, all the FPGA external interface logic has *ANALOG* state that cannot ever be dump/restored. It just isn't feasible for that class of application. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next] Driver: Vmxnet3: Reinitialize vmxnet3 backend on wakeup from hibernate
From: Shrikrishna Khare Date: Fri, 9 Jan 2015 15:19:14 -0800 > Failing to reinitialize on wakeup results in loss of network connectivity for > vmxnet3 interface. > > Signed-off-by: Srividya Murali > Signed-off-by: Shrikrishna Khare > Reviewed-by: Shreyas N Bhatewara 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 v5 2/2] gpio: Document GPIO hogging mechanism
On Tue, Jan 13, 2015 at 1:39 AM, Benoit Parrot wrote:
> Linus Walleij wrote on Mon [2015-Jan-12 11:20:14
> +0100]:
>> On Fri, Dec 19, 2014 at 9:07 PM, Benoit Parrot wrote:
>>
>> > Add GPIO hogging documentation to gpio.txt
>> >
>> > Signed-off-by: Benoit Parrot
>> > Reviewed-by: Alexandre Courbot
>>
>> This is starting to look good ...
>>
>> > + line_b {
>> > + gpio-hog;
>> > + gpios = <6 0>;
>> > + state = "output-low";
>>
>> I don't like the state string.
>>
>> Instead have boolean properties for all states.
>>
>> line_b {
>> gpio-hog;
>> gpios = <6 0>;
>> output-low;
>> line-name = "foo-bar-gpio";
>> }
>>
>> Then use of_property_read_bool() in the code to check which
>> state is to be selected intially. You can check that no mutually
>> exclusive state are selected, I don't like that an arbitrary string
>> select the state like that, if we do it that way an enumerator would
>> be better, I prefer bools.
>
> I am sorry but that is how it was originally in the first patch.
> Alexandre's review comment suggested this method in [1] and [2] (below).
>
> Alexandre, any comments?
>
> [1] http://marc.info/?l=linux-gpio&m=141456662426151&w=2
>
> [2] http://marc.info/?l=linux-gpio&m=141715982424744&w=2
When Linus and I are in conflict, follow Linus. Arnd's suggestion of
having enums defined in (IIUC) include/dt-bindings/gpio and using them
sounds good to me too and might make everyone happy (no possibility of
conflicting definitions + no strings). Linus, could you comment on it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16.y-ckt 030/168] drm/i915: Handle failure to kick out a conflicting fb driver
On Mon, Jan 12, 2015 at 6:43 PM, Luis Henriques
wrote:
> On Mon, Jan 12, 2015 at 06:20:22PM +0100, Daniel Vetter wrote:
>> On Sun, Jan 11, 2015 at 10:49 PM, Ben Hutchings wrote:
>> > On Mon, 2014-12-15 at 14:24 +, Luis Henriques wrote:
>> >> 3.16.7-ckt3 -stable review patch. If anyone has any objections, please
>> >> let me know.
>> >>
>> >> --
>> >>
>> >> From: Chris Wilson
>> >>
>> >> commit f96de58fc7e7d3d717c7c63975c3b896c906b5e3 upstream.
>> >>
>> >> Signed-off-by: Chris Wilson
>> >> Reviewed-by: Jani Nikula
>> >> Signed-off-by: Daniel Vetter
>> >> Signed-off-by: Luis Henriques
>> >
>> > Should this also be applied to any older stable branches?
>> >
>> > i915_kick_out_firmware_fb() was introduced in 3.6 and it has always been
>> > possible for the alloc_apertures() call to fail.
>> >
>> > remove_conflicting_framebuffers() has returned an error code since 3.14
>> > (but could silently fail before then!) so this should be applicable to
>> > the 3.14 stable branch too.
>>
>> tbh I don't know why this patch ended up in a stable kernel, at least
>> I didn't find anything where we (drm/i915 maintainers) marked it as
>> such. And there's no bugzilla references added either. Imo the patch
>> doesn't qualify for stable (it's not a real-world bug afaik).
>
> You're right, this patch was not tagged for stable.
>
> While applying 0485c9dc24ec ("drm/i915: Kick fbdev before vgacon") to
> the 3.16 kernel, I found that cherry-picking f96de58fc7e7 would make
> it apply cleanly and it didn't shock me to have it in a stable kernel.
> That's why I applied it for release 3.16.7-ckt3. I guess I should
> have added a note in the commit text justifying its presence.
Ah makes sense. Usually we try to tag cc: stable patches with their
depencies (and I looked for that but didn't find anything). As a rule
I only scan stable patches from Greg's kernels since there's way too
much going on (and this time around too much vacation and conferences
on top).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb/kaweth: use GFP_ATOMIC under spin_lock in usb_start_wait_urb()
From: Alexey Khoroshilov
Date: Sat, 10 Jan 2015 02:16:22 +0300
> Commit e4c7f259c5be ("USB: kaweth.c: use GFP_ATOMIC under spin_lock")
> makes sure that kaweth_internal_control_msg() allocates memory with
> GFP_ATOMIC,
> but kaweth_internal_control_msg() also calls usb_start_wait_urb()
> that still allocates memory with GFP_NOIO.
>
> The patch fixes usb_start_wait_urb() as well.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
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 05/11] usb: gadget: at91_udc: Remove non-DT handling code
On Wed, Dec 03, 2014 at 12:32:04PM +0100, Boris Brezillon wrote: > Since non-DT board support has been removed from the at91 architecture we > can safely remove non-DT handling code. > > Signed-off-by: Boris Brezillon doesn't apply cleanly: checking file drivers/usb/gadget/udc/Kconfig checking file drivers/usb/gadget/udc/at91_udc.c Hunk #1 succeeded at 1710 (offset 13 lines). Hunk #2 succeeded at 1722 (offset 13 lines). Hunk #3 succeeded at 1958 (offset 13 lines). Hunk #4 FAILED at 1960. 1 out of 4 hunks FAILED please rebase on testing/next which I just pushed. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 01/11] x86,fpu: document the data structures a little
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2015 04:18 PM, Borislav Petkov wrote:
> On Sun, Jan 11, 2015 at 04:46:23PM -0500, r...@redhat.com wrote:
>> +++ b/arch/x86/include/asm/processor.h @@ -400,6 +400,11 @@
>> struct xsave_struct { /* new processor state extensions will go
>> here */ } __attribute__ ((packed, aligned (64)));
>>
>> +/* + * The FPU state used depends on the capabilities of the
>> hardware; the + * registers used for vector instructions on newer
>> hardware are included + * in the FPU state. + */ union
>> thread_xstate { struct i387_fsave_struct fsave; struct
>> i387_fxsave_struct fxsave; @@ -408,8 +413,8 @@ union
>> thread_xstate { };
>>
>> struct fpu { - unsigned int last_cpu; -unsigned int has_fpu; +
>> unsigned int last_cpu; /* FPU state last loaded on this CPU */
>
> Isn't that the last CPU which had the FPU?
Indeed it is. Good catch. I will fix it.
>> +unsigned int has_fpu; /* FPU state in current use on CPU */
>
> I understand ->has_fpu as this thread has the FPU. See comment
> over user_has_fpu().
It does that currently, but the patch to __kernel_fpu_start() changes it
so it can point to a kernel FPU state as well.
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUtD7aAAoJEM553pKExN6D1TYH/34+5t9h+UxeVgqCxIAZuvAN
PY8r5PJMOdJb4hwbsbXfipA4oufRTXT3UrFYDUD2ASiJUv+P69FtXJgJRak0khJV
ZfOSXjnGA0WuTIWkTdXfl6H0RKxJd51Yc/EMgJL/kvnOucWBNjOPJnsWkQXrAan5
QJyM6WASFsUTjqAW3vzsKZwUmo/FnVh/FK/7pTVTqgZCI+j0WvitnGhD2J1A2Tvc
jlF2llmKQ/QxknW/HylurPAD4C68pw1AU08JcYtDmrRJGfweID/w5z+X3hd9xhjm
sEMjIKMTyrelj1K800uq0LXLw9gP7Vv7gNu6tMMWsle5wCTB0MrMH6/Qz3E/7Mk=
=5cE/
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: dwc2: problems with IN requests completion in linux-next
> From: Robert Baldyga [mailto:r.bald...@samsung.com] > Sent: Monday, December 22, 2014 6:13 AM > > I have recently noticed problem with DWC2 driver in latest linux-next. I > use it in gadget only mode at Samsung platform (Odroid U3) but I believe > the bug can be reproduced at another platforms. > > While running FFS example (tools/usb/ffs-aio-example/simple/) the > communication breaks after few seconds. It's because one of IN requests > enqueued in DWC2 driver do not complete. At USB analyzer I see that USB > device started to transmit data from this request, but it ended incomplete. > > I bisected kernel tree, and I got following patches are reason of break. > > 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg > structure > 11b usb: dwc2: Move gadget probe function into platform code > bcc0607 usb: dwc2: convert to use dev_pm_ops API > 510ffaa usb: dwc2: Initialize the USB core for peripheral mode > db8178c usb: dwc2: Update common interrupt handler to call gadget > interrupt handler > 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node > > Patch 941fcce breaks DWC2 driver at my platform and it starts to work > from 8d736d8 but it has described bug. > > I will try to localize reason of this issue. Hi Robert, I think the most likely suspect would be db8178c, since the rest appear to be init-time things. It seems to revert cleanly, can you try reverting just that patch and see if it helps? -- Paul
[PATCH] sched,numa: do not move past the balance point if unbalanced
There is a subtle interaction between the logic introduced in commit
e63da03639cc9e6e83b62e7ef8ffdbb92421416a, the way the load balancer
counts the load on each NUMA node, and the way NUMA hinting faults are
done.
Specifically, the load balancer only counts currently running tasks
in the load, while NUMA hinting faults may cause tasks to stop, if
the page is locked by another task.
This could cause all of the threads of a large single instance workload,
like SPECjbb2005, to migrate to the same NUMA node. This was possible
because occasionally they all fault on the same few pages, and only one
of the threads remains runnable. That thread can move to the process's
preferred NUMA node without making the imbalance worse, because nothing
else is running at that time.
The fix is to check the direction of the net moving of load, and to
refuse a NUMA move if it would cause the system to move past the point
of balance. In an unbalanced state, only moves that bring us closer
to the balance point are allowed.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 40667cb..5b07eef 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1197,9 +1197,11 @@ static void task_numa_assign(struct task_numa_env *env,
static bool load_too_imbalanced(long src_load, long dst_load,
struct task_numa_env *env)
{
- long imb, old_imb;
- long orig_src_load, orig_dst_load;
long src_capacity, dst_capacity;
+ long orig_src_load;
+ long load_a, load_b;
+ long moved_load;
+ long imb;
/*
* The load is corrected for the CPU capacity available on each node.
@@ -1212,30 +1214,38 @@ static bool load_too_imbalanced(long src_load, long
dst_load,
dst_capacity = env->dst_stats.compute_capacity;
/* We care about the slope of the imbalance, not the direction. */
- if (dst_load < src_load)
- swap(dst_load, src_load);
+ load_a = dst_load;
+ load_b = src_load;
+ if (load_a < load_b)
+ swap(load_a, load_b);
/* Is the difference below the threshold? */
- imb = dst_load * src_capacity * 100 -
- src_load * dst_capacity * env->imbalance_pct;
+ imb = load_a * src_capacity * 100 -
+ load_b * dst_capacity * env->imbalance_pct;
if (imb <= 0)
return false;
/*
* The imbalance is above the allowed threshold.
-* Compare it with the old imbalance.
+* Allow the move if it brings us closer to a balanced situation,
+* without moving things past the point of balance.
*/
orig_src_load = env->src_stats.load;
- orig_dst_load = env->dst_stats.load;
- if (orig_dst_load < orig_src_load)
- swap(orig_dst_load, orig_src_load);
-
- old_imb = orig_dst_load * src_capacity * 100 -
- orig_src_load * dst_capacity * env->imbalance_pct;
+ /*
+* In a task swap, there will be one load moving from src to dst,
+* and another moving back. This is the net sum of both moves.
+* Allow the move if it brings the system closer to a balanced
+* situation, without crossing over the balance point.
+*/
+ moved_load = orig_src_load - src_load;
- /* Would this change make things worse? */
- return (imb > old_imb);
+ if (moved_load > 0)
+ /* Moving src -> dst. Did we overshoot balance? */
+ return src_load < dst_load;
+ else
+ /* Moving dst -> src. Did we overshoot balance? */
+ return dst_load < src_load;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] ARM: at91: sama5d4: remove useless call to at91_init_sram
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/sama5d4.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-at91/sama5d4.c b/arch/arm/mach-at91/sama5d4.c
index 7638509639f4..fa127fb79221 100644
--- a/arch/arm/mach-at91/sama5d4.c
+++ b/arch/arm/mach-at91/sama5d4.c
@@ -56,7 +56,6 @@ static struct map_desc at91_io_desc[] __initdata = {
static void __init sama5d4_map_io(void)
{
iotable_init(at91_io_desc, ARRAY_SIZE(at91_io_desc));
- at91_init_sram(0, SAMA5D4_NS_SRAM_BASE, SAMA5D4_NS_SRAM_SIZE);
}
AT91_SOC_START(sama5d4)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ARM: at91: remove unused at91_init_sram
SRAM initialization is now done through the mmio-sram driver and
at91_init_sram() is not called anymore, remove it.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/generic.h | 2 --
arch/arm/mach-at91/setup.c | 20
2 files changed, 22 deletions(-)
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 54f3837a0a4d..18d5547f11d5 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -17,8 +17,6 @@
/* Map io */
extern void __init at91_map_io(void);
extern void __init at91_alt_map_io(void);
-extern void __init at91_init_sram(int bank, unsigned long base,
- unsigned int length);
/* Processors */
extern void __init at91_dt_initialize(void);
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index e3c21b458bb8..4c184285d38f 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -34,26 +34,6 @@ EXPORT_SYMBOL(at91_soc_initdata);
void __iomem *at91_ramc_base[2];
EXPORT_SYMBOL_GPL(at91_ramc_base);
-static struct map_desc sram_desc[2] __initdata;
-
-void __init at91_init_sram(int bank, unsigned long base, unsigned int length)
-{
- struct map_desc *desc = &sram_desc[bank];
-
- desc->virtual = (unsigned long)AT91_IO_VIRT_BASE - length;
- if (bank > 0)
- desc->virtual -= sram_desc[bank - 1].length;
-
- desc->pfn = __phys_to_pfn(base);
- desc->length = length;
- desc->type = MT_MEMORY_RWX_NONCACHED;
-
- pr_info("sram at 0x%lx of 0x%x mapped at 0x%lx\n",
- base, length, desc->virtual);
-
- iotable_init(desc, 1);
-}
-
static struct map_desc at91_io_desc __initdata __maybe_unused = {
.virtual= (unsigned long)AT91_VA_BASE_SYS,
.pfn= __phys_to_pfn(AT91_BASE_SYS),
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ARM: at91: remove useless map_io
Now that the SRAM is initialized by the mmio-sram driver, .map_io is useless.
remove it.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/at91rm9200.c | 6 --
arch/arm/mach-at91/at91sam9260.c | 27 ---
arch/arm/mach-at91/at91sam9261.c | 9 -
arch/arm/mach-at91/at91sam9263.c | 7 ---
arch/arm/mach-at91/at91sam9g45.c | 7 ---
arch/arm/mach-at91/at91sam9n12.c | 6 --
arch/arm/mach-at91/at91sam9rl.c | 18 --
arch/arm/mach-at91/at91sam9x5.c | 6 --
arch/arm/mach-at91/sama5d3.c | 6 --
9 files changed, 92 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index b52916947535..fc7c26138037 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -42,11 +42,6 @@ static void at91rm9200_restart(enum reboot_mode reboot_mode,
const char *cmd)
/*
* AT91RM9200 processor initialization
* */
-static void __init at91rm9200_map_io(void)
-{
- /* Map peripherals */
- at91_init_sram(0, AT91RM9200_SRAM_BASE, AT91RM9200_SRAM_SIZE);
-}
static void __init at91rm9200_initialize(void)
{
@@ -56,6 +51,5 @@ static void __init at91rm9200_initialize(void)
AT91_SOC_START(at91rm9200)
- .map_io = at91rm9200_map_io,
.init = at91rm9200_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 34e2abe82ae4..ab9841c8b0d5 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -22,38 +22,11 @@
* AT91SAM9260 processor initialization
* */
-static void __init at91sam9xe_map_io(void)
-{
- unsigned long sram_size;
-
- switch (at91_soc_initdata.cidr & AT91_CIDR_SRAMSIZ) {
- case AT91_CIDR_SRAMSIZ_32K:
- sram_size = 2 * SZ_16K;
- break;
- case AT91_CIDR_SRAMSIZ_16K:
- default:
- sram_size = SZ_16K;
- }
-
- at91_init_sram(0, AT91SAM9XE_SRAM_BASE, sram_size);
-}
-
-static void __init at91sam9260_map_io(void)
-{
- if (cpu_is_at91sam9xe())
- at91sam9xe_map_io();
- else if (cpu_is_at91sam9g20())
- at91_init_sram(0, AT91SAM9G20_SRAM_BASE, AT91SAM9G20_SRAM_SIZE);
- else
- at91_init_sram(0, AT91SAM9260_SRAM_BASE, AT91SAM9260_SRAM_SIZE);
-}
-
static void __init at91sam9260_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9260)
- .map_io = at91sam9260_map_io,
.init = at91sam9260_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 47878b849975..2029096b93fa 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -21,20 +21,11 @@
* AT91SAM9261 processor initialization
* */
-static void __init at91sam9261_map_io(void)
-{
- if (cpu_is_at91sam9g10())
- at91_init_sram(0, AT91SAM9G10_SRAM_BASE, AT91SAM9G10_SRAM_SIZE);
- else
- at91_init_sram(0, AT91SAM9261_SRAM_BASE, AT91SAM9261_SRAM_SIZE);
-}
-
static void __init at91sam9261_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9261)
- .map_io = at91sam9261_map_io,
.init = at91sam9261_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index aabcb66145d0..1fe672a05513 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -20,18 +20,11 @@
* AT91SAM9263 processor initialization
* */
-static void __init at91sam9263_map_io(void)
-{
- at91_init_sram(0, AT91SAM9263_SRAM0_BASE, AT91SAM9263_SRAM0_SIZE);
- at91_init_sram(1, AT91SAM9263_SRAM1_BASE, AT91SAM9263_SRAM1_SIZE);
-}
-
static void __init at91sam9263_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9263)
- .map_io = at91sam9263_map_io,
.init = at91sam9263_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index 000166777a8d..d0493df40a13 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -19,18 +19,11 @@
/*
* AT91SAM9G45 processor initialization
* */
-
-static void __init at91sam9g45_map_io(void)
-{
- at91_init_sram(0, AT91SAM9G45_SRAM_BASE, AT91SAM9G45_SRAM_SIZE);
-}
-
static void __init at91sam9g45_initialize(void)
{
[PATCH 6/6] ARM: at91: move at91rm9200_idle() to clk/at91/pmc.c
Move at91rm9200_idle() along with at91sam9_idle() in clk/at91/pmc.c.
Signed-off-by: Alexandre Belloni
---
Cc: Mike Turquette
Mike, Boris,
I guess that one can go through the at91 tree unless you have any objections.
arch/arm/mach-at91/at91rm9200.c | 9 -
arch/arm/mach-at91/generic.h| 1 +
drivers/clk/at91/pmc.c | 9 +
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index fc7c26138037..3be1963f5c56 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -21,14 +21,6 @@
#include "soc.h"
#include "generic.h"
-static void at91rm9200_idle(void)
-{
- /*
-* Disable the processor clock. The processor will be automatically
-* re-enabled by an interrupt or by a reset.
-*/
- at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
-}
static void at91rm9200_restart(enum reboot_mode reboot_mode, const char *cmd)
{
@@ -49,7 +41,6 @@ static void __init at91rm9200_initialize(void)
arm_pm_restart = at91rm9200_restart;
}
-
AT91_SOC_START(at91rm9200)
.init = at91rm9200_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 18d5547f11d5..c4aa21fb765f 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -25,6 +25,7 @@ extern void __init at91_dt_initialize(void);
extern void at91rm9200_timer_init(void);
/* idle */
+extern void at91rm9200_idle(void);
extern void at91sam9_idle(void);
/* Matrix */
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 386999b4f8eb..f07c8152e5cc 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -27,6 +27,15 @@
void __iomem *at91_pmc_base;
EXPORT_SYMBOL_GPL(at91_pmc_base);
+void at91rm9200_idle(void)
+{
+ /*
+* Disable the processor clock. The processor will be automatically
+* re-enabled by an interrupt or by a reset.
+*/
+ at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+}
+
void at91sam9_idle(void)
{
at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lockd: xdr: Remove unused function
On Sat, Jan 10, 2015 at 06:02:42PM +0100, Rickard Strandqvist wrote:
> Remove the function nlm_encode_fh() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
Huh. OK, thanks--applying.
--b.
>
> Signed-off-by: Rickard Strandqvist
> ---
> fs/lockd/xdr.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/fs/lockd/xdr.c b/fs/lockd/xdr.c
> index 9340e7e..5b651da 100644
> --- a/fs/lockd/xdr.c
> +++ b/fs/lockd/xdr.c
> @@ -95,14 +95,6 @@ nlm_decode_fh(__be32 *p, struct nfs_fh *f)
> return p + XDR_QUADLEN(NFS2_FHSIZE);
> }
>
> -static inline __be32 *
> -nlm_encode_fh(__be32 *p, struct nfs_fh *f)
> -{
> - *p++ = htonl(NFS2_FHSIZE);
> - memcpy(p, f->data, NFS2_FHSIZE);
> - return p + XDR_QUADLEN(NFS2_FHSIZE);
> -}
> -
> /*
> * Encode and decode owner handle
> */
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ARM: at91: pm: use the mmio-sram pool to access SRAM
Now that the SRAM is part of a genpool, use it to allocate memory to use for the
slowclock implementation.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/Kconfig | 1 +
arch/arm/mach-at91/pm.c| 46 +-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index cec0fb5d621a..b7dcef50db23 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -178,6 +178,7 @@ comment "AT91 Feature Selections"
config AT91_SLOW_CLOCK
bool "Suspend-to-RAM disables main oscillator"
+ select SRAM
depends on SUSPEND
help
Select this if you want Suspend-to-RAM to save the most power
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 79aa793d1f00..515791edcc60 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -14,10 +14,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -222,10 +224,52 @@ void at91_pm_set_standby(void (*at91_standby)(void))
}
}
+#ifdef CONFIG_AT91_SLOW_CLOCK
+static void __init at91_pm_sram_init(void)
+{
+ struct gen_pool *sram_pool;
+ phys_addr_t sram_pbase;
+ unsigned long sram_base;
+ struct device_node *node;
+ struct platform_device *pdev;
+
+ node = of_find_compatible_node(NULL, NULL, "mmio-sram");
+ if (!node) {
+ pr_warn("%s: failed to find sram node!\n", __func__);
+ return;
+ }
+
+ pdev = of_find_device_by_node(node);
+ if (!pdev) {
+ pr_warn("%s: failed to find sram device!\n", __func__);
+ goto put_node;
+ }
+
+ sram_pool = dev_get_gen_pool(&pdev->dev);
+ if (!sram_pool) {
+ pr_warn("%s: sram pool unavailable!\n", __func__);
+ goto put_node;
+ }
+
+ sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
+ if (!sram_base) {
+ pr_warn("%s: unable to alloc ocram!\n", __func__);
+ goto put_node;
+ }
+
+ sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
+ slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+
+put_node:
+ of_node_put(node);
+}
+#endif
+
+
static int __init at91_pm_init(void)
{
#ifdef CONFIG_AT91_SLOW_CLOCK
- slow_clock = (void *) (AT91_IO_VIRT_BASE - at91_slow_clock_sz);
+ at91_pm_sram_init();
#endif
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ARM: at91: pm: rework cpu detection
Store SoC differences in a struct to remove cpu_is_* usage.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 54 ++---
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9b15169a1c62..79aa793d1f00 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,11 @@
#include "generic.h"
#include "pm.h"
+static struct {
+ unsigned long uhp_udp_mask;
+ int memctrl;
+} at91_pm_data;
+
static void (*at91_pm_standby)(void);
static int at91_pm_valid_state(suspend_state_t state)
@@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
scsr = at91_pmc_read(AT91_PMC_SCSR);
/* USB must not be using PLLB */
- if (cpu_is_at91rm9200()) {
- if ((scsr & (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
- pr_err("AT91: PM - Suspend-to-RAM with USB still
active\n");
- return 0;
- }
- } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() ||
cpu_is_at91sam9263()
- || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
- if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
- pr_err("AT91: PM - Suspend-to-RAM with USB still
active\n");
- return 0;
- }
+ if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
+ pr_err("AT91: PM - Suspend-to-RAM with USB still active\n");
+ return 0;
}
/* PCK0..PCK3 must be disabled, or configured to use clk32k */
@@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
* turning off the main oscillator; reverse on wakeup.
*/
if (slow_clock) {
- int memctrl = AT91_MEMCTRL_SDRAMC;
-
- if (cpu_is_at91rm9200())
- memctrl = AT91_MEMCTRL_MC;
- else if (cpu_is_at91sam9g45())
- memctrl = AT91_MEMCTRL_DDRSDR;
#ifdef CONFIG_AT91_SLOW_CLOCK
/* copy slow_clock handler to SRAM, and call it
*/
memcpy(slow_clock, at91_slow_clock,
at91_slow_clock_sz);
#endif
slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1], memctrl);
+ at91_ramc_base[1],
+ at91_pm_data.memctrl);
break;
} else {
pr_info("AT91: PM - no slow clock mode enabled
...\n");
@@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
- /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
- if (cpu_is_at91rm9200())
+ at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
+
+ if (of_machine_is_compatible("atmel,at91rm9200")) {
+ /*
+* AT91RM9200 SDRAM low-power mode cannot be used with
+* self-refresh.
+*/
at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
-
+
+ at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
+ AT91RM9200_PMC_UDP;
+ at91_pm_data.memctrl = AT91_MEMCTRL_MC;
+ } else if (of_machine_is_compatible("atmel,at91sam9260") ||
+ of_machine_is_compatible("atmel,at91sam9g20") ||
+ of_machine_is_compatible("atmel,at91sam9261") ||
+ of_machine_is_compatible("atmel,at91sam9g10") ||
+ of_machine_is_compatible("atmel,at91sam9263")) {
+ at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
+ AT91SAM926x_PMC_UDP;
+ } else if (of_machine_is_compatible("atmel,at91sam9g45")) {
+ at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
+ }
+
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(&at91_cpuidle_device);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] AT91 cleanup for 3.20 #2
This patch sets is based on AT91 cleanup for 3.20 #1 and depends on AT91 DT for 3.20 #1 because it uses the added SRAM nodes. The first two patches rework the pm code to get rid of cpu_is_xxx (they will be dropped soon) and use the SRAM from the genpool instead of relying on the remap done by at91_init_sram. Then the following patches get rid of at91_init_sram, taking .map_io for almost all SoCs but the sama5d4 (more cleanups coming soon for that part). The final patch moves at91rm9200_idle to clk/at91/pmc.c and allows to almost empty arch/arm/mach-at91/at91rm9200.c (It is actually empty once "Atmel System Timer cleanups" is applied). Alexandre Belloni (6): ARM: at91: pm: rework cpu detection ARM: at91: pm: use the mmio-sram pool to access SRAM ARM: at91: remove useless map_io ARM: at91: sama5d4: remove useless call to at91_init_sram ARM: at91: remove unused at91_init_sram ARM: at91: move at91rm9200_idle() to clk/at91/pmc.c arch/arm/mach-at91/Kconfig | 1 + arch/arm/mach-at91/at91rm9200.c | 15 -- arch/arm/mach-at91/at91sam9260.c | 27 --- arch/arm/mach-at91/at91sam9261.c | 9 arch/arm/mach-at91/at91sam9263.c | 7 --- arch/arm/mach-at91/at91sam9g45.c | 7 --- arch/arm/mach-at91/at91sam9n12.c | 6 --- arch/arm/mach-at91/at91sam9rl.c | 18 --- arch/arm/mach-at91/at91sam9x5.c | 6 --- arch/arm/mach-at91/generic.h | 3 +- arch/arm/mach-at91/pm.c | 100 ++- arch/arm/mach-at91/sama5d3.c | 6 --- arch/arm/mach-at91/sama5d4.c | 1 - arch/arm/mach-at91/setup.c | 20 drivers/clk/at91/pmc.c | 9 15 files changed, 89 insertions(+), 146 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] x86,fpu: document the data structures a little
On Sun, Jan 11, 2015 at 04:46:23PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> Add some documentation to data structures used for FPU context
> switching.
>
> Signed-off-by: Rik van Riel
> ---
> arch/x86/include/asm/processor.h | 9 +++--
> arch/x86/kernel/cpu/common.c | 1 +
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h
> index a092a0c..17bd8a0 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -400,6 +400,11 @@ struct xsave_struct {
> /* new processor state extensions will go here */
> } __attribute__ ((packed, aligned (64)));
>
> +/*
> + * The FPU state used depends on the capabilities of the hardware; the
> + * registers used for vector instructions on newer hardware are included
> + * in the FPU state.
> + */
> union thread_xstate {
> struct i387_fsave_structfsave;
> struct i387_fxsave_struct fxsave;
> @@ -408,8 +413,8 @@ union thread_xstate {
> };
>
> struct fpu {
> - unsigned int last_cpu;
> - unsigned int has_fpu;
> + unsigned int last_cpu; /* FPU state last loaded on this CPU */
Isn't that the last CPU which had the FPU?
> + unsigned int has_fpu; /* FPU state in current use on CPU */
I understand ->has_fpu as this thread has the FPU. See comment over
user_has_fpu().
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.19.0-rc4+ fails to compile, missing 'usr/missing-syscalls'
On 01/12/2015 12:55 PM, Guenter Roeck wrote: > On Mon, Jan 12, 2015 at 12:08:22PM -0800, Ben Greear wrote: >> >> Any idea what is wrong? >> >> -rc3 compiled ok, then I rebased just now, and get this: >> > My auto-builders are all happy, with no build or qemu failures. > Did you try "make mrproper" prior to rebuilding ? yes, and blew away .ccache too. But, I saw something weird like git suddenly got confused a bit earlier, so I will re-clone and try again in case the 'reset --hard HEAD' didn't clean up as much as I had hoped. Thanks, Ben > > Guenter > -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v2 0/2 RESEND] r8152: adjust r8152_submit_rx
From: Hayes Wang Date: Fri, 9 Jan 2015 10:26:34 +0800 > v2: > Replace the patch #1 with "call rtl_start_rx after netif_carrier_on". > > For patch #2, replace checking tp->speed with netif_carrier_ok. > > v1: > Avoid r8152_submit_rx() from submitting rx during unexpected > moment. This could reduce the time of stopping rx. > > For patch #1, the tp->speed should be updated early. Then, > the patch #2 could use it to check the current linking status. Series 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 v8 2/4] fpga manager: add sysfs interface document
> Then configure udev to load right firmware for you, or ln -s
> image-i-want-now socfpga-fpga-image to select the one to read...?
Your conceptual model is wrong. FPGA firmware is dynamic. There are
already people who lazy reload FPGA firmware on taskswitches. This
proposed fpga manager is broken but it's broken in exactly the reverse
direction to the one you are arguing for.
There are plenty of people today who treat the FPGA as an entirely
dynamic resource. It's not like flashing a controller, its near
immediate.
The udev/sysfs model is broken because
- it's too slow for dynamic switching
- it doesn't address permissions
- it doesn't address namespaces
- it doesn't address dynamic management of resources (open/use/close)
with dyanmic resource recovery on the final close as is the Unix way.
not because FPGA's are some static boot time resource.
If you look at all the academic work on this you see the same kind
of dynamic usage, even more so.
The library API you actually need is much closer to
/* Get my firmware */
fw = fpga_openfirmware("foo.fpga");
/* Get me a suitable FPGA for it */
fd = fpga_alloc(&w);
/* Load it */
fgpa_load(fd, "foo.fpga");
do_shit(fd);
fpga_close(fd);
You want to be able to have things like your game just load up an audio
physics engine, lob it into a random fpga, play it, drop it. Likewise
lots of other FPGA apps - video processing for example, crypto, format
convertors, gesture analysers and so on. Think a world where there are
gimp filters that want to just grab an fpga for 3 seconds.
Its completely dynamic and it will get more so as we switch from the
painful world of VHDL and friends to high level parallel aware language
compilers for FPGAs and everyone will be knocking up quick FPGA hacks.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] pwm: Imagination Technologies PWM DAC driver
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); What if you've not been given a resource ? Otherwise looks fine to me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 12:26:38PM -0800, Andy Lutomirski wrote: > Is the usage you have in mind something like: > > pushq_cfi %r11 /* saves r11 */ > pushq_cfi $0 /* saves nothing */ > pushq_cfi %r11, savereg=rip /* saves rip */ > > I think I prefer the somewhat less magical: > > pushq_reg_cfi %r11 /* saves r11 */ > pushq_reg_cfi %r11, savereg=rip /* saves rip */ > pushq_nounwind_cfi $0 But that's two macro names and the above one is one single which does it all. And it's not like we're not looking at the definition of macros when staring at the code anyway... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] Overhaul the audit filename handling
On Thursday, January 08, 2015 11:50:23 AM Paul Moore wrote: > There have been some patches added to v3.19-rcX to fix various > problems in the way audit handles filenames but they have been hacks > on top of hacks, not really something we want long term. This > patchset reworks the way audit handles filenames, removing a lot of > nasty hacks added recently, and fixing a few bugs that still remain. > > Most significant to folks outside of audit, patch 5/5 does away with > the nasty getname()/putname() kludge in favor of a less ugly reference > count approach. > > Comments and feedback are welcome. If nothing ugly pops up on review > I'll see if Linus is interested in taking this for the next v3.19-rcX > release, otherwise I'll toss it into linux-next for v3.20. > > -Paul > > --- > > Paul Moore (5): > fs: rework getname_kernel to handle up to PATH_MAX sized filenames > fs: create proper filename objects using getname_kernel() > audit: enable filename recording via getname_kernel() > audit: fix filename matching in __audit_inode() and > __audit_inode_child() > audit: replace getname()/putname() hacks with reference counters > > > fs/exec.c | 11 +++ > fs/namei.c| 98 ++--- > fs/open.c | 11 +++ > include/linux/audit.h |3 - > include/linux/fs.h|9 +-- > kernel/audit.h| 17 + > kernel/auditsc.c | 167 - > 7 files changed, 115 insertions(+), 201 deletions(-) Al/fs dev: any chance you guys can take a quick look at the fs relevant portions of this patchset and give it a ACK/NACK? I'll carry the patchset in the audit tree, but I'd like to see a thumbs up from someone in fs land before I merge these patches. Thanks, -Paul -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv2 0/2] mm: infrastructure for correctly handling foreign pages on Xen
On Mon, 12 Jan 2015 15:53:11 + David Vrabel wrote: > These two patches are the common parts of a larger Xen series[1] > fixing several long-standing bugs the handling of foreign[2] pages in > Xen guests. > > The first patch is required to fix get_user_pages[_fast]() with > userspace space mappings of such foreign pages. Basically, pte_page() > doesn't work so an alternate mechanism is needed to get the page from > a VMA and address. By requiring mappings needing this method are > 'special' this should not have an impact on the common use cases. > > The second patch isn't essential but helps with readability of the > resulting user of the page flag. > > For further background reading see: > > http://xenbits.xen.org/people/dvrabel/grant-improvements-C.pdf > Looks OK to me. I can merge them if you like, but it's probably more convenient for you to include them in the Xen tree. It would be nice if PG_foreign (and PG_everythingelse) was properly documented at the definition site. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.19.0-rc4+ fails to compile, missing 'usr/missing-syscalls'
On Mon, Jan 12, 2015 at 12:08:22PM -0800, Ben Greear wrote: > > Any idea what is wrong? > > -rc3 compiled ok, then I rebased just now, and get this: > My auto-builders are all happy, with no build or qemu failures. Did you try "make mrproper" prior to rebuilding ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Tuesday 13 January 2015 02:17:00 Suman Tripathi wrote:
> Hi,
>
> On Tuesday 13 January 2015 02:00:45 Suman Tripathi wrote:
> > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote:
> > > Can you dump the ata_id parameters(LPM section) from the drive and we
> > > can check the related LPM parameters of the drive ?
> >
> > Hi,
> >
> > I'm sorry, but I'm not really familiar with ata, could you be a bit
> > more specific about what you'd like to see?
> > ok no issues. First can show the log from the point the drive got
> > enumerated ? Like for eg :
> > ata2.00: ATA-8: WDC WD5000AAKX-08U6AA0, 19.01H19, max UDMA/100
> >
> > ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
> >
> > ata2.00: configured for UDMA/100
> >
> > I would like to the ATA version the drive is complaint. In the above case
> > it is ATA-8
>
> [0.698842] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [0.701419] ata3.00: ATA-8: LITEONIT LMT-256M6M mSATA 256GB, DM8110F,
> max UDMA/133
> [0.701421] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth
> 31/32), AA
> [0.701982] ata3.00: configured for UDMA/133
>
> You can see the entire log here:
> http://www.spinics.net/lists/linux-ide/msg50069.html
>
> Can you try the below fix ? In the libata-core.c
Tried, unfortunately it does not solve the problem. I no longer get
"ahci :00:1f.2: port does not support device sleep"
[ 60.170199] ata3.00: exception Emask 0x10 SAct 0x2000 SErr 0x5 action
0xe frozen
[ 60.170209] ata3.00: irq_stat 0x0040, PHY RDY changed
[ 60.170215] ata3: SError: { PHYRdyChg CommWake }
[ 60.170221] ata3.00: failed command: WRITE FPDMA QUEUED
[ 60.170231] ata3.00: cmd 61/01:68:01:08:00/00:00:00:00:00/40 tag 13 ncq 512
out
res 40/00:6c:01:08:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
[ 60.170236] ata3.00: status: { DRDY }
[ 60.170244] ata3: hard resetting link
[ 60.894728] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 60.897672] ata3.00: configured for UDMA/133
[ 60.910690] ata3: EH complete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] TaskTracker : Simplified thread information tracker.
On Monday, January 12, 2015 10:14:34 AM Steve Grubb wrote: > On Monday, January 12, 2015 03:13:12 PM Tetsuo Handa wrote: > > This record contains multiple user-influenced comm names. If I use > > audit_log_untrustedstring(), I would need to split this record into > > multiple records like history[0]='...' history[1]='...' history[2]='...' > > in order to avoid matching delimiters (i.e. ';', '=' and '>') used in > > this record. > > That sounds like a good change to me. Audit records are always name=value > with a space between fields. We need this to always stay like this because > the tooling expects that format. There is nowhere in the audit logs we use > =>. As a FYI, I'm putting a hold on any new audit messages for the time being so we can evaluate the current kernel audit API to determine the possibility of transitioning to a less ugly API. I'll leave the door open for messages needed to fix bugs, but that's it. If we do end up providing a new API and record format, I want to limit the number of message types in the existing API. My apologies, but this is long overdue and the longer we wait the more difficult it will become. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] time: Cap clocksource reads to the clocksource max_cycles value
On Mon, Jan 12, 2015 at 09:30:07PM +0100, Richard Cochran wrote: > On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote: > > You say the tick should be scheduled before the clocksource wraps - > > but we have logic to do that. > > Well that is a shame. Arg, I mean, not a shame that we have logic for that, but rather that the logic is not reliable enough! Sorry Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] CHROMIUM: clk: rockchip: add clock IDs for the PVTM clocks
Am Donnerstag, 18. Dezember 2014, 16:13:45 schrieb Dmitry Torokhov: > From: Huang Lin > > Process-Voltage-Temperature Monitor has two clocks, PVTM_CORE and > PVTM_GPU. > > Signed-off-by: Huang Lin > Signed-off-by: Dmitry Torokhov applied both patches to my tree The clock-id addition is living in a separate branch, so if you have dts updates using this I can share the clock-id branch easily. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: rockchip: add clock ID for usbphy480m_src
Am Donnerstag, 13. November 2014, 15:22:36 schrieb Kever Yang: > There are 3 different parent clock from different usbphy, > all of them are fixed 480MHz, it is not able to auto select > by clock core to the 2nd and the 3rd parent. > For different use case for different board, we may need to > select different usbphy clock out as parent manually. > > Add the clock ID for it so that we can use in dts. > > Signed-off-by: Kever Yang applied both patches to my tree The clock-id addition is living in a separate branch, so if you have dts updates using this I can share the clock-id branch easily. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10][RFC] Increased clocksource validation and cleanups
On Mon, Jan 12, 2015 at 10:22:11AM -0800, John Stultz wrote: > Yea, I've not looked at the actual performance impact yet, but things > like the read-time capping (which is in the hot path) could be put > under a debug config. Thanks for the suggestion! Having a broken clock is like having a broken memory card. Both will make your system behave very strangely. Once you start having really strange issues, you run a dedicated memory test. That is why I would expect to have clock validation as compile time option. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] kstrdup optimization
On Mon, Jan 12, 2015 at 10:18 AM, Andrzej Hajda wrote:
> kstrdup if often used to duplicate strings where neither source neither
> destination will be ever modified. In such case we can just reuse the source
> instead of duplicating it. The problem is that we must be sure that
> the source is non-modifiable and its life-time is long enough.
>
> I suspect the good candidates for such strings are strings located in kernel
> .rodata section, they cannot be modifed because the section is read-only and
> their life-time is equal to kernel life-time.
>
> This small patchset proposes alternative version of kstrdup - kstrdup_const,
> which returns source string if it is located in .rodata otherwise it fallbacks
> to kstrdup.
It also introduces kfree_const(const void *x).
As kfree_const() has the exact same signature as kfree(), the risk of
accidentally passing pointers returned from kstrdup_const() to kfree() seems
high, which may lead to memory corruption if the pointer doesn't point to
allocated memory.
> To verify if the source is in .rodata function checks if the address is
> between
> sentinels __start_rodata, __end_rodata. I guess it should work with all
> architectures.
>
> The main patch is accompanied by four patches constifying kstrdup for cases
> where situtation described above happens frequently.
>
> As I have tested the patchset on mobile platform (exynos4210-trats) it saves
> 3272 string allocations. Since minimal allocation is 32 or 64 bytes depending
> on Kconfig options the patchset saves respectively about 100KB or 200KB of
> memory.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] update ip-sysctl.txt documentation (v2)
From: Ani Sinha Date: Wed, 7 Jan 2015 15:45:56 -0800 > Update documentation to reflect the fact that > /proc/sys/net/ipv4/route/max_size is no longer used for ipv4. > > Signed-off-by: Ani Sinha Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/10] time: Cap clocksource reads to the clocksource max_cycles value
On Tue, Jan 13, 2015 at 08:02:53AM +1300, Linus Torvalds wrote: > Indeed. It's making things more robust in the face of _known_ issues. > Even with a perfectly designed timer (which we so far have never > seen), interrupts get delayed etc, so trying to stretch it to the > limit of the timer is simply not a good idea. Quite the reverse. So is this patch supposed to fix the case when a tick just missed the range of the clock? Or is this to deal with really broken sources? > More importantly, if the timer is actually any good, the safety margin > won't actually matter, since the timer cycle is so long that 50% of > essentially infinite is still essentially infinite. > > And if the timer isn't very good, then some slop for safety is just > being robust. Here "isn't very good" means that the clock rolls over too frequently. Well, if you cannot be sure to sample the clock in time, then you shouldn't use that clock source at all. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.16.y-ckt stable] Linux 3.16.7-ckt4 stable review
On Mon, 12 Jan 2015, Luis Henriques wrote: This is the start of the review cycle for the Linux 3.16.7-ckt4 stable kernel. This version contains 216 new patches, summarized below. The new patches are posted as replies to this message and also available in this git branch: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.16.y-review;a=shortlog git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y-review The review period for version 3.16.7-ckt4 will be open for the next three days. To report a problem, please reply to the relevant follow-up patch message. For more information about the Linux 3.16.y-ckt extended stable kernel version, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable . Something is wrong with drm/i915 (I guess). I had a terrible memleak on Xorg when using mplayer using more and more RAM, and then the system is swapping itself to death. I'm using a openSUSE 13.1 (x86_64) on a Baytrail J1900 (this is Intel HD Gen7). Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] can: kvaser_usb: Update error counters before exiting on OOM
On Mon, Jan 12, 2015 at 12:09:32PM +0100, Marc Kleine-Budde wrote:
> On 01/11/2015 09:15 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish
> >
> > Let the error counters be more accurate in case of Out of
> > Memory conditions.
>
> Please have a look at kvaser_usb_rx_error(), the whole state handling is
> omitted in case of OOM.
>
I see. Regarding kvaser_usb_rx_error(), would something like
below patch be acceptable?
Kindly note that separating recording interface state from
error frame packet building leads to duplication of a good
number of if-conditions. Meanwhile, it truly saves _all_
of the possible state before any ENOMEM -- the correct thing
to do.
Another solution was to allocate the can frame on the stack,
and thus avoiding any code duplication. But this only leads
to calls of "kvaser_usb_simple_msg_async", which can fail
with -ENOMEM by itself, returning to the very same problem
again.
If the patch is acceptable, I'll rebase my USBCAN-II driver
above it and re-submit the series (minus the merged patch).
Thanks,
-->
[ Patch is build-tested, but not _fully_ run-time tested.
It's based on linux-can/testing commit d642b49f6d84b94bd
"can: kvaser_usb: Don't dereference skb after a netif_rx" ]
Subject: [PATCH] can: kvaser_usb: Update net interface state
before exiting on OOM
From: Ahmed S. Darwish
Let the network interface can bus state and error counters be
more accurate in case of Out of Memory conditions.
Suggested-by: Marc Kleine-Budde
Signed-off-by: Ahmed S. Darwish
---
drivers/net/can/usb/kvaser_usb.c | 182 +++
1 file changed, 106 insertions(+), 76 deletions(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index c32cd61..2d0ef76 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -273,6 +273,10 @@ struct kvaser_msg {
} u;
} __packed;
+struct kvaser_usb_error_summary {
+ u8 channel, status, txerr, rxerr, error_factor;
+};
+
struct kvaser_usb_tx_urb_context {
struct kvaser_usb_net_priv *priv;
u32 echo_index;
@@ -615,6 +619,57 @@ static void kvaser_usb_unlink_tx_urbs(struct
kvaser_usb_net_priv *priv)
priv->tx_contexts[i].echo_index = MAX_TX_URBS;
}
+static void kvaser_usb_rx_error_update_state(struct kvaser_usb_net_priv *priv,
+const struct
kvaser_usb_error_summary *es)
+{
+ struct net_device_stats *stats;
+ unsigned int new_state;
+
+ stats = &priv->netdev->stats;
+ new_state = priv->can.state;
+
+ netdev_dbg(priv->netdev, "Error status: 0x%02x\n", es->status);
+
+ if (es->status & M16C_STATE_BUS_OFF) {
+ priv->can.can_stats.bus_off++;
+ new_state = CAN_STATE_BUS_OFF;
+ } else if (es->status & M16C_STATE_BUS_PASSIVE) {
+ if (priv->can.state != CAN_STATE_ERROR_PASSIVE) {
+ priv->can.can_stats.error_passive++;
+ }
+ new_state = CAN_STATE_ERROR_PASSIVE;
+ }
+
+ if (es->status == M16C_STATE_BUS_ERROR) {
+ if ((priv->can.state < CAN_STATE_ERROR_WARNING) &&
+ ((es->txerr >= 96) || (es->rxerr >= 96))) {
+ priv->can.can_stats.error_warning++;
+ new_state = CAN_STATE_ERROR_WARNING;
+ } else if (priv->can.state > CAN_STATE_ERROR_ACTIVE) {
+ new_state = CAN_STATE_ERROR_ACTIVE;
+ }
+ }
+
+ if (!es->status) {
+ new_state = CAN_STATE_ERROR_ACTIVE;
+ }
+
+ if (priv->can.restart_ms &&
+ (priv->can.state >= CAN_STATE_BUS_OFF) &&
+ (new_state < CAN_STATE_BUS_OFF)) {
+ priv->can.can_stats.restarts++;
+ }
+
+ if (es->error_factor) {
+ priv->can.can_stats.bus_error++;
+ stats->rx_errors++;
+ }
+
+ priv->bec.txerr = es->txerr;
+ priv->bec.rxerr = es->rxerr;
+ priv->can.state = new_state;
+}
+
static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
const struct kvaser_msg *msg)
{
@@ -622,30 +677,30 @@ static void kvaser_usb_rx_error(const struct kvaser_usb
*dev,
struct sk_buff *skb;
struct net_device_stats *stats;
struct kvaser_usb_net_priv *priv;
- unsigned int new_state;
- u8 channel, status, txerr, rxerr, error_factor;
+ struct kvaser_usb_error_summary es = { };
+ unsigned int new_state, old_state;
switch (msg->id) {
case CMD_CAN_ERROR_EVENT:
- channel = msg->u.error_event.channel;
- status = msg->u.error_event.status;
- txerr = msg->u.error_event.tx_errors_count;
- rxerr = msg->u.error_event.rx_errors_count;
- error_factor = msg->u.error_event.error_factor;
+ es.channel = msg->u.error_event.cha
Re: SATA link power management issues
On Tuesday 13 January 2015 02:00:45 Suman Tripathi wrote: > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > > Can you dump the ata_id parameters(LPM section) from the drive and we > > can check the related LPM parameters of the drive ? > > Hi, > > I'm sorry, but I'm not really familiar with ata, could you be a bit > more specific about what you'd like to see? > ok no issues. First can show the log from the point the drive got > enumerated ? Like for eg : > ata2.00: ATA-8: WDC WD5000AAKX-08U6AA0, 19.01H19, max UDMA/100 > > ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) > > ata2.00: configured for UDMA/100 > > I would like to the ATA version the drive is complaint. In the above case > it is ATA-8 [0.698842] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [0.701419] ata3.00: ATA-8: LITEONIT LMT-256M6M mSATA 256GB, DM8110F, max UDMA/133 [0.701421] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 31/32), AA [0.701982] ata3.00: configured for UDMA/133 You can see the entire log here: http://www.spinics.net/lists/linux-ide/msg50069.html > > Thanks, > Gabriele > > On Tue, Jan 13, 2015 at 1:56 AM, Gabriele Mazzotta > wrote: > > > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > > > Can you dump the ata_id parameters(LPM section) from the drive and we > > > can check the related LPM parameters of the drive ? > > > > Hi, > > > > I'm sorry, but I'm not really familiar with ata, could you be a bit > > more specific about what you'd like to see? > > > > Thanks, > > Gabriele > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/at91_ether: prepare and unprepare clock
From: Alexandre Belloni Date: Wed, 7 Jan 2015 23:59:26 +0100 > The clock is enabled without being prepared, this leads to: > > WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:889 __clk_enable+0x24/0xa8() > > and a non working ethernet interface. > > Use clk_prepare_enable() and clk_disable_unprepare() to handle the clock. > > Signed-off-by: Alexandre Belloni 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 RESEND] isdn: fix NUL (\0 or \x00) specification in string
From: Giel van Schijndel Date: Wed, 7 Jan 2015 20:10:12 +0100 > In C one can either use '\0' or '\x00' (or '\000') to add a NUL byte to > a string. '\0x00' isn't part of these and will in fact result in a > single NUL followed by "x00". This fixes that. > > Signed-off-by: Giel van Schijndel > Reported-at: http://www.viva64.com/en/b/0299/ Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: >> >> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart >> >> wrote: >> >> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: >> >> >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: >> >> >> > thinkpad-acpi using software mute simplifies the driver and the user >> >> >> > experience >> >> >> > significantly. >> >> >> >> >> >> Except when it doesn't. >> >> >> >> >> >> I'm probably in minority, but I don't use fancy userspace to mess with >> >> >> my >> >> >> mixer and the mute button worked just fine for me before the change. >> >> >> Wasted half an hour to find out what happened is not a pure win from >> >> >> user >> >> >> experience point of view. >> >> >> >> >> >> Is it really necessary to have software_mute_requested == true by >> >> >> default? >> >> >> Can fancy userspace ask for desired behaviour instead and change >> >> >> kernel to >> >> >> not send hotkeys change notification until software_mute is enabled? >> >> >> >> >> >> -- >> >> >> Kirill A. Shutemov >> >> >> >> >> > >> >> > Thanks for the report Kirill, >> >> > >> >> > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only >> >> > have a >> >> > couple weeks to do so. >> >> > >> >> > Kirill, to define the scope of the problem, if you specify >> >> > software_mute_requested as false on the kernel command line, does your >> >> > system >> >> > function as expected? >> >> >> >> If I understood Kirill's email correctly, the only issue is that he >> >> liked the old behavior. Kirill, is that correct? >> > >> > Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour. >> > >> >> What aspect of the old behavior is better than the new default behavior? > > It's not necessary better. The new behavior just broke my use-case. > > I don't have anything in my system what would react on KEY_MUTE and I used > the functionality platform provides until it suddenly stopped working. > > I personally can live with new thinkpad_acpi. I'll probably update my > configuration to react on the software button. You'd have to do that anyway if you switched to a non-ThinkPad, for better or for worse. > > But who else will get frustrated after update to v3.19? Hopefully fewer people than got frustrated by the old, broken behavior. (It probably wasn't obviously broken for you, because you didn't have software that reacted to KEY_MUTE. But, if you did, you might have noticed all kinds of strange behavior.) --Andy > > -- > Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 12:14:32PM -0800, Andy Lutomirski wrote: > This stuff is at least useful (in theory) for debugging with gdb. And Bah, debugging the kernel with gdb, who does that?! Real men stare at oopses and rebuild stack with pen and paper! :-P -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:26 PM, Borislav Petkov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> What aspect of the old behavior is better than the new default behavior? > > Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0 > thing, the small control light in the mute button doesn't light up to > show that mute is enabled. It still mutes properly in both cases though > so it is only a feedback thing which doesn't work anymore... This is supposed to work, and it works fine on my X220. What Thinkpad do you have, and what distro are you running? Can you run alsamixer (with software_mute=1) and watch the controls to see what changes when you press mute? IIRC, when the master volume goes to 0 or is muted, the magic ALSA hooks will tell thinkpad_acpi so that thinkpad_acpi can adjust the LED. --Andy > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: > On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov > wrote: > > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: > >> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart wrote: > >> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: > >> >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: > >> >> > thinkpad-acpi using software mute simplifies the driver and the user > >> >> > experience > >> >> > significantly. > >> >> > >> >> Except when it doesn't. > >> >> > >> >> I'm probably in minority, but I don't use fancy userspace to mess with > >> >> my > >> >> mixer and the mute button worked just fine for me before the change. > >> >> Wasted half an hour to find out what happened is not a pure win from > >> >> user > >> >> experience point of view. > >> >> > >> >> Is it really necessary to have software_mute_requested == true by > >> >> default? > >> >> Can fancy userspace ask for desired behaviour instead and change kernel > >> >> to > >> >> not send hotkeys change notification until software_mute is enabled? > >> >> > >> >> -- > >> >> Kirill A. Shutemov > >> >> > >> > > >> > Thanks for the report Kirill, > >> > > >> > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only > >> > have a > >> > couple weeks to do so. > >> > > >> > Kirill, to define the scope of the problem, if you specify > >> > software_mute_requested as false on the kernel command line, does your > >> > system > >> > function as expected? > >> > >> If I understood Kirill's email correctly, the only issue is that he > >> liked the old behavior. Kirill, is that correct? > > > > Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour. > > > > What aspect of the old behavior is better than the new default behavior? It's not necessary better. The new behavior just broke my use-case. I don't have anything in my system what would react on KEY_MUTE and I used the functionality platform provides until it suddenly stopped working. I personally can live with new thinkpad_acpi. I'll probably update my configuration to react on the software button. But who else will get frustrated after update to v3.19? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/10] time: Cap clocksource reads to the clocksource max_cycles value
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote: > On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran > wrote: > > On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote: > >> When calculating the current delta since the last tick, we > >> currently have no hard protections to prevent a multiplciation > >> overflow from ocurring. > > > > This is just papering over the problem. The "hard protection" should > > be having a tick scheduled before the range of the clock source is > > exhausted. > > So I disagree this is papering over the problem. > > You say the tick should be scheduled before the clocksource wraps - > but we have logic to do that. Well that is a shame. To my way of thinking, having a reliable watchdog (clock readout) at half the period would be a real solution. Yes, I do mean providing some sort of "soft real time" guarantee. What is the use case here? I thought we are trying to fix unreliable clocks with random jumps. It is hard to see how substituting MAX_DURATION for RANDOM_JUMP_VALUE is helping to catch bad hardware. > However there are many ways that can still go wrong. Virtualization > can delay interrupts for long periods of time, fixable with some soft RT? > the timer/irq code isn't the simplest and there can be bugs, simplify and fix? > or timer hardware itself can have issues. for this we can have a compile time timer validation module, just like we have for locks, mutexs, rcu, etc. > The difficulty is that when something has gone wrong, the > only thing we have to measure the problem may become corrupted. And > worse, once the timekeeping code is having problems, that can result > in bugs that manifest in all sorts of strange ways that are very > difficult to debug (you can't trust your log timestamps, etc). But this this patch make the timestamps trustworthy? Not really. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] selinux: ss: mls: Remove unused function
On Sunday, January 11, 2015 11:44:30 PM Rickard Strandqvist wrote:
> Remove the function mls_import_netlbl_cat() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> security/selinux/ss/mls.c | 38 --
> security/selinux/ss/mls.h |7 ---
> 2 files changed, 45 deletions(-)
Thanks for bringing this up and sending a patch.
However, what we should probably do is take the existing MLS category code in
security_netlbl_secattr_to_sid() and reconcile it with the code in
mls_import_netlbl_cat() and convert security_netlbl_secattr_to_sid() to using
the mls_import_netlbl_cat() function.
Is that something you want to try? If not, let me know and we'll work on it.
> diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c
> index d307b37..c01c755 100644
> --- a/security/selinux/ss/mls.c
> +++ b/security/selinux/ss/mls.c
> @@ -631,42 +631,4 @@ int mls_export_netlbl_cat(struct context *context,
>
> return rc;
> }
> -
> -/**
> - * mls_import_netlbl_cat - Import the MLS categories from NetLabel
> - * @context: the security context
> - * @secattr: the NetLabel security attributes
> - *
> - * Description:
> - * Copy the NetLabel security attributes into the SELinux context; since
> the - * NetLabel security attribute only contains a single MLS category use
> it for - * both the low and high categories of the context. Returns zero
> on success, - * negative values on failure.
> - *
> - */
> -int mls_import_netlbl_cat(struct context *context,
> - struct netlbl_lsm_secattr *secattr)
> -{
> - int rc;
> -
> - if (!policydb.mls_enabled)
> - return 0;
> -
> - rc = ebitmap_netlbl_import(&context->range.level[0].cat,
> -secattr->attr.mls.cat);
> - if (rc != 0)
> - goto import_netlbl_cat_failure;
> -
> - rc = ebitmap_cpy(&context->range.level[1].cat,
> - &context->range.level[0].cat);
> - if (rc != 0)
> - goto import_netlbl_cat_failure;
> -
> - return 0;
> -
> -import_netlbl_cat_failure:
> - ebitmap_destroy(&context->range.level[0].cat);
> - ebitmap_destroy(&context->range.level[1].cat);
> - return rc;
> -}
> #endif /* CONFIG_NETLABEL */
> diff --git a/security/selinux/ss/mls.h b/security/selinux/ss/mls.h
> index e4369e3..11d3c8f 100644
> --- a/security/selinux/ss/mls.h
> +++ b/security/selinux/ss/mls.h
> @@ -62,8 +62,6 @@ void mls_import_netlbl_lvl(struct context *context,
> struct netlbl_lsm_secattr *secattr);
> int mls_export_netlbl_cat(struct context *context,
> struct netlbl_lsm_secattr *secattr);
> -int mls_import_netlbl_cat(struct context *context,
> - struct netlbl_lsm_secattr *secattr);
> #else
> static inline void mls_export_netlbl_lvl(struct context *context,
>struct netlbl_lsm_secattr *secattr)
> @@ -80,11 +78,6 @@ static inline int mls_export_netlbl_cat(struct context
> *context, {
> return -ENOMEM;
> }
> -static inline int mls_import_netlbl_cat(struct context *context,
> - struct netlbl_lsm_secattr *secattr)
> -{
> - return -ENOMEM;
> -}
> #endif
>
> #endif /* _SS_MLS_H */
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 12:22 PM, H. Peter Anvin wrote: > On 01/12/2015 12:14 PM, Andy Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:11 PM, Borislav Petkov wrote: >>> On Mon, Jan 12, 2015 at 11:46:53AM -0800, Andy Lutomirski wrote: Dumb example: pushq_cfi $__KERNEL_DS /* ss */ This doesn't save anything that the unwinder would care about. >>> >>> And? The unwinder or whatever looks at that info simply ignores stuff it >>> is not interested in, no? >> >> But CFI_REL_OFFSET $__KERNEL_DS, 0 probably isn't even well-formed and >> won't build. >> > > I think this is relatively easy to deal with at the expense of a large > .ifeq statement in the macro. > > Is the usage you have in mind something like: pushq_cfi %r11 /* saves r11 */ pushq_cfi $0 /* saves nothing */ pushq_cfi %r11, savereg=rip /* saves rip */ I think I prefer the somewhat less magical: pushq_reg_cfi %r11 /* saves r11 */ pushq_reg_cfi %r11, savereg=rip /* saves rip */ pushq_nounwind_cfi $0 Or something like that. --Andy -hpa > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: > What aspect of the old behavior is better than the new default behavior? Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0 thing, the small control light in the mute button doesn't light up to show that mute is enabled. It still mutes properly in both cases though so it is only a feedback thing which doesn't work anymore... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SATA link power management issues
On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > Can you dump the ata_id parameters(LPM section) from the drive and we > can check the related LPM parameters of the drive ? Hi, I'm sorry, but I'm not really familiar with ata, could you be a bit more specific about what you'd like to see? Thanks, Gabriele -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On 01/12/2015 12:14 PM, Andy Lutomirski wrote: > On Mon, Jan 12, 2015 at 12:11 PM, Borislav Petkov wrote: >> On Mon, Jan 12, 2015 at 11:46:53AM -0800, Andy Lutomirski wrote: >>> Dumb example: >>> >>> pushq_cfi $__KERNEL_DS /* ss */ >>> >>> This doesn't save anything that the unwinder would care about. >> >> And? The unwinder or whatever looks at that info simply ignores stuff it >> is not interested in, no? > > But CFI_REL_OFFSET $__KERNEL_DS, 0 probably isn't even well-formed and > won't build. > I think this is relatively easy to deal with at the expense of a large .ifeq statement in the macro. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix corner case in anon_vma endless growing prevention
On Sun, 11 Jan 2015 16:54:06 +0300 Konstantin Khlebnikov
wrote:
> Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas()
> ("kernel BUG at mm/rmap.c:399!").
>
> Anon_vma_clone() is usually called for a copy of source vma in destination
> argument. If source vma has anon_vma it should be already in dst->anon_vma.
> NULL in dst->anon_vma is used as a sign that it's called from anon_vma_fork().
> In this case anon_vma_clone() finds anon_vma for reusing.
>
> Vma_adjust() calls it differently and this breaks anon_vma reusing logic:
> anon_vma_clone() links vma to old anon_vma and updates degree counters but
> vma_adjust() overrides vma->anon_vma right after that. As a result final
> unlink_anon_vmas() decrements degree for wrong anon_vma.
>
> This patch assigns ->anon_vma before calling anon_vma_clone().
>
> Signed-off-by: Konstantin Khlebnikov
> Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
I've asked Greg not to take 7a3ef208e662 into -stable because of this
problem. So if you still think we should fix this in -stable, could
you please prepare an updated patch and send it to Greg?
> Tested-by: Chris Clayton
> Tested-by: Oded Gabbay
> Cc: Daniel Forrest
> Cc: Michal Hocko
> Cc: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cfq-iosched: fix incorrect filing of rt async cfqq
Hi,
If you can manage to submit an async write as the first async I/O from
the context of a process with realtime scheduling priority, then a
cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It
ends up in the best effort array, but actually has realtime I/O
scheduling priority set in cfqq->ioprio.
The reason is that cfq_get_queue assumes the default scheduling class and
priority when there is no information present (i.e. when the async cfqq
is created):
static struct cfq_queue *
cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
struct bio *bio, gfp_t gfp_mask)
{
const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
cic->ioprio starts out as 0, which is "invalid". So, class of 0
(IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
static struct cfq_queue **
cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
{
switch (ioprio_class) {
case IOPRIO_CLASS_RT:
return &cfqd->async_cfqq[0][ioprio];
case IOPRIO_CLASS_NONE:
ioprio = IOPRIO_NORM;
/* fall through */
case IOPRIO_CLASS_BE:
return &cfqd->async_cfqq[1][ioprio];
case IOPRIO_CLASS_IDLE:
return &cfqd->async_idle_cfqq;
default:
BUG();
}
}
Here, instead of returning a class mapped from the process' scheduling
priority, we get back the bucket associated with IOPRIO_CLASS_BE.
Now, there is no queue allocated there yet, so we create it:
cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
That function ends up doing this:
cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
cfq_init_prio_data(cfqq, cic);
cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio
data does this:
ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
switch (ioprio_class) {
default:
printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
case IOPRIO_CLASS_NONE:
/*
* no prio set, inherit CPU scheduling settings
*/
cfqq->ioprio = task_nice_ioprio(tsk);
cfqq->ioprio_class = task_nice_ioclass(tsk);
break;
So we basically have two code paths that treat IOPRIO_CLASS_NONE
differently, which results in an RT async cfqq filed into a best effort
bucket.
Attached is a patch which fixes the problem. I'm not sure how to make
it cleaner. Suggestions would be welcome.
Signed-off-by: Jeff Moyer
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 6f2751d..b9abdca 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -3656,12 +3656,17 @@ static struct cfq_queue *
cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
struct bio *bio, gfp_t gfp_mask)
{
- const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
- const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
+ int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
+ int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
struct cfq_queue **async_cfqq = NULL;
struct cfq_queue *cfqq = NULL;
if (!is_sync) {
+ if (!ioprio_valid(cic->ioprio)) {
+ struct task_struct *tsk = current;
+ ioprio = task_nice_ioprio(tsk);
+ ioprio_class = task_nice_ioclass(tsk);
+ }
async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
cfqq = *async_cfqq;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/10] clocksource: Remove clocksource_max_deferment()
On Mon, Jan 12, 2015 at 10:36:58AM -0800, John Stultz wrote: > So, the first patch had a cleanup which removed case where the max > mult value was being calculated assuming nanoseconds was a s64 instead > of a u64, which resulted in the max_idle_ns to be halved. So this > doesn't actually cost us more over what the current kernel does. Ok, fine, missed that. Thanks Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] console/dummy: Move screen size selection from CPP to Kconfig
PA-RISC already handled the dummy console screen size selection in Kconfig, so generalize this to other platforms. ARM keeps on using screen_info, which is filled in by platform-specific code, or from ATAGS. Signed-off-by: Geert Uytterhoeven --- drivers/video/console/Kconfig| 16 ++-- drivers/video/console/dummycon.c | 5 + 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index fe1cd0148e139eaa..ba97efc3bf707db8 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -77,18 +77,22 @@ config DUMMY_CONSOLE config DUMMY_CONSOLE_COLUMNS int "Initial number of console screen columns" -depends on PARISC && DUMMY_CONSOLE -default "160" +depends on DUMMY_CONSOLE && !ARM +default 160 if PARISC +default 80 help - The default value is 160, which should fit a 1280x1024 monitor. + On PA-RISC, the default value is 160, which should fit a 1280x1024 + monitor. Select 80 if you use a 640x480 resolution by default. config DUMMY_CONSOLE_ROWS int "Initial number of console screen rows" -depends on PARISC && DUMMY_CONSOLE -default "64" +depends on DUMMY_CONSOLE && !ARM +default 64 if PARISC +default 25 help - The default value is 64, which should fit a 1280x1024 monitor. + On PA-RISC, the default value is 64, which should fit a 1280x1024 + monitor. Select 25 if you use a 640x480 resolution by default. config FRAMEBUFFER_CONSOLE diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c index 40bec8d64b0a4a56..0efc52f11ad003ae 100644 --- a/drivers/video/console/dummycon.c +++ b/drivers/video/console/dummycon.c @@ -20,13 +20,10 @@ #if defined(__arm__) #define DUMMY_COLUMNS screen_info.orig_video_cols #define DUMMY_ROWS screen_info.orig_video_lines -#elif defined(__hppa__) +#else /* set by Kconfig. Use 80x25 for 640x480 and 160x64 for 1280x1024 */ #define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS #define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS -#else -#define DUMMY_COLUMNS 80 -#define DUMMY_ROWS 25 #endif static const char *dummycon_startup(void) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 12:11 PM, Borislav Petkov wrote: > On Mon, Jan 12, 2015 at 11:46:53AM -0800, Andy Lutomirski wrote: >> Dumb example: >> >> pushq_cfi $__KERNEL_DS /* ss */ >> >> This doesn't save anything that the unwinder would care about. > > And? The unwinder or whatever looks at that info simply ignores stuff it > is not interested in, no? But CFI_REL_OFFSET $__KERNEL_DS, 0 probably isn't even well-formed and won't build. > >> Better example: >> >> pushq_cfi \child_rip /* rip */ >> CFI_REL_OFFSETrip,0 >> >> Doing this with a macro would need a fancier macro. > > I'd ask first whether we really need this at all. > >> Then there's crap like: >> >> pushq_cfi %rdi >> SCHEDULE_USER >> popq_cfi %rdi > > I guess we can add a gas regname argument optional and if it is set, use > it and if not, use the reg itself... Or something like that in the best > effort type of approach. > >> I would need to look a lot more carefully to figure out whether this >> would need CFI_REL_OFFSET. >> >> If we actually had a DWARF unwinder in the kernel, maybe we could have >> real test cases :-/ > > I don't think that's ever going to happen. > > I'd say we do the CFI annotation on a best effort basis but not > sacrifice readability in the process. If it can't be annotated, well, > tough luck. > This stuff is at least useful (in theory) for debugging with gdb. And I wouldn't mind an optional DWARF unwinder to get higher quality backtraces. Obviously any such thing would need to be quite robust. I think SuSE has one. > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: line6: Updated comma spacing to fit within coding style
On Sat, Dec 27, 2014 at 05:00:10PM +1100, Damon Swayn wrote: > Fixed a coding style issue reported by checkpatch surrounding the > spacing of comma's > > Signed-off-by: Damon Swayn > --- > drivers/staging/line6/pcm.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Sorry, someone else sent this same patch in before you :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: line6: fix coding style issue in pcm.h
On Mon, Dec 22, 2014 at 10:45:01PM +0200, Dmitriy Polyanskiy wrote: > This is a patch to pcm.h file that fixes up some space warnings > found by checkpatch.pl > > Signed-off-by: Dmitriy Polyanskiy > --- > drivers/staging/line6/pcm.h |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Sorry, someone else already sent this patch in and got it merged first :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.19.0-rc4+ fails to compile, missing 'usr/missing-syscalls'
Any idea what is wrong? -rc3 compiled ok, then I rebased just now, and get this: cd /mnt/sda/home/greearb/git/linux-3.17.dev.y/drivers/net/wireless/ath/ath10k/ cd ~/kernel/2.6/linux-3.19.x64/; make -j8 bzImage modules CHK include/config/kernel.release GEN ./Makefile CHK include/generated/uapi/linux/version.h Using /mnt/sda/home/greearb/git/linux-3.19.dev.y as source for kernel CHK include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL/mnt/sda/home/greearb/git/linux-3.19.dev.y/scripts/checksyscalls.sh make[3]: *** No rule to make target `usr/missing-syscalls', needed by `__build'. Stop. make[3]: *** Waiting for unfinished jobs CC kernel/bounds.s CHK include/generated/compile.h CC init/main.o CC init/do_mounts.o CC init/do_mounts_rd.o /mnt/sda/home/greearb/git/linux-3.19.dev.y/kernel/Makefile:132: *** No X.509 certificates found *** CC init/do_mounts_initrd.o AS arch/x86/ia32/ia32entry.o make[2]: *** [usr] Error 2 make[2]: *** Waiting for unfinished jobs CC arch/x86/ia32/sys_ia32.o Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux/types.h: Always use unsigned long for pgoff_t
Everybody uses unsigned long for pgoff_t, and no ever overrode the definition of pgoff_t. Keep it that way, and remove the option of overriding it. Signed-off-by: Geert Uytterhoeven --- include/linux/types.h | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/include/linux/types.h b/include/linux/types.h index a0bb7048687f565e..c26aa84be9d36131 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -135,12 +135,9 @@ typedef unsigned long blkcnt_t; #endif /* - * The type of an index into the pagecache. Use a #define so asm/types.h - * can override it. + * The type of an index into the pagecache. */ -#ifndef pgoff_t #define pgoff_t unsigned long -#endif /* A dma_addr_t can hold any valid DMA or bus address for the platform */ #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 11:46:53AM -0800, Andy Lutomirski wrote: > Dumb example: > > pushq_cfi $__KERNEL_DS /* ss */ > > This doesn't save anything that the unwinder would care about. And? The unwinder or whatever looks at that info simply ignores stuff it is not interested in, no? > Better example: > > pushq_cfi \child_rip /* rip */ > CFI_REL_OFFSETrip,0 > > Doing this with a macro would need a fancier macro. I'd ask first whether we really need this at all. > Then there's crap like: > > pushq_cfi %rdi > SCHEDULE_USER > popq_cfi %rdi I guess we can add a gas regname argument optional and if it is set, use it and if not, use the reg itself... Or something like that in the best effort type of approach. > I would need to look a lot more carefully to figure out whether this > would need CFI_REL_OFFSET. > > If we actually had a DWARF unwinder in the kernel, maybe we could have > real test cases :-/ I don't think that's ever going to happen. I'd say we do the CFI annotation on a best effort basis but not sacrifice readability in the process. If it can't be annotated, well, tough luck. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] video: Drop superfluous "select VT_HW_CONSOLE_BINDING"
commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
VT_HW_CONSOLE_BINDING, but forgot to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split in two (drm and video) patches.
---
drivers/video/fbdev/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4916c97216f880fc..f2c3fb7d03992ad1 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2151,7 +2151,6 @@ config FB_PS3
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
---help---
Include support for the virtual frame buffer in the PS3 platform.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
commit 765d5b9c2b72f5b9 ("fbdev: fbcon: select VT_HW_CONSOLE_BINDING")
made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot
to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Remove it, also from new drivers.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split in two (drm and video) patches,
- Fix recently added rockchip.
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/rockchip/Kconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9e9b7e7992..c072999b7e0345c6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -6,7 +6,6 @@ config DRM_EXYNOS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ca9f085efa922982..8652dad82009e3ce 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,6 @@ config DRM_ROCKCHIP
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Rockchip soc chipset.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zsmalloc: add statistics support
On Tue, Dec 23, 2014 at 11:40:45AM +0900, Minchan Kim wrote: > Hi Ganesh, > > On Tue, Dec 23, 2014 at 10:26:12AM +0800, Ganesh Mahendran wrote: > > Hello Minchan > > > > 2014-12-20 10:25 GMT+08:00 Minchan Kim : > > > Hey Ganesh, > > > > > > On Sat, Dec 20, 2014 at 09:43:34AM +0800, Ganesh Mahendran wrote: > > >> 2014-12-20 8:23 GMT+08:00 Minchan Kim : > > >> > On Fri, Dec 19, 2014 at 04:17:56PM -0800, Andrew Morton wrote: > > >> >> On Sat, 20 Dec 2014 09:10:43 +0900 Minchan Kim > > >> >> wrote: > > >> >> > > >> >> > > It involves rehashing a lengthy argument with Greg. > > >> >> > > > >> >> > Okay. Then, Ganesh, > > >> >> > please add warn message about duplicaed name possibility althoug > > >> >> > it's unlikely as it is. > > >> >> > > >> >> Oh, getting EEXIST is easy with this patch. Just create and destroy a > > >> >> pool 2^32 times and the counter wraps ;) It's hardly a serious issue > > >> >> for a debugging patch. > > >> > > > >> > I meant that I wanted to change from index to name passed from caller > > >> > like this > > >> > > > >> > zram: > > >> > zs_create_pool(GFP_NOIO | __GFP_HIGHMEM, > > >> > zram->disk->first_minor); > > >> > > > >> > So, duplication should be rare. :) > > >> > > >> We still can not know whether the name is duplicated if we do not > > >> change the debugfs API. > > >> The API does not return the errno to us. > > >> > > >> How about just zsmalloc decides the name of the pool-id, like pool-x. > > >> When the pool-id reaches > > >> 0x., we print warn message about duplicated name, and stop > > >> creating the debugfs entry > > >> for the user. > > > > > > The idea is from the developer point of view to implement thing easy > > > but my point is we should take care of user(ie, admin) rather than > > > developer(ie, we). > > > > Yes. I got it. > > > > > > > > For user, /sys/kernel/debug/zsmalloc/zram0 would be more > > > straightforward and even it doesn't need zram to export > > > /sys/block/zram0/pool-id. > > > > BTW, If we add a new argument in zs_create_pool(). It seems we also need to > > add argument in zs_zpool_create(). So, zpool/zswap/zbud will be > > modified to support > > the new API. > > Is that acceptable? > > I think it's doable. > The zpool_create_pool has already zswap_zpool_type. > Ccing maintainers for double check. Late response, but fine by me. Seth > > Many thanks. > > > > > > Thanks. > > > > > > > > Thanks. > > > > > >> > > >> Thanks. > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-mm' in > > the body to majord...@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > > -- > Kind regards, > Minchan Kim > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.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/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart wrote: >> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: >> >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: >> >> > thinkpad-acpi using software mute simplifies the driver and the user >> >> > experience >> >> > significantly. >> >> >> >> Except when it doesn't. >> >> >> >> I'm probably in minority, but I don't use fancy userspace to mess with my >> >> mixer and the mute button worked just fine for me before the change. >> >> Wasted half an hour to find out what happened is not a pure win from user >> >> experience point of view. >> >> >> >> Is it really necessary to have software_mute_requested == true by default? >> >> Can fancy userspace ask for desired behaviour instead and change kernel to >> >> not send hotkeys change notification until software_mute is enabled? >> >> >> >> -- >> >> Kirill A. Shutemov >> >> >> > >> > Thanks for the report Kirill, >> > >> > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only >> > have a >> > couple weeks to do so. >> > >> > Kirill, to define the scope of the problem, if you specify >> > software_mute_requested as false on the kernel command line, does your >> > system >> > function as expected? >> >> If I understood Kirill's email correctly, the only issue is that he >> liked the old behavior. Kirill, is that correct? > > Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour. > What aspect of the old behavior is better than the new default behavior? --Andy > -- > Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] HMM: introduce heterogeneous memory management v2.
On 01/12/2015 05:46 PM, Jerome Glisse wrote:
> On Sun, Jan 11, 2015 at 03:24:42PM +0200, Oded Gabbay wrote:
>>
>>
>> On 01/06/2015 12:44 AM, j.gli...@gmail.com wrote:
>>> From: Jérôme Glisse
>>>
>>> This patch only introduce core HMM functions for registering a new mirror
>>> and
>>> stopping a mirror as well as registering and unregistering a device.
>>>
>>> The lifecycle of HMM object is handled differently then one of mmu_notifier
>>> because unlike mmu_notifier there can be concurrent call from both mm code
>>> to
>>> HMM code and/or from device driver code to HMM code. Moreover lifetime of
>>> HMM
>>> can be uncorrelated from the lifetime of the process that is being mirror.
>>>
>>> Changed since v1:
>>> - Updated comment of hmm_device_register().
>>>
>>> Signed-off-by: Jérôme Glisse
>>> Signed-off-by: Sherry Cheung
>>> Signed-off-by: Subhash Gutti
>>> Signed-off-by: Mark Hairgrove
>>> Signed-off-by: John Hubbard
>>> Signed-off-by: Jatin Kumar
>>> ---
>>> MAINTAINERS | 7 +
>>> include/linux/hmm.h | 129
>>> include/linux/mm.h | 11 ++
>>> include/linux/mm_types.h | 14 ++
>>> kernel/fork.c| 2 +
>>> mm/Kconfig | 15 ++
>>> mm/Makefile | 1 +
>>> mm/hmm.c | 373
>>> +++
>>> 8 files changed, 552 insertions(+)
>>> create mode 100644 include/linux/hmm.h
>>> create mode 100644 mm/hmm.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index c03bc6c..3ec87c4 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -4533,6 +4533,13 @@ F: include/uapi/linux/if_hippi.h
>>> F: net/802/hippi.c
>>> F: drivers/net/hippi/
>>>
>>> +HMM - Heterogeneous Memory Management
>>> +M: Jérôme Glisse
>>> +L: linux...@kvack.org
>>> +S: Maintained
>>> +F: mm/hmm.c
>>> +F: include/linux/hmm.h
>>> +
>>> HOST AP DRIVER
>>> M: Jouni Malinen
>>> L: hos...@shmoo.com (subscribers-only)
>>> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
>>> new file mode 100644
>>> index 000..8eddc15
>>> --- /dev/null
>>> +++ b/include/linux/hmm.h
>>> @@ -0,0 +1,129 @@
>>> +/*
>>> + * Copyright 2013 Red Hat Inc.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Authors: Jérôme Glisse
>>> + */
>>> +/* This is a heterogeneous memory management (hmm). In a nutshell this
>>> provide
>>> + * an API to mirror a process address on a device which has its own mmu
>>> using
>>> + * its own page table for the process. It supports everything except
>>> special
>>> + * vma.
>>> + *
>>> + * Mandatory hardware features :
>>> + * - An mmu with pagetable.
>>> + * - Read only flag per cpu page.
>>> + * - Page fault ie hardware must stop and wait for kernel to service
>>> fault.
>>> + *
>>> + * Optional hardware features :
>>> + * - Dirty bit per cpu page.
>>> + * - Access bit per cpu page.
>>> + *
>>> + * The hmm code handle all the interfacing with the core kernel mm code and
>>> + * provide a simple API. It does support migrating system memory to device
>>> + * memory and handle migration back to system memory on cpu page fault.
>>> + *
>>> + * Migrated memory is considered as swaped from cpu and core mm code point
>>> of
>>> + * view.
>>> + */
>>> +#ifndef _HMM_H
>>> +#define _HMM_H
>>> +
>>> +#ifdef CONFIG_HMM
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +
>>> +struct hmm_device;
>>> +struct hmm_mirror;
>>> +struct hmm;
>>> +
>>> +
>>> +/* hmm_device - Each device must register one and only one hmm_device.
>>> + *
>>> + * The hmm_device is the link btw HMM and each device driver.
>>> + */
>>> +
>>> +/* struct hmm_device_operations - HMM device operation callback
>>> + */
>>> +struct hmm_device_ops {
>>> + /* release() - mirror must stop using the address space.
>>> +*
>>> +* @mirror: The mirror that link process address space with the device.
>>> +*
>>> +* This callback is call either on mm destruction or as result to a
>>> +* call to hmm_mirror_release(). Device driver have to stop all hw
>>> +* thread and all usage of the address space, it has to dirty all pages
>>> +* that have been dirty by the device. But it must not clear any entry
>>> +* from the mirror page table.
>>> +*/
>>> + void (*release)(struct hmm_mirror *mirror);
>>> +};
>>> +
>>> +/* struct hmm_device - per device HMM structure
>>> + *
>>> + * @name: Device name (uniquel
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: > On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart wrote: > > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: > >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: > >> > thinkpad-acpi using software mute simplifies the driver and the user > >> > experience > >> > significantly. > >> > >> Except when it doesn't. > >> > >> I'm probably in minority, but I don't use fancy userspace to mess with my > >> mixer and the mute button worked just fine for me before the change. > >> Wasted half an hour to find out what happened is not a pure win from user > >> experience point of view. > >> > >> Is it really necessary to have software_mute_requested == true by default? > >> Can fancy userspace ask for desired behaviour instead and change kernel to > >> not send hotkeys change notification until software_mute is enabled? > >> > >> -- > >> Kirill A. Shutemov > >> > > > > Thanks for the report Kirill, > > > > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only have > > a > > couple weeks to do so. > > > > Kirill, to define the scope of the problem, if you specify > > software_mute_requested as false on the kernel command line, does your > > system > > function as expected? > > If I understood Kirill's email correctly, the only issue is that he > liked the old behavior. Kirill, is that correct? Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] AT91 DT for 3.20 #1
On Mon, 12 Jan 2015 20:01:51 +0100 Alexandre Belloni wrote: > This series enables RTC on the at91sam9n12 and at91rm9200. > It also adds nodes for the SRAM availabe on at91 SoCs. > > Finally it adds a dtsi for the at91sam9xe and uses it for the ethernut5 dts. To the whole series: Acked-by: Boris Brezillon > > Alexandre Belloni (6): > ARM: at91/dt: at91sam9n12: Add RTC node > ARM: at91/dt: rm9200: add RTC node > ARM: at91/dt: at91rm9200ek: enable RTC > ARM: at91/dt: add SRAM nodes > ARM: at91/dt: Add a dtsi for at91sam9xe > ARM: at91/dt: ethernut5: use at91sam9xe.dtsi > > .../devicetree/bindings/arm/atmel-at91.txt | 1 + > arch/arm/boot/dts/at91rm9200.dtsi | 12 + > arch/arm/boot/dts/at91rm9200ek.dts | 4 ++ > arch/arm/boot/dts/at91sam9260.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9261.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9263.dtsi | 10 > arch/arm/boot/dts/at91sam9g20.dtsi | 9 > arch/arm/boot/dts/at91sam9g45.dtsi | 7 ++- > arch/arm/boot/dts/at91sam9n12.dtsi | 12 + > arch/arm/boot/dts/at91sam9rl.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9x5.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9xe.dtsi | 60 > ++ > arch/arm/boot/dts/ethernut5.dts| 2 +- > arch/arm/boot/dts/sama5d3.dtsi | 5 ++ > arch/arm/boot/dts/sama5d4.dtsi | 5 ++ > 15 files changed, 144 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/boot/dts/at91sam9xe.dtsi > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kgdb: fix potential out-of-bounds access
On Mon, Jan 12, 2015 at 11:54 AM, Jason Wessel wrote: > This is actually already fixed a different way in the kgdb-next: > > https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/commit/?h=kgdb-next&id=c7d9ebf81c456dc185c8eae9e293bfdccf2a65f5 Great. Thanks for the quick response. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] hwmon: jc42: use bitops' sign_extend16
On Mon, Jan 12, 2015 at 06:28:20PM +0100, Martin Kepplinger wrote: > Example change, using new sign_extend functions. No need to drop the Signed-off: line; it only means that I can not take the patch even if I want to. Also, if the patch itself is final, no need to state that it is an example in the description. Instead, use an introductory mail (RFC PATCH 0/x] to explain the background. Otherwise looks good; feel free to add Reviewed-by: Guenter Roeck to the next version. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] can: Convert to runtime_pm
On 01/12/2015 04:04 PM, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the driver,
> Use the runtime_pm framework. This consolidates the actions for runtime PM
> In the appropriate callbacks and makes the driver more readable and
> mantainable.
>
> Signed-off-by: Soren Brinkmann
> Signed-off-by: Kedareswara rao Appana
FTBFS:
> drivers/net/can/xilinx_can.c:1064:9: error: undefined identifier
> 'SET_PM_RUNTIME_PM_OPS'
> CC [M] drivers/net/can/xilinx_can.o
> drivers/net/can/xilinx_can.c:1064:2: error: implicit declaration of function
> ‘SET_PM_RUNTIME_PM_OPS’ [-Werror=implicit-function-declaration]
> SET_PM_RUNTIME_PM_OPS(xcan_runtime_suspend, xcan_runtime_resume, NULL)
> ^
> drivers/net/can/xilinx_can.c:1065:1: error: initializer element is not
> constant
> };
> ^
> drivers/net/can/xilinx_can.c:1065:1: error: (near initialization for
> ‘xcan_dev_pm_ops.prepare’)
Have a look at commit 40bd62c6194bdee1bc6652b3b0aa28e34883f603:
More comments inline. Looks quite good now.
> PM: Remove the SET_PM_RUNTIME_PM_OPS() macro
>
> There're now no users left of the SET_PM_RUNTIME_PM_OPS() macro, since
> all have converted to use the SET_RUNTIME_PM_OPS() macro instead, so
> let's remove it.
> ---
> Changes for v5:
> - Updated with the review comments.
>Updated the remove fuction to use runtime_pm.
> Chnages for v4:
> - Updated with the review comments.
> Changes for v3:
> - Converted the driver to use runtime_pm.
> Changes for v2:
> - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
> drivers/net/can/xilinx_can.c | 157 -
> 1 files changed, 107 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 6c67643..67aef00 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_NAME "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
> u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
> void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
> u32 val);
> - struct net_device *dev;
> + struct device *dev;
> void __iomem *reg_base;
> unsigned long irq_flags;
> struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
> + __func__, ret);
> + return ret;
> + }
> +
> ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> ndev->name, ndev);
> if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
> goto err;
> }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
> /* Set chip into reset mode */
> ret = set_reset_mode(ndev);
> if (ret < 0) {
> netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
> }
>
> /* Common open */
> ret = open_candev(ndev);
> if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
> ret = xcan_chip_start(ndev);
> if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
> err_candev:
> close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
> err_irq:
> free_irq(ndev->irq, ndev);
> err:
> + pm_runtime_put(priv->dev);
> +
> return ret;
> }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
> netif_stop_queue(ndev);
> napi_disable(&priv->napi);
> xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> free_irq(ndev->irq, ndev);
> close_candev(ndev);
>
> can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
> return 0;
> }
> @@ -934,27 +927,20 @@ static int xcan_get_berr_counter(const struct
> net_device *ndev,
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret)
> -
Re: [PATCH 00/25] line6usb cleanup
On Mon, Jan 12, 2015 at 05:35:01PM +0100, Takashi Iwai wrote: > At Sun, 11 Jan 2015 15:04:55 -0600, > Chris Rorvick wrote: > > > > > At Fri, 9 Jan 2015 23:35:46 -0600, > > > Chris Rorvick wrote: > > >> > > >> I have a TonePort UX2 that I've used for testing, meaning that some of > > >> this is really only compile-tested. > > > > > > If anyone is responsible for testing with real hardware, I'll happily > > > review. > > > > To be clear, the TonePort UX2 is real hardware. But this driver > > basically supports four classes of Line 6 devices and I'm only covering > > one of them. > > > > So this series is a first step in trying to address this. Having this > > as a single driver probably made sense when it was a separate project, > > but now that it is in-tree it seems like the POD, PODHD, TonePort, and > > Variax pieces should each be separate drivers that each depend on a core > > Line 6 driver. I think the cleanup in this series will make that > > easier. None of this is my area of expertise, though, so advice and > > feedback is very welcome. > > > > > are there any active developers for this driver? > > > > I intended to do further work. I know there is quite a bit of mundane > > checkpatch cleanup that would need to get done before this could get > > promoted, and I believe I read that it's using sysfs for stuff that > > would normally be done via an ALSA interface, and the sysfs interface > > has not been documented nor has it been justified. All stuff I thought > > I might look into. > > > > But I'm just doing this for fun so I can't promise anything. :-) > > OK, so the situation looks fairly good, we have a few active > developers and/or testers. And the current code doesn't look so > terrible despite of it being in staging directory. That said, I think > we can promote this stuff into sound/usb/line6 directory, then apply > Chris' cleanup patches, and work on it further. > > Does it sound OK for you guys? Greg? > > Once when I get approval, I'll start a new clean branch on sound.git > tree so that you guys can work on it further for 3.20 kernel. That sounds fine with me. I have 4 other patches in my "to-apply" queue other than these 25 for this driver that I'll forward on to you for inclusion in your tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: line6: fix parentheses around macro in usbdefs.h
On Wed, Dec 03, 2014 at 07:34:42PM +0100, Sam van Kampen wrote:
> This patch fixes the error "Macros with complex values should be enclosed in
> parentheses", as reported by checkpatch.pl.
>
> Signed-off-by: Sam van Kampen
> ---
> drivers/staging/line6/usbdefs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/line6/usbdefs.h b/drivers/staging/line6/usbdefs.h
> index 2d1cc47..48958b5 100644
> --- a/drivers/staging/line6/usbdefs.h
> +++ b/drivers/staging/line6/usbdefs.h
> @@ -40,7 +40,7 @@
> #define LINE6_DEVID_TONEPORT_UX2 0x4142
> #define LINE6_DEVID_VARIAX0x534d
>
> -#define LINE6_BIT(x) LINE6_BIT_ ## x = 1 << LINE6_INDEX_ ## x
> +#define LINE6_BIT(x) (LINE6_BIT_ ## x = 1 << LINE6_INDEX_ ## x)
>
> enum {
> LINE6_INDEX_BASSPODXT,
I love this line in the driver, it proves that people make changes to
the code without even building it.
Please ALWAYS test-build your patches, otherwise you waste people's time
and make them grumpy.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] X86: Add a thread cpu time implementation to vDSO
On Tue, Jan 06, 2015 at 11:18:39AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 05, 2015 at 03:23:38PM -0800, Shaohua Li wrote:
> > Good, it works. But the timestamp (.time_running and friends) only gets
> > updated for real hardware event between context switches. For software
> > event, the timestamp is initialized once, then never updated. If I use
> > it to get time, I actually get CLOCK_MONOTONIC. Hardware events work
> > well here, but depending on hardware event is too tricky, which I'd like
> > to avoid.
>
> Hmm, that's an unfortunate difference in behaviour, does something like
> the below cure that for you?
Hi Peter,
can we push these to upstream? It works very well here.
Thanks,
Shaohua
> ---
> kernel/events/core.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 4c1ee7f2bebc..0feb4e039359 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5965,11 +5965,13 @@ static void perf_swevent_del(struct perf_event
> *event, int flags)
> static void perf_swevent_start(struct perf_event *event, int flags)
> {
> event->hw.state = 0;
> + perf_event_update_userpage(event);
> }
>
> static void perf_swevent_stop(struct perf_event *event, int flags)
> {
> event->hw.state = PERF_HES_STOPPED;
> + perf_event_update_userpage(event);
> }
>
> /* Deref the hlist from the update side */
> @@ -6410,12 +6412,14 @@ static void cpu_clock_event_start(struct perf_event
> *event, int flags)
> {
> local64_set(&event->hw.prev_count, local_clock());
> perf_swevent_start_hrtimer(event);
> + perf_event_update_userpage(event);
> }
>
> static void cpu_clock_event_stop(struct perf_event *event, int flags)
> {
> perf_swevent_cancel_hrtimer(event);
> cpu_clock_event_update(event);
> + perf_event_update_userpage(event);
> }
>
> static int cpu_clock_event_add(struct perf_event *event, int flags)
> @@ -6484,12 +6488,14 @@ static void task_clock_event_start(struct perf_event
> *event, int flags)
> {
> local64_set(&event->hw.prev_count, event->ctx->time);
> perf_swevent_start_hrtimer(event);
> + perf_event_update_userpage(event);
> }
>
> static void task_clock_event_stop(struct perf_event *event, int flags)
> {
> perf_swevent_cancel_hrtimer(event);
> task_clock_event_update(event, event->ctx->time);
> + perf_event_update_userpage(event);
> }
>
> static int task_clock_event_add(struct perf_event *event, int flags)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bitops.h: add sign_extend8(), 16 and 64 functions
On Mon, Jan 12, 2015 at 06:22:50PM +0100, Martin Kepplinger wrote: > This adds helper functions for sign-extending signed values of any lower > (hardware-)given size to s8, s16 or s64 respectively, just like > sign_extend32() > for s32. > > Signed-off-by: Martin Kepplinger > Suggested-by: Christoph Muellner Reviewed-by: Guenter Roeck Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
On Mon, Jan 12, 2015 at 11:37 AM, Borislav Petkov wrote: > Andy, please trim your replies. > > On Mon, Jan 12, 2015 at 11:25:39AM -0800, Andy Lutomirski wrote: >> I think that some users don't want the CFI_REL_OFFSET. > > Why? I thought those two annotations are independent? As you said: > > "IOW, one is to keep the stack frame tracking consistent and the other > is to tell the unwinder about the register we just saved." > > Sounds to me like we want both... > Dumb example: pushq_cfi $__KERNEL_DS /* ss */ This doesn't save anything that the unwinder would care about. Better example: pushq_cfi \child_rip /* rip */ CFI_REL_OFFSETrip,0 Doing this with a macro would need a fancier macro. Then there's crap like: pushq_cfi %rdi SCHEDULE_USER popq_cfi %rdi I would need to look a lot more carefully to figure out whether this would need CFI_REL_OFFSET. If we actually had a DWARF unwinder in the kernel, maybe we could have real test cases :-/ --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kgdb: fix potential out-of-bounds access
CPU arrays (e.g., kgdb_info[]) are indexed from 0 (inclusive) to NR_CPUS (exclusive). Pointed out by Coverity, CID 1262269 Signed-off-by: Brian Norris Cc: Jason Wessel --- Untested kernel/debug/kdb/kdb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c index f191bddf64b8..53f051853f14 100644 --- a/kernel/debug/kdb/kdb_main.c +++ b/kernel/debug/kdb/kdb_main.c @@ -2256,7 +2256,7 @@ static int kdb_cpu(int argc, const char **argv) /* * Validate cpunum */ - if ((cpunum > NR_CPUS) || !kgdb_info[cpunum].enter_kgdb) + if ((cpunum >= NR_CPUS) || !kgdb_info[cpunum].enter_kgdb) return KDB_BADCPUNUM; dbg_switch_cpu = cpunum; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question concerning RCU
On Mon, Jan 12, 2015 at 11:48:28AM +, Stoidner, Christoph wrote:
> Hi Paul,
>
> > You got stack traces with the stall warnings, correct? If so, please look
> > at them and at Documentation/RCU/stallwarn.txt and see if the kernel is
> > looping somewhere inappropriate.
>
> Yes and no. I have a stack trace, but it is not generated by a stall warning.
> More
> precise: I can never see any stall warning. The reason is that the system
> freezes
> when it is about to output such a warning. Instead the stack trace is
> generated
> by gdb and JTAG hardware debugging, when freezing has occurred.
>
> So I am not sure if there is really a CPU-stall condition or it is just a
> misrepresented
> stall detection. However, outputting a stall warning leads to system freeze.
> The
> warning is never seen.
Two things to try:
1. alt-sysreq-t to get all tasks' stacks, or
2. disable RCU CPU stall warnings and see if the hangs go away.
Hmmm... Are you by chance pushing all dmesg through a serial console?
> > I am not familiar with the low-level ARM kernel code, but the stack below
> > leads me to suspect that your kernel is interrupting itself to death or
> > is improperly handling interrupts.
>
> The stack trace must be read from bottom to top. The repetitive occurrence of
> "__irq_svc () at arch/arm/kernel/entry-armv.S:202" on bottom of stack trace
> is
> caused by the stack frame of the interrupt context. This is completely legal
> and
> also the case in normal situations. Instead the problem is on the top of the
> stack
> trace, in function rcu_print_task_stall(). The loop rcutree_plugin.h in line
> 528
> never ends:
>
> static int rcu_print_task_stall(struct rcu_node *rnp)
> {
> ...
> ...
>
> list_for_each_entry_continue(t, &rnp->blkd_tasks, rcu_node_entry) {
> printk(KERN_CONT " P%d", t->pid);
> ndetected++;
> }
>
> ...
> ...
> }
>
> That means list_for_each_entry_continue () never ends since
> rcu_node_entry.next
> seems to point to it-self but not to rnp->blkd_tasks. I have no idea how this
> can
> happen.
It is not supposed to happen, and I haven't heard of it happening
anywhere else. I do hold the appropriate lock across that code.
One thing to try would be to add a counter and break out of the loop
after (say) 10 iterations. Is that a change you are comfortable making?
> One more thing: Just for testing I have now enabled CONFIG_TINY_PREEMPT_RCU.
> Until now the problem has not occurred anymore. Do you have any idea what
> makes
> the differences here?
Any number of things, including that I am not sure that your version
of CONFIG_TINY_PREEMPT_RCU correctly detects RCU CPU stalls. ;-)
Please note that CONFIG_TINY_PREEMPT_RCU was removed a few versions ago.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] nfs: prevent truncate on active swapfile
On Sat, Jan 10, 2015 at 05:08:03PM -0500, Trond Myklebust wrote:
> Hi Omar,
>
> On Thu, Jan 8, 2015 at 4:18 AM, Omar Sandoval wrote:
> > Most filesystems prevent truncation of an active swapfile by way of
> > inode_newsize_ok, called from inode_change_ok. NFS doesn't call either
> > from nfs_setattr, presumably because most of these checks are expected
> > to be done server-side. However, the IS_SWAPFILE check can only be done
> > client-side, and truncating a swapfile can't possibly be good.
> >
> > Signed-off-by: Omar Sandoval
> > ---
> > Hi, Trond,
> >
> > Now that the holidays are over, could you take a look at this? It was
> > generated against v3.19-rc3.
> >
> > Thanks!
> >
> > fs/nfs/inode.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> > index 4bffe63..9205513 100644
> > --- a/fs/nfs/inode.c
> > +++ b/fs/nfs/inode.c
> > @@ -506,10 +506,15 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
> > attr->ia_valid &= ~ATTR_MODE;
> >
> > if (attr->ia_valid & ATTR_SIZE) {
> > + loff_t i_size;
> > +
> > BUG_ON(!S_ISREG(inode->i_mode));
> >
> > - if (attr->ia_size == i_size_read(inode))
> > + i_size = i_size_read(inode);
> > + if (attr->ia_size == i_size)
> > attr->ia_valid &= ~ATTR_SIZE;
> > + else if (attr->ia_size < i_size && IS_SWAPFILE(inode))
> > + return -ETXTBSY;
> > }
> >
> > /* Optimization: if the end result is no change, don't RPC */
> > --
> > 2.2.1
> >
>
> I agree that truncating a swap file is bad, however as you point out,
> this really only addresses the case on the client that knows about
> this being a swap file.
> I'll take the patch,
Thanks, I appreciate it.
> but I'm wondering if we couldn't do better in the
> case where we're using NFSv4 by using share deny modes (which are
> enforced by the server). The problem is that there appears to be
> nothing in swapon() that tells the filesystem this is an open of a
> swap file...
Yeah, it would be nice for completeness to prevent one client from
truncating another client's swapfile. However, I'd hope that anyone
using swap-over-NFS on a shared NFS mount would take the necessary
precautions in terms of permissions, etc. to prevent someone from doing
that. Also, since the failure mode of truncating an NFS swapfile is a
corrupt swapfile rather than a corrupt filesystem (like on a local
filesystem), it's probably okay to just deal with the low-hanging fruit
for now.
Thanks!
>
> Cheers
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer, PrimaryData
> trond.mykleb...@primarydata.com
--
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] ARM: at91/dt: update udc compatible strings
On Mon, 12 Jan 2015 13:31:26 -0600
Felipe Balbi wrote:
> On Mon, Jan 12, 2015 at 08:18:16PM +0100, Boris Brezillon wrote:
> > Hi Felipe,
> >
> > On Mon, 12 Jan 2015 12:23:49 -0600
> > Felipe Balbi wrote:
> >
> > > On Mon, Jan 12, 2015 at 11:57:56AM +0100, Boris Brezillon wrote:
> > > > at91sam9g45, at91sam9x5 and sama5 SoCs should not use
> > > > "atmel,at91sam9rl-udc" for their USB device compatible property since
> > > > this compatible is attached to a specific hardware bug fix.
> > > >
> > > > Signed-off-by: Boris Brezillon
> > > > Acked-by: Alexandre Belloni
> > >
> > > WARNING: DT compatible string "atmel,at91sam9g45-udc" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > #177: FILE: drivers/usb/gadget/udc/atmel_usba_udc.c:1827:
> > > + { .compatible = "atmel,at91sam9g45-udc" },
> > >
> > > WARNING: DT compatible string "atmel,sama5d3-udc" appears un-documented
> > > -- check ./Documentation/devicetree/bindings/
> > > #178: FILE: drivers/usb/gadget/udc/atmel_usba_udc.c:1828:
> > > + { .compatible = "atmel,sama5d3-udc" },
> > >
> > > please fix and resend. Also, when resending, could you add Nicolas'
> > > Acked-by since he's already given it ?
> >
> > Actually these compatible strings are documented in the first patch
> > (where they were introduced), but I'll send a v4 with Nicolas' ack.
>
> heh, checkpatch stupidity :-) My bad.
>
You took v3 of the first patch instead of v4.
Don't know if you can replace it (anyway, that's not such a big deal
since the only change is the commit message)...
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce push/pop macros which generate CFI_REL_OFFSET and CFI_RESTORE
Andy, please trim your replies. On Mon, Jan 12, 2015 at 11:25:39AM -0800, Andy Lutomirski wrote: > I think that some users don't want the CFI_REL_OFFSET. Why? I thought those two annotations are independent? As you said: "IOW, one is to keep the stack frame tracking consistent and the other is to tell the unwinder about the register we just saved." Sounds to me like we want both... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/5] ARM: at91/dt: update udc compatible strings
On Mon, Jan 12, 2015 at 08:18:16PM +0100, Boris Brezillon wrote:
> Hi Felipe,
>
> On Mon, 12 Jan 2015 12:23:49 -0600
> Felipe Balbi wrote:
>
> > On Mon, Jan 12, 2015 at 11:57:56AM +0100, Boris Brezillon wrote:
> > > at91sam9g45, at91sam9x5 and sama5 SoCs should not use
> > > "atmel,at91sam9rl-udc" for their USB device compatible property since
> > > this compatible is attached to a specific hardware bug fix.
> > >
> > > Signed-off-by: Boris Brezillon
> > > Acked-by: Alexandre Belloni
> >
> > WARNING: DT compatible string "atmel,at91sam9g45-udc" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > #177: FILE: drivers/usb/gadget/udc/atmel_usba_udc.c:1827:
> > + { .compatible = "atmel,at91sam9g45-udc" },
> >
> > WARNING: DT compatible string "atmel,sama5d3-udc" appears un-documented --
> > check ./Documentation/devicetree/bindings/
> > #178: FILE: drivers/usb/gadget/udc/atmel_usba_udc.c:1828:
> > + { .compatible = "atmel,sama5d3-udc" },
> >
> > please fix and resend. Also, when resending, could you add Nicolas'
> > Acked-by since he's already given it ?
>
> Actually these compatible strings are documented in the first patch
> (where they were introduced), but I'll send a v4 with Nicolas' ack.
heh, checkpatch stupidity :-) My bad.
--
balbi
signature.asc
Description: Digital signature
[PATCH 02/10] PCI, x86: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arch/x86/pci/i386.c | 74 +
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 9b18ef3..d43e1af 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -205,10 +205,11 @@ EXPORT_SYMBOL(pcibios_align_resource);
* as well.
*/
-static void pcibios_allocate_bridge_resources(struct pci_dev *dev)
+static bool pcibios_allocate_bridge_resources(struct pci_dev *dev)
{
int idx;
struct resource *r;
+ bool changed = false;
for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
r = &dev->resource[idx];
@@ -216,17 +217,33 @@ static void pcibios_allocate_bridge_resources(struct
pci_dev *dev)
continue;
if (r->parent) /* Already allocated */
continue;
- if (!r->start || pci_claim_resource(dev, idx) < 0) {
- /*
-* Something is wrong with the region.
-* Invalidate the resource to prevent
-* child resource allocations in this
-* range.
-*/
- r->start = r->end = 0;
- r->flags = 0;
+
+ if (!r->start)
+ goto clear;
+
+ if (pci_claim_resource(dev, idx) >= 0)
+ continue;
+
+ /* try again after clip for pci bridge*/
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
+ pci_bus_clip_resource(dev, r)) {
+ changed = true;
+ if (pci_claim_resource(dev, idx) >= 0)
+ continue;
}
+
+clear:
+ /*
+* Something is wrong with the region.
+* Invalidate the resource to prevent
+* child resource allocations in this
+* range.
+*/
+ r->start = r->end = 0;
+ r->flags = 0;
}
+
+ return changed;
}
static void pcibios_allocate_bus_resources(struct pci_bus *bus)
@@ -234,8 +251,12 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
struct pci_bus *child;
/* Depth-First Search on bus tree */
- if (bus->self)
- pcibios_allocate_bridge_resources(bus->self);
+ if (bus->self) {
+ bool changed = pcibios_allocate_bridge_resources(bus->self);
+
+ if (changed)
+ pci_setup_bridge(bus);
+ }
list_for_each_entry(child, &bus->children, node)
pcibios_allocate_bus_resources(child);
}
@@ -274,18 +295,27 @@ static void pcibios_allocate_dev_resources(struct pci_dev
*dev, int pass)
dev_dbg(&dev->dev,
"BAR %d: reserving %pr (d=%d, p=%d)\n",
idx, r, disabled, pass);
- if (pci_claim_resource(dev, idx) < 0) {
- if (r->flags & IORESOURCE_PCI_FIXED) {
- dev_info(&dev->dev, "BAR %d %pR
is immovable\n",
+
+ if (pci_claim_resource(dev, idx) >= 0)
+ continue;
+
+ if (r->flags & IORESOURCE_PCI_FIXED) {
+ dev_info(&dev->dev, "BAR %d %pR is
immovable\n",
idx, r);
- } else {
- /* We'll assign a new address
later */
- pcibios_save_fw_addr(dev,
- idx, r->start);
- r->end -= r->start;
- r->start = 0;
- }
+ continue;
+ }
+
+ /* try again with clip */
+ if (pci_bus_clip_resource(dev, r)) {
+ pci_update_resource(dev, idx);
+ if (pci_claim_resource(dev, idx) >= 0)
+
[PATCH 1/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.
One of the reasons omap_hsmmc doesn't use the slot-gpio library
is that it has some non-standard functionality in the card-detect
interrupt service routine.
To make it possible for omap_hsmmc (and maybe others) to be converted
to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
alternate isr to be register by the slot-gpio code.
Signed-off-by: NeilBrown
---
drivers/mmc/core/slot-gpio.c | 18 +-
include/linux/mmc/slot-gpio.h |2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 1a3edbd47719..27117ba47073 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -25,6 +25,7 @@ struct mmc_gpio {
struct gpio_desc *cd_gpio;
bool override_ro_active_level;
bool override_cd_active_level;
+ irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
char cd_label[0];
};
@@ -136,8 +137,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
irq = -EINVAL;
if (irq >= 0) {
+ if (!ctx->cd_gpio_isr)
+ ctx->cd_gpio_isr = mmc_gpio_cd_irqt;
ret = devm_request_threaded_irq(host->parent, irq,
- NULL, mmc_gpio_cd_irqt,
+ NULL, ctx->cd_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
ctx->cd_label, host);
if (ret < 0)
@@ -151,6 +154,19 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
+/* Register an alternate interrupt service routine for
+ * the card-detect GPIO.
+ */
+void mmc_gpio_set_cd_isr(struct mmc_host *host,
+irqreturn_t (*isr)(int irq, void *dev_id))
+{
+ struct mmc_gpio *ctx = host->slot.handler_priv;
+
+ WARN_ON(ctx->cd_gpio_isr);
+ ctx->cd_gpio_isr = isr;
+}
+EXPORT_SYMBOL(mmc_gpio_set_cd_isr);
+
/**
* mmc_gpio_request_cd - request a gpio for card-detection
* @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 4a36d6954631..3945a8c9d3cb 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -26,6 +26,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char
*con_id,
int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
unsigned int idx, bool override_active_level,
unsigned int debounce, bool *gpio_invert);
+void mmc_gpio_set_cd_isr(struct mmc_host *host,
+irqreturn_t (*isr)(int irq, void *dev_id));
void mmc_gpiod_request_cd_irq(struct mmc_host *host);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
