Re: [PATCH v4 5/8] mmc: sdhci-bcm-kona: Add basic use of clocks
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote: > Enable the external clock needed by the host controller during the > probe and disable it during the remove. > > Signed-off-by: Tim Kryger > Reviewed-by: Markus Mayer > Reviewed-by: Matt Porter Reviewed-by: Christian Daudt Chris, Are you ok with me pulling this patch along with the rest of the patchset into the bcm tree? Thanks, csd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] memcg: do not use vmalloc for mem_cgroup allocations
The vmalloc was introduced by patch 333279 ("memcgroup: use vmalloc for
mem_cgroup allocation"), because at that time MAX_NUMNODES was used for
defining the per-node array in the mem_cgroup structure so that the
structure could be huge even if the system had the only NUMA node.
The situation was significantly improved by patch 45cf7e ("memcg: reduce
the size of struct memcg 244-fold"), which made the size of the
mem_cgroup structure calculated dynamically depending on the real number
of NUMA nodes installed on the system (nr_node_ids), so now there is no
point in using vmalloc here: the structure is allocated rarely and on
most systems its size is about 1K.
Personally I'd like to remove this vmalloc, because I'm considering
using wait_on_bit() on mem_cgroup::kmem_account_flags in the kmemcg
shrinkers implementation, which is impossible on vmalloc'd areas.
Signed-off-by: Vladimir Davydov
Cc: Michal Hocko
Cc: Glauber Costa
Cc: Johannes Weiner
Cc: Balbir Singh
Cc: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7f1a356..205eb7b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -48,7 +48,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -335,12 +334,6 @@ struct mem_cgroup {
/* WARNING: nodeinfo must be the last member here */
};
-static size_t memcg_size(void)
-{
- return sizeof(struct mem_cgroup) +
- nr_node_ids * sizeof(struct mem_cgroup_per_node *);
-}
-
/* internal only representation about the status of kmem accounting. */
enum {
KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */
@@ -6139,14 +6132,12 @@ static void free_mem_cgroup_per_zone_info(struct
mem_cgroup *memcg, int node)
static struct mem_cgroup *mem_cgroup_alloc(void)
{
struct mem_cgroup *memcg;
- size_t size = memcg_size();
+ size_t size;
- /* Can be very big if nr_node_ids is very big */
- if (size < PAGE_SIZE)
- memcg = kzalloc(size, GFP_KERNEL);
- else
- memcg = vzalloc(size);
+ size = sizeof(struct mem_cgroup);
+ size += nr_node_ids * sizeof(struct mem_cgroup_per_node *);
+ memcg = kzalloc(size, GFP_KERNEL);
if (!memcg)
return NULL;
@@ -6157,10 +6148,7 @@ static struct mem_cgroup *mem_cgroup_alloc(void)
return memcg;
out_free:
- if (size < PAGE_SIZE)
- kfree(memcg);
- else
- vfree(memcg);
+ kfree(memcg);
return NULL;
}
@@ -6178,7 +6166,6 @@ out_free:
static void __mem_cgroup_free(struct mem_cgroup *memcg)
{
int node;
- size_t size = memcg_size();
mem_cgroup_remove_from_trees(memcg);
@@ -6199,10 +6186,7 @@ static void __mem_cgroup_free(struct mem_cgroup *memcg)
* the cgroup_lock.
*/
disarm_static_keys(memcg);
- if (size < PAGE_SIZE)
- kfree(memcg);
- else
- vfree(memcg);
+ kfree(memcg);
}
/*
--
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 1/2] memcg: fix memcg_size() calculation
The mem_cgroup structure contains nr_node_ids pointers to
mem_cgroup_per_node objects, not the objects themselves.
Signed-off-by: Vladimir Davydov
Cc: Michal Hocko
Cc: Glauber Costa
Cc: Johannes Weiner
Cc: Balbir Singh
Cc: KAMEZAWA Hiroyuki
---
mm/memcontrol.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index bf5e894..7f1a356 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -338,7 +338,7 @@ struct mem_cgroup {
static size_t memcg_size(void)
{
return sizeof(struct mem_cgroup) +
- nr_node_ids * sizeof(struct mem_cgroup_per_node);
+ nr_node_ids * sizeof(struct mem_cgroup_per_node *);
}
/* internal only representation about the status of kmem accounting. */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/8] Documentation: dt: kona-timer: Add clocks property
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote:
> The frequency for the Kona timer can either be specified through the
> device tree or determined by checking the rate of the clock specified
> in the device tree. Update the documentation to reflect both ways.
>
> Signed-off-by: Tim Kryger
> Reviewed-by: Matt Porter
> ---
> Documentation/devicetree/bindings/arm/bcm/kona-timer.txt | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
> b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
> index 17d88b2..39adf54 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
> +++ b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
> @@ -8,13 +8,18 @@ Required properties:
> - DEPRECATED: compatible : "bcm,kona-timer"
> - reg : Register range for the timer
> - interrupts : interrupt for the timer
> +- clocks: phandle + clock specifier pair of the external clock
> - clock-frequency: frequency that the clock operates
>
> +Only one of clocks or clock-frequency should be specified.
> +
> +Refer to clocks/clock-bindings.txt for generic clock consumer properties.
> +
> Example:
> timer@35006000 {
> compatible = "brcm,kona-timer";
> reg = <0x35006000 0x1000>;
> interrupts = <0x0 7 0x4>;
> - clock-frequency = <32768>;
> + clocks = <&hub_timer_clk>;
> };
>
> --
> 1.8.0.1
>
Reviewed-by: Christian Daudt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] xfs: allow linkat() on O_TMPFILE files
On Sat, Dec 14, 2013 at 01:36:47AM +0800, Zhi Yong Wu wrote: > On Sat, Dec 14, 2013 at 12:41 AM, Christoph Hellwig > wrote: > > On Fri, Dec 13, 2013 at 10:27:53PM +0800, Zhi Yong Wu wrote: > >> From: Zhi Yong Wu > >> > >> Enable O_TMPFILE support in linkat(). > >> For more info, please refer to: > >> http://oss.sgi.com/archives/xfs/2013-08/msg00341.html > > > > Generall you should provide all reasonable information in the changelog > > instead of linking to it. > will apply this, thanks. > > > >> + if (sip->i_d.di_nlink == 0) > >> + tres = &M_RES(mp)->tr_link_tmpfile; > >> + else > >> + tres = &M_RES(mp)->tr_link; > > > > As mentioned before I think Dave wanted you to always use the same > > reservation, but I'll leave that discussion to him. > If as you said, when some tons of regular files are created, it won't > waste some disk space? e.g. some files want to reserve some space, but > get NOSPACE due to other files reserving additional space? This is a log space reservation, not a disk space reservation. End either way, what is unused by the transaction is returned to the free space pool at the end of the transaction. So for simplicity, we should just use the one reservation for the link transaction - take whichever is larger at calculation time. Cheers, Dave. -- Dave Chinner da...@fromorbit.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: XFS / writeback invoking soft lockup.
On Fri, Dec 13, 2013 at 11:22:28AM -0500, Dave Jones wrote: > On Fri, Dec 13, 2013 at 03:16:39AM -0800, Christoph Hellwig wrote: > > On Fri, Dec 13, 2013 at 09:48:53PM +1100, Dave Chinner wrote: > > > All I can say is that there doesn't look to be any obvious signs > > > that this is a XFS or writeback problem fom the stack trace, and > > > without more information or a reproducable test case I'm not going > > > to be able to understand the cause. > > > > > > Is the problem reproducable, or is it just a one-off? > > > > If it's reproducable it would be good to enable the xfs_writepage > > tracepoint and get a trace-cmd log of it. > > I hit it pretty reliably last night. I'll make a note to look into it > on monday with that enabled. You might want to grab the writeback tracepoints as well. Note that you'll probably have to filter by device so you don't get noise from all the other block devices, too. Cheers, Dave. -- Dave Chinner da...@fromorbit.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 v4 7/8] clocksource: kona: Add basic use of external clock
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote: > When an clock is specified in the device tree, enable it and use it to > determine the external clock frequency. > > Signed-off-by: Tim Kryger > Reviewed-by: Markus Mayer > Reviewed-by: Matt Porter > --- Reviewed-by: Christian Daudt Daniel, Are you ok with me pulling this patch in with the rest of the patchset into the bcm tree ? Thanks, csd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: vunmap() on large regions may trigger soft lockup warnings
On Thu, 12 Dec 2013 12:50:47 + David Vrabel wrote: > > each time. But that would require difficult tuning of N. > > > > I suppose we could just do > > > > if (!in_interrupt()) > > cond_resched(); > > > > in vunmap_pmd_range(), but that's pretty specific to ghes.c and doesn't > > permit unmap-inside-spinlock. > > > > So I can't immediately think of a suitable fix apart from adding a new > > unmap_kernel_range_atomic(). Then add a `bool atomic' arg to > > vunmap_page_range() and pass that all the way down. > > That would work for the unmap, but looking at the GHES driver some more > and it looks like it's call to ioremap_page_range() is already unsafe -- > it may need to allocate a new PTE page with a non-atomic alloc in > pte_alloc_one_kernel(). > > Perhaps what's needed here is a pair of ioremap_page_atomic() and > iounmap_page_atomic() calls? With some prep function to sure the PTE > pages (etc.) are preallocated. Is ghes.c the only problem source here? If so then a suitable solution would be to declare that driver hopelessly busted and proceed as if it didn't exist :( Just from a quick look, the thing is doing ioremap() from NMI context! ioremap has to do a bunch of memory allocations, takes spinlocks etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 13 December 2013 20:07, Guenter Roeck wrote: >> I got the impression from Guenter Roeck's review, that it doesn't belong >> there, >> maybe I was too quick to remove it? >> > You'd have to answer the questions I raised in my review if you want it in > there. I didn't see a solution at the time. Now I'm thinking arm_pm_restart can be set later in probe, preventing a crash on load failure, and maybe it can be unset on unload. Would you accept a patch for this? Best regards, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Replace /dev/random input mix polynomial with Brent's xorgen?
Richard Brent extended some efficient XOR-based PRNGs designed by George Marsaglia into a family of "xorgen" generators which are efficent, non-sparse, maximal-period polynomials of length 64, 128, 256,... 4096 bits. (It ends there because proving period 2^n-1 requires knowing the factorization of 2^n-1, and 2^8192-1 = (2^4096+1)*(2^2048+1)*...*(2^1+1). The factorization of 2^4096+1 = F_12 is currently stuck on an 1133-digit composite residue; see http://caramel.loria.fr/f12.txt) http://maths-people.anu.edu.au/~brent/pub/pub224.html "Some long-period random number generators using shifts and xors", Related background papers: http://www.jstatsoft.org/v08/i14/paper "Xorshift RNGs" http://maths-people.anu.edu.au/~brent/pub/pub218.html "Note on Marsaglia's xorshift RNGs" Anyway, the algorithm boils down to t1 = x[i-r];t2 = x[i-s]; t1 ^= t1 << a; t2 ^= t2 << c; t1 ^= t1 >> b; t2 ^= t2 >> d; x[i] = t1 ^ t2; For various constants r = 2..128, s < r, and shifts a, b, c and d. Both 32- and 64-bit versions are included. This is both more efficient and (especually using 64-bit words) more thorough than the current code, for sizes up to 4096 bits. Although the current code has tables for larger pools, everything larger than 32x128 = 4096 bits is currenty commented out and not used. Would you be interested in a patch to revise _mix_pool_bytes()? I'm also thinking of revising the input rotate-by-7 to use Marsaglia's original xorshift as a whitener. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376)
On Fri, Dec 13, 2013 at 05:07:54PM +0100, Radim Krčmář wrote:
> 2013-12-12 21:36+0100, Paolo Bonzini:
> > From: Gleb Natapov
> >
> > A guest can cause a BUG_ON() leading to a host kernel crash.
> > When the guest writes to the ICR to request an IPI, while in x2apic
> > mode the following things happen, the destination is read from
> > ICR2, which is a register that the guest can control.
> >
> > kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
> > cluster id. A BUG_ON is triggered, which is a protection against
> > accessing map->logical_map with an out-of-bounds access and manages
> > to avoid that anything really unsafe occurs.
> >
> > The logic in the code is correct from real HW point of view. The problem
> > is that KVM supports only one cluster with ID 0 in clustered mode, but
> > the code that has the bug does not take this into account.
>
> The more I read about x2apic, the more confused I am ...
>
> - How was the cluster x2apic enabled?
>
>Linux won't enable cluster x2apic without interrupt remapping and I
>had no idea we were allowed to do it.
>
Malicious code can do it.
> - A hardware test-suite found this?
>
>This bug can only be hit when the destination cpu is > 256, so the
>request itself is buggy -- we don't support that many in kvm and it
>would crash when initializing the vcpus if we did.
>=> It looks like we should just ignore the ipi, because we have no
> vcpus in that cluster.
>
That's the nature of malicious code: it does what your code does not expects
it to do :)
> - Where does the 'only one supported cluster' come from?
>
"only one supported cluster" comes from 8 bit cpuid limitation of KVM's x2apic
implementation. With 8 bit cpuid you can only address cluster 0 in logical mode.
>I only see we use 'struct kvm_lapic *logical_map[16][16];', which
>supports 16 clusters of 16 apics = first 256 vcpus, so if we map
>everything to logical_map[0][0:15], we would not work correctly in
>the cluster x2apic, with > 16 vcpus.
>
Such config cannot work today because of 8 bit cpuid limitation. When the
limitation
will be removed KMV_X2APIC_CID_BITS will be set to actual number of bits we
want to support.
It will likely be smaller then 16 bit though since full 18 bit support will
require huge tables.
> Thanks.
>
> > Reported-by: Lars Bull
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Gleb Natapov
> > Signed-off-by: Paolo Bonzini
> > ---
> > arch/x86/kvm/lapic.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index b8bec45c1610..801dc3fd66e1 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -143,6 +143,8 @@ static inline int kvm_apic_id(struct kvm_lapic *apic)
> > return (kvm_apic_get_reg(apic, APIC_ID) >> 24) & 0xff;
> > }
> >
> > +#define KMV_X2APIC_CID_BITS 0
> > +
> > static void recalculate_apic_map(struct kvm *kvm)
> > {
> > struct kvm_apic_map *new, *old = NULL;
> > @@ -180,7 +182,8 @@ static void recalculate_apic_map(struct kvm *kvm)
> > if (apic_x2apic_mode(apic)) {
> > new->ldr_bits = 32;
> > new->cid_shift = 16;
> > - new->cid_mask = new->lid_mask = 0x;
> > + new->cid_mask = (1 << KMV_X2APIC_CID_BITS) - 1;
> > + new->lid_mask = 0x;
> > } else if (kvm_apic_sw_enabled(apic) &&
> > !new->cid_mask /* flat mode */ &&
> > kvm_apic_get_reg(apic, APIC_DFR) ==
> > APIC_DFR_CLUSTER) {
> > --
> > 1.8.3.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/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] xfs: allow linkat() on O_TMPFILE files
On Sat, Dec 14, 2013 at 4:19 PM, Dave Chinner wrote: > On Sat, Dec 14, 2013 at 01:36:47AM +0800, Zhi Yong Wu wrote: >> On Sat, Dec 14, 2013 at 12:41 AM, Christoph Hellwig >> wrote: >> > On Fri, Dec 13, 2013 at 10:27:53PM +0800, Zhi Yong Wu wrote: >> >> From: Zhi Yong Wu >> >> >> >> Enable O_TMPFILE support in linkat(). >> >> For more info, please refer to: >> >> http://oss.sgi.com/archives/xfs/2013-08/msg00341.html >> > >> > Generall you should provide all reasonable information in the changelog >> > instead of linking to it. >> will apply this, thanks. >> > >> >> + if (sip->i_d.di_nlink == 0) >> >> + tres = &M_RES(mp)->tr_link_tmpfile; >> >> + else >> >> + tres = &M_RES(mp)->tr_link; >> > >> > As mentioned before I think Dave wanted you to always use the same >> > reservation, but I'll leave that discussion to him. >> If as you said, when some tons of regular files are created, it won't >> waste some disk space? e.g. some files want to reserve some space, but >> get NOSPACE due to other files reserving additional space? > > This is a log space reservation, not a disk space reservation. End > either way, what is unused by the transaction is returned to the > free space pool at the end of the transaction. So for simplicity, > we should just use the one reservation for the link transaction - > take whichever is larger at calculation time. Good explaination, thanks Dave and Christoph. By the way, can you help check if the log reservation for adding/removing one inode to/from unlinked list is correct? or will you check after i post next version out? > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376)
On Fri, Dec 13, 2013 at 06:25:20PM +0100, Paolo Bonzini wrote:
> Il 13/12/2013 17:07, Radim Krčmář ha scritto:
> >This bug can only be hit when the destination cpu is > 256, so the
> >request itself is buggy -- we don't support that many in kvm and it
> >would crash when initializing the vcpus if we did.
> >=> It looks like we should just ignore the ipi, because we have no
> > vcpus in that cluster.
>
> That's what should happen in physical mode. Something like this patch:
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 5439117d5c4c..1f8e9e1abd3b 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -613,9 +615,10 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm,
> struct kvm_lapic *src,
>
> if (irq->dest_mode == 0) { /* physical mode */
> if (irq->delivery_mode == APIC_DM_LOWEST ||
> - irq->dest_id == 0xff)
> + irq->dest_id == 0xff ||
> + (apic_x2apic_mode(src) && irq->dest_id > 0xff))
Here you fall back to slow path wich still uses irq->dest_id == 0xff as
broadcast test.
> goto out;
> - dst = &map->phys_map[irq->dest_id & 0xff];
> + dst = &map->phys_map[irq->dest_id];
> } else {
> u32 mda = irq->dest_id << (32 - map->ldr_bits);
>
>
> On top of this, the x2apic spec documents a "broadcast" destination ID that
> could be implemented as follows. But I have no idea if this is correct and
> how it differs from the usual broadcast shorthand:
>
> @@ -815,9 +818,11 @@ static void apic_send_ipi(struct kvm_lapic *apic)
I'd rather add kvm_apic_is_broadcast() function like that:
bool kvm_apic_is_broadcast(struct kvm_lapic *l, u32 dest)
{
return dest == (apic_x2apic_mode(l) ? 0x : 0xff);
}
and use everywhere instead of irq->dest_id == 0xff test.
> irq.level = icr_low & APIC_INT_ASSERT;
> irq.trig_mode = icr_low & APIC_INT_LEVELTRIG;
> irq.shorthand = icr_low & APIC_SHORT_MASK;
> - if (apic_x2apic_mode(apic))
> + if (apic_x2apic_mode(apic)) {
> irq.dest_id = icr_high;
> - else
> + if (icr_high == 0x)
> + irq.shorthand = APIC_DEST_ALLINC;
> + } else
> irq.dest_id = GET_APIC_DEST_FIELD(icr_high);
>
> trace_kvm_apic_ipi(icr_low, irq.dest_id);
>
>
> > - Where does the 'only one supported cluster' come from?
> >
> >I only see we use 'struct kvm_lapic *logical_map[16][16];', which
> >supports 16 clusters of 16 apics = first 256 vcpus, so if we map
> >everything to logical_map[0][0:15], we would not work correctly in
> >the cluster x2apic, with > 16 vcpus.
>
> I think you're right. Something like this would be a better fix:
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
See my answer to Radim. There is not point in maintaining cid mapping that
cannot be
addressed.
> index dec48bfaddb8..58745cbbb7e6 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -198,7 +198,7 @@ static void recalculate_apic_map(struct kvm *kvm)
> cid = apic_cluster_id(new, ldr);
> lid = apic_logical_id(new, ldr);
>
> - if (lid)
> + if (cid < ARRAY_SIZE(new->logical_map) && lid)
> new->logical_map[cid][ffs(lid) - 1] = apic;
> }
> out:
> @@ -621,9 +621,12 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm,
> struct kvm_lapic *src,
> dst = &map->phys_map[irq->dest_id & 0xff];
> } else {
> u32 mda = irq->dest_id << (32 - map->ldr_bits);
> + u32 cid = apic_cluster_id(map, mda);
>
> - dst = map->logical_map[apic_cluster_id(map, mda)];
> + if (cid >= ARRAY_SIZE(map->logical_map))
> + goto out;
>
> + dst = map->logical_map[cid];
> bitmap = apic_logical_id(map, mda);
>
> if (irq->delivery_mode == APIC_DM_LOWEST) {
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index c8b0d0d2da5c..5ccb71658894 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -152,8 +152,6 @@ static inline u16 apic_cluster_id(struct kvm_apic_map
> *map, u32 ldr)
> ldr >>= 32 - map->ldr_bits;
> cid = (ldr >> map->cid_shift) & map->cid_mask;
>
> - BUG_ON(cid >= ARRAY_SIZE(map->logical_map));
> -
> return cid;
> }
>
> playground:~/work/upstream/linux-2.6/arch/x86 pbonzini$ vi kvm/lapic.c
> playground:~/work/upstream/linux-2.6/arch/x86 pbonzini$ git diff !$
> git diff kvm/lapic.c
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index dec48bfaddb8..1005185972a9 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -143,8 +143,6 @@ static inline int kvm_apic_id(struct kvm_lapic *apic)
> return (kvm_apic_get_reg(apic, APIC_ID) >> 24) & 0xff;
> }
>
> -#define KVM_X2APIC_CID_BITS 0
> -
> static
[GIT PULL] RAS for 3.14
Hi guys, please queue for 3.14. Thanks. -- The following changes since commit dc1ccc48159d63eca5089e507c82c7d22ef60839: Linux 3.13-rc2 (2013-11-29 12:57:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/ras_for_3.14 for you to fetch changes up to 42139eb356e3384759ca143ae04d82376346eb4c: ACPI, eMCA: Combine eMCA/EDAC event reporting priority (2013-12-11 19:04:37 +0100) * Add the functionality to override error reporting agents as some machines are sporting a new extended error logging capability which, if done properly in the BIOS, makes a corresponding EDAC module redundant, from Gong Chen. * PCIe AER tracepoint severity levels fix, from Rui Wang. * Error path correction for the mce device init, from Levente Kurusa. Chen, Gong (3): EDAC: Add an edac_report parameter to EDAC EDAC, sb_edac: Modify H/W event reporting policy ACPI, eMCA: Combine eMCA/EDAC event reporting priority Levente Kurusa (1): x86, mce: Call put_device on device_register failure Rui Wang (1): PCI, AER: Fix severity usage in aer trace event Documentation/kernel-parameters.txt | 8 arch/x86/kernel/cpu/mcheck/mce.c| 4 +++- drivers/acpi/acpi_extlog.c | 18 -- drivers/edac/edac_stub.c| 19 +++ drivers/edac/sb_edac.c | 6 +- include/linux/edac.h| 28 include/trace/events/ras.h | 10 +- 7 files changed, 84 insertions(+), 9 deletions(-) -- 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 V6] ARM : unwinder : Prevent data abort due to stack overflow
>You could try adding some debug printks to see how the backtrace fails.
>You could also try adding a few hand-crafted assembler functions
>with appropriate code and unwind directives to trigger different kinds
>of backtrace failure. You might have to add a way to artificially limit
>sp_high to check the cases where you run out of stack in the middle of
>popping multiple registers.
I added a a printk statement
+ if (*vsp >= (unsigned long *)ctrl->sp_high) {
+ printk(KERN_ERR "Stack Overflow Detected, vsp = %lx",
+ (unsigned long)*vsp);
+ return -URC_FAILURE;
+ }
I ran a many test cases to try and get the above print in the dmesg log.
I tried the following things :
1) Calling unwind_backtrace from diffrenet locations in the kernel, I
added the unwind call
in some irq, fork, exit and some sysfs entries call.
2) I limited the value of sp_high in unwind_frame() itself, I tried
many values of sp_high,
varrying from (low + sizeof(ctrl.vrs)/4) to (low + 4*sizeof(ctrl.vrs)).
When running the above cases I was able to see the above printk quiet
a few times in dmesg log.
So, the error condition is being handled.
If you have some test cases for verifying the unwinder, please share
the same. They might help
in thorough testing of unwinder.
Regards
On Wed, Dec 11, 2013 at 3:10 PM, Anurag Aggarwal wrote:
>>You could try adding some debug printks to see how the backtrace fails.
>>You could also try adding a few hand-crafted assembler functions
>>with appropriate code and unwind directives to trigger different kinds
>>of backtrace failure. You might have to add a way to artificially limit
>>sp_high to check the cases where you run out of stack in the middle of
>>popping multiple registers.
>
> I added a a printk statement
> + if (*vsp >= (unsigned long *)ctrl->sp_high) {
> + printk(KERN_ERR "Stack Overflow Detected, vsp = %lx",
> + (unsigned long)*vsp);
> + return -URC_FAILURE;
> + }
>
> I ran a many test cases to try and get the above print in the dmesg log.
>
> I tried the following things :
>
> 1) Calling unwind_backtrace from diffrenet locations in the kernel, I added
> the unwind call
> in some irq, fork, exit and some sysfs entries call.
> 2) I limited the value of sp_high in unwind_frame() itself, I tried many
> values of sp_high,
> varrying from (low + sizeof(ctrl.vrs)/4) to (low + 4*sizeof(ctrl.vrs)).
>
> When running the above cases I was able to see the above printk quiet a few
> times in dmesg log.
>
> So, the error condition is being handled.
>
> If you have some test cases for verifying the unwinder, please share the
> same. They might help
> in thorough testing of unwinder.
>
>
>
> Regards
> Anurag
--
Anurag Aggarwal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3] ipv6: log autoconfiguration failures
On Fri, Dec 13, 2013 at 05:57:09PM -0500, David Miller wrote: > From: Denys Vlasenko > Date: Fri, 13 Dec 2013 16:45:47 +0100 > > > If ipv6 auto-configuration does not work, currently it's hard > > to track what's going on. This change adds log messages > > (at debug level) on every code path where ipv6 autoconf fails. > > > > v3: changed pr_debug's to pr_warn's. > > > > Signed-off-by: Denys Vlasenko > > I already made it clear I want to see statistics added instead of log > messages for this. Hmm... I gave this a bit more thought. I would go with counters, too. What if we add something like per interface softerror states. So that we e.g. can see that one protocol had an error on an interface and it needs attention of an administrator? E.g. 2: eth0: Would catch the eyes more quickly. If counters are implemented we could do that completly in user space and add that flag as soon as one of the observed counters are above 0 (and of course, iproute needs colors). What do you think? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86: mm: Change tlb_flushall_shift for IvyBridge
On 12/13/2013 09:43 PM, Ingo Molnar wrote: > > * Alex Shi wrote: > >> On 12/13/2013 09:02 AM, Alex Shi wrote: > You have not replied to this concern of mine: if my concern is valid > then that invalidates much of the current tunings. >>> The benefit from pretend flush range is not unconditional, since invlpg >>> also cost time. And different CPU has different invlpg/flush_all >>> execution time. >> >> TLB refill time is also different on different kind of cpu. >> >> BTW, >> A bewitching idea is till attracting me. >> https://lkml.org/lkml/2012/5/23/148 >> Even it was sentenced to death by HPA. >> https://lkml.org/lkml/2012/5/24/143 > > I don't think it was sentenced to death by HPA. What do the hardware > guys say, is this safe on current CPUs? This talking is fully public, no any other info I known. At that time, I tried core2, nhm, wsm, snd, ivb, all kinds of machine I can get. No issue found. And assuming a rebase patch is testing in Fengguang's testing system from last Friday, no bad news till now. Fengugang, x86-tlb branch on my github tree. > > If yes then as long as we only activate this optimization for known > models (and turn it off for unknown models) we should be pretty safe, > even if the hw guys (obviously) don't want to promise this > indefinitely for all Intel HT implementations in the future, right? Agree with you. > >> That is that just flush one of thread TLB is enough for SMT/HT, >> seems TLB is still shared in core on Intel CPU. This benefit is >> unconditional, and if my memory right, Kbuild testing can improve >> about 1~2% in average level. > > Oh, a 1-2% kbuild speedup is absolutely _massive_. Don't even think > about dropping this idea ... it needs to be explored. > > Alas, that for_each_cpu() loop is obviously disgusting, these values > should be precalculated into percpu variables and such. yes, pr-calcucatied variable would save much time. > >> So could you like to accept some ugly quirks to do this lazy TLB >> flush on known working CPU? > > it's not really 'lazy TLB flush' AFAICS but a genuine optimization: > only flush the TLB on the logical CPUs that need it, right? I.e. do > only one flush per pair of siblings. > >> Forgive me if it's stupid. > > I'd say measurable speedups that are safe are never ever stupid. Thanks a lot! > > And even the range-flush TLB optimization we are talking about here > could still be used IMO, just tone it down a bit and make it less > model dependent. > > Thanks, > > Ingo > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Guten Tag
Guten Tag, Mein Name ist Mr.SUN Zhijun, ich mit der Bank of China zu arbeiten. Ich brauche Ihre Unterstützung in Durchführung einer Transaktion bei $ 18,5 Millionen Dollar geschätzt, möchte ich Ihnen 30% der gesamten Mittel als Ausgleich für Ihre Unterstützung in dieser Transaktion. Ich werde Sie über die vollständige Transaktion benachrichtigt nach Eingang Ihrer Antwort, wenn interessiert, bitte senden Sie mir Ihren vollständigen detials als unten, um meine E-Mail aufgeführt: s_zhijun...@qq.com 1. Vollständiger Name 2.Private Telefonnummer 3.Current Wohnadresse Mit freundlichen Grüßen, Mr.SUN Zhijun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/23] mm/memblock: Add memblock memory allocation apis
Hello, Santosh.
On Fri, Dec 13, 2013 at 07:52:42PM -0500, Santosh Shilimkar wrote:
> >> +static void * __init memblock_virt_alloc_internal(
> >> + phys_addr_t size, phys_addr_t align,
> >> + phys_addr_t min_addr, phys_addr_t max_addr,
> >> + int nid)
> >> +{
> >> + phys_addr_t alloc;
> >> + void *ptr;
> >> +
> >> + if (nid == MAX_NUMNODES)
> >> + pr_warn("%s: usage of MAX_NUMNODES is depricated. Use
> >> NUMA_NO_NODE\n",
> >> + __func__);
> >
> > Why not use WARN_ONCE()? Also, shouldn't nid be set to NUMA_NO_NODE
> > here?
> >
> You want all the users using MAX_NUMNODES to know about it so that
> the wrong usage can be fixed. WARN_ONCE will hide that.
Well, it doesn't really help anyone to be printing multiple messages
without any info on who was the caller and if this thing is gonna be
in mainline triggering of the warning should be rare anyway. It's
more of a tool to gather one-off cases in the wild. WARN_ONCE()
usually is the better choice as otherwise the warnings can swamp the
machine and console output in certain cases.
> > ...
> >> + if (nid != NUMA_NO_NODE) {
> >
> > Otherwise, the above test is broken.
> >
> So the idea was just to warn the users and allow them to fix
> the code. Well we are just allowing the existing users of using
> either MAX_NUMNODES or NUMA_NO_NODE continue to work. Thats what
> we discussed, right ?
Huh? Yeah, sure. You're testing @nid against MAX_NUMNODES at the
beginning of the function. If it's MAX_NUMNODES, you print a warning
but nothing else, so the if() conditional above, which should succeed,
would fail. Am I missing sth here?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/slab.c: check pointer slabp before using it in alloc_slabmgmt()
> > On Tue, 10 Dec 2013, Ethan Zhao wrote: > > > > > No, stable 3.12.4 and 3.12.3 need this patch. 3.13RC doesn't > > > need it anymore. > > > > Hmmm.. Then this commit may have fixed it: > > Cross-threaded from [Re: Slab BUG with DEBUG_* options ] > > On 12/08/2013 10:00 AM, Meelis Roos wrote: > > ldata alloc change + your second slab patch + slab debug: hang on boot > > after > > console [tty0] enabled, bootconsole disabled > > (after that, I should see all the dmesg again on serial but I do not). > > Meelis, > > Please grab this patch below and see if it fixes your 'hang on boot' > with Christoph's other slab patch + slab debug. Tried it on top of 3.12 + second slab patch + ldata alloc change, and lsab debug conf. No change - still hangs on boot. -- Meelis Roos (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] xfs: factor prid related codes into xfs_get_initial_prid()
On 12/14 2013 00:32 AM, Christoph Hellwig wrote:
>> +static inline prid_t xfs_get_initial_prid(struct xfs_inode *dp)
>> +{
>> +if (dp->i_d.di_flags & XFS_DIFLAG_PROJINHERIT)
>> +return xfs_get_projid(dp);
>> +else
>> +return XFS_PROJID_DEFAULT;
>> +}
>
> You could skip the else here.
Except that, I'd suggest we move this helper to proper header file with
further refactoring in xfs_symlink(), and it could be a separate patch.
Thanks,
-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
Em Fri, 13 Dec 2013 22:19:39 +0100 Frederik Himpe escreveu: > [My excuses for multiposting, it seems gmane does not permit posting to all > the relevant lists] > > Since upgrading my system from Linux 3.12 to 3.12.3, my PCTV Systems > nanoStick T2 290e does not work anymore. > > This happens with 3.12.3: > > [3.778817] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 > 80 f4 f5 94 90 > [3.779741] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb > c2 e8 30 e9 03 > [3.780643] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec > f1 12 07 72 80 > [3.781562] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 > f5 64 09 60 03 > [3.782473] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 > 87 03 02 09 92 > [3.783406] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 > c2 c6 22 12 09 > [3.784314] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f > 02 c0 13 6b 10 > [3.785213] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 > 00 00 00 00 00 > [3.786140] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 > 00 00 00 00 00 > [3.787057] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 > 20 01 01 00 00 > [3.787970] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 > [3.788879] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 > 00 00 00 00 00 > [3.789790] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 38 32 > [3.790709] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 > 32 32 31 46 4b > [3.791625] em28174 #0: i2c eeprom 00e0: 4a 31 00 4f 53 49 30 30 33 30 38 > 44 30 31 31 30 > [3.792531] em28174 #0: i2c eeprom 00f0: 46 4b 4a 31 00 00 00 00 00 00 00 > 00 00 00 31 30 > [3.793444] em28174 #0: i2c eeprom 0100: ... (skipped) > [3.793502] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0xfcf432bb > [3.793559] em28174 #0: EEPROM info: > [3.793616] em28174 #0:microcode start address = 0x0004, boot > configuration = 0x01 > [3.804741] scsi 8:0:0:0: Direct-Access Generic Ultra HS-SD/MMC 1.82 > PQ: 0 ANSI: 0 > [3.805345] sd 8:0:0:0: Attached scsi generic sg3 type 0 > [3.818139] em28174 #0:No audio on board. > [3.818194] em28174 #0:500mA max power > [3.818247] em28174 #0:Table at offset 0x39, strings=0x1aa0, 0x14ba, > 0x1ace > [3.818318] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) > [3.818374] em28174 #0: v4l2 driver version 0.2.0 > [3.821522] sd 8:0:0:0: [sdc] Attached SCSI removable disk > [3.823606] em28174 #0: V4L2 video device registered as video0 > [3.823662] em28174 #0: dvb set to isoc mode. > [3.823972] usbcore: registered new interface driver em28xx > [3.844020] tda18271 1-0060: creating new instance > [3.868422] tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: > -19 > [3.868492] Error reading device ID @ 1-0060, bailing out. > [3.868548] tda18271_attach: [1-0060|M] error -5 on line 1285 > [3.868603] tda18271 1-0060: destroying instance > [3.868666] Em28xx: Initialized (Em28xx dvb Extension) extension > [3.894687] Registered IR keymap rc-pinnacle-pctv-hd > [3.894819] input: em28xx IR (em28174 #0) as > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.7/rc/rc0/input23 > [3.894979] rc0: em28xx IR (em28174 #0) as > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.7/rc/rc0 > [3.895570] Em28xx: Initialized (Em28xx Input Extension) extension > > I see the same problem reported here: > https://github.com/Hexxeh/rpi-firmware/issues/38 where it is mentioned > that this regression also appeared in 3.10 stable series recently. > > I noticed upstream commit 8393796dfa4cf5dffcceec464c7789bec3a2f471 > (media: dvb-frontends: Don't use dynamic static allocation) > entered both 3.10.22 (which is the first version introducing the > regression in 3.10 stable according to the linked bug), and 3.12.3. > This file contains stuff related to tda18271. Could this be the > culprit? > Well, for board EM28174_BOARD_PCTV_290E, it first attaches cxd2820r and then the tuner tda18271. I suspect that the issue is at cxd2820r. Could you please apply this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0db3fa2741ad8371c21b3a6785416a4afc0cc1d4 and see if it solves the issue? Thanks! Mauro -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] xfs: factor prid related codes into xfs_get_initial_prid()
On Sat, Dec 14, 2013 at 7:20 PM, Jeff Liu wrote:
> On 12/14 2013 00:32 AM, Christoph Hellwig wrote:
>>> +static inline prid_t xfs_get_initial_prid(struct xfs_inode *dp)
>>> +{
>>> +if (dp->i_d.di_flags & XFS_DIFLAG_PROJINHERIT)
>>> +return xfs_get_projid(dp);
>>> +else
>>> +return XFS_PROJID_DEFAULT;
>>> +}
>>
>> You could skip the else here.
> Except that, I'd suggest we move this helper to proper header file with
> further refactoring in xfs_symlink(), and it could be a separate patch.
Good point, will apply it, thanks.
>
> Thanks,
> -Jeff
--
Regards,
Zhi Yong Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MTD fixes for 3.13-rc
On Sat, Dec 14, 2013 at 6:03 AM, Brian Norris wrote: > On Fri, Dec 13, 2013 at 11:37:36AM -0800, Linus Torvalds wrote: >> I do note that your pgp key still has very few signatures, and none of >> them in my normal key ring. Any possibility that you might expand on >> your signatures a bit? > > I'll see what I can do. dwmw2 offered to sign, but we're not exactly on > the same continent AFAIK. I'll try to get out to another conference > sometime soon. Where are you located? Maybe one of us is near you: https://maps.google.com/maps/ms?ie=UTF&msa=0&msid=203700972965484840643.0004b223fd8be6d3e2d90 > Brian > > __ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- 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 v2 1/9] drivers: net: Remove unused function igb_get_eee_status_i354() in e1000_82575.c
This patch removes the function igb_get_eee_status_i354() in
e1000_82575.c because it is unused.
It thus eliminates the following warning in
ethernet/intel/igb/e1000_82575.c:
drivers/net/ethernet/intel/igb/e1000_82575.c:2591:5: warning: no previous
prototype for ‘igb_get_eee_status_i354’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 32 --
1 file changed, 32 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c
b/drivers/net/ethernet/intel/igb/e1000_82575.c
index 47c2d10..18e5200 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -2580,38 +2580,6 @@ out:
return ret_val;
}
-/**
- * igb_get_eee_status_i354 - Get EEE status
- * @hw: pointer to the HW structure
- * @status: EEE status
- *
- * Get EEE status by guessing based on whether Tx or Rx LPI indications have
- * been received.
- **/
-s32 igb_get_eee_status_i354(struct e1000_hw *hw, bool *status)
-{
- struct e1000_phy_info *phy = &hw->phy;
- s32 ret_val = 0;
- u16 phy_data;
-
- /* Check if EEE is supported on this device. */
- if ((hw->phy.media_type != e1000_media_type_copper) ||
- (phy->id != M88E1543_E_PHY_ID))
- goto out;
-
- ret_val = igb_read_xmdio_reg(hw, E1000_PCS_STATUS_ADDR_I354,
-E1000_PCS_STATUS_DEV_I354,
-&phy_data);
- if (ret_val)
- goto out;
-
- *status = phy_data & (E1000_PCS_STATUS_TX_LPI_RCVD |
- E1000_PCS_STATUS_RX_LPI_RCVD) ? true : false;
-
-out:
- return ret_val;
-}
-
static const u8 e1000_emc_temp_data[4] = {
E1000_EMC_INTERNAL_DATA,
E1000_EMC_DIODE1_DATA,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dma-buf: Implement test module
On Thu, Dec 12, 2013 at 06:04:13PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Dec 12, 2013 at 03:36:29PM +0100, Thierry Reding wrote:
> > This is a simple test module that can be used to allocate, export and
> > delete DMA-BUF objects. It can be used to test DMA-BUF sharing in
> > systems that lack a real second driver.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/base/Kconfig| 4 +
> > drivers/base/Makefile | 1 +
> > drivers/base/dma-buf-test.c | 308
> >
> > 3 files changed, 313 insertions(+)
> > create mode 100644 drivers/base/dma-buf-test.c
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index e373671652b0..bed2abb9491b 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -200,6 +200,10 @@ config DMA_SHARED_BUFFER
> > APIs extension; the file's descriptor can then be passed on to other
> > driver.
> >
> > +config DMA_BUF_TEST
> > + tristate "DMA-BUF test module"
> > + depends on DMA_SHARED_BUFFER
>
> We need some good documentation here.
I agree. The description should go into more details about what exactly
this is meant to address.
> > > +static struct miscdevice dmabuf_device = {
> > + .minor = 128,
>
> Why did you pick this minor? Why not just make it dynamic?
It seemed like minors are statically allocated for miscdevice and 128
seemed to be as good as any. The tentative plan was to go through the
official way of having one allocated as explained in the comment in
include/linux/miscdevice.h.
Reading that comment again, there's MISC_DYNAMIC_MINOR, which I guess
would be appropriate here. Chances are that if you want to test DMA-BUF
you'll have a reasonably modern userspace that will create the device
dynamically.
Alternatively I guess I could instead turn this into a more full-fledged
cdev and do the whole alloc_chrdev_region() dance. Although that will
only allocate the major dynamically.
I'm not aware of any function that just allocates a single major/minor
pair completely dynamically. Is there one that you could point me to?
Thierry
pgpi4HKLz_vIl.pgp
Description: PGP signature
Re: ARM,sdhci_esdhc_imx: INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
On Fri, Dec 13, 2013 at 11:14:25PM +0100, Philippe De Muyter wrote: > Hi Shawn, > > On Fri, Dec 13, 2013 at 09:34:32PM +0800, Shawn Guo wrote: > > Hi Philippe, > > > > On Thu, Dec 12, 2013 at 03:49:25PM +0100, Philippe De Muyter wrote: > > > Hello, > > > > > > I have just booted 3.13-rc3 on my i.MX6DL board, done nothing but watch > > > it start, and I have got this! > > > > There is a patch [1] from Fabio for this issue. > > > > Shawn > > > > [1] http://thread.gmane.org/gmane.linux.kernel.mmc/23786 > > > > > == > > > [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] > ... > > Thanks. That fixed the problem. Will that go to 3.13 final ? That's a question for Chris. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/9] drivers: net: Mark functions as static in qlcnic_io.c
This patch marks the function qlcnic_enable_tx_intr(),
qlcnic_83xx_enable_tx_intr() and qlcnic_83xx_disable_tx_intr() in
qlcnic_io.c as static because they are not used outside this file.
Thus, it also removes the following warnings in
ethernet/qlogic/qlcnic/qlcnic_io.c:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:130:13: warning: no previous
prototype for ‘qlcnic_enable_tx_intr’ [-Wmissing-prototypes]
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:147:13: warning: no previous
prototype for ‘qlcnic_83xx_enable_tx_intr’ [-Wmissing-prototypes]
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:153:13: warning: no previous
prototype for ‘qlcnic_83xx_disable_tx_intr’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 0149c94..ac7ffc5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -127,7 +127,7 @@
struct sk_buff *qlcnic_process_rxbuf(struct qlcnic_adapter *,
struct qlcnic_host_rds_ring *, u16, u16);
-inline void qlcnic_enable_tx_intr(struct qlcnic_adapter *adapter,
+static inline void qlcnic_enable_tx_intr(struct qlcnic_adapter *adapter,
struct qlcnic_host_tx_ring *tx_ring)
{
if (qlcnic_check_multi_tx(adapter) &&
@@ -144,13 +144,13 @@ static inline void qlcnic_disable_tx_int(struct
qlcnic_adapter *adapter,
writel(1, tx_ring->crb_intr_mask);
}
-inline void qlcnic_83xx_enable_tx_intr(struct qlcnic_adapter *adapter,
+static inline void qlcnic_83xx_enable_tx_intr(struct qlcnic_adapter *adapter,
struct qlcnic_host_tx_ring *tx_ring)
{
writel(0, tx_ring->crb_intr_mask);
}
-inline void qlcnic_83xx_disable_tx_intr(struct qlcnic_adapter *adapter,
+static inline void qlcnic_83xx_disable_tx_intr(struct qlcnic_adapter *adapter,
struct qlcnic_host_tx_ring *tx_ring)
{
writel(1, tx_ring->crb_intr_mask);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/9] drivers: net: Mark functions as static in qlcnic_83xx_hw.c
This patch marks the function qlcnic_83xx_clear_legacy_intr_mask(),
qlcnic_83xx_set_legacy_intr_mask() and
qlcnic_83xx_enable_legacy_msix_mbx_intr() in qlcnic_83xx_hw.c as static
because they are not used outside this file.
Thus, it also removes the following warnings
in ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c:318:13: warning: no
previous prototype for ‘qlcnic_83xx_clear_legacy_intr_mask’
[-Wmissing-prototypes]
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c:323:13: warning: no
previous prototype for ‘qlcnic_83xx_set_legacy_intr_mask’ [-Wmissing-prototypes]
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c:343:13: warning: no
previous prototype for ‘qlcnic_83xx_enable_legacy_msix_mbx_intr’
[-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c|6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
index b1cb0ff..d0c2cd4 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -315,12 +315,12 @@ int qlcnic_83xx_setup_intr(struct qlcnic_adapter *adapter)
return 0;
}
-inline void qlcnic_83xx_clear_legacy_intr_mask(struct qlcnic_adapter *adapter)
+static inline void qlcnic_83xx_clear_legacy_intr_mask(struct qlcnic_adapter
*adapter)
{
writel(0, adapter->tgt_mask_reg);
}
-inline void qlcnic_83xx_set_legacy_intr_mask(struct qlcnic_adapter *adapter)
+static inline void qlcnic_83xx_set_legacy_intr_mask(struct qlcnic_adapter
*adapter)
{
if (adapter->tgt_mask_reg)
writel(1, adapter->tgt_mask_reg);
@@ -340,7 +340,7 @@ void qlcnic_83xx_disable_intr(struct qlcnic_adapter
*adapter,
writel(1, sds_ring->crb_intr_mask);
}
-inline void qlcnic_83xx_enable_legacy_msix_mbx_intr(struct qlcnic_adapter
+static inline void qlcnic_83xx_enable_legacy_msix_mbx_intr(struct
qlcnic_adapter
*adapter)
{
u32 mask;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] EDAC fix for 3.13
Hi Linus, please pull this annoyance fix. Thanks. The following changes since commit dc1ccc48159d63eca5089e507c82c7d22ef60839: Linux 3.13-rc2 (2013-11-29 12:57:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_fixes_for_3.13 for you to fetch changes up to bd4b9683623d0d91e87cf22f09008c05f56d7483: sb_edac: Shut up compiler warning when EDAC_DEBUG is enabled (2013-11-30 12:26:36 +0100) Silence a compiler warning in sb_edac. Aristeu Rozanski (1): sb_edac: Shut up compiler warning when EDAC_DEBUG is enabled drivers/edac/sb_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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 4/9] drivers: net: Mark functions as static in stmmac_platform.c
This patch marks the function stmmac_pltfr_freeze() and
stmmac_pltfr_restore() in stmmac_platform.c as static because they are
not used outside this file.
Thus, it also removes the following warnings in
ethernet/stmicro/stmmac/stmmac_platform.c:
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:222:5: warning: no
previous prototype for ‘stmmac_pltfr_freeze’ [-Wmissing-prototypes]
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:236:5: warning: no
previous prototype for ‘stmmac_pltfr_restore’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 51c9069..38bd1f4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -219,7 +219,7 @@ static int stmmac_pltfr_resume(struct device *dev)
return stmmac_resume(ndev);
}
-int stmmac_pltfr_freeze(struct device *dev)
+static int stmmac_pltfr_freeze(struct device *dev)
{
int ret;
struct plat_stmmacenet_data *plat_dat = dev_get_platdata(dev);
@@ -233,7 +233,7 @@ int stmmac_pltfr_freeze(struct device *dev)
return ret;
}
-int stmmac_pltfr_restore(struct device *dev)
+static int stmmac_pltfr_restore(struct device *dev)
{
struct plat_stmmacenet_data *plat_dat = dev_get_platdata(dev);
struct net_device *ndev = dev_get_drvdata(dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv7 04/12] driver/core: populate devices in order for IOMMUs
On Thu, Dec 12, 2013 at 06:14:02PM -0800, Greg KH wrote: > On Thu, Dec 12, 2013 at 11:39:20AM +, Grant Likely wrote: > > On Thu, 12 Dec 2013 09:57:05 +0200, Hiroshi Doyu wrote: > > > IOMMU devices on the bus need to be poplulated first, then iommu > > > master devices are done later. > > > > > > With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify > > > whether a device can be an iommu msater or not. If a device can, we'll > > > defer to populate that device till an iommu device is populated. Then, > > > those deferred iommu master devices are populated and configured with > > > help of the already populated iommu device. > > > > > > Signed-off-by: Hiroshi Doyu > > > Cc: Greg Kroah-Hartman > > > --- > > > This is related to the following discussion: > > > [RFC PATCH] Documentation: devicetree: add description for generic bus > > > properties > > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/215042.html > > > > > > v6: > > > Spinned off only driver core part from: > > > [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs > > > > > > v5: > > > Use "iommus=" binding instread of arm,smmu's "#stream-id-cells". > > > > > > v4: > > > This is newly added, and the successor of the following RFC: > > > [RFC][PATCHv3+ 1/2] driver/core: Add of_iommu_attach() > > > > > > http://lists.linuxfoundation.org/pipermail/iommu/2013-November/006914.html > > > > > > Signed-off-by: Hiroshi Doyu > > > --- > > > drivers/base/dd.c | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > > > index 0605176..0605f52 100644 > > > --- a/drivers/base/dd.c > > > +++ b/drivers/base/dd.c > > > @@ -25,6 +25,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "base.h" > > > #include "power/power.h" > > > @@ -273,6 +274,10 @@ static int really_probe(struct device *dev, struct > > > device_driver *drv) > > > > > > dev->driver = drv; > > > > > > + ret = of_iommu_attach(dev); > > > + if (ret) > > > + goto probe_failed; > > > + > > > > As discussed before, I really don't think hooking in to dd.c is the > > right thing to do here, and certainly not as a device tree specific > > function. ACPI or PCI described devices may have the same constraints > > and those won't have DT descriptions. > > I agree, this shouldn't be in the driver core. Okay, so what would be an alternative? Grant's objection makes sense and we could easily just wrap the call to of_iommu_attach() within a generic iommu_attach() that could decide at runtime which exact implementation to call, depending on whether the device is DT, ACPI, PCI or whatnot. If we don't want something like that in the core either, then the only other alternative would be to call this from each driver. However given the desire to handle IOMMUs completely transparently for device drivers that would be missing the point. Perhaps moving this into platform_drv_probe() would be more acceptable? That's still somewhat core, but maybe suburban enough. Thierry pgp9sutj2omjq.pgp Description: PGP signature
[PATCH v2 5/9] drivers: net: Put prototype declaration for function sbni_probe() in sbni.c
This patch declares the prototype for the function sbni_probe() in file sbni.c.
Thus, it also removes the following warning in wan/sbni.c:
drivers/net/wan/sbni.c:224:12: warning: no previous prototype for ‘sbni_probe’
[-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
This revision fixes the following issues of the previous revision:
Incorrect fix
drivers/net/wan/sbni.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c
index 388ddf6..5061ffd 100644
--- a/drivers/net/wan/sbni.c
+++ b/drivers/net/wan/sbni.c
@@ -221,6 +221,7 @@ static void __init sbni_devsetup(struct net_device *dev)
dev->netdev_ops = &sbni_netdev_ops;
}
+int __init sbni_probe(int unit);
int __init sbni_probe(int unit)
{
struct net_device *dev;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/9] drivers: net: Mark functions as static in 3945-debug.c
This patch marks the function il3945_ucode_rx_stats_read(),
il3945_ucode_tx_stats_read() and il3945_ucode_general_stats_read() in
3945-debug.c as static because they are not used outside this file.
Thus, it also removes the following warnings in
wireless/iwlegacy/3945-debug.c:
drivers/net/wireless/iwlegacy/3945-debug.c:52:1: warning: no previous prototype
for ‘il3945_ucode_rx_stats_read’ [-Wmissing-prototypes]
drivers/net/wireless/iwlegacy/3945-debug.c:317:1: warning: no previous
prototype for ‘il3945_ucode_tx_stats_read’ [-Wmissing-prototypes]
drivers/net/wireless/iwlegacy/3945-debug.c:407:1: warning: no previous
prototype for ‘il3945_ucode_general_stats_read’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
drivers/net/wireless/iwlegacy/3945-debug.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/3945-debug.c
b/drivers/net/wireless/iwlegacy/3945-debug.c
index f767dd1..c1b4441 100644
--- a/drivers/net/wireless/iwlegacy/3945-debug.c
+++ b/drivers/net/wireless/iwlegacy/3945-debug.c
@@ -48,7 +48,7 @@ il3945_stats_flag(struct il_priv *il, char *buf, int bufsz)
return p;
}
-ssize_t
+static ssize_t
il3945_ucode_rx_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -313,7 +313,7 @@ il3945_ucode_rx_stats_read(struct file *file, char __user
*user_buf,
return ret;
}
-ssize_t
+static ssize_t
il3945_ucode_tx_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -403,7 +403,7 @@ il3945_ucode_tx_stats_read(struct file *file, char __user
*user_buf,
return ret;
}
-ssize_t
+static ssize_t
il3945_ucode_general_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/9] drivers: net: Mark functions as static in 4965-debug.c
This patch marks the function il4965_ucode_rx_stats_read(),
il4965_ucode_tx_stats_read() and il4965_ucode_general_stats_read() in
4965-debug.c as static because they are not used outside this file.
Thus, it also removes the following warnings in
wireless/iwlegacy/4965-debug.c:
drivers/net/wireless/iwlegacy/4965-debug.c:59:1: warning: no previous prototype
for ‘il4965_ucode_rx_stats_read’ [-Wmissing-prototypes]
drivers/net/wireless/iwlegacy/4965-debug.c:471:1: warning: no previous
prototype for ‘il4965_ucode_tx_stats_read’ [-Wmissing-prototypes]
drivers/net/wireless/iwlegacy/4965-debug.c:637:1: warning: no previous
prototype for ‘il4965_ucode_general_stats_read’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
drivers/net/wireless/iwlegacy/4965-debug.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-debug.c
b/drivers/net/wireless/iwlegacy/4965-debug.c
index c8153fc..e0597bf 100644
--- a/drivers/net/wireless/iwlegacy/4965-debug.c
+++ b/drivers/net/wireless/iwlegacy/4965-debug.c
@@ -55,7 +55,7 @@ il4965_stats_flag(struct il_priv *il, char *buf, int bufsz)
return p;
}
-ssize_t
+static ssize_t
il4965_ucode_rx_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -467,7 +467,7 @@ il4965_ucode_rx_stats_read(struct file *file, char __user
*user_buf,
return ret;
}
-ssize_t
+static ssize_t
il4965_ucode_tx_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -633,7 +633,7 @@ il4965_ucode_tx_stats_read(struct file *file, char __user
*user_buf,
return ret;
}
-ssize_t
+static ssize_t
il4965_ucode_general_stats_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] drivers: net: Remove unused function igb_get_eee_status_i354() in e1000_82575.c
On Sat, 2013-12-14 at 17:44 +0530, Rashika Kheria wrote: > This patch removes the function igb_get_eee_status_i354() in > e1000_82575.c because it is unused. > > It thus eliminates the following warning in > ethernet/intel/igb/e1000_82575.c: > drivers/net/ethernet/intel/igb/e1000_82575.c:2591:5: warning: no > previous prototype for > ‘igb_get_eee_status_i354’ [-Wmissing-prototypes] > > Signed-off-by: Rashika Kheria > Reviewed-by: Josh Triplett > --- > drivers/net/ethernet/intel/igb/e1000_82575.c | 32 > -- > 1 file changed, 32 deletions(-) Thanks Rashika, I have added the patch to my queue. signature.asc Description: This is a digitally signed message part
[PATCH v2 8/9] drivers: net: Mark functions as static in debug.c
This patch marks the function il_clear_traffic_stats() in debug.c as
static because they are not used outside this file.
Thus, it also removes the following warnings in
wireless/iwlegacy/debug.c:
drivers/net/wireless/iwlegacy/debug.c:35:1: warning: no previous prototype for
‘il_clear_traffic_stats’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
drivers/net/wireless/iwlegacy/debug.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/debug.c
b/drivers/net/wireless/iwlegacy/debug.c
index eff2650..b7e03dd 100644
--- a/drivers/net/wireless/iwlegacy/debug.c
+++ b/drivers/net/wireless/iwlegacy/debug.c
@@ -31,7 +31,7 @@
#include "common.h"
-void
+static void
il_clear_traffic_stats(struct il_priv *il)
{
memset(&il->tx_stats, 0, sizeof(struct traffic_stats));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] drivers: net: Mark function xenvif_count_frag_slots() as static in netback.c
This patch marks the function xenvif_count_frag_slots() in netback.c as
static because they are not used outside this file.
Thus, it also removes the following warning in xen-netback/netback.c:
drivers/net/xen-netback/netback.c:218:14: warning: no previous prototype for
‘xenvif_count_frag_slots’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
---
This revision fixes the following issues of the previous revision:
Change commit message subject
drivers/net/xen-netback/netback.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 64f0e0d..9e4f399 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -215,7 +215,7 @@ struct xenvif_count_slot_state {
bool head;
};
-unsigned int xenvif_count_frag_slots(struct xenvif *vif,
+static unsigned int xenvif_count_frag_slots(struct xenvif *vif,
unsigned long offset, unsigned long size,
struct xenvif_count_slot_state *state)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dma-buf: Implement test module
On Thu, Dec 12, 2013 at 06:02:58PM -0800, Greg Kroah-Hartman wrote: > On Thu, Dec 12, 2013 at 03:42:12PM +0100, Thierry Reding wrote: > > On Thu, Dec 12, 2013 at 03:36:29PM +0100, Thierry Reding wrote: > > > This is a simple test module that can be used to allocate, export and > > > delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > > > systems that lack a real second driver. > > > > > > Signed-off-by: Thierry Reding > > > --- > > > drivers/base/Kconfig| 4 + > > > drivers/base/Makefile | 1 + > > > drivers/base/dma-buf-test.c | 308 > > > > > > 3 files changed, 313 insertions(+) > > > create mode 100644 drivers/base/dma-buf-test.c > > > > And attached is a small test program that I've been using to test this > > new module. It can be built with: > > > > $ gcc -O2 -g -Wall -Werror -I/usr/include/libdrm -o dma-buf-test > > dma-buf-test.c -ldrm > > Please put this in the patch as well (scripts/tests/ ?) There is also samples/ which already contains various test programs of a similar nature. > Also fix up the uapi stuff for the ioctls. Will do. Thanks, Thierry pgpraHcwv6hpl.pgp Description: PGP signature
Re: [RFC] dma-buf: Implement test module
On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom > wrote: > > On 12/12/2013 03:36 PM, Thierry Reding wrote: > >> > >> This is a simple test module that can be used to allocate, export and > >> delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > >> systems that lack a real second driver. > >> > >> > > > > Looks nice. I wonder whether this could be extended to create a "streaming" > > dma-buf from a user space mapping. That could be used as a generic way to > > implement streaming (user) buffer objects, rather than to add explicit > > support for those in, for example, TTM. > > Atm there's no way to get gpus to unbind their dma-buf mappings, so > their essentially pinned forever from first use on. Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle returned by drmPrimeFDToHandle()? I mean that should drop the last reference on the GEM object and cause it to be cleaned up (which should include detaching the DMA-BUF). Thierry pgpKHV7Ka3fIF.pgp Description: PGP signature
Re: [RFC] dma-buf: Implement test module
On Thu, Dec 12, 2013 at 08:34:28PM +0100, Thomas Hellstrom wrote: > On 12/12/2013 03:36 PM, Thierry Reding wrote: > >This is a simple test module that can be used to allocate, export and > >delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > >systems that lack a real second driver. > > > > > > Looks nice. I wonder whether this could be extended to create a "streaming" > dma-buf from a user space mapping. That could be used as a generic way to > implement streaming (user) buffer objects, rather than to add explicit > support for those in, for example, TTM. I'm somewhat reluctant to beef this up needlessly to prevent it from being used for purposes other than testing. Thierry pgp0pzOLlzcuU.pgp Description: PGP signature
[PATCH 1/3] drivers: rapidio: Include appropriate header file in rio-access.c
This patch includes appropriate header file linux/rio_drv.h in rio-access.c because functions __rio_local_read_config_8, __rio_local_read_config_16, __rio_local_read_config_32, __rio_local_write_config_8, __rio_local_write_config_16, __rio_local_write_config_32, rio_mport_read_config_8, rio_mport_read_config_16, rio_mport_read_config_32, rio_mport_write_config_8, rio_mport_write_config_16, rio_mport_write_config_32 and rio_mport_send_doorbell have their prototype declaration in linux/rio_drv.h. Thus, it also eliminates the following warning in rio-access.c: drivers/rapidio/rio-access.c:79:1: warning: no previous prototype for ‘__rio_local_read_config_8’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:80:1: warning: no previous prototype for ‘__rio_local_read_config_16’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:81:1: warning: no previous prototype for ‘__rio_local_read_config_32’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:82:1: warning: no previous prototype for ‘__rio_local_write_config_8’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:83:1: warning: no previous prototype for ‘__rio_local_write_config_16’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:84:1: warning: no previous prototype for ‘__rio_local_write_config_32’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:139:1: warning: no previous prototype for ‘rio_mport_read_config_8’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:140:1: warning: no previous prototype for ‘rio_mport_read_config_16’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:141:1: warning: no previous prototype for ‘rio_mport_read_config_32’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:142:1: warning: no previous prototype for ‘rio_mport_write_config_8’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:143:1: warning: no previous prototype for ‘rio_mport_write_config_16’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:144:1: warning: no previous prototype for ‘rio_mport_write_config_32’ [-Wmissing-prototypes] drivers/rapidio/rio-access.c:163:5: warning: no previous prototype for ‘rio_mport_send_doorbell’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria --- drivers/rapidio/rio-access.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rapidio/rio-access.c b/drivers/rapidio/rio-access.c index a3824ba..5e6c7eb 100644 --- a/drivers/rapidio/rio-access.c +++ b/drivers/rapidio/rio-access.c @@ -11,6 +11,7 @@ */ #include +#include #include /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers: rapidio: Include appropriate header file in rio-driver.c
This patch includes the header file linux/rio_drv.h in rio-driver.c because functions rio_dev_get(), rio_dev_put(), rio_register_driver() and rio_unregister_driver() have their prototype declarations in linux/rio_drv.h. Thus, it also eliminates the following warnings in rio-driver.c: drivers/rapidio/rio-driver.c:57:17: warning: no previous prototype for ‘rio_dev_get’ [-Wmissing-prototypes] drivers/rapidio/rio-driver.c:74:6: warning: no previous prototype for ‘rio_dev_put’ [-Wmissing-prototypes] drivers/rapidio/rio-driver.c:143:5: warning: no previous prototype for ‘rio_register_driver’ [-Wmissing-prototypes] drivers/rapidio/rio-driver.c:162:6: warning: no previous prototype for ‘rio_unregister_driver’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria --- drivers/rapidio/rio-driver.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rapidio/rio-driver.c b/drivers/rapidio/rio-driver.c index c9ae692..df73419 100644 --- a/drivers/rapidio/rio-driver.c +++ b/drivers/rapidio/rio-driver.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include "rio.h" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drivers: rapidio: Remove unused function rio_remove_sysfs_dev_files() in rio-sysfs.c
This patch removes the function rio_remove_sysfs_dev_files() in
rio-sysfs.c because it is unused.
Thus, it also eliminates the following warning in rio-sysfs.c:
drivers/rapidio/rio-sysfs.c:295:6: warning: no previous prototype for
‘rio_remove_sysfs_dev_files’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/rapidio/rio-sysfs.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/rapidio/rio-sysfs.c b/drivers/rapidio/rio-sysfs.c
index e0221c6..8929b9e 100644
--- a/drivers/rapidio/rio-sysfs.c
+++ b/drivers/rapidio/rio-sysfs.c
@@ -286,22 +286,6 @@ int rio_create_sysfs_dev_files(struct rio_dev *rdev)
return err;
}
-/**
- * rio_remove_sysfs_dev_files - cleanup RIO specific sysfs files
- * @rdev: device whose entries we should free
- *
- * Cleanup when @rdev is removed from sysfs.
- */
-void rio_remove_sysfs_dev_files(struct rio_dev *rdev)
-{
- device_remove_bin_file(&rdev->dev, &rio_config_attr);
- if (rdev->pef & RIO_PEF_SWITCH) {
- device_remove_file(&rdev->dev, &dev_attr_routes);
- device_remove_file(&rdev->dev, &dev_attr_lnext);
- device_remove_file(&rdev->dev, &dev_attr_hopcount);
- }
-}
-
static ssize_t bus_scan_store(struct bus_type *bus, const char *buf,
size_t count)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] sched: remove cpu_load decay
On 12/14/2013 03:50 AM, bseg...@google.com wrote: > Alex Shi writes: > >> On 12/03/2013 06:26 PM, Peter Zijlstra wrote: >>> >>> Paul, can you guys have a look at this, last time around you have a >>> regression with this stuff, so it would be good to hear from you. >>> > > This appears to be neutral on our search benchmark. > Thanks for testing! -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: md: Mark the function btree_insert_fn() as static in btree.c
This patch marks the function btree_insert_fn() as static in
bcache/btree.c because it is not used outside this file.
Thus, it also eliminates the following warning in bcache/btree.c:
drivers/md/bcache/btree.c:2220:5: warning: no previous prototype for
‘btree_insert_fn’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/md/bcache/btree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 5e2765a..dc6e2be 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -2217,7 +2217,7 @@ struct btree_insert_op {
struct bkey *replace_key;
};
-int btree_insert_fn(struct btree_op *b_op, struct btree *b)
+static int btree_insert_fn(struct btree_op *b_op, struct btree *b)
{
struct btree_insert_op *op = container_of(b_op,
struct btree_insert_op, op);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dma-buf: Implement test module
On Sat, Dec 14, 2013 at 7:47 AM, Thomas Hellstrom wrote: > On 12/14/2013 01:37 PM, Thierry Reding wrote: >> >> On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: >>> >>> On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom >>> wrote: On 12/12/2013 03:36 PM, Thierry Reding wrote: > > This is a simple test module that can be used to allocate, export and > delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > systems that lack a real second driver. > > Looks nice. I wonder whether this could be extended to create a "streaming" dma-buf from a user space mapping. That could be used as a generic way to implement streaming (user) buffer objects, rather than to add explicit support for those in, for example, TTM. >>> >>> Atm there's no way to get gpus to unbind their dma-buf mappings, so >>> their essentially pinned forever from first use on. >> >> Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle >> returned by drmPrimeFDToHandle()? I mean that should drop the last >> reference on the GEM object and cause it to be cleaned up (which should >> include detaching the DMA-BUF). > > > Actually, while the GEM prime implementation appears to pin an exported > dma-buf on first attach, from the dma-buf documentation it seems sufficient > to pin it on map or cpu access. > > But what I assume Daniel is referring to is that there is no way for > exporters to tell importers to force unmap() the dma-buf, so that it can be > unpinned? yeah, or some way for importers to opportunistically keep around a mapping rather than map/unmap on each use.. maybe we need something shrinker-ish for dmabuf? BR, -R > Daniel, maybe you could elaborate a bit on this? > > Thomas > >> >> Thierry >> >> >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mfd: mc13xxx: Remove duplicate mc13xxx_get_flags() declaration
mc13xxx_get_flags() declaration given twice. This patch removes this duplicate. Signed-off-by: Alexander Shiyan --- include/linux/mfd/mc13xxx.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h index f1b13b3..a326c85 100644 --- a/include/linux/mfd/mc13xxx.h +++ b/include/linux/mfd/mc13xxx.h @@ -21,8 +21,6 @@ int mc13xxx_reg_write(struct mc13xxx *mc13xxx, unsigned int offset, u32 val); int mc13xxx_reg_rmw(struct mc13xxx *mc13xxx, unsigned int offset, u32 mask, u32 val); -int mc13xxx_get_flags(struct mc13xxx *mc13xxx); - int mc13xxx_irq_request(struct mc13xxx *mc13xxx, int irq, irq_handler_t handler, const char *name, void *dev); int mc13xxx_irq_request_nounmask(struct mc13xxx *mc13xxx, int irq, -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mfd: mc13xxx: Remove useless symbol MFD_MC13783
Symbol MFD_MC13783 always selected by MFD_MC13XXX, so no need to keep additional symbol. Signed-off-by: Alexander Shiyan --- drivers/input/misc/Kconfig| 2 +- drivers/input/touchscreen/Kconfig | 2 +- drivers/mfd/Kconfig | 4 drivers/regulator/Kconfig | 2 +- sound/soc/fsl/Kconfig | 2 +- 5 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 4ffc397..7904ab0 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -168,7 +168,7 @@ config INPUT_MAX8997_HAPTIC config INPUT_MC13783_PWRBUTTON tristate "MC13783 ON buttons" - depends on MFD_MC13783 + depends on MFD_MC13XXX help Support the ON buttons of MC13783 PMIC as an input device reporting power button status. diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 961d58d..07e9e82 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -717,7 +717,7 @@ config TOUCHSCREEN_USB_COMPOSITE config TOUCHSCREEN_MC13783 tristate "Freescale MC13783 touchscreen input driver" - depends on MFD_MC13783 + depends on MFD_MC13XXX help Say Y here if you have an Freescale MC13783 PMIC on your board and want to use its touchscreen diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 58ed055..49bb445 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -163,14 +163,10 @@ config MFD_DA9063 Additional drivers must be enabled in order to use the functionality of the device. -config MFD_MC13783 - tristate - config MFD_MC13XXX tristate depends on (SPI_MASTER || I2C) select MFD_CORE - select MFD_MC13783 help Enable support for the Freescale MC13783 and MC13892 PMICs. This driver provides common support for accessing the device, diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index ce785f4..db9ae6f 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -343,7 +343,7 @@ config REGULATOR_MC13XXX_CORE config REGULATOR_MC13783 tristate "Freescale MC13783 regulator driver" - depends on MFD_MC13783 + depends on MFD_MC13XXX select REGULATOR_MC13XXX_CORE help Say y here to support the regulators found on the Freescale MC13783 diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index b7ab71f..5b44c5c 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -206,7 +206,7 @@ config SND_SOC_IMX_SPDIF config SND_SOC_IMX_MC13783 tristate "SoC Audio support for I.MX boards with mc13783" - depends on MFD_MC13783 && ARM + depends on MFD_MC13XXX && ARM select SND_SOC_IMX_SSI select SND_SOC_IMX_AUDMUX select SND_SOC_MC13783 -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: memstick: Mark function memstick_debug_get_tpc_name() as static in r592.c
This patch marks the function memstick_debug_get_tpc_name() as static in
host/r592.c because it is not used outside this file.
Thus, it also eliminates the following warning in host/r592.c:
drivers/memstick/host/r592.c:50:13: warning: no previous prototype for
‘memstick_debug_get_tpc_name’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/memstick/host/r592.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
index 31727bf..1cd9307 100644
--- a/drivers/memstick/host/r592.c
+++ b/drivers/memstick/host/r592.c
@@ -47,7 +47,7 @@ static const char *tpc_names[] = {
* memstick_debug_get_tpc_name - debug helper that returns string for
* a TPC number
*/
-const char *memstick_debug_get_tpc_name(int tpc)
+static const char *memstick_debug_get_tpc_name(int tpc)
{
return tpc_names[tpc-1];
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mfd: mc13xxx: Simplify "probe" & "remove"
This patch simplifies "probe" and "remove" functions by moving
some initialization code in the driver core.
Signed-off-by: Alexander Shiyan
---
drivers/mfd/mc13xxx-core.c | 36 +---
drivers/mfd/mc13xxx-i2c.c | 18 --
drivers/mfd/mc13xxx-spi.c | 19 ++-
drivers/mfd/mc13xxx.h | 6 ++
4 files changed, 29 insertions(+), 50 deletions(-)
diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
index b0c7cb0..06e64b6 100644
--- a/drivers/mfd/mc13xxx-core.c
+++ b/drivers/mfd/mc13xxx-core.c
@@ -636,42 +636,36 @@ static inline int mc13xxx_probe_flags_dt(struct mc13xxx
*mc13xxx)
}
#endif
-int mc13xxx_common_init(struct mc13xxx *mc13xxx,
- struct mc13xxx_platform_data *pdata, int irq)
+int mc13xxx_common_init(struct device *dev)
{
+ struct mc13xxx_platform_data *pdata = dev_get_platdata(dev);
+ struct mc13xxx *mc13xxx = dev_get_drvdata(dev);
int ret;
u32 revision;
- mc13xxx_lock(mc13xxx);
+ mc13xxx->dev = dev;
ret = mc13xxx_reg_read(mc13xxx, MC13XXX_REVISION, &revision);
if (ret)
- goto err_revision;
+ return ret;
mc13xxx->variant->print_revision(mc13xxx, revision);
/* mask all irqs */
ret = mc13xxx_reg_write(mc13xxx, MC13XXX_IRQMASK0, 0x00ff);
if (ret)
- goto err_mask;
+ return ret;
ret = mc13xxx_reg_write(mc13xxx, MC13XXX_IRQMASK1, 0x00ff);
if (ret)
- goto err_mask;
+ return ret;
- ret = request_threaded_irq(irq, NULL, mc13xxx_irq_thread,
+ ret = request_threaded_irq(mc13xxx->irq, NULL, mc13xxx_irq_thread,
IRQF_ONESHOT | IRQF_TRIGGER_HIGH, "mc13xxx", mc13xxx);
-
- if (ret) {
-err_mask:
-err_revision:
- mc13xxx_unlock(mc13xxx);
+ if (ret)
return ret;
- }
-
- mc13xxx->irq = irq;
- mc13xxx_unlock(mc13xxx);
+ mutex_init(&mc13xxx->lock);
if (mc13xxx_probe_flags_dt(mc13xxx) < 0 && pdata)
mc13xxx->flags = pdata->flags;
@@ -707,13 +701,17 @@ err_revision:
}
EXPORT_SYMBOL_GPL(mc13xxx_common_init);
-void mc13xxx_common_cleanup(struct mc13xxx *mc13xxx)
+int mc13xxx_common_exit(struct device *dev)
{
+ struct mc13xxx *mc13xxx = dev_get_drvdata(dev);
+
free_irq(mc13xxx->irq, mc13xxx);
+ mfd_remove_devices(dev);
+ mutex_destroy(&mc13xxx->lock);
- mfd_remove_devices(mc13xxx->dev);
+ return 0;
}
-EXPORT_SYMBOL_GPL(mc13xxx_common_cleanup);
+EXPORT_SYMBOL_GPL(mc13xxx_common_exit);
MODULE_DESCRIPTION("Core driver for Freescale MC13XXX PMIC");
MODULE_AUTHOR("Uwe Kleine-Koenig ");
diff --git a/drivers/mfd/mc13xxx-i2c.c b/drivers/mfd/mc13xxx-i2c.c
index 898bd33..ae3addb 100644
--- a/drivers/mfd/mc13xxx-i2c.c
+++ b/drivers/mfd/mc13xxx-i2c.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -60,7 +59,6 @@ static int mc13xxx_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct mc13xxx *mc13xxx;
- struct mc13xxx_platform_data *pdata = dev_get_platdata(&client->dev);
int ret;
mc13xxx = devm_kzalloc(&client->dev, sizeof(*mc13xxx), GFP_KERNEL);
@@ -69,15 +67,13 @@ static int mc13xxx_i2c_probe(struct i2c_client *client,
dev_set_drvdata(&client->dev, mc13xxx);
- mc13xxx->dev = &client->dev;
- mutex_init(&mc13xxx->lock);
+ mc13xxx->irq = client->irq;
mc13xxx->regmap = devm_regmap_init_i2c(client,
&mc13xxx_regmap_i2c_config);
if (IS_ERR(mc13xxx->regmap)) {
ret = PTR_ERR(mc13xxx->regmap);
- dev_err(mc13xxx->dev, "Failed to initialize register map: %d\n",
- ret);
+ dev_err(&client->dev, "Failed to initialize regmap: %d\n", ret);
return ret;
}
@@ -89,18 +85,12 @@ static int mc13xxx_i2c_probe(struct i2c_client *client,
mc13xxx->variant = (void *)id->driver_data;
}
- ret = mc13xxx_common_init(mc13xxx, pdata, client->irq);
-
- return ret;
+ return mc13xxx_common_init(&client->dev);
}
static int mc13xxx_i2c_remove(struct i2c_client *client)
{
- struct mc13xxx *mc13xxx = dev_get_drvdata(&client->dev);
-
- mc13xxx_common_cleanup(mc13xxx);
-
- return 0;
+ return mc13xxx_common_exit(&client->dev);
}
static struct i2c_driver mc13xxx_i2c_driver = {
diff --git a/drivers/mfd/mc13xxx-spi.c b/drivers/mfd/mc13xxx-spi.c
index cbcc86d..38ab678 100644
--- a/drivers/mfd/mc13xxx-spi.c
+++ b/drivers/mfd/mc13xxx-spi.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -129,26 +128,24 @@ static struct regmap_bus regmap_mc13xxx_bus = {
static int mc13x
Re: [RFC] dma-buf: Implement test module
On 12/14/2013 01:37 PM, Thierry Reding wrote: On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom wrote: On 12/12/2013 03:36 PM, Thierry Reding wrote: This is a simple test module that can be used to allocate, export and delete DMA-BUF objects. It can be used to test DMA-BUF sharing in systems that lack a real second driver. Looks nice. I wonder whether this could be extended to create a "streaming" dma-buf from a user space mapping. That could be used as a generic way to implement streaming (user) buffer objects, rather than to add explicit support for those in, for example, TTM. Atm there's no way to get gpus to unbind their dma-buf mappings, so their essentially pinned forever from first use on. Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle returned by drmPrimeFDToHandle()? I mean that should drop the last reference on the GEM object and cause it to be cleaned up (which should include detaching the DMA-BUF). Actually, while the GEM prime implementation appears to pin an exported dma-buf on first attach, from the dma-buf documentation it seems sufficient to pin it on map or cpu access. But what I assume Daniel is referring to is that there is no way for exporters to tell importers to force unmap() the dma-buf, so that it can be unpinned? Daniel, maybe you could elaborate a bit on this? Thomas Thierry ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dma-buf: Implement test module
On 12/14/2013 02:02 PM, Rob Clark wrote: On Sat, Dec 14, 2013 at 7:47 AM, Thomas Hellstrom wrote: On 12/14/2013 01:37 PM, Thierry Reding wrote: On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom wrote: On 12/12/2013 03:36 PM, Thierry Reding wrote: This is a simple test module that can be used to allocate, export and delete DMA-BUF objects. It can be used to test DMA-BUF sharing in systems that lack a real second driver. Looks nice. I wonder whether this could be extended to create a "streaming" dma-buf from a user space mapping. That could be used as a generic way to implement streaming (user) buffer objects, rather than to add explicit support for those in, for example, TTM. Atm there's no way to get gpus to unbind their dma-buf mappings, so their essentially pinned forever from first use on. Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle returned by drmPrimeFDToHandle()? I mean that should drop the last reference on the GEM object and cause it to be cleaned up (which should include detaching the DMA-BUF). Actually, while the GEM prime implementation appears to pin an exported dma-buf on first attach, from the dma-buf documentation it seems sufficient to pin it on map or cpu access. But what I assume Daniel is referring to is that there is no way for exporters to tell importers to force unmap() the dma-buf, so that it can be unpinned? yeah, or some way for importers to opportunistically keep around a mapping rather than map/unmap on each use.. maybe we need something shrinker-ish for dmabuf? Yes, I think that's needed for both the memory-shortage case where we want to unpin, and I guess it would desirable for iommu space management as well. /Thomas BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: infiniband: Mark function _c4iw_write_mem_dma() as static in mem.c
This patch marks the function _c4iw_write_mem_dma() as static in
hw/cxgb4/mem.c because it is not used outside this file.
Thus, it also eliminates the following warning in hw/cxgb4/mem.c:
drivers/infiniband/hw/cxgb4/mem.c:176:5: warning: no previous prototype for
‘_c4iw_write_mem_dma’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/infiniband/hw/cxgb4/mem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c
b/drivers/infiniband/hw/cxgb4/mem.c
index 4cb8eb2..84e4500 100644
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -173,7 +173,7 @@ static int _c4iw_write_mem_inline(struct c4iw_rdev *rdev,
u32 addr, u32 len,
return ret;
}
-int _c4iw_write_mem_dma(struct c4iw_rdev *rdev, u32 addr, u32 len, void *data)
+static int _c4iw_write_mem_dma(struct c4iw_rdev *rdev, u32 addr, u32 len, void
*data)
{
u32 remain = len;
u32 dmalen;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: mmc: Mark the function sdhci_disable_irq_wakeups() as static in sdhci.c
This patch marks the function sdhci_disable_irq_wakeups() as static in
host/sdhci.c because it is not used outside this file.
Thus, it also eliminates the following warning in host/sdhci.c:
drivers/mmc/host/sdhci.c:2553:6: warning: no previous prototype for
‘sdhci_disable_irq_wakeups’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index bd8a098..8de50e8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2550,7 +2550,7 @@ void sdhci_enable_irq_wakeups(struct sdhci_host *host)
}
EXPORT_SYMBOL_GPL(sdhci_enable_irq_wakeups);
-void sdhci_disable_irq_wakeups(struct sdhci_host *host)
+static void sdhci_disable_irq_wakeups(struct sdhci_host *host)
{
u8 val;
u8 mask = SDHCI_WAKE_ON_INSERT | SDHCI_WAKE_ON_REMOVE
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] dmaengine: remove obsolete comment reference to dma_data_direction
On Wed, Dec 11, 2013 at 10:07 +0400, Alexander Popov wrote:
>
> enum dma_transfer_direction is currently used
> in struct dma_slave_config, so update the comment
>
> Signed-off-by: Alexander Popov
> ---
> include/linux/dmaengine.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 41cf0c3..bd6b882 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -305,9 +305,8 @@ enum dma_slave_buswidth {
> /**
> * struct dma_slave_config - dma slave channel runtime config
> * @direction: whether the data shall go in or out on this slave
> - * channel, right now. DMA_TO_DEVICE and DMA_FROM_DEVICE are
> - * legal values, DMA_BIDIRECTIONAL is not acceptable since we
> - * need to differentiate source and target addresses.
> + * channel, right now. DMA_MEM_TO_DEV and DMA_DEV_TO_MEM are
> + * legal values.
> * @src_addr: this is the physical address where DMA slave data
> * should be read (RX), if the source is memory this argument is
> * ignored.
While I agree with the change to the comment text, I'd put the
description of the patch differently.
You are not removing an obsolete reference, but you are fixing an
erroneous comment. It's not that dma_data_direction would have
become obsolete, instead it's that dma_slave_config was
documented wrongly. The previous comment used the wrong data
type for one of its members and thus discussed inappropriate
values out of the type's domain. Maybe "fix incorrect kerneldoc
for struct dma_slave_config" or something similar could be a
better title. Especially for those who read the log later and
neither have the patch nor its description at hand.
And you might improve the description's body. Something like
"the 'direction' member of 'struct dma_slave_config' is of data
type 'enum dma_transfer_direction', so update the 'struct
dma_slave_config' kerneldoc to refer to appropriate values" or
similar.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: pnp: Mark the function pnp_build_option() as static in resource.c
This patch marks the function pnp_build_option() as static in resource.c
because it is not used outside this file.
Thus, it also eliminates the following warning in resource.c:
drivers/pnp/resource.c:34:20: warning: no previous prototype for
‘pnp_build_option’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/pnp/resource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
index d95e101..bacddd1 100644
--- a/drivers/pnp/resource.c
+++ b/drivers/pnp/resource.c
@@ -31,7 +31,7 @@ static int pnp_reserve_mem[16] = {[0 ... 15] = -1 }; /*
reserve (don't use) some
* option registration
*/
-struct pnp_option *pnp_build_option(struct pnp_dev *dev, unsigned long type,
+static struct pnp_option *pnp_build_option(struct pnp_dev *dev, unsigned long
type,
unsigned int option_flags)
{
struct pnp_option *option;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] ARM: dts: Add missing clocks for exynos4412 dwmmc node
Hi Alex, On Saturday 14 of December 2013 13:21:30 Alex Ling wrote: > This patch adds "biu" and "ciu" clocks for exynos4412 dwmmc > node. Without this patch, dwmmc host driver will skip enabling the > two clocks and it will break dwmmc host function on exynos4412. > Tested on FriendlyARM TINY4412 board. > > Signed-off-by: Alex Ling > --- > Changes for v2: >- Fix patch description as Mark Rutland suggested > > arch/arm/boot/dts/exynos4412.dtsi |2 ++ > 1 file changed, 2 insertions(+) The patch is correct, but unfortunately it's not the only thing that is wrong with MSHC device tree node for Exynos4x12. Please refer to my series fixing DW-MSHC support on Exynos4x12 (and enabling it on TRATS2 board): http://www.spinics.net/lists/arm-kernel/msg293652.html Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: reset: Mark function as static in core.c
This patch marks the function of_reset_simple_xlate() and
devm_reset_control_put() as static in core.c because it is not used
outside this file.
Thus, it also eliminate the following warnings in core.c:
drivers/reset/core.c:46:5: warning: no previous prototype for
‘of_reset_simple_xlate’ [-Wmissing-prototypes]
drivers/reset/core.c:262:6: warning: no previous prototype for
‘devm_reset_control_put’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/reset/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..8604053 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -43,7 +43,7 @@ struct reset_control {
* This simple translation function should be used for reset controllers
* with 1:1 mapping, where reset lines can be indexed by number without gaps.
*/
-int of_reset_simple_xlate(struct reset_controller_dev *rcdev,
+static int of_reset_simple_xlate(struct reset_controller_dev *rcdev,
const struct of_phandle_args *reset_spec)
{
if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
@@ -259,7 +259,7 @@ static int devm_reset_control_match(struct device *dev,
void *res, void *data)
* This function will not need to be called normally, as devres will take
* care of freeing the resource.
*/
-void devm_reset_control_put(struct reset_control *rstc)
+static void devm_reset_control_put(struct reset_control *rstc)
{
int ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: bnx2x_sriov.c: Missing switch/case breaks?
> > > Hi Ariel. > > > > > > I wrote a little checkpatch script to look for missing > > > switch/case breaks. > > > > > > http://www.kernelhub.org/?msg=379933&p=2 > > > > > > There are _many_ instances of case blocks in sriov.c > > > that could be missing breaks as they use fall-throughs. > > > > > > It would be good if these are actually intended to be > > > fall-throughs to add a /* fall-through */ comment between > > > each case block. > > > > > Hi Joe, > > Hi Yuval. > > > The `vfop' part of the code contains a lot of usage of the > `bnx2x_vfop_finalize()', > > which either goto or return at the end of almost every case. > > "Normal" analysis tools/scripts fail to recognize them as valid case > breaks. > > > > Adding `fallthrough' comments would make little sense, as this is not the > real > > behavior; Perhaps we need some alternative comment? (something in the > line > > of `macro case break') > > No idea. It's certainly an ugly macro. > True. > This does have a fallthrough path though when > (rc == 0 && next == VFOP_VERIFY_PEND) so This is a very rare path - there's exactly one place in the bnx2x code Where `next == VFOP_VERIFY_PEND' (also notice this path prints an error, so this is obviously not the expected behaviour). > maybe there should be a break after most all > uses of this macro anyway. When next is Won't some static code analysis tools regard such `break' calls as unreachable code? > VFOP_VERIFY_PEND, then a "fall-through" comment > would be appropriate. > > cheers, Joe Thanks, Yuval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] sched: remove cpu_load decay
On 12/14/2013 04:03 AM, Peter Zijlstra wrote: > > > I had a quick peek at the actual patches. > > afaict we're now using weighted_cpuload() aka runnable_load_avg as the > ->cpu_load. Whatever happened to also using the blocked_avg? When enabling the sched_avg in load balance, I didn't find any positive testing result for several blocked_avg trying, just few regression. :( And since this patchset is almost clean up only, no blocked_load_avg trying again... > > I totally hate patch 4; it seems like a random hack to make up for the > lack of blocked_avg. Yes, this bias criteria seems a bit arbitrary. :) But, anyway even with blocked_load_avg, we still need to consider to bias to local cpu. like in a scenario, 2 cpus both has nearly zero blocked_load_avg. BTW, Paul, do you has new idea on blocked_load_avg using? -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: hv: Mark the function hv_synic_free_cpu() as static in hv.c
This patch marks the function hv_synic_free_cpu() as static in hv.c
because it is not used outside this file.
Thus, it also eliminates the following warning in hv.c:
drivers/hv/hv.c:304:6: warning: no previous prototype for ‘hv_synic_free_cpu’
[-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/hv/hv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index f0c5e07..bcb4950 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -301,7 +301,7 @@ err:
return -ENOMEM;
}
-void hv_synic_free_cpu(int cpu)
+static void hv_synic_free_cpu(int cpu)
{
kfree(hv_context.event_dpc[cpu]);
if (hv_context.synic_event_page[cpu])
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: input: Include appropriate header file in cyttsp_i2c_common.c
This patch includes appropriate header file cyttsp4_core.h in
touchscreen/cyttsp_i2c_common.c because functions
cyttsp_i2c_read_block_data() and cyttsp_i2c_write_block_data()
have their prototype declaration in cyttsp4_core.h.
Thus, it also eliminates the following warning in cyttsp_i2c_common.c:
drivers/input/touchscreen/cyttsp_i2c_common.c:34:5: warning: no previous
prototype for ‘cyttsp_i2c_read_block_data’ [-Wmissing-prototypes]
drivers/input/touchscreen/cyttsp_i2c_common.c:64:5: warning: no previous
prototype for ‘cyttsp_i2c_write_block_data’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/input/touchscreen/cyttsp_i2c_common.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/cyttsp_i2c_common.c
b/drivers/input/touchscreen/cyttsp_i2c_common.c
index 1d7b6f1..ccefa56 100644
--- a/drivers/input/touchscreen/cyttsp_i2c_common.c
+++ b/drivers/input/touchscreen/cyttsp_i2c_common.c
@@ -31,6 +31,8 @@
#include
#include
+#include "cyttsp4_core.h"
+
int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf,
u16 addr, u8 length, void *values)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: dca: Mark the function dca_common_get_tag() as static in dca-core.c
This patch marks the function dca_common_get_tag() as static in
dca-core.c because it is not used outside this file.
Thus, it also eliminates the following warning in dca-core.c:
drivers/dca/dca-core.c:273:4: warning: no previous prototype for
‘dca_common_get_tag’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/dca/dca-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dca/dca-core.c b/drivers/dca/dca-core.c
index 819dfda..9096e59 100644
--- a/drivers/dca/dca-core.c
+++ b/drivers/dca/dca-core.c
@@ -270,7 +270,7 @@ EXPORT_SYMBOL_GPL(dca_remove_requester);
* @dev - the device that wants dca service
* @cpu - the cpuid as returned by get_cpu()
*/
-u8 dca_common_get_tag(struct device *dev, int cpu)
+static u8 dca_common_get_tag(struct device *dev, int cpu)
{
struct dca_provider *dca;
u8 tag;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] smp: remove cpumask_ipi
After commit 9a46ad6 (smp: make smp_call_function_many() use logic
similar to smp_call_function_single()), cfd->cpumask is accessed only
in smp_call_function_many(). So there is no more need to copy it
into cfd->cpumask_ipi before putting csd into the list.
The cpumask_ipi field is obsolete and can be removed.
Signed-off-by: Roman Gushchin
---
kernel/smp.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index bd9f940..dfdce07 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -23,7 +23,6 @@ enum {
struct call_function_data {
struct call_single_data __percpu *csd;
cpumask_var_t cpumask;
- cpumask_var_t cpumask_ipi;
};
static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
@@ -47,14 +46,8 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
action, void *hcpu)
if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
cpu_to_node(cpu)))
return notifier_from_errno(-ENOMEM);
- if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
- cpu_to_node(cpu))) {
- free_cpumask_var(cfd->cpumask);
- return notifier_from_errno(-ENOMEM);
- }
cfd->csd = alloc_percpu(struct call_single_data);
if (!cfd->csd) {
- free_cpumask_var(cfd->cpumask_ipi);
free_cpumask_var(cfd->cpumask);
return notifier_from_errno(-ENOMEM);
}
@@ -67,7 +60,6 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action,
void *hcpu)
case CPU_DEAD:
case CPU_DEAD_FROZEN:
free_cpumask_var(cfd->cpumask);
- free_cpumask_var(cfd->cpumask_ipi);
free_percpu(cfd->csd);
break;
#endif
@@ -402,13 +394,6 @@ void smp_call_function_many(const struct cpumask *mask,
if (unlikely(!cpumask_weight(cfd->cpumask)))
return;
- /*
-* After we put an entry into the list, cfd->cpumask may be cleared
-* again when another CPU sends another IPI for a SMP function call, so
-* cfd->cpumask will be zero.
-*/
- cpumask_copy(cfd->cpumask_ipi, cfd->cpumask);
-
for_each_cpu(cpu, cfd->cpumask) {
struct call_single_data *csd = per_cpu_ptr(cfd->csd, cpu);
struct call_single_queue *dst =
@@ -425,7 +410,7 @@ void smp_call_function_many(const struct cpumask *mask,
}
/* Send a message to all CPUs in the map */
- arch_send_call_function_ipi_mask(cfd->cpumask_ipi);
+ arch_send_call_function_ipi_mask(cfd->cpumask);
if (wait) {
for_each_cpu(cpu, cfd->cpumask) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: char: Include appropriate header file in frontend.c
This patch includes appropriate header file compat_ioctl.h in agp/frontend.c because functions agp_find_mem_by_key(), agp_create_segment(), agp_find_private(), agp_free_memory_wrap(), agp_allocate_memory_wrap(), agp_find_client_by_pid(), agp_create_client(), agp_remove_client(), agpioc_acquire_wrap(), agpioc_release_wrap(), agpioc_setup_wrap(), agpioc_protect_wrap() and agpioc_deallocate_wrap() have their prototype declaration in compat_ioctl.h. Thus, it also eliminates the following warnings in agp/frontend.c: drivers/char/agp/frontend.c:48:20: warning: no previous prototype for ‘agp_find_mem_by_key’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:164:5: warning: no previous prototype for ‘agp_create_segment’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:216:26: warning: no previous prototype for ‘agp_find_private’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:271:6: warning: no previous prototype for ‘agp_free_memory_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:277:20: warning: no previous prototype for ‘agp_allocate_memory_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:489:20: warning: no previous prototype for ‘agp_find_client_by_pid’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:514:20: warning: no previous prototype for ‘agp_create_client’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:527:5: warning: no previous prototype for ‘agp_remove_client’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:750:5: warning: no previous prototype for ‘agpioc_acquire_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:793:5: warning: no previous prototype for ‘agpioc_release_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:800:5: warning: no previous prototype for ‘agpioc_setup_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:880:5: warning: no previous prototype for ‘agpioc_protect_wrap’ [-Wmissing-prototypes] drivers/char/agp/frontend.c:914:5: warning: no previous prototype for ‘agpioc_deallocate_wrap’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria --- drivers/char/agp/frontend.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c index 1b19239..79c8666 100644 --- a/drivers/char/agp/frontend.c +++ b/drivers/char/agp/frontend.c @@ -42,6 +42,7 @@ #include #include #include "agp.h" +#include "compat_ioctl.h" struct agp_front_data agp_fe; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] drivers: edac: Mark the function amd64_decode_bus_error() as static in amd64_edac.c
This patch marks the function amd64_decode_bus_error() as static in
amd64_edac.c because it is not used outside this file.
Thus, it also eliminates the following warning in amd64_edac.c:
drivers/edac/amd64_edac.c:2038:6: warning: no previous prototype for
‘amd64_decode_bus_error’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/edac/amd64_edac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index b53d0de..52b34ea 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2035,7 +2035,7 @@ static inline void __amd64_decode_bus_error(struct
mem_ctl_info *mci,
__log_bus_error(mci, &err, ecc_type);
}
-void amd64_decode_bus_error(int node_id, struct mce *m)
+static void amd64_decode_bus_error(int node_id, struct mce *m)
{
__amd64_decode_bus_error(mcis[node_id], m);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers: edac: Mark the function edac_create_debug_nodes() as static in edac_mc_sysfs.c
This patch marks the function edac_create_debug_nodes() as static in
edac_mc_sysfs.c because it is not used outside this file.
Thus, it also eliminates the following warning in edac_mc_sysfs.c:
drivers/edac/edac_mc_sysfs.c:917:5: warning: no previous prototype for
‘edac_create_debug_nodes’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/edac/edac_mc_sysfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9f7e0e60..51c0362 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -914,7 +914,7 @@ void __exit edac_debugfs_exit(void)
debugfs_remove(edac_debugfs);
}
-int edac_create_debug_nodes(struct mem_ctl_info *mci)
+static int edac_create_debug_nodes(struct mem_ctl_info *mci)
{
struct dentry *d, *parent;
char name[80];
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drivers: edac: Mark the function get_mci_for_node_id() as static in sb_edac.c
This patch marks the function get_mci_for_node_id() as static in
sb_edac.c because it is not used outside this file.
Thus, it also eliminates the following warning in sb_edac.c:
drivers/edac/sb_edac.c:918:22: warning: no previous prototype for
‘get_mci_for_node_id’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/edac/sb_edac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 8472405..a8845a3 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -915,7 +915,7 @@ static void get_memory_layout(const struct mem_ctl_info
*mci)
}
}
-struct mem_ctl_info *get_mci_for_node_id(u8 node_id)
+static struct mem_ctl_info *get_mci_for_node_id(u8 node_id)
{
struct sbridge_dev *sbridge_dev;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] drivers: ata: Mark the function ahci_init_interrupts() as static in ahci.c
This patch marks the function ahci_init_interrupts() as static in ahci.c
because it is not used outside this file.
Thus, it also eliminates the following warning in ahci.c:
drivers/ata/ahci.c:1099:5: warning: no previous prototype for
‘ahci_init_interrupts’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/ata/ahci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 14f1e95..4ab1d41 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1097,7 +1097,7 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
-int ahci_init_interrupts(struct pci_dev *pdev, struct ahci_host_priv *hpriv)
+static int ahci_init_interrupts(struct pci_dev *pdev, struct ahci_host_priv
*hpriv)
{
int rc;
unsigned int maxvec;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] drivers: ata: Mark the function as static in libahci.c
This patch marks the function ahci_port_intr() and
ahci_hw_port_interrupt() as static in libahci.c because they are not
used outside this file.
Thus, it also eliminates the following warnings in libahci.c:
drivers/ata/libahci.c:1767:6: warning: no previous prototype for
‘ahci_port_intr’ [-Wmissing-prototypes]
drivers/ata/libahci.c:1800:6: warning: no previous prototype for
‘ahci_hw_port_interrupt’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
---
drivers/ata/libahci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index c482f8c..36605ab 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1764,7 +1764,7 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
}
}
-void ahci_port_intr(struct ata_port *ap)
+static void ahci_port_intr(struct ata_port *ap)
{
void __iomem *port_mmio = ahci_port_base(ap);
u32 status;
@@ -1797,7 +1797,7 @@ irqreturn_t ahci_thread_fn(int irq, void *dev_instance)
}
EXPORT_SYMBOL_GPL(ahci_thread_fn);
-void ahci_hw_port_interrupt(struct ata_port *ap)
+static void ahci_hw_port_interrupt(struct ata_port *ap)
{
void __iomem *port_mmio = ahci_port_base(ap);
struct ahci_port_priv *pp = ap->private_data;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Add missing audio-related clocks to imx6 clock tree
On Fri, Dec 13, 2013 at 11:44:06PM +0800, Nicolin Chen wrote: > This series of patches appends some essential clocks of audio IP to the > current i.MX6 Series clock trees. > > Nicolin Chen (2): > ARM: imx6sl: Add missing pll4_audio_div to the clock tree > ARM: imx6sl: Add missing spba clock to clock tree Applied both, 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] ARM: imx6: Derive spdif clock from pll3_pfd3_454m
On Fri, Dec 13, 2013 at 11:37:52PM +0800, Nicolin Chen wrote: > SPDIF can derive a TX clock for playback from one of its clock sources -- > spdif root clock to match its supporting sample rates. So this patch set > the spdif root clock's parent to pll3_pfd3_454m since the pll3_pfd3_454m > can approximately meet its sample rate requirement. > > Signed-off-by: Nicolin Chen 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] drivers: reset: Mark function as static in core.c
On Sat, Dec 14, 2013 at 06:56:10PM +0530, Rashika Kheria wrote: > This patch marks the function of_reset_simple_xlate() and > devm_reset_control_put() as static in core.c because it is not used > outside this file. > > Thus, it also eliminate the following warnings in core.c: > drivers/reset/core.c:46:5: warning: no previous prototype for > ‘of_reset_simple_xlate’ [-Wmissing-prototypes] > drivers/reset/core.c:262:6: warning: no previous prototype for > ‘devm_reset_control_put’ [-Wmissing-prototypes] > These are EXPORT_SYMBOL_GPL() so that doesn't make sense. devm_reset_control_put() is not used at all and of_reset_simple_xlate() doesn't look like it needs to be exported. Philipp? regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86: mm: Change tlb_flushall_shift for IvyBridge
On Fri, Dec 13, 2013 at 10:11:05AM +0800, Alex Shi wrote: > BTW, > A bewitching idea is till attracting me. > https://lkml.org/lkml/2012/5/23/148 > Even it was sentenced to death by HPA. > https://lkml.org/lkml/2012/5/24/143 > > That is that just flush one of thread TLB is enough for SMT/HT, seems > TLB is still shared in core on Intel CPU. This benefit is unconditional, > and if my memory right, Kbuild testing can improve about 1~2% in average > level. > > So could you like to accept some ugly quirks to do this lazy TLB flush > on known working CPU? > Forgive me if it's stupid. I think there's a further problem with that patch -- aside of it being right from a hardware point of view. We currently rely on the tlb flush IPI to synchronize with lockless page table walkers like gup_fast(). By not sending an IPI to all CPUs you can get into trouble and crash the kernel. We absolutely must keep sending the IPI to all relevant CPUs, we can choose not to actually do the flush on some CPUs, but we must keep sending the IPI. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86: mm: Change tlb_flushall_shift for IvyBridge
On Sat, Dec 14, 2013 at 03:19:02PM +0100, Peter Zijlstra wrote: > On Fri, Dec 13, 2013 at 10:11:05AM +0800, Alex Shi wrote: > > BTW, > > A bewitching idea is till attracting me. > > https://lkml.org/lkml/2012/5/23/148 > > Even it was sentenced to death by HPA. > > https://lkml.org/lkml/2012/5/24/143 > > > > That is that just flush one of thread TLB is enough for SMT/HT, seems > > TLB is still shared in core on Intel CPU. This benefit is unconditional, > > and if my memory right, Kbuild testing can improve about 1~2% in average > > level. > > > > So could you like to accept some ugly quirks to do this lazy TLB flush > > on known working CPU? > > Forgive me if it's stupid. > > I think there's a further problem with that patch -- aside of it being > right from a hardware point of view. > > We currently rely on the tlb flush IPI to synchronize with lockless page > table walkers like gup_fast(). > > By not sending an IPI to all CPUs you can get into trouble and crash the > kernel. > > We absolutely must keep sending the IPI to all relevant CPUs, we can > choose not to actually do the flush on some CPUs, but we must keep > sending the IPI. The alternative is switching x86 over to use HAVE_RCU_TABLE_FREE. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv7 04/12] driver/core: populate devices in order for IOMMUs
Thierry Reding wrote @ Sat, 14 Dec 2013 13:24:22 +0100: > * PGP Signed by an unknown key > > On Thu, Dec 12, 2013 at 06:14:02PM -0800, Greg KH wrote: > > On Thu, Dec 12, 2013 at 11:39:20AM +, Grant Likely wrote: > > > On Thu, 12 Dec 2013 09:57:05 +0200, Hiroshi Doyu wrote: > > > > IOMMU devices on the bus need to be poplulated first, then iommu > > > > master devices are done later. > > > > > > > > With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify > > > > whether a device can be an iommu msater or not. If a device can, we'll > > > > defer to populate that device till an iommu device is populated. Then, > > > > those deferred iommu master devices are populated and configured with > > > > help of the already populated iommu device. > > > > > > > > Signed-off-by: Hiroshi Doyu > > > > Cc: Greg Kroah-Hartman > > > > --- > > > > This is related to the following discussion: > > > > [RFC PATCH] Documentation: devicetree: add description for generic > > > > bus properties > > > > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/215042.html > > > > > > > > v6: > > > > Spinned off only driver core part from: > > > > [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs > > > > > > > > v5: > > > > Use "iommus=" binding instread of arm,smmu's "#stream-id-cells". > > > > > > > > v4: > > > > This is newly added, and the successor of the following RFC: > > > > [RFC][PATCHv3+ 1/2] driver/core: Add of_iommu_attach() > > > > > > > > http://lists.linuxfoundation.org/pipermail/iommu/2013-November/006914.html > > > > > > > > Signed-off-by: Hiroshi Doyu > > > > --- > > > > drivers/base/dd.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > > > > index 0605176..0605f52 100644 > > > > --- a/drivers/base/dd.c > > > > +++ b/drivers/base/dd.c > > > > @@ -25,6 +25,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > > > > > #include "base.h" > > > > #include "power/power.h" > > > > @@ -273,6 +274,10 @@ static int really_probe(struct device *dev, struct > > > > device_driver *drv) > > > > > > > > dev->driver = drv; > > > > > > > > + ret = of_iommu_attach(dev); > > > > + if (ret) > > > > + goto probe_failed; > > > > + > > > > > > As discussed before, I really don't think hooking in to dd.c is the > > > right thing to do here, and certainly not as a device tree specific > > > function. ACPI or PCI described devices may have the same constraints > > > and those won't have DT descriptions. > > > > I agree, this shouldn't be in the driver core. > > Okay, so what would be an alternative? Grant's objection makes sense and > we could easily just wrap the call to of_iommu_attach() within a generic > iommu_attach() that could decide at runtime which exact implementation > to call, depending on whether the device is DT, ACPI, PCI or whatnot. > > If we don't want something like that in the core either, then the only > other alternative would be to call this from each driver. However given > the desire to handle IOMMUs completely transparently for device drivers > that would be missing the point. What about using "bus_notifier" to send -EPROBE_DEFER? The current bus_notifier framework doesn't have the ability to defer the probe, but I may think that this change is acceptable relatively. The fundamental problem is that IOMMU doesn't follow the exact bus model like "chained IOMMU" cases, but this discussion may take long to be solved. I think that "bus_notifier" with send -EPROBE_DEFER would cover most of the normal cases, like normal IOMMU device probe population order. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MAINTAINERS: add myself as gpt maintainer
On Fri, 13 Dec, at 10:05:29AM, Davidlohr Bueso wrote: > From: Davidlohr Bueso > > Add a new entry for the GPT standard. Any future changes will now be routed > through linux-efi. > > Cc: Andrew Morton > Cc: Matt Fleming > Cc: Jens Axboe > Cc: Matt Domsch > Signed-off-by: Davidlohr Bueso > --- > This was discussed offline and both Matts are fine with me maintaining this. > > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4afcfb4..cf41aa5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3834,6 +3834,12 @@ T: git git://linuxtv.org/media_tree.git > S: Maintained > F: drivers/media/usb/gspca/ > > +GUID PARTITION TABLE (GPT) > +M: Davidlohr Bueso > +L: linux-...@vger.kernel.org > +S: Maintained > +F: block/partitions/efi.* > + Acked-by: Matt Fleming I'm happy to take this through the EFI tree unless Andrew or Jens wants to take it? -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()
On Fri, Dec 6, 2013 at 9:47 AM, Oleg Nesterov wrote: > On 12/05, Paul Moore wrote: >> On Thursday, December 05, 2013 05:59:53 PM Oleg Nesterov wrote: >> > >> > Note: perhaps we should simply kill ptrace_parent(), it buys >> > almost nothing and it is obviously racy. Or perhaps we should >> > change it to ensure it can't wrongly return the natural parent >> > if it races with ptrace_detach. >> >> Can you elaborate on "kill ptrace_parent()"? If the process is being traced >> we do need to fetch the tracer's task_struct for use in the SELinux access >> check at this bottom of the diff below. If you have something better in mind >> than ptrace_parent() it would be helpful to share that ... > > Sorry for confusion. > > I meant that the code like > > tracer = ptrace_parent(p); > if (tracer) > do_something(tracer); > > doesn't look better than just > > if (p->ptrace) > do_something(p->parent); > > but this is subjective of course. First, my apologizes for such a late reply, I got stuck working on some other bugs and this fell on the back burner for a bit. I understand your point, but I still think there is some value in keeping the call to ptrace_parent() rather than fetching the ptrace pointer on our own. Not only does it insulate the SELinux code from any future changes in the task_struct (unlikely, but still ...) it also helps act as a warning if something significant changes, e.g. ptrace_parent() goes away for some reason. As you say, it's largely subjective, but I still see some objective value in sticking with the ptrace_parent() call for the time being. However, that said, I think we should try and do something about the "suspicious RCU usage" you mentioned in your original posting. Adding the RCU read locks as you do in your patch seems reasonable to me, but I'm curious about the removal of the task lock; shouldn't week keep the task lock in place? > And perhaps I am wrong. Because otoh the usage of ->ptrace should be > avoided outside of the core kernel code. Not to muddy things up, but one could argue that this particular LSM/SELinux hook should be regarded as part of the "core" kernel code. However, I'm not sure that the distinction is really important here. > Mostly it annoys me because it is racy, without tasklist_lock it can > return ->real_parent (which never traced its child) if it races with > attach or detach, and I do not see a simple fix. Neither do I, and I'm fairly certain I haven't looked at this as long as others have. -- 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 4/4] w1: call put_device if device_register fails
Hi 13.12.2013, 23:23, "Levente Kurusa" : > Currently, memsetting and kfreeing the device is bad behaviour. > The device will have a reference count of 1 and hence can cause trouble > because it has kfree'd. Proper way to handle a failed device_register > is to call put_device right after it fails. Looks good to me, thank you Greg, please pull it into your treee > Signed-off-by: Levente Kurusa Acked-by: Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 12/14/2013 12:32 AM, Jonas Jensen wrote: On 13 December 2013 20:07, Guenter Roeck wrote: I got the impression from Guenter Roeck's review, that it doesn't belong there, maybe I was too quick to remove it? You'd have to answer the questions I raised in my review if you want it in there. I didn't see a solution at the time. Now I'm thinking arm_pm_restart can be set later in probe, preventing a crash on load failure, and maybe it can be unset on unload. Would you accept a patch for this? The above would at least avoid the crash, though I would not understand the point of having an unloadable restart handler. Forcing the watchdog driver into the kernel just because you want the restart handler in it would seem odd. And if the restart handler is optional, why have it in the first place ? I also don't follow Arnd's logic of wanting to have the code in the watchdog driver just because it happens to use a register that it needs. Conceptually it might be cleaner to write a separate driver, for example in drivers/power/restart, than plugging the functionality into the watchdog driver, at least if you don't want it in architecture or platform code. The xgene restart driver is a good example. Anyway, it is not up to me to accept the code, that is up to Wim. My rejection was primarily due to technical flaws, which can be addressed. For the logical reasoning you'll have to convince Wim. 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: [PATCHv6+ 01/13] of: introduce of_property_for_earch_phandle_with_args()
Hiroshi Doyu wrote @ Thu, 12 Dec 2013 14:14:04 +0200 (EET):
> > > From 8f7c0404aa68f0e8dbe0babc240590f6528ecc1f Mon Sep 17 00:00:00 2001
> > > From: Hiroshi Doyu
> > > Date: Fri, 15 Nov 2013 10:52:53 +0200
> > > Subject: [PATCH] of: introduce of_property_for_each_phandle_with_args()
> > >
> > > Iterating over a property containing a list of phandles with arguments
> > > is a common operation for device drivers. This patch adds a new
> > > of_property_for_each_phandle_with_args() macro to make the iteration
> > > simpler.
> > >
> > > Signed-off-by: Hiroshi Doyu
> > > Cc: Rob Herring
> > > ---
> > > drivers/of/base.c | 46 ++
> > > include/linux/of.h | 32
> > > 2 files changed, 78 insertions(+)
> > >
> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > > index f807d0e..cd4ab05 100644
> > > --- a/drivers/of/base.c
> > > +++ b/drivers/of/base.c
> > > @@ -1201,6 +1201,52 @@ void of_print_phandle_args(const char *msg, const
> > > struct of_phandle_args *args)
> > > printk("\n");
> > > }
> > >
> > > +const __be32 *of_phandle_iter_next(const char *cells_name, int
> > > cell_count,
> > > +const __be32 *cur, const __be32 *end,
> > > +struct of_phandle_args *out_args)
> >
> > Having to pass in cells_name, cell_count, cur and end each time seems a
> > little odd. Can a state structure be used instead?
> >
> > struct of_phandle_iter_state {
> > const char *cells_name;
> > int cells_count;
> > const __be32 *cur;
> > const __be32 *end;
> > struct of_phandle_args out_args;
> > }
> >
> > Make the caller provide one of those and fill it in with the init
> > function.
>
> I rewrote this a few times and so now I have a few version of this
> implementations :-) The above proposal is similar to the version v6+++
> mentioned in the above patch note:
>
> > > v6+++:
> > > Introduced a new struct "of_phandle_iter" to keep the state when
> > > iterating over the list.
>
> which is:
>
> [RFC][PATCHv6+++ 01/13] of: introduce
> of_property_for_earch_phandle_with_args()
> http://lists.linuxfoundation.org/pipermail/iommu/2013-November/007087.html
>
> Stephen seemed to prefer the version without state struct. I like the
> idea to not pass the same arguments repeatly. Instead, wrapping them
> in a struct with state may look better.
>
> So if Stephen agrees, I'll rewrite the version with state struct
> again.
Stephen, let me know what you think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma-buf: Implement test module
On Sat, Dec 14, 2013 at 1:37 PM, Thierry Reding wrote: > On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: >> On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom >> wrote: >> > On 12/12/2013 03:36 PM, Thierry Reding wrote: >> >> >> >> This is a simple test module that can be used to allocate, export and >> >> delete DMA-BUF objects. It can be used to test DMA-BUF sharing in >> >> systems that lack a real second driver. >> >> >> >> >> > >> > Looks nice. I wonder whether this could be extended to create a "streaming" >> > dma-buf from a user space mapping. That could be used as a generic way to >> > implement streaming (user) buffer objects, rather than to add explicit >> > support for those in, for example, TTM. >> >> Atm there's no way to get gpus to unbind their dma-buf mappings, so >> their essentially pinned forever from first use on. > > Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle > returned by drmPrimeFDToHandle()? I mean that should drop the last > reference on the GEM object and cause it to be cleaned up (which should > include detaching the DMA-BUF). Yeah, but that has the side-effect of also dropping the reference. And requires an explicit action from userspace. The entire point of kernel buffer managers is that this is all done transparently in the kernel and when low on memory some objects get swapped out behind userspaces back (and then pulled in again if needed). -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/
Guten Tag
Guten Tag, Mein Name ist Mr.SUN Zhijun, ich mit der Bank of China zu arbeiten. Ich brauche Ihre Unterstützung in Durchführung einer Transaktion bei $ 18,5 Millionen Dollar geschätzt, möchte ich Ihnen 30% der gesamten Mittel als Ausgleich für Ihre Unterstützung in dieser Transaktion. Ich werde Sie über die vollständige Transaktion benachrichtigt nach Eingang Ihrer Antwort, wenn interessiert, bitte senden Sie mir Ihren vollständigen detials als unten, um meine E-Mail aufgeführt: s_zhijun...@qq.com 1. Vollständiger Name 2.Private Telefonnummer 3.Current Wohnadresse Mit freundlichen Grüßen, Mr.SUN Zhijun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Guten Tag!
Guten Tag, Mein Name ist Mr.SUN Zhijun, ich mit der Bank of China zu arbeiten. Ich brauche Ihre Unterstützung in Durchführung einer Transaktion bei $ 18,5 Millionen Dollar geschätzt, möchte ich Ihnen 30% der gesamten Mittel als Ausgleich für Ihre Unterstützung in dieser Transaktion. Ich werde Sie über die vollständige Transaktion benachrichtigt nach Eingang Ihrer Antwort, wenn interessiert, bitte senden Sie mir Ihren vollständigen detials als unten, um meine E-Mail aufgeführt: s_zhijun...@qq.com 1. Vollständiger Name 2.Private Telefonnummer 3.Current Wohnadresse Mit freundlichen Grüßen, Mr.SUN Zhijun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] ARM: mach-moxart: add MOXA ART SoC platform files
On 14 December 2013 16:50, Guenter Roeck wrote: > The above would at least avoid the crash, though I would not understand > the point of having an unloadable restart handler. Forcing the watchdog > driver into the kernel just because you want the restart handler in it > would seem odd. And if the restart handler is optional, why have it > in the first place ? I also don't follow Arnd's logic of wanting to have > the code in the watchdog driver just because it happens to use a register > that it needs. > > Conceptually it might be cleaner to write a separate driver, for example > in drivers/power/restart, than plugging the functionality into > the watchdog driver, at least if you don't want it in architecture > or platform code. The xgene restart driver is a good example. > > Anyway, it is not up to me to accept the code, that is up to Wim. > My rejection was primarily due to technical flaws, which can be addressed. > For the logical reasoning you'll have to convince Wim. Thanks for the replies. Moving it to a new power/restart driver seems reasonable to me, I'm really just looking for a home for it, I would have preferred a hardware with reset in a separate register though. I now plan to remove it for v5 and submit a separate driver. Regards, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Added Capella CM32181 Ambient Light Sensor IIO Driver.
On 12/14/13 01:59, Kevin Tsai wrote:
> Signed-off-by: Kevin Tsai
Hi Kevin.
Generally for a new driver we'd expect a very brief description of what
functionality it provides in the patch comment.
As a starting point, you've cc'd the devicetree list and maintainers but
there is documentation in here? Looks at a quick glance like it might
be a candidate for a trivial binding file, but it does need to be somewhere.
If publically available it is also helpful to provide a link to the
device datasheet. Cuts down on questions by allowing reviewers to take
a look for themselves :) A quick google implies there isn't an easily
available datasheet. Oh well.
Couple of minor bits inline.
One big question is whether the retries are inherently necessary
(i.e. does the device actually have periods when it won't reply?)
If not then drop them at which point the wrappers just add code and
make reviewing harder. Hence please drop them infavour of calling
the i2c functions inline.
Another is whether providing the i2c detection functions makes sense
for this device. Is it ever used of devices where its location /address
is not known in advance.
Also, you have a couple of attributes which are handled as info_mask
elements in IIO. Finally why provide both raw and processed accesses to the
data?
Anyhow, whilst it sounds a lot, this is just a few quick tweaks and this driver
will be ready to merge.
Jonathan
> ---
> drivers/iio/light/Kconfig | 11 ++
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/cm32181.c | 437
>
> 3 files changed, 449 insertions(+)
> create mode 100644 drivers/iio/light/cm32181.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index a022f27..d12b2a0 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -27,6 +27,17 @@ config APDS9300
>To compile this driver as a module, choose M here: the
>module will be called apds9300.
>
> +config CM32181
> + depends on I2C
> + tristate "CM32181 driver"
> + help
> + Say Y here if you use cm32181.
> + This option enables ambient light sensor using
> + Capella cm32181 device driver.
> +
> + To compile this driver as a module, choose M here:
> + the module will be called cm32181.
> +
> config CM36651
> depends on I2C
> tristate "CM36651 driver"
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index daa327f..60e35ac 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -5,6 +5,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_ADJD_S311) += adjd_s311.o
> obj-$(CONFIG_APDS9300) += apds9300.o
> +obj-$(CONFIG_CM32181)+= cm32181.o
> obj-$(CONFIG_CM36651)+= cm36651.o
> obj-$(CONFIG_GP2AP020A00F) += gp2ap020a00f.o
> obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
> diff --git a/drivers/iio/light/cm32181.c b/drivers/iio/light/cm32181.c
> new file mode 100644
> index 000..58ab1b2
> --- /dev/null
> +++ b/drivers/iio/light/cm32181.c
> @@ -0,0 +1,437 @@
> +/*
> + * Copyright (C) 2013 Capella Microsystems Inc.
> + * Author: Kevin Tsai
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2, as
> published
> + * by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Registers Address */
> +#define CM32181_REG_ADDR_CMD0x00
> +#define CM32181_REG_ADDR_ALS0x04
> +#define CM32181_REG_ADDR_STATUS 0x06
> +#define CM32181_REG_ADDR_ID 0x07
> +
> +/* Number of Configurable Registers */
> +#define CM32181_CONF_REG_NUM 0x01
> +
> +/* CMD register */
> +#define CM32181_CMD_ALS_ENABLE 0x00
> +#define CM32181_CMD_ALS_DISABLE 0x01
> +#define CM32181_CMD_ALS_INT_EN 0x02
> +
> +#define CM32181_CMD_ALS_IT_SHIFT6
> +#define CM32181_CMD_ALS_IT_MASK (0x0F <<
> CM32181_CMD_ALS_IT_SHIFT)
> +#define CM32181_CMD_ALS_IT_DEFAULT (0x00 <<
> CM32181_CMD_ALS_IT_SHIFT)
> +
> +#define CM32181_CMD_ALS_SM_SHIFT 11
> +#define CM32181_CMD_ALS_SM_MASK (0x03 <<
> CM32181_CMD_ALS_SM_SHIFT)
> +#define CM32181_CMD_ALS_SM_DEFAULT (0x01 <<
> CM32181_CMD_ALS_SM_SHIFT)
> +
> +#define CM32181_MLUX_PER_BIT5 /* ALS_SM=01 IT=800ms */
> +#define CM32181_MLUX_PER_BIT_BASE_IT80 /* Based on IT=800ms */
> +#define CM32181_CALIBSCALE_RESOLUTION 1000
> +#define MLUX_PER_LUX1000
> +
> +enum cm32181_command {
> + CM32181_CMD_READ_RAW_LIGHT,
> +};
> +
> +static const u16 normal_i2c[] = {
> + 0x10, 0x48, I2C_CLIENT_END }
[PATCH v2] selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()
selinux_setprocattr() does ptrace_parent(p) under task_lock(p),
but task_struct->alloc_lock doesn't pin ->parent or ->ptrace,
this looks confusing and triggers the "suspicious RCU usage"
warning because ptrace_parent() does rcu_dereference_check().
And in theory this is wrong, spin_lock()->preempt_disable()
doesn't necessarily imply rcu_read_lock() we need to access
the ->parent.
Reported-by: Evan McNabb
Signed-off-by: Oleg Nesterov
---
security/selinux/hooks.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5503,11 +5503,11 @@ static int selinux_setprocattr(struct ta
/* Check for ptracing, and update the task SID if ok.
Otherwise, leave SID unchanged and fail. */
ptsid = 0;
- task_lock(p);
+ rcu_read_lock();
tracer = ptrace_parent(p);
if (tracer)
ptsid = task_sid(tracer);
- task_unlock(p);
+ rcu_read_unlock();
if (tracer) {
error = avc_has_perm(ptsid, sid, SECCLASS_PROCESS,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()
On 12/14, Paul Moore wrote: > > I understand your point, but I still think there is some value in > keeping the call to ptrace_parent() rather than fetching the ptrace > pointer on our own. Yes, agreed, I changed my mind ;) > However, that said, I think we should try and do something about the > "suspicious RCU usage" you mentioned in your original posting. Yes, this was the only motivation for this patch. > but > I'm curious about the removal of the task lock; shouldn't week keep > the task lock in place? Why? It protects nothing in this case, afaics. Unless of course it protects cred->security somehow, but it doesn't look as if. Probably task_lock() is here because PTRACE_ATTACH used the same lock, but this was changed by 4b105cbbaf7c0 in 2009 (ptrace_attach() still takes it for __ptrace_may_access() but this is another story). However (iirc) PTRACE_DETACH never took this lock, so this was always racy and task_lock() is simply misleading and confusing, at least currently. So I think the patch is fine, but I decided to send v2 without pid_alive(). If we are going to keep ptrace_parent(), it would be better to add the comment into ptrace_parent() to explain that ->ptrace != 0 guarantees that this task is not unhashed. IOW, I also changed my mind about this part The patch also checks pid_alive(p) before ptrace_parent(p) to ensure that this task can't be dead even before rcu_read_lock(), in this case its ->parent points to nowhere. This is not really needed "in practice", task->ptrace must be already cleared in this case but we should not rely on this. in the changelog. > > And perhaps I am wrong. Because otoh the usage of ->ptrace should be > > avoided outside of the core kernel code. > > Not to muddy things up, but one could argue that this particular > LSM/SELinux hook should be regarded as part of the "core" kernel code. > However, I'm not sure that the distinction is really important here. Yes, yes, sorry for confusion. I meant, the core kernel code which works with ptrace/exit/fork/etc. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: si570: Add a driver for SI570 oscillators
On 10/02/2013 04:17 PM, Mike Turquette wrote:
Quoting Sören Brinkmann (2013-10-02 10:20:38)
Hi Mike,
could you please comment on this/apply it to clk-next?
It looks good and is in the queue. Will show up in clk-next in a few
days.
Hi Mike,
trying again ... what happened with this driver ? Any reason for not pushing it
after all ?
Thanks,
Guenter
Thanks,
Mike
Thanks,
Sören
On Sat, Sep 21, 2013 at 04:40:39PM -0700, Soren Brinkmann wrote:
Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
The devices generate low-jitter clock signals and are reprogrammable via
an I2C interface.
Cc: Guenter Roeck
Signed-off-by: Soren Brinkmann
---
v5:
- fix typo in bindings documentation
- mention the unit for the 'temperature-stability' property
- remove calls to clk_unregister() (the device managed code takes care
of it)
v4:
- actually check and handle error on clk_set_rate() call
v3:
- add delay in the path for small frequency changes, which can take up
to 100us according to the data sheet
- use real range for usleep_range() argument
- use dev_err() over dev_warn() in set_rate()
- add list of applicable devices for 7ppm DT prop
- remove comments regarding platform data
- ignore 7ppm DT prop for incompatible devices
- replace raw numbers with #defines
- convert DT prop 'temperature-stability' from boolean to u32
- make 'temperature-stability' DT prop required (actually not fully
true, for 59x it is ignored and the driver does not require its
presence)
v2:
- document clock-output-names in bindings documentation
- don't use wildcards in compatibility string
- change Kconfig entry to "... 570 and compatible devices"
- change some indentation flaws
- use 1 as MIN and MAX value in usleep_range
- fail probe() if 'factory-fout' is not provided in DT
- default factory fout #defines removed
- use i2c driver_data instead of OF data
- remove some related structs and data
- rename DT property 'initial-fout' => 'clock-frequency' (like si5351
driver)
- add some more details regarding the 'factory-fout' DT property
---
.../devicetree/bindings/clock/silabs,si570.txt | 39 ++
drivers/clk/Kconfig| 10 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-si570.c| 531 +
4 files changed, 581 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/silabs,si570.txt
create mode 100644 drivers/clk/clk-si570.c
diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt
b/Documentation/devicetree/bindings/clock/silabs,si570.txt
new file mode 100644
index 000..c09f21e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si570.txt
@@ -0,0 +1,39 @@
+Binding for Silicon Labs 570, 571, 598 and 599 programmable
+I2C clock generators.
+
+Reference
+This binding uses the common clock binding[1]. Details about the devices can be
+found in the data sheets[2][3].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Si570/571 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
+[3] Si598/599 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
+
+Required properties:
+ - compatible: Shall be one of "silabs,si570", "silabs,si571",
+"silabs,si598", "silabs,si599"
+ - reg: I2C device address.
+ - #clock-cells: From common clock bindings: Shall be 0.
+ - factory-fout: Factory set default frequency. This frequency is part
specific.
+ The correct frequency for the part used has to be provided in
+ order to generate the correct output frequencies. For more
+ details, please refer to the data sheet.
+ - temperature-stability: Temperature stability of the device in PPM. Should be
+ one of: 7, 20, 50 or 100.
+
+Optional properties:
+ - clock-output-names: From common clock bindings. Recommended to be "si570".
+ - clock-frequency: Output frequency to generate. This defines the output
+ frequency set during boot. It can be reprogrammed during
+ runtime through the common clock framework.
+
+Example:
+ si570: clock-generator@5d {
+ #clock-cells = <0>;
+ compatible = "silabs,si570";
+ temperature-stability = <50>;
+ reg = <0x5d>;
+ factory-fout = <15625>;
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 279407a..349b88a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -64,6 +64,16 @@ config COMMON_CLK_SI5351
This driver supports Silicon Labs 5351A/B/C programmable clock
generators.
+config COMMON_CLK_SI570
+ tristate "Clock driver for SiLabs 570 and compatible devices"
+ depends on I2C
+ depends on OF
+ select REGMAP_I2C
+ help
+ ---help
Re: [PATCH] drivers: infiniband: Mark function _c4iw_write_mem_dma() as static in mem.c
Acked-by: Steve Wise -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] arm: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Russell King CC: linux-arm-ker...@lists.infradead.org --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7e..6990dc5 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -6,6 +6,7 @@ config ARM select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO if FOOTBRIDGE_HOST select ARCH_USE_CMPXCHG_LOCKREF select ARCH_WANT_IPC_PARSE_VERSION select BUILDTIME_EXTABLE_SORT if MMU -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10] Kconfig: cleanup SERIO_I8042 dependencies
This patch series removes the messy dependencies from SERIO_I8042 by having it depend on one variable (ARCH_MAY_HAVE_PC_SERIO) and having architectures which need it select that variable in arch/*/Kconfig. New architectures are unlikely to need SERIO_I8042, so this avoids having an ever growing list of architectures to exclude. If an architecture without i8042 support isn't excluded through the dependency list for SERIO_I8042 or through explicit disabling in a config, it will likely panic on boot with something similar to this (from arm64): [ 27.426181] [] i8042_flush+0x88/0x10c [ 27.426251] [] i8042_init+0x58/0xe8 [ 27.426320] [] do_one_initcall+0xc4/0x14c [ 27.426404] [] kernel_init_freeable+0x1a4/0x244 [ 27.426480] [] kernel_init+0x18/0x148 [ 27.426561] Code: d2800c82 f2bf7c02 f2dff7e2 f2e2 (39400042) [ 27.426789] ---[ end trace ac076843cf0f383e ]--- [ 27.426875] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b A tree with these patches is at: git://github.com/mosalter/linux.git (serio-i8042 branch) Mark Salter (10): alpha: select ARCH_MIGHT_HAVE_PC_SERIO arm: select ARCH_MIGHT_HAVE_PC_SERIO ia64: select ARCH_MIGHT_HAVE_PC_SERIO mips: select ARCH_MIGHT_HAVE_PC_SERIO powerpc: select ARCH_MIGHT_HAVE_PC_SERIO sh: select ARCH_MIGHT_HAVE_PC_SERIO sparc: select ARCH_MIGHT_HAVE_PC_SERIO unicore32: select ARCH_MIGHT_HAVE_PC_SERIO x86: select ARCH_MIGHT_HAVE_PC_SERIO Kconfig: cleanup SERIO_I8042 dependencies arch/alpha/Kconfig | 1 + arch/arm/Kconfig| 1 + arch/ia64/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/powerpc/Kconfig| 1 + arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/unicore32/Kconfig | 1 + arch/x86/Kconfig| 1 + drivers/input/serio/Kconfig | 11 --- 10 files changed, 17 insertions(+), 3 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] x86: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Ingo Molnar CC: Thomas Gleixner CC: "H. Peter Anvin" CC: x...@kernel.org --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index e903c71..b7f0903 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -23,6 +23,7 @@ config X86 def_bool y select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO select HAVE_AOUT if X86_32 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] unicore32: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Guan Xuetao --- arch/unicore32/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index a7ba27b..25c0dba 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -1,6 +1,7 @@ config UNICORE32 def_bool y select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO select HAVE_MEMBLOCK select HAVE_GENERIC_DMA_COHERENT select HAVE_DMA_ATTRS -- 1.8.3.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 1/3] drivers: edac: Mark the function amd64_decode_bus_error() as static in amd64_edac.c
On Sat, Dec 14, 2013 at 07:28:24PM +0530, Rashika Kheria wrote: > This patch marks the function amd64_decode_bus_error() as static in > amd64_edac.c because it is not used outside this file. > > Thus, it also eliminates the following warning in amd64_edac.c: > drivers/edac/amd64_edac.c:2038:6: warning: no previous prototype for > ‘amd64_decode_bus_error’ [-Wmissing-prototypes] How do you trigger this? .config and output of gcc --version please. I've never seen this warning before. -- 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 10/10] Kconfig: cleanup SERIO_I8042 dependencies
Remove messy dependencies from SERIO_I8042 by having it depend on one Kconfig symbol (ARCH_MIGHT_HAVE_PC_SERIO) and having architectures which need it select ARCH_MIGHT_HAVE_PC_SERIO in arch/*/Kconfig. New architectures are unlikely to need SERIO_I8042, so this avoids having an ever growing list of architectures to exclude. Signed-off-by: Mark Salter CC: Dmitry Torokhov CC: Richard Henderson CC: linux-al...@vger.kernel.org CC: Russell King CC: linux-arm-ker...@lists.infradead.org CC: Tony Luck CC: Fenghua Yu CC: linux-i...@vger.kernel.org CC: Ralf Baechle CC: linux-m...@linux-mips.org CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-...@lists.ozlabs.org CC: Paul Mundt CC: linux...@vger.kernel.org CC: "David S. Miller" CC: sparcli...@vger.kernel.org CC: Guan Xuetao CC: Ingo Molnar CC: Thomas Gleixner CC: "H. Peter Anvin" CC: x...@kernel.org --- drivers/input/serio/Kconfig | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index 8541f94..1f5cec2 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -16,14 +16,19 @@ config SERIO To compile this driver as a module, choose M here: the module will be called serio. +config ARCH_MIGHT_HAVE_PC_SERIO + bool + help + Select this config option from the architecture Kconfig if + the architecture might use a PC serio device (i8042) to + communicate with keyboard, mouse, etc. + if SERIO config SERIO_I8042 tristate "i8042 PC Keyboard controller" default y - depends on !PARISC && (!ARM || FOOTBRIDGE_HOST) && \ - (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN && !S390 && \ - !ARC + depends on ARCH_MIGHT_HAVE_PC_SERIO help i8042 is the chip over which the standard AT keyboard and PS/2 mouse are connected to the computer. If you use these devices, -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] alpha: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Richard Henderson CC: linux-al...@vger.kernel.org --- arch/alpha/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index d39dc9b..7ce5ce5 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -2,6 +2,7 @@ config ALPHA bool default y select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO select HAVE_AOUT select HAVE_IDE select HAVE_OPROFILE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] ia64: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Tony Luck CC: Fenghua Yu CC: linux-i...@vger.kernel.org --- arch/ia64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 4e4119b..f7337aa 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -7,6 +7,7 @@ menu "Processor type and features" config IA64 bool select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO select PCI if (!IA64_HP_SIM) select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] powerpc: select ARCH_MIGHT_HAVE_PC_SERIO
Architectures which might use an i8042 for serial IO to keyboard, mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO. Signed-off-by: Mark Salter CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-...@lists.ozlabs.org --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b44b52c..fb75485 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -86,6 +86,7 @@ config PPC bool default y select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_PC_SERIO select BINFMT_ELF select OF select OF_EARLY_FLATTREE -- 1.8.3.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/
