Re: [PATCH] [RFC] Taint the kernel for unsafe module options
On Thu, Mar 06, 2014 at 11:19:54AM +1030, Rusty Russell wrote: > Daniel Vetter writes: > > Users just love to set random piles of options since surely enabling > > all the experimental stuff helps. Later on we get bug reports because > > it all fell apart. > > > > Even more fun when it's labelled a regression when some change only > > just made the feature possible (e.g. stolen memory fixes suddenly > > making fbc possible). > > > > Make it clear that users are playing with fire here. In drm/i915 all > > these options follow the same pattern of using -1 as the per-machine > > default, and any other value being used for force the parameter. > > > > Adding a pile of cc's to solicit input and figure out whether this > > would be generally useful - this quick rfc is just for drm/i915. > > If this is a good idea, you can write a macro module_param_unsafe_named > which is a general wrapper. For this to work I need to somehow store the safe default value somewhere. since with bools or strings there really isn't such a thing, even less than with integers where my fairly abitrary -1 choice is already restricting. But I don't have a good idea how to do that, since creating a local static struct in the macro to store the default + the pointer to the storage location feels a bit ugly. > > -module_param_named(modeset, i915.modeset, int, 0400); > > Wait, WTF? Why do you prefix i915 here manually? That means that > the commandline parameter would be "i915.i915.modeset=" and the > module parameter would be "i915.modeset="... Nope, this is the named macro. The name of the param is the first parameter to the macro "modeset", "i915.modeset" is just the variable it'll get stored in. We've specifically switched to the _named version to avoid ugly i915.i915* paramters ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/mm/stab.c: In function '__ste_allocate':
arch/powerpc/mm/stab.c:138:42: error: lvalue required as left operand of
assignment
__this_cpu_read(stab_cache[offset++]) = stab_entry;
^
In file included from include/linux/kernel_stat.h:8:0,
from kernel/softirq.c:14:
kernel/softirq.c: In function '__do_softirq':
include/linux/interrupt.h:328:57: error: lvalue required as left operand of
assignment
#define set_softirq_pending(x) (local_softirq_pending() = (x))
^
kernel/softirq.c:252:2: note: in expansion of macro 'set_softirq_pending'
set_softirq_pending(0);
^
kernel/softirq.c: In function '__raise_softirq_irqoff':
include/linux/interrupt.h:329:57: error: lvalue required as left operand of
assignment
#define or_softirq_pending(x) (local_softirq_pending() |= (x))
^
kernel/softirq.c:427:2: note: in expansion of macro 'or_softirq_pending'
or_softirq_pending(1UL << nr);
^
In file included from arch/powerpc/include/asm/time.h:18:0,
from arch/powerpc/include/asm/cputime.h:29,
from include/linux/sched.h:33,
from include/linux/ptrace.h:5,
from arch/powerpc/kernel/mce.c:26:
arch/powerpc/kernel/mce.c: In function 'save_mce_event':
include/linux/percpu.h:737:2: error: incompatible types when initializing type
'struct machine_check_event *' using type 'struct machine_check_event'
(__this_cpu_preempt_check("read"),__pcpu_size_call_return(raw_cpu_read_,
(pcp)))
^
arch/powerpc/kernel/mce.c:77:36: note: in expansion of macro '__this_cpu_read'
struct machine_check_event *mce = __this_cpu_read(mce_event[index]);
^
arch/powerpc/kernel/mce.c: In function 'get_mce_event':
arch/powerpc/kernel/mce.c:156:10: error: incompatible types when assigning to
type 'struct machine_check_event *' from type 'struct machine_check_event'
mc_evt = __this_cpu_read(mce_event[index]);
^
Caused by commits 1c55f79be84e ("powerpc: replace __get_cpu_var uses")
and 0884f89e7e08 ("powerpc: handle new __get_cpu_var calls in 3.14").
Someone should check the build results overnight ...
http://kisskb.ellerman.id.au/linux-next
I added the following patch:
From: Stephen Rothwell
Date: Thu, 6 Mar 2014 18:36:39 +1100
Subject: [PATCH] powerpc: replace __get_cpu_var uses fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/hardirq.h | 4
arch/powerpc/kernel/mce.c | 4 ++--
arch/powerpc/mm/stab.c | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hardirq.h
b/arch/powerpc/include/asm/hardirq.h
index 2e14594ccea4..f8c2a0e71f24 100644
--- a/arch/powerpc/include/asm/hardirq.h
+++ b/arch/powerpc/include/asm/hardirq.h
@@ -21,6 +21,10 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
#define __ARCH_IRQ_STAT
#define local_softirq_pending()
__this_cpu_read(irq_stat.__softirq_pending)
+#define set_softirq_pending(x) __this_cpu_write(irq_stat.__softirq_pending,
(x))
+#define or_softirq_pending(x) __this_cpu_or(irq_stat.__softirq_pending, (x))
+
+#define __ARCH_SET_SOFTIRQ_PENDING
static inline void ack_bad_irq(unsigned int irq)
{
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index a9bf88affe79..46da0810a03b 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -74,7 +74,7 @@ void save_mce_event(struct pt_regs *regs, long handled,
{
uint64_t srr1;
int index = __this_cpu_inc_return(mce_nest_count);
- struct machine_check_event *mce = __this_cpu_read(mce_event[index]);
+ struct machine_check_event *mce = this_cpu_ptr(&mce_event[index]);
/*
* Return if we don't have enough space to log mce event.
@@ -153,7 +153,7 @@ int get_mce_event(struct machine_check_event *mce, bool
release)
/* Check if we have MCE info to process. */
if (index < MAX_MC_EVT) {
- mc_evt = __this_cpu_read(mce_event[index]);
+ mc_evt = this_cpu_ptr(&mce_event[index]);
/* Copy the event structure and release the original */
if (mce)
*mce = *mc_evt;
diff --git a/arch/powerpc/mm/stab.c b/arch/powerpc/mm/stab.c
index ecbdc28554c6..db4483e95382 100644
--- a/arch/powerpc/mm/stab.c
+++ b/arch/powerpc/mm/stab.c
@@ -135,7 +135,7 @@ static int __ste_allocate(unsigned long ea, struct
mm_struct *mm)
if (!is_kernel_addr(ea)) {
offset = __this_cpu_read(stab_cache_ptr);
if (offset < NR_STAB_CACHE_ENTRIES)
- __this_cpu_read(stab_cache[offset++]) = stab_entry;
+ __this_cpu_write(stab_cache[offset++], stab_entry);
Re: [PATCH 7/7] staging: cxt1e1: remove unneeded a value
Ok.
I will use sizeof(name) for snprintf() call.
Thanks.
Daeseok Youn.
2014-03-06 16:33 GMT+09:00 Tobias Klauser :
> On 2014-03-06 at 08:19:19 +0100, DaeSeok Youn wrote:
>> 2014-03-05 19:13 GMT+09:00 Tobias Klauser :
>> > On 2014-03-05 at 02:24:22 +0100, Daeseok Youn
>> > wrote:
>> >>
>> >> It doesn't need to assign name array address to np pointer.
>> >>
>> >> Signed-off-by: Daeseok Youn
>> >> ---
>> >> drivers/staging/cxt1e1/linux.c |5 ++---
>> >> 1 files changed, 2 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/staging/cxt1e1/linux.c
>> >> b/drivers/staging/cxt1e1/linux.c
>> >> index 5bb42ae..cae8c66 100644
>> >> --- a/drivers/staging/cxt1e1/linux.c
>> >> +++ b/drivers/staging/cxt1e1/linux.c
>> >> @@ -205,15 +205,14 @@ status_t
>> >> c4_wq_port_init(mpi_t *pi)
>> >> {
>> >>
>> >> - charname[16], *np; /* NOTE: name of the queue limited by
>> >> system
>> >> + charname[16]; /* NOTE: name of the queue limited by system
>> >>* to 10 characters */
>> >>
>> >> if (pi->wq_port)
>> >> return 0; /* already initialized */
>> >>
>> >> - np = name;
>> >> memset(name, 0, 16);
>> >
>> > This isn't necessary since s{,n}printf() adds a terminating '\0'.
>> Yes, I have looked at lib/vsprintf.c. I found it adds null to a string
>> in the end of vsnprintf() function.
>> I will remove memset() line.
>>
>> >
>> >> - sprintf(np, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01)
>> >> */
>> >> + sprintf(name, "%s%d", pi->up->devname, pi->portnum); /* IE
>> >> pmcc4-01) */
>> >
>> > Better use snprintf() here, even if the comment above claims the name
>> > never to be no longer than 10 characters.
>> OK. I will replace sprintf with snprintf() and set a string length to "10".
>
> It's probably fine to leave the string at length 16 (since there's also
> a number appended to it) and the use sizeof(name) for the snprintf call.
>
> Cheers
> Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: tlv320aic23: add support for SPI control mode
tlv320aic23 chip control interface may work in either I2C or SPI mode
depending on the MODE pin state. Functionality and register layout are
independent of the control mode.
Provide i2c and spi driver entry points when CONFIG_I2C and
CONFIG_SPI_MASTER are enabled respectively.
Signed-off-by: Max Filippov
---
sound/soc/codecs/Kconfig | 2 +-
sound/soc/codecs/tlv320aic23.c | 58 +++---
2 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 983d087a..6d82de5 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -71,7 +71,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STA529 if I2C
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_TAS5086 if I2C
- select SND_SOC_TLV320AIC23 if I2C
+ select SND_SOC_TLV320AIC23 if SND_SOC_I2C_AND_SPI
select SND_SOC_TLV320AIC26 if SPI_MASTER
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
diff --git a/sound/soc/codecs/tlv320aic23.c b/sound/soc/codecs/tlv320aic23.c
index 5d430cc..2418260 100644
--- a/sound/soc/codecs/tlv320aic23.c
+++ b/sound/soc/codecs/tlv320aic23.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -617,12 +618,13 @@ static struct snd_soc_codec_driver
soc_codec_dev_tlv320aic23 = {
.num_dapm_routes = ARRAY_SIZE(tlv320aic23_intercon),
};
+#ifdef CONFIG_I2C
/*
* If the i2c layer weren't so broken, we could pass this kind of data
* around
*/
-static int tlv320aic23_codec_probe(struct i2c_client *i2c,
- const struct i2c_device_id *i2c_id)
+static int tlv320aic23_i2c_probe(struct i2c_client *i2c,
+const struct i2c_device_id *i2c_id)
{
struct aic23 *aic23;
int ret;
@@ -661,12 +663,62 @@ static struct i2c_driver tlv320aic23_i2c_driver = {
.driver = {
.name = "tlv320aic23-codec",
},
- .probe = tlv320aic23_codec_probe,
+ .probe = tlv320aic23_i2c_probe,
.remove = __exit_p(tlv320aic23_i2c_remove),
.id_table = tlv320aic23_id,
};
module_i2c_driver(tlv320aic23_i2c_driver);
+#endif /* CONFIG_I2C */
+
+#ifdef CONFIG_SPI_MASTER
+static int aic23_spi_probe(struct spi_device *spi)
+{
+ struct aic23 *aic23;
+ int ret;
+
+ dev_dbg(&spi->dev, "probing tlv320aic23 spi device\n");
+
+ spi->bits_per_word = 16;
+ spi->mode = SPI_MODE_0;
+ ret = spi_setup(spi);
+ if (ret < 0)
+ return ret;
+
+ /* Allocate driver data */
+ aic23 = devm_kzalloc(&spi->dev, sizeof(struct aic23), GFP_KERNEL);
+ if (!aic23)
+ return -ENOMEM;
+
+ aic23->regmap = devm_regmap_init_spi(spi, &tlv320aic23_regmap);
+ if (IS_ERR(aic23->regmap))
+ return PTR_ERR(aic23->regmap);
+
+ /* Initialize the driver data */
+ dev_set_drvdata(&spi->dev, aic23);
+
+ ret = snd_soc_register_codec(&spi->dev,
+ &soc_codec_dev_tlv320aic23, &tlv320aic23_dai, 1);
+ return ret;
+}
+
+static int aic23_spi_remove(struct spi_device *spi)
+{
+ snd_soc_unregister_codec(&spi->dev);
+ return 0;
+}
+
+static struct spi_driver aic23_spi = {
+ .driver = {
+ .name = "tlv320aic23",
+ .owner = THIS_MODULE,
+ },
+ .probe = aic23_spi_probe,
+ .remove = aic23_spi_remove,
+};
+
+module_spi_driver(aic23_spi);
+#endif /* CONFIG_SPI_MASTER */
MODULE_DESCRIPTION("ASoC TLV320AIC23 codec driver");
MODULE_AUTHOR("Arun KS ");
--
1.8.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 6/7] Cpuidle: Deal with timer expiring in the past
On Mon, Feb 24, 2014 at 1:29 AM, Tuukka Tikkanen wrote: > Sometimes (fairly often) when the cpuidle menu governor is making a decision > about idle state to enter the next timer for the cpu appears to expire in > the past. The menu governor expects the expiry to always be in the future > and in fact stores the time delta in an unsigned variable. However, when > the expiry is in the past, the value returned by tick_nohz_get_sleep_length > can be negative. This patch prevents using negative values, instead making > the governor return immediately similar to having latency requirement set > to 0. > > Note: As with latency == 0, the return value is 0 with no check to see if > the state 0 has been disabled or not. > > Signed-off-by: Tuukka Tikkanen > --- > drivers/cpuidle/governors/menu.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpuidle/governors/menu.c > b/drivers/cpuidle/governors/menu.c > index 71b5232..c414468 100644 > --- a/drivers/cpuidle/governors/menu.c > +++ b/drivers/cpuidle/governors/menu.c > @@ -302,8 +302,16 @@ static int menu_select(struct cpuidle_driver *drv, > struct cpuidle_device *dev) > if (unlikely(latency_req == 0)) > return 0; > > - /* determine the expected residency time, round up */ > + /* > +* Determine the expected residency time. If the time is negative, > +* a timer interrupt has probably just expired after disabling > +* interrupts. Return as quickly as possible in the most shallow > +* state possible. tv_nsec is always positive, so only check the > +* seconds. > +*/ > t = ktime_to_timespec(tick_nohz_get_sleep_length()); > + if (t.tv_sec < 0) > + return 0; > data->next_timer_us = > t.tv_sec * USEC_PER_SEC + t.tv_nsec / NSEC_PER_USEC; > Are there special conditions that are necessary to provoke a negative return value? I've traced this code on several systems, and never seen a negative return value. However... I do see values up to 300.2 seconds, and those large values seem to decay at the rate of real-time so that after 5 minutes they are small, and then jump back up to 300 seconds. Some folks at Oracle debugged it down to use of NEXT_TIMER_MAX_DELTA when there is _no_ timer currently pending on that CPU. It seems this is easier to observe, the more CPUs a system has -- though I've been able to reproduce it on a system as small as a single-package 8-cpu systems. One proposed way to address this is to cap large values at 1 second. However, that will not recognize that for the period when the large value decays to under 1 second, all of those are fiction. Also, if we could identify the case where there is no future timer, it seems that re-using dev->last_residency would probably be a more useful guess than pretending we'll have a timer expire in 1 second. thanks, Len Brown, Intel Open Source Technology Cente -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Staging: comedi: addi-data: tidy up watchdog register map defines in hwdrv_apci1564.c
This patch for hwdrv_apci1564.c fixes the register map defines for the
watchdog registers such that they are all the real offsets to each
register, rather than a mix of real offsets and adders to those offsets.
Additionally, the defines have been renamed to assist with shortening
some lines in excess of 80 characters.
Signed-off-by: Chase Southwood
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 48 --
1 file changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index d17c37b..91ca091 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -65,7 +65,6 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define ADDIDATA_TIMER 0
#define ADDIDATA_COUNTER 1
#define ADDIDATA_WATCHDOG 2
-#define APCI1564_DIGITAL_OP_WATCHDOG 0x28
#define APCI1564_TIMER 0x48
#define APCI1564_COUNTER1 0x0
#define APCI1564_COUNTER2 0x20
@@ -92,6 +91,14 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_DO_INT_CTRL_REG 0x1c
#define APCI1564_DO_INT_STATUS_REG 0x20
#define APCI1564_DO_IRQ_REG0x24
+#define APCI1564_WDOG_REG 0x28
+#define APCI1564_WDOG_RELOAD_REG 0x2c
+#define APCI1564_WDOG_TIMEBASE_REG 0x30
+#define APCI1564_WDOG_CTRL_REG 0x34
+#define APCI1564_WDOG_STATUS_REG 0x38
+#define APCI1564_WDOG_IRQ_REG 0x3c
+#define APCI1564_WDOG_WARN_TIMEVAL_REG 0x40
+#define APCI1564_WDOG_WARN_TIMEBASE_REG0x44
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
@@ -285,13 +292,9 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
devpriv->b_TimerSelectMode = ADDIDATA_WATCHDOG;
/* Disable the watchdog */
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP_WATCHDOG +
- APCI1564_TCW_PROG);
+ outl(0x0, devpriv->i_IobaseAmcc + APCI1564_WDOG_CTRL_REG);
/* Loading the Reload value */
- outl(data[3],
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP_WATCHDOG +
- APCI1564_TCW_RELOAD_VALUE);
+ outl(data[3], devpriv->i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
} else if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
ul_Command1 =
@@ -305,10 +308,7 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
outl(0x02, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* Enable TIMER int & DISABLE ALL THE OTHER int SOURCES */
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG);
- outl(0x0,
- devpriv->i_IobaseAmcc +
- APCI1564_DIGITAL_OP_WATCHDOG +
- APCI1564_TCW_IRQ);
+ outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_WDOG_IRQ_REG);
outl(0x0,
devpriv->iobase + APCI1564_COUNTER1 +
APCI1564_TCW_IRQ);
@@ -427,19 +427,14 @@ static int
i_APCI1564_StartStopWriteTimerCounterWatchdog(struct comedi_device *d
if (devpriv->b_TimerSelectMode == ADDIDATA_WATCHDOG) {
switch (data[1]) {
case 0: /* stop the watchdog */
- outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_DIGITAL_OP_WATCHDOG + APCI1564_TCW_PROG);/* disable the watchdog */
+ /* disable the watchdog */
+ outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_WDOG_CTRL_REG);
break;
case 1: /* start the watchdog */
- outl(0x0001,
- devpriv->i_IobaseAmcc +
- APCI1564_DIGITAL_OP_WATCHDOG +
- APCI1564_TCW_PROG);
+ outl(0x0001, devpriv->i_IobaseAmcc +
APCI1564_WDOG_CTRL_REG);
break;
case 2: /* Software trigger */
- outl(0x0201,
- devpriv->i_IobaseAmcc +
- APCI1564_DIGITAL_OP_WATCHDOG +
- APCI1564_TCW_P
Re: [PATCH 7/7] staging: cxt1e1: remove unneeded a value
On 2014-03-06 at 08:19:19 +0100, DaeSeok Youn wrote:
> 2014-03-05 19:13 GMT+09:00 Tobias Klauser :
> > On 2014-03-05 at 02:24:22 +0100, Daeseok Youn
> > wrote:
> >>
> >> It doesn't need to assign name array address to np pointer.
> >>
> >> Signed-off-by: Daeseok Youn
> >> ---
> >> drivers/staging/cxt1e1/linux.c |5 ++---
> >> 1 files changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/staging/cxt1e1/linux.c
> >> b/drivers/staging/cxt1e1/linux.c
> >> index 5bb42ae..cae8c66 100644
> >> --- a/drivers/staging/cxt1e1/linux.c
> >> +++ b/drivers/staging/cxt1e1/linux.c
> >> @@ -205,15 +205,14 @@ status_t
> >> c4_wq_port_init(mpi_t *pi)
> >> {
> >>
> >> - charname[16], *np; /* NOTE: name of the queue limited by
> >> system
> >> + charname[16]; /* NOTE: name of the queue limited by system
> >>* to 10 characters */
> >>
> >> if (pi->wq_port)
> >> return 0; /* already initialized */
> >>
> >> - np = name;
> >> memset(name, 0, 16);
> >
> > This isn't necessary since s{,n}printf() adds a terminating '\0'.
> Yes, I have looked at lib/vsprintf.c. I found it adds null to a string
> in the end of vsnprintf() function.
> I will remove memset() line.
>
> >
> >> - sprintf(np, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01) */
> >> + sprintf(name, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01)
> >> */
> >
> > Better use snprintf() here, even if the comment above claims the name
> > never to be no longer than 10 characters.
> OK. I will replace sprintf with snprintf() and set a string length to "10".
It's probably fine to leave the string at length 16 (since there's also
a number appended to it) and the use sizeof(name) for the snprintf call.
Cheers
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: usbip: userspace: increase version to 2.0
On Wed, Mar 5, 2014 at 10:14 PM, Valentina Manea wrote: > On Tue, Mar 4, 2014 at 9:20 PM, Greg KH wrote: >> On Tue, Mar 04, 2014 at 09:16:39PM +0200, Valentina Manea wrote: >>> -AC_INIT([usbip-utils], [1.1.1], [linux-...@vger.kernel.org]) >>> +AC_INIT([usbip-utils], [2.0], [linux-...@vger.kernel.org]) >> >> Why? >> >> What does this mean? What warrents the version change? Why have a >> version at all? > > This was part of an effort to "refresh" USB/IP by moving userspace out > of kernel.git. > Since some major changes have been made (libudev migration), Andy (cc'ed) and > me > thought it was worth to be promoted to version 2.0. (sorry, resending in plain text mode so vger doesn't bounce (curse you gmail :-)) Valentina did considerable work in moving usbip-utils from using the defunct libsysfs to libudev (well, part of systemd now it seems.) so some version bump seems appropriate, why not to 2.0? esp. as a heads-up to pkg maintainers - btw usbip-utils is already packaged for Debian, and I could probably see it in Fedora too, why not. As to why have a version at all, this is of course tied to whether usbip-utils will ever emerge from the belly of the whale and return to its own home. I think it should someday, if the concerns about long-term maintenance and interface stability can be addressed to your satisfaction. It would be considerable work to integrate it into the kernel build, and would need to be undone if it ever left kernel.git. Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] iio: adc: at91 fixes
Hi, Alexandre On 3/6/2014 12:57 AM, Alexandre Belloni wrote: This series fixes a kernel crash at probe time when using the at91_adc driver through platform_data. This crash appeared in 3.13. The first patch fixes the crash. While it is already quite late, I think it would be good to get it in 3.14. The next patches restore support for at91_adc on the at91sam9g45 and at91sam9260 based boards. It would be great if they could make it in 3.14. But I'm not sure it is worth applying them to 3.13. Alexandre Belloni (3): iio: adc: at91_adc: Repair broken platform_data support ARM: at91: at91sam9g45: change at91_adc name ARM: at91: at91sam9260: change at91_adc name arch/arm/mach-at91/at91sam9260_devices.c | 2 +- arch/arm/mach-at91/at91sam9g45_devices.c | 2 +- drivers/iio/adc/at91_adc.c | 26 ++ 3 files changed, 24 insertions(+), 6 deletions(-) Thank you for the fixes. I tested the patch series in at91sam9m10g45ek and works fine. so here is my: Tested-by: Josh Wu Acked-by: Josh Wu Best Regards, Josh Wu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Staging: comedi: addi-data: tidy up timer register map defines in hwdrv_apci1564.c
This patch for hwdrv_apci1564.c fixes the register map defines for the
timer registers such that they are all the real offsets to each register,
rather than a mix of real offsets and adders to those offsets.
Additionally, the defines have been renamed to assist with shortening
some lines in excess of 80 characters.
Signed-off-by: Chase Southwood
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 82 +-
1 file changed, 33 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 91ca091..85e29b9 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -65,7 +65,6 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define ADDIDATA_TIMER 0
#define ADDIDATA_COUNTER 1
#define ADDIDATA_WATCHDOG 2
-#define APCI1564_TIMER 0x48
#define APCI1564_COUNTER1 0x0
#define APCI1564_COUNTER2 0x20
#define APCI1564_COUNTER3 0x40
@@ -99,6 +98,14 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_WDOG_IRQ_REG 0x3c
#define APCI1564_WDOG_WARN_TIMEVAL_REG 0x40
#define APCI1564_WDOG_WARN_TIMEBASE_REG0x44
+#define APCI1564_TIMER_REG 0x48
+#define APCI1564_TIMER_RELOAD_REG 0x4c
+#define APCI1564_TIMER_TIMEBASE_REG0x50
+#define APCI1564_TIMER_CTRL_REG0x54
+#define APCI1564_TIMER_STATUS_REG 0x58
+#define APCI1564_TIMER_IRQ_REG 0x5c
+#define APCI1564_TIMER_WARN_TIMEVAL_REG0x60
+#define APCI1564_TIMER_WARN_TIMEBASE_REG 0x64
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
@@ -297,15 +304,15 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
outl(data[3], devpriv->i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
} else if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
- ul_Command1 =
- inl(devpriv->i_IobaseAmcc + APCI1564_TIMER +
- APCI1564_TCW_PROG);
+ ul_Command1 = inl(devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
ul_Command1 = ul_Command1 & 0xF9FEUL;
- outl(ul_Command1, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* Stop The Timer */
+ /* Stop The Timer */
+ outl(ul_Command1, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
devpriv->b_TimerSelectMode = ADDIDATA_TIMER;
if (data[1] == 1) {
- outl(0x02, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* Enable TIMER int & DISABLE ALL THE OTHER int SOURCES */
+ /* Enable TIMER int & DISABLE ALL THE OTHER int SOURCES
*/
+ outl(0x02, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_WDOG_IRQ_REG);
@@ -322,25 +329,20 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
devpriv->iobase + APCI1564_COUNTER4 +
APCI1564_TCW_IRQ);
} else {
- outl(0x0, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* disable Timer interrupt */
+ /* disable Timer interrupt */
+ outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
}
/* Loading Timebase */
- outl(data[2],
- devpriv->i_IobaseAmcc + APCI1564_TIMER +
- APCI1564_TCW_TIMEBASE);
+ outl(data[2], devpriv->i_IobaseAmcc +
APCI1564_TIMER_TIMEBASE_REG);
/* Loading the Reload value */
- outl(data[3],
- devpriv->i_IobaseAmcc + APCI1564_TIMER +
- APCI1564_TCW_RELOAD_VALUE);
+ outl(data[3], devpriv->i_IobaseAmcc +
APCI1564_TIMER_RELOAD_REG);
- ul_Command1 =
- inl(devpriv->i_IobaseAmcc + APCI1564_TIMER +
- APCI1564_TCW_PROG);
- ul_Command1 =
- (ul_Command1 & 0xFFF719E2UL) | 2UL << 13UL | 0x10UL;
- outl(ul_Command1, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* m
[PATCH 5/5] Staging: comedi: addi-data: tidy up counter register map defines in hwdrv_apci1564.c
This patch for hwdrv_apci1564.c fixes the register map defines for the
digital input registers such that they are all the real offsets to each
register, rather than a mix of real offsets and adders to those offsets.
Signed-off-by: Chase Southwood
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 101 +
1 file changed, 44 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 85e29b9..2519472 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -61,22 +61,13 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_DIGITAL_OP_CC_INTERRUPT_DISABLE 0xfffd
/* TIMER COUNTER WATCHDOG DEFINES */
-
#define ADDIDATA_TIMER 0
#define ADDIDATA_COUNTER 1
#define ADDIDATA_WATCHDOG 2
-#define APCI1564_COUNTER1 0x0
-#define APCI1564_COUNTER2 0x20
-#define APCI1564_COUNTER3 0x40
-#define APCI1564_COUNTER4 0x60
-#define APCI1564_TCW_SYNC_ENABLEDISABLE0
-#define APCI1564_TCW_RELOAD_VALUE 4
-#define APCI1564_TCW_TIMEBASE 8
-#define APCI1564_TCW_PROG 12
-#define APCI1564_TCW_TRIG_STATUS 16
-#define APCI1564_TCW_IRQ 20
-#define APCI1564_TCW_WARN_TIMEVAL 24
-#define APCI1564_TCW_WARN_TIMEBASE 28
+#define APCI1564_COUNTER1 0
+#define APCI1564_COUNTER2 1
+#define APCI1564_COUNTER3 2
+#define APCI1564_COUNTER4 3
/*
* devpriv->i_IobaseAmcc Register Map
@@ -107,6 +98,18 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_TIMER_WARN_TIMEVAL_REG0x60
#define APCI1564_TIMER_WARN_TIMEBASE_REG 0x64
+/*
+ * devpriv->iobase Register Map
+ */
+#define APCI1564_TCW_REG(x)(0x00 + ((x) * 0x20))
+#define APCI1564_TCW_RELOAD_REG(x) (0x04 + ((x) * 0x20))
+#define APCI1564_TCW_TIMEBASE_REG(x) (0x08 + ((x) * 0x20))
+#define APCI1564_TCW_CTRL_REG(x) (0x0c + ((x) * 0x20))
+#define APCI1564_TCW_STATUS_REG(x) (0x10 + ((x) * 0x20))
+#define APCI1564_TCW_IRQ_REG(x)(0x14 + ((x) * 0x20))
+#define APCI1564_TCW_WARN_TIMEVAL_REG(x) (0x18 + ((x) * 0x20))
+#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
+
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
static unsigned int ui_InterruptData, ui_Type;
@@ -317,17 +320,13 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_WDOG_IRQ_REG);
outl(0x0,
- devpriv->iobase + APCI1564_COUNTER1 +
- APCI1564_TCW_IRQ);
+ devpriv->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1));
outl(0x0,
- devpriv->iobase + APCI1564_COUNTER2 +
- APCI1564_TCW_IRQ);
+ devpriv->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2));
outl(0x0,
- devpriv->iobase + APCI1564_COUNTER3 +
- APCI1564_TCW_IRQ);
+ devpriv->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3));
outl(0x0,
- devpriv->iobase + APCI1564_COUNTER4 +
- APCI1564_TCW_IRQ);
+ devpriv->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4));
} else {
/* disable Timer interrupt */
outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
@@ -603,14 +602,14 @@ static void v_APCI1564_Interrupt(int irq, void *d)
ui_DI = inl(devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG) & 0x01;
ui_DO = inl(devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG) & 0x01;
ui_Timer = inl(devpriv->i_IobaseAmcc + APCI1564_TIMER_IRQ_REG) & 0x01;
- ui_C1 = inl(devpriv->iobase + APCI1564_COUNTER1 +
- APCI1564_TCW_IRQ) & 0x1;
- ui_C2 = inl(devpriv->iobase + APCI1564_COUNTER2 +
- APCI1564_TCW_IRQ) & 0x1;
- ui_C3 = inl(devpriv->iobas
[PATCH 2/5] Staging: comedi: addi-data: tidy up digital output register map defines in hwdrv_apci1564.c
This patch for hwdrv_apci1564.c fixes the register map defines for the
digital output registers such that they are all the real offsets to each
register, rather than a mix of real offsets and adders to those offsets.
Additionally, the defines have been renamed to assist with shortening
some lines in excess of 80 characters.
Further, some of the old defines were being used incorrectly in the
i_APCI1564_Reset() function. Upon swapping the old defines out for the
new ones in this function, their use has been corrected.
Signed-off-by: Chase Southwood
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 50 +++---
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index d178a3b..d17c37b 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -46,21 +46,10 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_ADDRESS_RANGE 128
-/* DIGITAL INPUT-OUTPUT DEFINE */
-
-/* Output defines */
-#define APCI1564_DIGITAL_OP0x18
-#define APCI1564_DIGITAL_OP_RW 0
-#define APCI1564_DIGITAL_OP_INTERRUPT 4
-#define APCI1564_DIGITAL_OP_IRQ12
-
/* Digital Input IRQ Function Selection */
#define ADDIDATA_OR0
#define ADDIDATA_AND 1
-/* Digital Output Interrupt Status */
-#define APCI1564_DIGITAL_OP_INTERRUPT_STATUS 8
-
/* Digital Input Interrupt Enable Disable. */
#define APCI1564_DIGITAL_IP_INTERRUPT_ENABLE 0x4
#define APCI1564_DIGITAL_IP_INTERRUPT_DISABLE 0xfffb
@@ -99,6 +88,10 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_DI_INT_MODE2_REG 0x0c
#define APCI1564_DI_INT_STATUS_REG 0x10
#define APCI1564_DI_IRQ_REG0x14
+#define APCI1564_DO_REG0x18
+#define APCI1564_DO_INT_CTRL_REG 0x1c
+#define APCI1564_DO_INT_STATUS_REG 0x20
+#define APCI1564_DO_IRQ_REG0x24
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
@@ -226,12 +219,8 @@ static int i_APCI1564_ConfigDigitalOutput(struct
comedi_device *dev,
else
ul_Command = ul_Command & 0xFFFD;
- outl(ul_Command,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_INTERRUPT);
- ui_InterruptData =
- inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_INTERRUPT);
+ outl(ul_Command, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
+ ui_InterruptData = inl(devpriv->i_IobaseAmcc +
APCI1564_DO_INT_CTRL_REG);
devpriv->tsk_Current = current;
return insn->n;
}
@@ -243,12 +232,10 @@ static int apci1564_do_insn_bits(struct comedi_device
*dev,
{
struct addi_private *devpriv = dev->private;
- s->state = inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_RW);
+ s->state = inl(devpriv->i_IobaseAmcc + APCI1564_DO_REG);
if (comedi_dio_update_state(s, data))
- outl(s->state, devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_RW);
+ outl(s->state, devpriv->i_IobaseAmcc + APCI1564_DO_REG);
data[1] = s->state;
@@ -317,9 +304,7 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
if (data[1] == 1) {
outl(0x02, devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_PROG); /* Enable TIMER int & DISABLE ALL THE OTHER int SOURCES */
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_IRQ);
+ outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0,
devpriv->i_IobaseAmcc +
APCI1564_DIGITAL_OP_WATCHDOG +
@@ -634,8 +619,7 @@ static void v_APCI1564_Interrupt(int irq, void *d)
unsigned int ul_Command2 = 0;
ui_DI = inl(devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG) & 0x01;
- ui_DO = inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_IRQ) & 0x01;
+ ui_DO = inl(devpriv->i_IobaseAmcc + APCI1564_DO_IRQ_REG) & 0x01;
ui_Timer =
inl(devpriv->i_IobaseAmcc + APCI1564_TIMER +
APCI1564_TCW_IRQ) & 0x0
[PATCH 1/5] Staging: comedi: addi-data: tidy up digital input register map defines in hwdrv_apci1564.c
This patch for hwdrv_apci1564.c fixes the register map defines for the
digital input registers such that they are all the real offsets to each
register, rather than a mix of real offsets and adders to those offsets.
Additionally, the defines have been renamed to assist with shortening
some lines in excess of 80 characters.
Further, some of the old defines were being used incorrectly in the
i_APCI1564_Reset() function. Upon swapping the old defines out for the
new ones in this function, their use has been corrected.
Signed-off-by: Chase Southwood
---
Greg, as promised, this is the most up-to-date patchset for hwdrv_apci1564.c.
Please disregard any outstanding unapplied patches from me for this file as this
5 patch set supersedes all previous patchsets I have submitted for this file.
Hartley, I have followed the advice you gave and broke up this patchset
accordingly. It'd be great if I could get a review! This serves as the
beginning of a much more substantial cleanup of this driver.
Thanks,
Chase
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 78 +-
1 file changed, 31 insertions(+), 47 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 2b47fa1..d178a3b 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -47,11 +47,6 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_ADDRESS_RANGE 128
/* DIGITAL INPUT-OUTPUT DEFINE */
-/* Input defines */
-#define APCI1564_DIGITAL_IP0x04
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE14
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE28
-#define APCI1564_DIGITAL_IP_IRQ16
/* Output defines */
#define APCI1564_DIGITAL_OP0x18
@@ -63,9 +58,6 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define ADDIDATA_OR0
#define ADDIDATA_AND 1
-/* Digital Input Interrupt Status */
-#define APCI1564_DIGITAL_IP_INTERRUPT_STATUS 12
-
/* Digital Output Interrupt Status */
#define APCI1564_DIGITAL_OP_INTERRUPT_STATUS 8
@@ -99,6 +91,15 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_TCW_WARN_TIMEVAL 24
#define APCI1564_TCW_WARN_TIMEBASE 28
+/*
+ * devpriv->i_IobaseAmcc Register Map
+ */
+#define APCI1564_DI_REG0x04
+#define APCI1564_DI_INT_MODE1_REG 0x08
+#define APCI1564_DI_INT_MODE2_REG 0x0c
+#define APCI1564_DI_INT_STATUS_REG 0x10
+#define APCI1564_DI_IRQ_REG0x14
+
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
static unsigned int ui_InterruptData, ui_Type;
@@ -143,31 +144,17 @@ static int i_APCI1564_ConfigDigitalInput(struct
comedi_device *dev,
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
data[3] = data[3] << 4;
- outl(data[2],
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
- outl(data[3],
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
+ outl(data[2], devpriv->i_IobaseAmcc +
APCI1564_DI_INT_MODE1_REG);
+ outl(data[3], devpriv->i_IobaseAmcc +
APCI1564_DI_INT_MODE2_REG);
if (data[1] == ADDIDATA_OR) {
- outl(0x4,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl(0x4, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
} else {
- outl(0x6,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl(0x6, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
}
} else {
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_INT_MODE1_REG);
+ outl(0x0, devpriv->i_IobaseAmcc + APC
[PATCH] hung_task : check the value of "sysctl_hung_task_timeout_sec"
As sysctl_hung_task_timeout_sec is unsigned long, when this value is
larger then LONG_MAX, the function schedule_timeout_interruptible in
watchdog will return immediately without sleep :
for example (in x86_64 platform):
linux# echo 0x > /proc/sys/kernel/hung_task_timeout_secs
[ 66.798350] schedule_timeout: wrong timeout value ff06
[ 66.800064] schedule_timeout: wrong timeout value ff06
[ 66.801774] schedule_timeout: wrong timeout value ff06
[ 66.803488] schedule_timeout: wrong timeout value ff06
[ 66.805225] schedule_timeout: wrong timeout value ff06
The screen was filled with "schedule_timeout: wrong timeout value
ff06" and the system stalled.
So I do some check and correction in timeout_jiffies, to let the function
schedule_timeout_interruptible allways get the valid parameter.
Signed-off-by: Liu Hua
---
kernel/hung_task.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 06bb141..ef96650 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -186,7 +186,16 @@ static void check_hung_uninterruptible_tasks(unsigned long
timeout)
static unsigned long timeout_jiffies(unsigned long timeout)
{
/* timeout of 0 will disable the watchdog */
- return timeout ? timeout * HZ : MAX_SCHEDULE_TIMEOUT;
+ if ((timeout == 0) || (timeout > MAX_SCHEDULE_TIMEOUT)) {
+ pr_err("%s : wrong timeout value %lx\n",
+ __func__, timeout);
+ pr_err("Timeout value is set to MAX_SCHEDULE_TIMEOUT(%lx)
now.\n",
+ MAX_SCHEDULE_TIMEOUT);
+ return MAX_SCHEDULE_TIMEOUT;
+ }
+
+ return (timeout * HZ) < MAX_SCHEDULE_TIMEOUT ?
+ timeout * HZ : MAX_SCHEDULE_TIMEOUT;
}
/*
--
1.8.5.5.dirty
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the akpm-current tree
On Thu, 2014-03-06 at 18:08 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/vmacache.h:4:0,
> from include/linux/sched.h:28,
> from arch/arm/include/asm/tlbflush.h:204,
> from arch/arm/include/asm/pgtable.h:28,
> from arch/arm/include/asm/idmap.h:5,
> from arch/arm/mm/idmap.c:6:
> include/linux/mm.h: In function 'is_vmalloc_addr':
> include/linux/mm.h:359:17: error: 'VMALLOC_START' undeclared (first use in
> this function)
> include/linux/mm.h:359:41: error: 'VMALLOC_END' undeclared (first use in this
> function)
> include/linux/mm.h: In function 'maybe_mkwrite':
> include/linux/mm.h:589:3: error: implicit declaration of function
> 'pte_mkwrite' [-Werror=implicit-function-declaration]
> In file included from include/linux/vmacache.h:4:0,
> from include/linux/sched.h:28,
> from arch/arm/include/asm/tlbflush.h:204,
> from arch/arm/include/asm/pgtable.h:28,
> from arch/arm/include/asm/idmap.h:5,
> from arch/arm/mm/idmap.c:6:
> include/linux/mm.h: In function 'pmd_alloc':
> include/linux/mm.h:1396:2: error: implicit declaration of function 'pud_none'
> [-Werror=implicit-function-declaration]
> include/linux/mm.h:1397:3: error: implicit declaration of function
> 'pmd_offset' [-Werror=implicit-function-declaration]
> include/linux/mm.h:1397:7: warning: pointer/integer type mismatch in
> conditional expression [enabled by default]
> include/linux/mm.h: In function 'pte_lockptr':
> include/linux/mm.h:1433:2: error: implicit declaration of function 'pmd_page'
> [-Werror=implicit-function-declaration]
> include/linux/mm.h:1433:2: warning: passing argument 1 of 'ptlock_ptr' makes
> pointer from integer without a cast [enabled by default]
> include/linux/mm.h:1425:27: note: expected 'struct page *' but argument is of
> type 'int'
> include/linux/mm.h: In function 'pgtable_init':
> include/linux/mm.h:1476:2: error: implicit declaration of function
> 'pgtable_cache_init' [-Werror=implicit-function-declaration]
> In file included from arch/arm/include/asm/pgtable.h:33:0,
> from arch/arm/include/asm/idmap.h:5,
> from arch/arm/mm/idmap.c:6:
> arch/arm/include/asm/pgtable-2level.h: At top level:
> arch/arm/include/asm/pgtable-2level.h:159:22: error: conflicting types for
> 'pmd_offset'
> include/linux/mm.h:1397:9: note: previous implicit declaration of
> 'pmd_offset' was here
> In file included from arch/arm/include/asm/idmap.h:5:0,
> from arch/arm/mm/idmap.c:6:
> arch/arm/include/asm/pgtable.h:255:1: error: conflicting types for
> 'pte_mkwrite'
> include/linux/mm.h:589:9: note: previous implicit declaration of
> 'pte_mkwrite' was here
>
> and on and on ...
>
> Caused by commit 0d9ad4220e6d ("mm: per-thread vma caching") which adds
> the include of linux/vmacache.h (which includes linux/mm.h) into
> linux/sched.h ... There is a reason that we did not include linux/mm.h
> into sched.h.
Apologies, I was not aware of the "no mm.h in sched.h" rule. It broke
builds on several archs.
Thanks for looking into this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] staging: cxt1e1: remove unneeded a value
2014-03-05 19:13 GMT+09:00 Tobias Klauser :
> On 2014-03-05 at 02:24:22 +0100, Daeseok Youn wrote:
>>
>> It doesn't need to assign name array address to np pointer.
>>
>> Signed-off-by: Daeseok Youn
>> ---
>> drivers/staging/cxt1e1/linux.c |5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
>> index 5bb42ae..cae8c66 100644
>> --- a/drivers/staging/cxt1e1/linux.c
>> +++ b/drivers/staging/cxt1e1/linux.c
>> @@ -205,15 +205,14 @@ status_t
>> c4_wq_port_init(mpi_t *pi)
>> {
>>
>> - charname[16], *np; /* NOTE: name of the queue limited by
>> system
>> + charname[16]; /* NOTE: name of the queue limited by system
>>* to 10 characters */
>>
>> if (pi->wq_port)
>> return 0; /* already initialized */
>>
>> - np = name;
>> memset(name, 0, 16);
>
> This isn't necessary since s{,n}printf() adds a terminating '\0'.
Yes, I have looked at lib/vsprintf.c. I found it adds null to a string
in the end of vsnprintf() function.
I will remove memset() line.
>
>> - sprintf(np, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01) */
>> + sprintf(name, "%s%d", pi->up->devname, pi->portnum); /* IE pmcc4-01) */
>
> Better use snprintf() here, even if the comment above claims the name
> never to be no longer than 10 characters.
OK. I will replace sprintf with snprintf() and set a string length to "10".
Thanks for review.
Daeseok Youn.
>
> Cheers
> Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/3] r8152: remove rtl8152_get_stats
The rtl8152_get_stats() returns the point address of the struct
net_device_stats. This could be got from struct net_device directly.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 151398b..b8eee36 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -960,11 +960,6 @@ static int rtl8152_set_mac_address(struct net_device
*netdev, void *p)
return 0;
}
-static struct net_device_stats *rtl8152_get_stats(struct net_device *dev)
-{
- return &dev->stats;
-}
-
static void read_bulk_callback(struct urb *urb)
{
struct net_device *netdev;
@@ -1052,7 +1047,7 @@ static void write_bulk_callback(struct urb *urb)
return;
netdev = tp->netdev;
- stats = rtl8152_get_stats(netdev);
+ stats = &netdev->stats;
if (status) {
if (net_ratelimit())
netdev_warn(netdev, "Tx status %d\n", status);
@@ -1442,7 +1437,7 @@ static void rx_bottom(struct r8152 *tp)
while (urb->actual_length > len_used) {
struct net_device *netdev = tp->netdev;
- struct net_device_stats *stats;
+ struct net_device_stats *stats = &netdev->stats;
unsigned int pkt_len;
struct sk_buff *skb;
@@ -1454,8 +1449,6 @@ static void rx_bottom(struct r8152 *tp)
if (urb->actual_length < len_used)
break;
- stats = rtl8152_get_stats(netdev);
-
pkt_len -= CRC_SIZE;
rx_data += sizeof(struct rx_desc);
@@ -1504,16 +1497,14 @@ static void tx_bottom(struct r8152 *tp)
res = r8152_tx_agg_fill(tp, agg);
if (res) {
- struct net_device_stats *stats;
- struct net_device *netdev;
- unsigned long flags;
-
- netdev = tp->netdev;
- stats = rtl8152_get_stats(netdev);
+ struct net_device *netdev = tp->netdev;
if (res == -ENODEV) {
netif_device_detach(netdev);
} else {
+ struct net_device_stats *stats = &netdev->stats;
+ unsigned long flags;
+
netif_warn(tp, tx_err, netdev,
"failed tx_urb %d\n", res);
stats->tx_dropped += agg->skb_num;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/3] r8152: cleanups
Deal with some empty lines and spaces, replace some tp->netdev with netdev, and remove the unnecessary function. Hayes Wang (3): r8152: deal with the empty line and space r8152: replace tp->netdev with netdev r8152: remove rtl8152_get_stats drivers/net/usb/r8152.c | 36 1 file changed, 16 insertions(+), 20 deletions(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/3] r8152: replace tp->netdev with netdev
Replace some tp->netdev with netdev.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c8bad62..151398b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1037,6 +1037,7 @@ static void read_bulk_callback(struct urb *urb)
static void write_bulk_callback(struct urb *urb)
{
struct net_device_stats *stats;
+ struct net_device *netdev;
unsigned long flags;
struct tx_agg *agg;
struct r8152 *tp;
@@ -1050,10 +1051,11 @@ static void write_bulk_callback(struct urb *urb)
if (!tp)
return;
- stats = rtl8152_get_stats(tp->netdev);
+ netdev = tp->netdev;
+ stats = rtl8152_get_stats(netdev);
if (status) {
if (net_ratelimit())
- netdev_warn(tp->netdev, "Tx status %d\n", status);
+ netdev_warn(netdev, "Tx status %d\n", status);
stats->tx_errors += agg->skb_num;
} else {
stats->tx_packets += agg->skb_num;
@@ -1066,7 +1068,7 @@ static void write_bulk_callback(struct urb *urb)
usb_autopm_put_interface_async(tp->intf);
- if (!netif_carrier_ok(tp->netdev))
+ if (!netif_carrier_ok(netdev))
return;
if (!test_bit(WORK_ENABLE, &tp->flags))
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/vmacache.h:4:0,
from include/linux/sched.h:28,
from arch/arm/include/asm/tlbflush.h:204,
from arch/arm/include/asm/pgtable.h:28,
from arch/arm/include/asm/idmap.h:5,
from arch/arm/mm/idmap.c:6:
include/linux/mm.h: In function 'is_vmalloc_addr':
include/linux/mm.h:359:17: error: 'VMALLOC_START' undeclared (first use in this
function)
include/linux/mm.h:359:41: error: 'VMALLOC_END' undeclared (first use in this
function)
include/linux/mm.h: In function 'maybe_mkwrite':
include/linux/mm.h:589:3: error: implicit declaration of function 'pte_mkwrite'
[-Werror=implicit-function-declaration]
In file included from include/linux/vmacache.h:4:0,
from include/linux/sched.h:28,
from arch/arm/include/asm/tlbflush.h:204,
from arch/arm/include/asm/pgtable.h:28,
from arch/arm/include/asm/idmap.h:5,
from arch/arm/mm/idmap.c:6:
include/linux/mm.h: In function 'pmd_alloc':
include/linux/mm.h:1396:2: error: implicit declaration of function 'pud_none'
[-Werror=implicit-function-declaration]
include/linux/mm.h:1397:3: error: implicit declaration of function 'pmd_offset'
[-Werror=implicit-function-declaration]
include/linux/mm.h:1397:7: warning: pointer/integer type mismatch in
conditional expression [enabled by default]
include/linux/mm.h: In function 'pte_lockptr':
include/linux/mm.h:1433:2: error: implicit declaration of function 'pmd_page'
[-Werror=implicit-function-declaration]
include/linux/mm.h:1433:2: warning: passing argument 1 of 'ptlock_ptr' makes
pointer from integer without a cast [enabled by default]
include/linux/mm.h:1425:27: note: expected 'struct page *' but argument is of
type 'int'
include/linux/mm.h: In function 'pgtable_init':
include/linux/mm.h:1476:2: error: implicit declaration of function
'pgtable_cache_init' [-Werror=implicit-function-declaration]
In file included from arch/arm/include/asm/pgtable.h:33:0,
from arch/arm/include/asm/idmap.h:5,
from arch/arm/mm/idmap.c:6:
arch/arm/include/asm/pgtable-2level.h: At top level:
arch/arm/include/asm/pgtable-2level.h:159:22: error: conflicting types for
'pmd_offset'
include/linux/mm.h:1397:9: note: previous implicit declaration of 'pmd_offset'
was here
In file included from arch/arm/include/asm/idmap.h:5:0,
from arch/arm/mm/idmap.c:6:
arch/arm/include/asm/pgtable.h:255:1: error: conflicting types for 'pte_mkwrite'
include/linux/mm.h:589:9: note: previous implicit declaration of 'pte_mkwrite'
was here
and on and on ...
Caused by commit 0d9ad4220e6d ("mm: per-thread vma caching") which adds
the include of linux/vmacache.h (which includes linux/mm.h) into
linux/sched.h ... There is a reason that we did not include linux/mm.h
into sched.h.
I added the following patch:
From: Stephen Rothwell
Date: Thu, 6 Mar 2014 17:45:30 +1100
Subject: [PATCH] mm: don't implictly include linux/mm.h in linux/sched.h
Signed-off-by: Stephen Rothwell
---
arch/unicore32/include/asm/mmu_context.h | 1 +
fs/exec.c| 1 +
include/linux/sched.h| 2 +-
include/linux/vmacache.h | 4 +---
include/linux/vmacachedefs.h | 9 +
kernel/debug/debug_core.c| 1 +
kernel/fork.c| 1 +
mm/mmap.c| 1 +
mm/nommu.c | 1 +
9 files changed, 17 insertions(+), 4 deletions(-)
create mode 100644 include/linux/vmacachedefs.h
diff --git a/arch/unicore32/include/asm/mmu_context.h
b/arch/unicore32/include/asm/mmu_context.h
index 2dcd03719ace..ab474c8b8269 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/fs/exec.c b/fs/exec.c
index 60e36e9b5a1b..1b75ab04c787 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d718fd5048de..07fa6c2c4a9a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -25,7 +25,7 @@ struct sched_param {
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/include/linux/vmacache.h b/include/linux/vmacache.h
index 40e4eb829d48..e22a6b6a4889 100644
--- a/include/linux/vmacache.h
+++ b/include/linux/vmacache.h
@@ -2,10 +2,8 @@
#define __LINUX_VMACACHE_H
#include
+#include
-#define VMACACHE_BITS 2
-#define VMACACHE_SIZE (1U << VMACACHE_BITS)
-#define VMACACHE_MASK (VMACACHE_SIZE - 1)
/*
* Hash based on the page number. Provides a good hit rate for
* workloads with good locali
Re: [PATCH] abort secondary CPU bring-up gracefully if do_boot_cpu timed out on cpu_callin_mask
* Igor Mammedov wrote: > Master CPU may timeout before cpu_callin_mask is set and cancel > booting CPU, but being onlined CPU still continues to boot, sets > cpu_active_mask (CPU_STARTING notifiers) and spins in > check_tsc_sync_target() for master cpu to arrive. Following attempt > to online another cpu hangs in stop_machine, initiated from here: The changelog needs to prominently contain a description of the practical relevance of this patch: has the hang triggered on any system and under what circumstances, and did the patch resolve the hang, etc.? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/3] r8152: deal with the empty line and space
Add or remove some empty lines. Replace the spaces with the tabs.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0654bd3..c8bad62 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -593,6 +593,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
value, index, tmp, size, 500);
kfree(tmp);
+
return ret;
}
@@ -1514,6 +1515,7 @@ static void tx_bottom(struct r8152 *tp)
netif_warn(tp, tx_err, netdev,
"failed tx_urb %d\n", res);
stats->tx_dropped += agg->skb_num;
+
spin_lock_irqsave(&tp->tx_lock, flags);
list_add_tail(&agg->list, &tp->tx_free);
spin_unlock_irqrestore(&tp->tx_lock, flags);
@@ -1833,7 +1835,6 @@ static void r8152_power_cut_en(struct r8152 *tp, bool
enable)
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_PM_CTRL_STATUS);
ocp_data &= ~RESUME_INDICATE;
ocp_write_word(tp, MCU_TYPE_USB, USB_PM_CTRL_STATUS, ocp_data);
-
}
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
@@ -2013,8 +2014,8 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
static void r8152b_exit_oob(struct r8152 *tp)
{
- u32 ocp_data;
- int i;
+ u32 ocp_data;
+ int i;
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data &= ~RCR_ACPT_ALL;
@@ -2573,6 +2574,7 @@ static int rtl8152_open(struct net_device *netdev)
netif_carrier_off(netdev);
netif_start_queue(netdev);
set_bit(WORK_ENABLE, &tp->flags);
+
res = usb_submit_urb(tp->intr_urb, GFP_KERNEL);
if (res) {
if (res == -ENODEV)
@@ -3101,6 +3103,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev->features |= NETIF_F_IP_CSUM;
netdev->hw_features = NETIF_F_IP_CSUM;
+
SET_ETHTOOL_OPS(netdev, &ops);
tp->mii.dev = netdev;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: cxt1e1: use kzalloc instead of kmalloc/memset 0
Thanks for review.
OK. I will try to change all of OS_kmalloc to kmalloc/kzalloc.
And I also check GFP_DMA flag in kmalloc/kzalloc.
Regards,
Daeseok Youn
2014-03-05 19:04 GMT+09:00 Tobias Klauser :
> On 2014-03-05 at 03:37:15 +0100, Daeseok Youn wrote:
>>
>> Signed-off-by: Daeseok Youn
>> ---
>> drivers/staging/cxt1e1/sbecom_inline_linux.h |6 ++
>> 1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/cxt1e1/sbecom_inline_linux.h
>> b/drivers/staging/cxt1e1/sbecom_inline_linux.h
>> index ba3ff3e..6dd1b55 100644
>> --- a/drivers/staging/cxt1e1/sbecom_inline_linux.h
>> +++ b/drivers/staging/cxt1e1/sbecom_inline_linux.h
>> @@ -46,11 +46,9 @@ voidpci_write_32 (u_int32_t *p, u_int32_t v);
>> static inline void *
>> OS_kmalloc (size_t size)
>> {
>> -char *ptr = kmalloc (size, GFP_KERNEL | GFP_DMA);
>> + char *ptr = kzalloc(size, GFP_KERNEL | GFP_DMA);
>>
>> -if (ptr)
>> -memset (ptr, 0, size);
>> -return ptr;
>> + return ptr;
>> }
>
> It would probably be even better to get rid of this function altogether
> and replace all calls to it by kmalloc/kzalloc.
>
> From a quick look at the users of OS_kmalloc, it also looks like GFP_DMA
> isn't needed for all of them.
>
> Cheers
> Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How could we get rid of saved_max_pfn for calgary iommu?
On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote: > OK, second question... is it time to axe Calgary? I don't know of anyone still using it, but it's not impossible. Calgary and CalIOC2 machines would now be ~5-8 years old. Cheers, Muli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] Staging: comedi: range: remove unnecessary sanity check
This check is unnecessary because range_table will always be
initialized to range_unknown by comedi_device_postconfig() for
drivers that do not initialize range_table or range_table_list
Signed-off-by: Fred Akers
---
drivers/staging/comedi/range.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c
index c4bb13b..b684954 100644
--- a/drivers/staging/comedi/range.c
+++ b/drivers/staging/comedi/range.c
@@ -143,10 +143,6 @@ int comedi_check_chanlist(struct comedi_subdevice *s, int
n,
unsigned int chanspec;
int chan, range_len, i;
- if (!s->range_table && !s->range_table_list) {
- dev_err(dev->class_dev, "(bug) no range type list!\n");
- return -EINVAL;
- }
for (i = 0; i < n; i++) {
chanspec = chanlist[i];
chan = CR_CHAN(chanspec);
--
1.8.5.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/
[PATCH v2 1/2] Staging: comedi: range: tidy up comedi_check_chanlist()
Refactor this function to remove an extra indent level
Signed-off-by: Fred Akers
---
drivers/staging/comedi/range.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c
index 46b3da6..c4bb13b 100644
--- a/drivers/staging/comedi/range.c
+++ b/drivers/staging/comedi/range.c
@@ -143,29 +143,28 @@ int comedi_check_chanlist(struct comedi_subdevice *s, int
n,
unsigned int chanspec;
int chan, range_len, i;
- if (s->range_table || s->range_table_list) {
- for (i = 0; i < n; i++) {
- chanspec = chanlist[i];
- chan = CR_CHAN(chanspec);
- if (s->range_table)
- range_len = s->range_table->length;
- else if (s->range_table_list && chan < s->n_chan)
- range_len = s->range_table_list[chan]->length;
- else
- range_len = 0;
- if (chan >= s->n_chan ||
- CR_RANGE(chanspec) >= range_len ||
- aref_invalid(s, chanspec)) {
- dev_warn(dev->class_dev,
-"bad chanlist[%d]=0x%08x chan=%d range
length=%d\n",
-i, chanspec, chan, range_len);
- return -EINVAL;
- }
- }
- } else {
+ if (!s->range_table && !s->range_table_list) {
dev_err(dev->class_dev, "(bug) no range type list!\n");
return -EINVAL;
}
+ for (i = 0; i < n; i++) {
+ chanspec = chanlist[i];
+ chan = CR_CHAN(chanspec);
+ if (s->range_table)
+ range_len = s->range_table->length;
+ else if (s->range_table_list && chan < s->n_chan)
+ range_len = s->range_table_list[chan]->length;
+ else
+ range_len = 0;
+ if (chan >= s->n_chan ||
+ CR_RANGE(chanspec) >= range_len ||
+ aref_invalid(s, chanspec)) {
+ dev_warn(dev->class_dev,
+"bad chanlist[%d]=0x%08x chan=%d range
length=%d\n",
+i, chanspec, chan, range_len);
+ return -EINVAL;
+ }
+ }
return 0;
}
EXPORT_SYMBOL_GPL(comedi_check_chanlist);
--
1.8.5.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] pinctrl-baytrail: add function mux checking in gpio pin request
On 3/6/14, 5:59, "Chew Chiau Ee" wrote: >From: Chew, Kean Ho > >The requested gpio pin must has the func_pin_mux field set >to GPIO function by BIOS/FW in advanced. Else, the gpio pin >request would fail. This is to ensure that we do not expose >any gpio pins which shall be used for alternate functions, >for eg: wakeup pin, I/O interfaces for LPSS, etc. > >Signed-off-by: Chew, Kean Ho >Signed-off-by: Chew, Chiau Ee Thanks for sending this out Chiau Ee, Reviewed-by: Darren Hart -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How could we get rid of saved_max_pfn for calgary iommu?
On 03/05/2014 10:47 PM, Muli Ben-Yehuda wrote: > On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote: > >> Hi, Muli >> >> saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary >> could get rid of saved_max_pfn at all. But If this can't work, how >> about exporting a calgary tce table size to user space, so that >> kexec-tools can simply pass calgary=xxx cmdline to 2nd kernel. > > As Jon noted, this code is used to so that the TCE table remains > consistent between the original and the kexec'd kernel. I see two > options: either we hard code the TCE table size to the max so that > this bit of code becomes redundant, or we explicitly pass the original > table size (or the original max_pfn) to the kexec'd kernel. The first > option is more appealing, because I don't think anyone is actually > using the TCE table size -- we mostly added it for debugging the IOMMU > TCE code at the time -- but since I don't have a Calgary machine > anymore, I don't have any way to test it. The second option is uglier > but would be fully backward-compatible and less likely to break > things. Given that very few people are likely running the latest > upstream kernel on Calgary/CalIOC2 machines, I'm inclined towards the > first option. > >> BTW MAINTAINERS file still uses your old email, please update >> accordingly. > > I think you are the first person to actually look up the Calgary > maintainers in the last few years :-) > OK, second question... is it time to axe Calgary? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How could we get rid of saved_max_pfn for calgary iommu?
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote: > Hi, Muli > > saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary > could get rid of saved_max_pfn at all. But If this can't work, how > about exporting a calgary tce table size to user space, so that > kexec-tools can simply pass calgary=xxx cmdline to 2nd kernel. As Jon noted, this code is used to so that the TCE table remains consistent between the original and the kexec'd kernel. I see two options: either we hard code the TCE table size to the max so that this bit of code becomes redundant, or we explicitly pass the original table size (or the original max_pfn) to the kexec'd kernel. The first option is more appealing, because I don't think anyone is actually using the TCE table size -- we mostly added it for debugging the IOMMU TCE code at the time -- but since I don't have a Calgary machine anymore, I don't have any way to test it. The second option is uglier but would be fully backward-compatible and less likely to break things. Given that very few people are likely running the latest upstream kernel on Calgary/CalIOC2 machines, I'm inclined towards the first option. > BTW MAINTAINERS file still uses your old email, please update > accordingly. I think you are the first person to actually look up the Calgary maintainers in the last few years :-) Cheers, Muli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] mfd: max8997: use regmap to access registers
Hi,
On 03/06/2014 03:44 AM, Chanwoo Choi wrote:
> This patch has build error as following:
> I added some comment in max8997_irq_init()
> At least, you should test kernel build.
>
> drivers/mfd/max8997-irq.c: In function ‘max8997_irq_init’:
> drivers/mfd/max8997-irq.c:333:3: error: ‘i2c’ undeclared (first use in this
> function)
> drivers/mfd/max8997-irq.c:333:3: note: each undeclared identifier is reported
> only once for each function it appears in
> make[2]: *** [drivers/mfd/max8997-irq.o] Error 1
> make[1]: *** [drivers/mfd] Error 2
> make[1]: *** Waiting for unfinished jobs
>
I have missed to remove reference to unused variable. I will fix it.
Thanks!
Robert Baldyga
Samsung R&D Institute Poland
>
> On 03/05/2014 11:58 PM, Robert Baldyga wrote:
>> This patch modifies max8997 driver and each associated function driver,
>> to use regmap instead of operating directly on i2c bus. It will allow to
>> simplify IRQ handling using regmap-irq.
>>
>> Signed-off-by: Robert Baldyga
>> ---
>>
>> Changelog:
>>
>> v2:
>> - check devm_regmap_init_i2c() return value
>> - use proper register maps for muic and haptic registers in functions
>> max8997_freeze() and max8997_restore()
>> - fix style problems
>>
>> v1: http://www.spinics.net/lists/kernel/msg1700375.html
>>
>> drivers/extcon/extcon-max8997.c | 17 ++---
>> drivers/input/misc/max8997_haptic.c | 33 -
>> drivers/leds/leds-max8997.c | 12 ++--
>> drivers/mfd/max8997-irq.c | 31
>> drivers/mfd/max8997.c | 133
>> ++-
>> drivers/power/max8997_charger.c | 28
>> drivers/regulator/max8997.c | 80 ++---
>> drivers/rtc/rtc-max8997.c | 51 --
>> include/linux/mfd/max8997-private.h | 19 +++--
>> 9 files changed, 227 insertions(+), 177 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-max8997.c
>> b/drivers/extcon/extcon-max8997.c
>> index 6a00464..9abc614 100644
>> --- a/drivers/extcon/extcon-max8997.c
>> +++ b/drivers/extcon/extcon-max8997.c
>> @@ -116,7 +116,7 @@ enum max8997_muic_charger_type {
>>
>> struct max8997_muic_info {
>> struct device *dev;
>> -struct i2c_client *muic;
>> +struct max8997_dev *max8997;
>> struct extcon_dev *edev;
>> int prev_cable_type;
>> int prev_chg_type;
>> @@ -190,7 +190,7 @@ static int max8997_muic_set_debounce_time(struct
>> max8997_muic_info *info,
>> case ADC_DEBOUNCE_TIME_10MS:
>> case ADC_DEBOUNCE_TIME_25MS:
>> case ADC_DEBOUNCE_TIME_38_62MS:
>> -ret = max8997_update_reg(info->muic,
>> +ret = max8997_update_reg(info->max8997->regmap_muic,
>>MAX8997_MUIC_REG_CONTROL3,
>>time << CONTROL3_ADCDBSET_SHIFT,
>>CONTROL3_ADCDBSET_MASK);
>> @@ -228,7 +228,7 @@ static int max8997_muic_set_path(struct
>> max8997_muic_info *info,
>> else
>> ctrl1 = CONTROL1_SW_OPEN;
>>
>> -ret = max8997_update_reg(info->muic,
>> +ret = max8997_update_reg(info->max8997->regmap_muic,
>> MAX8997_MUIC_REG_CONTROL1, ctrl1, COMP_SW_MASK);
>> if (ret < 0) {
>> dev_err(info->dev, "failed to update MUIC register\n");
>> @@ -240,7 +240,7 @@ static int max8997_muic_set_path(struct
>> max8997_muic_info *info,
>> else
>> ctrl2 |= CONTROL2_LOWPWR_MASK; /* LowPwr=1, CPEn=0 */
>>
>> -ret = max8997_update_reg(info->muic,
>> +ret = max8997_update_reg(info->max8997->regmap_muic,
>> MAX8997_MUIC_REG_CONTROL2, ctrl2,
>> CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK);
>> if (ret < 0) {
>> @@ -543,7 +543,8 @@ static void max8997_muic_irq_work(struct work_struct
>> *work)
>> if (info->irq == muic_irqs[i].virq)
>> irq_type = muic_irqs[i].irq;
>>
>> -ret = max8997_bulk_read(info->muic, MAX8997_MUIC_REG_STATUS1,
>> +ret = max8997_bulk_read(info->max8997->regmap_muic,
>> +MAX8997_MUIC_REG_STATUS1,
>> 2, info->status);
>> if (ret) {
>> dev_err(info->dev, "failed to read muic register\n");
>> @@ -605,7 +606,7 @@ static int max8997_muic_detect_dev(struct
>> max8997_muic_info *info)
>> mutex_lock(&info->mutex);
>>
>> /* Read STATUSx register to detect accessory */
>> -ret = max8997_bulk_read(info->muic,
>> +ret = max8997_bulk_read(info->max8997->regmap_muic,
>> MAX8997_MUIC_REG_STATUS1, 2, info->status);
>> if (ret) {
>> dev_err(info->dev, "failed to read MUIC register\n");
>> @@ -667,7 +668,7 @@ static int max8997_muic_probe(struct platform_device
>> *pdev)
>> }
>>
>> info->dev = &pdev->dev;
>> -info->muic = max8997->muic;
>> +info->max8997 = max8997;
>>
>> platform_set_drvdata(pd
Re: [PATCH v2] mfd: max8997: use regmap to access registers
Hi, On 03/05/2014 07:54 PM, Dmitry Torokhov wrote: > Hi Robert, > > On Wed, Mar 05, 2014 at 03:58:17PM +0100, Robert Baldyga wrote: >> >> -int max8997_write_reg(struct i2c_client *i2c, u8 reg, u8 value) >> +int max8997_write_reg(struct regmap *map, u8 reg, u8 value) > > Why don't you make read/write reg to take struct max8997_dev as argument > instead of regmap? regmap seems to be the current implementation du jur, > but that is core's detail, functions do not need to care. > > Thanks. > It's because there are few regmaps in max8997_dev, and read/write reg functions has no way to check which regmap should be used. I think it would be clearer if I remove this functions and use regmap_read and regmap_write instead, because there is no particular purpose for them. Best regards Robert Baldyga Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
On 3/5/2014 8:13 PM, Suravee Suthikulanit wrote: On 3/5/2014 3:24 PM, Bjorn Helgaas wrote: [+cc linux-acpi] On Wed, Mar 5, 2014 at 2:06 PM, wrote: From: Suravee Suthikulpanit The current code only supports upto AMD hostbridge for family11h. This causes PCI numa_node information to be reported incorrectly for newer family with multi sockets. Where is the incorrect reporting? In ACPI tables? Is this patch a way to cover up firmware defects in the ACPI description? Or is this for machines without ACPI (it seems unlikely that machines with new AMD processors would not have ACPI)? This is incorrectly reported in the sysfs for each PCI device (e.g. /devices/pci:50/:50:00.2/numa_node). Without the patch, they return -1. In file arch/x86/pci/acpi.c, in function pci_acpi_scan_root(), it is queries the node information as following: #ifdef CONFIG_ACPI_NUMA pxm = acpi_get_pxm(device->handle); if (pxm >= 0) node = pxm_to_node(pxm); if (node != -1) set_mp_bus_to_node(busnum, node); else #endif node = get_mp_bus_to_node(busnum); In this case, I see that the acpi_get_pxm() returns -1. Therefore, it falls back to using the node information in mp_bus_to_node[]. So, without this patch, it would also returning -1. Also, the spec mentioned that the _PXM is optional, so I am not sure if this is a firmware bug. Suravee I am not quite familiar with the ACPI for this part. However, after taking a look at the code (in driver/acpi/pci_root.c: acpi_pci_root_add()), I believe it's trying to locate _PXM method in the DSDT table, in which I don't see any _PXM methods. I'm still trying to debug this issue, any suggestions would be appreciated. Thank you, Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: Allow building for tile
Tested by building perf:
- Cross-compiled for tile on x86_64
- Built natively on tile
Signed-off-by: Zhigang Lu
Signed-off-by: Chris Metcalf
---
tools/perf/config/Makefile.arch | 3 ++-
tools/perf/perf.h | 8
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
index fef8ae9..4b06719 100644
--- a/tools/perf/config/Makefile.arch
+++ b/tools/perf/config/Makefile.arch
@@ -5,7 +5,8 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/ -e
s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
- -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
+ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
+ -e s/tile.*/tile/ )
# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index e84fa26..75caf68 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -139,6 +139,14 @@
#define CPUINFO_PROC "core ID"
#endif
+#ifdef __tile__
+#define mb() asm volatile ("mf" ::: "memory")
+#define wmb() asm volatile ("mf" ::: "memory")
+#define rmb() asm volatile ("mf" ::: "memory")
+#define cpu_relax()asm volatile ("mfspr zero, PASS" ::: "memory")
+#define CPUINFO_PROC"model name"
+#endif
+
#define barrier() asm volatile ("" ::: "memory")
#ifndef cpu_relax
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
On 05/03/14 11:17 PM, Robert Hancock wrote: I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. Bisecting between 3.13.4 and 3.13.5 gives me this: c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit commit c8f44f98901994832ccecb87c3dd7900274b699a Author: Sarah Sharp Date: Fri Jan 31 11:26:25 2014 -0800 xhci 1.0: Limit arbitrarily-aligned scatter gather. commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called "TD fragment" rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma", it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp Tested-by: Mark Lord Cc: David Laight Cc: Bjørn Mork Cc: Freddy Xin Cc: Ming Lei Signed-off-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux does not use more than the startup RAM under Hyper-V with dynamic memory enabled
On 3/6/2014 1:20 AM, Brian Wong wrote: I'm new to LKML, so please don't be too hard on me :) I'm running Gentoo Linux under Microsoft Client Hyper-V on Windows 8.1 Pro, and I've noticed some odd behavior with respect to dynamic memory (aka memory ballooning). The system will never use more than the startup memory defined in the vitual machine's settings. For example, if I set the startup memory to 512 MB, and enable dynamic memory with a minimum of 512 MB and a maximum of 8192 MB, the system will never allocate than 512 MB of physical memory, despite Hyper-V assigning more memory to the VM and the added memory being visible in the output of "free" and "htop". Attempting to use more memory causes the system to start paging to swap, rather than actually allocating the memory above the startup memory assigned to the VM. The kernel is built with the full set of Hyper-V drivers, including the key "Microsoft Hyper-V Balloon Driver" as well as memory hot-add and hot-remove functionality. This is happening with both the Gentoo-patched 3.10.32 kernel and the vanilla 3.12.5 kernel. The host machine has a total of 24 GB of memory. For now, I am working around the issue by starting the VM with the startup memory set to the maximum and letting Hyper-V take the usused memory back when it is not in use. The VM will then get the extra memory when it needs it. Have I encountered a bug in the Hyper-V balloon driver? Just a correction: the vanilla kernel version is 3.13.5, not 3.12.5. Sorry for any confusion. -- Brian Wong http://www.fierydragonlord.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] tile/perf: Support perf_events on tilegx and tilepro
Add perf support for tile architecture.
Signed-off-by: Zhigang Lu
Signed-off-by: Chris Metcalf
---
arch/tile/Kconfig |2 +
arch/tile/include/asm/perf_event.h | 22 +
arch/tile/kernel/Makefile |1 +
arch/tile/kernel/irq.c | 18 +
arch/tile/kernel/perf_event.c | 1005
5 files changed, 1048 insertions(+)
create mode 100644 arch/tile/include/asm/perf_event.h
create mode 100644 arch/tile/kernel/perf_event.c
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 3067b15..31c8c62 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -3,6 +3,8 @@
config TILE
def_bool y
+ select HAVE_PERF_EVENTS
+ select USE_PMC if PERF_EVENTS
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select HAVE_KVM if !TILEGX
diff --git a/arch/tile/include/asm/perf_event.h
b/arch/tile/include/asm/perf_event.h
new file mode 100644
index 000..59c5b16
--- /dev/null
+++ b/arch/tile/include/asm/perf_event.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2014 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * 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, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ASM_TILE_PERF_EVENT_H
+#define _ASM_TILE_PERF_EVENT_H
+
+#include
+DECLARE_PER_CPU(u64, perf_irqs);
+
+unsigned long handle_syscall_link_address(void);
+#endif /* _ASM_TILE_PERF_EVENT_H */
diff --git a/arch/tile/kernel/Makefile b/arch/tile/kernel/Makefile
index 71d8353..21f77bf 100644
--- a/arch/tile/kernel/Makefile
+++ b/arch/tile/kernel/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PCI) += pci_gx.o
else
obj-$(CONFIG_PCI) += pci.o
endif
+obj-$(CONFIG_PERF_EVENTS) += perf_event.o
obj-$(CONFIG_USE_PMC) += pmc.o
obj-$(CONFIG_TILE_USB) += usb.o
obj-$(CONFIG_TILE_HVGLUE_TRACE)+= hvglue_trace.o
diff --git a/arch/tile/kernel/irq.c b/arch/tile/kernel/irq.c
index 0586fdb..906a76b 100644
--- a/arch/tile/kernel/irq.c
+++ b/arch/tile/kernel/irq.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/* Bit-flag stored in irq_desc->chip_data to indicate HW-cleared irqs. */
#define IS_HW_CLEARED 1
@@ -261,6 +262,23 @@ void ack_bad_irq(unsigned int irq)
}
/*
+ * /proc/interrupts printing:
+ */
+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+#ifdef CONFIG_PERF_EVENTS
+ int i;
+
+ seq_printf(p, "%*s: ", prec, "PMI");
+
+ for_each_online_cpu(i)
+ seq_printf(p, "%10llu ", per_cpu(perf_irqs, i));
+ seq_puts(p, " perf_events\n");
+#endif
+ return 0;
+}
+
+/*
* Generic, controller-independent functions:
*/
diff --git a/arch/tile/kernel/perf_event.c b/arch/tile/kernel/perf_event.c
new file mode 100644
index 000..53ddb5d
--- /dev/null
+++ b/arch/tile/kernel/perf_event.c
@@ -0,0 +1,1005 @@
+/*
+ * Copyright 2014 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * 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, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ *
+ *
+ * Perf_events support for Tile processor.
+ *
+ * This code is based upon the x86 perf event
+ * code, which is:
+ *
+ * Copyright (C) 2008 Thomas Gleixner
+ * Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
+ * Copyright (C) 2009 Jaswinder Singh Rajput
+ * Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
+ * Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
+ * Copyright (C) 2009 Intel Corporation,
+ * Copyright (C) 2009 Google, Inc., Stephane Eranian
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TILE_MAX_COUNTERS 4
+
+#define PERF_COUNT_0_IDX 0
+#define PERF_COUNT_1_IDX 1
+#define AUX_PERF_COUNT_0_IDX 2
+#define AUX_PERF_COUNT_1_IDX 3
+
+struct cpu_hw_events {
+ int n_events;
+ struct perf_event *events[TILE_MAX_COUNTERS]; /* counter order */
+ struct perf_event *event_list[TILE_MAX_COUNTERS]; /* enabled
+ order */
+ int assign[TILE_MAX_COUN
Linux does not use more than the startup RAM under Hyper-V with dynamic memory enabled
I'm new to LKML, so please don't be too hard on me :) I'm running Gentoo Linux under Microsoft Client Hyper-V on Windows 8.1 Pro, and I've noticed some odd behavior with respect to dynamic memory (aka memory ballooning). The system will never use more than the startup memory defined in the vitual machine's settings. For example, if I set the startup memory to 512 MB, and enable dynamic memory with a minimum of 512 MB and a maximum of 8192 MB, the system will never allocate than 512 MB of physical memory, despite Hyper-V assigning more memory to the VM and the added memory being visible in the output of "free" and "htop". Attempting to use more memory causes the system to start paging to swap, rather than actually allocating the memory above the startup memory assigned to the VM. The kernel is built with the full set of Hyper-V drivers, including the key "Microsoft Hyper-V Balloon Driver" as well as memory hot-add and hot-remove functionality. This is happening with both the Gentoo-patched 3.10.32 kernel and the vanilla 3.12.5 kernel. The host machine has a total of 24 GB of memory. For now, I am working around the issue by starting the VM with the startup memory set to the maximum and letting Hyper-V take the usused memory back when it is not in use. The VM will then get the extra memory when it needs it. Have I encountered a bug in the Hyper-V balloon driver? -- Brian Wong http://www.fierydragonlord.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: range: remove unnecessary sanity check
On Thu, Mar 06, 2014 at 01:07:03AM -0500, Fred Akers wrote: > This check is unnecessary because range_table will always be > initialized to range_unknown by comedi_device_postconfig() for > drivers that do not initialize range_table or range_table_list > > Signed-off-by: Fred Akers > --- > Apply this after first patch What "first" patch? If you have patches that need a sequence, then send a series of patches, all numbered, like git will export for you, so I know for sure that I've gotten them all, and that they are in the correct order. You don't want me to have to guess :) Care to try again? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: usbip: userspace: increase version to 2.0
On Tue, Mar 4, 2014 at 9:20 PM, Greg KH wrote: > On Tue, Mar 04, 2014 at 09:16:39PM +0200, Valentina Manea wrote: >> Signed-off-by: Valentina Manea >> --- >> drivers/staging/usbip/userspace/configure.ac | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/usbip/userspace/configure.ac >> b/drivers/staging/usbip/userspace/configure.ac >> index 25bf160..607d05c 100644 >> --- a/drivers/staging/usbip/userspace/configure.ac >> +++ b/drivers/staging/usbip/userspace/configure.ac >> @@ -1,7 +1,7 @@ >> dnl Process this file with autoconf to produce a configure script. >> >> AC_PREREQ(2.59) >> -AC_INIT([usbip-utils], [1.1.1], [linux-...@vger.kernel.org]) >> +AC_INIT([usbip-utils], [2.0], [linux-...@vger.kernel.org]) > > Why? > > What does this mean? What warrents the version change? Why have a > version at all? > > thanks, > > greg k-h This was part of an effort to "refresh" USB/IP by moving userspace out of kernel.git. Since some major changes have been made (libudev migration), Andy (cc'ed) and me thought it was worth to be promoted to version 2.0. Thanks, Valentina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: dgap: remove useless cast on kzalloc()
coccinelle warning:
drivers/staging/dgap/dgap.c:782:3-7: WARNING:
casting value returned by k[cmz]alloc to (char *) is useless.
drivers/staging/dgap/dgap.c:776:2-16: WARNING:
casting value returned by k[cmz]alloc to (struct board_t *) is useless.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index cbce457..1adcd13 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -773,13 +773,13 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
/* get the board structure and prep it */
brd = dgap_Board[dgap_NumBoards] =
- (struct board_t *) kzalloc(sizeof(struct board_t), GFP_KERNEL);
+ kzalloc(sizeof(struct board_t), GFP_KERNEL);
if (!brd)
return -ENOMEM;
/* make a temporary message buffer for the boot messages */
brd->msgbuf = brd->msgbuf_head =
- (char *) kzalloc(sizeof(char) * 8192, GFP_KERNEL);
+ kzalloc(sizeof(char) * 8192, GFP_KERNEL);
if (!brd->msgbuf) {
kfree(brd);
return -ENOMEM;
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] tile: Enable NMIs on return from handle_nmi() without errors
NMI interrupts mask ALL interrupts before calling the handler,
so we need to unmask NMIs according to the value handle_nmi() returns.
If it returns zero, the NMIs should be re-enabled; if it returns
a non-zero error, the NMIs should be disabled.
Signed-off-by: Zhigang Lu
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/intvec_32.S | 11 +++
arch/tile/kernel/intvec_64.S | 11 ++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 605ffbd..cdbda45 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -946,6 +946,13 @@ STD_ENTRY(interrupt_return)
bzt r30, .Lrestore_regs
3:
+ /* We are relying on INT_PERF_COUNT at 33, and AUX_PERF_COUNT at 48 */
+ {
+moveli r0, lo16(1 << (INT_PERF_COUNT - 32))
+bz r31, .Lrestore_regs
+ }
+ aulir0, r0, ha16(1 << (INT_AUX_PERF_COUNT - 32))
+ mtspr SPR_INTERRUPT_MASK_RESET_K_1, r0
/*
* We now commit to returning from this interrupt, since we will be
@@ -1171,6 +1178,10 @@ handle_nmi:
PTREGS_PTR(r0, PTREGS_OFFSET_BASE)
}
FEEDBACK_REENTER(handle_nmi)
+ {
+movei r30, 1
+seqr31, r0, zero
+ }
j interrupt_return
STD_ENDPROC(handle_nmi)
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index 8f892a5..5b67efc 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -971,6 +971,15 @@ STD_ENTRY(interrupt_return)
beqzt r30, .Lrestore_regs
3:
+#if INT_PERF_COUNT + 1 != INT_AUX_PERF_COUNT
+# error Bad interrupt assumption
+#endif
+ {
+movei r0, 3 /* two adjacent bits for the PERF_COUNT mask */
+beqz r31, .Lrestore_regs
+ }
+ shlir0, r0, INT_PERF_COUNT
+ mtspr SPR_INTERRUPT_MASK_RESET_K, r0
/*
* We now commit to returning from this interrupt, since we will be
@@ -1187,7 +1196,7 @@ handle_nmi:
FEEDBACK_REENTER(handle_nmi)
{
movei r30, 1
-move r31, r0
+cmpeq r31, r0, zero
}
j interrupt_return
STD_ENDPROC(handle_nmi)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] staging: usbip: userspace: migrate usbip_bind to libudev
On Wed, Mar 5, 2014 at 12:15 PM, Dan Carpenter wrote: > On Wed, Mar 05, 2014 at 12:42:59PM +0300, Dan Carpenter wrote: >> On Tue, Mar 04, 2014 at 09:10:41PM +0200, Valentina Manea wrote: >> > diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_common.h >> > b/drivers/staging/usbip/userspace/libsrc/usbip_common.h >> > index 2cb81b3..565ac78 100644 >> > --- a/drivers/staging/usbip/userspace/libsrc/usbip_common.h >> > +++ b/drivers/staging/usbip/userspace/libsrc/usbip_common.h >> > @@ -29,6 +29,15 @@ >> > #define USBIP_HOST_DRV_NAME"usbip-host" >> > #define USBIP_VHCI_DRV_NAME"vhci_hcd" >> > >> > +/* sysfs constants */ >> > +#define SYSFS_MNT_PATH "/sys" >> > +#define SYSFS_BUS_NAME "bus" >> > +#define SYSFS_BUS_TYPE "usb" >> > +#define SYSFS_DRIVERS_NAME "drivers" >> >> What on earth??? I don't even want to review any further than this. >> >> Groan No. no no no no no. >> > > I overreacted. This stuff was already in the original code, and this > change just moves it around. > > Fine fine. These patch set seem ok with me. > > regards, > dan carpenter > > Indeed, there are improvements than can be made to the code but I figured doing them all in just one patch series would be a step too big. This should be work for future patches. Thanks for your feedback. Valentina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tile: Add support for handling PMC hardware
The PMC module is used by perf_events, oprofile and watchdogs.
Signed-off-by: Zhigang Lu
Signed-off-by: Chris Metcalf
---
arch/tile/Kconfig| 4 ++
arch/tile/include/asm/pmc.h | 64 +++
arch/tile/kernel/Makefile| 1 +
arch/tile/kernel/intvec_32.S | 13 ++---
arch/tile/kernel/intvec_64.S | 13 ++---
arch/tile/kernel/pmc.c | 121 +++
6 files changed, 204 insertions(+), 12 deletions(-)
create mode 100644 arch/tile/include/asm/pmc.h
create mode 100644 arch/tile/kernel/pmc.c
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index b3692ce..3067b15 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -66,6 +66,10 @@ config HUGETLB_SUPER_PAGES
config GENERIC_TIME_VSYSCALL
def_bool y
+# Enable PMC if PERF_EVENTS, OPROFILE, or WATCHPOINTS are enabled.
+config USE_PMC
+ bool
+
# FIXME: tilegx can implement a more efficient rwsem.
config RWSEM_GENERIC_SPINLOCK
def_bool y
diff --git a/arch/tile/include/asm/pmc.h b/arch/tile/include/asm/pmc.h
new file mode 100644
index 000..7ae3956
--- /dev/null
+++ b/arch/tile/include/asm/pmc.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2014 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * 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, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ASM_TILE_PMC_H
+#define _ASM_TILE_PMC_H
+
+#include
+
+#define TILE_BASE_COUNTERS 2
+
+/* Bitfields below are derived from SPR PERF_COUNT_CTL*/
+#ifndef __tilegx__
+/* PERF_COUNT_CTL on TILEPro */
+#define TILE_CTL_EXCL_USER (1 << 7) /* exclude user level */
+#define TILE_CTL_EXCL_KERNEL (1 << 8) /* exclude kernel level */
+#define TILE_CTL_EXCL_HV (1 << 9) /* exclude hypervisor level */
+
+#define TILE_SEL_MASK 0x7f/* 7 bits for event SEL,
+ COUNT_0_SEL */
+#define TILE_PLM_MASK 0x780 /* 4 bits priv level msks,
+ COUNT_0_MASK*/
+#define TILE_EVENT_MASK(TILE_SEL_MASK | TILE_PLM_MASK)
+
+#else /* __tilegx__*/
+/* PERF_COUNT_CTL on TILEGx*/
+#define TILE_CTL_EXCL_USER (1 << 10) /* exclude user level */
+#define TILE_CTL_EXCL_KERNEL (1 << 11) /* exclude kernel level */
+#define TILE_CTL_EXCL_HV (1 << 12) /* exclude hypervisor level */
+
+#define TILE_SEL_MASK 0x3f/* 6 bits for event SEL,
+ COUNT_0_SEL*/
+#define TILE_BOX_MASK 0x1c0 /* 3 bits box msks,
+ COUNT_0_BOX */
+#define TILE_PLM_MASK 0x3c00 /* 4 bits priv level msks,
+ COUNT_0_MASK */
+#define TILE_EVENT_MASK(TILE_SEL_MASK | TILE_BOX_MASK | TILE_PLM_MASK)
+#endif /* __tilegx__*/
+
+/* Takes register and fault number. Returns error to disable the interrupt. */
+typedef int (*perf_irq_t)(struct pt_regs *, int);
+
+int userspace_perf_handler(struct pt_regs *regs, int fault);
+
+perf_irq_t reserve_pmc_hardware(perf_irq_t new_perf_irq);
+void release_pmc_hardware(void);
+
+unsigned long pmc_get_overflow(void);
+void pmc_ack_overflow(unsigned long status);
+
+void unmask_pmc_interrupts(void);
+void mask_pmc_interrupts(void);
+
+#endif /* _ASM_TILE_PMC_H */
diff --git a/arch/tile/kernel/Makefile b/arch/tile/kernel/Makefile
index 27a2bf3..71d8353 100644
--- a/arch/tile/kernel/Makefile
+++ b/arch/tile/kernel/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PCI) += pci_gx.o
else
obj-$(CONFIG_PCI) += pci.o
endif
+obj-$(CONFIG_USE_PMC) += pmc.o
obj-$(CONFIG_TILE_USB) += usb.o
obj-$(CONFIG_TILE_HVGLUE_TRACE)+= hvglue_trace.o
obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o mcount_64.o
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 2cbe6d5..605ffbd 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -313,13 +313,13 @@ intvec_\vecname:
movei r3, 0
}
.else
- .ifc \c_routine, op_handle_perf_interrupt
+ .ifc \c_routine, handle_perf_interrupt
{
mfspr r2, PERF_COUNT_STS
movei r3, -1 /* not used, but set for consistency */
}
.else
- .ifc \c_routine, op_handle_aux_perf_interrupt
+ .ifc \c_routine, handle_perf_interrupt
{
mfspr r2, AUX_PERF_COUNT_STS
movei r3, -1 /* not used, but set for consistency */
@@ -1835,8 +1835,9 @@ int_unalign:
/* Include .intrpt array of interrupt vectors */
.section ".intrpt", "ax"
-#define op_han
linux-next: build warning after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (i386 defconfig)
produced this warning:
arch/x86/kernel/cpu/perf_event_intel_uncore.c: In function
'snb_uncore_imc_init_box':
arch/x86/kernel/cpu/perf_event_intel_uncore.c:1725:15: warning: unused variable
'addr_hi' [-Wunused-variable]
Introduced by commit b9e1ab6d4c05 ("perf/x86/uncore: add SNB/IVB/HSW
client uncore memory controller support") from the tip tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpVlvjnUJ7sh.pgp
Description: PGP signature
[PATCH 0/4] tile: Add perf_events support for tile
From: Zhigang Lu This patchset adds perf support for tile architecture. The code is based on x86 perf event code, and it has been tested on tile for 2 years. Zhigang Lu (4): tile: Add support for handling PMC hardware tile: Enable NMIs on return from handle_nmi() without errors tile/perf: Support perf_events on tilegx and tilepro perf tools: Allow building for tile arch/tile/Kconfig |6 + arch/tile/include/asm/perf_event.h | 22 + arch/tile/include/asm/pmc.h| 64 +++ arch/tile/kernel/Makefile |2 + arch/tile/kernel/intvec_32.S | 24 +- arch/tile/kernel/intvec_64.S | 24 +- arch/tile/kernel/irq.c | 18 + arch/tile/kernel/perf_event.c | 1005 arch/tile/kernel/pmc.c | 121 + tools/perf/config/Makefile.arch|3 +- tools/perf/perf.h |8 + 11 files changed, 1283 insertions(+), 14 deletions(-) create mode 100644 arch/tile/include/asm/perf_event.h create mode 100644 arch/tile/include/asm/pmc.h create mode 100644 arch/tile/kernel/perf_event.c create mode 100644 arch/tile/kernel/pmc.c -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging: usbip: claim ports used by shared devices
A device should not be able to be used concurrently both by
the server and the client. Claiming the port used by the
shared device ensures no interface drivers bind to it and
that it is not usable from the server.
Signed-off-by: Valentina Manea
---
Changes since v1:
* add commit description
* move struct dev_state definition back to usb/core/devio.c
drivers/staging/usbip/stub_dev.c | 22 ++
drivers/usb/core/hub.c | 2 ++
drivers/usb/core/usb.h | 4
include/linux/usb.h | 7 +++
4 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index ee899f0..952743c 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -339,6 +339,7 @@ static int stub_probe(struct usb_device *udev)
const char *udev_busid = dev_name(&udev->dev);
int err = 0;
struct bus_id_priv *busid_priv;
+ int rc;
dev_dbg(&udev->dev, "Enter\n");
@@ -388,6 +389,18 @@ static int stub_probe(struct usb_device *udev)
busid_priv->sdev = sdev;
busid_priv->udev = udev;
+ /*
+* Claim this hub port.
+* It doesn't matter what value we pass as owner
+* (struct dev_state) as long as it is unique.
+*/
+ rc = usb_hub_claim_port(udev->parent, udev->portnum,
+ (struct dev_state *) udev);
+ if (rc) {
+ dev_dbg(&udev->dev, "unable to claim port\n");
+ return rc;
+ }
+
err = stub_add_files(&udev->dev);
if (err) {
dev_err(&udev->dev, "stub_add_files for %s\n", udev_busid);
@@ -424,6 +437,7 @@ static void stub_disconnect(struct usb_device *udev)
struct stub_device *sdev;
const char *udev_busid = dev_name(&udev->dev);
struct bus_id_priv *busid_priv;
+ int rc;
dev_dbg(&udev->dev, "Enter\n");
@@ -448,6 +462,14 @@ static void stub_disconnect(struct usb_device *udev)
*/
stub_remove_files(&udev->dev);
+ /* release port */
+ rc = usb_hub_release_port(udev->parent, udev->portnum,
+ (struct dev_state *) udev);
+ if (rc) {
+ dev_dbg(&udev->dev, "unable to release port\n");
+ return;
+ }
+
/* If usb reset is called from event handler */
if (busid_priv->sdev->ud.eh == current)
return;
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64ea219..e484933 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1819,6 +1819,7 @@ int usb_hub_claim_port(struct usb_device *hdev, unsigned
port1,
*powner = owner;
return rc;
}
+EXPORT_SYMBOL_GPL(usb_hub_claim_port);
int usb_hub_release_port(struct usb_device *hdev, unsigned port1,
struct dev_state *owner)
@@ -1834,6 +1835,7 @@ int usb_hub_release_port(struct usb_device *hdev,
unsigned port1,
*powner = NULL;
return rc;
}
+EXPORT_SYMBOL_GPL(usb_hub_release_port);
void usb_hub_release_all_ports(struct usb_device *hdev, struct dev_state
*owner)
{
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 8238577..222bbd2 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -57,10 +57,6 @@ extern int usb_match_device(struct usb_device *dev,
extern void usb_forced_unbind_intf(struct usb_interface *intf);
extern void usb_rebind_intf(struct usb_interface *intf);
-extern int usb_hub_claim_port(struct usb_device *hdev, unsigned port,
- struct dev_state *owner);
-extern int usb_hub_release_port(struct usb_device *hdev, unsigned port,
- struct dev_state *owner);
extern void usb_hub_release_all_ports(struct usb_device *hdev,
struct dev_state *owner);
extern bool usb_device_is_owned(struct usb_device *udev);
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 22de4af..140a6a3 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -366,6 +366,8 @@ struct usb_bus {
#endif
};
+struct dev_state;
+
/* --- */
struct usb_tt;
@@ -749,6 +751,11 @@ extern struct usb_host_interface *usb_find_alt_setting(
unsigned int iface_num,
unsigned int alt_num);
+/* port claiming functions */
+int usb_hub_claim_port(struct usb_device *hdev, unsigned port1,
+ struct dev_state *owner);
+int usb_hub_release_port(struct usb_device *hdev, unsigned port1,
+ struct dev_state *owner);
/**
* usb_make_path - returns stable device path in the usb tree
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: comedi: range: remove unnecessary sanity check
This check is unnecessary because range_table will always be
initialized to range_unknown by comedi_device_postconfig() for
drivers that do not initialize range_table or range_table_list
Signed-off-by: Fred Akers
---
Apply this after first patch
drivers/staging/comedi/range.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c
index c4bb13b..b684954 100644
--- a/drivers/staging/comedi/range.c
+++ b/drivers/staging/comedi/range.c
@@ -143,10 +143,6 @@ int comedi_check_chanlist(struct comedi_subdevice *s, int
n,
unsigned int chanspec;
int chan, range_len, i;
- if (!s->range_table && !s->range_table_list) {
- dev_err(dev->class_dev, "(bug) no range type list!\n");
- return -EINVAL;
- }
for (i = 0; i < n; i++) {
chanspec = chanlist[i];
chan = CR_CHAN(chanspec);
--
1.8.5.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: USB remote wakeup through gpio interrupt
> > Hi Peter, > > Thanks for your reply. > > I can use pm_runtime_get in interrupt handler, but i am not getting your > idea of using pm_runtime_put in interrupt handler? > After your device finishes using usb, it may need to toggle gpio to trigger interrupt, and you can suspend usb at this interrupt handler using pm_runtime_put. > My device is usb telephony modem, which will give interrupt through gpio > when call comes. so at that time i want to wakeup the usb functionality > as remote wakeup is not working properly. > > will pm_runtime_put suspend the device immidiately or it will not suspend > the device till it is in use? > It should suspend device immediately if you have not set any timeout value for runtime. You call pm_runtime_put, it means you want to stop using device, the host will stop sending SOF after it finishes suspending bus routine. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 4/4] MAINTAINERS: entry for APM X-Gene PCIe host driver
Add entry for AppliedMicro X-Gene PCIe host driver. Signed-off-by: Tanmay Inamdar --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e1297ff..80b7fe5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6629,6 +6629,13 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/pci/host/*designware* +PCI DRIVER FOR APPLIEDMICRO XGENE +M: Tanmay Inamdar +L: linux-...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org +S: Maintained +F: drivers/pci/host/pci-xgene.c + PCMCIA SUBSYSTEM P: Linux PCMCIA Team L: linux-pcm...@lists.infradead.org -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/4] dt-bindings: pci: xgene pcie device tree bindings
This patch adds the bindings for X-Gene PCIe driver. The driver resides
under 'drivers/pci/host/pci-xgene.c' file.
Signed-off-by: Tanmay Inamdar
---
.../devicetree/bindings/pci/xgene-pci.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/xgene-pci.txt
b/Documentation/devicetree/bindings/pci/xgene-pci.txt
new file mode 100644
index 000..e19fdb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xgene-pci.txt
@@ -0,0 +1,52 @@
+* AppliedMicro X-Gene PCIe interface
+
+Required properties:
+- device_type: set to "pci"
+- compatible: should contain "apm,xgene-pcie" to identify the core.
+- reg: A list of physical base address and length for each set of controller
+ registers. Must contain an entry for each entry in the reg-names
+ property.
+- reg-names: Must include the following entries:
+ "csr": controller configuration registers.
+ "cfg": pcie configuration space registers.
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- ranges: ranges for the outbound memory, I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+ to define the mapping of the PCIe interface to interrupt
+ numbers.
+- clocks: from common clock binding: handle to pci clock.
+
+Optional properties:
+- status: Either "ok" or "disabled".
+
+Example:
+
+SoC specific DT Entry:
+ pcie0: pcie@1f2b {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b 0x0 0x0001 /* Controller
registers */
+ 0xe0 0xd000 0x0 0x0020>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x0100 0x00 0x 0xe0 0x 0x00
0x0001 /* io */
+ 0x0200 0x00 0x1000 0xe0 0x1000 0x00
0x8000>; /* mem */
+ dma-ranges = <0x4200 0x40 0x 0x40 0x 0x40
0x>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
+0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
+0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
+0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ clocks = <&pcie0clk 0>;
+ };
+
+Board specific DT Entry:
+ &pcie0 {
+ status = "ok";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/4] arm64: dts: APM X-Gene PCIe device tree nodes
This patch adds the device tree nodes for APM X-Gene PCIe controller and
PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
nodes are added.
Signed-off-by: Tanmay Inamdar
---
arch/arm64/boot/dts/apm-mustang.dts |8 ++
arch/arm64/boot/dts/apm-storm.dtsi | 155 +++
2 files changed, 163 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts
b/arch/arm64/boot/dts/apm-mustang.dts
index 1247ca1..507b6c9 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -24,3 +24,11 @@
reg = < 0x1 0x 0x0 0x8000 >; /* Updated by
bootloader */
};
};
+
+&pcie0clk {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..6011d25 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -176,6 +176,161 @@
reg-names = "csr-reg";
clock-output-names = "eth8clk";
};
+
+ pcie0clk: pcie0clk@1f2bc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2bc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie0clk";
+ };
+
+ pcie1clk: pcie1clk@1f2cc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2cc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie1clk";
+ };
+
+ pcie2clk: pcie2clk@1f2dc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2dc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie2clk";
+ };
+
+ pcie3clk: pcie3clk@1f50c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f50c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie3clk";
+ };
+
+ pcie4clk: pcie4clk@1f51c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f51c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie4clk";
+ };
+ };
+
+ pcie0: pcie@1f2b {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b 0x0 0x0001 /* Controller
registers */
+ 0xe0 0xd000 0x0 0x0020>; /* PCI config
space */
+ reg-names = "csr", "cfg";
+ ranges = <0x0100 0x00 0x 0xe0 0x
0x00 0x0001 /* io */
+ 0x0200 0x00 0x1000 0xe0 0x1000
0x00 0x8000>; /* mem */
+ dma-ranges = <0x4200 0x40 0x 0x40
0x 0x40 0x>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
+0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
+0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
+0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ clocks = <&pcie0clk 0>;
+ };
+
+
[PATCH v4 0/4] APM X-Gene PCIe controller
This patch adds support for AppliedMicro X-Gene PCIe host controller. The driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint cards. X-Gene PCIe controller driver has depedency on the pcie arm64 arch support. Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and support for creating generic pcie bridge from device tree. Liviu's patches are available here 1. https://lkml.org/lkml/2014/3/5/179 2. https://lkml.org/lkml/2014/3/5/41 If someone wishes to test PCIe on X-Gene with this patch set, above mentioned patches from Liviu must be applied before the patches in this patch set. changes since V3: 1. remove 'struct hw_pci' and supporting ops in hw_pci 2. add code to create the host bridge from dts 3. add code to scan the the host bridge 4. modify outbound windows setup function to get resource information from 'bridge->windows' 5. add compatible string in pcie dts node with current X-Gene SOC name. changes since V2: 1. redefined each PCI port in different PCI domain correctly. 2. removed setup_lane and setup_link functions from driver. 3. removed scan_bus wrapper and set_primary_bus hack. 4. added pci_ioremap_io for io resources. changes since V1: 1. added PCI domain support 2. reading cpu and pci addresses from device tree to configure regions. 3. got rid of unnecessary wrappers for readl and writel. 4. got rid of endpoint configuration code. 5. added 'dma-ranges' property support to read inbound region configuration. 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c' 7. dropped 'clock-names' property from bindings 8. added comments whereever requested. Tanmay Inamdar (4): pci: APM X-Gene PCIe controller driver arm64: dts: APM X-Gene PCIe device tree nodes dt-bindings: pci: xgene pcie device tree bindings MAINTAINERS: entry for APM X-Gene PCIe host driver .../devicetree/bindings/pci/xgene-pci.txt | 52 ++ MAINTAINERS|7 + arch/arm64/boot/dts/apm-mustang.dts|8 + arch/arm64/boot/dts/apm-storm.dtsi | 155 drivers/pci/host/Kconfig | 10 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-xgene.c | 739 7 files changed, 972 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt create mode 100644 drivers/pci/host/pci-xgene.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] pci: APM X-Gene PCIe controller driver
This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.
X-Gene SOC supports maximum 5 PCIe ports.
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile|1 +
drivers/pci/host/pci-xgene.c | 739 ++
3 files changed, 750 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..19ce97d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -33,4 +33,14 @@ config PCI_RCAR_GEN2
There are 3 internal PCI controllers available with a single
built-in EHCI/OHCI host controller present on each one.
+config PCI_XGENE
+ bool "X-Gene PCIe controller"
+ depends on ARCH_XGENE
+ depends on OF
+ select PCIEPORTBUS
+ help
+ Say Y here if you want internal PCI support on APM X-Gene SoC.
+ There are 5 internal PCIe ports available. Each port is GEN3 capable
+ and have varied lanes from x1 to x8.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..34c7c36 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
+obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
new file mode 100644
index 000..ca16d1b
--- /dev/null
+++ b/drivers/pci/host/pci-xgene.c
@@ -0,0 +1,739 @@
+/**
+ * APM X-Gene PCIe Driver
+ *
+ * Copyright (c) 2013 Applied Micro Circuits Corporation.
+ *
+ * Author: Tanmay Inamdar .
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PCIECORE_LTSSM 0x4c
+#define PCIECORE_CTLANDSTATUS 0x50
+#define INTXSTATUSMASK 0x6c
+#define PIM1_1L0x80
+#define IBAR2 0x98
+#define IR2MSK 0x9c
+#define PIM2_1L0xa0
+#define IBAR3L 0xb4
+#define IR3MSKL0xbc
+#define PIM3_1L0xc4
+#define OMR1BARL 0x100
+#define OMR2BARL 0x118
+#define OMR3BARL 0x130
+#define CFGBARL0x154
+#define CFGBARH0x158
+#define CFGCTL 0x15c
+#define RTDID 0x160
+#define BRIDGE_CFG_0 0x2000
+#define BRIDGE_CFG_1 0x2004
+#define BRIDGE_CFG_4 0x2010
+#define BRIDGE_CFG_32 0x2030
+#define BRIDGE_CFG_14 0x2038
+#define BRIDGE_CTRL_1 0x2204
+#define BRIDGE_CTRL_2 0x2208
+#define BRIDGE_CTRL_5 0x2214
+#define BRIDGE_STATUS_00x2600
+#define MEM_RAM_SHUTDOWN0xd070
+#define BLOCK_MEM_RDY 0xd074
+
+#define DEVICE_PORT_TYPE_MASK 0x03c0
+#define PM_FORCE_RP_MODE_MASK 0x0400
+#define SWITCH_PORT_MODE_MASK 0x0800
+#define CLASS_CODE_MASK0xff00
+#define LINK_UP_MASK 0x0100
+#define AER_OPTIONAL_ERROR_EN 0xffc0
+#define XGENE_PCIE_DEV_CTRL0x2f0f
+#define AXI_EP_CFG_ACCESS 0x1
+#define ENABLE_ASPM0x0800
+#define XGENE_PORT_TYPE_RC 0x0500
+#define BLOCK_MEM_RDY_VAL 0x
+#define EN_COHERENCY 0xF000
+#define EN_REG 0x0001
+#define OB_LO_IO 0x0002
+#define XGENE_PCIE_VENDORID0xE008
+#define XGENE_PCIE_DEVICEID0xE004
+#define XGENE_PCIE_ECC_TIMEOUT 10 /* ms */
+#define XGENE_LTSSM_DETECT_WAIT20 /* ms */
+#define XGENE_LTSSM_L0_WAIT4 /* ms */
+#define SZ_1T (SZ_1G*1024ULL)
+#define PIPE_PHY_RATE_RD(src) ((0xc000 & (u32)(src)) >> 0xe)
+
+struct xgene_pcie_port {
+
Re: [PATCH] x86: new Intel Atom SoC power management controller driver
On 2014/3/6 13:52, H. Peter Anvin wrote: > On 03/05/2014 09:33 PM, Li, Aubrey wrote: >> >> These interfaces are uncommitted and don't have consumers now, I'd like >> to keep them unstable in debugfs. >> >> We can change it if we received a requirement to use them later. >> > > What we absolutely don't want to happen is someone starting to use these > unstable interfaces for something other than debugging. If debugfs ever > needs to be mounted in a system for full functionality, that is a bug. > Understood. But we don't have a plan to use it now. Just for observation and diagnosis purpose only. Are you suggesting we should put them into sysfs now? Thanks, -Aubrey > -hpa > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] devicetree: bindings: gpio-davinic: fix documentation
From: "Lad, Prabhakar"
This patch adds missing #gpio-cells and also adds a
usage example for leds.
Reported-by: Alexander Holler
Signed-off-by: Lad, Prabhakar
---
.../devicetree/bindings/gpio/gpio-davinci.txt | 21
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index 4ce9862..5079ba7 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -8,6 +8,10 @@ Required Properties:
- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are
@@ -27,6 +31,7 @@ Example:
gpio: gpio@1e26000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
+ #gpio-cells = <2>;
reg = <0x226000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
@@ -39,3 +44,19 @@ gpio: gpio@1e26000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ label = "davinci:green:usr1";
+ gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
+ ...
+ };
+
+ led2 {
+ label = "davinci:red:debug1";
+ gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
+ ...
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB remote wakeup through gpio interrupt
Hi Peter, Thanks for your reply. I can use pm_runtime_get in interrupt handler, but i am not getting your idea of using pm_runtime_put in interrupt handler? My device is usb telephony modem, which will give interrupt through gpio when call comes. so at that time i want to wakeup the usb functionality as remote wakeup is not working properly. will pm_runtime_put suspend the device immidiately or it will not suspend the device till it is in use? thanks, jagdish gediya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl-baytrail: add function mux checking in gpio pin request
From: Chew, Kean Ho
The requested gpio pin must has the func_pin_mux field set
to GPIO function by BIOS/FW in advanced. Else, the gpio pin
request would fail. This is to ensure that we do not expose
any gpio pins which shall be used for alternate functions,
for eg: wakeup pin, I/O interfaces for LPSS, etc.
Signed-off-by: Chew, Kean Ho
Signed-off-by: Chew, Chiau Ee
---
drivers/pinctrl/pinctrl-baytrail.c | 42 +--
1 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 665b96b..bf2b3f6 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -60,6 +60,10 @@
#define BYT_NGPIO_NCORE28
#define BYT_NGPIO_SUS 44
+#define BYT_SCORE_ACPI_UID "1"
+#define BYT_NCORE_ACPI_UID "2"
+#define BYT_SUS_ACPI_UID "3"
+
/*
* Baytrail gpio controller consist of three separate sub-controllers called
* SCORE, NCORE and SUS. The sub-controllers are identified by their acpi UID.
@@ -102,17 +106,17 @@ static unsigned const sus_pins[BYT_NGPIO_SUS] = {
static struct pinctrl_gpio_range byt_ranges[] = {
{
- .name = "1", /* match with acpi _UID in probe */
+ .name = BYT_SCORE_ACPI_UID, /* match with acpi _UID in probe */
.npins = BYT_NGPIO_SCORE,
.pins = score_pins,
},
{
- .name = "2",
+ .name = BYT_NCORE_ACPI_UID,
.npins = BYT_NGPIO_NCORE,
.pins = ncore_pins,
},
{
- .name = "3",
+ .name = BYT_SUS_ACPI_UID,
.npins = BYT_NGPIO_SUS,
.pins = sus_pins,
},
@@ -145,9 +149,41 @@ static void __iomem *byt_gpio_reg(struct gpio_chip *chip,
unsigned offset,
return vg->reg_base + reg_offset + reg;
}
+static bool is_special_pin(struct byt_gpio *vg, unsigned offset)
+{
+ /* SCORE pin 92-93 */
+ if (!strcmp(vg->range->name, BYT_SCORE_ACPI_UID) &&
+ offset >= 92 && offset <= 93)
+ return true;
+
+ /* SUS pin 11-21 */
+ if (!strcmp(vg->range->name, BYT_SUS_ACPI_UID) &&
+ offset >= 11 && offset <= 21)
+ return true;
+
+ return false;
+}
+
static int byt_gpio_request(struct gpio_chip *chip, unsigned offset)
{
struct byt_gpio *vg = to_byt_gpio(chip);
+ void __iomem *reg = byt_gpio_reg(chip, offset, BYT_CONF0_REG);
+ u32 value;
+ bool special;
+
+ /*
+* In most cases, func pin mux 000 means GPIO function.
+* But, some pins may have func pin mux 001 represents
+* GPIO function. Only allow user to export pin with
+* func pin mux preset as GPIO function by BIOS/FW.
+*/
+ value = readl(reg) & BYT_PIN_MUX;
+ special = is_special_pin(vg, offset);
+ if ((special && value != 1) || (!special && value)) {
+ dev_err(&vg->pdev->dev,
+ "pin %u cannot be used as GPIO.\n", offset);
+ return -EINVAL;
+ }
pm_runtime_get(&vg->pdev->dev);
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [blkg] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Hi,
Thanks for the report. The q->queue_lock may be taken in irq. And in
sys_read() context, we hold q->queue_lock with irq disabled and then
called local_bh_enable, which turned irq enabled. This leads to
potential double acquire of queue_lock.
One fix is to use "_local_bh_enable()" instead of "local_bh_enable()"
in u64_stats_fetch_retry_bh(). There's no enabling of irq in
_local_bh_enable().
But I wonder why we do "WARN_ON_ONCE(!irqs_disabled())" in
_local_bh_enable()? What's the bad thing if someone call
_local_bh_enable() with irqs_diabled()?
Is below change acceptable?
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 490fcbb..f446763 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -142,9 +142,11 @@ EXPORT_SYMBOL(_local_bh_enable);
void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
{
+ unsigned long flags;
+
WARN_ON_ONCE(in_irq() || irqs_disabled());
#ifdef CONFIG_TRACE_IRQFLAGS
- local_irq_disable();
+ raw_local_irq_save(flags);
#endif
/*
* Are softirqs going to be turned on now:
@@ -167,7 +169,7 @@ void __local_bh_enable_ip(unsigned long ip,
unsigned int cnt)
preempt_count_dec();
#ifdef CONFIG_TRACE_IRQFLAGS
- local_irq_enable();
+ raw_local_irq_restore(flags);
#endif
preempt_check_resched();
}
Zhiguo
On Wed, Mar 5, 2014 at 9:21 PM, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 2c575026fae6e63771bd2a4c1d407214a8096a89
> Author: Hong Zhiguo
> AuthorDate: Wed Nov 20 10:35:05 2013 -0700
> Commit: Jens Axboe
> CommitDate: Wed Nov 20 15:33:04 2013 -0700
>
> Update of blkg_stat and blkg_rwstat may happen in bh context.
> While u64_stats_fetch_retry is only preempt_disable on 32bit
> UP system. This is not enough to avoid preemption by bh and
> may read strange 64 bit value.
>
>
> +++
> |||
> +++
> | boot_successes | 0 |
> | boot_failures | 19 |
> | inconsistent_IN-HARDIRQ-W-HARDIRQ-ON-W_usage | 12 |
> | backtrace:vfs_read | 10 |
> | backtrace:SyS_read | 10 |
> | BUG:spinlock_lockup_suspected_on_CPU | 1 |
> | WARNING:CPU:PID:at_kernel/softirq.c:__local_bh_enable_ip() | 9 |
> | backtrace:do_mount | 9 |
> | backtrace:SyS_mount| 9 |
> | inconsistent_SOFTIRQ-ON-W-IN-SOFTIRQ-W_usage | 7 |
> | backtrace:floppy_work_workfn | 7 |
> +++
>
> [ 91.904407] [ INFO: inconsistent lock state ]
> [ 91.905533] 3.14.0-rc3-wl-01773-g311db85 #11 Tainted: GW
> [ 91.906880] -
> [ 91.908013] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 91.909378] blkid/3517 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 91.910360] (&(&q->__queue_lock)->rlock){?.-...}, at: []
> blk_flush_plug_list+0x15a/0x240
> [ 91.910360] {IN-HARDIRQ-W} state was registered at:
> [ 91.910360] [] __lock_acquire+0xb5a/0x1aa0
> [ 91.910360] [] lock_acquire+0x77/0xa0
> [ 91.910360] [] _raw_spin_lock_irqsave+0x4d/0x60
> [ 91.910360] [] blk_end_bidi_request+0x3b/0x60
> [ 91.910360] [] blk_end_request+0x12/0x20
> [ 91.910360] [] ide_end_rq+0x27/0x50
> [ 91.910360] [] ide_complete_rq+0x27/0x50
> [ 91.910360] [] cdrom_newpc_intr+0x315/0x8e0
> [ 91.910360] [] ide_intr+0x15a/0x1f0
> [ 91.910360] [] handle_irq_event_percpu+0x20/0x120
> [ 91.910360] [] handle_irq_event+0x2c/0x50
> [ 91.910360] [] handle_edge_irq+0x66/0x120
> [ 91.910360] irq event stamp: 2248
> [ 91.910360] hardirqs last enabled at (2245): []
> _raw_spin_unlock_irq+0x22/0x50
> [ 91.910360] hardirqs last disabled at (2246): []
> blk_flush_plug_list+0xf7/0x240
> [ 91.910360] softirqs last enabled at (2248): []
> __cfq_set_active_queue+0x45/0x1d0
> [ 91.910360] softirqs last disabled at (2247): []
> __cfq_set_active_queue+0x45/0x1d0
> [ 91.910360]
> [ 91.910360] other info that might help us debug this:
> [ 91.910360] Possible unsafe locking scenario:
> [ 91.910360]
> [ 91.910360]CPU0
> [ 91.910360]
> [ 91.910360] lock(&(&q->__queue_lock)->rlock);
> [ 91.910360]
> [ 91.910360] lock(&(&q->__queue_lock)->rlock);
> [ 91.910360]
> [ 91.910360] *** DEADLOCK ***
> [ 91.910360]
> [ 91.910360] 1 lock held by blkid/3517:
> [ 91.910360] #0: (&(&q->__queue_lock)->rlock){?.-...}, at: []
> blk_flush_plug_list+0x15a/0x240
> [ 91.910360]
> [ 91.910360] stack backtrace:
> [
Re: [PATCH] x86: new Intel Atom SoC power management controller driver
On 03/05/2014 09:33 PM, Li, Aubrey wrote: > > These interfaces are uncommitted and don't have consumers now, I'd like > to keep them unstable in debugfs. > > We can change it if we received a requirement to use them later. > What we absolutely don't want to happen is someone starting to use these unstable interfaces for something other than debugging. If debugfs ever needs to be mounted in a system for full functionality, that is a bug. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/le: fix endianness of the arguments passed to the ppc_rtas() syscall
On Wed, 2014-03-05 at 18:20 +0100, Greg Kurz wrote: > RTAS manipulates its input and output arguments in big endian order. > > I have looked at factoring some lines with rtas_call() but it is not really > worth it because of the variable arguments. I'm not sure about that one ... So this assumes that userspace will pass the RTAS arguments LE... This will work only as long as the arguments are indeed just an array of u32's. The minute userspace tries to crap something like two u16's in one argument or a u64 accross two arguments, it has the potential to be broken depending on how it has been done. I would have done it the other way around which is to define that ppc_rtas takes a BE structure since this is what RTAS expects (and the bit of RMA memory we expose to userspace for communicating with it also has to be handled BE so userspace has to know anyway). That means that the only things we need to fix here is when we interpret the args.nargs etc... we need a be32_to_cpu Cheers, Ben. > Signed-off-by: Greg Kurz > --- > arch/powerpc/kernel/rtas.c | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c > index 4cf674d..00dbe36 100644 > --- a/arch/powerpc/kernel/rtas.c > +++ b/arch/powerpc/kernel/rtas.c > @@ -1020,6 +1020,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs) > char *buff_copy, *errbuf = NULL; > int nargs; > int rc; > + int i; > > if (!capable(CAP_SYS_ADMIN)) > return -EPERM; > @@ -1056,9 +1057,19 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs) > > flags = lock_rtas(); > > - rtas.args = args; > + rtas.args.token = cpu_to_be32(args.token); > + rtas.args.nargs = cpu_to_be32(args.nargs); > + rtas.args.nret = cpu_to_be32(args.nret); > + for (i = 0; i < nargs; ++i) > + rtas.args.args[i] = cpu_to_be32(args.args[i]); > + rtas.args.rets = &rtas.args.args[nargs]; > + for (i = 0; i < args.nret; ++i) > + rtas.args.rets[i] = 0; > + > enter_rtas(__pa(&rtas.args)); > - args = rtas.args; > + > + for (i = 0; i < args.nret; ++i) > + args.rets[i] = be32_to_cpu(rtas.args.rets[i]); > > /* A -1 return code indicates that the last command couldn't > be completed due to a hardware error. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: new Intel Atom SoC power management controller driver
On 2014/3/6 13:28, H. Peter Anvin wrote: > On 03/05/2014 09:21 PM, Li, Aubrey wrote: >>> >>> What is the reason for putting this in debugfs? >> >> S0ix support on Atom SoC needs all of the devices under south complex to >> be quiesced, as well as the devices under north complex. This interface >> shows all of the devices states under platform control unit. If the >> system is not able to enter S0ix, we have a way to diagnose. Or if the >> system entered S0ix, we have counters to show S0ix entered and its >> residency. >> > > I guess the real question is: are you sure this is only for debugging, > or is this going to be an interface that applications or daemons will > actually use (in which case it should live in sysfs). These interfaces are uncommitted and don't have consumers now, I'd like to keep them unstable in debugfs. We can change it if we received a requirement to use them later. Thanks, -Aubrey > > -hpa > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched/clock: prevent tracing recursion in sched_clock_cpu()
From: Fernando Luis Vazquez Cao
Prevent tracing of preempt_disable/enable() in sched_clock_cpu().
When CONFIG_DEBUG_PREEMPT is enabled, preempt_disable/enable() are
traced and this causes trace_clock() users (and probably others) to
go into an infinite recursion. Systems with a stable sched_clock()
are not affected.
This problem is similar to that fixed by upstream commit 95ef1e52922
("KVM guest: prevent tracing recursion with kvmclock").
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Steven Rostedt
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux-3.14-rc5-orig/kernel/sched/clock.c
linux-3.14-rc5/kernel/sched/clock.c
--- linux-3.14-rc5-orig/kernel/sched/clock.c2014-03-06 13:37:43.567720550
+0900
+++ linux-3.14-rc5/kernel/sched/clock.c 2014-03-06 13:41:56.937100949 +0900
@@ -301,14 +301,14 @@ u64 sched_clock_cpu(int cpu)
if (unlikely(!sched_clock_running))
return 0ull;
- preempt_disable();
+ preempt_disable_notrace();
scd = cpu_sdc(cpu);
if (cpu != smp_processor_id())
clock = sched_clock_remote(scd);
else
clock = sched_clock_local(scd);
- preempt_enable();
+ preempt_enable_notrace();
return clock;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: new Intel Atom SoC power management controller driver
On 03/05/2014 09:21 PM, Li, Aubrey wrote: >> >> What is the reason for putting this in debugfs? > > S0ix support on Atom SoC needs all of the devices under south complex to > be quiesced, as well as the devices under north complex. This interface > shows all of the devices states under platform control unit. If the > system is not able to enter S0ix, we have a way to diagnose. Or if the > system entered S0ix, we have counters to show S0ix entered and its > residency. > I guess the real question is: are you sure this is only for debugging, or is this going to be an interface that applications or daemons will actually use (in which case it should live in sysfs). -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: new Intel Atom SoC power management controller driver
On 2014/3/6 11:49, H. Peter Anvin wrote: > On 03/05/2014 07:31 PM, Li, Aubrey wrote: >> The Power Management Controller (PMC) controls many of the power >> management features present in the SoC. This driver provides >> interface to configure the Power Management Controller (PMC). >> >> This driver exposes PMC device state and sleep state residency >> via debugfs for observation: >> /sys/kernel/debugfs/pmc_atom/dev_state >> /sys/kernel/debugfs/pmc_atom/sleep_state >> >> This driver also provides a native power off function via PMC PCI >> IO port. >> > > What is the reason for putting this in debugfs? S0ix support on Atom SoC needs all of the devices under south complex to be quiesced, as well as the devices under north complex. This interface shows all of the devices states under platform control unit. If the system is not able to enter S0ix, we have a way to diagnose. Or if the system entered S0ix, we have counters to show S0ix entered and its residency. Thanks, -Aubrey > > -hpa > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xHCI regression in stable 3.13.5 with USB3 card reader
I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. [ 25.177926] usb 4-2: Disable of device-initiated U1 failed. [ 26.906531] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 26.918439] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 26.918441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 26.921116] sd 6:0:0:0: [sdc] Unhandled error code [ 26.921118] sd 6:0:0:0: [sdc] [ 26.921120] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 26.921120] sd 6:0:0:0: [sdc] CDB: [ 26.921121] Read(10): 28 00 00 00 08 23 00 00 f0 00 [ 26.921126] end_request: I/O error, dev sdc, sector 2083 [ 27.208871] sd 6:0:0:0: [sdc] Media Changed [ 27.208874] sd 6:0:0:0: [sdc] [ 27.208875] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 27.208876] sd 6:0:0:0: [sdc] [ 27.208877] Sense Key : Unit Attention [current] [ 27.208878] sd 6:0:0:0: [sdc] [ 27.208880] Add. Sense: Not ready to ready change, medium may have changed [ 27.208880] sd 6:0:0:0: [sdc] CDB: [ 27.208881] Read(10): 28 00 00 00 08 24 00 00 ef 00 [ 27.208886] end_request: I/O error, dev sdc, sector 2084 [ 27.210467] FAT-fs (sdc1): FAT read failed (blocknr 35) [ 49.420334] usb 4-2: Disable of device-initiated U1 failed. [ 51.139080] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 51.150979] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 51.150981] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 51.153663] sd 6:0:0:0: [sdc] Unhandled error code [ 51.153665] sd 6:0:0:0: [sdc] [ 51.153666] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 51.153667] sd 6:0:0:0: [sdc] CDB: [ 51.153668] Read(10): 28 00 00 00 08 25 00 00 ee 00 [ 51.153672] end_request: I/O error, dev sdc, sector 2085 [ 51.441377] sd 6:0:0:0: [sdc] Media Changed [ 51.441379] sd 6:0:0:0: [sdc] [ 51.441380] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 51.441381] sd 6:0:0:0: [sdc] [ 51.441382] Sense Key : Unit Attention [current] [ 51.441384] sd 6:0:0:0: [sdc] [ 51.441385] Add. Sense: Not ready to ready change, medium may have changed [ 51.441386] sd 6:0:0:0: [sdc] CDB: [ 51.441386] Read(10): 28 00 00 00 08 26 00 00 ed 00 [ 51.441391] end_request: I/O error, dev sdc, sector 2086 [ 51.441454] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442083] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442570] FAT-fs (sdc1): FAT read failed (blocknr 235) [ 164.219227] usb 4-2: Disable of device-initiated U1 failed. [ 165.938731] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 165.950669] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 165.950672] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 165.953366] sd 6:0:0:0: [sdc] Unhandled error code [ 165.953368] sd 6:0:0:0: [sdc] [ 165.953369] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 165.953370] sd 6:0:0:0: [sdc] CDB: [ 165.953371] Read(10): 28 00 00 00 08 27 00 00 ec 00 [ 165.953375] end_request: I/O error, dev sdc, sector 2087 [ 166.240995] sd 6:0:0:0: [sdc] Media Changed [ 166.240997] sd 6:0:0:0: [sdc] [ 166.240999] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 166.241000] sd 6:0:0:0: [sdc] [ 166.241000] Sense Key : Unit Attention [current] [ 166.241002] sd 6:0:0:0: [sdc] [ 166.241003] Add. Sense: Not ready to ready change, medium may have changed [ 166.241004] sd 6:0:0:0: [sdc] CDB: [ 166.241005] Read(10): 28 00 00 00 08 28 00 00 eb 00 [ 166.241010] end_request: I/O error, dev sdc, sector 2088 [ 166.241055] FAT-fs (sdc1): FAT read failed (blocknr 39) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the staging tree with the staging.current tree
On Thu, Mar 06, 2014 at 04:06:49PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/cxt1e1/linux.c between commit 084b6e7765b9
> ("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
> from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
> remove space between function name and parenthesis") and a couple of
> others from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks, that looks good.
greg k-h
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/staging/cxt1e1/linux.c
> index 79206cb3fb94,579e68e3dece..
> --- a/drivers/staging/cxt1e1/linux.c
> +++ b/drivers/staging/cxt1e1/linux.c
> @@@ -861,79 -876,78 +876,80 @@@ c4_ioctl(struct net_device *ndev, struc
> #endif
>
> #if 0
> - pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
> - _IOC_DIR (iocmd), _IOC_TYPE (iocmd), _IOC_NR (iocmd),
> - _IOC_SIZE (iocmd));
> + pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
> + _IOC_DIR(iocmd), _IOC_TYPE(iocmd), _IOC_NR(iocmd),
> + _IOC_SIZE(iocmd));
> #endif
> - iolen = _IOC_SIZE (iocmd);
> - if (iolen > sizeof(arg))
> - return -EFAULT;
> - data = ifr->ifr_data + sizeof (iocmd);
> - if (copy_from_user (&arg, data, iolen))
> - return -EFAULT;
> -
> - ret = 0;
> - switch (iocmd)
> - {
> - case SBE_IOC_PORT_GET:
> - //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
> - ret = do_get_port (ndev, data);
> - break;
> - case SBE_IOC_PORT_SET:
> - //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
> - ret = do_set_port (ndev, data);
> - break;
> - case SBE_IOC_CHAN_GET:
> - //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
> - ret = do_get_chan (ndev, data);
> - break;
> - case SBE_IOC_CHAN_SET:
> - //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
> - ret = do_set_chan (ndev, data);
> - break;
> - case C4_DEL_CHAN:
> - //pr_info(">> C4_DEL_CHAN Ioctl...\n");
> - ret = do_del_chan (ndev, data);
> - break;
> - case SBE_IOC_CHAN_NEW:
> - ret = do_create_chan (ndev, data);
> - break;
> - case SBE_IOC_CHAN_GET_STAT:
> - ret = do_get_chan_stats (ndev, data);
> - break;
> - case SBE_IOC_LOGLEVEL:
> - ret = do_set_loglevel (ndev, data);
> - break;
> - case SBE_IOC_RESET_DEV:
> - ret = do_reset (ndev, data);
> - break;
> - case SBE_IOC_CHAN_DEL_STAT:
> - ret = do_reset_chan_stats (ndev, data);
> - break;
> - case C4_LOOP_PORT:
> - ret = do_port_loop (ndev, data);
> - break;
> - case C4_RW_FRMR:
> - ret = do_framer_rw (ndev, data);
> - break;
> - case C4_RW_MSYC:
> - ret = do_musycc_rw (ndev, data);
> - break;
> - case C4_RW_PLD:
> - ret = do_pld_rw (ndev, data);
> - break;
> - case SBE_IOC_IID_GET:
> - ret = (iolen == sizeof (struct sbe_iid_info)) ? c4_get_iidinfo (ci,
> &arg.u.iip) : -EFAULT;
> - if (ret == 0) /* no error, copy data */
> - if (copy_to_user (data, &arg, iolen))
> - return -EFAULT;
> - break;
> - default:
> - //pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
> - ret = -EINVAL;
> - break;
> - }
> - return mkret (ret);
> + iolen = _IOC_SIZE(iocmd);
> ++if (iolen > sizeof(arg))
> ++return -EFAULT;
> + data = ifr->ifr_data + sizeof(iocmd);
> + if (copy_from_user(&arg, data, iolen))
> + return -EFAULT;
> +
> + ret = 0;
> + switch (iocmd)
> + {
> + case SBE_IOC_PORT_GET:
> + //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
> + ret = do_get_port(ndev, data);
> + break;
> + case SBE_IOC_PORT_SET:
> + //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
> + ret = do_set_port(ndev, data);
> + break;
> + case SBE_IOC_CHAN_GET:
> + //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
> + ret = do_get_chan(ndev, data);
> + break;
> + case SBE_IOC_CHAN_SET:
> + //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
> + ret = do_set_chan(ndev, data);
> + break;
> + case C4_DEL_CHAN:
> + //pr_info(">> C4_DEL_CHAN Ioctl...\n");
> + ret = do_del_chan(ndev, data);
> + break;
> + case SBE_IOC_CHAN_NEW:
> + ret = do_create_chan(ndev, data);
> + break;
> + case SBE_IOC_CHAN_GET_STAT:
> + ret = do_get_chan_stats(ndev, data);
> + break;
> + case SBE_IOC_LOGLEV
linux-next: manual merge of the staging tree with the staging.current tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/cxt1e1/linux.c between commit 084b6e7765b9
("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
remove space between function name and parenthesis") and a couple of
others from the staging tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/staging/cxt1e1/linux.c
index 79206cb3fb94,579e68e3dece..
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@@ -861,79 -876,78 +876,80 @@@ c4_ioctl(struct net_device *ndev, struc
#endif
#if 0
- pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
- _IOC_DIR (iocmd), _IOC_TYPE (iocmd), _IOC_NR (iocmd),
- _IOC_SIZE (iocmd));
+ pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
+ _IOC_DIR(iocmd), _IOC_TYPE(iocmd), _IOC_NR(iocmd),
+ _IOC_SIZE(iocmd));
#endif
- iolen = _IOC_SIZE (iocmd);
- if (iolen > sizeof(arg))
- return -EFAULT;
- data = ifr->ifr_data + sizeof (iocmd);
- if (copy_from_user (&arg, data, iolen))
- return -EFAULT;
-
- ret = 0;
- switch (iocmd)
- {
- case SBE_IOC_PORT_GET:
- //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
- ret = do_get_port (ndev, data);
- break;
- case SBE_IOC_PORT_SET:
- //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
- ret = do_set_port (ndev, data);
- break;
- case SBE_IOC_CHAN_GET:
- //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
- ret = do_get_chan (ndev, data);
- break;
- case SBE_IOC_CHAN_SET:
- //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
- ret = do_set_chan (ndev, data);
- break;
- case C4_DEL_CHAN:
- //pr_info(">> C4_DEL_CHAN Ioctl...\n");
- ret = do_del_chan (ndev, data);
- break;
- case SBE_IOC_CHAN_NEW:
- ret = do_create_chan (ndev, data);
- break;
- case SBE_IOC_CHAN_GET_STAT:
- ret = do_get_chan_stats (ndev, data);
- break;
- case SBE_IOC_LOGLEVEL:
- ret = do_set_loglevel (ndev, data);
- break;
- case SBE_IOC_RESET_DEV:
- ret = do_reset (ndev, data);
- break;
- case SBE_IOC_CHAN_DEL_STAT:
- ret = do_reset_chan_stats (ndev, data);
- break;
- case C4_LOOP_PORT:
- ret = do_port_loop (ndev, data);
- break;
- case C4_RW_FRMR:
- ret = do_framer_rw (ndev, data);
- break;
- case C4_RW_MSYC:
- ret = do_musycc_rw (ndev, data);
- break;
- case C4_RW_PLD:
- ret = do_pld_rw (ndev, data);
- break;
- case SBE_IOC_IID_GET:
- ret = (iolen == sizeof (struct sbe_iid_info)) ? c4_get_iidinfo (ci,
&arg.u.iip) : -EFAULT;
- if (ret == 0) /* no error, copy data */
- if (copy_to_user (data, &arg, iolen))
- return -EFAULT;
- break;
- default:
- //pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
- ret = -EINVAL;
- break;
- }
- return mkret (ret);
+ iolen = _IOC_SIZE(iocmd);
++ if (iolen > sizeof(arg))
++ return -EFAULT;
+ data = ifr->ifr_data + sizeof(iocmd);
+ if (copy_from_user(&arg, data, iolen))
+ return -EFAULT;
+
+ ret = 0;
+ switch (iocmd)
+ {
+ case SBE_IOC_PORT_GET:
+ //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
+ ret = do_get_port(ndev, data);
+ break;
+ case SBE_IOC_PORT_SET:
+ //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
+ ret = do_set_port(ndev, data);
+ break;
+ case SBE_IOC_CHAN_GET:
+ //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
+ ret = do_get_chan(ndev, data);
+ break;
+ case SBE_IOC_CHAN_SET:
+ //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
+ ret = do_set_chan(ndev, data);
+ break;
+ case C4_DEL_CHAN:
+ //pr_info(">> C4_DEL_CHAN Ioctl...\n");
+ ret = do_del_chan(ndev, data);
+ break;
+ case SBE_IOC_CHAN_NEW:
+ ret = do_create_chan(ndev, data);
+ break;
+ case SBE_IOC_CHAN_GET_STAT:
+ ret = do_get_chan_stats(ndev, data);
+ break;
+ case SBE_IOC_LOGLEVEL:
+ ret = do_set_loglevel(ndev, data);
+ break;
+ case SBE_IOC_RESET_DEV:
+ ret = do_reset(ndev, data);
+ break;
+ case SBE_IOC_CHAN_DEL_STAT:
+ ret = do_reset_chan_stats(ndev, data);
+ break;
+ ca
Re: [PATCH net-next v2 12/13] r8152: add additional parameter for non x86 platform
From: Hayes Wang Date: Wed, 5 Mar 2014 14:49:27 +0800 > Add additional parameter for non x86 platform for better throughput. > > Signed-off-by: Hayes Wang This commit message tells me absolutely nothing. First of all, it doesn't say what the issue is, why is the chip slower on non-x86 platforms with the current way it is programmed? And in particular, which non-x86 platform? You can't possibly mean all of them. I can almost guarentee if you actually explain the issue, I'm going to tell you to use a more meaningful test for the condition or property an architecture has which makes the alternative setting more desirable. > /* USB_RX_EARLY_AGG */ > -#define EARLY_AGG_SUPPER 0x0e832981 > +#if defined(__i386__) || defined(__x86_64__) > + #define EARLY_AGG_SUPPER0x0e832981 > +#else > + #define EARLY_AGG_SUPPER0x0e835000 > +#endif And this value is completely magic, you must document what this register value means. I find this patch series extremely frustrating. You are combining so many things all at once, so if one aspect requires changes or to be removed, it invalidates the rest of the series and you have to respin it all over again. Why don't you re-submit this in pieces? First the cleanups (first three patches) would be one series. Once I apply that, perhaps submit the locking changes and tso/checksum support. Then finally, after I apply that, submit the tweaks at the end. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delivery Status Notification (Failure)
Hi Alan,
Thanks for you informative reply.
I will try your suggestion. yes, i will not get more than one wakeup per second.
I have tried below things.
My usb device is using the cdc-acm.c driver.
inside cdc-acm.c file,
static struct usb_device *usb_device;
static int acm_probe(, )
{
usb_device = interface_to_usbdev(intf);
..
}
inside interrupt handler
static irqhandle_t int_handler(..., ..)
{
usb_lock_device(usb_device);
usb_remote_wakeup(usb_device);
usb_unlock_device(usb_device);
return IRQ_HANDLED;
}
but these things are not working. kernel is crashing when interrupt occurs.
I have some other doubt also.
1. If usb is runtime suspended and if global suspend happens , do i
need to do anything special to wakeup the usb device?
2. How can i address particularly my usb device. right now, i am using
usb_device = interface_to_usbdev(intf) to get pointer to my usb device
inside probe function, but probe function is getting called for every
interface of the device. Is there any other way through which i can
get the pointer to my usb device like i can traverse all the available
usb device and on basis of vendor and product id i can address my usb
device or by any other way?
thanks,
jagdish gediya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/2] i2c: add DMA support for freescale i2c driver
On Thu, March 06, 2014 at 12:44:14 PM, Marek Vasut wrote:
> On Thursday, March 06, 2014 at 05:36:14 AM, Yao Yuan wrote:
> > On Thu, March 06, 2014 at 11:23:50 AM, Marek Vasut wrote:
> > > On Wednesday, March 05, 2014 at 07:52:31 AM, Yuan Yao wrote:
> > > > Add dma support for i2c. This function depend on DMA driver.
> > > > You can turn on it by write both the dmas and dma-name properties
> > > > in dts node.
> > > >
> > > > Signed-off-by: Yuan Yao
> > > > ---
> > >
> > > [...]
> > >
> > > > @@ -601,6 +826,7 @@ static int i2c_imx_probe(struct
> > > > platform_device
> > >
> > > *pdev)
> > >
> > > > void __iomem *base;
> > > > int irq, ret;
> > > > u32 bitrate;
> > > >
> > > > + u32 phy_addr;
> > > >
> > > > dev_dbg(&pdev->dev, "<%s>\n", __func__);
> > > >
> > > > @@ -611,6 +837,7 @@ static int i2c_imx_probe(struct
> > > > platform_device
> > >
> > > *pdev)
> > >
> > > > }
> > > >
> > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > >
> > > > + phy_addr = res->start;
> > >
> > > Uh ... Shawn, I really think I am lost here. Don't you need to map
> > > this memory before you can use it for DMA ? The DMA mapping function
> > > should give you the physical address and is the right way to go
> > > about this instead of pulling the address from here, no ?
> > >
> > > I might be wrong here, I am rather uncertain, so please help me out.
> > > Thanks!
> >
> > Hi, Marek, Thanks for your suggestion.
> > Here you can review the code in include/linux/ioport.h The
> > resource->start describes the entity on the CPU bus as a starting
> > physical address. So I thinks it can used for dma directly.
>
> This doesn't feel right for some reason. If this is a register area, you
> should
> ioremap() it. If it's a memory area you do DMA to/from, you need to make
> sure you correctly flush/invalidate caches and properly handle the
> effects the write buffer might have. But I have a feeling you actually do
> DMA to/from register space here ?
>
Yes, It's a register area. But I don't know why I should ioremap() it? It's a
bus address and DMA can use it directly.
Is there some problem for my understanding ?
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: USB remote wakeup through gpio interrupt
> > > Hi, > > There is some inconsistency in remote wakeup functionality in my > > custom board. so I want to wakeup the runtime suspended USB host > > through interrupt. My USB device is connected to the board through USB > > interface and some gpios. device will give interrupt on processor gpio > > when it needs attention of USB host. What should i do so that i can > > wakeup the usb host when i get interrupt from the device. > > Have your gpio interrupt handler call pm_request_resume() for the host > controller device. > > However, this may not do what you want. Since the root hub will remain > suspended, the host controller will go back to low-power immediately > after it is resumed. You really need to resume the USB device itself, > not the host controller. > I think it is the same we echo on > ../power/control, you may need to request gpio interrupt at your usb class driver, and call pm_runtime_get() when the gpio interrupt is coming. After the device finishes using usb, it can call pm_runtme_put through gpio interrupt. Peter > > My idea was to apply power management related hooks from the interrupt > > handler, but I am not getting the clear idea. > > > > My main doubt is, > > Will this mechanism be efficient as remote wakeup functionality? > > That's a hard question to answer without measurements. But it shouldn't > matter, because you probably won't get more than one wakeup per second, > right? > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/172] 3.13.6-stable review
On Wed, Mar 05, 2014 at 03:30:53PM -0700, Shuah Khan wrote: > On 03/04/2014 01:01 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.6 release. > > There are 172 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Mar 6 20:02:29 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.13.6-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compile tests and boot tests passed. No dmesg regressions: emerg, crit, > alert, err are clean. No regressions in warn. Thanks for testing both of these. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
On Thu, Mar 06, 2014 at 01:48:29AM +0100, Laurent Pinchart wrote: > Hi Joe, > > On Wednesday 05 March 2014 16:28:03 Joe Perches wrote: > > On Thu, 2014-03-06 at 00:50 +0100, Laurent Pinchart wrote: > > > Please note that -DDEBUG is equivalent to '#define DEBUG', not to '#define > > > CONFIG_DEBUG'. 'DEBUG' needs to be defined for dev_dbg() to have any > > > effect. > > > > Not quite. If CONFIG_DYNAMIC_DEBUG is set, these > > dev_dbg statements are compiled in but not by default > > set to emit output. Output can be enabled by using > > dynamic_debug controls like: > > > > # echo -n 'file omap4iss/* +p' > /dynamic_debug/control > > > > See Documentation/dynamic-debug-howto.txt for more details. > > Thank you for the additional information. > > Would you recommend to drop driver-specific Kconfig options related to > debugging and use CONFIG_DYNAMIC_DEBUG instead ? Yes, please do that, no one wants to rebuild drivers and subsystems with different options just for debugging. 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: mm: kernel BUG at mm/huge_memory.c:2785!
On 03/05/2014 08:52 AM, Kirill A. Shutemov wrote: Sasha Levin wrote: On 02/27/2014 10:03 AM, Kirill A. Shutemov wrote: Sasha Levin wrote: Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the following spew: [ 1428.146261] kernel BUG at mm/huge_memory.c:2785! Hm, interesting. It seems we either failed to split huge page on vma split or it materialized from under us. I don't see how it can happen: - it seems we do the right thing with vma_adjust_trans_huge() in __split_vma(); - we hold ->mmap_sem all the way from vm_munmap(). At least I don't see a place where we could drop it; Andrea, any ideas? And a somewhat related issue (please correct me if I'm wrong): Yeah. Looks similar. And I still have no idea how it could happened. Do you trinity logs for the crash? I can't get it to reproduce with trinity logging enabled, I guess it makes it harder for the race to occur. I'll keep it running through the night but don't really have high hopes. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Add option to build with -O3
On Wed, Mar 05, 2014 at 02:32:26AM -0500, Jon Ringle wrote: > On Wed, 5 Mar 2014, Greg KH wrote: > > > On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote: > > > +config CC_OPTIMIZE_FOR_SPEED > > > +bool "Optimze for speed (-O3)" > > > +help > > > + Enabling this option will pass "-O3" to gcc > > > + resulting in a larger kernel (but possibly faster) > > > > Are you sure about that? Have you measured it? > > (Resending this message, since it was "destroyed". Hopefully, this is now > an an acceptable form :) > > I do know that there is an improvement performance-wise for my particular > use-case. > > My target is an ARM board being built with gcc-4.8.2. My board has on it a > sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, > so when an interrupt comes in to indicate that there is data available to > be read, I need to get the data over the i2c bus. I do this on a kthread > to do this work. The i2c transactions (using i2c-davinci driver) are also > interrupt driven. I was seeing a lot of lost packets when receiving data > at only 19200. Adding the -O3 compile option helped in this regard in that > I am now rarely seeing packet loss. I'd take this up with the linux-arm developers, that sounds like something is wrong with your system that a compiler change fixes problems. Something else must be wrong... good luck, 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/
[PATCH 3/3] perf: Use 64-bit value when comparing sample_regs
When checking whether a bit representing a register is set in
sample_regs, a 64-bit mask, use 64-bit value (1LL).
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/util/unwind.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/unwind.c b/tools/perf/util/unwind.c
index 742f23b..2b888c6 100644
--- a/tools/perf/util/unwind.c
+++ b/tools/perf/util/unwind.c
@@ -396,11 +396,11 @@ static int reg_value(unw_word_t *valp, struct regs_dump
*regs, int id,
{
int i, idx = 0;
- if (!(sample_regs & (1 << id)))
+ if (!(sample_regs & (1LL << id)))
return -EINVAL;
for (i = 0; i < id; i++) {
- if (sample_regs & (1 << i))
+ if (sample_regs & (1LL << i))
idx++;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] powerpc/perf: Enable linking with libunwind
When we try to create backtraces (call-graphs) with the perf tool
perf record -g /tmp/sprintft
we get backtraces with duplicate arcs for sprintft[1]:
14.61% sprintft libc-2.18.so [.] __random
|
--- __random
|
|--61.09%-- __random
| |
| |--97.18%-- rand
| | do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| |
| --2.82%-- do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--38.91%-- rand
|
|--92.90%-- rand
| |
| |--99.87%-- do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| --0.13%-- [...]
|
--7.10%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
(where the two arcs both have the same backtrace but are not merged).
Linking with libunwind seems to create better backtraces. While x86 and
ARM processors have support for linking with libunwind but Power does not.
This patchset is an RFC for linking with libunwind.
With this patchset and running:
/tmp/perf record --call-graph=dwarf,8192 /tmp/sprintft
the backtrace is:
14.94% sprintft libc-2.18.so [.] __random
|
--- __random
rand
do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
(nil)
This appears better.
One downside is that we now need the kernel to save the entire user stack
(the 8192 in the command line is the default user stack size).
A second issue is that this invocation of perf (with --call-graph=dwarf,8192)
seems to fail for backtraces involving tail-calls[2]
/tmp/perf record -g ./tailcall
gives
20.00% tailcall tailcall [.] work2
|
--- work2
work
shows the tail function 'work2' as "called from" 'work()'
But with libunwind:
/tmp/perf record --call-graph=dwarf,8192 ./tailcall
we get:
20.50% tailcall tailcall [.] work2
|
--- work2
the caller of 'work' is not shown.
I am debugging this, but would appreciate any feedback/pointers on the
patchset/direction:
- Does libunwind need the entire user stack to work or are there
optimizations we can do to save the minimal entries for it to
perform the unwind.
- Does libunwind work with tailcalls like the one above ?
- Are there benefits to linking with libunwind (even if it does not
yet solve the tailcall problem)
- Are there any examples of using libdwarf to solve the tailcall
issue ?
[1] sprintft (excerpt from a test program by Maynard Johnson).
char * do_my_sprintf(char * strx, int num)
{
int i;
for (i = 0; i < inner_iterations; i++) {
int r = rand() % 10;
sprintf(my_string, "%s ...%d\n", strx+r, num);
if (strlen(my_string) > 15)
num = 15;
}
return my_string;
}
[2] tailcall (Powerpc assembly, from Anton Blanchard)
Build with: gcc -O2 --static -nostdlib -o tailcall tailcall.S
#define ITERATIONS 10
.align 2
.globl _start
.globl ._start
.section ".opd","aw"
_start:
.quad ._start
.quad .TOC.@tocbase
.quad 0;
.text;
._start:
lis 4,ITERATIONS@h
ori 4,4,ITERATIONS@l
mtctr 4
1: bl work
bdnz1b
li 0,1 /* sys_exit */
sc
work:
mflr30
bl work2
mtlr30
blr
work2:
blr
Sukadev Bhatt
[RFC][PATCH 2/3] power: perf tool: Add libunwind support for Power
Add ability to link with libunwind on Power.
This is based on similar changes in x86 and arm. Basically, implement
accessor functions that libunwind can call into while building the
backtrace from the user stack (which the kernel saved in a perf sample
- in previous commit).
Tested on Fedora-20 with libunwind and libunwind-devel libdwarf packages
installed.
TODO:
- Not sure if we need to list all the Power registers or restrict
to only those that libunwind needs.
- Check about perf_reg_abi()
- Build for 32-bit
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/arch/powerpc/Makefile|5 ++
tools/perf/arch/powerpc/include/perf_regs.h | 69 +++
tools/perf/arch/powerpc/util/unwind.c | 63
tools/perf/config/Makefile |7 +++
4 files changed, 144 insertions(+)
create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
create mode 100644 tools/perf/arch/powerpc/util/unwind.c
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 744e629..9d3b8ce 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -2,4 +2,9 @@ ifndef NO_DWARF
PERF_HAVE_DWARF_REGS := 1
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
endif
+
+ifndef NO_LIBUNWIND
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind.o
+endif
+
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h
b/tools/perf/arch/powerpc/include/perf_regs.h
new file mode 100644
index 000..d5667da
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -0,0 +1,69 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+#define PERF_REG_IPPERF_REG_POWERPC_NIP
+#define PERF_REG_SPPERF_REG_POWERPC_GPR1
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_POWERPC_GPR0: return "R0";
+ case PERF_REG_POWERPC_GPR1: return "R1";
+ case PERF_REG_POWERPC_GPR2: return "R2";
+ case PERF_REG_POWERPC_GPR3: return "R3";
+ case PERF_REG_POWERPC_GPR4: return "R4";
+ case PERF_REG_POWERPC_GPR5: return "R5";
+ case PERF_REG_POWERPC_GPR6: return "R6";
+ case PERF_REG_POWERPC_GPR7: return "R7";
+ case PERF_REG_POWERPC_GPR8: return "R8";
+ case PERF_REG_POWERPC_GPR9: return "R9";
+ case PERF_REG_POWERPC_GPR10:return "R10";
+ case PERF_REG_POWERPC_GPR11:return "R11";
+ case PERF_REG_POWERPC_GPR12:return "R12";
+ case PERF_REG_POWERPC_GPR13:return "R13";
+ case PERF_REG_POWERPC_GPR14:return "R14";
+ case PERF_REG_POWERPC_GPR15:return "R15";
+ case PERF_REG_POWERPC_GPR16:return "R16";
+ case PERF_REG_POWERPC_GPR17:return "R17";
+ case PERF_REG_POWERPC_GPR18:return "R18";
+ case PERF_REG_POWERPC_GPR19:return "R19";
+ case PERF_REG_POWERPC_GPR20:return "R20";
+ case PERF_REG_POWERPC_GPR21:return "R21";
+ case PERF_REG_POWERPC_GPR22:return "R22";
+ case PERF_REG_POWERPC_GPR23:return "R23";
+ case PERF_REG_POWERPC_GPR24:return "R24";
+ case PERF_REG_POWERPC_GPR25:return "R25";
+ case PERF_REG_POWERPC_GPR26:return "R26";
+ case PERF_REG_POWERPC_GPR27:return "R27";
+ case PERF_REG_POWERPC_GPR28:return "R28";
+ case PERF_REG_POWERPC_GPR29:return "R29";
+ case PERF_REG_POWERPC_GPR30:return "R30";
+ case PERF_REG_POWERPC_GPR31:return "R31";
+
+ case PERF_REG_POWERPC_NIP: return "NIP";
+ case PERF_REG_POWERPC_MSR: return "MSR";
+ case PERF_REG_POWERPC_ORIG_GPR3:return "ORIG_GPR3";
+ case PERF_REG_POWERPC_CTR: return "CTR";
+ case PERF_REG_POWERPC_LINK: return "LINK";
+ case PERF_REG_POWERPC_XER: return "XER";
+ case PERF_REG_POWERPC_CCR: return "CCR";
+
+#ifdef __powerpc64__
+ case PERF_REG_POWERPC_SOFTE:return "SOFTE";
+#else
+ case PERF_REG_POWERPC_MQ: return "MQ";
+#endif
+ case PERF_REG_POWERPC_TRAP: return "TRAP";
+ case PERF_REG_POWERP
[RFC][PATCH 1/3] power: perf: Enable saving the user stack in a sample.
When requested, have the kernel save the user stack in each perf sample
so 'perf report' can use libunwind and produce better backtraces.
The downside of course is that the kernel has to copy the user-stack
on each sample which has both performance and file-size implications
(of the perf.data file).
But we save the user-stack only when user explicitly requests it:
perf record --call-graph=dwarf,8192
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/Kconfig |2 +
arch/powerpc/include/uapi/asm/perf_regs.h | 70 +++
arch/powerpc/perf/Makefile|1 +
arch/powerpc/perf/perf-regs.c | 104 +
4 files changed, 177 insertions(+)
create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
create mode 100644 arch/powerpc/perf/perf-regs.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 957bf34..e79ce6e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,6 +113,8 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
+ select HAVE_PERF_USER_STACK_DUMP
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select ARCH_WANT_IPC_PARSE_VERSION
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h
b/arch/powerpc/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..b6120dc
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -0,0 +1,70 @@
+#ifndef _ASM_POWERPC_PERF_REGS_H
+#define _ASM_POWERPC_PERF_REGS_H
+
+#ifndef __powerpc64__
+#error Support for 32bit processors is TBD.
+#endif
+
+enum perf_event_powerpc_regs {
+ /*
+* The order of these values are based on the corresponding
+* macros in arch/powerpc/include/uapi/asm/ptrace.h .
+*/
+ PERF_REG_POWERPC_GPR0,
+ PERF_REG_POWERPC_GPR1,
+ PERF_REG_POWERPC_GPR2,
+ PERF_REG_POWERPC_GPR3,
+ PERF_REG_POWERPC_GPR4,
+ PERF_REG_POWERPC_GPR5,
+ PERF_REG_POWERPC_GPR6,
+ PERF_REG_POWERPC_GPR7,
+ PERF_REG_POWERPC_GPR8,
+ PERF_REG_POWERPC_GPR9,
+
+ PERF_REG_POWERPC_GPR10,
+ PERF_REG_POWERPC_GPR11,
+ PERF_REG_POWERPC_GPR12,
+ PERF_REG_POWERPC_GPR13,
+ PERF_REG_POWERPC_GPR14,
+ PERF_REG_POWERPC_GPR15,
+ PERF_REG_POWERPC_GPR16,
+ PERF_REG_POWERPC_GPR17,
+ PERF_REG_POWERPC_GPR18,
+ PERF_REG_POWERPC_GPR19,
+
+ PERF_REG_POWERPC_GPR20,
+ PERF_REG_POWERPC_GPR21,
+ PERF_REG_POWERPC_GPR22,
+ PERF_REG_POWERPC_GPR23,
+ PERF_REG_POWERPC_GPR24,
+ PERF_REG_POWERPC_GPR25,
+ PERF_REG_POWERPC_GPR26,
+ PERF_REG_POWERPC_GPR27,
+ PERF_REG_POWERPC_GPR28,
+ PERF_REG_POWERPC_GPR29,
+
+ PERF_REG_POWERPC_GPR30,
+ PERF_REG_POWERPC_GPR31,
+
+ PERF_REG_POWERPC_NIP,
+ PERF_REG_POWERPC_MSR,
+ PERF_REG_POWERPC_ORIG_GPR3,
+ PERF_REG_POWERPC_CTR, /* 35 */
+
+ PERF_REG_POWERPC_LINK,
+ PERF_REG_POWERPC_XER,
+ PERF_REG_POWERPC_CCR,
+#ifdef __powerpc64__
+ PERF_REG_POWERPC_SOFTE,
+#else
+ PERF_REG_POWERPC_MQ,
+#endif
+ PERF_REG_POWERPC_TRAP, /* 40 */
+
+ PERF_REG_POWERPC_DAR,
+ PERF_REG_POWERPC_DSISR,
+ PERF_REG_POWERPC_RESULT,
+ PERF_REG_POWERPC_DSCR,
+ PERF_REG_POWERPC_MAX
+};
+#endif
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index 60d71ee..44fec45 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,6 +2,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
obj-$(CONFIG_PERF_EVENTS) += callchain.o
+obj-$(CONFIG_HAVE_PERF_REGS) += perf-regs.o
obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o \
diff --git a/arch/powerpc/perf/perf-regs.c b/arch/powerpc/perf/perf-regs.c
new file mode 100644
index 000..3963038
--- /dev/null
+++ b/arch/powerpc/perf/perf-regs.c
@@ -0,0 +1,104 @@
+#include
+#include
+#include
+#include
+#include
+
+#define PT_REGS_GPR_OFFSET(g) \
+ [PERF_REG_POWERPC_GPR##g] = offsetof(struct pt_regs, gpr[g])
+
+#define PT_REGS_OFFSET(n, r) \
+ [PERF_REG_POWERPC_##n] = offsetof(struct pt_regs, r)
+
+/*
+ * An enum in arch/powerpc/include/uapi/asm/perf_regs.h assigns an "id" to
+ * each register in Power. Build a table mapping each register id to its
+ * offset in 'struct pt_regs', that we can use to quickly read-from or
+ * write-to the register in pt_regs.
+ */
+static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
+ PT_REGS_GPR_OFFSET(0),
+ PT_REGS_GPR_OFFSET(1),
+ PT_REGS_GPR_OFFSET(2),
+ PT_REGS_GPR_OFFSET(3),
+ PT_REGS_GPR_OFFSET(4),
+ PT_REGS_GPR_
Re: [PATCH v2 1/2] i2c: add DMA support for freescale i2c driver
On Thursday, March 06, 2014 at 05:36:14 AM, Yao Yuan wrote: > On Thu, March 06, 2014 at 11:23:50 AM, Marek Vasut wrote: > > On Wednesday, March 05, 2014 at 07:52:31 AM, Yuan Yao wrote: > > > Add dma support for i2c. This function depend on DMA driver. > > > You can turn on it by write both the dmas and dma-name properties in > > > dts node. > > > > > > Signed-off-by: Yuan Yao > > > --- > > > > [...] > > > > > @@ -601,6 +826,7 @@ static int i2c_imx_probe(struct platform_device > > > > *pdev) > > > > > void __iomem *base; > > > int irq, ret; > > > u32 bitrate; > > > > > > + u32 phy_addr; > > > > > > dev_dbg(&pdev->dev, "<%s>\n", __func__); > > > > > > @@ -611,6 +837,7 @@ static int i2c_imx_probe(struct platform_device > > > > *pdev) > > > > > } > > > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > > > > + phy_addr = res->start; > > > > Uh ... Shawn, I really think I am lost here. Don't you need to map this > > memory before you can use it for DMA ? The DMA mapping function should > > give you the physical address and is the right way to go about this > > instead of pulling the address from here, no ? > > > > I might be wrong here, I am rather uncertain, so please help me out. > > Thanks! > > Hi, Marek, Thanks for your suggestion. > Here you can review the code in include/linux/ioport.h > The resource->start describes the entity on the CPU bus as a starting > physical address. So I thinks it can used for dma directly. This doesn't feel right for some reason. If this is a register area, you should ioremap() it. If it's a memory area you do DMA to/from, you need to make sure you correctly flush/invalidate caches and properly handle the effects the write buffer might have. But I have a feeling you actually do DMA to/from register space here ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/2] i2c: add DMA support for freescale i2c driver
On Thu, March 06, 2014 at 11:23:50 AM, Marek Vasut wrote: > On Wednesday, March 05, 2014 at 07:52:31 AM, Yuan Yao wrote: > > Add dma support for i2c. This function depend on DMA driver. > > You can turn on it by write both the dmas and dma-name properties in > > dts node. > > > > Signed-off-by: Yuan Yao > > --- > > [...] > > > @@ -601,6 +826,7 @@ static int i2c_imx_probe(struct platform_device > *pdev) > > void __iomem *base; > > int irq, ret; > > u32 bitrate; > > + u32 phy_addr; > > > > dev_dbg(&pdev->dev, "<%s>\n", __func__); > > > > @@ -611,6 +837,7 @@ static int i2c_imx_probe(struct platform_device > *pdev) > > } > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + phy_addr = res->start; > > Uh ... Shawn, I really think I am lost here. Don't you need to map this > memory before you can use it for DMA ? The DMA mapping function should > give you the physical address and is the right way to go about this > instead of pulling the address from here, no ? > > I might be wrong here, I am rather uncertain, so please help me out. > Thanks! Hi, Marek, Thanks for your suggestion. Here you can review the code in include/linux/ioport.h The resource->start describes the entity on the CPU bus as a starting physical address. So I thinks it can used for dma directly.
Re: [RESEND Patch 0/9] dts pending patches for TI omap
On Thursday 06 March 2014 01:20 AM, Tony Lindgren wrote: > * Mugunthan V N [140303 06:53]: >> Benoit/Tony >> >> Here I am send all the pending dt patches that can go into 3.15 merge window, >> all the patches were already posted to mailing list and has beed reviewed. >> >> I have rebased the patches on top of >> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git >> omap-for-v3.15/dt >> and fixed all the merge conflicts. >> >> Pasting the mail archive for the patches series >> >> * Add ABB device nodes >> http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html >> >> * MMC hot plug support >> http://mail.blameitonlove.com/lists/linux-omap/msg101933.html >> Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as >> this >> is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a >> >> * DRA7 Cross bar DTS patches >> Cross bar driver has been pulled for next merge, so the dts patches can also >> be pulled for next merge window. >> >> Here is the pull request for the same patch series. >> >> The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84: >> >> Merge tag 'for_3.15/dts_signed' of >> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into >> omap-for-v3.15/dt (2014-03-02 14:22:03 -0800) >> >> are available in the git repository at: >> >> >> git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15 >> >> for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4: >> >> ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 >> 19:53:25 +0530) > > Thanks applying all except for the crossbar ones into > omap-for-v3.15/dt. > > Please resend the last three patches once the dependencies > are merged to mainline kernel as otherwise the interrupt > nubers are all wrong without the crossbar driver related > code. Ok, i will resend when the dependencies are merged Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] serial: sh-sci: Add missing call to uart_remove_one_port() in failure path
On Thu, Mar 06, 2014 at 01:19:13PM +0900, Simon Horman wrote:
> On Fri, Feb 28, 2014 at 02:21:33PM +0100, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven
> >
> > If cpufreq_register_notifier() fails, we have to remove the port added by
> > sci_probe_single(), which is not done by sci_cleanup_single().
> >
> > Else the serial port stays active from the point of view of the serial
> > subsystem, and it may crash when userspace getty is started, or when the
> > loadable driver module is unloaded.
> >
> > This was introduced by commit 6dae14216c85eea13db7b12c469475c5d30e5499
> > ("serial: sh-sci: Fix probe error paths").
> >
> > Signed-off-by: Geert Uytterhoeven
>
> Acked-by: Simon Horman
>
> This looks reasonable to me.
>
> Greg, could you take this one?
Will do, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: add pte_present() check on existing hugetlb_entry callbacks
On 03/04/2014 06:49 PM, Naoya Horiguchi wrote: > On Tue, Mar 04, 2014 at 05:46:52PM -0500, Sasha Levin wrote: >> On 03/04/2014 04:32 PM, Naoya Horiguchi wrote: >>> # sorry if duplicate message >>> >>> On Mon, Mar 03, 2014 at 04:38:41PM -0500, Sasha Levin wrote: On 03/03/2014 03:06 PM, Sasha Levin wrote: > On 03/03/2014 12:02 AM, Naoya Horiguchi wrote: >> Hi Sasha, >> I can confirm that with this patch the lockdep issue is gone. However, the NULL deref in walk_pte_range() and the BUG at mm/hugemem.c:3580 still appear. >> I spotted the cause of this problem. >> Could you try testing if this patch fixes it? > > I'm seeing a different failure with this patch: And the NULL deref still happens. >>> >>> I don't yet find out the root reason why this issue remains. >>> So I tried to run trinity myself but the problem didn't reproduce. >>> (I did simply like "./trinity --group vm --dangerous" a few hours.) >>> Could you show more detail or tips about how the problem occurs? >> >> I run it as root in a disposable vm, that may be the difference here. > > Sorry, I didn't write it but I also run it as root on VM, so condition is > the same. It might depend on kernel config, so I'm now trying the config > you previously gave me, but it doesn't boot correctly on my environment > (panic in initialization). I may need some time to get over this. I'd be happy to help with anything off-list, it shouldn't be too difficult to get that kernel to boot :) I've also reverted the page walker series for now, it makes it impossible to test anything else since it seems that hitting one of the issues is quite easy. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] mfd: max8997: use regmap to access registers
On Wed, Mar 05, 2014 at 10:54:39AM -0800, Dmitry Torokhov wrote: > On Wed, Mar 05, 2014 at 03:58:17PM +0100, Robert Baldyga wrote: > > -int max8997_write_reg(struct i2c_client *i2c, u8 reg, u8 value) > > +int max8997_write_reg(struct regmap *map, u8 reg, u8 value) > Why don't you make read/write reg to take struct max8997_dev as argument > instead of regmap? regmap seems to be the current implementation du jur, > but that is core's detail, functions do not need to care. Indeed, and had this been done originally this refactoring would be much smoother. signature.asc Description: Digital signature
[PATCH linux-next] sched: Fix broken setscheduler()
I decided to run my tests on linux-next, and my wakeup_rt tracer was
broken. After running a bisect, I found that the problem commit was:
linux-next commit c365c292d059
"sched: Consider pi boosting in setscheduler()"
And the reason the wake_rt tracer test was failing, was because it had
no RT task to trace. I first noticed this when running with
sched_switch event and saw that my RT task still had normal SCHED_OTHER
priority. Looking at the problem commit, I found:
- p->normal_prio = normal_prio(p);
- p->prio = rt_mutex_getprio(p);
With no
+ p->normal_prio = normal_prio(p);
+ p->prio = rt_mutex_getprio(p);
Reading what the commit is suppose to do, I realize that the p->prio
can't be set if the task is boosted with a higher prio, but the
p->normal_prio still needs to be set regardless, otherwise, when the
task is deboosted, it wont get the new priority.
The p->prio has to be set before "check_class_changed()" is called,
otherwise the class wont be changed.
Signed-off-by: Steven Rostedt
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4600bca..b1cc871 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3198,6 +3198,7 @@ static void __setscheduler_params(struct task_struct *p,
* getparam()/getattr() don't report silly values for !rt tasks.
*/
p->rt_priority = attr->sched_priority;
+ p->normal_prio = normal_prio(p);
set_load_weight(p);
}
@@ -3207,6 +3208,8 @@ static void __setscheduler(struct rq *rq, struct
task_struct *p,
{
__setscheduler_params(p, attr);
+ p->prio = rt_mutex_getprio(p);
+
if (dl_prio(p->prio))
p->sched_class = &dl_sched_class;
else if (rt_prio(p->prio))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Documentation: mfd: Add binding document for S2MPA01
On Wed, Mar 05, 2014 at 06:24:42PM +0800, Lee Jones wrote: > This document has been sitting on the MLs for nearly a month now. It > seems well written and doesn't add any new bindings. With that in mind > I'm inclined to take it though. However, as most of the important > configuration here is regulator related I'd like Mark Browns Ack on > it. Acked-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH] regulator: pfuze100: Add PFUZE200 support to Kconfig and module description
On Wed, Mar 05, 2014 at 06:02:43PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin Applied, thanks. signature.asc Description: Digital signature
[PATCH] mmc: sdhci-bcm-kona: Fix locking in sdhci_bcm_kona_sd_card_emulate()
Since sdhci_bcm_kona_sd_card_emulate() can be called from interrupt
context, we must use a spinlock instead of a mutex. This change
essentially restores the way things worked before the change to
mutexes in http://www.spinics.net/lists/linux-mmc/msg20276.html.
Without this change, we see "scheduling while atomic" errors.
Signed-off-by: Markus Mayer
---
drivers/mmc/host/sdhci-bcm-kona.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 7a190fe..f1b0a62 100644
--- a/drivers/mmc/host/sdhci-bcm-kona.c
+++ b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013 Broadcom Corporation
+ * Copyright (C) 2013-2014 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -53,7 +53,7 @@
#define KONA_MMC_AUTOSUSPEND_DELAY (50)
struct sdhci_bcm_kona_dev {
- struct mutexwrite_lock; /* protect back to back writes */
+ spinlock_t write_lock; /* protect back to back writes */
};
@@ -135,7 +135,7 @@ static int sdhci_bcm_kona_sd_card_emulate(struct sdhci_host
*host, int insert)
* insert-removal.
* We keep 20uS
*/
- mutex_lock(&kona_dev->write_lock);
+ spin_lock_bh(&kona_dev->write_lock);
udelay(20);
val = sdhci_readl(host, KONA_SDHOST_CORESTAT);
@@ -153,7 +153,7 @@ static int sdhci_bcm_kona_sd_card_emulate(struct sdhci_host
*host, int insert)
val &= ~KONA_SDHOST_CD_SW;
sdhci_writel(host, val, KONA_SDHOST_CORESTAT);
}
- mutex_unlock(&kona_dev->write_lock);
+ spin_unlock_bh(&kona_dev->write_lock);
return 0;
}
@@ -247,7 +247,7 @@ static int sdhci_bcm_kona_probe(struct platform_device
*pdev)
pltfm_priv = sdhci_priv(host);
kona_dev = sdhci_pltfm_priv(pltfm_priv);
- mutex_init(&kona_dev->write_lock);
+ spin_lock_init(&kona_dev->write_lock);
mmc_of_parse(host->mmc);
--
1.9.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 2/2] serial: sh-sci: Add missing call to uart_remove_one_port() in failure path
On Fri, Feb 28, 2014 at 02:21:33PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> If cpufreq_register_notifier() fails, we have to remove the port added by
> sci_probe_single(), which is not done by sci_cleanup_single().
>
> Else the serial port stays active from the point of view of the serial
> subsystem, and it may crash when userspace getty is started, or when the
> loadable driver module is unloaded.
>
> This was introduced by commit 6dae14216c85eea13db7b12c469475c5d30e5499
> ("serial: sh-sci: Fix probe error paths").
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Simon Horman
This looks reasonable to me.
Greg, could you take this one?
> ---
> This depends on "serial_core: Unregister console in uart_remove_one_port()"
> when using a serial console.
> ---
> drivers/tty/serial/sh-sci.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index be33d2b0613b..7958115e6a51 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2564,6 +2564,7 @@ static int sci_probe(struct platform_device *dev)
> ret = cpufreq_register_notifier(&sp->freq_transition,
> CPUFREQ_TRANSITION_NOTIFIER);
> if (unlikely(ret < 0)) {
> + uart_remove_one_port(&sci_uart_driver, &sp->port);
> sci_cleanup_single(sp);
> return ret;
> }
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Patch[Kernel 3.13.5]
Here is my first patch, adding a break point to fix bug 60845, case fallout through on switch in arch/mips/pci/msi-octeon.c. --- //home/nick/linux-3.13.5/arch/mips/pci/msi-octeon.c.orig 2014-03-05 22:48:19.084372515 -0500 +++ //home/nick/linux-3.13.5/arch/mips/pci/msi-octeon.c 2014-03-05 22:48:48.388372344 -0500 @@ -150,6 +150,7 @@ msi_irq_allocated: msg.address_lo = ((128ul << 20) + CVMX_PCI_MSI_RCV) & 0x; msg.address_hi = ((128ul << 20) + CVMX_PCI_MSI_RCV)>> 32; + break; case OCTEON_DMA_BAR_TYPE_BIG: /* When using big bar, Bar 0 is based at 0 */ msg.address_lo = (0 + CVMX_PCI_MSI_RCV) & 0x; Got one error no maintainer otherwise not issues with coding style. Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the tip tree
On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/irqchip/irq-armada-370-xp.c:415:1: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute
> have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute
> have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have
> effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute
> have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute
> have effect only on public objects [-Wattributes]
>
> Probably introduced by commit 128ea04a9885 ("lto: Make asmlinkage __visible").
>
> I guess that there may be more places where "asmlinkage" is used with
> "static" - I assume that they are all incorrect?
>
> $ git grep -l 'static.*asmlinkage'
> arch/x86/crypto/sha1_ssse3_glue.c
> arch/x86/crypto/sha256_ssse3_glue.c
> arch/x86/crypto/sha512_ssse3_glue.c
> drivers/irqchip/irq-armada-370-xp.c
> drivers/irqchip/irq-bcm2835.c
> drivers/irqchip/irq-gic.c
> drivers/irqchip/irq-mmp.c
> drivers/irqchip/irq-moxart.c
> drivers/irqchip/irq-orion.c
> drivers/irqchip/irq-sirfsoc.c
> drivers/irqchip/irq-sun4i.c
> drivers/irqchip/irq-vic.c
> drivers/irqchip/irq-vt8500.c
> drivers/irqchip/irq-zevio.c
> drivers/pnp/pnpbios/bioscalls.c
> scripts/checkpatch.pl
>
> (the last two don't matter)
Any resolution for this?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpKBheadjxUf.pgp
Description: PGP signature
[PATCH 1/5] SDHCI: Add a generic registration to the SDHCI platform driver
This patch adds a generic platform driver registration to the exiting SDHCI
platform driver using the devicetree compatibility string "generic-sdhci".
Signed-off-by: Alistair Popple
---
.../devicetree/bindings/mmc/sdhci-pltfm.txt| 16 +
drivers/mmc/host/sdhci-pltfm.c | 28 ++
2 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pltfm.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pltfm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pltfm.txt
new file mode 100644
index 000..3940659
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pltfm.txt
@@ -0,0 +1,16 @@
+Generic SHDCI platform driver
+
+The generic SDHCI platform driver should support most SDHCI host
+controllers. It uses the compatible="generic-sdhci" property and
+supports the following device tree properties as described in mmc.txt.
+
+Supported properties (described in mmc.txt):
+- reg
+- interrupts
+- wp-inverted
+- broken-cd
+- no-1-8-v
+- keep-power-in-suspend
+- enable-sdio-wakeup
+- bus-width
+- clock-frequency
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index bef250e..696d1f6 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -260,6 +260,34 @@ const struct dev_pm_ops sdhci_pltfm_pmops = {
EXPORT_SYMBOL_GPL(sdhci_pltfm_pmops);
#endif /* CONFIG_PM */
+static int sdhci_generic_probe(struct platform_device *pdev)
+{
+ return sdhci_pltfm_register(pdev, NULL, 0);
+}
+
+static int sdhci_generic_remove(struct platform_device *pdev)
+{
+ return sdhci_pltfm_unregister(pdev);
+}
+
+static const struct of_device_id sdhci_generic_of_match[] = {
+ { .compatible = "generic-sdhci" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdhci_generic_of_match);
+
+static struct platform_driver sdhci_generic_driver = {
+ .driver = {
+ .name = "sdhci-generic",
+ .owner = THIS_MODULE,
+ .of_match_table = sdhci_generic_of_match,
+ .pm = SDHCI_PLTFM_PMOPS,
+ },
+ .probe = sdhci_generic_probe,
+ .remove = sdhci_generic_remove,
+};
+module_platform_driver(sdhci_generic_driver);
+
static int __init sdhci_pltfm_drv_init(void)
{
pr_info("sdhci-pltfm: SDHCI platform and OF driver helper\n");
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] IBM Akebono: Add support for a new PHY interface to the IBM emac driver
The IBM PPC476GTR SoC that is used on the Akebono board uses a different ethernet PHY interface that has wake on lan (WOL) support with the IBM emac. This patch adds support to the IBM emac driver for this new PHY interface. At this stage the wake on lan functionality has not been implemented. Signed-off-by: Alistair Popple Acked-by: Benjamin Herrenschmidt --- .../devicetree/bindings/powerpc/4xx/emac.txt | 9 + drivers/net/ethernet/ibm/emac/Kconfig | 4 + drivers/net/ethernet/ibm/emac/Makefile | 1 + drivers/net/ethernet/ibm/emac/core.c | 50 - drivers/net/ethernet/ibm/emac/core.h | 12 + drivers/net/ethernet/ibm/emac/rgmii_wol.c | 244 + drivers/net/ethernet/ibm/emac/rgmii_wol.h | 62 ++ 7 files changed, 376 insertions(+), 6 deletions(-) create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.c create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.h diff --git a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt index 712baf6..0c20529 100644 --- a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt @@ -61,6 +61,8 @@ Fox Axon: present, whatever value is appropriate for each EMAC, that is the content of the current (bogus) "phy-port" property. +- rgmii-wol-device : 1 cell, required iff connected to a RGMII in the WKUP + power domain. phandle of the RGMII-WOL device node. Optional properties: - phy-address : 1 cell, optional, MDIO address of the PHY. If absent, @@ -146,3 +148,10 @@ available. For Axon: 0x012a + iv) RGMII-WOL node + +Required properties: +- compatible : compatible list, containing 2 entries, first is + "ibm,rgmii-wol-CHIP" where CHIP is the host ASIC (like + EMAC) and the second is "ibm,rgmii-wol". +- reg: diff --git a/drivers/net/ethernet/ibm/emac/Kconfig b/drivers/net/ethernet/ibm/emac/Kconfig index 3f44a30..56ea346 100644 --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool "IBM EMAC RGMII wake-on-LAN support" if COMPILE_TEST + default n + config IBM_EMAC_TAH bool default n diff --git a/drivers/net/ethernet/ibm/emac/Makefile b/drivers/net/ethernet/ibm/emac/Makefile index eba2183..8843803 100644 --- a/drivers/net/ethernet/ibm/emac/Makefile +++ b/drivers/net/ethernet/ibm/emac/Makefile @@ -7,5 +7,6 @@ obj-$(CONFIG_IBM_EMAC) += ibm_emac.o ibm_emac-y := mal.o core.o phy.o ibm_emac-$(CONFIG_IBM_EMAC_ZMII) += zmii.o ibm_emac-$(CONFIG_IBM_EMAC_RGMII) += rgmii.o +ibm_emac-$(CONFIG_IBM_EMAC_RGMII_WOL) += rgmii_wol.o ibm_emac-$(CONFIG_IBM_EMAC_TAH) += tah.o ibm_emac-$(CONFIG_IBM_EMAC_DEBUG) += debug.o diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c index ae342fd..ff58474 100644 --- a/drivers/net/ethernet/ibm/emac/core.c +++ b/drivers/net/ethernet/ibm/emac/core.c @@ -632,6 +632,8 @@ static int emac_configure(struct emac_instance *dev) if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_set_speed(dev->rgmii_dev, dev->rgmii_port, dev->phy.speed); + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_set_speed(dev->rgmii_wol_dev, dev->phy.speed); if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII)) zmii_set_speed(dev->zmii_dev, dev->zmii_port, dev->phy.speed); @@ -799,6 +801,8 @@ static int __emac_mdio_read(struct emac_instance *dev, u8 id, u8 reg) zmii_get_mdio(dev->zmii_dev, dev->zmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_get_mdio(dev->rgmii_dev, dev->rgmii_port); + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_get_mdio(dev->rgmii_wol_dev); /* Wait for management interface to become idle */ n = 20; @@ -846,6 +850,8 @@ static int __emac_mdio_read(struct emac_instance *dev, u8 id, u8 reg) DBG2(dev, "mdio_read -> %04x" NL, r); err = 0; bail: + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_put_mdio(dev->rgmii_wol_dev); if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_put_mdio(dev->rgmii_dev, dev->rgmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII)) @@ -871,6 +877,8 @@ static void __emac_mdio_write(struct emac_instance *dev, u8 id, u8 reg, zmii_get_mdio(dev->zmii_dev, dev->zmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS
Re: [PATCHv3] Generic Mailbox API
On Sun, Feb 16, 2014 at 2:22 AM, Jassi Brar wrote: > Hello, > > Here is what the generic mailbox api looks like after modifications > to make it work with 5 different platforms. > Major feedback from Suman Anna(TI), LeyFoon Tan(Intel), > Craig McGeachie(Broadcom) and Loic Pallardy(ST). > If there are no more comments, I plan to implement suggestion on this submission and issue v4 early next week (right now I am at Linaro Connect). Thanks Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] powerpc: Added PCI MSI support using the HSTA module
The PPC476GTR SoC supports message signalled interrupts (MSI) by writing
to special addresses within the High Speed Transfer Assist (HSTA) module.
This patch adds support for PCI MSI with a new system device. The DMA
window is also updated to allow access to the entire 42-bit address range
to allow PCI devices write access to the HSTA module.
Signed-off-by: Alistair Popple
---
.../devicetree/bindings/powerpc/4xx/hsta.txt | 19 ++
arch/powerpc/boot/dts/akebono.dts | 46 -
arch/powerpc/boot/treeboot-akebono.c | 15 --
arch/powerpc/platforms/44x/Kconfig | 2 +
arch/powerpc/sysdev/Kconfig| 6 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 215 +
arch/powerpc/sysdev/ppc4xx_pci.c | 8 +-
8 files changed, 287 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
create mode 100644 arch/powerpc/sysdev/ppc4xx_hsta_msi.c
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
new file mode 100644
index 000..c737c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
@@ -0,0 +1,19 @@
+
+ppc476gtr High Speed Serial Assist (HSTA) node
+==
+
+The 476gtr SoC contains a high speed serial assist module attached
+between the plb4 and plb6 system buses to provide high speed data
+transfer between memory and system peripherals as well as support for
+PCI message signalled interrupts.
+
+Currently only the MSI support is used by Linux using the following
+device tree entries:
+
+Require properties:
+- compatible : "ibm,476gtr-hsta-msi", "ibm,hsta-msi"
+- reg : register mapping for the HSTA MSI space
+- interrupt-parent : parent controller for mapping interrupts
+- interrupts : ordered interrupt mapping for each MSI in the register
+ space. The first interrupt should be associated with a
+ register offset of 0x00, the second to 0x10, etc.
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index 96ac13b..f92ecfe 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -82,6 +82,28 @@
ranges;
clock-frequency = <2>; // 200Mhz
+ HSTA0: hsta@31e {
+ compatible = "ibm,476gtr-hsta-msi", "ibm,hsta-msi";
+ reg = <0x310 0x000e 0x0 0xf0>;
+ interrupt-parent = <&MPIC>;
+ interrupts = <108 0
+ 109 0
+ 110 0
+ 111 0
+ 112 0
+ 113 0
+ 114 0
+ 115 0
+ 116 0
+ 117 0
+ 118 0
+ 119 0
+ 120 0
+ 121 0
+ 122 0
+ 123 0>;
+ };
+
MAL0: mcmal {
compatible = "ibm,mcmal-476gtr", "ibm,mcmal2";
dcr-reg = <0xc000 0x062>;
@@ -242,8 +264,10 @@
ranges = <0x0200 0x 0x8000 0x0110
0x8000 0x0 0x8000
0x0100 0x00x00x0140
0x00x0 0x0001>;
- /* Inbound starting at 0 to memsize filled in by zImage
*/
- dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 0x0>;
+ /* Inbound starting at 0x0 to 0x400. In order
to use MSI
+* PCI devices must be able to write to the HSTA module.
+*/
+ dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x400 0x0>;
/* This drives busses 0 to 0xf */
bus-range = <0x0 0xf>;
@@ -280,8 +304,10 @@
ranges = <0x0200 0x 0x8000 0x0210
0x8000 0x0 0x8000
0x0100 0x00x00x0240
0x00x0 0x0001>;
- /* Inbound starting at 0 to memsize filled in by zImage
*/
- dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 0x0>;
+ /* Inbound starting at 0x0 to 0x400. In order
to use MSI
+* PCI devices must be able to write to the HSTA module.
+
[PATCH 4/5] IBM Akebono: Add the Akebono platform
This patch adds support for the IBM Akebono board.
Signed-off-by: Alistair Popple
---
.../devicetree/bindings/powerpc/4xx/akebono.txt| 54 +++
arch/powerpc/boot/Makefile | 3 +
arch/powerpc/boot/dcr.h| 4 +
arch/powerpc/boot/dts/akebono.dts | 385 +
arch/powerpc/boot/treeboot-akebono.c | 178 ++
arch/powerpc/boot/wrapper | 3 +
arch/powerpc/configs/44x/akebono_defconfig | 148
arch/powerpc/platforms/44x/Kconfig | 26 ++
arch/powerpc/platforms/44x/Makefile| 1 +
arch/powerpc/platforms/44x/ppc476.c| 112 --
arch/powerpc/sysdev/ppc4xx_pci.c | 13 +-
11 files changed, 901 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
create mode 100644 arch/powerpc/boot/dts/akebono.dts
create mode 100644 arch/powerpc/boot/treeboot-akebono.c
create mode 100644 arch/powerpc/configs/44x/akebono_defconfig
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
new file mode 100644
index 000..db93921
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
@@ -0,0 +1,54 @@
+
+IBM Akebono board device tree
+=
+
+The IBM Akebono board is a development board for the PPC476GTR SoC.
+
+0) The root node
+
+ Required properties:
+
+ - model : "ibm,akebono".
+ - compatible : "ibm,akebono" , "ibm,476gtr".
+
+1.a) The Secure Digital Host Controller Interface (SDHCI) node
+
+ Represent the Secure Digital Host Controller Interfaces.
+
+ Required properties:
+
+ - compatible : should be "ibm,476gtr-sdhci","generic-sdhci".
+ - reg : should contain the SDHCI registers location and length.
+ - interrupt-parent : a phandle for the interrupt controller.
+ - interrupts : should contain the SDHCI interrupt.
+
+1.b) The Advanced Host Controller Interface (AHCI) SATA node
+
+ Represents the advanced host controller SATA interface.
+
+ Required properties:
+
+ - compatible : should be "ibm,476gtr-ahci".
+ - reg : should contain the AHCI registers location and length.
+ - interrupt-parent : a phandle for the interrupt controller.
+ - interrupts : should contain the AHCI interrupt.
+
+1.c) The FPGA node
+
+ The Akebono board stores some board information such as the revision
+ number in an FPGA which is represented by this node.
+
+ Required properties:
+
+ - compatible : should be "ibm,akebono-fpga".
+ - reg : should contain the FPGA registers location and length.
+
+1.d) The AVR node
+
+ The Akebono board has an Atmel AVR microprocessor attached to the I2C
+ bus as a power controller for the board.
+
+ Required properties:
+
+ - compatible : should be "ibm,akebono-avr".
+ - reg : should contain the I2C bus address for the AVR.
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 90e9d95..0a079a3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -47,6 +47,7 @@ $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-iss4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=405
+$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=405
$(obj)/virtex405-head.o: BOOTAFLAGS += -mcpu=405
@@ -86,6 +87,7 @@ src-plat-$(CONFIG_44x) += treeboot-ebony.c cuboot-ebony.c
treeboot-bamboo.c \
cuboot-taishan.c cuboot-katmai.c \
cuboot-warp.c cuboot-yosemite.c \
treeboot-iss4xx.c treeboot-currituck.c \
+ treeboot-akebono.c \
simpleboot.c fixed-head.S virtex.c
src-plat-$(CONFIG_8xx) += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c
src-plat-$(CONFIG_PPC_MPC52xx) += cuboot-52xx.c
@@ -236,6 +238,7 @@ image-$(CONFIG_YOSEMITE)+= cuImage.yosemite
image-$(CONFIG_ISS4xx) += treeImage.iss4xx \
treeImage.iss4xx-mpic
image-$(CONFIG_CURRITUCK) += treeImage.currituck
+image-$(CONFIG_AKEBONO)+= treeImage.akebono
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_MPC86XADS) += cuImage.mpc866ads
diff --git a/arch/powerpc/boot/dcr.h b/arch/powerpc/boot/dcr.h
index cc73f7a..bf8f4ed 100644
--- a/arch/powerpc/boot/dcr.h
+++ b/arch/powerpc/boot/dcr.h
@@ -15,6 +15,10 @@
asm volatile("mfdcrx %0,%1" : "=r"(rval) : "r"(rn)); \
rval; \
})
+#define mtdcrx(rn, val) \
+ ({ \
+ asm volatile("mtdcrx %0,%1" : : "r"(rn), "r" (val)); \
+ })
/* 440GP/440GX SDRAM controller DCRs */
#define DCRN_SDRAM0_CFGADDR
[PATCH 0/5] V2 IBM Akebono/PPC46GTR Support
The IBM Akebono board is a development board for the new PPC476GTR system on chip (SoC). This version of the series updates the device tree and drops the USB patches as the equivalent functionality is already in linux-next. It also addresses feedback from the previous submission. Alistair Popple (5): SDHCI: Add a generic registration to the SDHCI platform driver IBM Akebono: Add support for a new PHY interface to the IBM emac driver IBM Currituck: Clean up board specific code before adding Akebono code IBM Akebono: Add the Akebono platform powerpc: Added PCI MSI support using the HSTA module .../devicetree/bindings/mmc/sdhci-pltfm.txt| 16 + .../devicetree/bindings/powerpc/4xx/akebono.txt| 54 +++ .../devicetree/bindings/powerpc/4xx/emac.txt | 9 + .../devicetree/bindings/powerpc/4xx/hsta.txt | 19 + arch/powerpc/boot/Makefile | 3 + arch/powerpc/boot/dcr.h| 4 + arch/powerpc/boot/dts/akebono.dts | 415 + arch/powerpc/boot/treeboot-akebono.c | 163 arch/powerpc/boot/wrapper | 3 + arch/powerpc/configs/44x/akebono_defconfig | 148 arch/powerpc/platforms/44x/Kconfig | 28 ++ arch/powerpc/platforms/44x/Makefile| 3 +- arch/powerpc/platforms/44x/currituck.c | 233 arch/powerpc/platforms/44x/ppc476.c| 299 +++ arch/powerpc/sysdev/Kconfig| 6 + arch/powerpc/sysdev/Makefile | 1 + arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 215 +++ arch/powerpc/sysdev/ppc4xx_pci.c | 21 +- drivers/mmc/host/sdhci-pltfm.c | 28 ++ drivers/net/ethernet/ibm/emac/Kconfig | 4 + drivers/net/ethernet/ibm/emac/Makefile | 1 + drivers/net/ethernet/ibm/emac/core.c | 50 ++- drivers/net/ethernet/ibm/emac/core.h | 12 + drivers/net/ethernet/ibm/emac/rgmii_wol.c | 244 drivers/net/ethernet/ibm/emac/rgmii_wol.h | 62 +++ 25 files changed, 1796 insertions(+), 245 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pltfm.txt create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/akebono.txt create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/hsta.txt create mode 100644 arch/powerpc/boot/dts/akebono.dts create mode 100644 arch/powerpc/boot/treeboot-akebono.c create mode 100644 arch/powerpc/configs/44x/akebono_defconfig delete mode 100644 arch/powerpc/platforms/44x/currituck.c create mode 100644 arch/powerpc/platforms/44x/ppc476.c create mode 100644 arch/powerpc/sysdev/ppc4xx_hsta_msi.c create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.c create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] IBM Currituck: Clean up board specific code before adding Akebono code
The IBM Akebono code uses the same initialisation functions as the
earlier Currituck board. Rather than create a copy of this code for
Akebono we will instead integrate support for it into the same file as
the Currituck code.
This patch just renames the board support file and updates the Makefile.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/44x/Makefile| 2 +-
arch/powerpc/platforms/44x/currituck.c | 233 -
arch/powerpc/platforms/44x/ppc476.c| 233 +
3 files changed, 234 insertions(+), 234 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/currituck.c
create mode 100644 arch/powerpc/platforms/44x/ppc476.c
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index d03833a..f896b89 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -10,4 +10,4 @@ obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
-obj-$(CONFIG_CURRITUCK)+= currituck.o
+obj-$(CONFIG_CURRITUCK)+= ppc476.o
diff --git a/arch/powerpc/platforms/44x/currituck.c
b/arch/powerpc/platforms/44x/currituck.c
deleted file mode 100644
index 7f1b71a..000
--- a/arch/powerpc/platforms/44x/currituck.c
+++ /dev/null
@@ -1,233 +0,0 @@
-/*
- * Currituck board specific routines
- *
- * Copyright © 2011 Tony Breeds IBM Corporation
- *
- * Based on earlier code:
- *Matt Porter
- *Copyright 2002-2005 MontaVista Software Inc.
- *
- *Eugene Surovegin or
- *Copyright (c) 2003-2005 Zultys Technologies
- *
- *Rewritten and ported to the merged powerpc tree:
- *Copyright 2007 David Gibson , IBM Corporation.
- *Copyright © 2011 David Kliekamp IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-static __initdata struct of_device_id ppc47x_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,plb6", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-/* The EEPROM is missing and the default values are bogus. This forces USB in
- * to EHCI mode */
-static void quirk_ppc_currituck_usb_fixup(struct pci_dev *dev)
-{
- if (of_machine_is_compatible("ibm,currituck")) {
- pci_write_config_dword(dev, 0xe0, 0x0114231f);
- pci_write_config_dword(dev, 0xe4, 0x6c40);
- }
-}
-DECLARE_PCI_FIXUP_HEADER(0x1033, 0x0035, quirk_ppc_currituck_usb_fixup);
-
-static int __init ppc47x_device_probe(void)
-{
- of_platform_bus_probe(NULL, ppc47x_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(ppc47x, ppc47x_device_probe);
-
-/* We can have either UICs or MPICs */
-static void __init ppc47x_init_irq(void)
-{
- struct device_node *np;
-
- /* Find top level interrupt controller */
- for_each_node_with_property(np, "interrupt-controller") {
- if (of_get_property(np, "interrupts", NULL) == NULL)
- break;
- }
- if (np == NULL)
- panic("Can't find top level interrupt controller");
-
- /* Check type and do appropriate initialization */
- if (of_device_is_compatible(np, "chrp,open-pic")) {
- /* The MPIC driver will get everything it needs from the
-* device-tree, just pass 0 to all arguments
-*/
- struct mpic *mpic =
- mpic_alloc(np, 0, MPIC_NO_RESET, 0, 0, " MPIC ");
- BUG_ON(mpic == NULL);
- mpic_init(mpic);
- ppc_md.get_irq = mpic_get_irq;
- } else
- panic("Unrecognized top level interrupt controller");
-}
-
-#ifdef CONFIG_SMP
-static void smp_ppc47x_setup_cpu(int cpu)
-{
- mpic_setup_this_cpu();
-}
-
-static int smp_ppc47x_kick_cpu(int cpu)
-{
- struct device_node *cpunode = of_get_cpu_node(cpu, NULL);
- const u64 *spin_table_addr_prop;
- u32 *spin_table;
- extern void start_secondary_47x(void);
-
- BUG_ON(cpunode == NULL);
-
- /* Assume spin table. We could test for the enable-method in
-* the device-tree but currently there's little point as it's
-* our only supported method
-*/
- spin_table_addr_prop =
- of_get_property(cpunode, "cpu-release-addr", NULL);
-
- if (spin_table_addr_prop == NULL) {
- pr_err("CPU%d: Can't start, missing cpu-release-addr !\n",
- cpu);
- retur
Re: [PATCH] KEYS: Make the keyring cycle detector ignore other keyrings of the same name
Acked-by: James Morris
On Tue, 4 Mar 2014, David Howells wrote:
>
> This fixes CVE-2014-0102.
>
> The following command sequence produces an oops:
>
> keyctl new_session
> i=`keyctl newring _ses @s`
> keyctl link @s $i
>
> The problem is that search_nested_keyrings() sees two keyrings that have
> matching type and description, so keyring_compare_object() returns true.
> s_n_k() then passes the key to the iterator function -
> keyring_detect_cycle_iterator() - which *should* check to see whether this is
> the keyring of interest, not just one with the same name.
>
> Because assoc_array_find() will return one and only one match, I assumed that
> the iterator function would only see an exact match or never be called - but
> the iterator isn't only called from assoc_array_find()...
>
> The oops looks something like this:
>
> kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
> invalid opcode: [#1] SMP
> ...
> RIP: 0010:[] keyring_detect_cycle_iterator+0xe/0x1f
> ...
> Stack:
> ...
> Call Trace:
>[] search_nested_keyrings+0x76/0x2aa
>[] ? kmem_cache_alloc_trace+0xdd/0x159
>[] ? assoc_array_insert+0xab/0x929
>[] ? selinux_key_permission+0x2d/0x2f
>[] ? security_key_permission+0x11/0x13
>[] __key_link_check_live_key+0x50/0x5f
>[] ? keyring_describe+0x7b/0x7b
>[] key_link+0x4e/0x85
>[] keyctl_keyring_link+0x60/0x81
>[] SyS_keyctl+0x65/0xe4
>[] tracesys+0xdd/0xe2
>
> The fix is to make keyring_detect_cycle_iterator() check that the key it has
> is the key it was actually looking for rather than calling BUG_ON().
>
> A testcase has been included in the keyutils testsuite for this:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790b
>
> Reported-by: Tommi Rantala
> Signed-off-by: David Howells
> ---
> diff --git a/security/keys/keyring.c b/security/keys/keyring.c
> index d46cbc5e335e..2fb2576dc644 100644
> --- a/security/keys/keyring.c
> +++ b/security/keys/keyring.c
> @@ -1000,7 +1000,11 @@ static int keyring_detect_cycle_iterator(const void
> *object,
>
> kenter("{%d}", key->serial);
>
> - BUG_ON(key != ctx->match_data);
> + /* We might get a keyring with matching index-key that is nonetheless a
> + * different keyring. */
> + if (key != ctx->match_data)
> + return 0;
> +
> ctx->result = ERR_PTR(-EDEADLK);
> return 1;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
James Morris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
