Re: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
On Thu, 2015-04-23 at 08:29 +0200, Jan Kiszka wrote:
>
> > void irq_work_tick(void)
> > {
> > -#ifdef CONFIG_PREEMPT_RT_FULL
> > - irq_work_run_list(this_cpu_ptr(&lazy_list));
> > -#else
> > - struct llist_head *raised = &__get_cpu_var(raised_list);
> > + struct llist_head *raised = this_cpu_ptr(&raised_list);
> >
> > - if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
> > + if (!llist_empty(raised) &&
> > (!arch_irq_work_has_interrupt() ||
> > + IS_ENABLED(CONFIG_PREEMPT_RT_FULL)))
>
> OK, that additional condition is addressing archs that don't have
> irq_work support and fall back to the timer, right?
How will ever run if it is not run in either irq_work_run() or
irq_work_tick()? There are two choices, we better pick one.
Attaching patch since either evolution fscked up again (it does that),
or someone has managed to turn it into a completely useless piece of
crap... if so, likely the same dipstick who made it save messages such
that you need fromdos to wipe away the shite it smears all over it.
-MikeSubject: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
Date: Thu, 16 Apr 2015 18:28:16 +0200
From: Jan Kiszka
Instead of turning all irq_work requests into lazy ones on -rt, just
move their execution from hard into soft-irq context.
This resolves deadlocks of ftrace which will queue work from arbitrary
contexts, including those that have locks held that are needed for
raising a soft-irq.
Signed-off-by: Jan Kiszka
---
Second try, looks much better so far. And it also removes my concerns
regarding other potential cases besides ftrace.
kernel/irq_work.c | 84 ++
1 file changed, 41 insertions(+), 43 deletions(-)
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -80,17 +80,12 @@ bool irq_work_queue_on(struct irq_work *
if (!irq_work_claim(work))
return false;
-#ifdef CONFIG_PREEMPT_RT_FULL
- if (work->flags & IRQ_WORK_HARD_IRQ)
+ if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && (work->flags & IRQ_WORK_HARD_IRQ))
raise_irqwork = llist_add(&work->llnode,
&per_cpu(hirq_work_list, cpu));
else
raise_irqwork = llist_add(&work->llnode,
- &per_cpu(lazy_list, cpu));
-#else
- raise_irqwork = llist_add(&work->llnode,
&per_cpu(raised_list, cpu));
-#endif
if (raise_irqwork)
arch_send_call_function_single_ipi(cpu);
@@ -103,6 +98,9 @@ EXPORT_SYMBOL_GPL(irq_work_queue_on);
/* Enqueue the irq work @work on the current CPU */
bool irq_work_queue(struct irq_work *work)
{
+ bool realtime = IS_ENABLED(CONFIG_PREEMPT_RT_FULL);
+ bool raise = false;
+
/* Only queue if not already pending */
if (!irq_work_claim(work))
return false;
@@ -110,25 +108,22 @@ bool irq_work_queue(struct irq_work *wor
/* Queue the entry and raise the IPI if needed. */
preempt_disable();
-#ifdef CONFIG_PREEMPT_RT_FULL
- if (work->flags & IRQ_WORK_HARD_IRQ) {
+ if (realtime && (work->flags & IRQ_WORK_HARD_IRQ)) {
if (llist_add(&work->llnode, this_cpu_ptr(&hirq_work_list)))
- arch_irq_work_raise();
- } else {
- if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
- tick_nohz_tick_stopped())
- raise_softirq(TIMER_SOFTIRQ);
- }
-#else
- if (work->flags & IRQ_WORK_LAZY) {
+ raise = 1;
+ } else if (work->flags & IRQ_WORK_LAZY) {
if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
- tick_nohz_tick_stopped())
- arch_irq_work_raise();
- } else {
- if (llist_add(&work->llnode, this_cpu_ptr(&raised_list)))
- arch_irq_work_raise();
- }
-#endif
+ tick_nohz_tick_stopped()) {
+ if (realtime)
+raise_softirq(TIMER_SOFTIRQ);
+ else
+raise = true;
+ }
+ } else if (llist_add(&work->llnode, this_cpu_ptr(&raised_list)))
+ raise = true;
+
+ if (raise)
+ arch_irq_work_raise();
preempt_enable();
@@ -143,12 +138,13 @@ bool irq_work_needs_cpu(void)
raised = this_cpu_ptr(&raised_list);
lazy = this_cpu_ptr(&lazy_list);
- if (llist_empty(raised))
- if (llist_empty(lazy))
-#ifdef CONFIG_PREEMPT_RT_FULL
+ if (llist_empty(raised) && llist_empty(lazy)) {
+ if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) {
if (llist_empty(this_cpu_ptr(&hirq_work_list)))
-#endif
return false;
+ } else
+ return false;
+ }
/* All work should have been flushed before going offline */
WARN_ON_ONCE(cpu_is_offline(smp_processor_id()));
@@ -162,9 +158,7 @@ static void irq_work_run_list(struct lli
struct irq_work *work;
struct llist_node *llnode;
-#ifndef CONFIG_PREEMPT_RT_FULL
- BUG_ON(!irqs_disabled());
-#endif
+ BUG_ON(!IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !irqs_disabled());
if (llist_empty(list))
return;
@@ -200,26 +194,30 @@ static void irq_work_run_list(struct lli
*/
void irq_work_run(void)
{
-#ifdef CONFIG_PREEMPT_RT_FULL
- irq_work_run_list(this_cpu_ptr(&hirq_work_list));
-#else
- irq_work_run_list(this_cpu_ptr(&raised_list));
- irq_work_run_list(this_cpu_ptr(&lazy_list));
-#endif
+ if (IS_ENABLED(CONFIG_PREEMPT_RT_
Re: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
On Thu, 2015-04-23 at 08:50 +0200, Jan Kiszka wrote:
> On 2015-04-23 08:11, Mike Galbraith wrote:
> > @@ -103,6 +98,9 @@ EXPORT_SYMBOL_GPL(irq_work_queue_on);
> > /* Enqueue the irq work @work on the current CPU */
> > bool irq_work_queue(struct irq_work *work)
> > {
> > + bool realtime = IS_ENABLED(CONFIG_PREEMPT_RT_FULL);
> > + bool raise = false;
> > +
> > /* Only queue if not already pending */
> > if (!irq_work_claim(work))
> > return false;
> > @@ -110,25 +108,22 @@ bool irq_work_queue(struct irq_work *wor
> > /* Queue the entry and raise the IPI if needed. */
> > preempt_disable();
> >
> > -#ifdef CONFIG_PREEMPT_RT_FULL
> > - if (work->flags & IRQ_WORK_HARD_IRQ) {
> > + if (realtime && (work->flags & IRQ_WORK_HARD_IRQ)) {
> > if (llist_add(&work->llnode,
> > this_cpu_ptr(&hirq_work_list)))
>
> This boils down to
>
> #ifdef CONFIG_X
> some_type x;
> #endif
> ...
>
> if (IS_ENABLED(CONFIG_X) && ...)
> use(x);
>
> And here we even have an indirection for IS_ENABLED via that local
> bool
> variable. Is that pattern OK for Linux? Does it compile in all
> supported
> optimization levels of all supported compilers?
I hope it all goes away, that being what IS_ENABLED() is there for.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf/x86/intel/uncore: add Broadwell-U uncore IMC PMU support
On Wed, Apr 22, 2015 at 11:56 PM, Stephane Eranian wrote:
>
> This patch enables the uncore Memory Controller (IMC) PMU support
> for Intel Broadwell-U (Model 61) mobile processors.
> The IMC PMU enables measuring memory bandwidth.
>
> To use with perf:
> $ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/
> sleep 10
>
> Signed-off-by: Stephane Eranian
Tested-by: Sonny Rao
> ---
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> index c635b8b..a03f964 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> @@ -922,6 +922,9 @@ static int __init uncore_pci_init(void)
> case 69: /* Haswell Celeron */
> ret = hsw_uncore_pci_init();
> break;
> + case 61: /* Broadwell */
> + ret = bdw_uncore_pci_init();
> + break;
> default:
> return 0;
> }
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
> b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
> index 6c8c1e7..06b0793 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
> +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
> @@ -326,6 +326,7 @@ extern struct event_constraint uncore_constraint_empty;
> int snb_uncore_pci_init(void);
> int ivb_uncore_pci_init(void);
> int hsw_uncore_pci_init(void);
> +int bdw_uncore_pci_init(void);
> void snb_uncore_cpu_init(void);
> void nhm_uncore_cpu_init(void);
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
> b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
> index 0333d0b..0f768bf 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
> @@ -7,6 +7,7 @@
> #define PCI_DEVICE_ID_INTEL_IVB_E3_IMC 0x0150
> #define PCI_DEVICE_ID_INTEL_HSW_IMC0x0c00
> #define PCI_DEVICE_ID_INTEL_HSW_U_IMC 0x0a04
> +#define PCI_DEVICE_ID_INTEL_BDW_IMC0x1604
>
> /* SNB event control */
> #define SNB_UNC_CTL_EV_SEL_MASK0x00ff
> @@ -488,6 +489,14 @@ static const struct pci_device_id hsw_uncore_pci_ids[] =
> {
> { /* end: all zeroes */ },
> };
>
> +static const struct pci_device_id bdw_uncore_pci_ids[] = {
> + { /* IMC */
> + PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BDW_IMC),
> + .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
> + },
> + { /* end: all zeroes */ },
> +};
> +
> static struct pci_driver snb_uncore_pci_driver = {
> .name = "snb_uncore",
> .id_table = snb_uncore_pci_ids,
> @@ -503,6 +512,11 @@ static struct pci_driver hsw_uncore_pci_driver = {
> .id_table = hsw_uncore_pci_ids,
> };
>
> +static struct pci_driver bdw_uncore_pci_driver = {
> + .name = "bdw_uncore",
> + .id_table = bdw_uncore_pci_ids,
> +};
> +
> struct imc_uncore_pci_dev {
> __u32 pci_id;
> struct pci_driver *driver;
> @@ -516,6 +530,7 @@ static const struct imc_uncore_pci_dev
> desktop_imc_pci_ids[] = {
> IMC_DEV(IVB_E3_IMC, &ivb_uncore_pci_driver), /* Xeon E3-1200 v2/3rd
> Gen Core processor */
> IMC_DEV(HSW_IMC, &hsw_uncore_pci_driver),/* 4th Gen Core
> Processor */
> IMC_DEV(HSW_U_IMC, &hsw_uncore_pci_driver), /* 4th Gen Core ULT
> Mobile Processor */
> + IMC_DEV(BDW_IMC, &bdw_uncore_pci_driver),/* 5th Gen Core U */
> { /* end marker */ }
> };
>
> @@ -563,6 +578,11 @@ int hsw_uncore_pci_init(void)
> return imc_uncore_pci_init();
> }
>
> +int bdw_uncore_pci_init(void)
> +{
> + return imc_uncore_pci_init();
> +}
> +
> /* end of Sandy Bridge uncore support */
>
> /* Nehalem uncore support */
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf/x86/rapl: enable Broadwell-U RAPL support
This patch enables RAPL counters (energy consumption counters) support for Intel Broadwell-U processors (Model 61). To use: $ perf stat -a -I 1000 -e power/energy-cores/,power/energy-pkg/,power/energy-ram/ sleep 10 Signed-off-by: Stephane Eranian --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c b/arch/x86/kernel/cpu/perf_event_intel_rapl.c index 999289b9..358c54a 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c +++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c @@ -722,6 +722,7 @@ static int __init rapl_pmu_init(void) break; case 60: /* Haswell */ case 69: /* Haswell-Celeron */ + case 61: /* Broadwell */ rapl_cntr_mask = RAPL_IDX_HSW; rapl_pmu_events_group.attrs = rapl_events_hsw_attr; break; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
On 2015-04-23 09:01, Mike Galbraith wrote:
> On Thu, 2015-04-23 at 08:50 +0200, Jan Kiszka wrote:
>> On 2015-04-23 08:11, Mike Galbraith wrote:
>>> @@ -103,6 +98,9 @@ EXPORT_SYMBOL_GPL(irq_work_queue_on);
>>> /* Enqueue the irq work @work on the current CPU */
>>> bool irq_work_queue(struct irq_work *work)
>>> {
>>> + bool realtime = IS_ENABLED(CONFIG_PREEMPT_RT_FULL);
>>> + bool raise = false;
>>> +
>>> /* Only queue if not already pending */
>>> if (!irq_work_claim(work))
>>> return false;
>>> @@ -110,25 +108,22 @@ bool irq_work_queue(struct irq_work *wor
>>> /* Queue the entry and raise the IPI if needed. */
>>> preempt_disable();
>>>
>>> -#ifdef CONFIG_PREEMPT_RT_FULL
>>> - if (work->flags & IRQ_WORK_HARD_IRQ) {
>>> + if (realtime && (work->flags & IRQ_WORK_HARD_IRQ)) {
>>> if (llist_add(&work->llnode,
>>> this_cpu_ptr(&hirq_work_list)))
>>
>> This boils down to
>>
>> #ifdef CONFIG_X
>> some_type x;
>> #endif
>> ...
>>
>> if (IS_ENABLED(CONFIG_X) && ...)
>> use(x);
>>
>> And here we even have an indirection for IS_ENABLED via that local
>> bool
>> variable. Is that pattern OK for Linux? Does it compile in all
>> supported
>> optimization levels of all supported compilers?
>
> I hope it all goes away, that being what IS_ENABLED() is there for.
Hope is good - but not enough here: it breaks the build under
!CONFIG_X, even the case without the bool var.
CC kernel/irq_work.o
In file included from ../include/asm-generic/percpu.h:6:0,
from ../arch/x86/include/asm/percpu.h:522,
from ../arch/x86/include/asm/current.h:5,
from ../arch/x86/include/asm/processor.h:15,
from ../arch/x86/include/asm/irq_work.h:4,
from ../include/linux/irq_work.h:47,
from ../kernel/irq_work.c:11:
../kernel/irq_work.c: In function ‘irq_work_queue_on’:
../kernel/irq_work.c:85:17: error: ‘hirq_work_list’ undeclared (first use in
this function)
&per_cpu(hirq_work_list, cpu));
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 01/27] IB/Verbs: Implement new callback query_transport()
On 04/22/2015 05:02 PM, Doug Ledford wrote:
> On Mon, 2015-04-20 at 10:32 +0200, Michael Wang wrote:
>> Add new callback query_transport() and implement for each HW.
>
> The more I think about it, the more I think we need to eliminate this
> patch entirely.
>
> The problem here is that, if we follow my suggestion, then we are going
> to eliminate the query as an API function and replace the information it
> gives us with a static port attribute bitmap. If we do this patch, then
> reform this patch to my idea later, we introduce a very short lived
> API/ABI change in the kernel module interface that serves absolutely no
> purpose. Instead, let's do the bitmap creation first, update the
> drivers to properly set the bitmap, then do all of the remaining reforms
> you have here using that bitmap and completely skip the
> query_transport() API item that will no longer serve a purpose.
I really prefer to see the bitmask mechanism come along with the bits
defined, at least we are not going to use transport anymore, correct?
I think there will be more discussion on bitmask stuff, not only about
the definition of each bit, but also the timing to initialize it (should
before each HW register the device).
That's really a different topic which we can't settle down within few
versions IMHO, and I really like to staging our progress at this moment.
With these foundation, it would be really easy to expanding the topic
further and let more folks join at the beginning, but if we introduce
bitmask at this moments, the topic will be mixed with different purpose
and become confusion...
We can do whatever the reform/discussion in next series, the topic would
be clean and clear ;-)
Regards,
Michael Wang
>
>> Mapping List:
>> node-type link-layer old-transport new-transport
>> nes RNICETH IWARP IWARP
>> amso1100 RNICETH IWARP IWARP
>> cxgb3RNICETH IWARP IWARP
>> cxgb4RNICETH IWARP IWARP
>> usnicUSNIC_UDP ETH USNIC_UDP USNIC_UDP
>> ocrdma IB_CA ETH IB IBOE
>> mlx4 IB_CA IB/ETH IB IB/IBOE
>> mlx5 IB_CA IB IB IB
>> ehca IB_CA IB IB IB
>> ipathIB_CA IB IB IB
>> mthcaIB_CA IB IB IB
>> qib IB_CA IB IB IB
>>
>> Cc: Hal Rosenstock
>> Cc: Steve Wise
>> Cc: Tom Talpey
>> Cc: Jason Gunthorpe
>> Cc: Doug Ledford
>> Cc: Ira Weiny
>> Cc: Sean Hefty
>> Signed-off-by: Michael Wang
>> ---
>> drivers/infiniband/core/device.c | 1 +
>> drivers/infiniband/core/verbs.c | 4 +++-
>> drivers/infiniband/hw/amso1100/c2_provider.c | 7 +++
>> drivers/infiniband/hw/cxgb3/iwch_provider.c | 7 +++
>> drivers/infiniband/hw/cxgb4/provider.c | 7 +++
>> drivers/infiniband/hw/ehca/ehca_hca.c| 6 ++
>> drivers/infiniband/hw/ehca/ehca_iverbs.h | 3 +++
>> drivers/infiniband/hw/ehca/ehca_main.c | 1 +
>> drivers/infiniband/hw/ipath/ipath_verbs.c| 7 +++
>> drivers/infiniband/hw/mlx4/main.c| 10 ++
>> drivers/infiniband/hw/mlx5/main.c| 7 +++
>> drivers/infiniband/hw/mthca/mthca_provider.c | 7 +++
>> drivers/infiniband/hw/nes/nes_verbs.c| 6 ++
>> drivers/infiniband/hw/ocrdma/ocrdma_main.c | 1 +
>> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++
>> drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 3 +++
>> drivers/infiniband/hw/qib/qib_verbs.c| 7 +++
>> drivers/infiniband/hw/usnic/usnic_ib_main.c | 1 +
>> drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 6 ++
>> drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 2 ++
>> include/rdma/ib_verbs.h | 7 ++-
>> 21 files changed, 104 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/infiniband/core/device.c
>> b/drivers/infiniband/core/device.c
>> index 18c1ece..a9587c4 100644
>> --- a/drivers/infiniband/core/device.c
>> +++ b/drivers/infiniband/core/device.c
>> @@ -76,6 +76,7 @@ static int ib_device_check_mandatory(struct ib_device
>> *device)
>> } mandatory_table[] = {
>> IB_MANDATORY_FUNC(query_device),
>> IB_MANDATORY_FUNC(query_port),
>> +IB_MANDATORY_FUNC(query_transport),
>> IB_MANDATORY_FUNC(query_pkey),
>> IB_MANDATORY_FUNC(query_gid),
>> IB_MANDATORY_FUNC(alloc_pd),
>> diff --git a/drivers/infiniband/core/verbs.c
>> b/drivers/infiniband/core/verbs.c
>> index f93eb8d..626c9cf 100644
>> --- a/drivers/infiniband/core/verbs.c
>> +++ b/drivers/infiniband/core/verbs.c
>> @@ -133,14 +133,16 @@ enum
Re: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
On 2015-04-23 08:58, Mike Galbraith wrote:
> On Thu, 2015-04-23 at 08:29 +0200, Jan Kiszka wrote:
>>
>>> void irq_work_tick(void)
>>> {
>>> -#ifdef CONFIG_PREEMPT_RT_FULL
>>> - irq_work_run_list(this_cpu_ptr(&lazy_list));
>>> -#else
>>> - struct llist_head *raised = &__get_cpu_var(raised_list);
>>> + struct llist_head *raised = this_cpu_ptr(&raised_list);
>>>
>>> - if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
>>> + if (!llist_empty(raised) &&
>>> (!arch_irq_work_has_interrupt() ||
>>> + IS_ENABLED(CONFIG_PREEMPT_RT_FULL)))
>>
>> OK, that additional condition is addressing archs that don't have
>> irq_work support and fall back to the timer, right?
>
> How will ever run if it is not run in either irq_work_run() or
> irq_work_tick()? There are two choices, we better pick one.
Ah, now I see it. Indeed.
OK, will run through your fix and suggestions and come up with a new
version.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 3.18] irq_work: Provide a soft-irq based queue
On Thu, 2015-04-23 at 09:12 +0200, Jan Kiszka wrote:
> On 2015-04-23 09:01, Mike Galbraith wrote:
> > On Thu, 2015-04-23 at 08:50 +0200, Jan Kiszka wrote:
> > > On 2015-04-23 08:11, Mike Galbraith wrote:
> > > > @@ -103,6 +98,9 @@ EXPORT_SYMBOL_GPL(irq_work_queue_on);
> > > > /* Enqueue the irq work @work on the current CPU */
> > > > bool irq_work_queue(struct irq_work *work)
> > > > {
> > > > + bool realtime = IS_ENABLED(CONFIG_PREEMPT_RT_FULL);
> > > > + bool raise = false;
> > > > +
> > > > /* Only queue if not already pending */
> > > > if (!irq_work_claim(work))
> > > > return false;
> > > > @@ -110,25 +108,22 @@ bool irq_work_queue(struct irq_work *wor
> > > > /* Queue the entry and raise the IPI if needed. */
> > > > preempt_disable();
> > > >
> > > > -#ifdef CONFIG_PREEMPT_RT_FULL
> > > > - if (work->flags & IRQ_WORK_HARD_IRQ) {
> > > > + if (realtime && (work->flags & IRQ_WORK_HARD_IRQ)) {
> > > > if (llist_add(&work->llnode,
> > > > this_cpu_ptr(&hirq_work_list)))
> > >
> > > This boils down to
> > >
> > > #ifdef CONFIG_X
> > > some_type x;
> > > #endif
> > > ...
> > >
> > > if (IS_ENABLED(CONFIG_X) && ...)
> > > use(x);
> > >
> > > And here we even have an indirection for IS_ENABLED via that
> > > local
> > > bool
> > > variable. Is that pattern OK for Linux? Does it compile in all
> > > supported
> > > optimization levels of all supported compilers?
> >
> > I hope it all goes away, that being what IS_ENABLED() is there for.
>
> Hope is good - but not enough here: it breaks the build under
> !CONFIG_X, even the case without the bool var.
>
> CC kernel/irq_work.o
> In file included from ../include/asm-generic/percpu.h:6:0,
> from ../arch/x86/include/asm/percpu.h:522,
> from ../arch/x86/include/asm/current.h:5,
> from ../arch/x86/include/asm/processor.h:15,
> from ../arch/x86/include/asm/irq_work.h:4,
> from ../include/linux/irq_work.h:47,
> from ../kernel/irq_work.c:11:
> ../kernel/irq_work.c: In function ‘irq_work_queue_on’:
> ../kernel/irq_work.c:85:17: error: ‘hirq_work_list’ undeclared
> (first use in this function)
> &per_cpu(hirq_work_list, cpu));
Aw poo, so that's just what I _thought_ it was for.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 added to the 3.12 stable tree] net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5}
From: Markos Chandras
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 87f966d97b89774162df04d2106c6350c8fe4cb3 upstream.
On a MIPS Malta board, tons of fifo underflow errors have been observed
when using u-boot as bootloader instead of YAMON. The reason for that
is that YAMON used to set the pcnet device to SRAM mode but u-boot does
not. As a result, the default Tx threshold (64 bytes) is now too small to
keep the fifo relatively used and it can result to Tx fifo underflow errors.
As a result of which, it's best to setup the SRAM on supported controllers
so we can always use the NOUFLO bit.
Cc:
Cc:
Cc: Don Fry
Signed-off-by: Markos Chandras
Signed-off-by: David S. Miller
Signed-off-by: Jiri Slaby
---
drivers/net/ethernet/amd/pcnet32.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 2d8e28819779..048743573230 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1516,7 +1516,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
{
struct pcnet32_private *lp;
int i, media;
- int fdx, mii, fset, dxsuflo;
+ int fdx, mii, fset, dxsuflo, sram;
int chip_version;
char *chipname;
struct net_device *dev;
@@ -1553,7 +1553,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
}
/* initialize variables */
- fdx = mii = fset = dxsuflo = 0;
+ fdx = mii = fset = dxsuflo = sram = 0;
chip_version = (chip_version >> 12) & 0x;
switch (chip_version) {
@@ -1586,6 +1586,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
chipname = "PCnet/FAST III 79C973"; /* PCI */
fdx = 1;
mii = 1;
+ sram = 1;
break;
case 0x2626:
chipname = "PCnet/Home 79C978"; /* PCI */
@@ -1609,6 +1610,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
chipname = "PCnet/FAST III 79C975"; /* PCI */
fdx = 1;
mii = 1;
+ sram = 1;
break;
case 0x2628:
chipname = "PCnet/PRO 79C976";
@@ -1637,6 +1639,31 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct
pci_dev *pdev)
dxsuflo = 1;
}
+ /*
+* The Am79C973/Am79C975 controllers come with 12K of SRAM
+* which we can use for the Tx/Rx buffers but most importantly,
+* the use of SRAM allow us to use the BCR18:NOUFLO bit to avoid
+* Tx fifo underflows.
+*/
+ if (sram) {
+ /*
+* The SRAM is being configured in two steps. First we
+* set the SRAM size in the BCR25:SRAM_SIZE bits. According
+* to the datasheet, each bit corresponds to a 512-byte
+* page so we can have at most 24 pages. The SRAM_SIZE
+* holds the value of the upper 8 bits of the 16-bit SRAM size.
+* The low 8-bits start at 0x00 and end at 0xff. So the
+* address range is from 0x up to 0x17ff. Therefore,
+* the SRAM_SIZE is set to 0x17. The next step is to set
+* the BCR26:SRAM_BND midway through so the Tx and Rx
+* buffers can share the SRAM equally.
+*/
+ a->write_bcr(ioaddr, 25, 0x17);
+ a->write_bcr(ioaddr, 26, 0xc);
+ /* And finally enable the NOUFLO bit */
+ a->write_bcr(ioaddr, 18, a->read_bcr(ioaddr, 18) | (1 << 11));
+ }
+
dev = alloc_etherdev(sizeof(*lp));
if (!dev) {
ret = -ENOMEM;
--
2.3.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: Thunderbolt hotplug not working on MacMini7,1
On Wed, Apr 22, 2015 at 10:56:45PM -0400, Adam Goode wrote:
> On Wed, Apr 22, 2015 at 12:05 AM, Adam Goode wrote:
> > (resending in plain text)
> > (please CC me on replies, I am not on LKML)
> >
> > Hi,
> >
> > I have a new Mac Mini (MacMini7,1). This model supports hotplugging of
> > Thunderbolt on Windows 8 and above. Unfortunately hotplug does not
> > seem to be working for me under Linux. I get the default behavior of
> > devices only working if plugged in during boot.
> >
> > Also, the changes made to support Darwin for _OSI seems to make it
> > impossible to override. This makes it hard to test if the ACPI support
> > for Windows 2012 will just work on Linux. I have not built a kernel
> > yet with Darwin _OSI patched out.
> >
> > Any ideas? I think there are 2 ways forward:
> >
> > 1. Fix the thunderbolt code to work with this new Mac.
> > 2. Limit the Darwin _OSI response to a whitelisted set of Mac
> > machines. It seems like new Macs going forward may work best with the
> > standard Windows 2012 response. I don't know if this method would have
> > advantages over #1. The obvious change might be chained hotplugging
> > support. I don't have a chained device to test.
> >
>
> I have fixed the issue on my machine. On the Mac Mini, the 0x156c
> device has no subvendor or subdevice. When I added the new id to
> nhi_ids, everything worked without changing anything else in the
> kernel. This is in the _OSI("Darwin").
>
> Perhaps the driver is overmatching on subvendor/subdevice. Is it
> necessary to do so on some models?
Looks like it.
Can you send a patch showing the change you made to get this to work?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: powerpc: Fix ppc64_defconfig + PPC_POWERNV=n build error
On Thu, 2015-04-23 at 10:11 +0530, Shreyas B Prabhu wrote: > Any suggestions on this? It's in: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=fixes 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/
[PATCH V2 -next] ocfs2: Reduce object size of mlog uses
Using a function for __mlog_printk instead of a macro
reduces the object size of built-in.o by about 190KB, or
~18% overall (x86-64 defconfig with all ocfs2 options)
$ size fs/ocfs2/built-in.o*
textdata bss dec hex filename
870954 118471 134408 1123833 1125f9 fs/ocfs2/built-in.o,new
1064081 118071 134408 1316560 1416d0 fs/ocfs2/built-in.o.old
Miscellanea:
o Move the used-once __mlog_cpu_guess statement expression macro
to the masklog.c file above the use in __mlog_printk function
o Simplify the mlog macro moving the and/or logic and level code
into __mlog_printk
Signed-off-by: Joe Perches
---
V2: Moving and/or logic to the __mlog_printk function reduces
the object size an additional ~65K
fs/ocfs2/cluster/masklog.c | 46 ++
fs/ocfs2/cluster/masklog.h | 42 --
2 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
index af7598b..fc5e522 100644
--- a/fs/ocfs2/cluster/masklog.c
+++ b/fs/ocfs2/cluster/masklog.c
@@ -64,6 +64,52 @@ static ssize_t mlog_mask_store(u64 mask, const char *buf,
size_t count)
return count;
}
+/*
+ * smp_processor_id() "helpfully" screams when called outside preemptible
+ * regions in current kernels. sles doesn't have the variants that don't
+ * scream. just do this instead of trying to guess which we're building
+ * against.. *sigh*.
+ */
+#define __mlog_cpu_guess \
+({ \
+ unsigned long _cpu = get_cpu(); \
+ put_cpu(); \
+ _cpu; \
+})
+
+void __mlog_printk(const u64 *mask, const char *func, int line,
+ const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ const char *level;
+ const char *prefix = "";
+
+ if (!__mlog_test_u64(*mask, mlog_and_bits) ||
+ __mlog_test_u64(*mask, mlog_not_bits))
+ return;
+
+ if (*mask & ML_ERROR) {
+ level = KERN_ERR;
+ prefix = "ERROR: ";
+ } else if (*mask & ML_NOTICE) {
+ level = KERN_NOTICE;
+ } else {
+ level = KERN_INFO;
+ }
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ printk("%s(%s,%u,%lu):%s:%d %s%pV",
+ level, current->comm, task_pid_nr(current), __mlog_cpu_guess,
+ func, line, prefix, &vaf);
+
+ va_end(args);
+}
+
struct mlog_attribute {
struct attribute attr;
u64 mask;
diff --git a/fs/ocfs2/cluster/masklog.h b/fs/ocfs2/cluster/masklog.h
index 7fdc25a..308ea0e 100644
--- a/fs/ocfs2/cluster/masklog.h
+++ b/fs/ocfs2/cluster/masklog.h
@@ -162,38 +162,20 @@ extern struct mlog_bits mlog_and_bits, mlog_not_bits;
#endif
-/*
- * smp_processor_id() "helpfully" screams when called outside preemptible
- * regions in current kernels. sles doesn't have the variants that don't
- * scream. just do this instead of trying to guess which we're building
- * against.. *sigh*.
- */
-#define __mlog_cpu_guess ({\
- unsigned long _cpu = get_cpu(); \
- put_cpu(); \
- _cpu; \
-})
+__printf(4, 5)
+void __mlog_printk(const u64 *m, const char *func, int line,
+ const char *fmt, ...);
-/* In the following two macros, the whitespace after the ',' just
- * before ##args is intentional. Otherwise, gcc 2.95 will eat the
- * previous token if args expands to nothing.
+/*
+ * Testing before the __mlog_printk call lets the compiler eliminate the
+ * call completely when (m & ML_ALLOWED_BITS) is 0.
*/
-#define __mlog_printk(level, fmt, args...) \
- printk(level "(%s,%u,%lu):%s:%d " fmt, current->comm, \
- task_pid_nr(current), __mlog_cpu_guess, \
- __PRETTY_FUNCTION__, __LINE__ , ##args)
-
-#define mlog(mask, fmt, args...) do { \
- u64 __m = MLOG_MASK_PREFIX | (mask);\
- if ((__m & ML_ALLOWED_BITS) && \
- __mlog_test_u64(__m, mlog_and_bits) && \
- !__mlog_test_u64(__m, mlog_not_bits)) { \
- if (__m & ML_ERROR) \
- __mlog_printk(KERN_ERR, "ERROR: "fmt , ##args); \
- else if (__m & ML_NOTICE) \
- __mlog_printk(KERN_NOTICE, fmt , ##args); \
- else __mlog_printk(KERN_INFO, fmt , ##args);\
- }
Re: [PATCH v3 4/4] of/platform: Use platform_device interface
Hello Rob
On Wed, Apr 22, 2015 at 6:25 PM, Rob Herring wrote:
>> This patch, replaces of_device_add() with platform_device_data().
>
> This doesn't match the change.
Thanks for catching it up. Will fix it and resend
>> - if (of_device_add(dev) != 0) {
>> + if (platform_device_add(dev) != 0) {
>
> Can't we now remove of_device_add?
Now it is only used by ibmebus
ricardo@neopili:~/linux-upstream$ git grep of_device_add
arch/powerpc/kernel/ibmebus.c: ret = of_device_add(dev);
drivers/of/device.c:int of_device_add(struct platform_device *ofdev)
drivers/of/device.c:return of_device_add(pdev);
include/linux/of_device.h:extern int of_device_add(struct
platform_device *pdev);
I think it can also use platform_device_add. I will prepare a patch to
finally remove of_device_add()
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.12.y stable] crypto: testmgr - fix 3.12.40 regression
On 04/21/2015, 06:31 PM, Lennart Sorensen wrote: > commit ace3fc1e3f3a85ec705805146247231b11e1babe in 3.12.40 missed two > lines while pulling in commit 8a45ac12ec5b6ee67f8559c78ae11d9af8b821ee > from upstream. This causes the tests to fail in some cases. > > With the two missing lines added in, the tests pass again. > > Tested with omap-aes, omap-sham and talitos. > > Signed-off-by: Len Sorensen Applied, thanks! -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors
On Tue, Apr 21, 2015 at 9:43 PM, Tomasz Duszynski wrote:
> Add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light
> sensors.
>
> Signed-off-by: Tomasz Duszynski
> ---
> drivers/iio/light/Kconfig | 10 ++
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/bh1750.c | 322
> +
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/iio/light/bh1750.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 5a3237b..9fb79ca 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -37,6 +37,16 @@ config APDS9300
> To compile this driver as a module, choose M here: the
> module will be called apds9300.
>
> +config BH1750
> + tristate "BH1750 ambient light sensor"
Better use ROHM BH1750 .. here.
> +static const struct iio_chan_spec bh1750_channels[] = {
> + {
> + .type = IIO_INTENSITY,
Shouldn't this be IIO_LIGHT channel type?
Users will get illuminance after multiplying raw value with scale.
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_INT_TIME)
> + }
> +};
> +
> +static int bh1750_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + int ret, usec;
> + struct bh1750_data *data;
> + struct iio_dev *indio_dev;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
> + I2C_FUNC_SMBUS_WRITE_BYTE))
> + return -ENODEV;
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + i2c_set_clientdata(client, indio_dev);
> + data->client = client;
> + data->chip_info = &chip_info_tbl[id->driver_data];
> +
> + usec = data->chip_info->mtreg_to_usec *
> data->chip_info->mtreg_default;
> + ret = bh1750_change_int_time(data, usec);
> + if (ret < 0)
> + return ret;
> +
> + mutex_init(&data->lock);
> + indio_dev->dev.parent = &client->dev;
> + indio_dev->info = &bh1750_info;
> + indio_dev->name = id->name;
> + indio_dev->channels = bh1750_channels;
> + indio_dev->num_channels = ARRAY_SIZE(bh1750_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + return devm_iio_device_register(&client->dev, indio_dev);
You need also to add a remove function where the chip is powered down. Then
you shouldn't use devm_iio_device_register here, because you need to control
the order of chip powerdown/ device unregister operations at remove.
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/27] IB/Verbs: IB Management Helpers
On 04/22/2015 06:16 PM, Liran Liss wrote: [snip] > > Depends on who is "we". > For ULPs, you are probably right. > > However, core services (e.g., mad management, CM, SA) do care about various > details. > In some cases, where it doesn't matter, this code will use management helpers. > In other cases, this code will inspect link, transport, and node attributes > of rdma devices. > > For example, the CM code has specific code paths for IB, RoCE, and iWARP. > There is no other CM code; there is no reason to abstract 'CM'. This code > will have code > paths that depend on various specific details. That's exactly what we want to stop, we have classified the CM to IB and IWARP now :-) > >> This new transport is only understand by core-layer currently, for user-layer >> we still reserve the old transport for them, next step is to use bitmask >> instead >> of transport, at that time we can erase the new transport and make the >> whole stuff used by user-layer only :-) >> > > I am not sure that we need a bit mask at all. > Your helpers already provide all the useful abstractions, which both core and > ULPs call directly. > All the information is inferred directly from tuples. > > Some of the user-space tools need *exactly* the same reasoning. > For example, management tools manage specific technologies and protocols, not > some abstraction. > > So, For user-space, we can think about exposing exactly the same helper > framework, while providing > backward compatibility for the existing interfaces. I'd really like to put the topic on bitmask and user app reform into different thread... bitmask should be next topic, there are many discussion already, but I could imaging far more discussion there, the user reform should be the last step, after every thing in kernel settled down :-) > >>> >>> >>> Detailed remarks >>> == >>> >>> 1) The introduction of cap_*_*() stuff should have been introduced directly >> in patch 02/27. >>> This back-and-forth between rdma_ib_or_iboe() and cap_* is confusing and >> increases the number of patches in the patch-set. >>> Do this and remove patches 16-24. >> >> We have some discussion about compress the patch set, merge the reform >> and introducing patch will mix the concept (like the earlier version), IMHO >> it >> will increase the difficulty of review... >> >> And now since many review already been done, it's not wise to change the >> whole structure of patch set IMHO... >> > > I think it is because you are conditioning code on one thing, and then > conditioning > the same code on another thing. > > This is confusing. > > Once we get our abstractions correct (i.e., the right helper functions), you > replace the > existing logic with the suitable helper up-front. We need to classify and integrate the concept into mgmt helper, that would be very helpful for further reform, reform followed by integration sounds not that bad, correct? > >>> >>> 2)The name rdma_tech_* is lame. >>> rdma_transport_*(), adhering to the above (*) remark, is much better. >>> For example, both IB and ROCE *do* use the same transport. >> >> We have some discussion on that too, use transport means going back... >> > > No. > The existing notion of transport was correct. It was the node type that > wasn't. > And in any case the new helpers didn't use it. > > We need the original meaning of transport - see my response to Ira. > I propose replacing rdma_node_get_transport() with the following helpers: > - rdma_get_transport() > - rdma_is_ib_transport() > - rdma_is_iwarp_transport() We can change the name at anytime, tech/transport/protocol/standard, just one patch later can easily change it and start the topic of naming, any of these name will unsatisfied someone AFAIK, I'd like to suggest we consider this as a mark temporarily and focus on the logical issue. > - ... > >>> >>> 3) The name cap_* as it is used above is not accurate. >>> You use it to describe technology characteristics rather than extendable >> capabilities. >>> I would suggest having a single convention for all helpers, such as >> rdma_has_*() and rdma_is_*(). >>> For example: cap_ib_smi() ==> rdma_has_smi(). >> >> That means going back too... > > See response to Ira (https://lkml.org/lkml/2015/4/21/951). > > >> >>> >>> 4) Remove all capabilities that do not introduce any distinction in the >> current code. >>> We can add them as needed later. >>> This means remove patches: >>> - [PATCH v5 22/27] IB/Verbs: Use management helper cap_ipoib() – all >>> IB devices support ipoib >>> - [PATCH v5 24/27] IB/Verbs: Use management helper cap_af_ib() – all IB >> devices support AF_IB. >>> >>> On the other hand: >>> - rdma_has_multicast() makes sense, since iWARP doesn’t support it. >>> - cap_ib_sa() might make sense to cut code even further in the CMA, since >> RoCE has a GSI but no SA. >> >> We have discussion on define these helpers previously, again, name is not >> really a problem, I would rather to see su
[PATCH v2 RT 3.18] irq_work: Provide a soft-irq based queue
Instead of turning all irq_work requests into lazy ones on -rt, just
move their execution from hard into soft-irq context.
This resolves deadlocks of ftrace which will queue work from arbitrary
contexts, including those that have locks held that are needed for
raising a soft-irq.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- fix execution of raised list (discovered by Mike Galbraith)
- added comment of irq_work_run (derived from Mike's suggestion)
kernel/irq_work.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 9dda38a..171dfac 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -85,12 +85,9 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
raise_irqwork = llist_add(&work->llnode,
&per_cpu(hirq_work_list, cpu));
else
- raise_irqwork = llist_add(&work->llnode,
- &per_cpu(lazy_list, cpu));
-#else
+#endif
raise_irqwork = llist_add(&work->llnode,
&per_cpu(raised_list, cpu));
-#endif
if (raise_irqwork)
arch_send_call_function_single_ipi(cpu);
@@ -114,21 +111,20 @@ bool irq_work_queue(struct irq_work *work)
if (work->flags & IRQ_WORK_HARD_IRQ) {
if (llist_add(&work->llnode, this_cpu_ptr(&hirq_work_list)))
arch_irq_work_raise();
- } else {
+ } else
+#endif
+ if (work->flags & IRQ_WORK_LAZY) {
if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
tick_nohz_tick_stopped())
+#ifdef CONFIG_PREEMPT_RT_FULL
raise_softirq(TIMER_SOFTIRQ);
- }
#else
- if (work->flags & IRQ_WORK_LAZY) {
- if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
- tick_nohz_tick_stopped())
arch_irq_work_raise();
+#endif
} else {
if (llist_add(&work->llnode, this_cpu_ptr(&raised_list)))
arch_irq_work_raise();
}
-#endif
preempt_enable();
@@ -202,6 +198,13 @@ void irq_work_run(void)
{
#ifdef CONFIG_PREEMPT_RT_FULL
irq_work_run_list(this_cpu_ptr(&hirq_work_list));
+ /*
+* NOTE: we raise softirq via IPI for safety (caller may hold locks
+* that raise_softirq needs) and execute in irq_work_tick() to move
+* the overhead from hard to soft irq context.
+*/
+ if (!llist_empty(this_cpu_ptr(&raised_list)))
+ raise_softirq(TIMER_SOFTIRQ);
#else
irq_work_run_list(this_cpu_ptr(&raised_list));
irq_work_run_list(this_cpu_ptr(&lazy_list));
@@ -211,15 +214,12 @@ EXPORT_SYMBOL_GPL(irq_work_run);
void irq_work_tick(void)
{
-#ifdef CONFIG_PREEMPT_RT_FULL
- irq_work_run_list(this_cpu_ptr(&lazy_list));
-#else
- struct llist_head *raised = &__get_cpu_var(raised_list);
+ struct llist_head *raised = this_cpu_ptr(&raised_list);
- if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
+ if (!llist_empty(raised) && (!arch_irq_work_has_interrupt() ||
+IS_ENABLED(CONFIG_PREEMPT_RT_FULL)))
irq_work_run_list(raised);
- irq_work_run_list(&__get_cpu_var(lazy_list));
-#endif
+ irq_work_run_list(this_cpu_ptr(&lazy_list));
}
/*
--
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/
Re: [PATCH 2/2] PCI: designware: use iATU0 for cfg and IO, iATU1 for MEM
Hi Jisheng, On 04/22/2015 02:58 PM, Jisheng Zhang wrote: Most transactions' type are cfg0 and MEM, so the Current iATU usage is not balanced, iATU0 is hot while iATU1 is rarely used. This patch refactors the iATU usage: iATU0 for cfg and IO, iATU1 for MEM. This allocation ideas comes from Minghuan Lian: http://www.spinics.net/lists/linux-pci/msg40440.html Signed-off-by: Jisheng Zhang --- drivers/pci/host/pcie-designware.c | 83 +- 1 file changed, 47 insertions(+), 36 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 1da1446..bb81c8ad 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -508,6 +508,13 @@ int dw_pcie_host_init(struct pcie_port *pp) if (pp->ops->host_init) pp->ops->host_init(pp); + dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0, + PCIE_ATU_TYPE_IO, pp->io_mod_base, + pp->io_bus_addr, pp->io_size); + dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1, + PCIE_ATU_TYPE_MEM, pp->mem_mod_base, + pp->mem_bus_addr, pp->mem_size); + Some platforms doesn't have support for ATU. I think this is the reason to have rd_other_conf / wr_other_conf ops in the driver. IMO, this is not suitable to have this in the initialization routine for all platforms. Regards, Fabrice -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86/asm/entry/32: Remove unnecessary optimization in stub32_clone
On Thu, Apr 23, 2015 at 08:24:38AM +0200, Ingo Molnar wrote: > * Josh Triplett wrote: > > On Wed, Apr 22, 2015 at 11:22:02AM -0700, Linus Torvalds wrote: > > > On Wed, Apr 22, 2015 at 10:10 AM, Josh Triplett > > > wrote: > > > > > > > > I do think my two-patch HAVE_COPY_THREAD_TLS series should go in fixing > > > > this > > > > > > Ugh, I absolutely detesrt that patch. > > > > > > Don't make random crazy function signatures that depend on some config > > > option. That's just evil. The patch is a mess of #ifdef's and should > > > be shot in the head and staked with a silver stake to make sure it > > > never re-appears. > > > > > > Either: > > > > > > (a) make the change for every architecture > > > > > > (b) have side-by-side interfaces. With different names! > > > > ...that's exactly what I did. They're called copy_thread and > > copy_thread_tls; I very intentionally did not conditionally change > > the signature of copy_thread, for exactly that reason. Those > > functions are implemented in architecture-specific code, so the > > config option just specifies which of the two functions the > > architecture provides. > > > > *sys_clone* has different function signatures based on config > > options, but I didn't touch that other than fixing the type of the > > tls argument. That's historical baggage that we can't throw away > > without breaking userspace. > > So you want to add a new clone() parameter. I strongly suspect that > you won't be the last person who wants to do this. > > So why not leave the compatibility baggage alone and introduce a new > clean clone syscall with a flexible, backwards and forwards compatible > parameter ABI? ...that's also exactly what I did, in the clone4 patch series, which uses exactly the arg-structure approach you're describing. :) Take a look at the clone4 patch series (v2). We'll be updating it to v3 to address some feedback, and we're hoping to aim for the 4.2 merge window. > Something like: > > SYSCALL_DEFINE1(clone_params, struct clone_params __user *, params) clone4 passes the size outside the params structure, since otherwise you'd need to copy the first few bytes to know how much more to copy. clone4 also passes flags outside the params structure, to allow for a potential future flag that might indicate a completely different interpretation of the params structure. But otherwise, yes, clone4 moves all the parameters into a structure. (Differences between clone4_args and your clone_params structure: size and flags passed outside, type of the tls parameter is "unsigned long" since it's pointer-sized, and the structure includes the stack_size argument needed on some architectures.) > The only real cost of this approach is that this parameter structure > has to be copied (once): should be fast as it fits into a single cache > line and is a constant size copy. Also note how this parameter block > can be passed down by const reference from that point on, instead of > copying/shuffling 5-6 parameters into increasingly long function > parameter lists. So it might in fact turn out to be slightly faster as > well. Agreed. > Note how easily extensible it is: a new field can be added by > appending to the structure, and compatibility is achieved in the > kernel without explicit versioning, by checking params->size: > > params->size == sizeof(*params): > > Good, kernel and userspace ABI version matches. This is a simple > check and the most typical situation - it will be the fastest as > well. > > > params->size < sizeof(*params): > > Old binary calls into new kernel. Missing fields are set to 0. > Binaries will be forward compatible without any versioning hacks. I combined these two cases by just copying the userspace struct over a pre-zeroed params structure; then any fields not copied over will remain zero. > params->size > sizeof(*params): > > New user-space calls into old kernel. System call can still be > serviced if the new field(s) are all zero. We return -ENOSYS if > any field is non-zero. (i.e. if new user-space tries to make use > of a new syscall feature that this kernel has not implemented > yet.) This way user-space can figure out whether a particular > new parameter is supported by a kernel, without having to add new > system calls or versioning. In theory clone4 could have had this special case for "userspace passed extra parameters this kernel doesn't understand, but they're all zero", but since this is a brand new ABI, it seems far easier for userspace to simply pass only the size needed for its non-zero parameters, and then the kernel can reject structures larger than it expects. Only pass the new version of the args structure if you need to pass non-zero values for the new fields in that version. Since clone4 doesn't even copy the structure if the size exceeds what it understands, that also avoids additional special cases such as the
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Tue, Mar 31, 2015 at 8:38 AM, tip-bot for Denys Vlasenko wrote: > Commit-ID: e7d6eefaaa443130079d73cd05039d90b3db7a4a > Gitweb: http://git.kernel.org/tip/e7d6eefaaa443130079d73cd05039d90b3db7a4a > Author: Denys Vlasenko > AuthorDate: Fri, 27 Mar 2015 11:48:17 -0700 > Committer: Ingo Molnar > CommitDate: Tue, 31 Mar 2015 10:45:15 +0200 > > x86/vdso32/syscall.S: Do not load __USER32_DS to %ss > > This vDSO code only gets used by 64-bit kernels, not 32-bit ones. > > On 64-bit kernels, the data segment is the same for 32-bit and > 64-bit userspace, and the SYSRET instruction loads %ss with its > selector. > > So there's no need to repeat it by hand. Segment loads are somewhat > expensive: tens of cycles. > > Signed-off-by: Denys Vlasenko > [ Removed unnecessary comment. ] > Signed-off-by: Andy Lutomirski > Cc: Alexei Starovoitov > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Frederic Weisbecker > Cc: H. Peter Anvin > Cc: Kees Cook > Cc: Linus Torvalds > Cc: Oleg Nesterov > Cc: Steven Rostedt > Cc: Will Drewry > Link: > http://lkml.kernel.org/r/63da6d778f69fd0f1345d9287f6764d58be519fa.1427482099.git.l...@kernel.org > Signed-off-by: Ingo Molnar > --- > arch/x86/vdso/vdso32/syscall.S | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S > index 5415b56..6b286bb 100644 > --- a/arch/x86/vdso/vdso32/syscall.S > +++ b/arch/x86/vdso/vdso32/syscall.S > @@ -19,8 +19,6 @@ __kernel_vsyscall: > .Lpush_ebp: > movl%ecx, %ebp > syscall > - movl$__USER32_DS, %ecx > - movl%ecx, %ss > movl%ebp, %ecx > popl%ebp > .Lpop_ebp: This patch unfortunately is causing Wine to break on some applications: Unhandled exception: stack overflow in 32-bit code (0xf779bc07). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f779bc07 ESP:00aed60c EBP:00aed750 EFLAGS:00010216( R- -- I -A-P- ) EAX:0040 EBX:0010 ECX:00aed750 EDX:0040 ESI:0040 EDI:7ffd4000 Stack dump: 0x00aed60c: 00aed648 f7575e5b 7bcc8000 0x00aed61c: 7bc7bc09 0010 00aed750 0040 0x00aed62c: 00aed750 00aed650 7bcc8000 7bc7bbdd 0x00aed63c: 7bcc8000 00aed6a0 00aed750 00aed738 0x00aed64c: 7bc7cfa9 0011 00aed750 0040 0x00aed65c: 0020 7bc4f141 Backtrace: =>0 0xf779bc07 __kernel_vsyscall+0x7() in [vdso].so (0x00aed750) 1 0xf7575e5b __libc_read+0x4a() in libpthread.so.0 (0x00aed648) 2 0x7bc7bc09 read_reply_data+0x38(buffer=0xaed750, size=0x40) [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/server.c:239] in ntdll (0x00aed648) 3 0x7bc7cfa9 wine_server_call+0x178() in ntdll (0x00aed738) 4 0x7bc840ec NtSetEvent+0x4b(handle=0x80, NumberOfThreadsReleased=0x0(nil)) [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/sync.c:361] in ntdll (0x00aed7c8) 5 0x7b874afa SetEvent+0x24(handle=) [/home/bgerst/src/wine/wine32/dlls/kernel32/../../../dlls/kernel32/sync.c:572] in kernel32 (0x00aed7e8) 6 0x0044e31a in battle.net launcher (+0x4e319) (0x00aed818) ... __kernel_vsyscall+0x7 points to "pop %ebp". This is on an AMD Phenom(tm) II X6 1055T Processor. It appears that there are some subtle differences in how sysretl works on AMD vs. Intel. According to the Intel docs, the SS selector and descriptor cache is completely reset by sysret to fixed values. The AMD docs however are concerning: AMD's syscall: SS.sel = MSR_STAR.SYSCALL_CS + 8 SS.attr = 64-bit stack,dpl0 SS.base = 0x SS.limit = 0x AMD's sysret: SS.sel = MSR_STAR.SYSRET_CS + 8 // SS selector is changed, // SS base, limit, attributes unchanged. Not changing base or limit is no big deal, but not changing attributes could be the problem. It might be leaving the "64-bit stack" attribute set, for whatever that means. Reloading SS from the GDT would obviously reset any bad state left by sysretl. Unfortunately we may have to put it back in, and then NOP it out on Intel. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv3 0/4] add devm_of_phy_get_by_index and update platform drivers
Hi, On 23-04-15 01:04, Arun Ramamurthy wrote: This patch set adds a new API to get phy by index when multiple phys are present. This patch is based on discussion with Arnd Bergmann about dt bindings for multiple phys. History: v1: - Removed null pointers on Dmitry's suggestion - Improved documentation in commit messages - Exported new phy api v2: - EHCI and OHCI platform Kconfigs select Generic Phy to fix build errors in certain configs. v3: - Made GENERIC_PHY an invisible option so that other configs can select it - Added stubs for devm_of_phy_get_by_index - Reformated code Arun Ramamurthy (4): phy: phy-core: Make GENERIC_PHY an invisible option phy: core: Add devm_of_phy_get_by_index to phy-core usb: ehci-platform: Use devm_of_phy_get_by_index usb: ohci-platform: Use devm_of_phy_get_by_index Documentation/phy.txt | 7 +++- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 +- drivers/phy/phy-core.c| 32 ++ drivers/usb/host/Kconfig | 4 +- drivers/usb/host/ehci-platform.c | 69 +++ drivers/usb/host/ohci-platform.c | 69 +++ drivers/video/fbdev/exynos/Kconfig| 2 +- include/linux/phy/phy.h | 8 10 files changed, 100 insertions(+), 98 deletions(-) Patch set looks good to me: Acked-by: Hans de Goede Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] elevator: remove unneeded kfree in error path of elevator_alloc
In elevator_alloc, if we fail to allocate memory for storing elevator queue, our eq pointer must be NULL, we do not need to release it in error path, so remove it. Signed-off-by: Chao Yu --- block/elevator.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/elevator.c b/block/elevator.c index 59794d0..d146a5e 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -166,7 +166,6 @@ struct elevator_queue *elevator_alloc(struct request_queue *q, return eq; err: - kfree(eq); elevator_put(e); return NULL; } -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] ata: add Broadcom AHCI SATA3 driver for STB chips
On Wednesday 22 April 2015 19:59:08 Brian Norris wrote:
> Pretty straightforward driver, using the nice library-ization of the
> generic ahci_platform driver.
>
> Signed-off-by: Brian Norris
There is an alternative way to do this, by writing a separate phy driver
for drivers/phy and using the generic ahci-platform driver. Have you
considered that as well? I don't know which approach works better here,
but in general we should try to have the generic driver handle as many
chips as possible.
> diff --git a/drivers/ata/sata_brcmstb.c b/drivers/ata/sata_brcmstb.c
> new file mode 100644
> index ..ab8d2261fa96
> --- /dev/null
> +++ b/drivers/ata/sata_brcmstb.c
> @@ -0,0 +1,285 @@
> +/*
> + * Broadcom SATA3 AHCI Controller Driver
Is this AHCI or not? Most AHCI drivers are called ahci_*.c, not sata_*.c
> +#ifdef __BIG_ENDIAN
> +#define DATA_ENDIAN 2 /* AHCI->DDR inbound accesses */
> +#define MMIO_ENDIAN 2 /* CPU->AHCI outbound accesses */
> +#else
> +#define DATA_ENDIAN 0
> +#define MMIO_ENDIAN 0
> +#endif
Is this for MIPS or ARM based chips or both? ARM SoCs should never care
about the endianess of the CPU, so I'd expect something like
#if defined(__BIG_ENDIAN) && defined(CONFIG_MIPS)
/* mips big-endian stuff */
#else
/* all other combinations */
#endif
> +static void brcm_sata_phy_enable(struct brcm_ahci_priv *priv, int port)
> +{
> + void __iomem *phyctrl = priv->top_ctrl + SATA_TOP_CTRL_PHY_CTRL +
> + (port * SATA_TOP_CTRL_PHY_OFFS);
> + void __iomem *p;
> + u32 reg;
> +
> + /* clear PHY_DEFAULT_POWER_STATE */
> + p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_1;
> + reg = __raw_readl(p);
> + reg &= ~SATA_TOP_CTRL_1_PHY_DEFAULT_POWER_STATE;
> + __raw_writel(reg, p);
Similarly, the use of __raw_readl() is broken on ARM here and won't
work on big-endian kernels. Better use a driver specific helper
function that does the right thing based on the architecture and
endianess. You can use the same conditional as above and do
#if defined(__BIG_ENDIAN) && defined(CONFIG_MIPS)
static inline brcm_sata_phy_read(struct brcm_ahci_phy *priv, int port int reg)
{
void __iomem *phyctrl = priv->regs;
if (IS_ENABLED(CONFIG_MIPS) && IS_ENABLED(__BIG_ENDIAN))
return __raw_readl(regs->reg);
return readl_relaxed(regs->reg);
}
> +static const struct of_device_id ahci_of_match[] = {
> + {.compatible = "brcm,sata3-ahci"},
> + {},
This sounds awefully generic. Can you guarantee that no part of Broadcom
has produced another ahci-like SATA3 controller in the past, or will
have one in the future?
If not, please be more specific here, and use the internal specifier for
this version of the IP block. If you can't find out what that is, use the
identifier for the oldest chip you know that has it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][PATCHSET] non-recursive link_path_walk() and reducing stack footprint
On Wed, 22 Apr 2015 22:05:53 +0100 Al Viro wrote:
> On Wed, Apr 22, 2015 at 09:12:38PM +0100, Al Viro wrote:
> > On Wed, Apr 22, 2015 at 07:07:59PM +0100, Al Viro wrote:
> > > And one more: may_follow_link() is now potentially oopsable. Look:
> > > suppose
> > > we've reached the link in RCU mode, just as it got unlinked. link->dentry
> > > has become negative and may_follow_link() steps into
> > > /* Allowed if owner and follower match. */
> > > inode = link->dentry->d_inode;
> > > if (uid_eq(current_cred()->fsuid, inode->i_uid))
> > > return 0;
> > > Oops... Incidentally, I suspect that your __read_seqcount_retry() in
> > > follow_link() might be lacking a barrier; why isn't full
> > > read_seqcount_retry()
> > > needed?
Blind copy-paste error I suspect.
> > >
> > > FWIW, I would rather fetch ->d_inode *and* checked ->seq proir to calling
> > > get_link(), and passed inode to it as an explicit argument. And passed it
> > > to may_follow_link() as well...
> >
> > Hrm... You know, something really weird is going on here. Where are
> > you setting nd->seq? I don't see anything in follow_link() doing that.
follow_link calls link_path_walk -> walk_component -> lookup_fast which sets
nd->seq. Is that not enough? I guess not when nd_jump_link is called. Is
that what I missed?
> > And nd->seq _definitely_ needs setting if you want to stay in RCU mode -
> > at that point it matches the dentry of symlink, not that of nd->path
> > (== parent directory). Neil, could you tell me which kernel you'd been
> > testing (ideally - commit ID is a public git tree), what config and what
> > tests had those been?
The 'devel' branch of git://neil.brown.name/md, which is based on 4.0-rc7.
Tests have been fairly causal so far, making sure I can follow symlinks on a
small variety of filesystems, and running a particular test which repeatedly
stats a large number of non-existent files with paths that go through a
symlink.
>
> FWIW, there's a wart that had been annoying me for quite a while, and it
> might be related to dealing with that properly. Namely, walk_component()
> calling conventions. We have walk_component(nd, &path, follow), which can
> * return -E..., and leave us with pathwalk terminated; path contains
> junk, and so does nd->path.
> * return 0, update nd->path, nd->inode and nd->seq. The contents
> of path is in undefined state - it might be unchanged, it might be equal to
> nd->path (and not pinned down, RCU mode or not). In any case, callers do
> not touch it afterwards. That's the normal case.
> * return 1, update nd->seq, leave nd->path and nd->inode unchanged and
> set path pointing to our symlink. nd->seq matches path, not nd->path.
>
> In all cases the original contents of path is ignored - it's purely 'out'
> parameter, but compiler can't establish that on its own; it _might_ be
> left untouched. In all cases when its contents survives we don't look at
> it afterwards, but proving that requires a non-trivial analysis.
>
> And in case when we return 1 (== symlink to be followed), we bugger nd->seq.
> It's left as we need it for unlazy_walk() (and after unlazy_walk() we don't
> care about it at all), so currently everything works, but if we want to
> stay in RCU mode for symlink traversal, we _will_ need ->d_seq of parent
> directory.
>
> I wonder if the right way to solve that would be to drop the path argument
> entirely and store the bugger in nameidata. As in
> union {
> struct qstr last;
> struct path link;
> };
> ...
> union {
> int last_type;
> unsigned link_seq;
> };
> in struct nameidata. We never need both at the same time; after
> walk_component() (or its analogue in do_last()) we don't need the component
> name anymore. That way walk_component() would not trash nd->seq when
> finding a symlink...
>
> It would also shrink the stack footprint a bit - local struct path next
> in link_path_walk() would be gone, along with the same thing in
> path_lookupat()
> and friends. Not a lot of win (4 pointers total), but it might be enough
> to excuse putting ->d_seq of root in there, along with ->link.dentry->d_inode,
> to avoid rechecking its ->d_seq. As the matter of fact, we do have an
> odd number of 32bit fields in there, so ->d_seq of root would fit nicely...
>
> Comments?
One thing that is clear to me is that I don't really understand all the
handling of 'seq' numbers, making me unable to comment usefully.
I'll try to go through the current code and you current patch with that issue
in mind and make sure I do understand it. Then I'll try to comment.
Meanwhile, I like your suggestion in separate email to legitimize the whole
symlink stack when unlazy_walk is needed. One reason that I didn't even try
that originally is that it was not practical to walk the stack to find
everything that needed legitimizing. Now that
Re: [PATCH] mm/hugetlb: use pmd_page() in follow_huge_pmd()
On 04/10/2015, 10:38 PM, Andrew Morton wrote: > hm. I think I'll make it > > Fixes: 61f77eda "mm/hugetlb: reduce arch dependent code around follow_huge_*" +1. This is the best tag to work with. thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] mtd: nand_bbt: drop unnecessary header
On 22 April 2015 at 19:50, Brian Norris wrote: > On Thu, Apr 16, 2015 at 02:09:41AM +, Peter Pan 潘栋 (peterpandong) wrote: >> >> Signed-off-by: Brian Norris >> Signed-off-by: Peter Pan > > Why are you just resending my patches? You could Ack/Reviewed-by/etc. > instead... > > http://patchwork.ozlabs.org/patch/444604/ That was fishy to me too, thanks for clarifying it Brian. Also, if you *really* need to submit somebody's patch, you *should* use From to point the author to git. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] mtd: nand_bbt: drop unnecessary header
On 16 April 2015 at 04:09, Peter Pan 潘栋 (peterpandong) wrote: > > Signed-off-by: Brian Norris > Signed-off-by: Peter Pan I'm curious, what made you picking my e-mail address directly? -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FROM; Mr.BEN D DICKSON,\\\Hello my good friend
Date: 23/04/2015 Hello my good friend. How are you today? Hope all is well with you and your family?, You may not understand why this mail came to you.But if you do not remember me, you might have receive an email from me in the past regarding a multi-million-dollar business proposal which we never concluded.I am using this opportunity to inform you that this multi-million-dollar business has been concluded with the assistance of another partner from Thailand who financed the transaction to a logical conclusion. I thank you for your great effort to our unfinished transfer of fund into your account due to one reason or the other best known to you.But I want to inform you that I havesuccessfully transferred the fund out of my bank to my new partner's account in Thailand that was capable of assisting me in this great venture. Due to your effort, sincerity, courage and trust worthiness You showed during the course of the transaction.I want to compensate you and show mygratitude to you with the sum of $1,200,000.00. I have left a certified international bank draft for you worth of $1,200,000.00 cashable anywhere in the world. My dear friend I will like you to contact my secretary Mr. Foxton Richard, on his direct email address at:Mr; foxtonrich...@yandex.com for the collection of your bank draft. I authorized her to release the Bank draft to you whenever you contact him regarding the draft. At the moment, I'm very busy here because of the investment projects, which I and the new partner are having at hand. Please I will like you to accept this with good faith as this is from the bottom of my heart, Also comply with Mr,Foxton Richard.directives so that she will send the draft to youwithout any delay. CONTACT: Mr. Foxton Richard,My Secretary, Her email address: foxtonrich...@yandex.com Therefore, you should send her the followings: (1). Your full Name (2). Your addres where to deliver your cheque (3).Your telephone number/and fax (4). Your correct e-mail addres. Thanks and God bless you and your family. Hoping to hear from you after you received your cheque so that we can share the joy together. Mr;Ben,D,Dickson, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FROM; Mr.BEN D DICKSON,\\\Hello my good friend
Date: 23/04/2015 Hello my good friend. How are you today? Hope all is well with you and your family?, You may not understand why this mail came to you.But if you do not remember me, you might have receive an email from me in the past regarding a multi-million-dollar business proposal which we never concluded.I am using this opportunity to inform you that this multi-million-dollar business has been concluded with the assistance of another partner from Thailand who financed the transaction to a logical conclusion. I thank you for your great effort to our unfinished transfer of fund into your account due to one reason or the other best known to you.But I want to inform you that I havesuccessfully transferred the fund out of my bank to my new partner's account in Thailand that was capable of assisting me in this great venture. Due to your effort, sincerity, courage and trust worthiness You showed during the course of the transaction.I want to compensate you and show mygratitude to you with the sum of $1,200,000.00. I have left a certified international bank draft for you worth of $1,200,000.00 cashable anywhere in the world. My dear friend I will like you to contact my secretary Mr. Foxton Richard, on his direct email address at:Mr; foxtonrich...@yandex.com for the collection of your bank draft. I authorized her to release the Bank draft to you whenever you contact him regarding the draft. At the moment, I'm very busy here because of the investment projects, which I and the new partner are having at hand. Please I will like you to accept this with good faith as this is from the bottom of my heart, Also comply with Mr,Foxton Richard.directives so that she will send the draft to youwithout any delay. CONTACT: Mr. Foxton Richard,My Secretary, Her email address: foxtonrich...@yandex.com Therefore, you should send her the followings: (1). Your full Name (2). Your addres where to deliver your cheque (3).Your telephone number/and fax (4). Your correct e-mail addres. Thanks and God bless you and your family. Hoping to hear from you after you received your cheque so that we can share the joy together. Mr;Ben,D,Dickson, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FROM; Mr.BEN D DICKSON,\\\Hello my good friend
Date: 23/04/2015 Hello my good friend. How are you today? Hope all is well with you and your family?, You may not understand why this mail came to you.But if you do not remember me, you might have receive an email from me in the past regarding a multi-million-dollar business proposal which we never concluded.I am using this opportunity to inform you that this multi-million-dollar business has been concluded with the assistance of another partner from Thailand who financed the transaction to a logical conclusion. I thank you for your great effort to our unfinished transfer of fund into your account due to one reason or the other best known to you.But I want to inform you that I havesuccessfully transferred the fund out of my bank to my new partner's account in Thailand that was capable of assisting me in this great venture. Due to your effort, sincerity, courage and trust worthiness You showed during the course of the transaction.I want to compensate you and show mygratitude to you with the sum of $1,200,000.00. I have left a certified international bank draft for you worth of $1,200,000.00 cashable anywhere in the world. My dear friend I will like you to contact my secretary Mr. Foxton Richard, on his direct email address at:Mr; foxtonrich...@yandex.com for the collection of your bank draft. I authorized her to release the Bank draft to you whenever you contact him regarding the draft. At the moment, I'm very busy here because of the investment projects, which I and the new partner are having at hand. Please I will like you to accept this with good faith as this is from the bottom of my heart, Also comply with Mr,Foxton Richard.directives so that she will send the draft to youwithout any delay. CONTACT: Mr. Foxton Richard,My Secretary, Her email address: foxtonrich...@yandex.com Therefore, you should send her the followings: (1). Your full Name (2). Your addres where to deliver your cheque (3).Your telephone number/and fax (4). Your correct e-mail addres. Thanks and God bless you and your family. Hoping to hear from you after you received your cheque so that we can share the joy together. Mr;Ben,D,Dickson, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] mtd: diskonchip: don't call nand_scan_bbt() directly
On 23 April 2015 at 02:30, Peter Pan 潘栋 (peterpandong) wrote: > On Thu, Apr 23, 2015 at 01:51:27PM +, Brian Norris wrote: >> >> On Thu, Apr 16, 2015 at 02:11:24AM +, Peter Pan 潘栋 (peterpandong) >> wrote: >> > The diskonchip driver almost uses the default nand_base hooks as-is, >> > except that it provides custom on-flash BBT descriptors and avoids >> using >> > factory-marked bad blockers. >> > >> > So let's refactor the BBT initialization code into a private >> 'late_init' >> > hook which handles all the private details. Note the usage of >> > NAND_SKIP_BBTSCAN, which allows us to defer the BBT scan until we've >> > prepared everything. >> > >> > Signed-off-by: Brian Norris >> > Signed-off-by: Peter Pan >> >> Why are you just resending my patch? You could Ack/Review/Test it >> instead. (Did you test it?) > > My work is in the 6th patch. > I already tested the patch with micron own nand controller. I don't have > platform with docg4 or diskonchip controller. So the BBT and nand_base.c > part is covered while docg4.c and diskonchip.c not. You can use patch format's comment place to post sth like "Depends on 5 XXX patches from Brian" -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI: designware: use iATU0 for cfg and IO, iATU1 for MEM
Hi Fabrice,
On Thu, 23 Apr 2015 00:35:10 -0700
Fabrice Gasnier wrote:
> Hi Jisheng,
>
> On 04/22/2015 02:58 PM, Jisheng Zhang wrote:
> > Most transactions' type are cfg0 and MEM, so the Current iATU usage is not
> > balanced, iATU0 is hot while iATU1 is rarely used. This patch refactors
> > the iATU usage: iATU0 for cfg and IO, iATU1 for MEM. This allocation
> > ideas comes from Minghuan Lian:
> >
> > http://www.spinics.net/lists/linux-pci/msg40440.html
> >
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/pci/host/pcie-designware.c | 83
> > +-
> > 1 file changed, 47 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c
> > index 1da1446..bb81c8ad 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -508,6 +508,13 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > if (pp->ops->host_init)
> > pp->ops->host_init(pp);
> >
> > + dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> > + PCIE_ATU_TYPE_IO, pp->io_mod_base,
> > + pp->io_bus_addr, pp->io_size);
> > + dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> > + PCIE_ATU_TYPE_MEM, pp->mem_mod_base,
> > + pp->mem_bus_addr, pp->mem_size);
> > +
> Some platforms doesn't have support for ATU. I think this is the reason
> to have
> rd_other_conf / wr_other_conf ops in the driver.
oops. Thanks for the information. So what about something like:
if (!pp->ops->rd_other_conf) {
dw_pcie_prog_outbound_atu(...);
dw_pcie_prog_outbound_atu(...);
}
Thanks,
Jisheng
> IMO, this is not suitable to have this in the initialization routine for
> all platforms.
>
> Regards,
> Fabrice
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 22/27] IB/Verbs: Use management helper cap_ipoib()
On 04/22/2015 07:24 PM, Jason Gunthorpe wrote: > On Wed, Apr 22, 2015 at 10:49:44AM +0200, Michael Wang wrote: >> >> On 04/22/2015 07:40 AM, Jason Gunthorpe wrote: >>> On Mon, Apr 20, 2015 at 10:41:38AM +0200, Michael Wang wrote: >>> Introduce helper cap_ipoib() to help us check if the port of an IB device support IP over Infiniband. >>> >>> I thought we were dropping this in favor of listing the actual >>> features the ULP required unconditionally? One of my messages had the >>> start of a list.. >> >> Shall we drop it now or wait until the mechanism introduced? >> >> Just wondering the requirement of ULP could be similar to the >> requirement of management, isn't it? if the device can tell >> which ULP it support, then may be a cap_XX() make sense in here? > > You have to audit the ipoib dirver and see what core functions it > calls that have cap requirements themselves. > > At least SA, multicast and CM. It also requires cap_ib_ah() or > whatever we called that. I get your point :-) I'd like to suggest we put these in different threads: 1. bitmask reform 2. ulp check mechanism 3. naming (i think it'll be a really big discussion :-P) Separate them can help us focus on a particular topic at once, and the purpose of patches will be more clear ;-) Regards, Michael Wang > > JAson > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] base/platform: Continue on insert_resource() error
Hi Bjorn:
On Wed, Apr 22, 2015 at 6:44 PM, Bjorn Helgaas wrote:
> Usual style for referencing a commit is "(see 02bbde7849e6 ('Revert "of:
> use platform_device_add"'))".
Do you make that reference manually or there is a magic git command
for printing it in that style?
>
> Sounds like we should expect to see this message more in the future, after
> you change of_platform_device_create_pdata() use platform_device_add().
> You might want to use insert_resource_conflict() here so you can include
> information about *why* we failed to claim the resource. And it would be
> nice to use %pR for both resources.
>
.
>>
>> - failed:
>
> Might be nice to keep a comment here as a clue that the rest of the
> function is the failure path.
Will prepare a patch with the changes and resend.
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] misc: Add initial Digital Timing Engine (DTE) driver for cygnus
On Wednesday 22 April 2015 16:22:03 Jonathan Richardson wrote:
> Reviewed-by: Scott Branden
> Tested-by: Scott Branden
> Signed-off-by: Jonathan Richardson
No description at all?
You are introducing a new subsystem here, which means you get to put
a lot of thought into the API design, to ensure that it works with
other drivers of the same type, and that we don't already have
a subsystem that does what you need here.
Please write a few pages of text about the tradeoffs that went into
the internal and user-facing API design, and explain the differences
to the existing infrastructure we have for the clocksource, clockevent,
k_clock, posix timers, posix timers, timerfd, rtc, and ptp frameworks,
in particular why your hardware cannot fit into the existing frameworks
and has to have a new one.
> +struct bcm_cygnus_dte *dte_get_dev_from_devname(const char *devname)
> +{
> + struct bcm_cygnus_dte *cygnus_dte = NULL;
> + bool found = false;
> +
> + if (!devname)
> + return NULL;
> +
> + list_for_each_entry(cygnus_dte, &dtedev_list, node) {
> + if (!strcmp(dev_name(&cygnus_dte->pdev->dev), devname)) {
> + /* Matched on device name */
> + found = true;
> + break;
> + }
> + }
> +
> + return found ? cygnus_dte : NULL;
> +}
> +EXPORT_SYMBOL(dte_get_dev_from_devname);
No, don't match on a device name. If you must have a reference, use
a phandle in DT.
> +int dte_get_timestamp(
> + struct bcm_cygnus_dte *cygnus_dte,
> + enum dte_client client,
> + struct timespec *ts)
Please use timespec64 or ktime_t for internal interfaces.
> + case DTE_IOCTL_SET_DIVIDER:
For the IOCTLs, please write a documentation in man-page form. No need
for troff formatting, plain text is fine.
> +/**
> + * DTE Client
> + */
> +enum dte_client {
> + DTE_CLIENT_MIN = 0,
> + DTE_CLIENT_I2S0_BITCLOCK = 0,
> + DTE_CLIENT_I2S1_BITCLOCK,
> + DTE_CLIENT_I2S2_BITCLOCK,
> + DTE_CLIENT_I2S0_WORDCLOCK,
> + DTE_CLIENT_I2S1_WORDCLOCK,
> + DTE_CLIENT_I2S2_WORDCLOCK,
> + DTE_CLIENT_LCD_CLFP,
> + DTE_CLIENT_LCD_CLLP,
> + DTE_CLIENT_GPIO14,
> + DTE_CLIENT_GPIO15,
> + DTE_CLIENT_GPIO22,
> + DTE_CLIENT_GPIO23,
> + DTE_CLIENT_MAX,
> +};
Make this more abstract, so we can reuse the API for other vendors.
> +#define DTE_IOCTL_BASE 'd'
> +#define DTE_IO(nr) _IO(DTE_IOCTL_BASE, nr)
> +#define DTE_IOR(nr, type) _IOR(DTE_IOCTL_BASE, nr, type)
> +#define DTE_IOW(nr, type) _IOW(DTE_IOCTL_BASE, nr, type)
> +#define DTE_IOWR(nr, type) _IOWR(DTE_IOCTL_BASE, nr, type)
> +
> +#define DTE_IOCTL_SET_DIVIDER DTE_IOW(0x00, struct dte_data)
> +#define DTE_IOCTL_ENABLE_TIMESTAMP DTE_IOW(0x01, struct dte_data)
> +#define DTE_IOCTL_SET_IRQ_INTERVAL DTE_IOW(0x02, struct dte_data)
> +#define DTE_IOCTL_GET_TIMESTAMP DTE_IOWR(0x03, struct dte_timestamp)
> +#define DTE_IOCTL_SET_TIME DTE_IOW(0x04, struct timespec)
> +#define DTE_IOCTL_GET_TIME DTE_IOR(0x05, struct timespec)
Instead of timespec, use a pair of '__u64' values, or alternatively
just a '__u64' for nanoseconds if the API does not have to cover
times before 1970 or after 2262.
> +#define DTE_IOCTL_ADJ_TIME DTE_IOW(0x06, int64_t)
> +#define DTE_IOCTL_ADJ_FREQ DTE_IOW(0x07, int32_t)
Maybe 'struct timex' for the adjustment?
Also, how about adding new syscalls along the lines of
the timerfd stuff instead of using ioctl?
> +struct dte_data {
> + enum dte_client client;
> + unsigned int data;
> +};
No 'enum' in ioctl data, always use '__u32' etc.
> +
> +struct dte_timestamp {
> + enum dte_client client;
> + struct timespec ts;
> +};
Instead of timespec, use a pair of '__u64' values, or alternatively
just a '__u64' for nanoseconds if the API does not have to cover
times before 1970 or after 2262.
> +struct bcm_cygnus_dte;
> +
> +extern struct bcm_cygnus_dte *dte_get_dev_from_devname(
> + const char *devname);
> +extern int dte_enable_timestamp(
> + struct bcm_cygnus_dte *cygnus_dte,
> + enum dte_client client,
> + int enable);
Put the internal declarations into one header in include/linux, and the
user space facing ones in another one in include/uapi/linux.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: wacom: Simplify check for presence of single-finger touch
On Wed, 15 Apr 2015, Jason Gerecke wrote: > To determine if a touch is present in the single-touch case, we can > simply check if the BTN_TOUCH key is active or not. This will work for > both HID_GENERIC and other device types. > > Signed-off-by: Jason Gerecke Applied to for-4.2/wacom. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/4] kernel/resource: Invalid memory access in __release_resource
Hi Bjorn On Wed, Apr 22, 2015 at 6:47 PM, Bjorn Helgaas wrote: > > I'm not really a fan of this. The NULL pointer oops is a very good clue > all by itself, and it doesn't require any extra code here. It is a pointer to 0x30. For some reason my platform can handle a couple of oops, but if I get a fair amount of them in a short period of time, the whole thing crashes and debugging gets complicated. (no access to dmesg or remote debugging). Therefore this particular bug gave me a bad time. Now that we have located the root of the problem and solved the problem from the root, this particular error will never be hit. I just wanted to save somebody else's time with this patch. All that said, if the other patches are applied, my platform works completely fine. So it is completely your call to accept this or not :) I will resend the patchset without this patch Thanks! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support
Hi Geert,
On Wed, Apr 22, 2015 at 2:56 AM, Geert Uytterhoeven
wrote:
> Hi Magnus,
>
> On Tue, Apr 21, 2015 at 5:01 PM, Magnus Damm wrote:
>> irqchip: renesas-irqc: Fine grained Runtime PM support
>>
>> [PATCH/RFC 01/03] irqchip: renesas-irqc: Add irq_enable() and irq_disable()
>> [PATCH/RFC 02/03] irqchip: renesas-irqc: Add fine grained Runtime PM code
>> [PATCH/RFC 03/03] irqchip: renesas-irqc: Rely on Runtime PM for wakeup
>
> Thanks for your patches!
Thanks!
>> These patches attempt to convert the IRQC driver from using a mix of clock
>> framework and Runtime PM into only using Runtime PM and doing that in a
>> more fine grained way than before. With these patches in place, if there
>> is no interrupt used then the clock and/or power domain will not be used.
>>
>> Basic operation is that With these patches applied ->irq_enable() will
>> perform Runtime PM 'get sync' and ->irq_disable() simply performs
>> Runtime PM 'put'. The trigger mode callback is assumed to happen at any
>> time so there is a get/put wrapper there.
>>
>> Unless I'm misunderstanding the IRQ core code this means that the IRQC
>> struct device will be in Runtime PM 'get sync' state after someone has
>> started using an interrupt.
>
> I'm afraid you can't call pm_runtime_get_sync() from these methods, as
> they may be called from interrupt context.
Ouch. I know the clock framework has prepare/enable separated with
context, but with the irqchip callbacks I suppose no such separation
is made...? Maybe it makes more sense to do power management from the
online/offline hooks?
> BTW, I ran into similar issues with rcar-gpio, when trying to improve its
> Runtime PM handling (still have to finish my WIP).
Yeah, the IRQC and GPIO interrupt bits should be pretty much the same.
I considered IRQC to be a simpler test case, but I guess it is may be
more complicated due to lack of wakeup sources.
> On r8a73a4/ape6evm, I now get during boot:
>
> -8<-
> =
> [ INFO: inconsistent lock state ]
> 4.0.0-ape6evm-10563-g8b333096057b3c10 #213 Not tainted
> -
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&irq_desc_lock_class){?.+...}, at: []
> handle_fasteoi_irq+0x18/0x190
> {HARDIRQ-ON-W} state was registered at:
> [] _raw_spin_unlock_irq+0x24/0x2c
> [] __rpm_callback+0x50/0x60
> [] rpm_callback+0x20/0x80
> [] rpm_resume+0x3a4/0x5ec
> [] __pm_runtime_resume+0x4c/0x64
> [] irqc_irq_set_type+0x34/0x9c
> [] __irq_set_trigger+0x54/0x11c
> [] irq_set_irq_type+0x34/0x5c
> [] irq_create_of_mapping+0x114/0x168
> [] irq_of_parse_and_map+0x24/0x2c
> [] of_irq_to_resource+0x18/0xb8
> [] of_irq_to_resource_table+0x3c/0x54
> [] of_device_alloc+0x104/0x170
> [] of_platform_device_create_pdata+0x48/0xac
> [] of_platform_bus_create+0x94/0x130
> [] of_platform_populate+0x180/0x1c4
> [] simple_pm_bus_probe+0x30/0x38
> [] platform_drv_probe+0x44/0xa4
> [] driver_probe_device+0x178/0x2bc
> [] __driver_attach+0x94/0x98
> [] bus_for_each_dev+0x6c/0xa0
> [] bus_add_driver+0x140/0x1e8
> [] driver_register+0x78/0xf8
> [] do_one_initcall+0x118/0x1c8
> [] kernel_init_freeable+0x144/0x1e4
> [] kernel_init+0x8/0xe8
> [] ret_from_fork+0x14/0x24
> irq event stamp: 2304
> hardirqs last enabled at (2301): [] arch_cpu_idle+0x20/0x3c
> hardirqs last disabled at (2302): [] __irq_svc+0x34/0x5c
> softirqs last enabled at (2304): [] irq_enter+0x68/0x84
> softirqs last disabled at (2303): [] irq_enter+0x54/0x84
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(&irq_desc_lock_class);
>
> lock(&irq_desc_lock_class);
>
> *** DEADLOCK ***
>
> no locks held by swapper/0/0.
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.0.0-ape6evm-10563-g8b333096057b3c10 #213
> Hardware name: Generic R8A73A4 (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x88/0x98)
> [] (dump_stack) from [] (print_usage_bug+0x22c/0x2d8)
> [] (print_usage_bug) from [] (mark_lock+0x204/0x768)
> [] (mark_lock) from [] (__lock_acquire+0xa1c/0x215c)
> [] (__lock_acquire) from [] (lock_acquire+0xac/0x12c)
> [] (lock_acquire) from [] (_raw_spin_lock+0x30/0x40)
> [] (_raw_spin_lock) from []
> (handle_fasteoi_irq+0x18/0x190)
> [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x2c/0x3c)
> [] (generic_handle_irq) from []
> (__handle_domain_irq+0x5c/0xb4)
> [] (__handle_domain_irq) from []
> (gic_handle_irq+0x24/0x5c)
> [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
> Exception stack(0xc0583f58 to 0xc0583fa0)
> 3f40: 0001 0001
> 3f60: c05887a8 c0582000 c05854fc c0585400 c05d6624 c0585498 c057d3c4
> 3f80: c041f220 0100 c0583fa0 c0070a74 c0010c3c 2113
> [] (__irq_svc) from [] (arch_cp
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: > > I've been running current Linus' tree and have been getting system lockups > > frequently. After a few "silent" lockups, I was able to obtain a dmesg > > before the machine turned dead again (wifi stopped working shortly before > > that). > > > > Before starting to debug / bisect (last known good on this machine is > > 4.0-rc6), I am attaching the dmesg in case someone already knows what the > > issue is. > > > > I briefly went over the iwlwifi commits between 4.0-rc6 and linux/master > and couldn't find anything obvious. > Note that for the device you have, the commits that touch > drivers/net/wireless/iwlwifi/mvm are not relevant. > > What you are seeing is that the PCI host is disconnecting the WiFi NIC > for some weird reason. It is not the first time I see that, but > unfortunately, I have never been able to debug this. I am personally not > a HW PCI expert and I couldn't reproduce either... > > I am afraid I won't save you the time of the bisection, but I am not > entirely sure that bisecting the iwlwifi driver is enough to find the > commit that broke it. You may want to bisect the pci bus driver as well. The problem is that I can't really reliably reproduce it; it happens rather often, but not so often that I could be certainly sure that my distinction of good and bad kernels would be accurate. I will try it, but I expect the result to be bogus because of this, unfortunately. > First question is: Are you sure that 4.0-rc6 was good? Pretty much, yes. I've been running it for quite some time on this machine without any issues. But after updating to current HEAD two days ago, the issue triggered like 6 or 7 times already. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/17] video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
> @ mtrr_found @
> expression index, base, size;
> @@
>
> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> +index = arch_phys_wc_add(base, size);
>
> @ mtrr_rm depends on mtrr_found @
> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> @@
>
> -mtrr_del(index, base, size);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_zero_arg depends on mtrr_found @
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, 0, 0);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_fb_info depends on mtrr_found @
> struct fb_info *info;
Is this specific to the fb_info type?
julia
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> +arch_phys_wc_del(index);
>
> @ ioremap_replace_nocache depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap_nocache(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> @ ioremap_replace_default depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> Generated-by: Coccinelle SmPL
>
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Daniel Vetter
> Cc: Geert Uytterhoeven
> Cc: Julia Lawall
> Cc: Mikulas Patocka
> Cc: Suresh Siddha
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juergen Gross
> Cc: Andy Lutomirski
> Cc: Dave Airlie
> Cc: Antonino Daplas
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/video/fbdev/matrox/matroxfb_base.c | 36
> +++---
> drivers/video/fbdev/matrox/matroxfb_base.h | 27 +-
> 2 files changed, 14 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
> b/drivers/video/fbdev/matrox/matroxfb_base.c
> index 62539ca..2f70365 100644
> --- a/drivers/video/fbdev/matrox/matroxfb_base.c
> +++ b/drivers/video/fbdev/matrox/matroxfb_base.c
> @@ -370,12 +370,9 @@ static void matroxfb_remove(struct matrox_fb_info
> *minfo, int dummy)
> matroxfb_unregister_device(minfo);
> unregister_framebuffer(&minfo->fbcon);
> matroxfb_g450_shutdown(minfo);
> -#ifdef CONFIG_MTRR
> - if (minfo->mtrr.vram_valid)
> - mtrr_del(minfo->mtrr.vram, minfo->video.base, minfo->video.len);
> -#endif
> - mga_iounmap(minfo->mmio.vbase);
> - mga_iounmap(minfo->video.vbase);
> + arch_phys_wc_del(minfo->wc_cookie);
> + iounmap(minfo->mmio.vbase.vaddr);
> + iounmap(minfo->video.vbase.vaddr);
> release_mem_region(minfo->video.base, minfo->video.len_maximum);
> release_mem_region(minfo->mmio.base, 16384);
> kfree(minfo);
> @@ -1256,9 +1253,7 @@ static int nobios; /*
> "matroxfb:nobios" */
> static int noinit = 1; /* "matroxfb:init" */
> static int inverse; /* "matroxfb:inverse" */
> static int sgram;/* "matroxfb:sgram" */
> -#ifdef CONFIG_MTRR
> static int mtrr = 1; /* "matroxfb:nomtrr" */
> -#endif
> static int grayscale;/* "matroxfb:grayscale" */
> static int dev = -1; /* "matroxfb:dev:x" */
> static unsigned int vesa = ~0; /* "matroxfb:vesa:x" */
> @@ -1717,14 +1712,17 @@ static int initMatrox2(struct matrox_fb_info *minfo,
> struct board *b)
> if (mem && (mem < memsize))
> memsize = mem;
> err = -ENOMEM;
> - if (mga_ioremap(ctrlptr_phys, 16384, MGA_IOREMAP_MMIO,
> &minfo->mmio.vbase)) {
> +
> + minfo->mmio.vbase.vaddr = ioremap_nocache(ctrlptr_phys, 16384);
> + if (!minfo->mmio.vbase.vaddr) {
> printk(KERN_ERR "matroxfb: cannot ioremap(%lX, 16384), matroxfb
> disabled\n", ctrlptr_phys);
> goto failVideoMR;
> }
> minfo->mmio.base = ctrlptr_phys;
> minfo->mmio.len = 16384;
> minfo->video.base = video_base_phys;
> - if (mga_ioremap(video_base_phys, memsize, MGA_IOREMAP_FB,
> &minfo->video.vbase)) {
> + minfo->video.vbase.vaddr = ioremap_wc(video_base_phys, memsize);
> + if (!minfo->video.vbase.vaddr) {
> printk(KERN_ERR "matroxfb: cannot ioremap(%lX, %d), matroxfb
> disabled\n",
> video_base_phys, memsize);
> goto failCtrlIO;
> @@ -1772,13 +1770,9 @@ static int initMatrox2(struct matrox_fb_info *minfo,
> struct board *b)
> minfo->video.len_usable = minfo->video.len;
> if (minfo->video.len_usable > b->base->maxdisplayable)
> minfo->video.len_usable = b->base->maxdisplayable;
> -#ifdef CONFIG_MTRR
> - if (mtrr) {
> - minfo->mtrr.vram = mtrr_add(video_base_phys, minfo->video.len,
> MTRR_TYPE_WRCOMB, 1);
> - minfo->mtrr.vram_valid = 1;
> - printk(KERN_INFO "matroxfb: MTRR's turned on\n");
> - }
> -#endif /* CONFIG_MTRR
Re: [RFC] simple_char: New infrastructure to simplify chardev management
On Tue, Feb 10, 2015 at 03:44:05PM -0800, Andy Lutomirski wrote:
> This isn't adequately tested, and I don't have a demonstration (yet).
> It's here for review for whether it's a good idea in the first place
> and for weather the fully_dynamic mechanism is a good idea.
Sorry for the long delay.
I looked at this, and at a first glance, this looks good. The existing
char interface is a mess, and needs to really be simplified. I think
this code can go a long way toward making that happen.
But I'm a bit confused as to how to use this. Can you pick some
in-kernel driver and convert it to this interface to see how it would
"work"?
Ideally, between an interface like this, and the miscdevice interface,
that should be the main way to create character devices, simplifying a
lot of "boilerplate" code we have in drivers today.
Some minor comments on the code:
> + ret = -ENOMEM;
> + major = kmalloc(sizeof(struct simple_char_major), GFP_KERNEL);
> + if (!major)
> + goto out_unregister;
> + cdev_init(&major->cdev, &simple_char_fops);
> + kobject_set_name(&major->cdev.kobj, "%s", name);
The kobject in a cdev isn't a "real" kobject in that the name doesn't
matter, and it's never "registered" with sysfs. It's only use for the
kobject map code, for looking up the cdev very quickly. I really would
like to just split the kmap code out from being related to a kobject as
it's something that confuses a lot of people, but never spent the time
to do the work.
So a line like this shouldn't do anything, you don't have to set the
name here.
> +void simple_char_major_free(struct simple_char_major *major)
> +{
> + BUG_ON(!idr_is_empty(&major->idr));
WARN_ON is best, we never want to add new BUG calls to the kernel. Or,
if this really can never happen, we don't need to test for it.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] watchdog: Fix watchdog_nmi_enable_all()
> - Original Message - > From: "Andrew Morton" > To: "Don Zickus" > Cc: "LKML" , "Ulrich Obergfell" > > Sent: Wednesday, April 22, 2015 10:12:01 PM > Subject: Re: [PATCH] watchdog: Fix watchdog_nmi_enable_all() > > On Wed, 22 Apr 2015 10:47:49 -0400 Don Zickus wrote: > >> From: Ulrich Obergfell >> >> The 'watchdog_user_enabled' variable is only used as an 'interface' >> to the /proc/sys/kernel/watchdog parameter. The actual state of the >> watchdog is tracked by bits in the 'watchdog_enabled' variable. So, >> watchdog_nmi_enable_all() should check the NMI_WATCHDOG_ENABLED bit >> in 'watchdog_enabled'. > > What are the user-visible effects of the patch? Please always include > this information when fixing a bug. Andrew, this patch has no user-visible effects. The issue that is addressed by this patch came up during the recent merges. It is related to: 1) https://lkml.org/lkml/2015/2/5/624 2) http://lkml.kernel.org/r/1416251225-17721-12-git-send-email-eran...@google.com Patch series 1) changes the way how the code in kernel/watchdog.c uses certain variables such as 'watchdog_user_enabled' and it also introduces a new variable 'watchdog_enabled' as described in: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/watchdog.c?id=84d56e66b9b4a646f04ec30696ca1aeea5e654d5 This patch adjusts patch 2) which introduces watchdog_nmi_enable_all() to the new way how the code in kernel/watchdog.c should use 'watchdog_user_enabled' and 'watchdog_enabled'. Patch 2) is here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/watchdog.c?id=b3738d29323344da3017a91010530cf3a58590fc Regards, Uli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] TESTCASE: of: OOPS when disabling node via OF_DYNAMIC
> Sorry for the non-prompt reply; but just for kicks, can you try the attached > patch? > > I have a hunch this might be the problem. Yeah, this even makes my more complex driver work \o/ I will post it once -rc1 is out. Thanks a lot for your help, much appreciated! signature.asc Description: Digital signature
RE: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Wednesday, April 22, 2015 11:19 PM > > > Yes, I think we've all agreed we can do it ... it's now a question of whether > we > can stomach the ick factor of actually initiating a transaction in close ... > I'm still > feeling queasy. The file "close" here can I understand that the file system will call the "release" function at the file_operations struct? http://lxr.free-electrons.com/source/include/linux/fs.h#L1538 So, James you are meaning that we could initiating the update transaction inside the f_ops->release() and return the error code if update failed in this function? Thanks & Regards, Wilson
[PATCH 3/6] clk: mediatek: Add reset controller support
The pericfg and infracfg units also provide reset lines to several
other SoC internal units. This adds a function which can be called
from the pericfg and infracfg initialization functions which will
register the reset controller using reset_controller_register. The
reset controller will provide support for resetting the units
connected to the pericfg and infracfg controller. The units resetted
by this controller can use the standard reset device tree binding
to gain access to the reset lines.
Signed-off-by: Sascha Hauer
Acked-by: Philipp Zabel
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mtk.h | 10 +
drivers/clk/mediatek/reset.c | 97 ++
3 files changed, 108 insertions(+)
create mode 100644 drivers/clk/mediatek/reset.c
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c384e97..0b6f1c3 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1 +1,2 @@
obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 694fc39..61035b9 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -156,4 +156,14 @@ void __init mtk_clk_register_plls(struct device_node *node,
const struct mtk_pll_data *plls, int num_plls,
struct clk_onecell_data *clk_data);
+#ifdef CONFIG_RESET_CONTROLLER
+void mtk_register_reset_controller(struct device_node *np,
+ unsigned int num_regs, int regofs);
+#else
+static inline void mtk_register_reset_controller(struct device_node *np,
+ unsigned int num_regs, int regofs)
+{
+}
+#endif
+
#endif /* __DRV_CLK_MTK_H */
diff --git a/drivers/clk/mediatek/reset.c b/drivers/clk/mediatek/reset.c
new file mode 100644
index 000..9e9fe4b
--- /dev/null
+++ b/drivers/clk/mediatek/reset.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+struct mtk_reset {
+ struct regmap *regmap;
+ int regofs;
+ struct reset_controller_dev rcdev;
+};
+
+static int mtk_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct mtk_reset *data = container_of(rcdev, struct mtk_reset, rcdev);
+
+ return regmap_update_bits(data->regmap, data->regofs + ((id / 32) << 2),
+ BIT(id % 32), ~0);
+}
+
+static int mtk_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct mtk_reset *data = container_of(rcdev, struct mtk_reset, rcdev);
+
+ return regmap_update_bits(data->regmap, data->regofs + ((id / 32) << 2),
+ BIT(id % 32), 0);
+}
+
+static int mtk_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ int ret;
+
+ ret = mtk_reset_assert(rcdev, id);
+ if (ret)
+ return ret;
+
+ return mtk_reset_deassert(rcdev, id);
+}
+
+static struct reset_control_ops mtk_reset_ops = {
+ .assert = mtk_reset_assert,
+ .deassert = mtk_reset_deassert,
+ .reset = mtk_reset,
+};
+
+void mtk_register_reset_controller(struct device_node *np,
+ unsigned int num_regs, int regofs)
+{
+ struct mtk_reset *data;
+ int ret;
+ struct regmap *regmap;
+
+ regmap = syscon_node_to_regmap(np);
+ if (IS_ERR(regmap)) {
+ pr_err("Cannot find regmap for %s: %ld\n", np->full_name,
+ PTR_ERR(regmap));
+ return;
+ }
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return;
+
+ data->regmap = regmap;
+ data->regofs = regofs;
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.nr_resets = num_regs * 32;
+ data->rcdev.ops = &mtk_reset_ops;
+ data->rcdev.of_node = np;
+
+ ret = reset_controller_register(&data->rcdev);
+ if (ret) {
+ pr_err("could not register reset controller: %d\n", ret);
+ kfree(data);
+ return;
+ }
+}
--
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://
[PATCH 2/6] clk: mediatek: Add initial common clock support for Mediatek SoCs.
From: James Liao
This patch adds common clock support for Mediatek SoCs, including plls,
muxes and clock gates.
Signed-off-by: James Liao
Signed-off-by: Henry Chen
Signed-off-by: Sascha Hauer
---
drivers/clk/Makefile| 1 +
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-gate.c | 137 +
drivers/clk/mediatek/clk-gate.h | 49 ++
drivers/clk/mediatek/clk-mtk.c | 220 ++
drivers/clk/mediatek/clk-mtk.h | 159 +++
drivers/clk/mediatek/clk-pll.c | 332
7 files changed, 899 insertions(+)
create mode 100644 drivers/clk/mediatek/Makefile
create mode 100644 drivers/clk/mediatek/clk-gate.c
create mode 100644 drivers/clk/mediatek/clk-gate.h
create mode 100644 drivers/clk/mediatek/clk-mtk.c
create mode 100644 drivers/clk/mediatek/clk-mtk.h
create mode 100644 drivers/clk/mediatek/clk-pll.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..6d97203 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
obj-$(CONFIG_ARCH_HIP04) += hisilicon/
obj-$(CONFIG_ARCH_HIX5HD2) += hisilicon/
obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
+obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
ifeq ($(CONFIG_COMMON_CLK), y)
obj-$(CONFIG_ARCH_MMP) += mmp/
endif
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
new file mode 100644
index 000..c384e97
--- /dev/null
+++ b/drivers/clk/mediatek/Makefile
@@ -0,0 +1 @@
+obj-y += clk-mtk.o clk-pll.o clk-gate.o
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
new file mode 100644
index 000..9d77ee3
--- /dev/null
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+static int mtk_cg_bit_is_cleared(struct clk_hw *hw)
+{
+ struct mtk_clk_gate *cg = to_clk_gate(hw);
+ u32 val;
+
+ regmap_read(cg->regmap, cg->sta_ofs, &val);
+
+ val &= BIT(cg->bit);
+
+ return val == 0;
+}
+
+static int mtk_cg_bit_is_set(struct clk_hw *hw)
+{
+ struct mtk_clk_gate *cg = to_clk_gate(hw);
+ u32 val;
+
+ regmap_read(cg->regmap, cg->sta_ofs, &val);
+
+ val &= BIT(cg->bit);
+
+ return val != 0;
+}
+
+static void mtk_cg_set_bit(struct clk_hw *hw)
+{
+ struct mtk_clk_gate *cg = to_clk_gate(hw);
+
+ regmap_write(cg->regmap, cg->set_ofs, BIT(cg->bit));
+}
+
+static void mtk_cg_clr_bit(struct clk_hw *hw)
+{
+ struct mtk_clk_gate *cg = to_clk_gate(hw);
+
+ regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
+}
+
+static int mtk_cg_enable(struct clk_hw *hw)
+{
+ mtk_cg_clr_bit(hw);
+
+ return 0;
+}
+
+static void mtk_cg_disable(struct clk_hw *hw)
+{
+ mtk_cg_set_bit(hw);
+}
+
+static int mtk_cg_enable_inv(struct clk_hw *hw)
+{
+ mtk_cg_set_bit(hw);
+
+ return 0;
+}
+
+static void mtk_cg_disable_inv(struct clk_hw *hw)
+{
+ mtk_cg_clr_bit(hw);
+}
+
+const struct clk_ops mtk_clk_gate_ops_setclr = {
+ .is_enabled = mtk_cg_bit_is_cleared,
+ .enable = mtk_cg_enable,
+ .disable= mtk_cg_disable,
+};
+
+const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
+ .is_enabled = mtk_cg_bit_is_set,
+ .enable = mtk_cg_enable_inv,
+ .disable= mtk_cg_disable_inv,
+};
+
+struct clk *mtk_clk_register_gate(
+ const char *name,
+ const char *parent_name,
+ struct regmap *regmap,
+ int set_ofs,
+ int clr_ofs,
+ int sta_ofs,
+ u8 bit,
+ const struct clk_ops *ops)
+{
+ struct mtk_clk_gate *cg;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ cg = kzalloc(sizeof(*cg), GFP_KERNEL);
+ if (!cg)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.flags = CLK_SET_RATE_PARENT;
+ init.parent_names = parent_name ? &parent_name : NULL;
+ init.num_parents = parent_name ? 1 : 0;
+ init.ops = ops;
+
+ cg->regmap = regmap;
+ cg->set_ofs = set_ofs;
+ cg->clr_ofs = clr_ofs;
+ cg->sta_ofs = sta_ofs;
+ cg->bit = bit;
+
+ cg->hw.init = &init;
+
+ clk = clk_register(NU
[PATCH 4/6] clk: mediatek: Add basic clocks for Mediatek MT8135.
From: James Liao
This patch adds basic clocks for MT8135, including TOPCKGEN, PLLs,
INFRA and PERI clocks.
Signed-off-by: James Liao
Signed-off-by: Henry Chen
Signed-off-by: Sascha Hauer
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt8135.c | 644 +
include/dt-bindings/clock/mt8135-clk.h | 194 +++
.../dt-bindings/reset-controller/mt8135-resets.h | 64 ++
4 files changed, 903 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt8135.c
create mode 100644 include/dt-bindings/clock/mt8135-clk.h
create mode 100644 include/dt-bindings/reset-controller/mt8135-resets.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 0b6f1c3..12ce576 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,2 +1,3 @@
obj-y += clk-mtk.o clk-pll.o clk-gate.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-y += clk-mt8135.o
diff --git a/drivers/clk/mediatek/clk-mt8135.c
b/drivers/clk/mediatek/clk-mt8135.c
new file mode 100644
index 000..a63435b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8135.c
@@ -0,0 +1,644 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+static DEFINE_SPINLOCK(mt8135_clk_lock);
+
+static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
+ FACTOR(CLK_TOP_DSI0_LNTC_DSICLK, "dsi0_lntc_dsiclk", "clk_null", 1, 1),
+ FACTOR(CLK_TOP_HDMITX_CLKDIG_CTS, "hdmitx_clkdig_cts", "clk_null", 1,
1),
+ FACTOR(CLK_TOP_CLKPH_MCK, "clkph_mck", "clk_null", 1, 1),
+ FACTOR(CLK_TOP_CPUM_TCK_IN, "cpum_tck_in", "clk_null", 1, 1),
+};
+
+static const struct mtk_fixed_factor top_divs[] __initconst = {
+ FACTOR(CLK_TOP_MAINPLL_806M, "mainpll_806m", "mainpll", 1, 2),
+ FACTOR(CLK_TOP_MAINPLL_537P3M, "mainpll_537p3m", "mainpll", 1, 3),
+ FACTOR(CLK_TOP_MAINPLL_322P4M, "mainpll_322p4m", "mainpll", 1, 5),
+ FACTOR(CLK_TOP_MAINPLL_230P3M, "mainpll_230p3m", "mainpll", 1, 7),
+
+ FACTOR(CLK_TOP_UNIVPLL_624M, "univpll_624m", "univpll", 1, 2),
+ FACTOR(CLK_TOP_UNIVPLL_416M, "univpll_416m", "univpll", 1, 3),
+ FACTOR(CLK_TOP_UNIVPLL_249P6M, "univpll_249p6m", "univpll", 1, 5),
+ FACTOR(CLK_TOP_UNIVPLL_178P3M, "univpll_178p3m", "univpll", 1, 7),
+ FACTOR(CLK_TOP_UNIVPLL_48M, "univpll_48m", "univpll", 1, 26),
+
+ FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+ FACTOR(CLK_TOP_MMPLL_D3, "mmpll_d3", "mmpll", 1, 3),
+ FACTOR(CLK_TOP_MMPLL_D5, "mmpll_d5", "mmpll", 1, 5),
+ FACTOR(CLK_TOP_MMPLL_D7, "mmpll_d7", "mmpll", 1, 7),
+ FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll_d2", 1, 2),
+ FACTOR(CLK_TOP_MMPLL_D6, "mmpll_d6", "mmpll_d3", 1, 2),
+
+ FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "mainpll_806m", 1, 1),
+ FACTOR(CLK_TOP_SYSPLL_D4, "syspll_d4", "mainpll_806m", 1, 2),
+ FACTOR(CLK_TOP_SYSPLL_D6, "syspll_d6", "mainpll_806m", 1, 3),
+ FACTOR(CLK_TOP_SYSPLL_D8, "syspll_d8", "mainpll_806m", 1, 4),
+ FACTOR(CLK_TOP_SYSPLL_D10, "syspll_d10", "mainpll_806m", 1, 5),
+ FACTOR(CLK_TOP_SYSPLL_D12, "syspll_d12", "mainpll_806m", 1, 6),
+ FACTOR(CLK_TOP_SYSPLL_D16, "syspll_d16", "mainpll_806m", 1, 8),
+ FACTOR(CLK_TOP_SYSPLL_D24, "syspll_d24", "mainpll_806m", 1, 12),
+
+ FACTOR(CLK_TOP_SYSPLL_D3, "syspll_d3", "mainpll_537p3m", 1, 1),
+
+ FACTOR(CLK_TOP_SYSPLL_D2P5, "syspll_d2p5", "mainpll_322p4m", 2, 1),
+ FACTOR(CLK_TOP_SYSPLL_D5, "syspll_d5", "mainpll_322p4m", 1, 1),
+
+ FACTOR(CLK_TOP_SYSPLL_D3P5, "syspll_d3p5", "mainpll_230p3m", 2, 1),
+
+ FACTOR(CLK_TOP_UNIVPLL1_D2, "univpll1_d2", "univpll_624m", 1, 2),
+ FACTOR(CLK_TOP_UNIVPLL1_D4, "univpll1_d4", "univpll_624m", 1, 4),
+ FACTOR(CLK_TOP_UNIVPLL1_D6, "univpll1_d6", "univpll_624m", 1, 6),
+ FACTOR(CLK_TOP_UNIVPLL1_D8, "univpll1_d8", "univpll_624m", 1, 8),
+ FACTOR(CLK_TOP_UNIVPLL1_D10, "univpll1_d10", "univpll_624m", 1, 10),
+
+ FACTOR(CLK_TOP_UNIVPLL2_D2, "univpll2_d2", "univpll_416m", 1, 2),
+ FACTOR(CLK_TOP_UNIVPLL2_D4, "univpll2_d4", "univpll_416m", 1, 4),
+ FACTOR(CLK_TOP_UNIVPLL2_D6, "univpll2_d6", "univpll_416m", 1, 6),
+ FACTOR(CLK_TOP_UNIVPLL2_D8, "univpll2_d8", "univpll_416m", 1, 8),
+
+ FACTOR(CLK_TOP_UNIVPLL_D3, "univpll_d3", "univpll_416m", 1, 1),
+ FACTOR(CLK_TOP_UNIVPLL_D5, "univpll_d5",
[PATCH 1/6] clk: make strings in parent name arrays const
The clk functions and structs declare the parent_name arrays as
'const char **parent_names' which means the parent name strings
are const, but the array itself is not. Use
'const char * const * parent_names' instead which also makes
the array const. This allows us to put the parent_name arrays into
the __initconst section.
Signed-off-by: Sascha Hauer
Reviewed-by: Krzysztof Kozlowski
Tested-by: Krzysztof Kozlowski
---
drivers/clk/clk-composite.c | 2 +-
drivers/clk/clk-mux.c| 4 ++--
include/linux/clk-provider.h | 8
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 956b7e5..077f4c714 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -188,7 +188,7 @@ static void clk_composite_disable(struct clk_hw *hw)
}
struct clk *clk_register_composite(struct device *dev, const char *name,
- const char **parent_names, int num_parents,
+ const char * const *parent_names, int num_parents,
struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 69a094c..1fa2a8d 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -114,7 +114,7 @@ const struct clk_ops clk_mux_ro_ops = {
EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
struct clk *clk_register_mux_table(struct device *dev, const char *name,
- const char **parent_names, u8 num_parents, unsigned long flags,
+ const char * const *parent_names, u8 num_parents, unsigned long
flags,
void __iomem *reg, u8 shift, u32 mask,
u8 clk_mux_flags, u32 *table, spinlock_t *lock)
{
@@ -166,7 +166,7 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
EXPORT_SYMBOL_GPL(clk_register_mux_table);
struct clk *clk_register_mux(struct device *dev, const char *name,
- const char **parent_names, u8 num_parents, unsigned long flags,
+ const char * const *parent_names, u8 num_parents, unsigned long
flags,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags, spinlock_t *lock)
{
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5591ea7..410684d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -209,7 +209,7 @@ struct clk_ops {
struct clk_init_data {
const char *name;
const struct clk_ops*ops;
- const char **parent_names;
+ const char * const *parent_names;
u8 num_parents;
unsigned long flags;
};
@@ -426,12 +426,12 @@ extern const struct clk_ops clk_mux_ops;
extern const struct clk_ops clk_mux_ro_ops;
struct clk *clk_register_mux(struct device *dev, const char *name,
- const char **parent_names, u8 num_parents, unsigned long flags,
+ const char * const *parent_names, u8 num_parents, unsigned long
flags,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags, spinlock_t *lock);
struct clk *clk_register_mux_table(struct device *dev, const char *name,
- const char **parent_names, u8 num_parents, unsigned long flags,
+ const char * const *parent_names, u8 num_parents, unsigned long
flags,
void __iomem *reg, u8 shift, u32 mask,
u8 clk_mux_flags, u32 *table, spinlock_t *lock);
@@ -518,7 +518,7 @@ struct clk_composite {
};
struct clk *clk_register_composite(struct device *dev, const char *name,
- const char **parent_names, int num_parents,
+ const char * const *parent_names, int num_parents,
struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
--
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 6/6] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers
This adds the binding documentation for the apmixedsys, perisys and
infracfg controllers found on Mediatek SoCs.
Signed-off-by: Sascha Hauer
---
.../bindings/arm/mediatek/mediatek,apmixedsys.txt | 23 +
.../bindings/arm/mediatek/mediatek,infracfg.txt| 30 ++
.../bindings/arm/mediatek/mediatek,pericfg.txt | 30 ++
.../bindings/arm/mediatek/mediatek,topckgen.txt| 23 +
4 files changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
new file mode 100644
index 000..5af6d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -0,0 +1,23 @@
+Mediatek apmixedsys controller
+==
+
+The Mediatek apmixedsys controller provides the PLLs to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8135-apmixedsys"
+ - "mediatek,mt8173-apmixedsys"
+- #clock-cells: Must be 1
+
+The apmixedsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+apmixedsys: apmixedsys@10209000 {
+ compatible = "mediatek,mt8173-apmixedsys";
+ reg = <0 0x10209000 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
new file mode 100644
index 000..684da473
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -0,0 +1,30 @@
+Mediatek infracfg controller
+
+
+The Mediatek infracfg controller provides various clocks and reset
+outputs to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8135-infracfg", "syscon"
+ - "mediatek,mt8173-infracfg", "syscon"
+- #clock-cells: Must be 1
+- #reset-cells: Must be 1
+
+The infracfg controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+Also it uses the common reset controller binding from
+Documentation/devicetree/bindings/reset/reset.txt.
+The available reset outputs are defined in
+dt-bindings/reset-controller/mt*-resets.h
+
+Example:
+
+infracfg: infracfg@10001000 {
+ compatible = "mediatek,mt8173-infracfg", "syscon";
+ reg = <0 0x10001000 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
new file mode 100644
index 000..fdb45c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
@@ -0,0 +1,30 @@
+Mediatek pericfg controller
+===
+
+The Mediatek pericfg controller provides various clocks and reset
+outputs to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8135-pericfg", "syscon"
+ - "mediatek,mt8173-pericfg", "syscon"
+- #clock-cells: Must be 1
+- #reset-cells: Must be 1
+
+The pericfg controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+Also it uses the common reset controller binding from
+Documentation/devicetree/bindings/reset/reset.txt.
+The available reset outputs are defined in
+dt-bindings/reset-controller/mt*-resets.h
+
+Example:
+
+pericfg: pericfg@10003000 {
+ compatible = "mediatek,mt8173-pericfg", "syscon";
+ reg = <0 0x10003000 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
new file mode 100644
index 000..a425248
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
@@ -0,0 +1,23 @@
+Mediatek topckgen controller
+
+
+The Mediatek topckgen controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8135-topckgen"
+ - "mediatek,mt8173-topckgen"
+- #clock-cells: Must be 1
+
+The topckgen controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.
Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
On 04/22/2015 06:57 PM, Jason Gunthorpe wrote: > On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote: > >>> 2)The name rdma_tech_* is lame. >>> rdma_transport_*(), adhering to the above (*) remark, is much better. >>> For example, both IB and ROCE *do* use the same transport. >> >> I especially want to second this. I haven't really been happy with the >> rdma_tech_* names at all. > > I'm not excited about the names either.. > > cap_ is bad because it pollutes the global namespace. > > rdma_tech_ .. as used, this is selecting the standard the port > implements. The word 'standard' is a better choice than 'transport', > and 'technology' is often synonymous with 'standard'. Meh. > > I've said it already, but this patch set has probably gotten too > big. If we could just do the cap conversion without messing with other > stuff, or adding rdma_tech, that would really be the best. > > Nobody seems to like the rdma_tech parts of this series. > > I'd also drop '[PATCH v5 09/27] IB/Verbs: Reform IB-core > verbs/uverbs_cmd/sysfs' - that is UAPI stuff, it could be done as a > followup someday, not worth the risk right now. There won't be risk... the logical is clear that they will return the same result, but I'll drop the modification on link_layer_show() and ib_uverbs_query_port() anyway, since they are just try to get the link-layer type and we are not going to erase that helper anymore. Regards, Michael Wang > > Jason > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Issues with capability bits and meta-data in kdbus
On Wed, Apr 22, 2015 at 04:02:34PM -0400, Havoc Pennington wrote:
> On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti
> wrote:
> >
> > Just out of curiosity, would you like to change something in dbus design,
> > if you didn't have to worry about ABI breaks and the like?
> >
>
> Good question. I can't remember any big-picture things, I'm sure the
> current maintainers and users have a longer list. :-) There are a
> variety of little small things, some examples I can immediately think
> of:
>
> * the ad hoc authentication protocol is sort of ugly
> * the byte order marker in every message is silly
> * protocol version in every message is useless
> * Ryan Lortie's nice fixes in GVariant, which I think kdbus adopts (
> https://people.gnome.org/~ryanl/gvariant-serialisation.pdf ), for the
> most part these are 'cleanups' but nullable types ("maybe" types for
> Haskell fans) are a notable semantic addition
> * specify how it works on Windows, the Windows port last I checked
> (years ago) didn't do things in a Windows-sensible way
> * specify what happens when resource limits are reached
> * wouldn't use XML for introspection data these days
> http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
>
Nice, thanks!
It seems that all of these are userspace related only. Yes I saw a "gvariant
readme" in systemd sources, now I understood what it is (I'm not an expert) :D
My only fear was that kdbus was trying to keep something that even dbus himself
don't want. But it seems that this is not the case.
Thanks, regards,
Michele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] clk: mediatek: Add basic clocks for Mediatek MT8173.
From: James Liao
This patch adds basic clocks for MT8173, including TOPCKGEN, PLLs,
INFRA and PERI clocks.
Signed-off-by: James Liao
Signed-off-by: Henry Chen
Signed-off-by: Sascha Hauer
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt8173.c | 830 +
include/dt-bindings/clock/mt8173-clk.h | 235 ++
.../dt-bindings/reset-controller/mt8173-resets.h | 63 ++
4 files changed, 1129 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt8173.c
create mode 100644 include/dt-bindings/clock/mt8173-clk.h
create mode 100644 include/dt-bindings/reset-controller/mt8173-resets.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 12ce576..8e4b2a4 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,3 +1,4 @@
obj-y += clk-mtk.o clk-pll.o clk-gate.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-y += clk-mt8135.o
+obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
new file mode 100644
index 000..357b080
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -0,0 +1,830 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include
+
+static DEFINE_SPINLOCK(mt8173_clk_lock);
+
+static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
+ FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
+ FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
+ FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
+ FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
+};
+
+static const struct mtk_fixed_factor top_divs[] __initconst = {
+ FACTOR(CLK_TOP_ARMCA7PLL_754M, "armca7pll_754m", "armca7pll", 1, 2),
+ FACTOR(CLK_TOP_ARMCA7PLL_502M, "armca7pll_502m", "armca7pll", 1, 3),
+
+ FACTOR(CLK_TOP_MAIN_H546M, "main_h546m", "mainpll", 1, 2),
+ FACTOR(CLK_TOP_MAIN_H364M, "main_h364m", "mainpll", 1, 3),
+ FACTOR(CLK_TOP_MAIN_H218P4M, "main_h218p4m", "mainpll", 1, 5),
+ FACTOR(CLK_TOP_MAIN_H156M, "main_h156m", "mainpll", 1, 7),
+
+ FACTOR(CLK_TOP_TVDPLL_445P5M, "tvdpll_445p5m", "tvdpll", 1, 4),
+ FACTOR(CLK_TOP_TVDPLL_594M, "tvdpll_594m", "tvdpll", 1, 3),
+
+ FACTOR(CLK_TOP_UNIV_624M, "univ_624m", "univpll", 1, 2),
+ FACTOR(CLK_TOP_UNIV_416M, "univ_416m", "univpll", 1, 3),
+ FACTOR(CLK_TOP_UNIV_249P6M, "univ_249p6m", "univpll", 1, 5),
+ FACTOR(CLK_TOP_UNIV_178P3M, "univ_178p3m", "univpll", 1, 7),
+ FACTOR(CLK_TOP_UNIV_48M, "univ_48m", "univpll", 1, 26),
+
+ FACTOR(CLK_TOP_CLKRTC_EXT, "clkrtc_ext", "clk32k", 1, 1),
+ FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
+ FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
+
+ FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
+ FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
+
+ FACTOR(CLK_TOP_ARMCA7PLL_D2, "armca7pll_d2", "armca7pll_754m", 1, 1),
+ FACTOR(CLK_TOP_ARMCA7PLL_D3, "armca7pll_d3", "armca7pll_502m", 1, 1),
+
+ FACTOR(CLK_TOP_APLL1, "apll1_ck", "apll1", 1, 1),
+ FACTOR(CLK_TOP_APLL2, "apll2_ck", "apll2", 1, 1),
+
+ FACTOR(CLK_TOP_DMPLL, "dmpll_ck", "clkph_mck_o", 1, 1),
+ FACTOR(CLK_TOP_DMPLL_D2, "dmpll_d2", "clkph_mck_o", 1, 2),
+ FACTOR(CLK_TOP_DMPLL_D4, "dmpll_d4", "clkph_mck_o", 1, 4),
+ FACTOR(CLK_TOP_DMPLL_D8, "dmpll_d8", "clkph_mck_o", 1, 8),
+ FACTOR(CLK_TOP_DMPLL_D16, "dmpll_d16", "clkph_mck_o", 1, 16),
+
+ FACTOR(CLK_TOP_LVDSPLL_D2, "lvdspll_d2", "lvdspll", 1, 2),
+ FACTOR(CLK_TOP_LVDSPLL_D4, "lvdspll_d4", "lvdspll", 1, 4),
+ FACTOR(CLK_TOP_LVDSPLL_D8, "lvdspll_d8", "lvdspll", 1, 8),
+
+ FACTOR(CLK_TOP_MMPLL, "mmpll_ck", "mmpll", 1, 1),
+ FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+
+ FACTOR(CLK_TOP_MSDCPLL, "msdcpll_ck", "msdcpll", 1, 1),
+ FACTOR(CLK_TOP_MSDCPLL_D2, "msdcpll_d2", "msdcpll", 1, 2),
+ FACTOR(CLK_TOP_MSDCPLL_D4, "msdcpll_d4", "msdcpll", 1, 4),
+ FACTOR(CLK_TOP_MSDCPLL2, "msdcpll2_ck", "msdcpll2", 1, 1),
+ FACTOR(CLK_TOP_MSDCPLL2_D2, "msdcpll2_d2", "msdcpll2", 1, 2),
+ FACTOR(CLK_TOP_MSDCPLL2_D4, "msdcpll2_d4", "msdcpll2", 1, 4),
+
+ FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "main_h546m", 1, 1),
+ FACTOR(CLK_TOP_SYSPLL
[PATCH v12] clk: Add common clock support for Mediatek MT8135 and MT8173
The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76: Linux 4.0 (2015-04-12 15:12:50 -0700) are available in the git repository at: git://git.pengutronix.de/git/sha/linux-2.6.git tags/v4.0-clk-mediatek-v12 for you to fetch changes up to e0ebeaa8a3f4a762cb9c2780170445aad15915d1: dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers (2015-04-23 10:22:34 +0200) This patchset contains the initial common clock support for Mediatek SoCs. Mediatek SoC's clock architecture comprises of various PLLs, dividers, muxes and clock gates. Changes in v12: - Fix UART clocks: Add clocks providing the baudrate - enable necessary but unused clocks for surviving the disabling of unused clocks - cleanup clock define names: remove _CK suffix and consistently add a CLK_ prefix - add and use mtk_clk_register_composites() for registering multiple composite clocks Changes in v11: - Use more defines in PLL code - drop unused pr_fmt - use i++ instead of ++i in two places Changes in v10: - polish some commit messages Changes in v9: - rename 'lock' to 'mt81xx_clk_lock' to get better lockdep output Changes in v8: - add patch to allow to put parent_name arrays in __initconst - put parent_name arrays into __initconst Changes in v7: - fix duplicate definition/declaration of mtk_register_reset_controller - fix pd_reg offset of tvdpll - make clk initialization arrays const Changes in v6: - rework PLL support, only a fraction of original size now - Move binding docs to Documentation/devicetree/bindings/arm/mediatek since the units are not really clock specific (they contain reset controllers) Changes in v5: - Add reset controller support for pericfg/infracfg - Use regmap for the gates - remove now unnecessary spinlock for the gates - Add PMIC wrapper support as of v3 Changes in v4: - Support MT8173 platform. - Re-ordered patchset. driver/clk/Makefile in 2nd patch. - Extract the common part definition(mtk_gate/mtk_pll/mtk_mux) from clk-mt8135.c/clk-mt8173.c to clk-mtk.c. - Refine code. Rmove unnessacary debug information and unsed defines, add prefix "mtk_" for static functions. - Remove flag CLK_IGNORE_UNUSED and set flag CLK_SET_RATE_PARENT on gate/mux/fixed-factor. - Use spin_lock_irqsave(&clk_ops_lock, flags) instead of mtk_clk_lock. - Example above include a node for the clock controller itself, followed by the i2c controller example above. Changes in v3: - Rebase to 3.19-rc1. - Refine code. Remove unneed functions, debug logs and comments, and fine tune error logs. Changes in v2: - Re-ordered patchset. Fold include/dt-bindings and DT document in 1st patch. James Liao (3): clk: mediatek: Add initial common clock support for Mediatek SoCs. clk: mediatek: Add basic clocks for Mediatek MT8135. clk: mediatek: Add basic clocks for Mediatek MT8173. Sascha Hauer (3): clk: make strings in parent name arrays const clk: mediatek: Add reset controller support dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 23 + .../bindings/arm/mediatek/mediatek,infracfg.txt| 30 + .../bindings/arm/mediatek/mediatek,pericfg.txt | 30 + .../bindings/arm/mediatek/mediatek,topckgen.txt| 23 + drivers/clk/Makefile | 1 + drivers/clk/clk-composite.c| 2 +- drivers/clk/clk-mux.c | 4 +- drivers/clk/mediatek/Makefile | 4 + drivers/clk/mediatek/clk-gate.c| 137 drivers/clk/mediatek/clk-gate.h| 49 ++ drivers/clk/mediatek/clk-mt8135.c | 644 drivers/clk/mediatek/clk-mt8173.c | 830 + drivers/clk/mediatek/clk-mtk.c | 220 ++ drivers/clk/mediatek/clk-mtk.h | 169 + drivers/clk/mediatek/clk-pll.c | 332 + drivers/clk/mediatek/reset.c | 97 +++ include/dt-bindings/clock/mt8135-clk.h | 194 + include/dt-bindings/clock/mt8173-clk.h | 235 ++ .../dt-bindings/reset-controller/mt8135-resets.h | 64 ++ .../dt-bindings/reset-controller/mt8173-resets.h | 63 ++ include/linux/clk-provider.h | 8 +- 21 files changed, 3152 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt create mode 100644 drivers/clk/me
Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
On Wed, 1 Apr 2015, Borislav Petkov wrote: > > > From: Jiri Kosina > > > > > > Since GHES sources are global, we theoretically need only a single CPU > > > reading them per NMI instead of a thundering herd of CPUs waiting on a > > > spinlock in NMI context for no reason at all. > > > > I originally wasn't 100% sure whether GHES sources are global (i.e. if it > > really doesn't matter which CPU is reading the registers), but looking at > > the code more it actually seems that this is really the right thing to do. > > > > Rationale: ghes_ioremap_pfn_nmi() always ioremaps() (exclusively) the page > > with the registers, performs apei_read() (which is ghes-source specific, > > but not CPU-specific) and unmaps the page again. > > > > There is nothing that would make this CPU-specific. Adding Huang Ying (the > > original author of the code) to confirm this. Huang? > > > > > Do that. > > > > I think this should indeed be pushed forward. It fixes horrible spinlock > > contention on systems which are under NMI storm (such as when perf is > > active) unrelated to GHES. > > Right, so I tested injecting an error without your patch and same > behavior. So it all points at global sources AFAICT. It would be cool, > though, if someone who knows the fw confirms unambiguously. Three weeks have passed, therefore I find this an appropriate time for a friendly ping :) Rafael? Naoya? Huang? This fixes a contention spinlock problem in NMI observed on a real HW, so it would be really nice to have it fixed. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] TESTCASE: of: OOPS when disabling node via OF_DYNAMIC
Hi Wolfram, > On Apr 23, 2015, at 11:33 , Wolfram Sang wrote: > > >> Sorry for the non-prompt reply; but just for kicks, can you try the attached >> patch? >> >> I have a hunch this might be the problem. > > Yeah, this even makes my more complex driver work \o/ I will post it > once -rc1 is out. Thanks a lot for your help, much appreciated! > Good! This patch has been posted before but up to now, no-one had a test case that triggered the bug, so gregh was reluctant to pick it up. Let’s gang up on him :) Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] clk: make strings in parent name arrays const
Halli, On Thu, Apr 23, 2015 at 10:35:38AM +0200, Sascha Hauer wrote: > The clk functions and structs declare the parent_name arrays as > 'const char **parent_names' which means the parent name strings > are const, but the array itself is not. Use > 'const char * const * parent_names' instead which also makes > the array const. This allows us to put the parent_name arrays into > the __initconst section. > > Signed-off-by: Sascha Hauer > Reviewed-by: Krzysztof Kozlowski > Tested-by: Krzysztof Kozlowski Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] TESTCASE: of: OOPS when disabling node via OF_DYNAMIC
> This patch has been posted before but up to now, no-one had a test case that > triggered > the bug, At your service... ;) signature.asc Description: Digital signature
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Thu, Apr 23, 2015 at 12:37 AM, Brian Gerst wrote: > On Tue, Mar 31, 2015 at 8:38 AM, tip-bot for Denys Vlasenko > wrote: >> Commit-ID: e7d6eefaaa443130079d73cd05039d90b3db7a4a >> Gitweb: >> http://git.kernel.org/tip/e7d6eefaaa443130079d73cd05039d90b3db7a4a >> Author: Denys Vlasenko >> AuthorDate: Fri, 27 Mar 2015 11:48:17 -0700 >> Committer: Ingo Molnar >> CommitDate: Tue, 31 Mar 2015 10:45:15 +0200 >> >> x86/vdso32/syscall.S: Do not load __USER32_DS to %ss >> >> This vDSO code only gets used by 64-bit kernels, not 32-bit ones. >> >> On 64-bit kernels, the data segment is the same for 32-bit and >> 64-bit userspace, and the SYSRET instruction loads %ss with its >> selector. >> >> So there's no need to repeat it by hand. Segment loads are somewhat >> expensive: tens of cycles. >> >> Signed-off-by: Denys Vlasenko >> [ Removed unnecessary comment. ] >> Signed-off-by: Andy Lutomirski >> Cc: Alexei Starovoitov >> Cc: Andy Lutomirski >> Cc: Borislav Petkov >> Cc: Frederic Weisbecker >> Cc: H. Peter Anvin >> Cc: Kees Cook >> Cc: Linus Torvalds >> Cc: Oleg Nesterov >> Cc: Steven Rostedt >> Cc: Will Drewry >> Link: >> http://lkml.kernel.org/r/63da6d778f69fd0f1345d9287f6764d58be519fa.1427482099.git.l...@kernel.org >> Signed-off-by: Ingo Molnar >> --- >> arch/x86/vdso/vdso32/syscall.S | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S >> index 5415b56..6b286bb 100644 >> --- a/arch/x86/vdso/vdso32/syscall.S >> +++ b/arch/x86/vdso/vdso32/syscall.S >> @@ -19,8 +19,6 @@ __kernel_vsyscall: >> .Lpush_ebp: >> movl%ecx, %ebp >> syscall >> - movl$__USER32_DS, %ecx >> - movl%ecx, %ss >> movl%ebp, %ecx >> popl%ebp >> .Lpop_ebp: > > This patch unfortunately is causing Wine to break on some applications: > > Unhandled exception: stack overflow in 32-bit code (0xf779bc07). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:f779bc07 ESP:00aed60c EBP:00aed750 EFLAGS:00010216( R- -- I -A-P- ) > EAX:0040 EBX:0010 ECX:00aed750 EDX:0040 > ESI:0040 EDI:7ffd4000 > Stack dump: > 0x00aed60c: 00aed648 f7575e5b 7bcc8000 > 0x00aed61c: 7bc7bc09 0010 00aed750 0040 > 0x00aed62c: 00aed750 00aed650 7bcc8000 7bc7bbdd > 0x00aed63c: 7bcc8000 00aed6a0 00aed750 00aed738 > 0x00aed64c: 7bc7cfa9 0011 00aed750 0040 > 0x00aed65c: 0020 7bc4f141 > Backtrace: > =>0 0xf779bc07 __kernel_vsyscall+0x7() in [vdso].so (0x00aed750) > 1 0xf7575e5b __libc_read+0x4a() in libpthread.so.0 (0x00aed648) > 2 0x7bc7bc09 read_reply_data+0x38(buffer=0xaed750, size=0x40) > [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/server.c:239] > in ntdll (0x00aed648) > 3 0x7bc7cfa9 wine_server_call+0x178() in ntdll (0x00aed738) > 4 0x7bc840ec NtSetEvent+0x4b(handle=0x80, > NumberOfThreadsReleased=0x0(nil)) > [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/sync.c:361] > in ntdll (0x00aed7c8) > 5 0x7b874afa SetEvent+0x24(handle=) > [/home/bgerst/src/wine/wine32/dlls/kernel32/../../../dlls/kernel32/sync.c:572] > in kernel32 (0x00aed7e8) > 6 0x0044e31a in battle.net launcher (+0x4e319) (0x00aed818) > ... > > __kernel_vsyscall+0x7 points to "pop %ebp". > > This is on an AMD Phenom(tm) II X6 1055T Processor. > > It appears that there are some subtle differences in how sysretl works > on AMD vs. Intel. According to the Intel docs, the SS selector and > descriptor cache is completely reset by sysret to fixed values. The > AMD docs however are concerning: My understanding is that, in long mode, the segment attributes are ignored, and that there is no such thing as a "64-bit stack". So... > > AMD's syscall: > SS.sel = MSR_STAR.SYSCALL_CS + 8 > SS.attr = 64-bit stack,dpl0 I don't really believe that. > SS.base = 0x > SS.limit = 0x > > AMD's sysret: > SS.sel = MSR_STAR.SYSRET_CS + 8 // SS selector is changed, > // SS base, limit, attributes unchanged. > I'm pretty sure that this is at least a little bit wrong. It makes no sense for me for syscall to set SS.DPL=0 and for sysret to leave SS.DPL=0. It had better at least change DPL to 3. (Except... don't they mean RPL? Why is the DPL cached at all? But RPL is clearly changed, since it's part of the selector.) > Not changing base or limit is no big deal, but not changing attributes > could be the problem. It might be leaving the "64-bit stack" > attribute set, for whatever that means. Hmm. I don't know if I believe that explanation. For one thing, the APM says "Executing SYSRET in non-64-bit mode or with a 16- or 32-bit operand size returns to 32-bit mode with a 32-bit stack pointer." We can revert this patch or fix it, but I'd like to at least try to understand what's wrong first. Borislav, any ideas? I'm curious whether we can somehow end up in the kernel without a sensible SS. W
[PATCH 2/4] tty: serial: 8250_mtk: remove unnecessary test
When the driver has probed successfully the clk pointer is always valid,
so no need to test for it.
Signed-off-by: Sascha Hauer
---
drivers/tty/serial/8250/8250_mtk.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mtk.c
b/drivers/tty/serial/8250/8250_mtk.c
index c6901dc..bcfaa8dc 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -212,9 +212,7 @@ static int mtk8250_remove(struct platform_device *pdev)
pm_runtime_get_sync(&pdev->dev);
serial8250_unregister_port(data->line);
- if (!IS_ERR(data->uart_clk)) {
- clk_disable_unprepare(data->uart_clk);
- }
+ clk_disable_unprepare(data->uart_clk);
pm_runtime_disable(&pdev->dev);
pm_runtime_put_noidle(&pdev->dev);
@@ -246,8 +244,7 @@ static int mtk8250_runtime_suspend(struct device *dev)
{
struct mtk8250_data *data = dev_get_drvdata(dev);
- if (!IS_ERR(data->uart_clk))
- clk_disable_unprepare(data->uart_clk);
+ clk_disable_unprepare(data->uart_clk);
return 0;
}
@@ -256,8 +253,7 @@ static int mtk8250_runtime_resume(struct device *dev)
{
struct mtk8250_data *data = dev_get_drvdata(dev);
- if (!IS_ERR(data->uart_clk))
- clk_prepare_enable(data->uart_clk);
+ clk_prepare_enable(data->uart_clk);
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 1/4] tty: serial: 8250_mtk: Use devm_clk_get
Just because of_clk_get() doesn't mean it should be used. Use devm_clk_get
which is the correct function when a struct device * is available. Also
since it's a devm function we can drop the calls to clk_put(). While at
it also fix a wrong debug message.
Signed-off-by: Sascha Hauer
---
drivers/tty/serial/8250/8250_mtk.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mtk.c
b/drivers/tty/serial/8250/8250_mtk.c
index 7a11fac..c6901dc 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -131,18 +131,16 @@ static int mtk8250_probe_of(struct platform_device *pdev,
struct uart_port *p,
struct mtk8250_data *data)
{
int err;
- struct device_node *np = pdev->dev.of_node;
- data->uart_clk = of_clk_get(np, 0);
+ data->uart_clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->uart_clk)) {
- dev_warn(&pdev->dev, "Can't get timer clock\n");
+ dev_warn(&pdev->dev, "Can't get uart clock\n");
return PTR_ERR(data->uart_clk);
}
err = clk_prepare_enable(data->uart_clk);
if (err) {
dev_warn(&pdev->dev, "Can't prepare clock\n");
- clk_put(data->uart_clk);
return err;
}
p->uartclk = clk_get_rate(data->uart_clk);
@@ -216,7 +214,6 @@ static int mtk8250_remove(struct platform_device *pdev)
serial8250_unregister_port(data->line);
if (!IS_ERR(data->uart_clk)) {
clk_disable_unprepare(data->uart_clk);
- clk_put(data->uart_clk);
}
pm_runtime_disable(&pdev->dev);
--
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/4] tty: serial: 8250_mtk: use pm_runtime callbacks for enabling
The pm_runtime callbacks already enable and disable the device.
Use them in probe() and remove() instead of duplicating the
code. This allows us to concentrate more code for enabling/disabling
the UART in a single place.
Signed-off-by: Sascha Hauer
---
drivers/tty/serial/8250/8250_mtk.c | 69 --
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mtk.c
b/drivers/tty/serial/8250/8250_mtk.c
index bcfaa8dc..2f28bd0 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -115,6 +115,29 @@ mtk8250_set_termios(struct uart_port *port, struct
ktermios *termios,
tty_termios_encode_baud_rate(termios, baud, baud);
}
+static int mtk8250_runtime_suspend(struct device *dev)
+{
+ struct mtk8250_data *data = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(data->uart_clk);
+
+ return 0;
+}
+
+static int mtk8250_runtime_resume(struct device *dev)
+{
+ struct mtk8250_data *data = dev_get_drvdata(dev);
+ int err;
+
+ err = clk_prepare_enable(data->uart_clk);
+ if (err) {
+ dev_warn(dev, "Can't enable clock\n");
+ return err;
+ }
+
+ return 0;
+}
+
static void
mtk8250_do_pm(struct uart_port *port, unsigned int state, unsigned int old)
{
@@ -130,19 +153,12 @@ mtk8250_do_pm(struct uart_port *port, unsigned int state,
unsigned int old)
static int mtk8250_probe_of(struct platform_device *pdev, struct uart_port *p,
struct mtk8250_data *data)
{
- int err;
-
data->uart_clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->uart_clk)) {
dev_warn(&pdev->dev, "Can't get uart clock\n");
return PTR_ERR(data->uart_clk);
}
- err = clk_prepare_enable(data->uart_clk);
- if (err) {
- dev_warn(&pdev->dev, "Can't prepare clock\n");
- return err;
- }
p->uartclk = clk_get_rate(data->uart_clk);
return 0;
@@ -193,14 +209,18 @@ static int mtk8250_probe(struct platform_device *pdev)
writel(0x0, uart.port.membase +
(MTK_UART_RATE_FIX << uart.port.regshift));
- data->line = serial8250_register_8250_port(&uart);
- if (data->line < 0)
- return data->line;
-
platform_set_drvdata(pdev, data);
- pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ if (!pm_runtime_enabled(&pdev->dev)) {
+ err = mtk8250_runtime_resume(&pdev->dev);
+ if (err)
+ return err;
+ }
+
+ data->line = serial8250_register_8250_port(&uart);
+ if (data->line < 0)
+ return data->line;
return 0;
}
@@ -212,10 +232,13 @@ static int mtk8250_remove(struct platform_device *pdev)
pm_runtime_get_sync(&pdev->dev);
serial8250_unregister_port(data->line);
- clk_disable_unprepare(data->uart_clk);
pm_runtime_disable(&pdev->dev);
pm_runtime_put_noidle(&pdev->dev);
+
+ if (!pm_runtime_status_suspended(&pdev->dev))
+ mtk8250_runtime_suspend(&pdev->dev);
+
return 0;
}
@@ -239,26 +262,6 @@ static int mtk8250_resume(struct device *dev)
}
#endif /* CONFIG_PM_SLEEP */
-#ifdef CONFIG_PM
-static int mtk8250_runtime_suspend(struct device *dev)
-{
- struct mtk8250_data *data = dev_get_drvdata(dev);
-
- clk_disable_unprepare(data->uart_clk);
-
- return 0;
-}
-
-static int mtk8250_runtime_resume(struct device *dev)
-{
- struct mtk8250_data *data = dev_get_drvdata(dev);
-
- clk_prepare_enable(data->uart_clk);
-
- return 0;
-}
-#endif
-
static const struct dev_pm_ops mtk8250_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(mtk8250_suspend, mtk8250_resume)
SET_RUNTIME_PM_OPS(mtk8250_runtime_suspend, mtk8250_runtime_resume,
--
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 4/4] tty: serial: 8250_mtk: Add support for bus clock
The mtk 8250 needs two clocks, one for providing the baudrate and
one that needs to be enabled for register accesses. The latter has
not been supported, this patch adds support for it. It is optional
for now since not all SoCs provide a bus clock.
Signed-off-by: Sascha Hauer
---
Documentation/devicetree/bindings/serial/mtk-uart.txt | 9 +++--
drivers/tty/serial/8250/8250_mtk.c| 14 +-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 4415226..369b5c3 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -14,7 +14,11 @@ Required properties:
- interrupts: A single interrupt specifier.
-- clocks: Clock driving the hardware.
+- clocks : Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names:
+ - "baud": The clock the baudrate is derived from
+ - "bus": The bus clock for register accesses (optional)
Example:
@@ -22,5 +26,6 @@ Example:
compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart";
reg = <0x11006000 0x400>;
interrupts = ;
- clocks = <&uart_clk>;
+ clocks = <&uart_clk>, <&bus_clk>;
+ clock-names = "baud", "bus";
};
diff --git a/drivers/tty/serial/8250/8250_mtk.c
b/drivers/tty/serial/8250/8250_mtk.c
index 2f28bd0..20c27f0 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -34,6 +34,7 @@
struct mtk8250_data {
int line;
struct clk *uart_clk;
+ struct clk *bus_clk;
};
static void
@@ -120,6 +121,7 @@ static int mtk8250_runtime_suspend(struct device *dev)
struct mtk8250_data *data = dev_get_drvdata(dev);
clk_disable_unprepare(data->uart_clk);
+ clk_disable_unprepare(data->bus_clk);
return 0;
}
@@ -135,6 +137,12 @@ static int mtk8250_runtime_resume(struct device *dev)
return err;
}
+ err = clk_prepare_enable(data->bus_clk);
+ if (err) {
+ dev_warn(dev, "Can't enable bus clock\n");
+ return err;
+ }
+
return 0;
}
@@ -153,7 +161,7 @@ mtk8250_do_pm(struct uart_port *port, unsigned int state,
unsigned int old)
static int mtk8250_probe_of(struct platform_device *pdev, struct uart_port *p,
struct mtk8250_data *data)
{
- data->uart_clk = devm_clk_get(&pdev->dev, NULL);
+ data->uart_clk = devm_clk_get(&pdev->dev, "baud");
if (IS_ERR(data->uart_clk)) {
dev_warn(&pdev->dev, "Can't get uart clock\n");
return PTR_ERR(data->uart_clk);
@@ -161,6 +169,10 @@ static int mtk8250_probe_of(struct platform_device *pdev,
struct uart_port *p,
p->uartclk = clk_get_rate(data->uart_clk);
+ data->bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (IS_ERR(data->bus_clk))
+ data->bus_clk = NULL;
+
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/
tty: serial: 8250_mtk: Add support for second clock
The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76: Linux 4.0 (2015-04-12 15:12:50 -0700) are available in the git repository at: git://git.pengutronix.de/git/sha/linux-2.6.git tags/v4.0-mtk-uart-clk for you to fetch changes up to 91bb93e93bf0916f9ebf571e8ab7cb671322ebc8: tty: serial: 8250_mtk: Add support for bus clock (2015-04-23 10:36:04 +0200) This series adds support for the second clock on the Mediatek UART. This is necessary for SoCs needing a bus clock to be enabled before the UART can be accessed. Sascha Hauer (4): tty: serial: 8250_mtk: Use devm_clk_get tty: serial: 8250_mtk: remove unnecessary test tty: serial: 8250_mtk: use pm_runtime callbacks for enabling tty: serial: 8250_mtk: Add support for bus clock .../devicetree/bindings/serial/mtk-uart.txt| 9 ++- drivers/tty/serial/8250/8250_mtk.c | 92 -- 2 files changed, 57 insertions(+), 44 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ext4 crypto: remove duplicated encryption mode definitions
This patch removes duplicated encryption modes which were already in ext4.h. They were duplicated from commit 3edc18d and commit f542fb. Cc: Theodore Ts'o Cc: Michael Halcrow Cc: Andreas Dilger Signed-off-by: Chanho Park --- fs/ext4/ext4.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index ef267ad..07378a4 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1066,12 +1066,6 @@ extern void ext4_set_bits(void *bm, int cur, int len); /* Metadata checksum algorithm codes */ #define EXT4_CRC32C_CHKSUM 1 -/* Encryption algorithms */ -#define EXT4_ENCRYPTION_MODE_INVALID 0 -#define EXT4_ENCRYPTION_MODE_AES_256_XTS 1 -#define EXT4_ENCRYPTION_MODE_AES_256_GCM 2 -#define EXT4_ENCRYPTION_MODE_AES_256_CBC 3 - /* * Structure of the super block */ -- 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] HID: i2c-hid: Do not fail probing if gpiolib is not enabled
On Tue, 14 Apr 2015, Mika Westerberg wrote:
> Using GPIOs and gpiolib is optional. If the kernel is compiled without GPIO
> support the driver should not fail if it finds the interrupt using normal
> methods.
>
> However, commit a485923efbb8 ("HID: i2c-hid: Add support for ACPI GPIO
> interrupts") did not take into account that acpi_dev_add_driver_gpios()
> returns -ENXIO when !CONFIG_GPIOLIB.
>
> Fix this by checking the return value against -ENXIO and 0 and only in that
> case fail the probe.
>
> Reported-by: Gabriele Mazzotta
> Signed-off-by: Mika Westerberg
I have applied this to for-4.1/upstream-fixes.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] GHES: Make NMI handler have a single reader
On Thu, Apr 23, 2015 at 10:39:58AM +0200, Jiri Kosina wrote: > Three weeks have passed, therefore I find this an appropriate time for a > friendly ping :) > > Rafael? Naoya? Huang? > > This fixes a contention spinlock problem in NMI observed on a real HW, so > it would be really nice to have it fixed. I think we should apply this. Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific accesses. It iterates over the list of ghes sources which do NMI notification but those sources are the *same* regardless of which core does the access as their addresses are per-source, i.e. in that struct acpi_generic_address error_status_address; thing. And it is a safe bet to say that all that error information is serialized in the firmware for the error source to consume. So I'm going to route this through the RAS tree unless Rafael wants to take it. Ok? Tony, objections? -- 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/
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Thu, Apr 23, 2015 at 1:49 AM, Andy Lutomirski wrote:
>
> I'm curious whether we can somehow end up in the kernel without a
> sensible SS. What happens if we have SS = 0?
>
> Try this on for size:
>
> 1. Wine process does syscall
> 2. Context switch to any other task
> 3. Interrupt (software or hardware), which loads SS with ss0, which is
> 0 on x86_64.
> 4. Context switch back to Wine.
> 5. sysretl
>
> Would fixing this be as simple as changing this code in
> arch/x86/kernel/process.c:
>
> __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss) = {
> .x86_tss = {
> .sp0 = TOP_OF_INIT_STACK,
> #ifdef CONFIG_X86_32
> .ss0 = __KERNEL_DS,
>
> by moving the ifdef down a line? Even if that fixed it, it would be
> extremely fragile, but IMO it would be a good change to make
> regardless (i.e. the kernel's SS would be less unpredictable).
Confirmed with KVM on VMX: we can definitely end up in the kernel with SS == 0.
I don't know whether changing ss0 would be a good idea, though. It
would be cleaner, but it could slow down interrupt processing:
interrupt delivery would have to do an extra GDT load.
Food for thought: wouldn't this mean that we have a bug on sysretq
too? If we're in the kernel with SS == 0, we do sysretq, and then
user code does a far jump to 32-bit code, then we end up with a bogus
SS. Maybe we don't care, and reloading SS on every sysretq would
suck. We could fix it up in a kind of evil way: in do_stack_segment,
we could detect that we had SS == __USER_DS, in which case #SS should
be impossible, and just return without signalling the process. IRET
would fix up the attributes.
We just might need a stable fix, though -- I wonder if there's any bad
interaction with opportunistic sysret in 4.0. Maybe we should
benchmark ss0 = __KERNEL_DS and try it after all.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Thu, 2015-04-23 at 10:15 +0200, Jiri Kosina wrote:
> On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote:
>
> > > I've been running current Linus' tree and have been getting system
> > > lockups
> > > frequently. After a few "silent" lockups, I was able to obtain a dmesg
> > > before the machine turned dead again (wifi stopped working shortly before
> > > that).
> > >
> > > Before starting to debug / bisect (last known good on this machine is
> > > 4.0-rc6), I am attaching the dmesg in case someone already knows what the
> > > issue is.
> > >
> >
> > I briefly went over the iwlwifi commits between 4.0-rc6 and linux/master
> > and couldn't find anything obvious.
> > Note that for the device you have, the commits that touch
> > drivers/net/wireless/iwlwifi/mvm are not relevant.
> >
> > What you are seeing is that the PCI host is disconnecting the WiFi NIC
> > for some weird reason. It is not the first time I see that, but
> > unfortunately, I have never been able to debug this. I am personally not
> > a HW PCI expert and I couldn't reproduce either...
> >
> > I am afraid I won't save you the time of the bisection, but I am not
> > entirely sure that bisecting the iwlwifi driver is enough to find the
> > commit that broke it. You may want to bisect the pci bus driver as well.
>
> The problem is that I can't really reliably reproduce it; it happens
> rather often, but not so often that I could be certainly sure that my
> distinction of good and bad kernels would be accurate.
>
> I will try it, but I expect the result to be bogus because of this,
> unfortunately.
>
I can understand. A few users reported that this bug occurred more
reliably when moving their system, although it seems very weird to me.
> > First question is: Are you sure that 4.0-rc6 was good?
>
> Pretty much, yes. I've been running it for quite some time on this
> machine without any issues. But after updating to current HEAD two days
> ago, the issue triggered like 6 or 7 times already.
>
Ok - I will try to look at the PCI commits there although I am not sure
I'll be able to make much sense of them...
> Thanks,
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [GIT PULL] First batch of KVM changes for 4.1
On 22/04/2015 23:21, Marcelo Tosatti wrote: > On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote: >> On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini wrote: >>> >>> >>> On 17/04/2015 22:18, Marcelo Tosatti wrote: The bug which this is fixing is very rare, have no memory of a report. In fact, its even difficult to create a synthetic reproducer. >>> >>> But then why was the task migration notifier even in Jeremy's original >>> code for Xen? Was it supposed to work even on non-synchronized TSC? >>> >>> If that's the case, then it could be reverted indeed; but then why did >>> you commit this patch to 4.1? Did you think of something that would >>> cause the seqcount-like protocol to fail, and that turned out not to be >>> the case later? I was only following the mailing list sparsely in March. >> >> I don't think anyone ever tried that hard to test this stuff. There >> was an infinte loop that Firefox was triggering as a KVM guest >> somewhat reliably until a couple months ago in the same vdso code. :( > > https://bugzilla.redhat.com/show_bug.cgi?id=1174664 That was the missing volatile in an asm. Older compilers didn't catch it. :( Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: iwlwifi getting stuck with current Linus' tree (646da63172)
On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: > > I will try it, but I expect the result to be bogus because of this, > > unfortunately. > > I can understand. A few users reported that this bug occurred more > reliably when moving their system, although it seems very weird to me. My "feeling" was that it sometimes was related to start of audio playback, but not 100% relieble either. > > > First question is: Are you sure that 4.0-rc6 was good? > > > > Pretty much, yes. I've been running it for quite some time on this > > machine without any issues. But after updating to current HEAD two days > > ago, the issue triggered like 6 or 7 times already. > > Ok - I will try to look at the PCI commits there although I am not sure > I'll be able to make much sense of them... Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/i915: Fix screen flickering on X
[cc'ing the authors]
On Sat, Apr 11, 2015 at 07:40:34PM -0300, Ismael Luceno wrote:
> A bisect showed that commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
> introduced the issue.
>
> The issue starts as soon as X takes control of the screen, even if just
> a plain X doing nothing, so based on the code touched by the commit I
> thought it had to be related to the so called "hardware cursor". I
> confirmed it when hiding the cursor made the flickering go away.
>
> The aforementioned commit removed some suspicious code, and the
> Programmer's Reference Manual confirmed my suspicion:
>
> "Incorrectly programmed watermark values can result in screen corruption.
>
> The watermarks should be calculated and programmed when any of the
> watermark calculation inputs change. This includes planes enabling or
> disabling, plane source format or size changing, etc."
>
> So I'm re-adding the few lines that update the watermarks after a cursor
> size change.
>
> Signed-off-by: Ismael Luceno
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f75173c..e23f062 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12258,6 +12258,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
> struct intel_crtc *intel_crtc;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> struct drm_i915_gem_object *obj = intel_fb_obj(state->base.fb);
> + unsigned old_width;
> uint32_t addr;
>
> crtc = crtc ? crtc : plane->crtc;
> @@ -12282,11 +12283,15 @@ intel_commit_cursor_plane(struct drm_plane *plane,
> intel_crtc->cursor_addr = addr;
> intel_crtc->cursor_bo = obj;
> update:
> + old_width = intel_crtc->cursor_width;
> intel_crtc->cursor_width = state->base.crtc_w;
> intel_crtc->cursor_height = state->base.crtc_h;
>
> - if (intel_crtc->active)
> + if (intel_crtc->active) {
> + if (old_width != intel_crtc->cursor_width)
> + intel_update_watermarks(crtc);
> intel_crtc_update_cursor(crtc, state->visible);
> + }
> }
>
> static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
> --
> 2.3.4
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] w1: introduce an ability to specify microseconds bus scanning intervals
On Thu, Apr 23, 2015 at 12:55:35AM +0300, Dmitry Khromov wrote: > Signed-off-by: Dmitry Khromov > --- > drivers/w1/w1.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) You added a new sysfs file, without any documentation about it added to Documentation/ABI, nor any reason why this needs to be done in the changelog entry for the patch. I need _some_ kind of information here, sorry, I can't take this as-is. 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/
[v6] kvm/fpu: Enable fully eager restore kvm FPU
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Signed-off-by: Liang Li
Signed-off-by: Xudong Hao
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/svm.c | 22 ++--
arch/x86/kvm/vmx.c | 74 +++--
arch/x86/kvm/x86.c | 8 +
include/linux/kvm_host.h| 2 --
5 files changed, 9 insertions(+), 98 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index dea2e7e..5d84cc9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -743,7 +743,6 @@ struct kvm_x86_ops {
void (*cache_reg)(struct kvm_vcpu *vcpu, enum kvm_reg reg);
unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
- void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
void (*tlb_flush)(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ce741b8..1b3b29b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1087,7 +1087,6 @@ static void init_vmcb(struct vcpu_svm *svm)
struct vmcb_control_area *control = &svm->vmcb->control;
struct vmcb_save_area *save = &svm->vmcb->save;
- svm->vcpu.fpu_active = 1;
svm->vcpu.arch.hflags = 0;
set_cr_intercept(svm, INTERCEPT_CR0_READ);
@@ -1529,15 +1528,12 @@ static void update_cr0_intercept(struct vcpu_svm *svm)
ulong gcr0 = svm->vcpu.arch.cr0;
u64 *hcr0 = &svm->vmcb->save.cr0;
- if (!svm->vcpu.fpu_active)
- *hcr0 |= SVM_CR0_SELECTIVE_MASK;
- else
- *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
- | (gcr0 & SVM_CR0_SELECTIVE_MASK);
+ *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
+ | (gcr0 & SVM_CR0_SELECTIVE_MASK);
mark_dirty(svm->vmcb, VMCB_CR);
- if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
+ if (gcr0 == *hcr0) {
clr_cr_intercept(svm, INTERCEPT_CR0_READ);
clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
} else {
@@ -1568,8 +1564,6 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
if (!npt_enabled)
cr0 |= X86_CR0_PG | X86_CR0_WP;
- if (!vcpu->fpu_active)
- cr0 |= X86_CR0_TS;
/*
* re-enable caching here because the QEMU bios
* does not do it - this results in some delay at
@@ -1795,7 +1789,6 @@ static void svm_fpu_activate(struct kvm_vcpu *vcpu)
clr_exception_intercept(svm, NM_VECTOR);
- svm->vcpu.fpu_active = 1;
update_cr0_intercept(svm);
}
@@ -4139,14 +4132,6 @@ static bool svm_has_wbinvd_exit(void)
return true;
}
-static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
-{
- struct vcpu_svm *svm = to_svm(vcpu);
-
- set_exception_intercept(svm, NM_VECTOR);
- update_cr0_intercept(svm);
-}
-
#define PRE_EX(exit) { .exit_code = (exit), \
.stage = X86_ICPT_PRE_EXCEPT, }
#define POST_EX(exit) { .exit_code = (exit), \
@@ -4381,7 +4366,6 @@ static struct kvm_x86_ops svm_x86_ops = {
.cache_reg = svm_cache_reg,
.get_rflags = svm_get_rflags,
.set_rflags = svm_set_rflags,
- .fpu_deactivate = svm_fpu_deactivate,
.tlb_flush = svm_flush_tlb,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f5e8dce..811a666 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1567,7 +1567,7 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
u32 eb;
eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
-(1u << NM_VECTOR) | (1u << DB_VECTOR);
+(1u << DB_VECTOR);
if ((vcpu->guest_debug &
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
@@ -1576,8 +1576,6 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
eb = ~0;
if (enable_ept)
eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
- if (vcpu->fpu_active)
- eb &= ~(1u << NM_VECTOR);
/* When we are running a nested L2 guest and L1 specified for it a
* certain exception bitmap, we must trap the same exceptions and pass
@@ -1961,9 +1959,6 @@ static void vmx_fpu_activate(struct kvm_vcpu *vcpu)
{
ulong cr0;
- if (vcpu->fpu_active)
- return;
- vcpu->fpu_active = 1;
cr0 = vmcs_readl(GUEST_CR0);
cr0 &= ~(X86_CR0_TS | X86_CR0_MP);
cr0 |= kvm_read_cr0_bits(vcpu, X86_CR0_TS | X86_CR0_MP);
@@ -1994,33 +1989,6 @@ static inline unsigned long nested_read_cr4(struct
vmcs12 *fields)
(fields->cr4_read_shadow &
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On 04/23/2015 09:37 AM, Brian Gerst wrote: > On Tue, Mar 31, 2015 at 8:38 AM, tip-bot for Denys Vlasenko > wrote: >> Commit-ID: e7d6eefaaa443130079d73cd05039d90b3db7a4a >> Gitweb: >> http://git.kernel.org/tip/e7d6eefaaa443130079d73cd05039d90b3db7a4a >> Author: Denys Vlasenko >> AuthorDate: Fri, 27 Mar 2015 11:48:17 -0700 >> Committer: Ingo Molnar >> CommitDate: Tue, 31 Mar 2015 10:45:15 +0200 >> >> x86/vdso32/syscall.S: Do not load __USER32_DS to %ss >> >> This vDSO code only gets used by 64-bit kernels, not 32-bit ones. >> >> On 64-bit kernels, the data segment is the same for 32-bit and >> 64-bit userspace, and the SYSRET instruction loads %ss with its >> selector. >> >> So there's no need to repeat it by hand. Segment loads are somewhat >> expensive: tens of cycles. >> >> Signed-off-by: Denys Vlasenko >> [ Removed unnecessary comment. ] >> Signed-off-by: Andy Lutomirski >> Cc: Alexei Starovoitov >> Cc: Andy Lutomirski >> Cc: Borislav Petkov >> Cc: Frederic Weisbecker >> Cc: H. Peter Anvin >> Cc: Kees Cook >> Cc: Linus Torvalds >> Cc: Oleg Nesterov >> Cc: Steven Rostedt >> Cc: Will Drewry >> Link: >> http://lkml.kernel.org/r/63da6d778f69fd0f1345d9287f6764d58be519fa.1427482099.git.l...@kernel.org >> Signed-off-by: Ingo Molnar >> --- >> arch/x86/vdso/vdso32/syscall.S | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S >> index 5415b56..6b286bb 100644 >> --- a/arch/x86/vdso/vdso32/syscall.S >> +++ b/arch/x86/vdso/vdso32/syscall.S >> @@ -19,8 +19,6 @@ __kernel_vsyscall: >> .Lpush_ebp: >> movl%ecx, %ebp >> syscall >> - movl$__USER32_DS, %ecx >> - movl%ecx, %ss >> movl%ebp, %ecx >> popl%ebp >> .Lpop_ebp: > > This patch unfortunately is causing Wine to break on some applications: > > Unhandled exception: stack overflow in 32-bit code (0xf779bc07). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:f779bc07 ESP:00aed60c EBP:00aed750 EFLAGS:00010216( R- -- I -A-P- ) > EAX:0040 EBX:0010 ECX:00aed750 EDX:0040 > ESI:0040 EDI:7ffd4000 > Stack dump: > 0x00aed60c: 00aed648 f7575e5b 7bcc8000 > 0x00aed61c: 7bc7bc09 0010 00aed750 0040 > 0x00aed62c: 00aed750 00aed650 7bcc8000 7bc7bbdd > 0x00aed63c: 7bcc8000 00aed6a0 00aed750 00aed738 > 0x00aed64c: 7bc7cfa9 0011 00aed750 0040 > 0x00aed65c: 0020 7bc4f141 > Backtrace: > =>0 0xf779bc07 __kernel_vsyscall+0x7() in [vdso].so (0x00aed750) > 1 0xf7575e5b __libc_read+0x4a() in libpthread.so.0 (0x00aed648) > 2 0x7bc7bc09 read_reply_data+0x38(buffer=0xaed750, size=0x40) > [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/server.c:239] > in ntdll (0x00aed648) > 3 0x7bc7cfa9 wine_server_call+0x178() in ntdll (0x00aed738) > 4 0x7bc840ec NtSetEvent+0x4b(handle=0x80, > NumberOfThreadsReleased=0x0(nil)) > [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/sync.c:361] > in ntdll (0x00aed7c8) > 5 0x7b874afa SetEvent+0x24(handle=) > [/home/bgerst/src/wine/wine32/dlls/kernel32/../../../dlls/kernel32/sync.c:572] > in kernel32 (0x00aed7e8) > 6 0x0044e31a in battle.net launcher (+0x4e319) (0x00aed818) > ... > > __kernel_vsyscall+0x7 points to "pop %ebp". > > This is on an AMD Phenom(tm) II X6 1055T Processor. > > It appears that there are some subtle differences in how sysretl works > on AMD vs. Intel. According to the Intel docs, the SS selector and > descriptor cache is completely reset by sysret to fixed values. The > AMD docs however are concerning: > > AMD's syscall: > SS.sel = MSR_STAR.SYSCALL_CS + 8 > SS.attr = 64-bit stack,dpl0 > SS.base = 0x > SS.limit = 0x > > AMD's sysret: > SS.sel = MSR_STAR.SYSRET_CS + 8 // SS selector is changed, > // SS base, limit, attributes unchanged. > Not changing base or limit is no big deal, but not changing attributes > could be the problem. It might be leaving the "64-bit stack" > attribute set, for whatever that means. I am not aware of any officially existing "64-bit" stack or data segment attribute. x86 data segment descriptors don't have any such bits, the 64-bitness of stack operations in long mode is hardwired. (Unlike code segment descriptors, which _do_ have a bit which controls 64-bitness). This is not to say that CPU internally is prohibited from having something along those lines. However, if AMD CPUs would have a bug where after sysretl %ss descriptor cache is left in a bad state causing stack ops to be done in 64-bit fashion, *any* 32-bit userspace would immediately explode. This is not the case. What Wine could do differently from a typical Linux executable? It may use nonzero %ss base, it may use a non-4Gb limit, it may use 16-bit stack segment, it may use an expand-down stack segment. (I know very little about Windows/Wine internals, so I just listed all possibilities which came to m
[PATCH] ncpfs: Remove pointless cast
Remove explicit casts of kmem_cache_alloc return values in
fs/ncpfs/inode.c::ncp_alloc_inode().
Signed-off-by: Firo Yang
---
fs/ncpfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ncpfs/inode.c b/fs/ncpfs/inode.c
index 01a9e16..a3aab17 100644
--- a/fs/ncpfs/inode.c
+++ b/fs/ncpfs/inode.c
@@ -52,7 +52,7 @@ static struct kmem_cache * ncp_inode_cachep;
static struct inode *ncp_alloc_inode(struct super_block *sb)
{
struct ncp_inode_info *ei;
- ei = (struct ncp_inode_info *)kmem_cache_alloc(ncp_inode_cachep,
GFP_KERNEL);
+ ei = kmem_cache_alloc(ncp_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
return &ei->vfs_inode;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] x86: mm: Enable deferred struct page initialisation on x86-64
On Wed, Apr 22, 2015 at 04:45:00PM -0700, Andrew Morton wrote: > On Wed, 22 Apr 2015 18:07:50 +0100 Mel Gorman wrote: > > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -32,6 +32,7 @@ config X86 > > select HAVE_UNSTABLE_SCHED_CLOCK > > select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 > > select ARCH_SUPPORTS_INT128 if X86_64 > > + select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT if X86_64 && NUMA > > Put this in the "config X86_64" section and skip the "X86_64 &&"? > Done. > Can we omit the whole defer_meminit= thing and permanently enable the > feature? That's simpler, provides better test coverage and is, we > hope, faster. > Yes. The intent was to have a workaround if there were any failures like Waiman's vmalloc failures in an earlier version but they are bugs that should be fixed. > And can this be used on non-NUMA? Presumably that won't speed things > up any if we're bandwidth limited but again it's simpler and provides > better coverage. Nothing prevents it. There is less opportunity for parallelism but improving coverage is desirable. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] elevator: fix double release for elevator module
Our issue is descripted in below call path:
->elevator_init
->elevator_init_fn
->{cfq,deadline,noop}_init_queue
->elevator_alloc
->kzalloc_node
fail to call kzalloc_node and then put module in elevator_alloc;
fail to call elevator_init_fn and then put module again in elevator_init.
Remove elevator_put invoking in error path of elevator_alloc to avoid
double release issue.
Signed-off-by: Chao Yu
---
block/elevator.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/block/elevator.c b/block/elevator.c
index d146a5e..8985038 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -157,7 +157,7 @@ struct elevator_queue *elevator_alloc(struct request_queue
*q,
eq = kzalloc_node(sizeof(*eq), GFP_KERNEL, q->node);
if (unlikely(!eq))
- goto err;
+ return NULL;
eq->type = e;
kobject_init(&eq->kobj, &elv_ktype);
@@ -165,9 +165,6 @@ struct elevator_queue *elevator_alloc(struct request_queue
*q,
hash_init(eq->hash);
return eq;
-err:
- elevator_put(e);
- return NULL;
}
EXPORT_SYMBOL(elevator_alloc);
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On 04/23/2015 10:49 AM, Andy Lutomirski wrote:
> Would fixing this be as simple as changing this code in
> arch/x86/kernel/process.c:
>
> __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss) = {
> .x86_tss = {
> .sp0 = TOP_OF_INIT_STACK,
> #ifdef CONFIG_X86_32
> .ss0 = __KERNEL_DS,
>
> by moving the ifdef down a line?
You can't do that. 64-bit TSS has no .ss0/1/2 fields :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11]: clk: Add common clock support for Mediatek MT8135 and MT8173
On Wed, Apr 15, 2015 at 05:48:08PM +0200, Matthias Brugger wrote: > 2015-04-15 17:11 GMT+02:00 Matthias Brugger : > > 2015-04-14 13:57 GMT+02:00 Sascha Hauer : > >> On Tue, Apr 14, 2015 at 01:01:30PM +0200, Matthias Brugger wrote: > >>> Hi Sascha, > >>> > >>> 2015-04-14 12:08 GMT+02:00 Sascha Hauer : > >>> > Hi Matthias, > >>> > > >>> > On Tue, Apr 07, 2015 at 01:47:58PM +0200, Matthias Brugger wrote: > >>> >> Hi Sascha, > >>> >> > >>> >> > >>> >> 2015-03-31 20:16 GMT+02:00 Sascha Hauer : > >>> >> > > >>> >> > The following changes since commit > >>> >> > 9eccca0843205f87c00404b663188b88eb248051: > >>> >> > > >>> >> > Linux 4.0-rc3 (2015-03-08 16:09:09 -0700) > >>> >> > > >>> >> > are available in the git repository at: > >>> >> > > >>> >> > git://git.pengutronix.de/git/imx/linux-2.6.git > >>> >> > tags/v4.0-clk-mediatek-v11 > >>> >> > > >>> >> > for you to fetch changes up to > >>> >> > ae9129219143cfdefe8b3a463deb8c5cb8955525: > >>> >> > > >>> >> > dt-bindings: ARM: Mediatek: Document devicetree bindings for > >>> >> > clock/reset controllers (2015-03-31 20:08:46 +0200) > >>> >> > > >>> >> > > >>> >> > This patchset contains the initial common clock support for Mediatek > >>> >> > SoCs. > >>> >> > Mediatek SoC's clock architecture comprises of various PLLs, > >>> >> > dividers, muxes > >>> >> > and clock gates. > >>> >> > >>> >> I tried the patch set on my mt8135 eval board. I used the dts bindings > >>> >> from a former version of this set [1], but it does not boot the board > >>> >> (based on v4.0-rc7). > >>> >> Do you have any hint, what is happening, or are the bindings wrong? > >>> > > >>> > I just tried on a v4.0 with > >>> > - this series applied > >>> > - the dts patch applied (which is still up-to-date) > >>> > - multi_v7_defconfig > >>> > > >>> > And it still works. What do you mean with "does not boot the board"? No > >>> > console output? Could you try with earlyprintk? > >>> > >>> The probelms I see is, that with the clock patches, I'm not able to > >>> boot into a initramfs [1]. > >>> Whereas if I just comment topckgen and preicfg in the dts, I'm able to > >>> get the a serial console of my initramfs [2]. > >>> > >>> I wonder if you are able to get serial console from the initramfs with > >>> the clock patches + dts patch? > >> > >> So you get kernel messages but no output from initramfs? In this case > >> the kernel disables the unused clocks in a late_initcall. The UART > >> driver still uses the dummy clock provided in the dtsi, so the real > >> UART clk gets disabled in the initcall. Try passing clk_ignore_unused to > >> the kernel > > > > OK, I can boot to the initramfs with this kernel parameter, but it > > fails to boot, when I change the uart clock. I suppose that PERI_UART3 > > for debug port uart3 should be fine, but it looks like it doesn't > > work. > > I can see on the mt6589 datasheet that you have a register > > PERI_UART_CK_SOURCE_SEL where you can decide if you want a 26 MHz or a > > 52 MHz clock for the UART block. > > Does this register exists on mt8135? If so, why is it not implemented? > > I found that PERI_UARTx_CK is connected to axi_sel but should be > connected to uart_sel. Like this I'm able to reach to initramfs > console, but the baud rate values are screwed up. > As uart_sel is at 52 MHz, I suppose we need to change the entries in > PERI_UART_CK_SOURCE_SEL. I sorted the UART clock stuff out. I sent out three series, with all of them merged together you should get UART + common clock support working properly on MT835. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/27] IB/Verbs: Reform IB-core verbs/uverbs_cmd/sysfs
On 04/22/2015 06:28 PM, ira.weiny wrote:
[snip]
>
>>
>> link_layer_show() was supposed to report the same info to user
>> space as usual, so user tool don't have to change anything :-)
>
> We need to expose the "cap_*" functionality to userspace which can then
> convert
> to this interface and stop relying on inferring support based on the link
> layer. But that is a separate issue from correctly reporting the link layer.
>
> The link layer should be reported correctly from the drivers "get_link_layer"
> call.
I get your point :-) link_layer_show() and ib_uverbs_query_port() do
only need the link layer type rather then a mgmt check, modification
on these two will be dropped in next version.
Regards,
Michael Wang
>
> Ira
>
>>
>> Regards,
>> Michael Wang
>>
>>>
>>> Ira
>>>
return sprintf(buf, "%s\n", "InfiniBand");
- case IB_LINK_LAYER_ETHERNET:
+ else
return sprintf(buf, "%s\n", "Ethernet");
- default:
- return sprintf(buf, "%s\n", "Unknown");
- }
}
static PORT_ATTR_RO(state);
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index a9f0489..5dc90aa 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -515,8 +515,10 @@ ssize_t ib_uverbs_query_port(struct ib_uverbs_file
*file,
resp.active_width= attr.active_width;
resp.active_speed= attr.active_speed;
resp.phys_state = attr.phys_state;
- resp.link_layer = rdma_port_get_link_layer(file->device->ib_dev,
- cmd.port_num);
+ resp.link_layer = rdma_tech_ib(file->device->ib_dev,
+ cmd.port_num) ?
+ IB_LINK_LAYER_INFINIBAND :
+ IB_LINK_LAYER_ETHERNET;
if (copy_to_user((void __user *) (unsigned long) cmd.response,
&resp, sizeof resp))
diff --git a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
index 626c9cf..7264860 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -200,11 +200,9 @@ int ib_init_ah_from_wc(struct ib_device *device, u8
port_num, struct ib_wc *wc,
u32 flow_class;
u16 gid_index;
int ret;
- int is_eth = (rdma_port_get_link_layer(device, port_num) ==
- IB_LINK_LAYER_ETHERNET);
memset(ah_attr, 0, sizeof *ah_attr);
- if (is_eth) {
+ if (rdma_tech_iboe(device, port_num)) {
if (!(wc->wc_flags & IB_WC_GRH))
return -EPROTOTYPE;
@@ -873,7 +871,7 @@ int ib_resolve_eth_l2_attrs(struct ib_qp *qp,
union ib_gid sgid;
if ((*qp_attr_mask & IB_QP_AV) &&
- (rdma_port_get_link_layer(qp->device, qp_attr->ah_attr.port_num) ==
IB_LINK_LAYER_ETHERNET)) {
+ (rdma_tech_iboe(qp->device, qp_attr->ah_attr.port_num))) {
ret = ib_query_gid(qp->device, qp_attr->ah_attr.port_num,
qp_attr->ah_attr.grh.sgid_index, &sgid);
if (ret)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] minix: No need to cast alloction return value in minix
Remove unneeded kmem_cache_alloc() return value casts in
fs/minix/inode.c::minix_alloc_inode().
Signed-off-by: Firo Yang
---
fs/minix/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index 3f57af1..8898633 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -62,7 +62,7 @@ static struct kmem_cache * minix_inode_cachep;
static struct inode *minix_alloc_inode(struct super_block *sb)
{
struct minix_inode_info *ei;
- ei = (struct minix_inode_info *)kmem_cache_alloc(minix_inode_cachep,
GFP_KERNEL);
+ ei = kmem_cache_alloc(minix_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
return &ei->vfs_inode;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hpfs: Remove unessary cast
Avoid a pointless kmem_cache_alloc() return value cast in
fs/hpfs/super.c::hpfs_alloc_inode()
Signed-off-by: Firo Yang
---
fs/hpfs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/hpfs/super.c b/fs/hpfs/super.c
index 7cd00d3..ccace08 100644
--- a/fs/hpfs/super.c
+++ b/fs/hpfs/super.c
@@ -201,7 +201,7 @@ static struct kmem_cache * hpfs_inode_cachep;
static struct inode *hpfs_alloc_inode(struct super_block *sb)
{
struct hpfs_inode_info *ei;
- ei = (struct hpfs_inode_info *)kmem_cache_alloc(hpfs_inode_cachep,
GFP_NOFS);
+ ei = kmem_cache_alloc(hpfs_inode_cachep, GFP_NOFS);
if (!ei)
return NULL;
ei->vfs_inode.i_version = 1;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 22/27] IB/Verbs: Use management helper cap_ipoib()
On 04/22/2015 06:45 PM, ira.weiny wrote:
> On Wed, Apr 22, 2015 at 10:49:44AM +0200, Michael Wang wrote:
>>
>> On 04/22/2015 07:40 AM, Jason Gunthorpe wrote:
>>> On Mon, Apr 20, 2015 at 10:41:38AM +0200, Michael Wang wrote:
>>>
Introduce helper cap_ipoib() to help us check if the port of an
IB device support IP over Infiniband.
>>>
>>> I thought we were dropping this in favor of listing the actual
>>> features the ULP required unconditionally? One of my messages had the
>>> start of a list..
>
> ??? I forget. I was arguing that we should not have it. But I thought
> others
> disagreed with me so it was left in.
>
> V4 of this patch had no responses.
>
> https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg24040.html
>
> Jason, I can't find the email where you mentioned a list?
I don't see a list too :-P but agreed the ULP reform idea, the check should be
ipoib_init()
{
if (device don't suport SA or IB CM or...)
return error;
...
}
So I'll put the reform to that series.
Regards,
Michael Wang
>
> Ira
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] simple_char: New infrastructure to simplify chardev management
Hi
On Wed, Feb 11, 2015 at 12:44 AM, Andy Lutomirski wrote:
> This isn't adequately tested, and I don't have a demonstration (yet).
> It's here for review for whether it's a good idea in the first place
> and for weather the fully_dynamic mechanism is a good idea.
>
> The current character device interfaces are IMO awful. There's a
> reservation mechanism (alloc_chrdev_region, etc), a bizarre
> sort-of-hashtable lookup mechanism that character drivers need to
> interact with (cdev_add, etc), and number of lookup stages on open
> with various levels of optimization. Despite all the code, there's no
> core infrastructure to map from a dev_t back to a kobject, struct
> device, or any other useful device pointer.
>
> This means that lots of drivers need to implement all of this
> themselves. The drivers don't even all seem to do it right. For
> example, the UIO code seems to be missing any protection against
> chardev open racing against device removal.
>
> On top of the complexity of writing a chardev driver, the user
> interface is odd. We have /proc/devices, which nothing should use,
> since it conveys no information about minor numbers, and minors are
> mostly dynamic these days. Even the major numbers aren't terribly
> useful, since sysfs refers to (major, minor) pairs.
>
> This adds simple helpers simple_char_minor_create and
> simple_char_minor_free to create and destroy chardev minors. Common
> code handles minor allocation and lookup and provides a simple helper
> to allow (and even mostly require!) users to reference count their
> devices correctly.
>
> Users can either allocation a traditional dynamic major using
> simple_char_major_create, or they can use a global "fully_dynamic"
> major and avoid thinking about major numbers at all.
>
> This currently does not integrate with the driver core at all.
> Users are responsible for plugging the dev_t into their struct
> devices manually. I couldn't see a clean way to fix this without
> integrating all of this into the driver core.
>
> Thoughts? I want to use this for the u2f driver, which will either be
> a chardev driver in its own right or use a simple new iso7816 class.
>
> Ideally we could convert a bunch of drivers to use this, at least
> where there are no legacy minor number considerations.
>
> (Note: simple_char users will *not* have their devicename%d indices
> match their minor numbers unless they specifically arrange for this to
> be the case. For new drivers, this shouldn't be a problem at all. I
> don't know whether it matters for old drivers.)
>
> Signed-off-by: Andy Lutomirski
> ---
>
> drivers/base/Makefile | 2 +-
> drivers/base/simple_char.c | 231
>
> include/linux/simple_char.h | 38
> 3 files changed, 270 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/simple_char.c
> create mode 100644 include/linux/simple_char.h
>
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 6922cd6850a2..d3832749f74c 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o
> syscore.o \
>driver.o class.o platform.o \
>cpu.o firmware.o init.o map.o devres.o \
>attribute_container.o transport_class.o \
> - topology.o container.o
> + topology.o container.o simple_char.o
> obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
> obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
> obj-y += power/
> diff --git a/drivers/base/simple_char.c b/drivers/base/simple_char.c
> new file mode 100644
> index ..f3205ef9e44b
> --- /dev/null
> +++ b/drivers/base/simple_char.c
> @@ -0,0 +1,231 @@
> +/*
> + * A simple way to create character devices
> + *
> + * Copyright (c) 2015 Andy Lutomirski
> + *
> + * Loosely based, somewhat arbitrarily, on the UIO driver, which is one
> + * of many copies of essentially identical boilerplate.
> + *
> + * Licensed under the GPLv2.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_MINORS (1U << MINORBITS)
> +
> +struct simple_char_major {
> + struct cdev cdev;
> + unsigned majornum;
> + struct idr idr;
> + struct mutex lock;
> +};
> +
> +static struct simple_char_major *fully_dynamic_major;
> +static DEFINE_MUTEX(fully_dynamic_major_lock);
> +
> +static int simple_char_open(struct inode *inode, struct file *filep)
> +{
> + struct simple_char_major *major =
> + container_of(inode->i_cdev, struct simple_char_major,
> +cdev);
> + void *private;
> + const struct simple_char_ops *ops;
> + int ret = 0;
> +
> + mutex_lock(&major->lock);
> +
> + {
> + /*
> +
Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
On 04/22/2015 07:10 PM, ira.weiny wrote: > On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote: >> On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote: > > [snip] > >>> >>> 2)The name rdma_tech_* is lame. >>> rdma_transport_*(), adhering to the above (*) remark, is much better. >>> For example, both IB and ROCE *do* use the same transport. >> >> I especially want to second this. I haven't really been happy with the >> rdma_tech_* names at all. >> > > I am sure Michael is open to alternative names. I know I am. The problem is > that we can't figure out what "IBoE" is. It is not a transport, even though > query_transport is now returning it as one. :-P Exactly :-P > > I think the idea behind the "tech" name was that it is a technology "family". > I can't think of a better name. IMHO a single patch to change the name and collecting all the discussion in that thread would be better. The discussion in this thread already starting to be scattered, like discussion on bitmask would be better in a thread dedicated on that purpose, otherwise we have to collect all these scattered discussions again when the bitmask series come out... Regards, Michael Wang > > Ira > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Thu, Apr 23, 2015 at 01:49:50AM -0700, Andy Lutomirski wrote: > I'm pretty sure that this is at least a little bit wrong. It makes no > sense for me for syscall to set SS.DPL=0 and for sysret to leave > SS.DPL=0. It had better at least change DPL to 3. (Except... don't > they mean RPL? Why is the DPL cached at all? But RPL is clearly > changed, since it's part of the selector.) I think this should explain it a bit: "• STAR—The STAR register has the following fields (unless otherwise noted, all bits are read/write): - SYSRET CS and SS Selectors—Bits 63:48. This field is used to specify both the CS and SS selectors loaded into CS and SS during SYSRET. If SYSRET is returning to 32-bit mode (either legacy or compatibility), this field is copied directly into the CS selector field. If SYSRET is returning to 64-bit mode, the CS selector is set to this field + 16. SS.Sel is set to this field + 8, regardless of the target mode. Because SYSRET always returns to CPL 3, the RPL bits 49:48 should be initialized to 11b. - SYSCALL CS and SS Selectors—Bits 47:32. This field is used to specify both the CS and SS selectors loaded into CS and SS during SYSCALL. This field is copied directly into CS.Sel. SS.Sel is set to this field + 8. Because SYSCALL always switches to CPL 0, the RPL bits 33:32 should be initialized to 00b." So I'm reading "SYSRET always returns to CPL3" and "SYSCALL always switches to CPL 0" as those are being enforced. And this is also mentioned in the SYSCALL/SYSRET documentation: "SYSCALL sets the CPL to 0, regardless of the values of bits 33:32 of the STAR register." and "SYSRET sets the CPL to 3, regardless of the values of bits 49:48 of the star register." BUT(!) "It is also assumed (but not checked) that the RPL of the SYSCALL and SYSRET target selectors are set to 0 and 3, respectively." > > > Not changing base or limit is no big deal, but not changing attributes > > could be the problem. It might be leaving the "64-bit stack" > > attribute set, for whatever that means. > > Hmm. I don't know if I believe that explanation. For one thing, the > APM says "Executing SYSRET in non-64-bit mode or with a 16- or 32-bit > operand size returns to 32-bit mode with a 32-bit stack pointer." > > We can revert this patch or fix it, but I'd like to at least try to > understand what's wrong first. Borislav, any ideas? Right, so according to the documentation, SYSRET does load SS from MSR_STAR[63:48] and forces the RPL bits [49:48] to 3. So if we really do have a bad %ss, then something is changing it in MSR_STAR. But that sounds really far-fetched and implausible so it must be something else. /me scratches head... -- 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/
[PATCH] xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM
Make sure that xen_swiotlb_init allocates buffers that are DMA capable
when at least one memblock is available below 4G. Otherwise we assume
that all devices on the SoC can cope with >4G addresses.
No functional changes on x86.
From: Chen Baozi
Signed-off-by: Chen Baozi
Signed-off-by: Stefano Stabellini
Tested-by: Chen Baozi
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 2f7e6ff..0b579b2 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -110,5 +110,6 @@ static inline bool set_phys_to_machine(unsigned long pfn,
unsigned long mfn)
bool xen_arch_need_swiotlb(struct device *dev,
unsigned long pfn,
unsigned long mfn);
+unsigned long xen_get_swiotlb_free_pages(unsigned int order);
#endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 793551d..4983250 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,6 +22,20 @@
#include
#include
+unsigned long xen_get_swiotlb_free_pages(unsigned int order)
+{
+ struct memblock_region *reg;
+ gfp_t flags = __GFP_NOWARN;
+
+ for_each_memblock(memory, reg) {
+ if (reg->base < (phys_addr_t)0x) {
+ flags |= __GFP_DMA;
+ break;
+ }
+ }
+ return __get_free_pages(flags, order);
+}
+
enum dma_cache_op {
DMA_UNMAP,
DMA_MAP,
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 358dcd3..c44a5d5 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -269,4 +269,9 @@ static inline bool xen_arch_need_swiotlb(struct device *dev,
return false;
}
+static inline unsigned long xen_get_swiotlb_free_pages(unsigned int order)
+{
+ return __get_free_pages(__GFP_NOWARN, order);
+}
+
#endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..4c54932 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -235,7 +235,7 @@ retry:
#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN, order);
+ xen_io_tlb_start = (void
*)xen_get_swiotlb_free_pages(order);
if (xen_io_tlb_start)
break;
order--;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
On Wed, Apr 22, 2015 at 09:11:17AM -0700, James Bottomley wrote:
> On Wed, 2015-04-22 at 17:46 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 22, 2015 at 08:35:54AM -0700, James Bottomley wrote:
> > > On Wed, 2015-04-15 at 15:19 +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Apr 15, 2015 at 11:32:29AM +, Kweh, Hock Leong wrote:
> > > > > > -Original Message-
> > > > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > > > > Sent: Tuesday, April 14, 2015 10:09 PM
> > > > > >
> > > > > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > > > > > + */
> > > > > > > +static void __exit efi_capsule_loader_exit(void)
> > > > > > > +{
> > > > > > > + platform_device_unregister(efi_capsule_pdev);
> > > > > >
> > > > > > This is not a platform device, don't abuse that interface please.
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Okay, so you would recommend to use device_register() for this case?
> > > > > Or you would think that this is more suitable to use class_register()?
> > > >
> > > > A class isn't needed, you just want a device right? So just use a
> > > > device, but not a platform device, as that isn't what you have here.
> > >
> > > Coming back to this, am I the only one confused here? What is a
> > > 'platform device' then? Because if it doesn't fit a direct channel to
> > > the platform firmware, which seems to be one of the definitions covered
> > > in driver-model/platform.txt under devices with minimal infrastructure
> > > then perhaps the documentation needs updating.
> >
> > I don't remember the original code here at all, sorry. I'm guessing
> > that they were using a class, and a platform device together, which is
> > not a good idea. Just make a "virtual" device, as you don't need/want
> > any of the platform device infrastructure here, you just wanted a device
> > node and/or a way to show up in sysfs somewhere.
>
> It was a platform device called efi_platform_loader and a single
> attribute file in that device called capsule_load. I agree that if
> we're going to use this for other things, we should probably have a uefi
> directory somewhere (under firmware?) to collect everything together
> rather than spraying random devices around.
>
> > If you have some kind of "platform resource", then you can be a platform
> > device, otherwise please don't use that api just because it seems simple
> > to use. Use the ones the driver core provides for you that really are
> > just as simple (i.e. device_create()).
>
> OK, so this is what I'm trying to understand. Why isn't a pipe to
> firmware for something a "platform resource"? I think UEFI is in the
> same class as ACPI which uses platform devices all over.
And I hate the fact that ACPI did that, but that ship has sailed a long
time ago. It "should" have been it's own bus and device type, but oh
well.
For a "simple" bus-less device, that has no platform resources needed
(i.e from acpi or device tree), so you don't need the infrastructure
from the platform core, just use a simple device_create() call, that's
what it is there for.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support
Hi Magnus,
On Thu, Apr 23, 2015 at 10:10 AM, Magnus Damm wrote:
> On Wed, Apr 22, 2015 at 2:56 AM, Geert Uytterhoeven
> wrote:
>> On Tue, Apr 21, 2015 at 5:01 PM, Magnus Damm wrote:
>>> These patches attempt to convert the IRQC driver from using a mix of clock
>>> framework and Runtime PM into only using Runtime PM and doing that in a
>>> more fine grained way than before. With these patches in place, if there
>>> is no interrupt used then the clock and/or power domain will not be used.
>>>
>>> Basic operation is that With these patches applied ->irq_enable() will
>>> perform Runtime PM 'get sync' and ->irq_disable() simply performs
>>> Runtime PM 'put'. The trigger mode callback is assumed to happen at any
>>> time so there is a get/put wrapper there.
>>>
>>> Unless I'm misunderstanding the IRQ core code this means that the IRQC
>>> struct device will be in Runtime PM 'get sync' state after someone has
>>> started using an interrupt.
>>
>> I'm afraid you can't call pm_runtime_get_sync() from these methods, as
>> they may be called from interrupt context.
>
> Ouch. I know the clock framework has prepare/enable separated with
> context, but with the irqchip callbacks I suppose no such separation
It's not the clock operations, but the pm_runtime operations that cannot be
called from interrupt context.
> is made...? Maybe it makes more sense to do power management from the
> online/offline hooks?
Which online/offline hooks do you mean?
>> BTW, I ran into similar issues with rcar-gpio, when trying to improve its
>> Runtime PM handling (still have to finish my WIP).
>
> Yeah, the IRQC and GPIO interrupt bits should be pretty much the same.
> I considered IRQC to be a simpler test case, but I guess it is may be
> more complicated due to lack of wakeup sources.
>
>> On r8a73a4/ape6evm, I now get during boot:
[snip]
> Thanks, this looks troublesome. =) I can see it is on APE6EVM, but
> which patches are applied?
I can reproduce it on renesas-drivers-2015-04-20-v4.0 with just your 3 patches.
I was using my own .config.
With shmobile_defconfig + CONFIG_PROVE_LOCKING=y I see a different one:
[ INFO: inconsistent lock state ]
4.0.0-10356-g7156f022c08bb358 #231 Not tainted
-
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
swapper/0/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&irq_desc_lock_class){?.-...}, at: [] __irq_get_desc_lock+0x78/0x94
{IN-HARDIRQ-W} state was registered at:
[] lock_acquire+0x74/0x94
[] _raw_spin_lock+0x34/0x44
[] handle_fasteoi_irq+0x20/0x128
[] generic_handle_irq+0x28/0x38
[] __handle_domain_irq+0x94/0xbc
[] gic_handle_irq+0x40/0x64
[] __irq_svc+0x44/0x5c
[] _raw_spin_unlock_irqrestore+0x48/0x4c
[] prepare_to_wait_event+0xd8/0xe8
[] sh_mobile_i2c_xfer+0x338/0x4f4
[] __i2c_transfer+0x1d0/0x220
[] i2c_transfer+0x7c/0xa0
[] regmap_i2c_read+0x50/0x6c
[] _regmap_raw_read+0x9c/0xd4
[] _regmap_bus_read+0x2c/0x58
[] _regmap_read+0xa4/0xe0
[] regmap_read+0x48/0x68
[] max8973_dcdc_get_voltage_sel+0x28/0x5c
[] regulator_attr_is_visible+0x90/0x238
[] internal_create_group+0x13c/0x254
[] sysfs_create_group+0x18/0x1c
[] sysfs_create_groups+0x3c/0x68
[] device_add+0x224/0x514
[] device_register+0x1c/0x20
[] regulator_register+0x290/0xd0c
[] devm_regulator_register+0x3c/0x78
[] max8973_probe+0x3b8/0x430
[] i2c_device_probe+0xf8/0x120
[] driver_probe_device+0x100/0x268
[] __device_attach+0x30/0x4c
[] bus_for_each_drv+0x8c/0x9c
[] device_attach+0x70/0x94
[] bus_probe_device+0x30/0xa4
[] device_add+0x3fc/0x514
[] device_register+0x1c/0x20
[] i2c_new_device+0x12c/0x1a0
[] i2c_register_adapter+0x2f0/0x408
[] i2c_add_adapter+0x90/0xa8
[] i2c_add_numbered_adapter+0x1c/0x28
[] sh_mobile_i2c_probe+0x3c0/0x454
[] platform_drv_probe+0x50/0xa0
[] driver_probe_device+0x100/0x268
[] __driver_attach+0x78/0x9c
[] bus_for_each_dev+0x74/0x98
[] driver_attach+0x20/0x28
[] bus_add_driver+0xdc/0x1c4
[] driver_register+0xa4/0xe8
[] __platform_driver_register+0x50/0x64
[] sh_mobile_i2c_adap_init+0x18/0x20
[] do_one_initcall+0x108/0x1bc
[] kernel_init_freeable+0x11c/0x1e4
[] kernel_init+0x10/0xec
[] ret_from_fork+0x14/0x24
irq event stamp: 162248
hardirqs last enabled at (162247): []
__mutex_unlock_slowpath+0x174/0x198
hardirqs last disabled at (162248): []
_raw_spin_lock_irqsave+0x24/0x58
softirqs last enabled at (160452): [] __do_softirq+0x204/0x29c
softirqs last disabled at (160443): [] irq_exit+0x8c/0x118
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
3 locks held by swapper/0/1:
#0: (&dev->mutex){..}, at: [] __driver_attach+0x3c/0x9c
#1: (&dev->mutex){..}, at: [] __driver_attach+0x60/0x9c
#2: (&irq_desc_lock_class){?.-...}, at: []
__irq_get_desc_lock+0x78/0x94
stack backtrace:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-10356
Re: [PATCH] xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM
On 23/04/15 10:47, Stefano Stabellini wrote:
> Make sure that xen_swiotlb_init allocates buffers that are DMA capable
> when at least one memblock is available below 4G. Otherwise we assume
> that all devices on the SoC can cope with >4G addresses.
This commit message must explain why the PFNs (IPAs) are relevant for DMA.
David
> No functional changes on x86.
>
> From: Chen Baozi
>
> Signed-off-by: Chen Baozi
> Signed-off-by: Stefano Stabellini
> Tested-by: Chen Baozi
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 2f7e6ff..0b579b2 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -110,5 +110,6 @@ static inline bool set_phys_to_machine(unsigned long pfn,
> unsigned long mfn)
> bool xen_arch_need_swiotlb(struct device *dev,
> unsigned long pfn,
> unsigned long mfn);
> +unsigned long xen_get_swiotlb_free_pages(unsigned int order);
>
> #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 793551d..4983250 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -21,6 +22,20 @@
> #include
> #include
>
> +unsigned long xen_get_swiotlb_free_pages(unsigned int order)
> +{
> + struct memblock_region *reg;
> + gfp_t flags = __GFP_NOWARN;
> +
> + for_each_memblock(memory, reg) {
> + if (reg->base < (phys_addr_t)0x) {
> + flags |= __GFP_DMA;
> + break;
> + }
> + }
> + return __get_free_pages(flags, order);
> +}
> +
> enum dma_cache_op {
> DMA_UNMAP,
> DMA_MAP,
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 358dcd3..c44a5d5 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -269,4 +269,9 @@ static inline bool xen_arch_need_swiotlb(struct device
> *dev,
> return false;
> }
>
> +static inline unsigned long xen_get_swiotlb_free_pages(unsigned int order)
> +{
> + return __get_free_pages(__GFP_NOWARN, order);
> +}
> +
> #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 810ad41..4c54932 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -235,7 +235,7 @@ retry:
> #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
> while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
> - xen_io_tlb_start = (void
> *)__get_free_pages(__GFP_NOWARN, order);
> + xen_io_tlb_start = (void
> *)xen_get_swiotlb_free_pages(order);
> if (xen_io_tlb_start)
> break;
> order--;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/10] KVM: arm: guest debug, define API headers
Christoffer Dall writes:
> On Tue, Mar 31, 2015 at 04:08:01PM +0100, Alex Bennée wrote:
>> This commit defines the API headers for guest debugging. There are two
>> architecture specific debug structures:
>>
>> - kvm_guest_debug_arch, allows us to pass in HW debug registers
>> - kvm_debug_exit_arch, signals the exact debug exit and pc
>>
>> The type of debugging being used is control by the architecture specific
>> control bits of the kvm_guest_debug->control flags in the ioctl
>> structure.
>>
>> Signed-off-by: Alex Bennée
>>
>> ---
>> v2
>>- expose hsr and pc directly to user-space
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h
>> b/arch/arm64/include/uapi/asm/kvm.h
>> index 3ef77a4..6ee70a0 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -100,10 +100,24 @@ struct kvm_sregs {
>> struct kvm_fpu {
>> };
>>
>> +/*
>> + * See ARM ARM D7.3: Debug Registers
>
> see the ARM ARM for ??
>
>> + *
>> + * The control registers are architecturally defined as 32 bits but are
>> + * stored as 64 bit values along side the value registers and aligned
>
> do you mean alongside?
sure.
>
>> + * with the rest 64 bit registers in the normal CPU context.
>
> rest of the 64 bit
>
>> + */
>
> why do we store them as 64 bit values? There's nothing prevented us
> from defining them as __u32 is there? Is this to make the ONE_REG
> interface accessers more convenient?
No but it will involve more fiddling when we copy them into the CPU
context which keeps everything as 64 bit aligned. Of course if we want
to remove the debug registers from the context and put a pointer in
place then this is fairly moot as we will need to change the hyp.S code
that copies the registers during the world switch. I was trying to
minimise the amount of change to the assembler in this series.
>
>> +#define KVM_ARM_NDBG_REGS 16
>
> nit: is NDBG short for something I don't know about or is it
> the number of debug registers we are noting here, in which case I think
> KVM_ARM_NUM_DBG_REGS is more clear.
OK.
>
>> struct kvm_guest_debug_arch {
>> +__u64 dbg_bcr[KVM_ARM_NDBG_REGS];
>> +__u64 dbg_bvr[KVM_ARM_NDBG_REGS];
>> +__u64 dbg_wcr[KVM_ARM_NDBG_REGS];
>> +__u64 dbg_wvr[KVM_ARM_NDBG_REGS];
>> };
>>
>> struct kvm_debug_exit_arch {
>> +__u64 pc;
>> +__u32 hsr;
>> };
>>
>> struct kvm_sync_regs {
>> @@ -207,4 +221,11 @@ struct kvm_arch_memory_slot {
>>
>> #endif
>>
>> +/*
>> + * Architecture related debug defines - upper 16 bits of
>> + * kvm_guest_debug->control
>> + */
>> +#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
>> +#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
>> +
>> #endif /* __ARM_KVM_H__ */
>> --
>> 2.3.4
>>
>
> Thanks,
> -Christoffer
--
Alex Bennée
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Thu, Apr 23, 2015 at 11:20:56AM +0200, Denys Vlasenko wrote: > * what if %ss before syscall was NOT the usual value of 0x2b, but some > other segment, not the typical 0-base, 0x limit 32-bit expand-up one? > Not restoring proper %ss would not go well. > [but then, Intel CPUs work, and old code worked] Have we run the exact same reproducer on Intel already? Brian, can you run the same thing on an Intel box, if you haven't done so already? Thanks. -- 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/
Re: [PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size
On Wed, Apr 22 2015, Gavin Guo wrote:
> /*
> + * The kmalloc_names is for temporary usage to make
> + * slub_debug=,kmalloc-xx option work in the boot time. The
> + * kmalloc_index() support to 2^26=64MB. So, the final entry of the
> + * table is kmalloc-67108864.
> + */
> + static const char *kmalloc_names[] = {
The array itself could be const, but more importantly it should be
marked __initconst so that the 27*sizeof(char*) bytes can be released after
init.
> + "0","kmalloc-96", "kmalloc-192",
> + "kmalloc-8","kmalloc-16", "kmalloc-32",
> + "kmalloc-64", "kmalloc-128", "kmalloc-256",
> + "kmalloc-512", "kmalloc-1024", "kmalloc-2048",
> + "kmalloc-4196", "kmalloc-8192", "kmalloc-16384",
"kmalloc-4096"
> + "kmalloc-32768","kmalloc-65536",
> + "kmalloc-131072", "kmalloc-262144",
> + "kmalloc-524288", "kmalloc-1048576",
> + "kmalloc-2097152", "kmalloc-4194304",
> + "kmalloc-8388608", "kmalloc-16777216",
> + "kmalloc-33554432", "kmalloc-67108864"
> + };
On Wed, Apr 22 2015, Andrew Morton wrote:
> You could do something like
>
> kmalloc_caches[i] = create_kmalloc_cache(
> kmalloc_names[i],
> kstrtoul(kmalloc_names[i] + 8),
> flags);
>
> here, and remove those weird "96" and "192" cases.
Eww. At least spell 8 as strlen("kmalloc-").
> Or if that's considered too messy, make it
>
> static const struct {
> const char *name;
> unsigned size;
> } kmalloc_cache_info[] = {
> { NULL, 0 },
> { "kmalloc-96", 96 },
> ...
> };
I'd vote for this color for the bikeshed :-)
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On 04/23/2015 10:49 AM, Andy Lutomirski wrote: > On Thu, Apr 23, 2015 at 12:37 AM, Brian Gerst wrote: >> On Tue, Mar 31, 2015 at 8:38 AM, tip-bot for Denys Vlasenko >> wrote: >>> Commit-ID: e7d6eefaaa443130079d73cd05039d90b3db7a4a >>> Gitweb: >>> http://git.kernel.org/tip/e7d6eefaaa443130079d73cd05039d90b3db7a4a >>> Author: Denys Vlasenko >>> AuthorDate: Fri, 27 Mar 2015 11:48:17 -0700 >>> Committer: Ingo Molnar >>> CommitDate: Tue, 31 Mar 2015 10:45:15 +0200 >>> >>> x86/vdso32/syscall.S: Do not load __USER32_DS to %ss >>> >>> This vDSO code only gets used by 64-bit kernels, not 32-bit ones. >>> >>> On 64-bit kernels, the data segment is the same for 32-bit and >>> 64-bit userspace, and the SYSRET instruction loads %ss with its >>> selector. >>> >>> So there's no need to repeat it by hand. Segment loads are somewhat >>> expensive: tens of cycles. >>> >>> Signed-off-by: Denys Vlasenko >>> [ Removed unnecessary comment. ] >>> Signed-off-by: Andy Lutomirski >>> Cc: Alexei Starovoitov >>> Cc: Andy Lutomirski >>> Cc: Borislav Petkov >>> Cc: Frederic Weisbecker >>> Cc: H. Peter Anvin >>> Cc: Kees Cook >>> Cc: Linus Torvalds >>> Cc: Oleg Nesterov >>> Cc: Steven Rostedt >>> Cc: Will Drewry >>> Link: >>> http://lkml.kernel.org/r/63da6d778f69fd0f1345d9287f6764d58be519fa.1427482099.git.l...@kernel.org >>> Signed-off-by: Ingo Molnar >>> --- >>> arch/x86/vdso/vdso32/syscall.S | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S >>> index 5415b56..6b286bb 100644 >>> --- a/arch/x86/vdso/vdso32/syscall.S >>> +++ b/arch/x86/vdso/vdso32/syscall.S >>> @@ -19,8 +19,6 @@ __kernel_vsyscall: >>> .Lpush_ebp: >>> movl%ecx, %ebp >>> syscall >>> - movl$__USER32_DS, %ecx >>> - movl%ecx, %ss >>> movl%ebp, %ecx >>> popl%ebp >>> .Lpop_ebp: >> >> This patch unfortunately is causing Wine to break on some applications: >> >> Unhandled exception: stack overflow in 32-bit code (0xf779bc07). >> Register dump: >> CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b >> EIP:f779bc07 ESP:00aed60c EBP:00aed750 EFLAGS:00010216( R- -- I -A-P- ) >> EAX:0040 EBX:0010 ECX:00aed750 EDX:0040 >> ESI:0040 EDI:7ffd4000 >> Stack dump: >> 0x00aed60c: 00aed648 f7575e5b 7bcc8000 >> 0x00aed61c: 7bc7bc09 0010 00aed750 0040 >> 0x00aed62c: 00aed750 00aed650 7bcc8000 7bc7bbdd >> 0x00aed63c: 7bcc8000 00aed6a0 00aed750 00aed738 >> 0x00aed64c: 7bc7cfa9 0011 00aed750 0040 >> 0x00aed65c: 0020 7bc4f141 >> Backtrace: >> =>0 0xf779bc07 __kernel_vsyscall+0x7() in [vdso].so (0x00aed750) >> 1 0xf7575e5b __libc_read+0x4a() in libpthread.so.0 (0x00aed648) >> 2 0x7bc7bc09 read_reply_data+0x38(buffer=0xaed750, size=0x40) >> [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/server.c:239] >> in ntdll (0x00aed648) >> 3 0x7bc7cfa9 wine_server_call+0x178() in ntdll (0x00aed738) >> 4 0x7bc840ec NtSetEvent+0x4b(handle=0x80, >> NumberOfThreadsReleased=0x0(nil)) >> [/home/bgerst/src/wine/wine32/dlls/ntdll/../../../dlls/ntdll/sync.c:361] >> in ntdll (0x00aed7c8) >> 5 0x7b874afa SetEvent+0x24(handle=) >> [/home/bgerst/src/wine/wine32/dlls/kernel32/../../../dlls/kernel32/sync.c:572] >> in kernel32 (0x00aed7e8) >> 6 0x0044e31a in battle.net launcher (+0x4e319) (0x00aed818) >> ... >> >> __kernel_vsyscall+0x7 points to "pop %ebp". >> >> This is on an AMD Phenom(tm) II X6 1055T Processor. >> >> It appears that there are some subtle differences in how sysretl works >> on AMD vs. Intel. According to the Intel docs, the SS selector and >> descriptor cache is completely reset by sysret to fixed values. The >> AMD docs however are concerning: > > My understanding is that, in long mode, the segment attributes are > ignored, and that there is no such thing as a "64-bit stack". So... > >> >> AMD's syscall: >> SS.sel = MSR_STAR.SYSCALL_CS + 8 >> SS.attr = 64-bit stack,dpl0 > > I don't really believe that. > >> SS.base = 0x >> SS.limit = 0x >> >> AMD's sysret: >> SS.sel = MSR_STAR.SYSRET_CS + 8 // SS selector is changed, >> // SS base, limit, attributes unchanged. >> > > I'm pretty sure that this is at least a little bit wrong. It makes no > sense for me for syscall to set SS.DPL=0 and for sysret to leave > SS.DPL=0. It had better at least change DPL to 3. (Except... don't > they mean RPL? Why is the DPL cached at all? But RPL is clearly > changed, since it's part of the selector.) > >> Not changing base or limit is no big deal, but not changing attributes >> could be the problem. It might be leaving the "64-bit stack" >> attribute set, for whatever that means. > > Hmm. I don't know if I believe that explanation. For one thing, the > APM says "Executing SYSRET in non-64-bit mode or with a 16- or 32-bit > operand size returns to 32-bit mode with a 32-bit stack pointer." > > We ca
[PATCH] linux/slab.h: fix three off-by-one typos in comment
The first is a keyboard-off-by-one, the other two the ordinary mathy
kind.
Signed-off-by: Rasmus Villemoes
---
include/linux/slab.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index ffd24c830151..a99f0e5243e1 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -240,8 +240,8 @@ extern struct kmem_cache
*kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1];
* belongs to.
* 0 = zero alloc
* 1 = 65 .. 96 bytes
- * 2 = 120 .. 192 bytes
- * n = 2^(n-1) .. 2^n -1
+ * 2 = 129 .. 192 bytes
+ * n = 2^(n-1)+1 .. 2^n
*/
static __always_inline int kmalloc_index(size_t size)
{
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Thunderbolt hotplug not working on MacMini7,1
Hi Adam,
On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
controller both use 0x1547 and are only differentiated by
subvendor/subdevice.
0x156c is the 4 channel TB2 controller and was originally added by
Matthew. Judging from his patch it looks like the subvendor/subdevice
is set on his system:
http://patchwork.ozlabs.org/patch/354626/
But it also indicates that the bridges already use different ids. If
that is the case then we can drop the subvendor/subdevice for 0x156c.
Matthew can you confirm that on your system 0x156c is used only for
the controller?
Adam, could you check that suspend/resume works properly? Also your
bugzilla report suggest that hotplug might now work without the
driver. Could you try to revert the _OSI check (and disable the
driver) and check whether everything "just works"?
Andreas
On Thu, Apr 23, 2015 at 4:56 AM, Adam Goode wrote:
> On Wed, Apr 22, 2015 at 12:05 AM, Adam Goode wrote:
>> (resending in plain text)
>> (please CC me on replies, I am not on LKML)
>>
>> Hi,
>>
>> I have a new Mac Mini (MacMini7,1). This model supports hotplugging of
>> Thunderbolt on Windows 8 and above. Unfortunately hotplug does not
>> seem to be working for me under Linux. I get the default behavior of
>> devices only working if plugged in during boot.
>>
>> Also, the changes made to support Darwin for _OSI seems to make it
>> impossible to override. This makes it hard to test if the ACPI support
>> for Windows 2012 will just work on Linux. I have not built a kernel
>> yet with Darwin _OSI patched out.
>>
>> Any ideas? I think there are 2 ways forward:
>>
>> 1. Fix the thunderbolt code to work with this new Mac.
>> 2. Limit the Darwin _OSI response to a whitelisted set of Mac
>> machines. It seems like new Macs going forward may work best with the
>> standard Windows 2012 response. I don't know if this method would have
>> advantages over #1. The obvious change might be chained hotplugging
>> support. I don't have a chained device to test.
>>
>
> I have fixed the issue on my machine. On the Mac Mini, the 0x156c
> device has no subvendor or subdevice. When I added the new id to
> nhi_ids, everything worked without changing anything else in the
> kernel. This is in the _OSI("Darwin").
>
> Perhaps the driver is overmatching on subvendor/subdevice. Is it
> necessary to do so on some models?
>
> Can PCI_ANY_ID just be used for subvendor/subdevice?
>
>
> Thanks,
>
> Adam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] vfs part 2
On 04/15/2015 09:14 PM, Al Viro wrote: > 9p: switch p9_client_write() to passing it struct iov_iter * Hi Al, This change caused following: [ 91.637917] == [ 91.639252] BUG: KASan: out of bounds on stack in iov_iter_advance+0x3e4/0x4b0 at addr 8800ba1efd20 [ 91.640979] Read of size 8 by task trinity-c15/4746 [ 91.641493] page:ea0002e87bc0 count:0 mapcount:0 mapping: (null) index:0x0 [ 91.641787] flags: 0x100() [ 91.641787] page dumped because: kasan: bad access detected [ 91.641787] CPU: 1 PID: 4746 Comm: trinity-c15 Not tainted 4.0.0+ #319 [ 91.641787] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 91.641787] 8800ba1efd08 8800ba1ef918 81ab94ed 1d40005d0f7f [ 91.641787] 8800ba1ef9b0 8800ba1ef998 812bc0f4 814901f0 [ 91.641787] 8800ba1efa40 0296 8801f4993490 81228fe0 [ 91.641787] Call Trace: [ 91.641787] dump_stack (lib/dump_stack.c:52) [ 91.641787] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193) [ 91.641787] ? idr_mark_full (lib/idr.c:551) [ 91.641787] ? clear_exceptional_entry (mm/truncate.c:561) [ 91.641787] __asan_report_load8_noabort (mm/kasan/report.c:251) [ 91.641787] ? iov_iter_advance (lib/iov_iter.c:511) [ 91.641787] iov_iter_advance (lib/iov_iter.c:511) [ 91.641787] p9_client_write (net/9p/client.c:1656) [ 91.641787] ? p9_client_readdir (net/9p/client.c:1614) [ 91.641787] ? kasan_kmalloc (mm/kasan/kasan.c:355) [ 91.641787] ? __kmalloc (mm/slub.c:3325) [ 91.641787] ? p9_client_readdir (net/9p/client.c:1614) [ 91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405) [ 91.641787] v9fs_file_write_iter (fs/9p/vfs_file.c:421) [ 91.641787] ? __sb_end_write (fs/super.c:1192) [ 91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405) [ 91.641787] ? do_readv_writev (fs/read_write.c:776) [ 91.641787] ? recalc_sigpending (kernel/signal.c:160) [ 91.641787] ? __set_task_blocked (kernel/signal.c:2514) [ 91.641787] __vfs_write (fs/read_write.c:479 fs/read_write.c:490) [ 91.641787] ? recalc_sigpending (kernel/signal.c:160) [ 91.641787] ? __vfs_read (fs/read_write.c:486) [ 91.641787] ? __sb_end_write (fs/super.c:1192) [ 91.641787] ? signal_setup_done (kernel/signal.c:2556) [ 91.641787] ? hrtimer_start (kernel/time/hrtimer.c:1043) [ 91.641787] ? do_setitimer (kernel/time/itimer.c:222) [ 91.641787] vfs_write (include/linux/fs.h:1984 include/linux/fs.h:2416 fs/read_write.c:543) [ 91.641787] SyS_write (fs/read_write.c:585 fs/read_write.c:576) [ 91.641787] ? SyS_read (fs/read_write.c:576) [ 91.641787] ? init_fpu (arch/x86/kernel/i387.c:231 arch/x86/kernel/i387.c:266) [ 91.641787] ? math_state_restore (arch/x86/kernel/traps.c:869) [ 91.641787] system_call_fastpath (arch/x86/kernel/entry_64.S:261) [ 91.641787] Memory state around the buggy address: [ 91.641787] 8800ba1efc00: f2 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f3 f3 f3 [ 91.641787] 8800ba1efc80: f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 [ 91.641787] >8800ba1efd00: f1 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 [ 91.641787]^ [ 91.641787] 8800ba1efd80: f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 [ 91.641787] 8800ba1efe00: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 91.641787] == This could happen when p9pdu_readf() changes 'count' to some value > iov_iter_count(from): p9_client_write(): <...> int count = iov_iter_count(from); <...> *err = p9pdu_readf(req->rc, clnt->proto_version, "d", &count); <...> iov_iter_advance(from, count); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/23/2015 03:00 AM, Nishanth Menon wrote: > On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: >> Hi, >> >> On 04/21/2015 03:51 AM, Nishanth Menon wrote: >>> Alarm interrupt enable register is at offset 0x7, while the time >>> registers for the alarm follow that. When we program Alarm interrupt >>> enable prior to programming the time, it is possible that previous >>> time value could be close or match at the time of alarm enable >>> resulting in interrupt trigger which is unexpected (and does not match >>> the time we expect it to trigger). >>> >>> To prevent this scenario from occuring, program the ALM0_EN bit only >>> after the alarm time is appropriately programmed. >>> >>> Ofcourse, I2C programming is non-atomic, so there are loopholes where >>> the interrupt wont trigger if the time requested is in the past at >>> the time of programming the ALM0_EN bit. However, we will not have >>> unexpected interrupts while the time is programmed after the interrupt >>> are enabled. >> >> I think it will be nice if you will mention that you going to follow >> vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family >> http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf >> ;) >> "Also, it is recommended that the alarm registers be loaded >> before the alarm is enabled." >> > > Hmm... i did not know that existed, thanks for digging it up.. that > teaches me to look for docs before putting a scope/LA on the board > (not that I regret doing that)... That said, reading the app note, I > kind of realized: > a) that playing with ST bit for programming time is not done, but > then, that implies that oscillator will have to be restarted (upto a > few seconds for certain crystals).. but that said, it does not seem > mandatory or seem to (yet seen) functional issues... > > b) We dont have flexibility yet to describe if we do indeed have a > backup battery or not - VBATEN should be set only if we have a backup > battery on the platform :( - on some it might even be optional thanks > to certain compliance requirements of shipping boards internationally > and general "unlike" of lithium ion in cargo hold.. > > c) we dont have capability to control the alarm polarity in the driver > which, by the way, we probably should also control OUT polarity (when > ALARM is not asserted).. > > d) we dont have support for external 32k oscillator(X1 only) instead > of assuming we always have a 32k crystal(X1 and X2)... > > Ugghhh... more cleaning up to do for the future.. > > that said, the sequence it does recommend (in page 4): > The following steps show how the Alarm 0 is config- > ured. Alarm 1 can be configured in the same manner. > 1.Write 0x23 to the Alarm0 Seconds register > [0x0A]. > 2.Write 0x47 to the Alarm0 Minutes register > [0x0B]. > 3.Write 0x71 to the Alarm0 Hours register [0x0C] > – 11 hours in 12-hour format. > 4.Write 0x72 to the Alarm0 Day register [0x0D] – > Tuesday + Alarm Polarity Low + Match on all. > The Alarm0 Interrupt Flag is also cleared. > 5.Write 0x14 to the Alarm0 Date register [0x0E]. > 6.Write 0x08 to the Alarm0 Month register [0x0F]. > With all the Alarm0 registers set we can now activate > the Alarm0 on the Control register. > 7.Write 0x10 to the Control register [0x07] – > Alarm0 enabled no CLKOUT, Alarm1 disabled > > before this patch we do ( http://pastebin.ubuntu.com/10863880/) > CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) > OSCTRIM r[8] = 0x00 > EEUNLOCK r[9] = 0x00 > ALM0SEC r[A] = 0x01 > ALM0MIN r[B] = 0x45 > ALM0HOUR r[C] = 0x23 > ALM0WKDAY r[D] = 0x75 <-ALMOIF is cleared > ALM0DATE r[E] = 0x09 > ALM0MTH r[F] = 0x04 > RSRVED r[10] = 0x01 > > with this patch, we do: > burst(CONTROL r[7] = 0x80 (OUT=1) > OSCTRIM r[8] = 0x00 > EEUNLOCK r[9] = 0x00 > ALM0SEC r[A] = 0x01 > ALM0MIN r[B] = 0x45 > ALM0HOUR r[C] = 0x23 > ALM0WKDAY r[D] = 0x75 <-ALMOIF is cleared > ALM0DATE r[E] = 0x09 > ALM0MTH r[F] = 0x04 > RSRVED r[10] = 0x01 > ) > CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) > > Which is slightly unoptimal way of what the app note recommends. - as > I mentioned earlier in this thread, I will try and do optimizations in > a later patch. > > Given that Andrew had picked up this patch, I dont see a reason to > respin this yet. but will include the app note for future patches - > thanks for pointing it out to me. ^^ Up to you. Np, Always yours! >>> >>> Signed-off-by: Nishanth Menon >>> --- >>> Changes in v2: >>> - minor typo fix in comments >>> - merged up code that I missed committing in >>> >>> V1: https://patchwork.kernel.org/patch/6245041/ >>> >>>drivers/rtc/rtc-ds1307.c | 12 ++-- >>>1 file changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c >>> index 4ffabb322a9a..3cd4783375a5 100644 >>> --- a/drivers/rtc/rtc-ds1307.c >>> +++ b/drive
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On Thu, Apr 23, 2015 at 11:56:21AM +0200, Denys Vlasenko wrote: > The fix can look like this (untested): > > > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S > index 0c302d0..9f4c232 100644 > --- a/arch/x86/ia32/ia32entry.S > +++ b/arch/x86/ia32/ia32entry.S > @@ -198,6 +198,18 @@ sysexit_from_sys_call: >* with 'sysenter' and it uses the SYSENTER calling convention. >*/ > andl$~TS_COMPAT,ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) > + /* > + * On AMD, SYSRET32 does not modify %ss cached descriptor; Ok, but doc says that in both long and compat mode, SYSRET does load SS.sel with the value in MSR_STAR... Hmmm. -- 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/
Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
On 04/23/2015 12:18 PM, Borislav Petkov wrote: > On Thu, Apr 23, 2015 at 11:56:21AM +0200, Denys Vlasenko wrote: >> The fix can look like this (untested): >> >> >> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S >> index 0c302d0..9f4c232 100644 >> --- a/arch/x86/ia32/ia32entry.S >> +++ b/arch/x86/ia32/ia32entry.S >> @@ -198,6 +198,18 @@ sysexit_from_sys_call: >> * with 'sysenter' and it uses the SYSENTER calling convention. >> */ >> andl$~TS_COMPAT,ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) >> +/* >> + * On AMD, SYSRET32 does not modify %ss cached descriptor; > > Ok, but doc says that in both long and compat mode, SYSRET does load > SS.sel with the value in MSR_STAR... Yes. It loads *selector*. AMD docs say that selector is loaded as you say, but *cached descriptor* of SS (which is a different entity) is not modified. If *cached descriptor* is invalid, in 32-bit mode stack ops will fail. (In 64-bit mode, CPU doesn't do those checks). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
