RE: [Question]Why a skb with frag_list causes BUG_ON in function skb_segment
Get it.
Eric, thanks for your explaination. :-)
Jason, thank you! I will remember cc net...@vger.kernel.org next time.
-Original Message-
From: Eric Dumazet [mailto:eric.duma...@gmail.com]
Sent: Thursday, July 30, 2015 1:01 PM
To: Jason Wang
Cc: Zhangjie (HZ); linux-kernel@vger.kernel.org; m...@redhat.com; Qinchuanyu;
Yewudi; liuyongan 00175866; net...@vger.kernel.org
Subject: Re: [Question]Why a skb with frag_list causes BUG_ON in function
skb_segment
On Thu, 2015-07-30 at 12:26 +0800, Jason Wang wrote:
> cc netdev for more experts
>
> On 07/28/2015 04:53 PM, Zhangjie (HZ) wrote:
> >
> > Hi,
> >
> > I generate a skb as follows:
> >
> > It has a linear data region, 17 frags and the last fragment is in
> > skb_shinfo(skb)->frag_list.
> >
> > Before this skb is sent to driver, dev_hard_start_xmit() will
> > segment it first(skb has frag_list,
> >
> > so we get true from netif_needs_gso()), then the skb is passed to
> > function skb_segment().
> >
> > Then, BUG_ON() happened.
> >
> > while (pos < offset + len) {
> >
> > if (i >= nfrags) {
> >
> > BUG_ON(skb_headlen(list_skb));(skbuff.c:3120)
> >
> > …
> >
> > }
> >
> > …
> >
> > }
> >
> > A skb that has no frags but frag_list also causes BUG_ON().
> >
> > I wonder if skb like follows is legal? Could skb in frag_list have
> > linear data region?
The answer is : skb_segment() is very complex but does not handle all possible
cases.
skb found in skb_shinfo(skb)->frag_list must not have anything in their
skb->head. This would require very expensive logic and memory
allocations and copies.
Make sure you follow this rule in your driver, or even better leave this work
to GRO engine.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
On Thu, Jul 30, 2015 at 8:18 AM, Fu, Zhonghui wrote: > Enable wiphy device to suspend/resume asynchronously. This can improve > system suspend/resume speed. > How will that impact the timing with respect to the suspend call coming from the bus? I think that a few drivers rely on the suspend call of the wiphy device happening before the suspend call to the bus device. Not sure though. > Signed-off-by: Zhonghui Fu > --- > net/wireless/core.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/net/wireless/core.c b/net/wireless/core.c > index 2a0bbd2..bc5e68f 100644 > --- a/net/wireless/core.c > +++ b/net/wireless/core.c > @@ -416,6 +416,7 @@ use_default_name: > device_initialize(>wiphy.dev); > rdev->wiphy.dev.class = _class; > rdev->wiphy.dev.platform_data = rdev; > + device_enable_async_suspend(>wiphy.dev); > > INIT_LIST_HEAD(>destroy_list); > spin_lock_init(>destroy_list_lock); > -- 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] noop-iosched: do not attempt to sort requests
Hi Jens, did you get a chance to take a look at this patch? On Thu, Jul 23, 2015 at 2:20 PM, Tahsin Erdogan wrote: > Noop scheduler currently dispatches a request by calling > elv_dispatch_sort(). In practice, sorting does not occur because > __elv_next_request() asks the io scheduler to dispatch a request > only when elevator queue is empty. > > Also, not reordering requests seems more appropriate for noop. This > change makes the behavior more explicit. > > Reviewed-by: Nauman Rafique > Signed-off-by: Tahsin Erdogan > --- > block/Kconfig.iosched | 8 > block/noop-iosched.c | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched > index 421bef9..b9e42f8 100644 > --- a/block/Kconfig.iosched > +++ b/block/Kconfig.iosched > @@ -7,10 +7,10 @@ config IOSCHED_NOOP > default y > ---help--- > The no-op I/O scheduler is a minimal scheduler that does basic > merging > - and sorting. Its main uses include non-disk based block devices like > - memory devices, and specialised software or hardware environments > - that do their own scheduling and require only minimal assistance > from > - the kernel. > + only. Its main uses include non-disk based block devices like memory > + devices, and specialised software or hardware environments that do > + their own scheduling and require only minimal assistance from the > + kernel. > > config IOSCHED_DEADLINE > tristate "Deadline I/O scheduler" > diff --git a/block/noop-iosched.c b/block/noop-iosched.c > index 3de89d4..f0fec14 100644 > --- a/block/noop-iosched.c > +++ b/block/noop-iosched.c > @@ -26,7 +26,7 @@ static int noop_dispatch(struct request_queue *q, int force) > struct request *rq; > rq = list_entry(nd->queue.next, struct request, queuelist); > list_del_init(>queuelist); > - elv_dispatch_sort(q, rq); > + elv_dispatch_add_tail(q, rq); > return 1; > } > return 0; > -- > 2.4.3.573.g4eafbef > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq: Lock CPU online/offline in cpufreq_register_driver()
On 30-07-15, 01:45, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> To protect against races with concurrent CPU online/offline, call
> get_online_cpus() before registering a cpufreq driver.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -2471,10 +2471,14 @@ int cpufreq_register_driver(struct cpufr
>
> pr_debug("trying to register driver %s\n", driver_data->name);
>
> + /* Protect against concurrent CPU online/offline. */
> + get_online_cpus();
> +
> write_lock_irqsave(_driver_lock, flags);
> if (cpufreq_driver) {
> write_unlock_irqrestore(_driver_lock, flags);
> - return -EEXIST;
> + ret = -EEXIST;
> + goto out;
> }
> cpufreq_driver = driver_data;
> write_unlock_irqrestore(_driver_lock, flags);
> @@ -2513,7 +2517,10 @@ int cpufreq_register_driver(struct cpufr
> register_hotcpu_notifier(_cpu_notifier);
> pr_debug("driver %s up and running\n", driver_data->name);
>
> - return 0;
> +out:
> + put_online_cpus();
> + return ret;
> +
> err_if_unreg:
> subsys_interface_unregister(_interface);
> err_boost_unreg:
> @@ -2523,7 +2530,7 @@ err_null_driver:
> write_lock_irqsave(_driver_lock, flags);
> cpufreq_driver = NULL;
> write_unlock_irqrestore(_driver_lock, flags);
> - return ret;
> + goto out;
> }
> EXPORT_SYMBOL_GPL(cpufreq_register_driver);
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/11] stm class: Introduce an abstraction for System Trace Module devices
Chunyan Zhang writes: > If let stm_probe() implement probe deferral, it has to have a global > variable for the later calling of "stm_register_device", because the No, it doesn't. Please read about probe deferral. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 3/7] avr32: Remove finish_arch_switch()
Around Wed 29 Jul 2015 21:08:51 +0200 or thereabout, Peter Zijlstra wrote:
> Fold the tracing hook into switch_to() in order to remove
> finish_arch_switch().
AFAICT this should work, I do not have a nexus debugger to verify behavior.
> Cc: Hans-Christian Egtvedt
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Hans-Christian Egtvedt
> ---
> arch/avr32/include/asm/switch_to.h |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> --- a/arch/avr32/include/asm/switch_to.h
> +++ b/arch/avr32/include/asm/switch_to.h
> @@ -15,11 +15,13 @@
> */
> #ifdef CONFIG_OWNERSHIP_TRACE
> #include
> -#define finish_arch_switch(prev) \
> +#define ocd_switch(prev, next) \
> do {\
> ocd_write(PID, prev->pid); \
> - ocd_write(PID, current->pid); \
> + ocd_write(PID, next->pid); \
> } while(0)
> +#else
> +#define ocd_switch(prev, next)
> #endif
>
> /*
> @@ -38,6 +40,7 @@ extern struct task_struct *__switch_to(s
> struct cpu_context *);
> #define switch_to(prev, next, last) \
> do {\
> + ocd_switch(prev, next); \
> last = __switch_to(prev, >thread.cpu_context + 1, \
> >thread.cpu_context); \
> } while (0)
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4573/4573] Staging: rtl8188eu: fixed newlines after declarations
On Wed, 2015-07-29 at 21:34 -0400, Dave Perez wrote: > This is a patch to the rtw_debug.c file that fixes styling errors relating to > new lines after variable declarations. [] > diff --git a/drivers/staging/rtl8188eu/core/rtw_debug.c > b/drivers/staging/rtl8188eu/core/rtw_debug.c [] > @@ -219,6 +219,7 @@ int proc_get_ht_option(char *page, char **start, > struct mlme_priv *pmlmepriv = &(padapter->mlmepriv); > > int len = 0; > + > len += snprintf(page + len, count - len, "ht_option=%d\n", > pmlmepriv->htpriv.ht_option); > *eof = 1; > return len; the blank line before "int len = 0" could also be removed. The routine _could_ be rewritten more simply as: struct mlme_priv *pmlmepriv = >mlmepriv; int len = snprintf(page, count, "ht_option=%d\n", pmlmepriv->htpriv.htoption); *eof = 1; return len; } but there are a bunch of other routines that use this form so it's probably fine as-is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC 2/3] x86: Add Intel PT logger
Takao Indoh writes: > Ok, I'm reading the code around perf_event_create_kernel_counter. It > seems to work for my purpose, I'll try to update my patch with this. Thank you. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
Enable wiphy device to suspend/resume asynchronously. This can improve system suspend/resume speed. Signed-off-by: Zhonghui Fu --- net/wireless/core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/wireless/core.c b/net/wireless/core.c index 2a0bbd2..bc5e68f 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -416,6 +416,7 @@ use_default_name: device_initialize(>wiphy.dev); rdev->wiphy.dev.class = _class; rdev->wiphy.dev.platform_data = rdev; + device_enable_async_suspend(>wiphy.dev); INIT_LIST_HEAD(>destroy_list); spin_lock_init(>destroy_list_lock); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>
> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's almost guaranteed to be
that
crtc->dev
access as part of list_for_each_entry(), with crtc being NULL. And
yes, "->dev" is the very first field, so the offset is zero too (while
the "->mode_config" list access would not be at offset zero).
And it looks like it is called from drm_atomic_helper_check_modeset():
the reason it has a question mark in the backtrace is because the
fault happens before the stack frame has even been set up.
There are multiple calls to "drm_crtc_index()" from that function, I
can't tell which one it is. Looking at the code generation I get, I
think it's because update_connector_routing() gets inlined, and that
one does several calls. Most of them look like this:
if (connector->state->crtc) {
idx = drm_crtc_index(connector->state->crtc);
ie they check that the crtc is non-NULL, but that last one does not:
connector_state->best_encoder = new_encoder;
idx = drm_crtc_index(connector_state->crtc);
crtc_state = state->crtc_states[idx];
crtc_state->mode_changed = true;
and I suspect the fix might be something like the attached. Totally
untested. Ted?
This whole "atomic modeset" series has been one royal fuck-up, guys.
We've had too many of these kinds of crap issues.
Linus
drivers/gpu/drm/drm_atomic_helper.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 5b59d5ad7d1c..aac212297b49 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state *state,
int conn_idx)
}
connector_state->best_encoder = new_encoder;
- idx = drm_crtc_index(connector_state->crtc);
+ if (connector_state->crtc) {
+ idx = drm_crtc_index(connector_state->crtc);
- crtc_state = state->crtc_states[idx];
- crtc_state->mode_changed = true;
+ crtc_state = state->crtc_states[idx];
+ crtc_state->mode_changed = true;
+ }
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d]\n",
connector->base.id,
Re: [PATCH] align crash_notes allocation to make it be inside one physical page
On 07/30/15 at 11:07am, Baoquan He wrote:
> People reported that crash_notes in /proc/vmcore were corrupted and
> this cause crash kdump failure. With code debugging and log we got
> the root cause. This is because percpu variable crash_notes are
> allocated in 2 vmalloc pages. As you know percpu is based on vmalloc
> by default. Then vmalloc can't guarantee 2 continuous vmalloc pages
> are also on 2 continuous physical pages. Then 1st kernel export the
> starting addr and size, kdump kernel use the starting addr and size
> to get the content of crash_notes, then 2nd part may not be in the
> next neighbouring physical page as we think. That's why nhdr_ptr->n_namesz
> or nhdr_ptr->n_descsz could be very huge in update_note_header_size_elf64()
> and cause note header merging failure or some warnings.
>
> In this patch change to call __alloc_percpu() to passed in the align
> value which is nearest the the 2^log(sizeof(note_buf_t)). This align
> value can make sure the crash_notes is allocated inside one physical
> page since sizeof(note_buf_t) in all ARCHS is smaller PAGE_SIZE. But
> add a WARN_ON in case it grow to be bigger than PAGE_SIZE in the future.
>
> Signed-off-by: Baoquan He
> ---
> kernel/kexec.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index a785c10..1740c42 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1620,7 +1620,16 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
> static int __init crash_notes_memory_init(void)
> {
> /* Allocate memory for saving cpu registers. */
> - crash_notes = alloc_percpu(note_buf_t);
> + size_t size, align;
> + int order;
> +
> + size = sizeof(note_buf_t);
> + order = get_count_order(size);
> + align = 1<< order;
> +
> + WARN_ON(size > PAGE_SIZE);
It is fine without this warning, since percpu will fail to allocate the
memory larger than PAGE_SIZE.
Thanks
Minfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question]Why a skb with frag_list causes BUG_ON in function skb_segment
On Thu, 2015-07-30 at 12:26 +0800, Jason Wang wrote:
> cc netdev for more experts
>
> On 07/28/2015 04:53 PM, Zhangjie (HZ) wrote:
> >
> > Hi,
> >
> > I generate a skb as follows:
> >
> > It has a linear data region, 17 frags and the last fragment is in
> > skb_shinfo(skb)->frag_list.
> >
> > Before this skb is sent to driver, dev_hard_start_xmit() will segment
> > it first(skb has frag_list,
> >
> > so we get true from netif_needs_gso()), then the skb is passed to
> > function skb_segment().
> >
> > Then, BUG_ON() happened.
> >
> > while (pos < offset + len) {
> >
> > if (i >= nfrags) {
> >
> > BUG_ON(skb_headlen(list_skb));(skbuff.c:3120)
> >
> > …
> >
> > }
> >
> > …
> >
> > }
> >
> > A skb that has no frags but frag_list also causes BUG_ON().
> >
> > I wonder if skb like follows is legal? Could skb in frag_list have
> > linear data region?
The answer is : skb_segment() is very complex but does not handle all
possible cases.
skb found in skb_shinfo(skb)->frag_list must not have anything in their
skb->head. This would require very expensive logic and memory
allocations and copies.
Make sure you follow this rule in your driver, or even better leave this
work to GRO engine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] KVM: i8254: remove unnecessary irqchip_in_kernel check
On Wed, Jul 29, 2015 at 03:28:57PM +0200, Paolo Bonzini wrote: > The PIT is only created if irqchip_in_kernel returns true, so the > check is superfluous. I poked around. Looks to me like the existence of an IOAPIC is not checked on the creation of the in-kernel PIT. Userspace might limit itself to that scenario (PIT implies IOAPIC in-kernel), but that isn't enforced at PIT creation. It's worth adding that check in. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/i8254.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c > index f90952f64e79..f588eb7bdf45 100644 > --- a/arch/x86/kvm/i8254.c > +++ b/arch/x86/kvm/i8254.c > @@ -333,7 +333,7 @@ static void create_pit_timer(struct kvm *kvm, u32 val, > int is_period) > struct kvm_kpit_state *ps = >arch.vpit->pit_state; > s64 interval; > > - if (!irqchip_in_kernel(kvm) || ps->flags & KVM_PIT_FLAGS_HPET_LEGACY) > + if (ps->flags & KVM_PIT_FLAGS_HPET_LEGACY) > return; > > interval = muldiv64(val, NSEC_PER_SEC, KVM_PIT_FREQ); > -- > 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] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address
When testing hibernate, I found the EFI runtime services was broken
on some old EFI machines on my hand, Intel DQ57TM development board
and Acer Gateway Z5WT2 notebook.
After printing the EFI memmap and virtual address mapping on -4G area,
found those issue machines keep the physical address of Runtime
Data/Code regions unchanged but not Boot Data/Code. The logs were
attached on openSUSE bug:
https://bugzilla.suse.com/show_bug.cgi?id=939979
Due to Boot Data/Code can be used by OS as available memory regions,
so those old EFI BIOS do not keep the physical address of Boot regions
unchanged. But, address of Runtime regions are the same.
On Intel DQ57TM, sometimes the order of EFI Boot regions changed. On
Acer Gateway Z5WT2, the amount of EFI Boot regions changed.
The above changing of EFI Boot regions causes the EFI Runtime Data/Code
may not mapping to constant virtual address, that's because the EFI Boot
and Runtime regions are interleaved and EFI va mapping applied PMD
2M-aligned logic.
A workaround of this situation is mapping Boot and Runtime regions to
different starting virtual address. Then the changing of Boot Data/Code
regions will not affect to the virtual address mapping to Runtime
Data/Code.
This patch adds codes for mapping Boot Data/Code regions start from
0x___, has 1G space. And mapping Runtime Data/Code
regions start from 0x_fffe_c000_ that has 63G space.
Link: https://bugzilla.suse.com/show_bug.cgi?id=939979
Cc: Matt Fleming
Cc: Borislav Petkov
Signed-off-by: Lee, Chun-Yi
---
arch/x86/platform/efi/efi_64.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index a0ac0f9..fde7f8f 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -42,10 +42,14 @@
#include
/*
- * We allocate runtime services regions bottom-up, starting from -4G, i.e.
- * 0x___ and limit EFI VA mapping space to 64G.
+ * We allocate boot and runtime services regions bottom-up, starting from -4G,
+ * i.e. 0x___ and limit EFI VA mapping space to 64G.
+ *
+ * Boot Data/Code are starting from 0x___ (1G space)
+ * Runtime Data/Code are starting from 0x_fffe_c000_ (63G space)
*/
-static u64 efi_va = EFI_VA_START;
+static u64 efi_boot_va = EFI_VA_START;
+static u64 efi_runtime_va = EFI_VA_START - 0x4000;
/*
* Scratch space used for switching the pagetable in the EFI stub
@@ -218,6 +222,7 @@ void __init efi_map_region(efi_memory_desc_t *md)
{
unsigned long size = md->num_pages << PAGE_SHIFT;
u64 pa = md->phys_addr;
+ u64 *efi_va = _boot_va;
if (efi_enabled(EFI_OLD_MEMMAP))
return old_map_region(md);
@@ -239,30 +244,33 @@ void __init efi_map_region(efi_memory_desc_t *md)
return;
}
- efi_va -= size;
+ if (md->attribute & EFI_MEMORY_RUNTIME)
+ efi_va = _runtime_va;
+
+ *efi_va -= size;
/* Is PA 2M-aligned? */
if (!(pa & (PMD_SIZE - 1))) {
- efi_va &= PMD_MASK;
+ *efi_va &= PMD_MASK;
} else {
u64 pa_offset = pa & (PMD_SIZE - 1);
- u64 prev_va = efi_va;
+ u64 prev_va = *efi_va;
/* get us the same offset within this 2M page */
- efi_va = (efi_va & PMD_MASK) + pa_offset;
+ *efi_va = (*efi_va & PMD_MASK) + pa_offset;
- if (efi_va > prev_va)
- efi_va -= PMD_SIZE;
+ if (*efi_va > prev_va)
+ *efi_va -= PMD_SIZE;
}
- if (efi_va < EFI_VA_END) {
+ if (*efi_va < EFI_VA_END) {
pr_warn(FW_WARN "VA address range overflow!\n");
return;
}
/* Do the VA map */
- __map_region(md, efi_va);
- md->virt_addr = efi_va;
+ __map_region(md, *efi_va);
+ md->virt_addr = *efi_va;
}
/*
--
1.8.4.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: [Question]Why a skb with frag_list causes BUG_ON in function skb_segment
cc netdev for more experts
On 07/28/2015 04:53 PM, Zhangjie (HZ) wrote:
>
> Hi,
>
> I generate a skb as follows:
>
> It has a linear data region, 17 frags and the last fragment is in
> skb_shinfo(skb)->frag_list.
>
> Before this skb is sent to driver, dev_hard_start_xmit() will segment
> it first(skb has frag_list,
>
> so we get true from netif_needs_gso()), then the skb is passed to
> function skb_segment().
>
> Then, BUG_ON() happened.
>
> while (pos < offset + len) {
>
> if (i >= nfrags) {
>
> BUG_ON(skb_headlen(list_skb));(skbuff.c:3120)
>
> …
>
> }
>
> …
>
> }
>
> A skb that has no frags but frag_list also causes BUG_ON().
>
> I wonder if skb like follows is legal? Could skb in frag_list have
> linear data region?
>
>
>
>
>
> Thanks
>
> Zhangjie
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Initial support for user namespace owned mounts
On Tue, Jul 28, 2015 at 11:40 PM, Seth Forshee
wrote:
>
> On Wed, Jul 22, 2015 at 05:05:17PM -0700, Casey Schaufler wrote:
> > > This is what I currently think you want for user ns mounts:
> > >
> > > 1. smk_root and smk_default are assigned the label of the backing
> > > device.
Seth,
There were 2 main concerns discussed in this thread:
1. trusting LSM labels outside the namespace
2. trusting the content of the image file/loopdev
While your approach addresses the first concern, I suspect it may be placing
an obstacle in a way for resolving the second concern.
A viable security policy to mitigate the second concern could be:
- Allow only trusted programs (e.g. mkfs, fsck) to write to 'Loopback' images
- Allow mount only of 'Loopback' images
This should allow the system as a whole to trust unprivileged mounts based on
the trust of the entities that had raw access the the fs layout.
Alas, if you choose to propagate the backing dev label to contained files,
they would all share the designated 'Loopback' label and render the policy above
useless.
Any thoughts on how to reconcile this conflict?
Amir.
> > > 2. s_root is assigned the transmute property.
> > > 3. For existing files:
> > > a. Files with the same label as the backing device are accessible.
> > > b. Files with any other label are not accessible.
> >
> > That's right. Accept correct data, reject anything that's not right.
> >
> > > If this is right, there are a couple lingering questions in my mind.
> > >
> > > First, what happens with files created in directories with the same
> > > label as the backing device but without the transmute property set? The
> > > inode for the new file will initially be labeled with smk_of_current(),
> > > but then during d_instantiate it will get smk_default and thus end up
> > > with the label we want. So that seems okay.
> >
> > Yes.
> >
> > > The second is whether files with the SMACK64EXEC attribute is still a
> > > problem. It seems it is, for files with the same label as the backing
> > > store at least. I think we can simply skip the code that reads out this
> > > xattr and sets smk_task for user ns mounts, or else skip assigning the
> > > label to the new task in bprm_set_creds. The latter seems more
> > > consistent with the approach you've suggested for dealing with labels
> > > from disk.
> >
> > Yes, I think that skipping the smk_fetch(XATTR_NAME_SMACKEXEC, ...) in
> > smack_d_instantiate for unprivileged mounts would do the trick.
> >
> > > So I guess all of that seems okay, though perhaps a bit restrictive
> > > given that the user who mounted the filesystem already has full access
> > > to the backing store.
> >
> > In truth, there is no reason to expect that the "user" who did the
> > mount will ever have a Smack label that differs from the label of
> > the backing store. If what we've got here seems restrictive, it's
> > because you've got access from someone other than the "user".
> >
> > > Please let me know whether or not this matches up with what you are
> > > thinking, then I can procede with the implementation.
> >
> > My current mindset is that, if you're going to allow unprivileged
> > mounts of user defined backing stores, this is as safe as we can
> > make it.
>
> All right, I've got a patch which I think does this, and I've managed to
> do some testing to confirm that it behaves like I expect. How does this
> look?
>
> What's missing is getting the label from the block device inode; as
> Stephen discovered the inode that I thought we could get the label from
> turned out to be the wrong one. Afaict we would need a new hook in order
> to do that, so for now I'm using the label of the proccess calling
> mount.
>
> ---
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index a143328f75eb..8e631a66b03c 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -662,6 +662,8 @@ static int smack_sb_kern_mount(struct super_block *sb,
> int flags, void *data)
> skp = smk_of_current();
> sp->smk_root = skp;
> sp->smk_default = skp;
> + if (sb_in_userns(sb))
> + transmute = 1;
> }
> /*
> * Initialize the root inode.
> @@ -1023,6 +1025,12 @@ static int smack_inode_permission(struct inode *inode,
> int mask)
> if (mask == 0)
> return 0;
>
> + if (sb_in_userns(inode->i_sb)) {
> + struct superblock_smack *sbsp = inode->i_sb->s_security;
> + if (smk_of_inode(inode) != sbsp->smk_root)
> + return -EACCES;
> + }
> +
> /* May be droppable after audit */
> if (no_block)
> return -ECHILD;
> @@ -3220,14 +3228,16 @@ static void smack_d_instantiate(struct dentry
> *opt_dentry, struct inode *inode)
> if (rc >= 0)
> transflag = SMK_INODE_TRANSMUTE;
>
Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack
On Wed, Jul 29, 2015 at 10:57:26AM -0700, Andy Lutomirski wrote: > OK if I do that as a follow-up? It would probably want to be a > separate patch anyway. Of course. > Hmm, I'm starting to like this new regime in which we never ever > switch to user mode from anywhere other than the standard kernel > stack. It looks like even Xen may play along and do it cleanly soon > :) Maybe I'll even add an assertion somewhere to make sure we don't > break it. (I think this also means that the bad iret fixup can be > simplified.) Definitely sounds like a nice, logical thing. We sometimes switch stacks to land on the kernel stack before returning to user mode (IST and all) but I guess that's a clean enough thing to do. Oh, and only a couple of insns so yeah. > Also, with all this stuff applied (and the modify_ldt thing, once the > Xen folks figure out what's wrong), I think we can reinstate the old > LARL check for 16-bit segments and thus prevent naughty users from > banging on espfix using only sigreturn. Uuh, and then only check ZF. I guess this should cover all the legacy cases, which is nice. Yeah, sounds coolio. :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the block tree
Hi Jens,
After merging the block tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0,
from
drivers/staging/lustre/lustre/llite/../include/lustre_cfg.h:225,
from
drivers/staging/lustre/lustre/llite/../include/lustre_lib.h:55,
from drivers/staging/lustre/lustre/llite/lloop.c:105:
drivers/staging/lustre/lustre/llite/lloop.c: In function 'loop_handle_bio':
drivers/staging/lustre/lustre/llite/../include/linux/lustre_compat25.h:89:35:
error: too many arguments to function 'bio_endio'
#define cfs_bio_endio(a, b, c)bio_endio((a), (c))
^
drivers/staging/lustre/lustre/llite/lloop.c:379:3: note: in expansion of macro
'cfs_bio_endio'
cfs_bio_endio(bio, bio->bi_iter.bi_size, ret);
^
In file included from include/linux/blkdev.h:18:0,
from drivers/staging/lustre/lustre/llite/lloop.c:91:
include/linux/bio.h:442:13: note: declared here
extern void bio_endio(struct bio *);
^
Caused by commit
4246a0b63bd8 ("block: add a bi_error field to struct bio")
I added the following fix patch, but more is probably required:
From: Stephen Rothwell
Date: Thu, 30 Jul 2015 14:10:57 +1000
Subject: [PATCH] block: lustre: temporary fix for bio_endio API change
Signed-off-by: Stephen Rothwell
---
drivers/staging/lustre/lustre/include/linux/lustre_compat25.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 513c81f43d6e..1aac5a77c500 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -86,7 +86,7 @@
vfs_rename(old, old_dir, new, new_dir, NULL, 0)
#define cfs_bio_io_error(a, b) bio_io_error((a))
-#define cfs_bio_endio(a, b, c)bio_endio((a), (c))
+#define cfs_bio_endio(a, b, c)bio_endio((a))
#define cfs_path_put(nd) path_put(&(nd)->path)
--
2.4.6
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP
On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.
With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.
Cheers,
Benjamin
No, what i recommended was to do link training but in intel_dp_detect.
Since USB Type C cable
also has its own lane count restriction (it can have different lane
count than the one supported
by panel) you might have to figure that out as well. so both reversal
and lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.
Please find below the code to do the same. Do not waste time trying to
apply this directly on
nightly since this is based on a local tree and because this is pre-
atomic changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.
---
Author: Durgadoss R
Date: Fri May 22 14:30:07 2015 +0530
drm/i915: Enable Upfront link training for type-C DP support
To support USB type C alternate DP mode, the display driver needs
to know the
number of lanes required by DP panel as well as number of lanes
that can be
supported by the type-C cable. Sometimes, the type-C cable may
limit the
bandwidth even if Panel can support more lanes. To address these
scenarios,
the display driver will start link training with max lanes, and if
the link
training fails, the driver then falls back to x2 lanes.
* Since link training is done before modeset, planes are not
enabled. Only
encoder and the its associated PLLs are enabled.
* Once link training is done, the encoder and its PLLs are
disabled; so that
the subsequent modeset is not aware of these changes.
* As of now, this is tested only on CHV.
Signed-off-by: Durgadoss R
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0c8ae2a..c72dcaa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14793,3 +14793,121 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, " VSYNC: %08x\n", error->transcoder[i].vsync);
}
}
+
+bool chv_upfront_link_train(struct drm_device *dev,
+struct intel_dp *intel_dp, struct intel_crtc *crtc)
+{
+struct drm_i915_private *dev_priv = dev->dev_private;
+struct intel_connector *connector = intel_dp->attached_connector;
+struct intel_encoder *encoder = connector->encoder;
+bool found = false;
+bool valid_crtc = false;
+
+if (!connector || !encoder) {
+DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
+return false;
+}
+
+/* If we already have a crtc, start link training directly */
+if (crtc) {
+valid_crtc = true;
+goto start_link_train;
+}
+
+/* Find an unused crtc and use it for link training */
+for_each_intel_crtc(dev, crtc) {
+if (intel_crtc_active(>base))
+continue;
+
+connector->new_encoder = encoder;
+encoder->new_crtc = crtc;
+encoder->base.crtc = >base;
+
+/* Make sure the new crtc will work with the encoder */
+if (drm_encoder_crtc_ok(>base,
+ >base)) {
+found = true;
+break;
+}
+}
+
+if (!found) {
+DRM_ERROR("Could not find crtc for upfront link training\n");
+return false;
+}
+
+start_link_train:
+
+DRM_DEBUG_KMS("upfront link training on pipe:%c\n",
+pipe_name(crtc->pipe));
+found = false;
+
+/* Initialize with Max Link rate & lane count supported by panel */
+intel_dp->link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
+intel_dp->lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] &
+DP_MAX_LANE_COUNT_MASK;
+
+do {
+/* Find port clock from link_bw */
+crtc->config.port_clock =
+drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
+
+/* Enable PLL followed by port */
+intel_dp_set_clock(encoder, >config, intel_dp->link_bw);
+chv_update_pll(crtc);
+encoder->pre_pll_enable(encoder);
+chv_enable_pll(crtc);
+encoder->pre_enable(encoder);
+
+/* Check if
Re: Regression in v4.2-rc1 caused by hierarchical irqdomain changes
On 2015/7/30 5:03, Thomas Gleixner wrote: > On Mon, 27 Jul 2015, Matt Fleming wrote: >> [BAD] >> 3: 1 0 0 0 IR-IO-APIC 3-edge >> 6: 0 0 0 0 IR-IO-APIC 6-edge >> dw_dmac >> 7: 15 1 0 0 IR-IO-APIC 7-edge >> INT3432:00, INT3433:00 > > [GOOD] >> 3: 16 17 49 20 IR-IO-APIC-fasteoi >> AudioDSP, dw_dmac >> 6: 0 0 0 0 IR-IO-APIC-fasteoi >> dw_dmac >> 7: 2662 3072 12307 5419 IR-IO-APIC-fasteoi >> INT3432:00, INT3433:00 > > So the old code uses fasteoi while the new one uses edge. > > Jiang Sorry for the slow response. We have reproduced this regression on Surface Pro 3, but are still trying to figure out the root cause. Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] KVM: x86: store IOAPIC-handled vectors in each VCPU
On Wed, Jul 29, 2015 at 03:37:35PM +0200, Paolo Bonzini wrote:
> We can reuse the algorithm that computes the EOI exit bitmap to figure
> out which vectors are handled by the IOAPIC. The only difference
> between the two is for edge-triggered interrupts other than IRQ8
> that have no notifiers active; however, the IOAPIC does not have to
> do anything special for these interrupts anyway.
>
> This again limits the interactions between the IOAPIC and the LAPIC,
> making it easier to move the former to userspace.
>
> Inspired by a patch from Steve Rutherford.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/include/asm/kvm_host.h | 3 ++-
> arch/x86/kvm/ioapic.c | 18 ++
> arch/x86/kvm/ioapic.h | 8
> arch/x86/kvm/lapic.c| 10 --
> arch/x86/kvm/svm.c | 2 +-
> arch/x86/kvm/vmx.c | 3 ++-
> arch/x86/kvm/x86.c | 8 +++-
> 7 files changed, 18 insertions(+), 34 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 2f9e504f9f0c..d0e991ef6ef0 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -383,6 +383,7 @@ struct kvm_vcpu_arch {
> u64 efer;
> u64 apic_base;
> struct kvm_lapic *apic;/* kernel irqchip context */
> + u64 eoi_exit_bitmap[4];
> unsigned long apic_attention;
> int32_t apic_arb_prio;
> int mp_state;
> @@ -808,7 +809,7 @@ struct kvm_x86_ops {
> int (*vm_has_apicv)(struct kvm *kvm);
> void (*hwapic_irr_update)(struct kvm_vcpu *vcpu, int max_irr);
> void (*hwapic_isr_update)(struct kvm *kvm, int isr);
> - void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
> + void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
> void (*set_virtual_x2apic_mode)(struct kvm_vcpu *vcpu, bool set);
> void (*set_apic_access_page_addr)(struct kvm_vcpu *vcpu, hpa_t hpa);
> void (*deliver_posted_interrupt)(struct kvm_vcpu *vcpu, int vector);
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index eaf4ec38d980..2dcda0f188ba 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -233,19 +233,6 @@ static void kvm_ioapic_inject_all(struct kvm_ioapic
> *ioapic, unsigned long irr)
> }
>
>
> -static void update_handled_vectors(struct kvm_ioapic *ioapic)
> -{
> - DECLARE_BITMAP(handled_vectors, 256);
> - int i;
> -
> - memset(handled_vectors, 0, sizeof(handled_vectors));
> - for (i = 0; i < IOAPIC_NUM_PINS; ++i)
> - __set_bit(ioapic->redirtbl[i].fields.vector, handled_vectors);
> - memcpy(ioapic->handled_vectors, handled_vectors,
> -sizeof(handled_vectors));
> - smp_wmb();
> -}
> -
> void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> {
> struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
> @@ -310,7 +297,6 @@ static void ioapic_write_indirect(struct kvm_ioapic
> *ioapic, u32 val)
> e->bits |= (u32) val;
> e->fields.remote_irr = 0;
> }
> - update_handled_vectors(ioapic);
> mask_after = e->fields.mask;
> if (mask_before != mask_after)
> kvm_fire_mask_notifiers(ioapic->kvm,
> KVM_IRQCHIP_IOAPIC, index, mask_after);
> @@ -594,7 +580,6 @@ static void kvm_ioapic_reset(struct kvm_ioapic *ioapic)
> ioapic->id = 0;
> memset(ioapic->irq_eoi, 0x00, IOAPIC_NUM_PINS);
> rtc_irq_eoi_tracking_reset(ioapic);
> - update_handled_vectors(ioapic);
> }
>
> static const struct kvm_io_device_ops ioapic_mmio_ops = {
> @@ -623,8 +608,10 @@ int kvm_ioapic_init(struct kvm *kvm)
> if (ret < 0) {
> kvm->arch.vioapic = NULL;
> kfree(ioapic);
> + return ret;
> }
>
> + kvm_vcpu_request_scan_ioapic(kvm);
> return ret;
> }
>
> @@ -661,7 +648,6 @@ int kvm_set_ioapic(struct kvm *kvm, struct
> kvm_ioapic_state *state)
> memcpy(ioapic, state, sizeof(struct kvm_ioapic_state));
> ioapic->irr = 0;
> ioapic->irr_delivered = 0;
> - update_handled_vectors(ioapic);
> kvm_vcpu_request_scan_ioapic(kvm);
> kvm_ioapic_inject_all(ioapic, state->irr);
> spin_unlock(>lock);
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index 3dbd0e2aac4e..bf36d66a1951 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -73,7 +73,6 @@ struct kvm_ioapic {
> struct kvm *kvm;
> void (*ack_notifier)(void *opaque, int irq);
> spinlock_t lock;
> - DECLARE_BITMAP(handled_vectors, 256);
> struct rtc_status rtc_status;
> struct delayed_work eoi_inject;
> u32 irq_eoi[IOAPIC_NUM_PINS];
> @@ -98,13 +97,6 @@ static inline struct kvm_ioapic *ioapic_irqchip(struct kvm
> *kvm)
> return kvm->arch.vioapic;
> }
>
> -static inline bool
Re: [PATCH v2] kthread: Export kthread functions
> On Jul 29, 2015, at 18:34, Thomas Gleixner wrote: > > On Tue, 28 Jul 2015, Andrew Morton wrote: > >> On Tue, 28 Jul 2015 11:59:01 -0400 David Kershner >> wrote: >> >>> The s-Par visornic driver, currently in staging, processes a queue >>> being serviced by the an s-Par service partition. We can get a message >>> that something has happened with the Service Partition, when that >>> happens, we must not access the channel until we get a message that the >>> service partition is back again. >>> >>> The visornic driver has a thread for processing the channel, when we >>> get the message, we need to be able to park the thread and then resume >>> it when the problem clears. >>> >>> We can do this with kthread_park and unpark but they are not exported >>> from the kernel, this patch exports the needed functions. >>> >>> Signed-off-by: David Kershner >> >> Please accumulate the acked-by's and reviewed-by's in the changelog as >> they are received. I presently have >> >> Acked-by: Ingo Molnar >> Acked-by: Neil Horman >> Cc: Thomas Gleixner >> Cc: Richard Weinberger >> Cc: Tejun Heo >> >> >> I'll scoot this into mainline probably this week to make life simpler >> for the various trees. > i am curious why not make some tiny functions to be inline ? so that don’t need EXPORT_SYMOBLS , shrink the kernel size. 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] bus: subsys: propagate errors from subsys interface's ->add_dev()
On 30-07-15, 01:29, Rafael J. Wysocki wrote: > > > There is a small problem with it that I've already pointed out to Viresh. > > > > > > Namely, while changing subsys_interface_(un)register() to handle return > > > values from ->add_dev(), it doesn't do the same thing in > > > bus_probe_device() > > > which I believe it should for consistency at least. > > > > Oops, sorry, missed that response. I'll go drop this patch then, thanks > > for letting me know. It was discussed in last 2-3 days over a cpufreq related thread, no way you could have caught that :) But, I think we should keep this patch until the time we find a better solution to our problem. You are the driver core maintainer and probably no one can give a better suggestion to fix our problem, so lemme explain that again here :) A platform specific cpufreq driver may depend on a external driver (say i2c which may control access to regulators) for its working, and until the time regulator is up along with i2c we need to defer cpufreq driver from being registered. We already have an EPROBE_DEFER mechanism to handle such situations nicely. cpufreq core calling sequence at a glance: cpufreq_register_driver() -> subsys_interface_register() -> subsys->add_dev() for all present CPUs one by one -> cpufreq_add_dev() -> cpufreq_driver->init() Now init() is the only location where the drivers initialize per policy (group of CPUs that share clock/voltage rails) stuff and can check if all the resources like clk/regulator are available or not. And so -EPROBE_DEFER will be returned from here. The only broken part here is the return value of subsys->add_dev() and that I tried to fix. Another important part here is that the cpufreq driver isn't probed against a cpu device, but a dummy platform device to get the EPROBE_DEFER story right, plus there are few other issues that it solves, like probing the right cpufreq driver. Now, please explain a sane way to get things working for such platforms. > > > But then, the question is whether or not the probing should fail and > > > what if device_attach() returns 0 and one of the ->add_dev() callbacks > > > returns an error. > > > > That's a total mess... Right and so modifying that to propagate return value wouldn't be that straight forward. > > Given that there are almost no uses of this api, I think people should > > work it out before any more start to pop up :) > > cpufreq is one of the users and that's where the problem is, but in my opinion > it should be addressed in a different way. > > But while we are at it, should the ->add_dev and ->remove_dev callbacks in > struct subsys_interface return an int if their return values are always > ignored? Maybe it would be better to redefine them to be void to make it > clear > that they can't fail? For remove_dev(), surely a void return type will make sense. I can put some effort to get that done. But not sure about add_dev() yet. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/11] stm class: Introduce an abstraction for System Trace Module devices
On Wed, Jul 29, 2015 at 9:46 PM, Alexander Shishkin wrote: > Mark Brown writes: > >> On Wed, Jul 29, 2015 at 04:25:10PM +0300, Alexander Shishkin wrote: >> >>> There has to be a way to defer stm_probe(), although a quick look at >>> amba code suggests it's not implemented. >> >> What makes you say this? Probe deferral is implemented in the driver >> core rather than individual buses, the buses don't need to know anything >> about it. > > I stand corrected, it indeed is. > > So returning EPROBE_DEFER from stm_probe() should Just Work (provided > stm_probe() handles its error paths correctly). If let stm_probe() implement probe deferral, it has to have a global variable for the later calling of "stm_register_device", because the first parameter of "stm_register_device" is " struct device * " which comes from amba_probe(), after finished amba_probe(), we may not get this structure by other means. This was a similar policy that we both thought was not good :) > > Regards, > -- > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: x86: set TMR when the interrupt is accepted
On Wed, Jul 29, 2015 at 03:37:34PM +0200, Paolo Bonzini wrote:
> Do not compute TMR in advance. Instead, set the TMR just before the interrupt
> is accepted into the IRR. This limits the coupling between IOAPIC and LAPIC.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/ioapic.c | 9 ++---
> arch/x86/kvm/ioapic.h | 3 +--
> arch/x86/kvm/lapic.c | 19 ++-
> arch/x86/kvm/lapic.h | 1 -
> arch/x86/kvm/x86.c| 5 +
> 5 files changed, 14 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index 856f79105bb5..eaf4ec38d980 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -246,8 +246,7 @@ static void update_handled_vectors(struct kvm_ioapic
> *ioapic)
> smp_wmb();
> }
>
> -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> - u32 *tmr)
> +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> {
> struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
> union kvm_ioapic_redirect_entry *e;
> @@ -260,13 +259,9 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64
> *eoi_exit_bitmap,
> kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC,
> index) ||
> index == RTC_GSI) {
> if (kvm_apic_match_dest(vcpu, NULL, 0,
> - e->fields.dest_id, e->fields.dest_mode)) {
> + e->fields.dest_id, e->fields.dest_mode))
> __set_bit(e->fields.vector,
> (unsigned long *)eoi_exit_bitmap);
> - if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG)
> - __set_bit(e->fields.vector,
> - (unsigned long *)tmr);
> - }
> }
> }
> spin_unlock(>lock);
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index ca0b0b4e6256..3dbd0e2aac4e 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -120,7 +120,6 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
> kvm_lapic *src,
> struct kvm_lapic_irq *irq, unsigned long *dest_map);
> int kvm_get_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> - u32 *tmr);
> +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
>
> #endif
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 2a5ca97c263b..9be64c77d6db 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -551,15 +551,6 @@ static void pv_eoi_clr_pending(struct kvm_vcpu *vcpu)
> __clear_bit(KVM_APIC_PV_EOI_PENDING, >arch.apic_attention);
> }
>
> -void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr)
> -{
> - struct kvm_lapic *apic = vcpu->arch.apic;
> - int i;
> -
> - for (i = 0; i < 8; i++)
> - apic_set_reg(apic, APIC_TMR + 0x10 * i, tmr[i]);
> -}
> -
> static void apic_update_ppr(struct kvm_lapic *apic)
> {
> u32 tpr, isrv, ppr, old_ppr;
> @@ -781,6 +772,9 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
> delivery_mode,
> case APIC_DM_LOWEST:
> vcpu->arch.apic_arb_prio++;
> case APIC_DM_FIXED:
> + if (unlikely(trig_mode && !level))
> + break;
> +
> /* FIXME add logic for vcpu on reset */
> if (unlikely(!apic_enabled(apic)))
> break;
> @@ -790,6 +784,13 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
> delivery_mode,
> if (dest_map)
> __set_bit(vcpu->vcpu_id, dest_map);
>
> + if (apic_test_vector(vector, apic->regs + APIC_TMR) !=
> !!trig_mode) {
> + if (trig_mode)
> + apic_set_vector(vector, apic->regs + APIC_TMR);
> + else
> + apic_clear_vector(vector, apic->regs +
> APIC_TMR);
> + }
> +
> if (kvm_x86_ops->deliver_posted_interrupt)
> kvm_x86_ops->deliver_posted_interrupt(vcpu, vector);
> else {
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index 764037991d26..eb46d6bcaa75 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -57,7 +57,6 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value);
> u64 kvm_lapic_get_base(struct kvm_vcpu *vcpu);
> void kvm_apic_set_version(struct kvm_vcpu *vcpu);
>
> -void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr);
> void __kvm_apic_update_irr(u32 *pir, void *regs);
> void kvm_apic_update_irr(struct kvm_vcpu *vcpu, u32 *pir);
> int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_lapic_irq *irq,
> diff
Re: [PATCH 4/4] KVM: x86: clean/fix memory barriers in irqchip_in_kernel
On Wed, Jul 29, 2015 at 03:28:58PM +0200, Paolo Bonzini wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 2d62229aac26..23e47a0b054b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3626,30 +3626,25 @@ long kvm_arch_vm_ioctl(struct file *filp,
> r = kvm_ioapic_init(kvm);
> if (r) {
> mutex_lock(>slots_lock);
> - kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS,
> - >dev_master);
> - kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS,
> - >dev_slave);
> - kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS,
> - >dev_eclr);
> + kvm_destroy_pic(vpic);
> mutex_unlock(>slots_lock);
> - kfree(vpic);
> goto create_irqchip_unlock;
> }
> } else
> goto create_irqchip_unlock;
> - smp_wmb();
> - kvm->arch.vpic = vpic;
> - smp_wmb();
> r = kvm_setup_default_irq_routing(kvm);
> if (r) {
> mutex_lock(>slots_lock);
> mutex_lock(>irq_lock);
> kvm_ioapic_destroy(kvm);
> - kvm_destroy_pic(kvm);
> + kvm_destroy_pic(vpic);
> mutex_unlock(>irq_lock);
> mutex_unlock(>slots_lock);
> + goto create_irqchip_unlock;
> }
> + /* Write kvm->irq_routing before kvm->arch.vpic. */
> + smp_wmb();
I assume this pairs with irqchip_in_kernel?
> + kvm->arch.vpic = vpic;
> create_irqchip_unlock:
> mutex_unlock(>lock);
> break;
> --
> 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] bus: subsys: propagate errors from subsys interface's ->add_dev()
On 29-07-15, 14:19, Greg KH wrote: > I don't see how this is a stable bug fix, what is resolved by it that > doesn't work today? Is there some code that is expecting this > functionality that has never been present? > > I'll go queue it up, but I don't think it is -stable material, but feel > free to change my mind. Yeah, probably its a bit overdone. Leave the stable thing for now.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/22] platform: delay device-driver matches until late_initcall
On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
wrote:
> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some drivers not having registered
> yet.
>
> The reason why only platform devices are delayed is that some other
> devices are expected to be probed earlier than late_initcall, for
> example, the system PNP driver needs to probe its devices in
> fs_initcall.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> Changes in v2:
> - Move delay to platform.c
>
> drivers/base/platform.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 063f0ab15259..fcf654678e27 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -33,6 +33,8 @@
> /* For automatically allocated device IDs */
> static DEFINE_IDA(platform_devid_ida);
>
> +static bool enable_matches;
> +
> struct device platform_bus = {
> .init_name = "platform",
> };
> @@ -839,6 +841,15 @@ static int platform_match(struct device *dev, struct
> device_driver *drv)
> struct platform_device *pdev = to_platform_device(dev);
> struct platform_driver *pdrv = to_platform_driver(drv);
>
> + /*
> +* Delay matches of platform devices until late_initcall, when we are
> +* sure that all built-in drivers have been registered already. This
> +* is needed to prevent deferred probes because of some drivers
> +* not having registered yet.
> +*/
> + if (!enable_matches)
> + return false;
> +
Having this as a global makes me nervous. I think it would be better
to be DT specific or per device some how. Perhaps use OF_POPULATED_BUS
flag as an additional test.
There could be non-DT platforms that rely on the initcall ordering and
moving all probes to late_initcall could change the ordering. I'm not
sure though.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/11] stm class: Introduce an abstraction for System Trace Module devices
On Wed, Jul 29, 2015 at 9:25 PM, Alexander Shishkin
wrote:
> Chunyan Zhang writes:
>
>>> +/**
>>> + * stm_source_register_device() - register an stm_source device
>>> + * @parent:parent device
>>> + * @data: device description structure
>>> + *
>>> + * This will create a device of stm_source class that can write
>>> + * data to an stm device once linked.
>>> + *
>>> + * Return: 0 on success, -errno otherwise.
>>> + */
>>> +int stm_source_register_device(struct device *parent,
>>> + struct stm_source_data *data)
>>> +{
>>> + struct stm_source_device *src;
>>> + int err;
>>> +
>>> + if (!stm_core_up)
>>> + return -EPROBE_DEFER;
>>> +
>>
>> I tried to update Coresight-stm driver[1] based on your this version
>> patch, but the Coresight-stm driver probe() failed.
>> the reason was:
>> In the end of Coresight stm_probe(), we called this function, but
>> "stm_core_up" was zero then, so the error returned value
>> "-EPROBE_DEFER" was received.
>
> Yes, that is the intended behavior if stm core is not initialized yet.
>
>> In fact, "stm_core_up" would increase itself until "stm_core_init" be
>> called - it's the root of this problem, I'll explain this where the
>> function "stm_core_init" defined.
>
> I'm sorry, I didn't understand this, can you rephrase?
Sure, I mean, the root reason of this problem is here ( i.e.
"stm_core_up" was zero then):
if (!stm_core_up)
return -EPROBE_DEFER;
Why it was zero?
Because the function (i.e. stm_core_init() ) in which "stm_core_up"
would be added one hasn't been executed at this moment. It would be
executed on module_init stage for you this version of patch.
>
>> And redoing Coresight stm_probe() will incur a WARN_ON() like below:
>>
>> [1.075746] coresight-stm 10006000.stm: stm_register_device failed
>> [1.082118] [ cut here ]
>> [1.086819] WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:657
>> clk_core_disable+0x138/0x13c()
>> [1.095353] Modules linked in:
>> [1.098487] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G S
>> 4.2.0-rc1+ #107
>> [1.106398] Hardware name: Spreadtrum SC9836 Openphone Board (DT)
>> [1.112678] Call trace:
>> [1.115194] [] dump_backtrace+0x0/0x138
>> [1.120761] [] show_stack+0x1c/0x28
>> [1.125972] [] dump_stack+0x84/0xc8
>> [1.131179] [] warn_slowpath_common+0xa4/0xdc
>> [1.137285] [] warn_slowpath_null+0x34/0x44
>> [1.143213] [] clk_core_disable+0x134/0x13c
>
> Well, like I said in the offline thread, this has to do with cleaning up
> in the error path of stm_probe(). What happens if stm_probe() fails for
> any other reason? I'm guessing the same warning.
The reason of this warning is:
After stm_probe() failed, clk_core_disable() would be called from
amba_put_disable_pclk(), then WARN_ON() happened:
if (WARN_ON(core->enable_count == 0))
return;
I'm guessing the reason why "core->enable_count" was 0 at this moment is:
I don't know who created a thread to process the
amba_pm_runtime_suspend(), in which clk_core_disable() was already
called, "core->enable_count" was, of course, cleared to zero then.
And this thread run before amba_put_disable_pclk(pcdev) which is just
the one called from amba_probe() after
"->probe"(i.e. stm_probe in this case) returning a non-zero value.
In a word, if clk_core_disable() is called again after
"core->enable_count" has already been cleared to zero in the first
round of clk_core_disable()'s.
As such, the WARN_ON occurred.
>
>>> +static int __init stm_core_init(void)
>>> +{
>>> + int err;
>>> +
>>> + err = class_register(_class);
>>> + if (err)
>>> + return err;
>>> +
>>> + err = class_register(_source_class);
>>> + if (err)
>>> + goto err_stm;
>>> +
>>> + err = stp_configfs_init();
>>> + if (err)
>>> + goto err_src;
>>> +
>>> + init_srcu_struct(_source_srcu);
>>> +
>>> + stm_core_up++;
>>> +
>>> + return 0;
>>> +
>>> +err_src:
>>> + class_unregister(_source_class);
>>> +err_stm:
>>> + class_unregister(_class);
>>> +
>>> + return err;
>>> +}
>>> +
>>> +module_init(stm_core_init);
>>
>> Since you are using module_init() instead of postcore_initcall() which
>> was in the last version patch, as such, this function would be
>> executed after Coresight "stm_probe" finished.
>
> Yes, iirc on arm the initcall order somehow forced postcore
> stm_core_init() before configfs, which it relies on, causing a
> crash. Now I see that somebody hacked configfs to start at core_initcall
> (f5b697700c8) instead.
>
> There has to be a way to defer stm_probe(), although a quick look at
> amba code suggests it's not implemented.
>
>> So, we think there a few optional solutions:
>> 1) Remove the "stm_register_device" out from Coresight "stm_probe",
>> but we have to save another global variable:
>>
>> struct device *stm_dev;
>>
>> in the
linux-next: manual merge of the block tree with the f2fs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/f2fs/data.c
between commit:
8e5b935bf1ce ("f2fs: maintain extent cache in separated file")
from the f2fs tree and commit:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/f2fs/data.c
index 111f180fd1d2,8f0baa7ffb50..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -27,7 -26,10 +27,7 @@@
#include "trace.h"
#include
- static void f2fs_read_end_io(struct bio *bio, int err)
-static struct kmem_cache *extent_tree_slab;
-static struct kmem_cache *extent_node_slab;
-
+ static void f2fs_read_end_io(struct bio *bio)
{
struct bio_vec *bvec;
int i;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the ext3 tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
block/bounce.c
between commit:
a3ad0a9da863 ("block: Remove forced page bouncing under IO")
from the ext3 tree and commit:
b7c44ed9d2fc ("block: manipulate bio->bi_flags through helpers")
from the block tree.
I fixed it up (the former removed some of the code updated by the latter)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc block/bounce.c
index 31cad13a0c9d,2c310ea007ee..
--- a/block/bounce.c
+++ b/block/bounce.c
@@@ -160,24 -161,42 +161,24 @@@ static void __bounce_end_io_read(struc
{
struct bio *bio_orig = bio->bi_private;
- if (test_bit(BIO_UPTODATE, >bi_flags))
+ if (!bio->bi_error)
copy_to_high_bio_irq(bio_orig, bio);
- bounce_end_io(bio, pool, err);
+ bounce_end_io(bio, pool);
}
- static void bounce_end_io_read(struct bio *bio, int err)
+ static void bounce_end_io_read(struct bio *bio)
{
- __bounce_end_io_read(bio, page_pool, err);
+ __bounce_end_io_read(bio, page_pool);
}
- static void bounce_end_io_read_isa(struct bio *bio, int err)
+ static void bounce_end_io_read_isa(struct bio *bio)
{
- __bounce_end_io_read(bio, isa_page_pool, err);
+ __bounce_end_io_read(bio, isa_page_pool);
}
-#ifdef CONFIG_NEED_BOUNCE_POOL
-static int must_snapshot_stable_pages(struct request_queue *q, struct bio
*bio)
-{
- if (bio_data_dir(bio) != WRITE)
- return 0;
-
- if (!bdi_cap_stable_pages_required(>backing_dev_info))
- return 0;
-
- return bio_flagged(bio, BIO_SNAP_STABLE);
-}
-#else
-static int must_snapshot_stable_pages(struct request_queue *q, struct bio
*bio)
-{
- return 0;
-}
-#endif /* CONFIG_NEED_BOUNCE_POOL */
-
static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
- mempool_t *pool, int force)
+ mempool_t *pool)
{
struct bio *bio;
int rw = bio_data_dir(*bio_orig);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/22] ACPI: add acpi_dev_get_device()
On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso wrote: > This function is just a getter for struct acpi_device.dev and is needed > in the implementation of the fwnode API when building with !CONFIG_ACPI. > > Signed-off-by: Tomeu Vizoso > --- > > Changes in v2: > - Add acpi_dev_get_device() > > include/linux/acpi.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 01e6770d8e27..d1ad6c20c7e4 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -78,6 +78,11 @@ static inline void acpi_preset_companion(struct device > *dev, > ACPI_COMPANION_SET(dev, acpi_find_child_device(parent, addr, NULL)); > } > > +static inline struct device *acpi_dev_get_device(struct acpi_device *adev) get usually implies reference counting. Perhaps acpi_dev_to_device or acpi_dev_find_device. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] align crash_notes allocation to make it be inside one physical page
People reported that crash_notes in /proc/vmcore were corrupted and
this cause crash kdump failure. With code debugging and log we got
the root cause. This is because percpu variable crash_notes are
allocated in 2 vmalloc pages. As you know percpu is based on vmalloc
by default. Then vmalloc can't guarantee 2 continuous vmalloc pages
are also on 2 continuous physical pages. Then 1st kernel export the
starting addr and size, kdump kernel use the starting addr and size
to get the content of crash_notes, then 2nd part may not be in the
next neighbouring physical page as we think. That's why nhdr_ptr->n_namesz
or nhdr_ptr->n_descsz could be very huge in update_note_header_size_elf64()
and cause note header merging failure or some warnings.
In this patch change to call __alloc_percpu() to passed in the align
value which is nearest the the 2^log(sizeof(note_buf_t)). This align
value can make sure the crash_notes is allocated inside one physical
page since sizeof(note_buf_t) in all ARCHS is smaller PAGE_SIZE. But
add a WARN_ON in case it grow to be bigger than PAGE_SIZE in the future.
Signed-off-by: Baoquan He
---
kernel/kexec.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index a785c10..1740c42 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1620,7 +1620,16 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
static int __init crash_notes_memory_init(void)
{
/* Allocate memory for saving cpu registers. */
- crash_notes = alloc_percpu(note_buf_t);
+ size_t size, align;
+ int order;
+
+ size = sizeof(note_buf_t);
+ order = get_count_order(size);
+ align = 1<< order;
+
+ WARN_ON(size > PAGE_SIZE);
+
+ crash_notes = __alloc_percpu(size, align);
if (!crash_notes) {
pr_warn("Kexec: Memory allocation for saving cpu register
states failed\n");
return -ENOMEM;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
5677d67ae394 ("drm: Stop resetting connector state to unknown")
from Linus' tree and commit:
1c473be11958 ("drm: Fixup locking WARNINGs in drm_mode_config_reset")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/drm_crtc.c
index c91c18b2b1d4,7d02e32b4e94..
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -5273,9 -5273,14 +5273,11 @@@ void drm_mode_config_reset(struct drm_d
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);
+ mutex_lock(>mode_config.mutex);
- drm_for_each_connector(connector, dev) {
- connector->status = connector_status_unknown;
-
+ drm_for_each_connector(connector, dev)
if (connector->funcs->reset)
connector->funcs->reset(connector);
- }
+ mutex_unlock(>mode_config.mutex);
}
EXPORT_SYMBOL(drm_mode_config_reset);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] memory_failure: remove redundant check for the PG_HWPoison flag of 'hpage'
On Wed, 29 Jul 2015 09:17:32 +
Naoya Horiguchi wrote:
> # CC:ed linux-mm
>
> Hi Xiaoqiang,
>
> On Wed, Jul 29, 2015 at 03:52:46PM +0800, Wang Xiaoqiang wrote:
> > Hi,
> >
> > I find a little problem in the memory_failure function in
> > mm/memory-failure.c . Please check it.
> >
> > memory_failure: remove redundant check for the PG_HWPoison flag of
> > `hpage'.
> >
> > Since we have check the PG_HWPoison flag by `PageHWPoison' before,
> > so the later check by `TestSetPageHWPoison' must return true, there
> > is no need to check again!
>
> I'm afraid that this TestSetPageHWPoison is not redundant, because
> this code serializes the concurrent memory error events over the same
> hugetlb page (, where 'p' indicates the 4kB error page and 'hpage'
> indicates the head page.)
>
> When an error hits a hugetlb page, set_page_hwpoison_huge_page() sets
> PageHWPoison flags over all subpages of the hugetlb page in the
> ascending order of pfn. So if we don't have this TestSet, memory
> error handler can run more than once on concurrent errors when the
> 1st memory error hits (for example) the 100th subpage and the 2nd
> memory error hits (for example) the 50th subpage.
In your example, the 100th subage enter the memory
error handler firstly, and then it uses the
set_page_hwpoison_huge_page to set all subpages
with PG_HWPoison flag, the 50th page handler waits
for grab the lock_page(hpage) now.
When the 100th page handler unlock the 'hpage',
the 50th grab it, and now the 'hapge' has been
set with PG_HWPosison. So PageHWPoison micro
will return true, and the following code will
be executed:
if (PageHWPoison(hpage)) {
if ((hwpoison_filter(p) && TestClearPageHWPoison(p))
|| (p != hpage && TestSetPageHWPoison(hpage))) {
atomic_long_sub(nr_pages, _poisoned_pages);
unlock_page(hpage);
return 0;
}
}
Now 'p' is 50th subpage, it doesn't equal the
'hpage' obviously, so if we don't have TestSetPageHWPoison
here, it still will ignore the 50th error.
Why the memory error handler can run more than once?
Hope to receive from you!
thx,
Wang Xiaoqiang
>
> Thanks,
> Naoya Horiguchi
>
> > Signed-off-by: Wang Xiaoqiang
> > ---
> > mm/memory-failure.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index 1cf7f29..7794fd8 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1115,7 +1115,7 @@ int memory_failure(unsigned long pfn, int
> > trapno, int flags) lock_page(hpage);
> > if (PageHWPoison(hpage)) {
> > if ((hwpoison_filter(p) &&
> > TestClearPageHWPoison(p))
> > - || (p != hpage &&
> > TestSetPageHWPoison(hpage))) {
> > + || p != hpage) {
> > atomic_long_sub(nr_pages,
> > _poisoned_pages); unlock_page(hpage);
> > return 0;
> > --
> > 1.7.10.4
> >
> >
> >
> > --
> > thx!
> > Wang Xiaoqiang
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] soc: versatile: Use devm_kzalloc
On Wed, Jul 29, 2015 at 2:00 PM, Linus Walleij wrote: > On Tue, Jul 28, 2015 at 4:17 PM, Vaishali Thakkar > wrote: >> On 28 Jul 2015 17:35, "Linus Walleij" wrote: > >>> Reviewed-by: Linus Walleij >>> Please get this through ARM SoC or tell me if I should handle it. >> >> So, do you want me to send this in ARM SoC mailing list? > > linux-arm-ker...@lists.infradead.org is preferred, if you want > the ARM SoC maintainers to apply the patch directly not > that it has my Review tag, send it to a...@vger.kernel.org > and ask them to apply it. Ok. I will send this to linux-arm-ker...@lists.infradead.org with your Review tag. >>> Likely. There are sloppy errors everywhere. >> >> Can I go for handling them?? I am not sure how much important this driver >> is. > > Yes, and it's kind of important-ish since people look at > reference designs when doing other board support and the > realviews are also supported in QEMU making them kind > of popular. I see. Then I'll go for it. Thank You. > Yours, > Linus Walleij -- Vaishali -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] CMA: Don't return a valid cma for non-cma dev
When system(one x86 soc) boot, we saw many normal dma allocation requests
goes to cma area. The call chain is
dma_generic_alloc_coherent
dma_alloc_from_contiguous -- arch/x86/kernel/pci-dma.c
cma_alloc(dev_get_cma_area(dev), count, align)
Current dev_get_cma_area() will return a valid "cma" anyway. Then all
these requests will be taken as valid cma request, and get pages from
cma area, which has 2 problems:
1. make the cma area fragmented
2. confuse the cma reservation, usually cma memory size is set according
to the expectation of system scenario, these unexpected requests
will affect the designed cma usage.
So this patch will enforce the judgement, and only return valid "cma"
for real cma user, thus make normal user like IO device driver not
abuse cma reserved region.
Signed-off-by: Feng Tang
---
include/linux/dma-contiguous.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 569bbd0..d6ccc19 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -66,7 +66,8 @@ static inline struct cma *dev_get_cma_area(struct device *dev)
{
if (dev && dev->cma_area)
return dev->cma_area;
- return dma_contiguous_default_area;
+ else
+ return NULL;
}
static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
--
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 v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks
Hi Stephen, On Wed, 2015-07-29 at 17:27 -0700, Stephen Boyd wrote: > On 07/29, James Liao wrote: > > From: Sascha Hauer > > > > On the MT8173 the clocks are provided by different units. To enable > > the critical clocks we must be sure that all parent clocks are already > > registered, otherwise the parents of the critical clocks end up being > > unused and get disabled later. > > > > On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED > > PLLs as their parents, so we cannot enable the CLK_TOP critical clocks > > until the CLK_APMIXED clocks have all been registered. > > > > To find a place where all parents are registered we try each time > > after we've registered some clocks if all known providers are present > > now and only then we enable the critical clocks. > > > > Signed-off-by: Sascha Hauer > > Signed-off-by: James Liao > > --- > > Please move up to v4.2-rc2 so that this patch can be dropped. I > already applied this and sent it off to Linus so it's in -rc2. OK. I'll rebase to v4.2-rc2 in next patchset. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the nfsd tree with Linus' tree
On Wed, Jul 29, 2015 at 09:35:11PM -0400, Trond Myklebust wrote:
> Hi Stephen,
>
> On Wed, Jul 29, 2015 at 9:23 PM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the nfsd tree got a conflict in:
> >
> > fs/nfs/nfs42proc.c
> >
> > between commit:
> >
> > bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors")
> >
> > from Linus' tree and commit:
> >
> > 0183ae17c741 ("NFSv4.2: handle NFS-specific llseek errors")
> >
> > from the nfsd tree.
> >
> > The only difference here is that _nfs42_proc_llseek is static in the
> > former, so I used that.
Whoops, thanks, I shouldn't have even had that one in my tree
> Yes, I snuck that declaration into the patch since it was obvious that
> we would never want to export _nfs42_proc_llseek(), and because
> "sparse" complained. Apologies if that caused a conflict...
I actually noticed that, then noticed a bunch of other stuff there had
the same problem, then started to make a patch to fix all those in one
fell swoop, then decided I was being annoying and dropped it.
Um.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/bridge/br_multicast.c
between commit:
544586f742b4 ("bridge: mcast: give fast leave precedence over multicast
router and querier")
from the net tree and commit:
09cf0211f970 ("bridge: mdb: fill state in br_mdb_notify")
from the net-next tree.
I fixed it up (hopefully - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/bridge/br_multicast.c
index 0b39dcc65b94,fd238587e032..
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@@ -1424,31 -1441,6 +1440,32 @@@ br_multicast_leave_group(struct net_bri
if (!mp)
goto out;
+ if (port && (port->flags & BR_MULTICAST_FAST_LEAVE)) {
+ struct net_bridge_port_group __rcu **pp;
+
+ for (pp = >ports;
+ (p = mlock_dereference(*pp, br)) != NULL;
+ pp = >next) {
+ if (p->port != port)
+ continue;
+
+ rcu_assign_pointer(*pp, p->next);
+ hlist_del_init(>mglist);
+ del_timer(>timer);
++ br_mdb_notify(br->dev, port, group, RTM_DELMDB,
++p->state);
+ call_rcu_bh(>rcu, br_multicast_free_pg);
- br_mdb_notify(br->dev, port, group, RTM_DELMDB);
+
+ if (!mp->ports && !mp->mglist &&
+ netif_running(br->dev))
+ mod_timer(>timer, jiffies);
+ }
+ goto out;
+ }
+
+ if (timer_pending(_query->timer))
+ goto out;
+
if (br->multicast_querier) {
__br_multicast_send_query(br, port, >addr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[lkp] [mm] 112b650f83e: -6.8% will-it-scale.per_process_ops
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git master
commit 112b650f83e5ccea260708f8b7ca747580584659 ("mm: gup: make
get_user_pages_fast and __get_user_pages_fast latency conscious")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/test:
lkp-sbx04/will-it-scale/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/futex1
commit:
b7c3d6a0d545317e63ff58a1e60059ce79ac359e
112b650f83e5ccea260708f8b7ca747580584659
b7c3d6a0d545317e 112b650f83e5ccea260708f8b7
--
%stddev %change %stddev
\ |\
5155618 ± 0% -6.8%4806190 ± 0% will-it-scale.per_process_ops
1203105 ± 1% -3.0%1166790 ± 0% will-it-scale.per_thread_ops
18828 ± 11% +97.6% 37211 ± 5%
will-it-scale.time.involuntary_context_switches
80265 ± 8% -20.5% 63818 ± 11% numa-numastat.node0.numa_hit
18828 ± 11% +97.6% 37211 ± 5% time.involuntary_context_switches
3600 ± 3% +20.6% 4341 ± 5% vmstat.system.cs
227062 ± 3% +52.6% 346589 ± 1%
latency_stats.hits.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
5878405 ± 0% +19.7%7035430 ± 0%
latency_stats.sum.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
7597 ± 12% -36.0% 4860 ± 32% numa-meminfo.node0.AnonPages
5012 ± 50% +59.1% 7975 ± 31% numa-meminfo.node2.Mapped
12346 ± 14% +24.2% 15338 ± 3% numa-meminfo.node3.SReclaimable
3516 ± 3% +10.0% 3867 ± 3% slabinfo.kmalloc-2048.active_objs
20418 ± 3% -10.9% 18198 ± 5% slabinfo.kmalloc-256.active_objs
344.25 ± 6% -25.9% 255.00 ± 14% slabinfo.kmem_cache.active_objs
344.25 ± 6% -25.9% 255.00 ± 14% slabinfo.kmem_cache.num_objs
683.00 ± 4% -16.4% 571.00 ± 7%
slabinfo.kmem_cache_node.active_objs
752.00 ± 3% -14.9% 640.00 ± 7% slabinfo.kmem_cache_node.num_objs
1899 ± 12% -36.0% 1214 ± 32% numa-vmstat.node0.nr_anon_pages
113103 ± 8% -11.7% 99882 ± 4% numa-vmstat.node0.numa_hit
78508 ± 13% -16.9% 65214 ± 8% numa-vmstat.node0.numa_local
95.75 ± 24% -56.7% 41.50 ± 41% numa-vmstat.node2.nr_dirtied
1252 ± 50% +59.1% 1993 ± 31% numa-vmstat.node2.nr_mapped
93.25 ± 24% -57.1% 40.00 ± 44% numa-vmstat.node2.nr_written
3086 ± 14% +24.2% 3834 ± 3%
numa-vmstat.node3.nr_slab_reclaimable
2.26 ± 2% -36.9% 1.42 ± 2%
perf-profile.cpu-cycles.___might_sleep.__might_sleep.get_futex_key.futex_wake.do_futex
0.41 ± 5%+140.2% 0.98 ± 1%
perf-profile.cpu-cycles.___might_sleep.get_futex_key.futex_wake.do_futex.sys_futex
0.00 ± -1% +Inf% 3.65 ± 1%
perf-profile.cpu-cycles.___might_sleep.get_user_pages_fast.get_futex_key.futex_wake.do_futex
3.21 ± 2% -31.6% 2.20 ± 1%
perf-profile.cpu-cycles.__might_sleep.get_futex_key.futex_wake.do_futex.sys_futex
4.42 ± 1% -11.8% 3.90 ± 1%
perf-profile.cpu-cycles.get_futex_key_refs.isra.10.futex_wake.do_futex.sys_futex.entry_SYSCALL_64_fastpath
26.58 ± 0% +18.8% 31.59 ± 0%
perf-profile.cpu-cycles.get_user_pages_fast.get_futex_key.futex_wake.do_futex.sys_futex
14.18 ± 1% -9.6% 12.81 ± 0%
perf-profile.cpu-cycles.unlock_page.get_futex_key.futex_wake.do_futex.sys_futex
193.00 ± 55% -60.1% 77.00 ± 87%
sched_debug.cfs_rq[10]:/.blocked_load_avg
209.25 ± 51% -73.2% 56.00 ±107%
sched_debug.cfs_rq[10]:/.tg_load_contrib
0.50 ±100%+350.0% 2.25 ± 72%
sched_debug.cfs_rq[14]:/.nr_spread_over
65.00 ±154% -96.2% 2.50 ±100%
sched_debug.cfs_rq[15]:/.blocked_load_avg
81.00 ±124% -79.9% 16.25 ± 13%
sched_debug.cfs_rq[15]:/.tg_load_contrib
217.25 ± 96% -61.4% 83.75 ±167%
sched_debug.cfs_rq[17]:/.blocked_load_avg
219.75 ± 95% -60.8% 86.25 ±161%
sched_debug.cfs_rq[17]:/.tg_load_contrib
9485 ± 11% +16.1% 11016 ± 6%
sched_debug.cfs_rq[19]:/.tg_load_avg
9453 ± 12% +16.5% 11015 ± 6%
sched_debug.cfs_rq[20]:/.tg_load_avg
8076 ± 0% +13.7% 9178 ± 11%
sched_debug.cfs_rq[21]:/.avg->runnable_avg_sum
9442 ± 11% +16.6% 11010 ± 6%
sched_debug.cfs_rq[21]:/.tg_load_avg
175.00 ± 0% +13.4% 198.50 ± 11%
sched_debug.cfs_rq[21]:/.tg_runnable_contrib
9432 ± 12% +16.7% 11010 ± 6%
sched_debug.cfs_rq[22]:/.tg_load_avg
9473 ± 12% +15.9% 10977 ± 6%
sched_debug.cfs_rq[23]:/.tg_load_avg
175.00 ± 2% +7.7% 188.50 ± 5%
RE: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc
On Thu, 2015-07-30 at 5:21, Scott Wood wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, July 30, 2015 12:19 AM
> To: Zhao Qiang-B45475
> Cc: lau...@codeaurora.org; linux-kernel@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net;
> catalin.mari...@arm.com; Xie Xiaobo-R63061
> Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to
> genalloc
>
> On Tue, 2015-07-28 at 00:32 -0500, Zhao Qiang-B45475 wrote:
> > On Tue, 2015-07-28 at 5:21, Scott Wood wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, July 28, 2015 5:21 AM
> > > To: Zhao Qiang-B45475
> > > Cc: lau...@codeaurora.org; linux-kernel@vger.kernel.org; linuxppc-
> > > d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net;
> > > catalin.mari...@arm.com; Xie Xiaobo-R63061
> > > Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo
> > > to genalloc
> > >
> > > On Mon, 2015-07-27 at 17:57 +0800, Zhao Qiang wrote:
> > >
> > > Where's the part that adds the ability to pass in data to each
> > > allocation call, as per the previous discussion?
> >
> > You means to use gen_pool_alloc_data()?
>
> Yes.
>
> > Previously you said that the format of data is algorithm-specific, So
> > I think it is better to handle data in algorithm function.
>
> It is a channel for communication from the API caller to the algorithm.
>
> > If you still prefer gen_pool_alloc_data(), I will modify it.
> > But there still are details I want to confirm with you.
> > 1. If use gen_pool_alloc_data(), should I pass data as a parameter?
>
> Yes.
>
> > 2. Should I count align_mask in gen_pool_alloc_data(), meanwhile, add
> >a align_mask to data as a member?
>
> gen_pool_alloc_data() should just pass data to the algorithm. The
> algorithm should calculate align_mask based on align. I don't think
> exposing align_mask to API users would be very friendly.
If calculate align_mask in algorithm, I need to get pool->min_alloc_order in
algorithm,
Like:
order = data->pool->min_alloc_order;
align_mask = ((data->align + (1UL << order) - 1) >> order) - 1;
so I add pool to structure data as a member. Is there any other better idea?
>
> > 3. where to define the data, in genalloc.h or caller layer?
>
> Same place as where the algorithm function is declared.
>
> -Scott
>
-Zhao Qiang
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH RESEND 1/1] Staging: rtl8188eu: fixed newlines after declarations
This is a patch to the rtw_debug.c file that fixes styling errors relating to
new lines after variable declarations.
Signed-off-by: Dave Perez
---
drivers/staging/rtl8188eu/core/rtw_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core/rtw_debug.c
b/drivers/staging/rtl8188eu/core/rtw_debug.c
index bc3fe10..12beab0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_debug.c
+++ b/drivers/staging/rtl8188eu/core/rtw_debug.c
@@ -219,6 +219,7 @@ int proc_get_ht_option(char *page, char **start,
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
int len = 0;
+
len += snprintf(page + len, count - len, "ht_option=%d\n",
pmlmepriv->htpriv.ht_option);
*eof = 1;
return len;
@@ -588,6 +589,7 @@ int proc_set_rx_signal(struct file *file, const char __user
*buffer,
if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
int num = sscanf(tmp, "%u %u", _signal_dbg,
_strength);
+
is_signal_dbg = is_signal_dbg == 0 ? 0 : 1;
if (is_signal_dbg && num != 2)
return count;
--
2.4.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 v4 0/4] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter
On 7/29/15 5:08 PM, Daniel Borkmann wrote: On 07/28/2015 01:17 PM, Kaixu Xia wrote: Previous patch v3 url: https://lkml.org/lkml/2015/7/23/203 ... Kaixu Xia (3): bpf: Add new bpf map type to store the pointer to struct perf_event bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter samples/bpf: example of get selected PMU counter value Wang Nan (1): bpf: Make the bpf_prog_array_map more generic So kernel/bpf/ patches are usually going via netdev tree as main development happens there and to avoid cross tree conflicts, etc. Thus, please Cc also netdev in the next iterations. Maybe when these patches are in a perfect shape at some point, perf folks provide their Acked-by(s) to the series to give their consent, and then this should go via net-next? Or will this be organized differently? In this case it looks that amount of kernel/bpf/ changes is higher than perf related. Also it looks like addition of bpf_perf_event_read() helper also won't affect anything on perf side, so in this case I think net-next tree is indeed a better fit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC 2/3] x86: Add Intel PT logger
On 2015/07/29 18:09, Alexander Shishkin wrote: > Takao Indoh writes: > >> On 2015/07/29 15:08, Alexander Shishkin wrote: >>> Instead, we should be able to do use the existing perf functionality to >>> enable the system-wide tracing, so that it goes through the >> >> "existing driver" means PMU driver (perf_event_intel_pt.c)? > > Yes. > >> The feature of these patches is a sort of flight recorder. Once it >> starts, never stop, not export anything to user, it just captures data >> with minimum overhead in preparation for kernel panic. This usage is >> different from perf and therefore I'm not sure whether this feature can >> be implemented using perf infrastructure. > > Why not? There is an established infrastructure for in-kernel perf > events already, take a look at the nmi watchdog, for example. Ok, I'm reading the code around perf_event_create_kernel_counter. It seems to work for my purpose, I'll try to update my patch with this. Thanks, Takao Indoh > >>> driver. Another thing to remember is that you'd also need some of the >>> sideband data (vm mappings, context switches) to be able to properly >>> decode the trace, which also can come from perf. And it'd also be much >>> less code. The only missing piece is the code that would allocate the >>> ring buffer for such events. >> >> The sideband data is needed if we want to reconstruct user program flow, >> but is it needed to reconstruct kernel panic path? > > You are not really interested in the panic path as much as events > leading up to the panic and those usually have context, which is much > easier to reconstruct with sideband info. Some of it you can reconstruct > by walking kernel's data structures, but that is not reliable after the > panic. > > Regards, > -- > 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 4573/4573] Staging: rtl8188eu: fixed newlines after declarations
This is a patch to the rtw_debug.c file that fixes styling errors relating to
new lines after variable declarations.
Signed-off-by: Dave Perez
---
drivers/staging/rtl8188eu/core/rtw_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core/rtw_debug.c
b/drivers/staging/rtl8188eu/core/rtw_debug.c
index bc3fe10..12beab0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_debug.c
+++ b/drivers/staging/rtl8188eu/core/rtw_debug.c
@@ -219,6 +219,7 @@ int proc_get_ht_option(char *page, char **start,
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
int len = 0;
+
len += snprintf(page + len, count - len, "ht_option=%d\n",
pmlmepriv->htpriv.ht_option);
*eof = 1;
return len;
@@ -588,6 +589,7 @@ int proc_set_rx_signal(struct file *file, const char __user
*buffer,
if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
int num = sscanf(tmp, "%u %u", _signal_dbg,
_strength);
+
is_signal_dbg = is_signal_dbg == 0 ? 0 : 1;
if (is_signal_dbg && num != 2)
return count;
--
2.4.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][RESEND] btrfs: fix search key advancing condition
Hello, list.
Could any one take a look at on this? I believe this is a issue slowing
down ioctl(BTRFS_IOC_TREE_SEARCH) if the target key is missing.
On Tue, Jun 30, 2015 at 11:25 AM, Naohiro Aota wrote:
> The search key advancing condition used in copy_to_sk() is loose. It can
> advance the key even if it reaches sk->max_*: e.g. when the max key = (512,
> 1024, -1) and the current key = (512, 1025, 10), it increments the
> offset by 1, continues hopeless search from (512, 1025, 11). This issue
> make ioctl() to take unexpectedly long time scanning all the leaf a blocks
> one by one.
>
> This commit fix the problem using standard way of key comparison:
> btrfs_comp_cpu_keys()
>
> Signed-off-by: Naohiro Aota
> ---
> fs/btrfs/ioctl.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 1c22c65..07dc01d 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -1932,6 +1932,7 @@ static noinline int copy_to_sk(struct btrfs_root *root,
> u64 found_transid;
> struct extent_buffer *leaf;
> struct btrfs_ioctl_search_header sh;
> + struct btrfs_key test;
> unsigned long item_off;
> unsigned long item_len;
> int nritems;
> @@ -2015,12 +2016,17 @@ static noinline int copy_to_sk(struct btrfs_root
> *root,
> }
> advance_key:
> ret = 0;
> - if (key->offset < (u64)-1 && key->offset < sk->max_offset)
> + test.objectid = sk->max_objectid;
> + test.type = sk->max_type;
> + test.offset = sk->max_offset;
> + if (btrfs_comp_cpu_keys(key, ) >= 0)
> + ret = 1;
> + else if (key->offset < (u64)-1)
> key->offset++;
> - else if (key->type < (u8)-1 && key->type < sk->max_type) {
> + else if (key->type < (u8)-1) {
> key->offset = 0;
> key->type++;
> - } else if (key->objectid < (u64)-1 && key->objectid <
> sk->max_objectid) {
> + } else if (key->objectid < (u64)-1) {
> key->offset = 0;
> key->type = 0;
> key->objectid++;
> --
> 2.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] Introduce 64bit accessors and structures required to address y2038 issues in the posix_clock subsystem
This patch series change the 32-bit time types (timespec/itimerspec) to the 64-bit types (timespec64/itimerspec64), and add new 64bit accessor functions, which are required in order to avoid y2038 issues in the posix_clock subsystem. In order to avoid spamming people too much, I'm only sending the first few patches of the patch series, and left the other patches for later. And if you are interested in the whole patch series, see: https://git.linaro.org/people/baolin.wang/upstream_0627.git Thoughts and feedback would be appreciated. Changes since v1: - Modify the changelog. - Delete one patch without y2038 safe. Baolin Wang (5): time: Introduce struct itimerspec64 timekeeping: Introduce current_kernel_time64() security: Introduce security_settime64() time: Introduce do_sys_settimeofday64() time: Introduce timespec64_to_jiffies()/jiffies_to_timespec64() include/linux/jiffies.h | 22 +++--- include/linux/lsm_hooks.h |5 +++-- include/linux/security.h| 20 +--- include/linux/time64.h | 35 +++ include/linux/timekeeping.h | 24 +--- kernel/time/time.c | 28 +--- kernel/time/timekeeping.c |6 +++--- security/commoncap.c|2 +- security/security.c |2 +- 9 files changed, 117 insertions(+), 27 deletions(-) -- 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 v4 2/4] bpf: Add new bpf map type to store the pointer to struct perf_event
On 7/29/15 4:30 PM, Daniel Borkmann wrote: +if (map && map->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY && +func_id != BPF_FUNC_perf_event_read) this part belongs in patch 3, since patch 2 won't compile as-is. Please keep bi-sectability intact. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI
Hi,
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > Hi,
> > > >
> > > > > From: linux-kernel-ow...@vger.kernel.org
> > > > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro
> > > > > Kawai
> > > > > (2015/07/27 23:34), Michal Hocko wrote:
> > > > > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> > > > [...]
> > > > > > The check could be also relaxed a bit and nmi_panic would
> > > > > > return only if the ongoing panic is the current cpu when we really
> > > > > > have
> > > > > > to return and allow the preempted panic to finish.
> > > > >
> > > > > It's reasonable. I'll do that in the next version.
> > > >
> > > > I noticed atomic_read() is insufficient. Please consider the following
> > > > scenario.
> > > >
> > > > CPU 1: call panic() in the normal context
> > > > CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
> > > > CPU 1: set 1 to panic_cpu
> > > > CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
> > > > CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()
> > > >
> > > > At this point, since CPU 0 loops in NMI context, it never executes
> > > > the NMI handler registered by kdump_nmi_shootdown_cpus(). This means
> > > > that no register states are saved and no cleanups for VMX/SVM are
> > > > performed.
> > >
> > > Yes this is true but it is no different from the current state, isn't
> > > it? So if you want to handle that then it deserves a separate patch.
> > > It is certainly not harmful wrt. panic behavior.
> > >
> > > > So, we should still use atomic_cmpxchg() in nmi_panic() to
> > > > prevent other cpus from running panic routines.
> > >
> > > Not sure what you mean by that.
> >
> > I mean that we should use the same logic as my V2 patch like this:
> >
> > #define nmi_panic(fmt, ...)\
> >do {\
> >if (atomic_cmpxchg(_cpu, -1, raw_smp_processor_id()) \
> >== -1) \
> >panic(fmt, ##__VA_ARGS__); \
> >} while (0)
>
> This would allow to return from NMI too eagerly.
Yes, but what's the problem?
The root cause of your case hasn't been clarified yet.
I can't fix for an unclear issue because I don't know what's the right
solution.
> When I was testing my
> previous approach (on 3.0 based kernel) I had basically the same thing
> (one NMI to process panic) and others to return. This led to a strange
> behavior when the NMI button triggered NMI on all (hundreds) CPUs.
It's strange. Usually, NMI caused by NMI button is routed to only CPU 0
as an external NMI. External NMI for CPUs other than CPU 0 are masked
at boot time. Does it really happen? Does the problem still happen on
the latest kernel? What kind of NMI is deliverd to each CPU?
Traditionally, we should have assumed that NMI for crash dumping is
delivered to only one cpu. Otherwise, we should often fail to take
a proper crash dump. It seems that your case is another problem to be
solved separately.
> The
> crash kernel booted eventually but the log contained lockups when a
> CPU waited for an IPI to the CPU which was handling the NMI panic.
Could you explain more precisely?
> Anyway, I do not thing this is really necessary to solve the panic
> reentrancy issue.
> If the missing saved state is a real problem then it
> should be handled separately - maybe it can be achieved without an IPI
> and directly from the panic context if we are in NMI.
What I would like to do via this patchse is to solve race issues
among NMI, panic() and crash_kexec(). So, I don't think we should fix
that separately, although I would need to reword some descriptions
and titles.
Anyway, I'm going to sent out my revised version once in order to
tidy up. I also would like to hear kexec/kdump guys' opinions.
Regards,
Kawai
Re: [PATCH v4 1/4] bpf: Make the bpf_prog_array_map more generic
On 7/29/15 4:17 PM, Daniel Borkmann wrote: -if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY) +if (map->map_type >= BPF_MAP_TYPE_PROG_ARRAY) /* prog_array stores refcnt-ed bpf_prog pointers * release them all when user space closes prog_array_fd */ -bpf_prog_array_map_clear(map); +bpf_fd_array_map_clear(map); When we are going to add a new map type to the eBPF framework that is not an fd_array_map thing, this assumption of map->map_type >= BPF_MAP_TYPE_PROG_ARRAY might not hold then ... Also I think here changing == to >= is probably unnecessary. prog_array needs to do it because of circular dependency whereas perf_event_array cannot have it. Even when we attach bpf prog to perf_event and then add it to perf_event_array used by the same prog, right? Please test such scenario just in case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console
On 2015/07/29 22:35, Thomas Gleixner wrote: > On Wed, 29 Jul 2015, Peter Hurley wrote: >> On 07/29/2015 07:53 AM, Thomas Gleixner wrote: >>> On Wed, 29 Jul 2015, Peter Hurley wrote: On 07/29/2015 06:32 AM, Thomas Gleixner wrote: > On Wed, 29 Jul 2015, Taichi Kageyama wrote: >> - Keep interrupt disabled on the CPU which is used to detect >> an interrupt during the timeout of autoconfig_irq(). >> + Kick printk() on the CPU which detects interrupt >>from a console serial port. > > This is wrong to begin with. How is that supposed to work on an UP > machine? Not at all. > > So no, fix the code which has interrupts disabled accross autoprobing > and do not try to apply bandaids somewhere else. Like printk() from some unrelated driver? >>> >>> If that's the cause for the wreckage then yes, we need a way to tell >>> the printk code not to call into the driver until that initialization >>> step is done. It's that simple. >> >> Like this? > > Looks about right. Thomas, Thank you for your comments. The status of interrupt disabled should be short, but it cannot be controlled from autorpobing side. That's why I was thinking fixing autoprobing itself was better. However, I remember Peter also mentioned about your idea first. OK, I change my mind to fix the real problem simply. I actually have seen the problem caused only by "printk()" on RHEL. Peter, I know your code is sample (console.h is required), but it is conflict with [patch v2 1/3]. I think serial8250_console_write should not touch ctrl reg during autoconfig_irq. To resolve the real problem, I think keeping only [patch v2 1/3] is best(opt1). What do you think? opt1. keep [patch v2 1/3] + Don't touch other legacy drivers using autoprobe. Each driver can use console_lock to fix this problem if it happens. opt2. fix probe_irq_on/mask/off for all legacy devices which use them + Discard [patch v2 1/3] + Fix autoconfig_irq and probe_irq_* + Test for all these drivers is required. --> Probably, it works but I cannot test them. Thanks, Taichi > >> --- >% -- >> Subject: [PATCH] genirq: Disable printk() during irq probe >> >> printk() disables interrupts for extended periods of time while >> outputting to console drivers. This breaks irq probing since the >> triggered irq may not be serviced (in time) if scheduled on the >> printk() cpu. >> >> Claim the console_lock() which effectively disables console output. >> >> Signed-off-by: Peter Hurley >> --- >> kernel/irq/autoprobe.c | 9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/kernel/irq/autoprobe.c b/kernel/irq/autoprobe.c >> index 0119b9d..47535d2 100644 >> --- a/kernel/irq/autoprobe.c >> +++ b/kernel/irq/autoprobe.c >> @@ -39,6 +39,13 @@ unsigned long probe_irq_on(void) >> */ >> async_synchronize_full(); >> mutex_lock(_active); >> + >> +/* >> + * printk() breaks irq probing - disable printk output until probe >> + * completes >> + */ >> +console_lock(); >> + >> /* >> * something may have generated an irq long ago and we want to >> * flush such a longstanding irq before considering it as spurious. >> @@ -132,6 +139,7 @@ unsigned int probe_irq_mask(unsigned long val) >> } >> raw_spin_unlock_irq(>lock); >> } >> +console_unlock(); >> mutex_unlock(_active); >> >> return mask & val; >> @@ -174,6 +182,7 @@ int probe_irq_off(unsigned long val) >> } >> raw_spin_unlock_irq(>lock); >> } >> +console_unlock(); >> mutex_unlock(_active); >> >> if (nr_of_irqs > 1) >> -- >> 2.5.0 >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4573/4573] Staging: rtl8188eu: fixed newlines after declarations
On Wed, Jul 29, 2015 at 09:34:42PM -0400, Dave Perez wrote: > This is a patch to the rtw_debug.c file that fixes styling errors relating to > new lines after variable declarations. > > Signed-off-by: Dave Perez > --- > drivers/staging/rtl8188eu/core/rtw_debug.c | 2 ++ > 1 file changed, 2 insertions(+) Where are the 4572 other patches in this series? :) Can you please line-wrap your commit message, and fix up the patch numbering and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Wed, Jul 29, 2015 at 08:49:37PM -0400, Theodore Ts'o wrote: > > Unfortunately the failure causes a series of recursive faults and I > haven't been able to capture the stack trace, but on 4.2-rcX kernels, > I can reliably cause the system to crash if my T540p is booted with > the docking station attached. > > It will also crash if I boot the system first, and then insert the > laptop into the dockstation. > > Unfortunately, I can't get a stack trace because there are a huge > number of recursive/double faults, and the system dies so quickly that > nothing ends up in the log files. If you really need a stack dump I > can try to rig something, but modern Laptops don't have serial > consoles any more, alas, so it's bit of a pain. The bad news is that I tried to use kdump to capture a crashdump and hopefully get more information, and kdump utterly wedged on the panic. The good news is because it wedged the system, I was able to get the console stackdump before it scrolled off due to a whole series of recursive oops messages. It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9 Hopefully tihs is useful. It's not obvious how to revert this change, since there were a large number of changes to i915 after this. If someone could help me with a revert, I'd be happy to test it. Thanks, - Ted > > I was able to bisect it down to this commit, however: 8c7b5ccb72987: > "drm/i915: Use atomic helpers for computing changed flags:" > > Is there any chance Intel could add a Lenovo Dockstation with a > Multistream DP output to part of your test hardware? Unfortunately it > seems pretty common that I see regressions with my particular > hardware. Maybe there aren't enough people using Thinkpads any more? :-( > > - Ted > > > P.S. The git bisect log > > git bisect start > # bad: [421d125c06c4be4c5005cb69840206bd09b71dd6] builddeb: sign the modules > after splitting out the debuginfo files > git bisect bad 421d125c06c4be4c5005cb69840206bd09b71dd6 > # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 > git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 > # good: [aeaa2122af4e53f3bfd28e8f294557bb95af43fc] drm/i915/skl: Add the INIT > power domain to the MISC I/O power well > git bisect good aeaa2122af4e53f3bfd28e8f294557bb95af43fc > # bad: [4d70f38a760ad2879d2ebd84001c92980180f630] drm/i915/bios: remove a > redundant NULL pointer check > git bisect bad 4d70f38a760ad2879d2ebd84001c92980180f630 > # bad: [27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25] drm/i915/bxt: Enable > WaEnableYV12BugFixInHalfSliceChicken7 for Broxton > git bisect bad 27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25 > # good: [4be0731786de10d0e9ae1d159504c83c6b052647] drm/i915: Add crtc states > before calling compute_config() > git bisect good 4be0731786de10d0e9ae1d159504c83c6b052647 > # good: [d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1] drm/i915: Stage new > modeset state straight into atomic state > git bisect good d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1 > # bad: [a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10] drm/i915: Swap atomic state > in legacy modeset > git bisect bad a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10 > # bad: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic > helpers for computing changed flags > git bisect bad 8c7b5ccb729870e606321b3703e2c2e698c49a95 > # good: [0f63cca2afdc38877e86acfa9821020f6e2213fd] drm/i915: Update crtc > state active flag based on DPMS > git bisect good 0f63cca2afdc38877e86acfa9821020f6e2213fd > # good: [840bfe953384a134c8639f2964d9b74bfa671e16] drm/atomic: Make > mode_fixup() optional for check_modeset() > git bisect good 840bfe953384a134c8639f2964d9b74bfa671e16 > # first bad commit: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use > atomic helpers for computing changed flags > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] Input: max77693: Prepare for adding support for Maxim 77843
Prepare the driver for supporting two devices: Maxim 77693 and 77843:
1. Add table of device ids and store current device type for later
usage.
2. Differentiate the haptic device configuration.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Dmitry Torokhov
---
drivers/input/misc/max77693-haptic.c | 41 ++--
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/input/misc/max77693-haptic.c
b/drivers/input/misc/max77693-haptic.c
index 8dc43c1ebf0e..4c0f67ab66d9 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -47,6 +47,8 @@ enum max77693_haptic_pwm_divisor {
};
struct max77693_haptic {
+ enum max77693_types dev_type;
+
struct regmap *regmap_pmic;
struct regmap *regmap_haptic;
struct device *dev;
@@ -81,16 +83,23 @@ static int max77693_haptic_set_duty_cycle(struct
max77693_haptic *haptic)
static int max77693_haptic_configure(struct max77693_haptic *haptic,
bool enable)
{
- unsigned int value;
+ unsigned int value, config_reg;
int error;
- value = ((haptic->type << MAX77693_CONFIG2_MODE) |
- (enable << MAX77693_CONFIG2_MEN) |
- (haptic->mode << MAX77693_CONFIG2_HTYP) |
- MAX77693_HAPTIC_PWM_DIVISOR_128);
+ switch (haptic->dev_type) {
+ case TYPE_MAX77693:
+ value = ((haptic->type << MAX77693_CONFIG2_MODE) |
+ (enable << MAX77693_CONFIG2_MEN) |
+ (haptic->mode << MAX77693_CONFIG2_HTYP) |
+ MAX77693_HAPTIC_PWM_DIVISOR_128);
+ config_reg = MAX77693_HAPTIC_REG_CONFIG2;
+ break;
+ default:
+ return -EINVAL;
+ }
error = regmap_write(haptic->regmap_haptic,
-MAX77693_HAPTIC_REG_CONFIG2, value);
+config_reg, value);
if (error) {
dev_err(haptic->dev,
"failed to update haptic config: %d\n", error);
@@ -254,12 +263,23 @@ static int max77693_haptic_probe(struct platform_device
*pdev)
return -ENOMEM;
haptic->regmap_pmic = max77693->regmap;
- haptic->regmap_haptic = max77693->regmap_haptic;
haptic->dev = >dev;
haptic->type = MAX77693_HAPTIC_LRA;
haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
haptic->suspend_state = false;
+ /* Variant-specific init */
+ haptic->dev_type = platform_get_device_id(pdev)->driver_data;
+ switch (haptic->dev_type) {
+ case TYPE_MAX77693:
+ haptic->regmap_haptic = max77693->regmap_haptic;
+ break;
+ default:
+ dev_err(>dev, "unsupported device type: %u\n",
+ haptic->dev_type);
+ return -EINVAL;
+ }
+
INIT_WORK(>work, max77693_haptic_play_work);
/* Get pwm and regulatot for haptic device */
@@ -337,12 +357,19 @@ static int __maybe_unused max77693_haptic_resume(struct
device *dev)
static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops,
max77693_haptic_suspend, max77693_haptic_resume);
+static const struct platform_device_id max77693_haptic_id[] = {
+ { "max77693-haptic", TYPE_MAX77693 },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, max77693_haptic_id);
+
static struct platform_driver max77693_haptic_driver = {
.driver = {
.name = "max77693-haptic",
.pm = _haptic_pm_ops,
},
.probe = max77693_haptic_probe,
+ .id_table = max77693_haptic_id,
};
module_platform_driver(max77693_haptic_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] net: netcp: bug fixes for dynamic module support
From: Murali Karicheri Date: Tue, 28 Jul 2015 18:20:11 -0400 > This series fixes few bugs to allow keystone netcp modules to be > dynamically loaded and removed. Currently it allows following > sequence multiple times ... Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] Input: max77693: Add support for Maxim 77843
The Maxim 77843 haptic driver differs from 77693 by:
1. Setting the bias.
2. Different configuration register.
3. Not enabling the low-sys DAC.
4. Using same regmap for PMIC and haptic blocks.
Incorporate all differences into max77693 haptic driver so both devices
can be supported.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Dmitry Torokhov
---
drivers/input/misc/Kconfig | 6 ++---
drivers/input/misc/max77693-haptic.c | 48 +---
2 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a817e858..f5d7a98a329d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -167,12 +167,12 @@ config INPUT_M68K_BEEP
depends on M68K
config INPUT_MAX77693_HAPTIC
- tristate "MAXIM MAX77693 haptic controller support"
- depends on MFD_MAX77693 && PWM
+ tristate "MAXIM MAX77693/MAX77843 haptic controller support"
+ depends on (MFD_MAX77693 || MFD_MAX77843) && PWM
select INPUT_FF_MEMLESS
help
This option enables support for the haptic controller on
- MAXIM MAX77693 chip.
+ MAXIM MAX77693 and MAX77843 chips.
To compile this driver as module, choose M here: the
module will be called max77693-haptic.
diff --git a/drivers/input/misc/max77693-haptic.c
b/drivers/input/misc/max77693-haptic.c
index 4c0f67ab66d9..6d96bff32a0e 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -1,8 +1,9 @@
/*
- * MAXIM MAX77693 Haptic device driver
+ * MAXIM MAX77693/MAX77843 Haptic device driver
*
- * Copyright (C) 2014 Samsung Electronics
+ * Copyright (C) 2014,2015 Samsung Electronics
* Jaewon Kim
+ * Krzysztof Kozlowski
*
* This program is not provided / owned by Maxim Integrated Products.
*
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
#define MAX_MAGNITUDE_SHIFT16
@@ -80,6 +82,26 @@ static int max77693_haptic_set_duty_cycle(struct
max77693_haptic *haptic)
return 0;
}
+static int max77843_haptic_bias(struct max77693_haptic *haptic, bool on)
+{
+ int error;
+
+ if (haptic->dev_type != TYPE_MAX77843)
+ return 0;
+
+ error = regmap_update_bits(haptic->regmap_haptic,
+ MAX77843_SYS_REG_MAINCTRL1,
+ MAX77843_MAINCTRL1_BIASEN_MASK,
+ on << MAINCTRL1_BIASEN_SHIFT);
+ if (error) {
+ dev_err(haptic->dev, "failed to %s bias: %d\n",
+ on ? "enable" : "disable", error);
+ return error;
+ }
+
+ return 0;
+}
+
static int max77693_haptic_configure(struct max77693_haptic *haptic,
bool enable)
{
@@ -94,6 +116,12 @@ static int max77693_haptic_configure(struct max77693_haptic
*haptic,
MAX77693_HAPTIC_PWM_DIVISOR_128);
config_reg = MAX77693_HAPTIC_REG_CONFIG2;
break;
+ case TYPE_MAX77843:
+ value = (haptic->type << MCONFIG_MODE_SHIFT) |
+ (enable << MCONFIG_MEN_SHIFT) |
+ MAX77693_HAPTIC_PWM_DIVISOR_128;
+ config_reg = MAX77843_HAP_REG_MCONFIG;
+ break;
default:
return -EINVAL;
}
@@ -113,6 +141,9 @@ static int max77693_haptic_lowsys(struct max77693_haptic
*haptic, bool enable)
{
int error;
+ if (haptic->dev_type != TYPE_MAX77693)
+ return 0;
+
error = regmap_update_bits(haptic->regmap_pmic,
MAX77693_PMIC_REG_LSCNFG,
MAX77693_PMIC_LOW_SYS_MASK,
@@ -228,6 +259,10 @@ static int max77693_haptic_open(struct input_dev *dev)
struct max77693_haptic *haptic = input_get_drvdata(dev);
int error;
+ error = max77843_haptic_bias(haptic, true);
+ if (error)
+ return error;
+
error = regulator_enable(haptic->motor_reg);
if (error) {
dev_err(haptic->dev,
@@ -250,6 +285,8 @@ static void max77693_haptic_close(struct input_dev *dev)
if (error)
dev_err(haptic->dev,
"failed to disable regulator: %d\n", error);
+
+ max77843_haptic_bias(haptic, false);
}
static int max77693_haptic_probe(struct platform_device *pdev)
@@ -274,6 +311,9 @@ static int max77693_haptic_probe(struct platform_device
*pdev)
case TYPE_MAX77693:
haptic->regmap_haptic = max77693->regmap_haptic;
break;
+ case TYPE_MAX77843:
+ haptic->regmap_haptic = max77693->regmap;
+ break;
default:
dev_err(>dev, "unsupported device type: %u\n",
haptic->dev_type);
@@ -359,6 +399,7 @@ static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops,
[PATCH v2 0/4] regulator: input: Merge max77843 haptic driver into max77693
Hi Mark, This patchset depends on "regulator: Merge max77843 into max77693" [0] which you applied already. Dmitry agreed [1] to take this through regulator tree. Can you apply it? Changes since v1 1. Fix signed-off-by in patch 4/4. 2. Add acked-by Dmitry. Description === The Maxim 77843 haptic driver differs from 77693 by: 1. Setting the bias. 2. Different configuration register. 3. Not enabling the low-sys DAC. 4. Using same regmap for PMIC and haptic blocks. The patchset merges max77843 driver into the max77693. Dependencies The patchset *depends on* "regulator: Merge max77843 into max77693" [0] which was applied by Mark Brown (regulator tree). The mentioned regulator patchset actually changed also MFD drivers and other headers so the child drivers (like max77693 regulator or haptic) can be used with both max77693 and max77843 main MFD drivers. Merging ideas = 0. Patches 1 and 2 can be applied directly. For rest of it (patches 3 and 4): 1. If this will go to v4.3, then maybe Mark Brown could prepare an immutable branch (or a tag) with the [0] patchset? 2. If this will go to v4.4, then patchset can wait till MFD/regulator changes reach Linus' tree. 3. Everything will go through regulator tree (with Dmitry's ack). Best regards, Krzysztof [0] https://lkml.org/lkml/2015/7/15/554 [1] http://www.spinics.net/lists/kernel/msg2044546.html Krzysztof Kozlowski (4): Input: max77693: Remove a read-only pwm_divisor field Input: max77693: Prepare for adding support for Maxim 77843 Input: max77693: Add support for Maxim 77843 Input: Remove the max77843 haptic driver drivers/input/misc/Kconfig | 18 +- drivers/input/misc/Makefile | 1 - drivers/input/misc/max77693-haptic.c | 91 +++-- drivers/input/misc/max77843-haptic.c | 359 --- 4 files changed, 82 insertions(+), 387 deletions(-) delete mode 100644 drivers/input/misc/max77843-haptic.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] Input: max77693: Remove a read-only pwm_divisor field
Storing a predefined PWM divisor in state container structure is
meaningless. The field, after initialization, is only read so this only
obfuscates the code. Remove the field and use directly enum value.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Dmitry Torokhov
---
drivers/input/misc/max77693-haptic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/misc/max77693-haptic.c
b/drivers/input/misc/max77693-haptic.c
index 4524499ea72f..8dc43c1ebf0e 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -60,7 +60,6 @@ struct max77693_haptic {
unsigned int pwm_duty;
enum max77693_haptic_motor_type type;
enum max77693_haptic_pulse_mode mode;
- enum max77693_haptic_pwm_divisor pwm_divisor;
struct work_struct work;
};
@@ -88,7 +87,7 @@ static int max77693_haptic_configure(struct max77693_haptic
*haptic,
value = ((haptic->type << MAX77693_CONFIG2_MODE) |
(enable << MAX77693_CONFIG2_MEN) |
(haptic->mode << MAX77693_CONFIG2_HTYP) |
- (haptic->pwm_divisor));
+ MAX77693_HAPTIC_PWM_DIVISOR_128);
error = regmap_write(haptic->regmap_haptic,
MAX77693_HAPTIC_REG_CONFIG2, value);
@@ -259,7 +258,6 @@ static int max77693_haptic_probe(struct platform_device
*pdev)
haptic->dev = >dev;
haptic->type = MAX77693_HAPTIC_LRA;
haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
- haptic->pwm_divisor = MAX77693_HAPTIC_PWM_DIVISOR_128;
haptic->suspend_state = false;
INIT_WORK(>work, max77693_haptic_play_work);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] Input: Remove the max77843 haptic driver
The max77693 haptic driver supports Maxim 77843 device so remove the
max77843 driver.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Dmitry Torokhov
---
drivers/input/misc/Kconfig | 12 --
drivers/input/misc/Makefile | 1 -
drivers/input/misc/max77843-haptic.c | 359 ---
3 files changed, 372 deletions(-)
delete mode 100644 drivers/input/misc/max77843-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index f5d7a98a329d..c41dec819cdf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -177,18 +177,6 @@ config INPUT_MAX77693_HAPTIC
To compile this driver as module, choose M here: the
module will be called max77693-haptic.
-config INPUT_MAX77843_HAPTIC
-tristate "MAXIM MAX77843 haptic controller support"
-depends on MFD_MAX77843 && REGULATOR
-select INPUT_FF_MEMLESS
-help
- This option enables support for the haptic controller on
- MAXIM MAX77843 chip. The driver supports ff-memless interface
- from input framework.
-
- To compile this driver as module, choose M here: the
- module will be called max77843-haptic.
-
config INPUT_MAX8925_ONKEY
tristate "MAX8925 ONKEY support"
depends on MFD_MAX8925
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 53df07dcc23c..0357a088c6a9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_INPUT_KEYSPAN_REMOTE)+= keyspan_remote.o
obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
obj-$(CONFIG_INPUT_MAX77693_HAPTIC)+= max77693-haptic.o
-obj-$(CONFIG_INPUT_MAX77843_HAPTIC)+= max77843-haptic.o
obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
diff --git a/drivers/input/misc/max77843-haptic.c
b/drivers/input/misc/max77843-haptic.c
deleted file mode 100644
index 30da81ab5a21..
--- a/drivers/input/misc/max77843-haptic.c
+++ /dev/null
@@ -1,359 +0,0 @@
-/*
- * MAXIM MAX77693 Haptic device driver
- *
- * Copyright (C) 2015 Samsung Electronics
- * Author: Jaewon Kim
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define MAX_MAGNITUDE_SHIFT16
-
-enum max77843_haptic_motor_type {
- MAX77843_HAPTIC_ERM = 0,
- MAX77843_HAPTIC_LRA,
-};
-
-enum max77843_haptic_pwm_divisor {
- MAX77843_HAPTIC_PWM_DIVISOR_32 = 0,
- MAX77843_HAPTIC_PWM_DIVISOR_64,
- MAX77843_HAPTIC_PWM_DIVISOR_128,
- MAX77843_HAPTIC_PWM_DIVISOR_256,
-};
-
-struct max77843_haptic {
- struct regmap *regmap_haptic;
- struct device *dev;
- struct input_dev *input_dev;
- struct pwm_device *pwm_dev;
- struct regulator *motor_reg;
- struct work_struct work;
- struct mutex mutex;
-
- unsigned int magnitude;
- unsigned int pwm_duty;
-
- bool active;
- bool suspended;
-
- enum max77843_haptic_motor_type type;
- enum max77843_haptic_pwm_divisor pwm_divisor;
-};
-
-static int max77843_haptic_set_duty_cycle(struct max77843_haptic *haptic)
-{
- int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
- int error;
-
- error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
- if (error) {
- dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
- return error;
- }
-
- return 0;
-}
-
-static int max77843_haptic_bias(struct max77843_haptic *haptic, bool on)
-{
- int error;
-
- error = regmap_update_bits(haptic->regmap_haptic,
- MAX77843_SYS_REG_MAINCTRL1,
- MAX77843_MAINCTRL1_BIASEN_MASK,
- on << MAINCTRL1_BIASEN_SHIFT);
- if (error) {
- dev_err(haptic->dev, "failed to %s bias: %d\n",
- on ? "enable" : "disable", error);
- return error;
- }
-
- return 0;
-}
-
-static int max77843_haptic_config(struct max77843_haptic *haptic, bool enable)
-{
- unsigned int value;
- int error;
-
- value = (haptic->type << MCONFIG_MODE_SHIFT) |
- (enable << MCONFIG_MEN_SHIFT) |
- (haptic->pwm_divisor << MCONFIG_PDIV_SHIFT);
-
- error = regmap_write(haptic->regmap_haptic,
-MAX77843_HAP_REG_MCONFIG, value);
- if (error) {
- dev_err(haptic->dev,
-
Re: linux-next: manual merge of the nfsd tree with Linus' tree
Hi Stephen,
On Wed, Jul 29, 2015 at 9:23 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the nfsd tree got a conflict in:
>
> fs/nfs/nfs42proc.c
>
> between commit:
>
> bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors")
>
> from Linus' tree and commit:
>
> 0183ae17c741 ("NFSv4.2: handle NFS-specific llseek errors")
>
> from the nfsd tree.
>
> The only difference here is that _nfs42_proc_llseek is static in the
> former, so I used that.
>
Yes, I snuck that declaration into the patch since it was obvious that
we would never want to export _nfs42_proc_llseek(), and because
"sparse" complained. Apologies if that caused a conflict...
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dtb: Create a common home for cross-architecture dtsi files.
Hi,
2015-07-30 0:23 GMT+09:00 Rob Herring :
> On Wed, Jul 29, 2015 at 8:22 AM, Ian Campbell wrote:
>> On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
>>> Hi Ian,
>>>
>>>
>>> 2015-07-27 19:35 GMT+09:00 Ian Campbell :
>>> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
>>> > LogicTile Express 20MG" added a new dts file to arch/arm64 which
>>> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
>>> > .dtsi supplied by arch/arm.
>>> >
>>> > Unfortunately this causes some issues for the split device tree
>>> > repository[0], since things get moved around there. In that context
>>> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
>>> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
>>> >
>>> > The sharing of the .dtsi is legitimate since the baseboard is the same
>>> > for various vexpress systems whatever processor they use.
>>> >
>>> > Rather than using ../../ tricks to pickup .dtsi files from another
>>> > arch this patch creates a new directory include/dt-dtsi as a
>>> > home for such cross-arch .dtsi files, arranges for it to be in the
>>> > include path when the .dts files are processed by cpp and switches the
>>>
>>>
>>> "include/dt-dtsi/" can be referenced from normal C sources.
>>>
>>> I think another possible home for cross-arch DTSI is "kernel/dts/".
>>> This directory can be hidden from C sources.
>>
>> I suppose, I don't really mind and will follow the direction of the other
>> DTB maintainers. It doesn't seem like a big deal to me.
>
> Seems fine to me. We might think of other things to put here that are
> not includes. Overlays perhaps?
Putting device trees below "include/" seems weird to me.
I thought, kernel/ is a place where we put something common among
architectures.
"kernel/configs/" was created as a home for cross-arch config fragments.
arch/${ARCH}/configs/ - arch-specific *_defconfig and *.config
kernel/configs/- arch-common *.config
Likewise,
arch/${ARCH}/boot/dts - arch-specific *.dts and *.dtsi
kernel/dts - arch-common *.dtsi
This is just a matter of preference, though.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: samples/kdbus/kdbus-workers.c and cross compiling MIPS
On Wed, 2015-07-29 at 12:19 -0400, Paul Gortmaker wrote: > Hi David, > > Does it make sense to build this sample when cross compiling? > > The reason I ask is that it has been breaking the linux-next build of > allmodconfig for a while now, with: > > HOSTCC samples/kdbus/kdbus-workers > samples/kdbus/kdbus-workers.c: In function ‘prime_new’: > samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared > (first use in this function) > p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); > ^ > samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is > reported only once for each function it appears in > scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' > failed > make[2]: *** [samples/kdbus/kdbus-workers] Error 1 > > http://kisskb.ellerman.id.au/kisskb/buildresult/12473453/ > > We recently made some changes to skip other sample/test programs when > cross compiling in mainline 65f6f092a6987 and f59514b6a8c5ca6dd and > 6a407a81a9abcf. Maybe it makes sense to do the same here? Hi Paul, We also can configure kisskb to not build samples for all_modconfig, which avoids these sort of issues with a slight decrease in code coverage. We already disable samples for several other arch all_modconfigs. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio
On 2015/7/30 3:16, Michael S. Tsirkin wrote:
> ACPI spec 5.0 allows the use of PCI vendor IDs.
>
But virtio-mmio is not a PCI device, it's a platform device.
Why do we drop the previous way using "QEMU"? Something I missed?
> Since we have one for virtio, it seems neater to use that
> rather than LNRO. For the device ID, use 103F which is a legacy ID that
> isn't used in virtio PCI spec - seems to make sense since virtio-mmio is
> a legacy device but we don't know the correct device type.
>
> Guests should probably match everything in the range 1000-103F
> (just like legacy pci drivers do) which will allow us to pass in the
> actual ID in the future if we want to.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> hw/arm/virt-acpi-build.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index f365140..dea61ba 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope,
>
> for (i = 0; i < num; i++) {
> Aml *dev = aml_device("VR%02u", i);
> -aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005")));
> +aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F")));
> aml_append(dev, aml_name_decl("_UID", aml_int(i)));
>
> Aml *crs = aml_resource_template();
>
--
Shannon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the nfsd tree with Linus' tree
Hi all,
Today's linux-next merge of the nfsd tree got a conflict in:
fs/nfs/nfs42proc.c
between commit:
bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors")
from Linus' tree and commit:
0183ae17c741 ("NFSv4.2: handle NFS-specific llseek errors")
from the nfsd tree.
The only difference here is that _nfs42_proc_llseek is static in the
former, so I used that.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 3/5] clk: Supply the critical clock {init, enable, disable} framework
Quoting Lee Jones (2015-07-27 01:53:38)
> On Mon, 27 Jul 2015, Maxime Ripard wrote:
>
> > On Wed, Jul 22, 2015 at 02:04:13PM +0100, Lee Jones wrote:
> > > These new API calls will firstly provide a mechanisms to tag a clock as
> > > critical and secondly allow any knowledgeable driver to (un)gate clocks,
> > > even if they are marked as critical.
> > >
> > > Suggested-by: Maxime Ripard
> > > Signed-off-by: Lee Jones
> > > ---
> > > drivers/clk/clk.c| 45
> > >
> > > include/linux/clk-provider.h | 2 ++
> > > include/linux/clk.h | 30 +
> > > 3 files changed, 77 insertions(+)
> > >
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index 61c3fc5..486b1da 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char
> > > *name);
> > >
> > > /***private data structures***/
> > >
> > > +/**
> > > + * struct critical - Provides 'play' over critical clocks. A
> > > clock can be
> > > + * marked as critical, meaning that it should not be
> > > + * disabled. However, if a driver which is aware of the
> > > + * critical behaviour wants to control it, it can do so
> > > + * using clk_enable_critical() and
> > > clk_disable_critical().
> > > + *
> > > + * @enabledIs clock critical? Once set, doesn't change
> > > + * @leave_on Self explanatory. Can be disabled by knowledgeable
> > > drivers
> > > + */
> > > +struct critical {
> > > + bool enabled;
> > > + bool leave_on;
> > > +};
> > > +
> > > struct clk_core {
> > > const char *name;
> > > const struct clk_ops*ops;
> > > @@ -75,6 +90,7 @@ struct clk_core {
> > > struct dentry *dentry;
> > > #endif
> > > struct kref ref;
> > > + struct critical critical;
> > > };
> > >
> > > struct clk {
> > > @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core *clk)
> > > if (WARN_ON(clk->enable_count == 0))
> > > return;
> > >
> > > + /* Refuse to turn off a critical clock */
> > > + if (clk->enable_count == 1 && clk->critical.leave_on)
> > > + return;
> > > +
> >
> > I think it should be handled by a separate counting. Otherwise, if you
> > have two users that marked the clock as critical, and then one of them
> > disable it...
> >
> > > if (--clk->enable_count > 0)
> > > return;
> > >
> > > @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> > > }
> > > EXPORT_SYMBOL_GPL(clk_disable);
> > >
> > > +void clk_disable_critical(struct clk *clk)
> > > +{
> > > + clk->core->critical.leave_on = false;
> >
> > .. you just lost the fact that it was critical in the first place.
>
> I thought about both of these points, which is why I came up with this
> strategy.
>
> Any device which uses the *_critical() API should a) have knowledge of
> what happens when a particular critical clock is gated and b) have
> thought about the consequences.
If this statement above is true then I fail to see the need for a new
api. A driver which has a really great idea of when it is safe or unsafe
to gate a clock should call clk_prepare_enable at probe and then only
call clk_disable_unprepare once it is safe to do so.
The existing bookkeeping in the clock framework will do the rest.
Regards,
Mike
> I don't think we can use reference
> counting, because we'd need as many critical clock owners as there are
> critical clocks. Cast your mind back to the reasons for this critical
> clock API. One of the most important intentions of this API is the
> requirement mitigation for each of the critical clocks to have an owner
> (driver).
>
> With regards to your second point, that's what 'critical.enabled'
> is for. Take a look at clk_enable_critical().
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 3/5] clk: Supply the critical clock {init, enable, disable} framework
Quoting Lee Jones (2015-07-28 06:00:55)
> On Tue, 28 Jul 2015, Maxime Ripard wrote:
>
> > On Mon, Jul 27, 2015 at 09:53:38AM +0100, Lee Jones wrote:
> > > On Mon, 27 Jul 2015, Maxime Ripard wrote:
> > >
> > > > On Wed, Jul 22, 2015 at 02:04:13PM +0100, Lee Jones wrote:
> > > > > These new API calls will firstly provide a mechanisms to tag a clock
> > > > > as
> > > > > critical and secondly allow any knowledgeable driver to (un)gate
> > > > > clocks,
> > > > > even if they are marked as critical.
> > > > >
> > > > > Suggested-by: Maxime Ripard
> > > > > Signed-off-by: Lee Jones
> > > > > ---
> > > > > drivers/clk/clk.c| 45
> > > > >
> > > > > include/linux/clk-provider.h | 2 ++
> > > > > include/linux/clk.h | 30 +
> > > > > 3 files changed, 77 insertions(+)
> > > > >
> > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > index 61c3fc5..486b1da 100644
> > > > > --- a/drivers/clk/clk.c
> > > > > +++ b/drivers/clk/clk.c
> > > > > @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char
> > > > > *name);
> > > > >
> > > > > /***private data structures***/
> > > > >
> > > > > +/**
> > > > > + * struct critical - Provides 'play' over critical clocks. A
> > > > > clock can be
> > > > > + * marked as critical, meaning that it should
> > > > > not be
> > > > > + * disabled. However, if a driver which is
> > > > > aware of the
> > > > > + * critical behaviour wants to control it, it
> > > > > can do so
> > > > > + * using clk_enable_critical() and
> > > > > clk_disable_critical().
> > > > > + *
> > > > > + * @enabledIs clock critical? Once set, doesn't change
> > > > > + * @leave_on Self explanatory. Can be disabled by knowledgeable
> > > > > drivers
> > > > > + */
> > > > > +struct critical {
> > > > > + bool enabled;
> > > > > + bool leave_on;
> > > > > +};
> > > > > +
> > > > > struct clk_core {
> > > > > const char *name;
> > > > > const struct clk_ops*ops;
> > > > > @@ -75,6 +90,7 @@ struct clk_core {
> > > > > struct dentry *dentry;
> > > > > #endif
> > > > > struct kref ref;
> > > > > + struct critical critical;
> > > > > };
> > > > >
> > > > > struct clk {
> > > > > @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core
> > > > > *clk)
> > > > > if (WARN_ON(clk->enable_count == 0))
> > > > > return;
> > > > >
> > > > > + /* Refuse to turn off a critical clock */
> > > > > + if (clk->enable_count == 1 && clk->critical.leave_on)
> > > > > + return;
> > > > > +
> > > >
> > > > I think it should be handled by a separate counting. Otherwise, if you
> > > > have two users that marked the clock as critical, and then one of them
> > > > disable it...
> > > >
> > > > > if (--clk->enable_count > 0)
> > > > > return;
> > > > >
> > > > > @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(clk_disable);
> > > > >
> > > > > +void clk_disable_critical(struct clk *clk)
> > > > > +{
> > > > > + clk->core->critical.leave_on = false;
> > > >
> > > > .. you just lost the fact that it was critical in the first place.
> > >
> > > I thought about both of these points, which is why I came up with this
> > > strategy.
> > >
> > > Any device which uses the *_critical() API should a) have knowledge of
> > > what happens when a particular critical clock is gated and b) have
> > > thought about the consequences.
> >
> > Indeed.
> >
> > > I don't think we can use reference counting, because we'd need as
> > > many critical clock owners as there are critical clocks.
> >
> > Which we can have if we replace the call to clk_prepare_enable you add
> > in your fourth patch in __set_critical_clocks.
>
> What should it be replaced with?
>
> > > Cast your mind back to the reasons for this critical clock API. One
> > > of the most important intentions of this API is the requirement
> > > mitigation for each of the critical clocks to have an owner
> > > (driver).
> > >
> > > With regards to your second point, that's what 'critical.enabled'
> > > is for. Take a look at clk_enable_critical().
> >
> > I don't think this addresses the issue, if you just throw more
> > customers at it, the issue remain with your implementation.
> >
> > If you have three customers that used the critical API, and if on of
> > these calls clk_disable_critical, you're losing leave_on.
>
> That's the idea. See my point above, the one you replied "Indeed"
> to. So when a driver uses clk_disable_critical() it's saying, "I know
> why this clock is a critical clock, and I know that nothing terrible
> will happen if I disable it, as I have that covered". So then if it's
>
Re: [PATCH 15/20] watchdog: at91sam9: get and use slow clock
On 07/29/2015 05:22 PM, Alexandre Belloni wrote:
Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
hang") added a workaround for the slow clock as it is not properly handled
by its users.
Get and use the slow clock as it is necessary for the at91sam9 watchdog.
Signed-off-by: Alexandre Belloni
Reviewed-by: Guenter Roeck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/20] Documentation: watchdog: at91sam9_wdt: add clocks property
On 07/29/2015 05:21 PM, Alexandre Belloni wrote: The watchdog has an input clock, the slow clock. It is required as it will not function without it. Signed-off-by: Alexandre Belloni Reviewed-by: Guenter Roeck -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 3/5] clk: Supply the critical clock {init, enable, disable} framework
Hi Lee,
+ linux-clk ml
Quoting Lee Jones (2015-07-22 06:04:13)
> These new API calls will firstly provide a mechanisms to tag a clock as
> critical and secondly allow any knowledgeable driver to (un)gate clocks,
> even if they are marked as critical.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Lee Jones
> ---
> drivers/clk/clk.c| 45
>
> include/linux/clk-provider.h | 2 ++
> include/linux/clk.h | 30 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 61c3fc5..486b1da 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char *name);
>
> /***private data structures***/
>
> +/**
> + * struct critical - Provides 'play' over critical clocks. A clock can be
> + * marked as critical, meaning that it should not be
> + * disabled. However, if a driver which is aware of the
> + * critical behaviour wants to control it, it can do so
> + * using clk_enable_critical() and
> clk_disable_critical().
> + *
> + * @enabledIs clock critical? Once set, doesn't change
> + * @leave_on Self explanatory. Can be disabled by knowledgeable drivers
Not self explanatory. I need this explained to me. What does leave_on
do? Better yet, what would happen if leave_on did not exist?
> + */
> +struct critical {
> + bool enabled;
> + bool leave_on;
> +};
> +
> struct clk_core {
> const char *name;
> const struct clk_ops*ops;
> @@ -75,6 +90,7 @@ struct clk_core {
> struct dentry *dentry;
> #endif
> struct kref ref;
> + struct critical critical;
> };
>
> struct clk {
> @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core *clk)
> if (WARN_ON(clk->enable_count == 0))
> return;
>
> + /* Refuse to turn off a critical clock */
> + if (clk->enable_count == 1 && clk->critical.leave_on)
> + return;
How do we get to this point? clk_enable_critical actually calls
clk_enable, thus incrementing the enable_count. The only time that we
could hit the above case is if,
a) there is an imbalance in clk_enable and clk_disable calls. If this is
the case then the drivers need to be fixed. Or better yet some
infrastructure to catch that, now that we have per-user struct clk
cookies.
b) a driver knowingly calls clk_enable_critical(foo) and then regular,
old clk_disable(foo). But why would a driver do that?
It might be that I am missing the point here, so please feel free to
clue me in.
Regards,
Mike
> +
> if (--clk->enable_count > 0)
> return;
>
> @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> }
> EXPORT_SYMBOL_GPL(clk_disable);
>
> +void clk_disable_critical(struct clk *clk)
> +{
> + clk->core->critical.leave_on = false;
> + clk_disable(clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_disable_critical);
> +
> static int clk_core_enable(struct clk_core *clk)
> {
> int ret = 0;
> @@ -1100,6 +1127,15 @@ int clk_enable(struct clk *clk)
> }
> EXPORT_SYMBOL_GPL(clk_enable);
>
> +int clk_enable_critical(struct clk *clk)
> +{
> + if (clk->core->critical.enabled)
> + clk->core->critical.leave_on = true;
> +
> + return clk_enable(clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_enable_critical);
> +
> static unsigned long clk_core_round_rate_nolock(struct clk_core *clk,
> unsigned long rate,
> unsigned long min_rate,
> @@ -2482,6 +2518,15 @@ fail_out:
> }
> EXPORT_SYMBOL_GPL(clk_register);
>
> +void clk_init_critical(struct clk *clk)
> +{
> + struct critical *critical = >core->critical;
> +
> + critical->enabled = true;
> + critical->leave_on = true;
> +}
> +EXPORT_SYMBOL_GPL(clk_init_critical);
> +
> /*
> * Free memory allocated for a clock.
> * Caller must hold prepare_lock.
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 5591ea7..15ef8c9 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -563,6 +563,8 @@ struct clk *devm_clk_register(struct device *dev, struct
> clk_hw *hw);
> void clk_unregister(struct clk *clk);
> void devm_clk_unregister(struct device *dev, struct clk *clk);
>
> +void clk_init_critical(struct clk *clk);
> +
> /* helper functions */
> const char *__clk_get_name(struct clk *clk);
> struct clk_hw *__clk_get_hw(struct clk *clk);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 8381bbf..9807f3b 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -231,6 +231,19 @@ struct clk *devm_clk_get(struct device *dev, const char
> *id);
> int clk_enable(struct clk
[GIT PULL] Power management and ACPI fixes for v4.2-rc5
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-4.2-rc5 to receive power management and ACPI fixes for v4.2-rc5 with top-most commit d29809b8eb12d291d7b507fdaaa5e44707641685 Merge branches 'pm-cpufreq' and 'acpi-pm' on top of commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f Linux 4.2-rc4 These fix three regressions, two recent ones (cpufreq core and ACPI device power management) and one introduced during the 4.1 cycle (intel_pstate). Specifics: - Fix a recently introduced issue in the cpufreq core causing it to attempt to create duplicate symbolic links to the policy directory in sysfs for CPUs that are offline when the cpufreq driver is being registered (Rafael J Wysocki). - Fix a recently introduced problem in the ACPI device power management core code causing it to store an incorrect value in the device object's power.state field in some cases which in turn leads to attempts to turn power resources off while they should still be on going forward (Mika Westerberg). - Fix an intel_pstate driver issue introduced during the 4.1 cycle which leads to kernel panics on boot on Knights Landing chips due to incomplete support for them in that driver (Lukasz Anaczkowski). Thanks! --- Lukasz Anaczkowski (1): intel_pstate: Add get_scaling cpu_defaults param to Knights Landing Mika Westerberg (1): ACPI / PM: Use target_state to set the device power state Rafael J. Wysocki (1): cpufreq: Avoid attempts to create duplicate symbolic links --- drivers/acpi/device_pm.c | 2 +- drivers/cpufreq/cpufreq.c | 108 + drivers/cpufreq/intel_pstate.c | 1 + include/linux/cpufreq.h| 1 + 4 files changed, 58 insertions(+), 54 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
i915 driver crashes on T540p if docking station attached
Unfortunately the failure causes a series of recursive faults and I haven't been able to capture the stack trace, but on 4.2-rcX kernels, I can reliably cause the system to crash if my T540p is booted with the docking station attached. It will also crash if I boot the system first, and then insert the laptop into the dockstation. Unfortunately, I can't get a stack trace because there are a huge number of recursive/double faults, and the system dies so quickly that nothing ends up in the log files. If you really need a stack dump I can try to rig something, but modern Laptops don't have serial consoles any more, alas, so it's bit of a pain. I was able to bisect it down to this commit, however: 8c7b5ccb72987: "drm/i915: Use atomic helpers for computing changed flags:" Is there any chance Intel could add a Lenovo Dockstation with a Multistream DP output to part of your test hardware? Unfortunately it seems pretty common that I see regressions with my particular hardware. Maybe there aren't enough people using Thinkpads any more? :-( - Ted P.S. The git bisect log git bisect start # bad: [421d125c06c4be4c5005cb69840206bd09b71dd6] builddeb: sign the modules after splitting out the debuginfo files git bisect bad 421d125c06c4be4c5005cb69840206bd09b71dd6 # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 # good: [aeaa2122af4e53f3bfd28e8f294557bb95af43fc] drm/i915/skl: Add the INIT power domain to the MISC I/O power well git bisect good aeaa2122af4e53f3bfd28e8f294557bb95af43fc # bad: [4d70f38a760ad2879d2ebd84001c92980180f630] drm/i915/bios: remove a redundant NULL pointer check git bisect bad 4d70f38a760ad2879d2ebd84001c92980180f630 # bad: [27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25] drm/i915/bxt: Enable WaEnableYV12BugFixInHalfSliceChicken7 for Broxton git bisect bad 27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25 # good: [4be0731786de10d0e9ae1d159504c83c6b052647] drm/i915: Add crtc states before calling compute_config() git bisect good 4be0731786de10d0e9ae1d159504c83c6b052647 # good: [d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1] drm/i915: Stage new modeset state straight into atomic state git bisect good d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1 # bad: [a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10] drm/i915: Swap atomic state in legacy modeset git bisect bad a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10 # bad: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic helpers for computing changed flags git bisect bad 8c7b5ccb729870e606321b3703e2c2e698c49a95 # good: [0f63cca2afdc38877e86acfa9821020f6e2213fd] drm/i915: Update crtc state active flag based on DPMS git bisect good 0f63cca2afdc38877e86acfa9821020f6e2213fd # good: [840bfe953384a134c8639f2964d9b74bfa671e16] drm/atomic: Make mode_fixup() optional for check_modeset() git bisect good 840bfe953384a134c8639f2964d9b74bfa671e16 # first bad commit: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic helpers for computing changed flags -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick dependency mask model
On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote: > On 07/29/2015 09:23 AM, Frederic Weisbecker wrote: > >>At a higher level, is the posix-cpu-timers code here really providing the > >>>right semantics? It seems like before, the code was checking a struct > >>>task-specific state, and now you are setting a global state such that if > >>>ANY > >>>task anywhere in the system (even on housekeeping cores) has a pending > >>>posix > >>>cpu timer, then nothing can go into nohz_full mode. > >>> > >>>Perhaps what is needed is a task_struct->tick_dependency to go along with > >>>the system-wide and per-cpu flag words? > >That's an excellent point! Indeed the tick dependency check on > >posix-cpu-timers > >was made on task granularity before and now it's a global dependency. > > > >Which means that if any task in the system has a posix-cpu-timer enqueued, it > >prevents all CPUs from shutting down the tick. I need to mention that in the > >changelog. > > > >Now here is the rationale: I expect that nohz full users are not interested > >in > >posix cpu timers at all. The only chance for one to run without breaking the > >isolation is on housekeeping CPUs. So perhaps there is a corner case > >somewhere > >but I assume there isn't until somebody reports an issue. > > > >Keeping a task level dependency check means that we need to update it on > >context > >switch. Plus it's not only about task but also process. So that means two > >states to update on context switch and to check from interrupts. I don't > >think > >it's worth the effort if there is no user at all. > > I really worry about this! The vision EZchip offers our customers is > that they can run whatever they want on the slow path housekeeping > cores, i.e. random control-plane code. Then, on the fast-path cores, > they run their nohz_full stuff without interruption. Often they don't > even know what the hell is running on their control plane cores - SNMP > or random third-party crap or god knows what. And there is a decent > likelihood that some posix cpu timer code might sneak in. I see. But note that installing a posix cpu timer ends up triggering an IPI to all nohz full CPUs. That's how nohz full has always behaved. So users running posix timers on nohz should already suffer issues anyway. > > You mentioned needing two fields, for task and for process, but in > fact let's just add the one field to the one thing that needs it and > not worry about additional possible future needs. And note that it's > the task_struct->signal where we need to add the field for posix cpu > timers (the signal_struct) since that's where the sharing occurs, and > given CLONE_SIGHAND I imagine it could be different from the general > "process" model anyway. Well, posix cpu timers can be install per process (signal struct) or per thread (task struct). But we can certainly simplify that with a per process flag and expand the thread dependency to the process scope. Still there is the issue of telling the CPUs where a process runs when a posix timer is installed there. There is no process-like tsk->cpus_allowed. Either we send an IPI everywhere like we do now or we iterate through all threads in the process to OR all their cpumasks in order to send that IPI. > > In any case it seems like we don't need to do work at context switch. > Updates to the task's tick_dependency are just done as normal in the > task context via "current->signal->". When we are returning to user > space and we want to check the tick, again, we can just read via > "current->signal->". Why would we need to copy the value around at > task switch time? That's only necessary if you want to do something > like read/write the task tick_dependency via the cpu index, I would think. Yeah you're right, at least the context switch should be fine. 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/
[PATCH 3/4] perf, tools, stat: Add support for metrics in interval mode
From: Andi Kleen
Now that we can modify the metrics printout functions easily,
it's straight forward to support metric printing for interval mode.
All that is needed is to print the time stamp on every new line.
Pass the prefix into the context and print it out.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 62 ++-
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e6386f1..372e719 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -619,6 +619,9 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
struct outstate {
FILE *fh;
+ const char *prefix;
+ int nfields;
+ u64 run, ena;
};
#define BASE_INDENT 41
@@ -629,13 +632,13 @@ struct outstate {
static void new_line_no_aggr_std(void *ctx)
{
struct outstate *os = ctx;
- fprintf(os->fh, "\n%*s", BASE_INDENT + NA_INDENT, "");
+ fprintf(os->fh, "\n%s%-*s", os->prefix, BASE_INDENT + NA_INDENT, "");
}
static void new_line_std(void *ctx)
{
struct outstate *os = ctx;
- fprintf(os->fh, "\n%-*s", BASE_INDENT + AGGR_INDENT, "");
+ fprintf(os->fh, "\n%s%-*s", os->prefix, BASE_INDENT + AGGR_INDENT, "");
}
static void print_metric_std(void *ctx, const char *color, const char *fmt,
@@ -662,6 +665,7 @@ static void nsec_printout(int id, int nr, struct perf_evsel
*evsel, double avg,
void *ctx, print_metric_t print_metric)
{
double msecs = avg / 1e6;
+ double ratio;
const char *fmt_v, *fmt_n;
char name[25];
@@ -685,12 +689,13 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg,
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
- if (csv_output || interval)
+ if (csv_output)
return;
- if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
+ ratio = avg_stats(_nsecs_stats);
+ if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK) && ratio)
print_metric(ctx, NULL, "%8.3f", "CPUs utilized",
-avg / avg_stats(_nsecs_stats));
+avg / ratio);
else
print_metric(ctx, NULL, NULL, NULL, 0);
}
@@ -730,7 +735,7 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg,
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
- if (csv_output || interval)
+ if (csv_output)
return;
perf_stat__print_shadow_stats(evsel, avg, cpu,
@@ -739,17 +744,25 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg,
ctx);
}
-static void printout(int id, int nr, struct perf_evsel *counter, double uval)
+static void printout(int id, int nr, struct perf_evsel *counter, double uval,
+char *prefix)
{
- struct outstate os = { .fh = output };
+ struct outstate os = {
+ .fh = output,
+ .prefix = prefix ? prefix : ""
+ };
+ print_metric_t pm = print_metric_std;
+ void (*nl)(void *);
+
+ if (aggr_mode == AGGR_NONE)
+ nl = new_line_no_aggr_std;
+ else
+ nl = new_line_std;
if (nsec_counter(counter))
- nsec_printout(id, nr, counter, uval, , print_metric_std);
+ nsec_printout(id, nr, counter, uval, , pm);
else
- abs_printout(id, nr, counter, uval, ,
-print_metric_std,
-aggr_mode == AGGR_NONE ?
-new_line_no_aggr_std : new_line_std);
+ abs_printout(id, nr, counter, uval, , pm, nl);
}
static void print_aggr(char *prefix)
@@ -805,7 +818,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval);
+ printout(id, nr, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -835,7 +848,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval);
+ printout(thread, 0, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -884,7 +897,7 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
}
uval = avg * counter->scale;
- printout(-1, 0, counter, uval);
+ printout(-1, 0, counter, uval, prefix);
perf, tools: Refactor and support interval and CSV metrics
Currently perf stat does not support printing computed metrics for interval (-I xxx) or CSV (-x,) mode. For example IPC or TSX metrics over time are quite useful to know. This patch implements them. The main obstacle was that the metrics printing was all open coded all over the metrics computation code. The second patch refactors the metrics printing to work through call backs that can be more easily changed. This also cleans up the metrics printing significantly. The indentation is now handled through printf, no more need to manually count spaces. Then based on that it implements metrics printing for CSV and interval mode. Example output: % perf stat -I1000 -a sleep 1 # time counts unit eventsmetric multiplex 1.001301370 12020.049593 task-clock (msec) (100.00%) 1.001301370 3,952 context-switches #0.329 K/sec(100.00%) 1.001301370 69 cpu-migrations#0.006 K/sec(100.00%) 1.001301370 76 page-faults #0.006 K/sec 1.001301370386,582,789 cycles#0.032 GHz (100.00%) 1.001301370716,441,544 stalled-cycles-frontend # 185.33% frontend cycles idle (100.00%) 1.001301370 stalled-cycles-backend 1.001301370101,751,678 instructions #0.26 insn per cycle 1.001301370 #7.04 stalled cycles per insn (100.00%) 1.001301370 20,914,692 branches #1.740 M/sec(100.00%) 1.001301370 1,943,630 branch-misses #9.29% of all branches CSV mode % perf stat -x, -I1000 -a sleep 1 1.000852081,12016.143006,,task-clock 1.000852081,4457,,context-switches,12015168277,100.00,0.371,K/sec 1.000852081,50,,cpu-migrations,12014024424,100.00,0.004,K/sec 1.000852081,76,,page-faults,12013076716,100.00,0.006,K/sec 1.000852081,515854373,,cycles,12011235336,100.00,0.043,GHz 1.000852081,1030742150,,stalled-cycles-frontend,12010984057,100.00,199.81,frontend cycles idle 1.000852081,,,stalled-cycles-backend,0,100.00 1.000852081,116782495,,instructions,12011130729,100.00,0.23,insn per cycle 1.00085208112011130729,100.00,8.83,stalled cycles per insn 1.000852081,23748237,,branches,12010745125,100.00,1.976,M/sec 1.000852081,1976560,,branch-misses,12010501884,100.00,8.32,of all branches Available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/stat-metrics Note: for some of the --per-*/-A modes metrics are not printed correctly. That was already the case before, so I didn't change it. I think some of it may be related to Jiri's earlier stat changes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/20] ARM: at91/dt: at91rm9200: use slow clock where necessary
The system timer and the RTC need the slow clock, add it.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91rm9200.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index e3cfb9972f54..385e0c36dece 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -359,6 +359,7 @@
compatible = "atmel,at91rm9200-st", "syscon",
"simple-mfd";
reg = <0xfd00 0x100>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <_xtal>;
watchdog {
compatible = "atmel,at91rm9200-wdt";
@@ -369,6 +370,7 @@
compatible = "atmel,at91rm9200-rtc";
reg = <0xfe00 0x40>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <_xtal>;
status = "disabled";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/20] Documentation: dt: rtc: at91rm9200: add clocks property
The RTC needs an input clock, it is the slow clock. It is required as it
will not function without it.
Signed-off-by: Alexandre Belloni
---
Cc: Alessandro Zummo
Cc: rtc-li...@googlegroups.com
Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
index 34c1505774bf..5d3791e789c6 100644
--- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
@@ -5,6 +5,7 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: rtc alarm/event interrupt
+- clocks: phandle to input clock.
Example:
@@ -12,4 +13,5 @@ rtc@fe00 {
compatible = "atmel,at91rm9200-rtc";
reg = <0xfe00 0x100>;
interrupts = <1 4 7>;
+ clocks = <>;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/20] ARM: at91: Properly handle slow clock
Hi,
It was discovered that all the slow clock user were not properly claiming it.
This can end up in a system hang because the last registered user is releasing
it, and it gets disabled.
commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system hang")
was a workaround. This series is adding the slow clock to the necessary drivers
to avoid the issue and then removes that workaround.
The Documentation updates and DT patches should probably go through the AT91
tree this cycle to avoid breakage.
Then the other patches can go through each subsystem tree. They are trivial
enough to also go in this cycle.
The final clk patch depends on the other ones and may be taken for the next
cycle to avoid synchronization issues.
I've thrown in a cleanup for at91-reset as it avoids adding support for that
clock to the platform data initialization
Cc: Alessandro Zummo
Cc: rtc-li...@googlegroups.com
Cc: Wim Van Sebroeck
Cc: linux-watch...@vger.kernel.org
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: linux...@vger.kernel.org
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Alexandre Belloni (20):
Documentation: dt: atmel-at91: add clocks to system timer, rstc and
shdwc
Documentation: watchdog: at91sam9_wdt: add clocks property
Documentation: dt: rtc: at91rm9200: add clocks property
ARM: at91/dt: at91rm9200: use slow clock where necessary
ARM: at91/dt: at91sam9260: use slow clock where necessary
ARM: at91/dt: at91sam9261: use slow clock where necessary
ARM: at91/dt: at91sam9263: use slow clock where necessary
ARM: at91/dt: at91sam9g45: use slow clock where necessary
ARM: at91/dt: at91sam9n12: use slow clock where necessary
ARM: at91/dt: at91sam9rl: use slow clock where necessary
ARM: at91/dt: at91sam9x5: use slow clock where necessary
ARM: at91/dt: sama5d3: use slow clock where necessary
ARM: at91/dt: sama5d4: use slow clock where necessary
rtc: at91rm9200: get and use slow clock
watchdog: at91sam9: get and use slow clock
power/reset: at91-reset: remove useless at91_reset_platform_probe()
power/reset: at91-reset: get and use slow clock
power/reset: at91-poweroff: get and use slow clock
clocksource: atmel-st: get and use slow clock
clk: at91: Revert "keep slow clk enabled to prevent system hang"
.../devicetree/bindings/arm/atmel-at91.txt | 11 +++--
.../bindings/rtc/atmel,at91rm9200-rtc.txt | 2 +
.../devicetree/bindings/watchdog/atmel-wdt.txt | 2 +
arch/arm/boot/dts/at91rm9200.dtsi | 2 +
arch/arm/boot/dts/at91sam9260.dtsi | 3 ++
arch/arm/boot/dts/at91sam9261.dtsi | 3 ++
arch/arm/boot/dts/at91sam9263.dtsi | 3 ++
arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++
arch/arm/boot/dts/at91sam9n12.dtsi | 4 ++
arch/arm/boot/dts/at91sam9rl.dtsi | 4 ++
arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++
arch/arm/boot/dts/sama5d3.dtsi | 4 ++
arch/arm/boot/dts/sama5d4.dtsi | 4 ++
drivers/clk/at91/clk-slow.c| 27 -
drivers/clocksource/timer-atmel-st.c | 31 +-
drivers/power/reset/at91-poweroff.c| 13 ++
drivers/power/reset/at91-reset.c | 47 ++
drivers/rtc/rtc-at91rm9200.c | 27 +++--
drivers/watchdog/at91sam9_wdt.c| 22 +-
19 files changed, 138 insertions(+), 79 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/20] ARM: at91/dt: at91sam9g45: use slow clock where necessary
The watchdog, the reset controller, the RTC, the real-time timer and the
shutdown controller need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91sam9g45.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 18177f5a7464..74e54fb08898 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -387,6 +387,7 @@
rstc@fd00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfd00 0x10>;
+ clocks = <>;
};
pit: timer@fd30 {
@@ -400,6 +401,7 @@
shdwc@fd10 {
compatible = "atmel,at91sam9rl-shdwc";
reg = <0xfd10 0x10>;
+ clocks = <>;
};
tcb0: timer@fff7c000 {
@@ -1113,6 +1115,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfd40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
atmel,watchdog-type = "hardware";
atmel,reset-type = "all";
atmel,dbg-halt;
@@ -1247,6 +1250,7 @@
compatible = "atmel,at91rm9200-rtc";
reg = <0xfdb0 0x30>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
status = "disabled";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/20] ARM: at91/dt: at91sam9263: use slow clock where necessary
The watchdog, the reset controller, the two real-time timers and the
shutdown controller need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91sam9263.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index e36d966ef5e8..dc168acfebdd 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -384,11 +384,13 @@
rstc@fd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfd00 0x10>;
+ clocks = <_xtal>;
};
shdwc@fd10 {
compatible = "atmel,at91sam9260-shdwc";
reg = <0xfd10 0x10>;
+ clocks = <_xtal>;
};
pinctrl@f200 {
@@ -902,6 +904,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfd40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <_xtal>;
atmel,watchdog-type = "hardware";
atmel,reset-type = "all";
atmel,dbg-halt;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/20] ARM: at91/dt: at91sam9261: use slow clock where necessary
The watchdog, the reset controller, the real-time timer and the shutdown
controller need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91sam9261.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi
b/arch/arm/boot/dts/at91sam9261.dtsi
index b2c44a07a3d0..4f338d433f3c 100644
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -820,11 +820,13 @@
rstc@fd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfd00 0x10>;
+ clocks = <_xtal>;
};
shdwc@fd10 {
compatible = "atmel,at91sam9260-shdwc";
reg = <0xfd10 0x10>;
+ clocks = <_xtal>;
};
pit: timer@fd30 {
@@ -846,6 +848,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfd40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <_xtal>;
status = "disabled";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/20] ARM: at91/dt: sama5d3: use slow clock where necessary
The watchdog, the reset controller, the RTC and the shutdown controller
need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/sama5d3.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 9e2444b07bce..6e2cfef98ff2 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1261,11 +1261,13 @@
rstc@fe00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfe00 0x10>;
+ clocks = <>;
};
shutdown-controller@fe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfe10 0x10>;
+ clocks = <>;
};
pit: timer@fe30 {
@@ -1279,6 +1281,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfe40 0x10>;
interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
atmel,watchdog-type = "hardware";
atmel,reset-type = "all";
atmel,dbg-halt;
@@ -1315,6 +1318,7 @@
compatible = "atmel,at91rm9200-rtc";
reg = <0xfeb0 0x30>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
};
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/20] ARM: at91/dt: at91sam9n12: use slow clock where necessary
The watchdog, the reset controller, the RTC and the shutdown controller
need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91sam9n12.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 5c2a8c8c8bd4..b1c2f52dea05 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -376,6 +376,7 @@
rstc@fe00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfe00 0x10>;
+ clocks = <>;
};
pit: timer@fe30 {
@@ -388,6 +389,7 @@
shdwc@fe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfe10 0x10>;
+ clocks = <>;
};
sckc@fe50 {
@@ -891,6 +893,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfe40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
atmel,watchdog-type = "hardware";
atmel,reset-type = "all";
atmel,dbg-halt;
@@ -901,6 +904,7 @@
compatible = "atmel,at91rm9200-rtc";
reg = <0xfeb0 0x40>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
status = "disabled";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/20] ARM: at91/dt: sama5d4: use slow clock where necessary
The watchdog, the reset controller, the RTC and the shutdown
controller need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/sama5d4.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 3ee22ee13c5a..d5bec50d14e0 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1279,11 +1279,13 @@
rstc@fc068600 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfc068600 0x10>;
+ clocks = <>;
};
shdwc@fc068610 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfc068610 0x10>;
+ clocks = <>;
};
pit: timer@fc068630 {
@@ -1296,6 +1298,7 @@
watchdog@fc068640 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfc068640 0x10>;
+ clocks = <>;
status = "disabled";
};
@@ -1329,6 +1332,7 @@
compatible = "atmel,at91rm9200-rtc";
reg = <0xfc0686b0 0x30>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
};
dbgu: serial@fc069000 {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] rtc: at91sam9: sort headers alphabetically
Sort included headers alphabetically. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-at91sam9.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c index 0a8485ac3864..23f721d049b2 100644 --- a/drivers/rtc/rtc-at91sam9.c +++ b/drivers/rtc/rtc-at91sam9.c @@ -11,20 +11,20 @@ * 2 of the License, or (at your option) any later version. */ -#include -#include -#include -#include -#include +#include #include #include -#include -#include #include +#include #include +#include +#include +#include #include +#include +#include #include -#include +#include /* * This driver uses two configurable hardware resources that live in the -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/20] ARM: at91/dt: at91sam9x5: use slow clock where necessary
The watchdog, the reset controller, the RTC and the shutdown controller
need the slow clock, add it where necessary.
Signed-off-by: Alexandre Belloni
---
Cc: Jean-Christophe Plagniol-Villard
arch/arm/boot/dts/at91sam9x5.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index b6c8df8d380e..2d8c9f5caff9 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -376,11 +376,13 @@
rstc@fe00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfe00 0x10>;
+ clocks = <>;
};
shdwc@fe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfe10 0x10>;
+ clocks = <>;
};
pit: timer@fe30 {
@@ -1173,6 +1175,7 @@
compatible = "atmel,at91sam9260-wdt";
reg = <0xfe40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
atmel,watchdog-type = "hardware";
atmel,reset-type = "all";
atmel,dbg-halt;
@@ -1183,6 +1186,7 @@
compatible = "atmel,at91sam9x5-rtc";
reg = <0xfeb0 0x40>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <>;
status = "disabled";
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] rtc: at91sam9: remove useless check
rtc->sclk necessarily points to a valid clocks at this point. Else the probe would have aborted. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-at91sam9.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c index 152cd816cc43..0a8485ac3864 100644 --- a/drivers/rtc/rtc-at91sam9.c +++ b/drivers/rtc/rtc-at91sam9.c @@ -494,8 +494,7 @@ static int at91_rtc_remove(struct platform_device *pdev) /* disable all interrupts */ rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN)); - if (!IS_ERR(rtc->sclk)) - clk_disable_unprepare(rtc->sclk); + clk_disable_unprepare(rtc->sclk); return 0; } -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/13] twl4030_charger: split uA calculation into a function.
We will need this calculation in other places, so
create functions to map between register value and uA value.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
drivers/power/twl4030_charger.c | 48 ---
1 file changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index a075216d65ed..29984b263a35 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -178,6 +178,40 @@ static int twl4030_is_battery_present(struct twl4030_bci
*bci)
}
/*
+ * TI provided formulas:
+ * CGAIN == 0: ICHG = (BCIICHG * 1.7) / (2^10 - 1) - 0.85
+ * CGAIN == 1: ICHG = (BCIICHG * 3.4) / (2^10 - 1) - 1.7
+ * Here we use integer approximation of:
+ * CGAIN == 0: val * 1.6618 - 0.85 * 1000
+ * CGAIN == 1: (val * 1.6618 - 0.85 * 1000) * 2
+ */
+/*
+ * convert twl register value for currents into uA
+ */
+static int regval2ua(int regval, bool cgain)
+{
+ if (cgain)
+ return (regval * 16618 - 8500 * 1000) / 5;
+ else
+ return (regval * 16618 - 8500 * 1000) / 10;
+}
+
+/*
+ * convert uA currents into twl register value
+ */
+static int ua2regval(int ua, bool cgain)
+{
+ int ret;
+ if (cgain)
+ ua /= 2;
+ ret = (ua * 10 + 8500 * 1000) / 16618;
+ /* rounding problems */
+ if (ret < 512)
+ ret = 512;
+ return ret;
+}
+
+/*
* Enable/Disable USB Charge functionality.
*/
static int twl4030_charger_enable_usb(struct twl4030_bci *bci, bool enable)
@@ -366,14 +400,6 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
return NOTIFY_OK;
}
-/*
- * TI provided formulas:
- * CGAIN == 0: ICHG = (BCIICHG * 1.7) / (2^10 - 1) - 0.85
- * CGAIN == 1: ICHG = (BCIICHG * 3.4) / (2^10 - 1) - 1.7
- * Here we use integer approximation of:
- * CGAIN == 0: val * 1.6618 - 0.85
- * CGAIN == 1: (val * 1.6618 - 0.85) * 2
- */
static int twl4030_charger_get_current(void)
{
int curr;
@@ -388,11 +414,7 @@ static int twl4030_charger_get_current(void)
if (ret)
return ret;
- ret = (curr * 16618 - 850 * 1) / 10;
- if (bcictl1 & TWL4030_CGAIN)
- ret *= 2;
-
- return ret;
+ return regval2ua(curr, bcictl1 & TWL4030_CGAIN);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] rtc: at91rm9200: sort headers alphabetically
Sort included headers alphabetically. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-at91rm9200.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c index 8093d9e50619..cb62e214b52a 100644 --- a/drivers/rtc/rtc-at91rm9200.c +++ b/drivers/rtc/rtc-at91rm9200.c @@ -18,21 +18,21 @@ * */ -#include -#include -#include -#include -#include #include #include +#include #include -#include #include -#include #include -#include +#include +#include #include +#include +#include +#include +#include #include +#include #include #include "rtc-at91rm9200.h" -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/13] twl4030_charger: assume a 'charger' can supply maximum current.
If it cannot, we will stop pulling more current when voltage drops.
Signed-off-by: NeilBrown
---
drivers/power/twl4030_charger.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 2c537ee11bbe..c7432f532a83 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -697,8 +697,10 @@ static void twl4030_bci_usb_work(struct work_struct *data)
struct twl4030_bci *bci = container_of(data, struct twl4030_bci, work);
switch (bci->event) {
- case USB_EVENT_VBUS:
case USB_EVENT_CHARGER:
+ bci->usb_cur = USB_MAX_CURRENT;
+ /* FALL THROUGH */
+ case USB_EVENT_VBUS:
twl4030_charger_enable_usb(bci, true);
break;
case USB_EVENT_NONE:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/13] twl4030_charger: distinguish between USB current and 'AC' current
The twl4030 charger has two current sources, 'USB' and 'AC'
(presumably "Accessory Charger" because it isn't Alternating Current).
If 'AC' is providing current, we should set the current limit
differently to when it isn't (and so USB is used).
So split 'cur' into 'usb_cur' and 'ac_cur' and use accordingly.
Now we must review the current setting on any interrupt or USB
event which might indicate that the charger-source has changed.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
drivers/power/twl4030_charger.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 3b7cc631bb8a..982675df21b7 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#define TWL4030_BCIMSTATEC 0x02
#define TWL4030_BCIICHG0x08
@@ -101,10 +102,13 @@ struct twl4030_bci {
int usb_enabled;
/*
-* ichg values in uA. If any are 'large', we set CGAIN to
-* '1' which doubles the range for half the precision.
+* ichg_* and *_cur values in uA. If any are 'large', we set
+* CGAIN to '1' which doubles the range for half the
+* precision.
*/
- unsigned intichg_eoc, ichg_lo, ichg_hi, cur;
+ unsigned intichg_eoc, ichg_lo, ichg_hi;
+ unsigned intusb_cur, ac_cur;
+ boolac_is_active;
unsigned long event;
};
@@ -225,11 +229,24 @@ static int ua2regval(int ua, bool cgain)
static int twl4030_charger_update_current(struct twl4030_bci *bci)
{
int status;
+ int cur;
unsigned reg, cur_reg;
u8 bcictl1, oldreg, fullreg;
bool cgain = false;
u8 boot_bci;
+ /*
+* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+* and AC is enabled, set current for 'ac'
+*/
+ if (twl4030_get_madc_conversion(11) > 4500) {
+ cur = bci->ac_cur;
+ bci->ac_is_active = true;
+ } else {
+ cur = bci->usb_cur;
+ bci->ac_is_active = false;
+ }
+
/* First, check thresholds and see if cgain is needed */
if (bci->ichg_eoc >= 20)
cgain = true;
@@ -237,7 +254,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
cgain = true;
if (bci->ichg_hi >= 82)
cgain = true;
- if (bci->cur > 852000)
+ if (cur > 852000)
cgain = true;
status = twl4030_bci_read(TWL4030_BCICTL1, );
@@ -318,7 +335,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
* And finally, set the current. This is stored in
* two registers.
*/
- reg = ua2regval(bci->cur, cgain);
+ reg = ua2regval(cur, cgain);
/* we have only 10 bits */
if (reg > 0x3ff)
reg = 0x3ff;
@@ -371,6 +388,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
if (enable && !IS_ERR_OR_NULL(bci->transceiver)) {
+ twl4030_charger_update_current(bci);
+
/* Need to keep phy powered */
if (!bci->usb_enabled) {
pm_runtime_get_sync(bci->transceiver->dev);
@@ -463,6 +482,7 @@ static irqreturn_t twl4030_charger_interrupt(int irq, void
*arg)
struct twl4030_bci *bci = arg;
dev_dbg(bci->dev, "CHG_PRES irq\n");
+ twl4030_charger_update_current(bci);
power_supply_changed(bci->ac);
power_supply_changed(bci->usb);
@@ -495,6 +515,7 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void *arg)
power_supply_changed(bci->ac);
power_supply_changed(bci->usb);
}
+ twl4030_charger_update_current(bci);
/* various monitoring events, for now we just log them here */
if (irqs1 & (TWL4030_TBATOR2 | TWL4030_TBATOR1))
@@ -724,10 +745,11 @@ static int twl4030_bci_probe(struct platform_device *pdev)
bci->ichg_eoc = 80100; /* Stop charging when current drops to here */
bci->ichg_lo = 241000; /* Low threshold */
bci->ichg_hi = 50; /* High threshold */
+ bci->ac_cur = 50; /* 500mA */
if (allow_usb)
- bci->cur = 50; /* 500mA */
+ bci->usb_cur = 50; /* 500mA */
else
- bci->cur = 10; /* 100mA */
+ bci->usb_cur = 10; /* 100mA */
bci->dev = >dev;
bci->irq_chg = platform_get_irq(pdev, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/13] twl4030_charger: enable manual enable/disable of usb charging.
'off' or 'auto' to
/sys/class/power/twl4030_usb/mode
will now enable or disable charging from USB port. Normally this is
enabled on 'plug' and disabled on 'unplug'.
Unplug will still disable charging. 'plug' will only enable it if
'auto' if selected.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
.../ABI/testing/sysfs-class-power-twl4030 | 11
drivers/power/twl4030_charger.c| 59
2 files changed, 70 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power-twl4030
b/Documentation/ABI/testing/sysfs-class-power-twl4030
index 0331bba4605d..40e0f919cbde 100644
--- a/Documentation/ABI/testing/sysfs-class-power-twl4030
+++ b/Documentation/ABI/testing/sysfs-class-power-twl4030
@@ -13,3 +13,14 @@ Description:
Value can the set by writing to the attribute.
The change will only persist until the next
plug event. These event are reported via udev.
+
+
+What: /sys/class/power_supply/twl4030_usb/mode
+Description:
+ Changing mode for USB port.
+ Writing to this can disable charging.
+
+ Possible values are:
+ "auto" - draw power as appropriate for detected
+power source and battery status.
+ "off" - do not draw any power.
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index b0a50adebfda..6fa928ed3128 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -109,10 +109,16 @@ struct twl4030_bci {
unsigned intichg_eoc, ichg_lo, ichg_hi;
unsigned intusb_cur, ac_cur;
boolac_is_active;
+ int usb_mode; /* charging mode requested */
+#defineCHARGE_OFF 0
+#defineCHARGE_AUTO 1
unsigned long event;
};
+/* strings for 'usb_mode' values */
+static char *modes[] = { "off", "auto" };
+
/*
* clear and set bits on an given register on a given module
*/
@@ -386,6 +392,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
{
int ret;
+ if (bci->usb_mode == CHARGE_OFF)
+ enable = false;
if (enable && !IS_ERR_OR_NULL(bci->transceiver)) {
twl4030_charger_update_current(bci);
@@ -629,6 +637,53 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
return NOTIFY_OK;
}
+/*
+ * sysfs charger enabled store
+ */
+static ssize_t
+twl4030_bci_mode_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
+ int mode;
+ int status;
+
+ if (sysfs_streq(buf, modes[0]))
+ mode = 0;
+ else if (sysfs_streq(buf, modes[1]))
+ mode = 1;
+ else
+ return -EINVAL;
+ twl4030_charger_enable_usb(bci, false);
+ bci->usb_mode = mode;
+ status = twl4030_charger_enable_usb(bci, true);
+ return (status == 0) ? n : status;
+}
+
+/*
+ * sysfs charger enabled show
+ */
+static ssize_t
+twl4030_bci_mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
+ int len = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++)
+ if (bci->usb_mode == i)
+ len += snprintf(buf+len, PAGE_SIZE-len,
+ "[%s] ", modes[i]);
+ else
+ len += snprintf(buf+len, PAGE_SIZE-len,
+ "%s ", modes[i]);
+ buf[len-1] = '\n';
+ return len;
+}
+static DEVICE_ATTR(mode, 0644, twl4030_bci_mode_show,
+ twl4030_bci_mode_store);
+
static int twl4030_charger_get_current(void)
{
int curr;
@@ -815,6 +870,7 @@ static int twl4030_bci_probe(struct platform_device *pdev)
bci->usb_cur = 50; /* 500mA */
else
bci->usb_cur = 10; /* 100mA */
+ bci->usb_mode = CHARGE_AUTO;
bci->dev = >dev;
bci->irq_chg = platform_get_irq(pdev, 0);
@@ -898,6 +954,8 @@ static int twl4030_bci_probe(struct platform_device *pdev)
twl4030_charger_update_current(bci);
if (device_create_file(>usb->dev, _attr_max_current))
dev_warn(>dev, "could not create sysfs file\n");
+ if (device_create_file(>usb->dev, _attr_mode))
+ dev_warn(>dev, "could not create sysfs file\n");
if (device_create_file(>ac->dev, _attr_max_current))
dev_warn(>dev, "could not create sysfs file\n");
@@ -926,6 +984,7 @@ static int __exit twl4030_bci_remove(struct platform_device
*pdev)
twl4030_charger_enable_backup(0, 0);
device_remove_file(>usb->dev, _attr_max_current);
+
Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option
On 30/07/2015 00:13, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
> wrote:
>> On 29/07/2015 23:49, Boris Ostrovsky wrote:
>>> On 07/29/2015 06:46 PM, David Vrabel wrote:
On 29/07/2015 23:11, Andrew Cooper wrote:
> On 29/07/2015 23:05, Andy Lutomirski wrote:
>> On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper
>> wrote:
>>> On 29/07/2015 22:26, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky
wrote:
> On 07/29/2015 03:03 PM, Andrew Cooper wrote:
>> On 29/07/15 15:43, Boris Ostrovsky wrote:
>>> FYI, I have got a repro now and am investigating.
>> Good and bad news. This bug has nothing to do with LDTs
>> themselves.
>>
>> I have worked out what is going on, but this:
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 5abeaac..7e1a82e 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -493,6 +493,7 @@ static void set_aliased_prot(void *v,
>> pgprot_t prot)
>> pte = pfn_pte(pfn, prot);
>>+ (void)*(volatile int*)v;
>> if (HYPERVISOR_update_va_mapping((unsigned long)v,
>> pte, 0)) {
>> pr_err("set_aliased_prot va update failed w/
>> lazy mode
>> %u\n", paravirt_get_lazy_mode());
>> BUG();
>>
>> Is perhaps not the fix we are looking for, and every use of
>> HYPERVISOR_update_va_mapping() is susceptible to the same problem.
> I think in most cases we know that page is mapped so hopefully
> this is the
> only site that we need to be careful about.
Is there any chance we can get some kind of quick-and-dirty fix that
can go to x86/urgent in the next few days even if a clean fix isn't
available yet?
>>> Quick and dirty?
>>>
>>> Reading from v is the most obvious and quick way, for areas where
>>> we are
>>> certain v exists, is kernel memory and is expected to have a backing
>>> page. I don't know offhand how many of current
>>> HYPERVISOR_update_va_mapping() callsites this applies to.
>> __get_user((char *)v, tmp), perhaps, unless there's something better
>> in the wings. Keep in mind that we need this for -stable, and it's
>> likely to get backported quite quickly due to CVE-2015-5157.
> Hmm - something like that tucked inside HYPERVISOR_update_va_mapping()
> would probably work, and certainly be minimal hassle for -stable.
>
> Altering the hypercall used is certainly not something to backport, nor
> are we sure it is a viable fix at this time.
Changing this one use of update_va_mapping to use mmu_update_normal_pt
is the correct fix to unblock this LDT series. I see no reason why this
cannot be backported.
>>> To properly fix it should include batching and that is not something
>>> that I think we should target for stable.
>> Batching is absolutely not necessary to alter update_va_mapping to
>> mmu_update_normal_pt. After all, update_va_mapping isn't batched.
>>
>> However this isn't the first issue issue we have had lazy mmu faulting,
>> and I doubt it is the last. There are not many callsites of
>> update_va_mapping - I will audit them tomorrow and see if any similar
>> issues are lurking elsewhere.
> One thing I should add: nothing flushes old aliases in xen_alloc_ldt,
> yet I haven't been able to get xen_alloc_ldt to fail or subsequent LDT
> access to fault. Is this something we should be worried about?
Yes. update_va_mapping() will function perfectly well taking one RW
mapping to RO even if there is a second RW mapping. In such a case, the
next LDT access will fault.
On closer inspection, Xen is rather unhelpful with the fault. Xen's
lazy #PF will be bounced back to the guest with cr2 adjusted to appear
in the range passed to set_ldt(). The error code however will be
unmodified (and limited only by not-user and not-reserved), so will
appear as a non-present read or write supervisor access to an address
which the kernel has a valid read mapping of.
Unlike pagetables, there is no notion of pinning a segdesc page in the
Xen ABI. Pinning to a type allows the guest to take a single extra type
ref, and as a side effect forces eager validation of the contents. It
also prevents another unsuspecting vcpu from coming along, constructing
a writeable mapping and turning the soon-to-be-faulted-in LDT into a
plain writeable page and forcing a fault.
This frankly looks like an oversight, as pinning a segdesc page would
work work fine in the existing page model; it is just that there isn't a
hypercall to make such an action happen.
Therefore, set_ldt() needs to be confident that there are no writeable
mappings to the frames used to make up the LDT. It could proactively
fault
Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848
On Wed, Jul 29, 2015 at 12:36 PM, Josh Boyer wrote: > On Wed, Jul 29, 2015 at 11:32 AM, Ming Lei wrote: >> On Wed, Jul 29, 2015 at 9:51 AM, Johannes Weiner wrote: >>> On Wed, Jul 29, 2015 at 09:27:16AM -0400, Josh Boyer wrote: Hi All, We've gotten a report[1] that any of the upcoming Fedora 23 install images are all failing on 32-bit VMs/machines. Looking at the first instance of the oops, it seems to be a bad page state where a page is still charged to a group and it is trying to be freed. The oops output is below. Has anyone seen this in their 32-bit testing at all? Thus far nobody can recreate this on a 64-bit machine/VM. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 [9.026738] systemd[1]: Switching root. [9.036467] systemd-journald[149]: Received SIGTERM from PID 1 (systemd). [9.082262] BUG: Bad page state in process kworker/u5:1 pfn:372ac [9.083989] page:f3d32ae0 count:0 mapcount:0 mapping:f2252178 index:0x16a [9.085755] flags: 0x40020021(locked|lru|mappedtodisk) [9.087284] page dumped because: page still charged to cgroup [9.088772] bad because of flags: [9.089731] flags: 0x21(locked|lru) [9.090818] page->mem_cgroup:f2c3e400 >>> >>> It's also still locked and on the LRU. This page shouldn't have been >>> freed. >>> [9.117848] Call Trace: [9.118738] [] dump_stack+0x41/0x52 [9.120034] [] bad_page.part.80+0xaa/0x100 [9.121461] [] free_pages_prepare+0x3b9/0x3f0 [9.122934] [] free_hot_cold_page+0x22/0x160 [9.124400] [] ? copy_to_iter+0x1af/0x2a0 [9.125750] [] ? mempool_free_slab+0x13/0x20 [9.126840] [] __free_pages+0x37/0x50 [9.127849] [] mempool_free_pages+0xd/0x10 [9.128908] [] mempool_free+0x26/0x80 [9.129895] [] bounce_end_io+0x56/0x80 >>> >>> The page state looks completely off for a bounce buffer page. Did >>> somebody mess with a bounce bio's bv_page? >> >> Looks the page isn't touched in both lo_read_transfer() and >> lo_read_simple(). >> >> Maybe it is related with aa4d86163e4e(block: loop: switch to VFS ITER_BVEC), >> or it might be helpful to run 'git bisect' if reverting aa4d86163e4e can't >> fix the issue, suppose the issue can be reproduced easily. > > I can try reverting that and getting someone to test it. It is > somewhat complicated by having to spin a new install ISO, so a report > back will be somewhat delayed. In the meantime, I'm also asking > people to track down the first kernel build that hits this, so > hopefully that gives us more of a clue as well. > > It is odd that only 32-bit hits this issue though. At least from what > we've seen thus far. Page bounce may be just valid on 32-bit, and I will try to find one ARM box to see if it can be reproduced easily. BTW, are there any extra steps for reproducing the issue? Such as cgroup operations? 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] Revert "block: remove artifical max_hw_sectors cap"
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Jeff Moyer > Sent: Wednesday, July 29, 2015 11:53 AM > To: Christoph Hellwig > Cc: Jens Axboe ; linux-kernel@vger.kernel.org; > dmilb...@redhat.com Adding linux-scsi... > Subject: Re: [patch] Revert "block: remove artifical max_hw_sectors cap" > > Christoph Hellwig writes: > > > On Mon, Jul 20, 2015 at 03:17:07PM -0400, Jeff Moyer wrote: > >> For SAN storage, we've seen initial write and re-write performance drop > >> 25-50% across all I/O sizes. On locally attached storage, we've seen > >> regressions of 40% for all I/O types, but only for I/O sizes larger > than > >> 1MB. > > > > Workload, and hardare please. An only mainline numbers, not some old > > hacked vendor kernel, please. > > I've attached a simple fio config that reproduces the problem. It just > does sequential, O_DIRECT write I/O with I/O sizes of 1M, 2M and 4M. So > far I've tested it on an HP HSV400 and an IBM XIV SAN array connected > via a qlogic adapter, a nearline sata driveand a WD Red (NAS) sata disk > connected via an intel ich9r sata controller. The kernel I tested was > 4.2.0-rc3, and the testing was done across 3 different hosts (just > because I don't have all the hardware connected to a single box). I did > 10 runs using max_sectors_kb set to 1024, and 10 runs with it set to > 32767. Results compare the averages of those 10 runs. In no cases did > I see a performance gain. In two cases, there is a performance hit. > > In addition to my testing, our performance teams have seen performance > regressions running iozone on fibre channel-attached HP MSA1000 storage, > as well as on an SSD hidden behind a megaraid controller. I was not > able to get the exact details on the SSD. iozone configurations can be > provided, but I think I've nailed the underlying problem with this test > case. > > But, don't take my word for it. Run the fio script on your own > hardware. All you have to do is echo a couple of values into > /sys/block/sdX/queue/max_sectors_kb to test, no kernel rebuilding > required. > > In the tables below, concentrate on the BW/IOPS numbers under the WRITE > column. Negative numbers indicate that max_sectors_kb of 32767 shows a > performance regression of the indicated percentage when compared with a > setting of 1024. > > Christoph, did you have some hardware where a higher max_sectors_kb > improved performance? I don't still have performance numbers, but the old default of 512 KiB was interfering with building large writes that RAID controllers can treat as full stripe writes (avoiding the need to read the old parity). With the SCSI LLD value bumped up, some other limits remain: * the block layer BIO_MAX_PAGES value of 256 limits IOs to a maximum of 1 MiB (bio chaining affects this too) * the SCSI LLD maximum number of scatter gather entries reported in /sys/block/sdNN/queue/max_segments and /sys/block/sdNN/queue/max_segment_size creates a limit based on how fragmented the data buffer is in virtual memory * the Block Limits VPD page MAXIMUM TRANSFER LENGTH field indicates the maximum transfer size for one command over the SCSI transport protocol supported by the drive itself The patch let 1 MiB IOs flow through the stack, which is a better fit for modern strip sizes than 512 KiB. Software using large IOs must be prepared for long latencies in exchange for the potential bandwidth gains, and must use a low (but greater than 1) queue depth to keep the IOs flowing back-to-back. Are you finding real software generating such IOs but relying on the storage stack to break them up for decent performance? Your fio script is using the sync IO engine, which means no queuing. This forces a turnaround time between IOs, preventing the device from looking ahead to see what's next (for sequential IOs, probably continuing data transfers with minimal delay). If the storage stack breaks up large sync IOs, the drive might be better at detecting that the access pattern is sequential (e.g., the gaps are between every set of 2 IOs rather than every IO). This is very drive-specific. If we have to go back to that artificial limit, then modern drivers (e.g., blk-mq capable drivers) need a way to raise the default; relying on users to change the sysfs settings means they're usually not changed. --- Robert Elliott, HP Server Storage -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 0/5] clk: Provide support for always-on clocks
Quoting Lee Jones (2015-07-22 06:04:10)
> Lots of platforms contain clocks which if turned off would prove fatal.
> The only way to recover from these catastrophic failures is to restart
> the board(s). Now, when a clock provider is registered with the
> framework it is possible for a list of critical clocks to be supplied
> which must be kept ungated. Each clock mentioned in the newly
> introduced 'critical-clock' property will be clk_prepare_enable()d
> where the normal references will be taken. This will prevent the
> common clk framework from attempting to gate them during the normal
> clk_disable_unused() and disable_clock() procedures.
>
> Note that it will still be possible for knowledgeable drivers to turn
> these clocks off using clk_{enable,disable}_critical() calls.
Hi Lee,
Thanks for submitting the series.
It has been a little while since v6. It would be helpful to remind me of
why a new api is necessary, versus using the existing clk_prepare_unused
call at the time that a clock is enabled.
I'm looking over the patches in detail now, but one question stands out:
besides the DT use case, would a Linux device driver ever call
clk_enable_critical instead of using clk_enable? If so, why?
Thanks,
Mike
>
> Changelog:
> v6 => v7:
> - Introduce API to enable and disable critical clocks
> - Rename 'always-on-clock' to 'critical-clock'
>
> v5 => v6:
> - Use of_clk_get_from_provider() instead of of_clk_get_by_clkspec()
> - Explicitly describe expected DT values
> - Be pedantic with regards to printk() format specifiers
>
> vX => v5:
> Implementations have changed drastically between versions, thus I
> would like for this set to be thought of independently from its
> predecessors. The only reason for identifying as 'v5' is ease of
> differentiation on the list, which stems from the confusion caused
> by submitting 'v4' as a separate entity.
>
> Lee Jones (5):
> ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
> ARM: sti: stih410-clocks: Identify critical clocks
> clk: Supply the critical clock {init, enable, disable} framework
> clk: Provide critical clock support
> clk: dt: Introduce binding for critical clock support
>
> .../devicetree/bindings/clock/clock-bindings.txt | 39 +++
> arch/arm/boot/dts/stih410-clock.dtsi | 10 +
> drivers/clk/clk-conf.c | 45
> +-
> drivers/clk/clk.c | 45
> ++
> include/dt-bindings/clock/stih407-clks.h | 4 ++
> include/linux/clk-provider.h | 2 +
> include/linux/clk.h| 30 +++
> 7 files changed, 174 insertions(+), 1 deletion(-)
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks
On 07/29, James Liao wrote: > From: Sascha Hauer > > On the MT8173 the clocks are provided by different units. To enable > the critical clocks we must be sure that all parent clocks are already > registered, otherwise the parents of the critical clocks end up being > unused and get disabled later. > > On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED > PLLs as their parents, so we cannot enable the CLK_TOP critical clocks > until the CLK_APMIXED clocks have all been registered. > > To find a place where all parents are registered we try each time > after we've registered some clocks if all known providers are present > now and only then we enable the critical clocks. > > Signed-off-by: Sascha Hauer > Signed-off-by: James Liao > --- Please move up to v4.2-rc2 so that this patch can be dropped. I already applied this and sent it off to Linus so it's in -rc2. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/13] twl4030_charger: trust phy to determine when USB power is available.
The usb phy driver already determines when VBUS is available,
so repeating the test in the charger driver is pointless duplication.
On probe, process the last event from the phy, and from then on,
do whatever the phy tells us without double-checking.
Signed-off-by: NeilBrown
---
drivers/power/twl4030_charger.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index ffc123fb7158..a075216d65ed 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -178,28 +178,6 @@ static int twl4030_is_battery_present(struct twl4030_bci
*bci)
}
/*
- * Check if VBUS power is present
- */
-static int twl4030_bci_have_vbus(struct twl4030_bci *bci)
-{
- int ret;
- u8 hwsts;
-
- ret = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, ,
- TWL4030_PM_MASTER_STS_HW_CONDITIONS);
- if (ret < 0)
- return 0;
-
- dev_dbg(bci->dev, "check_vbus: HW_CONDITIONS %02x\n", hwsts);
-
- /* in case we also have STS_USB_ID, VBUS is driven by TWL itself */
- if ((hwsts & TWL4030_STS_VBUS) && !(hwsts & TWL4030_STS_USB_ID))
- return 1;
-
- return 0;
-}
-
-/*
* Enable/Disable USB Charge functionality.
*/
static int twl4030_charger_enable_usb(struct twl4030_bci *bci, bool enable)
@@ -207,10 +185,6 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
int ret;
if (enable && !IS_ERR_OR_NULL(bci->transceiver)) {
- /* Check for USB charger connected */
- if (!twl4030_bci_have_vbus(bci))
- return -ENODEV;
-
/*
* Until we can find out what current the device can provide,
* require a module param to enable USB charging.
@@ -662,7 +636,12 @@ static int twl4030_bci_probe(struct platform_device *pdev)
dev_warn(>dev, "failed to unmask interrupts: %d\n", ret);
twl4030_charger_enable_ac(true);
- twl4030_charger_enable_usb(bci, true);
+ if (!IS_ERR_OR_NULL(bci->transceiver))
+ twl4030_bci_usb_ncb(>usb_nb,
+ bci->transceiver->last_event,
+ NULL);
+ else
+ twl4030_charger_enable_usb(bci, false);
if (pdata)
twl4030_charger_enable_backup(pdata->bb_uvolt,
pdata->bb_uamp);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/13] twl4030_charger: allow max_current to be managed via sysfs.
'max_current' sysfs attributes are created which allow the
max to be set.
Whenever a current source changes, the default is restored.
This will be followed by a uevent, so user-space can decide to
update again.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
.../ABI/testing/sysfs-class-power-twl4030 | 15
drivers/power/twl4030_charger.c| 72
2 files changed, 87 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-power-twl4030
diff --git a/Documentation/ABI/testing/sysfs-class-power-twl4030
b/Documentation/ABI/testing/sysfs-class-power-twl4030
new file mode 100644
index ..0331bba4605d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-twl4030
@@ -0,0 +1,15 @@
+What: /sys/class/power_supply/twl4030_ac/max_current
+ /sys/class/power_supply/twl4030_usb/max_current
+Description:
+ Read/Write limit on current which may
+ be drawn from the ac (Accessory Charger) or
+ USB port.
+
+ Value is in micro-Amps.
+
+ Value is set automatically to an appropriate
+ value when a cable is plugged or unplugged.
+
+ Value can the set by writing to the attribute.
+ The change will only persist until the next
+ plug event. These event are reported via udev.
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 982675df21b7..b0a50adebfda 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -482,6 +482,8 @@ static irqreturn_t twl4030_charger_interrupt(int irq, void
*arg)
struct twl4030_bci *bci = arg;
dev_dbg(bci->dev, "CHG_PRES irq\n");
+ /* reset current on each 'plug' event */
+ bci->ac_cur = 50;
twl4030_charger_update_current(bci);
power_supply_changed(bci->ac);
power_supply_changed(bci->usb);
@@ -536,6 +538,63 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
return IRQ_HANDLED;
}
+/*
+ * Provide "max_current" attribute in sysfs.
+ */
+static ssize_t
+twl4030_bci_max_current_store(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t n)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
+ int cur = 0;
+ int status = 0;
+ status = kstrtoint(buf, 10, );
+ if (status)
+ return status;
+ if (cur < 0)
+ return -EINVAL;
+ if (dev == >ac->dev)
+ bci->ac_cur = cur;
+ else
+ bci->usb_cur = cur;
+
+ twl4030_charger_update_current(bci);
+ return n;
+}
+
+/*
+ * sysfs max_current show
+ */
+static ssize_t twl4030_bci_max_current_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int status = 0;
+ int cur = -1;
+ u8 bcictl1;
+ struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
+
+ if (dev == >ac->dev) {
+ if (!bci->ac_is_active)
+ cur = bci->ac_cur;
+ } else {
+ if (bci->ac_is_active)
+ cur = bci->usb_cur;
+ }
+ if (cur < 0) {
+ cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
+ if (cur < 0)
+ return cur;
+ status = twl4030_bci_read(TWL4030_BCICTL1, );
+ if (status < 0)
+ return status;
+ cur = regval2ua(cur, bcictl1 & TWL4030_CGAIN);
+ }
+ return scnprintf(buf, PAGE_SIZE, "%u\n", cur);
+}
+
+static DEVICE_ATTR(max_current, 0644, twl4030_bci_max_current_show,
+ twl4030_bci_max_current_store);
+
static void twl4030_bci_usb_work(struct work_struct *data)
{
struct twl4030_bci *bci = container_of(data, struct twl4030_bci, work);
@@ -558,6 +617,12 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
dev_dbg(bci->dev, "OTG notify %lu\n", val);
+ /* reset current on each 'plug' event */
+ if (allow_usb)
+ bci->usb_cur = 50;
+ else
+ bci->usb_cur = 10;
+
bci->event = val;
schedule_work(>work);
@@ -831,6 +896,11 @@ static int twl4030_bci_probe(struct platform_device *pdev)
dev_warn(>dev, "failed to unmask interrupts: %d\n", ret);
twl4030_charger_update_current(bci);
+ if (device_create_file(>usb->dev, _attr_max_current))
+ dev_warn(>dev, "could not create sysfs file\n");
+ if (device_create_file(>ac->dev, _attr_max_current))
+ dev_warn(>dev, "could not create sysfs file\n");
+
twl4030_charger_enable_ac(true);
if (!IS_ERR_OR_NULL(bci->transceiver))
twl4030_bci_usb_ncb(>usb_nb,
@@ -855,6 +925,8 @@ static int __exit twl4030_bci_remove(struct platform_device
*pdev)
twl4030_charger_enable_usb(bci, false);
twl4030_charger_enable_backup(0, 0);
+
[PATCH 11/13] twl4030_charger: add ac/mode to match usb/mode
This allows AC charging to be turned off, much like usb charging.
"continuous" mode is not available though.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
.../ABI/testing/sysfs-class-power-twl4030 | 10 ++
drivers/power/twl4030_charger.c| 35 +++-
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-power-twl4030
b/Documentation/ABI/testing/sysfs-class-power-twl4030
index e8baa36aaa2b..be26af0f1895 100644
--- a/Documentation/ABI/testing/sysfs-class-power-twl4030
+++ b/Documentation/ABI/testing/sysfs-class-power-twl4030
@@ -33,3 +33,13 @@ Description:
This is useful for unstable power sources
such as bicycle dynamo, but care should
be taken that battery is not over-charged.
+
+What: /sys/class/power_supply/twl4030_ac/mode
+Description:
+ Changing mode for 'ac' port.
+ Writing to this can disable charging.
+
+ Possible values are:
+ "auto" - draw power as appropriate for detected
+power source and battery status.
+ "off" - do not draw any power.
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index de5430deaf23..68117ad23564 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -114,7 +114,7 @@ struct twl4030_bci {
unsigned intichg_eoc, ichg_lo, ichg_hi;
unsigned intusb_cur, ac_cur;
boolac_is_active;
- int usb_mode; /* charging mode requested */
+ int usb_mode, ac_mode; /* charging mode requested */
#defineCHARGE_OFF 0
#defineCHARGE_AUTO 1
#defineCHARGE_LINEAR 2
@@ -459,10 +459,13 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
/*
* Enable/Disable AC Charge funtionality.
*/
-static int twl4030_charger_enable_ac(bool enable)
+static int twl4030_charger_enable_ac(struct twl4030_bci *bci, bool enable)
{
int ret;
+ if (bci->ac_mode == CHARGE_OFF)
+ enable = false;
+
if (enable)
ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOAC);
else
@@ -688,9 +691,17 @@ twl4030_bci_mode_store(struct device *dev, struct
device_attribute *attr,
mode = 2;
else
return -EINVAL;
- twl4030_charger_enable_usb(bci, false);
- bci->usb_mode = mode;
- status = twl4030_charger_enable_usb(bci, true);
+ if (dev == >ac->dev) {
+ if (mode == 2)
+ return -EINVAL;
+ twl4030_charger_enable_ac(bci, false);
+ bci->ac_mode = mode;
+ status = twl4030_charger_enable_ac(bci, true);
+ } else {
+ twl4030_charger_enable_usb(bci, false);
+ bci->usb_mode = mode;
+ status = twl4030_charger_enable_usb(bci, true);
+ }
return (status == 0) ? n : status;
}
@@ -704,9 +715,13 @@ twl4030_bci_mode_show(struct device *dev,
struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
int len = 0;
int i;
+ int mode = bci->usb_mode;
+
+ if (dev == >ac->dev)
+ mode = bci->ac_mode;
for (i = 0; i < ARRAY_SIZE(modes); i++)
- if (bci->usb_mode == i)
+ if (mode == i)
len += snprintf(buf+len, PAGE_SIZE-len,
"[%s] ", modes[i]);
else
@@ -916,6 +931,7 @@ static int twl4030_bci_probe(struct platform_device *pdev)
else
bci->usb_cur = 10; /* 100mA */
bci->usb_mode = CHARGE_AUTO;
+ bci->ac_mode = CHARGE_AUTO;
bci->dev = >dev;
bci->irq_chg = platform_get_irq(pdev, 0);
@@ -1001,10 +1017,12 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
dev_warn(>dev, "could not create sysfs file\n");
if (device_create_file(>usb->dev, _attr_mode))
dev_warn(>dev, "could not create sysfs file\n");
+ if (device_create_file(>ac->dev, _attr_mode))
+ dev_warn(>dev, "could not create sysfs file\n");
if (device_create_file(>ac->dev, _attr_max_current))
dev_warn(>dev, "could not create sysfs file\n");
- twl4030_charger_enable_ac(true);
+ twl4030_charger_enable_ac(bci, true);
if (!IS_ERR_OR_NULL(bci->transceiver))
twl4030_bci_usb_ncb(>usb_nb,
bci->transceiver->last_event,
@@ -1024,13 +1042,14 @@ static int __exit twl4030_bci_remove(struct
platform_device *pdev)
{
struct twl4030_bci *bci = platform_get_drvdata(pdev);
- twl4030_charger_enable_ac(false);
+ twl4030_charger_enable_ac(bci, false);
