Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 69/78] ncr5380: Fix whitespace in comments using regexp
On Sat, 2 Jan 2016, Joe Perches wrote:
> On Sun, 2016-01-03 at 16:06 +1100, Finn Thain wrote:
> > Hanging indentation was a poor choice for the text inside comments. It
> > has been used in the wrong places and done badly elsewhere. There is
> > little consistency within any file. One fork of the core driver uses
> > tabs for this indentation while the other uses spaces. Better to use
> > flush-left alignment throughout.
> >
> > This patch is the result of the following substitution. It replaces tabs
> > and spaces at the start of a comment line with a single space.
> >
> > perl -i -pe 's,^(\t*[/ ]\*)[ \t]+,$1 ,' drivers/scsi/{atari_,}NCR5380.c
> >
> > This removes some unimportant discrepancies between the two core driver
> > forks so that the important ones become obvious, to facilitate
> > reunification.
>
> I still think this patch is poor at best and
> overall not useful.
Opinions will differ.
> @@ -32,15 +32,15 @@
> > /*
> > * Further development / testing that should be done :
> > * 1. Cleanup the NCR5380_transfer_dma function and DMA operation complete
> > - * code so that everything does the same thing that's done at the
> > - * end of a pseudo-DMA read operation.
> > + * code so that everything does the same thing that's done at the
> > + * end of a pseudo-DMA read operation.
> > *
> > * 2. Fix REAL_DMA (interrupt driven, polled works fine) -
> > - * basically, transfer size needs to be reduced by one
> > - * and the last byte read as is done with PSEUDO_DMA.
> > + * basically, transfer size needs to be reduced by one
> > + * and the last byte read as is done with PSEUDO_DMA.
> > *
> > * 4. Test SCSI-II tagged queueing (I have no devices which support
> > - * tagged queueing)
> > + * tagged queueing)
>
> Numbering 1, 2, then 4 could be improved.
That would be churn. I have other plans for the To Do list. The numbering
will get fixed as items are removed.
--
Re: rcu_preempt self-detected stall on CPU from 4.4-rc4, since 3.17
I would not describe the load on this test machine as high or real time. Apart from a number of standard daemons not much more is running at all! I normally build a release kernel as soon as possible and set it running. Typically I run a series of benchmarks to confirm most things appear to be working and then just leave it running. During a normal day i will check on the machine 4/5 times just to see how its going! Typically I will logon remotely via wifi network connection. just for your information i will include a few other stack traces from previous kernels that may show some trend! Please see the attachments. Regards, Ross On Sun, Jan 3, 2016 at 5:17 PM, Paul E. McKenney wrote: > On Sun, Jan 03, 2016 at 04:29:11PM +1100, Ross Green wrote: >> Still seeing these rcu_preempt stalls on kernels through to 4.4-rc7 >> >> Still have not found a sure fire method to evoke this stall, but have >> found that it will normally occur within a week of running a kernel - >> usually when it is quiet with light load. >> >> Have seen similar self detected stalls all the way back to 3.17. >> Most recent kernels have included 4.4-rc5 4.4-rc6 and 4.4-rc7 >> >> Regards, >> >> Ross >> >> On Fri, Dec 11, 2015 at 10:17 PM, Ross Green wrote: >> > I have been getting these stalls in kernels going back to 3.17. >> > >> > This stall occurs usually under light load but often requires several >> > days to show itself. I have not found any simple way to trigger the >> > stall. Indeed heavy workloads seems not to show the fault. >> > >> > Anyone have any thoughts here? >> > >> > The recent patch by peterz with kernel/sched/wait.c I thought might >> > help the situation, but alas after a few days of running 4.4-rc4 the >> > following turned up. >> > >> > [179922.003570] INFO: rcu_preempt self-detected stall on CPU >> > [179922.008178] INFO: rcu_preempt detected stalls on CPUs/tasks: >> > [179922.008178] 0-...: (1 ticks this GP) idle=a91/1/0 > > CPU 0 is non-idle from an RCU perspective. > >> > softirq=1296733/1296733 fqs=0 >> > [179922.008178] >> > [179922.008209] (detected by 1, t=8775 jiffies, g=576439, c=576438, q=102) >> > [179922.008209] Task dump for CPU 0: >> > [179922.008209] swapper/0 R [179922.008209] running [179922.008209] >> > 0 0 0 0x >> > [179922.008209] Backtrace: >> > >> > [179922.008239] Backtrace aborted due to bad frame pointer > > Can't have everything, I guess... > >> > [179922.008239] rcu_preempt kthread starved for 8775 jiffies! g576439 >> > c576438 f0x0 s3 ->state=0x1 > > Something is keeping the rcu_preempt grace-period kthread from > running. This far into the grace period, it should have a > timer event waking it every few jiffies. It is currently > in TASK_INTERRUPTIBLE state. > >> > [179922.060302] 0-...: (1 ticks this GP) idle=a91/1/0 >> > softirq=1296733/1296733 fqs=0 >> > [179922.068023] (t=8775 jiffies g=576439 c=576438 q=102) >> > [179922.073913] rcu_preempt kthread starved for 8775 jiffies! g576439 >> > c576438 f0x2 s3 ->state=0x100 > > Same story, same grace period, pretty much same time. Now there is an FQS > request (f0x2) and the state is now TASK_WAKING (->state=0x100 == 256). > >> > [179922.083587] Task dump for CPU 0: >> > [179922.087097] swapper/0 R running 0 0 0 0x >> > [179922.093292] Backtrace: >> > [179922.096313] [] (dump_backtrace) from [] >> > (show_stack+0x18/0x1c) >> > [179922.104675] r7:c0908514 r6:80080193 r5: r4:c090aca8 >> > [179922.110809] [] (show_stack) from [] >> > (sched_show_task+0xbc/0x110) >> > [179922.119049] [] (sched_show_task) from [] >> > (dump_cpu_task+0x40/0x44) >> > [179922.127624] r5:c0917680 r4: >> > [179922.131042] [] (dump_cpu_task) from [] >> > (rcu_dump_cpu_stacks+0x9c/0xdc) >> > [179922.140350] r5:c0917680 r4:0001 >> > [179922.143157] [] (rcu_dump_cpu_stacks) from [] >> > (rcu_check_callbacks+0x504/0x8e4) >> > [179922.153808] r9:c0908514 r8:c0917680 r7:0066 r6:2eeab000 >> > r5:c0904300 r4:ef7af300 >> > [179922.161499] [] (rcu_check_callbacks) from [] >> > (update_process_times+0x40/0x6c) >> > [179922.170898] r10:c009a584 r9:0001 r8:ef7abc4c r7:a3a3 >> > r6:4ec3391c r5: >> > [179922.179901] r4:c090aca8 >> > [179922.182708] [] (update_process_times) from [] >> > (tick_sched_handle+0x50/0x54) >> > [179922.192108] r5:c0907f10 r4:ef7abe40 >> > [179922.195983] [] (tick_sched_handle) from [] >> > (tick_sched_timer+0x50/0x94) >> > [179922.204895] [] (tick_sched_timer) from [] >> > (__hrtimer_run_queues+0x110/0x1a0) >> > [179922.214324] r7: r6:ef7abc40 r5:ef7abe40 r4:ef7abc00 >> > [179922.220428] [] (__hrtimer_run_queues) from [] >> > (hrtimer_interrupt+0xac/0x1f8) >> > [179922.227111] r10:ef7abc78 r9:ef7abc98 r8:ef7abc14 r7:ef7abcb8 >> > r6: r5:0003 >> > [179922.238220] r4:ef7abc00 >> > [179922.238220] [] (hrtimer_interrupt) from [] >> > (twd_handler+0x38/0x48) >> > [179922.238220] r10:c090
[PATCH 0/8] rtc-ab-b5ze-s3: Fine-tuning for some function implementations
From: Markus Elfring Date: Sun, 3 Jan 2016 09:37:34 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (8): Better exception handling in abb5zes3_probe() Delete an unnecessary variable in abb5zes3_rtc_set_alarm() Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() Delete an unnecessary variable in _abb5zes3_rtc_read_timer() Delete an unnecessary variable in _abb5zes3_rtc_interrupt() Delete an unnecessary variable in _abb5zes3_rtc_set_timer() drivers/rtc/rtc-ab-b5ze-s3.c | 59 1 file changed, 27 insertions(+), 32 deletions(-) -- 2.6.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 1/8] rtc-ab-b5ze-s3: Better exception handling in abb5zes3_probe()
From: Markus Elfring
Date: Sun, 3 Jan 2016 07:07:49 +0100
This issue was detected by using the Coccinelle software.
* Return directly before the data structure element "irq" was assigned.
* Drop the explicit initialisation for the variable "data"
at the beginning then.
* Adjust jump targets according to the Linux coding style convention.
* Simplify a condition check at the end.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index a319bf1..1291206 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -889,35 +889,31 @@ static const struct regmap_config
abb5zes3_rtc_regmap_config = {
static int abb5zes3_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct abb5zes3_rtc_data *data = NULL;
+ struct abb5zes3_rtc_data *data;
struct device *dev = &client->dev;
struct regmap *regmap;
int ret;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
I2C_FUNC_SMBUS_BYTE_DATA |
-I2C_FUNC_SMBUS_I2C_BLOCK)) {
- ret = -ENODEV;
- goto err;
- }
+I2C_FUNC_SMBUS_I2C_BLOCK))
+ return -ENODEV;
regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config);
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(dev, "%s: regmap allocation failed: %d\n",
__func__, ret);
- goto err;
+ return ret;
}
ret = abb5zes3_i2c_validate_chip(regmap);
if (ret)
- goto err;
+ return ret;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
- if (!data) {
- ret = -ENOMEM;
- goto err;
- }
+ if (!data)
+ return -ENOMEM;
mutex_init(&data->lock);
data->regmap = regmap;
@@ -925,7 +921,7 @@ static int abb5zes3_probe(struct i2c_client *client,
ret = abb5zes3_rtc_check_setup(dev);
if (ret)
- goto err;
+ return ret;
if (client->irq > 0) {
ret = devm_request_threaded_irq(dev, client->irq, NULL,
@@ -940,7 +936,7 @@ static int abb5zes3_probe(struct i2c_client *client,
} else {
dev_err(dev, "%s: irq %d unavailable (%d)\n",
__func__, client->irq, ret);
- goto err;
+ return ret;
}
}
@@ -950,7 +946,7 @@ static int abb5zes3_probe(struct i2c_client *client,
if (ret) {
dev_err(dev, "%s: unable to register RTC device (%d)\n",
__func__, ret);
- goto err;
+ goto check_irq;
}
/* Enable battery low detection interrupt if battery not already low */
@@ -959,12 +955,12 @@ static int abb5zes3_probe(struct i2c_client *client,
if (ret) {
dev_err(dev, "%s: enabling battery low interrupt "
"generation failed (%d)\n", __func__, ret);
- goto err;
+ goto check_irq;
}
}
-
-err:
- if (ret && data && data->irq)
+ return 0;
+check_irq:
+ if (data->irq)
device_init_wakeup(dev, false);
return ret;
}
--
2.6.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 2/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in abb5zes3_rtc_set_alarm()
From: Markus Elfring
Date: Sun, 3 Jan 2016 07:35:09 +0100
Pass the address of the data structure element "time" directly in a call
of the function "rtc_tm_to_time" instead of an extra initialisation
for one local variable at the beginning.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 1291206..ed9b873 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -596,7 +596,6 @@ err:
static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
{
struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
- struct rtc_time *alarm_tm = &alarm->time;
unsigned long rtc_secs, alarm_secs;
struct rtc_time rtc_tm;
int ret;
@@ -610,7 +609,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alarm)
if (ret)
goto err;
- ret = rtc_tm_to_time(alarm_tm, &alarm_secs);
+ ret = rtc_tm_to_time(&alarm->time, &alarm_secs);
if (ret)
goto err;
--
2.6.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 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer()
From: Markus Elfring Date: Sun, 3 Jan 2016 07:42:18 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring --- drivers/rtc/rtc-ab-b5ze-s3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index ed9b873..33a7cf1 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -560,7 +560,7 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; - int ret = 0; + int ret; /* Program given number of seconds to Timer A registers */ sec_to_timer_a(secs, ®s[0], ®s[1]); -- 2.6.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 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm()
From: Markus Elfring
Date: Sun, 3 Jan 2016 07:51:49 +0100
Replace an explicit initialisation for one local variable at the beginning
by an assignment.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 33a7cf1..0986715 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -476,7 +476,7 @@ static int abb5zes3_rtc_read_alarm(struct device *dev,
struct rtc_wkalrm *alarm)
static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
*alarm)
{
struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
- struct rtc_time *alarm_tm = &alarm->time;
+ struct rtc_time *alarm_tm;
unsigned long rtc_secs, alarm_secs;
u8 regs[ABB5ZES3_ALRM_SEC_LEN];
struct rtc_time rtc_tm;
@@ -490,6 +490,7 @@ static int _abb5zes3_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alarm)
if (ret)
goto err;
+ alarm_tm = &alarm->time;
ret = rtc_tm_to_time(alarm_tm, &alarm_secs);
if (ret)
goto err;
--
2.6.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 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm()
From: Markus Elfring
Date: Sun, 3 Jan 2016 08:00:29 +0100
Replace an explicit initialisation for one local variable at the beginning
by an assignment.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 0986715..02e3443 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -382,7 +382,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev,
struct rtc_wkalrm *alarm)
{
struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
- struct rtc_time rtc_tm, *alarm_tm = &alarm->time;
+ struct rtc_time rtc_tm, *alarm_tm;
unsigned long rtc_secs, alarm_secs;
u8 regs[ABB5ZES3_ALRM_SEC_LEN];
unsigned int reg;
@@ -396,6 +396,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev,
goto err;
}
+ alarm_tm = &alarm->time;
alarm_tm->tm_sec = 0;
alarm_tm->tm_min = bcd2bin(regs[0] & 0x7f);
alarm_tm->tm_hour = bcd2bin(regs[1] & 0x3f);
--
2.6.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 6/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_read_timer()
From: Markus Elfring
Date: Sun, 3 Jan 2016 08:46:50 +0100
Pass the address of the data structure element "time" directly in a call
of the function "rtc_time_to_tm" instead of an extra initialisation
for one local variable at the beginning.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 02e3443..e3a015a 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -326,7 +326,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev,
struct rtc_wkalrm *alarm)
{
struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
- struct rtc_time rtc_tm, *alarm_tm = &alarm->time;
+ struct rtc_time rtc_tm;
u8 regs[ABB5ZES3_TIMA_SEC_LEN + 1];
unsigned long rtc_secs;
unsigned int reg;
@@ -362,7 +362,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev,
goto err;
/* ... and convert back. */
- rtc_time_to_tm(rtc_secs + timer_secs, alarm_tm);
+ rtc_time_to_tm(rtc_secs + timer_secs, &alarm->time);
ret = regmap_read(data->regmap, ABB5ZES3_REG_CTRL2, ®);
if (ret) {
--
2.6.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 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
From: Markus Elfring
Date: Sun, 3 Jan 2016 09:00:30 +0100
Pass the address of the data structure element "time" directly in calls
of the function "rtc_update_irq" instead of an extra initialisation
for one local variable at the beginning.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index e3a015a..88f1d0b 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
*data)
struct i2c_client *client = data;
struct device *dev = &client->dev;
struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev);
- struct rtc_device *rtc = rtc_data->rtc;
u8 regs[ABB5ZES3_CTRL_SEC_LEN];
int ret, handled = IRQ_NONE;
@@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
*data)
/* Check alarm flag */
if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) {
dev_dbg(dev, "RTC alarm!\n");
-
- rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
+ rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
/* Acknowledge and disable the alarm */
_abb5zes3_rtc_clear_alarm(dev);
@@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
*data)
/* Check watchdog Timer A flag */
if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) {
dev_dbg(dev, "RTC timer!\n");
-
- rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
+ rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
/*
* Acknowledge and disable the alarm. Note: WTAF
--
2.6.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 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer()
From: Markus Elfring
Date: Sun, 3 Jan 2016 09:19:32 +0100
Pass a value directly in a call of the function "regmap_update_bits"
instead of an extra initialisation for one local variable at the beginning.
Signed-off-by: Markus Elfring
---
drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 88f1d0b..fed52d0 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev,
struct rtc_wkalrm *alarm,
{
struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
u8 regs[ABB5ZES3_TIMA_SEC_LEN];
- u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1;
int ret;
/* Program given number of seconds to Timer A registers */
@@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev,
struct rtc_wkalrm *alarm,
/* Configure Timer A as a watchdog timer */
ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK,
-mask, ABB5ZES3_REG_TIM_CLK_TAC1);
+ABB5ZES3_REG_TIM_CLK_TAC0
+| ABB5ZES3_REG_TIM_CLK_TAC1,
+ABB5ZES3_REG_TIM_CLK_TAC1);
if (ret)
dev_err(dev, "%s: failed to update timer\n", __func__);
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 32/32] virtio_ring: use virt_store_mb
On Fri, Jan 01, 2016 at 08:23:46PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 12/31/2015 10:09 PM, Michael S. Tsirkin wrote:
>
> >We need a full barrier after writing out event index, using
> >virt_store_mb there seems better than open-coding. As usual, we need a
> >wrapper to account for strong barriers.
> >
> >It's tempting to use this in vhost as well, for that, we'll
> >need a variant of smp_store_mb that works on __user pointers.
> >
> >Signed-off-by: Michael S. Tsirkin
> >---
> > include/linux/virtio_ring.h | 12
> > drivers/virtio/virtio_ring.c | 15 +--
> > 2 files changed, 21 insertions(+), 6 deletions(-)
> >
> >diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> >index f3fa55b..3a74d91 100644
> >--- a/include/linux/virtio_ring.h
> >+++ b/include/linux/virtio_ring.h
> >@@ -45,6 +45,18 @@ static inline void virtio_wmb(bool weak_barriers)
> > wmb();
> > }
> >
> >+static inline void virtio_store_mb(bool weak_barriers,
> >+ __virtio16 *p, __virtio16 v)
> >+{
> >+if (weak_barriers)
> >+virt_store_mb(*p, v);
> >+else
> >+{
>
>The kernel coding style dictates:
>
> if (weak_barriers) {
> virt_store_mb(*p, v);
> } else {
>
> >+WRITE_ONCE(*p, v);
> >+mb();
> >+}
> >+}
> >+
> [...]
>
> MBR, Sergei
Will fix, 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 v2 17/32] arm: define __smp_xxx
On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote: > On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote: > > This defines __smp_xxx barriers for arm, > > for use by virtualization. > > > > smp_xxx barriers are removed as they are > > defined correctly by asm-generic/barriers.h > > > > This reduces the amount of arch-specific boiler-plate code. > > > > Signed-off-by: Michael S. Tsirkin > > Acked-by: Arnd Bergmann > > In combination with patch 14, this looks like it should result in no > change to the resulting code. > > Acked-by: Russell King > > My only concern is that it gives people an additional handle onto a > "new" set of barriers - just because they're prefixed with __* > unfortunately doesn't stop anyone from using it (been there with > other arch stuff before.) > > I wonder whether we should consider making the smp memory barriers > inline functions, so these __smp_xxx() variants can be undef'd > afterwards, thereby preventing drivers getting their hands on these > new macros? That'd be tricky to do cleanly since asm-generic depends on ifndef to add generic variants where needed. But it would be possible to add a checkpatch test for this. > -- > RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()
On 02-01-16 12:21, SF Markus Elfring wrote:
>> I have never seen much evolution going on in this area.
>
> I can get an other impression from a specific document for example.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
>
>
>> What the patch tries to do is avoid the extra 'if (err)'.
>
> Yes. - I propose to look at related consequences together with the usage
> of a popular short jump label once more.
When I read a subject saying "Better exception handling" it sounds like
a functional improvement. Your change does not change anything
functionally and may or may not save a bit of execution time depending
on how smart the compiler is. What you change does is confuse people
reading the code. So please explain why your update improves exception
handling here. I don't see it. The code is not making the driver more
robust against failures in this function, which is what I think of
reading "better exception handling".
>> Setting coding style aside, the question is whether there is
>> a good metric for the patch.
>
> A software development challenge is to accept changes also around a topic
> like "error handling". My update suggestion for the source file
> "drivers/net/wireless/marvell/libertas/if_spi.c" should only improve
> exception handling. (I came along other source files where more improvements
> will eventually be possible.)
>
> When will the run-time behaviour matter also for exceptional situations?
>
>
>> Did you look at the resulting assembly code for different target
>> architectures?
>
> Not yet. - Which execution system variants would you recommend for
> further comparisons?
Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] crypto: algif_skcipher - Require setkey before accept(2)
On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen this way. > > I'll try to add some compatibility code for your case, assuming > your modus operandi is accept(2) followed by a single setkey before > proceeding to encryption/decryption. Hi, yes, basically it prepares socket()/bind()/accept() and then it calls setkey once. (I'll try to fix in next releases to call setkey first though.) I am doing exactly the same for AF_ALG HMAC (hmac() key, does this requirement for order if accept/setkey applies there as well? (It is not enforced yet.) Anyway, you can easily simulate that skcipher API call just with running "cryptsetup benchmark" (with accept() patch it will print N/A for all ciphers while without patch it measures some more-or-less magic performance numbers :) > >> (Moreover it still doesn't work for cipher_null that has min/max key size 0.) > > Setkey works just fine on cipher_null. Yes, it works if ALG_SET_KEY is set to zero-length key. I just re-introduced old bug to code, sorry. Thanks! Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] 390/qeth: Fine-tuning for qeth_core_set_online()
From: Markus Elfring Date: Sun, 3 Jan 2016 10:56:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Refactoring drivers/s390/net/qeth_core_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.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 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online()
From: Markus Elfring
Date: Sun, 3 Jan 2016 10:48:05 +0100
Omit explicit initialisation at the beginning for one local variable
that is redefined before its first use.
Signed-off-by: Markus Elfring
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/net/qeth_core_main.c
b/drivers/s390/net/qeth_core_main.c
index 7871537..54fde2e 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct
ccwgroup_device *gdev)
static int qeth_core_set_online(struct ccwgroup_device *gdev)
{
struct qeth_card *card = dev_get_drvdata(&gdev->dev);
- int rc = 0;
+ int rc;
int def_discipline;
if (!card->discipline) {
--
2.6.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 2/2] 390/qeth: Refactoring for qeth_core_set_online()
From: Markus Elfring
Date: Sun, 3 Jan 2016 10:50:11 +0100
Reduce the scope for the local variable "def_discipline" to one branch
of an if statement.
Signed-off-by: Markus Elfring
---
drivers/s390/net/qeth_core_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/net/qeth_core_main.c
b/drivers/s390/net/qeth_core_main.c
index 54fde2e..3261977 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device
*gdev)
{
struct qeth_card *card = dev_get_drvdata(&gdev->dev);
int rc;
- int def_discipline;
if (!card->discipline) {
+ int def_discipline;
+
if (card->info.type == QETH_CARD_TYPE_IQD)
def_discipline = QETH_DISCIPLINE_LAYER3;
else
--
2.6.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/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
Le jeudi 31 décembre 2015 à 22:14 +, Mark Brown a écrit : > On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote: > > > I understand, thanks for pointing this out. Well, for my use case, there > > is no use in disabling the chip at any point as it powers the external > > mmc. > > Presumably someone might decide not to use the MMC in some case (perhaps > only mounting it when explicitly needed in order to save power for > example, or the MMC subsystem might figure out a way to power down an > idle MMC block device). Makes sense, I'll keep that in mind. > > Would you agree to have the enable pin handled directly (and by that, I > > mean enabled once, when requested, as I first suggested in the patchset) > > in the driver then? > > That's probably fine, or do it via runtime PM (the framework is fairly > simple to use, I'll probably go add support in the core for it in the > next day or two as this seems like a sensible use case). I can't > remember if this device is a MFD or not and I'm just on my way out the > door. Runtime PM seems like a good fit (though I hadn't heard about it before: you can guess I'm fairly new to kernel development), please let me know whether you end up implementing it so I can try to handle the GPIO this way. Thanks! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part
Re: next-20151231 - aes crypto algorithm went missing?
On 01/03/2016 06:34 AM, Valdis Kletnieks wrote: > So booting into a next-20151222 kernel, I can mount an external drive > that uses cryptLuks. I try -1231, and I get this failure: > > Failed to setup dm-crypt key mapping for device /dev/sdb2. > Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more > info). > > Tracked it down to this difference in /proc/crypto between the 12/22 and > 12/31: ... > This ringing any bells, before I start the New Year with a bisect? :) Perhaps see the discussion in thread [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2) Could you try to revert this patch? http://git.kernel.org/cgit/linux/kernel/git/next/linux-next-history.git/commit/crypto?id=9f47e11b9e3169ff4cb35b3cdac0e0f7c2fcfe27 Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/5] nbd: Remove signal usage
Hi Markus,
this looks great!
Reviewed-by: Christoph Hellwig
One thing I noticed, which might be a good cleanup in the future:
> - spin_lock_irqsave(&nbd->tasks_lock, flags);
> nbd->task_recv = current;
> - spin_unlock_irqrestore(&nbd->tasks_lock, flags);
It seems like task_{send,recv} are only used for the files showing
the pids. Maybe you should just store the pids directly in the
nbd_device structure and also keep the sysfs file around for the
life time of that structure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] av7110: constify sp8870_config structure
This sp8870_config structure is never modified, so declare it as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/media/pci/ttpci/av7110.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c
index a69dc6a..18d229f 100644
--- a/drivers/media/pci/ttpci/av7110.c
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -1739,7 +1739,7 @@ static int alps_tdlb7_request_firmware(struct
dvb_frontend* fe, const struct fir
#endif
}
-static struct sp8870_config alps_tdlb7_config = {
+static const struct sp8870_config alps_tdlb7_config = {
.demod_address = 0x71,
.request_firmware = alps_tdlb7_request_firmware,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V5 4/9] Drivers: hv: ring_buffer: enhance hv_ringbuffer_read() to support hvsock
> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Saturday, January 2, 2016 12:30 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; step...@networkplumber.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY Srinivasan ; pebo...@tiscali.nl; > stefa...@redhat.com; vkuzn...@redhat.com; dan.carpen...@oracle.com > Subject: Re: [PATCH V5 4/9] Drivers: hv: ring_buffer: enhance > hv_ringbuffer_read() to support hvsock > > From: Dexuan Cui > Date: Thu, 24 Dec 2015 06:14:36 -0800 > > > +#define HV_RINGBUFFER_READ_FLAG_RAW(1 << 0) > > +#define HV_RINGBUFFER_READ_FLAG_HVSOCK (1 << 1) > > Please use BIT(). Hi David, Thanks for the suggestion! I'll fix it. -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()
>>> What the patch tries to do is avoid the extra 'if (err)'. >> >> Yes. - I propose to look at related consequences together with the usage >> of a popular short jump label once more. > > When I read a subject saying "Better exception handling" it sounds like > a functional improvement. Your change does not change anything > functionally and may or may not save a bit of execution time depending > on how smart the compiler is. Can it eventually matter to skip another condition check in three cases? > What you change does is confuse people reading the code. A few software developers might find this proposal unusual. > So please explain why your update improves exception handling here. > I don't see it. How does this feedback fit to the mentioned check avoidance? > The code is not making the driver more robust against failures That's true for this update suggestion. > in this function, which is what I think of reading "better exception > handling". Other implementation details are affected by the shown fine-tuning. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/media/usb/dvb-usb-v2: constify mxl111sf_tuner_config structure
This mxl111sf_tuner_config structure is never modified, so declare it as
const.
There are some indentation changes to remain within 80 columns.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c |6 +++---
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h |8
drivers/media/usb/dvb-usb-v2/mxl111sf.c |2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
index 444579b..7d16252 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
@@ -36,7 +36,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
(or-able)).");
struct mxl111sf_tuner_state {
struct mxl111sf_state *mxl_state;
- struct mxl111sf_tuner_config *cfg;
+ const struct mxl111sf_tuner_config *cfg;
enum mxl_if_freq if_freq;
@@ -489,8 +489,8 @@ static struct dvb_tuner_ops mxl111sf_tuner_tuner_ops = {
};
struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
- struct mxl111sf_state *mxl_state,
- struct mxl111sf_tuner_config *cfg)
+ struct mxl111sf_state *mxl_state,
+ const struct mxl111sf_tuner_config *cfg)
{
struct mxl111sf_tuner_state *state = NULL;
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
index e6caab2..509b550 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
@@ -63,13 +63,13 @@ struct mxl111sf_tuner_config {
#if IS_ENABLED(CONFIG_DVB_USB_MXL111SF)
extern
struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
- struct mxl111sf_state *mxl_state,
- struct mxl111sf_tuner_config *cfg);
+ struct mxl111sf_state *mxl_state,
+ const struct mxl111sf_tuner_config *cfg);
#else
static inline
struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
- struct mxl111sf_state *mxl_state,
- struct mxl111sf_tuner_config *cfg)
+ struct mxl111sf_state *mxl_state,
+ const struct mxl111sf_tuner_config *cfg)
{
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
return NULL;
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index b669dec..b586e17 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -856,7 +856,7 @@ static int mxl111sf_ant_hunt(struct dvb_frontend *fe)
return 0;
}
-static struct mxl111sf_tuner_config mxl_tuner_config = {
+static const struct mxl111sf_tuner_config mxl_tuner_config = {
.if_freq = MXL_IF_6_0, /* applies to external IF output, only */
.invert_spectrum = 0,
.read_reg= mxl111sf_read_reg,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Charity Donation
Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid. Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia. Regards, Jeffrey Skoll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v1 3/3] ARM64 LPC: update binding doc
在 2015/12/31 23:00, Rongrong Zou 写道:
2015-12-31 22:40 GMT+08:00 Arnd Bergmann mailto:a...@arndb.de>>:
>
> On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> > >> +Example:
> > >> +
> > >> +lpc_0: lpc@a01b {
> > >> + #address-cells = <1>;
> > >> + #size-cells = <1>;
> > >> +compatible = "low-pin-count";
> > >> +reg = <0x0 0xa01b 0x0 0x1>;
> > >> +};
> > >
> > > One more thought: please try to stick as closely as possible to the
existing
> > > ISA binding that is documented at
> > >
> > > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> > From the specification, I think I should use 2 32bit integer to describe
the isa addr in dts.
> > >
> > > In particular, this should cover the possibility of describing both
memory
> > > and I/O spaces in child devices.
> > >
> >
> > I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
> >
> > isa@1e {
> > device_type = "isa";
> > #interrupt-cells = <2>;
> > #size-cells = <1>;
> > #address-cells = <2>;
> > reg = <0xf000 0x0 0x0 0x0 0x0>;
> > ranges = <0x1 0x0 0x100 0x0 0x0
> >0x1000>;
> > interrupt-parent = <&i8259>;
> >
> >
> >
> > rtc@70 {
> > compatible = "pnpPNP,b00";
> > reg = <0x1 0x70 0x2>;
> > };
> > the isa space in child-node: reg = <0x1 0x70 0x2>;
> > 0x1 means IO space, 70 means addr, 0x2 is size.
> > but when i config the following in dts, the ipmi_0 node can't be probed,
> > I think there may be some problems.
> >
> > lpc_0: lpc@a01b {
> > compatible = "low-pin-count";
> > device_type = "isa";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <0x0 0xa01b 0x0 0x1>;
> >
> > ipmi_0:ipmi@00e4{
> > device_type = "ipmi";
> > compatible = "ipmi-bt";
> > reg = <0x1 0x00e4 0x4>;
> > };
>
> The DT sample above looks good in principle. I believe what you are missing
> here is code in your driver to scan the child nodes to create the platform
> devices. of_bus_isa_translate() should work with your definition here
> and create the correct IORESOURCE_IO resources. You don't have any MMIO
> resources, so the absence of a ranges property is ok. Maybe all you
> are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>
You are right. thanks, i'll try on test board . if i get the correct result ,
the new patch
will be sent later. By the way, it's my another email account use when i at
home.
I tried, and there need some additional changes.
isa@a01b {
/*the node name should start with "isa", because of below definition
* static int of_bus_isa_match(struct device_node *np)
* {
* return !strcmp(np->name, "isa");
* }
*/
compatible = "low-pin-count";
device_type = "isa";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xa01b 0x0 0x1>;
ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
* ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1,
0x00e4, 4>".
*
*/
ipmi_0:ipmi@00e4{
device_type = "ipmi";
compatible = "ipmi-bt";
reg = <0x1 0x00e4 0x4>;
};
drivers\of\address.c
static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
u64 taddr;
if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
return -EINVAL;
taddr = of_translate_address(dev, addrp);
if (taddr == OF_BAD_ADDR)
return -EINVAL;
memset(r, 0, sizeof(struct resource));
if (flags & IORESOURCE_IO) {
unsigned long port;
/*/
/*legacy port(< 0x1000) is reserved, and need no translation here*/
/*/
if(taddr + size < PCIBIOS_MIN_IO){
r->start = taddr;
r->end = taddr + size - 1;
}
else{
port = pci_address_to_pio(taddr);
if (port == (unsigned long)-1)
return -EINVAL;
r->start = port;
[PATCH] media: bt8xx: constify or51211_config structure
The or51211_config structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/media/pci/bt8xx/dvb-bt8xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/bt8xx/dvb-bt8xx.c
b/drivers/media/pci/bt8xx/dvb-bt8xx.c
index d407244..8aeb14c 100644
--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
@@ -458,7 +458,7 @@ static void or51211_sleep(struct dvb_frontend * fe)
bttv_write_gpio(bt->bttv_nr, 0x0001, 0x);
}
-static struct or51211_config or51211_config = {
+static const struct or51211_config or51211_config = {
.demod_address = 0x15,
.request_firmware = or51211_request_firmware,
.setmode = or51211_setmode,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] media: bt8xx: constify sp887x_config structure
This sp887x_config structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
This patch and the previous one on the same file can be applied in any order.
drivers/media/pci/bt8xx/dvb-bt8xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/bt8xx/dvb-bt8xx.c
b/drivers/media/pci/bt8xx/dvb-bt8xx.c
index d407244..a3aa0cd 100644
--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
@@ -318,7 +318,7 @@ static int microtune_mt7202dtf_request_firmware(struct
dvb_frontend* fe, const s
return request_firmware(fw, name, &bt->bt->dev->dev);
}
-static struct sp887x_config microtune_mt7202dtf_config = {
+static const struct sp887x_config microtune_mt7202dtf_config = {
.demod_address = 0x70,
.request_firmware = microtune_mt7202dtf_request_firmware,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
On Sun, 3 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 3 Jan 2016 09:00:30 +0100
>
> Pass the address of the data structure element "time" directly in calls
> of the function "rtc_update_irq" instead of an extra initialisation
> for one local variable at the beginning.
Why is it better?
julia
> Signed-off-by: Markus Elfring
> ---
> drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index e3a015a..88f1d0b 100644
> --- a/drivers/rtc/rtc-ab-b5ze-s3.c
> +++ b/drivers/rtc/rtc-ab-b5ze-s3.c
> @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> struct i2c_client *client = data;
> struct device *dev = &client->dev;
> struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev);
> - struct rtc_device *rtc = rtc_data->rtc;
> u8 regs[ABB5ZES3_CTRL_SEC_LEN];
> int ret, handled = IRQ_NONE;
>
> @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> /* Check alarm flag */
> if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) {
> dev_dbg(dev, "RTC alarm!\n");
> -
> - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
> + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
>
> /* Acknowledge and disable the alarm */
> _abb5zes3_rtc_clear_alarm(dev);
> @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> /* Check watchdog Timer A flag */
> if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) {
> dev_dbg(dev, "RTC timer!\n");
> -
> - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
> + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
>
> /*
>* Acknowledge and disable the alarm. Note: WTAF
> --
> 2.6.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 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer()
On Sun, 3 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 3 Jan 2016 09:19:32 +0100
>
> Pass a value directly in a call of the function "regmap_update_bits"
> instead of an extra initialisation for one local variable at the beginning.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index 88f1d0b..fed52d0 100644
> --- a/drivers/rtc/rtc-ab-b5ze-s3.c
> +++ b/drivers/rtc/rtc-ab-b5ze-s3.c
> @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev,
> struct rtc_wkalrm *alarm,
> {
> struct abb5zes3_rtc_data *data = dev_get_drvdata(dev);
> u8 regs[ABB5ZES3_TIMA_SEC_LEN];
> - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1;
> int ret;
>
> /* Program given number of seconds to Timer A registers */
> @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev,
> struct rtc_wkalrm *alarm,
>
> /* Configure Timer A as a watchdog timer */
> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK,
> - mask, ABB5ZES3_REG_TIM_CLK_TAC1);
> + ABB5ZES3_REG_TIM_CLK_TAC0
> + | ABB5ZES3_REG_TIM_CLK_TAC1,
> + ABB5ZES3_REG_TIM_CLK_TAC1);
This doesn't seem like an improvement. The concept (mask) has
disappeared, the binary operation is strangely broken, and the function
call has one more line of arguments, which all look sort of the same and
thus are hard to understand.
Don't underestimate the value of naming things.
julia
> if (ret)
> dev_err(dev, "%s: failed to update timer\n", __func__);
>
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
On Sun, 3 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 3 Jan 2016 09:00:30 +0100
>
> Pass the address of the data structure element "time" directly in calls
> of the function "rtc_update_irq" instead of an extra initialisation
> for one local variable at the beginning.
Also, I don't see anything related to time in this patch.
julia
>
> Signed-off-by: Markus Elfring
> ---
> drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index e3a015a..88f1d0b 100644
> --- a/drivers/rtc/rtc-ab-b5ze-s3.c
> +++ b/drivers/rtc/rtc-ab-b5ze-s3.c
> @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> struct i2c_client *client = data;
> struct device *dev = &client->dev;
> struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev);
> - struct rtc_device *rtc = rtc_data->rtc;
> u8 regs[ABB5ZES3_CTRL_SEC_LEN];
> int ret, handled = IRQ_NONE;
>
> @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> /* Check alarm flag */
> if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) {
> dev_dbg(dev, "RTC alarm!\n");
> -
> - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
> + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
>
> /* Acknowledge and disable the alarm */
> _abb5zes3_rtc_clear_alarm(dev);
> @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void
> *data)
> /* Check watchdog Timer A flag */
> if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) {
> dev_dbg(dev, "RTC timer!\n");
> -
> - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF);
> + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF);
>
> /*
>* Acknowledge and disable the alarm. Note: WTAF
> --
> 2.6.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] Net: irda: actisys-sir: fixed coding style issue
fixed trail white space
Signed-off-by: ZhengboWang
---
drivers/net/irda/actisys-sir.c | 44 ++
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/net/irda/actisys-sir.c b/drivers/net/irda/actisys-sir.c
index e224b8b..c201361 100644
--- a/drivers/net/irda/actisys-sir.c
+++ b/drivers/net/irda/actisys-sir.c
@@ -1,8 +1,8 @@
/*
- *
+ *
* Filename: actisys.c
* Version: 1.1
- * Description: Implementation for the ACTiSYS IR-220L and IR-220L+
+ * Description: Implementation for the ACTiSYS IR-220L and IR-220L+
*dongles
* Status:Beta.
* Authors: Dag Brattli (initially)
@@ -11,24 +11,23 @@
* Created at:Wed Oct 21 20:02:35 1998
* Modified at: Sun Oct 27 22:02:13 2002
* Modified by: Martin Diehl
- *
+ *
* Copyright (c) 1998-1999 Dag Brattli, All Rights Reserved.
* Copyright (c) 1999 Jean Tourrilhes
* Copyright (c) 2002 Martin Diehl
- *
- * 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
+ *
+ * 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.
- *
+ *
* Neither Dag Brattli nor University of Tromsø admit liability nor
- * provide warranty for any of this software. This material is
+ * provide warranty for any of this software. This material is
* provided "AS-IS" and at no charge.
- *
+ *
/
-/*
- * Changelog
+/* Changelog
*
* 0.8 -> 0. - Jean
* o New initialisation procedure : much safer and correct
@@ -48,8 +47,7 @@
#include "sir-dev.h"
-/*
- * Define the timing of the pulses we send to the dongle (to reset it, and
+/* Define the timing of the pulses we send to the dongle (to reset it, and
* to toggle speeds). Basically, the limit here is the propagation speed of
* the signals through the serial port, the dongle being much faster. Any
* serial port support 115 kb/s, so we are sure that pulses 8.5 us wide can
@@ -121,7 +119,7 @@ static int actisys_open(struct sir_dev *dev)
sirdev_set_dtr_rts(dev, TRUE, TRUE);
/* Set the speeds we can accept */
- qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200;
+ qos->baud_rate.bits &= IR_9600 | IR_19200 | IR_38400 | IR_57600 |
IR_115200;
/* Remove support for 38400 if this is not a 220L+ dongle */
if (dev->dongle_drv->type == IRDA_ACTISYS_DONGLE)
@@ -143,8 +141,7 @@ static int actisys_close(struct sir_dev *dev)
return 0;
}
-/*
- * Function actisys_change_speed (task)
+/* Function actisys_change_speed (task)
*
*Change speed of the ACTiSYS IR-220L and IR-220L+ type IrDA dongles.
*To cycle through the available baud rates, pulse RTS low for a few us.
@@ -169,11 +166,9 @@ static int actisys_change_speed(struct sir_dev *dev,
unsigned speed)
/* dongle was already resetted from irda_request state machine,
* we are in known state (dongle default)
-*/
-
- /*
+*
* Now, we can set the speed requested. Send RTS pulses until we
- * reach the target speed
+* reach the target speed
*/
for (i = 0; i < MAX_SPEEDS; i++) {
if (speed == baud_rates[i]) {
@@ -199,8 +194,7 @@ static int actisys_change_speed(struct sir_dev *dev,
unsigned speed)
return ret;
}
-/*
- * Function actisys_reset (task)
+/* Function actisys_reset (task)
*
* Reset the Actisys type dongle. Warning, this function must only be
* called with a process context!
@@ -229,14 +223,14 @@ static int actisys_reset(struct sir_dev *dev)
/* Go back to normal mode */
sirdev_set_dtr_rts(dev, TRUE, TRUE);
-
+
dev->speed = 9600; /* That's the default */
return 0;
}
MODULE_AUTHOR("Dag Brattli - Jean Tourrilhes
");
-MODULE_DESCRIPTION("ACTiSYS IR-220L and IR-220L+ dongle driver");
+MODULE_DESCRIPTION("ACTiSYS IR-220L and IR-220L+ dongle driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("irda-dongle-2"); /* IRDA_ACTISYS_DONGLE */
MODULE_ALIAS("irda-dongle-3"); /* IRDA_ACTISYS_PLUS_DONGLE */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] chelsio: constify cphy_ops structures
The cphy_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/chelsio/cxgb/cphy.h |2 +-
drivers/net/ethernet/chelsio/cxgb/mv88e1xxx.c |2 +-
drivers/net/ethernet/chelsio/cxgb/mv88x201x.c |2 +-
drivers/net/ethernet/chelsio/cxgb/my3126.c|2 +-
drivers/net/ethernet/chelsio/cxgb3/ael1002.c | 12 ++--
drivers/net/ethernet/chelsio/cxgb3/aq100x.c |2 +-
drivers/net/ethernet/chelsio/cxgb3/common.h |2 +-
drivers/net/ethernet/chelsio/cxgb3/vsc8211.c |4 ++--
8 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb/cphy.h
b/drivers/net/ethernet/chelsio/cxgb/cphy.h
index a4d2a4c..bf43da6 100644
--- a/drivers/net/ethernet/chelsio/cxgb/cphy.h
+++ b/drivers/net/ethernet/chelsio/cxgb/cphy.h
@@ -137,7 +137,7 @@ static inline int simple_mdio_write(struct cphy *cphy, int
reg,
/* Convenience initializer */
static inline void cphy_init(struct cphy *phy, struct net_device *dev,
-int phy_addr, struct cphy_ops *phy_ops,
+int phy_addr, const struct cphy_ops *phy_ops,
const struct mdio_ops *mdio_ops)
{
struct adapter *adapter = netdev_priv(dev);
diff --git a/drivers/net/ethernet/chelsio/cxgb/mv88e1xxx.c
b/drivers/net/ethernet/chelsio/cxgb/mv88e1xxx.c
index 71018a4..76ce6e5 100644
--- a/drivers/net/ethernet/chelsio/cxgb/mv88e1xxx.c
+++ b/drivers/net/ethernet/chelsio/cxgb/mv88e1xxx.c
@@ -337,7 +337,7 @@ static void mv88e1xxx_destroy(struct cphy *cphy)
kfree(cphy);
}
-static struct cphy_ops mv88e1xxx_ops = {
+static const struct cphy_ops mv88e1xxx_ops = {
.destroy = mv88e1xxx_destroy,
.reset= mv88e1xxx_reset,
.interrupt_enable = mv88e1xxx_interrupt_enable,
diff --git a/drivers/net/ethernet/chelsio/cxgb/mv88x201x.c
b/drivers/net/ethernet/chelsio/cxgb/mv88x201x.c
index d0cf611..7ddb301 100644
--- a/drivers/net/ethernet/chelsio/cxgb/mv88x201x.c
+++ b/drivers/net/ethernet/chelsio/cxgb/mv88x201x.c
@@ -195,7 +195,7 @@ static void mv88x201x_destroy(struct cphy *cphy)
kfree(cphy);
}
-static struct cphy_ops mv88x201x_ops = {
+static const struct cphy_ops mv88x201x_ops = {
.destroy = mv88x201x_destroy,
.reset = mv88x201x_reset,
.interrupt_enable = mv88x201x_interrupt_enable,
diff --git a/drivers/net/ethernet/chelsio/cxgb/my3126.c
b/drivers/net/ethernet/chelsio/cxgb/my3126.c
index a683fd3..d546f46 100644
--- a/drivers/net/ethernet/chelsio/cxgb/my3126.c
+++ b/drivers/net/ethernet/chelsio/cxgb/my3126.c
@@ -154,7 +154,7 @@ static void my3126_destroy(struct cphy *cphy)
kfree(cphy);
}
-static struct cphy_ops my3126_ops = {
+static const struct cphy_ops my3126_ops = {
.destroy= my3126_destroy,
.reset = my3126_reset,
.interrupt_enable = my3126_interrupt_enable,
diff --git a/drivers/net/ethernet/chelsio/cxgb3/ael1002.c
b/drivers/net/ethernet/chelsio/cxgb3/ael1002.c
index 2028da9..dadf11e 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/ael1002.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/ael1002.c
@@ -198,7 +198,7 @@ static int get_link_status_r(struct cphy *phy, int
*link_ok, int *speed,
return 0;
}
-static struct cphy_ops ael1002_ops = {
+static const struct cphy_ops ael1002_ops = {
.reset = ael1002_reset,
.intr_enable = ael1002_intr_noop,
.intr_disable = ael1002_intr_noop,
@@ -224,7 +224,7 @@ static int ael1006_reset(struct cphy *phy, int wait)
return t3_phy_reset(phy, MDIO_MMD_PMAPMD, wait);
}
-static struct cphy_ops ael1006_ops = {
+static const struct cphy_ops ael1006_ops = {
.reset = ael1006_reset,
.intr_enable = t3_phy_lasi_intr_enable,
.intr_disable = t3_phy_lasi_intr_disable,
@@ -495,7 +495,7 @@ static int ael2005_intr_handler(struct cphy *phy)
return ret ? ret : cphy_cause_link_change;
}
-static struct cphy_ops ael2005_ops = {
+static const struct cphy_ops ael2005_ops = {
.reset = ael2005_reset,
.intr_enable = ael2005_intr_enable,
.intr_disable= ael2005_intr_disable,
@@ -801,7 +801,7 @@ static int ael2020_intr_handler(struct cphy *phy)
return ret ? ret : cphy_cause_link_change;
}
-static struct cphy_ops ael2020_ops = {
+static const struct cphy_ops ael2020_ops = {
.reset = ael2020_reset,
.intr_enable = ael2020_intr_enable,
.intr_disable= ael2020_intr_disable,
@@ -856,7 +856,7 @@ static int get_link_status_x(struct cphy *phy, int
*link_ok, int *speed,
return 0;
}
-static struct cphy_ops qt2045_ops = {
+static const struct cphy_ops qt2045_ops = {
.reset = ael1006_reset,
.intr_enable = t3_phy_lasi_intr_enable,
.intr_disable = t3_phy_lasi_intr_disa
Re: [RFC PATCH v0] Add tw5864 driver
On Sun, Jan 3, 2016 at 5:47 AM, Joe Perches wrote:
> several of these have unnecessary parentheses
Thanks, fixed.
> Maybe use bool a bit more
Thanks, fixed.
> or maybe just use fls
Thanks, fls() fit greatly, rewritten the function with compatibility testing.
>> +static inline int bs_size_ue(unsigned int val)
>> +{
>> + int i_size = 0;
>> + static const int i_size0_254[255] = {
>
> Same sort of thing
Dropped this procedure because it is not used.
Thanks.
>> diff --git a/drivers/staging/media/tw5864/tw5864-config.c
>> b/drivers/staging/media/tw5864/tw5864-config.c
> []
>> +u8 tw_indir_readb(struct tw5864_dev *dev, u16 addr)
>> +{
>> + int timeout = 3;
>
> misleading name, retries would be more proper,
> or maybe use real timed loops.
Thanks, renamed to "retries".
> This seems a little repetitive.
Thanks, reworked.
> u16?
Thanks, fixed.
> odd indentation
Indeed. For some mysterious reason, vim + syntastic insists on this way. Fixed.
>> +#ifdef DEBUG
>> + dev_dbg(&input->root->pci->dev,
>> + "input %d, frame md stats: min %u, max %u, avg %u, cells above
>> threshold: %u\n",
>> + input->input_number, min, max, sum / md_cells,
>> + cnt_above_thresh);
>> +#endif
>
> unnecessary #ifdef
Not quite. This debug printout works with variables which are declared
in another "#ifdef DEBUG" clause. And it turns out that dev_dbg is
compiled not only if DEBUG is declared, so when I remove this ifdef, I
get "undefined variable" errors. It seems it is compiled if this
condition is met:
#if (defined DEBUG) || (defined CONFIG_DYNAMIC_DEBUG)
so I can wrap my stats variables into this statement instead. But such
change is not equivalent - I guess CONFIG_DYNAMIC_DEBUG is common to
be enabled, so debug stats will be always calculated, even when module
is not under debug. Except if I use DEFINE_DYNAMIC_DEBUG_METADATA etc.
in my code. Please let me know if this can be sorted out in cleaner
way.
On Sun, Jan 3, 2016 at 7:38 AM, Leon Romanovsky wrote:
> On Sun, Jan 03, 2016 at 03:41:42AM +0200, Andrey Utkin wrote:
>
>> +/*
>> + * TW5864 driver - Exp-Golomb code functions
>> + *
>> + * Copyright (C) 2015 Bluecherry, LLC
>> + * Copyright (C) 2015 Andrey Utkin
>
> I doubt that you have contract with your employer which permits you to
> claim copyright on the work/product.
Thank you for commenting.
I have previously asked my employer to review copyright statment, and
he told this is fine.
Now I have requrested him again with reference to your comment.
--
Bluecherry developer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] ACPI: amba bus probing support
On Wed, Dec 23, 2015 at 05:19:40PM +0300, Aleksey Makarov wrote:
> + dev = amba_device_alloc(NULL, 0, 0);
> + if (!dev) {
> + dev_err(&adev->dev, "%s(): amba_device_alloc() failed\n",
> + __func__);
> + return -ENOMEM;
> + }
...
> + /*
> + * If the ACPI node has a parent and that parent has a physical device
> + * attached to it, that physical device should be the parent of the
> + * platform device we are about to create.
> + */
> + dev->dev.parent = NULL;
No need to initialise this; amba_device_alloc() uses kzalloc(), and so
dev->dev.parent will already be NULL.
...
> + dev_set_name(&dev->dev, "%s", dev_name(&adev->dev));
Is there a reason not to use:
dev = amba_device_alloc(dev_name(&adev->dev), 0, 0);
above?
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ubifs: Fix error codes in ubifs_iget()
On Sat, 2016-01-02 at 23:11 +0100, Richard Weinberger wrote: > We cannot use positive error codes in ERR_PTR(). > IS_ERR() won't catch them. Right, but why there is a "err = -EINVAL;" when at 'out_invalid'. > Cc: sta...@vger.kernel.org > Signed-off-by: Richard Weinberger I do not see a bug, but I see a removal of a useful code which lets you understand what verification failed. Do I miss something? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"git send-email" thru Gmail incurs few minutes delay
After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':" prompt I always have a delay of 2-3 minutes. It is weird! "Unsafe clients" are allowed in Gmail settings. I experience this both with @gmail.com mailbox and with gmail-based company domain mail. I noticed this happening the first time several months ago. Has anybody else experienced this? Any solution? My git version is 2.6.4. -- Bluecherry developer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ubifs: Use XATTR_*_PREFIX_LEN
On Sat, 2016-01-02 at 23:12 +0100, Richard Weinberger wrote: > ...instead of open coding it. > > Signed-off-by: Richard Weinberger Looks good, thanks! Signed-off-buy: Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ubifs: Fix error codes in ubifs_iget()
On Sun, 2016-01-03 at 15:51 +0200, Artem Bityutskiy wrote: > On Sat, 2016-01-02 at 23:11 +0100, Richard Weinberger wrote: > > We cannot use positive error codes in ERR_PTR(). > > IS_ERR() won't catch them. > > Right, but why there is a "err = -EINVAL;" when at 'out_invalid'. Sorry Richard, I edited the sentence and did not notice it was messy. Here is what I wanted to say: right, but there is a "err = -EINVAL' at the end of 'out_invalid'. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ubifs: Fix error codes in ubifs_iget()
Am 03.01.2016 um 14:54 schrieb Artem Bityutskiy: > On Sun, 2016-01-03 at 15:51 +0200, Artem Bityutskiy wrote: >> On Sat, 2016-01-02 at 23:11 +0100, Richard Weinberger wrote: >>> We cannot use positive error codes in ERR_PTR(). >>> IS_ERR() won't catch them. >> >> Right, but why there is a "err = -EINVAL;" when at 'out_invalid'. > > Sorry Richard, I edited the sentence and did not notice it was messy. > > Here is what I wanted to say: right, but there is a "err = -EINVAL' at > the end of 'out_invalid'. Oh, you're right. I've missed this somehow. Let's ignore this patch. :) Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
Hello, Michael. On Sat, Jan 02, 2016 at 11:36:03PM +0200, Michael S. Tsirkin wrote: > > Why so? As long as the maximum concurrently used workers are not > > high, 1/5 second or even a lot longer sleeps are completely fine. > > I always thought the right way to defer executing a work queue item > is to queue delayed work, not sleep + queue work. That works too and is preferable if there are gonna be a lot of work items sleeping but it isn't different from any other blocking. > Doing a sleep ties up one thread for 1/5 of a second, does it not? It does. > If so, as long as it's the only driver doing this, we'll be fine, > but if many others copy this pattern, things will > start to break, will they not? The maximum concurrency on the system_wq is 256 which is pretty high, so for most use cases, it's fine. If high concurrency is expected, it's better to break it out to a separate workqueue. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuset: fix cpus_allowed mask for offline/online CPUs
On Fri, Jan 01, 2016 at 08:09:13PM +0800, Chen Yu wrote:
> Commit be4c9dd7aee5 ("cpuset: enable onlined cpu/node in effective masks")
> leverages cpuset's cpus_allowed and its parent's effective_cpus to calculate
> the new_cpus by:
>
> cpumask_and(&new_cpus, cs->cpus_allowed, parent_cs(cs)->effective_cpus);
>
> However cpus_allowed will also be updated after the CPU is offline, in
> hotplug_update_tasks_legacy, so when the CPU is online again, it will use
> the old cpus_allowed mask to calculate the new_cpus, thus new_cpus will get
> incorrect value after each round of offline/online.
>
> This problem is found on ubuntu 15.10 with cpuset mounted:
>
> 1. echo 0 > /sys/devices/system/cpu/cpu2/online
> 2. echo 1 > /sys/devices/system/cpu/cpu2/online
> 3. cat /sys/fs/cgroup/cpuset/cpuset.cpus
>0-3
> 4. cat /sys/fs/cgroup/cpuset/user.slice/cpuset.cpus
>0-1,3
> 5. taskset -c 2 ls
>taskset: failed to set pid 0's affinity: Invalid argument
>
> This patch works around this problem by introducing a new
> mask cpumask_var_t cpus_sysfs inside struct cpuset,
> which will only be updated by writing value to sysfs.cpuset.cpus,
> and CPU offline/online will use this mask to set the new cpumask
> for a cpuset.
Li?
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 69/78] ncr5380: Fix whitespace in comments using regexp
On Sat, 02 Jan 2016 23:54:28 -0800
Joe Perches wrote:
> On Sun, 2016-01-03 at 16:06 +1100, Finn Thain wrote:
> > Hanging indentation was a poor choice for the text inside comments. It
> > has been used in the wrong places and done badly elsewhere. There is
> > little consistency within any file. One fork of the core driver uses
> > tabs for this indentation while the other uses spaces. Better to use
> > flush-left alignment throughout.
> >
> > This patch is the result of the following substitution. It replaces tabs
> > and spaces at the start of a comment line with a single space.
> >
> > perl -i -pe 's,^(\t*[/ ]\*)[ \t]+,$1 ,' drivers/scsi/{atari_,}NCR5380.c
> >
> > This removes some unimportant discrepancies between the two core driver
> > forks so that the important ones become obvious, to facilitate
> > reunification.
>
> I still think this patch is poor at best and
> overall not useful.
I would beg to differ. As a tool for understanding the differences as you
step through the versions it's invaluable.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 7/7] pciutils: Allow 32-bit domains
Hello!
> PCI-e segments will continue to use the lower 16 bits as required by
> ACPI. Special domains may use the full 32-bits.
>
> Signed-off-by: Keith Busch
> ---
> lib/filter.c |2 +-
> lib/pci.h|2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/filter.c b/lib/filter.c
> index d4254a0..075dc2f 100644
> --- a/lib/filter.c
> +++ b/lib/filter.c
> @@ -45,7 +45,7 @@ pci_filter_parse_slot_v33(struct pci_filter *f, char *str)
> if (str[0] && strcmp(str, "*"))
> {
> long int x = strtol(str, &e, 16);
> - if ((e && *e) || (x < 0 || x > 0x))
> + if ((e && *e) || (x < 0))
> return "Invalid domain number";
> f->domain = x;
> }
> diff --git a/lib/pci.h b/lib/pci.h
> index 10ba831..7e42765 100644
> --- a/lib/pci.h
> +++ b/lib/pci.h
> @@ -119,7 +119,7 @@ struct pci_param *pci_walk_params(struct pci_access *acc,
> struct pci_param *prev
>
> struct pci_dev {
>struct pci_dev *next; /* Next device in the chain */
> - u16 domain;/* PCI domain (host bridge) */
> + int32_t domain;/* PCI domain (host bridge) */
>u8 bus, dev, func; /* Bus inside domain, device and
> function */
This is definitely not enough. Try grepping the source for "domain" :-)
At least the following places need updating, too:
o struct pci_filter and operations on it
o Format strings for printing domains at various places
o ABI compability ... changing a field in the middle of struct pci_dev
(or pci_filter) is going to break ABI, so you either need to change the
structures in a backward-compatible way, or to use ABI versioning.
Also, we should decide on what type the domain should have -- currently, some
places use "int", others use u16, and your patch introduces int32_t. I would
prefer u32 myself, but especially in the filters we should be careful about
how to encode "any domain".
Have a nice new year
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] USB: serial: add Moxa UPORT 11x0 driver
Hi Johan, Thanks for merging ! About the follow ups, I have tested the driver on uport 1110 without double OPEN_PORT/START_PORT commands. It is still working fine so, I guess it can be removed. Plus, I sniffed the Windows USB driver for uport 1110 and the commands sent are : OPEN_PORT, SET_CONFIG, START_PORT, CLOSE_PORT. The STOP_PORT command isn't used. I add it anyway to close callback and it doesn't modify driver's behaviour. I will post a patch serie cleaning up control commands and adding a probe callback as you suggested. Thanks, Mathieu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] USB: mxu11x0: fixes and follow ups
Hi, Here are the follow up commits proposed during last Johan review of the new mxu11x0 driver. I also patched a memory leak on usb_serial private data. Mathieu Mathieu OTHACEHE (3): USB: mxu11x0: fix memory leak on usb_serial private data USB: mxu11x0: clean device control commands USB: mxu11x0: move firmware download and endpoint testing to probe callback drivers/usb/serial/mxu11x0.c | 179 +-- 1 file changed, 104 insertions(+), 75 deletions(-) -- 2.6.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/3] USB: mxu11x0: clean device control commands
Sending OPEN and START commands twice is not necessary for this driver.
Also send STOP command at close.
Signed-off-by: Mathieu OTHACEHE
---
drivers/usb/serial/mxu11x0.c | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
index 0fe7eab..354fcb5 100644
--- a/drivers/usb/serial/mxu11x0.c
+++ b/drivers/usb/serial/mxu11x0.c
@@ -823,30 +823,6 @@ static int mxu1_open(struct tty_struct *tty, struct
usb_serial_port *port)
goto unlink_int_urb;
}
- /*
-* reset the data toggle on the bulk endpoints to work around bug in
-* host controllers where things get out of sync some times
-*/
- usb_clear_halt(serial->dev, port->write_urb->pipe);
- usb_clear_halt(serial->dev, port->read_urb->pipe);
-
- if (tty)
- mxu1_set_termios(tty, port, NULL);
-
- status = mxu1_send_ctrl_urb(serial, MXU1_OPEN_PORT,
- open_settings, MXU1_UART1_PORT);
- if (status) {
- dev_err(&port->dev, "cannot send open command: %d\n", status);
- goto unlink_int_urb;
- }
-
- status = mxu1_send_ctrl_urb(serial, MXU1_START_PORT,
- 0, MXU1_UART1_PORT);
- if (status) {
- dev_err(&port->dev, "cannot send start command: %d\n", status);
- goto unlink_int_urb;
- }
-
status = usb_serial_generic_open(tty, port);
if (status)
goto unlink_int_urb;
@@ -866,6 +842,13 @@ static void mxu1_close(struct usb_serial_port *port)
usb_serial_generic_close(port);
usb_kill_urb(port->interrupt_in_urb);
+ status = mxu1_send_ctrl_urb(port->serial, MXU1_STOP_PORT,
+ 0, MXU1_UART1_PORT);
+ if (status) {
+ dev_err(&port->dev, "failed to send stop port command: %d\n",
+ status);
+ }
+
status = mxu1_send_ctrl_urb(port->serial, MXU1_CLOSE_PORT,
0, MXU1_UART1_PORT);
if (status) {
--
2.6.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/3] USB: mxu11x0: move firmware download and endpoint testing to probe callback
Move interrupt in endpoint test and firmware download to a new probe
callback. This avoids unnecessary memory allocations done by core
before port_probe callback is called.
If the device has to be reseted (firmware downloaded) or if the
interface is incorrect (no interrupt in endpoint), the probe fails
by returning ENODEV.
Signed-off-by: Mathieu OTHACEHE
---
drivers/usb/serial/mxu11x0.c | 130 ++-
1 file changed, 78 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
index 354fcb5..0392531 100644
--- a/drivers/usb/serial/mxu11x0.c
+++ b/drivers/usb/serial/mxu11x0.c
@@ -272,7 +272,8 @@ static int mxu1_send_ctrl_urb(struct usb_serial *serial,
}
static int mxu1_download_firmware(struct usb_serial *serial,
- const struct firmware *fw_p)
+ const struct firmware *fw_p,
+ struct usb_endpoint_descriptor *endpoint)
{
int status = 0;
int buffer_size;
@@ -285,7 +286,7 @@ static int mxu1_download_firmware(struct usb_serial *serial,
struct mxu1_firmware_header *header;
unsigned int pipe;
- pipe = usb_sndbulkpipe(dev, serial->port[0]->bulk_out_endpointAddress);
+ pipe = usb_sndbulkpipe(dev, endpoint->bEndpointAddress);
buffer_size = fw_p->size + sizeof(*header);
buffer = kmalloc(buffer_size, GFP_KERNEL);
@@ -336,16 +337,85 @@ static void mxu1_release(struct usb_serial *serial)
kfree(mxdev);
}
-static int mxu1_port_probe(struct usb_serial_port *port)
+static int mxu1_probe(struct usb_serial *serial, const struct usb_device_id
*id)
{
- struct mxu1_port *mxport;
- struct mxu1_device *mxdev;
+ struct usb_host_interface *cur_altsetting;
+ char fw_name[32];
+ const struct firmware *fw_p = NULL;
+ struct usb_device *dev = serial->dev;
+ u16 model;
+ int err;
+ struct usb_endpoint_descriptor *endpoint, *interrupt_in, *bulk_out;
+ int i;
+
+ dev_dbg(&serial->interface->dev, "%s - product 0x%04X, num
configurations %d, configuration value %d\n",
+ __func__, le16_to_cpu(dev->descriptor.idProduct),
+ dev->descriptor.bNumConfigurations,
+ dev->actconfig->desc.bConfigurationValue);
+
+ cur_altsetting = serial->interface->cur_altsetting;
+ interrupt_in = NULL;
+ bulk_out = NULL;
+
+ for (i = 0; i < cur_altsetting->desc.bNumEndpoints; i++) {
+ endpoint = &cur_altsetting->endpoint[i].desc;
+ if (usb_endpoint_is_bulk_out(endpoint)) {
+ dev_dbg(&serial->interface->dev,
+ "found bulk out on endpoint %d\n", i);
+ bulk_out = endpoint;
+ }
+
+ if (usb_endpoint_is_int_in(endpoint)) {
+ dev_dbg(&serial->interface->dev,
+ "found interrupt in on endpoint %d\n", i);
+ interrupt_in = endpoint;
+ }
+ }
+
+ /* if we have only 1 bulk out endpoint, download firmware */
+ if (bulk_out && (cur_altsetting->desc.bNumEndpoints == 1)) {
+
+ model = le16_to_cpu(dev->descriptor.idProduct);
+ snprintf(fw_name,
+sizeof(fw_name),
+"moxa/moxa-%04x.fw",
+model);
+
+ err = request_firmware(&fw_p, fw_name, &serial->interface->dev);
+ if (err) {
+ dev_err(&serial->interface->dev, "failed to request
firmware: %d\n",
+ err);
+ return -ENODEV;
+ }
+
+ err = mxu1_download_firmware(serial, fw_p, bulk_out);
+ if (err)
+ goto err_release_firmware;
- if (!port->interrupt_in_urb) {
- dev_err(&port->dev, "no interrupt urb\n");
+ /* device is being reset */
+ err = -ENODEV;
+ goto err_release_firmware;
+
+ } else if (!interrupt_in) {
+ /* firmware is already loaded but there is
+* no interrupt in endpoint available
+*/
+ dev_err(&serial->interface->dev, "no interrupt endpoint\n");
return -ENODEV;
}
+ return 0;
+
+err_release_firmware:
+ release_firmware(fw_p);
+ return err;
+}
+
+static int mxu1_port_probe(struct usb_serial_port *port)
+{
+ struct mxu1_port *mxport;
+ struct mxu1_device *mxdev;
+
mxport = kzalloc(sizeof(struct mxu1_port), GFP_KERNEL);
if (!mxport)
return -ENOMEM;
@@ -389,16 +459,6 @@ static int mxu1_port_remove(struct usb_serial_port *port)
static int mxu1_startup(struct usb_serial *serial)
{
struct mxu1_device *mxdev;
- struct usb_device
[PATCH 1/3] USB: mxu11x0: fix memory leak on usb_serial private data
On nominal execution, private data allocated on port_probe and attach
are never freed. Add port_remove and release callbacks to free them
respectively.
Signed-off-by: Mathieu OTHACEHE
---
drivers/usb/serial/mxu11x0.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
index e3c3f57c..0fe7eab 100644
--- a/drivers/usb/serial/mxu11x0.c
+++ b/drivers/usb/serial/mxu11x0.c
@@ -328,6 +328,14 @@ static int mxu1_download_firmware(struct usb_serial
*serial,
return 0;
}
+static void mxu1_release(struct usb_serial *serial)
+{
+ struct mxu1_device *mxdev;
+
+ mxdev = usb_get_serial_data(serial);
+ kfree(mxdev);
+}
+
static int mxu1_port_probe(struct usb_serial_port *port)
{
struct mxu1_port *mxport;
@@ -368,6 +376,16 @@ static int mxu1_port_probe(struct usb_serial_port *port)
return 0;
}
+static int mxu1_port_remove(struct usb_serial_port *port)
+{
+ struct mxu1_port *mxport;
+
+ mxport = usb_get_serial_port_data(port);
+ kfree(mxport);
+
+ return 0;
+}
+
static int mxu1_startup(struct usb_serial *serial)
{
struct mxu1_device *mxdev;
@@ -957,7 +975,9 @@ static struct usb_serial_driver mxu11x0_device = {
.id_table = mxu1_idtable,
.num_ports = 1,
.port_probe = mxu1_port_probe,
+ .port_remove= mxu1_port_remove,
.attach = mxu1_startup,
+ .release= mxu1_release,
.open = mxu1_open,
.close = mxu1_close,
.ioctl = mxu1_ioctl,
--
2.6.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] drivers/media/usb/dvb-usb-v2: constify mxl111sf_tuner_config structure
On Sun, Jan 3, 2016 at 7:11 AM, Julia Lawall wrote:
> This mxl111sf_tuner_config structure is never modified, so declare it as
> const.
>
> There are some indentation changes to remain within 80 columns.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thank you for this, Julia
Reviewed-by: Michael Ira Krufky
>
> ---
> drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c |6 +++---
> drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h |8
> drivers/media/usb/dvb-usb-v2/mxl111sf.c |2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> index 444579b..7d16252 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> @@ -36,7 +36,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info
> (or-able)).");
> struct mxl111sf_tuner_state {
> struct mxl111sf_state *mxl_state;
>
> - struct mxl111sf_tuner_config *cfg;
> + const struct mxl111sf_tuner_config *cfg;
>
> enum mxl_if_freq if_freq;
>
> @@ -489,8 +489,8 @@ static struct dvb_tuner_ops mxl111sf_tuner_tuner_ops = {
> };
>
> struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> - struct mxl111sf_state *mxl_state,
> - struct mxl111sf_tuner_config *cfg)
> + struct mxl111sf_state *mxl_state,
> + const struct mxl111sf_tuner_config *cfg)
> {
> struct mxl111sf_tuner_state *state = NULL;
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> index e6caab2..509b550 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> @@ -63,13 +63,13 @@ struct mxl111sf_tuner_config {
> #if IS_ENABLED(CONFIG_DVB_USB_MXL111SF)
> extern
> struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> - struct mxl111sf_state *mxl_state,
> - struct mxl111sf_tuner_config *cfg);
> + struct mxl111sf_state *mxl_state,
> + const struct mxl111sf_tuner_config *cfg);
> #else
> static inline
> struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> - struct mxl111sf_state *mxl_state,
> - struct mxl111sf_tuner_config *cfg)
> + struct mxl111sf_state *mxl_state,
> + const struct mxl111sf_tuner_config *cfg)
> {
> printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
> return NULL;
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index b669dec..b586e17 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -856,7 +856,7 @@ static int mxl111sf_ant_hunt(struct dvb_frontend *fe)
> return 0;
> }
>
> -static struct mxl111sf_tuner_config mxl_tuner_config = {
> +static const struct mxl111sf_tuner_config mxl_tuner_config = {
> .if_freq = MXL_IF_6_0, /* applies to external IF output, only
> */
> .invert_spectrum = 0,
> .read_reg= mxl111sf_read_reg,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
On Mon, Dec 28, 2015 at 03:11:25PM +0100, Arnd Bergmann wrote: > On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote: > > On 28 December 2015 at 12:50, Arnd Bergmann wrote: > > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote: > > > How about a different approach that keeps the relocatable kernel, but > > > moves it in > > > physical memory with the same random offset as the virtual address? That > > > way, both > > > would be random, and you can keep the simple virt_to_phys() function. > > > > > > I suppose the downside of that is that the number of random bits is then > > > limited > > > by the size of the first memblock, which is smaller than the vmalloc area. > > > > > > > I don't see a reason to use the same virtual and physical offset > > (other than the conditional). On arm64, it would be up to the > > bootloader to decide where to put the Image in physical memory, and it > > would be up to the kernel to decide whether or not to virtually remap > > itself. > > I see. If we pull in the bootloader to the discussion, there are a couple > of related points that are not directly required for your series but that > we should keep in mind anyway: > > - We need to implement the randomization for each boot loader separately. > This is probably easy enough for grub, as it can tap the same random > number source that you use here, but a little harder for u-boot (requiring > to implement access to hardware rng separately on each platform) and > much harder to get done consistently in UEFI for direct kernel loading > since there is no common upstream. In the GRUB case the kernel is loaded as an EFI application -- as far as I am aware, GRUB for arm64 doesn't know anything about the Linux kernel Image binary. When loaded as an EFI application the EFI stub can perform the relocation, which it already does if the kernel was laoded at an address it cannot execute from. It looks like Ard's implemented that for v2. Being (cold) booted from EFI is likely to be the most consistent case as we have complete control over where the kernel is placed, bar some limitations imposed by prior EFI applications or EFI itself. > - once we have a random number in the bootloader, we should also pass that > through a DT property. This has been discussed multiple times in the past > and I think we had reached consensus already but don't know if we had > agreed on a specific DT property that contains the random number seed. Any links for this? I don't recall spotting this discussion. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dell-wmi: Stop storing pointers to DMI tables
The dmi_walk function maps the DMI table, walks it, and unmaps it.
This means that the dell_bios_hotkey_table that find_hk_type stores
points to unmapped memory by the time it gets read.
I've been able to trigger crashes caused by the stale pointer a
couple of times, but never on a stock kernel.
Fix it by generating the keymap in the dmi_walk callback instead of
storing a pointer.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
This seems to work on my laptop. It applies to platform-drivers-x86/for-next.
drivers/platform/x86/dell-wmi.c | 69 +
1 file changed, 42 insertions(+), 27 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 57402c4c394e..52db2721d7e3 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -116,7 +116,10 @@ struct dell_bios_hotkey_table {
};
-static const struct dell_bios_hotkey_table *dell_bios_hotkey_table;
+struct dell_dmi_results {
+ int err;
+ struct key_entry *keymap;
+};
/* Uninitialized entries here are KEY_RESERVED == 0. */
static const u16 bios_to_linux_keycode[256] __initconst = {
@@ -316,20 +319,34 @@ static void dell_wmi_notify(u32 value, void *context)
kfree(obj);
}
-static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
+static void __init handle_dmi_table(const struct dmi_header *dm,
+ void *opaque)
{
- int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
- sizeof(struct dell_bios_keymap_entry);
+ struct dell_dmi_results *results = opaque;
+ struct dell_bios_hotkey_table *table;
struct key_entry *keymap;
- int i;
+ int hotkey_num, i;
+
+ if (results->err || results->keymap)
+ return; /* We already found the hotkey table. */
+
+ if (dm->type != 0xb2 || dm->length <= 6)
+ return;
+
+ table = container_of(dm, struct dell_bios_hotkey_table, header);
+
+ hotkey_num = (table->header.length - 4) /
+ sizeof(struct dell_bios_keymap_entry);
keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
- if (!keymap)
- return NULL;
+ if (!keymap) {
+ results->err = -ENOMEM;
+ return;
+ }
for (i = 0; i < hotkey_num; i++) {
const struct dell_bios_keymap_entry *bios_entry =
- &dell_bios_hotkey_table->keymap[i];
+ &table->keymap[i];
/* Uninitialized entries are 0 aka KEY_RESERVED. */
u16 keycode = (bios_entry->keycode <
@@ -358,11 +375,13 @@ static const struct key_entry * __init
dell_wmi_prepare_new_keymap(void)
keymap[hotkey_num].type = KE_END;
- return keymap;
+ results->err = 0;
+ results->keymap = keymap;
}
static int __init dell_wmi_input_setup(void)
{
+ struct dell_dmi_results dmi_results = {};
int err;
dell_wmi_input_dev = input_allocate_device();
@@ -373,20 +392,26 @@ static int __init dell_wmi_input_setup(void)
dell_wmi_input_dev->phys = "wmi/input0";
dell_wmi_input_dev->id.bustype = BUS_HOST;
- if (dell_new_hk_type) {
- const struct key_entry *keymap = dell_wmi_prepare_new_keymap();
- if (!keymap) {
- err = -ENOMEM;
- goto err_free_dev;
- }
+ err = dmi_walk(handle_dmi_table, &dmi_results);
+ if (err)
+ goto err_free_dev;
- err = sparse_keymap_setup(dell_wmi_input_dev, keymap, NULL);
+ if (dmi_results.err) {
+ err = dmi_results.err;
+ goto err_free_dev;
+ }
+
+ if (dmi_results.keymap) {
+ dell_new_hk_type = true;
+
+ err = sparse_keymap_setup(dell_wmi_input_dev,
+ dmi_results.keymap, NULL);
/*
* Sparse keymap library makes a copy of keymap so we
* don't need the original one that was allocated.
*/
- kfree(keymap);
+ kfree(dmi_results.keymap);
} else {
err = sparse_keymap_setup(dell_wmi_input_dev,
dell_wmi_legacy_keymap, NULL);
@@ -413,15 +438,6 @@ static void dell_wmi_input_destroy(void)
input_unregister_device(dell_wmi_input_dev);
}
-static void __init find_hk_type(const struct dmi_header *dm, void *dummy)
-{
- if (dm->type == 0xb2 && dm->length > 6) {
- dell_new_hk_type = true;
- dell_bios_hotkey_table =
- container_of(dm, struct dell_bios_hotkey_table, header);
- }
-}
-
static int __init dell_wmi_init(void)
{
int
Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()
On 3 January 2016 at 10:36, Arend van Spriel wrote:
> On 02-01-16 12:21, SF Markus Elfring wrote:
>>> Did you look at the resulting assembly code for different target
>>> architectures?
>>
>> Not yet. - Which execution system variants would you recommend for
>> further comparisons?
>
> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC.
Oh, don't forget about MIPS with its fancy branches handling. You know
about it, don't you?
I'm against this patch as well.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
On 3 January 2016 at 15:50, Mark Rutland wrote: > On Mon, Dec 28, 2015 at 03:11:25PM +0100, Arnd Bergmann wrote: >> On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote: >> > On 28 December 2015 at 12:50, Arnd Bergmann wrote: >> > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote: >> > > How about a different approach that keeps the relocatable kernel, but >> > > moves it in >> > > physical memory with the same random offset as the virtual address? That >> > > way, both >> > > would be random, and you can keep the simple virt_to_phys() function. >> > > >> > > I suppose the downside of that is that the number of random bits is then >> > > limited >> > > by the size of the first memblock, which is smaller than the vmalloc >> > > area. >> > > >> > >> > I don't see a reason to use the same virtual and physical offset >> > (other than the conditional). On arm64, it would be up to the >> > bootloader to decide where to put the Image in physical memory, and it >> > would be up to the kernel to decide whether or not to virtually remap >> > itself. >> >> I see. If we pull in the bootloader to the discussion, there are a couple >> of related points that are not directly required for your series but that >> we should keep in mind anyway: >> >> - We need to implement the randomization for each boot loader separately. >> This is probably easy enough for grub, as it can tap the same random >> number source that you use here, but a little harder for u-boot (requiring >> to implement access to hardware rng separately on each platform) and >> much harder to get done consistently in UEFI for direct kernel loading >> since there is no common upstream. > > In the GRUB case the kernel is loaded as an EFI application -- as far as I am > aware, GRUB for arm64 doesn't know anything about the Linux kernel Image > binary. > No, it doesn't. Alexander Graf is even proposing a EFI compatible runtime in U-boot so it can run EFI-GRUB as well, so it is unlikely that something like that will get added soon. If he includes a EFI_RNG_PROTOCOL implementation, we can run these patches on U-Boot as well. > When loaded as an EFI application the EFI stub can perform the relocation, > which it already does if the kernel was laoded at an address it cannot execute > from. It looks like Ard's implemented that for v2. > Indeed. > Being (cold) booted from EFI is likely to be the most consistent case as we > have complete control over where the kernel is placed, bar some limitations > imposed by prior EFI applications or EFI itself. > >> - once we have a random number in the bootloader, we should also pass that >> through a DT property. This has been discussed multiple times in the past >> and I think we had reached consensus already but don't know if we had >> agreed on a specific DT property that contains the random number seed. > > Any links for this? I don't recall spotting this discussion. > > Thanks, > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "git send-email" thru Gmail incurs few minutes delay
On 1/3/16, Andrey Utkin wrote: > After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and > before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':" > prompt I always have a delay of 2-3 minutes. It is weird! "Unsafe > clients" are allowed in Gmail settings. > I experience this both with @gmail.com mailbox and with gmail-based > company domain mail. > I noticed this happening the first time several months ago. > Has anybody else experienced this? Any solution? > My git version is 2.6.4. > > -- Yes. I see it. It's the gmail smtp gateway but 3 minutes is short, I am seeing longer. It's gmail not git. Jeff > Bluecherry developer. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] x86/extable: use generic search and sort routines
Replace the arch specific versions of search_extable() and sort_extable()
with calls to the generic ones, which now support relative exception
tables as well.
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/uaccess.h | 5 +-
arch/x86/mm/extable.c | 106 +---
2 files changed, 4 insertions(+), 107 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 09b1b0ab94b7..6d130c4cb7de 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -106,9 +106,8 @@ static inline bool __chk_range_not_ok(unsigned long addr,
unsigned long size, un
struct exception_table_entry {
int insn, fixup;
};
-/* This is not the generic standard exception_table_entry format */
-#define ARCH_HAS_SORT_EXTABLE
-#define ARCH_HAS_SEARCH_EXTABLE
+
+#define ARCH_HAS_RELATIVE_EXTABLE
extern int fixup_exception(struct pt_regs *regs);
extern int early_fixup_exception(unsigned long *ip);
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 903ec1e9c326..0b172b656f43 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,14 +1,9 @@
+
#include
-#include
-#include
+
#include
static inline unsigned long
-ex_insn_addr(const struct exception_table_entry *x)
-{
- return (unsigned long)&x->insn + x->insn;
-}
-static inline unsigned long
ex_fixup_addr(const struct exception_table_entry *x)
{
return (unsigned long)&x->fixup + x->fixup;
@@ -70,100 +65,3 @@ int __init early_fixup_exception(unsigned long *ip)
return 0;
}
-
-/*
- * Search one exception table for an entry corresponding to the
- * given instruction address, and return the address of the entry,
- * or NULL if none is found.
- * We use a binary search, and thus we assume that the table is
- * already sorted.
- */
-const struct exception_table_entry *
-search_extable(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
-{
- while (first <= last) {
- const struct exception_table_entry *mid;
- unsigned long addr;
-
- mid = ((last - first) >> 1) + first;
- addr = ex_insn_addr(mid);
- if (addr < value)
- first = mid + 1;
- else if (addr > value)
- last = mid - 1;
- else
- return mid;
-}
-return NULL;
-}
-
-/*
- * The exception table needs to be sorted so that the binary
- * search that we use to find entries in it works properly.
- * This is used both for the kernel exception table and for
- * the exception tables of modules that get loaded.
- *
- */
-static int cmp_ex(const void *a, const void *b)
-{
- const struct exception_table_entry *x = a, *y = b;
-
- /*
-* This value will always end up fittin in an int, because on
-* both i386 and x86-64 the kernel symbol-reachable address
-* space is < 2 GiB.
-*
-* This compare is only valid after normalization.
-*/
- return x->insn - y->insn;
-}
-
-void sort_extable(struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
- struct exception_table_entry *p;
- int i;
-
- /* Convert all entries to being relative to the start of the section */
- i = 0;
- for (p = start; p < finish; p++) {
- p->insn += i;
- i += 4;
- p->fixup += i;
- i += 4;
- }
-
- sort(start, finish - start, sizeof(struct exception_table_entry),
-cmp_ex, NULL);
-
- /* Denormalize all entries */
- i = 0;
- for (p = start; p < finish; p++) {
- p->insn -= i;
- i += 4;
- p->fixup -= i;
- i += 4;
- }
-}
-
-#ifdef CONFIG_MODULES
-/*
- * If the exception table is sorted, any referring to the module init
- * will be at the beginning or the end.
- */
-void trim_init_extable(struct module *m)
-{
- /*trim the beginning*/
- while (m->num_exentries &&
- within_module_init(ex_insn_addr(&m->extable[0]), m)) {
- m->extable++;
- m->num_exentries--;
- }
- /*trim the end*/
- while (m->num_exentries &&
-
within_module_init(ex_insn_addr(&m->extable[m->num_exentries-1]), m))
- m->num_exentries--;
-}
-#endif /* CONFIG_MODULES */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] extable: add support for relative extables to search and sort routines
This adds support to the generic search_extable() and sort_extable()
implementations for dealing with exception table entries whose fields
contain relative offsets rather than absolute addresses.
Signed-off-by: Ard Biesheuvel
---
lib/extable.c | 50
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/lib/extable.c b/lib/extable.c
index 4cac81ec225e..0be02ad561e9 100644
--- a/lib/extable.c
+++ b/lib/extable.c
@@ -14,7 +14,37 @@
#include
#include
+#ifndef ARCH_HAS_RELATIVE_EXTABLE
+#define ex_to_insn(x) ((x)->insn)
+#else
+static inline unsigned long ex_to_insn(const struct exception_table_entry *x)
+{
+ return (unsigned long)&x->insn + x->insn;
+}
+#endif
+
#ifndef ARCH_HAS_SORT_EXTABLE
+#ifndef ARCH_HAS_RELATIVE_EXTABLE
+#define swap_exNULL
+#else
+static void swap_ex(void *a, void *b, int size)
+{
+ struct exception_table_entry *x = a, *y = b, tmp;
+ int delta = b - a;
+
+ tmp = *x;
+ x->insn = y->insn + delta;
+ y->insn = tmp.insn - delta;
+
+#ifdef swap_ex_entry_fixup
+ swap_ex_entry_fixup(x, y, tmp, delta);
+#else
+ x->fixup = y->fixup + delta;
+ y->fixup = tmp.fixup - delta;
+#endif
+}
+#endif /* ARCH_HAS_RELATIVE_EXTABLE */
+
/*
* The exception table needs to be sorted so that the binary
* search that we use to find entries in it works properly.
@@ -26,9 +56,9 @@ static int cmp_ex(const void *a, const void *b)
const struct exception_table_entry *x = a, *y = b;
/* avoid overflow */
- if (x->insn > y->insn)
+ if (ex_to_insn(x) > ex_to_insn(y))
return 1;
- if (x->insn < y->insn)
+ if (ex_to_insn(x) < ex_to_insn(y))
return -1;
return 0;
}
@@ -37,7 +67,7 @@ void sort_extable(struct exception_table_entry *start,
struct exception_table_entry *finish)
{
sort(start, finish - start, sizeof(struct exception_table_entry),
-cmp_ex, NULL);
+cmp_ex, swap_ex);
}
#ifdef CONFIG_MODULES
@@ -48,13 +78,15 @@ void sort_extable(struct exception_table_entry *start,
void trim_init_extable(struct module *m)
{
/*trim the beginning*/
- while (m->num_exentries && within_module_init(m->extable[0].insn, m)) {
+ while (m->num_exentries &&
+ within_module_init(ex_to_insn(&m->extable[0]), m)) {
m->extable++;
m->num_exentries--;
}
/*trim the end*/
while (m->num_exentries &&
- within_module_init(m->extable[m->num_exentries-1].insn, m))
+ within_module_init(ex_to_insn(&m->extable[m->num_exentries - 1]),
+ m))
m->num_exentries--;
}
#endif /* CONFIG_MODULES */
@@ -81,13 +113,13 @@ search_extable(const struct exception_table_entry *first,
* careful, the distance between value and insn
* can be larger than MAX_LONG:
*/
- if (mid->insn < value)
+ if (ex_to_insn(mid) < value)
first = mid + 1;
- else if (mid->insn > value)
+ else if (ex_to_insn(mid) > value)
last = mid - 1;
else
return mid;
-}
-return NULL;
+ }
+ return NULL;
}
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] arm64: switch to relative exception tables
Instead of using absolute addresses for both the exception location
and the fixup, use offsets relative to the exception table entry values.
Not only does this cut the size of the exception table in half, it is
also a prerequisite for KASLR, since absolute exception table entries
are subject to dynamic relocation, which is incompatible with the sorting
of the exception table that occurs at build time.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Ard Biesheuvel
---
Note that this patch supersedes the version I sent as part of the series that
implements KASLR for arm64: http://thread.gmane.org/gmane.linux.kernel/2116531
arch/arm64/include/asm/assembler.h | 2 +-
arch/arm64/include/asm/futex.h | 4 ++--
arch/arm64/include/asm/uaccess.h | 18 ++
arch/arm64/kernel/armv8_deprecated.c | 4 ++--
arch/arm64/mm/extable.c | 2 +-
scripts/sortextable.c| 2 +-
6 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index 12eff928ef8b..8094d50f05bc 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -98,7 +98,7 @@
: x; \
.section __ex_table,"a";\
.align 3; \
- .quad b,l;\
+ .long (b - .), (l - .); \
.previous
/*
diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
index 007a69fc4f40..35e73e255ad3 100644
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -44,7 +44,7 @@
" .popsection\n" \
" .pushsection __ex_table,\"a\"\n"\
" .align 3\n"\
-" .quad 1b, 4b, 2b, 4b\n" \
+" .long (1b - .), (4b - .), (2b - .), (4b - .)\n" \
" .popsection\n" \
ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,\
CONFIG_ARM64_PAN) \
@@ -135,7 +135,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
" .popsection\n"
" .pushsection __ex_table,\"a\"\n"
" .align 3\n"
-" .quad 1b, 4b, 2b, 4b\n"
+" .long (1b - .), (4b - .), (2b - .), (4b - .)\n"
" .popsection\n"
: "+r" (ret), "=&r" (val), "+Q" (*uaddr), "=&r" (tmp)
: "r" (oldval), "r" (newval), "Ir" (-EFAULT)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index b2ede967fe7d..ab627e6c06c9 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -36,11 +36,11 @@
#define VERIFY_WRITE 1
/*
- * The exception table consists of pairs of addresses: the first is the
- * address of an instruction that is allowed to fault, and the second is
- * the address at which the program should continue. No registers are
- * modified, so it is entirely up to the continuation code to figure out
- * what to do.
+ * The exception table consists of pairs of relative offsets: the first
+ * is the relative offset to an instruction that is allowed to fault,
+ * and the second is the relative offset at which the program should
+ * continue. No registers are modified, so it is entirely up to the
+ * continuation code to figure out what to do.
*
* All the routines below use bits of fixup code that are out of line
* with the main instruction path. This means when everything is well,
@@ -50,9 +50,11 @@
struct exception_table_entry
{
- unsigned long insn, fixup;
+ int insn, fixup;
};
+#define ARCH_HAS_RELATIVE_EXTABLE
+
extern int fixup_exception(struct pt_regs *regs);
#define KERNEL_DS (-1UL)
@@ -125,7 +127,7 @@ static inline void set_fs(mm_segment_t fs)
" .previous\n"\
" .section __ex_table,\"a\"\n"\
" .align 3\n"\
- " .quad 1b, 3b\n" \
+ " .long (1b - .), (3b - .)\n" \
" .previous" \
: "+r" (err), "=&r" (x) \
: "r" (addr), "i" (-EFAULT))
@@ -192,7 +194,7 @@ do {
\
" .previous\n"\
" .section __ex_table,\"a\"\n"\
" .align 3\n"\
- " .quad 1b, 3b\n" \
+ " .long (
[PATCH 3/6] s390/extable: use generic search and sort routines
Replace the arch specific versions of search_extable() and sort_extable()
with calls to the generic ones, which now support relative exception
tables as well.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Signed-off-by: Ard Biesheuvel
---
arch/s390/include/asm/uaccess.h | 8 +-
arch/s390/mm/Makefile | 2 +-
arch/s390/mm/extable.c | 85
3 files changed, 2 insertions(+), 93 deletions(-)
diff --git a/arch/s390/include/asm/uaccess.h b/arch/s390/include/asm/uaccess.h
index 9dd4cc47ddc7..e0900ddf91dd 100644
--- a/arch/s390/include/asm/uaccess.h
+++ b/arch/s390/include/asm/uaccess.h
@@ -79,18 +79,12 @@ struct exception_table_entry
int insn, fixup;
};
-static inline unsigned long extable_insn(const struct exception_table_entry *x)
-{
- return (unsigned long)&x->insn + x->insn;
-}
-
static inline unsigned long extable_fixup(const struct exception_table_entry
*x)
{
return (unsigned long)&x->fixup + x->fixup;
}
-#define ARCH_HAS_SORT_EXTABLE
-#define ARCH_HAS_SEARCH_EXTABLE
+#define ARCH_HAS_RELATIVE_EXTABLE
/**
* __copy_from_user: - Copy a block of data from user space, with less
checking.
diff --git a/arch/s390/mm/Makefile b/arch/s390/mm/Makefile
index 839592ca265c..479550dae80e 100644
--- a/arch/s390/mm/Makefile
+++ b/arch/s390/mm/Makefile
@@ -3,7 +3,7 @@
#
obj-y := init.o fault.o extmem.o mmap.o vmem.o pgtable.o maccess.o
-obj-y += page-states.o gup.o extable.o pageattr.o mem_detect.o
+obj-y += page-states.o gup.o pageattr.o mem_detect.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/s390/mm/extable.c b/arch/s390/mm/extable.c
deleted file mode 100644
index 18c8b819b0aa..
--- a/arch/s390/mm/extable.c
+++ /dev/null
@@ -1,85 +0,0 @@
-#include
-#include
-#include
-
-/*
- * Search one exception table for an entry corresponding to the
- * given instruction address, and return the address of the entry,
- * or NULL if none is found.
- * We use a binary search, and thus we assume that the table is
- * already sorted.
- */
-const struct exception_table_entry *
-search_extable(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
-{
- const struct exception_table_entry *mid;
- unsigned long addr;
-
- while (first <= last) {
- mid = ((last - first) >> 1) + first;
- addr = extable_insn(mid);
- if (addr < value)
- first = mid + 1;
- else if (addr > value)
- last = mid - 1;
- else
- return mid;
- }
- return NULL;
-}
-
-/*
- * The exception table needs to be sorted so that the binary
- * search that we use to find entries in it works properly.
- * This is used both for the kernel exception table and for
- * the exception tables of modules that get loaded.
- *
- */
-static int cmp_ex(const void *a, const void *b)
-{
- const struct exception_table_entry *x = a, *y = b;
-
- /* This compare is only valid after normalization. */
- return x->insn - y->insn;
-}
-
-void sort_extable(struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
- struct exception_table_entry *p;
- int i;
-
- /* Normalize entries to being relative to the start of the section */
- for (p = start, i = 0; p < finish; p++, i += 8) {
- p->insn += i;
- p->fixup += i + 4;
- }
- sort(start, finish - start, sizeof(*start), cmp_ex, NULL);
- /* Denormalize all entries */
- for (p = start, i = 0; p < finish; p++, i += 8) {
- p->insn -= i;
- p->fixup -= i + 4;
- }
-}
-
-#ifdef CONFIG_MODULES
-/*
- * If the exception table is sorted, any referring to the module init
- * will be at the beginning or the end.
- */
-void trim_init_extable(struct module *m)
-{
- /* Trim the beginning */
- while (m->num_exentries &&
- within_module_init(extable_insn(&m->extable[0]), m)) {
- m->extable++;
- m->num_exentries--;
- }
- /* Trim the end */
- while (m->num_exentries &&
-
within_module_init(extable_insn(&m->extable[m->num_exentries-1]), m))
- m->num_exentries--;
-}
-#endif /* CONFIG_MODULES */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] generic relative extable support
There are currently four architectures (x86, ia64, alpha and s390) whose user-access exception tables are relative to the table entry address rather than absolute. Each of these architectures has its own search_extable() and sort_extable() implementation, which are not only mostly identical to each other, but also deviate very little from the generic absolute implementations in lib/extable.c that they override. So before making arm64 the fifth architecture that reimplements this, let's refactor the existing code so that all of these architectures use common code for searching and sorting the relative extables. Archs may set ARCH_HAS_RELATIVE_EXTABLE to indicate that the table consists of a pair of relative ints, and may define swap_ex_entry_fixup() if the fixup member needs special treatment in the swapping step of the sorting routine (such as alpha). Note that the s390 patch applies on top of the following patch: http://article.gmane.org/gmane.linux.kernel/2117036 which fixes a bug I spotted while working on this code. Since that probably needs to go to -stable, I broke it out and posted it separately. Ard Biesheuvel (6): extable: add support for relative extables to search and sort routines alpha/extable: use generic search and sort routines s390/extable: use generic search and sort routines x86/extable: use generic search and sort routines ia64/extable: use generic search and sort routines arm64: switch to relative exception tables arch/alpha/include/asm/uaccess.h | 10 +- arch/alpha/mm/Makefile | 2 +- arch/alpha/mm/extable.c | 92 - arch/arm64/include/asm/assembler.h | 2 +- arch/arm64/include/asm/futex.h | 4 +- arch/arm64/include/asm/uaccess.h | 18 ++-- arch/arm64/kernel/armv8_deprecated.c | 4 +- arch/arm64/mm/extable.c | 2 +- arch/ia64/include/asm/uaccess.h | 8 +- arch/ia64/mm/extable.c | 97 +- arch/s390/include/asm/uaccess.h | 8 +- arch/s390/mm/Makefile| 2 +- arch/s390/mm/extable.c | 85 arch/x86/include/asm/uaccess.h | 5 +- arch/x86/mm/extable.c| 106 +--- lib/extable.c| 50 +++-- scripts/sortextable.c| 2 +- 17 files changed, 77 insertions(+), 420 deletions(-) delete mode 100644 arch/alpha/mm/extable.c delete mode 100644 arch/s390/mm/extable.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] alpha/extable: use generic search and sort routines
Replace the arch specific versions of search_extable() and sort_extable()
with calls to the generic ones, which now support relative exception
tables as well.
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Signed-off-by: Ard Biesheuvel
---
arch/alpha/include/asm/uaccess.h | 10 ++-
arch/alpha/mm/Makefile | 2 +-
arch/alpha/mm/extable.c | 92
3 files changed, 9 insertions(+), 95 deletions(-)
diff --git a/arch/alpha/include/asm/uaccess.h b/arch/alpha/include/asm/uaccess.h
index 9b0d40093c9a..c419b43c461d 100644
--- a/arch/alpha/include/asm/uaccess.h
+++ b/arch/alpha/include/asm/uaccess.h
@@ -483,7 +483,13 @@ struct exception_table_entry
(pc) + (_fixup)->fixup.bits.nextinsn; \
})
-#define ARCH_HAS_SORT_EXTABLE
-#define ARCH_HAS_SEARCH_EXTABLE
+#define ARCH_HAS_RELATIVE_EXTABLE
+
+#define swap_ex_entry_fixup(a, b, tmp, delta) \
+ do {\
+ (a)->fixup.unit = (b)->fixup.unit; \
+ (b)->fixup.unit = (tmp).fixup.unit; \
+ } while (0)
+
#endif /* __ALPHA_UACCESS_H */
diff --git a/arch/alpha/mm/Makefile b/arch/alpha/mm/Makefile
index c993d3f93cf6..5a9807936411 100644
--- a/arch/alpha/mm/Makefile
+++ b/arch/alpha/mm/Makefile
@@ -4,6 +4,6 @@
ccflags-y := -Werror
-obj-y := init.o fault.o extable.o
+obj-y := init.o fault.o
obj-$(CONFIG_DISCONTIGMEM) += numa.o
diff --git a/arch/alpha/mm/extable.c b/arch/alpha/mm/extable.c
deleted file mode 100644
index 813c9b63c0e1..
--- a/arch/alpha/mm/extable.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- * linux/arch/alpha/mm/extable.c
- */
-
-#include
-#include
-#include
-
-static inline unsigned long ex_to_addr(const struct exception_table_entry *x)
-{
- return (unsigned long)&x->insn + x->insn;
-}
-
-static void swap_ex(void *a, void *b, int size)
-{
- struct exception_table_entry *ex_a = a, *ex_b = b;
- unsigned long addr_a = ex_to_addr(ex_a), addr_b = ex_to_addr(ex_b);
- unsigned int t = ex_a->fixup.unit;
-
- ex_a->fixup.unit = ex_b->fixup.unit;
- ex_b->fixup.unit = t;
- ex_a->insn = (int)(addr_b - (unsigned long)&ex_a->insn);
- ex_b->insn = (int)(addr_a - (unsigned long)&ex_b->insn);
-}
-
-/*
- * The exception table needs to be sorted so that the binary
- * search that we use to find entries in it works properly.
- * This is used both for the kernel exception table and for
- * the exception tables of modules that get loaded.
- */
-static int cmp_ex(const void *a, const void *b)
-{
- const struct exception_table_entry *x = a, *y = b;
-
- /* avoid overflow */
- if (ex_to_addr(x) > ex_to_addr(y))
- return 1;
- if (ex_to_addr(x) < ex_to_addr(y))
- return -1;
- return 0;
-}
-
-void sort_extable(struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
- sort(start, finish - start, sizeof(struct exception_table_entry),
-cmp_ex, swap_ex);
-}
-
-#ifdef CONFIG_MODULES
-/*
- * Any entry referring to the module init will be at the beginning or
- * the end.
- */
-void trim_init_extable(struct module *m)
-{
- /*trim the beginning*/
- while (m->num_exentries &&
- within_module_init(ex_to_addr(&m->extable[0]), m)) {
- m->extable++;
- m->num_exentries--;
- }
- /*trim the end*/
- while (m->num_exentries &&
- within_module_init(ex_to_addr(&m->extable[m->num_exentries-1]),
- m))
- m->num_exentries--;
-}
-#endif /* CONFIG_MODULES */
-
-const struct exception_table_entry *
-search_extable(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
-{
-while (first <= last) {
- const struct exception_table_entry *mid;
- unsigned long mid_value;
-
- mid = (last - first) / 2 + first;
- mid_value = ex_to_addr(mid);
-if (mid_value == value)
-return mid;
-else if (mid_value < value)
-first = mid+1;
-else
-last = mid-1;
-}
-
-return NULL;
-}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ia64/extable: use generic search and sort routines
Replace the arch specific versions of search_extable() and sort_extable()
with calls to the generic ones, which now support relative exception
tables as well.
Cc: Tony Luck
Cc: Fenghua Yu
Signed-off-by: Ard Biesheuvel
---
arch/ia64/include/asm/uaccess.h | 8 +-
arch/ia64/mm/extable.c | 97 +---
2 files changed, 4 insertions(+), 101 deletions(-)
diff --git a/arch/ia64/include/asm/uaccess.h b/arch/ia64/include/asm/uaccess.h
index 4f3fb6ccbf21..2189d5ddc1ee 100644
--- a/arch/ia64/include/asm/uaccess.h
+++ b/arch/ia64/include/asm/uaccess.h
@@ -341,13 +341,11 @@ extern unsigned long __strnlen_user (const char __user *,
long);
__su_ret; \
})
-/* Generic code can't deal with the location-relative format that we use for
compactness. */
-#define ARCH_HAS_SORT_EXTABLE
-#define ARCH_HAS_SEARCH_EXTABLE
+#define ARCH_HAS_RELATIVE_EXTABLE
struct exception_table_entry {
- int addr; /* location-relative address of insn this fixup is for
*/
- int cont; /* location-relative continuation addr.; if bit 2 is
set, r9 is set to 0 */
+ int insn; /* location-relative address of insn this fixup is for
*/
+ int fixup; /* location-relative continuation addr.; if bit 2 is
set, r9 is set to 0 */
};
extern void ia64_handle_exception (struct pt_regs *regs, const struct
exception_table_entry *e);
diff --git a/arch/ia64/mm/extable.c b/arch/ia64/mm/extable.c
index c99a41e29fe8..8f70bb2d0c37 100644
--- a/arch/ia64/mm/extable.c
+++ b/arch/ia64/mm/extable.c
@@ -5,107 +5,12 @@
* David Mosberger-Tang
*/
-#include
-
#include
-#include
-
-static int cmp_ex(const void *a, const void *b)
-{
- const struct exception_table_entry *l = a, *r = b;
- u64 lip = (u64) &l->addr + l->addr;
- u64 rip = (u64) &r->addr + r->addr;
-
- /* avoid overflow */
- if (lip > rip)
- return 1;
- if (lip < rip)
- return -1;
- return 0;
-}
-
-static void swap_ex(void *a, void *b, int size)
-{
- struct exception_table_entry *l = a, *r = b, tmp;
- u64 delta = (u64) r - (u64) l;
-
- tmp = *l;
- l->addr = r->addr + delta;
- l->cont = r->cont + delta;
- r->addr = tmp.addr - delta;
- r->cont = tmp.cont - delta;
-}
-
-/*
- * Sort the exception table. It's usually already sorted, but there
- * may be unordered entries due to multiple text sections (such as the
- * .init text section). Note that the exception-table-entries contain
- * location-relative addresses, which requires a bit of care during
- * sorting to avoid overflows in the offset members (e.g., it would
- * not be safe to make a temporary copy of an exception-table entry on
- * the stack, because the stack may be more than 2GB away from the
- * exception-table).
- */
-void sort_extable (struct exception_table_entry *start,
- struct exception_table_entry *finish)
-{
- sort(start, finish - start, sizeof(struct exception_table_entry),
-cmp_ex, swap_ex);
-}
-
-static inline unsigned long ex_to_addr(const struct exception_table_entry *x)
-{
- return (unsigned long)&x->addr + x->addr;
-}
-
-#ifdef CONFIG_MODULES
-/*
- * Any entry referring to the module init will be at the beginning or
- * the end.
- */
-void trim_init_extable(struct module *m)
-{
- /*trim the beginning*/
- while (m->num_exentries &&
- within_module_init(ex_to_addr(&m->extable[0]), m)) {
- m->extable++;
- m->num_exentries--;
- }
- /*trim the end*/
- while (m->num_exentries &&
- within_module_init(ex_to_addr(&m->extable[m->num_exentries-1]),
- m))
- m->num_exentries--;
-}
-#endif /* CONFIG_MODULES */
-
-const struct exception_table_entry *
-search_extable (const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long ip)
-{
- const struct exception_table_entry *mid;
- unsigned long mid_ip;
- long diff;
-
-while (first <= last) {
- mid = &first[(last - first)/2];
- mid_ip = (u64) &mid->addr + mid->addr;
- diff = mid_ip - ip;
-if (diff == 0)
-return mid;
-else if (diff < 0)
-first = mid + 1;
-else
-last = mid - 1;
-}
-return NULL;
-}
void
ia64_handle_exception (struct pt_regs *regs, const struct
exception_table_entry *e)
{
- long fix = (u64) &e->cont + e->cont;
+ long fix = (u64) &e->fixup + e->fixup;
regs->r8 = -EFAULT;
if (fix & 4)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
[PATCH] cgroup: make /proc/cgroups aligned
This patch makes /proc/cgroups aligned like this: $ cat /proc/cgroups #subsys_namehierarchy num_cgroups enabled cpuset 11 1 1 cpu2 1 1 cpuacct2 1 1 blkio 12 1 1 memory3 1 1 devices483 1 freezer 10 1 1 perf_event9 1 1 hugetlb7 1 1 intel_rdt6 1 1 pids8 1 1 debug5 1 1 Signed-off-by: Geliang Tang --- kernel/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index f1603c1..063b28f 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -5411,7 +5411,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v) mutex_lock(&cgroup_mutex); for_each_subsys(ss, i) - seq_printf(m, "%s\t%d\t%d\t%d\n", + seq_printf(m, "%12s\t%9d\t%11d\t%7d\n", ss->legacy_name, ss->root->hierarchy_id, atomic_read(&ss->root->nr_cgrps), cgroup_ssid_enabled(i)); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] USB: mxu11x0: fix memory leak on usb_serial private data
On Sun, Jan 03, 2016 at 03:25:59PM +0100, Mathieu OTHACEHE wrote:
> On nominal execution, private data allocated on port_probe and attach
> are never freed. Add port_remove and release callbacks to free them
> respectively.
Ouch. I thought I'd vetted the driver for further memleaks but
apparently missed the most obvious ones.
> Signed-off-by: Mathieu OTHACEHE
> ---
> drivers/usb/serial/mxu11x0.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
> index e3c3f57c..0fe7eab 100644
> --- a/drivers/usb/serial/mxu11x0.c
> +++ b/drivers/usb/serial/mxu11x0.c
> @@ -328,6 +328,14 @@ static int mxu1_download_firmware(struct usb_serial
> *serial,
> return 0;
> }
>
> +static void mxu1_release(struct usb_serial *serial)
> +{
> + struct mxu1_device *mxdev;
> +
> + mxdev = usb_get_serial_data(serial);
> + kfree(mxdev);
> +}
Please place this once after the matching attach (startup) callback.
> +
> static int mxu1_port_probe(struct usb_serial_port *port)
> {
> struct mxu1_port *mxport;
> @@ -368,6 +376,16 @@ static int mxu1_port_probe(struct usb_serial_port *port)
> return 0;
> }
>
> +static int mxu1_port_remove(struct usb_serial_port *port)
> +{
> + struct mxu1_port *mxport;
> +
> + mxport = usb_get_serial_port_data(port);
> + kfree(mxport);
> +
> + return 0;
> +}
> +
> static int mxu1_startup(struct usb_serial *serial)
> {
> struct mxu1_device *mxdev;
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] USB: mxu11x0: clean device control commands
On Sun, Jan 03, 2016 at 03:26:00PM +0100, Mathieu OTHACEHE wrote:
> Sending OPEN and START commands twice is not necessary for this driver.
> Also send STOP command at close.
>
> Signed-off-by: Mathieu OTHACEHE
> ---
> drivers/usb/serial/mxu11x0.c | 31 +++
> 1 file changed, 7 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
> index 0fe7eab..354fcb5 100644
> --- a/drivers/usb/serial/mxu11x0.c
> +++ b/drivers/usb/serial/mxu11x0.c
> @@ -823,30 +823,6 @@ static int mxu1_open(struct tty_struct *tty, struct
> usb_serial_port *port)
> goto unlink_int_urb;
> }
>
> - /*
> - * reset the data toggle on the bulk endpoints to work around bug in
> - * host controllers where things get out of sync some times
> - */
> - usb_clear_halt(serial->dev, port->write_urb->pipe);
> - usb_clear_halt(serial->dev, port->read_urb->pipe);
This is an unrelated change. You can remove it, but then do so in a
separate patch.
> -
> - if (tty)
> - mxu1_set_termios(tty, port, NULL);
But you should definitely not be removing this.
> -
> - status = mxu1_send_ctrl_urb(serial, MXU1_OPEN_PORT,
> - open_settings, MXU1_UART1_PORT);
> - if (status) {
> - dev_err(&port->dev, "cannot send open command: %d\n", status);
> - goto unlink_int_urb;
> - }
> -
> - status = mxu1_send_ctrl_urb(serial, MXU1_START_PORT,
> - 0, MXU1_UART1_PORT);
> - if (status) {
> - dev_err(&port->dev, "cannot send start command: %d\n", status);
> - goto unlink_int_urb;
> - }
> -
Also did you not say that your sniffed traffic showed the following
sequence OPEN, CONFIG (e.g. purge, set_termios), START?
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-slicoss: Replace variable initialisations by assignments in slic_if_init()
From: Markus Elfring
Date: Sun, 3 Jan 2016 17:25:59 +0100
Replace explicit initialisation for two local variables at the beginning
by assignments.
Signed-off-by: Markus Elfring
---
drivers/staging/slicoss/slicoss.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index b23a2d1..8fdcac8 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter
*adapter,
*/
static int slic_if_init(struct adapter *adapter, unsigned long *flags)
{
- struct sliccard *card = adapter->card;
+ struct sliccard *card;
struct net_device *dev = adapter->netdev;
- __iomem struct slic_regs *slic_regs = adapter->slic_regs;
+ __iomem struct slic_regs *slic_regs;
struct slic_shmem *pshmem;
int rc;
@@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter, unsigned
long *flags)
adapter->queues_initialized = 1;
}
+ slic_regs = adapter->slic_regs;
slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH);
mdelay(1);
@@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter, unsigned
long *flags)
}
adapter->state = ADAPT_UP;
+ card = adapter->card;
if (!card->loadtimerset) {
setup_timer(&card->loadtimer, &slic_timer_load_check,
(ulong)card);
--
2.6.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] staging-slicoss: Replace variable initialisations by assignments in slic_if_init()
On Sun, 3 Jan 2016, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 3 Jan 2016 17:25:59 +0100
>
> Replace explicit initialisation for two local variables at the beginning
> by assignments.
Why?
julia
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/slicoss/slicoss.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/slicoss/slicoss.c
> b/drivers/staging/slicoss/slicoss.c
> index b23a2d1..8fdcac8 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter
> *adapter,
> */
> static int slic_if_init(struct adapter *adapter, unsigned long *flags)
> {
> - struct sliccard *card = adapter->card;
> + struct sliccard *card;
> struct net_device *dev = adapter->netdev;
> - __iomem struct slic_regs *slic_regs = adapter->slic_regs;
> + __iomem struct slic_regs *slic_regs;
> struct slic_shmem *pshmem;
> int rc;
>
> @@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter,
> unsigned long *flags)
> adapter->queues_initialized = 1;
> }
>
> + slic_regs = adapter->slic_regs;
> slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH);
> mdelay(1);
>
> @@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter,
> unsigned long *flags)
> }
>
> adapter->state = ADAPT_UP;
> + card = adapter->card;
> if (!card->loadtimerset) {
> setup_timer(&card->loadtimer, &slic_timer_load_check,
> (ulong)card);
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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/3] USB: mxu11x0: move firmware download and endpoint testing to probe callback
On Sun, Jan 03, 2016 at 03:26:01PM +0100, Mathieu OTHACEHE wrote:
> Move interrupt in endpoint test and firmware download to a new probe
> callback. This avoids unnecessary memory allocations done by core
> before port_probe callback is called.
>
> If the device has to be reseted (firmware downloaded) or if the
> interface is incorrect (no interrupt in endpoint), the probe fails
> by returning ENODEV.
>
> Signed-off-by: Mathieu OTHACEHE
> ---
> drivers/usb/serial/mxu11x0.c | 130
> ++-
> 1 file changed, 78 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
> index 354fcb5..0392531 100644
> --- a/drivers/usb/serial/mxu11x0.c
> +++ b/drivers/usb/serial/mxu11x0.c
> @@ -272,7 +272,8 @@ static int mxu1_send_ctrl_urb(struct usb_serial *serial,
> }
>
> static int mxu1_download_firmware(struct usb_serial *serial,
> - const struct firmware *fw_p)
> + const struct firmware *fw_p,
> + struct usb_endpoint_descriptor *endpoint)
> {
> int status = 0;
> int buffer_size;
> @@ -285,7 +286,7 @@ static int mxu1_download_firmware(struct usb_serial
> *serial,
> struct mxu1_firmware_header *header;
> unsigned int pipe;
>
> - pipe = usb_sndbulkpipe(dev, serial->port[0]->bulk_out_endpointAddress);
> + pipe = usb_sndbulkpipe(dev, endpoint->bEndpointAddress);
>
> buffer_size = fw_p->size + sizeof(*header);
> buffer = kmalloc(buffer_size, GFP_KERNEL);
> @@ -336,16 +337,85 @@ static void mxu1_release(struct usb_serial *serial)
> kfree(mxdev);
> }
>
> -static int mxu1_port_probe(struct usb_serial_port *port)
> +static int mxu1_probe(struct usb_serial *serial, const struct usb_device_id
> *id)
> {
> - struct mxu1_port *mxport;
> - struct mxu1_device *mxdev;
> + struct usb_host_interface *cur_altsetting;
> + char fw_name[32];
> + const struct firmware *fw_p = NULL;
> + struct usb_device *dev = serial->dev;
> + u16 model;
> + int err;
> + struct usb_endpoint_descriptor *endpoint, *interrupt_in, *bulk_out;
> + int i;
> +
> + dev_dbg(&serial->interface->dev, "%s - product 0x%04X, num
> configurations %d, configuration value %d\n",
> + __func__, le16_to_cpu(dev->descriptor.idProduct),
> + dev->descriptor.bNumConfigurations,
> + dev->actconfig->desc.bConfigurationValue);
> +
> + cur_altsetting = serial->interface->cur_altsetting;
> + interrupt_in = NULL;
> + bulk_out = NULL;
> +
> + for (i = 0; i < cur_altsetting->desc.bNumEndpoints; i++) {
> + endpoint = &cur_altsetting->endpoint[i].desc;
> + if (usb_endpoint_is_bulk_out(endpoint)) {
> + dev_dbg(&serial->interface->dev,
> + "found bulk out on endpoint %d\n", i);
> + bulk_out = endpoint;
> + }
> +
> + if (usb_endpoint_is_int_in(endpoint)) {
> + dev_dbg(&serial->interface->dev,
> + "found interrupt in on endpoint %d\n", i);
> + interrupt_in = endpoint;
> + }
> + }
> +
> + /* if we have only 1 bulk out endpoint, download firmware */
> + if (bulk_out && (cur_altsetting->desc.bNumEndpoints == 1)) {
No need for inner parentheses.
> +
> + model = le16_to_cpu(dev->descriptor.idProduct);
> + snprintf(fw_name,
> + sizeof(fw_name),
> + "moxa/moxa-%04x.fw",
> + model);
> +
> + err = request_firmware(&fw_p, fw_name, &serial->interface->dev);
> + if (err) {
> + dev_err(&serial->interface->dev, "failed to request
> firmware: %d\n",
> + err);
> + return -ENODEV;
> + }
> +
> + err = mxu1_download_firmware(serial, fw_p, bulk_out);
> + if (err)
> + goto err_release_firmware;
>
> - if (!port->interrupt_in_urb) {
> - dev_err(&port->dev, "no interrupt urb\n");
> + /* device is being reset */
> + err = -ENODEV;
> + goto err_release_firmware;
> +
> + } else if (!interrupt_in) {
> + /* firmware is already loaded but there is
> + * no interrupt in endpoint available
> + */
Multi-line comments should be on the following format
/*
* ...
*/
Looks good otherwise.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: __vmalloc() vs. GFP_NOIO/GFP_NOFS
On Sun, Jan 03, 2016 at 07:12:47AM +, Al Viro wrote: > Allocation page tables doesn't have gfp argument at all. Trying to propagate > it down there could be done, but it's not attractive. While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in __vmalloc() flags? After all, we explicitly put the pages we'd allocated into the page table at vmalloc range we'd grabbed and these are the addresses visible to caller. Is there any point in having another alias for those pages? vmalloc() itself passes __GFP_HIGHMEM and so does a lot of __vmalloc() callers; in fact, most of those that do not look like a result of "we want vmalloc(), but we want to avoid it going into fs code and possibly deadlocking us; vmalloc() has no gfp_t argument, so let's use __vmalloc() and give it GFP_NOFS". Another very weird thing is the use of GFP_ATOMIC by alloc_large_system_hash(); if we want _that_ honoured, we'd probably have to pass gfp_t to alloc_one_pmd() and friends, but I'm not sure what exactly is that caller requesting. Confused... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
>> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Why is it better? I suggest to refer to the data item "rtc_data->rtc" directly because the variable "rtc" was read only in two if branches. Does it make sense then to reduce the variable allocation? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> Pass the address of the data structure element "time" directly in calls > >> of the function "rtc_update_irq" instead of an extra initialisation > >> for one local variable at the beginning. > > > > Why is it better? > > I suggest to refer to the data item "rtc_data->rtc" directly because > the variable "rtc" was read only in two if branches. > Does it make sense then to reduce the variable allocation? No. That is the job of the compiler. For a local variable whose address is never taken, the compiler can easily detect its live region, and place the initialization in an optimal way. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt()
>> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Also, I don't see anything related to time in this patch. I should have referred to the data structure element "rtc" here. Should I resend this patch series with a corrected commit message now? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/7] tpm_crb: Use the common ACPI definition of struct acpi_tpm2
On Thu, Dec 17, 2015 at 11:23:14AM -0700, Jason Gunthorpe wrote:
> include/acpi/actbl2.h is the proper place for these definitions
> and the needed TPM2 ones have been there since
> commit 413d4a6defe0 ("ACPICA: Update TPM2 ACPI table")
>
> This also drops a couple of le32_to_cpu's for members of this table,
> the existing swapping was not done consistently, and the definitions
> in actbl2.h do not have endianness annotations, declaring that no swap
> is required. Note that the TPM ACPI spec defines all of these
> values to be little endian, both in crb2 and ppi.
I think this patch mixes two separate changes to the driver: removing
l32_to_cpu's and moving to common headers and that is not right.
Even if they should be removed I think what you say about actbl2.h is
wrong. Annotations are probably missing because it is imported code (I'm
happy to be corrected if this is not the case).
/Jarkko
> Signed-off-by: Jason Gunthorpe
> Tested-by: Wilck, Martin
> Tested-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm.h | 7 ---
> drivers/char/tpm/tpm_crb.c | 31 +--
> drivers/char/tpm/tpm_tis.c | 2 +-
> 3 files changed, 10 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 542a80cbfd9c..28b477e8da6a 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -128,13 +128,6 @@ enum tpm2_startup_types {
> TPM2_SU_STATE = 0x0001,
> };
>
> -enum tpm2_start_method {
> - TPM2_START_ACPI = 2,
> - TPM2_START_FIFO = 6,
> - TPM2_START_CRB = 7,
> - TPM2_START_CRB_WITH_ACPI = 8,
> -};
> -
> struct tpm_chip;
>
> struct tpm_vendor_specific {
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 8342cf51ffdc..8dd70696ebe8 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -34,14 +34,6 @@ enum crb_defaults {
> CRB_ACPI_START_INDEX = 1,
> };
>
> -struct acpi_tpm2 {
> - struct acpi_table_header hdr;
> - u16 platform_class;
> - u16 reserved;
> - u64 control_area_pa;
> - u32 start_method;
> -} __packed;
> -
> enum crb_ca_request {
> CRB_CA_REQ_GO_IDLE = BIT(0),
> CRB_CA_REQ_CMD_READY= BIT(1),
> @@ -207,7 +199,7 @@ static const struct tpm_class_ops tpm_crb = {
> static int crb_acpi_add(struct acpi_device *device)
> {
> struct tpm_chip *chip;
> - struct acpi_tpm2 *buf;
> + struct acpi_table_tpm2 *buf;
> struct crb_priv *priv;
> struct device *dev = &device->dev;
> acpi_status status;
> @@ -217,13 +209,14 @@ static int crb_acpi_add(struct acpi_device *device)
>
> status = acpi_get_table(ACPI_SIG_TPM2, 1,
> (struct acpi_table_header **) &buf);
> - if (ACPI_FAILURE(status)) {
> - dev_err(dev, "failed to get TPM2 ACPI table\n");
> + if (ACPI_FAILURE(status) || buf->header.length < sizeof(*buf)) {
> + dev_err(dev, FW_BUG "failed to get TPM2 ACPI table\n");
> return -ENODEV;
> }
>
> /* Should the FIFO driver handle this? */
> - if (buf->start_method == TPM2_START_FIFO)
> + sm = buf->start_method;
> + if (sm == ACPI_TPM2_MEMORY_MAPPED)
> return -ENODEV;
>
> chip = tpmm_chip_alloc(dev, &tpm_crb);
> @@ -232,11 +225,6 @@ static int crb_acpi_add(struct acpi_device *device)
>
> chip->flags = TPM_CHIP_FLAG_TPM2;
>
> - if (buf->hdr.length < sizeof(struct acpi_tpm2)) {
> - dev_err(dev, "TPM2 ACPI table has wrong size");
> - return -EINVAL;
> - }
> -
> priv = (struct crb_priv *) devm_kzalloc(dev, sizeof(struct crb_priv),
> GFP_KERNEL);
> if (!priv) {
> @@ -244,21 +232,20 @@ static int crb_acpi_add(struct acpi_device *device)
> return -ENOMEM;
> }
>
> - sm = le32_to_cpu(buf->start_method);
> -
> /* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
>* report only ACPI start but in practice seems to require both
>* ACPI start and CRB start.
>*/
> - if (sm == TPM2_START_CRB || sm == TPM2_START_FIFO ||
> + if (sm == ACPI_TPM2_COMMAND_BUFFER || sm == ACPI_TPM2_MEMORY_MAPPED ||
> !strcmp(acpi_device_hid(device), "MSFT0101"))
> priv->flags |= CRB_FL_CRB_START;
>
> - if (sm == TPM2_START_ACPI || sm == TPM2_START_CRB_WITH_ACPI)
> + if (sm == ACPI_TPM2_START_METHOD ||
> + sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
> priv->flags |= CRB_FL_ACPI_START;
>
> priv->cca = (struct crb_control_area __iomem *)
> - devm_ioremap_nocache(dev, buf->control_area_pa, 0x1000);
> + devm_ioremap_nocache(dev, buf->control_address, 0x1000);
> if (!priv->cca) {
> dev_err(dev, "ioremap of the control area failed\n");
> return -ENOMEM;
> diff --git a/drivers/char/tpm/tpm_
[PATCH] drivers: staging: octeon-usb: octeon-hcd.c: fixed coding style related warnings
fixed coding style warnings related to comment blocks
Signed-off-by: Saatvik Arya
---
drivers/staging/octeon-usb/octeon-hcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index 6f28717..16d4587 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -2006,7 +2006,8 @@ static void octeon_usb_urb_complete_callback(struct
cvmx_usb_state *usb,
urb->hcpriv = NULL;
/* For Isochronous transactions we need to update the URB packet status
- list from data in our private copy */
+* list from data in our private copy
+*/
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
int i;
/*
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] tpm_tis: Disable interrupt auto probing on a per-device basis
On Thu, Dec 17, 2015 at 11:23:15AM -0700, Jason Gunthorpe wrote:
> Instead of clearing the global interrupts flag when any device
> does not have an interrupt just pass -1 through tpm_info.irq.
>
> The only thing that asks for autoprobing is the force=1 path.
Sorry for my ignorance but what does this patch help? Why interrupts
flag is not enough?
> Signed-off-by: Jason Gunthorpe
> Tested-by: Wilck, Martin
> Tested-by: Jarkko Sakkinen
Did I already give Tested-by's for this series (I did for those that
went into v4.5 pull request)?
/Jarkko
> ---
> drivers/char/tpm/tpm_tis.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index 304323bdcaaa..fecd27b45fd1 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -69,7 +69,11 @@ enum tis_defaults {
> struct tpm_info {
> unsigned long start;
> unsigned long len;
> - unsigned int irq;
> + /* irq > 0 means: use irq $irq;
> + * irq = 0 means: autoprobe for an irq;
> + * irq = -1 means: no irq support
> + */
> + int irq;
> };
>
> static struct tpm_info tis_default_info = {
> @@ -807,7 +811,7 @@ static int tpm_tis_init(struct device *dev, struct
> tpm_info *tpm_info,
> /* INTERRUPT Setup */
> init_waitqueue_head(&chip->vendor.read_queue);
> init_waitqueue_head(&chip->vendor.int_queue);
> - if (interrupts) {
> + if (interrupts && tpm_info->irq != -1) {
> if (tpm_info->irq) {
> tpm_tis_probe_irq_single(chip, intmask, IRQF_SHARED,
>tpm_info->irq);
> @@ -895,9 +899,9 @@ static SIMPLE_DEV_PM_OPS(tpm_tis_pm, tpm_pm_suspend,
> tpm_tis_resume);
>
> #ifdef CONFIG_PNP
> static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
> - const struct pnp_device_id *pnp_id)
> + const struct pnp_device_id *pnp_id)
> {
> - struct tpm_info tpm_info = tis_default_info;
> + struct tpm_info tpm_info = {};
> acpi_handle acpi_dev_handle = NULL;
>
> tpm_info.start = pnp_mem_start(pnp_dev, 0);
> @@ -906,7 +910,7 @@ static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
> if (pnp_irq_valid(pnp_dev, 0))
> tpm_info.irq = pnp_irq(pnp_dev, 0);
> else
> - interrupts = false;
> + tpm_info.irq = -1;
>
> #ifdef CONFIG_ACPI
> if (pnp_acpi_device(pnp_dev)) {
> @@ -984,6 +988,7 @@ static int tpm_tis_acpi_init(struct acpi_device *acpi_dev)
> return -ENODEV;
>
> INIT_LIST_HEAD(&resources);
> + tpm_info.irq = -1;
> ret = acpi_dev_get_resources(acpi_dev, &resources, tpm_check_resource,
>&tpm_info);
> if (ret < 0)
> @@ -991,9 +996,6 @@ static int tpm_tis_acpi_init(struct acpi_device *acpi_dev)
>
> acpi_dev_free_resource_list(&resources);
>
> - if (!tpm_info.irq)
> - interrupts = false;
> -
> if (is_itpm(acpi_dev))
> itpm = true;
>
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/7] tpm_tis: Use devm_ioremap_resource
On Thu, Dec 17, 2015 at 11:23:17AM -0700, Jason Gunthorpe wrote:
> This does a request_resource under the covers which means tis holds a
> lock on the memory range it is using so other drivers cannot grab it.
> When doing probing it is important to ensure that other drivers are
> not using the same range before tis starts touching it.
>
> To do this flow the actual struct resource from the device right
> through to devm_ioremap_resource. This ensures all the proper resource
> meta-data is carried down.
Reviewed-by: Jarkko Sakkinen
> Signed-off-by: Jason Gunthorpe
> Tested-by: Wilck, Martin
> Tested-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm_tis.c | 29 -
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index b2b31f5418ca..856fb35e574c 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -67,8 +67,7 @@ enum tis_defaults {
> };
>
> struct tpm_info {
> - unsigned long start;
> - unsigned long len;
> + struct resource res;
> /* irq > 0 means: use irq $irq;
>* irq = 0 means: autoprobe for an irq;
>* irq = -1 means: no irq support
> @@ -77,8 +76,11 @@ struct tpm_info {
> };
>
> static struct tpm_info tis_default_info = {
> - .start = TIS_MEM_BASE,
> - .len = TIS_MEM_LEN,
> + .res = {
> + .start = TIS_MEM_BASE,
> + .end = TIS_MEM_BASE + TIS_MEM_LEN - 1,
> + .flags = IORESOURCE_MEM,
> + },
> .irq = 0,
> };
>
> @@ -692,7 +694,7 @@ static int tpm_tis_init(struct device *dev, struct
> tpm_info *tpm_info,
> chip->acpi_dev_handle = acpi_dev_handle;
> #endif
>
> - chip->vendor.iobase = devm_ioremap(dev, tpm_info->start, tpm_info->len);
> + chip->vendor.iobase = devm_ioremap_resource(dev, &tpm_info->res);
> if (!chip->vendor.iobase)
> return -EIO;
>
> @@ -875,9 +877,12 @@ static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
> {
> struct tpm_info tpm_info = {};
> acpi_handle acpi_dev_handle = NULL;
> + struct resource *res;
>
> - tpm_info.start = pnp_mem_start(pnp_dev, 0);
> - tpm_info.len = pnp_mem_len(pnp_dev, 0);
> + res = pnp_get_resource(pnp_dev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENODEV;
> + tpm_info.res = *res;
>
> if (pnp_irq_valid(pnp_dev, 0))
> tpm_info.irq = pnp_irq(pnp_dev, 0);
> @@ -940,12 +945,10 @@ static int tpm_check_resource(struct acpi_resource
> *ares, void *data)
> struct tpm_info *tpm_info = (struct tpm_info *) data;
> struct resource res;
>
> - if (acpi_dev_resource_interrupt(ares, 0, &res)) {
> + if (acpi_dev_resource_interrupt(ares, 0, &res))
> tpm_info->irq = res.start;
> - } else if (acpi_dev_resource_memory(ares, &res)) {
> - tpm_info->start = res.start;
> - tpm_info->len = resource_size(&res);
> - }
> + else if (acpi_dev_resource_memory(ares, &res))
> + tpm_info->res = res;
>
> return 1;
> }
> @@ -978,7 +981,7 @@ static int tpm_tis_acpi_init(struct acpi_device *acpi_dev)
>
> acpi_dev_free_resource_list(&resources);
>
> - if (tpm_info.start == 0 && tpm_info.len == 0) {
> + if (resource_type(&tpm_info.res) != IORESOURCE_MEM) {
> dev_err(&acpi_dev->dev,
> FW_BUG "TPM2 ACPI table does not define a memory
> resource\n");
> return -EINVAL;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer()
>> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); >> + ABB5ZES3_REG_TIM_CLK_TAC0 >> + | ABB5ZES3_REG_TIM_CLK_TAC1, >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > This doesn't seem like an improvement. Interesting … > The concept (mask) has disappeared, I suggest to drop another local variable. Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > the binary operation is strangely broken, Do you prefer an other source code formatting within the usual line length range? > and the function call has one more line of arguments, How should several long preprocessor symbols be combined together with indentation so that they will fit into the limit of 80 characters? > which all look sort of the same and thus are hard to understand. Is this an usual consequence from an ordinary name pattern? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 5/7] tpm_tis: Clean up the force=1 module parameter
On Thu, Dec 17, 2015 at 11:23:18AM -0700, Jason Gunthorpe wrote:
> The TPM core has long assumed that every device has a driver attached,
> however the force path was attaching the TPM core outside of a driver
> context. This isn't generally reliable as the user could detatch the
> driver using sysfs or something, but commit b8b2c7d845d5 ("base/platform:
> assert that dev_pm_domain callbacks are called unconditionally")
> forced the issue by leaving the driver pointer NULL if there is
> no probe.
>
> Rework the TPM setup to create a platform device with resources and
> then allow the driver core to naturally bind and probe it through the
> normal mechanisms. All this structure is needed anyhow to enable TPM
> for OF environments.
>
> Finally, since the entire flow is changing convert the init/exit to use
> the modern ifdef-less coding style when possible
>
> Reported-by: "Wilck, Martin"
> Signed-off-by: Jason Gunthorpe
> Tested-by: Wilck, Martin
> Tested-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm_tis.c | 173
> +++--
> 1 file changed, 106 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index 856fb35e574c..12aa96a69b6c 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -60,7 +60,6 @@ enum tis_int_flags {
> };
>
> enum tis_defaults {
> - TIS_MEM_BASE = 0xFED4,
> TIS_MEM_LEN = 0x5000,
> TIS_SHORT_TIMEOUT = 750,/* ms */
> TIS_LONG_TIMEOUT = 2000,/* 2 sec */
> @@ -75,15 +74,6 @@ struct tpm_info {
> int irq;
> };
>
> -static struct tpm_info tis_default_info = {
> - .res = {
> - .start = TIS_MEM_BASE,
> - .end = TIS_MEM_BASE + TIS_MEM_LEN - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - .irq = 0,
> -};
> -
> /* Some timeout values are needed before it is known whether the chip is
> * TPM 1.0 or TPM 2.0.
> */
> @@ -695,8 +685,8 @@ static int tpm_tis_init(struct device *dev, struct
> tpm_info *tpm_info,
> #endif
>
> chip->vendor.iobase = devm_ioremap_resource(dev, &tpm_info->res);
> - if (!chip->vendor.iobase)
> - return -EIO;
> + if (IS_ERR(chip->vendor.iobase))
> + return PTR_ERR(chip->vendor.iobase);
Isn't this a regression in the descendig patch in this series?
> /* Maximum timeouts */
> chip->vendor.timeout_a = TIS_TIMEOUT_A_MAX;
> @@ -825,7 +815,6 @@ out_err:
> return rc;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> static void tpm_tis_reenable_interrupts(struct tpm_chip *chip)
> {
> u32 intmask;
> @@ -867,11 +856,9 @@ static int tpm_tis_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(tpm_tis_pm, tpm_pm_suspend, tpm_tis_resume);
>
> -#ifdef CONFIG_PNP
> static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
> const struct pnp_device_id *pnp_id)
> {
> @@ -889,14 +876,12 @@ static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
> else
> tpm_info.irq = -1;
>
> -#ifdef CONFIG_ACPI
> if (pnp_acpi_device(pnp_dev)) {
> if (is_itpm(pnp_acpi_device(pnp_dev)))
> itpm = true;
>
> - acpi_dev_handle = pnp_acpi_device(pnp_dev)->handle;
> + acpi_dev_handle = ACPI_HANDLE(&pnp_dev->dev);
> }
> -#endif
>
> return tpm_tis_init(&pnp_dev->dev, &tpm_info, acpi_dev_handle);
> }
> @@ -937,7 +922,6 @@ static struct pnp_driver tis_pnp_driver = {
> module_param_string(hid, tpm_pnp_tbl[TIS_HID_USR_IDX].id,
> sizeof(tpm_pnp_tbl[TIS_HID_USR_IDX].id), 0444);
> MODULE_PARM_DESC(hid, "Set additional specific HID for this driver to
> probe");
> -#endif
>
> #ifdef CONFIG_ACPI
> static int tpm_check_resource(struct acpi_resource *ares, void *data)
> @@ -1024,80 +1008,135 @@ static struct acpi_driver tis_acpi_driver = {
> };
> #endif
>
> +static struct platform_device *force_pdev;
> +
> +static int tpm_tis_plat_probe(struct platform_device *pdev)
> +{
> + struct tpm_info tpm_info = {};
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + dev_err(&pdev->dev, "no memory resource defined\n");
> + return -ENODEV;
> + }
> + tpm_info.res = *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (res) {
> + tpm_info.irq = res->start;
> + } else {
> + if (pdev == force_pdev)
> + tpm_info.irq = -1;
> + else
> + /* When forcing auto probe the IRQ */
> + tpm_info.irq = 0;
> + }
> +
> + return tpm_tis_init(&pdev->dev, &tpm_info, NULL);
> +}
> +
> +static int tpm_tis_plat_remove(struct platform_device *pdev)
> +{
> + struct tpm_chip *chip = dev_get_drvdata(&pdev->dev);
> +
> + tpm_chip_unregister(chip
Re: [PATCH v3 6/7] tpm_crb: Drop le32_to_cpu(ioread32(..))
On Thu, Dec 17, 2015 at 11:23:19AM -0700, Jason Gunthorpe wrote:
> ioread32 and readl are defined to read from PCI style memory, ie little
> endian and return the result in host order. On platforms where a
> swap is required ioread32/readl do the swap internally (eg see ppc).
Reviewed-by: Jarkko Sakkinen
/Jarkko
> Signed-off-by: Jason Gunthorpe
> Tested-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm_crb.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 8dd70696ebe8..0237006dc4d8 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -89,7 +89,7 @@ static u8 crb_status(struct tpm_chip *chip)
> struct crb_priv *priv = chip->vendor.priv;
> u8 sts = 0;
>
> - if ((le32_to_cpu(ioread32(&priv->cca->start)) & CRB_START_INVOKE) !=
> + if ((ioread32(&priv->cca->start) & CRB_START_INVOKE) !=
> CRB_START_INVOKE)
> sts |= CRB_STS_COMPLETE;
>
> @@ -105,7 +105,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
> if (count < 6)
> return -EIO;
>
> - if (le32_to_cpu(ioread32(&priv->cca->sts)) & CRB_CA_STS_ERROR)
> + if (ioread32(&priv->cca->sts) & CRB_CA_STS_ERROR)
> return -EIO;
>
> memcpy_fromio(buf, priv->rsp, 6);
> @@ -141,11 +141,11 @@ static int crb_send(struct tpm_chip *chip, u8 *buf,
> size_t len)
> struct crb_priv *priv = chip->vendor.priv;
> int rc = 0;
>
> - if (len > le32_to_cpu(ioread32(&priv->cca->cmd_size))) {
> + if (len > ioread32(&priv->cca->cmd_size)) {
> dev_err(&chip->dev,
> "invalid command count value %x %zx\n",
> (unsigned int) len,
> - (size_t) le32_to_cpu(ioread32(&priv->cca->cmd_size)));
> + (size_t) ioread32(&priv->cca->cmd_size));
> return -E2BIG;
> }
>
> @@ -181,7 +181,7 @@ static void crb_cancel(struct tpm_chip *chip)
> static bool crb_req_canceled(struct tpm_chip *chip, u8 status)
> {
> struct crb_priv *priv = chip->vendor.priv;
> - u32 cancel = le32_to_cpu(ioread32(&priv->cca->cancel));
> + u32 cancel = ioread32(&priv->cca->cancel);
>
> return (cancel & CRB_CANCEL_INVOKE) == CRB_CANCEL_INVOKE;
> }
> @@ -251,10 +251,10 @@ static int crb_acpi_add(struct acpi_device *device)
> return -ENOMEM;
> }
>
> - pa = ((u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_high)) << 32) |
> - (u64) le32_to_cpu(ioread32(&priv->cca->cmd_pa_low));
> - priv->cmd = devm_ioremap_nocache(dev, pa,
> - ioread32(&priv->cca->cmd_size));
> + pa = ((u64)ioread32(&priv->cca->cmd_pa_high) << 32) |
> + (u64)ioread32(&priv->cca->cmd_pa_low);
> + priv->cmd =
> + devm_ioremap_nocache(dev, pa, ioread32(&priv->cca->cmd_size));
> if (!priv->cmd) {
> dev_err(dev, "ioremap of the command buffer failed\n");
> return -ENOMEM;
> @@ -262,8 +262,8 @@ static int crb_acpi_add(struct acpi_device *device)
>
> memcpy_fromio(&pa, &priv->cca->rsp_pa, 8);
> pa = le64_to_cpu(pa);
> - priv->rsp = devm_ioremap_nocache(dev, pa,
> - ioread32(&priv->cca->rsp_size));
> + priv->rsp =
> + devm_ioremap_nocache(dev, pa, ioread32(&priv->cca->rsp_size));
> if (!priv->rsp) {
> dev_err(dev, "ioremap of the response buffer failed\n");
> return -ENOMEM;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer()
On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >>ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > >> + ABB5ZES3_REG_TIM_CLK_TAC0 > >> + | ABB5ZES3_REG_TIM_CLK_TAC1, > >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > > > This doesn't seem like an improvement. > > Interesting … > > > > The concept (mask) has disappeared, > > I suggest to drop another local variable. > Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > > > > the binary operation is strangely broken, > > Do you prefer an other source code formatting within the usual line length > range? > > > > and the function call has one more line of arguments, > > How should several long preprocessor symbols be combined together with > indentation > so that they will fit into the limit of 80 characters? > > > > which all look sort of the same and thus are hard to understand. > > Is this an usual consequence from an ordinary name pattern? The original code was better. No 80 character problem, easy to distinguish one argument from another, moderately meaningful variable name, etc. julia
Re: [PATCH v3 7/7] tpm_crb: Use devm_ioremap_resource
On Thu, Dec 17, 2015 at 11:23:20AM -0700, Jason Gunthorpe wrote:
> To support the force mode in tpm_tis we need to use resource locking
> in tpm_crb as well, via devm_ioremap_resource.
>
> The light restructuring better aligns crb and tis and makes it easier
> to see the that new changes make sense.
This patch mixes two items: restructing and actual change.
It might make the code cleaner but this patch harder to accept because
it contains more code changes are therefore more risks of regressions.
Tested code is better than clean code.
You should propose clean ups on smaller scale (patches) and not and not
hidden into other changes.
/Jarkko
>
> Signed-off-by: Jason Gunthorpe
> Tested-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm_crb.c | 157
> +++--
> 1 file changed, 108 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 0237006dc4d8..1f844cc63016 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -77,6 +77,8 @@ enum crb_flags {
>
> struct crb_priv {
> unsigned int flags;
> + struct resource res;
> + void __iomem *iobase;
> struct crb_control_area __iomem *cca;
> u8 __iomem *cmd;
> u8 __iomem *rsp;
> @@ -196,22 +198,121 @@ static const struct tpm_class_ops tpm_crb = {
> .req_complete_val = CRB_STS_COMPLETE,
> };
>
> -static int crb_acpi_add(struct acpi_device *device)
> +static int crb_init(struct acpi_device *device, struct crb_priv *priv)
> {
> struct tpm_chip *chip;
> + int rc;
> +
> + chip = tpmm_chip_alloc(&device->dev, &tpm_crb);
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + chip->vendor.priv = priv;
> + chip->acpi_dev_handle = device->handle;
> + chip->flags = TPM_CHIP_FLAG_TPM2;
> +
> + rc = tpm_get_timeouts(chip);
> + if (rc)
> + return rc;
> +
> + rc = tpm2_do_selftest(chip);
> + if (rc)
> + return rc;
> +
> + return tpm_chip_register(chip);
> +}
> +
> +static int crb_check_resource(struct acpi_resource *ares, void *data)
> +{
> + struct crb_priv *priv = data;
> + struct resource res;
> +
> + if (acpi_dev_resource_memory(ares, &res))
> + priv->res = res;
> +
> + return 1;
> +}
> +
> +static void __iomem *crb_access(struct device *dev, struct crb_priv *priv,
> + u64 start, u32 size)
> +{
> + struct resource tmp = {};
> +
> + tmp.start = start;
> + tmp.end = start + size - 1;
> + tmp.flags = IORESOURCE_MEM;
> +
> + /* Detect a 64 bit address on a 32 bit system */
> + if (start != tmp.start)
> + return ERR_PTR(-EINVAL);
> +
> + if (!resource_contains(&priv->res, &tmp)) {
> + dev_err(dev,
> + FW_BUG "TPM2 ACPI sub resource %pR is not in the
> device's region of %pR\n",
> + &tmp, &priv->res);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return priv->iobase + (tmp.start - priv->res.start);
> +}
> +
> +static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
> + struct acpi_table_tpm2 *buf)
> +{
> + struct list_head resources;
> + struct device *dev = &device->dev;
> + u64 pa;
> + int ret;
> +
> + INIT_LIST_HEAD(&resources);
> + ret = acpi_dev_get_resources(device, &resources, crb_check_resource,
> + priv);
> + if (ret < 0)
> + return ret;
> + acpi_dev_free_resource_list(&resources);
> +
> + if (resource_type(&priv->res) != IORESOURCE_MEM) {
> + dev_err(dev,
> + FW_BUG "TPM2 ACPI table does not define a memory
> resource\n");
> + return -EINVAL;
> + }
> +
> + priv->iobase = devm_ioremap_resource(dev, &priv->res);
> + if (IS_ERR(priv->iobase))
> + return PTR_ERR(priv->iobase);
> +
> + priv->cca = crb_access(dev, priv, buf->control_address, 0x1000);
> + if (IS_ERR(priv->cca))
> + return PTR_ERR(priv->cca);
> +
> + pa = ((u64)ioread32(&priv->cca->cmd_pa_high) << 32) |
> + (u64)ioread32(&priv->cca->cmd_pa_low);
> + priv->cmd = crb_access(dev, priv, pa, ioread32(&priv->cca->cmd_size));
> + if (IS_ERR(priv->cmd))
> + return PTR_ERR(priv->cmd);
> +
> + memcpy_fromio(&pa, &priv->cca->rsp_pa, 8);
> + pa = le64_to_cpu(pa);
> + priv->rsp = crb_access(dev, priv, pa, ioread32(&priv->cca->rsp_size));
> + if (IS_ERR(priv->rsp))
> + return PTR_ERR(priv->rsp);
> + return 0;
> +}
> +
> +static int crb_acpi_add(struct acpi_device *device)
> +{
> struct acpi_table_tpm2 *buf;
> struct crb_priv *priv;
> struct device *dev = &device->dev;
> acpi_status status;
> u32 sm;
> - u64 pa;
> int rc;
>
> status = acpi_get_table(ACPI_SIG_TPM2, 1,
> (
[PATCH] drivers: staging: xgifb: vgatypes.h: fixed coding style warnings
fixed warnings about comment block coding style
Signed-off-by: Saatvik Arya
---
drivers/staging/xgifb/vgatypes.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/xgifb/vgatypes.h b/drivers/staging/xgifb/vgatypes.h
index 61fa10f..de80e5c 100644
--- a/drivers/staging/xgifb/vgatypes.h
+++ b/drivers/staging/xgifb/vgatypes.h
@@ -27,14 +27,16 @@ struct xgi_hw_device_info {
/* of Linear VGA memory */
unsigned long ulVideoMemorySize; /* size, in bytes, of the
- memory on the board */
+ * memory on the board
+ */
unsigned char jChipType; /* Used to Identify Graphics Chip */
/* defined in the data structure type */
/* "XGI_CHIP_TYPE" */
unsigned char jChipRevision; /* Used to Identify Graphics
- Chip Revision */
+ * Chip Revision
+ */
unsigned char ujVBChipID; /* the ID of video bridge */
/* defined in the data structure type */
@@ -46,4 +48,3 @@ struct xgi_hw_device_info {
/* Additional IOCTL for communication xgifb <> X driver*/
/* If changing this, xgifb.h must also be changed (for xgifb) */
#endif
-
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init()
>> Replace explicit initialisation for two local variables at the beginning >> by assignments. > > Why? I prefer that assignments for variables like "card" and "slic_regs" will only be performed immediately before the corresponding content will be read again (after a few condition checks were executed). Another description could be this view: I suggest to move the variable initialisation a bit. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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-slicoss: Replace variable initialisations by assignments in slic_if_init()
On Sun, Jan 03, 2016 at 06:48:17PM +0100, SF Markus Elfring wrote: > >> Replace explicit initialisation for two local variables at the beginning > >> by assignments. > > > > Why? > > I prefer that assignments for variables like "card" and "slic_regs" > will only be performed immediately before the corresponding content will be > read again (after a few condition checks were executed). > > Another description could be this view: > I suggest to move the variable initialisation a bit. And like David Miller and others just said, please don't bother us with pointless patches such as this, if you keep it up, I'll have to add you to my killfile as patches like this are a waste of everyone's valuable time. 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] af_unix: Fix splice-bind deadlock
Rainer Weikusat writes:
> Hannes Frederic Sowa writes:
>> On 27.12.2015 21:13, Rainer Weikusat wrote:
>>> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res)
>>> +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t
>>> mode,
>>> + struct path *res)
>>> {
>>> - struct dentry *dentry;
>>> - struct path path;
>>> - int err = 0;
>>> - /*
>>> -* Get the parent directory, calculate the hash for last
>>> -* component.
>>> -*/
>>> - dentry = kern_path_create(AT_FDCWD, sun_path, &path, 0);
>>> - err = PTR_ERR(dentry);
>>> - if (IS_ERR(dentry))
>>> - return err;
>>> + int err;
>>>
>>> - /*
>>> -* All right, let's create it.
>>> -*/
>>> - err = security_path_mknod(&path, dentry, mode, 0);
>>> + err = security_path_mknod(path, dentry, mode, 0);
>>> if (!err) {
>>> - err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0);
>>> + err = vfs_mknod(d_inode(path->dentry), dentry, mode, 0);
>>> if (!err) {
>>> - res->mnt = mntget(path.mnt);
>>> + res->mnt = mntget(path->mnt);
>>> res->dentry = dget(dentry);
>>> }
>>> }
>>> - done_path_create(&path, dentry);
>>> +
>>
>> The reordered call to done_path_create will change the locking
>> ordering between the i_mutexes and the unix readlock. Can you comment
>> on this? On a first sight this looks like a much more dangerous change
>> than the original deadlock report. Can't this also conflict with
>> splice code deep down in vfs layer?
>
> Practical consideration
[...]
> A deadlock was possible here if the thread doing the bind then blocked
> when trying to acquire the readlock while the thread holding the
> readlock is blocked on another lock held by a thread trying to perform
> an operation on the same directory as the bind (possibly with some
> indirection).
Since this was probably pretty much a "write only" sentence, I think I
should try this again (with apologies in case a now err on the other
side and rather explain to much --- my abilities to express myself such
that people understand what I mean to express instead of just getting
mad at me are not great).
For a deadlock to happen here, there needs to be a cycle (circle?) of
threads each holding one lock and blocking while trying to acquire
another lock which ultimatively ends with a thread trying to acquire the
i_mutex of the directory where the socket name is to be created. The
binding thread would need to block when trying to acquire the
readlock. But (contrary to what I originally wrote[*]) this cannot happen
because the af_unix code doesn't lock anything non-socket related while
holding the readlock. The only instance of that was in _bind and caused
the deadlock.
[*] I misread
static ssize_t skb_unix_socket_splice(struct sock *sk,
struct pipe_inode_info *pipe,
struct splice_pipe_desc *spd)
{
int ret;
struct unix_sock *u = unix_sk(sk);
mutex_unlock(&u->readlock);
ret = splice_to_pipe(pipe, spd);
mutex_lock(&u->readlock);
return ret;
}
as 'lock followed by unlock' instead of 'unlock followed by lock'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] af_unix: Fix splice-bind deadlock
Rainer Weikusat writes:
[...]
> + dentry = NULL;
> + if (sun_path[0]) {
> + /* Get the parent directory, calculate the hash for last
> + * component.
> + */
> + dentry = kern_path_create(AT_FDCWD, sun_path, &path, 0);
> +
> + err = PTR_ERR(dentry);
> + if (IS_ERR(dentry))
> + goto out;
> + }
> +
This is wrong because kern_path_create can return with -EEXIST which
needs to be translated to -EADDRINUSE for this case. I'll fix that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: smp_read_barrier_depends() for Blackfin
On Sun, Jan 03, 2016 at 06:25:39PM +0200, Petko Manolov wrote: > Content preview: Hi Paul, Ingo, It seems to me that smp_read_barrier_depends > (which resolves to ___raw_smp_check_barrier_asm) is overdoing it, unless >that particular part it is written for is a disaster in terms of cache > coherency. > [...] > > Content analysis details: (-1.0 points, 5.0 required) > > pts rule name description > -- > -- > -1.0 ALL_TRUSTEDPassed through trusted hosts only via SMTP > X-ZLA-Header: unknown; 0 > X-ZLA-DetailInfo: BA=6.4041; NDR=6.0001; ZLA=6.0005; > ZF=6.0009; ZB=6.; ZH=6.; ZP=6.; ZU=6.0002; > UDB=6.00287883; UTC=2016-01-03 16:24:57 > x-cbid: 16010316-2214---0F04BD9C > X-IBM-ISS-SpamDetectors: Score=0.415652; FLB=0; FLI=0; BY=0.280117; FL=0; > FP=0; FZ=0; HX=0; KW=0; PH=0; RB=0; SC=0.415652; ST=0; TS=0; UL=0; ISC= > X-IBM-ISS-DetailInfo: BY=3.4748; HX=3.0237; KW=3.0007; > PH=3.0004; SC=3.0129; SDB=6.00639970; UDB=6.00287883; UTC=2016-01-03 > 16:25:07 > X-TM-AS-MML: disable > > Hi Paul, Ingo, > > It seems to me that smp_read_barrier_depends (which resolves to > ___raw_smp_check_barrier_asm) is overdoing it, unless that particular part it > is > written for is a disaster in terms of cache coherency. > > So far this is the only architecture that i know of (baring Alpha) which > employs > non-empty read_barrier_depends(). I am wondering if this is really needed or > those who did the arch port got overly enthusiastic. If it is the former > then > you may include another example of crazy architecture in your book. :) Hello, Petko, I must defer to the architecture maintainers. That said, there was a time when the blackfin maintainer were trying to make an SMP system without cache coherence, that is, by simply wiring two UP-only blackfin CPUs into a single system. They were using cache-flush tricks to make things more-or-less work. And their ___raw_smp_check_barrier_asm() does look to be flushing caches, so maybe that is what is happening here. And the comment header for read_barrier_depends() seems to support this view. Adding the blackfin folks and the usual lists on CC. Might get us something better than my half-remembered hearsay and possible misinterpretations of header comments. ;-) That said, cache-incoherent systems might well be a good addition to the book. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/7] dax: add support for fsync/msync
On Wed, Dec 23, 2015 at 11:39 AM, Ross Zwisler wrote: > To properly handle fsync/msync in an efficient way DAX needs to track dirty > pages so it is able to flush them durably to media on demand. > > The tracking of dirty pages is done via the radix tree in struct > address_space. This radix tree is already used by the page writeback > infrastructure for tracking dirty pages associated with an open file, and > it already has support for exceptional (non struct page*) entries. We > build upon these features to add exceptional entries to the radix tree for > DAX dirty PMD or PTE pages at fault time. > > Signed-off-by: Ross Zwisler I'm hitting the following report with the ndctl dax test [1] on next-20151231. I bisected it to commit 3cb108f941de "dax-add-support-for-fsync-sync-v6". I'll take a closer look tomorrow, but in case someone can beat me to it, here's the back-trace: [ cut here ] kernel BUG at fs/inode.c:497! [..] CPU: 1 PID: 3001 Comm: umount Tainted: G O4.4.0-rc7+ #2412 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: 8800da2a5a00 ti: 880307794000 task.ti: 880307794000 RIP: 0010:[] [] clear_inode+0x71/0x80 RSP: 0018:880307797d50 EFLAGS: 00010002 RAX: 8800da2a5a00 RBX: 8800ca2e7328 RCX: 8800da2a5a28 RDX: 0001 RSI: 0005 RDI: 8800ca2e7530 RBP: 880307797d60 R08: 82900ae0 R09: R10: 8800ca2e7548 R11: R12: 8800ca2e7530 R13: 8800ca2e7328 R14: 8800da2e88d0 R15: 8800da2e88d0 FS: 7f2b22f4a880() GS:88031fc4() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 5648abd933e8 CR3: 7f3fc000 CR4: 06e0 Stack: 8800ca2e7328 8800ca2e7000 880307797d88 a01c18af 8800ca2e7328 8800ca2e74d0 a01ec740 880307797db0 81281038 8800ca2e74c0 880307797e00 8800ca2e7328 Call Trace: [] xfs_fs_evict_inode+0x5f/0x110 [xfs] [] evict+0xb8/0x180 [] dispose_list+0x3b/0x50 [] evict_inodes+0x144/0x170 [] generic_shutdown_super+0x3f/0xf0 [] kill_block_super+0x27/0x70 [] deactivate_locked_super+0x43/0x70 [] deactivate_super+0x5c/0x60 [] cleanup_mnt+0x3f/0x90 [] __cleanup_mnt+0x12/0x20 [] task_work_run+0x76/0x90 [] syscall_return_slowpath+0x20a/0x280 [] int_ret_from_sys_call+0x25/0x9f Code: 48 8d 93 30 03 00 00 48 39 c2 75 23 48 8b 83 d0 00 00 00 a8 20 74 1a a8 40 75 18 48 c7 8 3 d0 00 00 00 60 00 00 00 5b 41 5c 5d c3 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 1f 44 00 00 0f 1f 44 00 00 55 RIP [] clear_inode+0x71/0x80 RSP ---[ end trace 3b1d8898a94a4fc1 ]--- [1]: git://g...@github.com:pmem/ndctl.git pending make TESTS="test/dax.sh" check -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rcu_preempt self-detected stall on CPU from 4.4-rc4, since 3.17
On Sun, Jan 03, 2016 at 07:27:17PM +1100, Ross Green wrote: > I would not describe the load on this test machine as high or real time. > > Apart from a number of standard daemons not much more is running at all! > > I normally build a release kernel as soon as possible and set it running. > Typically I run a series of benchmarks to confirm most things appear > to be working and then just leave it running. During a normal day i > will check on the machine 4/5 times just to see how its going! > Typically I will logon remotely via wifi network connection. > > just for your information i will include a few other stack traces from > previous kernels that may show some trend! > > > Please see the attachments. Thank you for the additional details. This does look similar to some problems I am seeing, though only in heavy rcutorture workloads with CPU hotplugging. I have some crude workarounds in progress, see for example 2da26818e515 (rcu: Awaken grace-period kthread when stalled) at git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git. This workaround kicks the RCU grace-period kthread on every stall warning. In my testing, this workaround results in slow but real forward progress. I have a better workaround in progress, however, please note: 1. I have no intention of sending these workarounds upstream. 2. The workarounds will splat when they take effect. In other words, the idea is not to paper over the problem, but instead to allow me to separate testing concerns. 3. A fix is needed for the underlying bug, wherever it might be. Thanx, Paul > Regards, > > Ross > > > > On Sun, Jan 3, 2016 at 5:17 PM, Paul E. McKenney > wrote: > > On Sun, Jan 03, 2016 at 04:29:11PM +1100, Ross Green wrote: > >> Still seeing these rcu_preempt stalls on kernels through to 4.4-rc7 > >> > >> Still have not found a sure fire method to evoke this stall, but have > >> found that it will normally occur within a week of running a kernel - > >> usually when it is quiet with light load. > >> > >> Have seen similar self detected stalls all the way back to 3.17. > >> Most recent kernels have included 4.4-rc5 4.4-rc6 and 4.4-rc7 > >> > >> Regards, > >> > >> Ross > >> > >> On Fri, Dec 11, 2015 at 10:17 PM, Ross Green wrote: > >> > I have been getting these stalls in kernels going back to 3.17. > >> > > >> > This stall occurs usually under light load but often requires several > >> > days to show itself. I have not found any simple way to trigger the > >> > stall. Indeed heavy workloads seems not to show the fault. > >> > > >> > Anyone have any thoughts here? > >> > > >> > The recent patch by peterz with kernel/sched/wait.c I thought might > >> > help the situation, but alas after a few days of running 4.4-rc4 the > >> > following turned up. > >> > > >> > [179922.003570] INFO: rcu_preempt self-detected stall on CPU > >> > [179922.008178] INFO: rcu_preempt detected stalls on CPUs/tasks: > >> > [179922.008178] 0-...: (1 ticks this GP) idle=a91/1/0 > > > > CPU 0 is non-idle from an RCU perspective. > > > >> > softirq=1296733/1296733 fqs=0 > >> > [179922.008178] > >> > [179922.008209] (detected by 1, t=8775 jiffies, g=576439, c=576438, > >> > q=102) > >> > [179922.008209] Task dump for CPU 0: > >> > [179922.008209] swapper/0 R [179922.008209] running > >> > [179922.008209] 0 0 0 0x > >> > [179922.008209] Backtrace: > >> > > >> > [179922.008239] Backtrace aborted due to bad frame pointer > > > > Can't have everything, I guess... > > > >> > [179922.008239] rcu_preempt kthread starved for 8775 jiffies! g576439 > >> > c576438 f0x0 s3 ->state=0x1 > > > > Something is keeping the rcu_preempt grace-period kthread from > > running. This far into the grace period, it should have a > > timer event waking it every few jiffies. It is currently > > in TASK_INTERRUPTIBLE state. > > > >> > [179922.060302] 0-...: (1 ticks this GP) idle=a91/1/0 > >> > softirq=1296733/1296733 fqs=0 > >> > [179922.068023] (t=8775 jiffies g=576439 c=576438 q=102) > >> > [179922.073913] rcu_preempt kthread starved for 8775 jiffies! g576439 > >> > c576438 f0x2 s3 ->state=0x100 > > > > Same story, same grace period, pretty much same time. Now there is an FQS > > request (f0x2) and the state is now TASK_WAKING (->state=0x100 == 256). > > > >> > [179922.083587] Task dump for CPU 0: > >> > [179922.087097] swapper/0 R running 0 0 0 0x > >> > [179922.093292] Backtrace: > >> > [179922.096313] [] (dump_backtrace) from [] > >> > (show_stack+0x18/0x1c) > >> > [179922.104675] r7:c0908514 r6:80080193 r5: r4:c090aca8 > >> > [179922.110809] [] (show_stack) from [] > >> > (sched_show_task+0xbc/0x110) > >> > [179922.119049] [] (sched_show_task) from [] > >> > (dump_cpu_task+0x40/0x44) > >> > [179922.127624] r5:c0917680 r4: > >> > [179922.131042] [] (dump_cpu_task) from [] >
Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init()
>> I prefer that assignments for variables like "card" and "slic_regs" >> will only be performed immediately before the corresponding content will be >> read again (after a few condition checks were executed). >> >> Another description could be this view: >> I suggest to move the variable initialisation a bit. > > And like David Miller and others just said, please don't bother us with > pointless patches such as this, if you keep it up, I'll have to add you > to my killfile as patches like this are a waste of everyone's valuable time. I am a bit surprised that you do not like such source code fine-tuning. Will related software improvements get another chance later (eventually together with other changes)? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 69/78] ncr5380: Fix whitespace in comments using regexp
On Sun, 2016-01-03 at 14:10 +, One Thousand Gnomes wrote:
> On Sat, 02 Jan 2016 23:54:28 -0800
> Joe Perches wrote:
>
> > On Sun, 2016-01-03 at 16:06 +1100, Finn Thain wrote:
> > > Hanging indentation was a poor choice for the text inside comments. It
> > > has been used in the wrong places and done badly elsewhere. There is
> > > little consistency within any file. One fork of the core driver uses
> > > tabs for this indentation while the other uses spaces. Better to use
> > > flush-left alignment throughout.
> > >
> > > This patch is the result of the following substitution. It replaces tabs
> > > and spaces at the start of a comment line with a single space.
> > >
> > > perl -i -pe 's,^(\t*[/ ]\*)[ \t]+,$1 ,' drivers/scsi/{atari_,}NCR5380.c
> > >
> > > This removes some unimportant discrepancies between the two core driver
> > > forks so that the important ones become obvious, to facilitate
> > > reunification.
> >
> > I still think this patch is poor at best and
> > overall not useful.
>
> I would beg to differ. As a tool for understanding the differences as you
> step through the versions it's invaluable.
This removes intentional formatting that
makes reading comments easier.
diff -w works well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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-slicoss: Replace variable initialisations by assignments in slic_if_init()
On Sun, Jan 03, 2016 at 07:16:49PM +0100, SF Markus Elfring wrote: > >> I prefer that assignments for variables like "card" and "slic_regs" > >> will only be performed immediately before the corresponding content will be > >> read again (after a few condition checks were executed). > >> > >> Another description could be this view: > >> I suggest to move the variable initialisation a bit. > > > > And like David Miller and others just said, please don't bother us with > > pointless patches such as this, if you keep it up, I'll have to add you > > to my killfile as patches like this are a waste of everyone's valuable time. > > I am a bit surprised that you do not like such source code fine-tuning. It's moving stuff around for no real reason, why would I like it? Reading and reviewing and applying this type of stuff takes away from the time I have to spend reviewing and applying actual code fixes from other developers who are doing real and useful work. Remember maintainer's time is our most limited resource right now. You are abusing that by wasting their time for no valid reason. > Will related software improvements get another chance later (eventually > together > with other changes)? Define "improvements". Did you fix an obvious bug? Did you speed up the code in a measurable way? Did you make the code easier to understand somehow? For this patch you did none of these things. Code in staging needs to be moved out of staging, and this patch does nothing toward achieving that goal and it wastes people's time reviewing it to see if it is correct or not. Please stop or again, you will end up in some killfiles, if you haven't already been placed there. 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/
